はじめに：記事の品質は、書き始める前の大部分で決まる

これまで何本かブログ記事の自律執筆パイプラインを作ってきて、体感としてひとつ確信していることがあります。記事の品質は、実際に本文を書き始める前の企画・設計の段階で、その大部分が決まってしまうということです。あくまで実測データに基づく数字ではなく、経験則としての体感ですが、下準備が甘いまま執筆に入った記事は、後からどれだけ推敲しても最後まで直しきれません。

そこで今回、既存のブログ執筆パイプライン（企画→設計→執筆→校閲）の「設計」と「執筆」の間に、もう一段レビューを挟むことにしました。設計書（design.md）に書かれた事実や技術的な主張を、執筆に入る前に見直す /blog-verify というステージです。

見直しをせずに提出をしたい人はいないはずです

人間は、答案用紙をすべて埋めた後、そのままでは提出しません。見直しをして、書き間違いや論理の飛躍がないかを確認してから出すはずです。AIによる執筆も、本質的には同じだと考えています。見直し工程が薄いパイプラインは、答案を見直さずに提出するのに近いリスクを抱えています。

これまでの執筆パイプラインにも、校閲工程自体は存在していました。しかしその中身は、表記揺れや誤字脱字、そして過去記事との重複度チェックが中心で、設計段階の事実や主張そのものの妥当性を見直す工程は含まれていませんでした。文章としての体裁は整えられても、「その主張は本当に正しいのか」「その言い回しは反証可能な具体性を持っているか」までは検証されていなかったのです。

同じ自分が見直しても、同じ見落としをしやすい

では、執筆前の設計書をAI自身に見直させればよいのかというと、話はそう単純ではありません。AIが自分の出力を、同じ会話のコンテキストを保ったまま見直す場合、その直前までの前提（なぜその主張をそう書いたか）を引きずったまま読んでしまい、見落としが再現されやすいと考えています。これも実測データに基づく主張ではなく、あくまでこの設計の前提としている仮説です。

人間が「一晩置いてから読み返す」「他人に見てもらう」ことで精度が上がるのと同じ発想で、AIでも会話履歴を持たない状態でサブエージェントを新規に起動し、それまでの経緯を一切知らない状態で見返させることには意味があると考えました。サブエージェントは、呼び出し元の会話の記憶を持たずに起動される、という技術的な前提のもとに新しい文脈で対象を読みます。本記事ではこれを、便宜的に「別人格に見返してもらう」と呼んでいますが、実体としては同一のモデルであり、人間同士の他者チェックとは独立性の質が異なる点には注意が必要です。それでも、直前の文脈を引きずらずに読み直せるという一点だけでも、見直しの精度を上げる余地があります。

具体的には、/blog-design と /blog-write の間に /blog-verify <slug> というステージを新設しました。設計書（design.md）の事実・技術的主張を、独立したサブエージェントに読ませてレビューさせる仕組みです。

さらに一歩、「必ず間違いがある」という前提でレビューさせる

ただ見直しをさせるだけでなく、レビュー役には「性善説」ではなく「必ず誤りがある」という懐疑的な前提を与えることにしました。曖昧で反証不可能な言い回しでごまかしていないか、技術的主張として誇張や不正確さがないか、そして企画書（plan.md）の狙いやペルソナと矛盾していないかを、懐疑的な読者の視点で洗い出させます。指摘は 進行可 か 要修正 の判定として verify.md に記録され、この判定は最終的に人間ではなくClaude自身が指摘の重要度を評価して下します。

この効果（「懐疑的な前提を与えると指摘の解像度が上がる」）についても、断定はせず、そう考えて設計した仮説として扱っています。実際、この記事自体の設計書も /blog-verify にかけたところ、1回目・2回目・3回目の検証でいずれも「要修正」の判定を受け、指摘に基づいて設計書を3回書き直した上で、4回目の検証でようやく「進行可」の判定になりました。指摘の内容は、見出しに残っていた「8割」という数値が実測データのように読めてしまう点や、「別人格」という比喩と技術的な実態のズレ、既存パイプラインの校閲工程の説明が裏取りされていない点などです。これは狙って作った筋書きではなく、実際の検証プロセスでそのまま起きた結果です。ちなみに、この結果は「レビューが機能した証拠」であると同時に、当初の設計書自体の詰めが甘かったことの証拠でもあります。一発で通過していたら「レビューが機能しなかった」のではなく「設計が最初から十分だった」可能性も残るため、この自己言及的な実例だけをもって効果を証明したとまでは言えない、という限界も併記しておきます。

「戻れない」を仕組みにする：ハードゲート

レビューのステージを挟んだだけでは、都合よくスキップされてしまうリスクが残ります。急いでいるときほど、「今回はいいか」と見直しを飛ばしたくなるのは、人間もAIも同じです。

そこで /blog-write 側に、verify.md が存在すること、そしてその判定行が **判定: 進行可** と一言一句一致していることを確認するハードゲートを追加しました。/blog-verify を経ていない、あるいは「要修正」のまま放置された設計書では、執筆フェーズそのものに進めない構造です。レビューを「推奨される工程」ではなく「迂回できない工程」として組み込んだことになります。

まとめ：品質保証は、性善説では設計しない

今回の変更を通じて伝えたかったのは、AIも人間と同じく見直しが必要であり、その見直し役は同一コンテキストの自分よりも、コンテキストを持たない別の視点であるほど機能しやすい、という考え方です。そして、その見直しに懐疑的な前提を与えることと、それを気合いや運用ルールではなく仕組み（ハードゲート）として組み込むことの両方が揃って初めて、実効性のある品質保証になります。

これはブログ執筆に限った話ではありません。AIにレビューを任せる場面全般で、「性善説でお願いする」のではなく「必ず間違いがあるという前提で検証させ、その検証を迂回できない構造にする」という設計は、そのまま応用できる考え方だと思います。

私は、品質とプロセス設計に一切妥協しないシステムエンジニアリングを提供しています。AIを活用した高度な業務自動化や、堅牢なシステム設計に関心がある方は、ぜひコンタクトフォーム、またはSNSからお気軽にご相談ください。