はじめに

（30秒で読む結論）

Mermaidで構造だけ書く → それを「インフォグラフィック化」専用のGemに投げる → 白背景・日本語ゴシック体のビジネス向け図解が返ってくる
肝は いきなり長文を投げないこと。構造をMermaidで先に固定してから清書させる
日本語テキストと公式アイコンを綺麗に出したいなら、ナノバナナは「Pro」か「2」を選ぶ

この記事の対象読者はこんな人です。

構成図やフローはサッと描けるが、資料用に清書するのが地味に面倒なエンジニア

打ち合わせで「この仕組み、あとで図にして共有して」と言われがちな人

Geminiの画像生成（ナノバナナ）を、業務でどう使うか探している人

あなたも、エンジニア向けの図とビジネス向けの図のあいだで、毎回手作業の清書に時間を溶かしていませんか？

そこで、Mermaidをそのまま渡すと「白背景・日本語ゴシック体・公式アイコン付き」のインフォグラフィックに清書してくれるGemを作りました。プロンプトはたった4文です。全文そのまま載せます。

仕組み：なぜわざわざMermaidを噛ませるのか

最初は私も、図にしたい内容を文章のままナノバナナに投げていました。でもこれ、思ったより上手くいきません。長い説明文を渡すと、モデルが勝手に「ここは要らないな」と要約して、肝心の要素や矢印の向きが崩れるんです。

ここで効いてくるのがMermaidです。Mermaidは、要素と関係を厳密に書く「構造の中間言語」として使えます。先に構造を固定してしまえば、ナノバナナがやることは清書だけになる。役割を分けるイメージです。

頭の中のモヤモヤ
   ↓ 構造化（人間 + Mermaid）
Mermaid（骨組み・関係が確定した状態）
   ↓ 清書（ナノバナナ）
インフォグラフィック（見た目が整った状態）

Mermaidは設計者の頭の中、ナノバナナは清書担当のデザイナー——そう考えると分担がきれいに腹落ちします。設計の責任はこちらが持ち、見た目の責任は向こうに渡す。崩れやすい「要約」の工程を、人間側で先に終わらせておくのがコツなんです。

システムプロンプト（全文公開）

Gemのカスタム指示にこれを貼るだけです。

gem-custom-instruction.txt

入力内容を要約・構造化し、日本語ゴシック体でインフォグラフィック画像を生成して。公式のアイコンを使い視覚化すること。30文字以上の文章が入力された場合には、内容をまず要約して構造化してから画像生成してください。背景は白でタイトルは不要。

短いですが、1文ずつ役割があります。順に見ていきます。

「入力内容を要約・構造化し」——Mermaidでも長文でも、まず構造に落としてから描かせる。雑な入力でも崩れにくくなる土台です
「日本語ゴシック体で」——明朝やポップ体で出てくると資料に馴染まない。ビジネス資料の標準に寄せます
「公式のアイコンを使い視覚化すること」——AWSやサービスのアイコンを使わせる指定。後述しますが、ここは過度に期待しないのがコツ
「30文字以上の文章が入力された場合には〜」——うっかり長文を貼ってしまったときの保険。ここでも要約→構造化を先にやらせる
「背景は白でタイトルは不要」——資料やSlackに貼ったときに浮かないように。タイトルは自分で付けたいので任せない

太字にするほどの派手さはないプロンプトですが、毎回同じ品質で返ってくるのが地味に効きます。

モデル選びだけは注意（Nano Banana / Pro / 2）

ここだけは2026年前半に状況が変わったので、補足します。「ナノバナナ」は今や1つのモデルではありません。

通称	モデル	向いている用途
Nano Banana	Gemini 2.5 Flash Image	高速・軽量。日本語テキストは崩れやすい
Nano Banana Pro	Gemini 3 Pro Image	インフォグラフィック・図解・多言語テキスト
Nano Banana 2	Gemini 3.1 Flash Image	Pro相当の品質をFlashの速度で

今回のユースケースは「日本語の文字が読めること」と「図として破綻しないこと」が命です。初代（2.5 Flash Image）だと日本語が崩れがちなので、私はProか2を使っています。Googleも Nano Banana Pro を、アイデアの可視化・データのインフォグラフィック化・手書きメモの図解化に向く、と位置づけています。まさに今回やりたいことそのものでした。

