AIエージェントが独自の連携ツールをオンデマンドで生成する方法

要約：McProxyは、Model Context Protocol（MCP）上に構築されたオープン標準のゲートウェイです。AIエージェントが自然言語またはOpenAPI仕様を使用して、ツール連携をオンザフライで生成できるようにします。統合を静的コードから動的アセットに移行することで、オンボーディング時間を16時間から30秒未満に短縮すると同時に、Okta AURMのエンタープライズセキュリティを一元化します。

すべての開発者が支払う「統合税」とその解消法

新しいAPIを統合したり、さらに厄介なことに、新しいMCPサーバーを作成してオンボーディングしたりする必要があるときの、あの何とも言えない気持ちをご存知ですか。本来なら簡単なはずの作業が、ドキュメントを何時間も読み込み、認証フローと格闘し、不明瞭なEdgeケースをデバッグする作業に変わってしまいます。

これを、CI/CDパイプライン、プロジェクトトラッカー、ドキュメンテーションWiki、シークレットマネージャーなど、スタック内のすべてのツールに当てはめて考えてみてください。統合の作業に終わりはありません。

Oktaで開発ツールに取り組んでいたとき、気になることがありました。AIエージェントが10分程度しか使わないインテグレーションを構築するために、チームが丸一日を費やしていたのです。どうしても辻褄が合いませんでした。

そこで私は考え始めました。これを逆にしたらどうなるだろうか、と。AIエージェントが必要に応じて独自のインテグレーションを構築するとしたら、どうなるでしょうか。MCPサーバーのセットアップと構成を一度行うだけで、ツール、ワークフロー、子MCPサーバーのすべてをオーケストレーションできるとしたらどうでしょうか。

McProxyとは何か、また、どのようにツールをスケールさせるのか。

McProxy（特許出願中）は、私がMCP上に構築したメタPlatformです。これにより、AIエージェントは、平易な英語またはAPI仕様を使用して連携ツールをオンザフライで作成したり、複数のMCPサーバー、ツール、ワークフローを単一の統合された傘下でオーケストレーションしたりできます。これまで何時間もかかっていた作業が、数秒で完了します。さらに、ゲートウェイアーキテクチャは、当初は予想していなかったセキュリティとガバナンスに関する興味深い可能性をいくつか提示しています。

McProxyは、舞台裏で多数のMCPサーバーを密かにやりくりする、単一のMCPサーバーだとお考えください。開発者ツールへの統一ゲートウェイであると同時に、オンデマンドで新しい接続を迅速に構築できる統合ファクトリーでもあります。

参考情報：MCPは、AIエージェントがツールと通信する方法に関する比較的新しい標準です。ツールのディスカバリー、認証、結果処理といった基本を網羅しています。McProxyはその基盤をベースに、必要に応じて新しい統合を生成する機能を追加します。

AIクライアント（Copilot CLI、Claude Desktop、VS Code拡張機能など）から見ると、McProxyは複数のツールを備えた単一のサーバーとして表示されます。しかし、内部ではすべてを専用の子サーバーにルーティングします。

すぐに使用できる状態で、プロジェクト管理用のJira、ドキュメンテーション用のConfluence、CI/CDパイプライン用のCircleCI、テストのアナリティクスと測定基準用のCalciferといったエンタープライズレベルのSaaS統合が含まれています。さらに、不安定なテストを分析・修正するための専用のテストフィクサーも搭載しています。また、まだ持っていないものを要求すると、数秒でまったく新しいサーバーを起動できます。

エコシステムの拡大に伴い、McProxyはツールをツールセットに整理します。ツールセットは論理的なグループであり、単一のサーバーが数十から数百のツールを公開する場合に、よりきめ細かな制御を可能にします。ツールセット全体を動的に有効化または無効化できるため、エージェントは現在のタスクで重要なことだけに集中できます。

オンデマンドでカスタムMCPサーバーを生成する3つの方法

McProxyでは、新しいMCPサーバーを作成する方法が3つ用意されています。いずれの方法でも、手動で構成作業を行うことなく、すぐに結果を得られるという共通点があります。

1. 自然言語プロンプトからの動的な生成

