AIエージェントはマイクロサービス時代に入りつつあるが、その類比には限界もある

StartupHub.aiは、AIエージェントはいま2015年当時のマイクロサービスと同じ位置にある、という鋭い主張でGoogle Newsに掲載された。この比較は、エージェントがそのアーキテクチャを支えるほど信頼性高く振る舞えるのかという未解決の疑問を抱えつつも、インフラの転換が近づいていることを示している。

この主張は、製品発表や独立した測定に基づく節目ではなく、類比である。その価値は、そこから浮かび上がる対立にある。AI企業はますます、ツールを使い、タスクをやり取りし、業務システムをまたいで動作できるモジュール型の働き手としてエージェントを提示している。

しかし、エージェントは通常のソフトウェアサービスではない。曖昧な言語を解釈し、変動する出力を生成し、ときには設計者が想定していなかった行動を取る。より多くのエージェントを接続すれば、こうした不確実性を封じ込めるどころか、増幅する可能性がある。

マイクロサービスもまた、難しい移行を経験した。チームは独立したデプロイとスケーリングを得る一方、サービス探索、トレーシング、認証、レイテンシー、分散障害といった新たな問題を引き継いだ。こうした運用上の隔たりを埋めるため、インフラ製品の業界が成長した。

AIエージェント市場も現在、その道の一部をたどっているように見える。Model Context Protocol、すなわちMCPのような標準は、AIアプリケーションをツールやデータと接続する。A2Aとして知られるAgent2Agentは、独立したエージェント間の通信と委任を支援する。

この類似性によって、StartupHub.aiの枠組みは有用なものになる。しかし、それが結果を必然にするわけではない。決定的な競争は、モジュール型エージェントシステムと、それを信頼できるものにするために必要な運用管理との間で繰り広げられる。

Google Newsの主張が実際に変えるもの

StartupHub.aiの見出しは、エージェント市場に対し、自律型ソフトウェアに関するまた一つの予測よりも厳しい基準を突きつけている。

この記事は「AI Agents Are Where Microservices Were in 2015」というタイトルでGoogle Newsに掲載された。この見出しは、特定の日付における技術的達成を裏付けるものではない。業界の発展曲線における位置づけを提案している。

この比較が2015年を指すのは、マイクロサービスが広く注目を集め始めた一方、それを支えるインフラがまだ不完全だった時期だからだ。多くの組織は、運用コストを理解する前にアーキテクチャ上の可能性を理解していた。

マイクロサービスは、アプリケーションを明示的なインターフェースを持つ独立デプロイ可能なサービスに分割した。このアプローチにより、チームは個々のコンポーネントを更新、拡張、置き換える自由度を高めた。

同時に、複雑さはコードベースからネットワークへと移った。一つの関数呼び出しは、タイムアウト、失敗、再試行、互換性のない応答の返却が起こり得るリモートリクエストになった。

エージェント版もよく似ている。企業は、リサーチ、計画、コーディング、カスタマーサポート、購買を専門エージェントに分けられる。オーケストレーターは、各エージェントが異なるモデル、ツール、データ、権限を使用しながら作業を割り当てられる。

Microsoftのagent architectureは、このパターンを直接文書化している。そこでは、定義済みのAPIまたはメッセージングプロトコルを通じて接続される独立サービスとしてエージェントが説明されている。

同じ資料はトレードオフも指摘している。エージェント間通信はレイテンシーと障害モードを増やす。共有コンテキストの管理は難しくなり、ガバナンスとセキュリティはサービス境界をまたがねばならない。

こうした警告が重要なのは、AIエージェントが従来型のAPIラッパー以上の存在だからだ。エージェントは、モデルが生成した推論、取得したコンテキスト、ツールの説明、ユーザー指示に基づいて行動を選択する。

通常のサービスは、有効なリクエストを受け取れば予測可能に振る舞うべきだ。エージェントは、モデルの更新、コンテキストの変更、ツールからの応答を受けて、同じ目標を異なる形で解釈する可能性がある。

