AI記事の公開前ゲートを設計する——出所の確認と承認内容の照合で書き出しを止める

整った一本だけを見て、企画を通せるか

広報担当が新しいサービスを紹介する三本の記事をAIへ依頼したとします。一本目は利用手順、二本目は効果、三本目は担当者の体験談です。どれも自然な日本語で、見出しも揃っています。担当者が一本目だけを読んで「この企画で進めて」と伝えたとき、残り二本も公開してよいのでしょうか。効果の数字に根拠がなく、体験談の話し手が不明なら、同じ企画に属することだけでは公開の条件を満たしません。

記事制作基盤には、生成した文章をすぐ外部へ送らず、根拠の確認と人が読む資料の準備を経て停止する設計があります。問題がない場合も確認待ちとなり、承認された記事を書き出す工程は別に置かれています。本文を作れたこと、確認できる状態にしたこと、承認を受けたことを、それぞれ違う成果として扱う構成です。

以下では三本のうち効果の記事だけが根拠不足だった場合を追います。人が何を見るべきか、一本を直した後に前の承認が使えるか、書き出しが終わったら公開済みと呼べるかを順に考えます。ローカルの書き出しと外部公開は別の工程です。どこまで処理が進み、どの確認が残っているかを整理しておくと、未配信の記事を公開済みと取り違えずに済みます。

企画時に、三本へ別々の材料を渡す

最初に三本を同じサービスの紹介という目的へまとめながら、各記事に使える材料を分けます。利用手順には承認済みの操作説明、効果には測定条件が分かる報告、体験談には話し手と掲載許可が確認できる記録を使う、という設計例です。共通の題材だからといって、操作説明から効果の数字を推測したり、サービス紹介文から担当者の経験を創作したりしてよいわけではありません。

受渡しでは、各記事がどの材料に基づくかを対応させます。効果の記事に測定報告が見つからなければ、その不足を残して止めます。今回の例なら「サービスの操作は説明できるが、作業時間の短縮率は確認できない」という形です。企画全体を漠然と失敗にせず、何が足りず、どの記事の主張へ影響するかを示すと、担当者は資料を探すか、効果の断定を取り下げるかを選べます。

記事を区別する情報も必要です。確認結果が別の記事に結び付くと、手順の根拠があることを効果の根拠があることに取り違えます。実装には題材や保存先の扱いに関する検査があり、同じ場所へ意図せず記事が重なることを避ける考え方が見られます。運用上は題名だけでなく、記事の目的と使う材料を並べて確認すると、どの一本を差し戻したのかを人も追いやすくなります。

根拠不足の一本を、どう書き直すか

効果の記事が「導入すれば作業時間が三割減る」と断定していたとします。測定報告がない条件では、文章の言い回しを弱めるだけで根拠の不足は埋まりません。「大きく減る可能性がある」へ変更しても、その可能性の根拠を説明できなければ同じ問題が残ります。まず数字を使う目的を確かめ、測定資料を用意するか、確認できる機能の説明へ構成を変えるかを選びます。

代案としては、削減率を示す記事を「どの作業が自動化の対象になるか」という記事へ変える方法があります。承認済みの操作説明が、入力の転記を省く機能を示しているなら、その手順までを解説できます。ただし実際に何分短縮されたか、利用者の負担が減ったかは別の確認が必要です。この変更では結論を都合よく維持するのではなく、根拠が支えられる問いへ記事の役割を組み直します。

実装の根拠確認は、資料の登録状況、対象組織との対応、利用承認、有効期限、参照場所などを調べる設計です。期限切れの資料がある場合と、そもそも資料がない場合は、追加で確認する相手も違います。一方、この検査だけで文章に含まれる全ての主張の真偽を保証するわけではありません。登録条件を満たす資料であっても、資料に書かれていない効果を本文が述べていれば、人の読解で見つける必要があります。

体験談には、経験の持ち主を残す

二本目の根拠不足を直しても、三本目には別の問題が残り得ます。「私たちは導入後に困らなくなった」という一人称の体験を、誰の話か分からないまま生成している場合です。サービス提供者の説明を読んだAIが、利用者の体験として語れば、資料の出所を示していても経験の帰属が変わってしまいます。体験談では、何が起きたかだけでなく、誰がどの立場で語っているかが内容の一部です。

担当者の発言記録を使う企画なら、その人が経験した範囲を確認します。導入前の検討を担当した人の話は、導入後の業務成果の証言にはなりません。掲載許可が取れていなければ、確認待ちとして止めるか、公開できる客観的な手順の説明へ変えます。匿名にすれば何を書いてもよいのではなく、匿名でも経験の出所と許された利用範囲は制作側で把握する必要があります。

実装には一人称の話し手と資料の持ち主を扱う検査がありますが、限られた表現の検出だけで全ての帰属違いを発見できるとは言えません。「私」を使わずに体験を断定する文章もあります。そこで人の確認では、主語、引用の範囲、体験の時点を読んで、根拠のない顧客事例が混ざっていないかを見ます。効果の数字と経験の帰属は別の失敗なので、どちらかを直したことを企画全体の確認完了にしない設計が必要です。

人に渡すのは、本文だけではない

根拠の問題を整理した後、制作は確認用資料を準備して一度停止します。確認者が読むのは三本の本文に加え、使った根拠、検査で見つかった問題、記事の扱いに関する設定です。文章だけを見せると、なぜ数字を削ったのか、どの体験談を使わなかったのかが分からず、確認者が善意で削除部分を戻してしまう可能性があります。変更理由を読める形で渡すことも、確認の入力を揃える作業です。

