急速に進化する AI 支援開発の状況において、ほとんどの開発者は、不格好な Web インターフェイス、リソースを大量に消費する IDE、断片化されたツールチェーンに苦労し続けています。しかし、Google の 76.3K-star Gemini CLI (わずか 5 か月で) と Docker の革新的な MCP Toolkit を組み合わせ、現代の AI 開発者の働き方に静かに革命をもたらす組み合わせがあると言ったらどうなるでしょうか?
Gemini CLI と Docker MCP Toolkit という強力なデュオが登場します。これは単なるツールの組み合わせではなく、複雑さのオーバーヘッドなしで開発者の AI 支援を提供するパラダイム シフトです。わずか 5 分の 1 回限りのセットアップで、テスト シナリオごとに 20 分節約でき、テストを実行するたびに 97% の時間短縮になります。
具体的な例を見てみましょう: 開発者が定期的に行うブラウザのテストとパフォーマンス分析を簡素化し、完全に自動化できます。以前は、ブラウザを開き、フローをクリックし、DevToolsを分析し、スクリーンショットを撮り、購入を手動で文書化する必要があったことが、今では1回の 30秒の会話で実現できます。
このガイドでは、次の方法について説明します。
- Gemini CLI をセットアップし、Docker MCP Toolkit に接続します
- ブラウザーの自動化のために Playwright MCP サーバー を構成する
- 課題作成用の GitHub MCP サーバー を構成する
- テスト成果物を保存するための ファイルシステムMCPサーバー の構成
- 実際のバグを発見し、文書化された GitHub の問題を作成するブラウザー テストを自動化します
- Gemini CLI がパフォーマンスの分析、スクリーンショットのキャプチャ、結果のレポートをすべて端末から離れることなく行う方法をご覧ください
220+ 事前構築された MCP サーバーを使用すると、ブラウザの自動化は会話をするのと同じくらい簡単になります。Selenium WebDriverの設定、CI/CDパイプラインの複雑さ、手動のスクリーンショット管理は不要で、実際のブラウザテストを実行する自然言語命令だけです。
Gemini CLI と Docker MCP Toolkit が連携してより適切に機能する理由
手動のブラウザテストとパフォーマンス分析は壊れています。Chrome DevTools を開き、ページをクリックし、ネットワーク リクエストを確認し、パフォーマンス メトリックを分析し、スクリーンショットを撮り、バグ レポートを作成し、GitHub の問題を手動で作成します。このコンテキスト切り替えの悪夢は、スプリントごとに何時間も無駄にします。
従来の自動化ツールでは、本当の問題は解決しません。Selenium には、脆いセレクターと複雑なセットアップが必要です。Playwright には JavaScript の知識とテスト フレームワークが必要です。どちらも、UI が変更されるたびに中断されるテスト スクリプトを維持する必要があります。「ソリューション」には、多くの場合、手動テストよりも時間がかかります。
Gemini は強力な AI 機能を提供し、MCP はプロトコルを提供しますが、Docker MCP Toolkit はブラウザの自動化を実用的にします。コンテナ化がない場合、ブラウザ テストの設定は、Chrome/Firefox インストールの管理、WebDriver バージョンの処理、Node.js依存関係の構成、スクリーンショット ディレクトリの手動処理、および開発者のマシンごとに異なる構成を意味します。2分かかるはずのセットアップには、開発者あたり2〜6時間かかります。
Docker MCP Toolkitは、この摩擦を排除します。
- 220+ カタログ内の事前構築済み MCP サーバー
- Docker Desktop によるワンクリック展開
- ブラウザがプリインストールされたPlaywright MCP(Chrome、Firefox、WebKit)
- 課題作成の自動化のための GitHub MCP
- アーティファクト・ストレージ用のファイル・システムMCP
- OAuthまたは暗号化ストレージによる安全な認証情報管理
- Mac、Windows、Linux 全体で一貫した構成
- 新しいサーバーバージョンがリリースされたときの自動更新
Docker MCP Toolkit は、開発者の現状に合わせて構築しました。Gemini CLI を使用している場合は、インフラストラクチャに取り組むことなくブラウザー テストを自動化できるはずです。
テストはマシン上で安全に実行されます。すべては、ローカルシステム上の分離されたDockerコンテナで実行されます。テストデータ、スクリーンショット、アプリケーションへのアクセスは、コンピューターから離れることはありません。クラウドアップロード、サードパーティサービス、コンプライアンスの懸念はありません。完全なプライバシーを備えたエンタープライズグレードのブラウザ自動化を実現します。
Docker MCP Toolkit での Gemini CLI のセットアップ
前提 条件
ステップ 1.Gemini CLI をインストールする
npm経由でインストールします。
npm install -g @google/gemini-cli
ステップ 2.起動と認証
インストールしたら、ターミナルウィンドウにgeminiと入力するだけです。
gemini
ステップ 3.Google経由でログイン
セットアップ ウィザードに従います。
- オプションから好みのテーマスタイルを選択します。
- ログイン方法を選択します。「Login with Google」をお勧めしますが、リクエストは最大 60 件/分で、 1件、リクエスト/日000 件まで無料で行えます
より高いレート制限やエンタープライズ アクセスが必要な場合は、 Google AI Studio の API キーを使用することをお勧めします。環境変数として簡単に設定できます。
export GEMINI_API_KEY="YOUR_API_KEY"
サインイン方法を選択すると、ブラウザー ウィンドウが開きます。Googleアカウントでログインするだけです
ステップ 4.Gemini でチャットを開始する
ターミナルウィンドウに「gemini」と入力するだけで、Geminiとのチャットを開始し、プロンプトを入力します。

