AI記事の公開前レビュー12ステップ
この記事で学べること
- 記事作成、機械検査、人の承認を分ける必要性
- 主張抽出、引用確認、URL・数値・構造検証を含む12ステップの進め方
- 作成したAIが
passedへ進めず、人が公開可否を判断するゲート設計
AI記事の公開可否を段階的に確認する
AI支援の記事を安全に公開するには、構造とリンクの自動検査、事実と日英対応の編集確認、公開責任を持つ人の承認を別の段階にします。形式が整っていても、事実確認、著者体験、公開判断が未完了のまま残ることがあるためです。このサイトでは、作成したAIが自分の原稿を合格にせず、12段階の確認を通して公開可否を決めます。
この記事では、「自動検査と人の判断をどの順で通し、誰が公開を承認するか」という問いに焦点を当て、実行前の前提、作業手順、完了を確かめる方法を扱います。
最後まで読むと、「自動検査と人の判断をどの順で通し、誰が公開を承認するか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
AI記事レビューは根拠・体験・公開責任を分けるために必要になる
AIは確信を持った口調で不正確な情報を書くことがあります。特に数値、リンクURL、法律・規制の詳細は、確認せずに公開するリスクが高い要素です。
また、外部の事実を引用している記事では、引用箇所に参考文献番号が対応しているかどうかも確認が必要です。リンクが存在していても、そのリンク先が本文の主張を支えているとは限りません。
作成エージェントは自分のドラフトをpassedにしない
passed は「Markdownの構造が正しい」という意味ではなく、「公開してよいと判断された」という状態です。そのため、新規記事を作成したエージェントが、自分の出力をそのまま passed にする実装にはしませんでした。
作成エージェントに任せてよいのは、次のような構造整合性の確認です。
- frontmatter（Markdown記事の先頭に置くtitle、description、dateなどの設定情報）の必須項目、slug（記事の公開URLや内部リンクで使う短い識別子）、date、series、series_order、tagsがルールに沿っているか
- JA/EN ペアの構成、日付、シリーズと読む順番、見出し順が揃っているか
- 本文の参考文献番号と参考文献リストが対応しているか
- 内部リンクやリポジトリ内コマンドの記述が現在の実装と矛盾していないか
- 既存記事との重複候補が機械的に検出されていないか
一方で、次の判断は作成者だけで閉じるべきではありません。
- 参考文献が本文の主張を本当に支持しているか
- 著者体験として書いた内容が実際の経験と一致しているか
- 似た記事があっても、読者にとって別記事として必要か
- 表現、結論、公開タイミングが著者の意図に合っているか
- 修正ではなく公開承認として扱ってよいか
この分離により、記事作成時点では review_status: needs_review を維持します。構造上の問題はできるだけ解消しますが、公開承認だけは承認台帳と人の判断に残します。
公開判定を構造・根拠・人の判断・公開状態のゲートへ分ける
公開前レビューでは、機械で確認できることと人が判断することを別々のゲートにしました。
review:contentは frontmatter、引用番号、参考文献形式、公開停止レベルの構造問題を確認します。review:repo-claimsは npm scripts、ローカル設定、build と deploy の説明など、リポジトリ実装と照合できる主張を確認します。review:duplicatesは同じロケール内の既存記事と近すぎる記事を候補として出します。review:ledgerは、人が判断すべき主張、重複候補、リポジトリ証拠の確認事項を承認台帳の形にまとめます。
この設計にすると、エージェントは「公開できる」と宣言するのではなく、「構造チェックは通したが、公開承認は残っている」と状態を明示できます。記事の品質管理では、この違いが重要です。
公開前レビューは目的確認から公開判断まで順に進める
著者が記事の目的と主張を定義する
AIにドラフト作成を依頼する前に、誰に何を伝える記事なのか、著者としてどの経験・意見を含めるのか、外部情報をどこまで扱うのかを人が決めます。この段階での決定がドラフトの品質と、その後のレビューの基準になります。
記事の種別を確認する
記事がドキュメントページなのかブログ記事なのかを確認します。種別によってレビューの基準が異なります。ドキュメントは根拠の明確さと正確性が最優先です。ブログは著者の体験・解釈を含むため、体験部分と事実部分を区別してレビューします。
記事全体を最初から一度通読する
この段階では編集しません。記事全体の流れを把握し、確認が必要そうな箇所に印をつけます。編集と確認を同時に行うと、確認がもれやすくなります。
確認が必要な主張を抜き出す
本文から、具体的な数値、統計、外部情報に依拠した説明、誤っていると読者の判断に影響する断定を抜き出します。これらは事実確認が必要な主張です。
引用が必要かどうかを判断する
抜き出した主張が、著者の個人的な体験・意見なのか、外部の事実・統計なのかを区別します。外部の事実・統計を根拠にしている場合は参考文献が必要です。著者の体験や意見は引用不要ですが、著者本人の確認は必要です。
参考文献番号と本文の対応を確認する
参考文献がある記事では、本文中の [1] [2] などの番号が、記事末尾の参考文献リストの番号と対応しているか確認します。番号がずれていると、読者が根拠を追跡できなくなります。
URLが実在するか確認する
参考文献のURLをブラウザで開き、実際にページが存在するか確認します。AIは存在しないURLを生成することがあります。URLが404になる場合は、正しいURLを探すか、参考文献から除外します。
数値の計算や根拠が正しいか確認する
記事に数値の計算や派生値が含まれる場合、計算が正しいか確認します。比率・割合の計算は特に確認が必要です。
未確認のURL・数値・体験を削除または限定表現へ直す
ステップ3〜7で確認した問題を修正します。確認できないURL、一次情報源が見つからない数値、著者が確認できない体験は、記事から削除するか、断定しない表現に置き換えます。
構造チェックを実行する
npm run review:content を実行し、フロントマター、引用、参考文献、レビュー状態などを機械的に確認します。記事内にローカルコマンドや実装の説明がある場合は、npm run review:repo-claims でリポジトリ実装とも照合します。
重複と内部リンクを確認する
npm run review:duplicates を実行し、同じロケール内で既存記事と近すぎる内容がないか確認します。記事内の内部リンクも確認し、Markdownファイルの存在だけでなく公開ルートとして成立しているかを見ます。
公開ゲートを確認する
ハーネス（AIに渡すルール、作業手順、検証方法をまとめた仕組み）とレビューガードレールを実行し、公開前の最終確認として次の項目を確認します。
- タイトルに命令型・挑発型の表現が含まれていないか
- 未確認の著者の経歴・実績を本文に含めていないか
- Critical（公開停止）レベルのレビュー問題が残っていないか
- 記事作成者とは別の人による公開承認が残っているか
人のレビュー後に公開する
npm run review:ledger で人の確認事項を出力し、記事本文、証拠、重複候補、著者体験を人が確認します。承認できる場合だけ、承認台帳に判断理由と証拠を残し、記事を passed に進めます。
まとめ：公開判定は記事の作成者と承認者を分ける
この実装の狙いは、AI支援の作業を止めることではなく、AIに任せる範囲を明確にすることです。構造整合性、リンク、frontmatter、リポジトリ実装との照合は自動化できます。一方で、公開してよいかどうか、著者の体験として正しいか、似た記事として残す価値があるかは、人が判断する領域です。
新規記事を needs_review に残すことで、記事作成と公開承認を分離できます。作成エージェントは整ったドラフトを用意し、人が公開責任を持って承認する。この分担が、AI支援で記事を増やすときの品質管理の基本になります。
最初の行動は、12段階の各確認へ「自動検査」「編集者」「公開承認者」のいずれかを割り当てることです。自動化できる項目が増えても、著者経験の正しさ、類似記事を残す価値、公開責任は機械判定だけで完了させません。