AI ワークフローで公開する前に置く5つの人による承認

AI ワークフローでコンテンツを公開するとき必要なのは、長いプロンプトではなく五つの人による承認です。何を書くか、どの主張を許すか、下書きがどこまで言えるか、誰が公開ボタンを押すか、公開後のページが承認した内容と一致するか。この五つは人が決めます。承認を引き継ぎの中に置けば、エージェントは役に立ちます。外せば、間違いを公開する速度が上がるだけです。

この章は、コンテンツブリーフと事実確認の方法がすでにある前提で書いています。ブリーフがまだテーマと文字数だけなら、コンテンツ構成案の書き方から始めてください。確認作業が弱いなら、生成AIのファクトチェックで紹介する主張台帳が補助になります。ここで扱うのはもっと狭い話です。スクリプトやAIアシスタントが引き継ぎをするとき、人はどこに立つのか。

AI ワークフローに承認が必要で、プロンプトだけでは足りない理由

承認とは、次の工程が始まる前に記録される決定です。プロンプトは次の出力の方向を決めるだけです。この違いは、エージェントがツールを呼び、クレジットを使い、記録を書き、その間にもう一度聞かないことから重要になります。プロトコルはその責任をホスト側に置いています。MCPの仕様には、ホストは「ツールを呼び出す前にユーザーの明示的な同意を得なければならない」とあります（Model Context Protocol 仕様、2026-11-02確認）。この同意が承認であり、誰も読まないダイアログではなく業務の流れの中に置くべきものです。

多くのチームには、すでに同じ役割があります。編集者がブリーフを承認し、確認担当者が主張に署名し、公開担当者がボタンを押す。問題は、その決定を自動化された引き継ぎに移したとき、手順を書き直さないことにあります。エージェントは五つの仕事を一度に任され、残る制御は出力を信じるかどうかだけになります。

この章が作るのは三行目です。最初は遅くなり、最後は速くなります。修正がまだ安い段階で入るからです。

登場人物は三人で、同じ身元を共有すべきではありません。モデルが書き、スクリプトがデータを運び、何が起きたかを記録し、人が承認します。鍵を共有すると、記録から誰が動いたか分からなくなり、最初の重要な確認が調査になります。鍵を分けるのは手続きの重さではなく、公開の承認を見える状態に保つためのものです。

AI ワークフローの五つの承認を順番に進める

次の順番で実行します。どれも観察できる通過条件を持ち、次の人に渡せる記録を残します。記録がなければ、その承認は失敗したものとして扱います。

1. 入力の承認：問いを認める。ブリーフには読者一人、検索意図一つ、答えを持つべきページ一つを書きます。重複してはいけない既存ページがブリーフに書かれていれば通過です。検索意図の読み方が、読者の本当の問いを確かめる方法です。
2. 根拠の承認：出典を認める。事実の主張にはURLと確認日、または自社のサンプルと期間を付けます。「未確認」が残っておらず、確認担当が出典を実際に開いていれば通過です。引用を見ただけでは通りません。
3. 下書きの承認：論を認める。下書きは最初の段落で答え、節ごとに一つの考えを保ち、限界を明記します。このページが扱わないことを述べた一文を、確認担当が指させれば通過です。
4. 公開の承認：行動を認める。名前のある人が自分のアカウントでボタンを押します。公開記録にURL、時刻、実行したアカウントがあれば通過です。エージェントは内容を用意できますが、アカウントの持ち主にはなりません。
5. 検証の承認：結果を認める。公開ページを取得し、承認済みの下書きと比べます。タイトル、canonical、構造化データ、内部リンクが記録と一致し、URLが200を返せば通過です。

API や MCP での引き継ぎはどう見えるか

引き継ぎは、一つの連携ではなく、権限の組と書き残された履歴です。RESTでもMCPでも、呼び出す側には、触れてよい承認に対応したスコープの鍵が必要です。QueryWinの開発者向け文書はread、publish、spendを分け、publishはspendを含まないと明記しています（QueryWin 開発者向け文書、2026-11-02確認）。この分離が公開承認の技術版です。下書きを読める鍵が、別の下書きの費用を払う鍵に自動で変わることはありません。

