エージェントは、ソフトウェアの構築・デプロイ・運用のあり方を大きく変えつつあります。

ソフトウェアスタックのあらゆるレイヤーが、エージェントを前提に書き換えられています。ビルドパイプラインでは、コードのリファクタリングを担うエージェントが動き始めました。インシデント対応の現場では、アラートを切り分けるエージェントが立ち上がります。データチームでは、データウェアハウスへの突発的な問い合わせに答えるエージェントが活躍しています。顧客向けのチャット画面も、いつの間にかチャットボットの顔をした司令塔役のエージェントへと姿を変えています。

興味深いのは、個々のタスクが自動化されたという事実そのものではありません。LLM が登場するずっと前から、多くの個別タスクはすでに自動化されてきました。本当の変化は、タスクとタスクをつなぐ「のりしろ」の部分、つまり推論し、計画を立て、次にどのツールを呼び出すかを判断するという作業を、ソフトウェア自身が担えるようになったことです。エージェントは、これまで人の手を介さなければ進まなかったワークフロー全体を、ひとつの対話ループの中に圧縮してしまいます。

この圧縮は、あらゆる現場にプレッシャーをもたらします。開発者の一日の過ごし方、運用チームが監視すべき対象、セキュリティチームが脅威モデルとして検討すべき範囲、そしてデータチームが公開すべきデータの内容。そのすべてが変わります。エージェンティックアーキテクチャは、単なるプロダクト上の意思決定ではありません。システム設計の問題であり、組織設計の問題でもあるのです。

このブログシリーズでは、まずエンタープライズ向けエージェンティックアーキテクチャの構成要素から見ていきましょう。次回の記事では、Google Cloud Platform 上で構築されたエージェンティックアーキテクチャを取り上げ、AI-Ready データレイヤーの重要性に光を当てていきます。

エージェントの実行環境：デスクトップ型コーディングエージェント vs. クラウドエージェント

エージェントの導入パターンは大きく 2 つに分かれますが、両者の姿はほとんど別物と言ってよいほど異なります。

デスクトップエージェントはローカルで動作します。Claude Code、Cursor、Windsurf、Gemini CLI、Codex といったツールは、開発者のマシン上で実行され、ローカルファイルシステムからリポジトリを読み込みます。シェルコマンドはサンドボックス化されたターミナルで実行し、操作対象には開発者本人の認証情報を使います。状態は一時的か、ファイルとして保持される程度です。信頼モデルもシンプルで、要するに「開発者は自分自身を信頼している」という前提に立っています。並行実行は基本的に、開発者 1 人につき 1 セッション・1 エージェント。ただし最近では、複数セッションのコーディングエージェントを同時に走らせるなど、限界に挑む開発者も出てきました。エージェントの影響範囲は、開発者のワークステーションから手の届く範囲に収まります。

クラウドエージェントは、他社のインフラストラクチャ上で長期稼働するサービスとして動作します。多数のユーザーからのトラフィックをさばき、プールされた LLM のキャパシティを共有しながら、セッションをまたいでメモリを永続化します。エンタープライズシステムへのアクセスには、マネージドサービス ID を使います。状態はマネージドストアに保持されます。信頼モデルは設計の段階からマルチテナントが前提です。ユーザー A のために動いているエージェント A が、ユーザー B のためのエージェント B のセッションに漏れ出すようなことは、決してあってはなりません。並行実行の規模は、数千の同時会話という単位で測られます。影響範囲は、IAM とネットワーク境界が許容する範囲に閉じ込められます。

クラウドエージェントアーキテクチャは、見た目こそ AI ですが、その実体は分散システムの問題です。エンジニアリング上の難所のほとんどは、プロンプトの中にはありません。必要なときに、エージェントへ適切なコンテキストを届ける、その仕組みのなかにあります。

エージェント用ハーネス