Gemini CLI を Docker MCP Toolkit に接続する
オプション 1:ワンクリック接続(推奨)
- Docker Desktop を開く
- サイドバーの MCP Toolkit に移動します。
- [ クライアント] タブをクリックします
- リストで「Gemini」を見つけます。
- [接続] をクリックします。

Docker Desktop は、Gemini CLI と MCP サーバー間でリクエストをルーティングする基盤となるインフラストラクチャである MCP ゲートウェイ接続を自動的に構成し、認証、コンテナ化、安全な通信をシームレスに処理します。
オプション 2: 手動コマンドライン設定
コマンドライン設定を希望する場合、または特定のプロジェクトを構成する必要がある場合:
- ターミナルでプロジェクトフォルダに移動します
- 次のコマンドを実行します。
docker mcp client connect gemini --global
次のような出力が表示されます。
=== System-wide MCP Configurations ===
● gemini: connected
MCP_DOCKER: Docker MCP Catalog (gateway server) (stdio)
● gordon: connected
MCP_DOCKER: Docker MCP Catalog (gateway server) (stdio)
You might have to restart 'gemini'.
connected
ステータスは、Gemini CLI が Docker MCP ゲートウェイにリンクされていることを確認します。
ボンネットの下で何が起こっているのでしょうか?
Gemini CLI は、settings.json ファイル内の mcpServers 設定を使用して、MCP サーバーを見つけて接続します。この構成では、異なるトランスポート メカニズムを持つ複数のサーバーがサポートされます。mcpServers オブジェクトは、CLI が接続する各 MCP サーバーを定義する場所です。
Gemini CLI の Docker MCP クライアントの下にある [接続] ボタンを押すたびに、次の Docker MCP ゲートウェイ構成が ~/.gemini/settings.json
ファイルに追加されます。
{
"theme": "Default",
"selectedAuthType": "oauth-personal",
"mcpServers": {
"MCP_DOCKER": {
"command": "docker",
"args": ["mcp", "gateway", "run"],
"env": {}
}
}
}
MCP と Gemini CLI の相互作用の詳細については 、こちらの リンクをご覧ください。
ステップ 5.Gemini CLI を再起動する
# Exit Gemini CLI if running, then restart
gemini
ステップ 6.接続を確認する
Claude Code内で /mcp
と入力すると、利用可能なMCPサーバーが表示されます。

