現実世界で AI エージェントを構築するには、多くの場合、単にモデル呼び出しを行うだけでなく、外部ツールとの統合、複雑なワークフローの処理、ソリューションが本番環境で確実に拡張できるようにする必要があります。
この投稿では、Docker MCP Toolkit を使用してエージェントを作成するための実際の開発者セットアップについて説明します。
物事を具体的にするために、Git リポジトリを入力として受け取り、関数の目的の説明、モジュールの要約、特定の API 呼び出しが行われた場所の検索など、その内容に関する質問に答えることができるエージェントを構築しました。このシンプルだが実用的なユースケースは、エージェントが現実世界のデータソースと対話し、インテリジェントに応答する方法を探るための基盤として機能します。
Docker MCP Toolkitを使用して構築して実行したため、セットアップと統合が高速で移植性があり、反復可能になりました。このブログでは、その開発者のセットアップを順を追って説明し、Docker MCPがエージェントの構築と実行に大きな変革をもたらす理由を説明します。
ユースケース: GitHub リポジトリ質問応答エージェント
目標: GitHub リポジトリに接続し、関連するコードやメタデータを取得し、開発者の質問に平易な言葉で答えることができる AI エージェントを構築します。
クエリの例:
- "このリポジトリを要約する:
https://github.com/owner/repo
" - 「認証ロジックはどこに実装されていますか?」
- 「主要なモジュールとその目的をリストアップしてください。」
- 「関数
parse_config
説明し、それがどこで使用されているかを示します。」
これは単純なコードデモにとどまらず、開発者が実際の環境でどのように作業するかを反映しています
- エージェントは、いつでもクエリできるコードを認識したチームメイトのように機能します。
- MCP ゲートウェイは、エージェント コードを肥大化させることなく、ツール統合 (GitHub API) を処理します。
- Docker Compose は環境を結び付けて、開発、ステージング、または運用環境で同じように実行されるようにします。
Docker MCP Toolkitの役割
MCP Toolkit を使用しないと、API SDK の接続、認証トークンの管理、環境の違いのトラブルシューティングに何時間も費やすことになります。
MCP Toolkit を使用すると、次のようになります。
- コンテナ化されたコネクタ – GitHub MCP Gateway を既製のサービス (
docker/mcp-gateway:latest
) として実行し、SDK のセットアップは必要ありません。 - 一貫性のある環境 – コンテナーイメージには固定された依存関係があるため、セットアップはすべてのチームメンバーに対して同じように機能します。
- 迅速な統合 – エージェントは HTTP 経由でゲートウェイに接続します。新しいツールの追加は、新しいコンテナを追加するのと同じくらい簡単です。
- イテレーションの高速化 –
docker compose
を使用して数秒でサービスを再起動またはスワップします。 - 配管ではなくロジックに焦点を当てる – ゲートウェイは GitHub 固有の面倒な作業を処理し、ユーザーはプロンプト設計、推論、マルチエージェントのオーケストレーションに集中します。
Docker Compose の役割
Docker Compose を介してすべてを実行すると、エージェント環境全体を 1 つのデプロイ可能なユニットとして扱うことができます。
- ワンコマンド起動 –
docker compose up
MCP ゲートウェイ (およびコンテナー化されている場合はエージェント) を一緒に起動します。 - サービスオーケストレーション – Compose は、依存関係が正しい順序で開始されるようにします。
- 内部ネットワーク – サービスは、手動でポート ラングリングを行うことなく、名前 (
http://mcp-gateway-github:8080
) で相互に通信します。 - スケーリング – 同時リクエストに対して複数のエージェントインスタンスを実行します。
- 統合ログ – すべてのログを 1 か所で表示して、デバッグを容易にします。
アーキテクチャの概要

