はじめに
GMOコネクトの永田です。
前回の記事で書いた通り、Claude Codeを使って提案スライドのドラフトを自動生成するワークフローを構築しました。
アーキテクチャ図は別途作成が必要（次回、Google AI Studio連携にチャレンジ予定）
Claude Code × Slidev で49ページの提案スライドは作れたものの、アーキテクチャ全体図やシーケンス図といった構造的なダイアグラムはSlidevのコンポーネントだけでは描けず、手つかずでした。
Gemini Chatで1枚ずつ生成する手もありますが、Claude Codeとの間を人手で橋渡しするのがとにかく面倒です😇
- デザイン指示をClaude Codeの会話からコピペしてGemini Chatに貼る
- 生成されたPNGをダウンロードしてプロジェクトに配置する
- スライドに挿入して表示を確認する
- 修正が必要ならまたGemini Chatに戻る……
10枚の挿絵でこれを繰り返すのは非常に手間です。
今回は、Claude CodeのAgent SkillとしてGemini API（Nano Banana Pro）を組み込んで、Claude Codeの中で完結するようにしました。指示書の作成から画像生成、レビュー、スライドへの挿入、Playwrightでの表示確認まで、Claude Codeが自律的に回してくれます。
Geminiの画像生成にはまだ粗さがあります。ただ、ゼロから図を描く必要がなくなるだけで、体感は大きく改善しました。
（最初に）まとめ
| 内容 | |
|---|---|
| Input | 前回生成した49枚のSlidevスライド |
| Output | 10枚の挿絵（アーキテクチャ図・シーケンス図・ダッシュボードモックなど） |
| 方法 | 3ステップ（計3プロンプト + 1 Agent Skill） |
| ツール | Claude Code / Nano Banana Pro (Gemini) / Playwright MCP |
| 成功の鍵 | illustration-request.md（デザイナー指示書）の品質 |
成果物・プロンプト・Agent Skill全文
完成イメージ
できあがった挿絵入りスライドを3枚だけ紹介します。
① アーキテクチャ全体図（ill-01）
AWSサーバーレス・マネージドサービスを軸にしたクラウドネイティブアーキテクチャの全体像です。CloudFrontからALB、ECS、Auroraへ至るメインフローに加え、認証・ダッシュボード・CI/CDの各フローを一枚にまとめています。
② 多層防御オニオンモデル（ill-03）
WAF・GuardDuty・CloudTrailによる多層防御をオニオンモデルで図にしました。エッジ、認証、コンピュート、データの4層を同心円で表現しています。
③ QuickSight ダッシュボード（ill-06）
QuickSightダッシュボードのモックアップです。SlidevのProcessFlowコンポーネントで描いたデータパイプラインと、生成したダッシュボード画像を並べています。
全体ワークフロー
前回記事のPhase 1〜3に続く Phase 4、挿絵の作成が今回の範囲です。
Phase 1-3（前回記事）
Step 1-3: テンプレート整備
Step 4-5: ストーリー作成
Step 6-7: Slidev化・レビュー
↓
Phase 4（本記事）
Step 8: Agent Skill作成（Claude Codeが自分で使う道具を自分で作る）
Step 9: デザイナー指示書の作成（illustration-request.md）
Step 10: 挿絵の生成・レビュー・スライド挿入
面白いのは、Claude Codeがこの全工程を一人で回すところです。
- Gemini APIを呼び出すAgent Skillを自分で実装する
- スライド内容を分析し、620行のデザイナー指示書を書く
- 自作のSkillでGemini APIを叩いて画像を生成する
- 生成された画像を読み取り、仕様との差分を確認する
- slides.mdを編集してスライドに挿入する
- Playwright MCPでスクリーンショットを撮り、レイアウトのバランスを見る
- 必要があれば3〜6を繰り返す
事前準備
-
Nano Banana Pro（Gemini）のAPIキーを取得する
- 参考: https://note.com/naoki_35/n/nfd7fea56b151
-
.envにGEMINI_API_KEY=your-api-keyを設定
-
Claude Codeは前回記事と同じ構成
- モデル: Opus 4.6
- MCPプラグイン:
playwright
具体的な実施手順
Step 8: Nano Banana Pro Agent Skill の作成
Chat Session: 新規、Plan mode で方針確認後に実施
Agent Skill とは
Claude CodeのAgent Skillは、Claudeの能力を拡張するモジュール式の仕組みです。.claude/skills/ ディレクトリに SKILL.md を置いておくと、Claudeがリクエストの内容を見て自動的に検出・使用します。明示的にコマンドを打つ必要はなく、たとえば「挿絵を生成して」と頼めば、SKILL.mdの description にマッチしてSkillが動き出します。
今回はGemini APIで画像を生成・編集するSkillを作りました。
プロンプト
Claude Codeへの依頼内容です。
デザイナー（=Nano Banana Pro）の呼び出しをClaude Code Agent Skillにしたい。
他の案件でも再利用できる汎用的なスキルとして作成すること。
**要件:**
- 画像の新規生成（テキストプロンプトから画像を生成）
- 既存画像の編集（テキスト＋画像入力による画像変換）
- Nano Banana Pro API (`gemini-3-pro-image-preview`) を Python SDK (`google-genai`) で呼び出す
- Agent Skill として `.claude/skills/generate-illustration/` に配置
- `SKILL.md`（ワークフロー定義）+ `scripts/generate_image.py`（API呼び出し）の2ファイル構成
- CLI引数: `--prompt`, `--output`, `--input`（編集時）, `--aspect-ratio`, `--image-size`
プロンプト全文（Python SDKの使い方やAgent Skillの構成例を含む）:
生成されたファイル
.claude/skills/generate-illustration/
├── SKILL.md # スキル定義（ワークフロー手順）
└── scripts/
└── generate_image.py # Gemini API呼び出しスクリプト（約90行）
SKILL.mdには次のワークフローが書かれています。
- ユーザーの指示を解釈し、新規生成か編集かを判断する
- 日本語の指示を英語プロンプトに変換する（Geminiは英語のほうが画像生成の精度が高いため）
- Pythonスクリプトを実行して画像を生成・編集する
- 生成画像を表示してユーザーに報告する
generate_image.pyは、--prompt・--output・--input などのCLI引数を受け取ってGemini APIを呼ぶだけのスクリプトです。
作成例:
Claude Codeが自分で使う道具を自分で作っているのが面白いところです。一度Skillを作ってしまえば、別のChatセッションで「挿絵を生成して」と頼むだけで、Claudeが勝手にこのSkillを拾って使ってくれます。
Step 9: デザイナー指示書（illustration-request.md）の作成
Chat Session: 新規、Plan mode で方針確認後に実施
何を作るか
スライドの中身を見て、Slidevコンポーネントでは描ききれない構造的なダイアグラムを洗い出します。その上で、デザイナーであるNano Banana ProがMarkdownだけを見て作業できる水準の仕様書を作ります。
プロンプト
design/slidev/slides.md にslidevのスライドMarkdownは作成済み。
残りは挿絵のデザイナーへの作成依頼だが、挿絵にする箇所のピックアップと、デザイナー向けの依頼内容をMarkdown(proposal/illustration-request.md)にまとめる。
- 共通的なデザイン指示と、個別の絵の具体的な指示を想定
- デザイナーがこのMarkdownのみの参照でも十分な内容にすること
- デザイナーの納品はPNG（デザイナー=NanoBananaProがPNG出力）
参考:
- design/proposal-knowhow.md
- proposal/story.md
- prompts/2_story/prompt-story.md
生成された仕様書
Claudeが約620行のproposal/illustration-request.mdを作成してくれました。
共通のデザイン指示として、McKinsey/BCG流のミニマルスタイル、カラーパレット（基本9色＋AWS構成図専用4色）、フォントやアイコンの規約、出力仕様（980×500px論理、1960×1000px実解像度）、そして3D効果・グラデーション・影・装飾を禁止するルールが定められています。
個別のイラスト仕様は10枚分です。
| ID | タイトル | 用途 |
|---|---|---|
| ill-01 | アーキテクチャ全体図 | AWS構成の全体俯瞰（最重要） |
| ill-02 | S3 Pre-signed URL データフロー | Before/After比較 |
| ill-03 | 多層防御オニオンモデル | セキュリティ4層構造 |
| ill-04 | Multi-AZ 可用性構成 | 高可用性・自動フェイルオーバー |
| ill-05 | Cognito + ALB 認証シーケンス | 認証フローの分岐表現 |
| ill-06 | QuickSight ダッシュボード | KPIモックアップ |
| ill-07 | CI/CD + Blue/Green デプロイ | パイプライン全体像 |
| ill-08 | コンテナイメージ比較 | 500MB → 15MBのサイズ比較 |
| ill-09 | 現行3層アーキテクチャ | オンプレミス現状（任意） |
| ill-10 | S3コスト比較 | ライフサイクルコスト削減（任意） |
各イラストに、対象スライド、キーメッセージ、レイアウトの詳細、色指定、ラベルのテキストが個別に書かれています。
この仕様書の出来が、最終的な挿絵の出来を左右します。Claudeは提案ノウハウとスライドの中身を踏まえた上で、デザイナーが単独で作業できる水準の仕様書を生成してくれました。
ただし、自動生成された仕様書をそのまま渡すのは危険ですので、必ず人手でレビューしてください。
アーキテクチャ構成やデータフローの記述に誤りがあれば、そのまま挿絵の誤りになります。画像を生成してから直すより、仕様書の段階で技術者が中身を確認しておくほうがずっと手戻りが少なく済むためです。
Step 10: 挿絵の生成・レビュー・スライド挿入
Chat Session: 新規、Ask before edits で開始
プロンプト
illustration-request.mdの「No1」に対し、以下を順に実施。
1. proposal/illustration-request.md の挿絵をNanoBananaProで作成
2. 作成後の内容が指示に沿っているかレビューし、必要に応じて修正依頼
3. 依頼通りの挿絵ができていれば、スライド( design/slidev/slides.md)に挿入
4. playwrightで挿入後のスライド全体のバランスを確認し、必要に応じて挿絵の修正依頼
slidevはport3030で起動している。
ill-01からill-10まで、番号を変えて1枚ずつ実行します。まとめて10枚頼んでもClaudeは順番にやってくれますが、人手でのレビューが追いつかなくなるので、1枚ずつ進めるのがおすすめです。
ワークフローの実際
Claude Codeは1枚の挿絵に対して、だいたいこういうループを回します。
- illustration-request.mdから共通指示と個別仕様を読む
- 日本語の仕様を英語プロンプトに変換する
- Step 8で作ったgenerate-illustration Skillを自動検出して画像を生成する
- 生成された画像を読み取り、仕様との差分を確認する
- 必要なら
--inputモードで既存画像を編集する - slides.mdのプレースホルダーを
<img>タグに書き換える - port 3030のスライドをPlaywrightでスクリーンショットし、レイアウトを確認する
- 画像サイズやマークアップを微調整する
生成、レビュー、修正を数回繰り返すこともあります。ill-01のアーキテクチャ全体図は最も複雑で、何度か修正が入りました。
生成された挿絵の品質について
良かった点
- レイアウトと構成はおおむね指示どおり
- カラーコーディングが仕様に沿って反映されている
- プレゼンのスケールで見れば十分に読める
課題
- 日本語テキストの描画精度が甘い。文字が崩れたり、不自然な字体になったりする
- 文字崩れなどのチェック自体はClaudeでもやってくれる
- ラベルの配置が雑で、要素同士が重なったり位置がずれたりする
- AWSアイコンは正確なArchitecture Iconsではなく、それっぽい近似にとどまる
そして最も注意すべき点として、技術的に正しくない情報が含まれます😇
ill-01のアーキテクチャ全体図では、Multi-AZの構成やリソースの配置関係に誤りがありました。見た目は整っているのに、中身は間違っています。
ここが一番怖いですね。見た目が立派な分、正しそうに見えてしまいます。テーブルやフローのテキストなら読めば正誤が分かりますが、構造図は見た目のそれっぽさに引きずられて、配置関係の誤りを見逃しやすいです。アーキテクチャ図で構成を間違えれば、提案全体の信頼性が崩れます。
実務では必ず技術者による内容レビューを行ってください。
特にアーキテクチャ図は、リソースの配置関係・AZ構成・データフローの正確性などを重点的に確認すること。
実務での使い方
AI生成の挿絵はたたき台と割り切るのが、現時点では現実的です。
- 社内レビューやドラフト段階なら生成したままでも十分使える
- 最終提出版は技術者がレビューした上で、必要に応じて修正する
まとめ＋所感
できたこと
前回記事の残課題だったアーキテクチャ図の生成を、Claude Code × Geminiで実現しました。
- 箇条書きから挿絵入り49ページスライドまで、一気通貫のワークフローが繋がった
- Claude Codeが自分でAgent Skillを作り、仕様書を書き、画像を生成し、レビューし、スライドに挿入し、表示を確認するところまで自律的にやってくれた
- 作ったAgent Skillは汎用的なので、別のプロジェクトにそのまま持っていける
まだ改善の余地あり
- Geminiの画像生成はまだ粗い。日本語テキストの描画や精密なレイアウトには難がある
- 生成された挿絵はたたき台であって、そのまま最終版にはならない
- 技術的な正確性は人間が見るしかない。見た目がきれいでも中身が間違っていることがよくある
非常に手間と時間がかかりますが、実務では人手によるレビューを必ず併用してください。（前回記事から3回目😇）
所感
前回記事で「たたき台をゼロから作る壁がなくなった」と書きましたが、今回それが図にも広がりました。アーキテクチャ図を白紙から描くのは、構成とレイアウトを同時に考えなければならず地味に時間を食う作業です。たたき台があるだけで、修正に集中できます。
Agent Skillの仕組みも収穫でした。Claude Codeが自分で道具を作り、その道具で仕事をする。この流れは提案書に限らず、他の場面でもいろいろ応用が効きそうです。
提案書作成に手を焼いている方、試してみてください。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。