シニアエンジニアが AI エージェント構築に苦戦する理由 — Google DeepMind

シニアエンジニアが AI エージェント構築で苦戦する理由：5 つのパラダイムシフトと新マインドセット

Google DeepMind のエンジニア、フィリップ氏は、なぜ熟練したシニアエンジニアであっても AI エージェントの構築に苦戦するのかを解説しています。その核心は、従来の「決定論的」なソフトウェア開発手法から、「確率的」なアプローチへの根本的な転換が必要だからです。

単なるコードの延長線上ではなく、テキストが状態管理となり、エラーをプロセスの一部として扱い、モデルとの信頼関係を築く新しい設計思想が求められています。本記事では、動画で指摘された 5 つのパラダイムシフトと、実務に即した重要な洞察を整理します。

1. テキストが新たな「状態管理」の役割を果たす

従来のソフトウェア開発では、システムの状態は明確なデータ構造、ブール値、フラグによって管理されていました。しかし、AI エージェントの世界では、LLM（大規模言語モデル）が意味理解に基づき、文脈（コンテキスト）そのものを状態として扱います。

「従来であれば『却下』となり、フォローアップが必要とされるのが一般的でした。しかし現在、LLM は意味を理解できるようになり、柔軟な対話が可能になります。」

例えば、市場調査の依頼に対し、従来のシステムでは「計画が不完全」として却下し、ユーザーに追加情報を求めてから再提出を促すフローしかありませんでした。一方、AI エージェントは文脈を理解した上で、「米国市場には焦点を当てたいが、カリフォルニアは除外したい」といった追加条件を柔軟に受け入れ、計画を調整しながら進めることができます。

同様に、ユーザーの好み（摂氏か華氏か）も、固定されたプロファイルフラグではなく、会話の流れや文脈から動的に読み取る必要があります。画像、動画、音声を含め、明確な構造化データにマッピングできない情報が、新たな状態管理の中心となっています。

2. 「制御」から「委任」への役割転換

開発者の役割が、「詳細な手順を指定する交通整理役」から、「目標のみを定義して実行方法を任せる配車係」へとシフトする必要があります。従来のソフトウェアは、信号や速度制限、通行可能な道路を完全に制御し、車の運転方法まで細かく指示していました。

しかし、AI エージェントには、以下のような委任が必要です。

「『ロンドンに行きたい』という目標だけを与えます。電車か飛行機か、車か、あるいは地下鉄を使うかは、エージェントに任せるのです。」

顧客サポートの例で言えば、ユーザーが「購読をキャンセルしたい」と言った際、従来のシステムは「離脱意向」と分類し、事前に定義されたワークフロー（販売を試みるか、キャンセル手続きへ進むか）に従って動きました。しかし、AI エージェントなら、文脈を理解して「もしかしたら別のプランの方がお得かもしれませんね」と提案したり、ユーザーの心情に寄り添った動的な対応を試みたりできます。

このように、モデルが意味を理解し、独自の判断で最適な解決策を提示できる環境こそが、真の委任です。純粋な決定論的な環境では動作しないため、開発者はモデルへの信頼と、制御の放棄というバランス感覚が求められます。

3. エラーは「入力」として扱う設計へ

AI エージェントの開発において最も重要なマインドセットの一つが、「エラーをプロセスの失敗として扱わず、単なる入力情報として扱う」ことです。従来のソフトウェアでは、HTTP リクエストや関数呼び出しでエラーが発生すれば、リトライするか、あるいは処理を中断してログを残すのが一般的でした。

しかし、AI エージェントは実行に数分を要することが多く、途中で失敗した場合に最初からやり直すと、膨大な計算リソースを浪費し、失われたコンテキストを取り戻せなくなるリスクがあります。

「エラーが発生しても、全体をリセットせず、そのエラー情報をモデルに入力としてフィードバックし、代替案で継続させる設計が必要です。」

Go 言語などでは関数呼び出しがエラーにも値にもなり得ますが、エージェントにおいても同様に扱うべきです。失敗した事実を「次のステップの文脈」としてモデルに伝え、回避策や追加のチェックを組み込みながらフローを進めることが重要です。

4. 「単体テスト」から「評価（Evals）」へ基準を変える

非確実な AI エージェントでは、「同じ入力なら必ず同じ出力が得られる」という前提が成り立ちません。そのため、従来のコード検証用の「単体テスト」や「統合テスト」に代わり、成功率や出力の質を定量的・定性的に測る「評価（Evals）」が不可欠となります。

「10 回中 1 回しか機能しないエージェントを本番環境に導入する価値はありません。頻繁に動作するかをテストし、信頼性を確認する必要があります。」

評価では、LLM を判事として使ったり、人間の専門家によるレビューを行ったりして、出力の質やプロセスの妥当性を判断します。例えば、あるユーザーには 4 つのリサーチステップが必要だが、別のユーザーには不要であるといった文脈に応じた判断がなされるかどうかが問われます。

最終的な成果（リポートの質や顧客満足度）こそが成功の指標であり、トークン消費量などのコストは二次的な要素となります。このように、確率的な挙動を統計的に評価する仕組みがなければ、実用化は困難です。

5. エージェント向けに API を自己完結的に設計する

開発者が長年の経験で得た「暗黙知」や文脈に依存しないよう、API やツール定義はエージェント自身のために完全に自己完結的なものにする必要があります。従来の API ドキュメントは、開発者の背景知識を前提とした記述が多いですが、AI エージェントはコードを見ず、コンテキストも持ちません。

「『アイテム削除』というメソッド名だけでは、ID の意味や何が起こるかは把握できません。関数の役割や挙動を明確にしたドキュメント文字列を持つ必要があります。」

エージェントがツールを使用する際、確認できるのはスキーマとドキュメント文字列だけです。したがって、「この ID はユーザーの固有識別子であり、削除すると復元不可です」といった具体的な意味を、人間ではなく機械（モデル）が理解できる形で定義する必要があります。

まとめ：信頼と検証、そして「使い捨て」のマインドセット

AI エージェント開発の本質は、モデルとの対立をやめ、信頼を与えつつも厳格に検証するバランスにあります。完璧なモデルなど存在しないため、エラーを許容し、失敗から回復できる設計（リカバリー）が不可欠です。

「苦い教訓として学んでいるのは、ソフトウェアは使い捨てであるということです。より良いモデルやエージェントで何度も再構築することになります。」

状況は常に変化します。一度作ったシステムを永遠に維持するのではなく、新しい技術や知見を取り入れて再構築していく柔軟なマインドセットこそが、AI エージェント時代を生き抜く鍵となります。