ハーネスとは、LLM への呼び出しをエージェントへと変えるためのランタイムの足場です。セッションのライフサイクル、ツールの呼び出し、メモリの永続化、リトライ処理、ストリーミング、ガードレール、テレメトリ、そしてタスクに対して連携する複数の専門エージェントのオーケストレーション。これらをまとめて引き受けます。ハーネスがなければ、手元にあるのは LLM とプロンプトだけです。ハーネスがあれば、計画し、実行し、記憶し、回復できる「何か」が手に入ります。ハーネスの主な役割は、LLM に適切なコンテキストを届けることです。そのコンテキストをもとに LLM が推論し、次に取るべき最適な行動を導き出します。

ハーネスは、エージェントを作り始めたばかりの人が見落としがちな部分です。LLM はもちろん中心的な存在ですが、同時にスタックの中で最もコモディティ化が進んでいる部分でもあります。エンジニアリング上の意思決定が積み重なるのは、むしろハーネスの側です。どのメモリストアを選ぶか、どのツールプロトコルにするか、どのトレース形式を採用するか、どのアイデンティティモデルを使うか、どの評価パイプラインを組むか。その一つひとつが後になって効いてきます。本番運用が始まって半年ほど経った頃、午前 2 時に何かが壊れたタイミングで、ようやくその影響が表に出てくるのです。

ハーネスは、インフラストラクチャの中でも特に変化の速い領域です。AI エコシステムの急速な進歩によって、ハーネスを構成するコンポーネントは絶えず入れ替わっています。何ヶ月もかけてハーネスを作り上げた企業が、気づけば多くのコンポーネントを書き直す羽目になっていたり、最新の LLM モデルのアップデートによってその部分がコモディティ化されていたり。そんな事態が起きています。この問題については、以前の「メタハーネス」についてのブログで、ハーネスの進化にどう向き合うかを詳しく取り上げています。

既成のハーネス vs. プロコードによる組み立て

ハーネスを用意する方法は、大きく分けて 2 つあります。

既成のハーネスは、ほぼ組み立て済みの状態で届きます。ベンダーがランタイム、メモリストア、オーケストレーション、アイデンティティモデル、UI、可観測性、そして主要なエンタープライズシステム向けのコネクタ群までを提供してくれます。ユーザーは周辺部分をカスタマイズしていきます。独自のツールを追加したり、ベンダーのフレームワーク上で独自のエージェントを定義したり、自社のビジネスコンテキストを注入したり。とはいえ、ハーネスに関する重要な決定の大半はすでに済まされた状態です。これらは SaaS 製品です。ユーザーは、他社のエージェントプラットフォーム上のテナントという立場になります。

プロコードによる組み立てとは、コンポーネントを自分の手で配線していくアプローチです。コンピュートランタイム（Cloud Run、GKE、Agent Engine）、セッションストア（Firestore、Memorystore）、メモリ戦略（RAG エンジン、Vertex Vector DB、独自実装）、ツールプロトコル（MCP、関数呼び出し、OpenAPI）、トレースシステム（Cloud Trace、OpenTelemetry、Datadog）、アイデンティティモデル（IAM、ワークロード ID、サービスアカウント）。これらをすべて自分で選んでいきます。引き換えに得られるのは、完全な制御権と、それと表裏一体の全責任です。Google Agent Development Kit (ADK)、LangGraph、CrewAI といったフレームワークはこちらのカテゴリーに属します。これらが提供するのは完成品ではなく、組み立てるためのプリミティブ（基本部品）です。Agent Engine は、プロコードで構築した ADK のデプロイをスケールさせる際に着地先となるマネージドランタイムです。あくまでデプロイ先であって、ハーネスそのものではありません。

この 2 つのうちどちらを選ぶかは、たいてい「スタックのどこまで自分の都合に合わせて曲げる必要があるか」という問いに行き着きます。既成のハーネスはデプロイが速い反面、カスタマイズできるのは周辺部分にかぎられます。プロコードによる組み立ては本番到達までに時間がかかりますが、そのぶん、すでに運用しているレガシーインフラストラクチャと密に連携する自由度が手に入ります。SaaS 型ハーネスベンダーがまだコネクタを用意していないツールやデータも、自分たちで公開できるようになります。

