上級エンジニアが AI エージェントの構築時に困難に遭遇するのはなぜでしょうか? @philschmid 氏は、興味深いパラドックスを共有しました。なぜ経験豊富なシニアエンジニアは、ジュニアエンジニアに比べてAIエージェントの開発が遅く、開発が困難になることが多いのでしょうか？ Schmid 氏は、その根本原因は、従来のソフトウェアエンジニアリングが決定論と曖昧性解消を重視するのに対し、エージェントエンジニアリングは本質的に確率論的であるため、エンジニアは非線形プロセスと自然言語入力を処理するために LLM（ローカルレベルモデル）を「信頼」することを学ぶ必要があることにあると考えています。彼は、この考え方の転換の難しさを 5 つの主要な課題を通して分析し、エンジニアがこのパラダイムに適応するための実践的な洞察を提供します。 重要なポイント：決定論から確率論へのパラダイムシフト。従来のソフトウェア開発では、予測可能性、すなわち固定入力、決定論的な出力、例外処理によるエラー分離が重視されていました。これとは対照的に、インテリジェントエージェントはLLMを「頭脳」として活用し、自然言語による意思決定を行い、複数ターンのインタラクション、分岐、適応を可能にします。しかし、上級エンジニアは「不確実性をコードで排除する」という本能を持ち、皮肉にもそれがインテリジェントエージェントの潜在能力を阻害しています。シュミット氏は、若手エンジニアは不確実性をより直感的に受け入れ、実用的なプロトタイプをより早く作成できる傾向がある一方、上級エンジニアは長年培ってきた習慣を克服する必要があると指摘しています。 5つの主要な課題は、従来のエンジニアリング手法とエージェント開発の間に存在する5つの矛盾点を概説しています。それぞれの課題には説明と事例が添えられており、より柔軟なアプローチへの移行方法を強調しています。 1. テキストは新しい状態 従来のシステムでは、状態を表すために構造化データ（「is_approved: true/false」のようなブール値など）を使用することで、離散性と予測可能性を確保しています。しかし、現実世界の意図は、ユーザーからのフィードバック「このプランは良さそうですが、米国市場に焦点を当ててください」のように、自然言語のニュアンスの中に隠れていることがよくあります。システムにバイナリ構造を強制すると、こうしたニュアンスが失われ、エージェントが動的に応答できなくなります。 洞察：元のテキストを状態として保存し、LLMが文脈に沿って解釈できるようにします。例えば、「天気は摂氏を好みますが、料理は華氏を使います」といったユーザーの好みを、単純なブール値ではなく保存します。これにより、エンジニアは「構造重視」から「意味の柔軟性」へとシフトする必要があります。 2. 管理権の譲渡 マイクロサービスのような従来のアーキテクチャは、プロセス制御のために固定ルートとAPIエンドポイントに依存しています。しかし、エージェントには自然言語のエントリポイントが1つしかなく、LLMはツールとコンテキストに基づいて次のステップ（ループ、バックトラック、リダイレクトなど）を決定します。例えば、「登録解除」のインテントは、「エージェントを維持するための割引を提供する」というネゴシエーションを受ける可能性があります。これらのプロセスをハードコーディングすることは、エージェントの適応性を阻害します。 洞察：LLMに制御フローの処理を任せ、そのコンテキスト全体の理解を活用しましょう。エンジニアは、すべての分岐を事前に設定するのではなく、この「非線形ナビゲーション」をサポートするシステムを設計する必要があります。 3. エラーは単なる入力です。 従来のコードでは、エラー（変数の欠落など）は例外をトリガーし、クラッシュや再試行につながります。しかし、エージェントの実行は毎回時間とリソースを消費するため、完全な失敗は許容されません。著者らは、エラーを新たな入力として扱い、エージェントにフィードバックすることで自己修復を可能にする必要があることを強調しています。 洞察：エラーを分離するのではなく、LLMにループバックして回復する、回復力のあるメカニズムを構築します。これは確率論的な考え方を反映しています。つまり、失敗は終わりではなく、反復の機会なのです。 4. ユニットテストから評価へ ユニットテストは、決定論的な出力に適したバイナリアサーション（合格/不合格）に依存しています。しかし、エージェントの出力は確率的です。例えば、「このメールを要約する」というテストは、無数の有効なバリエーションを生成する可能性があります。LLMをシミュレートするテストも、実装の詳細のみを検証し、全体的な動作は検証しません。 洞察：信頼性（成功率、例えば45/50パスなど）、品質（LLMを用いて有用性と正確性を評価する）、そして追跡（中間ステップの確認、例えばナレッジベースを参照したかどうかなど）を含む「評価」へとシフトしましょう。目標は100%の確実性ではなく、高い信頼度で成功する可能性です。 5. エージェントは進化しますが、API は進化しません。 APIは、人間のユーザーが文脈を推測できるという前提で設計されていますが、インテリジェントエージェントは「文字どおりに解釈する」ため、get_user(id) の「email」がUUIDと誤って解釈されると、誤った応答が返される可能性があります。APIの曖昧さは、LLMの限界をさらに増幅させます。 インサイト：詳細なセマンティック型（delete_item_by_uuid(uuid: str) など）とドキュメント文字列を使用して、「確実な」APIを設計します。インテリジェントエージェントはAPIの変更に即座に適応できるため、従来のコードよりも柔軟性が高まります。 解決策と影響 シュミット氏はエンジニアリングの原則を完全に放棄することを提唱するのではなく、「信頼しつつも検証する」というバランスを追求しています。つまり、確率的な管理を評価・追跡することで、回復力のあるシステムを構築するということです。同時に、エージェントは万能ではないことを認識しており、単純な線形タスクはエージェントよりもワークフローに適しています。例えば、ユーザーフィードバックのテキスト状態を保持すること、エラー駆動型のリカバリループを可能にすること、評価を用いてエージェントのパフォーマンスを定量化すること（例：成功率90%、品質スコア4.5/5）などが挙げられます。 ブログアドレス:
