Agentが原稿を作り、編集者が確認する。これで制作の流れは整ったように見えます。しかし、Webサイトと接続すると、別の判断が必要になります。サイトはどの版を読むのか。承認すると、その場で公開されるのか。ページが変わらない場合、原稿がまだマージされていないのか、それともキャッシュの更新が止まっているのか。
コンテンツを正式な記録として受け入れるルールと、訪問者に公開するルールは、それぞれ定義する必要があります。この接続が明確になれば、編集者は自分の操作が何を変えるのか把握できます。
サイトが実際に読み込む対象を確認する
Busabaseでは、ChangeRequestに提案と変更履歴を残します。審査待ち、承認済み、マージ済みは異なる段階です。マージによってレコードの参照先が進み、受け入れられた版が正式なレコードになります。承認しただけで、この更新まで完了したとは限りません。
サイト連携では、読み込み元を明示します。一般に公開ページは、受け入れ済みの正式なレコードを読み、サイト側で定義した公開条件に従って絞り込む設計が適しています。審査待ちの提案は専用のプレビューで確認し、訪問者向けの取得対象とは分けます。
公開条件は、個々のCMSとサイトで実装するものです。たとえば、マージ済みであり、定義した公開状態と公開時刻の条件も満たす場合にだけ表示対象にする、と決められます。Busabaseが接続先すべてのサイトに、その公開ルールを自動設定するわけではありません。
人の確認で止まるかどうかは権限で変わる
APIキーの権限によって、提案の扱いは変わります。changeRequest権限では読み取りと変更提案ができますが、自分の提案をマージできません。write権限のある書き込み元では、ChangeRequestの作成時に即時マージされる場合があります。呼び出し側がautoMerge: falseを明示して、その変更を審査に回すこともできます。
そのため、ChangeRequestを使っているという事実だけで、人の承認が必須になっているとは判断できません。実際の認証情報の権限、送信パラメータ、返された状態を確認する必要があります。
編集者が先に受け入れる運用なら、起草Agentには提案専用の権限を与えます。サイトの読み取り用認証情報にも、役割に必要なアクセスだけを設定します。認証情報はサーバー側で管理し、公開ページやブラウザーで動くコードには含めません。
本文だけでなく、公開される一式を確認する
本文は修正済みでも、要約が古い機能を約束したままかもしれません。中国語版の価格は直っていても、別の言語には誤りが残っていることがあります。リンクの表示は正しくても、移動先が無効な場合もあります。
タイトル、要約、本文、カバー、本文画像、リンク、各言語版を、公開する一式として確認します。言語版同士の対応関係を保ち、まとめて受け入れられるものと、個別に待つ必要があるものを明確にします。
更新原稿では、変更前後の差分と影響範囲も確認します。ある段落への同意は、公開日やURL、ほかの記事の変更まで承認したことにはなりません。提案メッセージと差分から、今回どのページに影響するのか分かるようにします。
マージの後にも、サイトへの反映工程がある
サイト側の読み込みルールには、次の内容を含めると実用的です。
- 取得対象： どのBaseの、どのレコードと正式版を、どの公開条件で読むか。
- プレビュー： 未公開版をどこで確認し、本番と同じ描画ルールを使うか。
- 更新方法： ビルドやキャッシュ無効化など、管理された方法でどう反映し、失敗をどう検知するか。
- 検収対象： 実ページの本文、言語別URL、画像、リンク、公開メタデータ。
- 公開停止： ページ、キャッシュ、関連する入口をどう更新または除去するか。
これはサイト管理者が実装するための推奨事項です。新規レコード向けのイベントが、すべての本文更新にも対応するとは限りません。イベントやポーリングを選ぶ際は、更新、状態変更、公開停止をそれぞれ扱えるか確認します。
再試行する前に、止まった工程を特定する
「承認したのにサイトが変わらない」ときは、まずChangeRequestがマージ済みか、次にサイトがどの版を取得しているかを調べます。正式なレコードが正しければ、公開条件、ビルド、キャッシュ更新を確認します。本番に古い内容が残る場合は実際の応答とページの版を保存し、公開を促すために同じ記事をもう一つ作ることは避けます。
再試行も工程ごとに行います。内容がマージ済みなら、下流の反映処理を再試行します。審査待ちなら審査を進め、版の競合なら提案に戻って確認します。あらゆる失敗を「もう一度書く」で処理すると、重複レコードが増えます。
公開停止にも検収が必要です。レコードの公開状態を変えた後、ページ、一覧、そのほか設定した入口が約束どおり更新されたかを確認します。過去の変更履歴は監査用に残し、以前何を公開していたか説明できるようにします。
Busabaseで起草から公開までの引き渡しを整理する
既存のCMS用Baseがあれば再利用し、記事を二重管理しません。新規ならFolderで資料をまとめ、Baseにタイトル、要約、本文、言語、公開条件、プレビューURLを保存できます。Docには編集と公開のルール、SkillにはAgentが起草前に読む手順を置きます。これは構成案であり、実際のフィールド名と状態値はサイトの取得処理に合わせます。言語版は関連フィールドで結び、原資料へたどれる入口も残します。
Agentはルールと情報源を読み、指定記事のChangeRequestを提出し、影響するフィールドと言語を示します。編集者が差分を確認し、マージによって受け入れた内容が正式レコードになります。サイトのサーバーはそのBaseの正式レコードを取得し、合意した公開条件で絞り込んでページを更新します。本番URLと確認結果を記事に書き戻すと、一つのレコードから原稿、受け入れた版、実ページを追跡できます。審査待ちの提案はプレビューに残します。取得、更新、結果の書き戻しは個別のサイト連携で実装します。
一種類のコンテンツで、最後までつなげる
Content Factoryを使うと、情報源、原稿、審査記録を整理し、既存のサイトに受け入れ済みの内容を読ませる構成を作れます。最初は一種類のコンテンツを選び、Agentの提案権限、編集者の受け入れ範囲、サイトの取得ルールを決めてから自動化を広げます。
内容を作成するAgentには、次のように依頼できます。
指定した情報源と編集ルールを読み、タイトル、要約、本文、リンクを一式で準備してください。既存レコードを確認して重複を避け、ChangeRequestで変更を提案してください。影響するページと言語版を明示し、返された状態とプレビューURLを編集者に渡してください。審査待ちを公開済みと報告しないでください。
サイト管理者が確認するのは別の結果です。審査待ちの変更、受け入れ済みの変更、公開停止をそれぞれ用意し、プレビュー、正式レコードの取得、本番表示が取り決めどおりか確かめます。これは推奨する検証方法であり、結果は実際のサイトで実施して記録します。
AI審査のボトルネックは、人が効率よく確認するための課題です。Webサイトへの反映では、編集者が受け入れた内容と訪問者が見た内容も、それぞれ追跡できる必要があります。この接続を明確にすることが、安心してAgentの実行量を増やす土台になります。