見出し画像

プロンプトはなぜ今また重要なのか?ハーネス時代のAI設計を実行契約から考える

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中

CodexやClaude Codeを使っていると、少し不思議なことが起きます。

同じモデルを使い、同じリポジトリを渡し、同じツールを使える状態にしても、依頼の書き方によって結果が大きく変わる。実装の正確さだけではありません。調査範囲、ファイルの変更量、テストの有無、サブエージェントの数、トークン消費、どこで完了と判断するかまで変わります。

一方で、いまのAI開発はプロンプトだけで成立しません。必要な情報を選ぶコンテキスト設計、ツールや権限や状態を管理するハーネス、結果を測る評価、失敗時に止めて戻す仕組みが必要です。

では、プロンプトエンジニアリングの重要性は下がったのでしょうか。

私の結論は逆です。プロンプトだけでは足りない時代になったからこそ、プロンプトを雑に扱えなくなりました。

現在のプロンプトは、気の利いた言い回しではありません。人間の目的、判断基準、権限の境界、完了条件を、モデルとツールと複数のエージェントへ伝える実行時の契約です。ハーネスが強くなるほど、良い指示は大きな成果へ増幅され、曖昧な指示は大きな損失へ増幅されます。

この記事では、2025年から2026年の研究、AnthropicとOpenAIの公式資料、実務家の議論、そしてCodexやClaude Codeを使った実感をつなぎ、プロンプト、コンテキスト、ハーネス、評価をどう分担して設計すべきかを整理します。

※研究には査読済み論文とプレプリントが含まれます。数値は各研究の対象タスク、モデル、実験条件に依存し、すべてのAI業務へそのまま一般化できるものではありません。


プロンプトは主役から基礎契約へ変わった

2023年前後のプロンプトエンジニアリングは、しばしば「AIから良い回答を引き出す言い回し」として語られました。

専門家として振る舞わせる。順を追って考えさせる。役割や文体を細かく指定する。成功したテンプレートを保存し、別の仕事でも使い回す。こうした工夫には現在も使い道がありますが、AIシステム全体の中心ではなくなっています。

いま設計対象になっているのは、もっと広い範囲です。

ハーネスは、AIをどの環境、権限、実行順序、再試行、停止条件で動かすかを決めます。コンテキストは、AIに何を、いつ、どの量だけ見せるかを決めます。プロンプトは、その情報をどう解釈し、何を実行し、何を優先し、どこで止まるかを決めます。評価は、完成したように見える結果が、本当に目的を満たしたかを測ります。

この関係は、足し算よりも乗算に近いと考えると分かりやすくなります。

AIエージェントの性能は、モデル、プロンプト、コンテキスト、ハーネス、評価の掛け合わせで決まる。

これは研究から導出された厳密な数式ではなく、複数の研究と実務を統合した概念モデルです。ただ、現場感覚には合います。どれか一つが著しく弱いと、他が強くても全体が崩れるからです。

高性能モデルを使っても、要求が曖昧なら、何を完成とするかがずれます。正しい資料を大量に渡しても、優先順位がなければ重要な情報が埋もれます。優れたプロンプトを書いても、削除権限や外部送信権限が無制限なら安全にはなりません。すべてが整っていても、評価がなければ失敗を成功として保存します。

プロンプトは主役ではなくなりました。しかし、システム全体の意味を定義する基礎契約になりました。

以前の記事では、プロンプト単体からツール、権限、評価まで設計対象が広がった流れを、2023年から2026年の変化として整理しています。

同じ意味でも結果が変わる問題は消えていない

モデルが賢くなれば、細かな言い回しの差は吸収される。そう期待したくなります。

しかし、近年の研究は、プロンプトへの感度が消えていないことを示しています。

NAACL 2025の査読論文「What Did I Do Wrong?」は、意味を維持した言い換えに対して、モデルの性能だけでなく感度と一貫性を測る枠組みを提示しました。2025年のプレプリント「Benchmarking Prompt Sensitivity in Large Language Models」でも、PromptSETを使った評価から、わずかな表現変更が回答精度へ影響し、成功する言い回しを既存手法だけで安定して予測することは難しいと報告されています。

