【ITニュース解説】Orchestrating Real-World Agent Workflows with MCP

現代のIT分野では、大規模言語モデル（LLM）の進化が目覚ましい。LLMとは、人間が使う言葉を理解し、生成できるAIモデルのことで、これまでのコンピューターには難しかった自然な会話や文章作成ができるようになった。このLLMの登場により、「AIエージェント」という新しいタイプのアプリケーションが注目されている。AIエージェントとは、LLMを頭脳として持ち、自分で状況を判断し、必要な行動を取ることができるAIのことだ。たとえば、顧客からの問い合わせを理解して適切な部署に連絡したり、システムのエラーを検知して自動で修復を試みたりといった、複雑な多段階のタスクを自動化することが期待されている。

しかし、実際にAIエージェントを開発する段階では、多くの課題に直面する。アイデアを形にするプロトタイプは比較的簡単に作れるものの、それを企業で実際に使う「セキュアで信頼性が高く、本番環境で動作する」システムとして展開するのは非常に難しい。AIエージェントが、様々な社内システムや外部のサービス（例：顧客管理システム、プロジェクト管理ツール、コミュニケーションツールなど）と連携する必要があるからだ。これらのシステムはそれぞれ異なる方法で動作しており、それらを安全かつ確実に連携させるための「共通のルール」が存在しなかった。

そこで登場したのが、アンソロピック社が開発したオープンな標準規格である「Model Context Protocol（MCP）」だ。MCPは、LLMが外部のツール、API（アプリケーション・プログラミング・インターフェース：ソフトウェア同士が情報をやり取りするための窓口）、そしてデータソースと、安全かつ標準化された方法でやり取りできるようにするための仕組みを提供する。これは、異なる言語を話す人々が共通の通訳を介してスムーズにコミュニケーションするようなイメージである。

このMCPの重要性を具体的に示す事例として、ジェントロ社が開発したシステムが挙げられる。彼らは、MCPを活用して、企業内にある「整理されていない情報（例：大量のチャットメッセージ）」と、「構造化された自動ビジネスワークフロー」との間の隔たりを埋めることに成功した。

一般的な企業が抱える問題の一つに、コミュニケーションやデータが様々な場所に散らばってしまっているというものがある。例えば、あるB2C（企業対消費者）向けの音楽プラットフォームでは、200人以上のミュージシャンがたった一つのSlack（ビジネスチャットツール）チャンネルを使ってやり取りしていた。このチャンネルは、日常会話から人事問題、スタジオ機器のトラブルなど、あらゆる情報がごちゃ混ぜになり、「情報の火の海」のような状態だった。毎日200件以上のメッセージが投稿され、本当に重要な問題が膨大なチャットの中に埋もれてしまうことが日常茶飯事だった。運用のチームはこれらのメッセージを分類する仕組みを持たず、問題解決に必要な情報も、営業用のHubSpotやプロジェクト管理用のNotionといった別のシステムに散らばっていた。

これは、企業のシステム連携における「ラストマイル問題」と呼ばれる典型的な課題だ。LLMは自然言語（人間の言葉）を分類することには非常に優れているが、それだけでは異なるプラットフォーム上で具体的な行動（例：チケットを作成する、ユーザーに返信する）を実行することはできない。これには、安全かつ標準化された方法が必要だった。

ジェントロ社の解決策は、MCPの基本的な考え方に基づいている。まず、Slackにメッセージが投稿されると、それがトリガー（引き金）となり、ワークフローが開始される。このメッセージは、ジェントロが提供する「ツールボックス」に送られる。ツールボックスとは、MCPに対応した様々なツールの集合体である。ツールボックスの内部にいる「オーケストレーションエージェント」というAIが、その推論能力を使ってメッセージの内容を分析し、「製品のバグ」「スタジオの問題」「人事の問題」といった具体的なカテゴリに分類する。

この分類に基づいて、エージェントは異なるMCPツールを介して、事前に定義された特定のアクションを実行できる。例えば、製品のバグに関するメッセージであれば、エージェントはNotionツールを使って新しいチケットを作成し、適切なチームメンバーにタグ付けする。同時に、顧客サポートに関する問題であれば、HubSpotツールを使ってそちらにもチケットを作成し、さらにSlackツールを使ってユーザーに確認メッセージを送信したり、関係する内部チャンネルに要約を送ったりする。

このようにして、これまでバラバラで混沌としていたデータの流れが、構造化され、自動化され、そして後から確認可能な（監査可能な）プロセスへと生まれ変わるのだ。

MCPは、AIエージェントアプリケーションの開発と展開を簡素化するための抽象化レイヤーを提供する。抽象化とは、複雑なシステムの詳細を隠し、より高レベルで扱いやすいインターフェースを提供することだ。MCPは、「MCPホスト（LLMアプリケーションやAIエージェント）」と、「MCPサーバー（外部の機能をツールとして提供するサービス）」間の通信に関する正式な仕様を定義している。

このユースケースを可能にするMCPの主要な機能はいくつかある。 一つ目は「標準化されたツール発見」だ。MCPを使うと、AIエージェントは利用可能なツールの機能（何ができて、どう使うのか）を動的に発見し、理解できる。これは、開発者が個々のAPIエンドポイント（APIの具体的な機能を示す場所）をすべて手作業でエージェントに教え込む必要がないことを意味する。ジェントロのプラットフォームは、様々なAPIから「ツールボックス」を自動生成でき、エージェントはそれらのツールを必要に応じてアクセスし、使用できる。

