最新AIエージェント開発の最前線：Google DeepMind Philipp Schmidtが語る実践的課題とGeminiの可能性

AIエージェント開発は、現代のテクノロジー領域で最もエキサイティングかつ挑戦的なフロンティアの一つです。単なるチャットボットの域を超え、自律的に目標を設定し、ツールを使いこなし、学習・適応しながら複雑なタスクを遂行するAIエージェントの可能性は無限大です。しかし、その開発プロセスには、モデル選定から評価、プロダクションへの展開に至るまで、数々の実践的な課題が横たわっています。

今回、私たちは「The Agent Factory」ポッドキャストのエピソード5で、Google DeepMindのデベロッパーリレーションズで活躍し、AIおよびエージェント開発に関する人気技術ブログの著者でもあるPhilipp Schmidt氏を迎え、これらの「最も難しい質問」に真正面から切り込みました。本記事では、その議論の核心を深く掘り下げ、読者の皆様がAIエージェントの重要性、具体的な機能、ビジネスへの影響、そして将来性を包括的に理解できるよう、詳細かつ説得力のある形で解説します。

AIの進化が加速する中、プロダクションレディなエージェントを構築するための実践的な知見とプロのヒントを、Philipp Schmidt氏の専門的な洞察と共にお届けします。

1. Geminiが拓くエージェント開発の地平：なぜGoogle Geminiが選ばれるのか

AIエージェント開発の基盤となる大規模言語モデル（LLM）の選定は、プロジェクトの成否を左右する重要な決定です。Philipp Schmidt氏は、Google Geminiが今日の基盤モデル空間において依然として「非常にユニーク」であると強調し、その卓越した能力を次のように解説しています。

1.1. 圧倒的なコンテキストウィンドウとマルチモーダリティ

Geminiの際立った特徴の一つは、その100万トークンに及ぶ大規模なコンテキストウィンドウです。これは、モデルが一度に処理できる情報の量が膨大であることを意味します。競合モデルも追随しつつありますが、この容量は、複雑な顧客サポートエージェントなど、ユーザー固有のタスクを解決するために必要な詳細な情報（過去の会話履歴、関連ドキュメント、ユーザープロファイルなど）を全てモデルに提供できることを可能にします。モデルがより多くの情報を参照できることで、より正確でパーソナライズされた応答や行動を生成する能力が向上します。

さらに、Geminiは強力なマルチモーダリティサポートを誇ります。テキスト入力だけでなく、画像、音声、動画といった多様な形式の情報を入力として受け入れ、またマルチモーダルな出力を生成できます。これは、私たちが生きる「現実世界」がテキストのみで構成されているわけではないというPhilipp氏の指摘に深く関連します。例えば、カメラからの映像やマイクからの音声情報に基づいて状況を理解し、適切に行動するエージェントを構築する上で、マルチモーダリティは不可欠な機能です。これは、単なるチャットウィンドウでのやり取りを超えた、真に実用的なエージェントアプリケーションの可能性を大きく広げます。

1.2. 高度な推論能力と「思考時間」の価値

Gemini、特にGemini 2.5 Pro、2.5 Flash、2.5 Lightといったモデルは、その**優れた推論能力と「思考時間」**によって特徴づけられます。モデルがより多くのトークンを生成する、つまり「考える」時間を長く持つことで、特定のユースケースを解決するためにより深く計算し、理解することが可能になります。これは、複雑な意思決定を伴うエージェントにおいて特に重要です。例えば、単一の質問に対する直接的な回答だけでなく、複数の情報を統合し、論理的なステップを踏んで問題を解決するようなシナリオで、Geminiの推論能力は真価を発揮します。

この「思考時間」の概念は、単に速度が遅いという意味ではなく、モデルが与えられた問題に対してより多くの内部処理サイクルを費やすことで、より高品質で整合性の取れた結果を導き出す能力を指します。大規模なコンテキストウィンドウと組み合わせることで、モデルはより豊富な情報に基づいて、より洗練された推論を行うことが可能になります。

1.3. 関数呼び出しとツール利用：外部環境との連携

AIエージェントの核心機能の一つは、外部ツールを利用して環境とインタラクトする能力です。Gemini APIが提供する**関数呼び出し（Function Calling）やツール利用（Tool Use）**の機能は、この能力を強力にサポートします。これは、モデルが単に応答を生成するだけでなく、構造化された出力（例: JSON形式）を生成し、それをコード実行に利用できることを意味します。

例えば、ユーザーが「明日の天気は？」と尋ねた場合、モデルは天気予報APIを呼び出すための構造化されたJSONを生成し、それをアプリケーション側で実行して実際の天気情報を取得できます。Philipp氏は、特にGoogle Searchのような組み込みツールとの連携を強調しています。エージェントがリアルタイムの情報を取得したり、自身の知識ベースにない事実を確認したりする際に、Google Searchツールを自律的に呼び出すことで、その能力は飛躍的に向上します。これにより、エージェントは「チャットウィンドウに座っている」状態を超え、現実世界の情報にアクセスし、それに基づいて行動できるようになります。

1.4. プロンプトエンジニアリングからコンテキストエンジニアリングへ

かつては「プロンプトエンジニアリング」と呼ばれた概念が、Geminiのような先進的なモデルの登場により、**「コンテキストエンジニアリング」**へと進化しているとPhilipp氏は指摘します。これは単なる用語の変更ではなく、モデルに与える情報の範囲と質が大きく変化したことを表しています。