このセットアップでは、Docker Compose が環境をオーケストレーションし、Dockerized MCP Gateway を介して開発者のローカル エージェントを GitHub に接続します。その仕組みを段階的に説明します。
- ユーザーインタラクション
- 開発者は、CLI またはターミナルからエージェントを実行します。
- 彼らはGitHubリポジトリに関する質問を入力します - 例:「認証ロジックはどこに実装されていますか?」
- エージェント処理
- エージェント(LLM + MCPTools)が質問を受け取ります。
- エージェントは、リポジトリー・データが必要であると判断し、MCPTools を介してツール呼び出しを発行します。
- MCPゲートウェイ→MCPTools
- MCPTools は、
streamable-http
を使用して Docker で実行されている MCP ゲートウェイにリクエストを送信します。 - このゲートウェイは
docker-compose.yml
で定義され、GitHub サーバー (--servers=github --port=8080
) 用に構成されます。
- GitHub への統合
- MCP ゲートウェイは、ファイルの一覧表示、コンテンツの取得、コードの検索など、すべての GitHub API インタラクションを処理し、構造化された結果をエージェントに返します。
- LLM推論
- エージェントは、取得した GitHub コンテキストをプロンプトの一部として OpenAI GPT-4o に送信します。
- LLM はデータを推論し、明確でコンテキストが豊富な回答を生成します。
- ユーザーへの応答
- エージェントは、多くの場合、ファイル名と行参照とともに、最終的な回答を CLI に出力します。
コードリファレンスとファイルロール
このセットアップの詳細なソースコードは、この リンクから入手できます。
行ごとに説明するのではなく、実際の開発者セットアップで各ファイルが行うことを次に示します。
docker-compose.yml
- GitHub の MCP ゲートウェイ サービスを定義します。
- 構成されたサーバーとして GitHub を使用して
docker/mcp-gateway:latest
コンテナーを実行します。 - ポート
8080
でゲートウェイを公開します。 - エージェントと追加のコネクタを同じネットワーク内の個別のサービスとして実行するように拡張できます。
app.py
- GitHub リポジトリ サマライザー エージェントを実装します。
MCPTools
を使用して、streamable-http
経由でMCPゲートウェイに接続します。- ゲートウェイ経由でクエリを GitHub に送信し、結果を取得し、推論のために GPT4に渡します。
- 対話型 CLI ループを処理するため、質問を入力してリアルタイムの応答を得ることができます。
つまり、Compose ファイルは インフラストラクチャとオーケストレーションを管理し、Python スクリプトは インテリジェンスと会話を処理します。
セットアップと実行
- リポジトリのクローンを作成する
git clone https://github.com/rajeshsgr/mcp-demo-agents/tree/main
cd mcp-demo-agents
- 環境の構成
.env を作成するファイルをルートディレクトリに追加し、OpenAI API キーを追加します。
OPEN_AI_KEY = <<Insert your Open AI Key>>
- GitHub Access の構成
MCP ゲートウェイが GitHub リポジトリにアクセスできるようにするには、GitHub 個人用アクセス トークンを設定します。
docker mcp secret set github.personal_access_token=<YOUR_GITHUB_TOKEN>
- MCP ゲートウェイの起動
Docker Compose を使用して GitHub MCP Gateway コンテナーを起動します。
docker compose up -d
- 依存関係のインストールとエージェントの実行
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
python app.py
- 質問
クエリを入力します。 Summarize https://github.com/owner/repo
Docker、MCP、Compose を使用した実際のエージェント開発
このセットアップは、生産の現実を念頭に置いて構築されています。
- Docker は、各統合 (GitHub、データベース、API) が、すべての依存関係が事前に構成された独自の分離されたコンテナーで実行されるようにします。
- MCP はエージェントと現実世界のツールの間の架け橋として機能し、API の複雑さを抽象化して、エージェント コードをクリーンに保ち、推論に集中させます。
- Docker Compose は、これらすべての可動部分を調整し、開発、ステージング、本番間の起動順序、ネットワーク、スケーリング、および環境パリティを管理します。
ここから、簡単に追加できます。
- その他の MCP コネクタ (Jira、Slack、内部 API)。
- さまざまなタスクに特化した複数のエージェント。
- 自動テストのためにこの環境をスピンアップする CI/CD パイプライン
最終的な考え
分離のための Docker 、シームレスなツール統合のための MCP 、オーケストレーションのための Docker Compose を組み合わせることで、私たちは単なる動作するAIエージェント以上のものを構築し、反復可能で本番環境に対応した開発パターンを作成しました。このアプローチにより、環境のドリフトが排除され、イテレーションが加速され、既存のワークフローを中断することなく新しい機能を簡単に追加できるようになります。ローカルで実験する場合でも、大規模に展開する場合でも、このセットアップにより、エージェントの信頼性と保守性が保証され、初日から現実世界の需要に対応できるようになります。
導入前と導入後: 開発者エクスペリエンス
アスペクト |
Docker + MCP + Composeなし |
Docker + MCP + Compose を使用 |
---|---|---|
環境のセットアップ |
SDKの手動インストール、依存関係の競合、「マシンで動作する」問題。 |
固定された依存関係を持つ事前構築済みコンテナーイメージにより、どこでも同じ環境が保証されます。 |
ツール(GitHub、Jiraなど)との統合 |
エージェントコード内のカスタムAPIワイヤリング。メンテナンスのオーバーヘッドが高い。 |
MCP は、個別のコンテナーでの統合を処理します。エージェント コードはクリーンで焦点を絞ったままです。 |
起動プロセス |
複数のスクリプト/端末。手動サービス注文。 |
|
ネットワーキング |
ポートと URL の手動設定。エラーが発生しやすい。 |
サービス名解決( |
拡張性 |
サービスのスケーリングには、カスタムスクリプトと再構成が必要です。 |
|
拡張性 |
新しい統合を追加するということは、エージェントのコードを変更して再デプロイすることを意味します。 |
エージェントを変更せずに、新しい MCP コンテナを |
CI/CD統合 |
パイプライン内の環境を再現するのは困難です。もろいビルド。 |
同じ Compose ファイルは、ローカル、ステージング、CI/CD パイプラインで機能します。 |
反復速度 |
サービスの再起動や設定の切り替えは時間がかかり、エラーが発生しやすくなります。 |
コンテナーの停止、交換、再起動は数秒で行うことができます。 |