ここが一番の見どころです。AIエージェントが「現在の気象状況、気象予測、悪天候警報を備えた気象サーバーを作成して」と指示するだけで、McProxyがLLMを使用して、ツール、エラー処理、認証などを含む完全なMCPサーバーを生成します。

生成されたコードも、セキュリティに妥協はありません。資格情報は環境変数ではなく、システムのキーチェーンに保存されます。McProxyは、バックグラウンドで高度なテンプレートとリファレンス実装を利用して生成プロセスを誘導し、一貫したパターン、適切なエラー処理、セキュリティのベストプラクティスへの準拠を保証します。単なるLLMの未加工の出力ではなく、品質管理されたコード生成です。30秒もかからずに新しいサーバーがオンボーディングされ、すべてのツールが使用可能な状態になります。

2. OpenAPI仕様の自動変換

多くの最新のAPIは、エンドポイントを記述したOpenAPI仕様を公開しています。McProxyはこれらの仕様を取り込み、MCPサーバーを自動的に生成できます。

GitHubのOpenAPI仕様を指定するだけで、200以上のツールに即座にアクセスできるようになります。それぞれに適切な型付け、認証処理、ドキュメントが備わっています。プロセス全体が30秒未満で完了するため、これまで数週間かかっていた手作業が不要になります。

3. マルチサーバーのワークフローオーケストレーション

ここからが興味深い点です。McProxyは、既存の子サーバーからツールを取得し、新しいオーケストレーターサーバーに統合することで、実質的に自動化されたワークフローを作成できます。「リポジトリのタグ付け、リリースノートの作成、アソシエイトされたJiraチケットの更新、チームへの通知を行うワークフローを生成する」のように、複数ステップのプロセスを記述するだけです。

McProxyは、複数のサーバーにまたがる呼び出しを連鎖させ、障害を適切に処理し、進捗を報告するオーケストレーターを生成します。これにより、通常であれば多数のカスタムスクリプトを必要とする複雑な操作を、単一のツールで即座に調整できるようになります。

McProxyによって開発者の作業時間はどのくらい短縮されますか？

数字で見てみましょう。従来のMCPアーキテクチャにおけるAPIとツールのオンボーディングは、手作業で手間がかかり、構成に何時間も要します。以下に、従来型の開発と自動生成の定量的な比較を示します。

大きな問題が発生しないと仮定した場合、1つの統合あたり6〜16時間かかります。

McProxyを使用しますか？30秒未満。AIエージェントが必要なものを記述すると、McProxyがサーバーを自動的に生成してオンボーディングし、ツールがすぐに利用可能になります。生成されるすべてのサーバーが同じ堅牢なパターンに準拠しているため、品質も一貫して維持されます。

あるいは、GitHub、Jira、Confluence、およびさまざまな通知システムが関わる、典型的なリリースワークフローを考えてみましょう。適切なエラー回復を含めて手動で実装すると、丸1日を費やすことになりかねません。McProxyを使用すると、ワークフローを記述するだけで、実用的なオーケストレーターをわずか数秒で入手できます。

分散型ツールと一元化された制御：ゲートウェイアーキテクチャの利点

McProxyを構築して初めて深く理解したことがあります。それは、すべてのリクエストフローを単一のプロキシサーバーに通過させることで、一元化された制御を実現するための非常に強力な機会が生まれるということです。

すべてが1つのゲートウェイを通過するため、子サーバーごとに再実装することなく、最上位レベルでエンタープライズレベルのポリシーを適用できます。

• セキュリティポリシーとアクセス制御
• 個人を特定できる情報（PII）の検出、処理、および墨消し
• レート制限とクォータ管理
• 包括的な監査ロギング
• コンプライアンスの徹底

このゲートウェイは、エコシステムの保守性を維持するランタイム管理機能も提供します。接続されているすべてのサーバーを一覧表示したり、動的に有効化または無効化したり、構成をリロードしたりすることが、再起動なしで可能です。サーバーを一時的に無効にする必要がありますか。1つのコマンド。現在アクティブなサーバーを確認しますか？別のコマンド。統合の数が増えるにつれて、この運用の柔軟性が非常に重要になります。

エンタープライズガバナンスとトップレベルのセキュリティポリシー

