ペイロード内のポリシー：AIエージェントアーキテクチャへの備え

AIエージェントは、アプリケーションとインフラストラクチャの連携方法を変えつつあります。従来のシステムとは異なり、エージェントは各リクエスト内に、何を実行するか、どのように復旧するか、何をもって成功とするかという独自の目標、コンテキスト、意思決定ロジックを保持します。この変化により、トラフィック管理に関する従来の前提が通用しなくなり、企業インフラストラクチャの再考が求められています。リクエストごとに自律性がある環境では、静的ルーティング、リソースプール、集中管理型ポリシーだけでは、もはや十分ではありません。

エージェントアーキテクチャでは、インフラストラクチャを、受動的な処理から、リクエストに組み込まれた意図をリアルタイムで解釈する仕組みへと進化させる必要があります。この変化を認識した企業は、既存の投資を破棄するのではなく、それらを適応させることで備えることができます。

はじめに

AIエージェントは、単なるインテリジェントなアプリケーションではありません。アプリケーションの動作、意思決定、適応のあり方を構造的に変える存在です。従来のシステムとは異なり、エージェントはトラフィックポリシーに従うだけでなく、独自のポリシーを備えています。エージェントが送信する各リクエストには、データだけでなく、何を実行すべきか、フォールバック時にどう動作すべきか、何をもって成功とするかというロジックも組み込まれています。

この変化により、意思決定は静的なコントロールプレーンからランタイム自体へと移行します。従来のコントロールプレーンとデータプレーンの分離が崩れ、ロードバランサー、ゲートウェイ、プロキシなどのトラフィックインフラストラクチャには、事前設定されたルートを受動的に実行するのではなく、リクエストごとのポリシーを解釈する役割が求められます。

本稿では、ヘルスチェックやフォールバックロジックからオブザーバビリティ、セキュリティポリシーの適用に至るまで、エージェントアーキテクチャがトラフィックエンジニアリングの主要な前提をどのように覆すかを考察します。また、リクエストごとに意図が異なる環境では、静的プールや平均値に基づく健全性指標といった従来の仕組みでは、もはや十分でない理由を説明します。さらに、レイヤー7インフラストラクチャは進化しなければ、信頼性は高くても戦略的には存在感のない、コモディティ化された配管のような存在になりかねないと論じます。これに適応するには、組織はトラフィックスタックを見直し、ランタイムでプログラム可能かつコンテキスト認識型にするとともに、Model Context Protocol（MCP）のようなエージェントネイティブのプロトコルに対応させる必要があります。これには、フォールバックロジックの再構築、セマンティックオブザーバビリティの導入、エージェントが生成したポリシーの適用への対応が含まれます。リアルタイムデータラベリングなどの新たなツールは、この移行を大きく支えます。

つまり、トラフィック管理の未来は、単にパケットを配信するだけでなく、その目的を実行することにあります。

エージェントアーキテクチャ：主な特性

エージェントアーキテクチャは、エージェントと呼ばれる自律型の生成AI搭載コンポーネントが、目標に沿ったタスクを実行し、リアルタイムで意思決定を行い、状況に応じて実行方法を柔軟に調整するために必要なコンテキストを保持するという、新たな運用モデルをもたらします。これらのエージェントは、現在のサービスチェイニングとよく似た役割を果たしますが、事前設定されたワークフローには依存しません。代わりに、目標、環境の状態、観測された結果に基づき、実行時に適切な実行フローを決定します。

この変化は、事前定義されたワークフローを中央でオーケストレーションする従来型システムから、実行パスをリアルタイムで構築できる分散型の動的システムへの移行を意味します。静的なマイクロサービスチェーンの予測可能性に代わり、リアルタイムデータと意図に基づく、柔軟で即応性の高い意思決定が行われます。

エージェントベースのシステムには、次のような特徴があります。

