どの業務に使うか
記事のテーマは決まっているが、資料の整理と初稿作成に時間がかかる場合の設計例です。ここで作るのは公開原稿ではなく、編集者が検証するための構成案と本文案です。検索順位や流入増加を保証するものではありません。
入力と出力を先に決める
入力は対象キーワード、想定読者、記事の目的、参照してよい一次情報です。商品仕様や価格など更新される情報は、資料の版と確認日も添えます。出力は見出しごとの根拠を示した構成案、本文の初稿、出典を付けられなかった主張の一覧に分けます。
Difyでの構成
開始ノードで入力を受け、アップロード資料がある場合は文書抽出でテキスト化します。資料の分量が多い場合は検索対象を整理し、構成作成用のLLMには関連する部分だけを渡します。次のLLMは承認前の構成案に沿って本文を作ります。構成と本文を一度に生成させないことで、論点の不足と文章表現の問題を別々に見直せます。
検査工程では、数字・固有名詞・引用に対応する根拠があるかを確認用リストにします。これは自動の事実認定ではありません。根拠がない箇所は断定文として残さず、編集者への確認事項として出力します。CMSへの自動公開はこの構成に含めません。
設計で迷う点
外部Web検索を足す前に、使用を許可された資料の範囲を決めます。最新情報が必要な記事では、取得日とURLを保存し、生成文と別に確認できるようにします。SEOに関する提案は見出しや検索意図の仮説として扱い、事実の正確さより優先させません。
例外と確認
資料が不足している、資料同士で数字が食い違う、引用元が分からない場合は本文を完成扱いにせず、追加調査へ戻します。編集者は根拠、著作権、独自見解、表現の正確さを確認してから公開を判断します。
最初の検証では過去の記事テーマを一つ選び、構成案の不足、出典を確認できない文、編集者の修正箇所を記録します。修正理由を残すと、資料の渡し方とプロンプトのどちらを改善すべきか判断できます。
