AI時代に「プロンプトエンジニアリング」はまだ重要か？2023〜2026年、設計対象はどこまで広がったのか。

「これからは、プロンプトエンジニアリングが重要になる」

2023年ごろ、生成AIについて語る場でよく聞かれた言葉です。

実際、ChatGPTから望む回答を引き出すためのテンプレートや、「この一文を入れると精度が上がる」といった方法が数多く共有されました。明確な指示、役割の設定、Few-shotの例示、出力形式の指定。こうした工夫が、AIを使いこなすための中心的な技術として扱われていた時期です。

ところが2025年から2026年にかけて、周辺で使われる言葉は大きく広がりました。

Context Engineering、Agent Engineering、Harness Engineering、AGENTS.md、SKILL.md、MCP、メモリ、ツール、評価、トレース、Human-in-the-loop。

こうした変化を見ると、自然な疑問が浮かびます。

モデルが賢くなり、AIがツールを使って複数の作業を進める時代に、良いプロンプトを書く能力はまだ重要なのでしょうか。

私の結論は、次の通りです。

より短く言えば、プロンプトエンジニアリングの単独時代が終わった、ということです。

プロンプトは、いまでも重要です

まず、「もうプロンプトは不要になった」という理解は正しくありません。

OpenAIの公式ガイドでは、現在も次のような基本原則が示されています。

• 指示を入力の冒頭に置く

• 指示と参照情報を明確に分ける

• 望む結果、長さ、形式、文体を具体的に示す

• 必要に応じて例を与える

また、新しい高性能モデルは、一般に旧世代のモデルよりも指示しやすいとも説明されています。これは、プロンプトが不要になったということではなく、モデル側の指示理解力が上がり、特別な言い回しへの依存が減っていると読む方が適切です。

AIへ依頼するとき、プロンプトは今でも次のことを伝える重要な入口です。

• 何を達成したいのか

• 誰のための成果物なのか

• 何を材料として使うのか

• 何を優先するのか

• 何をしてはいけないのか

• どのような形式で返すのか

• どこまでできたら完了なのか

この部分が曖昧であれば、モデルが強くても結果はぶれます。

むしろ、ツールを使って複数の処理を実行できるAIでは、曖昧な指示の影響は大きくなります。文章の品質が少し下がるだけでなく、誤ったファイル変更、不要な外部操作、承認前の送信や公開につながる可能性があるからです。

OpenAIのAgents SDKも、繰り返しのツール呼び出し、エージェント間の引き継ぎ、セッション、ガードレール、トレース、人間の承認待ちを実行環境の要素として扱っています。

AIの能力が高くなるほど、人間が示すべき目的、境界、禁止事項、停止条件、承認条件は重要になります。

ただし、それらをすべて一つの巨大なプロンプトへ詰め込めばよいわけではありません。

ここに、2023年から2026年にかけて起きた大きな変化があります。

2023年には、すでにプロンプト単体から外へ広がり始めていた

2023年は、一般には「プロンプトエンジニアリングが広く注目された年」と見られています。

明確な指示、Zero-shot、Few-shot、役割設定、出力形式、Chain-of-Thought、タスク分解。モデルへ渡す文章を工夫し、一回または数回の呼び出しで能力を引き出すことが主な関心でした。

しかし、研究の流れを見ると、その時点ですでに「一回のプロンプトで良い回答を出す」だけではない方向へ進み始めています。

ReActは、推論と外部行動を組み合わせた

ReActは、LLMに推論だけをさせるのでも、行動だけを生成させるのでもなく、推論とタスク固有の行動を交互に行わせる枠組みを示しました。

推論によって計画を立て、外部環境や知識源へ行動し、その結果を受け取って次の判断へ進む。現在のエージェント設計につながる基本的な構造です。

ここでは、成果を左右するものが最初の指示文だけではありません。

何を観察できるか。どの行動を選べるか。外部から得た結果をどう次の推論へ渡すか。いつ停止するか。