コンテキストエンジニアリングの目的は、モデルに**「適切な情報、適切なタイミングで、適切なツールと共に」**提供し、ユーザーのタスクや目標を解決させることです。大規模なコンテキストウィンドウとマルチモーダリティにより、私たちはもはや短いテキストプロンプトに情報を圧縮する必要がありません。ユーザーに関する詳細、過去の会話履歴、関連ドキュメント、画像、動画、音声など、より豊かで多様な情報をコンテキストとして提供できます。これにより、モデルはより包括的な理解に基づき、高度なタスクを遂行できるようになります。

Geminiは、これらの機能群を通じて、開発者が単なる会話型AIではなく、真に現実世界で機能する「エージェント」を構築するための強固な基盤を提供します。そのアクセスしやすさと強力な機能は、AIエージェント開発の新たな標準を確立しつつあると言えるでしょう。

2. モデル選択の戦略：APIかオープンソースか？ – 賢い選択肢と中小モデルの再評価

AIエージェント開発において、どのLLMを選択するかは、プロジェクトの性質、リソース、そして目標によって大きく異なります。Philipp Schmidt氏は、Google GeminiのようなAPI提供型モデルと、Gemmaのようなオープンモデルのそれぞれの利点と最適な利用シナリオについて、実践的なアドバイスを提供します。

2.1. POC開発におけるGemini APIの優位性

Philipp氏が開発者に対して常に推奨するのは、「最も簡単なパス」で概念実証（Proof of Concept: POC）を検証することです。この観点から、GeminiのようなAPI提供型モデルは圧倒的な優位性を持っています。

手軽なアクセス: AI Studioのようなプラットフォームを通じて、APIキーを30秒以内に生成し、すぐにリクエストを送信できる手軽さは、開発の初期段階で非常に重要です。
多様な開発環境対応: JavaScript, Python, Go, あるいは単純なBashやHTTPリクエストといった多様な方法でGemini APIにアクセスできるため、開発者は慣れ親しんだ環境で迅速に作業を開始できます。
迅速なプロトタイピング: APIアクセスと豊富な機能により、数時間から数日でエージェントのPOCを構築することが可能です。これは、アイデアの有効性をチームやリーダーシップに提示し、フィードバックを得る上で極めて効果的です。 Philipp氏は「4、5年前にはなかった能力」と述べ、現代の開発者がいかに迅速にアイデアを形にできるようになったかを強調しています。

API利用の初期コストは通常、オープンモデルを自己ホストする場合のGPUやTPUといった計算リソースの先行投資よりもはるかに低く抑えられます。これは、初期段階でのリスクを最小限に抑えつつ、アイデアを素早く検証したいスタートアップや開発者にとって大きなメリットとなります。

2.2. オープンモデルが適しているケース

APIモデルが迅速なPOCに適している一方で、オープンモデルには独自のメリットがあり、特定のシナリオで優れた選択肢となります。

制約された環境: ローカルデバイスや独自のオンプレミス環境でモデルを実行する必要がある場合、オープンモデルは唯一の選択肢となることがあります。例えば、データプライバシー規制が厳しく、データを外部APIに送信できないようなケースです。
高度なカスタマイズとファインチューニング: 特定のドメインやタスクに特化した性能を追求する場合、オープンモデルはファインチューニングを通じて、その能力を最大限に引き出すことができます。モデルのアーキテクチャや学習プロセスに深く関与したい開発者にとって、これは大きな魅力です。
コスト効率の最適化（大規模運用時）: POC段階ではAPIが有利でも、エージェントを大規模に運用する際には、オープンモデルを最適化されたハードウェアで実行する方が、長期的に見てコスト効率が良い場合があります。

ただし、オープンモデルの運用には、計算リソースの調達、モデルのデプロイ、管理、そしてパフォーマンスチューニングといった「異なる課題」が伴います。

2.3. 中小モデルの台頭とその可能性：Gemma 3 270Mが示す未来

AIモデルの進化は、単にモデルサイズが大きくなる方向だけではありません。Philipp氏は、GoogleがリリースしたGemma 3 270Mのような超小型で高効率なモデルに大きな期待を寄せています。このモデルは、わずか2億7000万のパラメータ数でありながら、以前の世代の大型モデルと同等、あるいはそれ以上の能力を発揮する可能性があります。

エッジデバイスへの展開: Gemma 3 270Mのようなモデルは、消費リソースが極めて少なく（約500MBのメモリで動作）、スマートフォン、Raspberry Pi、スマートホームアシスタントといったエッジデバイス上で動作可能です。これにより、AIの能力がクラウドからユーザーの身近なデバイスへと広がり、新たなユースケースが生まれることが期待されます。
特化型ユースケース: Gemmaのような小型モデルは、汎用的な大規模モデルには劣るものの、特定のタスク（情報検索、構造化出力の生成、テキスト分類など）に対してファインチューニングを行うことで、非常に高い性能を発揮できます。Philipp氏は、自身のスマートホームアシスタントが「AIモデルができることに比べて非常に鈍い」と感じており、こうした小型モデルがデバイスの知能を飛躍的に向上させると期待しています。
モデルサイズのトレンド: AIの歴史は、小型化→大型化→小型化（高性能化）という「トレンド」を繰り返してきたとPhilipp氏は指摘します。より良く、より速く、より小型なオープンモデルが登場し、同時に、より良く、より大型なモデルも進化し続けています。Gemma 3 270Mは、GoogleがかつてリリースしMLエコシステムに大きな影響を与えたBERTの基本モデル（約1億1000万パラメータ）と近いサイズでありながら、はるかに多様な機能を提供します。

