読み込み中

設計ドキュメントまたはRFCを書く

先行事例とトレードオフを記入済みの、構造化された提案書。

10 分エンジニアリングClaude Cowork
読み込み中

セットアップ

プラグインを試す

Engineeringプラグインには、出発点として/system-designが同梱されており、RFCテンプレートへの記入とウィキ全体からの先行事例の検索を行えるようあらかじめ構造化されています。管理者がプラグインを管理していてまだ利用できない場合は、これをスキップしてください。以下の内容はこれを必要としません。

EngineeringStreamline engineering workflows — standups, code review, architecture decisions, incident response, and technical documentation. Works with your existing tools or standalone.
追加
/system-designDesign systems, services, and architectures.
Cowork で開く
/architectureCreate or evaluate an architecture decision record (ADR).
Cowork で開く

ツールを接続する

Claude Coworkは、お使いのシステムと直接連携することで、より強力になります。権限とアクセスはあなたが管理します。ツールアクセスについて学ぶ。

設定するには、Cowork内の Customize → コネクタ に移動します。

Confluence
過去のRFCやアーキテクチャページを調べ、新しいドキュメントをエンジニアリングスペースに直接書き込みます。Confluenceへのアクセスは、Atlassian Rovoコネクタ(JiraとConfluence)経由で行われます。
接続
GitHub
関連するコードと過去のADRを読み取り、提案が実際のシステムを正確に参照するようにします。
接続
Notion任意
RFCテンプレートを取得し、ドラフトをデザインレビューデータベースに公開します。
接続

作業フォルダを設定する

使用するファイル(RFCテンプレート、すでに書いた1ページの概要やメモ、関連する過去のRFC、サービスのアーキテクチャ図)を1つのフォルダにドラッグし、Coworkにそのフォルダを指定します。Coworkはそこから読み取り、ドラフト、代替案の比較表、図をそこに書き戻します。RFCsフォルダからCoworkプロジェクトを作成すれば、テンプレート、レビューチェックリスト、チームの執筆規約がそのまま紐づいた状態を保てます。

RFCs / 0087-streaming-events
rfc-template.mdJan 4, 20262 KB
notes-streaming-migration.mdApr 24, 20265 KB
current-pipeline-diagram.pngMar 11, 2026142 KB
Cowork のチャットバーで:RFCs / 0087-streaming-events

プロンプト

これをClaude Coworkにコピーする

イベントパイプラインをバッチからストリーミングに移行するための設計ドキュメントを書いてください。先行事例とアーキテクチャ上の制約を調べ、その後、私たちのRFCテンプレートに沿って提案をドラフトしてください:問題、ゴールと非ゴール、トレードオフを伴う2つか3つのアプローチ、推奨案、そして未解決の課題。私しか知らない部分は私が記入します。

RFCs / 0087-streaming-events

これがうまくいく理由

プロンプト

先行事例を明示的に求めましょう。 Coworkはウィキと過去のRFCを検索し、これまでに試されたことをドキュメントに引用します。

プロンプト

2つか3つのアプローチを強制しましょう。 最初のアイデアの売り込みではなく、本物のトレードオフ表が得られます。

プロンプト

自分が記入する部分を伝えましょう。 Coworkが構造と調査を担当するので、あなたは実際の判断に時間を使えます。

ソース

従うべきテンプレートを渡しましょう。 出力はあなたのセクションと見出しに従うため、レビュアーは期待通りの構造を目にします。

より良いドラフトを得る

練習

お手本となる例を追加しましょう。 気に入っている例をフォルダに入れておくと、Coworkがその構成と文体に合わせます。

練習

不確かな点を指摘するよう依頼しましょう。 「自信がない部分にはフラグを立ててください」と付け加えておくと、ドラフトをレビューする際に最初に確認すべき箇所がわかります。

Coworkを自分のために働かせる

プラグインのスキルはあくまで出発点です。自分自身のやり方や専門知識でカスタマイズしましょう。数分間の会話をすれば、それ以降はあなたの基準に沿って動作します。

このタスクでここまで行ったことをスキルにしてください。あるいは、私のフィードバックをもとに/system-designスキルを編集してください。

RFCs

繰り返し使えるようにする

どんな1ページの概要からでも実行する

設計ドキュメントは、Slackスレッドの一段落やメモファイルから始まります。/scheduleと入力するか、CoworkのサイドバーでScheduledを開くと、カスタマイズされたスキルがRFCs/inboxフォルダを監視し、新しい1ページの概要を構造化された最初のドラフトに変換します。

/schedule 平日の午前9時に、RFCs/inboxで新しい1ページの概要を確認し、それぞれに対して/system-designを実行し、構造化されたドラフトをRFCs/配下の番号付きフォルダに書き込んでください。

RFCs
スケジュールタスクアクティブ
RFC受信箱からドラフトへ

平日の午前9時に、RFCs/inboxから新しい1ページの概要を取り込み、先行事例の検索を伴う/system-designを実行し、構造化されたドラフトを番号付きのRFCフォルダに書き込みます。

平日午前9時Cowork で開く

チームメンバーと共有する

カスタマイズされた/system-designには、あなたのテンプレート、先行事例の情報源、レビュアーが常に確認する質問事項が組み込まれています。これを共有すれば、すべてのテックリードのRFCが同じ形式で届くようになり、アーキテクチャレビューはフォーマットではなく意思決定に時間を使えるようになります。

設計レビューで何が変わるか