この違いが、類比に求められるものを変える。エージェント開発者に必要なのは、サービス探索、ルーティング、負荷分散に相当する仕組みだけではない。意図、委任、証拠、権限、生成された判断を記録するシステムも必要だ。

そのためGoogle Newsの見出しは、モデルの知能から運用上の成熟度へと注目を移す。もはや重要な問いは、エージェントが印象的なデモを完遂できるかどうかではない。

問われるのは、チームが可視性や制御を失わずに多数のエージェントをデプロイできるかどうかだ。この基準は、エージェントプラットフォーム、クラウドプロバイダー、セキュリティベンダー、企業のエンジニアリングチームに圧力をかける。

これが、インフラが議論の中心になっている理由でもある。次の段階は、さらに洗練されたアシスタントよりも、不確実なコンポーネント間の信頼できる契約に左右される。

AIエージェントインフラがいま収束しつつある理由

開発者がツールアクセス、エージェント間通信、アイデンティティ、オーケストレーションを別個のレイヤーに分け始めたため、エージェントインフラが形成されつつある。

初期のエージェントデモでは、すべての機能が一つのアプリケーションにまとめられていることが多かった。単一のプロセスが、プロンプト、モデル選択、ツール定義、メモリ、実行ループ、ユーザーインターフェースを担っていた。

この設計は、開発者が一つのコードベースを確認し、すべてのレイヤーをまとめて変更できるため、実験には適している。しかし、複数のチーム、モデル、ベンダー、セキュリティドメインがワークフローに加わると脆弱になる。

MCPは、この問題の一部に対処した。このプロトコルは、AIアプリケーションがツールを発見・呼び出したり、コンテキストリソースを取得したりするための共通の方法を提供する。

A2Aは別のレイヤーに対処する。A2A specificationは、独立したエージェントが機能を発見し、タスクを交換し、結果を伝達するための標準を説明している。

この区別は重要だ。エージェントからデータベースへの接続と、別々の所有者と内部推論プロセスを持つ二つのエージェント間の委任は異なる。

この分離は、分散ソフトウェアの周辺で生まれたレイヤリングに似ている。開発者はやがて、アプリケーションロジックをネットワーク、サービス探索、テレメトリー、ポリシー、デプロイ管理から分離した。

最近のガバナンス活動は、この比較をさらに強めている。Axiosは2026年8月、GoogleのA2AプロジェクトがAgentic AI Foundationへ移行する予定だと報じた。

standards reportによると、この財団は40社未満のメンバーから250社超へと成長していた。参加者には大手のクラウド、モデル、ソフトウェア、コマース企業が含まれていた。

この移行により、A2AはMCPおよび関連プロジェクトとともに、より焦点を絞ったガバナンス構造の下に置かれる。これが相互運用性を保証するわけではないが、複数のベンダーが調整の問題を認識していることを示している。

中立的なガバナンスは、ためらいの一因を減らし得る。企業は通常、重要なワークフローが一つのモデルプロバイダーの内部的なエージェント形式に縛られることを望まない。

共通インターフェースは代替手段を提供する。購買エージェントは、契約分析をあるプロバイダーに、コンプライアンス審査を別のプロバイダーに、社内データの取得を企業管理下のサービスに委任できる。

このモジュール性は、購入者に交渉力と技術的柔軟性をもたらす。同時に、アイデンティティ、コンテキスト、権限が失敗し得る境界も増やす。

これが、マイクロサービスとの比較がいま登場した理由だ。エージェントの能力は統合上の問題が見えるほど進歩した一方、標準は採用を競うほど若いままである。

このタイミングは、モデルの多様性にも左右されている。企業は推論品質、レイテンシー、プライバシー、モダリティ、運用コストに応じて、異なるモデルを選ぶことが増えている。

単一のモノリシックなエージェントは、この選択を一つのインターフェースの背後に隠せる。マルチエージェントシステムは違いを表面化させ、コンポーネント間に明示的な契約を必要とする。

開発者には、持続的な組織コンテキストも必要だ。エージェントは、リクエストの背景にあるファイル、決定、用語、履歴を欠いていれば、有用な作業を行えない。

