Gemini と MCP で画像生成を効率化する — 仕組みと実務運用

画像生成AIを制作やプロトタイピングに使う場面は増えていますが、ブラウザのUIを一枚ずつ操作する運用は、枚数がまとまると途端に手間になります。プロンプトの管理、生成物の整理、どの指示でどの画像が出たかの記録といった作業は、手作業では抜け落ちがちです。こうした反復作業を、開発者が普段使うツールの中に取り込んで自動化する手立てとして注目されているのが、Gemini と MCP（Model Context Protocol） を組み合わせた画像生成です。

本記事では、2026年時点の実情を踏まえ、MCP の考え方から、画像生成 MCP サーバーの役割、Gemini CLI や対応クライアントへの登録、ツール呼び出しの流れ、そしてバッチ生成・プロンプト管理・provenance 記録といった実務運用までを整理します。ローカル実行と API 利用の使い分けにも触れ、どの規模でどちらを選ぶかの判断材料を示します。

MCP（Model Context Protocol）とは何か

MCP は、AIモデルやそれを組み込んだアプリケーションを、外部のツールやデータソースへ接続するためのオープンな標準プロトコルです。従来は、AIから外部機能を呼び出すたびに、クライアントごと・サービスごとに個別の連携を作り込む必要がありました。MCP はこの接続を共通の仕様に置き換え、対応クライアントであれば同じ MCP サーバーをそのまま利用できるようにします。

構成はシンプルで、機能を提供する側を MCP サーバー、それを利用する側を MCP クライアント（ホスト）と呼びます。サーバーは「どんなツール（機能）を持っているか」をクライアントへ公開し、クライアント側のモデルは必要に応じてそのツールを呼び出します。ツールの一覧取得、呼び出し、結果の受け渡しといったやり取りが標準化されているため、一度サーバーを用意すれば複数のクライアントで使い回せる点が利点です。

画像生成の文脈では、この仕組みによって「画像を作る」という機能を一つのサーバーとして切り出し、Gemini CLI をはじめとする対応クライアントから同じ手順で呼び出せるようになります。

Gemini CLI などのクライアントが、設定に登録した画像生成 MCP サーバーへプロンプトをツール呼び出しとして送り、生成された画像を受け取る流れを示した図。バッチ用プロンプトファイルと provenance ログも描かれている — MCP を介した画像生成の全体像で、クライアントから MCP サーバーへツール呼び出しを送り生成画像を受け取り来歴を記録する

画像生成 MCP サーバーの役割

画像生成 MCP サーバーは、テキストのプロンプトを受け取り、画像生成モデルを呼び出して結果を返すことに特化したサーバーです。クライアントに対しては、たとえば「プロンプトから画像を生成するツール」や「既存画像を編集するツール」といった単位で機能を公開します。クライアント側のモデルは、ユーザーの指示を解釈し、適切なツールへ引数を渡して呼び出します。

サーバーが内部で何を行うかは実装によって異なります。代表的なのは、Gemini の画像生成モデルや Imagen 系のモデルを API 経由で呼び出す構成です。この場合、サーバーは受け取ったプロンプトと生成パラメータを API に渡し、返ってきた画像をファイルとして保存したり、データとしてクライアントへ返したりします。ローカルの生成モデルを動かす実装もあり、こちらはネットワークを介さずに画像を作ります。

重要なのは、クライアントから見れば「ツールを呼ぶ」という操作は共通で、その裏側が API か手元のモデルかを意識せずに使える点です。サーバーを差し替えれば、呼び出し方を変えずに生成の基盤だけを切り替えられます。

Gemini CLI や対応クライアントへの登録

Gemini CLI は MCP サーバーの利用に対応しており、設定ファイルにサーバーを登録することで、その機能を対話やコマンドから呼び出せるようになります。登録はユーザー設定ファイル（~/.gemini/settings.json）またはプロジェクト直下の設定に、mcpServers としてサーバーの起動方法を記述する形が基本です。

