「ブリーフ」メソッド：Claude Codeで10倍良い結果を得る方法
ドラフト: 2026年3月9日 | プラットフォーム: Dev.to + Hashnode | トーン: 開発者から開発者へ | ステータス: レビュー準備完了
Claude Codeを試して中途半端な結果に終わる多くの開発者に共通する問題は、彼らがブリーフを作成せずに願望を書いていることです。
「この関数をより良くしてください」というのは願望です。
ブリーフは全く異なります。
ブリーフとは何か
Claude Codeのブリーフは4つのパートからなる構造化されたタスク説明です：
- コンテキスト — このコードは何か？何をするのか？システム全体のどこに位置するのか？
- タスク — 具体的に何をしてほしいのか？
- 制約条件 — 何を変更してはいけないか？どの基準を守らなければならないか？
- 成功基準 — どうすれば成功と判断できるか？
実践での違いは以下の通りです。
願望：
「支払い処理モジュールをよりきれいにリファクタリングしてください」
ブリーフ：
「コンテキスト：これは私たちの支払い処理モジュール（src/payments/processor.py）です。Stripeのウェブフックを処理し、注文テーブルに書き込みを行います。2021年に作成されて以来、触られていません。現在は約500件の取引／日を処理しています。
タスク：可読性向上のためリファクタリングしてください。主な問題は関数の長さ（process_webhookは180行あること）とエラーハンドリング（至る所にbare except句があること）です。
制約条件：関数のシグネチャは絶対に変更しないでください—他のモジュールが依存しています。データベースの書き込みロジックも変更禁止—これは別途レビューが必要です。Stripeライブラリのバージョンは維持してください。
成功基準：すべての関数を50行未満にすること。bare except句の代わりに特定の例外型を使うこと。テストスイートはすべてパスすること。」
最初のプロンプトは何かを返してくれますが、二つ目は実際に使えるものを返してくれます。
なぜコンテキストが最も重要か
Claude Codeはあなたのコードベースを読み解きます。それがその強みです。しかし読み取るのは関連する部分だけであり、「関連性」はあなたが焦点を伝えた内容で決まります。
コンテキストがなければ、Claude Codeは重要なものを推測します。時には正しく推測しますが、多くの場合、技術的には正しいけれども実務的には誤りとなる変更を行います。例えば、ordersテーブルがリードレプリカで書き込み不可であることを知らなければ。
あなたのコンテキスト説明は以下に答えるべきです：
- このコードは何のためのものか？
- 何と繋がっているのか？（他のモジュール、外部サービス、データベース）
- 履歴や既知の複雑性は？（レガシー、頻繁に変更されている、別チームの所有など）
- トラフィック／業務上の重要性は？
3文のコンテキストで3回の修正ラウンドを防げます。
制約条件セクションは安全網
多くのAIコード生成時のトラブルは制約条件未指定が原因です。
「このAPIエンドポイントをより高速化してください」→Claude Codeがルーティングを再構成し他の5つのエンドポイントを破壊する、という具合に。
速くするという点は間違っていません。問題はルーティングが触ってはいけない領域だと伝えていなかったことです。
常に考慮すべき制約条件:
- インターフェース制約：関数シグネチャ、API契約、変更できないデータベーススキーマ
- 依存関係制約：ライブラリ、バージョン、互換性の要件
- スコープ制約：見た目が間違っていても触ってはいけない部分
- スタイル制約：チームが使う特定のパターンや規約
成功基準が評価を閉じる
ここは開発者が最も省きがちな部分で、Claude Codeを自己評価可能にします。
「テストスイートが全て通る」が成功基準に入っていれば、Claude Codeはテストを実行して合格するまで繰り返します。「すべての関数が50行未満」も自身の出力を検証します。
成功基準がなければ、「これが私のベストな試みです」と言われて評価は自分で行うしかありません。
良い成功基準は：
- 測定可能 — 「全テストパス」、ただの「コードが良い」ではない
- 検証可能 — Claude Code自体がチェックできるもの
- 適切な数 — 小さなタスクなら2〜3基準、複雑なものなら5〜6基準
コピー可能なブリーフテンプレート
コンテキスト:
[このコードは何か、何をするか、システム内の位置、トラフィック／重要性]
タスク:
[具体的で動詞始まりの指示]
制約条件:
- [変更してはいけないこと]
- [保持すべきこと]
- [遵守すべき標準／スタイル]
成功基準:
- [測定可能な成果1]
- [測定可能な成果2]
- [完了を検証するテストやチェック]
チームでこのフォーマットを共有すると
ブリーフフォーマットは個人だけでなくチーム単位でも非常に有用です。
みんなが同じ方法でブリーフを書くと：
- PRレビューで委任された内容と自分で書いた内容を追跡できる
- 不適切なブリーフを見つけて学習できる
- ジュニア開発者の成長が早まる（考え方の足場ができるため）
- 再利用可能な良質なブリーフのライブラリが構築される
Claude Codeで最大のROIを得ているチームは、最も多くのAPIアクセス権を持つチームではありません。ブリーフ作成をチームの習慣にしたチームです。
まずここから始めよう
次のClaude Codeタスクは、4要素すべてを含むブリーフとして書いてみましょう。5分余計にかかります。
戻ってくるものを見てみてください。
もう願望を書くことはないと断言します。
これをエンジニアリングチーム全体に展開する方法を考えているなら、それこそがAsk Patrickのコーワークプログラムがカバーする内容です。askpatrick.co/co-work
Ask Patrickはエンジニアリングチーム向けに定額料金制のコーワークセッションを運営しています。無料チーム評価はこちら：https://askpatrick.co/assessment.html