• 目標主導型の実行：エージェントは、静的なワークフローではなく、プロンプトやミッションに基づいて動作します。目標の達成状況に応じて、APIの選択、パラメーターの変更、処理経路の変更を行います。例：「顧客からの苦情を解決する」というタスクを処理するエージェントは、それまでの結果に応じて、請求、アカウント、メッセージングの各APIを異なる方法で呼び出す場合があります。
• ポータブルなコンテキスト：エージェントは、独自のメモリ、状態、ポリシーを保持します。Model Context Protocol（MCP）または構造化メタデータを介して、このコンテキストを各リクエストに埋め込みます。
• 実行時の適応： インフラストラクチャによる判断を待つのではなく、エージェントがその場で適応し、リアルタイムで再試行、再ルーティング、エスカレーション、実行パスの調整を行います。
• 組み込みのオブザーバビリティ：すべてのアクションには、その内容を示す情報が付随します。エージェントは、特定のパスを選択した理由、評価した内容、目標を達成したかどうかを報告できます。これは、単なるログやメトリクスではなく、振る舞いとしてのオブザーバビリティです。

これらが相まって、アプリケーション環境は予測可能なものから、適応し進化するものへと変化します。

従来のトラフィック管理への影響

現在のトラフィック管理システムは、明確な境界を前提に構築されています。

• The コントロールプレーンは、どのエンドポイントが有効か、どのパスを優先するか、どのポリシーを適用するかという意図を定義します。
• The データプレーンは決定事項を実行します。リクエストをルーティングし、セキュリティを適用して、負荷を分散します。

このモデルは、特にサービス指向アーキテクチャやマイクロサービス環境において、数十年にわたり有効に機能してきました。これは、トラフィックフローを事前にモデル化でき、ワークロードが予測可能なパターンに従うことを前提としています。

例：

• ロードバランサーは、/api/loginを一方のプールに、/api/imagesをもう一方のプールにルーティングします。
• ヘルスチェックにより、ノードは利用可能または停止中としてマークされます。
• 静的しきい値によってフェイルオーバー条件が決まります。

これらのシステムは、以下に依存します。

• ポリシーおよび構成と静的リソースの密結合（特定のプールやメンバーなど）
• 静的な構成要素（プールやメンバーなど）
• 決定論的ルーティング（パス、ヘッダー、またはプロトコルに基づく）
• 一元化されたオーケストレーション：サービスディスカバリ、ヘルスチェック、フォールバックロジックに対応

しかし、エージェントベースのシステムには、流動性、自律性、自己主導型のロジックが伴うため、こうした前提は成り立たなくなります。

エージェントアーキテクチャでは、コントロールプレーンとデータプレーンの従来の分離が崩れ始めます。エージェントは単にリクエストを実行するだけではありません。リクエストの内容、フォールバックをトリガーする条件、成功の測定方法、さらには優先すべき経路を定義するロジックを組み込みます。これらは従来、コントロールプレーンが担う事項でしたが、エージェントはそのロジックをヘッダー、トークン、またはメタデータにエンコードし、リクエスト自体とともにデータプレーンを通過させます。

この融合により、データプレーンは、中央で下された決定を受動的に実行するだけでは不十分になります。状況に応じてポリシーを能動的に解釈しなければなりません。リクエストはもはや単なるパケットではなく、ポリシーを具現化したものです。そのため、ロードバランサー、ゲートウェイ、ルーティングレイヤーは、受動的に反応するコンポーネントから、エージェントが伝える意図をリアルタイムで解釈するコンポーネントへと進化する必要があります。

この変化により、コントロールプレーンは静的かつ一元的であるという、アーキテクチャの根幹をなす前提が崩れます。代わって、意思決定ロジックは分散化され、移植可能かつ個別化されたものとなり、各リクエストとともに伝達され、実行時に処理されます。これは単なるデプロイ方法の変更ではなく、意思決定が行われる場所と方法そのものの変化です。

これは、Kubernetesがネットワーク、ストレージ、さらにはL4トラフィックルーティングまで、基盤となるインフラストラクチャを抽象化し、宣言型の制御インターフェースの背後にある「配管」へと変えた取り組みを、事実上完成させるものです。Kubernetesはこれらのレイヤーを排除したのではなく、その位置付けを下げました。これらは表から見えなくなり、自動化され、新たなインテント駆動型システムに従属するものとなりました。

エージェントアーキテクチャは、インフラストラクチャだけでなく、スタック全体に対して同じことを行います。

トラフィック管理に重大な支障

こうした障害を実際の例に即して理解するために、ローカル環境でのアプリケーションデリバリーのシナリオを考えてみましょう。

