マネージドエージェントに分散型インフラが必要な理由

Anthropicが今週発表したClaude Managed Agentsは、インフラ企業に対する直接的な脅威と受け止められ、Akamaiのような企業への潜在的な影響について業界での大きな議論を巻き起こしました。世界を動かすほどのAnthropicの影響力を考えると、モデルプロバイダーがホスト型サービスを発表したときには、インフラレイヤーが中抜きされてしまうと想定するのが直感的な反応であることは認めます。しかし、その解釈では、Anthropicが構築しているものや、その企業規模での運用で実際に機能すべきものとは合致しません。

エンジニアリングに関するブログ記事を注意深く読んでみましょう。マネージドエージェントは、ホスト型サービスであり、特定の実装よりも永続的な少数のインターフェース群を介して、ユーザーの代理で長期視野のエージェントを実行します。Anthropicはエージェントのコンポーネント（セッション、ハーネス、サンドボックス）を仮想化し、それぞれを独立して入れ替えられるようにしています。自ら予見できないと公言している未来に向けた設計なのです。すなわち、Anthropicが直面している課題は、「まだ想定されていないプログラムのシステムを設計する方法」です。

これはインフラの代替ではありません。インフラに対する新たな需要源なのです。

Anthropicのエンジニアリングチームの説明によれば、基本的な設計上の判断は、「脳」（Claudeとそのハーネス）を「手」（アクションを実行するサンドボックスとツール）から切り離すということでした。この分離により、「many brains, many hands（多くの脳と多くの手）」と称していることが可能になります。1つのエージェントセッションから複数の推論呼び出しや複数の実行環境を生成することができ、複数の場所やリソースの間で並行して実行されます。

理解しておくべき重要なポイントがあります。Anthropicは、Claudeが必要とする脳や手の数や場所について何の仮定も置いていないということです。これはアーキテクチャに関する軽いコメントではありません。推論、サンドボックス、ツールが実行される場所であるインフラレイヤーを、意図的にオープンにしておくという宣言です。Anthropicがそのオーケストレーションを構築します。その下支えとなるコンピューティングファブリックは、まさにAkamaiのような企業が提供しているものです。

これはすなわち、2026年3月に米国カリフォルニア州サンノゼで開催されたNVIDIA GTCで当社が発表した分散推論アーキテクチャに対応します。実用レベルのAI推論（特に低レイテンシー応答、多段階推論、リアルタイムのツール呼び出しを必要とするエージェント型ワークフロー）には、集中型のAIファクトリーとは異なるアプローチが必要であるという当社のテーゼこそ、マネージドエージェントがエンタープライズ規模で機能するために必要なのです。

AIファクトリーは、基盤モデルのトレーニングや大規模な同時実行GPUワークロードについては優れています。しかし、マネージドエージェントが並列動作する5つの「脳」を生成し、そのそれぞれがツールの呼び出し、コードの実行、結果のリターンをリアルタイムアプリケーションのレイテンシー制約内で実行する必要がある場合（Anthropicは「まだ想定されていないプログラム」に向けて設計している意識であることに注意）、複数の地域に分散し、高スループットのネットワークファブリックで接続されたGPU群があり、その各レイヤにセキュリティが適用されていることが必要です。

すなわち、Akamai Inference Cloudです。トレーニングや微調整のための集約的なGPUクラスタから、実運用での推論に使用する分散型NVIDIA RTX PRO™ 6000 Blackwell Server Edition GPUまで、そして、ルーティング、キャッシュ処理、セキュリティのためのエッジポイントまで、当社のコンピューティングリソースの連続体は、このようなワークロードパターンを対象に構築されています。

光の速度を超えることはできません。ロンドンのユーザーがバージニア州に置かれた推論エンドポイントにアクセスする場合、1つのトークンが生成されるまでに、両方向とも約28ミリ秒の伝播遅延が発生します。これに、エージェント型ワークフローでの順次推論呼び出しの数を乗算すると、リアルタイムアプリケーションでは集中型推論は非実用的だと分かります。

Anthropicのエンジニアリングチームは、マネージドエージェントのセキュリティ上の課題について、驚くほど率直に語っていました。その結合型の設計では、Claudeが生成した信頼できないコードは、すべて認証情報と同じコンテナで実行されるため、プロンプトインジェクションを行うにはClaudeに自身の環境を読むように指示するだけで済んだのです。攻撃者がトークンを入手すると、新しく制限がないセッションを生成して、マネージドエージェントに作業を委任することができます。

チームによる構造上の修正は、認証情報をサンドボックスから分離することでした。それでもまだ根本的な不安点が認識されていました。スコープを狭めることは明らかに緩和策となりますが、これは、限られたトークンではClaudeにできないことがあるという前提を組み込んだものであり、Claudeはますますスマートになっているからです。

こういったことから、Akamaiのセキュリティポートフォリオが、有用だということに留まらず必須の存在になっていると当社は考えています。企業がマネージドエージェントを実運用環境に導入すると、エージェントが複数ステップタスクの自律的実行、外部APIの呼び出し、コードの生成と実行、社内システムの操作を行うことにより、攻撃対象領域が劇的に拡大します。プロンプトインジェクション、敵対的なコードの生成、認証情報の盗難、ラテラルムーブメント（横方向の移動）、データ窃取が、実際の運用上の大規模なリスクになり、それを「まだ想定されていないプログラム」が継承することになります。