モデルの周囲にある実行環境が、結果へ影響し始めています。

Reflexionは、失敗から次の試行を改善した

Reflexionは、モデルの重みを更新する代わりに、タスク結果への言語的なフィードバックを記録し、次の試行へ利用する枠組みです。

モデルは失敗を振り返り、その内容をエピソード記憶へ保持し、次回の意思決定を改善します。

この研究が示した重要な点は、最初から完璧なプロンプトを書くことだけが性能改善の方法ではないということです。

実行し、評価し、失敗を記録し、再試行する。

評価と改善のループ自体が設計対象になるという考え方が、すでに現れています。

OPROとDSPyは、プロンプトを最適化対象へ変えた

OPROは、過去に生成した解とその評価値をプロンプトへ含め、LLM自身に新しい候補を生成させる最適化手法です。プロンプトの改善も、人間の感覚だけではなく、評価結果を使って探索する対象になりました。

DSPyはさらに、長いプロンプトテンプレートを人間が試行錯誤で手書きする方法から離れ、LMの呼び出しをモジュールとして表現し、データと評価指標を使ってパイプラインを最適化する方向を示しました。

DSPy Assertionsでは、自然言語で「この条件を守ってください」と頼むだけでなく、モデルが満たすべき計算可能な制約を定義し、違反時の自己修正へつなげています。

つまり2023年の時点で、問いはすでに変わり始めていました。

だけではなく、

が重要になっていたのです。

2024年、プロンプトの基本技法は標準技能になった

2024年になると、主要なAI企業が示すプロンプトの基本原則は、かなり共通化してきました。

• 指示を具体的にする

• 必要な背景情報を与える

• 指示、入力、例を分ける

• 出力形式を示す

• 複雑な作業を分解する

• 結果を確認して反復する

これらは今でも有効です。

ただし、一部の専門家しか知らない「秘伝の技術」というより、AIを仕事で使う人が身につけるべき標準的な技能へ近づいています。

この変化を考えるうえで重要なのが、Anthropicが2024年12月に公開した「Building Effective Agents」です。

Anthropicは、LLMとツールが事前に定義されたコード経路に沿って動くものをWorkflow、LLM自身が処理やツール利用を動的に方向づけるものをAgentと区別しています。

同時に、最初から複雑なエージェントを作るのではなく、まず最も単純な解決策を探し、必要な場合だけ複雑性を増やすべきだと説明しています。エージェントは性能を高める可能性がある一方で、コストや待ち時間も増やすからです。

ここは、誤解されやすい部分です。

「プロンプトの次はエージェントだから、すべてエージェント化すればよい」という話ではありません。

単純な要約や文章作成なら、明確な一回の指示で十分な場合があります。

処理順序が決まっているなら、コードで固定したワークフローの方が安定します。

一方、状況によって判断や利用ツールが変わる仕事では、エージェントが有効です。

したがって、現在重要なのは、良いプロンプトを書くことに加えて、どの処理方式を採用すべきか判断することです。

2025年、設計対象はコンテキスト全体へ広がった

モデルが実際に参照する情報は、ユーザーが入力した文章だけではありません。

たとえば、次のようなものが含まれます。

• システム指示

• ユーザーの依頼

• 会話履歴

• 検索結果

• 社内文書

• ファイルやコード

• ツール定義

• ツールの実行結果

• セッション状態

• 短期・長期メモリ

• 過去の作業記録

• サブエージェントからの報告

AnthropicはContext Engineeringを、LLMの推論時に、プロンプト以外の情報も含めて最適なトークン集合を選び、維持するための戦略と説明しています。

複数ターン、長時間動くエージェントでは、システム指示、ツール、MCP、外部データ、履歴など、コンテキスト全体の状態を管理する必要があるということです。

コンテキストウィンドウが大きくなっても、すべての情報を詰め込めばよいわけではありません。

情報量が増えると、次の問題が起こります。

