帳票Vibe Coding

AI駆動開発勉強会 名古屋支部 #1 の発表スライドです。
yagisan-reportsという帳票プロダクト用の帳票テンプレートをAIに生成させる（帳票Vibe Codingをする）ために色々工夫した話です。

1. 帳票Vibe Coding デンキヤギ株式会社 terurou
2. おことわり このセッションでは AI駆動開発に関する用語の説明を 全て省略しています
4. 要するに ビジネスで使う 紙とかPDF
5. • デンキヤギで作ってる帳票エンジン • (XMLテンプレート, データ) -> PDF
6. 2月～5月頃
7. 世間のみなさんが、 CursorやらClineで Vibe Codingとか言い始めた
8. 実際にCline（Roo Code）を試してみた。 「こりゃあ、やべえの来たな…」
9. • デンキヤギで作ってる帳票エンジン • (XMLテンプレート, データ) -> PDF テキストなのだから Vibe Coding可能では？
10. これがやりたい 帳票テンプレート プロンプト 「請求書を作って」 Designed by Freepik
11. とりあえず雑に生成させてみよう → 当然ダメ
12. 汎用AIが マイナー製品のことを 学習している訳がない
13. 気を取り直して、 プロンプトで軽くXML構造を入力してみる → なんかいけそう
14. どのような情報をプロンプトとして入力したのか • XML要素の一覧 • ルート要素 • 各要素で指定可能な属性と子要素 • 検証では最小限を記述 （網羅的に仕様を記述するのは大変…） • 体感で7-8割ぐらい正しいXMLが出力できる
15. どのような情報をプロンプトとして入力したのか • XML要素の一覧 • ルート要素 • 各要素で指定可能な属性と子要素 • 検証では最小限を記述 （網羅的に仕様を記述するのは大変…） • 体感で7-8割ぐらい正しいXMLが出力できる これは XMLスキーマでは…？
16. を AI向けにピボットしよう！
17. 5月22日
18. • Claude Code • Claude 4 Opus/Sonnet • Maxプラン
19. なんかやべえのきた…
20. 6月～現在
21. XMLスキーマが書けたから、 Claude Codeに食わせてみよう
22. XMLスキーマがデカすぎて読めない なお、GitHub Copilot + GPT-4.1ならロードできる
23. AI ≠ XMLスキーマ処理系 XMLスキーマを削って読ませてみたが… • 体感で8-9割正しい内容が出力される • 明らかにスキーマ定義を逸脱した出力もある AI駆動開発を数か月やってきた経験値から、ダメそうだと判断
24. AI（LLM）の仕組み上、プロンプトだけで 厳密性を保証させようとする方針が 間違っていた
25. 課題と対応案 [課題1] XMLスキーマを入力しても出力精度が頭打ち • AIに構文エラーがあることを検知させる [課題2] XMLスキーマが大きすぎる • 必要な情報だけをロードする • XMLスキーマよりも軽量なデータフォーマットにする
26. MCPサーバーを実装してみる • validate_xml • テンプレートXMLの構文チェック • 構文エラーがあれば、エラー箇所を返す • get_document • 指定した要素の定義情報を取得
27. MCPサーバーの導入で劇的に改善 • 正しいXMLが出力できるようなった • AIの挙動 1. XMLを生成してみる 2. validate_xml 3. エラーがあればget_document→XMLを修正して、2に戻る
28. ただし効率が悪い • validate_xmlを繰り返し呼び出して、力業で直している • 最初に生成されるXMLの精度が低いことが原因？
29. 初期プロンプトの改善 以下を明示するように変更 • XML要素の一覧と概要 • XML要素の親子関係 • ワークフロー （最重要）
30. ワークフローの要点 1. 要件から使用する要素をリストアップ 2. 必要な要素の情報を取得 / MCP: get_document 3. XML生成 4. XML検証 / MCP: validate_xml ※厳密にはもう少し細かい指示を与えてる
31. プロンプト改善の効果 • 生成初回のXMLの精度が大幅に改善 • 修正なし～1回程度で正しいXMLを生成可能に • 初手で明示的にドキュメントを読むようになった • どう書いたらいいかを理解してから生成するように
32. 今後の改善ポイント • 構文エラー時に「どのように直すべきか」も返す • 警告レベルの情報の強化（≒Linter） • AI（LLM）のクセに合わせてXML仕様自体を変更 • 例えば、区切り線をやたらと書きたがる傾向がある • 既存の要素（Rectangle）で無理やり実現している
33. 今回のセッションでは話していないこと • セマンティック（内容の妥当性）はカバーできない • 「請求書を作って」の生成内容が正しいとは限らない • 追加プロンプトを都度与えればカバーできるが… • 今日話した内容とは別のアプローチが必要 • シンタックス（構文の正しさ）は今日の話でOK