例：ある地域のeコマースサイトでは、ADCを使用して内部APIトラフィックを管理しています。AIエージェントには、注文処理速度を最適化するタスクが割り当てられています。このエージェントは、特定のAPIエンドポイント（例：/api/inventory/check）で、リクエストの複雑化とバックエンドデータベースの競合によりパフォーマンスが低下していることを特定します。「最速応答」を含む従来の負荷分散アルゴリズムでは、このパフォーマンス低下の微妙な違いを捉えられません。これは、タスク単位や呼び出し単位ではなく、特定のプールメンバーに対するすべての応答の全体的な平均としてパフォーマンスを算出するためです。

SLAを満たすため、エージェントはこれらの在庫確認リクエストを、トランザクションクエリ向けに最適化された別のノードグループへ再ルーティングします。その際、各リクエストに次のようなコンテキストヘッダーを付与します。X-Task-Profile: inventory-sensitive。ロードバランサーが適切に設定されていれば、このヘッダーを解釈し、それに応じてトラフィックを転送できます。ただし、これらのノードは、/api/inventoryに関連付けられた静的プールに事前に割り当てられていないため、トラフィックステアリングサービスには、エージェントが付与した指示に従い、静的な構成に依存せずにルーティングを動的に決定できる機能が必要です。

このシナリオは、プールのような静的構成の限界と、コンテキストを認識し、動的にプログラム可能なトラフィック処理の必要性を浮き彫りにしています。

エージェントベースのシステムは、トラフィックエンジニアリングにおけるいくつかの基本的な前提を覆します。

制御プレーンとデータプレーンの融合：従来、ルーティングの判断は静的ルールに基づいていましたが、現在ではリクエスト自体に基づいて行われます。これにより、従来の適用ロジックが成り立たなくなります。

インテントベースルーティング：エージェントは、エンドポイントだけでなく、目標に基づいてトラフィックをルーティングします。たとえば、単一のエンドポイントである「/api/process」が、エージェントの指示に応じて数百もの異なるタスクフローを処理する場合があります。

静的プールの陳腐化：従来のプールは、役割が固定されていることを前提としています。しかし、エージェントは、ある時点ではGPUへのアクセスを必要とし、次の時点ではCPUの最適化を必要とする可能性があるため、固定的なプール構成では柔軟に対応できません。

フォールバックとフェイルオーバーが戦略的に：従来、フェイルオーバーは「次のサーバーを試す」ことを意味していました。現在では、エージェントがリアルタイムのパフォーマンスと過去の結果を評価し、今後の対応を戦略的に決定します。

トラフィックパターンは繰り返されるのではなく、その都度形成される： エージェントはオンデマンドでワークフローを作成します。すべての経路を事前に定義することはできず、ニーズに応じて形成されます。

こうした変化により、ロードバランサー、ゲートウェイ、オブザーバビリティスタックには、流動的でリアルタイムに変化するトラフィックロジックへの対応が求められます。

健全性とパフォーマンスの指標を再考する

健全性とパフォーマンスの指標は、常にトラフィック管理の基盤となってきました。負荷分散の判断には、サーバーが利用可能か、応答速度はどの程度か、負荷はどの程度かを把握する必要があります。しかし、エージェント駆動型システムでは、健全性を二者択一で判断することはできず、パフォーマンスを大まかなカテゴリー単位で平均化することもできません。指標には、単に稼働しているかどうかではなく、ターゲットが特定のタスクに適しているかどうかを反映する必要があります。

重要な理由：ヘルスメトリクスは、トラフィックの振り分け、フェイルオーバーの判断、パフォーマンスの最適化に直接影響します。エージェントネイティブ環境では、リクエストごとに意図が異なり、異なる経路や応答保証が必要になる場合があります。従来のアプローチでは、次の理由からこのニーズに対応できません。

• 従来のアプローチは、タスク固有のばらつきを覆い隠す表面的な集計値（平均応答時間など）に依存しています。
• 評価対象は、サーバーの観点から見た健全性のみであり、エージェントレベルでの成功や満足度については把握できません。
• これらは、トラフィックが均質であることを前提としていますが、実行時の意思決定によってリクエストが形成される場合、この前提は成り立ちません。

例：APIサーバーのプールは、ヘルスチェック上はすべて「正常」であっても、そのうちの1台が、X-Task-Profile: inventory-sensitiveクエリに対して一貫して100 ms未満で応答できない場合があります。このレイテンシープロファイルを期待するエージェントは、インフラストラクチャ側では正常と認識されていても、障害と判断します。