ACL 2026の査読論文「Understanding the Prompt Sensitivity」でも、意味が近い入力がモデル内部で必ずしも近く表現されず、質問内容そのものよりプロンプトのテンプレートが出力直前の確率へ大きく影響する場合があると分析されています。表層的な単語変更への感度を扱う研究も続いており、プロンプト感度は過去の小型モデルだけの問題とは言い切れません。

ここで大事なのは、「魔法の言葉を探し続けるべき」という結論ではありません。

むしろ逆です。一つの書き方でうまくいったことを、頑健な仕様だと思わない方がよい。

分類してください。選択肢から選んでください。理由を考えた後にラベルだけ返してください。JSONでラベルと根拠を返してください。人間には近い依頼でも、モデルにとっては同じではありません。

本番で繰り返すなら、意味を維持した複数の表現で試し、結果の安定性を確認する必要があります。プロンプトの品質は、最高点だけでなく、表現が少し変わっても崩れないかで評価すべきです。

問題の多くは言い回しより指示不足から生まれる

プロンプト感度を考えるとき、細かな単語選びだけに注目すると本質を外します。

2025年のプレプリント「What Prompts Don’t Say」は、モデルが暗黙の要件を推測できる場合があっても、その挙動は安定しないと報告しました。実験では、指定されていない要件をモデルが既定動作として満たした割合は41.1パーセントでした。

しかし、要件不足のプロンプトはモデルやプロンプトの変更で回帰する確率が約2倍になり、20ポイントを超える精度低下も観測されています。一方、要件を考慮した最適化は、すべての要件を単純に追記する方法などの基準手法より平均4.8パーセント改善しました。

2026年のプロンプト感度研究でも、指示不足のプロンプトは性能分散が大きく、具体的な指示を含むプロンプトの方が影響を受けにくいと報告されています。

つまり、改善すべきなのは、語尾より先に要求です。

「適切に修正して」

「問題がなければ完了して」

「必要に応じて調査して」

人間同士なら、過去の経験や組織の常識から意味を補えます。AIエージェントは補うこともありますが、その補完はモデル変更、コンテキスト圧縮、サブエージェントへの委譲、再実行で崩れます。

現在のプロンプトエンジニアリングは、曖昧な期待を検証可能な要求へ変換する仕事です。

対象は何か。何を変えてよいか。何を変えてはいけないか。どの資料を正本にするか。何を確認したら完了か。情報不足なら推測するのか、止めるのか。テストが失敗したら修正するのか、報告するのか。

こうした内容は、文章術というより要件定義、受入基準、例外設計、変更管理です。

複雑なAI依頼を、目的、背景、入力、制約、工程、出力、完成条件へ分ける方法は、こちらの記事で具体化しています。

ハーネスが強いほど曖昧な一文の被害は広がる

単発のチャットで曖昧な指示を出しても、被害は一つの回答で止まるかもしれません。

ハーネスに組み込まれた指示は違います。

同じsystem promptが数百件のタスクで再利用されます。複数のサブエージェントへ複製されます。ツール呼び出しを誘発します。後続エージェントの入力になります。長期メモリへ保存されます。評価と再試行の基準になります。

たとえば、上位指示に「不明な場合は合理的に推測する」と書いてあるとします。

最初のエージェントが推測し、その推測が成果物へ書き込まれ、次のエージェントが事実として読み、検証エージェントも同じ前提を共有し、誤った成果物が完成扱いされる可能性があります。

ハーネスは、プロンプトの欠陥を補うだけの仕組みではありません。プロンプトの意味を高速かつ大規模に実行する仕組みでもあります。

ここで、実務上の重要な視点が出てきます。

プロンプトは文章としてではなく、その一文が誘発する計算として監査すべきです。

「多角的に調査する」は、通常チャットでは数段落の分析かもしれません。Deep Researchでは多数の検索になります。Codexでは大量のファイル探索になります。マルチエージェントでは役割分裂になります。自律ループでは、停止条件が満たされるまで反復します。

「徹底的に」「抜け漏れなく」「独立して検証」「追加調査」「各観点別に実行」といった指示が重なると、品質を上げる前に計算量を爆発させることがあります。