• 重要な指示が埋もれる

• 古い情報が現在の判断へ混入する

• 不要なログやツール結果が注意を奪う

• 情報同士が競合する

• コストと処理時間が増える

• 外部データに含まれる悪意ある指示を読み込む

Googleは、コンテキストを単なる変更可能な文字列ではなく、より豊かな状態システムから一回のモデル呼び出し用に生成される「compiled view」として扱う考え方を示しています。

永続的なセッションやメモリ、ファイルと、その都度モデルへ渡す作業用コンテキストを分けることで、情報の保存と提示を独立して管理できます。

私がContext Engineeringを実務で考える場合、次の5点に分けます。

1. 選択する
   何をモデルへ渡し、何を渡さないか。

2. 順序を決める
   どの情報を先に置き、何を後に置くか。

3. 圧縮する
   何を要約し、何を原文のまま残すか。

4. 分離する
   どのエージェントや処理へ、どの情報まで見せるか。

5. 更新する
   古くなった状態や指示をどう置き換えるか。

Context Engineeringは、巨大なプロンプトを書く技術ではありません。

限られた注意資源へ、必要な情報を必要な時点で配置する技術です。

AGENTS.mdやSKILL.mdは、プロンプトを再利用可能な部品へ変えた

AGENTS.mdやSKILL.mdは自然言語で書かれるため、広い意味ではプロンプトの一種です。

ただし、チャット欄へ毎回貼り付ける一時的な指示とは性質が異なります。

• ファイルとして保存できる

• バージョン管理できる

• 適用範囲を決められる

• 必要な場面で読み込める

• 補助資料やスクリプトを持てる

• チームで保守できる

• 評価やテストの対象にできる

Claude CodeのSkillsでは、SKILL.mdが主要な指示を持ち、必要に応じてテンプレート、期待される出力例、実行スクリプト、詳細な参考資料を追加できます。

GoogleのADKでも、すべての専門知識を一つのシステムプロンプトへ結合するのではなく、必要な知識を段階的に読み込む「progressive disclosure」が紹介されています。

Googleの例では、10個のSkillsを最初からすべて連結する場合と比べて、初期コンテキスト使用量を約90％減らせる構成が示されています。ただし、これは同記事内の特定の構成例であり、あらゆるシステムで同じ削減率になるという意味ではありません。

ここで起きている変化は、単なる保存形式の違いではありません。

従来のプロンプトは、その場で書き、貼り付け、結果を目視するものでした。

現在の指示ファイルは、名前、範囲、参照先、関連ツール、保守責任を持つ、ソフトウェア部品に近い存在です。

プロンプトエンジニアリングは、コピーライティングだけではなく、自然言語による設定、仕様、手順、ポリシーの管理へ広がっています。

2026年、OpenAIはHarness Engineeringを明示した

2026年2月11日、OpenAIは「Harness engineering: leveraging Codex in an agent-first world」を公開しました。

この中で特に重要なのが、巨大なAGENTS.mdを一つ用意する方式がうまく機能しなかったという説明です。

OpenAIは、その問題として次を挙げています。

• 巨大な指示ファイルが、タスクやコード、関連文書のためのコンテキストを圧迫する

• すべてが重要と書かれると、本当に重要な指示が見えなくなる

• 一枚岩の文書はすぐ古くなる

• 機械的な検証が難しい

そのため、OpenAIはAGENTS.mdを百科事典ではなく、より詳しい正規文書へ案内する「目次」として扱う方針を採っています。

ここに、2023年頃との違いがよく表れています。

以前の発想は、次のようなものでした。

現在の発想は、次のように変わっています。

OpenAIの事例では、Codexがアプリケーションの画面、ログ、メトリクス、トレースを直接確認できる環境も整備されています。

Codexは不具合を再現し、修正し、再起動し、再検証するループを実行できます。

この場合、成果を決めるのは最初のプロンプトだけではありません。

• 実際の画面を見られるか