必要なもの：

• 意図と観測された結果を反映する、リクエスト単位のリアルタイムテレメトリ。
• ノードが他のタスクでは正常であっても、一部のタスクでは性能が低下していることを認識する、タスク固有の健全性スコアリング。
• エージェントから報告された成功または失敗を、ルーティングおよび優先順位付けのロジックに反映するフィードバックループ。

ここでは、データラベリングツールが、転送中のトラフィックにラベルを付け、パフォーマンスとコンテキストとの整合性を把握するうえで重要な役割を果たします。これにより、システムは単に「何が起きたか」だけでなく、「それを開始したアクターの目標を達成できたか」まで判断できるようになります。

エージェントアーキテクチャにおけるフォールバック、サーキットブレーカー、再試行機能

従来のインフラストラクチャでは、再試行、バックアップノードへのリダイレクト、サーキットブレーカーの作動といったフォールバック動作は、インフラストラクチャ層に実装されます。ロードバランサー、プロキシ、ゲートウェイは、事前定義されたしきい値（タイムアウト、エラー率など）に基づいて、対象へのトラフィックのルーティングを停止し、代替先へのルーティングを試行するタイミングを判断します。

エージェントアーキテクチャでは、そのロジックが逆転します。

エージェントには、独自のフォールバック戦略があります。リクエスト自体に、再試行ポリシー、エスカレーションロジック、目標を重視した優先順位が含まれています。そのため、複雑さが増し、インフラストラクチャレベルのフェイルオーバーメカニズムと競合する可能性があります。

重要な理由：

• インフラストラクチャは障害を回復可能と判断する一方で、エージェントは許容できないと判断する可能性があります（またはその逆の場合もあります）。
• エージェントとインフラストラクチャの両方が同時にフォールバックを試みる可能性があり、その結果、重複した再試行、レイテンシーの増大、トラフィックループが発生することがあります。
• 平均的なトラフィックを想定して設計されたサーキットブレーカーにより、エージェントが依然として最適と判断するサービスへのアクセスが遮断される可能性があります。

主なリスク：

• 二重フォールバック：エージェントとインフラストラクチャの両方が再試行するため、不要な負荷が発生します。
• 競合状態：システム側では数ミリ秒以内に問題を解決できたにもかかわらず、エージェントがより高コストまたは安全性の低い選択肢に切り替えます。
• 決定論的フェイルオーバーの破綻：静的ポリシーでは、エージェントの微妙な判断の違いに対応できません。
• 破損：エージェントのメタデータが不正な形式であるか、欠落しているか、読み取れません。

適応に関するガイダンス：

• インフラストラクチャは、エージェントが指定したフォールバックの優先順位を認識できるように進化させる必要があります（例：X-Fallback-Order、X-Timeout-Preferenceを使用）。
• サーキットブレーカーは、グローバルしきい値ではなく、タスク単位またはエージェント単位のロジックをサポートできるよう、インテントを認識する必要があります。
• エージェントが優先する戦略を提案し、ゲートウェイがシステムの健全性、負荷、ポリシーに基づいて調整する、ネゴシエーション対応のフェイルオーバーロジックの導入を検討してください。
• エージェントのメタデータが欠落している、不完全である、またはスキーマ検証に失敗した場合にグレースフルデグラデーションを確保できるよう、トラフィックシステムはデフォルトの実行ロジックをサポートする必要があります。
• インフラストラクチャは、システムの機能低下時にループを引き起こしたり、トラフィックを増幅させたりする可能性がある再帰的な委任や、競合するエージェントの再試行を検出して防止する必要があります。

例：リアルタイムの不正チェックを担うエージェントが、50 ms以内の応答を要求するとします。そのフォールバックロジックでは、時間のかかる完全なクエリよりも、キャッシュされた部分的な結果が優先されます。この点を認識していないインフラストラクチャは、フルサービスのバックエンドにルーティングし、ユーザーが認識できる遅延を引き起こす可能性があります。より協調的なモデルであれば、エージェントのフォールバック優先順位を尊重し、より高速な縮退応答を返します。

意思決定がスタックの上位層へ移るのに伴い、フォールバック戦略も上位層へ移行する必要があります。サーキットブレーカーと再試行ロジックを固定的または不透明なままにすることはできません。システム全体の安全性と公平性を維持しながら、エージェントが示す優先事項に適応させる必要があります。