次は、npm パッケージとして配布される画像生成 MCP サーバーを、コマンド実行で起動する形で登録する例です。API キーは設定ファイルへ直接書かず、環境変数から渡す形にしておくと安全です。

{
  "mcpServers": {
    "image-generator": {
      "command": "npx",
      "args": ["-y", "mcp-server-gemini-image-generator"],
      "env": {
        "GEMINI_API_KEY": "$GEMINI_API_KEY"
      }
    }
  }
}

この command と args は、クライアントがサーバープロセスをどう起動するかを表します。ローカルにクローンしたサーバーを直接動かす場合は、次のようにエントリポイントを指定する形にします。

{
  "mcpServers": {
    "image-generator": {
      "command": "node",
      "args": ["./mcp-server-gemini-image-generator/dist/index.js"],
      "env": {
        "GEMINI_API_KEY": "$GEMINI_API_KEY"
      }
    }
  }
}

設定を保存したら、環境変数へ API キーを用意してから Gemini CLI を起動します。起動時にクライアントが登録済みの MCP サーバーへ接続し、公開されているツールを読み込みます。

# API キーを環境変数へ
export GEMINI_API_KEY="your-api-key"

# Gemini CLI を起動（登録済み MCP サーバーが読み込まれる）
gemini

登録済みのサーバーやツールが正しく認識されているかは、Gemini CLI の対話中に MCP の状態を確認するコマンド（/mcp）で一覧できます。ここにサーバーと公開ツールが表示されれば、呼び出しの準備は整っています。同じ設定の考え方は、MCP に対応する他のクライアントでも共通しており、記述箇所こそ違えど「サーバーの起動方法と環境変数を登録する」という流れは変わりません。

画像生成ツールの呼び出しフロー

登録が済むと、あとは自然言語で指示を出すだけで、モデルが必要なツールを判断して呼び出します。処理の流れは概ね次のように進みます。

ツールの提示 — クライアントが MCP サーバーから公開ツールの一覧と、それぞれが受け取る引数の仕様を取得する。
呼び出しの判断 — ユーザーの指示を解釈したモデルが、画像生成ツールを呼ぶべきと判断し、プロンプトやサイズなどの引数を組み立てる。
ツールの実行 — MCP サーバーが引数を受け取り、画像生成モデルを呼び出して画像を生成する。
結果の返却 — 生成された画像がファイルとして保存される、あるいはデータとしてクライアントへ返され、結果が提示される。

利用者から見た操作は、たとえば次のように指示するだけです。生成条件を細かく指定したい場合は、そのまま文章に含めれば、モデルが引数へ落とし込みます。

# 対話中に自然言語で依頼する
gemini "夕暮れの港町を上空から俯瞰した風景を、横長で生成して保存して"

複数ステップの編集も、同じサーバーが編集ツールを公開していれば連続して依頼できます。直前に生成した画像を対象に「空を夜に変えて」といった指示を続ければ、モデルは文脈を保ったまま編集ツールを呼び出します。どこまで文脈を引き継げるかはクライアントとサーバーの実装に依存するため、意図した対象へ確実に適用したい場合は、対象ファイルを明示して依頼するほうが安定します。

バッチ生成・プロンプト管理・provenance の記録

単発の生成であれば対話で十分ですが、制作の現場では同種の画像をまとまった枚数で作ることが多く、ここで自動化の効果が効いてきます。プロンプトを外部ファイルにまとめておき、それを順に流し込む形にすれば、生成の再現性と一覧性が高まります。

プロンプト管理の基本は、生成条件をコードやUIの操作履歴に埋もれさせず、独立したデータとして持つことです。次は、プロンプトを一行ずつ記述したファイルを読み、順に生成を依頼する素朴な例です。実際の呼び出し方はクライアントに合わせて調整しますが、考え方はどの環境でも共通します。

