プロンプトエンジニアリングの終焉？

2023年から2024年にかけての「プロンプトエンジニアリング」のゴールドラッシュを覚えていますか？　ネットのグルたちは、LLMに与えるべき正確な魔法の言葉を知っていることこそ21世紀でいちばん価値のあるスキルだ、と主張していました。求人サイトには、モデルにいつ「深呼吸して」「ステップ・バイ・ステップで考えて」「熟練のソフトウェアエンジニアとして振る舞って」と言えばいいかを心得たスペシャリストに向けて、天文学的な年収の求人が並びました。

あれはコンピューティングの歴史のなかでも、奇妙な過渡期でした。私たちはコンピューターチップに自然言語で話しかけ、文字列をハックすることで、隠れた挙動を探り当てようとしていたのです。

しかし2026年半ばの今、景色はまったく違って見えます。独立した専門分野としてのプロンプトハックは、消えつつあります。フロンティアモデルがより賢くなり、指示に素直に従うようになり、エージェント型のアーキテクチャにネイティブに組み込まれるにつれて、焦点が移ったのです。複雑なタスクをこなしてもらうために、長々としたテキストのプロンプトでモデルをなだめすかす必要は、もうありません。そのかわりに、私たちはシステムをつくっています。

「プロンプトを書く人」の時代は終わり、AIシステムエンジニアの時代がやってきました。

---

魔法の文字列のもろさ

なぜこの変化が起きたのかを理解するには、初期のプロンプトベースのアプリケーションがいかにもろかったかを見る必要があります。3,000文字のプロンプトに頼るソフトウェア機能をつくったことがあるなら、プロンプトエンジニアリングが砂上の楼閣だということに、すぐ気づいたはずです。

• 決定性の欠如：95%の確率で完璧に動いていたプロンプトでも、モデルの確率的な性質のせいで、96回目の実行でランダムに失敗することがありました。
• プロバイダーへのロックイン：Claude 3.5 Sonnet向けに最適化したプロンプトは、GPT-4oやGemini 1.5 Proに送るとしばしば失敗しました。どのモデルにも、自然言語の解釈に独特の細かなクセがあったのです。
• アップデートによるリグレッション：プロバイダーがモデルにマイナーアップデートをかけると、モデル内部の重みが変わったせいで、プロンプトが突然壊れてしまいました。

+-----------------------------------+
|  Original Prompt:                 |
|  "Write JSON output. Be concise." |
+-----------------------------------+
                 |
                 v (Model Version Update)
+-----------------------------------+
|  Failed Output:                   |
|  "Sure, here is your JSON..."     |
|  (Breaks parser with intro text)  |
+-----------------------------------+

「魔法の文字列」に頼るのは、安定したソフトウェアをつくるには最悪のやり方でした。インフラのちょっとしたアップデートで、アプリケーションのエンドポイントが返す文字列のフォーマットがランダムに壊れるなんて、ほかのどんなコンピューティング環境でありうるでしょうか？

---

構造化されたシステムへの移行

モノリシックなプロンプトのもろさを解決するために、開発者たちは巨大な指示文を書くのをやめ、タスクを構造化されたパイプラインに分解しはじめました。

モデルに「このユーザーのサポートチケットを読んで、注文を探し、口調を分析して、JSONで返信を書いて」と頼むかわりに、いまはステートマシンを組みます。システムは、それぞれが単一の目的を持つ別々のステップに分割されます。

1. 分類器（Classifier）：軽量なモデルがチケットのカテゴリを分類します（出力は厳密なenum）。
2. データ取得（Data Retriever）：APIクエリで、チケットのメタデータをもとにユーザーの注文情報を取得します。
3. 下書き生成（Draft Producer）：取得したコンテキストを使って、モデルが下書きを生成します。
4. 検証（Validator）：最後のコード層で、下書きにハルシネーションが含まれておらず、スキーマのルールに合っていることを保証します。

問題を分解することで、プロンプトそのものの複雑さが下がります。各ノードのプロンプトはもう長いエッセイではなく、シンプルで直接的な指示です。あるステップが失敗しても、グラフのどのノードが原因なのかが正確にわかります。各ステップを独立してテストし、デバッグし、最適化できるのです。

構造化出力を使って、これをどう実装するのかを見てみましょう。モデルにJSONを書かせて正しくフォーマットされることを祈るのではなく、スキーマ検証によって出力の構造を保証するのです。

Zodと構造化出力のクライアントを使った、モダンなTypeScriptの例がこちらです。

import { z } from "zod";

// 1. モデルの出力に対する厳密なスキーマを定義する
const TicketAnalysisSchema = z.object({
  category: z.enum(["billing", "technical", "feature_request", "general"]),
  priority: z.enum(["low", "medium", "high", "critical"]),
  sentiment: z.enum(["positive", "neutral", "frustrated", "angry"]),
  suggestedAction: z.string().describe("The next immediate action the team should take"),
});

type TicketAnalysis = z.infer<typeof TicketAnalysisSchema>;