高可用性とフェイルオーバーは今なお重要

エージェントアーキテクチャでは、意思決定と調整がリクエストレイヤーに移行しますが、基盤となるインフラストラクチャは引き続き、システムの中核的な信頼性を確保する役割を担います。そのため、インフラストラクチャレイヤーにおける高可用性（HA）とフェイルオーバーの仕組みは、今後も不可欠です。実際、システムの動作がより動的かつ自律的になるにつれて、その重要性はさらに高まります。

エージェントは目標やコンテキストに基づいてトラフィックを振り分けることがありますが、障害発生時にもサービスへの到達性とレジリエンスを維持するには、依然としてネットワークに依存します。ロードバランサーは、エージェントのフォールバック戦略にかかわらず、到達不能なノード、障害が発生しているサービス、または性能が低下した環境を検出し、リアルタイムでトラフィックを再ルーティングする必要があります。

変わることのない中核的な役割：

• プールメンバーとバックエンドサービスの正常性を監視する
• ネットワーク分断やルーティング障害を検出
• 稼働状態、可用性、またはシステムレベルの性能低下に基づいてトラフィックをリダイレクト
• 必要に応じて、ステートフルなサービスやセッションのHAを維持

エージェントが「次に何をすべきか」を判断するロジックを備えている場合でも、ノードがダウンした際の復旧速度は、引き続きロードバランサーが担います。

適応型でエージェントを認識するルーティングロジックを導入する際も、運用の安定性を損なわないことが不可欠です。十分な計測機能を備えたインフラストラクチャでは、以下を維持する必要があります。

• ノードが利用できなくなった場合の即時フェイルオーバーとトラフィックの再分散
• 上流の障害からエージェントとサービスを保護する、耐障害性に優れたHAトポロジ
• エージェントのフォールバックロジックと競合せず、それを補完する迅速な自動復旧

つまり、エージェント駆動型アーキテクチャによってフェイルオーバーが不要になるわけではなく、その重要性はむしろ高まります。インフラストラクチャには、自律的な動作のボトルネックになることなく、より迅速かつ状況に応じて的確に対応することが求められます。

エンタープライズトラフィック管理への影響

エージェントベースのアーキテクチャへの移行により、ロードバランサーやゲートウェイなどのトラフィックシステムに求められる動作は根本的に変わります。従来のトラフィックシステムは、リクエストの外部に置かれることが多い事前設定済みのポリシーに基づいて判断していましたが、エージェント駆動型システムでは、そのポリシーをリクエスト自体に組み込みます。これが、Model Context Protocol（MCP）によって可能になる、埋め込みポリシーのリクエスト単位での実行の基盤です。

このモデルを「ペイロード内ポリシー」と呼びます。中央集約型システムですべてのエッジケースを解析するのではなく、エージェントが関連するポリシー判断（フォールバック戦略、ノードの優先順位、エラー許容度、プライバシー要件など）を各リクエストに組み込みます。その後、インフラストラクチャはそれらのポリシー指示を読み取り、解釈し、リアルタイムで実行する必要があります。

この新しい実行モデルにより、トラフィック管理コンポーネントの役割は次のように変わります。

• 判断主体から実行主体へ：インフラストラクチャはトラフィックの転送先を決定するのではなく、エージェントが伝達する決定を適用します。例：ロードバランサーが「X-Route-Preference: gpu-optimized」を読み取った場合、そのノードが元のプールに含まれていなくても、その指定に従ってトラフィックを転送する必要があります。
• 実行時にプログラム可能：iRulesとポリシーは、X-Intent、X-Context、X-Goalなどのヘッダーを評価する必要があります。これにより、ロジックは事前設定されたパスから、動的なインライン解釈へと移行します。
• コンテキスト認識型ルーティング：ADCや同様のサービスでは、ホストやパスだけでなく、アイデンティティ、意図、コンテキストに基づいてルーティングする必要があります。
• セマンティックオブザーバビリティ：ログには、何が起きたかだけでなく、その理由も示す必要があります。たとえば、「レイテンシーがしきい値を超えたため、エージェントがルーティング先を変更」の方が、単に「プールBにルーティング」

データラベリング技術や同様のツールは、リアルタイムのリクエストコンテキストにタグを付けて分類することで、この移行を支援し、セマンティックルーティングとオブザーバビリティを実現しやすくします。