Philipp氏は、自身のMacBook ProでGemma 3 12B（中規模モデル）を動作させ、インターネット接続がないフライト中にも「世界のあらゆる知識について質問できる」ことに驚きを感じています。これは、小型モデルがいかに実用的で強力なツールになり得るかを示しています。

最終的に、モデル選択は「アイデアを検証する最も速い方法」を追求すべきだというのがPhilipp氏の哲学です。APIのアクセシビリティから始め、必要に応じてオープンモデルやファインチューニングへと移行するハイブリッドなアプローチが、現代のエージェント開発における賢い戦略と言えるでしょう。

3. 複雑なエージェントを構築する：フレームワークとその哲学

AIエージェント開発の複雑さが増すにつれて、その構築を支援するフレームワークの重要性が高まっています。Philipp Schmidt氏は、LangChain (LangGraph), LlamaIndex, CrewAI, Pydantic AIといった主要なエージェントフレームワークについて言及し、それぞれの特徴と開発者がフレームワークを選択する際の考慮事項を解説しました。

3.1. 主要エージェントフレームワークの概要

LangChain (LangGraph): AIジャーニーをLangChainで始めた開発者も多く、LangGraphは構成可能なエージェント構築のためのフレームワークとして進化しています。エージェントの各ステップをPython関数として定義し、条件に基づいて接続することで、複雑なワークフローを構築できます。
CrewAI: マルチエージェントアーキテクチャの先駆者として知られ、複数のエージェントが連携してタスクを遂行するシステム構築に強みがあります。
Pydantic AI: Pydanticのデータ構造モデルを統合することで、構造化データとの連携を非常にスムーズに行えるフレームワークです。モデル出力の信頼性と堅牢性を高めるのに役立ちます。
LlamaIndex: ドキュメント処理とRAG（Retrieval Augmented Generation）に特化したフレームワークとして強力な機能を提供します。エンタープライズ規模のドキュメントパイプライン構築において多くのリソースと成功事例があります。

これらのフレームワークはそれぞれ異なる設計思想と得意分野を持っており、開発者は自身のユースケースと開発スタイルに合わせて最適なものを選択できます。Google DeepMindも、これらを含む20以上のスタートアップやオープンソースライブラリと連携し、Geminiのアクセシビリティ向上に努めているとPhilipp氏は語ります。

3.2. フレームワークを採用するメリット

なぜエージェント開発においてフレームワークを使用すべきなのでしょうか？Philipp氏は以下のメリットを挙げます。

プロトタイピングの加速: フレームワークは、エージェントのコアとなるコンポーネント（ツール利用、記憶管理、評価など）を抽象化し、再利用可能な形で提供します。これにより、開発者はゼロからすべてを構築する手間を省き、迅速にアイデアをプロトタイプ化できます。
コミュニティとサポート: 人気のあるフレームワークには活発なコミュニティが存在します。共通の課題に直面した場合、コミュニティの例、ドキュメント、そして他の開発者からのサポートを得やすいという大きな利点があります。これは、伝統的なソフトウェア開発におけるライブラリ利用のメリットと共通しています。
運用上の要件への対応: エージェントをプロダクション環境で動作させるには、単に機能するだけでなく、モニタリング、オブザーバビリティ、評価といった運用上の要件を満たす必要があります。多くのフレームワークは、これらの機能を組み込むための構造やツールを提供しており、開発者がプロダクションレディなエージェントを構築する上で大きな助けとなります。Philipp氏は「エージェントは単なるwhileループではない」と述べ、これらの非機能要件の重要性を強調しています。

3.3. フレームワーク選択の基準：個人の好みとユースケース

「完璧なフレームワークは存在しない」とPhilipp氏は明言します。フレームワークの選択は、最終的には個人の好みや設計原則、そしてプロジェクトの具体的なユースケースに依存します。

個人のコーディングスタイル: 開発者は、自身のコーディングスタイルや、慣れ親しんだパラダイムに合致するフレームワークを選ぶことで、生産性を最大化できます。
企業の開発文化: チームや企業全体で特定のフレームワークや設計原則が採用されている場合、それに合わせることが連携の効率化につながります。
ユースケースの特性:
- ドキュメント処理: LlamaIndexは、RAGシステムや企業内の大量文書処理パイプラインをスケーリングする上で非常に強力です。
- マルチエージェント連携: CrewAIは、複数の専門エージェントが協調してタスクを遂行するシナリオにおいて、豊富な例とアイデアを提供します。
- 構成可能性と制御: LangGraphは、エージェントの実行フローをグラフとして視覚的に設計し、細かい制御を行いたい場合に適しています。

このように、エージェントフレームワークの選択は、技術的な側面だけでなく、開発者の快適性やプロジェクトの目標に合わせた総合的な判断が求められます。オープンソースエコシステムが多様な選択肢を提供していることは、開発者にとって大きな恩恵であるとPhilipp氏は締めくくっています。

4. プロダクションレディなエージェントへの道：開発者が直面する「最も難しい質問」