この要件は、検索とknowledge blendingの重要性を高める。しかし、より良いコンテキストがアクセス制御やソース追跡の必要性をなくすわけではない。

インフラレイヤーは、同時に複数の問いへ答えなければならない。どのエージェントがタスクを受け取り、どのデータを読み、どのツールを呼び出し、誰が行動を承認したのか。

マイクロサービスプラットフォームは最終的に、サービスとネットワークリクエストに関する同様の問いを標準化した。エージェントシステムは依然として、断片化したログ、フレームワーク固有のトレース、アプリケーションコードによってそれらに答えている。

この隔たりが、StartupHub.aiの主張の背景にある機会を生む。同時に、市場が安定したインフラレイヤーからどれほど遠いかも明らかにしている。

モジュール型エージェントは同じ分散システム税に直面する

一つのAIワークフローを複数のエージェントに分割すれば専門性は高められるが、ローカルな不確実性は分散した不確実性へと変わる。

マイクロサービスは独立した所有権とデプロイを約束した。特に、多数のチームと不均一なスケーリング要件を抱える大規模組織にとって、その利点は現実のものだった。

コストも同様に現実的だった。サービスには、安定した契約、バージョニング、探索、再試行、認証、分散トレーシング、部分的な障害を扱う仕組みが必要だった。

エージェントは、これらすべての必要性を引き継ぐ。さらに、確率的な振る舞い、変化するモデル出力、プロンプトインジェクション、コンテキスト制限、曖昧な委任も加わる。

カスタマーサポートのワークフローを考えてみよう。一つのエージェントがリクエストを分類し、別のエージェントがアカウントデータを取得し、さらに別のエージェントが解決策を提案する。

承認を受けた後、四つ目のエージェントが返金を処理するかもしれない。それぞれの引き渡しでは、前の段階からデータ、前提、権限が運ばれる。

取得エージェントが古いポリシーを選択すれば、解決策エージェントは自信に満ちた無効な提案を生成する可能性がある。その後、返金エージェントがその提案に基づいて行動を実行するかもしれない。

障害は一つのコンポーネント内に収まらない。チェーン全体で生じるため、従来のデバッグは効果が薄くなる。

ネットワークリクエストが成功したことを示すトレースでは、エージェントがポリシーを誤解したかどうかを説明できない。モデルのトランスクリプトでは、正しい顧客レコードへのアクセスが認可されていたことを証明できない。

したがって、エージェントの可観測性には複数のレイヤーが必要になる。チームには、ネットワークテレメトリー、モデル入力、ツール呼び出し、取得したソース、意思決定経路、承認イベントが必要だ。

また、不要な個人情報を保存せずに有用な記録を保持しなければならない。詳細なトレーシングそのものが、セキュリティおよびコンプライアンス上のリスクになり得る。

再試行は、もう一つの違いを示す。従来のサービスは多くの場合、冪等な操作を繰り返せる。つまり、同じリクエストが追加の影響を生まない。

エージェントの再試行では、異なる計画を生成したり、別のツールを選んだりすることがある。周辺システムがトランザクション制御を強制しない限り、失敗した購入リクエストを繰り返すことで二重注文が発生する可能性がある。

状態はさらに難しさを加える。一つのエージェントが要約を保存し、別のエージェントが元の文書を保持する場合がある。どちらかの表現が変化すれば、その結論は乖離し得る。

マイクロサービスは、同様の問題に対して明示的なスキーマ、契約テスト、イベントログ、分散状態管理を導入した。エージェントプラットフォームには、モデルの振る舞いを考慮に入れた同等の仕組みが必要だ。

エージェントのアイデンティティも、もう一つの不足している制御手段だ。サービスは通常、権限が限定された定義済みのワークロードアイデンティティの下で実行される。

一つのエージェントが別のエージェントに委任し、そのエージェントがさらに委任することもある。各移管では、権限をタスクとともに引き継ぐべきかという問いが生じる。