実際、Codexで約200体のサブエージェントが作られ、週間上限を短時間で使い切る問題では、「45観点に対して4エージェント」という構造が疑われました。ただし、どの文が何体の生成へ寄与したかは未計測です。ここは仮説として扱う必要があります。

それでも、設計上の教訓は明確です。抽象的な品質要求には、探索予算と停止条件を加えるべきです。

良いプロンプトは自由度を増やすのではなく配分する

プロンプトを詳細にすればよい、と考えると、今度は長大な指示が生まれます。

長い指示は必ずしも悪くありません。高性能なモデルは複雑な手順を実行できます。ただし、AnthropicがAgent SkillsやMCPの解説で示しているように、すべての説明やツール定義を最初から常駐させるのではなく、必要になった時点で読み込む段階的な開示が重要です。

ただし、常時すべてを読み込ませると、必要な情報と不要な情報が競合します。コンテキストを消費し、別案件のルールが誤発火し、どの指示が効いているか分からなくなります。

良いプロンプトの本質は、文字数ではありません。誰が何を決めるかを分けることです。

人間が固定するべきものは、目的、禁止事項、正本、証拠要件、出力契約、完了条件です。

モデルへ委ねられるものは、説明順序、仮説生成、例の選定、表現、局所的な問題解決です。

コードやハーネスが固定すべきものは、型、必須フィールド、権限、課金、削除、外部送信、ロールバック、秘密情報の保護です。

この分担がないと、二つの失敗が起きます。

一つは、モデルへ自由を与えすぎ、重要な境界まで推測させること。もう一つは、細部まで自然言語で縛り、モデルの問題解決能力を殺すことです。

プロンプトエンジニアリングの核心は、指示を増やすことではありません。人間、モデル、コード、ハーネスの間で、決定権を適切に配分することです。

意味を決めるプロンプトと破れない境界を作るコードは別物である

プロンプトには強みがあります。

目的を伝える。判断基準を示す。何を優先するかを定める。例外時の基本姿勢を示す。成果物の意味を定義する。

しかし、自然言語は絶対保証には向きません。

必須項目が常に入ること。外部送信前に承認を通すこと。削除権限を限定すること。課金上限を超えないこと。秘密情報を出さないこと。テストが失敗した状態でマージしないこと。

こうした要件は、コード、スキーマ、権限、サンドボックス、検証器、CIで保証すべきです。

プロンプトによる意味制御と、コードによる強制制御を混同すると、「禁止と書いてあるから安全」という危険な設計になります。

反対に、すべてをコードへ押し込むこともできません。何を良い成果とみなすか、複数の妥当な選択肢から何を優先するか、不完全な証拠からどこまで結論を出すかは、自然言語の判断基準が必要です。

AIエージェントを安全に動かすハーネスの要素は、こちらの記事で、目的、コンテキスト、ツール、状態、権限、検証、ログ、復旧、人間介入まで分けて整理しています。

マルチエージェントではプロンプトが分散システムの契約になる

マルチエージェント環境では、プロンプトは質問文ではありません。

各エージェントの責任範囲、入力、出力、参照可能な情報、推測可能な範囲、上流成果物を疑う条件、下流へ渡す形式、完了判定、再作業条件を定めるインターフェースです。

「調査エージェント」「分析エージェント」「レビューエージェント」と役割名だけを付けても、実務では重複します。全員が検索し、全員が要約し、全員が同じ観点を確認し、誰も最終責任を持たない状態になります。

必要なのは、役割ではなく契約です。

調査エージェントは一次情報の収集だけを担当し、解釈を確定しない。分析エージェントは渡された根拠の範囲で推論し、不足情報を追加検索しない。検証エージェントは事実、引用、数値、適用範囲だけを確認し、文章を全面改稿しない。統合エージェントは採否を決め、矛盾を解消できない場合は不明として残す。

2026年6月公開のプレプリントPerspectiveGapは、27の商用モデルを110のシナリオで評価し、複数課題を合わせた平均合格率が14.9パーセントだったと報告しました。

評価対象は、各サブエージェントへ必要な情報を渡せるか、無関係な情報を渡さないか、役割の重複を減らせるか、最小限の構成でループを作れるかです。研究固有の採点方法による結果ですが、オーケストレーション用の指示作成が独立した難題であることを示しています。