AIエージェントのプロトタイプを構築することは、驚くほど簡単かつ魅力的な体験です。しかし、それを実世界のプロダクション環境で安定して動作させることは、伝統的なソフトウェア開発とは異なる、数々の困難な課題を伴います。Philipp Schmidt氏は、これらの「最も難しい質問」と、それらにどう対処すべきかについて深く掘り下げました。

4.1. 伝統的ソフトウェア開発とのギャップ：非決定性と評価の難しさ

Philipp氏は、「Hello World」の魔法とプロダクション運用の現実との間に大きなギャップがあると指摘します。伝統的なWebサービスの「Ping-Pong」リクエストが感動的でなかったのに対し、エージェントは30分でチャットボットがドキュメントと会話したり、Google検索したり、音声でやり取りしたりできるという「魔法」を提供します。しかし、この魔法には代償が伴います。

非決定性（Nondeterminism）: LLMは本質的に非決定性です。Philipp氏が「たとえGeminiにフランスの首都を100万回尋ねても、必ずしもパリと答えるとは限らない」という極端な例を挙げたように、同じ入力に対して毎回全く同じ出力を保証することはできません。これは、伝統的なソフトウェア開発のテストと品質保証の前提を根底から覆します。
評価の難しさ: エージェントの性能をどのように測定し、評価するのかは極めて難しい問題です。手動でのテスト（「トップ10〜20のプロンプトリスト」）では、エージェントの複雑な挙動や潜在的な失敗モードを網羅することはできません。評価は、単に「正しい答えを返したか」だけでなく、安全性、関連性、有用性、トーンなど、多角的な側面から行われる必要があります。

4.2. オブザーバビリティ、データドリフト、そしてユーザー期待の変化

エージェント開発は、これらの基本的な課題に加え、さらに複雑な問題に直面します。

オブザーバビリティとモニタリング: エージェントの内部的な意思決定プロセスやツールの利用状況、生成された思考過程などを可視化する「オブザーバビリティ」は、デバッグ、最適化、そして予期せぬ挙動の特定に不可欠です。伝統的なログ記録だけでは不十分であり、エージェント固有のトレーシングや監視メカニズムが求められます。
データドリフト: エージェントがインタラクトする環境や入力データは時間とともに変化します。この「データドリフト」は、エージェントの性能劣化や予期せぬ振る舞いを引き起こす可能性があります。継続的な監視と再学習のプロセスが必要です。
ユーザー期待値の変化: Philipp氏は、ユーザーがAIとインタラクトする中で、その期待値が急速に変化することを強調します。最初は簡単なエッセイの生成に感動していたユーザーも、すぐに「ガンを治せ」といった高度な要求をするようになります。エージェントは、この変化する期待に常に対応し、進化し続ける必要があります。これは、プロダクトの成功において非常に重要な要素です。

これらの課題に対処するため、Philipp氏は「オブザーバビリティ、モニタリング、評価が、優れたエージェントフレームワークやアプリケーションを構築するための基盤となる」と断言しています。どのフレームワークやモデルを選ぶかよりも、これらの運用上の側面がより重要であるという示唆は、開発者にとって重い意味を持ちます。

4.3. 「Ship, Iterate, Ship, Iterate」：リスクレベルに応じたデプロイ戦略

これらの課題に直面しつつも、Philipp氏の哲学は「Ship, Iterate, Ship, Iterate（リリースして、改善して、リリースして、改善する）」です。現実のユーザーからのフィードバックに勝るものはないという考えに基づいています。

Dogfooding（ドッグフーディング）: 開発者自身がエージェントの最大のユーザーとなることの重要性。Philipp氏自身も、日々の情報収集やSNSリサーチを自動化するための「ニュースレターエージェント」など、多くの小型エージェントを個人的に利用しています。これにより、エージェントが実際にどのように機能し、どのような課題があるかを深く理解できます。
段階的リリースとシャドウモード: 全てのプロダクトが低リスクであるわけではありません。Philipp氏は、顧客サポートエージェントのような高リスクなシナリオでは、「最初のプロトタイプをプロダクションに直接投入すべきではない」と警告します。しかし、それでも段階的にフィードバックを得る方法はあります。
- 低リスクシナリオ: 小規模なユーザーグループでのテスト、限定的な機能でのリリース。
- 高リスクシナリオ: 例えば、顧客インタラクションの1%をエージェントにシャドウ（シミュレーション）させ、人間の対応と比較して性能を評価する。
LLMによるユーザーシミュレーション: 評価をスケールさせるための先進的なアプローチとして、別のLLMにユーザーをシミュレートさせ、エージェントと会話させる方法が挙げられます。これにより、多様なユースケースを網羅し、エージェントの脆弱性や予期せぬ挙動を効果的に「暴露」することができます。

エージェントは「生きているアーティファクト」であり、一度開発して終わりではありません。ユーザーの入力、期待、環境の変化に適応し、常に改善し続ける必要があります。この継続的な改善サイクルこそが、プロダクションレディなエージェントを成功させる鍵となります。

5. 実践的アプローチ：Deep Research Agent開発の舞台裏

AIエージェントの理論と課題を理解した上で、Google DeepMindチームが構築した「Deep Research Agent」のクイックスタート例は、実践的な開発手法の優れたショーケースです。Philipp Schmidt氏は、このエージェントの開発プロセス、設計思想、そしてLangGraphの活用方法について詳細を語りました。