最も安全な答えが、無制限の権限継承であることはほとんどありません。顧客記録を読み取れるリサーチエージェントが、その権限を外部の計画エージェントに自動的に付与すべきではありません。

短命な認証情報、スコープを限定したアクセス、明示的な委任記録は、露出を抑えることができます。しかし、プロトコルだけで組織のポリシーを強制することはできません。

モジュール型アーキテクチャは調達のあり方も変えます。企業は複数ベンダーのエージェントを組み合わせつつ、オーケストレーションと機密データを自社環境内に保持できるようになります。

この構成により、単一のプロバイダーがワークフロー全体を掌握することを防げます。その一方で、インシデントの責任を誰に帰するべきかは、より難しくなります。

障害の原因はモデル、プロンプト、ツールコネクタ、オーケストレーター、データソース、それとも受信側エージェントだったのか。各ベンダーは技術的にはもっともらしい反論を示すことができます。

この説明責任の問題こそが、エージェント基盤を通常のコンポーネント統合と分ける要素です。システムには、何が起きたかだけでなく、なぜ権限が付与されたのかを再構築できるだけの証拠が必要です。

2015年の類比が最も説得力を持つのはここです。マイクロサービスが実用的になったのは、組織が運用ツールをオプションではなくアーキテクチャの一部として扱うようになったときでした。

エージェントにも同じ転換が求められます。タスクを完了するデモは出発点にすぎません。本番運用への準備は、障害を封じ込め、説明し、復旧できるようになって初めて始まります。

本当の問題は接続性ではなく、振る舞いにある

共有プロトコルはエージェントを接続できますが、その判断を正確、安全、一貫したものにすることはできません。

相互運用性は重要なエンジニアリング目標です。個別の統合作業を減らし、開発者がワークフロー全体を作り直すことなくコンポーネントを置き換えられるようにします。

しかし、メッセージの交換に成功したことは、狭義の成功にすぎません。2つのエージェントが完全に通信できても、不正確な前提、危険な指示、過剰な権限を受け渡している可能性があります。

この制約は、マイクロサービスの類比の最も単純な形を弱めます。従来のサービスは、エンジニアが検査、テスト、制約を加えられるコードパスを実装します。

エージェントは、プロンプト、コンテキストの順序、取得した資料、ツールの説明、サンプリングの挙動によって出力が変わるモデルを使用します。決定論的な設定であっても、曖昧なタスクに伴う不確実性をなくすことはできません。

エージェントは侵害されていなくても誤った行動を取ることがあります。正当な指示に従い、認可されたツールを使いながら、それでも損害を招く選択をするかもしれません。

このリスクは、よく知られた侵入モデルとは異なります。不正アクセスを阻止するために設計されたセキュリティ制御が、認可済みだが誤った行動を止められるとは限りません。

NISTの2026年5月のエージェントセキュリティ分析は、この懸念を捉えています。回答者は、新たなエージェントセキュリティ上の脅威を導入の障壁として広く認識していました。

同機関は、既存のサイバーセキュリティ慣行が依然として有効だという幅広い合意も確認しました。ただし、こうした慣行はエージェントシステム向けに適応させる必要があります。

ここに、インフラへの熱狂がしばしば見落とす懐疑的な視点があります。ルーティングや標準化の改善は、信頼性が向上する前に、エージェントが到達できるシステムの数を増やしかねません。

ユニバーサルなツールプロトコルは、安全なアプリケーションの統合コストを下げられます。同じプロトコルが、操作された、あるいは混乱したエージェントが引き起こす影響を拡大する可能性もあります。

プロンプトインジェクションは、この対立をよく示しています。エージェントが、その挙動を誘導し直すために設計されたテキストを含む文書を取得する場合があります。

エージェントがその内容を指示として扱えば、ユーザーの意図に反して情報を開示したり、ツールを呼び出したりする可能性があります。インシデントの間も、ネットワーク接続自体は適切に認証されたままであることがあります。

マルチエージェントシステムは、信頼できないコンテンツがコンポーネント間を移動できるため、攻撃対象領域を広げます。あるエージェントが悪意あるテキストを、一見信頼できる要約に変換することもあります。