この結果をすべてのマルチエージェント設計へ一般化はできません。ただ、情報を多く渡すほどよいわけではないことを示唆します。

必要なのは、各エージェントが責任を遂行するための最小情報です。ここでプロンプトエンジニアリングとコンテキストエンジニアリングは合流します。

一つの強いプロンプトが複雑なオーケストレーションを上回ることもある

ここまで読むと、タスクを細かく分解し、ハーネスを強くすればよいように見えるかもしれません。

しかし、反対方向の研究もあります。

2026年4月公開のプレプリント「In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks」は、旅行予約、Zoomの技術サポート、保険請求という手続き型の会話タスクで、LangGraphによる外部オーケストレーションより、手順全体をsystem prompt、つまり会話全体へ常時適用される上位指示へ渡してモデル自身に進行させる方が高い評価を得たと報告しました。

これは、複雑な権限管理、長期状態、外部副作用、失敗復旧を含むエージェント全般へ一般化できません。対象は定義済みの手続き型タスクです。

ただし、重要な警告があります。

分解すればするほど、文脈は失われます。中間要約で要求が落ちます。判断が不一致になります。通信回数と遅延が増えます。小さな誤差が累積します。

手続き全体がコンテキストに収まり、一つのモデルが全体を理解でき、外部強制が少ないなら、一つのよく設計されたsystem promptの方が適切な場合があります。

したがって、単一エージェントかマルチエージェントかは信仰ではありません。

判断基準は、タスクの長さ、状態の持続、権限の複雑さ、外部副作用、専門性の分離、独立検証の必要性、文脈分断の損失です。

プロンプト最適化は職人芸から評価付き探索へ移っている

プロンプトエンジニアリングが残るとしても、人間が一語ずつ調整し続けるのでしょうか。

研究の流れは、そうではありません。

2025年のプレプリントAutoPDLは、Zero-shot、Chain-of-Thought、ReAct、ReWOO、few-shot、具体的指示などの組み合わせを探索し、3タスク、6モデルで平均9.5ポイントの改善を報告しました。

ばらつきは大きく、最大値は68.9ポイントでした。選ばれる戦略はモデルとタスクで異なっており、一つのプロンプト方式を万能視できないことも示しています。

Salesforce ResearchのPromptomatixは、自然言語のタスク記述からプロンプトを自動最適化し、性能だけでなく長さと計算量も考慮します。自動プロンプト最適化を体系化する大規模サーベイも公開されています。

2026年のTATRAは、固定した一つのプロンプトではなく、入力ごとにfew-shot例を合成する方向を示しました。promptolution、低遅延の候補分類、Agent-GWOなど、生成、選択、探索を組み合わせる研究も進んでいます。

ここから分かるのは、プロンプトエンジニアリングが消えるのではなく、手作業から評価付き探索へ移ることです。

人間の役割も変わります。

完成した一文を書くのではなく、候補の探索空間を決める。守る制約を決める。正解データや評価基準を作る。コストと遅延の上限を決める。どの失敗を許容しないかを決める。

プロンプトを自動で改善するほど、評価設計が重要になります。

評価がなければプロンプト改善は思い込みになる

一度の成功例を見て、「このプロンプトは良い」と判断するのは危険です。

プロンプトの評価には、少なくとも通常ケース、境界ケース、情報不足、矛盾、ツール失敗、悪意ある入力、極端に長い入力が必要です。

見る指標も品質だけでは足りません。

正確性。完全性。再現性。コスト。遅延。ツール回数。サブエージェント数。権限逸脱。人間の修正量。失敗からの復旧。モデル更新後の回帰。

Anthropicのエージェント評価ガイドも、開発初期から、どの入力を与えるか、何を成功とみなすか、どの採点ロジックを使うかを明示するよう勧めています。Hamel Husainも、モデルの失敗モードを理解し、ドメイン固有テストを作り、本番挙動を監視する重要性を繰り返し述べています。

実務では、次の順序が妥当です。

成功条件を決める。代表ケースを作る。初期プロンプトを実行する。失敗を分類する。プロンプト、コンテキスト、ツール、モデル、ハーネスのどこを直すか判断する。候補を比較する。回帰テストを通す。採用版をバージョン管理する。