• ログやエラーを取得できるか

• テストを再実行できるか

• 正しい状態を判定できるか

• 失敗後に修正と再検証を行えるか

こうした環境全体が成果を左右します。

これがHarness Engineeringの中心的な考え方です。

「PromptからContext、Harnessへ」は分かりやすいが、完全には正確ではない

ここまでの変化を、次のように説明することがあります。

流れを理解するための簡略図としては有効です。

ただし、厳密には、前の概念が次の概念へ完全に置き換わるわけではありません。

プロンプト、コンテキスト、ツール、評価、権限は、目的も設計対象も異なります。

より正確には、AIシステム設計を次のような領域へ分ける方が分かりやすいでしょう。

1. 要件設計

• 何を実現するか

• 誰が利用するか

• 何を成功とするか

• 何を制約とするか

• 誰が責任を負うか

2. プロンプト設計

• どのような指示を与えるか

• どの例を見せるか

• どの判断方針を伝えるか

• どの出力形式を求めるか

3. コンテキスト設計

• 何を検索するか

• 何を記憶するか

• 何をモデルへ渡すか

• 何を圧縮・削除するか

4. ツール設計

• どの能力を与えるか

• 入力と戻り値をどう定義するか

• エラーをどう返すか

• 破壊的な操作をどう識別するか

5. ワークフロー・エージェント設計

• どこをコードで固定するか

• どこをモデルに判断させるか

• どのように分岐、再試行、停止するか

6. 権限・セキュリティ設計

• どのデータへアクセスできるか

• どの操作を自動実行できるか

• どこで人間の承認を求めるか

• 秘密情報をどう隔離するか

7. 評価設計

• 何を正しい結果とするか

• どのテストケースを使うか

• 何を失敗として分類するか

• 品質、コスト、安全性をどう測るか

8. Human-AI Interaction Design

• AIが何を準備するか

• 人間が何を判断するか

• どこで修正・確認するか

• 誰が最終責任を持つか

9. 運用設計

• ログとトレースをどう残すか

• モデル更新時にどう回帰試験するか

• 問題発生時にどう停止・復旧するか

• 失敗をどう改善へつなげるか

ハーネスは、このうち複数の領域をモデルの周囲で統合し、実際に動かすための実行環境と捉えると理解しやすくなります。

プロンプトが消えたのではなく、より大きな設計体系の一部として位置づけ直されたのです。

プロンプト力の本質は、要件定義へ近づいている

プロンプトという言葉から、AIに通じる特別な表現を想像する人は少なくありません。

しかし、仕事で大きな差を生むのは、次のような能力です。

• 何を作りたいかを明確にする

• 対象者と利用目的を決める

• 必要な材料をそろえる

• 必須条件を定義する

• 禁止事項を定義する

• 判断基準を定義する

• 完了条件を定義する

これは、ほとんど要件定義です。

この見方を支持する研究の一つが、Requirement-Oriented Prompt Engineering、略してROPEです。

この研究では、32人を無作為に割り当て、途中で参加を中断した2人を除く30人を分析しています。

要件を明確に書くことへ焦点を当てたROPE群は、事前・事後評価で19.0％の改善を示しました。一方、一般的なプロンプトエンジニアリングの教材と自己練習を行った群の改善は0.7％でした。

ただし、注意も必要です。

この研究は30人を対象とする小規模な研究であり、参加者はプロンプト経験が限定的な初心者でした。すべての業務や熟練者へ同じ結果を一般化することはできません。

それでも、「定型句を覚えることより、要求を整理することの方が有効な場合がある」という示唆は、実務的にも重要です。

たとえば、次の言葉を加えるだけでは、要件は明確になりません。

• あなたは専門家です

• 詳しく説明してください

• ステップバイステップで考えてください

• 完璧な回答をしてください

それよりも、

• 成果物は何に使われるのか

• 誰が読むのか

• どの資料を根拠にするのか