すると、受信側エージェントには、その操作を見抜くために必要な元の文脈がありません。委任は、本来なら危険な指示を、正当なワークフローを通じて洗浄してしまう可能性があります。

開発者には、データ、指示、ポリシー、ユーザー承認を区別する境界が必要です。その区別は、すべてのメッセージと変換を経ても維持されなければなりません。

また、個別のモデル応答だけでなく、ワークフロー全体をテストする評価手法も必要です。計画エージェントは単独テストには合格しても、別のエージェントが不完全なコンテキストを提供すると失敗することがあります。

長時間に及ぶタスクは、別の不確実性を生みます。数時間にわたって動作するエージェントは、変化するファイル、認証情報、ネットワーク状況、業務状態に直面します。

実行が完了する前に、当初の計画が無効になることもあります。システムはその変化を検知し、古い前提に基づいて進めるのではなく、確認を求めなければなりません。

人による承認は1つの制御手段ですが、承認の設計が重要です。「続行」するかを尋ねる曖昧なプロンプトでは、レビュー担当者は判断の根拠をほとんど得られません。

有用な承認では、意図する行動、影響を受けるリソース、証拠、スコープ、可逆的な結果を示すべきです。影響の大きい行動には、読み取り専用の取得よりも強い確認が必要です。

企業はまた、どこで自律性が正当化されるかを判断する必要があります。社内要約を作成するエージェントと、支払いを送信したり本番インフラを変更したりするエージェントでは、リスクが異なります。

この違いは段階的な導入を支持します。チームは、読み取り専用タスク、測定可能な出力、明確なエスカレーション経路から始められます。

実行権限は、障害率と復旧に関する証拠を集めた後にのみ追加できます。この進展は、自律エージェントネットワークへの即時移行というより、段階的なサービス抽出に似ています。

市場は、サービスメッシュに相当するエージェント向けの仕組みを生み出すかもしれません。それはおそらく、エージェント間の相互作用を取り巻くアイデンティティ、ポリシー、ルーティング、テレメトリ、標準化された制御を管理するものになるでしょう。

ただし、それはアプリケーションレベルの判断に取って代わることはできません。どの組織にとっても許容可能なエラー率や承認境界を、インフラ層だけで決めることはできません。

だからこそ、接続性を成熟度と取り違えてはなりません。エージェント市場は、信頼できる振る舞いを標準化する前に、通信の標準化を始めています。

スタックの成熟に伴い、誰に圧力がかかるのか

新たに形成されるスタックは、クローズドなエージェントプラットフォーム、企業の買い手、インフラベンダーに、それぞれ異なる理由で圧力をかけます。

クローズドなプラットフォームは、オープンインターフェースから圧力を受けます。企業が共有プロトコルを通じてモデル、ツール、エージェントを接続できれば、個々のサプライヤーを置き換える自由度が高まります。

ベンダーは、モデル品質、セキュリティ、ホスティング、専門アプリケーションによって、なお差別化できます。しかし、独自コネクタだけでプラットフォームを守ることは難しくなります。

クラウドプロバイダーは別の課題に直面します。顧客を1つのモデルやフレームワークに閉じ込めているように見せずに、選ばれるコントロールプレーンを提供したいのです。

オープンプロトコルへの対応は、その懸念を和らげる可能性があります。同時に、アプリケーション層に対するプロバイダーの制御を弱めることにもなります。

エージェントフレームワークの開発者は、どの責任をライブラリ内に収めるべきかを決めなければなりません。プロンプトのオーケストレーションだけでは、本番利用には不十分になりつつあります。

顧客はますます、評価、トレーシング、ポリシー適用、認証情報の処理、復旧、バージョン管理を必要としています。すべての機能を追加すれば、軽量なフレームワークが複雑なプラットフォームになりかねません。

可観測性企業には機会がありますが、エージェントのトレースには従来にないデータが必要です。トークン数とレイテンシだけでは、委任された判断が正当化されていたかを説明できません。