ここで重要なのは、失敗をすべてプロンプトで直さないことです。

資料が不足しているならコンテキストを直す。ツールが使いにくいならツール定義を直す。権限が危険ならハーネスを直す。出力形式が壊れるならスキーマを使う。モデル能力が不足しているならモデルを変える。

公開後のAIシステムを品質、費用、事故、変更まで継続評価する方法は、こちらの記事で詳しく扱っています。

reasoning modelには思考量より条件を渡す

旧来型のテクニックの中には、相対的な価値が下がったものがあります。

「世界最高の専門家として振る舞ってください」というペルソナは、文章の雰囲気を変えられても、専門精度を保証しません。専門家の肩書きより、専門家が使う評価軸を渡す方が安定します。

「必ず20段階で思考してください」「全可能性を列挙してください」「step by stepで考えてください」といった指示も、reasoning model、つまり複雑な問題を内部で長く検討するよう設計されたモデルでは、冗長化や性能低下につながる場合があります。

OpenAIの推論モデル向け公式ガイドは、モデル系列によって適切な指示が異なると説明し、推論モデルには簡潔で直接的な指示を与えることを勧めています。

渡すべきなのは、思考の長さではありません。

最終成果物、利用可能な証拠、制約、判断基準、主要な反証、確認事項です。

内部思考の詳細を要求する代わりに、「結論を出す前に主要な反証とデータ不足を確認し、回答には判断に必要な根拠の要点を示す」と指示する方が実務的です。

万能なテンプレートもありません。通常の指示追従モデル、推論モデル、コーディングエージェント、ツール利用エージェント、小型ローカルモデルでは、適切な依頼が異なります。

プロンプトを固定資産ではなく、モデルとタスクに依存する実装部品として扱う必要があります。

高精度なプロンプトはSkillへ昇格させる

CodexやClaude Codeを使う中で、うまくいく指示が固まったらSkill化する。この運用は妥当です。

ただし、Skillは「長いプロンプトの保存場所」ではありません。

再利用可能な標準作業手順と実行契約です。

Skillに必要なのは、適用条件、非適用条件、必要入力、実行工程、判断基準、制約、成果物、完了条件、失敗時処理、検証です。

Skill化の目安も必要です。

異なる案件で3回以上有効だったか。入力を差し替えても工程が変わらないか。実行順序に意味があるか。失敗パターンと例外処理が分かっているか。完了条件を定義できるか。成果物を検収できるか。毎回書くと漏れや表現揺れが出るか。

反対に、一案件だけで成功した、成功理由を説明できない、案件ごとに工程が変わる、抽象語が中心、失敗時の挙動が未検証、過剰実行しそうな場合は、まだSkill化しない方がよいでしょう。

未成熟なプロンプトをSkill化すると、単発の悪い癖を全案件へ複製します。ハーネスが強いほど、その複製速度も上がります。

私は、Skillを次の段階で昇格させる設計がよいと考えます。

Draftでは手動で使う。Trialでは2から3案件で試し、実行ログと失敗を集める。Candidateでは入出力と完了条件を固定する。Skillではバージョン管理して利用する。陳腐化や重複が起きたら廃止し、新しいSkillへ移行する。

検証したモデル、成功案件、既知の失敗条件、最大ツール回数、最大サブエージェント数、期待出力、バージョン、最終検証日も記録します。

AIへの反復指示をルール、Skill、テストへ変え、組織の知識資産として残す方法は、こちらの記事で整理しています。

長大な指示は五つの層へ分ける

長大なカスタム指示を一つの文書として管理すると、品質ルール、案件固有条件、工程、検証、表現の好みが混ざります。

これを五つの層へ分けると、保守しやすくなります。

最初は不変の原則です。捏造禁止、正本優先、既存機能の無断削除禁止、外部操作の承認、事実と推論の分離など、常時読み込む少数のルールです。

次は案件固有仕様です。対象、目的、読者、成果物、今回だけの制約、正本、予算、期限など、案件ごとに変える内容です。

三つ目は工程別Skillです。調査、設計、実装、ファクトチェック、画像制作、検収など、必要な時だけ読み込みます。