• 何を必須とするのか

• どの判断は人間へ戻すのか

• どう検証するのか

を整理する方が、モデルや製品が変わっても有効です。

私は、これからのAI研修で本当に重視すべきなのは、プロンプトの「型」を大量に覚えることではないと考えています。

曖昧な業務要求を、AIが実行でき、人間が評価できる仕様へ変換する訓練の方が重要です。

それでも、プロンプトの書き方で結果が変わることはある

ここまで読むと、「では言い回しや形式は、もう重要ではないのか」と感じるかもしれません。

そうではありません。

同じ内容でも、プロンプトの書式や構造によって性能が変わることは、研究でも確認されています。

2024年の研究では、同じ内容をプレーンテキスト、Markdown、JSON、YAMLなどの異なるテンプレートで表現し、複数のタスクで性能を比較しています。

その結果、GPT-3.5-turboのコード翻訳タスクでは、テンプレートの違いによって最大40％の差が生じました。一方、GPT-4は比較的頑健でした。

ここから、二つの異なる結論を導けます。

一つ目は、プロンプトの書き方は依然として重要だということです。

二つ目は、少しの書式変更で性能が大きく揺れるのであれば、業務の信頼性を一つのプロンプトだけに依存させるべきではないということです。

実務では、次のような仕組みで揺らぎを吸収する必要があります。

• 構造化出力

• スキーマ検証

• 複数のテストケース

• 自動評価

• 再試行

• ルールベースの検査

• 外部ツールによる確認

• 人間レビュー

• モデル更新時の回帰試験

「このプロンプトで一度うまくいった」という事実と、「このシステムが継続して一定品質を出せる」という事実は別です。

プロンプト改善は必要ですが、それだけで再現性を保証することはできません。

ツール設計は、プロンプト設計と同じくらい重要になった

エージェントは、モデルが賢いだけでは仕事を完了できません。

検索、ファイル操作、コード実行、メール、カレンダー、データベース、ブラウザ、外部APIなど、実際に作業するための能力が必要です。

これらのツールは、単に用意すればよいわけではありません。

• ツール名が分かりやすいか

• 説明が明確か

• 入力項目が適切か

• 必須項目が分かるか

• 戻り値が大きすぎないか

• エラーの原因が分かるか

• 似たツールが重複していないか

• 破壊的操作かどうか分かるか

Anthropicは、ツールの説明や仕様を改善することが、エージェントのツール利用性能へ大きく影響すると説明しています。

同社の事例では、ツール説明の精密な改善によって、エラー率とタスク完了率が大幅に改善したとされています。

したがって、エージェントが失敗したとき、原因がプロンプトとは限りません。

• 必要な情報がない

• 入力データが古い

• ツール名が曖昧

• 入力スキーマが複雑

• 戻り値が扱いにくい

• 必要な権限がない

• エラー情報が不足している

• 途中状態が壊れている

• 停止条件が不明確

こうした問題をすべてプロンプトの修正で解決しようとすると、原因を誤認します。

評価能力は、プロンプト能力より上位にある

プロンプトAとプロンプトBのどちらが優れているか。

この問いに答えるためには、何を「優れている」とするかを決めなければなりません。

• 正確性

• 完全性

• 読みやすさ

• コスト

• 処理時間

• 安全性

• 適切なツール選択

• 禁止操作の回避

• 人間承認の遵守

• 失敗後の回復能力

これらの基準がなければ、プロンプト改善は印象論になります。

OpenAIのエージェント評価ガイドでは、最終回答だけでなく、モデル呼び出し、ツール呼び出し、ガードレール、エージェント間の引き継ぎを含む実行記録全体をトレースとして評価します。

トレース評価によって、次のような問題を確認できます。

• 適切なツールを選んだか

• 必要な引き継ぎが行われたか

• 指示や安全方針へ違反していないか

• プロンプトやルーティングの変更が全体挙動を改善したか