有用なシステムは、技術イベントとビジネス上の意味を結び付けなければなりません。どの証拠が行動を裏付け、どのポリシーがそれを認可したのかを示す必要があります。

セキュリティベンダーも同じ拡大に直面します。ネットワーク制御とアイデンティティシステムは依然として必要ですが、エージェントは有効なセッションの内部に判断リスクをもたらします。

ベンダーは、ツール利用、委任チェーン、文脈データ、変化する意図を監視する必要があります。過度な監視は機密性の高いプロンプトや文書を露出させる可能性があるため、収集には節度が必要です。

企業の買い手が負う当面の負担は最も大きいものです。プロトコルを採用しても、運用モデル、説明責任の構造、許容可能なリスクのポリシーが生まれるわけではありません。

チームには、エージェントのアイデンティティ、ツール権限、データソース、評価、インシデント、承認ルールの担当者が必要です。こうした責任は、エンジニアリング、セキュリティ、法務、事業部門をまたぐことが多くあります。

ナレッジマネジメントも運用インフラになります。権威性、鮮度、所有者が不明確なまま散在する文書では、エージェントは信頼性高く動作できません。

検索可能な技術ナレッジベースは、情報取得を改善できます。それでもチームには、矛盾する情報源や古くなったガイダンスに対するポリシーが必要です。

エージェント基盤を構築するスタートアップは、タイミングの問題に直面します。顧客は課題を認識している一方、標準やアーキテクチャの選択肢はまだ定まっていません。

1つのプロトコルを中心に構築すれば、今日の導入を加速できます。しかし、ガバナンス、トランスポート、セキュリティの要件が変われば、移行作業が発生する可能性があります。

マイクロサービス市場では、クラウドプラットフォームが機能を吸収するにつれ、多くのツールが姿を消しました。エージェントのスタートアップも同様のリスクに直面しています。

独立したビジネスになるカテゴリーもあります。ほかはクラウド、モデルプラットフォーム、開発者ツール、既存のセキュリティ製品の機能になるでしょう。

したがって、この類比は投資の確実性よりもアーキテクチャの指針となるべきです。どのベンダーが取り込むかを予測せずに、運用上の圧力がどこに蓄積するかを示します。

最も防御力のある製品は、モデルやフレームワークをまたいで持続する問題を解決する可能性が高いでしょう。アイデンティティ、評価、可観測性、ポリシー、信頼性の高い実行は、その条件に当てはまります。

これらのカテゴリーも相互に結び付いています。評価システムにはトレースデータが必要であり、ポリシーエンジンにはアイデンティティと文脈情報が必要です。

スタックは、共有イベント形式とガバナンス制御を中心に統合されるかもしれません。あるいは、大規模プラットフォームが、境界部にアダプターを備えた統合システムを提供する可能性もあります。

どちらの結果でも、中心的な対立は残ります。買い手はモジュール式の選択肢を望む一方、ワークフローが失敗した際に責任を負う当事者も求めています。

マイクロサービスはこの緊張を解消しませんでした。組織は、独立したコンポーネントと分散システムの運用コストの均衡を取ってきました。

AIエージェントは、その均衡をさらに難しくします。コンポーネントは単に失敗するだけではありません。技術的には正常に見えながら、誤ったタスクを完了する可能性があります。

Google Newsの読者が次に注目すべきこと

AIエージェントがマイクロサービスの生産的な段階を繰り返しているのか、それとも複雑さだけを繰り返しているのかを示すシグナルは3つあります。

最初のシグナルは、ベンダー間の真の相互運用性です。企業が周囲のワークフローを書き直すことなく、1つのエージェントやモデルを置き換えられるとき、プロトコルには意味があります。

同じ財団の下にあるプロジェクト間のデモだけでは不十分です。買い手には、タスク状態、アイデンティティ、権限、エラー処理を維持できる独立した実装が必要です。

A2Aが焦点を絞ったオープンガバナンスへ移行したことは、相互運用性の根拠を強めます。次の試金石は、競合プラットフォームが基本的なメッセージ交換を超えて互換性のある振る舞いを実装するかどうかです。