四つ目は機械検証です。ファイル名、必須ファイル、文字数、URL、ハッシュ、JSON Schema、テスト、静的解析など、自然言語ではなくコードで保証します。

最後は評価です。品質、完全性、コスト、エージェント数、ツール回数、回帰、誤情報、権限逸脱を継続的に測ります。

この分離により、常時読み込む指示を小さくし、必要な工程だけを追加できます。案件固有条件が他案件へ漏れることも減ります。

長期案件の背景、正式資料、判断履歴、未解決事項を会話履歴から切り離して管理する方法は、こちらの記事が参考になります。

抽象的な品質要求を有限の探索へ変える

「多角的に徹底調査し、抜け漏れなく検証する」

一見すると高品質な指示です。しかし、探索範囲も停止条件もありません。

実務で使うなら、有限の契約へ変えます。

調査観点を、一次研究、主要ラボ公式見解、実務家の事例、反対論、適用限界、実務転用の六つに限定する。各観点で最大五件を確認する。類似情報は追加価値がなければ増やさない。新しい重要論点が二回連続で見つからなければ終了する。重要な事実は一次情報へ戻る。未確認事項は推測で埋めない。

品質要求を削るのではありません。探索予算と停止条件を加えています。

同じ考え方は開発にも使えます。

対象不具合の再現、原因特定、最小修正、関連テスト、回帰確認まで行う。無関係なリファクタリングは禁止する。既存仕様か判断できない挙動は変更せず報告する。変更ファイルは必要最小限にする。テストが通らなければ完了扱いしない。

「リポジトリを確認して問題を修正して」と比べると、目的だけでなく工程、変更境界、検証、停止条件があります。

CodexやClaude Codeへ開発全体を一度に任せず、要件、局所計画、実装、検証、独立レビューへ分ける工程設計は、こちらの記事で詳しく解説しています。

正例だけでなく失敗例と境界例を渡す

few-shot、つまり少数の見本を入力へ添えて、AIへ望ましい判断や形式を示す方法は有効です。

ただし、良い例だけでは、表面をまねることがあります。判断基準を理解させるには、採用例、不採用例、境界例が役立ちます。

関連記事の配置を例にすると、採用例は、読者が次に抱く疑問へ直接答える記事を、意味的に近い位置へ置くことです。不採用例は、関係の薄い記事を検索流入や営業目的で機械的に置くことです。境界例は、関連性は高いが本文の論理を中断するため、章末へ移す判断です。

同じように、コード変更、調査範囲、引用、外部操作、個人情報、画像生成にも境界があります。

モデルへ「良いものを作れ」と言うだけでなく、何をしてはいけないか、どこから人間判断へ戻すかを示します。

推測できることと確認すべきことを分ける

AIへ創造性を与えることと、事実を自由に作らせることは別です。

見出し表現、説明順序、読者向けの例は推測してよい。数値、日付、固有名詞、製品仕様、法制度、引用、外部URLは確認が必要。読んでいない資料の内容、未実行テストの結果、存在未確認のファイルは推測してはいけない。

この三分割は、記事制作だけでなく開発や業務自動化にも使えます。

どこまで判断してよいかを明示しないと、モデルは過度に慎重になるか、過度に補完します。すべて推測禁止でも、すべて自由でもありません。

反対論を入れると設計が現実に戻る

プロンプトが重要だという主張には、いくつかの反対論があります。

まず、プロンプト技法の一部は陳腐化します。大げさなペルソナ、報酬や罰、万能な呪文、推論モデルへの冗長な思考指示、モデル非依存のテンプレートは、相対価値が下がるでしょう。

次に、すべてをプロンプトで解決してはいけません。セキュリティ境界、必須フィールド、型、外部送信、削除、課金、ロールバック、秘密情報保護はコードと権限で保証すべきです。

逆に、すべてをハーネスで分解してもいけません。全体が一つのコンテキストに収まり、単一モデルが手続きを理解できるなら、分解が文脈欠落とコストを生むことがあります。

研究結果にも限界があります。小型モデルで最大40パーセント改善した構造化プロンプト研究は、DDoS検出を中心とする限定タスクです。