5.1. コンセプトと設計：人間のリサーチプロセスを模倣する

Deep Research Agentの構築は、Philipp氏自身の「トピックを深くリサーチするプロセス」を模倣することから始まりました。

初期質問の設定: 「2025年の再生可能エネルギーの最新トレンドは？」のような初期の質問からスタート。
関連クエリの生成: 2024年のトレンド、関連企業、世界的な分布など、多数の小さな関連クエリを生成。
情報収集とスクラッチパッド: これらのクエリに基づいて情報を検索し、結果を「スクラッチパッド」にまとめる。

この手動プロセスをエージェントとして自動化するために、Philipp氏はLangGraphを用いたグラフ構造を設計しました。エージェントの各ステップはシンプルなPython関数として定義され、条件に基づいて相互に接続されます。これにより、動的で柔軟なワークフローを実現できます。

5.2. LangGraphの活用とエージェントパターン

Deep Research Agentの核心は、LangGraphによって実現された構成可能性と制御フローにあります。

グラフベースの制御: LangGraphでは、エージェントの実行パスをノードとエッジを持つグラフとして定義します。各ノードは特定の機能を持ち、その出力に基づいて次のノードへの遷移が決定されます。
条件付きフロー: 例えば、エージェントが生成したレポートをLLMが評価し、「さらにリサーチが必要」と判断した場合はリサーチステップに戻り、「十分」と判断した場合は最終回答を生成するといった条件分岐が可能です。

このエージェントは、以下の主要なエージェントパターンを組み合わせています。

ツール利用（Tool Use）パターン: Google Searchとの統合により、外部のリアルタイム情報にアクセスし、リサーチを行うことができます。これは、エージェントが自身の内部知識だけでなく、外部環境から情報を取得する上で不可欠です。
自己反省（Self-reflection）パターン: LLMが自身の出力を批評し、改善点を特定するメカニズムです。Deep Research Agentでは、生成されたリサーチレポートをGemini自身が初期の質問と計画に基づいて評価し、さらなるリサーチが必要かどうかを判断します。このループ構造により、エージェントはより高品質な結果を自律的に追求できます。

この自己反省ループは、エージェントが何回リサーチを繰り返すべきかを決定する点で、伝統的な固定されたワークフロー（例: 4つのクエリを生成→情報取得→レポート作成）とは異なります。もちろん、無限ループを防ぐために、開発者が最大反復回数などのガードレールを設定することは非常に重要です。

5.3. コンテキストエンジニアリングの実践：詳細と進化

Deep Research Agentの開発は、コンテキストエンジニアリングの具体的な適用例でもあります。

大規模コンテキストの活用: Geminiの大きなコンテキストウィンドウを活用し、関連するすべてのリサーチ結果をサマリーステップに含めることで、モデルが包括的な理解に基づいてレポートを作成できるようにします。
指示とルールの一貫性: プロンプトの冒頭と末尾に指示を繰り返すことで、モデルがタスクの目標とルールを確実に理解できるように強調します。
構造化出力の利用: ユーザーの初期リクエストに基づいて複数の検索クエリを生成する際に、構造化出力（JSON形式）を利用します。これにより、生成されたクエリを後続のツール実行ステップに渡すことが容易になります。
リアルタイム情報の考慮: モデルは現在の「日付」を知らないため、プロンプトに明示的に現在の日付を含めることが重要です。これにより、「2020年の情報」のような古い情報ではなく、最新のトレンドをリサーチできます。
イテレーションと改善: 開発中に、「モデルが引用や出典を正しく提供しない」といった問題が発見されることがあります。これに対し、プロンプトに具体的なルールや例を追加することで、モデルの出力品質を向上させます。

Philipp氏は、このクイックスタート例が「プロダクションに投入するものではない」と強調しつつも、開発者がエージェントの構築方法、異なるビルディングブロックの活用方法、そして自身のユースケースへの応用方法について「インスピレーションを得る」ためのものだと述べています。

5.4. メモリの拡張可能性

Deep Research Agentの現在のバージョンではメモリは使用されていませんが、Philipp氏は、メモリの追加が非常に興味深い拡張機能となると言及しています。

永続的な情報の追加: メモリは、LLMやエージェントとの「ステートレス」な会話に、外部の永続的な情報を追加する機会を提供します。例えば、ユーザーが好む出力スタイル（短い箇条書き、200語以内など）や過去のインタラクション履歴を記憶させることで、エージェントのパーソナライゼーションを深めることができます。
実装の難しさ: メモリシステムの実装は、「正しく行うのが非常に難しい」とPhilipp氏は指摘します。フィードバックループが間接的で、その効果を測定しにくいからです。ユーザーは改善された体験を享受するかもしれませんが、それがプロンプトの変更によるものか、モデルの能力向上によるものか、あるいはメモリによるものかを区別することは困難です。これは、メモリが評価とオブザーバビリティの側面をさらに複雑にする要因となります。

Deep Research Agentの事例は、AIエージェント開発が単なるコード記述以上の、深い設計思想、反復的な改善、そして人間のプロセスを模倣する創造性を必要とすることを示しています。

6. 開発者の新たな相棒：Google Gemini CLIの徹底解説

AIエージェントの進化は、開発者の日常業務に革命をもたらすツールを生み出しています。その最たる例が、GoogleがオープンソースでリリースしたGemini CLIです。Philipp Schmidt氏は、このコマンドラインインターフェース（CLI）がもたらす利点、Google内外での活用事例、そしてMCPサーバーやカスタムコマンドといった強力な機能について熱く語りました。

