§この章で扱うこと
AIに指示を出すコツ、いわゆる「プロンプト」を工夫するテクニックは、ここ数年で急速に陳腐化しました。「魔法の呪文」を貼り付ければ良い出力が返ってくる、という時代は2025年秋で終わっています。それでもなお、多くの経営者やチームは「もっとうまく書けばもっと良い答えが返ってくるはず」と、プロンプト単体をひねくり回すことに時間を使い続けています。この章はその段階から一歩先へ進むための章です。
コーチングの現場で毎週見ているのは、次のような光景です。ある経営コンサル・M&A会社の社長は、初回のセッションで「プロンプトエンジニアリングって、聞いたことないんだよね」と正直に切り出しました。ChatGPTを使いこなしているつもりで、なぜ自分の出力が「なんとなく足りない」のか説明できない。
人材紹介会社の経営者は、10回目のセッションで「AIは1回で良いものを出してこない」ということを、実感として腹落ちさせました。広告運用会社のディレクターは、4案件を並行で走らせて全部中途半端になり、上司から「要件定義書を先に作れ、ループを10周回せ、真面目すぎるAIの使い方をやめろ」という3つの処方を出される羽目になりました。
この章では、そういう現場を通じて実際に効果が出ている4つの型を、使う順番どおりに解説します。順番は「4世代論(全体地図) → 100問問答方式(型を作る) → コンテキストエンジニアリング(型を育てる) → ループエンジニアリング(型を回して仕上げる)」です。
網羅的な教科書ではなく、明日の朝から使う順に並べてあります。読み終わったときに、「自分がまだ第1世代のプロンプト工夫にとどまっていた」ということが構造的に理解できていれば、この章の役割は果たされています。
§4-1. AI使用法の4世代論 — いま自分がどこにいるかを知る
なぜこの世代論を最初に押さえる必要があるのか。
AIの使い方には、大まかに4つの世代があります。第1世代は「プロンプトエンジニアリング」。指示文をうまく書けば良い出力が返る、という時代の技法です。第2世代は「コンテキストエンジニアリング」。プロンプト単体ではなく、AIに渡す情報の束(過去のやりとり、社内資料、失敗履歴)を設計する段階に入ります。
第3世代は「ハーネスエンジニアリング」。ハーネスとは馬具・安全帯という意味で、AIが暴走せず走れるようにガードレールを整備する考え方です。CLAUDE.mdやrulesファイルで「これはやるな」「これはこう書け」と定義するのはこの世代の話です。そして第4世代が「ループエンジニアリング」。ゴールを定義して、AI自身に何周も自己修正させる段階です。
この4世代論を、ある経営コンサル・M&A会社の社長にコーチングで説明したときの言葉が、いちばん腹落ちしやすいので紹介します。「100km/hで走ってる車に対して、くねくねの道路を用意してたらすぐ事故っちゃうんですよ。まっすぐな道路をいかに整備してあげるか、それがハーネスエンジニアリング」。AIは日々賢くなり、速度は上がり続けている。
速度が上がるほど、道路(渡す文脈・ルール・停止条件)の設計が甘いと、事故は大きくなります。「プロンプトを工夫する」というのは、時速20km/hの車の運転を丁寧にすることに相当します。もう車のスペックがそこにないのです。
自分がいまどこにいるかを知らないと、次に何を学べばいいかの優先順位が付けられないからです。多くの経営者は、第1世代のまま「もっと良いプロンプト集はないか」を探しています。それは第1世代の中で頑張ることであって、第2〜4世代に進む行為ではありません。この章の残りの3節は、そのまま第2世代・第3世代・第4世代への具体的な入り口になっています。
§4-2. 100問問答方式 — 型を1個作って逆算で情報を集める
第1世代から第2世代へ抜けるいちばん速いショートカットが、この「100問問答方式」です。
やり方は驚くほどシンプルで、次の順序で進めます。①まず「正解っぽい成果物の型」を1個だけAIに作らせる。②その型を仕上げるために必要な質問を、AIに最大限・最小限で列挙させる。③その質問リストをそのまま経営者・担当者・クライアントに投げて回答を集める。④集まった回答を渡して同じ型を別対象向けに再生成する。これだけです。
なぜこれが効くのか。人間は「何を聞かれるか分からない状態」だと情報を出せません。AIも同じで、「何を渡せばいいか分からない状態」だと出力の質が上がりません。
従来のやり方は「なんとなく状況を書いて、なんとなく良い出力を待つ」でした。100問問答方式では、まず理想形をAIに1回作らせ、そのあと「この理想形に到達するために欠けている情報は何か」を逆算させる。AIが得意な作業(理想形の想像・不足情報の網羅的列挙)と、人間が得意な作業(実情報の記入)を分離する構造です。
現場で強力なのは、この方式が「マネジメントの解像度」まで上げてくれることです。人材紹介会社の経営者は、この型を導入したあと「部下に何を任せればいいか」の質問リスト自体が資産になっていることに気づきました。
AIコーチングという文脈を離れても、業務委託ディレクターへの発注書、営業担当への引き継ぎ書、面談前の候補者への事前アンケート、すべて100問問答方式で作れます。AI活用の話をしていたはずが、いつのまにか組織設計の話になっている、というのがこの型の特徴です。
さらに、この方式は「型が資産化する」という副産物を持っています。1回目の生成コストは重いのですが、2回目以降は「別の対象に同じ型を当てる」だけなので、労力が劇的に下がります。事業計画のフィードバック、セミナー資料、会社説明の動画台本、採用の合否基準、退職面談のヒアリングシート、どれも1度型を作れば、対象が変わってもフォーマットは使い回せます。「毎回ゼロから考える」から「型に流し込む」への移行が、ここで起きます。
§4-3. コンテキストエンジニアリング — スキルを2層に分け、失敗ログを蓄積する
そこで採るのが「スキル2層分割」という構造です。
型ができたら、次はそれを「毎週使える運用」に落とし込む段階です。ここでよくある失敗が、1つの大きなプロンプトファイルに全部詰め込むことです。実行手順・クライアント固有情報・過去の失敗履歴・出力フォーマット、これらを1本のファイルにまとめると、更新が怖くなり、誰も触れなくなり、半年で使われなくなります。
1層目は「実行スキル」。毎週・毎日起動する定型処理そのもの(たとえば毎朝9時に広告レポートを出す、月曜朝に案件進捗を集計する等)を書きます。ここは中身がほぼ変わりません。
2層目は「更新スキル」または「文脈ファイル」。クライアント名.md、施策履歴.md、失敗ログ.md、判断基準.md といった形で、状況変化に応じて追記していくファイル群です。実行スキルは起動のたびに更新スキル群を読み込みます。これによって、同じ処理が「今の状況を踏まえた出力」に変わっていきます。
この2層分割が効くのは、「AIあるある」を構造的に防げるからです。AIあるあるの代表格は、同じパイプラインを二重に構築してしまうことです。先週作ったスキルを本人が忘れ、今週また似たようなスキルを一から作る。1ヶ月後には似たようなスキルが3本あって、どれを使えばいいか分からない、という状態になります。実行スキルと文脈ファイルを分離しておけば、「実行の骨格は増えない、増えるのは文脈ファイルの中身だけ」という状態を保てます。
そして、この構造で最も重要な資産が「失敗ログ」です。同じミスを2度しないためのファイルであり、AIに毎回参照させることで複利で品質が上がる仕組みです。失敗ログには次の3つを書きます。①いつ・何が起きたか(事実)。②なぜ起きたか(原因の推定)。
③次からどうするか(行動指針)。ここに「Notionのフォーマットを直す前に差分を確認する」「クライアント名の表記ゆれをチェックしてから納品する」といった一行が積み上がっていきます。半年でこのファイルが100行を超える頃には、AIの出力が明らかに「あなたの会社仕様」に馴染んできます。それがコンテキストエンジニアリングの複利効果です。
なぜこれが今の主流なのか。理由はシンプルで、AIそのものの賢さが横並びになったからです。どのAIも一定以上賢い時代には、差がつくのは「渡す文脈の質」です。プロンプトを1文字ずつ工夫しても、渡す文脈が薄ければ出力は薄い。逆に、文脈さえ厚ければ、プロンプトはむしろ短くて済みます。「2025年秋からプロンプトエンジニアリングではなくコンテキストエンジニアリングが主流」というのは、こういう意味です。
§4-4. マルチAI議論・ループエンジニアリング — 10周回して仕上げる
この停止条件設計こそが、Loop Engineering時代の人間の仕事です。
型を作り、文脈を厚くしたら、最後は「ループで仕上げる」段階です。ここが第4世代の核心であり、多くの経営者にとっていちばん「勇気がいる」領域です。理由は単純で、「AIを10周回す」というのは、時間もお金(API利用料)も一定量かかるからです。1周で終わらせたい、という誘惑と戦うのがこの節のテーマです。
やり方の骨格は次のとおりです。①ヘッドとなるAI(実務ではClaude Codeを推奨)から、別のAI(Codex、Grok、DeepSeek、GPT等)を呼び出せる状態を作る。②あるタスクの初稿をヘッドAIに書かせる。③その初稿を別AIにレビューさせる。
④返ってきたレビューを踏まえてヘッドAIが修正する。⑤修正稿をまた別AIにレビューさせる。この③④⑤を10周繰り返します。実質的に、AI4体が円卓で議論している状態を経営者一人で持てる、という構造です。
なぜ10周なのか。5周では甘く、100周では過剰、体感で10周前後がちょうど質が飽和する境目、というのが現場での感覚値です。ただしこれには重要な但し書きがあり、「どこで止めるか」の停止条件を人間が設計しないと、1万周まで平気で回ってAPI利用料を溶かすことがあります。停止条件の例は次のようなものです。
「レビューAIが2周連続で重大指摘なし」「特定の評価軸で全AIが◎判定」「初稿から100文字以下しか変化しなくなった」。ゴールを人間が定義できないと、AIはいつまでも走り続けます。
ループを乗せる最も価値の高いタスクは「要件定義」です。実装に入ってから要件が揺れると、コストは10倍・100倍に膨れます。逆に、実装前の要件定義書を10周ループで磨いておけば、実装フェーズは驚くほど滑らかに進みます。
広告運用事業のディレクターは、4案件を並行で走らせて全部中途半端になり、上司から「要件定義書を先に作れ」「ループを10周回せ」「真面目すぎるAIの使い方をやめろ」の3処方を出されました。この3つは順序も重要で、要件定義がない状態でループを回しても、それは「どこにも着かない車を10km走らせる」に等しいのです。
「真面目すぎるAIの使い方をやめろ」という3つ目の処方も補足しておきます。これは、AIに毎回1発で完璧を求める姿勢を捨てろ、という意味です。1発で完璧を求めると、プロンプトが肥大化し、指示は硬直し、結局アウトプットも硬直します。
ラフな初稿を出させ、レビューさせ、直させる、という「反復前提」の姿勢が第4世代の基本動作です。ここでも4世代論の話に戻ってきます。プロンプト単体で完璧を狙うのは第1世代の発想であり、ループを回すのは第4世代の発想です。