そして、望ましい挙動が明確になったら、個別トレースの確認から、再現可能なデータセットと評価実行へ移行することが推奨されています。

Anthropicも、エージェントは複数ターンでツールを呼び、状態を変更し、中間結果に応じて振る舞いを変えるため、通常の回答生成より評価が難しいと説明しています。

ここから分かるのは、今後より重要になるのは「良いプロンプトを一発で書く能力」だけではないということです。

何を良い結果とするかを定義し、失敗を観測し、どこを修正すべきか判断する能力の方が上位にあります。

原因によっては、修正すべきなのはプロンプトではありません。

• モデルを変える

• データを追加する

• ツールを修正する

• ワークフローを固定する

• 権限を狭める

• 検証コードを追加する

• 人間承認を追加する

評価基準があって初めて、どの対策を選ぶべきか判断できます。

セキュリティは、プロンプトだけでは守れない

エージェントが外部のWebページ、メール、文書、チャット、データベースを読むようになると、それらの中に含まれる悪意ある指示も読み取る可能性があります。

これは、間接プロンプトインジェクションと呼ばれる問題です。

この問題に対して、システムプロンプトへ、

と書くだけでは十分ではありません。

必要なのは、多層的な防御です。

• 最小権限

• 読み取りと書き込みの分離

• 高リスク操作での人間承認

• サンドボックス

• 秘密情報へのアクセス制御

• 外部データと命令の分離

• ツール入出力の検査

• 操作ログとトレース

• 異常時の停止

プロンプトは重要な制御手段ですが、強い防御境界ではありません。

エージェントの能力、自律性、権限が高くなるほど、権限設計と実行環境の重要性が増します。

モデルが高性能だから安全なのではありません。

高性能なモデルへ広い権限を与えるほど、曖昧な目的や誤った判断が大きな副作用へつながる可能性があります。

Human-in-the-loopは、自動化の失敗ではない

AIの進化を、「人間をすべての処理から外す方向」とだけ捉えるのは正確ではありません。

仕事によっては、次の役割分担の方が合理的です。

• AIが情報を集める

• AIが候補を整理する

• AIが問題を発見する

• 人間が判断する

• AIが承認済みの処理を実行する

• 人間が結果を監査する

特に、次のような領域では人間の介入が重要です。

• 公開

• 契約

• 高額な支出

• 法的責任

• 顧客への連絡

• ブランド判断

• 個人情報の利用

• 不可逆な変更

OpenAIのAgents SDKは、処理を人間の承認待ちで停止し、承認後に再開できる仕組みを扱っています。

Googleの長時間実行エージェントの設計でも、状態を保持し、一時停止し、外部イベントを待ち、後から処理を再開する構造が示されています。

Human-in-the-loopは、AIが未熟な間だけ使う暫定策ではありません。

どこまでAIへ任せ、どこで人間へ戻すかを決める、業務設計上の要素です。

「プロンプトエンジニア」という職業は消えるのか

ここは、断定しすぎない方がよい論点です。

現時点で、「プロンプトエンジニアという職業が消える」と証明する十分な事実はありません。

ただし、単発のプロンプトを作成・販売するだけの専門性は、相対的に弱くなる可能性があります。

理由は次の通りです。

• モデルごとに有効な表現が変わる

• モデル更新で古い技法が不要になる

• 自動プロンプト最適化が進む

• 製品側が指示を補完する

• 強いモデルほど自然な指示へ対応できる

• プロンプト単体では本番品質を保証できない

一方で、高度なプロンプト設計の専門性は残ります。

• 指示の優先順位

• 不確実性の扱い

• ツール選択方針

• エラー時の行動

• エージェント間の責任分担

• 出力スキーマ

• 安全方針

• モデル差分への対応

• 評価可能な仕様

こうした仕事は、単なる言葉選びではありません。

自然言語を含む、確率的なソフトウェア仕様の設計に近い仕事です。