6.1. Gemini CLIの魅力：オープンソースと透明性

Philipp氏は、Gemini CLIの最大の魅力の一つが、そのオープンソース性にあると強調します。

透明性: 開発者は、Gemini CLIの内部動作を直接確認できます。システムプロンプト、利用されているツール、エージェントの思考プロセスなど、通常はブラックボックスになりがちな部分を詳細に検査できるため、モデルがなぜ特定のアクションをとるのか、なぜ特定の出力を生成するのかを深く理解できます。これは、エージェントのデバッグと信頼性向上に不可欠です。
拡張性: オープンソースであるため、コミュニティからのフィードバックやコード貢献が活発です。これにより、Gemini CLIは継続的に改善され、新たな機能やユースケースが迅速に追加されます。Philipp氏は、Gemini CLIが「最高のコーディングCLI」になることを願っていると述べています。
幅広い採用: Gemini CLIは、Google内部のエンジニアと外部のソフトウェア開発者の両方に広く利用されています。これにより、共通のツールを通じて知識と経験が共有され、製品の品質向上に貢献するというユニークなエコシステムが形成されています。Philipp氏は、社内ライブラリのバグ修正にGemini CLIが使われた事例を挙げ、その影響力を示しました。

6.2. ドキュメント更新の自動化：Google内部での画期的な活用

Philipp氏にとって、Gemini CLIの最も「祝福された」活用法の一つは、Google内部でのドキュメント更新作業の自動化です。

反復的でエラーが発生しやすいタスクの自動化: 新しいGeminiモデルがリリースされるたびに、APIドキュメントのコードスニペットのテスト、情報のレビュー、モデルIDの更新といった作業が発生します。これらの作業は非常に反復的で、人間の手作業ではミスが発生しやすいものです。
Gemini CLIによる解決: Philipp氏は、Gemini CLIに「やるべきこと」を指示し、既存のファイルを読み込ませ、モデルIDを自動的に更新するプロセスを構築しました。これにより、ドキュメント更新の効率が飛躍的に向上し、エラーのリスクが低減されました。
コードスニペットの検証: さらに高度な活用法として、Gemini CLIは自身の生成したコードスニペットを実行し、その正しさを検証する能力を持っています。これは、コードスニペットの信頼性を保証し、ドキュメントの品質を維持する上で極めて重要です。

6.3. MCPサーバー：安全かつ柔軟なコード実行環境の構築

Gemini CLIが生成したコードを実行する際、セキュリティと環境の分離は重要な課題となります。Philipp氏が構築したMCP（Multi-Code Execution Provider）サーバーは、この課題に対する洗練された解決策を提供します。

必要性:
- セキュリティ: 不明な、あるいは任意に生成されたコードをローカルマシンで直接実行することは、セキュリティ上の大きなリスクを伴います。
- 環境の一貫性: 開発者のローカル環境は、SDKバージョンや依存関係によって異なる可能性があります。再現性のあるコード実行には、クリーンで隔離された環境が必要です。
- 柔軟性: 特定の言語やライブラリがインストールされた環境でコードを実行したい場合があります。
Ephemeral環境の実現: MCPサーバーは、DockerやPodmanといったコンテナ技術を利用して、「一時的（Ephemeral）」なコード実行環境を動的に作成・破棄します。これにより、コードは他のシステムから完全に隔離された状態で実行され、セキュリティリスクが最小限に抑えられます。
実装とワークフロー: Philipp氏は、LLM Sandboxというオープンソースライブラリ（PodmanおよびDocker SDKを利用してコンテナを開始・停止し、コードを実行するPythonライブラリ）を活用し、MCPサーバーを構築しました。
1. Gemini CLIが実行したいコードを生成。
2. コードはMCPサーバーに渡される。
3. MCPサーバーは、Gemini SDKがインストールされたDockerコンテナを起動し、そのコンテナ内にPythonまたはNodeファイルを生成。
4. コンテナ内でコードを実行し、標準出力やエラーをキャプチャ。
5. 結果がGemini CLIに返され、モデルはエラーがあればコードの修正を自動的に試みる。
- 柔軟な設定: 自身の環境に合わせてDockerコンテナのカスタマイズ（例: 特定のSDKバージョンのインストール、APIキーの追加）が可能です。
デバッグと改善: コード実行エラーが発生した場合、Gemini CLIはエラーメッセージを受け取り、利用可能なドキュメントや自身の知識を使ってコードを自動的に修正しようとします。これにより、開発者はより効率的にコードのイテレーションを行うことができます。

6.4. カスタムコマンドによる開発効率化

Gemini CLIのもう一つの強力な機能は、カスタムコマンドです。これは、繰り返し使用するプロンプトやコンテキストをテンプレート化し、開発ワークフローに直接統合できる機能です。