ここでは、セキュリティは後付けで考えるものではありません。設計の初日から組み込まれています。すべてのツールでAURM（Oktaのセキュアな認証システム）による認証が必須です。資格情報はシステムキーチェーンを使用して保存され、構成ファイルや環境変数に保存されることはありません。

McProxyが新しいサーバーを生成すると、適切な認証の基盤が自動的に組み込まれます。生成されたサーバーは手動で作成されたサーバーと同じセキュアなパターンを使用するため、ハードコードされた資格情報や安全でないトークンの保存といった、よくある脆弱性を防ぐことができます。

結論として、動的に生成された統合であっても、エンタープライズレベルのセキュリティ標準は維持されます。エージェントはツールを自由に作成できますが、セキュリティの脆弱性を生み出すことはできません。

複数の子サーバーにまたがる複雑なオペレーションの連鎖

個々のツールを生成することにも、もちろん価値はあります。しかし、既存のツールを組み合わせてワークフローサーバーを構築する機能についてはどうでしょうか。そこからが、真の変革の始まりです。

オーケストレーターサーバーを作成すると、そのサーバーはクライアントとしてMcProxyに接続し、他の子サーバーからツールを呼び出します。これにより、エラー処理と進捗レポート機能を備えた複数ステップのワークフローが可能になります。

機能開発のワークフローでは、Confluenceから要件を読み取り、Jiraでチケットを作成して「進行中」に移行し、GitHubでブランチを作成してドキュメントを更新するといった一連のプロセスを、単一のアトミックなオペレーションとして実行できます。

McProxyには、機能開発、リリース、インシデント対応といった一般的なシナリオに対応する、事前構築済みのワークフローが含まれています。ただし、エージェントはチーム固有のプロセスに合わせてカスタマイズされたオーケストレーターをリクエストできます。ワークフローが生成、オンボーディングされ、既存のツールと並行してすぐに使用できるようになります。

従来のワークフロー自動化では、柔軟性のない事前構築済みの統合か、大規模なカスタムコードかの選択を迫られます。McProxyのオーケストレーターは、多様なユースケースに対応できる柔軟性と、自然言語から生成できるシンプルさのバランスが取れています。

動的なサーバーのホットリロードでダウンタイムを解消

新しいサーバーは、自然言語、OpenAPI仕様、または既存ツールの組み合わせなど、その生成方法にかかわらず自動的にオンボーディングされます。手動での設定は不要です。再起動は不要です。セットアップ手順はありません。McProxyは新しいサーバーを動的にホットリロードするため、ダウンタイムは発生しません。

これにより、統合に対する考え方が一変します。新規の統合を大規模なプロジェクトとして扱うのではなく、簡単な作業として処理できるようになります。必要な機能はありますか？生成する。ワークフローを自動化しますか？既存のツールを組み合わせる。すべてが数秒で完了し、すぐに使用できます。

AIとエンジニア間のフィードバックループ：アーキテクチャパターンの最適化

さらに、予期せぬメリットもありました。生成されたコードがフィードバックループとして機能することです。AIが生成したサーバーをレビューする際、エンジニアは手作業で実装したものよりも優れたアプローチを発見することがあります。

これにより、好循環が生まれます。人間のエンジニアがPlatformとパターンを提供します。AIがそれらのパターンに基づいて実装を生成します。人間はAIの解釈から学習します。テンプレートとプロンプトは時間とともに改善され、より質の高い生成につながります。

サーバーが作成されるたびに、エコシステムはよりスマートになります。

Model Context Protocolが相互運用性に不可欠な理由

McProxyは、独自のフォーマットを新たに作成するのではなく、MCPを基盤に構築されています。これは、システムの長期的な利用と相互運用性のために重要です。

MCPは、ツールの公開、認証の処理、結果の伝達に関する標準的な方法を定義しています。McProxyで生成されたサーバーは、MCP互換のあらゆるクライアントで動作します。AIエコシステムの進化に伴い、MCPベースの統合は引き続き有効な選択肢となります。

stdioベースの通信モデルにより、分離が保証されます。各子サーバーは、構造化されたJSON-RPCメッセージを使用して個別のプロセスとして実行されます。1台のサーバーの障害が連鎖的に波及することはありません。リソース制御はきめ細かく行えます。デバッグは簡単です。

