前回の記事で、Gemini 4 Argonを使って自作アプリ（Robocopy Scheduler）のマニュアル自動生成を検証し、前世代（3.5 Flash Lite）の「枠ズレ」は解消したものの新たな3つの惜しい課題が浮き彫りになりました。

▼ 前回の記事（リベンジ編）

前回の最後に「プロンプトの制約追加で解決できそう」と考察した以下の3大課題について、実際に対策プロンプトをそのまま投入して再検証を行いました。

結論から言うと、「レイアウト面は劇的に改善して文句なしの及第点（実用域）に達したが、中華フォントだけはプロンプトでは直らなかった」という結果になりました。その技術検証ログです。

投入したプロンプト

使用した画像群は、自作ツール「ClickCapture」で取得した前回と全く同一のスクリーンショットです。
前回の指示文に、考察で挙げた3つの制約ルールをそのまま追加しました。

- 日本語フォント（Noto Sans JP等）を明示してレンダリングすること
- 注釈ラベルはUI枠内・真上に重ねず、枠外（上下の余白）にオフセットして配置すること
- 画像内には①②などの番号アイコンのみを描画し、具体的な操作テキストは図下のキャプションまたは手順本文に記載すること

ビフォーアフター比較（同一ページの比較）

改善結果：
文字被り・文字切れの完全解消：画像内を「①」「②」「③」といった番号アイコンのみに制限したことで、UIを覆い隠す巨大バナーが一掃された。
キャプションへのテキスト分離：詳細な操作説明（「①コピー先入力後、②1行目の【完全同期】を選択」など）が図下のキャプションへ整理され、手順書として自然かつ非常に読みやすいレイアウトに進化した。

アノテーションの責務分離:
「画像内にすべての説明文を詰め込ませようとする」と、AI側でのバウンディングボックスのサイズ計算や文字の折り返し処理が破綻しやすくなります。「画像内はインデックス番号のみ、説明テキストはDOM/PDFレイアウト側（キャプション）に逃がす」というプロンプト設計にするだけで、破綻リスクをゼロに抑え込めることが実証できました。

プロンプト指定（Noto Sans JP）のスルー:
「日本語フォントを明示してレンダリングすること」と強く指示したにもかかわらず、生成されたPDFの漢字（特に頻出する「入」「図」「所」「反」など）は相変わらず簡体字フォント（中華フォント）特有のグリフのまま出力されました。
要因分析:
これはLLMの指示理解力の問題ではなく、サーバー側のPDF生成エンジン（Headless Chrome等の実行環境）におけるフォントフォールバックの問題と考えられます。コンテナ環境に日本語フォントが正しくインストールされていないか、ロケール設定で簡体字（CJK SC）が優先されている場合、プロンプト側の指定だけでは上書きできません。

評価項目	3.5 Flash Lite	4 Argon（初期）	4 Argon（対策プロンプト）
UI座標特定	❌ 画面外へズレる	⭕ ピクセル精度で追従	⭕ ピクセル精度で追従
UIの可読性	❌ 枠位置が破綻	❌ バナーが文字を隠す	⭕ 番号アイコン化で視認性抜群
文字切れ	-	❌ 固定幅で末尾切断	⭕ キャプション分離で完全解消
日本語フォント	⚠️ 中華フォント感	⚠️ 中華フォント感	⚠️ 直らず（環境依存）
総合実用度	実用不可	要手動修正	文句なしの及第点（実用域）

フォントの字形にわずかな違和感が残るものの、「人間が手作業でスクショを撮り、ペイントで赤枠を囲み、Wordで手順を起こす」という苦行から解放されるレベル（実務の初稿としてそのまま使えるクオリティ）には十分に達しました。

キャプチャツール: ClickCapture
- 左クリックと連動してアクティブ画面を自動連番保存する自作Windowsユーティリティ。今回の検証用画像もこれを使って一括収集しました。
題材アプリ: Robocopy Scheduler
- RobocopyをGUIで管理・自動スケジュール実行できる自作ツール。