Mermaid図解をGeminiナノバナナで清書する方法

エンジニア同士のコミュニケーションでは欠かせないMermaid図。しかし、そのまま会議資料や顧客向けドキュメントに貼ると「何が書いてあるかわかりにくい」と言われた経験がある人は少なくないだろう。テキストベースのMermaidは構造を正確に表現できる半面、見た目の整った「ビジネス向け図解」にはなりにくい。

このギャップを埋めるのが、Google Geminiの画像生成機能、通称「ナノバナナ」を使った新手法だ。Qiitaユーザーのktdatascience氏が2026年6月6日に公開した記事によれば、たった4文のシステムプロンプトで、Mermaidの「設計図」を白背景・日本語ゴシック体・公式アイコン付きのインフォグラフィックに変換できるという。しかも、清書にかかる時間はほぼゼロに近い。

なぜMermaidを噛ませるのか

この手法の要は、いきなりナノバナナに図の説明を文章で投げないことにある。筆者は初期の試行で、長文を直接画像生成APIに渡すと、モデルが内容を勝手に要約してしまい、要素や矢印の向きが崩れる問題に直面したという。

そこで考案されたのが、Mermaidを中間言語として使うアプローチだ。Mermaidは要素と関係を厳密に記述する「構造の中間言語」として機能する。先に人間がMermaidで構造を固定してからナノバナナに渡せば、モデルに任せるのは「清書」だけになる。

この役割分担は明確だ。人間が設計（構造）の責任を持ち、AIは見た目の調整だけを担当する。崩れやすい「要約」の工程を人間側で先に終わらせてしまうことで、品質の安定した出力が得られる。

4文のシステムプロンプトを解説

公開されているGem用カスタム指示（システムプロンプト）は以下の通りだ。

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

この4文には以下の意図が込められていると説明されている。

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

モデル選びの注意点

2026年前半時点で、ナノバナナは単一のモデルではなくなっている。用途に応じて以下の3つから選ぶ必要がある。

• Nano Banana（Gemini 2.5 Flash Image）：高速・軽量だが、日本語テキストは崩れやすい。
• Nano Banana Pro（Gemini 3 Pro Image）：インフォグラフィック・図解・多言語テキストに向く。今回のユースケースに最適。
• Nano Banana 2（Gemini 3.1 Flash Image）：Pro相当の品質をFlashの速度で実現する。

日本語の文字が読めることと図として破綻しないことが最優先なら、Proか2を選ぶべきとしている。GoogleもNano Banana Proを「アイデアの可視化・データのインフォグラフィック化・手書きメモの図解化」に向くと位置づけており、まさに今回のユースケースに合致する。

3ステップの使い方

使い方は驚くほどシンプルだ。

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

VS CodeでMermaidを書いてコピペするだけで、清書の手間はほぼゼロになる。筆者が公開した実例は3種類で、いずれもMermaidの簡素な図がナノバナナを通して見違えるように変化している。

AWS構成図（3層Webアプリ）の例では、矢印だけだった構成がアイコン付きで「どこからリクエストが来て、どこにデータが溜まるか」が一目で追えるようになる。データ分析基盤のパイプラインの例では、非エンジニアに説明する際に清書版が効果的だという。業務フロー（シーケンス図）の例では、時系列のやり取りをシーケンス図のままだと読み手に予備知識を要求するが、清書すると「申込んだら、決済されて、メールが届く」という流れとして自然に読めるようになる。

編集部の見解

この手法が特に興味深いのは、AIの「要約癖」を逆手に取っている点だ。画像生成AIに長文を投げると、モデルはしばしば内容を削りすぎてしまう。しかし、Mermaidという「冗長性のない構造表現」を先に与えてしまえば、AIが余計な要約をする余地がなくなる。これは、生成AIを業務で使う際の「プロンプトエンジニアリング」の新しい形を示している。

短期的には、議事録や仕様書の図解作成にかかる時間が大幅に削減される。とくに「エンジニアが書いた図はわかりにくい」と言われがちな現場で、この手法は即効性の高い改善策になる。SlackやNotion、Google Docsに直接貼れる画像が生成されるため、フローを変えずに導入できるのも実用的だ。

長期的に見ると、Mermaidのようなテキストベースの図式表現と生成AIの組み合わせは、より広がりを見せるだろう。今回の事例では「清書」に特化しているが、応用すれば「Mermaidから複数の視点の図を生成する」「古いアーキテクチャ図を最新のサービス構成に変換する」といった高度なユースケースも考えられる。ただし、公式アイコンの自動適用には限界があると筆者も認めており、完全な自動化にはまだ距離がある。

編集部として注目したいのは、この手法が本質的に「設計と装飾の分離」を実現している点だ。エンジニアは構造に集中し、AIは見た目を担当する。役割分担が明確だからこそ、品質が安定する。この考え方は、単なる図解作成を超えて、ソフトウェア開発のドキュメンテーション全般に応用できる可能性を秘めている。

参考

• 【図解】エンジニアの「雑なMermaid」を、ビジネス側に刺さる図解に変換する - Qiita — 2026-06-06公開