既成のハーネスの例

既成のハーネスが実際にはどのようなものか、いくつか見ていきましょう。

• Google Gemini Enterprise — エンタープライズユーザー向けに Google が提供するマネージドエージェントプラットフォームです。Vertex AI Agent Builder を基盤としつつ、フレームワークというよりプロダクトとしてパッケージ化されています。Workspace との統合、Google Drive を対象としたエンタープライズ検索、ユーザー向け UI が標準で備わっています。管理者は従業員が利用できるエージェントを管理し、従業員は Gemini ブランドの画面を通じてエージェントとやり取りします。

• Claude Managed Agents — Anthropic が提供するマネージドエージェントサービスです。Claude が推論ループ、ツール呼び出し、セッション状態、コネクタ層をまとめて担います。利用企業は自社データ用の MCP サーバーを接続し、プロンプトとツール定義を通じてエージェントの振る舞いを設定します。

• Salesforce Agentforce — Salesforce のデータモデルを中心に構築されたハーネスです。エージェントは Salesforce の信頼境界の中に存在し、Salesforce オブジェクトに対してネイティブに推論を行い、Salesforce プラットフォームの権限モデルを通じて動作します。カスタマイズは Flow、Apex、プロンプトテンプレートを使って行います。

• Microsoft 365 Copilot Agent Builder / Copilot Studio — Microsoft Graph の上に重ねられた、Microsoft 製のハーネスです。エージェントは M365 テナント内で実行され、ユーザーとして認証を受け、Graph を介して Outlook、Teams、SharePoint、Dynamics にアクセスします。カスタムエージェントはローコードツールで定義し、Copilot の画面に公開します。

• ServiceNow AI Agents / Now Assist — ServiceNow プラットフォームのデータモデルを中心に構築されたハーネスで、IT サービス管理やワークフロー自動化のユースケースを主な対象としています。

それぞれが、独自の考え方を内側に組み込んだうえでハーネスの問題を解決しています。共通しているのは、ベンダーがランタイム、オーケストレーション、メモリ、UI、アイデンティティモデルを所有しているという点です。一方で企業側が所有するのは、プロンプト、カスタムツール、そしてガバナンスポリシーです。この役割分担は明確で、先の見通しも立てやすくなっています。LLMOps のプラットフォームチームを編成する余裕はないけれど、まずは速く動き出したい。そうしたチームにとって、既成のハーネスが魅力的に映るのはまさにこのためです。

その代わりに手放すことになるのは、制御の細やかさ、ベンダーのコネクタライブラリの範囲を超えた連携のしやすさ、そして同じエージェントアーキテクチャを複数のクラウドやオンプレミス環境にまたがって動かすための柔軟性です。ここで Agent Engine + ADK のようなプロコードによる組み立てが、最適な選択肢として浮かび上がってきます。次回のブログでは、この点を詳しく取り上げていきます。

Connect AI による、エージェンティックアーキテクチャ向けのガバナンス付きデータアクセス

エージェンティックアーキテクチャをどのように構築するにしても、CData の社内ベンチマークでは、適切なデータレイヤーがあればエージェントの精度を 98.5% まで引き上げられることが分かっています。CData Connect AI は、エンタープライズ AI 向けのガバナンス付きデータレイヤーです。MCP を通じて 350 を超えるエンタープライズデータソースに、AI エージェントからリアルタイムでアクセスできるようにします。

本シリーズの次のブログ記事で、Connect AI が Google Cloud Platform とどう連携するのかをご覧いただくか、無償トライアルを開始して、ご自身の環境で確かめてみてください。

※本記事は CData US ブログ What Is an Enterprise Agentic Architecture? の翻訳です。