適合性テスト、共有された機能記述、公開された互換性結果に注目してください。こうした進展は、StartupHub.aiの類比を強めるでしょう。

ベンダー固有の拡張が根強く残れば、その類比は弱まります。それは、プロトコルが共通のラッパーとして機能する一方で、意味のある振る舞いは独自のままであることを示唆します。

2つ目のシグナルは、測定可能な本番信頼性です。エージェントベンダーは限定された評価で完了率を示すことが多いものの、企業が必要とするのはワークフロー全体に関する証拠です。

有用な指標には、誤ったツール呼び出し、未認可の行動試行、復旧の成功、承認頻度、古いコンテキストによって生じた失敗などが含まれます。

これらの指標は、慎重に選ばれたデモではなく、実際の環境を反映したものでなければならない。また、モデルのエラーと、統合、データ、権限、オーケストレーションの失敗を区別すべきだ。

明確な本番運用指標があれば、成熟した分散ソフトウェアとの比較はより説得力を増す。逸話的な成功事例に依存し続ければ、その比較は弱まる。

3つ目のシグナルは、実用的なアイデンティティおよび認可インフラである。エージェントには、検証可能なアイデンティティ、スコープが限定された認証情報、そして組織の境界を越えて機能する委任記録が必要だ。

NISTは、エージェントのアイデンティティとセキュリティを標準化の議題に組み込んでいる。同機関の標準化イニシアチブは、自主的なガイダンスと業界連携への関心が高まっていることを示している。

重要な試金石は、こうした取り組みが導入可能なパターンを生み出すかどうかだ。企業には、既存のアイデンティティシステムに適合し、最小権限アクセスを維持できる制御が必要となる。

最小権限とは、特定のタスクに必要な権限だけを付与することを意味する。エージェントが計画を変更したり、動的に作業を委任したりすると、その実現はより難しくなる。

実用的なシステムでは、タスクがチェーンを進むにつれて権限を絞り込むべきだ。参加するすべてのエージェントに、広範なユーザー権限を複製してはならない。

この問題で進展が見られれば、エージェントインフラが持続可能なプラットフォーム段階に入りつつあるという見方は強まる。共有APIキーへの依存が続けば、その見方は弱まる。

読者は、今後のGoogle Newsの見出しについても慎重に受け止めるべきだ。「AI agent」という言葉は現在、アシスタント、スクリプト化されたワークフロー、コーディングツール、そして意味のある自律性を持つシステムまでを含んでいる。

これらの製品には異なるリスクがあり、同じ成熟度の主張で扱うべきではない。信頼できる下書き支援アシスタントがあるからといって、自律型の金融・業務エージェントが実用段階にあることの証明にはならない。

StartupHub.aiの見出しが成功しているのは、業界に有用な歴史的参照点を与えているからだ。しかし、読者がこの比較を、すでにその結末が実現した証拠と解釈するなら、失敗に終わる。

2015年のマイクロサービスは、認識可能なアーキテクチャを提供した一方で、運用モデルは未完成だった。AIエージェントも現在、同じような大きな構図を示しているが、より大きな行動上の負担を抱えている。

インフラの機会は現実のものだ。同時に、信頼性の低い判断を、より多くのツール、データ、組織へ分散させる危険も現実にある。

開発者は、すべてのエージェント境界に明確な契約、アイデンティティ、トレース、フォールバック、責任者があるかを問うべきだ。エンタープライズの購買担当者は、権限を拡大する前に、完全なワークフローから得られた証拠を要求すべきである。

ナレッジワーカーは、エージェントが何にアクセスできるのか、そしてどの操作に承認が必要なのかを注視すべきだ。利便性によって、作業を準備することと実行することの違いが消えてはならない。

最も強い裏付けとなるのは、また一つ野心的なエージェントのデモではない。目に見える形で失敗し、被害を限定し、予測可能に復旧する、退屈なほど堅実な本番システムだ。

それこそがGoogle Newsの読者が追うべき節目である。それが実現するまでは、マイクロサービスのアナロジーは有用な地図ではあっても、目的地に到達した証拠ではない。