🔧 阿川の電商水電行
前言
GMO Connect 的永田。
各位工程師和架構師，是否曾經有過這樣的經驗呢？
「這技術性的內容，光用文字會很難理解，請用圖來解釋」
雖然想要清楚地解釋，但老實說，製作 AWS 組合圖或架構圖實在是相當麻煩。整理結構、考慮佈局、與工具格鬥......不知不覺幾個小時就這樣過去了😇。
我自己過去幾乎沒有利用過影像生成 AI，因為我一直認為雖然可以創造出漂亮的圖像，卻不適合用於資訊量龐大的技術文件。
然而，最近發布的 Nano Banana Pro（Gemini 3 Pro 影像） 聽說可以生成充滿文字和圖表的「霞關報告」級別的圖像。
如果這是真的，那麼那繁瑣的圖版製作可能會變得輕鬆許多...！😊
在這篇文章中，我將以過去我曾經「想要畫出來但因為麻煩而放棄」的 Qiita 文章為主題，驗證Nano Banana Pro 在技術文件的圖版製作上可以提高多少效率。
驗證主題：
- AWS 組合圖的前後比較圖
- 自動測試導入的說明圖
究竟能否解決工程師的「請用圖解釋」問題呢？
總結
- Nano Banana Pro 在技術文件的圖版製作上已經足夠使用。雖然不是最終形態，但作為圖案和佈局設計的草案，具有顯著的時間縮短效果。
- 提示越詳細，精度就越高，但事前進行「方針確認」可以減少試錯。因為影像生成需要 30 秒，所以方針確認非常有效。
- 雖然並不完全解決「請用圖解釋」問題，但圖版製作的心理障礙確實降低了。今後希望能夠積極應用於資料製作中😊。
嘗試 Nano Banana Pro
在 Gemini 工具中選擇「製作圖像」，然後選擇「思考模式」，就可以使用 Nano Banana Pro。
如果顯示思考過程已經切換到 Nano Banana Pro，那麼期待中的 Nano Banana Pro 已經可以使用了。
主題1: AWS 組合圖的前後
第一個主題是這個。
<iframe id="qiita-embed-content__851714427f3dbfdacae8f37405a8246e"></iframe>
做架構設計的時候，會有將現有的問題如何改善，以圖的方式進行說明的情況，這也正是相對應的內容。我當時也想用圖來表達，但因為麻煩，所以只用 Mermaid 混水摸魚😇。
最初使用的提示
雖然我想試試看簡單的提示是否可行，但我先用簡短的提示來試試。
根據以下的 Qiita 文章，生成一張 AWS 組合圖，顯示 FastScaler 導入前後的問題與改善要點，並用信息圖的形式生成。
https://qiita.com/ntaka329/items/9f72bf6824abe8b4af97
不知不覺中 AI/ML 也登場了😇。
試行錯誤的提示
基於此，我將各種信息進行整合。
根據以下的 Qiita 文章，生成一張 AWS 組合圖，顯示 FastScaler 導入前後的問題與改善要點，並用信息圖的形式生成。
https://qiita.com/ntaka329/items/9f72bf6824abe8b4af97
- 將 ECS Fargate Scale Out 速度的課題表的要點寫入前圖，將 FastScaler 導入後的 Scale Out 速度的表的要點寫入後圖
- FastScaler 的要點參照 Qiita 中的 Mermaid 的序列圖
- FastScaler Lambda 定期執行
- 另一個指標收集 Lambda 從 ECS 實例直接以秒為單位收集指標（因此比 CloudWatch Metrics 的 Scale Out 更快）
- 當指標超出閾值時，FastScaler Lambda 直接增加 ECS 的 desiredCount（因此比 ECS 標準的 AutoScaling 更快）。
- 前
- ECS 標準的 CloudWatch Metrics（如 CPU 等）收集需 2 分至 3 分鐘
- 指標是分鐘級別，需要花時間才能參考到數據
- 對 CloudWatch Metrics 的警報觸發（ECS desiredCount 增加）：約 3 分鐘
- 如果是目標追蹤，則固定需 3 分分鐘（警報設置無法自行修改），步驟縮放則最小需 1 分鐘
- 圖中僅出現一個 CloudWatch
- 後
- 指標收集 Lambda 從 ECS 實例直接以秒為單位收集指標：幾秒鐘
- 不使用 CloudWatch Logs/Metrics
- 當指標超過閾值時，FastScaler Lambda 直接增加 ECS 的 desiredCount
- 不使用 CloudWatch Logs/Metrics
- 圖中不出現 CloudWatch 或對其沒有訪問
雖然有些地方有未解之處，但已經有了相當大的改善！
雖然要把這個直接展示給客戶還是有難度，但作為說明資料的圖案，是相當不錯的。
原本我在佈局方面常常會花很多時間困擾，繪製圖像後重新整理的手動操作，現在看來這方面是可以改善的。
主題2: 自動測試導入的說明
下一個主題是這個。
<iframe id="qiita-embed-content__bf90dc45aff94190ba6cb6829753ca08"></iframe>
最初的提示
根據以下的 Qiita 文章，生成一張信息圖。
https://qiita.com/ntaka329/items/9bfb2a2c136dbf49f2de
- 解釋 UT/IT/情境測試的關係和區別
- 向開發成員說明各工程的自動測試概要、要點和優勢
- 列出每個流程的工具範例（參考 Qiita）及採用理由
這幅畫實在是太酷了！！但工具範例完全無視了 Qiita 的內容😇。
添加信息圖計畫的提示
因為像第一個例子那樣大量填充信息很麻煩，所以我決定事先確認方針。
根據以下的 Qiita 文章進行內容理解。（以便稍後生成信息圖）
https://qiita.com/ntaka329/items/9bfb2a2c136dbf49f2de
特別是要注意以下要點
- UT/IT/情境測試的關係和區別
- 各工程的自動測試概要、要點和優勢
- 每個流程的工具範例和採用理由
在信息圖的創建過程中，如果有需要進行用戶評審或決定的觀點，請提出。在生成圖像之前，進行了多方確認！
由於生成一次圖像需要約 30 秒，因此事先確認方針是非常好的！😊
我隨便回答，讓 AI 為我生成圖像。
1. 強調「AI 如何縮短代碼創建（2 天內導入）」這個故事
2. 為初學者加強「為何需要 Mock？」的概念圖
3. 添加一般 IT（重型）和此次改良 IT（輕型）的對比圖
4. 添加目錄結構圖，以及 Maven 命令（mvn verify）被執行時它們按什麼順序運行的時間線圖這樣生成出來的圖像與最初的相比，雰圍截然不同，但卻非常忠實於 Qiita 的文章，並且符合 QA 的內容！
當輸出圖片的方針不明確時，先進行一輪計畫模式的確認（ 在創建信息圖的過程中，如果有需要進行用戶評審或決定的觀點，請提出。 ）就會比較好。
（再次回顧）總結
- Nano Banana Pro 在技術文件的圖版製作上已經足夠使用。雖然不是最終形態，但作為圖案和佈局設計的草案，具有顯著的時間縮短效果。
- 提示越詳細，精度就越高，但事前進行「方針確認」可以減少試錯。因為影像生成需要 30 秒，所以方針確認非常有效。
- 雖然並不完全解決「請用圖解釋」問題，但圖版製作的心理障礙確實降低了。今後希望能夠積極應用於資料製作中😊。
最後，GMO Connect 提供服務開發支援和技術支援等廣泛的支援服務，若有需要歡迎隨時聯絡我們。
聯絡方式: https://gmo-connect.jp/contactus/
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