今後は、プロンプト設計の専門性が消えるというより、次のような職種や役割へ統合される可能性が高いでしょう。

• AIエンジニア

• エージェントエンジニア

• AIプロダクトマネージャー

• AI業務設計者

• 評価エンジニア

• AIセキュリティ担当

• ナレッジマネジメント担当

• ドメイン専門家

• AI研修設計者

つまり、「プロンプトだけを専門とする仕事」の比重は下がっても、自然言語でAIの仕様を設計する能力は多くの職種へ広がっていきます。

自然言語でAIへ指示する能力は、全職種の基礎能力になる

専門職としての独立性が下がることと、能力の重要性が下がることは同じではありません。

メールを書く能力は多くの職種で必要ですが、「メールエンジニア」という職業は一般的ではありません。

同じように、AIへの指示能力も、特定職種だけの専門技術ではなく、多くの職種が持つべき基礎能力へ近づいています。

必要になるのは、次のような能力です。

• 問題を言語化する

• 前提を共有する

• 必要な材料を渡す

• 判断基準を示す

• 完了条件を決める

• 出力を批判的に確認する

• 不足を追加する

• 失敗原因を診断する

• AIと共同で要件を詰める

ただし、一度で完璧なプロンプトを書くことが中心ではありません。

実務では、次の循環が重要です。

これは、「プロンプトを書く能力」というより、AIとの協働を継続的に調整する能力と呼ぶ方が近いでしょう。

AI活用格差は、プロンプト格差だけでは説明できない

2023年頃は、AIを使いこなせない理由を「プロンプトが下手だから」と説明することが多くありました。

しかし、現在のAI活用格差は、より複雑です。

個人レベル

• 問題を整理できるか

• 必要な材料を集められるか

• AIの出力を評価できるか

• 不明点を放置しないか

• 適切に反復できるか

チームレベル

• 共通ルールがあるか

• 良い事例を共有できるか

• 業務データへ接続できるか

• レビュー責任が決まっているか

• 失敗を記録し、再発防止へ使えるか

組織レベル

• AIツールを導入しただけで終わっていないか

• 社内文書やデータが整理されているか

• 権限体系が整っているか

• 評価データを用意できるか

• AIを業務フローへ組み込めているか

• モデルや製品の変更へ対応できるか

私は、AIの成果を概念的に次のような掛け算で捉えています。

これは研究上の確立した公式ではなく、ここまでの事実を実務向けに整理した私の見方です。

プロンプト能力が高くても、社内データが散乱し、評価基準がなく、権限が曖昧なら、安定した成果にはつながりません。

逆に、最新・最高性能のモデルでなくても、業務が整理され、良い材料と検証ループがあれば、十分な成果を出せる場合があります。

では、これから何を学ぶべきか

ここからは、私の提案です。

プロンプトエンジニアリングを学ぶことには、今でも価値があります。

ただし、特定モデルにだけ効く言い回しや、万能テンプレートを大量に集める方法は勧めません。

これから優先すべきなのは、次の能力です。

1. 曖昧な依頼を、要件へ変える

目的、対象者、材料、必須条件、禁止事項、判断基準、完了条件を整理します。

2. AIへ渡す情報を設計する

何を常時見せ、何を必要時に検索し、何を要約し、何を分離するかを決めます。

3. プロンプトで解く問題と、それ以外で解く問題を分ける

指示を変えるのか、材料を追加するのか、モデルを変えるのか、コードやワークフローで固定するのか、人間の判断へ戻すのかを切り分けます。

4. 最終出力だけでなく、実行過程を評価する

どの情報を使い、どのツールを選び、どこで失敗し、承認条件を守ったかまで確認します。

5. 小さく始め、失敗から仕組みを育てる

最初から巨大な万能エージェントを作るのではなく、単発のプロンプト、単純なワークフロー、限定されたツールから始めます。

実際の失敗を観測し、必要な仕組みだけを追加します。

AI活用の成熟度は、プロンプトの長さでは測れません。

