Googleは最近無料のエージェントコースを開始しました。
Prompt、エージェントループからGraph Workflow、マルチエージェント、自己進化システムまで、コースは続きました。一見すると、新しいエージェント開発手法を導入しているように見えます。
しかし、Google ADK 2.0の公式データ、Google Cloudアーキテクチャガイドライン、最近のエージェントレビュー研究をまとめると、本当に注目すべきはAPIではなく、はるかに大きな変化だと思います。
エージェント開発は，“モデル調整”から“システム設計”へと移行しつつある.
過去のAIアプリケーションのほとんどは以下のようでした：
入力→ Prompt →モデル→出力
翻訳、要約、分類、情報抽出、コンテンツ書き換え、これらのタスクは通常、1回の呼び出しで完了します。
開発が速く、コストが見積もりやすく、エラーが発生した場合は1回の再呼び出しで済みます。
しかし、ツールコールが来ると、エージェントは実際にビジネスプロセスに入り始めます。
データの検索、APIの呼び出し、コードの実行、データベースのクエリを実行し、ツールが返す結果に基づいて次のステップを決定します。
モデルはもはや“質問に答える”だけではありません
それは“物事をする”から始まる。
しかし、モデルが実装されると、問題は全く異なります。
コンテキストは成長し続け、ツールの結果は履歴に記録され続け、エージェントはツールを繰り返し呼び出したり、途中で目標を外れたり、タスクが完了する前に終了することさえあります。
エンタープライズプロセスは、権限、承認、ステータス、再試行、リカバリ、監査の要件をさらに増加させます。
カスタマーサービスの払い戻し、請求書の確認、従業員のオンボーディング、注文処理、これらのことは簡単な質問と回答ではありません。
エージェントの本当の問題は：
“どうやってモデルを何回正しくするのか？”
となった。
“モデルが関与するビジネスプロセスを安定的に実行するには？”
これがGoogle ADK 2.0が注目すべき点です。
Prompt、Agent Loop、Graphの違いは何ですか？
エージェントについて話す人が多いので、Prompt、Agent Loop、Workflowを混同しがちです。
実際には3つの異なるレベルの問題を解決します
“理解”を促進する
プロンプトはモデルに伝えます。
何をすべきか、何をすべきか、出力するフォーマット、制限は何ですか。
翻訳、要約、分類、書き換えなど、タスク自体が単純な場合は、Promptで十分です。
エージェントループ“アクション”を解決する
モデルにツールがある場合、以下ができます。
目標を理解する→次のステップを設定する→ツールを呼び出す→結果を読む→次のステップを決定する。
これは典型的なエージェントループです
オープンエンドのタスクに特に適しています。
例えば、データ検索、コード修復、複雑なデータ分析です。
各ステップを事前に記述することは困難であるため、モデルはフィールドの結果に基づいて計画を動的に調整する必要があります。
Graph Workflowの“実行”
ワークフローは以下の通りです。
全体の流れはどのように走るか。
どのようなステップを実行する必要がありますか？
どのタスクが並列できますか？
どのような場合にブランチに入る？
手動承認はいつ必要ですか？
失敗した後はどこで再試行できますか？
保存すべき状態は？
これらの問題の全てをモデル現場決定に任せることはできない。
プログラムに書く方が良いです。
3つは簡単に理解できます。
Promptは理解を担当し、Agent Loopはアクションを担当し、Workflowは制約の実行を担当する。
3つは置き換えられず、重ね合わせることができます。
1回のモデル呼び出しで解決できる問題は、ワークフローを強制することなく解決できます。
シングルエージェントがすでに安定して遂行できるタスクも，“Agentic”のために複数のエージェントに分割する必要はない.
2）Promptはいつ失敗しますか？
Promptの最大の問題は、十分ではないことです。
ビジネスプロセスが複雑になるにつれて、プロセス自体はPromptの中に隠れ始めています。
例えば、払い戻しプロセス：
ユーザーが払い戻しを行う→注文を照会→ポリシーを判断→払い戻しを行う→確認メールを送信→請求書を更新します。
これらすべてをエージェントに渡し、モデルが次のステップを自分で決定することは非常に柔軟に見えます。
しかし、本番環境にはすぐに問題が発生します。
開発者が特定するのは難しい。
このステップは毎回行われますか？
払い戻し前に許可チェックを完了しましたか？
ツールの失敗後に返金は繰り返されますか？
メールが失敗した後はどこに行けばいいですか？
データベースの更新が失敗した後、以前の操作をロールバックする必要はありませんか？
これはもはやPromptの問題ではない。
ソフトウェア工学の問題です
したがって、真に信頼できるシステムは通常、より現実的な分業を採用する。
モデルは不確実性を担当し、コードは決定性を担当する。
例えば：
苦情内容の理解と分析は、モデルに任せることができる。
注文照会、払い戻し実行、データベース更新は、プログラムによって制御される必要があります。
エージェントループは柔軟ですが、本番環境には“手綱をかける”必要があります。
エージェントループの魅力は、すべての経路を事前に知る必要がないことです。
モデルは、ツールのリターン結果に基づいて計画を継続的に調整できます。
例えば：
“この会社の最近の資金調達状況を調べてください。
エージェントは自分でWebページを検索したり、データベースをクエリしたり、資料を整理したりして、情報が不足していることに気付いたときに検索を続けることができる。
このようなタスクは、完全にデッドフローを書くと面倒になります。
しかしループには自然なリスクもあります
いつ止まるか分からない。
そのため、本番環境でのエージェントループは通常明示的に設定する必要があります。
- 実行ステップの最大数
- 合計タイムアウト時間
- トークン/ API予算
- 成功の条件
- 失敗の条件
- 手動アップグレードパス
そうでなければ、間違った判断は次のようになります。
ツールを呼び出す→エラー結果を得る→ 再起動→ 再起動→再試行
最終的な結果は
コストは上昇し、遅延は増加し、タスクは完了しません。
だからこそ、
経路が不確実な場合は、モデルに決定させます。
パスが決まったら、モデルに推測させないでください。
これはエージェントプロジェクトの非常に重要な原則です。
Graph Workflowとは何ですか？
Graph Workflowの機能はとてもシンプルです。
モデルの決定に隠されていたプロセスを、開発者が見て、テストし、変更できるソフトウェア構造に変えます。
例えば、払い戻しプロセスは以下のように設計できます。
オーダーの照会
↓ ↓ ↓
ユーザー苦情の分析
↓ ↓ ↓
返金条件の判断
↓ ↓ ↓
条件を満たし、払い戻しを実行する。
│ │ │
No. -不満→スケジュールを閉じる
↓ ↓ ↓
確認メールを生成
↓ ↓ ↓
請求書ステータスの更新
その結果、すべてのポイントが明確になります。
どのようなステップを実行する必要がありますか？
どのステップが並行できますか？
手動確認が必要な場所は？
失敗後はどこから回復するのか。
持続可能な結果とは？
全て明確に表現できます。
これはワークフローの最大の利点です。
エージェントを賢くするのではなく、エージェントをより制御できるようにします。
Google ADK 2.0が注目される理由は？
Google ADK 2.0の重要な変更点は、ワークフローランタイムがエージェント開発の中心に正式に配置されたことです。
Python 2.0は2026 年 5 月 19 日にGAになり、Go 2.0は6 月 30 日にGAになる。
公式設計では、エージェント、ツール、関数はすべてワークフローのノードとなり、実行関係を通じてプロセス全体を制御することができます。
シーケンシャル実行、条件付きルーティング、並列タスク、ループ、動的ワークフロー、ネストされたプロセス、および人間の介入はすべて、統一された実行モデルに組み込むことができます。
さらに重要なのは、長期タスクのステータスと回復に焦点を当て始めたことです。
実際のエンタープライズタスクは数秒で完了することはできません。
数十分、あるいはそれ以上続くことがあります。
途中で中断可能。
手動の承認を待つことができます。
外部システムが一時的に利用できない場合があります。
この時点でシステムは：
それ以前はどこで行われたか。
チェックポイントと状態のリカバリ機能がない場合、エージェントはいったん停止すると、再開するしかありません。
そのため、エンタープライズエージェントは最終的に従来のソフトウェアシステムのようになります。
必要なのは
状態です。
イベントですね。
チェックポイント。
再試行。
権限を持つ。
日記です。
監査役。
回復した。
長いコンテキストは信頼できる記憶と等しくない
見落とされがちなもう一つの問題があります。
Context Rotです。
多くの人は、履歴をコンテキストに詰め込むだけで、エージェントは“すべてを記憶している”と考えています。
実はそう簡単ではありません。
入力が長くなるにつれて、コンテキストから本当に重要な情報を正確に見つけるモデルの能力が低下する可能性があります。
エージェントは通常のチャットよりもこの問題に直面しやすいです。
ツールを呼び出すたびに新しいデータが得られます。
検索結果、Webページコンテンツ、データベースレコード、API戻り値、中間推論
すべてがコンテキストに追加され続けると、最終的には膨大な情報のゴミ捨て場になります。
コンテキストが長いほど、必ずしも賢くはありません。
時には間違いを犯しやすい。
ワークフローは3つの方法で軽減できます。
まず、ノード分離コンテキストです。
各ノードは本当に必要な情報のみを読み取ります。
次に、構造化状態を使用する。
毎回完全なチャット履歴をモデルに再ロードしないでください。
第三に、チェックポイントの設定。
1つのノードが完了すると確認結果を保存し、次のノードが確認された状態から続行する。
しかし、ここに重要な違いがあります。
チャット記録の保存は回復力とは限りません。
真の回復メカニズムも考慮すべきです。
チェックポイント、ロギング、冪等アクション、および外部システムのリプレイポリシー。
マルチエージェントはより高度ではない
誤解されやすい傾向もあります。
エージェントが多ければ多いほど、システムが高度になるようです。
全く違います。
マルチエージェントが本当に価値があるのは職務分担の明確化。
例えば：
エージェントが回収を担当します。
エージェントが分析を担当する。
エージェントが実行します。
各エージェントは異なるツール、権限、コンテキストを持つことができます。
問題も発生します。
もっと電話をかける。
コミュニケーションが増えた。
状態同期はより複雑になります。
トラブルシューティングはもっと難しい。
並行性は、フロー制限、リソース競争、一貫性の問題にもつながります。
NeurIPS 2025のMAST調査では、1，600以上のマルチエージェント実行トレースを分析し、14種類の障害を特定しました。
これらの問題の多くはPromptがよく書かれていない。
しかしながら：
不合理なタスク分担、エージェントの連携の失敗、状態管理の混乱、結果の検証不能。
私はシンプルな原則に同意します
明確な責任境界がなければ、“マルチエージェント”のためにマルチエージェントを使用しないでください。
エージェントで安定的に解決できる問題は、まずエージェントを使用します。
タスクが明確な役割分担、権限分離、または複雑なコラボレーションを示す場合にのみ、分割を検討してください。
8.エージェント評価は“正解なし”だけでは見られない
従来のLLMアプリケーションでは、精度テストを簡単に実行できます。
エージェントは異なります。
それは単に“正しく答える”だけでなく、“物事を成し遂げる”ことです。
例えば、払い戻しエージェントです。
最終的に答えた。
“返金は完了しました”。
この言葉がどれほど美しいかは意味がない。
本当に検証する必要があるもの：
払い戻しは実際に行われるか？
払い戻し額ですよね？
繰り返し払い戻しはありますか？
過剰操作はありますか？
ワークブックは更新されたか？
ユーザーは通知されたか？
プロセス全体の記録はありますか？
企業がエージェントを評価するとき、私は現実的で脱感作的な歴史的タスクのセットを比較することをお勧めします。
20 - 50のタスク。
少なくとも3つの実装を比較：
- シングルモデルコール
- ツール付きのシングル·エージェント
- グラフワークフローまたはマルチエージェント
同じタスクと承認基準を使用します。
主な記録：
- 初成功率
- 最終ミッション成功率
- 手動変更時間
- エンドツーエンドの遅延
- モデルとツールの総コスト
- 再試行の回数
- 失敗はどこで起こるか？
- 不正な操作の回数
- ソースと実行トラックが完全かどうか
特にリスクの高いビジネスでは、“成功 /失敗”だけを記録することはできません。
保存する必要があります
採点基準、元の証拠、実行軌道、手動レビュー記録。
実際にオンラインになったら、答えなければならないのは：
“正しいことをしたのか？”
答えてください：
“どうしてこんなことを？”
9、エンタープライズ着陸エージェント、最良の出発点は“スーパーエージェントを作る”ことではない
もし私がビジネスエージェントになるとしたら、まず考えないでしょう。
“マルチエージェントシステムを作りたいですか？”
私はまず尋ねます：
明確な境界と検証可能な結果を持つ既存の手動プロセスはありますか？
例えば：
請求書の検証。
顧客の払い戻し。
契約の審査。
従業員が入社。
セールスリードの整理
まず、人工的な流れを明確にする。
どのくらいかかるの？
費用はいくら？
最も一般的な間違いはどこですか？
最も無駄なステップは？
決定ルールに該当する手順は？
人間の判断が必要なステップは？
このベンチマークができたら、モデルを使用する場所を決定します。
その後、
1つのエージェントで解決できる場合は、複数を削除する必要はありません。
コードで解決できれば、モデルに決めさせないでください。
プロセスが明確な場合にのみ：
分岐、パラレル、承認、再試行、再開
必要に応じてワークフローを導入する。
支払い、データベースへの書き込み、電子メールの送信、チケットの提出などの不可逆的なアクションが含まれる場合は、事前に設計する必要があります。
パーミッション検証、冪等キー、手動確認、ロールバックパス。
この時点で、あなたは発見する：
エージェントのエンジニアリングは、本質的に従来のソフトウェアエンジニアリングに近づいています。
最後に、エージェントの真の次のステップは何ですか？
過去2年間、私たちは以下を調査しました。
モデルを賢くするには？
Promptをより効果的にするには？
エージェントがツールを使用できるようにするには？
しかし、企業にとって本当の関心事は次のようになります。
エージェントが仕事を安定させるには？
この2つは全く違います。
モデルが時折驚くべきものであっても、本番環境に移行できるとは限りません。
エージェントが1つのタスクを完了できるからといって、1日に1万回のタスクを完了できるわけではありません。
企業が本当に必要とするもの：
安定した成功。
制御可能なコスト。
プロセスを追跡できます
状態を回復できる。
最小限の権限。
信頼できる再試行。
完全な監査。
人間の介入です
継続的な評価です
私はエージェントをツールを呼び出すチャットウィンドウではなく、新しいソフトウェアシステムとして見たいと思います。
プロンプトはモデルにタスクを理解させます。
Agent Loopは，モデルを結果に応じて行動させる.
Graph Workflowは実行プロセス全体を制限します。
AIの柔軟性と従来のソフトウェアの確実性の両方を得るためには、3つを適切な場所に配置します。
Google ADK 2.0で本当に注目すべきことは、APIがどれだけ追加されたかではない。
しかし、それは非常に明確なシグナルを送った。
エージェントは、“ツールを呼び出すチャットボット”から、“エンジニアリング、運用、監査が可能なソフトウェアシステム”へと進化しています。
Graph Workflowはその第一歩に過ぎません。
エージェントがオンラインになるかどうかの最終的な決定は、デモの素晴らしさではなく、
成功率、手作業による再作業、遅延、コスト、および安全記録。
これは、エージェントが実際にエンタープライズ本番環境に参入した後、最も注目すべき競争力かもしれません。