Docker MCP ゲートウェイが一覧表示され、有効なすべての MCP サーバーへのアクセスが提供されます。/MCP_DOCKER
ツールは、接続が成功したことを示します。Docker Desktop でさらに多くの MCP サーバーを有効にすると、自動的にここに表示されます。
初回実行:期待すること
Docker MCP Toolkit に接続した後、Gemini CLI を初めて起動すると、新しい MCP サーバーに関するプロンプトが表示されます。

オプション 1 (推奨) を選択します。これにより、Docker MCP Toolkit と Docker Desktop で有効にした MCP サーバーを自動的に使用するようにプロジェクトが構成されます。MCP サーバーを毎回個別に承認する必要はありません。

これで、Docker Desktop の MCP サーバーで Gemini を使用する準備が整いました。
実際のデモ: 自動ブラウザ テストとパフォーマンス分析
Gemini CLI を Docker MCP Toolkit に接続したので、実際の例を使用して実際の動作を見てみましょう。ブラウザのテストを通じて実際のバグを自動的に発見し、詳細な分析を通じてパフォーマンスのボトルネックを特定します (手動テスト、DevTools の監視、パフォーマンス プロファイリングに 20 分かかるようなもの)。
何がこれを現実的にするのでしょうか?
これは些細な「Hello World」のデモではありません。実際の電子商取引アプリケーションに対して、本番環境で発生する種類の問題について、包括的なブラウザテストとパフォーマンス分析を実行しています。
- localhost で実行されている実際のアプリケーションを使用します。
- 機能ブラウザテスト(ナビゲーション、要素検査、コンソール監視)を実行します。
- ブラウザのDevTools分析による真のパフォーマンスボトルネックの発見
- 実際のユーザーに影響するアクセシビリティ違反を特定します
- スクリーンショットとコンソールログで証拠をキャプチャします
- 実際のパフォーマンス指標を測定:ページの読み込み時間、ネットワークリクエスト、リソース使用量
- 適切な形式の GitHub 課題を作成し、実用的な推奨事項を作成します。
時間投資:
- 手動プロセス: ~20 分 (ブラウザーを開く、フローをクリックする、DevTools 分析、パフォーマンス プロファイリング、ドキュメント、課題の作成)
- Gemini CLI + MCPで自動化:合計~30 秒
これは 97%の時間短縮ですが、さらに重要なことは、一貫性があり、徹底的で、毎回文書化されていることです。
テスト対象
catalog-service-node
アプリケーションは、一般的な生産上の問題を反映した意図的な問題を含む現実的な電子商取引カタログです。
パフォーマンスの問題:
- ページネーションなし – すべての 15 製品を一度に読み込みます (スケールによって劣化します)
- 重複した API 呼び出し – リクエストが不必要に 2 回
/api/products
- 最適化の欠落 – 最適化されていない読み込みパターン
アクセシビリティの問題:
- 商品画像の欠落 – 実際の画像ではなくプレースホルダーボタン
- あいまいなボタンラベル – 「取得」と「アップロード」はスクリーンリーダーの説明ではありません
- ARIA ラベルの欠落 – テーブル構造が適切にアナウンスされない
ブラウザの問題:
- ファビコンの欠落 – コンソールで 404 エラーが生成される
- コンソールの警告 – 重複するリクエストの警告
Gemini CLI がインテリジェントなブラウザ テストとパフォーマンス分析を通じてこれらすべてを自動的に検出できるかどうかを確認し、包括的な GitHub 問題を作成しましょう。
ステップ 1: 実際の e コマース カタログ アプリケーションを設定する
このデモでは、実際の電子商取引カタログ アプリケーションを使用します。これにより、現実的なパフォーマンスとアクセシビリティの問題を発見できます。
リポジトリをクローンします。
git clone https://github.com/ajeetraina/catalog-service-node
cd catalog-service-node
すべてのサービスを開始します。
# Start Docker services (database, S3, Kafka)
docker compose up -d
# Install dependencies
npm install --omit=optional
# Start the application
npm run dev
実行中であることを確認します。
- フロントエンド:http://localhost:5173
- API: http://localhost:3000
ステップ 2:シードテストデータ
テストを現実的にするには、サンプル製品を作成します。
# Create seed script
cat > seed-data.sh << 'EOF'
#!/bin/bash
API_URL="http://localhost:3000/api"
echo "Seeding test products..."
curl -s -X POST "$API_URL/products" \
-H "Content-Type: application/json" \
-d '{"name":"Vintage Camera","description":"Classic 35mm film camera","price":299.99,"upc":"CAM001"}' \
> /dev/null && echo "✅ Vintage Camera"
curl -s -X POST "$API_URL/products" \
-H "Content-Type: application/json" \
-d '{"name":"Rare Vinyl Record - LAST ONE!","description":"Limited edition. Only 1 left!","price":149.99,"upc":"VINYL001"}' \
> /dev/null && echo "✅ Rare Vinyl Record"
curl -s -X POST "$API_URL/products" \
-H "Content-Type: application/json" \
-d '{"name":"Professional DSLR Camera","description":"50MP camera with 8K video","price":2499.99,"upc":"CAMPRO001"}' \
> /dev/null && echo "✅ Professional DSLR"
# Add bulk test products
for i in {4..15}; do
curl -s -X POST "$API_URL/products" \
-H "Content-Type: application/json" \
-d "{\"name\":\"Test Product $i\",\"description\":\"Bulk test product $i\",\"price\":$((50 + RANDOM % 450)).99,\"upc\":\"BULK$(printf '%03d' $i)\"}" \
> /dev/null && echo "✅ Test Product $i"
done
echo ""
TOTAL=$(curl -s "$API_URL/products" | jq '. | length')
echo "Total products: $TOTAL"
echo "Ready! Visit http://localhost:5173"
EOF
chmod +x seed-data.sh
./seed-data.sh
期待される出力:
Seeding test products...
✅ Vintage Camera
✅ Rare Vinyl Record
✅ Professional DSLR
✅ Test Product 4
✅ Test Product 5
...
✅ Test Product 15
Total products: 15
Ready! Visit http://localhost:5173
これで、分析する 15 製品を備えた現実的な環境ができました。
MCP サーバーの構成
ブラウザーのテストとパフォーマンス分析の自動化のために、3 つの MCP サーバーを調整します。
- Playwright MCP – ブラウザの制御、スクリーンショットの撮影、コンソール ログのキャプチャ
- GitHub MCP – 完全なコンテキストで課題を自動的に作成します
- ファイルシステムMCP –スクリーンショットとテストアーティファクトを保存します
それぞれを設定しましょう。
Playwright MCP (ブラウザー オートメーション) の設定
Playwright MCP サーバーにより、Gemini は人間と同じように実際のブラウザ、Chrome、Firefox、WebKit を制御できるようになります。
Docker Desktopの場合:
- Docker Desktop → MCP Toolkit → Catalogを開きます
- 「Playwright」または「ブラウザ」を検索します
- 結果で Playwright(ブラウザーオートメーション) を見つける
- [+ 追加] をクリックします。
- サーバーはデフォルト構成で追加されます(追加のセットアップは必要ありません)
- [サーバーの開始] をクリックします。
あなたが得るもの:
- 21+ ブラウザ自動化ツールには以下が含まれます。
browser_navigate
– URLに移動しますbrowser_snapshot
– 分析のためにページ状態をキャプチャするbrowser_take_screenshot
– 視覚的証拠を保存するbrowser_click, browser_type
– 要素と対話するbrowser_console_messages
–コンソールエラーを取得するbrowser_network_requests
– HTTP リクエストを分析する

