コンテンツ作成の自動化:確認済みの資料から下書きを作る
執筆:Ai Flowi · 公開日 。
公式情報源:Tavily ドキュメント
コンテンツ作成の自動化は、読者像と目的をまとめたブリーフと、確認済みの根拠一覧を用意するところから始めます。そのうえで、編集者向けの構成案と、出典をひも付けた下書きを生成します。自動化で調査を整理し、各セクションの下書きを作成できますが、主張に根拠があるか、記事が読者の疑問に答えているかを判断するのは編集者です。このワークフローは、既存の記事を別の形式に変換するのではなく、新しいブリーフから始めます。
設定例であり、記録されたテストではありません。調査から下書きまでの提案は、カタログに記載されたインターフェースを使用します。Ai Flowiによる本番環境でのテストは行われていません。
1. 読者が何を達成する必要があるかを明確にする
読者、取り組む課題、対象範囲、主な検索語句、記事が支援すべき判断を書き出します。使用を許可された製品情報と参考資料を加えます。キーワードは記事のテーマを示すもので、製品に関する主張の根拠ではありません。そのため、AIを使ったSEOコンテンツのブリーフでは、答えるべき問いと、その答えを裏付ける資料を区別する必要があります。
ブリーフとともに、提供されていない機能、根拠のない数値を含む主張、利用制限のある資料、記事の対象外の問いを除外リストにまとめます。製品説明を自動作成する場合は、承認済みの仕様が範囲を定めます。モデルが推奨用途を製品機能として扱ったり、提供された根拠では確認できない利点を推測したりしてはいけません。
AI Flowi Workflow、モデルへのアクセス、原文を処理する許可が必要です。 Tavilyを使う場合は、ご自身の検索サービスのアカウントとAPIキーも必要です。 Google Docsをレビュー先にする場合は、ご自身のGoogleアカウント、保存済みで、必要なアクセス権限を付与した接続、編集可能なドキュメントも必要です。 機密の調査資料ではなく、使用を許可されたサンプル入力から始めます。
2. 検索範囲を絞って参考資料の候補を集める
Tavily Search API は、カタログによると単独でもエージェントのツールとしても使用できます。段階的に進める調査の設定では、必須の api_keyを設定し、根拠を探すための問いを query に入力します。 include_domains または exclude_domains で候補サイトの範囲を指定します。使用可能なドメインリストの書式はエディターで確認してください。エクスポートには文字列フィールドが記載されていますが、書式の仕様は定められていません。
| Tavilyの入力 | 設定案 | 編集上の目的 |
|---|---|---|
topic | 参考情報を扱う記事では "general" を選択します。 | 調査をブリーフに沿わせます。 |
search_depth | まず "basic"から始めます。 | 範囲を広げる前に、役立つ資料がどこまで得られるかを確認します。 |
max_results | レビュー件数に上限を設けます。 | 編集者が検証できる範囲だけを集めます。 |
include_answer, include_images | 根拠に基づくこの文章の下書きではfalseに設定します。 | レビューを元の参考資料に集中させます。 |
include_raw_content | 処理が許可された資料に対してのみ有効にします。 | 要約に頼らず、該当箇所を確認します。 |
エクスポートされる出力は api_run_model (JSON)と api_build_tool (Tool)です。この提案では、調査結果のJSONを確認に使用します。検索結果の抜粋を検証済みの引用としては扱いません。ご自身のレビュー手順で資料を開き、出典URL、関連する箇所、日付に関する情報、その資料で裏付けられる主張を記録します。日付で絞り込んでも、ページの内容が最新である証拠にはなりません。
3. 問い、主張、資料の不足を分ける
段落の下書きを作る前に、主張の一覧を作成します。各行に、読者の問い、回答案、根拠資料の識別子、根拠の正確な所在、制約を記載します。直接確認した事実と解釈を区別します。資料の内容が食い違う場合は、両方の記述と、未解決の問いを明確にして編集者に渡します。
根拠に基づく構成案を Structured Output で作成する場合は、 system_prompt で、各セクション案に読者の問いと裏付けとなる箇所を必ず含めるよう指定します。 output_schema は、問い、セクションの目的、根拠のある主張、出典、不足情報を中心に設計します。根拠のない見出し案は、編集上の問いとして残しても構いませんが、下書きの中で事実に基づく答えにしてはいけません。
この段階での構成案に使うため、確認した箇所を根拠資料のテキスト集にまとめます。スキーマと接続要件は Structured Outputの項目 を参照してください。
関連情報:生成AIとは:下書きの作成と事実の検証の違い。
4. 承認された構成案だけを基に下書きを作る
下書き作成用の接続は、 Prompt Templateのリファレンス と Language Modelの設定方法 に従って設定します。
template は、採用した各セクションの問いを基に設定し、それぞれに根拠の識別子を添えます。 system_messageでは、出典の適用範囲を広げずに、それらの問いに答える下書きを求めます。根拠のない主張は、整った文章の中に紛れ込ませず、編集用のメモに残します。書き出しは読者の課題に合わせます。比較記事には判断基準が、手順記事には実行可能な最初の行動が必要です。
記事には、問いへの直接的な答え、ブリーフに沿ったセクション、根拠への参照、編集者向けの未解決の主張一覧を含めます。架空の統計や引用でその一覧を埋めてはいけません。既存の資料を別の形式に展開する場合は、別の AIによるコンテンツ再活用ガイドを参照してください。
5. 採用した文章を編集レビュー用に保存する
Template Merge を使用します。 Docsのテンプレート操作リファレンス に従って、編集用の下書きをレビュー用ドキュメントに配置します。
置換マップは本文全体を一つにまとめず、記事のフィールドごとに設計します。書き出しの答え、各セクションの文章、根拠メモ、未解決の主張を分けます。編集者専用のメモは公開用の文章フィールドに入れません。セクションが却下された場合は、その内容に依存する主張を書き出しからも削除します。見出しで約束した内容をそのまま残すと、根拠を示すセクションが変更された記事について誤解を招くおそれがあります。保存後の内容をタイトルから最後の段落まで読み、その不整合を見つけます。
記録されたフォームからDocsへのフローは、テストに42/42で合格しました 。ただし、これは文書化された改行変換の範囲内での結果です。そのレシピの作成処理だけを裏付けるものであり、この調査、執筆、マージの提案を裏付けるものではありません。
6. コンテンツ作成の自動化で根拠のない主張を止める手順をどうテストしますか?
根拠のない製品機能を一つ含むブリーフ、矛盾する記述のある参考資料、出典のない引用を下書き作成プロセスに与えます。採用した文章がドキュメントに入る前に、レビュー用の成果物でこれらの問題が明らかになる必要があります。記事がキーワードを繰り返すだけでなく、当初の読者の課題に答えているかを確認します。
例として、文書の下書き作成を扱う購入検討者向けの記事では、コンポーネントが文章を作成する根拠と、その承認プロセスの根拠を分けます。カタログの説明は前者を裏付けられますが、作成された文章が承認されたことや、利用者の時間が短縮されたことまでは確認できません。これらの主張を一覧の別々の行に割り当てます。ブリーフが、資料では裏付けられない利点を求めている場合は、確認可能な下書き作成手順とレビューの限界を説明する内容に修正します。成果を捏造せずに、役立つ答えを提供できます。
公開前に、各セクションが異なる役割を持つか確認します。資料収集を説明する見出しが二つある場合は、資料の発見と信頼性の判断など、異なる判断を扱っていない限り、一つのセクションにまとめます。書き出しの答えを繰り返すだけの段落は、手順も根拠も追加しません。削除して、その分、読者が避けられる具体的な誤りを説明します。
この提案を自動公開、内容の乏しいページの大量作成、検索順位に関する主張に使用してはいけません。検索結果やモデルの文章は、誤っていたり古くなっていたりする可能性があります。資料の最新性は 文書の出典監査で確認します。成果物が業務上の指示である場合は、 レビューを前提とした手順書の下書き作成 を利用します。
プランとワークフローの容量。月間 Flowi Tokens は Go が 5,000、Plus が 25,000、Pro 100 が 50,000、Pro 200 が 100,000、Pro 500 が 250,000 です。ワークフロー、連携ツール、確認手順に合う容量を選んでください。 デモを予約
実装の参照資料は カタログ と 最初に試すユースケース です。このワークフローで得られるのは、編集者がまとめて評価できる、新しい記事のブリーフ、主張一覧、編集可能な下書きです。