単一system promptがオーケストレーションを上回った研究は手続き型会話タスクです。プロンプト感度研究の多くは分類、質問応答、数学、コードなど特定ベンチマークです。プレプリントは査読前の場合があります。LLMを採点者に使う評価には、採点モデル固有の偏りがあります。

したがって、研究を「この手法が常に正しい」というレシピへ変えてはいけません。

使えるのは、検証すべき仮説です。

実務で使えるプロンプトの骨格は明確になっている

ここまでを、実務で使える形へ落とします。

良いプロンプトは、背景、目的、入力、実行要件、制約、成果物、完了条件、失敗時の扱いを分けます。

成功状態は「高品質」ではなく、読者が何を理解できるか、どのテストを通すか、どのファイルが存在するか、誰が承認したかで書きます。

指示には優先順位を付けます。安全と権限、正本と事実整合、成果物要件、品質基準、文体上の好みの順にします。衝突したときに、どれを優先するかを明示します。

サブエージェントへは役割名でなく、担当、入力、出力、禁止事項、完了条件を渡します。

長い指示は、常時必要な原則、案件固有仕様、工程Skillへ分離します。

抽象語には、最大件数、最大ツール回数、最大サブエージェント数、停止条件を付けます。

プロンプトを改善したら、同じ意味の言い換え、境界入力、矛盾入力、ツール失敗で回帰テストします。

品質だけでなく、トークン、遅延、ツール回数、サブエージェント数、人間修正量を測ります。

私が今後優先すべきだと考える三つのこと

第一に、長大なカスタム指示を文章ではなく、実行されるプログラムとして監査することです。

各指示について、何回実行されるか、どの条件で発火するか、サブエージェントへ継承されるか、他の指示と組み合わさると何が起きるか、終了条件があるか、検索とツールとエージェントをどこまで増やすかを確認します。

第二に、長いプロンプトではなく、検証可能なプロンプトを作ることです。

必須論点数、一次情報の確認件数、重複調査を止める条件、最大サブエージェント数、成果物数、完了条件、変更禁止範囲、テスト条件へ変換します。

第三に、プロンプトを評価とセットで改善することです。

成功条件、代表タスク、複数候補、品質、コスト、ツール回数、回帰を測り、採用版をバージョン管理します。モデルが変わったら再評価します。

この三つができると、プロンプトは「うまくお願いする文章」から、測定可能なAI運用資産になります。

企業でAIの指示、コンテキスト、Skill、評価、権限を実際の業務へ落とすには、文章だけでなく運用設計と検証環境が必要です。AI研修、業務設計、エージェント開発まで含めた相談窓口はこちらです。

プロンプトだけでは足りないからこそプロンプトを雑に扱えない

プロンプトエンジニアリングは、以前と同じ形では残りません。

Prompt Engineerという独立した職種名は減るかもしれません。しかし、曖昧な要求を仕様へ変える力、必要な情報を選ぶ力、モデルへ渡す自由度を設計する力、例外と停止条件を決める力、評価で改善する力は、AI product engineer、agent engineer、context engineer、eval engineer、requirements engineerへ分散して残ります。

私自身、同じハーネスでもプロンプトによって結果が変わることを経験し、高精度な指示をSkillへ変えてきました。その方向は間違っていません。

ただし、次の段階では、より長いSkillを作るのではなく、どの指示が品質へ効き、どの指示がコストや暴走を生むかを測る必要があります。Skillを小さな責任単位へ分け、適用条件と非適用条件を持たせ、探索上限と停止条件を設定し、評価と回帰テストを付ける必要があります。

プロンプトだけでは、本番AIシステムを設計できません。

それでも、ハーネスとコンテキストが高度になるほど、プロンプトは人間の意図をシステム全体へ伝播させる重要な契約になります。

だから、結論はこうなります。

プロンプトだけでは歯が立たない時代になったからこそ、プロンプトを雑に扱えなくなった。

生成AIの実務、エージェント設計、評価、組織導入について別の記事も読み比べたい方は、こちらのマガジンにまとめています。

出典・参考資料

以下は2026年7月27日時点で再確認した主要資料です。査読論文、プレプリント、企業の公式技術資料を区別して本文へ反映しています。

いいなと思ったら応援しよう！

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中 社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。