// 構造化されたノードを表す実行関数の例
async function analyzeTicket(ticketBody: string): Promise<TicketAnalysis> {
  // JSON形式で出力するようプロンプトで指示を書くかわりに、
  // スキーマをモデルの設定に直接渡す。
  const response = await aiClient.chat.completions.create({
    model: "gpt-4o-2026-05-10",
    messages: [
      { role: "system", content: "Analyze the customer ticket." },
      { role: "user", content: ticketBody }
    ],
    response_format: {
      type: "json_object",
      schema: TicketAnalysisSchema, // APIレベルで強制される
    }
  });

  return TicketAnalysisSchema.parse(JSON.parse(response.choices[0].message.content));
}

スキーマへの準拠をAPIレベルで強制すれば、プロンプトそのものはごく単純なものになります。「Markdownのタグを含めないこと。『Sure, here is...』で始めないこと。有効なJSONだけを出力すること」と、何段落もかけてモデルに指示する必要はもうありません。モデルの出力トークンは、パーサーのステートマシンに合うよう強制されるのです。

---

プロンプトからシステムへ移行するための実践ガイドライン

もしまだ長くて複雑なシステムプロンプトを書いているなら、リファクタリングのときです。次のルールを使って、アプリケーションをプロンプトエンジニアリングからシステムエンジニアリングへと移行させましょう。

• 複雑さを分解する：プロンプトが500語を超えているなら、そのプロンプトはいろいろなことをやりすぎています。複数の連続したLLM呼び出しやツールループに分割しましょう。
• あらゆる場所でスキーマを検証する：Zod、Pydantic、ネイティブのJSONスキーマなどのツールを使い、モデルのステージ間でやりとりされる構造化された入出力をすべて検証します。
• テキストよりコード：単純な正規表現、データベースクエリ、すっきりしたユーティリティ関数で書けるタスクなら、LLMを使ってはいけません。LLMの推論は、意味の解析と統合だけに集中させましょう。
• プロンプトをバージョン管理する：システムへの指示はコードと同じように扱います。バージョン管理（git）に保存し、更新のたびに自動のリグレッション評価を走らせ、複数のモデルのエンドポイントでテストしましょう。

---

これからの展望：中間表現（IR）としてのプロンプト

エージェントフレームワークが進化するにつれて、人間がプロンプトを書く機会は減っていくでしょう。プロンプトは中間表現（IR：Intermediate Representation）、つまりコンパイラやフレームワークが自動生成する低レベルの命令セットになっていきます。

DSPy（Declarative Self-Improving Language Programs）のようなシステムは、すでにこの考え方が成り立つことを示しています。プロンプトを手で書くかわりに、プログラムの構造（入力、出力、モジュール）を定義し、少数の学習用サンプルを与えます。するとフレームワークがプログラムをコンパイルし、制約付き最適化を使って、使っているモデルに合わせたプロンプトを自動で生成・テスト・最適化してくれるのです。

そんな未来では、プロンプトを手で書くことは、アセンブリ言語を手で書くような感覚になるでしょう。低レベルのデバッグやパフォーマンスチューニングにはまだ役立つものの、ほとんどの開発者は高レベルのロジック、スキーマ、アサーションを書き、指示へのコンパイルはフレームワークに任せるようになります。

---

関連記事

• 標準化されたインターフェースがモジュール型のシステムアーキテクチャをどう支えるのかは、MCPはAIアプリケーションのUSB-Cになるをご覧ください。
• AIを活用した開発でテストカバレッジと検証を維持するためのヒントは、AIでコード品質を保つための原則にまとめています。
• 開発者体験を変えつつある実践的なツールについては、Claude Code vs Cursor：作り手目線の徹底比較で解説しています。

参考リンク

• 構造化スキーマとプロンプト管理については、OpenAI Developer Blogをご覧ください。
• 自己改善型のプロンプトコンパイラや研究論文については、Stanford NLP Groupで読めます。
• 堅牢なエージェントを構築するための開発パターンは、Vercel AI SDK Docsで確認できます。

---

私の考えが変わったきっかけ

2024年、私は自社プロダクトの分類機能のために、2週間かけてシステムプロンプトを最適化しました。形容詞をいじり、few-shotの例を足し、モデルに「この出力に私の仕事がかかっている」と伝えることまで試しました。精度は92%に達し、自分は天才なんじゃないかと思ったものです。

1か月後、プロバイダーがモデルをアップデートしました。精度は78%まで落ち、モデルが突然ていねいな前置きの文章をつけるようになったせいで、JSONパーサーが構文エラーを吐きはじめました。

そのとき、プロンプトエンジニアリングは幻想だったのだと気づきました。私は堅牢なソフトウェアをつくるかわりに、何週間もかけて、混沌としたブラックボックスのパラメータをいじっていただけだったのです。

私たちはモノリシックなプロンプトを捨て、スキーマの強制と厳密な入力パースを使ったシンプルな3ステップのステートマシンに置き換えました。コードは数十行増えましたが、プロンプトはたった1文に縮みました。精度は98%に上がり、モデルをアップデートしてもそのまま保たれました。私は悟りました。モデルの不安定さを解決するのは、決してより良いプロンプトではなく、より良いアーキテクチャなのだと。