📝 本記事について:この記事は AI(Claude)と共同で執筆しています。構成案・調査・下書きを AI と壁打ちしながらまとめ、最終的な編集・主観的判断は人間(筆者)が行っています。本記事で触れる AIエージェントの挙動・ツール仕様・各種テクニックは 2026年6月13日時点の調査と実感に基づきます。AIモデルもエージェント基盤も更新が速いため、本番運用に組み込む前に各公式ドキュメントの最新版で再確認してください。
はじめに
ある夜、自分はAIエージェントに「この企画、筋が良いと思うんだけど、どう?」と聞いて、見事に気持ちよく騙されました。
返ってきたのは、流暢で、構造的で、自信に満ちた肯定でした。「市場性があります」「技術的にも妥当です」「競合との差別化も明確です」──読んでいて思わず頷きそうになるくらい、よくできた回答です。けれど一晩おいて読み返すと、その大半は「自分が聞きたかったこと」を、それらしい言葉で言い換えただけのものでした。AIは何ひとつ嘘をついていないのに、自分の思い込みを高い解像度で補強してくれただけだったのです。
そのとき素直に思いました。このままだと、AIは自分の思考の拡張ではなく、ただの「高速な確証バイアス生成機」になる、と。AIエージェントとの協働で決定的な差がつくのは、プロンプトの巧拙ではありません。コンテキストの設計力と、AIの歪みを補正する問いの立て方です。
人間の思考は確証バイアスや可用性ヒューリスティックに縛られます。AIも同様に歪みますが、その歪みの形が人間と違う。AIは統計的にもっともらしいパターンに引きずられ、「それらしい答え」を高い確信度で出力します。この非対称な歪みを理解したうえで使うと、一人では到達できなかった思考の地平が開けます。本記事は、自分がAIエージェントを使い込むなかで「これは効く」と確信したコツを、横断・調査・設計・コーディングのフェーズ別に整理したものです。
TL;DR(読む時間がない人へ)
- 勝負はプロンプトではなくコンテキスト:「何を言うか」より「何を渡すか・何を渡さないか」で出力品質の大半が決まる
- AIをYes-manにしない:確証バイアスの増幅を防ぐため、検証は常に「肯定の確認」ではなく「反証の試み」として設計する
- モードを明示する:記述/分析/反証/ペルソナのどれを求めているかを毎回明確に指定すると、回答の質が安定する
- 比較と逆説で天井を壊す:「点数で評価して」より「Aと比べて何が足りないか」「失敗したとしたら原因は何か」が深い差分を引き出す
- 指摘は一回で消費せず資産に変える:レビューや調査で得た洞察を、CLAUDE.md・ガイドライン・ADRに昇華させるループを作る
- 使い込むほど自分の問いが鋭くなる:AIのために思考を構造化する習慣が、自分自身の思考力として転移する
本記事の対象範囲
-
扱うこと
- 全フェーズに効く「横断的コツ」(コンテキスト設計・自信の不信・比較・逆説・複数役割)
- 調査フェーズで「自分の認知の外側」を引き出すコツ
- 設計フェーズで制約・本質・死角を炙り出すコツ
- コーディングフェーズでコードベースの文脈に沿わせるコツ
- そのままコピペして使えるプロンプト例
-
扱わないこと
- 特定モデル・特定ツールの操作手順やUIの解説
- プロンプトエンジニアリングの網羅的なテクニック集
- エージェント基盤(MCP・スキル等)の実装方法
-
想定する読者像
- AIエージェントを「便利な検索」以上の相棒として使いこなしたい方
- 出力の流暢さに惑わされず、思考の質を上げる使い方を探している方
- 調査・設計・実装の各フェーズで、AIとの協働パターンを言語化したい方
Part 1: 横断的コツ ― 全フェーズに効く土台
最初に、フェーズを問わず効く土台を固めておきます。ここで紹介する6つは、このあとの調査・設計・コーディングのすべての章で繰り返し顔を出す「原則」です。逆に言えば、ここを押さえておけば、後続の各フェーズは「その原則をどう適用するか」という差分だけで読めるようになります。最後に、これら6原則を使い込んだ先に起きる「認知の転換」についても触れて、このPartを締めます。
1.1 プロンプトエンジニアリングからコンテキストエンジニアリングへ
「何を言うか」を磨くプロンプトエンジニアリングは、AIとの対話を「入力→出力」のブラックボックスとして扱います。けれども実際のAIは、その瞬間の会話の総体から回答を組み立てています。だから効くのは、一発の上手い指示よりも、回答の土台になるコンテキストの設計です。
自分が最低限そろえるようにしているのは、次の3要素です。
- 背景:なぜこの問いが生まれたか
- 制約:何をしてはいけないか(してほしくないか)
- ゴール:この会話ではなく、最終的に何を達成したいか
セッションの冒頭に、次のような「コンテキストの土台」を一度貼っておくだけで、以降の回答の精度がまるで変わります。
## セッションコンテキスト
### 私について
- 役割:[職種・経験年数]
- このプロジェクトでの私のゴール:[1〜2行]
### このセッションの目的
- 今日解決したい問い:[具体的に]
- 成功の定義:[どうなれば今日は成功か]
- 今日扱わないこと:[スコープ外の明示]
### 既知の制約
- 技術的制約:[例:既存DBスキーマは変えられない]
- 組織的制約:[例:チームに機械学習の専門家がいない]
- 時間的制約:[例:2週間でMVPが必要]
このコンテキストを理解した上で、最初の質問に答えてください。
⚠️ コンテキストは「多ければ良い」わけではない:無関係な情報を大量に与えると、AIはそこからむりやりパターンを見つけようとして判断が歪みます。コンテキスト設計は「足す技術」であると同時に「削る技術」でもあります。特に矛盾するコンテキストは致命的で、AIは矛盾を解消しようとして意図しない解釈に走ります。
1.2 コンテキストウィンドウの高度管理
会話履歴は、AIにとっての作業記憶(ワーキングメモリ)です。ここで人間の記憶との決定的な違いを押さえておく必要があります。人間の記憶は重要度でフィルタリングされますが、AIは位置によって情報の扱いに偏りが出るのです。コンテキスト全体にattentionはかかるものの、実際には冒頭と末尾の情報が強く効き、中盤の情報が相対的に埋もれやすい──いわゆる "lost in the middle" 現象が知られています。
つまり、会話の中盤で設定した重要な制約や目標は、対話が長くなるほど「埋没」していきます。冒頭で宣言した前提も、長い会話の末尾から見れば遠くなり、影響力が薄れます。これに対して自分がよくやるのが、定期的な「汚染チェック」です。
今の会話で、あなたが最も強く意識している制約と目標を3つ挙げてください。
私が最初に伝えた要件と一致していますか? ズレがあれば教えてください。
そして会話を閉じる前には、次の「蒸留と引き継ぎ」を必ず実行します。これを習慣にすると、長い検討が次のセッションに無駄なく繋がります。
この会話を終える前に、以下を作成してください:
1. 次の会話で必ず伝えるべき「前提知識」(3〜5行)
2. 今日発見した「意外な学び」(1〜2行)
3. 次に検討すべき未解決の問い(1〜2個)
形式:次の会話の冒頭にそのまま貼れるMarkdownで。
💡 「決めたこと」より「決めなかったこと」を残す:却下した選択肢こそ、後から効いてくる情報です。Claude Code を使っているなら、メモリ機能がこの蓄積を助けてくれます(挙動はバージョンに依存するため、最新仕様は実機で確認してください)。要は「次の自分が同じ議論を二度しない」ための置き場を持つことです。
1.3 AIの「自信」を信頼しない技術
AIのハルシネーションには、構造的なパターンがあります。認知科学でいう「流暢さの錯覚(illusion of fluency)」です。回答が流暢であるほど人間はそれを正しいと判断しやすく、AIもまた流暢な誤りを生成しやすい。この二つが噛み合うと、もっともらしい嘘がいちばん見抜きにくくなります。
経験上、AIが特に間違えやすいのは次のようなパターンです。
- バージョン番号・日付・固有名詞などの数値
- 「AとBの関係」という複合的な主張
- 「〜はできない」という否定的な断言
- 最新情報と古い情報が混在する分野
だからこそ、回答を鵜呑みにする前に「不確実性の開示」を強制します。
この回答で、あなたが70%以上の確信を持てない部分に[要確認]タグを付けてください。
確信の根拠(学習データ? 論理的推論?)も明記してください。
さらに踏み込むなら、AIに自分の主張を攻撃させます。
あなたが今提示した[具体的な主張]について、
これが間違っている可能性のある根拠を3つ挙げてください。
その後、それでも正しいと思う理由を述べてください。
⚠️ 「正しいか確認して」は効果が低い:AIは自分の回答を肯定する方向に引きずられます。検証は常に「反証の試み」として設計してください。「これは間違っていないか?」ではなく「これが間違っている世界ではどうなるか?」という形にするのがコツです。
1.4 「比較」を武器にする
AIに「1〜10点で評価して」と聞くと、回答は中央やや上に引き寄せられがちです(自分の実感では6〜7点付近)。ところが「Aと比べてどうか」という比較の軸を与えた瞬間、AIは差分を探すモードに切り替わり、見逃していた具体的な違いを発見しやすくなります。評価を絶対値で求めるのではなく、相対値で求める。それだけで回答の解像度が上がります。
たとえば、自分の提案を架空の最高水準と比較させます。
[提案A]と[提案B]を比較するのではなく、
「現時点で業界最高水準と考えられる解決策」を架空で設定し、
私の提案はそれと比べて何が足りないか教えてください。
複雑さや規模感を掴みたいときは、両端を固定したスケールで相対化させます。
この設計の複雑さを、
「Todoアプリ」を1、「Googleの検索エンジン」を10としたとき、
何点に相当しますか? その根拠も教えてください。
💡 「6〜7点に寄る」は統計ではなく実感値:この手の体感ベースの主張を人に説明するときは「経験上」と明示し、断定を避けるのが安全です。比較プロンプトの効きどころも、データではなく「自分の手元で何度も再現した」レベルの話として扱ってください。
1.5 「発想の天井」を壊す逆説的問い
「どうすればXが実現できるか」という問いは、Xが実現可能であるという前提を埋め込んでしまいます。創造的な問題解決の多くは、認知科学でいう「制約緩和(constraint relaxation)」──当然とされていた制約を疑うこと──から始まります。だから自分は、前提そのものを揺さぶる問いをよく使います。
ひとつは、失敗から逆算するPre-mortemです。
3年後、このプロジェクトは完全に失敗しました。
最も可能性が高い失敗の原因を5つ挙げてください(技術・組織・市場・タイミング・競合の観点で)。
それを知っていたとして、今日変えるべきことは何ですか?
もうひとつは、いったん制約を全部外し、そこから現実に着地させる二段構えです。
ステップ1:予算・時間・技術・法律の制約がすべてない場合、この問題の理想的な解決策は?
ステップ2:その理想解の核心的な価値は何ですか?
ステップ3:その価値を、現実の制約の中で50%だけ実現するとしたら?
異分野の発想を借りるのも効きます。
この問題を[免疫システム/ジャズの即興演奏/都市計画/進化生物学]の視点から分析してください。
その分野での解決原理を、私たちの文脈に翻訳してください。
1.6 複数エージェントの「生産的対立」設計
単一のAIに質問し続けると、そのAIの内部一貫性が強化されるだけで、前提は問い直されません。複数のエージェントに構造的に異なる役割を与えると、その対立から前提が炙り出されます。設計レビューにも応用できる強力な型なので、ここで原則だけ押さえておきます(具体的な適用は Part 3 の設計フェーズで深掘りします)。
あなたは[楽観的な起業家/懐疑的な投資家/技術的完璧主義者/ユーザーの代弁者]として、
以下の提案に対して意見を述べてください:
[提案内容]
役割に忠実であるために、通常なら言わないような批判や賛成も含めてください。
矛盾をあえて作り出し、それを統合させるのも面白い使い方です。
この問題について、互いに矛盾する2つの真実を見つけてください。
例:「スピードが重要」かつ「品質が重要」など。
その矛盾を「両立させるための第三の道」を提案してください。
💡 役割は具体的なキャラクターとして与える:「投資家として」ではなく「2008年のリーマンショックを生き延びた、今は慎重なシリアルアントレプレナーとして」のように、具体的な経験と文脈を持たせると回答の深さが段違いになります。抽象的なロールは、表面的なロールプレイに終わります。
番外:使い込みが生む「認知的コペルニクス転換」
AIエージェントを長く使い込んだ人に共通する変化があります。それは 「AIに聞く前に、自分の問いを構造化する習慣」 が身につくことです。AIのために考えていたはずが、その整理力が「自分自身の思考を構造化する」能力として転移していく。これが、使い込みの最大の見返りだと自分は思っています。
その転移を意図的に加速させるのが、問いの変形訓練です。
私はあなたに「[漠然とした問い]」を聞こうとしています。
この問いを、より良い回答が得られるように3つの異なる方法で言い換えてください。
それぞれの言い換えが、何を明確にしているかも教えてください。
セッションの終わりに、協働そのものを振り返るのも効きます。
今日の会話を振り返って:
1. 私の問いが良かった瞬間とその理由
2. 私の問いが非効率だった瞬間とその理由
3. 今後のこのテーマとの対話で使えるパターン
を教えてください。
⚠️ 最大の失敗は「答えが出たら終わり」という消費的な使い方:AIを「思考の鏡」として使う、という意識の転換が、使い込みを深化させる最大のポイントです。
✅ このPartの要点(3行)
- 効くのは一発のプロンプトより、背景・制約・ゴールを揃えたコンテキストの設計(足す技術であり削る技術)。
- 検証は「肯定の確認」ではなく反証の試みとして設計する(自信・流暢さを信頼しない)。
- 比較・逆説・複数役割で発想の天井を壊し、得た問いの構造化力を自分自身へ転移させる。
📌 次のPartへの布石:ここまでの6原則(と、それを使い込んだ先の認知の転換)は、どのフェーズでも効く土台でした。次のPart 2では、これらを「調査フェーズ」に適用していきます。調査が難しいのは、そもそも「自分が何を知らないかが分からない」からです。AIに自分の認知の外側を引き出させる具体的な型を見ていきます。
Part 2: 調査フェーズのコツ
調査フェーズでAIが特に難しいのは、AIが「知っていることを整理する能力」は高い一方で、「何を知るべきかを判断する能力」はユーザー側に依存するからです。調査の本質的な問題は「自分の無知の範囲が分からない」ことなので、AIをうまく使うには「自分の認知の外側」を引き出す設計が要ります。Part 1 で触れた「比較」「反証」「複数役割」が、ここで一気に活きてきます。
2.1 「比較」ではなく「なぜ劣るのか」を問う
「AとBを比較せよ」と言うと、AIは表面的な差異を羅列します。けれど「なぜAはBに市場で負けているのか」と問うと、AIは因果関係の推論を強制されます。前者は記述、後者は分析です。同じ素材でも、問いの角度ひとつで返ってくるものの深さが変わります。
[比較対象:NotionとObsidian]
「ユーザー数ではNotionが圧倒しているが、Obsidianのほうが技術者に根強い支持がある。
この非対称性が生まれた理由を、
(1)製品哲学の違い
(2)課金モデルの設計意図
(3)コミュニティ形成の戦略
の3軸で分解して説明してください。
その上で、Notionが意図的に諦めているトレードオフを特定してください。」
時間軸を入れて「何が陳腐化したか」を問うのも有効です。
「このサービスの2020年時点の強みと2025年時点の強みを比較し、
どの強みが陳腐化し、何が代わりに台頭したか。
陳腐化した強みはなぜ強みでなくなったのか、
技術変化・市場変化・競合の行動の3つに分けて要因を示せ。」
⚠️ 「10項目で比較表を作れ」系は罠:AIが均等に枠を埋めようとするため、重要度の低い差異が同列に並びます。比較項目はAIに選ばせず、問いの角度を指定してください。
2.2 「私が見落としていること」を明示的に問う
AIは確証バイアスの増幅装置になりやすい存在です。「このビジネスは有望だと思うが分析して」と言えば、AIは概ね同調します。これを意図的に破るには、「反証を探す」モードへ明示的に切り替えさせます。調査結果ではなく、調査者である自分の認知を対象にするのがポイントです。
「以下が私の市場調査の結論です。
[結論を貼る]
この結論を導いた調査に含まれているであろう確証バイアスを3つ特定してください。
つまり、私がこの結論に都合のいい情報を無意識に選んでいると仮定した場合、
何が抜け落ちているか。
その上で、この結論を正面から否定するような反証データや事例が存在するとしたら、
どんなものが考えられるか仮説を立ててください。」
調査手法そのものの限界を突かせるのも効きます。
「この調査手法自体の限界を指摘してください。
具体的には:
- このデータソースが体系的に見えていない層は誰か
- このフレームワーク(例:SWOT)が前提としていて問えない問いは何か
- 調査期間・地域・対象者の偏りが結論に与える影響」
💡 「問題点を教えて」だけだと表面的:「私の思考プロセスのどこが甘いか」という形で、AIに自分の推論を攻撃させてください。対象を「結果」から「認知」へずらすと、返ってくる指摘の鋭さが変わります。
2.3 複数ソース間の「矛盾」を検出させる
調査の質は、情報量ではなく信頼性で決まります。AIはテキスト間の論理的な不整合を見つけるのが得意なので、この役割を任せると効果的です。
「以下の3つの情報源から得た市場規模データがあります。
[ソースA:2024年 市場規模1兆円]
[ソースB:2023年 市場規模7000億円]
[ソースC:2025年予測 8500億円]
これらの数字の間にある矛盾・不整合を分析してください。
矛盾がある場合、それが生じる可能な理由として:
(1) 定義の違い(何を市場に含めるか)
(2) 集計方法の違い
(3) データが実際に古くなっている
のどれが最も可能性が高いか、根拠とともに示してください。」
⚠️ AIは矛盾を「調和的に解釈」して消そうとする:放っておくと、無理やり辻褄を合わせた解釈を提示してきます。「矛盾を解消しなくていい、矛盾を矛盾として記述して」と明示することで、これを防げます。
2.4 仮説を「先に立ててから」調査させる
調査してから考えるより、考えてから調査するほうが質が上がります。仮説なしの調査は「何でも入ってくる状態」で、AIは膨大な情報を出してくるものの、取捨選択の基準がありません。先に仮説を置き、その検証として調査を設計します。
「私はこの市場について以下の仮説を持っています:
[仮説:「BtoBのSaaSは2026年以降、エージェント機能の有無で二極化し、
持たない製品は価格競争に追い込まれる」]
この仮説を検証するために:
(1) この仮説が正しいとすれば何が観察されるはずか(観測可能な証拠)
(2) この仮説が間違いとすれば何が観察されるはずか(反証の条件)
(3) 現時点で入手できる情報のうち、どちらの方向の証拠が多いか
の順序で分析してください。
先に結論を出さず、証拠の重みづけを丁寧に行ってください。」
⚠️ 仮説駆動の罠は確証バイアスの強化:2.2 の「見落とし」プロンプトとセットで使うと相殺できます。仮説は単独ではなく、複数立てて競合させるのがベストです。
2.5 「悪魔の代弁者」として問わせる
調査の目的が意思決定であるなら、最も価値があるのは「なぜこの方向に進むべきでないか」の情報です。AIに「悪魔の代弁者として振る舞え」と指示すると、AIのロールが明確に変わり、お世辞抜きの指摘が返ってきます。
「あなたは私のビジネスプランに投資しないVCです。
私のピッチを聞いて、投資を断る理由をできるだけ根拠を持って3〜5点挙げてください。
お世辞や「良い点もありますが」という前置きは不要です。
最も致命的な問題から順に述べてください。
[ビジネスプランを記載]」
より使いやすい迂回策が、Part 1 でも触れたPre-mortemです。
「この計画が3年後に失敗したとして、失敗の原因を過去形で書いてください。」
2.6 ペルソナを「利害関係者」に具体的に指定する
「競合他社の視点で」という曖昧なペルソナ指定は、効果が薄いです。利害関係者を具体的にすると、AIは「その人物が実際に気にすること」にフォーカスした分析を返します。
「あなたは[既存大手競合]のプロダクトマネージャーです。
私のサービス[説明を貼る]がリリースされたと仮定して:
(1) あなたの製品の何が最も脅威にさらされますか
(2) 半年以内にどんな対抗策を検討しますか
(3) 私のサービスのどの部分を「脅威でない」と判断しますか、その理由は
という視点で分析してください。」
ユーザーの離脱理由を一人称で描写させるのも、生々しい示唆が得られます。
「このサービスのターゲットユーザーが
『使ってみたが2週間で使うのをやめた』とした場合、
離脱の理由として最もありそうなものトップ3を、
ユーザー視点の内なる声(一人称)で描写してください。」
💡 ペルソナは解像度が命:「マーケターとして分析して」程度ではロールプレイに終始します。「業界歴15年で、自社の主力製品が侵食されることを恐れている中間管理職」くらいまで具体化すると、回答が一気に立体的になります。
2.7 「要因分解」を階層ごとに分離させる
「なぜこのトレンドが起きているのか」と問うと、AIは表層の要因と根本の要因を混ぜて答えがちです。階層を明示的に指定すると、分析が「表層現象→直接要因→構造要因→メタ要因」の形で整理されます。
「[観察されているトレンド]について要因分析をします。
以下の4層に分けて説明してください:
Layer 1(表層現象):数字や統計で観察できること
Layer 2(直接要因):Layer 1を直接引き起こしている要因
Layer 3(構造要因):Layer 2を可能にしている業界・社会の構造変化
Layer 4(メタ要因):このトレンド全体を生んでいる、さらに大きなパラダイムシフト
Layer 3とLayer 4に特に注力してください。
Layer 1,2は誰でも書けるので簡潔に。」
⚠️ なぜなぜ5回をそのままやらせない:Why-Why分析をAIに丸投げすると、後半で根拠の薄い「なぜ」を捏造しがちです。なぜの「回数」ではなく「層の種類」を指定するほうが、結果の質が安定します。
2.8 「このセッション全体を振り返って」で終わる
調査セッションは、最後の振り返りまでやって初めて次に繋がります。自分は調査を閉じる前に、必ずこれを投げます。
「今日の調査セッションを振り返って:
(1) 私が深く掘ったテーマと、表面だけ触れたテーマを分類してください
(2) 今日の調査全体を通して、私が一貫して避けていた問いはありますか
(3) 次の調査セッションで最優先に取り組むべき未解決の問いを
3つ挙げてください、その理由とともに」
✅ このPartの要点(3行)
- 「比較」より「なぜ劣るのか」、「結果の問題点」より「自分の認知の死角」を問う(記述から分析へ)。
- 仮説を先に複数立てて競合させ、その検証として調査を設計する(見落としプロンプトとセットで)。
- 悪魔の代弁者・具体的な利害関係者ペルソナ・層別の要因分解で、進むべきでない理由を炙り出す。
📌 次のPartへの布石:調査で「何を知るべきか」が見えてきたら、次は要件定義・設計です。設計フェーズで最も高くつく失敗は「正しいものを正確に作ったが、それは誰も欲しいものではなかった」という事故です。次のPart 3では、制約・本質・死角を炙り出して、その事故を未然に防ぐコツを見ていきます。
Part 3: 要件定義・設計フェーズのコツ
設計フェーズのAI活用は、コンテキストの質がそのまま提案の質に直結します。そして、Part 1 で原則だけ示した「複数役割によるレビュー」が、ここで本領を発揮します。順番に見ていきましょう。
3.1 プロンプトより「コンテキスト」を設計する
設計提案の質は、プロンプトの巧みさよりも渡したコンテキストの質で決まります。自分が設計フェーズで意識して渡すのは、次の4層です。
- ビジネス制約(予算、スケジュール、チームスキル、ベンダー契約)
- 技術制約(既存システム、移行コスト、パフォーマンス要件)
- 組織の前提知識(暗黙の意思決定ルール、過去に失敗した理由)
- 利害関係者の優先順位(誰が拒否権を持つか)
これを構造化して渡し、各案に「このコンテキストでの採用可否」まで言わせるのがコツです。
## プロジェクトコンテキスト
**ビジネス制約**
- リリース期限: 2026-08-01(変更不可。契約上の義務)
- 開発チーム: 3名(フルスタック、ただし全員Kubernetes未経験)
- 予算: 月額インフラコスト $500 上限
**技術制約**
- 既存のPostgreSQL 13が稼働中(移行コスト高のため継続使用)
- 外部API: PayPal(Stripe切り替えは承認不可)
**過去の失敗**
- 前回のマイクロサービス化試みは運用コストで失敗(2チーム→1チームに縮小済み)
**利害関係者**
- CTO: スケーラビリティ重視、複雑すぎる設計を嫌う
- セキュリティ担当: 個人情報の外部サービス送信に拒否権あり
上記コンテキストを踏まえ、[機能X]のアーキテクチャ案を3パターン提案してください。
各パターンに「このコンテキストでの採用可否」を明示してください。
💡 重要判断は会話の外に蓄積する:長期プロジェクトでは、過去の判断が会話履歴に埋もれていきます。
CLAUDE.mdや専用メモリファイルに「この設計で下した重要判断と理由」を貯めておくと、毎回ゼロから説明し直す手間が消えます。
3.2 「制約を先に列挙させてから設計させる」逆順プロセス
先に設計を生成させると、制約違反を事後にチェックする非効率なループに入ります。順番を逆にして、先に制約を列挙させると、AIが「制約の見落とし」を自律的に発見してくれます。
【フェーズ1: 制約の洗い出し】
以下の要件に対して設計を行う前に、まず制約を洗い出してください。
要件: [要件を記述]
以下の観点で制約を列挙してください:
1. 技術的に不可能なこと(現在の技術スタックで)
2. ビジネス的に選択できないこと(予算・スケジュール・契約)
3. 組織的に受け入れられないこと(チームスキル・意思決定構造)
4. あなたが私のコンテキストを知らないために見落としている可能性がある制約
※ 特に4番目を重視してください。私が言っていない前提を質問してください。
3.3 「なぜ」を3回深掘りして要件の本質を掴む
設計で最も高コストな失敗は「正しいものを正確に作ったが、誰も欲しくなかった」というものです。これを防ぐには、要件の表面ではなく、その奥にあるビジネス課題まで降りる必要があります。
以下の要件の「なぜ」を3階層掘り下げてください。
最終的に「この要件が解決しようとしている根本的なビジネス問題」を明示してください。
要件: 「ユーザーが自分のコンテンツをCSVでエクスポートできるようにする」
フォーマット:
- なぜ1: この要件が求められている直接的な理由
- なぜ2: その理由が生まれた背景
- なぜ3: その背景が意味するビジネス上の本質的課題
- 代替解決策: もし根本課題を直接解決するなら、CSVエクスポート以外のアプローチは何があるか
私が考えていない角度からの反論も含めてください。
3.4 「6ヶ月後に引き継ぐ人」視点でのレビュー依頼
設計負債の多くは「なぜこの決定をしたかが分からない」という暗黙知の喪失から生まれます。「未来の引き継ぎ者」というペルソナを与えると、AIは「現在の設計者が当然と思っている前提」を掘り起こそうとします。
以下の設計書を読んで、「6ヶ月後にこのシステムを引き継いだエンジニア」の立場で質問リストを作成してください。
[設計書の内容]
質問は以下のカテゴリに分類してください:
1. 意思決定の理由が不明な箇所(「なぜAではなくBを選んだのか」)
2. 運用時に直面するはずだが設計書に記述がない事態
3. 「こうなるはずがない」と設計者が思っているが実際には起きうる障害
4. 将来の要件変更で最初に壊れそうな箇所
各質問に「この疑問が解消されていないと発生するリスク」を添えてください。
3.5 ダメ出しセッションで設計を鍛える
AIは通常、提案された設計に概ね肯定的な評価を返します。「採用しない理由を10個挙げよ」という否定的な指示は、その出力バイアスを意図的に反転させ、設計の脆弱点を体系的に暴き出します。
【ステップ1: ダメ出し】
以下の設計を採用すべきでない理由を10個挙げてください。
「よくある批判」ではなく、このアーキテクチャ固有の問題を挙げてください。
[設計内容]
---
【ステップ2: 反論(必ず別セッションで)】
上記の10個の批判に対して、以下を行ってください:
- 反論できる批判: 設計の意図・コンテキストから見て問題ではない理由
- 反論できない批判: 認めざるを得ない設計の弱点(優先度高/中/低で分類)
- 対処案: 「反論できない」かつ「優先度高」の批判の設計変更案
⚠️ ステップ1と2は必ずセッションを分ける:一度に頼むと、AIは批判を最初から「後で反論できるもの」に選別してしまいます。ダメ出しと反論の間に、はっきり区切りを入れてください。
3.6 複数役割によるレビューで死角を消す
設計品質を高める本質は「異なる評価軸の衝突」にあります。セキュリティ専門家が重視することをUX専門家は軽視し、インフラ専門家が重視することを開発速度論者は軽視する。この衝突を一つの会話の中で起こさせます(Part 1.6 で示した「生産的対立」の設計フェーズ版です)。
以下の設計を、4つの異なる専門家の視点から順番にレビューしてください。
[設計内容]
**レビュアー1: セキュリティアーキテクト**
- 攻撃面、最小権限原則、データ漏洩リスクに敏感
**レビュアー2: SRE(サイト信頼性エンジニア)**
- 障害時の復旧可能性、監視容易性、デプロイリスクを重視
**レビュアー3: プロダクトマネージャー**
- ユーザー価値、開発速度、機能変更のしやすさを重視
**レビュアー4: 将来のメンテナー(経験3年のエンジニア)**
- コードの可読性、ドキュメントの充実度、学習コストに敏感
最後に、4人の意見が衝突している箇所を「トレードオフマトリクス」として整理してください。
3.7 AIに指摘させた内容をADR・テンプレートに昇格する
設計レビューで得た洞察を、その会話限りで消費してしまうと、同じ議論を次の設計でまた繰り返す羽目になります。「一回の設計判断」を「組織の知識資産」に変換するループを作ると、AIとの設計品質が時間とともに底上げされていきます。
今回の設計議論で下した以下の決定について、ADR(Architecture Decision Record)を生成してください。
決定内容: [今回決めたこと]
採用した選択肢: [A案]
却下した選択肢: [B案、C案]
ADRフォーマット:
## タイトル: ADR-[番号] [決定の一行要約]
## ステータス: Accepted
## コンテキスト: [この決定が必要になった背景・制約]
## 決定: [何を選んだか]
## 理由: [なぜこれを選んだか、他の選択肢ではなく]
## 結果: [この決定がもたらすトレードオフ]
## 見直し条件: [この決定を覆すべき状況]
3.8 「曖昧さ可視化」プロンプト
設計を始める前に、自分が必ず一度通すワンショットがあります。「決まっていないこと」を全部表に出させてしまうプロンプトです。
以下の要件仕様を読んで、「設計を始めるために確定が必要だが、現時点で決まっていない項目」を全て列挙してください。
[要件仕様]
分類してください:
1. ブロッカー: これが決まらないと設計を進められない
2. 仮定で進める: 合理的な仮定を置いて進むが、後で覆る可能性がある
3. 設計で吸収できる: 設計を柔軟にしておけば後で決まっても対応できる
各項目に「誰が・いつまでに決定すべきか」を添えてください。
✅ このPartの要点(3行)
- 提案の質は渡したコンテキストの質で決まる。制約を先に列挙させ、要件の「なぜ」を本質まで降ろす。
- ダメ出しと反論を別セッションに分け、複数役割レビューで評価軸を衝突させて死角を消す。
- 得た判断はADR・テンプレートに昇格させ、曖昧さは設計前に可視化して潰す。
📌 次のPartへの布石:設計が固まったら、いよいよ実装です。コーディングフェーズで失敗する最大の理由は「AIがコードを書ける」という事実に惑わされることです。問題はAIが書けるかどうかではなく、あなたのコードベースの文脈を理解した上で書けるか。次のPart 4では、その文脈をAIに正しく渡し、AIの自己批判を引き出すコツを見ていきます。
Part 4: コーディングフェーズのコツ
調査・設計と違い、コーディングフェーズの落とし穴は「AIがコードを書ける」という見かけの万能感です。AIは確かに書けます。けれど、書けることと、あなたのプロジェクトの思想・規約・パターンに沿って書けることは、まったくの別物です。ここでは、その差を埋めるコツを扱います。
4.1 プロンプトより「コンテキスト」を制度化する
「いい感じに書いて」という指示は、人間同士なら通じても、AIには「いい感じ」の基準がありません。アーキテクチャの思想、命名規則、エラーハンドリングのパターン──これらを会話のたびに再説明するのではなく、構造化されたドキュメントとして常に参照させることが、最大のレバレッジになります。
CLAUDE.md の書き方ひとつで、AIの従順さが変わります。人間向けの説明文ではなく、AIが従うべきパターンを明示するのがコツです。
# 悪い例(人間向けの説明文)
このプロジェクトはNext.jsを使っています。
エラーハンドリングはちゃんとやってください。
# 良い例(AIが従うべきパターンの明示)
## エラーハンドリング規約
- Server Actionsは必ずActionResult<T>型を返す
- throwは禁止。必ずresult.success === falseで返す
- エラーコードはerror-codes.tsの定数を使う(文字列リテラル禁止)
## NG例
throw new Error("不正なリクエスト")
## OK例
return { success: false, error: ERROR_CODES.INVALID_REQUEST }
コンテキストは、永続性のレベルで使い分けます。
| レベル | 場所 | 内容 |
|---|---|---|
| L1 哲学 | CLAUDE.md(プロジェクトルート) | アーキテクチャの思想、絶対に守るルール |
| L2 規約 | docs/guidelines/ | フレームワーク別・ドメイン別の具体的パターン |
| L3 瞬間 | 会話の冒頭 | 今回のタスク固有の前提条件 |
そのうえで、タスク開始時には既存パターンを参照させてから書かせます。
タスクを始める前に、以下を確認してください:
- CLAUDE.md のアーキテクチャ規約
- src/lib/types/result.ts の ActionResult 型定義
- src/app/actions/ 以下の既存実装パターン(3ファイル参照)
上記のパターンに**厳密に**従って、[実装内容]を実装してください。
もしパターンに従えない理由があれば、実装前に質問してください。
4.2 AIのコードレビュー指摘をガイドラインに昇華させる
AIに「このコードをレビューして」と頼むと、指摘は1回限りの会話で消えます。指摘を抽象化してルール化すると、エラーのパターンをプロジェクト資産に変換できます(Part 3.7 のADR昇格と同じ発想の、コーディング版です)。
自分は次の3ステップで回しています。
Step 1: 普通のレビュー依頼
「このPRの変更をレビューして」
Step 2: 昇華プロンプト(重要)
「指摘した内容のうち、プロジェクト全体に適用すべき再発防止ルールを
3〜5つ抽出して、以下の形式で書いてください:
- ルール名:(一言で)
- なぜ問題か:(原理)
- NGパターン:(コード例)
- OKパターン:(コード例)
- 既存ガイドラインへの追加場所:docs/guidelines/[ファイル名]」
Step 3: ガイドラインファイルに追記
「上記ルールを [ガイドラインファイル] の適切な場所に追記して」
4.3 バグ調査を「構造的分析」で依頼する
「このエラーを直して」と頼むと、AIは症状を治します。けれど優秀なエンジニアがやるのは、なぜそのバグが発生できる構造になっているかを理解し、同種のバグが生まれない設計にすることです。だから自分は、バグ調査を3段階に分けて依頼します。
【分析1: 直接原因(AIが得意)】
「このエラーログとコードから、バグの直接原因を特定してください」
【分析2: 根本原因(明示的に依頼)】
「この直接原因が生まれた根本原因を深掘りしてください。
ただし『なぜ』の回数ではなく、層の種類で分けてください:
- 実装層:このコードの書き方が招いた直接の引き金
- 設計層:その書き方を許してしまった設計・型・インターフェースの緩さ
- 前提層:そもそも『起きない』と暗黙に仮定していた前提」
【分析3: 波及範囲(AIが非常に得意)】
「このバグと同じ根本原因から発生し得る、
他のバグが潜在している箇所をコードベース全体から列挙してください。
特に以下の観点で:
- 同じパターンのコード
- 同じ前提条件に依存しているコード
- このバグの修正が副作用を与え得るコード」
4.4 「悪いコードを書かせてから批判させる」2フェーズ戦略
「いきなりベストな実装を書いて」と頼むと、AIは過去の学習から「それっぽいコード」を出してきます。意図的にドラフトを出させ、そのドラフトへの批判をAI自身にやらせる。この二段を踏むと、「なんとなく正しそうなコード」が「根拠のある実装選択」に変わります。
[機能名]を実装してください。
まず、シンプルな実装(v1)を書いてください。
次に、あなた自身でv1の問題点を列挙してください:
- パフォーマンス問題が顕在化するのはどういうケースか
- このコードがサイレントに失敗するケースはあるか
- セキュリティ上の懸念点は何か
最後に、問題点を解消した改善版(v2)を書いてください。
v1とv2の違いを、なぜその変更をしたかの理由とともに示してください。
4.5 テストをAIへの「仕様書」として書く
自然言語で仕様を説明するより、テストケースで仕様を表現し、それを満たす実装を書かせるほうが、アウトプットの品質が安定します。テストは曖昧さを排除してくれるからです。
以下のテストケースを全て満たす [関数名] を実装してください。
実装の制約:
- テストコードは変更禁止
- ActionResult 型を使用
- 外部APIは必ずモック可能な形で実装
describe('[関数名]', () => {
it('正常系: [条件]のとき[期待結果]', () => {
// ...
});
it('異常系: [エラー条件]のとき[エラー処理]', () => {
// ...
});
});
⚠️ 「テスト変更禁止」を明示しないと迂回される:制約を書かないと、実装が難しいケースでAIがテストのほうを簡略化してきます。仕様を守らせたいなら、仕様(テスト)を不可侵だと宣言してください。
4.6 会話の粒度を「コミット単位」に揃える
会話が長くなると、コンテキストが希釈されて、AIは前の指示を忘れたり、矛盾した実装をしたりします。1つの会話 = 1つのコミットに相当するスコープという設計にすると、会話が整理され、コンテキスト汚染を防げます。
次のサインが出たら、会話を分割する合図です。
- 「…そして、…も、…さらに」と会話が伸びていく
- 前に頼んだことを「さっき言いましたが」で参照し始める
- エラーの修正が別のエラーを生む連鎖が3回以上続く
スコープは、始める前に明示します。
【今回の会話のスコープ】
実装対象: [具体的なファイル/機能]
完了条件: [テストが通る / 型エラーがない / 特定のAPIレスポンスが返る]
スコープ外(今回は触らない): [明示的に除外するもの]
スコープ外の改善点に気づいた場合は、実装せず「メモ: 」として列挙してください。
4.7 AIが苦手な領域を把握し、人間がレビューする閾値を持つ
AIに任せて良い領域と、人間が握るべき領域を分けておくと、レビューのコストを正しく配分できます。自分の実感値ですが、信頼度はおおむね次のように分かれます。
| 信頼度 | 内容 |
|---|---|
| 高(そのまま使いやすい) | CRUD実装の定型、型変換・バリデーション、テストコードの雛形、リファクタリング |
| 中(レビュー必須) | 既存コードとのインターフェース結合、外部API連携、パフォーマンスクリティカルな実装 |
| 低(AIは補助、人間が設計) | 認可ロジック、並行処理・トランザクション境界、金額・ポイント計算、セキュリティ要件全般 |
そのうえで、AI自身にレビューポイントを申告させます。
以下の実装を書いてください:[実装内容]
実装後に、以下を自己評価してください:
1. この実装で私が必ずレビューすべき箇所はどこか(セキュリティ・認可・並行性の観点)
2. この実装に含まれる「私が判断できない前提条件」は何か
3. この実装が本番環境で問題を起こす可能性のあるシナリオを具体的に挙げてください
「問題なし」という回答は禁止。必ず何らかのレビューポイントを挙げてください。
⚠️ 信頼度マップは実感値:上の表は自分の経験に基づく肌感であって、絶対的な基準ではありません。プロジェクトの性質やモデルの世代で動くので、自分のチームの事故履歴に合わせて調整してください。
✅ このPartの要点(3行)
- 「書ける」と「コードベースの文脈に沿って書ける」は別物。規約はCLAUDE.md等に制度化して常に参照させる。
- ドラフト→自己批判→改善版の二段、テストを仕様書(不可侵)にする、会話をコミット単位に揃える。
- AIの得意/不得意でレビュー閾値を持ち、レビュー指摘はガイドラインへ昇華させる。
まとめ
凡庸な使い方 vs 成熟した使い方
フェーズごとに、ありがちな使い方と、一歩進んだ使い方を並べると、差がくっきり見えます。
| フェーズ | 凡庸な使い方 | 成熟した使い方 |
|---|---|---|
| 調査 | 「〇〇について調べて」 | 「仮説を先に立て、反証を探させる」 |
| 設計 | 「この機能を設計して」 | 「制約を洗い出させてから、複数役割でレビューさせる」 |
| コーディング | 「このコードを書いて」 | 「制約付きでドラフトを出させ、自己批判させてから完成版へ」 |
| 横断 | プロンプトを磨く | コンテキストを設計する |
根本原則
本記事を貫く原則は、次の5つに集約できます。
- AIをYes-manにしない設計:確証バイアスへの対抗策を、常に問いの形に組み込む
- モードを明示する:記述/分析/反証/ペルソナの違いを、毎回はっきり指定する
- AIに設計を任せず、AIで判断を鋭くする:AIは一般解を返す。固有解を引き出すのはコンテキスト
- 指摘を資産に変換する:一回限りで消費せず、CLAUDE.md・ガイドライン・ADRに昇華させる
- 使い込み自体を深化させる:AIを使うほど、自分の問いの構造化力が上がっていく
今日からできること
読み終えたその足で動き出せるアクションを並べておきます。
- 次のセッションの冒頭に、Part 1.1 の「セッションコンテキスト」テンプレを貼ってみる(5分)
- 直近のAIの回答ひとつに、Part 1.3 の「主張を攻撃させる(反証)プロンプト」を投げて反証させてみる(10分)
- 進行中の調査に、Part 2.4 の「仮説駆動」+ Part 2.2 の「見落とし」をセットで適用する(30分)
- 設計中のテーマで、Part 3.6 の「複数役割レビュー」を一度通してみる(30分)
- 直近のレビュー指摘を、Part 4.2 の昇華プロンプトでガイドライン1項目に変換する(20分)
-
自分のプロジェクトの
CLAUDE.mdを、Part 4.1 の「悪い例→良い例」基準で1箇所だけ直す(15分)
最後に ― AIを「思考の鏡」にする
ここまで紹介してきたコツは、突き詰めれば一つのことを言っています。AIを「答えを出す装置」ではなく「自分の思考を映す鏡」として使う、ということです。
AIエージェントを数百時間使い込んだ人に共通して起きるのは、技術の習得というより、認知の転換です。AIのために問いを構造化しているうちに、その構造化の力が、AIのいない場面でも働くようになる。会話を通じて両者が同じ地図を持ち、自分が地図の設計者として、AIが地図の探索者として機能する──この分業が成立したとき、一人では届かなかった思考の地平が開けます。
流暢な回答に頷いて終わるのは簡単です。けれど、その流暢さを疑い、反証を求め、前提を揺さぶり、指摘を資産に変える。その地味な反復こそが、AIを「高速な確証バイアス生成機」から「思考の拡張装置」へと変えていく、唯一の道だと自分は思っています。