プロンプトを超えて：なぜAIエージェントには決定論的な制御フローが必要なのか

AIエージェントに関する主流のナラティブは、長らく「プロンプトエンジニアリング」、つまりモデルを意図通りに動作させるための魔法の言葉を見つける技術に集中してきました。しかし、開発者が単純なプロトタイプから複雑で本番環境向けのシステムへと移行するにつれ、壁に突き当たっています。モデルに特定のシーケンスに従わせるために、大文字で MANDATORY や DO NOT SKIP と入力しなければならない状況に陥っているなら、それは「プロンプトの限界」に達していることを意味します。

ソフトウェアにおける信頼性は、常に決定論的な制御フロー、すなわち、明示的な状態遷移、検証チェックポイント、および再帰的な構成可能性を通じて達成されてきました。AIエージェントが単なる「確率論的なオウム」を超え、信頼できるツールとなるためには、ロジックを散文（プロンプト）からランタイムへと移行させる必要があります。

プロンプトベースのロジックの失敗

プロンプトチェーンは本質的に非決定論的であり、仕様が不明確です。LLMをシステム内の単一のコンポーネントとしてではなく、システム全体として扱うことは、複雑さが増すにつれて信頼性の崩壊を招きます。

ステートメントが単なる提案に過ぎず、関数が「Success」を返しつつ同時に結果をハルシネーション（幻覚）させているようなプログラミング言語を想像してみてください。そのような環境では、推論は不可能になります。これは、LLMが自身のハイレベルなオーケストレーションを管理するタスクを課されている現在の多くのエージェント的ワークフローの現状です。Hacker Newsでの議論においてあるユーザーが指摘したように、モデルに制御フローを管理させると、ファイルを見落としたり、bundlesを三重にテストしたり、ループに陥ったりすることがよくあります。これらの失敗は、GPT-4やClaude 3.5のような最先端のモデルであっても発生します。

ロジックをランタイムへ移行する

信頼できるエージェントを構築するためには、開発者は決定論的な足場（scaffolds）を実装しなければなりません。これは、LLMを特定の限定されたタスクのためのツールとして扱い、周囲のソフトウェアが「どのように」「いつ」を行うかを処理することを意味します。

1. 決定論的なオーケストレーション

エージェントに「トピックを調査してレポートを書いて」と頼む代わりに、決定論的なシステムはこれをDAG (Directed Acyclic Graph) または状態マシンに分解します：

• Step 1: LLMが検索クエリを生成する。
• Step 2: プログラマティックな検索の実行（決定論的）。
• Step 3: LLMが結果を合成する。
• Step 4: 出力形式のプログラマティックな検証。

記帳やルーティングを記号論的レイヤー（symbolic layer）に移行させることで、開発者はトークンコストを削減し、速度を向上させ、エージェントがステップを「忘れる」リスクを排除できます。

2. 積極的なエラー検出と品質ゲート

プログラマティックな検証のないエージェントは、単に誤った結論に到達するための速い方法に過ぎません。コミュニティでは、エラーハンドリングに対して3つの一般的な（そしてしばしば欠陥のある）アプローチが提案されています：

• The Babysitter: エラーが伝播する前に人間が介入してキャッチする。
• The Auditor: 実行後に徹底的なエンドツーエンドの検証を行う。
• The Prayer: 出力を「雰囲気」で受け入れ、最善を願う。

これらを超えて、開発者は品質保証を担う決定論的なノードである「品質ゲート（quality gates）」を実装しています。例えば、Stripeの「Minions」システムは、非決定論的なLLMの作業の間に決定論的なノードを配置することで、検証をLLM自体に任せることなく品質を確保しています。

フィールドからの視点

決定論的な制御フローへの移行は、さまざまな技術的な反論や補完的な戦略を引き起こしています：

ソフトウェア作成におけるLLMの役割

一部の主張では、究極の目標は、実行時にLLMを使用してタスクを完了することではなく、タスクを完了するための ソフトウェアを書く ことにLLMを使用することであるとしています。この見解では、LLMの役割は、厳格なビジネスルールを体現するシステムに対して、ユーザーが準拠した入力を提供するのを助けることに縮小されます。

「オペレーショナル・リフレックス」アプローチ

一貫性を確保しつつ柔軟性を維持するために、一部の開発者は一般的なタスクに対して「lockfiles」を使用しています。これらは、タスクに関連する特定のスキルや専門知識の断片がどれであるかを定義し、オープンエンドなプロンプトではなく、定義済みのブループリントに基づいてタスクを割り当てるコーディネーターとして機能します。

ハイブリッドモデル

私たちは単にプログラミングを再発明しているだけではないかという議論があります。あるコメント主は次のように述べています：

"Can't wait for ya'll to come full circle and invent programming from first principles."

しかし、他の人々は、ゲームエンジンがハイレベルなスクリプト言語（Luaなど）を使用して高性能な C++ ライブラリを呼び出すのと同様のハイブリッドアプローチを提案しています。このアナロジーでは、LLMは柔軟な「スクリプト」レイヤーを提供し、決定論的なハーネスが堅牢な「エンジン」を提供します。

結論：エージェント・エンジニアリングの未来

プロンプトを書くことではなく、制御フローを設計することこそが、エージェント・エンジニアリングの新たなフロンティアとなっています。エージェントのループをプレゼンテーション層や制御層から分離することで、開発者は、観測可能で、フォールトトレラント（耐故障性）であり、真にスケーラブルなシステムを構築できます。目標は、LLMの創造性を排除することではなく、それを結果がユーザーの意図に沿うことを保証するフレームワーク内に繋ぎ止めることです。