二つ目は「セキュアで宣言的な通信」である。MCPの通信は、どのような操作を行いたいかを明確に「宣言」する形式をとり、安全性が重視されている。JSON-RPC 2.0というメッセージ形式を使い、HTTPのような標準的な通信方法でやり取りされるため、リクエストとレスポンスが構造化され、信頼性が高い。また、プロトコルの設計には、ユーザーの同意やデータプライバシーに関する仕様も含まれており、特にデータセキュリティが最優先される企業での利用において非常に重要だ。

三つ目は「構成可能性」だ。このプロトコルは、複数のツールを組み合わせて（連鎖させて）一つの複雑なワークフローを構築できるように設計されている。音楽プラットフォームの事例では、オーケストレーションエージェントによる一つの「推論」が、Slack、Notion、HubSpotへの複数のツール呼び出しの連鎖を引き起こしている。このような多段階のプロセスは、MCPによってスムーズに管理される。

このようなアプローチは、AIエージェントアプリケーションを構築する従来のやり方と大きく異なる。以前は、個別のAPI連携をその都度開発したり、異なるサービスを接続するための「つなぎ合わせるための特別なコード（グルーコード）」を記述したりすることが多かった。LangChainやGoogleのAgent Development Kit (ADK) のようなフレームワークも、LLMを活用したアプリケーションのための抽象化を提供し、コンポーネントやツールを連携させる「チェーン」の概念を使っている。これらのフレームワークはAIエージェント開発の初期段階で非常に役立ったが、MCPは通信のためのより深い、低レベルな標準を提供する。ジェントロのアプローチは、MCP標準の上にプラットフォームを構築し、システムをゼロから実装する際に必要となる定型的なコードを抽象化することで、安全でスケーラブルな実行環境を提供できることを示している。

MCPのワークフローは、安全でスケーラブルな運用を可能にする明確なアーキテクチャに基づいている。まず、Slackメッセージが投稿されると、それがウェブフックとして機能するLambda関数（イベントに応じてコードを実行するクラウドサービス）を起動する。Lambda関数は、そのメッセージをジェントロのランタイム（MCPの機能を実行する環境）に転送する。メッセージは、事前に設定されたツールボックスによって受け取られる。ここで中心的な役割を果たすのが、強力なオーケストレーターツールだ。これは、音楽プラットフォームの「分類アシスタント」としての役割とプロンプト（AIへの指示）を与えられたLLMであり、メッセージの核心的な分類と推論を実行する。

ジェントロのプラットフォームの重要な機能の一つに、「ツールの自動生成」がある。既存のAPIや仕様（例：OpenAPI）から直接MCPツールを自動的に生成できるのだ。この生成プロセスは、開発者にとって大きな生産性向上につながる「ローコード（少ないコードで開発）またはノーコード（コードを書かずに開発）」のアプローチだ。開発者は、プロンプトで目的の機能を定義するだけで、プラットフォームがLLMを使ってツールのコード、スキーマ（データの構造）、API呼び出しを生成してくれる。

オーケストレーターの決定に基づいて、ジェントロのランタイムが必要なツールアクションを実行する。これには、Slack、Notion、HubSpotへのAPI呼び出しが含まれる。ランタイムは、各ツールの認証、ロールベースのアクセス制御（誰が何にアクセスできるかを管理する仕組み）、そして監視を管理する。例えば、Notionツールがチケットの作成はできるが、データベースの削除はできないように、アクセス権限を確実に制御する。

最後に、実行されたアクションの構造化された要約が、Slackの返信としてユーザーに返され、プロセス全体がジェントロのスタジオUIに記録される。これにより、AIエージェントのワークフローが「ブラックボックス（中身が見えないもの）」ではなく、透明で管理可能なシステムへと進化し、エンドツーエンドでの可視性と制御が提供される。

ジェントロによるこの実演は、Model Context Protocolが企業AIにとってなぜ不可欠なのかを強く示している。Slack、HubSpot、Notionといった多様なシステムを統合し、連携させる技術的な課題は決して簡単ではない。ジェントロの解決策は、API統合やセキュリティ管理といった低レベルの詳細を抽象化することで、この複雑さを効果的に簡素化している。これにより、開発者はより高レベルのビジネスロジック、つまり「何をしたいか」という本質的な部分に集中できるようになる。

重要な点は、AIエージェントの構築が「ローコード」や「会話型」のアプローチへと移行しつつあることだ。将来的にAIエージェントの開発は、手動でのコーディングが減り、より宣言的なプロンプト（AIへの指示）を用いる方法が主流になる可能性がある。これは、プロダクトマネージャーのような非技術的な役割の人々でも、複雑なワークフローを試作できるようになる未来を示唆している。

しかし、潜在的な課題も存在する。ツールの生成範囲が限定的である可能性だ。ジェントロはOpenAPI仕様からのツール作成をサポートしているが、MCPがより広く採用されるためには、一般的な企業アプリケーション向けに、あらかじめ構築された本番環境対応のMCPサーバーが幅広く利用可能になることが重要だ。また、多くの企業には形式的な仕様を持たない独自の内部APIが存在することも認識されている。これは、ツールの自動生成にとって課題となる可能性がある。MCPが目指す普遍的な標準となるためには、今後もサーバーとクライアントの堅牢なエコシステムを構築し続ける必要がある。