# prompts.txt に生成したいプロンプトを1行ずつ列挙しておく
while IFS= read -r prompt; do
  gemini "次の内容で画像を生成して保存して: $prompt"
done < prompts.txt

枚数がまとまるほど重要になるのが provenance（来歴）の記録 です。どのプロンプトで、どのモデルの、どのパラメータ（サイズ、シード、生成日時など）から、どの画像が生成されたのかを、画像とは別に記録しておきます。これがないと、後から「この画像をもう一度作りたい」「少しだけ条件を変えたい」といった要望に応えられなくなり、生成物の管理も破綻しがちです。

記録は、生成物と対応づく形の構造化データにしておくと扱いやすくなります。たとえば、画像ごとに次のようなメタデータを残す形です。

{
  "file": "port-town-aerial-0001.png",
  "prompt": "夕暮れの港町を上空から俯瞰した風景、横長",
  "model": "gemini-image-generation",
  "parameters": { "aspect_ratio": "16:9", "seed": 12345 },
  "created_at": "2026-07-20T10:32:00+09:00"
}

この来歴データを画像と同じディレクトリに並べる、あるいは一つの索引ファイルへ追記していく運用にすると、生成物の追跡と再生成が容易になります。加えて、生成AIによる画像であることを明示する用途にも役立ちます。MCP サーバーの中には、こうしたメタデータの保存まで担う実装もありますが、担わない場合は呼び出し側で記録する仕組みを用意しておくのが実務的です。

ローカル実行と API 利用の使い分け

画像生成 MCP サーバーの裏側は、ホスト型の API を呼ぶ構成と、手元のマシンで生成モデルを動かす構成に大きく分かれます。どちらを選ぶかは、品質・コスト・機密性・運用負荷のバランスで決まります。

API を使う構成は、Gemini や Imagen 系といった高品質なモデルを、手元のGPUや環境構築なしに利用できる点が強みです。導入が速く、モデルの更新も提供側に任せられます。一方で、生成量に応じた課金が発生し、プロンプトや生成物が外部サービスを経由するため、機密性の高い素材では取り扱いに注意が必要です。

ローカル実行は、オープンな画像生成モデルを自分の環境で動かす構成で、データを外部へ出さずに完結できる点と、生成量が増えても追加課金が発生しない点が利点です。反面、相応のGPUリソースと環境構築が必要で、モデルの選定や更新も自分たちで担うことになります。

実務では二者択一にせず、用途で使い分けるのが現実的です。品質を最優先する本番用の素材は API 側の高品質モデルで、機密性の高い検証や大量の下書き生成はローカルで、といった振り分けが取れます。MCP を挟んでおけば、呼び出し側の手順を変えずにサーバーを差し替えられるため、この使い分けを後から調整しやすくなります。

まとめ

Gemini と MCP を組み合わせた画像生成の要点は、単に「コマンドで画像が作れる」ことではなく、画像生成という機能を標準化されたサーバーとして切り出し、開発者が使い慣れたクライアントの中で自動化・管理できるようにする点にあります。MCP サーバーを一度登録すれば、自然言語の指示からツール呼び出しへとつながり、バッチ生成やプロンプト管理、provenance の記録といった運用を組み込めます。

導入の順序としては、まず単発の生成で呼び出しの流れを確かめ、次にプロンプトを外部化してバッチ化し、そのうえで来歴の記録とローカル・API の使い分けを整えていく進め方が無理なく進みます。生成の量が増えるほど、記録と管理の設計が効いてくるため、これらを後回しにせず初期から組み込んでおくことをおすすめします。

エンハンスド株式会社では、生成AIを実務のワークフローへ組み込む支援を行っています。MCP を用いたツール連携の設計、画像・文章生成の自動化、プロンプトや生成物の管理と provenance の記録、ローカルと API を組み合わせた構成の検討まで、要件定義から運用設計までを一貫してサポートします。AI活用と業務自動化の進め方をお考えの際は、お気軽にご相談ください。

関連サービス