AIエージェントエンジニアリングの5つの落とし穴

従来のソフトウェアエンジニアリング（決定論的、厳格な制御）の習慣が、AIエージェント開発（確率論的、柔軟性重視）ではむしろ足かせになるという内容。

• Hugging FaceのPhilipp Schmidが指摘するところによれば、シニア開発者ほどLLMの不確実性を「コードで排除」しようとして、ジュニアより遅くなる。
• たとえ: 管制官（従来型）→ディスパッチャー（エージェント）への役割転換が必要。

1. テキストが新たな状態（State）
   • 落とし穴: 自然言語入力を構造化データ（例: true/false）に無理やり変換すると、文脈を失う。
   • 解決: フィードバック（例: 「承認、米国市場に集中」）をテキストのまま保持し、動的に調整できるようにする。

2. 制御権を手放す
   • 落とし穴: フローをハードコーディング（例: サブスクリプション解約ルート）すると、非線形な相互作用に対応できない。
   • 解決: エージェント（LLM）が文脈ベースで意図を判断できるよう信頼する。

3. エラーはただの入力
   • 落とし穴: エラー発生時にプログラムを停止する（従来方式）と、高コストな実行が無駄になる。
   • 解決: エラーをフィードバックとして与え、エージェントが自己回復を試みられるようにする。

4. ユニットテストからEvalへ
   • 落とし穴: 二値テスト（TDD）を適用しても、確率的システムでは意味が薄い（有効な回答が無限にある）。
   • 解決: 信頼性（Pass@k）、品質（LLM Judge）、追跡（Eval）で変動性を管理する。

5. エージェントは進化するが、APIはそうではない
   • 落とし穴: 人間中心のAPI（暗黙の文脈）を使うと、エージェントにハルシネーションが生じる。
   • 解決: 詳細なセマンティックタイピング（例: user_email_address）とdocstringで明確化する。エージェントはツールの変化に適応できる。

結論

確率性を受け入れ、Evalと自己修正で管理する。「信頼しつつ検証する」――厳格さではなく、弾力的なシステム構築が鍵。 （原文出典: Philipp Schmidの「Why (Senior) Engineers Struggle to Build AI Agents」）