Akamai Firewall for AIは、大規模言語モデル（LLM）のエンドポイントを、プロンプトインジェクションやモデルの不正使用から保護します。Akamai API Securityは、エージェントが外部のツールやサービスに対して行うAPIコールを探索、マッピング、監視します。Akamai App & API Protectorは、ウェブアプリケーション・ファイアウォール・ソリューションで、エージェントとその操作の対象であるアプリケーションの間のトラフィックを検査します。Akamai Guardicore Segmentationは、エージェント（または侵害されたエージェント）がエンタープライズネットワーク内でアクセスできる対象を制限します。また、Akamai Bot Managerは、正当なエージェントトラフィックと、エージェントの動作を模倣する攻撃者の自動実行を区別します。

Anthropicを含めて、モデルプロバイダーはオーケストレーションレイヤーを構築する立場であり、こうした機能すべてを構築することはないと考えられます。ランタイム保護、ネットワークセキュリティ、インフラへのルール適用は、Akamaiのような企業が提供していますが、こういったものが、顧客データ、金融取引、重要な業務を処理する実運用システムを対象に自律型エージェントを導入するために企業で必要となります。

市場の最初の反応では、マネージドエージェントについて、AnthropicがCDN、クラウド、セキュリティインフラの代替品を発表したかのような扱いでした。正しくはその逆だと考えています。

実運用環境で実行されるすべてのマネージドエージェントのセッションには、推論用コンピューティング（Akamai Inference Cloudへの需要を創出）、ネットワーク接続とルーティング（Akamaiのエッジプラットフォームとバックボーンへの需要）、アプリケーション、API、ネットワークレイヤーでのセキュリティの適用（Akamaiのセキュリティポートフォリオの需要）、分散した場所でのオーケストレーション（当社が構築しているコンピューティングリソースの連続体の需要）が必要です。

クラウドコンピューティングが登場したときに何が起きたかを考えてみてください。AWSによって、CDN、セキュリティ、エッジコンピューティングの必要性が無くなることはありませんでした。むしろアプリケーション数、トラフィック、攻撃対象領域がどれも大幅に増加し、Akamaiが提供するサービスの需要が促進されました。マネージドエージェントでも同じパターンになると考えています。エージェントの数が増えると、推論呼び出しやAPIインタラクションの増加、分散コンピューティングの必要性の増大、セキュリティ上の露出増加につながります。当社はこれらを支えるインフラになることを目指しています。

1週間の間に、同じ会社からの2つの発表（Project GlasswingとClaude Managed Agents）によって、AIセキュリティとインフラという問題の両方の側面が浮き彫りになりました。Glasswingは、脆弱性の検知を高速化します。これにより、開示から修復までのギャップにおけるランタイム保護の必要性が増大します。マネージドエージェントは、自律型AIワークフローを大きな規模で実現します。これにより、スタックのあらゆるレイヤで分散推論インフラとセキュリティの適用の必要性が増加します。

どちらの発表も、Akamaiの製品が必要だということを裏付けるものです。当社のネットワーク、データ、セキュリティポートフォリオ、分散コンピューティングプラットフォームが、これらの開発物によって脅威にさらされることはありません。逆に、このような開発物のために、Akamaiが構築している製品が必要になると考えています。新しい脆弱性が検知されるごとに、パッチが展開されるまでの間の本番環境での保護が必要です。新しいエージェントが本番環境に導入されるたびに、推論用コンピューティング、ネットワークファブリック、セキュリティ制御が必要ですが、これらを提供しているのはモデルプロバイダーではなくAkamaiです。

Akamaiのエッジネットワーク、ランタイム適用機能、分散推論インフラは、AIにより実現するものと、企業がAIを安全かつ大規模に導入するために必要なものとの間の橋渡しになるように設計されています。現在は、そのような橋渡しがこれまでにないほど重要になっています。

このブログ投稿には、1933年証券法（改正）のセクション27Aおよび1934年証券取引所法のセクション21Eの意味における、将来の見通しに関する記述が含まれています。これらの記述には、AIエージェントの導入に起因するAkamaiの分散型インフラおよびセキュリティ製品の需要予測に関する記述、Akamai Inference Cloudおよびセキュリティポートフォリオの競合上の位置付け、マネージドAIエージェントの企業導入の成長予想、製品開発および市場の位置付けに関する当社の計画と戦略が含まれますが、これらに限定されません。「考える」、「なる」、「期待」、「意図」などの言葉は、将来の見通しに関する記述を特定することを目的としています。これらの記述は、現在の期待と想定に基づいており、AIエージェント技術の企業導入のペースと規模、AIインフラとセキュリティサービスの競合状況の変化、第三者によるAI機能開発スピード、Akamai Inference Cloudとセキュリティ製品の顧客採用率、進歩するAI関連のセキュリティ脅威に対する当社製品の有効性、一般的な経済状況および市場状況、SEC提出書類に記載されているその他の要因（Form 10-Kの最新年次報告書を含む）など、実際の結果が大きく変化するリスクと不確実性の影響を受けます。当社は、本投稿日以降の事象や状況を反映するために将来予想に関する記述を更新する義務を負いません。