プロンプトとコンテキストのテンプレート化: TOMLファイルを使用して、ルール、ガイドライン、参照するファイルへのリンク、特定のライブラリに関する情報などを含む長いプロンプトとコンテキストを定義できます。
直接的な利用: 定義したカスタムコマンドは、CLI上で/mcpのように/に続けてコマンド名を入力するだけで呼び出すことができます。
ユースケースの例:
- 「plan develop」モード: Philipp氏は、最初に計画を生成しディスクに書き出す（実装詳細を含む）、次にその計画に基づいて実装を行うための二つのカスタムテンプレートを作成しました。
- フロントエンド開発: Tailwind CSSを使用するフロントエンド開発者は、特定のカラーパレットやクラスに関する指示を含むテンプレートを作成し、チーム全体で共有できます。
生産性の向上: カスタムコマンドにより、開発者はプロンプトを毎回書き直す手間を省き、一貫性のある指示をモデルに与えることで、開発サイクルを大幅に加速できます。

6.5. コスト管理と継続的改善

AIエージェントの利用にはコストが伴いますが、Gemini CLIは透明性を提供します。

トークン使用量のレポート: エージェントの実行が完了すると、CLIは使用されたトークン数（入力と出力）に関する簡潔なレポートを提供します。これにより、開発者はコストを容易に把握し、最適化のための判断を下せます。
課金モデルの選択: 外部開発者の場合、フラット料金プランの利用や、Vertex AIのようなプラットフォームを介した利用も検討できます。
継続的な進化: Gemini CLIは「生きているアーティファクト」であり、週ごとに新しいリリースがプッシュされています。Philipp氏は、たとえ2週間前に試しただけであっても、常に最新バージョンを追いかけることの重要性を強調しました。最近のアップデートでは、VS CodeへのIDE統合が追加され、ターミナルだけでなくIDE内で変更を直接確認できるようになり、開発体験がさらに向上しています。

Gemini CLIは、AIエージェント開発をよりアクセスしやすく、効率的で、そして強力なものにするためのGoogleからの贈り物です。Philipp氏の経験が示すように、このツールは開発者の生産性を劇的に向上させ、新たな創造性を刺激します。

7. プロンプト最適化の最前線：モデルアグノスティックな挑戦

AIエージェントをプロダクション環境で運用する際、開発者が直面する最も手強い課題の一つが、モデルアグノスティックなプロンプトの実現です。IntuitのシニアスタッフAIサイエンティストであるConrad Dewuter氏からの質問に答える形で、Philipp Schmidt氏は、この課題の複雑さと、それに対する現実的なアプローチを詳細に解説しました。

7.1. 課題：モデル間の性能差とプロンプトの個別最適化

Conrad氏の質問は、GPT-5で最適化されたプロンプトがClaude Sonnetでは「ひどく機能しない」という一般的な開発者の経験を的確に捉えています。Philipp氏も「その痛みはよくわかる」と共感を示し、この問題の根深さを認めます。

モデル固有の特性: LLMはそれぞれ異なるアーキテクチャ、学習データ、微調整プロセスを持っています。例えば、ClaudeはXMLタグを用いた構造化されたプロンプトを好む傾向がある一方で、他のモデルではその効果が薄い、あるいは逆効果になることさえあります。これは、特定のモデルで最適化されたプロンプトが、他のモデルでは期待通りのパフォーマンスを発揮しない主な理由です。
容量制限とスケーリング: 特定のモデルに依存したプロンプトは、そのモデルの容量制限や将来的な変更によって、スケーリングや柔軟なモデル移行を困難にします。例えば、より安価なモデルや性能が向上した新しいモデルに切り替えたい場合、既存のプロンプトが使えないために大きな労力を要することになります。

Philipp氏は、「モデルアグノスティックな単一のプロンプトを書く」というアプローチ自体が、現実的ではない可能性が高いと指摘します。

7.2. 解決策は「プロセス」：自動プロンプト最適化と評価セットの活用

Philipp氏が提唱する解決策は、単一の汎用プロンプトを作成することではなく、異なるモデルやユースケースに対してプロンプトを自動的に最適化できる「プロセス」を構築することです。

評価セットの構築: 自動最適化の基盤となるのは、エージェントの性能を客観的に測定するための「評価セット（Eval Set）」です。これには、多様な入力プロンプトと、それに対する期待される理想的な出力が含まれます。この評価セットを充実させることが、プロンプト最適化の精度を向上させる鍵となります。
AIとライブラリによる自動最適化: 幸いなことに、LLM自身や関連ライブラリが、プロンプトの自動最適化を支援するツールとして利用できるようになってきています。
- LLM as a Judgeパイプライン: LLMを「審査員」として利用し、異なるプロンプトで生成された出力を評価させるパイプラインを構築します。このパイプラインは、どのプロンプトが最も高いスコアを達成するかを反復的にテストし、最適なプロンプトを見つけ出すことができます。
- Meta Prompting: LLMにプロンプト自体を生成・改善させる「メタプロンプト」の技術も活用できます。Geminiのような強力なモデルは、与えられた要件に基づいて多様なプロンプトのバリエーションを提案し、評価結果に基づいてそれを調整できます。
Google Cloud Vertex AI Prompt Optimizer: Google Cloudは、このようなプロンプト最適化の課題に対応するために、Vertex AI Prompt Optimizerのようなサービスを提供しています。これは、プレーンなLLMを用いてプロンプトをリファクタリングしたり、過去のモデルインタラクションデータに基づいてプロンプトをターゲットモデルに移行したりすることを可能にします。これは、まさにConrad氏が直面しているような問題を解決するための具体的なソリューションと言えるでしょう。

7.3. 継続的な監視と最適化：「生きているアーティファクト」としてのエージェント

プロンプトの最適化は、一度行えば終わりではありません。Philipp氏は、エージェントは常に進化し続ける「生きているアーティファクト」であるという視点を強調します。