何を言葉で指示し、何を情報として与え、何をコードで固定し、どこで権限を止め、何を評価し、どこで人間が判断するか。

この分担を設計できることが、より本質的な能力です。

まとめ——プロンプトは「魔法の一文」から、AI設計の基礎言語へ変わった

プロンプトエンジニアリングは、まだ重要です。

AIへ目的、判断基準、制約、責任範囲を伝える役割は、モデルやエージェントの能力が高くなるほど重要になります。

一方で、信頼性、再現性、安全性、長時間実行を、一つの長いプロンプトだけで担保する発想には限界があります。

現在、設計対象は次の範囲まで広がっています。

• 要件

• プロンプト

• コンテキスト

• データ

• ツール

• メモリ

• 実行ループ

• 権限

• 評価

• 人間との役割分担

• 運用と改善

したがって、「プロンプトエンジニアリングは終わった」という表現は正確ではありません。

私が最も妥当だと考える整理は、次の通りです。

これから評価されるのは、特定の魔法の一文を知っている人だけではありません。

曖昧な目的を実行可能な要件へ変え、必要な情報と道具をそろえ、権限を制御し、結果を評価し、失敗から仕組みを改善できる人です。

だから、これから考えるべき問いは、「どんなプロンプトを書けばよいか」だけではありません。

この切り分けができることこそ、AI時代に必要な本当の設計能力だと私は考えています。

出典・参考資料

• OpenAI「Harness engineering: leveraging Codex in an agent-first world」2026年2月11日。巨大なAGENTS.mdの問題、文書構造、観測可能性を含むCodexの実践事例。

• OpenAI Developers「Agents SDK」。エージェントループ、ツール呼び出し、引き継ぎ、セッション、ガードレール、人間承認、トレースの公式仕様。

• OpenAI Developers「Evaluate agent workflows」。トレース評価、データセット、継続評価の公式ガイド。

• OpenAI Help Center「Best practices for prompt engineering with the OpenAI API」。明確な指示、入力との分離、具体的な出力条件に関する基本原則。

• Anthropic「Building Effective AI Agents」。WorkflowとAgentの区別、単純な構成から始める設計原則。

• Anthropic「Effective context engineering for AI agents」。推論時の情報選択とコンテキスト状態管理の定義。

• Anthropic「Extend Claude with skills」。SKILL.mdと補助ファイルによる再利用可能な能力設計。

• Anthropic「Writing effective tools for AI agents」。ツール説明と仕様設計がエージェント性能へ与える影響。

• Anthropic「Demystifying evals for AI agents」。複数ターン、ツール利用、状態変更を伴うエージェント評価。

• Google Developers Blog「Architecting efficient context-aware multi-agent framework for production」。コンテキストを状態システムから生成されるviewとして扱う設計。

• Google Developers Blog「Developer’s Guide to Building ADK Agents with Skills」。段階的な情報読み込みとSkills構成。

• Google Developers Blog「Build Long-running AI agents that pause, resume, and never lose context with ADK」。状態保持、一時停止、再開を含む長時間実行設計。

• Yaoほか「ReAct: Synergizing Reasoning and Acting in Language Models」。推論と行動を交互に行う枠組み。

• Shinnほか「Reflexion: Language Agents with Verbal Reinforcement Learning」。言語的フィードバックと記憶による試行改善。

• Yangほか「Large Language Models as Optimizers」。OPROによる自然言語最適化。

• Khattabほか「DSPy」。ハードコードされたプロンプトテンプレートから、最適化可能なLMパイプラインへの移行。

• Singhviほか「DSPy Assertions」。計算可能な制約と自己修正を含むLMパイプライン。

• Maほか「What Should We Engineer in Prompts?」。ROPEによる要件重視の訓練と30人を対象とした比較実験。

• Heほか「Does Prompt Formatting Have Any Impact on LLM Performance?」。プロンプト形式によるモデル性能差の検証。