AIを使うようになって、原稿の最初の形はずいぶん早くできるようになりました。
構成を出し、資料を整理し、言い回しを変える。ここまでは速い。
それでも、公開ボタンの前では止まります。
この数字は今も正しいのか。公式発表と自分の観測が混ざっていないか。リンク先は主張を本当に支えているか。
原稿ができたことと、公開してよいことは別でした。
そこで僕は、主張、根拠、更新されやすい事実を一つの記録へまとめ、公開判断をPASS / HOLDで残す「Source-to-Publish Evidence Gate」を作りました。
これはAIの記事を自動で正しくする仕組みではありません。
人が確認すべき場所を見えるようにし、公開する、まだ止める、という判断を終わらせるための小さな道具です。
AIで速くなったのは原稿作成だった
AIへ資料を渡すと、要点の抽出や構成案は短い時間で返ってきます。
複数の案を比べることも、長い文を短く整えることもやりやすくなりました。
一方で、出力が読みやすいほど、そのまま公開できそうに見えます。
文章として自然であることと、根拠が十分であることは同じではありません。
OpenAIの利用規約にも、出力は常に正確とは限らず、利用や共有の前に正確さと適切さを人が評価する必要があると書かれています。
これはEvidence Gateへの推薦ではなく、OpenAIサービスを使う時の一般的な注意です。
僕が解決したかったのは、AIの文章力ではありません。
速くできた原稿を前に、誰が、何を確かめれば公開判断を終えられるのか、という運用の方でした。
sourceを増やしても「公開してよいか」が終わらない
最初は、参考URLを増やせば安心できると思っていました。
公式ページ、仕様書、一次資料、実際に動かした結果。原稿の末尾へ並べるほど、根拠は厚く見えます。
しかし、URLの本数だけでは判断できません。
価格の主張に古い製品紹介を当てていないか。自分の環境で起きたことを、誰にでも起きる仕様へ広げていないか。確認日が必要な情報を、永続的な事実のように書いていないか。
Google Search Centralも、生成AIは調査や構成に役立つ一方、正確さ、品質、関連性、metadataやstructured dataを確認し、読者へ制作背景を伝えることが大切だと案内しています。
これも、特定のtoolを使えば検索評価が上がるという話ではありません。
sourceを集める仕事と、どのsourceがどのclaimを支えるかを決める仕事は別です。
僕は後者が曖昧なまま残り、公開前の確認が何度も最初へ戻ることに引っかかっていました。
Evidence Gateがすること、しないこと
Evidence Gateが扱うのは、利用者が用意したmanifestです。
sourceの種類、公開可能なURL、記事で使うclaim、変わりやすい事実、確認日時などを決めたschemaで記録します。
engineは、その入力が設定したruleを満たすかを検査します。
不足があればHOLD、条件が揃えばPASSを返し、同じ結果をMarkdownとversioned JSONへ残します。
ただし、source本文を取りに行きません。
検索もしなければ、claimを原稿から自動抽出せず、CMSへ公開することもありません。PASSは事実の真偽、法的適合、著者性を証明する印ではないのです。
確認した情報を入力するのは人。
その情報を公開に使ってよいか決めるのも人です。Evidence Gateは、その間にある確認漏れを機械的に止めます。
manifestからPASS / HOLDまでを一本につなぐ
流れは、public-safe manifest → claim ledger → Markdown / JSON report → PASS / HOLDです。
manifestには、外へ出してよいsource URLとclaimだけを入れます。
claim ledgerでは、どの主張を、どの種類の根拠で支えるか、更新されやすい事実か、公開前に再確認したかを並べます。
engineを実行すると、人が読めるMarkdownと後工程で扱えるJSONができます。
二つは同じgate結果を持つため、担当者の確認と機械処理で結論がずれにくい形です。
大切なのは、点数を付けないことでした。
82点だから公開する、ではなく、未確認があるのでHOLD、条件を満たしたのでPASSと理由を残す。公開しなかった理由も、あとから読み直せます。
synthetic fixtureをHOLDからPASSへ進めた
実際のengineで、架空の製品情報を使ったsynthetic fixtureを試しました。
source、claim、modeは同じまま、更新されやすいversion情報から確認日時のverified_atだけを外します。
結果はHOLD / exit 3でした。
理由は、変わりやすい事実が未確認だからです。これは処理の失敗ではなく、公開を止めるために意図した終了です。
元の情報を確認し、verified_atを加えて同じengineを再実行すると、PASS / exit 0になりました。
原稿を書き換えて判定をすり抜けたのではなく、足りなかった確認を終えたことで状態が変わります。
このvisualはデモ用の想像図ではありません。
公開中のRC.4 archiveに含まれるsynthetic fixtureを、実engineへ通した結果をまとめたものです。なお、配布中の0.2.0 wheelとRC.4 archiveは別の配布物として扱います。
offlineとpublic-safe URLにした理由
公開前のmanifestには、まだ表へ出したくない判断が集まります。
だからcore engineは、取得後の実行をofflineにし、URLをfetchせず、telemetryも送らない設計にしました。
ここでいうofflineは、最初から通信が不要という意味ではありません。
wheelやarchiveの初回downloadにはnetworkが必要です。取得後のengineが、入力済みmanifestだけをlocalで処理します。
また、manifestへはpublic-safeなURLだけを入れます。
ログイン画面、署名付きURL、社内だけの場所、credentialを根拠欄へ持ち込まない。便利な検査でも、確認のために機密を別の場所へ複製したら本末転倒です。
外へ送らないことと、何を入力してよいかを同時に決める。
僕には、この二つが公開前toolの最低条件でした。
free coreとpaid workflow packは役割が違う
free coreには、判定engine、schema、sample、安全上の説明が入っています。
まずsynthetic fixtureを動かし、HOLDの理由を直してPASSまで進めるところを試せます。
paid workflow packは、同じengineを反復運用するための実務資料です。
三つのmode、判断表、完成sample、HOLD-to-PASS walkthrough、author / editor / reviewerのhandoff、updateやrollbackのguideをまとめています。
2026年9月3日に商品ページで確認したprivate betaは、$29のone-timeです。
最大5名は販売枠で、paid licenseは購入者本人だけが使えるsingle-user。本人が所有・管理する最大3台まで利用でき、paid pack自体の共有・再配布はできません。全0.x update込みという条件も、その日の表示内容です。
販売枠と利用人数は別です。
販売数や利用者数、外部での成果も確認していないため、ここでは書きません。
一度判定を再現するだけならfree core。
一人のbuyerが繰り返し制作し、author / editor / reviewerへ生成reportや判断材料を渡す運用まで揃えたい時にworkflow packを検討する。この境界なら、無料engineを入口にしたまま選べます。
別modelのreviewも、そのまま正解にしなかった
制作途中では、Claudeにread-onlyのcross-model reviewを1回依頼しました。
onboardingとartifactのずれ、local URLやqueryの扱い、errorの安定性についてfindingが返りました。
ただし、Claudeの回答をそのまま修正指示にはしていません。
materialな項目を僕とCodex側で再現し、確認できたものだけを直しました。この考え方は、以前書いた「CodexとClaudeを相互レビューさせる運用」と同じです。
さらに、修正後の独立QAでは、正しい英数字domainまで拒否する誤検知が見つかりました。
別modelのfindingを直したあとにも、人が実際の入力で確かめる必要があったのです。
「AIの仕事を、会話ではなく成果物で確認する」運用でも、最後に見るのは返事の自信ではなく成果物でした。
Evidence Gate自身も例外ではなく、review、author reproduction、独立QAを分けて閉じました。
向く人と、向かない人
向いているのは、AIを使って技術記事、製品比較、調査記事を継続的に作る人です。
sourceが複数あり、価格、version、提供地域、規約のように公開直前の再確認が必要な記事ほど、HOLDの理由を残す意味があります。
author、editor、reviewerが分かれている現場でも、single-user buyerが生成reportや判断材料を渡す運用には合います。
paid packをteam内で共有するという意味ではありません。口頭の「確認しました」ではなく、何を確認して誰へ渡したかを同じ形式で読めるからです。
反対に、sourceを自動で集めたい人、原稿を自動でfact-checkしてほしい人、CMS公開まで無人化したい人には向きません。
入力manifestを作る手間も残るため、変動情報がほとんどない短い日記へ毎回使う必要もないと思います。
AI活用を製品と運用の両方から整理したい人には、「生成AI時代のプロダクトマネジメント」も次の読書候補になります。
Evidence Gateの開発に使った本や、本記事の出典ではありません。AIを組み込んだ仕事で、価値と責任の境界を考えるために選びました。
ポチップ
まずfree coreで一度HOLDを作ってみる
最初から自分の記事全体をmanifestへ移す必要はありません。
free coreのsampleを動かし、更新されやすい事実の確認日時を一つ外してHOLDにする。確認後に戻し、PASSへ進める。まずはこの往復で十分です。
そこで分かるのは、記事が真実であることではありません。
自分の公開基準で何が足りず、何を確認したから進めたのかを、同じ形で説明できるかです。
AIで文章を速く作れるほど、公開前に止まる仕組みが必要になります。
僕が作りたかったのは、人の責任を消す自動化ではなく、人が責任を持てるところまで判断を絞る仕組みでした。
原稿を作る速さと、公開を決める確かさを分ける。
Source-to-Publish Evidence Gateは、その間に残っていた迷いをHOLDとして見えるようにし、確認したあとにPASSで閉じるための道具です。