記事公開日
Claudeで画像が作れない ― Azure OpenAIのgpt-image-2をGoogle Workspace認証で社内展開する
この記事のポイント
Claude は画像を生成できません（公式ドキュメントに明記）。Azure OpenAI の gpt-image-2 を、全社員が持つ Google Workspace アカウントだけで呼び出せる MCP サーバーを自作した PoC の記録です（2026年8月時点）。この記事の構成図・カバー画像・作例は、すべてその基盤で生成しました。
- 認証を二段に分ける：本人確認は Google Workspace、モデルの呼び出しはマネージド ID。あらかじめ配る資格情報が1つもないため、利用量の記録も上限も利用停止も後から載ります。
- 環境差は、人に触ってもらうまで見つからない：「Azure で画像生成ができる」の確認だけなら半日です。時間がかかったのは、自分以外が使い始めてからでした。
- 自分の権限だけでは完結しない作業を見積もる：Azure・Google Workspace・Claude の3環境にまたがり、それぞれの管理担当者への依頼と待ち時間が積み上がりました。
こんにちは！DXソリューション営業本部の大和矢です。
Claude Code に「〇〇の画像を作って」と頼んだことはあるでしょうか。
筆者の環境では、写真のような絵ではなく図形を組み合わせた簡易的な図（SVG）が返ってきました。図としては読めるのですが、資料に貼れる品質ではありません。
人に何かを説明するとき、「ここに1枚あれば伝わるのに」と思う場面がたびたびあります。この記事にも、構成図とカバー画像が要りました。
その1枚を、Claude Code にそのまま作らせたい。これが今回の出発点です。
そこで、Azure OpenAI の画像生成モデル gpt-image-2 を、会社の Google Workspace アカウントだけで呼び出せる MCP サーバーを作りました。利用者は API キーもクライアントシークレットも持ちません。
実装コードよりも、「なぜこの形にしたのか」と「利用者は何をすればよいのか」に寄せて書いています。
なお本記事は検証段階（PoC）の記録です。社内への展開はこれからで、検証環境で少人数に試用してもらった結果にもとづきます。
Claude は絵を描けない ― これは公式にも書いてある
これは筆者の環境だけの話ではありません。
Claude Code が内部で呼んでいるのは Claude という言語モデルで、画像を生成できないことは公式ドキュメントに明記されています。
No, Claude is an image understanding model only. It can interpret and analyze images, but it cannot generate, produce, edit, manipulate, or create images.
（いいえ。Claude は画像を理解するためのモデルです。画像を解釈・分析できますが、生成・作成・編集・加工はできません）
― Vision - Claude Docs
ただし、まったく何も描けないわけではありません。ヘルプセンターには、写真やイラストは作れないが、図・チャート・インタラクティブなビジュアルなら HTML と SVG で組み立てられる、と書かれています。
つまり「図は描けるが、絵は描けない」のが公式の立ち位置です。冒頭で SVG が返ってきたのは、仕様どおりの振る舞いでした。
ところが実務では、提案書の挿絵や資料の表紙のように絵そのものが要る場面が日常的にあります。文字だけのページに1枚あるかないかで、読み手の印象は変わります。
需要はあるのに、Claude の中に道具がありません。
なぜ Azure OpenAI と Google 認証なのか
画像生成モデルは各社から出ています。その中で Azure OpenAI を選んだ理由は、すでに手元にあったからです。
筆者の所属する DX ソリューション営業本部には、検証やアプリ開発で使っている Azure の開発環境があります。そこで使える gpt-image-2 の品質を確かめたところ、資料に貼れる水準でした。
新しいサービスを引き込めば、契約・稟議・セキュリティ確認といった手続きが最初に発生します。すでに使っている環境の中で完結すること自体が、大きな導入コストの削減でした。
ところが、Azure のアカウントは全社員が持っていない
Azure を使うには Microsoft Entra ID のアカウントが要ります。
しかし会社の共通基盤は Google Workspace で、Microsoft Entra ID は全社員に配られていません。持っているのは、Azure を業務で使っている筆者の部門など一部だけです。
一方、Google Workspace のアカウントは全社員が持っています。メールもカレンダーもそこにあります。
使いたいモデルは Azure にあり、全社員に行き渡っている ID は Google にある。
この2つを橋渡しするのが、今回作った MCP サーバーです。Google 認証を選んだのは好みの問題ではなく、条件を満たす ID がそれしかなかったからです。
「API キーは配らない」という要件が、設計を決めた
この開発は、本部長からの依頼で始まりました。そのとき機能要件として提示されたのが、次の一行です。
Google 認証で、社員が API キーもシークレットも持たずに使えるようにすること。
いちばん簡単なのは、社員それぞれに Azure OpenAI の API キー（サービスを使うためのパスワードのような文字列）を配り、各自の PC から直接モデルを呼ばせる形です。作るだけなら一瞬で終わります。ただし、これはセキュリティ上おすすめできません。理由は3つあります。
| キーを配ると起きること | なぜ困るのか |
|---|---|
| 流出したら誰でも使える | キーは「持っている人＝正当な利用者」として扱われます。設定ファイルごとチャットに貼られた時点で、社外の誰でも使えます。 |
| 誰がいくら使ったか分からない | キーは個人を識別しません。費用が増えても、どの部署の誰の利用なのか追えません。上限を設けることもできません。 |
| 個別に止められない | 退職者ひとりを止めるために、キーを作り直して全員に配り直すことになります。 |
だから中継サーバー（MCP サーバー）を置く
3つとも「利用者の手元にキーがある」ことに起因しています。であれば、モデルを呼べる場所を1か所に絞るのが素直な解決策です。
社員と Azure OpenAI のあいだに中継サーバーを1台置き、利用者はそこへ「こういう絵を作って」と依頼します。利用者は Azure を直接呼ぶ手段そのものを持ちません。
1か所を通るようになると、生成1枚ごとに誰が使ったかを記録でき、上限を生成前に判定でき、アカウントを止めればその人だけが止まります。
API ゲートウェイを使わなかった理由は費用
この手の中継役には、API ゲートウェイという専用のサービスがあります。当初はこちらを本命と考えていましたが、価格を調べて取り下げました。「利用者ごとに上限を掛ける」機能が、いちばん安い従量課金のプランでは使えないと公式に明記されていたためです。1つ上のプランは時間あたりの課金で、誰も使っていない時間帯も止まりません。
そこでコンテナを1つ動かすだけの構成にしました。使われていないあいだは起動数を0まで落とせるため、固定費がほとんどかかりません。上限の判定も、自分で書けば数十行で済みます。いまは上限を設けていませんが、必要になったときも追加の費用なしで足せます。
とはいえ、API ゲートウェイが不利なわけではありません。複数の AI サービスをまとめて社内に公開する段階に進めば、設定だけで足りる利点が上回ります。今回はモデル1つ・入口1つという小ささが、自作を選ばせました。
ただし、ここで次の問いが残ります。
その中継サーバーはキーを持つのか？持つなら、キーの置き場所が社員の PC からサーバーに移っただけです。
解き方は「認証を二段に分ける」だけ
「社員の本人確認」と「モデルを呼ぶ権限」を、まったく別の仕組みで持たせました。これで、利用者にキーを配らずに済み、中継サーバーもキーを持たずに済みます。
※図は Claude Code を例にしています。Cowork やチャットでも、①の依頼元が変わるだけで経路は同じです。
| 段 | どこからどこへ | 何で身元を示すか |
|---|---|---|
| 一段目 | 社員の PC → 中継サーバー（MCP サーバー） | 会社の Google Workspace アカウント。ブラウザでいつものログインをするだけで、サーバーは「自社の社員である」と確認できます。 |
| 二段目 | 中継サーバー → Azure OpenAI・ストレージ | マネージド ID。Azure がサーバー自身に与える身分証で、パスワードを持たずに他の Azure サービスを呼べます。 |
③④のとおり、Azure OpenAI を呼ぶときも画像をストレージに保存するときも、使うのはマネージド ID だけです。Microsoft もこの方式を推奨しています（Foundry tools authentication and authorization）。
⑤⑥が戻り経路です。サーバーは期限付きの URL を返すだけで、画像そのものは送りません。その URL から画像を取ってきて保存するのは、利用者側で動くフック（AI の応答が返るたびに自動で実行される小さなプログラム）です。
ここでの要点は、AI に「保存してください」と頼む形にしなかったことです。お願いは省略されることがあり、実際この仕組みを入れる前は「絵はできたのに保存されていない」ことがありました。フックにすれば、その取りこぼしがなくなります。
Claude Code では、頼んだ数十秒後には画像がフォルダに入っています。リンクをクリックする操作も、保存先を選ぶダイアログもありません。
副次的な利点として、画像そのものを応答に載せないぶん、AI が一度に扱える情報量（コンテキストウィンドウ）の消費も抑えられます。
「トークンもキーではないか」について：
そのとおりです。認証が終わると、サーバーが発行したトークンが利用者の手元に1つ残ります。資格情報がゼロなのではなく、あらかじめ配っておくものがゼロだとお考えください。
キーとの違いは期限があることと、誰のものか分かることの2点です。キーは無期限で、しかも全員が同じものを使います。1本漏れれば作り直して全員に配り直すことになります。トークンは放っておいても期限が来れば失効しますし、利用者ごとに別のものが発行されます。
サーバーが保存しているのは、元に戻せない形に変換した値だけです。サーバー側のデータが漏れても、トークンそのものは復元できません。
キーを「配らない」ではなく「使えなくする」
さらに踏み込んで、Azure 側でキー認証そのものを無効化しました。Azure OpenAI の disableLocalAuth と、ストレージの共有キーアクセス無効化です。公式にも「Microsoft Entra 認証を使うには、キーベース（ローカル）認証を無効にする必要がある」と明記されています（Configure keyless authentication with Microsoft Entra ID）。
実際に管理者権限でキーを取り出そうとすると、2つのリソースで結果が違いました。Azure OpenAI は取得そのものが拒否され（Failed to list key. disableLocalAuth is set to be true）、ストレージはキーの値は取得できるものの、そのキーでは認証が通りません。
見え方は違いますが、結果は同じです。キーを配ったところで、誰も使えません。
社外の人は Google が手前で止める
個人の Gmail アカウントで試したところ、こちらのサーバーに届く前に Google が拒否しました。Google 側の同意画面を「組織内限定」で構成しているためです。
防御は二重になりました。外側は Google、内側は自前サーバーの組織判定です。外側で止まるため内側の判定はふつう出番がありませんが、多層防御として残しています。
利用者から見た手順 ― 準備するものは1つもない
どれだけ設計が正しくても、導入が面倒なら使われません。現在、利用者がするのは、設定画面からプラグインを追加して、そのまま認証するだけです。2分ほどで終わります。
この形にできるのは、Claude の組織管理者が全社へプラグインを配布できる仕組みに乗せているからです。ここでいう管理者とは、会社で契約している Claude の管理画面を触れる担当者のことで、情報システム部門や Azure の管理者とは別です。
その担当者が配布元を登録しておけば、利用者は設定画面から選んで追加するだけです。
| 手順 | 利用者がやること | 裏で起きていること |
|---|---|---|
| 1 | 設定画面の一覧から、部品（プラグイン）を追加する | 管理者が登録した配布元から、必要なファイル一式が取り込まれます。 |
| 2 | ブラウザが開くので、会社のアカウントで連携を許可する | ブラウザで会社のアカウントにログイン済みなら、画面が一瞬開いて戻るだけで終わります。以降この操作は要りません。 |
版を上げたときも、開発側が「この版を出す」と目印を付けるだけで、あとは自動で全員に届きます。管理者が配り直す作業も、利用者側の作業もありません。
ただしこの自動化は、標準でついてくるものではありません。先ほどの Claude の管理者が、各部門の配布物を集めて全社の一覧へ反映する仕組みをあらかじめ用意してくれていました。今回はそこに載せただけです。
この手順は、開発者向けの Claude Code だけでなく、一般業務向けの作業環境「Claude Cowork」でも同じです。ただし Cowork では、部品の配布とは別に先ほどの管理者が、外部サービスへの接続そのものを許可する必要があります。許可がないと、部品は届いているのに接続ボタンが押せません。
使う場所によって管理者の作業が変わる点は、社内展開の計画に入れておくと安全です。
利用者が入力する秘密情報はありません。コピー＆ペーストする場面が1つもないのが狙いです。以降は日本語で頼むだけです。
実際に頼んでいる画面がこちらです。スラッシュコマンドは打っていません。日本語の一文だけで、社内の画像生成スキルが自動で立ち上がっています。
面白いのは、コストの使い分けを Claude が自分でやっているところです。まず狙いの違う2案を medium で出し、採用する1枚だけを high で作り直しています。画質もサイズも、こちらは指示していません。
出てきたのがこの1枚です。
保存先は使う場所で変わります。Claude Code なら、そのとき開いているプロジェクトのフォルダです。Cowork とチャットは処理がクラウド側で動くため保存先もクラウド上になり、手元に置くにはダウンロードします。1枚あたりの生成時間は、筆者の環境では10〜60秒程度でした（公式も「モデル・サイズ・品質により通常10〜30秒」と案内しています。Azure OpenAI image generation models）。
画風のテンプレートは、社内にあったものをそのまま使った
いまの1枚、依頼文には白背景もブランドの配色も書いていません。それでもトーンが揃ったのは、サーバー側に画風のテンプレートを置いてあるからです。
社内に配ると、まず画風がバラバラになります。同じ資料の中で写実的な絵とフラットなイラストが混ざると、それだけで素人っぽく見えます。
ここは自分で考えていません。社内の別のメンバーが以前から公開していたスキルに、画風のテンプレートが一式そろっていたので、それをサーバー側に載せ替えました。
テンプレートを選ぶのは利用者ではなく Claude です。「提案書用に」と伝えれば用途に合うものが適用され、「水彩で」のように画風を自分で指定したときは適用されません。迷ったら適用しないのが既定なので、利用者はテンプレートの存在を知らなくて構いません。
下はまったく同じ依頼文で、テンプレートなし（上）とブランド用テンプレート（下）の比較です。
プロンプトを書き換えていないのに、白背景・フラット・自社の配色に寄りました。利用者が画風を意識しなくても資料のトーンが揃うことを狙っています。
この記事の図も、この基盤で作りました：
上の全体構成図と、この記事のカバー画像（記事一覧ではサムネイルとして出ています）が、それにあたります。生成 AI の画像は文字が崩れやすいのが通説ですが、構成図の日本語ラベルも、カバー画像のタイトルもそのまま入りました。ただし毎回成功するわけではなく、構成図は矢印の向きが1本おかしくなって作り直しています。
ちなみにカバー画像は、普段なら自分で作っています。今回は記事の内容をそのままツールに渡してみた結果です。正直、少し「AI が作った感」が出ていますが、それも含めて今回はこのままにしておきます（笑）。
よくある質問
Q. 日本リージョンで動かせますか？
中継サーバーと画像の保管先は日本に置けますが、画像生成そのものは海外リージョンで処理されます。
画像生成モデルの提供リージョンは限られており、日本は含まれていません（最新の対応状況はリージョン別の提供状況でご確認ください）。
データの所在地に要件がある案件では、ここが最初の確認事項になります。
Q. モデルを使うのに申請は必要ですか？
公式ドキュメントでは、gpt-image-2 は一般提供（GA）、gpt-image-1 系は限定アクセス（申請が必要）と案内されています（2026年8月時点。Azure OpenAI image generation models）。
導入時点での最新の案内をご確認ください。
Q. 大人数が同時に使っても大丈夫ですか？
品質より先に問題になるのは、枠（クォータ）の確保です。
公式では画像生成の既定のレート上限はデプロイあたり毎分5枚と案内されており、増枠は申請で行います（2026年8月時点。Azure OpenAI image generation models）。
筆者の環境でも、割り当てが小さいと混雑時に待たされることを実測しました。全社展開を考えるなら、ここは最初に見積もっておくのが安全です。
Q. 同じ構成は他の会社でも作れますか？
作れると考えています。必要なのは特別な製品ではなく、次の3点を満たす設計です。
①全社員が持っている ID で本人確認する、②モデルの呼び出し権限はサーバー側に閉じる、③利用量を個人単位で記録する。
認証に使う ID は Google Workspace でも Microsoft Entra ID でも成立します。社内にどちらが全社展開済みかで選ぶのが実務的です。
なお、認証経路を2つ用意するのはおすすめしません。利用量の集計キーが個人のメールアドレスになるため、1人が2つのアカウントを持つと上限も記録も二重になります。
まとめ：認証を分ければ、配るものは無くなる
Claude に足りなかった画像生成を、すでに社内で使っている Azure のモデルで補い、全社員が持っている Google Workspace アカウントで使える形にしました。学びは3つです。
- 「キーは配らない」は制約ではなく設計指針：本人確認と呼び出し権限を分ける、この一点だけで、利用量の記録も上限も利用停止も後から設定できました。
- モデルより先に、全社員が持っている ID から考える：どんなに良いモデルでも、社員がそこに立てなければ使われません。認証に使う ID が全社に行き渡っているかが、実質的な出発点でした。
- 難所は技術ではなく環境：「Azure で画像生成ができる」ことの確認だけなら半日で終わります。時間がかかったのは、自分以外の人に触ってもらってからでした。手元の1台で試しているあいだは、利用者ごとの環境差が1つも見つかりません。
もう1つ、事前に見積もっておくとよいのが自分の権限だけでは完結しない作業です。今回は Azure・Google Workspace・Claude と3つの環境にまたがったため、認証に使うプロジェクトの用意、組織へのプラグイン配布、外部接続の許可といった場面で、それぞれの管理担当者に依頼して待つ時間が発生しました。
1件ずつは短くても、依頼して、確認して、直してもう一度依頼するという往復が重なります。実装そのものより、この調整のほうが日数を要しました。環境をまたぐ構成を検討するときは、誰に何を依頼する必要があるかを先に洗い出しておくと、見通しが立てやすくなります。
なお今後も、いきなり全社には開きません。いまは数人での試用にとどめ、次に部門単位で試験運用の期間を置き、そこで出た問題を潰してから全社へ広げる計画です。環境差も、管理担当者への依頼も、人数が増えてからでは後戻りしにくいためです。
社内で「AI を配りたいが、キーの管理が怖い」という話になったとき、この二段構えは有効な選択肢になります。まずは自部門の1リージョンだけで、1つのモデルを1つの入口から呼ぶ形を作ってみてはいかがでしょうか。そこまで動けば、あとは配る範囲を広げていく話になります。
QUICK E-Solutionsでは、AIを活用した業務効率化・システム導入から、各種アプリケーションの開発・導入まで対応しております。
提供するサービス・ソリューションは こちら に掲載しております。
システム開発・構築でお困りのことがありましたら、ぜひ一度 お問い合わせ ください。
また、ガバナンス整備・セキュアな利用環境構築・利活用コンサルティング・セキュリティレビューまで、Claude / Claude Code の組織導入を一貫して支援しています。AWS（Amazon Bedrock）経由での提供にも対応しています。支援内容は下記のサービスページ、および無料の「Claude 導入チェックリスト」をご覧いただくか、お問い合わせフォームよりお気軽にご相談ください。
▼ 無料ダウンロード資料
Claude 導入チェックリスト（情報システム・セキュリティ部門向け）
プラン選定・監査ログ・SSO・テナント制限・コスト管理・運用ポリシーまで、Claude / Claude Code を安全に導入するための確認項目を6カテゴリで整理。導入プロジェクトの進捗管理・監査証跡としてそのままご活用いただけます。
※このブログで参照されている、Google、Google Workspace、Gmailは、米国およびその他の国におけるGoogle LLCの商標または登録商標です。Microsoft、Azure、Azure OpenAI、Microsoft Entra IDは、米国およびその他の国におけるMicrosoft Corporationの商標または登録商標です。Claude、Claude Code、Claude Coworkは、米国およびその他の国におけるAnthropic, PBCの商標または登録商標です。その他、記載されている会社名および製品名は、各社の商標または登録商標です。