エージェントアーキテクチャに対応するエンタープライズインフラストラクチャの準備

AIエージェントは単独で動作するものではありません。レガシーシステムと連携し、従来型のAPIを利用し、企業データベース内のビジネスロジックを操作するほか、モノリシックなバックエンドやマイクロサービスでホストされている関数を呼び出します。企業には、ゼロから構築し直すのではなく、既存のインフラを進化させることが求められます。

現実：エージェントはあらゆるものと連携する

エンタープライズスタックは、以下の要素で構成されています。

• 財務業務で今も使用されている数十年前のSOAP API
• Webアプリケーションを支えるRESTfulサービス
• 非同期在庫管理システム向けのメッセージキュー
• クラウドネイティブなマイクロサービス
• レート制限と複雑な認証を伴うSaaS API
• LLMとファインチューニング済みエージェント

エージェントは、そのすべてを横断して機能する方法を学習する必要があります。また、インフラストラクチャは、コンテキストに応じたポリシー適用により、そのやり取りをリアルタイムで仲介できるようになる必要があります。

エンタープライズチームが準備すべきこと

1. インテントに対応しやすいインターフェースを通じて社内システムを公開する

エージェントが必要としているのは、5つのエンドポイントではなく、1つの目的を達成する手段です。ビジネス機能（例：「注文状況を取得」）を抽象化レイヤーまたはAPIコンポジションを介して公開し、エージェントが単一のセマンティックエントリーポイントから利用できるようにします。

準備手順：APIゲートウェイまたはサービスメッシュを使用して、明確な入出力コントラクトを備えたタスク指向のエンドポイントを統合します。

2. メトリクスだけでなく、コンテキストも把握できるよう計測する

従来のロギングでは、メソッド、パス、応答時間が重視されます。一方、エージェントが重視するのは次の点です。

• タスクの内容
• どのフォールバックを試みたか
• 目標が達成されたかどうか

準備手順：トラフィックに「X-Intent」、「X-Task-Type」、「X-Agent-Outcome」などのラベルを付与するセマンティックオブザーバビリティツールを導入します。

3. 組み込みポリシーの実行時評価をサポート

エージェントは、フォールバック指示、タイムアウト設定、セキュリティ要件をリクエストに含めます。既存のインフラストラクチャでは、このデータは破棄されます。

準備手順： エージェントのメタデータ（例：X-Route-Preference、X-Fallback-Order、X-Data-Class）を解析し、それに基づいて処理できるようにトラフィックポリシーを拡張します。まずはiRulesまたは同様のランタイムスクリプティングを使用します。

4. アクセス制御とガバナンスを再構築

エージェントは自律的に動作します。以下を把握する必要があります。

• どのエージェントが誰の代理として動作しているか
• アクセス可能なツール
• アクセスが許可されているデータの範囲

準備手順：IPアドレスの許可リストや静的なRBACだけでなく、IDベースのアクセス制御と属性ベースのポリシー制御（ABAC）を統合します。

5. フォールバックと再試行のロジックを分離する

インフラストラクチャとエージェントが、互いに先を争って復旧を試みることがないようにします。一方がランタイムの目標を担い、もう一方がシステム全体の保護策を適用するようにしてください。

準備手順：エージェントのフォールバック範囲（エージェントが制御する対象）と、インフラストラクチャのフェイルオーバー（自社が管理する対象）を明確に分けます。調整ルールとオーバーライド条件を定義します。

まとめ

AIが個別のモデルから自律型エージェントへと成熟するなか、企業は戦略的な転換点を迎えています。これらのエージェントは、何もない環境で稼働するわけではありません。既存のアプリケーションと統合し、レガシーAPIを呼び出し、重要なビジネスシステム全体の意思決定を促進します。そのため企業は、新しいツールを導入するだけでなく、アーキテクチャが意図、実行、ガバナンスをどのように扱うかを見直し、エージェントをサポートする準備を今から進める必要があります。

今は、既存システムを全面的に刷新する局面ではありません。従来のシステムと新たなエージェントの動作が、意図に沿って正確に相互運用できるよう、両者を融合させる局面です。

エージェントアーキテクチャの時代が到来しようとしています。今から備える企業は、後れを取らないだけでなく、業界をリードできるでしょう。

LORI MACVITTIE

2025年7月1日公開