「AIにブログ記事や下書きを作らせると、一見もっともらしい文章が出てくるが、必要な要件が抜け落ちていたり、薄い一般論が混ざったりする」。 「かといって、人間が全文を一字一句細かく校正していては、AIを導入した時間削減効果が消えてしまう」。
1人法人や個人開発でオウンドメディアやブログを運営する際、記事制作（post-generate）や反響分析（post-analyze）の体制が整った後に直面する最大の壁が、**「公開前の品質チェックに取られる時間の肥大化」**です。
どれだけ執筆を自動化しても、公開前のチェックを人間の感覚だけで行っていると、「内部リンクを貼り忘れる」「文字数が足りない」「誇大表現が混ざる」といったミスが必ず発生します。
そこで私の会社（Nogawa L.prince合同会社）では、公開前チェックリストに基づく品質管理エージェント（社内呼称：029「関門 検一」）を導入し、検査の自動化を進めました。
先に結論から言うと、「文字数、内部リンク、タイトル形式、具体的数値の有無」といった客観的な形式要件は、100%機械判定に任せられるようになりました。しかし、「一次体験の真偽、クライアントの守秘義務、独自の洞察があるか」という本質的な判断は、最後まで人間が握り続けました。
長期連載「1人法人1000馬力化計画」の第4回として、点数と公開判断を切り離した品質管理エージェントの設計思想と、自社で112本の記事を検査して分かった運用のリアルを記録します。
この記事の結論（先に3点）
- 「機械判定できる項目」と「人間が判断する項目」を厳密に分離: 文字数・内部リンク・タイトルのクエリ形・具体的数字はプログラムで0/1判定し、独自性・一次体験・守秘義務の30点は人間が目視確認するハイブリッド採点（75点合格基準）を確立。
- 「足切り」と「要確認」を分ける: 内部リンク不足や極端な文字数不足は「公開即NG（足切り）」、タイトルのクエリ判定などは「要確認（警告）」として扱い、誤検出で作業が止まるのを防止。
- 事実確認は「誤りの指摘」ではなく「確認の依頼」にする: 一次体験の記述（「サービスを比較検討した」等）は機械では真偽を判定できないため、検出箇所をリストアップして人間に差し出す「035 実栗 証」の分担を導入。
適合する読者と限定事項
- この記事が役に立つ人:
- AIを活用してブログやオウンドメディアを運営しており、記事の品質チェックに追われている人
- LLMやスクリプトによる品質ゲートウェイを自社の開発・執筆フローに組み込みたいエンジニア
- 「AIの出力をどう安全に本番投入するか」の責任分界点を設計したい人
- 限定事項:
- 市販の文法チェッカーの紹介ではなく、自社の実務で「品質事故を防ぎながら、人間のチェック時間を数分に短縮するための設計記録」です。
課題：AIに全部チェックさせると「見落とし」と「過剰な指摘」で破綻する
記事の品質検査を自動化しようとした際、最初に試したのは「LLMに記事全文を渡し、問題点を指摘させる」という素朴なアプローチでした。
しかし、この方法はすぐに運用が破綻しました。理由は2つあります。
1. 致命的な形式不備をスルーする
LLMは文脈や文章の流れを読むのは得意ですが、「内部リンクが何本貼られているか」「本文が指定の1,500文字を超えているか」といった単純な計数・形式チェックを平気で見落とします。文章の雰囲気が整っていると、重要な必須要件が欠落していても「素晴らしい記事です」と高得点をつけてしまうのです。
2. 主観的なダメ出しで人間の手が止まる
逆に、「もっと情緒的な表現を加えるべき」「この段落は読者の共感を呼びにくい」といった、レビュアーの主観や好みに属する指摘を大量に出力してきます。これらに人間がいちいち付き合っていると、修正に何十分もかかり、何をもって「合格」なのかが分からなくなってしまいました。
この失敗から学んだのは、「機械（ルールベース・スクリプト）にしかできないこと」と「人間にしかできないこと」を混ぜてはいけないという原則でした。
解決策：75点満点の配点制と、機械と人間の責任境界
そこで導入したのが、事業運営の原則に基づく**「75点合格基準」の品質検査システム**です。
検査項目を「機械が0/1で判定できる形式項目」と「人間が目で見て判断する定性項目」に完全に二分しました。
1. 機械判定ゾーン（スクリプト担当：029 関門 検一）
scripts/lib/check-article-quality.ts というTypeScript製スクリプトが、原稿のMarkdownを解析してミリ秒単位で検査します。
- 本文文字数（1,500文字以上）：【足切り条件】満たさなければ即座に公開不可。
- 内部リンク数（2本以上12本以下）：【足切り条件】自社ブログの回遊性を保つため、重複のない正常な内部リンクが2本以上あるかを正規表現で厳格にカウント。
- タイトルが検索クエリ形であるか：タイトルに読者の検索意図（「とは」「方法」「比較」「違い」「実数」など）が含まれているかを判定。
- 具体的な数字が1つ以上含まれているか：金額、時間、パーセントなどの具体的実績数値が含まれているかを検査。
2. 人間確認ゾーン（社長・人間の担当）
機械では判定不可能な項目は、最初から機械に判断させず、人間が最終確認を行います。
- 一次体験・生データの有無（20点）：ネットのまとめではなく、筆者自身の実体験や実際のログ・失敗談が含まれているか。
- 守秘義務・プライバシーの遵守（10点）：クライアント名や特定可能な情報、家族のプライバシーが適切に抽象化されているか。
- 検索意図への真の回答（20点）：読者の問いに対して、冒頭で結論が提示されているか。
機械判定の項目をノーミスで通過した上で、人間が定性チェックを行うことで、合計75点以上になれば「公開GO」と判定します。
【構造化比較】一括目視レビュー vs 機械判定＋人間確認の分担モデル
従来のすべてを目視で行うレビューと、機械判定を前段に置いた分担モデルの違いを比較表にまとめました。
| 比較項目 | 従来の一括目視レビュー | 機械判定＋人間確認の分担モデル |
|---|---|---|
| 形式チェック（文字数・リンク等） | 人間が目視で数える（見落としが頻発） | スクリプトがミリ秒で自動判定（足切り条件でブロック） |
| 事実・一次体験の確認 | 記事全体を漫然と読み直して探す | check-experience-claims が該当箇所だけを抽出して提示 |
| レビュー所要時間 | 1記事あたり15〜20分 | 機械判定1秒 ＋ 人間の確認2〜3分 |
| 合格基準のブレ | レビュアーの疲労度や気分で基準が揺れる | 75点基準と足切りルールで客観的に判定 |
| 誤検出への耐性 | 気になった箇所をすべて直そうとして疲弊 | 「足切り（ブロック）」と「要確認（警告）」を分離 |
| 担当社員（本体） | 社長（人間）ひとりの多重タスク | 029 関門（形式） ＋ 035 実栗（事実） ＋ 社長（判断） |
自社運用のリアル：112本一斉検査で直面した2つのトラブル
実際にこの品質管理システムを社内に導入した初日、既存の全112本の記事に対して一括検査を実行しました。そこで浮き彫りになった泥臭いトラブルと対策を紹介します。
1. 「タイトルがクエリ形」の誤検出事件
初回の実行時、112本中なんと63本が「タイトルが検索クエリ形ではない」と判定されました。 詳しく調べてみると、判定用の正規表現パターンに「〜とは」「方法」「手順」といった代表的な語句しか登録されていなかったためでした。
実際には、「実数」「比較」「基準」「なぜ」「違い」「3つの」といった、検索意図に完璧に合致した優れた記事タイトルが大量に誤検知されていたのです。 すぐに判定ロジック（QUERY_SHAPED_PATTERNS）に実務で使われるクエリ表現を網羅的に追加した結果、誤検出は38本まで激減しました。
【教訓】: 機械判定のルールは最初から完璧を目指すのではなく、自社の過去データに当てはめて誤検出を削りながら「育てる」必要があります。
2. 一次体験の記述を拾う「035 実栗 証」と確認済み台帳
もう1つの重要な仕組みが、事実確認を担当するエージェント（035「実栗 証」 / check-experience-claims.ts）です。
「2つ以上の選択肢を比べた」といった、誇大広告や虚偽になりやすい一次体験の主張を全記事から正規表現で自動抽出し、「本当にこの体験をしたか？」と人間に突きつける役割を持ちます。
しかし、一度確認した記事に対して毎回同じ警告が出続けると、人間はアラートを無視するようになります（アラート疲れ）。 そこで、人間が一度「確認済み」とした段落の内容からハッシュ値を生成し、台帳（blog/confirmed-claims.md）に記憶させる仕組みを追加しました。
本文の文言を書き換えたときだけハッシュ値が変わり、再び確認対象に戻る設計にしたことで、**「新しい記述だけをピンポイントで確認する」**という理想的な運用が実現しました。
任せられたこと、人に残ったこと
品質管理エージェントの導入によって、私の作業はどう変わったのか。
AI・スクリプトに任せられたこと（手放した作業）
- 本文文字数（1,500文字以上）の常時カウントと足切り判定
- 内部リンクのURL形式・重複・本数（2〜12本）の機械的検証
- タイトルにおける検索キーワード含有の有無チェック
- 一次体験を主張している段落の自動リストアップ
- 過去に確認済みの記述の記憶と差分検出
人間に残ったこと（手放してはいけない判断）
- 体験談の真実性の保証:
- 「本当に自分で体験した一次情報か」「数字に嘘や誇張はないか」の裏付け確認
- クライアントの守秘義務・匿名化のジャッジ:
- 社名や特定可能な業界用語・プロジェクト固有の数字が漏れていないかの最終判断
- 公開のGOサイン（status: publish）:
- スクリプトがどれだけ「100点満点」を出しても、本番へ一般公開する操作だけは人間がwp-adminから手動で行う規定の遵守
まとめ
- 機械判定と人間判断を分ける: 文字数やリンクなどの形式チェックはスクリプトに100%任せ、人間は一次体験と守秘義務の確認だけに集中する。
- 足切りルールで品質事故を防ぐ: 1,500文字未満や内部リンク不足など、SEO上致命的な欠陥はスクリプトの exit code で物理的にブロックする。
- 誤検出とアラート疲れを設計で防ぐ: 判定辞書の継続的なアップデートと、ハッシュ値による「確認済み記憶台帳」で、人間の集中力をすり減らさない。
- 公開ボタンは人間が押す: 自動化の究極の目的は全自動で垂れ流すことではなく、「人間が最も責任を持つべき判断に100%の時間を使える状態を作ること」。
次回は、これまでに登場した制作・品質管理・分析の各エージェントを連携させ、1人のまま複数事業を回し続ける「エージェント間連携と自律稼働ループ」の全体設計を公開します。