例では、利用手順は根拠資料と照合済み、効果の記事は測定値を使わない構成へ変更、体験談は掲載許可の確認待ち、と整理できます。この状態なら三本全てを公開するか、一部を外すか、追加資料を待つかという選択が具体的になります。根拠が不足する記事を黙って消すのも、残りと同じ扱いで紛れ込ませるのも避け、現在の企画に何が含まれるかを確認者へ示します。

この段階は生成担当の「完成」と、人の「承認」をつなぐ境界です。確認用の資料を作れたことだけでは、人が読んだ証拠になりません。実装は明示された承認の記録を、承認後の記事を書き出す工程へ渡す構成を持ちます。例の運用で誰が承認権限を持つか、どの条件で一部の記事を除外できるかは、導入側で定める必要があります。処理の停止場所があることと、社内の責任分担が決まっていることは別です。

三本目の掲載許可が間に合わないなら、二本だけで公開判断へ進む案もあります。この選択は自動処理に任せず、企画担当が掲載範囲を決める運用にします。三本目を外した結果、残る記事が体験談を参照していないか、企画の導入文が「三つの事例」と述べていないかも見直します。一記事を削る判断が、他の記事の整合まで変えることを、承認者へ渡す資料に含めます。

承認したあとで一本を変えたら

仮に確認者が三本の現在の内容と公開先を読んで承認した後、二本目の題材を変更したとします。文章の差替えは一記事だけでも、前の承認が対象としていた組と違います。実装では、現在の記事の組、公開先、適用する方針、確認報告の内容が承認記録と一致することを求めます。企画名が同じだから前の承認でよい、という扱いにはしません。

この照合は承認者の手間を増やすためではなく、何に同意したかを保存するためです。例えば、三本を自社の紹介ページへ置く承認と、一本を外部広告として配信する承認は意味が違います。本文が同じでも送り先や扱いが変われば、公開条件を改めて見直す必要があります。承認を単なる「進めてよい」の一言として扱うと、あとから増えた用途まで許可したように見えてしまいます。

部分修正を頻繁に行う制作では、全体の承認を毎回取り直す方法が重く感じられるでしょう。その場合に必要なのは、無条件な省略ではなく、承認の対象をどこまで分けられるかという設計です。ただし、この基盤では企画全体が承認対象であり、記事単位への分割は追加の設計になります。読者が別の運用へ応用するなら、部分修正が他の記事の説明や公開条件へ影響するかまで含めて検証する必要があります。

承認の照合には、記事内容・適用方針・レビュー報告それぞれの識別値（SHA-256で作るハッシュ値）を使います。承認を現在の対象へ結び付け、文章や公開先が変わった後に古い了承を流用しないための仕組みです。ハッシュが一致しても主張の真偽は証明できないため、根拠の読解と承認者の判断は前段に残ります。

書き出しが終わっても、サイトはまだ別

承認を受けた記事を書き出す工程は、ローカルの納品用のまとまりと、その処理結果を保存します。確認した実装のこの経路は外部ネットワークへ記事を投稿しません。処理の中で公開に相当する言葉が使われていても、読者へ説明すべき成果は、承認済みの内容を取り出せる状態にしたことです。これを実際のサイトで公開されたことと混同すると、広報担当は未配信の記事を公開済みとして案内してしまいます。

例では、承認した三本を納品用にまとめるところまで終わっても、公開担当が掲載先へ反映し、外部から記事を読めることを確認する工程が残ります。画面上の完了だけを見ず、何が保存され、どこまで送られたかを確かめます。書き出しの記録はローカル成果の証拠であり、公開先の閲覧成功を示す証拠ではありません。公開を別の担当やサービスへ引き継ぐ場合ほど、この差を明示する意味があります。

文章を作る入口にも境界があります。この記事で扱う操作の入口は、実際の文章生成を行わない模擬処理です。実制作には文章生成の仕組みを接続する必要があります。資料の読込も既定ではローカルのものを扱うため、外部の資料を取り込むには別の接続が要ります。模擬処理を最後まで通せたことから、実際の生成費用、外部資料の取得、本番公開まで問題なく動くと推定することはできません。

試作では、一本の不足を残して確かめる

試験には、ネットワークを使わずに確認用資料を作る例、根拠が不足する例、承認が現在の内容と一致しない例、模擬処理を扱う例があります。これらは試験の定義と実装から確認できる範囲で、現行環境での実行結果ではありません。根拠の検査がどこで止めるかを説明する材料にはなりますが、実際の文章生成の品質や本番サイトの公開成功まで確認した証拠としては扱いません。

自分の業務で試すなら、三本のうち一本だけに根拠資料を渡さない条件を作ります。期待するのは、不足した記事と主張を示して確認を止め、根拠が揃う記事の状態も読めることです。次に不足を直して確認用資料を作り、承認後に一本の文章を差し替えます。そのとき古い承認で書き出せないかを見ます。最後に正常な記事の組へ戻し、承認された内容が納品用のまとまりへ一致しているかを調べます。

読後に最初に確認してほしいのは、自社の「公開完了」が指す場所です。文章ができた時点なのか、承認済みになった時点なのか、外部の読者が読めた時点なのかを分けて書きます。そのうえで、根拠不足を直す担当、承認する担当、掲載を確認する担当へ渡す材料を揃えてください。企画全体の品質を、整った一本や生成担当の完成宣言から推定しないことが、三本を安心して公開判断へ進める最初の設計になります。