Gem内での画像生成の可否や、選べるモデル（Fast / Thinking / Pro）は、契約プランやロールアウト状況によって挙動が変わる場合があります。本記事は2026年6月時点の情報です。最新の対応状況は公式の案内をご確認ください。

使い方は3ステップだけ

図解したい内容をMermaidで書く（普段どおりでOK）
そのMermaidを、上のプロンプトを設定したGemに貼って送る
返ってきた画像をそのまま資料・Slack・議事録に貼る

それだけです。私はVS Codeで書いたMermaidをコピペしているだけなので、清書の手間はほぼゼロになりました。正直、最初に試したときは「これでいいのか」と拍子抜けしたくらいです。

実例3つ：Mermaid → ナノバナナ

「で、結局どんな図が出るの？」が一番気になるところだと思います。毛色の違う3つで試しました。各例とも、上がQiitaでそのまま描画されるMermaid（＝ビフォー）、下がGemに通したあとの出力（＝アフター）です。

アフターの画像は、ご自身のGemで生成したものに差し替えてください。![...](画像URL) のURL部分を、生成画像のリンクに置き換えるだけです。

例1：AWS構成図（3層Webアプリ）

ビフォー（Mermaid）:

アフター（ナノバナナ）:

矢印だけだった構成が、アイコン付きで「どこからリクエストが来て、どこにデータが溜まるか」が一目で追えるようになります。

例2：データ分析基盤のパイプライン

ビフォー（Mermaid）:

アフター（ナノバナナ）:

「データがどこから来て、どう加工されて、最後に誰が見るのか」を非エンジニアに説明するとき、この清書版がかなり効きます。私の本業（ID-POSの分析基盤）でも、この粒度の図が一番伝わりました。

例3：業務フロー（シーケンス図）

ビフォー（Mermaid）:

アフター（ナノバナナ）:

時系列のやり取りは、シーケンス図のままだと読み手に予備知識を要求します。清書すると「申込んだら、決済されて、メールが届く」という当たり前の流れとして読めるようになる。ビジネス側に渡すならこちらです。

ハマったポイント

便利なんですが、万能ではありません。私が実際につまずいた3つを残しておきます。

1つ目は 公式アイコンの正確性には期待しすぎない こと。「公式のアイコンを使って」と指示しても、ピクセル単位で正確なAWSアイコンが出るわけではなく、雰囲気の似たアイコンに寄せられることがあります。厳密なブランドガイドライン準拠が必要な対外資料では、ここは手で差し替える前提で使うほうが安全でした。

2つ目は日本語の崩れ。前述のとおり初代モデルだと文字化けのような崩れが出ることがあります。私はここで一度ハマって、原因がプロンプトではなくモデル選択だったと気づくのに時間を使いました（根本原因はモデル側、というやつです）。Proか2に切り替えたら解決しました。

3つ目は入力が複雑すぎるとき。ノードが20も30もあるMermaidを丸ごと投げると、要約の段階で要素が間引かれることがあります。図が大きいときは、サブグラフ単位で分割して投げるほうが破綻しにくいです。

社外秘の構成図やシステム情報をクラウドの生成AIに入力する際は、社内のデータ取り扱いポリシーを必ず確認してください。具体的なホスト名・IP・認証情報などは、ダミーに置き換えてから渡すのが無難です。

まとめ

Mermaidで構造を固定 → ナノバナナで清書、と役割を分けると、ビジネス向け図解の手間がほぼ消える
プロンプトは4文。コピペしてGemに貼るだけ
日本語と図解の品質を出したいなら、モデルは Pro か 2 を選ぶ
公式アイコンの厳密性と、社外秘情報の扱いだけは注意

正直、清書という作業がこんなにあっさり外注できるとは思っていませんでした。同じように「Mermaidは描けるけど資料化が面倒」な人は、一度このGemを作って試してみてください。もっと良いプロンプトの改良案があれば、ぜひコメントで教えてください。次は、このGemをスケジュール実行と組み合わせて定例資料を自動更新する話を書こうと思っています。