McProxyは、他の多くのサーバーに接続する単一のMCPサーバーとして機能することで、クリーンな抽象化を提供します。AIクライアントは、複数の接続を管理したり、バックエンドの複雑さを理解したりする必要がありません。McProxyに接続し、拡大し続けるエコシステムにアクセスします。

ただし、究極の開発者エクスペリエンスは、クライアントを動かすLLMの性能に大きく依存するという点は注目に値します。より高性能なクライアントLLMは、ツールのSelect、引数の生成、結果の解釈に優れているため、最終的にはMcProxyツールとの連携において、より柔軟で優れたエクスペリエンスを実現します。

現在のMcProxyの制限事項と今後のロードマップ

動的な生成は完全ではありません。生成されたコードには検証が必要です。LLMは通常、動作するコードを生成しますが、EdgeケースやAPIの変更によって問題が発生する可能性があります。テストフレームワークと段階的なロールアウトによってこれに対処します。

今後の機能強化：

• 生成されたサーバーのバージョン管理
• APIの変更の自動検知と再生成
• 高度なオーケストレーションパターン（並列実行、条件付きロジック、状態管理）
• ゲートウェイレベルでのポリシー適用の強化
• 統合の品質スコアリングと監視

生成されるサーバーを、手作業で構築した統合と同等の堅牢性を持ち、なおかつスピードと柔軟性を維持できるようにすることが目標です。

ソフトウェアエンジニアリングの枠を超えた、クロスドメインのエンタープライズアプリケーション

McProxyは開発ワークフロー向けに構築されましたが、その概念はカスタマーサポート、データアナリティクス、インフラストラクチャ管理など、複数のツールにわたる連携を必要とするあらゆるドメインに適用できます。

現代の働き方では、モノリシックなアプリケーションを使用するのではなく、専門的なツールを組み合わせて使用する傾向が強まっています。AIエージェントは、統合を柔軟に作成、適応できる場合に、オーケストレーションで優れた能力を発揮します。McProxyは、インテリジェントなコード生成と堅牢なPlatformアーキテクチャによって、この柔軟性が実現可能であることを示しています。

静的なインフラストラクチャから動的なAI統合への移行

McProxyは、統合を手作業によるエンジニアリングメンテナンスが必要な静的なインフラストラクチャとしてではなく、オンデマンドで作成される動的なリソースとして扱うことで、基盤となるソフトウェアアーキテクチャを変革します。

自動ツール生成とリアルタイムのワークフローオーケストレーションを組み合わせることで、このPlatformは従来の統合の経済性を根底から覆します。以前は慎重な計画と数日間にわたるカスタム開発を必要としていた運用が、自動化されたオンデマンドのリクエストに集約されます。

ガバナンスに一元化されたゲートウェイアーキテクチャが重要な理由

一元化されたプロキシゲートウェイを展開することで、エンタープライズコンプライアンスにネイティブなアーキテクチャ上のメリットがもたらされます。組織の特化型AIツールのエコシステムが拡大するにつれて、この中央レイヤーにより、エンジニアリングチームは個々のサーバーを変更することなく、レート制限、監査ログ、セキュリティポリシーを全体に適用できるようになります。

最終的に、AIエージェントが独自のツールを動的に生成できるようになると、エンタープライズ内での役割が変化します。つまり、ハードコードされた機能に限定されたアシスタントから、真に順応性の高い開発パートナーへと移行するのです。

セキュアなAI統合の未来を築く

開発者が長年直面してきた統合のチャレンジに、ついにスケーラブルなソリューションが登場するかもしれません。McProxyは、当初は社内の開発ワークフローを合理化するための内部プロジェクトとして始まりましたが、その基盤となるアーキテクチャパターン、すなわち動的なツール生成、クライアントサーバープロキシ、一元化されたゲートウェイポリシーは、今日、お客様のエンタープライズシステムにも採用できる設計原則です。

同様のフレームワークを構築することで、静的な統合をオンデマンドでセキュアな機能に変えることができます。まずは、AIにおけるMCPの詳細を見るで、このプロトコルがどのようにエージェントの接続を標準化するかをご確認ください。また、Okta for AI AgentsがカスタムエージェントPlatformのセキュリティ確保とガバナンスにどのように役立つかについてもご覧ください。