Playwright MCP は、ブラウザーがプリインストールされた安全な Docker コンテナーで実行されます。ChromeDriverの手動セットアップ、WebDriverの競合、OS固有のブラウザのインストールはありません。
GitHub MCP の構成 (課題の作成)
GitHub MCP を使用すると、Gemini はユーザーに代わって課題、PR を作成し、リポジトリを管理できます。
オプション 1: OAuth 認証 (推奨 – 最も簡単)
- MCP Toolkit → Catalog で、「GitHub Official」を検索します。
- [+ 追加] をクリックします。
- Docker Desktop の [OAuth ] タブに移動します
- GitHub エントリを見つける
- 「承認」をクリックします。
- ブラウザーで GitHub の承認ページが開きます
- GitHubの 「Authorize Docker」 をクリックします。
- Docker Desktop にリダイレクトされます
- [カタログ] タブに戻り、GitHub Official を見つけます。
- [サーバーの開始] をクリックします。

利: トークンを手動で作成する必要はありません。承認は、トークンの自動更新を備えた GitHub の安全な OAuth フローを通じて行われます。
オプション 2: 個人用アクセストークン(きめ細かな制御用)
手動制御を希望する場合、または特定のスコープが必要な場合:
ステップ 1: GitHub Personal Access Token を作成する
- https://github.com に移動 そしてサインイン
- プロフィール写真→設定をクリックします
- 左側のサイドバーの 「開発者設定」 までスクロールします
- 「個人用アクセストークン」→「トークン(クラシック)」をクリックします。
- 「新しいトークンの生成」→「新しいトークンの生成(クラシック)」をクリックします。
- 「 Docker MCP Browser Testing」という名前を付けます。
- スコープを選択します。
repo
(リポジトリのフルコントロール)workflow
(GitHub Actions ワークフローの更新)
- 「トークンの生成」をクリックします
- トークンをすぐにコピーします (二度と表示されません!
ステップ 2: Docker Desktop で構成する
- MCP Toolkit → Catalog で、GitHub Official
- [ + 追加 ] をクリックします (まだ追加していない場合)
- [ 構成 ] タブに移動します
- 認証方法として 「個人用アクセストークン」 を選択します
- トークンを貼り付ける
- [サーバーの開始] をクリックします。
またはCLI経由で:
docker mcp secret set GITHUB.PERSONAL_ACCESS_TOKEN=github_pat_YOUR_TOKEN_HERE
ファイルシステムMCPの設定(スクリーンショットストレージ)
ファイルシステムMCPを使用すると、Geminiはスクリーンショットとテストアーティファクトをローカルマシンに保存できます。
Docker Desktopの場合:
- MCP Toolkit → カタログに移動
- 「ファイルシステム」を検索
- ファイルシステム(参照)を見つけて、[+ 追加]をクリックします
- [ 構成 ] タブに移動します
- filesystem.paths で、プロジェクトディレクトリを追加します。
- 例: /Users/yourname/catalog-service-node
- または、リポジトリを複製した場所
- [+] ボタンをクリックすると、複数のパスを追加できます
- [保存] をクリックします
- [サーバーの開始] をクリックします。

重要なセキュリティ上の注意: Gemini の読み書きに慣れているディレクトリへのアクセスのみを許可します。ファイル・システム MCP は、保護のためにこれらの特定のパスにスコープが設定されます。
オートメーションの実行
ディレクトリを catalog-service-node
プロジェクトリポジトリのルートに変更し、Gemini CLI を開きます。
gemini
このプロンプトを貼り付けます。
Navigate to http://host.docker.internal:5173 and perform a detailed
performance and accessibility analysis:
1. Take a screenshot of the full page
2. Count how many products are displayed
3. Open browser DevTools and check:
- Console for any JavaScript errors
- Network tab: how many HTTP requests are made?
- Performance: how long does the page take to load?
4. Identify performance issues:
- Are all products loading at once with no pagination?
- Are images optimized?
- Any unnecessary network requests?
5. Check for accessibility issues:
- Missing alt text on images
- Color contrast problems
- Vague button labels
Create a GitHub issue titled "Product catalog performance and
accessibility issues" with:
- Screenshots attached
- List of specific problems found
- Severity: Medium
- Labels: performance, accessibility, enhancement
ジェミニの作品を見る
Gemini が複数の MCP サーバーをオーケストレーションする舞台裏で何が起こるかは次のとおりです。
ステップ 1: ブラウザ ナビゲーション
The web server is running. I'll navigate to http://host.docker.internal:5173, take a screenshot, and then proceed with the rest of the performance analysis.
Gemini は、Docker コンテナーで実際の Chromium ブラウザーを起動し、アプリケーションに移動します。
ステップ 2: コンソール分析
✦ I can see 15 products listed on the page: * Vintage Camera * Rare Vinyl Record - LAST ONE! * Professional DSLR Camera * Test Product 4-15
ステップ 3:パフォーマンスチェック
✦ Checking browser console and network requests... Opening DevTools to analyze performance metrics...
ステップ 4: 課題の作成
✦ Creating GitHub issue with findings...
create_issue (MCP_DOCKER MCP Server) {"labels":["performance","accessibility","enhancement"],"body":"### Summary..."}
✦ I have successfully created the issue. You can find it at: https://github.com/ajeetraina/catalog-service-node/issues/1
完全な GitHub 問題
Gemini は、構造化された情報を使用して、この包括的な課題を自動的に作成しました。

ワークフローの比較: MCP 前と MCP 後
歩 |
MCP (手動テスト) の前 |
時間 |
MCP 後(Gemini CLI + MCP) |
時間 |
---|---|---|---|---|
1 |
ブラウザを手動で開く |
1 分 |
Gemini CLI でのプロンプトの貼り付け |
5 秒 |
2 |
アプリケーションに移動します |
30 秒 |
Gemini は自動的に分析します |
25 秒 |
3 |
クリックスルーページ |
3 分 |
GitHub の問題が作成されました |
自動 |
4 |
DevTools を手動で開く |
30 秒 |
スクリーンショットを添付 |
自動 |
5 |
スクリーンショットを撮る |
2 分 |
✓ コンプリート |
– |
6 |
ブラウザコンソールを確認する |
1 分 |
– |
– |
7 |
ネットワーク要求の分析 |
2 分 |
– |
– |
8 |
調査結果の文書化 |
3 分 |
– |
– |
9 |
詳細なバグレポートを作成する |
5 分 |
– |
– |
10 |
GitHub 課題の作成 |
2 分 |
– |
– |
概要 |
トータル |
~ テストごとに 20 分 |
– |
テストあたり30秒 |
テストあたりの節約時間: 19。5 分(97%高速化!
時間の経過に伴う影響:
- 1日あたり(5テスト):→ 197分節約。6時間
- 週あたり (25 テスト): 1 日全体→ 1 8 時間節約
- スプリントごと (50 テスト): 16 時間→ 2 フル稼働日で節約
- 年間 (1、000 テスト): 営業日→ 40 325 時間節約
まとめ
Docker MCP Toolkit が Gemini CLI をチャット アシスタントから完全なブラウザ テストおよびパフォーマンス分析プラットフォームに変える方法を目の当たりにしました。以前は、ブラウザーを開き、フローをクリックし、DevToolsを分析し、バグを文書化し、問題を手動で作成する必要があったことが、1 30秒の会話で完了するようになりました。
Gemini CLI と Docker MCP Toolkit の組み合わせは、AI 支援開発におけるパラダイム シフトを表しています。ターミナルネイティブツールとコンテナ化されたサービスを活用することで、次のことが可能になります。
- 工具選択における比類のない柔軟性
- 最小限のオーバーヘッドで優れたパフォーマンス
- ニーズに合わせて拡張できる将来性のあるアーキテクチャ
この設定は利便性だけでなく、ワークフローに適応することを強制するのではなく、ワークフローに適応する開発環境を構築することです。開発者の生産性革命がここにあります。問題は、AI 支援開発を採用するかどうかではなく、利用可能な最高のツールでリードするか、後で追いつくかです。
試してみる準備はできましたか?Docker Desktop で Docker MCP Toolkit を有効にして、Gemini を利用した独自の開発ワークフローの構築を今すぐ開始してください。
さらに詳しく
- MCP カタログの探索: コンテナ化されたセキュリティ強化された MCP サーバーを検出する
- Docker Desktop を開き、MCP Toolkit の使用を開始します (MCP Toolkit を自動的に起動するには、バージョン 448 以降が必要です)
- Docker MCP Toolkitを使用してClaude CodeにMCPサーバーを追加するガイドをご覧ください。
- MCP ホラー ストーリー シリーズをチェックして、MCP セキュリティの一般的な落とし穴とそれらを回避する方法を確認してください。