同じページには十九のMCPツールが載り、ツールはスコープで絞られるとあります。読み取り専用の鍵では、生成ツールがアシスタントの一覧にすら出ません。さらに、鍵ごとに毎分120リクエスト、一日の生成上限、そして利用者が報告した公開済みと、QueryWinが約72時間後に再確認した検証済みは別の項目であることも書かれています。これらは制御であり、保証ではありません。システムが記録できることを示すだけで、下書きが正しいかは決めません。

エージェントには専用の鍵を渡します。共有の鍵は、一つの連携が破られたときにすべての承認を同時に破り、公開記録も役に立たなくします。誰が動いたか分からなくなるからです。

持ち帰れる成果物：一枚の引き継ぎ表

この表をブリーフと同じ文書にコピーします。これが制御面の全体です。五行、行ごとに一人の担当者、根拠を残す場所が一つ。担当者のいない承認は提案にすぎません。

エージェントを動かす前：
[ ] ブリーフに重複させないページが書かれている
[ ] すべての主張にURLと確認日、またはサンプルと期間がある
[ ] 確認担当が出典を開いた
[ ] エージェントは専用の鍵を持ち、今回の作業だけに制限されている
[ ] 公開には人とアカウントが明記されている

エージェントの返答後：
[ ] 下書きが限界を一文で述べている
[ ] 根拠の承認後に主張が増えていない
[ ] 公開URLが200を返す
[ ] タイトル、canonical、構造化データ、内部リンクが一致する
[ ] 公開記録に誰がいつ動いたかがある

偽装しやすい行が二つあります。「確認担当が出典を開いた」は行動の話で、チェック欄ではありません。主張の横に出典URLを書きます。「ページが一致する」は比較なので、承認した下書きの版かハッシュを残します。どちらも出せないなら、その承認は起きていません。下書きは決定ではない。

このワークフローが失敗する場所

損害のほとんどは三つの失敗から来ます。どれも軽く読むと通ってしまうので、承認は記憶ではなく記録にします。

1. エージェントがブリーフを書く。入力の承認が、モデルがもともと言いたかった内容の要約になります。ページは読者の問いではなく、簡単な問いに答えます。直し方は、生成の前にブリーフを承認し、入力をしてエージェントに渡すことです。
2. 根拠の承認がリンク確認になる。リンクが存在するかだけを確かめ、その文を支えているかを見ません。出典が実在しても、下書きの主張を言っていないことがあります。直し方は、確認担当が主張を自分の言葉で出典の横に書き、下書きと比べることです。
3. 公開の承認をツールに任せる。連携にpublishスコープがあるので公開します。技術的には何も壊れておらず、記録にはエージェントが動いたと残ります。直し方は、publishは人が使う鍵に残し、エージェントにはreadとspendだけを渡すことです。

エージェントが承認を飛ばす頻度は測っていません。飛ばした承認は記録を残さないからです。そこが問題です。失敗は出力に見えず、引き継ぎの中だけに見えます。

確認の処理能力も分かりません。五つの承認が、誰も片付けない待ち行列になることがあります。行列が詰まっているなら、記事の数を減らし、承認は減らさないでください。承認済みを少なく公開する方が、読まれていないページを多く公開するよりましです。

よくある質問

AI ワークフローとは何ですか

検索の機会を承認済みのページに変える順番で、引き継ぎごとに責任者がいるものです。ブリーフ、根拠、下書き、公開、検証を含みます。モデルは執筆の一部を担えますが、決定の持ち主ではありません。

エージェントは確認なしで公開できますか

自社の製品、市場、顧客について事実を述べるページではできません。下書きは決定ではないからです。危険が低く取り消せる出力なら軽い承認で足りることもありますが、公開記録には実行したアカウントを書く必要があります。

AI が作った内容はどう確認しますか

文章ではなく主張を確認します。事実の文を台帳に入れ、出典と日付を付け、出典がその文を言っているか確かめます。前に説明した主張台帳なら、読み返しでは通り過ぎる作られた数字を見つけられます。

MCP は承認の流れを置き換えますか

いいえ。MCPはアシスタントがツールを呼ぶ方法を標準化するだけで、どの呼び出しを人が承認したかは決めません。仕様は同意をホスト側に置いており、あなたの流れは「はい」を記録する必要があります。ツールが増えるほど、二回の確認の間に起きる行動が増えるので、記録は重要になります。

この章は引き継ぎを扱い、執筆やプロンプトは扱いません。承認があれば下書きが真になる、とも言いません。承認は決定を見えるようにするだけです。それだけで高い失敗は止められ、判断は判断すべき人のところに残ります。