はじめに
GMOコネクトの永田です。
前回記事に引き続き「絵で説明して」問題に取り組んでいきます。
皆さん、NotebookLMは使っていますでしょうか？
NotebookLMは、マニュアルやQAなど情報源となるソースを指定すると、それらを要約したりチャットでQAしてくれたりする便利ツールです。
最近、インフォグラフィック作成とスライド作成機能が加わり、これらのエンジンとしてNanoBananaProが使われているという情報を見かけたので試してみました。
前回との違い：ソース指定で誤情報が減る
前回のGeminiアプリでは、誤情報が混じることがありました。
NotebookLMはソースに指定した情報からのみ生成するため、ソースの内容が正しければ誤情報が減ることが期待できます！😊
NotebookLM自体の詳細は以下の記事などを参照してください。
まとめ
- ソース指定のおかげで、Geminiアプリ単体よりも誤情報が少なく元記事に忠実な図が生成できた
- ただし「詳細」モードは文字崩壊などの課題があり、PowerPointなど編集可能な形式での出力など今後のアップデートに期待
- いきなり画像生成せず、プロンプト案自体をNotebookLMのチャットと壁打ちして作成させると精度が上がる
NotebookLMでのインフォグラフィック生成手順
NotebookLMを最初見た時、これどうやって使うん？と調べたので、手順の要点をまとめておきます。
- NotebookLMを開く: https://notebooklm.google.com/
- 「ノートブックを新規作成」
- 情報ソースを指定（後述）
- 指定がおわると、個別のノートブックページが開き、ソースの情報をざっとサマリーしてくれる
- 右側の「Studio」からインフォグラフィックを選択し画像を生成（後述）
情報ソースを指定
最初に情報元になるソースを指定してあげます。
ソースを追加すると、NotebookLM がユーザーにとって最も重要な情報に基づいて回答を返せるようになります。
（例: マーケティング計画、コース リーディング、調査メモ、会議の文字起こし、セールス ドキュメントなど）
ここが「誤情報が減る（ソースの内容があっていれば）」のポイントですね！
サポートされているファイル形式: PDF, .txt, Markdown, 音声（例: mp3）, .docx, .avif, .bmp, .gif, .ico, .jp2, .png, .webp, .tif, .tiff, .heic, .heif, .jpeg, .jpg, .jpe
と幅広いフォーマットがサポートされています。
またWebページのURLを直接指定することもできますし、「ソースを探す」でWebページ or GoogleDriveから情報を収集することもできます。
（社内ドキュメントのRAGも、これでサクッと実現できる気がする・・？）
インフォグラフィックの生成
個別Notebookの右側のエリアに「Studio」があり、そこからインフォグラフィックが生成できます。
（中央のチャットはソースに対するQAをしてくれるエリアで、インフォグラフィックの生成には直接は使わないです）
「インフォグラフィック」ボタンに鉛筆ボタンがあり、生成内容をカスタマイズできます。
カスタムプロンプトで追加の指示もここに書きます。
Studioの下半分が、生成済みのコンテンツ履歴になります。生成に利用したカスタムプロンプトもここで確認が可能です。
では実際に、詳細レベルやカスタムプロンプトでアウトプットがどう変わるか、早速確かめてみましょう！
NotebookLMでインフォグラフィックを試してみた
テーマ1: AWS構成図のBefore/After
前回と同じです！
詳細レベルやカスタムプロンプトでどう変わるか、これで試してみます。
ソースとしてこのURLのみを指定しています、
プロンプトなしの場合は特に生成する毎に画像の結果が異なるので、それぞれ3つサンプルを載せておきます。
レベル=標準、カスタムプロンプト無し の場合
特に何も指定していない状態で、このレベルは割と良いのではないでしょうか？
Geminiアプリ（NanoBananaPro）であったような、誤情報がぱっと見なく、ソースにしたQiitaの記事に忠実な内容になっています。
エンジニアが顧客や社内に出す資料としては、ちょっと絵がうるさいですが・・😇
レベル=簡潔、カスタムプロンプト無し の場合
「標準」であったようなうるさい絵（個人の主観）がなくなり、要点のみとなっています。
個人的には「標準」より好みではありますが、「簡潔」とあるようにサマリー的な内容になっています。
これはこれで、使い所はありそうです。
レベル=詳細（ベータ版）、カスタムプロンプト無し の場合
最後に「詳細」レベルで試してみます。
「これこれ、インフォグラフィックといえばこれだよね！😊（主観）」という見た目になっています。
情報量がある程度ありつつも、絵で情報が整理されており、個人的にはこれが一番好みです。
ただ現状「詳細」モードがベータ版なせいか、簡潔・標準ではみられなかった、文字崩壊がところどころ発生しています😇
誤情報がない点はとても良いのですが、現状、崩壊した文字を再修正したり微修正したりと、追加での修正指示をする機能がなさそうであり、その点はちょっと使いにくいです。
GoogleスライドやPowerPointなど、編集可能なフォーマットでインフォグラフィックを出力してくれるとこちらで微修正がしやすく使い勝手が良いのですが、今後のアップデートに期待です。
この課題はGeminiアプリのNanoBananaProも同じですが、Geminiアプリだとその場で追加の指示をいれて画像修正が出来るのはメリットです。とはいえ、編集可能なフォーマットで出てくれる方がプロンプトをtry&errorするよりも手っ取り早いので、正確かつ詳細な情報をいれることのあるインフォグラフィックでは、やはり編集可能フォーマットでの出力に対応して欲しいですね。
レベル=詳細（ベータ版）、カスタムプロンプト有り の場合
最後にプロンプトの有無でのアウトプットへの影響（生成内容のブレも含め）を確認しておきます。
カスタムプロンプト自体をNotebookLMに考えてもらうため、チャットで以下の依頼をしました。
（前回もりもりで依頼した内容ベースです）
Qiita記事を元に、FastScaler導入前後の課題・改善ポイントを、AWS構成図としてインフォグラフィックで画像生成したいので、画像生成AIのプロンプト案を作成。
- ECS Fargate Scale Out速度の課題の表のポイントをbefore絵に、fast scaler導入後のScale Out速度の表のポイントをafter絵に追記
- fastscalerの要点は、Qiita中のmermaidのシーケンス図を参照
- fastscaler Lambdaで定期実行
- 別のmetrics収集LambdaでECSインスタンスから直接metricsを秒単位で収集（これによりCloudWatch MetricsよりもScaleOutが高速になる）
- metricsが閾値を超過するとfastscaler LambdaがECS desiredCountを直接増加させる（これによりECS標準のAutoScalingよりもScaleOutが高速になる）
- before
- ECS標準のCloudWatch Metrics(CPUなど)の収集: 2分〜3分程度
- 1分単位のMetricsであり、データ参照できるようになるまで時間がかかる
- CloudWatch Metricsに対してのAlarm Trigger（ECS desiredCount Up）: 3分程度
- ターゲット追跡の場合は固定で3分(Alarmの設定を自分でいじれない)、ステップスケーリングだと最小1分
- 絵の中でCloudWatchは1つのみ登場
- after
- metrics収集LambdaでECSインスタンスから直接metricsを秒単位で収集: 数秒程度
- CloudWatch Logs/Metricsは利用していない
- metricsが閾値を超過するとfastscaler LambdaがECS desiredCountを直接増加させる
- CloudWatch Logs/Metricsは利用していない
- 絵の中ではCloudWatchは登場しない or アクセスがない
NotebookLMが出してきた回答が以下です。
ご提示いただいたQiita記事の情報と要件に基づき、FastScaler導入前後の課題と改善点を比較するAWS構成図インフォグラフィックを作成するための、画像生成AI向けプロンプト案を以下に作成します。
このプロンプトは、AWSサービスのアイコンを使い、情報伝達を目的とした専門的なインフォグラフィック（図解）スタイルを指示しています。
---
## 画像生成AI プロンプト案
### 1. 全体の指示とスタイル設定
**【スタイル】** AWS構成図のインフォグラフィック [i]。プロフェッショナルでクリーンなデザイン。図には、構成要素間のデータ/制御の流れ（矢印）と、それにかかる時間（テキストラベル）を明確に記載する。比較しやすいように「Before」と「After」の2枚の絵を並べるか、1枚の画像内で明確に分離して構成する。
**【目的】** ECS Fargateの標準Auto Scalingが抱えるScale Out速度の課題と、FastScaler導入による改善点を視覚的に比較する。
### 2. FastScaler導入前（Before 図）のプロンプト詳細
**【タイトル】** FastScaler導入前: 標準ECS Auto Scalingの Scale Out 課題
**【登場するAWSサービスと要素】**
1. 外部からのトラフィック（高い負荷）
2. ALB (Application Load Balancer)
3. **ECS Fargate サービス**
4. ECS Task (少なめ。サービス内にはECS Taskが現在稼働していることを示す)
5. **CloudWatch** (図の中心的な要素として配置)
6. ECS Auto Scaling Policy (CloudWatch Alarmに紐づくことを示す)
**【フローと課題の表現（時間表記を強調）】**
* ECS Taskから**CloudWatch**へMetrics（CPU使用率など）が送信される。
* **課題 No.1：Metrics収集の遅延**
* CloudWatch Metricsの収集にかかる時間：「**2分〜3分程度**」と明記。
* 備考：「**1分単位のMetricsのため時間がかかる**」と注記。
* **課題 No.2：Alarm Triggerの遅延**
* CloudWatch Metricsが閾値を超過し、Alarmがトリガーされるまでの時間：「**3分程度**」と明記。
* 備考：「**ターゲット追跡ポリシーでは固定3分**」と注記。
* CloudWatch Alarmが発火し、ECSサービスのDesired Countを更新する。
* Desired Count更新後、新しいECS Taskが起動し、ALBに登録される（このフェーズは「20秒〜30秒 (INITまで)」「30秒〜60秒 (Service Inまで)」かかるが、改善点ではないため、**ボトルネックとして小さく注記**するに留める）。
**【強調ポイント】**
* **「desiredCount Upまで、合計約5分」**かかることを図の主要な遅延として強調する。
* スケールアウトが遅れることで、スパイク負荷に対応できていない状況を表現する。
### 3. FastScaler導入後（After 図）のプロンプト詳細
**【タイトル】** FastScaler導入後: 高速 Scale Out の実現
**【登場するAWSサービスと要素】**
1. 外部からのトラフィック（高い負荷）
2. ALB (Application Load Balancer)
3. **ECS Fargate サービス**
4. ECS Task (スケールアウト後の増加した状態を示す)
5. **FastScaler Lambda** (メインの制御ロジック、EventBridgeなどで定期実行されることを示す)
6. **Metrics収集 Lambda** (VPC内に配置。ECS Taskに直接アクセスする役割)
7. ECS Task内の**独自Endpoint** (Metrics収集元)
**【フローと改善点の表現（時間表記を強調）】**
* ECS Task内の**独自Endpoint**へ**Metrics収集 Lambda**が直接アクセスする。
* **改善 No.1：高速Metrics収集**
* Metrics収集にかかる時間：「**数秒程度（1秒単位収集）**」と明記。
* 備考：「**CloudWatch Logs/Metricsを利用しない**」と注記。
* Metrics収集 Lambdaが収集したMetricsを**FastScaler Lambda**へ渡す。
* FastScaler Lambdaが閾値を超過したと判断し、ECSのDesired Countを**直接**増加させる。
* **改善 No.2：高速Trigger**
* Trigger（desiredCount Up）にかかる時間：「**5秒程度**」と明記。
* 備考：「**CloudWatchを利用しないため高速**」と注記。
* Desired Count更新後、新しいECS Taskが迅速に起動し、ALBに登録される。
**【強調ポイント】**
* 図中には**CloudWatchは一切登場させない**か、全くアクセスされていないことを明確に示す。
* 制御の流れがLambdaとECSサービス間で完結し、標準のCloudWatchを経由しないことを示す。
* 最終的な目標：「**ELB target Service Inまで約1分半**」で実現できたことを強調する。
### 4. プロンプト構成のまとめ
上記の指示に基づき、画像生成AIへの入力プロンプトとして統合します。
```prompt
プロフェッショナルなAWS構成図のインフォグラフィックを作成してください。タイトルは「ECS Fargate 高速 Scale Out 実現のためのFastScaler導入前後比較」。
【共通要素】
情報伝達を重視し、各コンポーネントとデータ/制御の流れ（矢印）を明確にし、処理にかかる時間を大きく表示する。
【左側 (Before: 標準ECS Auto Scalingの課題)】
構成：外部負荷 -> ALB -> ECS Fargateサービス (Task) -> CloudWatch (中央に配置) -> Auto Scaling Policy。
課題点（強調）：
1. CloudWatch Metrics収集：「2分〜3分程度」(1分単位Metricsのため)。
2. CloudWatch Alarm Trigger (desiredCount Up)：「3分程度」(ターゲット追跡は固定)。
遅延結果：「desiredCount Upまでに約5分」かかることを強調。
備考：CloudWatchは1つのみ登場。
【右側 (After: FastScaler導入による高速化)】
構成：外部負荷 -> ALB -> ECS Fargateサービス (Task)。CloudWatchは登場させない。
新しい制御要素：FastScaler Lambda (定期実行) と Metrics収集 Lambda (VPC Lambda)。
Metrics収集 Lambdaは、ECS Taskの独自EndpointからCPU Metricsを直接秒単位で収集する。
改善点（強調）：
1. Metrics収集：「数秒程度（1秒単位収集）」。
2. FastScaler Lambdaによる desiredCount 直接増加：「5秒程度」。
高速化の理由：「CloudWatch Logs/Metricsを利用しない」ことを注記。
改善結果：「ELB target Service Inまで約1.5分」で実現したことを強調。
各要素にはAWSのアイコンを使用し、構成図として分かりやすく描画すること。
```
上記の指示に基づき、画像生成AIへの入力プロンプトとして統合します。
と、プロンプトとしてまとめてくれていますので、これをインフォグラフィック（詳細レベル）のカスタムプロンプトにぶっこみます。
なお、画像生成には時間とコストがかかるので、実務ではそのままぶっこむ前にチャットでレビューやフィードバックしてあげてください。
調子にのって何度も生成しなおすと、レートリミットがかかります😇
では、実際の出力例3つです。
細かな点は違うものの、プロンプト無しと比べて出力内容がずいぶん似通っているのが分かるかと思います。
自分の中でアウトプットイメージがある程度あるなら、できる限り詳細にプロンプトで伝えてあげる方が良さそうですね。
なお、プロンプトの内容自体も、NotebookLMのチャットで考えてくれるので、画像生成前にチャットと壁打ちすると良さそうです。（次のテーマ2でこれをやります）
テーマ2: 自動テスト導入の説明
前回と同じです！（2回目）
テーマ1の結果を受けて、詳細＋カスタムプロンプト有りのパターンで試します。
まずは、インフォグラフィックの方針をチャットで相談してみます。
ソースのQiita記事に対し、以下のポイントを押さえたインフォグラフィックを作成するための、
画像生成AIに対するプロンプトを検討して欲しい。
- UT/IT/シナリオ試験の関係と違いを説明
- 各工程での自動テストの概要・ポイント・メリット
- 工程毎のツール例と採用理由
インフォグラフィック作成にあたり、ユーザーレビューや決定が必要な観点があれば提示してください。
チャットからのお返事がこちら（ちょっと長いですが原文まま）
この度は、Qiita記事の内容を効果的に伝えるインフォグラフィック作成のためのプロンプト検討のご依頼ありがとうございます。提供されたソースに基づき、テストの階層構造、各工程の目的、採用されたツールの詳細、および生成AI活用の成果を視覚化するためのプロンプト案と、決定が必要な観点を提示します。
---
## 1. 画像生成AI向けプロンプト案（日本語）
以下のプロンプトは、インフォグラフィックの**構造**、**内容**、**視覚的な強調点**を詳細に指定し、テストピラミッドの概念を中心に据えた設計となっています。
### プロンプトタイトル：Java自動テスト導入ガイド：テストピラミッドとツール選定（692件の実例）
```
プロンプト：技術的かつモダンなデザインのインフォグラフィックを作成してください。テーマは「Java自動テスト導入ガイド：テストピラミッドとツール選定」。生成AIを活用し、2日で692件のテストを導入した実績を強調してください。
**【視覚化の構造】**
1. **メインビジュアル：** テストピラミッド（逆三角形の階層構造）を中央に配置し、下から上へ「ユニットテスト (UT)」、「統合テスト (IT)」、「シナリオテスト (ST/E2E)」の3層に分ける。
2. **全体実績：** ピラミッドの横に、**合計692件のテストを約20秒で実行**したこと、および**命令カバレッジ91%達成** を目立つように記載する。
3. **生成AIの貢献：** 「生成AIサポートにより、ゼロからの自動テストコード実装を2日程度で対応可能」という事実をフッターまたはヘッダーに強調する。
**【各フェーズの詳細描写】**
### 1. ユニットテスト (UT) — 基盤（底辺）
* **目的・概要：** ロジックの正確性。単一クラス/メソッドを検証。
* **特徴：** **外部依存なし**（モックを使用）。
* **実績データ：** 481件 (最多)。実行速度：〜5秒 (高速)。
* **採用ツールと理由 (アイコン化)：**
* **Mockito：** 役割：モックオブジェクト生成。理由：**外部依存を排除**し、ロジック単体をテスト可能に。
* **Hamcrest：** 役割：可読性の高いアサーション。理由：**自然言語に近い表現**でテスト意図を明確化し、複雑な検証を簡潔に。
* **JaCoCo：** 役割：コードカバレッジ測定。理由：テストの**網羅性を定量的に把握**。
### 2. 統合テスト (IT) — 中間層
* **目的・概要：** 連携の正確性。API + DB + JNDIを検証。
* **特徴：** **外部依存あり**（Docker環境）。**本番環境に近いテスト**を実現。
* **実績データ：** 193件。実行速度：〜1秒 (非常に高速)。
* **採用ツールと理由 (アイコン化)：**
* **Maven Failsafe Plugin：** 役割：IT実行プラグイン。理由：UT/ITを分離し、Mavenライフサイクルと統合して**環境の準備/クリーンアップを安全に自動化**。
* **Tomcat Catalina：** 役割：JNDI環境の提供。理由：JNDI環境を再現し、**WARデプロイなしで軽量かつ高速**にDB連携テストを実行可能に。
### 3. シナリオテスト (ST/E2E) — 頂点
* **目的・概要：** 業務フローの正確性。複数API連携、非同期処理を含むE2E検証。
* **特徴：** **外部依存あり**（Docker + Stub）。
* **実績データ：** 18件 (最少)。実行速度：〜12秒。
* **採用ツールと理由 (アイコン化)：**
* **REST Assured：** 役割：REST APIテスト。理由：**Given-When-Then形式**の自然言語に近いDSLで高い可読性を実現。
* **Awaitility：** 役割：非同期処理の待機。理由：**ポーリングベース**で非同期処理の完了を簡潔かつ安全に待機可能。
**【デザイン指示】**
* 情報を整理するためにグリッドレイアウトを使用。
* 各ツール名と、その「役割」および「選定理由」を明確なラベルで表示する。
* テストピラミッドの各層の境目には、テスト対象のスコープ（単一クラス vs 複数API連携）を示すイラストを配置する。
```
---
## 2. インフォグラフィック作成にあたり決定が必要な観点
インフォグラフィックを効果的にし、ユーザーの意図を正確に反映するために、以下の観点についてユーザーレビューと決定が必要です。
### A. 視覚的表現に関する決定
1. **テストピラミッドのスケールに関する決定**
* **観点：** ピラミッドの各層の**高さや面積**を、単に概念的な階層（UT > IT > ST）として表現するのか、それとも**実際のテスト件数比**（481件：193件：18件）に近い割合で視覚化するのか。
* *理由：* 件数比を反映させると、UTが圧倒的な基盤であることがより明確に伝わります。
2. **実行速度の表現方法の決定**
* **観点：** 各フェーズの実行時間（UT: 〜5秒、IT: 〜1秒、ST: 〜12秒） を、ピラミッドの横に**棒グラフ**や**スピードメーター**のような形で対比させて表現するか。
* *理由：* UTが非常に高速であること、ITがさらに高速であること、STが最も時間を要することを視覚的に理解しやすくするためです。
3. **外部依存の有無の強調**
* **観点：** UTの「外部依存❌（Mock）」と、IT/STの「外部依存✅（Docker/Stub）」 の対比を、色やアイコン（例：鎖のアイコンの有無）を使って強く強調するかどうか。
* *理由：* 各テストフェーズの根本的な違い（隔離性 vs 現実性）を明確に表現するためです。
### B. 内容・文脈に関する決定
1. **生成AI要素の強調度合いの決定**
* **観点：** インフォグラフィック全体を通して「生成AI」をメインテーマとして扱うのか、あるいは単に自動テスト導入を加速させた「要因」としてフッターなどに留めるのか。
* *理由：* 記事のタイトルには「生成AI活用」が含まれており、生成AIがAsIsのテストコード作成に特に効果的であった点 を含め、どの程度フィーチャーするかでレイアウトが変わります。
2. **前提技術スタックの記載の有無**
* **観点：** この結果がJava (OpenJDK 11)、Maven、JAX-RS、MariaDBという**特定の技術スタック** の下で達成されたことを図中に明記するか、それともライブラリ名（Mockito, Hamcrestなど）のみで構成し、汎用的な「自動テスト」ガイドとして扱うか。
* *理由：* 実例としてのリアリティを重視するか、抽象的な知識伝達を重視するかによって異なります。
3. **カバレッジに関する注意点の取扱い**
* **観点：** JaCoCoのカバレッジ計測に関して、「100%を目指す必要はない」 や「カバレッジ≠品質保証」 といった**注意点**を図の脇に補足として含めるかどうか。
* *理由：* 単なる結果（91%）だけでなく、テストの質の重要性も伝えることができますが、図が複雑になる可能性があります。
「決定が必要な観点」に対し、適当に回答します。
A-1: 単に概念的な階層で良い
A-2: 不要（テスト実行時間よりも、自動テスト作成がAIで簡単になったことを強調したい）
A-3: 強く強調しなくて良い
B-1: 「生成AI」をメインテーマとして扱いたい
B-2: 前提技術スタックの記載をする
B-3: 図が複雑になりそうなら不要（優先度は低い）
プロンプトができました！
ユーザーの決定事項に基づき、生成AIの活用によるテスト導入の「スピード」と「効率」を最大に強調したインフォグラフィックを作成するためのプロンプト案を検討しました。
このプロンプトでは、「テストピラミッドの概念的な階層構造（A-1）」を維持しつつ、**生成AI（B-1）** がいかに短期間で大規模なテスト（692件）を実現したかという実績を核に据えています。
---
## 1. 画像生成AI向けプロンプト案（日本語）
### プロンプトタイトル：【生成AIが実現】Java自動テストを2日で692件導入するロードマップ：テストピラミッドと実践ツール選定
```
プロンプト：**未来志向で技術的なトーン**のインフォグラフィックを作成してください。メインテーマは「生成AIによる自動テスト導入の圧倒的な効率化」。
**【視覚化の構造とハイライト】**
1. **AI強調ヘッダー：** 最上部に「生成AIサポートにより、ゼロからの自動テスト実装を**わずか2日**で実現」というテキストを最大フォントで配置し、AIアシスタントのアイコンやグラフを添える。
2. **コア実績の強調：** 図の中央に、「合計692件のテストを導入」「命令カバレッジ91%達成」という数値を非常に目立つように配置する。
3. **メインビジュアル：** 従来のテスト工数を示すアイコン（例：山脈や迷路）と対比させ、**テストピラミッド**（概念的な階層構造 A-1）を中央に配置する。
**【階層構造：テストピラミッド（概念的階層）】**
* ピラミッドは上からシナリオテスト (ST)、統合テスト (IT)、ユニットテスト (UT) の順に配置し、それぞれの層に件数（UT: 481件、IT: 193件、ST: 18件）を併記する。
**【前提技術環境 (B-2) — ピラミッドの土台または側面に明記】**
以下の技術スタックをアイコンとともに図示する。
* **Java環境:** OpenJDK 11
* **ビルドツール:** Maven 3.9
* **フレームワーク:** JAX-RS (Jersey 2.41)
* **データベース:** MariaDB 10.11
**【各フェーズの詳細とツール選定理由】**
### 1. ユニットテスト (UT) — ロジックの正確性 (481件)
* **概要・ポイント：** 単一クラス/メソッドの検証。外部依存を排除し、ロジック単体をテストする。高速で安定したテストを実現。
* **採用ツールと理由 (アイコン化)：**
* **Mockito：** 役割：モックオブジェクト生成。理由：**外部依存を完全にモック化**し、テストの高速化とCI/CD環境での実行容易化を実現。
* **Hamcrest：** 役割：可読性の高いアサーション。理由：`assertThat(actual, is(expected))` のような**自然言語に近い表現**で可読性を向上させ、複雑な検証を簡潔に。
* **JaCoCo：** 役割：コードカバレッジ測定。理由：テストの**網羅性を定量的に把握**し、品質基準を共有。
### 2. 統合テスト (IT) — 連携の正確性 (193件)
* **概要・ポイント：** API + DB + JNDIの検証。Mavenライフサイクルと統合し、環境準備・クリーンアップを自動化。
* **採用ツールと理由 (アイコン化)：**
* **Maven Failsafe Plugin：** 役割：統合テスト実行プラグイン。理由：UT（Surefire）と明確に分離し、**テスト失敗時でも安全に環境クリーンアップ**（Docker停止など）を保証。
* **Tomcat Catalina：** 役割：JNDI環境の提供。理由：WARデプロイなしで**本番環境と同じJNDI設定を軽量に再現**し、高速なDB連携テストを実現。
### 3. シナリオテスト (ST/E2E) — 業務フローの正確性 (18件)
* **概要・ポイント：** 複数API連携を含むE2E検証。Markdownによる全体概要のドキュメント化が重要。
* **採用ツールと理由 (アイコン化)：**
* **REST Assured：** 役割：REST APIテスト。理由：**Given-When-Then形式**のDSLにより、業務フロー検証の**可読性を極限まで高める**。
* **Awaitility：** 役割：非同期処理の待機。理由：`Thread.sleep()` ではなく**ポーリングベース**で非同期処理の完了を安全かつ簡潔に待機可能。
**【デザイン指示】**
* テストの種類（UT, IT, ST）ごとのフェーズの責務（外部依存の有無：UTは❌、IT/STは✅）はテキストとして記載し、**過度な視覚的強調は避ける**（A-3）。
* 生成AIの貢献度（AsIsのテストコード作成に特に効果を発揮）を示すキャプションを、ピラミッドの近くに配置する。
* 全体的にグリッドを使用し、情報の整理と技術的な信頼感を表現する。
```
---
## 2. 決定事項の反映とインフォグラフィックの方向性
ユーザーから提供された決定事項に基づき、インフォグラフィックの方向性は以下のように確定しました。
| 決定事項 | 意図/効果 | ソース内の根拠 |
| :--- | :--- | :--- |
| **A-1: ピラミッドは概念的階層** | 視覚的な階層のバランスを保ち、テスト件数（481件:18件）による極端な歪みを避ける。 | テストピラミッドの概念図。 |
| **A-2: 実行速度は不要** | 実行時間（20秒）よりも、**生成AIによる作成速度（2日）** を主要なメリットとして強調する (B-1に合流)。 | 2日で対応可能という実績。 |
| **A-3: 外部依存の強調は不要** | UT/IT/STの責務の違いは記載するものの、デザインをシンプルに保つ。 | 各フェーズの「外部依存」欄。 |
| **B-1: 生成AIをメインテーマ** | 図のタイトル、実績部分、導入メリット説明の全てで「生成AI」の貢献度を強調する。 | 生成AI活用を謳う記事タイトル、生成AIのサポートで2日導入を実現。 |
| **B-2: 前提技術スタックの記載** | Java (OpenJDK 11)、Maven、JAX-RS、MariaDBという具体的な技術環境を図に明記する。 | 検証環境の詳細記載。 |
| **B-3: カバレッジの注意点は不要** | 図の複雑化を避けるため、「91%達成」という結果のみを提示し、カバレッジの質に関する議論（100%不要論など）は省略する。 | JaCoCoによる91%命令カバレッジ達成。 |
このプロンプトは、自動テスト導入という複雑な課題に対し、**生成AIがいかに強力なブレークスルー（2日での692件導入）** を提供したかというストーリーを視覚的に伝えることに焦点を当てています。
チャットが作ってくれたプロンプトを、インフォグラフィック（詳細レベル）のカスタムプロンプトにぶっこみます。
なお、画像生成には時間とコストがかかるので、実務ではそのままぶっこむ前にチャットでレビューやフィードバックしてあげてください。（2回目）
できました！
絵がうるさい😇 （ちなみに、3回目が個人的な好みではあります。）
3回とも似たような感じなので、**未来志向で技術的なトーン** なり他のプロンプトの内容に引っ張られていそうですので、実務ではプロンプトぶっこむ前にフィードバックしてあげる方が、やはり良さそうです。
今回は文字数が少なかったからか、文字の崩壊はほとんどありませんでした。とはいえ、3回目のように文字情報の数に比例して、文字の崩壊が多くなる傾向があります。
（再掲）まとめ
- ソース指定のおかげで、Geminiアプリ単体よりも誤情報が少なく元記事に忠実な図が生成できた
- ただし「詳細」モードは文字崩壊などの課題があり、PowerPointなど編集可能な形式での出力など今後のアップデートに期待
- いきなり画像生成せず、プロンプト案自体をNotebookLMのチャットと壁打ちして作成させると精度が上がる
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。