ユーザー期待とデータドリフトへの対応: 以前議論したように、ユーザーの期待は時間とともに変化し、入力データもドリフトします。これらは、たとえ同じモデル、同じユースケースであっても、プロンプトやコンテキストを常に監視し、最適化し続ける必要があることを意味します。
トレーシングと評価システム: 優れたトレーシング機能と堅牢な評価システムは、プロンプトのパフォーマンスの変化を検出し、自動最適化パイプラインをトリガーするために不可欠です。これにより、エージェントは常に最適なパフォーマンスを維持し、変化する環境に適応できます。

「エージェントをプロダクションに投入しても、それで終わりではない」というPhilipp氏の言葉は、エージェント開発が単なる技術実装を超え、継続的な監視、評価、改善のライフサイクルを伴うことを示しています。モデルアグノスティックなプロンプトの夢は、単一のプロンプトによってではなく、変化に対応し、自動的に最適なプロンプトを見つけ出す「適応的なプロセス」を構築することによって実現されるでしょう。

結論：AIエージェント開発の未来と行動への呼びかけ

Google DeepMindのPhilipp Schmidt氏との対話は、AIエージェント開発の最前線で開発者が直面する挑戦と、それを乗り越えるための実践的な知見、そしてGoogle Geminiとそのエコシステムが提供する無限の可能性を深く掘り下げました。本記事で見てきたように、エージェント開発は、単なるコード記述以上の、深い戦略的思考、継続的なイテレーション、そして変化への適応を要求する領域です。

主要な学びの再確認

Geminiの力: 大規模なコンテキストウィンドウ、強力なマルチモーダリティ、高度な推論能力、そして関数呼び出しとツール利用の機能は、現実世界で機能するエージェントを構築するための比類ない基盤を提供します。プロンプトエンジニアリングからコンテキストエンジニアリングへの進化は、モデルに「適切な情報、適切なタイミング、適切なツール」を提供する重要性を強調しています。
モデル選択の戦略: POC段階ではGemini APIの手軽さと迅速性が強力な味方となりますが、制約された環境や高度なカスタマイズが必要な場合はオープンモデルが適しています。Gemmaのような中小モデルの台頭は、エッジAIや特化型ユースケースに新たなフロンティアを開いています。
フレームワークの活用: LangChain (LangGraph), LlamaIndex, CrewAI, Pydantic AIといったエージェントフレームワークは、プロトタイピングを加速し、コミュニティサポートを提供し、モニタリングや評価といったプロダクション運用に必要な機能の基盤を築きます。完璧なフレームワークは存在せず、自身のユースケースと開発スタイルに合わせた選択が重要です。
「最も難しい質問」への対処: 非決定性、評価の難しさ、オブザーバビリティ、データドリフト、そして変化するユーザー期待は、エージェント開発における避けられない課題です。これらには、「Ship, Iterate, Ship, Iterate」の哲学に基づき、Dogfooding、段階的リリース、LLMによるユーザーシミュレーションといった戦略で臨む必要があります。エージェントは「生きているアーティファクト」であり、継続的な監視と改善が必須です。
Gemini CLIの革新: オープンソースであるGemini CLIは、その透明性、拡張性、そしてMCPサーバーによる安全なコード実行環境やカスタムコマンドによるワークフロー最適化機能により、開発者の生産性を劇的に向上させる新たな相棒です。Google内外での活用事例は、その実用性を証明しています。
プロンプト最適化の未来: モデルアグノスティックなプロンプトという理想は、単一のプロンプトによってではなく、評価セットとLLM as a Judgeパイプライン、そしてVertex AI Prompt Optimizerのようなツールを活用した「自動最適化プロセス」を構築することによって現実のものとなります。プロンプトもまた、常に進化し続けるべき「生きているアーティファクト」です。

AIエージェント開発の未来への展望

AIエージェント開発はまだ初期段階にありますが、その進歩の速度は驚くべきものです。私たちは、個人の生産性向上から、複雑な企業プロセスの自動化、さらにはこれまで想像もできなかったような新しいアプリケーションの創出まで、あらゆる領域でエージェントが活躍する未来を目の当たりにすることになるでしょう。

Philipp Schmidt氏の言葉は、この急速に進化する分野において、開発者がどのように思考し、どのように行動すべきかを示しています。それは、恐れることなく実験し、学び、そして継続的に改善していくという、アジャイル開発の精神そのものです。

行動への呼びかけ

このブログ記事を読み終えた開発者の皆様へ。今こそ、AIエージェント開発の世界に深く飛び込む時です。

Gemini CLIを試してみてください: 最新の機能とIDE統合を体験し、あなたの開発ワークフローにどのように組み込めるかを探ってみましょう。その驚くべき生産性向上を実感できるはずです。
コミュニティに参加しましょう: LangChain、LlamaIndex、CrewAIなどの活発なオープンソースコミュニティに参加し、知識を共有し、協力してエージェント開発のフロンティアを押し広げましょう。
アイデアを形にしましょう: 「Ship, Iterate, Ship, Iterate」の精神で、小さなプロトタイプから始めてみましょう。あなたが抱くアイデアが、次のAIエージェント革命のきっかけとなるかもしれません。

AIエージェントの可能性は無限大です。この刺激的な旅に共に乗り出し、未来を創造していきましょう。