生成AIワークフローの品質を安定させる設計｜LLMと決定論スクリプトの役割分担

生成AIを使った記事、動画、資料の制作は、最初の試作が動いても運用段階で品質が安定しないことがあります。同じ指示なのに構成が変わる、HTMLのクラス名が揺れる、検証項目が抜ける、修正のたびに別の場所が崩れる。こうした問題は、プロンプトを長くするだけでは解決しません。

結論は、LLMの役割を構造化データと素材の準備に限定し、生成、検証、レンダリングを決定論スクリプトへ分けることです。AIには意味を理解して選ぶ仕事を任せ、同じ入力から毎回同じ結果にしたい工程はコードで固定します。境界を明確にすると、モデル変更や再実行があっても品質基準を保ちやすくなります。

LLMに完成物まで書かせると品質が揺れる理由

LLMは、文章の意味をつかみ、要点を選び、例を作ることが得意です。一方で、同じ入力でも表現や構造が少しずつ変わります。HTML全体、CSS、タイミング、検証条件まで一度に作らせると、その小さな違いがクラス名、要素数、配置、ファイル参照の揺れとして積み重なります。

実運用では、見た目を整える指示を追加するほど出力が長くなり、修正対象と守るべき条件が混ざりやすくなりました。ある箇所を直す再生成で、合格していた別の箇所まで変わることもあります。これはAIの性能不足というより、意味判断と機械処理を一つの出力へ詰め込んだ設計上の問題です。

工程	LLMが向く仕事	スクリプトが向く仕事
企画	読者の悩み、要点、順序を選ぶ	ID、必須項目、文字数範囲を検査する
素材	場面に合う説明や候補を作る	ファイル存在、形式、寸法を確認する
組み立て	構成データを作る	テンプレートからHTMLや画面を生成する
品質確認	意味の自然さを批評する	件数、重複、参照切れ、範囲を判定する
出力	修正理由を説明する	同じ入力を同じ手順でレンダリングする

最初に構造化データの契約を決める

役割分担の中心は、LLMとスクリプトの間に置くデータ契約です。JSON、YAML、CSVなど形式は問いません。重要なのは、各項目の名前、型、必須か任意か、許容範囲、参照先を先に決めることです。自由文の完成物を受け取るのではなく、機械が検査できる設計図を受け取ります。

たとえば画面構成なら、`scene_id`、`headline`、`body`、`asset`、`layout`、`duration`のように分けます。LLMは内容に合う値を決めますが、タグの入れ子や配置計算は書きません。スクリプトは値をテンプレートへ流し込み、定義されていないレイアウト名や存在しない素材パスがあれば生成前に止めます。

生成・検証・レンダリングを同じ入力へ接続する

次に、合格した構造化データを唯一の入力として、生成、検証、レンダリングをつなぎます。生成スクリプトはテンプレートを使って成果物を組み立てます。検証スクリプトは、その成果物と元データの両方を確認します。レンダリングは検証合格後だけ動かし、途中の手修正を前提にしません。

1. 設計: LLMがスキーマに沿った構成データを作る
2. 入口検証: 型、必須項目、範囲、参照先を確認する
3. 機械生成: 固定テンプレートからHTMLや中間成果物を作る
4. 成果物検証: 件数、重複、表示条件、リンク、素材を確認する
5. レンダリング: 合格した入力とコードの版を記録して出力する
6. 目視確認: 意味、読みやすさ、違和感など機械で判定しにくい点を見る

この流れなら、文言だけを変えたい時は構成データを直し、レイアウトを変えたい時はテンプレートを直せます。どちらを変更したかが明確になり、全体をLLMへ書き直させる必要がありません。同じ入力と同じコードなら同じ中間成果物を再現できるため、問題の切り分けも速くなります。

検証は失敗条件を先にコードへする

品質基準を文章だけで残すと、確認者によって解釈が変わります。数えられる条件は、生成後ではなく生成前から検証コードへ移します。必須キーの欠落、ID重複、参照ファイルなし、文字数の範囲外、長すぎる表示、同じ素材の連続、リンク切れなどは機械判定できます。

検証層	確認例	失敗時の戻り先
スキーマ	型、必須キー、列挙値	LLMの構成データ
素材	存在、形式、寸法、重複	素材選定
構造	見出し数、順番、ID一意性	データまたはテンプレート
公開面	HTTP、画像、リンク、横はみ出し	生成または公開設定
意味	誤解、読みやすさ、名義、公開可否	人のレビュー

モデルを変えても壊れにくい運用へする

完成HTMLやレンダリング手順をプロンプトの中へ埋め込むと、モデルごとに出力の癖が変わります。構成データだけを受け取る設計なら、モデル変更時に見るのはスキーマ合格率、意味の品質、修正回数です。テンプレート、検証、レンダリングは同じコードを使い続けられます。

• 入力、スキーマ版、テンプレート版、実行時刻を記録する
• LLM出力の自由文をそのまま実行しない
• 検証に落ちたデータだけを理由付きで再生成する
• 完成物の手修正ではなく、データかコードへ修正を戻す
• 公開や送信は最終ゲート合格後だけ許可する

WordPress記事を一定のブロック構造で作る場合はACS Article Generator、公開資料の数値を本文と画像で照合する例は公式PDFをAIで記事化する確認手順、定期処理の入口を整理する場合は定期タスクの二重実行防止も参考になります。自社工程に合わせた実装は開発依頼で相談できます。

よくある質問

まとめ

生成AIワークフローの品質を安定させるには、LLMへ完成物の全工程を任せません。LLMは意味を理解して構造化データと素材を作り、決定論スクリプトが生成、検証、レンダリングを担当します。データ契約、失敗条件、修正の戻り先を先に決めれば、モデルや入力が変わっても品質基準を保ちやすくなります。

決定論的な検証工程へモデル比較を加える場合は、FP8型エラーをBF16代替と実測で切り分ける方法も確認してください。

決定論的な監視工程へMacアプリ操作を組み込む場合は、AppleEventタイムアウト-1712をアプリ応答と処理へ分ける方法も確認してください。

生成工程と品質確認を分けるには、生成AIの部分編集を検証する方法も確認してください。

自動化へ新しい拡張を足す時は、外部Skillの入手元・権限・差分を確認する手順も役立ちます。

公開できる構成を決めた後は、AI動画の商用利用ライセンス確認で根拠も記録してください。