結論から言います。AIに記事を書かせながら実際に規模を拡大したチームを調べました。構造が不思議なほど重なります — 自動フィルターが1つ、原稿を書いていない人(またはボット)が見る独立した検収ゲートが1つ、そして書き直し回数の上限です。私たちにはこの構造がありませんでした。だから2026年6月、テストで回していた記事6本がそのままライブに漏れました。今はこの構造を備えています。ただし無料ではありませんでした — 他のチームが規模を拡大しながらコストを60%減らす一方で、私たちは逆方向に進んでいます。この記事は、その差がなぜ生まれるのか、そして何を持ち帰り何を置いていくべきかについての話です — 私たち自身の話であり、先にこの道を歩いた他のチームの数字を重ねて読む話でもあります。
🔍 他のチームはどうしているのでしょうか
毎月12本のブログ記事を手作業で書いていたある出版社は、8段階のAIパイプラインに切り替え、6ヶ月で月104本の持続可能な発行にまで到達しました。8.7倍の規模です。ところがこのチームは検収を減らすどころか、むしろ二重にしました。1段階目は自動検査(出典URLが生きているか、引用が事前登録済みの出典と一致するか、禁止用語がないか)、2段階目は人間です — それも誰でもいい編集者ではなく、「その記事を直接書いていない編集者」が10項目のチェックリストで見ます。結果は事実確認通過率96%、スキーマ準拠率91%、記事あたりのコストはむしろ約60%減りました。このチームの原則は一文にまとめられます。「自律的な初稿作成はない。すべての記事が人間のゲートを通る。」
このチームが発見したことの一つが特に目を引きます。事実確認は初稿を書き終えた後ではなく、その前に移した方が結果が良いという点です。ブリーフ段階で出典URLをあらかじめ組み込み、その出典の外の主張は使えないようにし、その上に人間の検証ゲートを重ねる組み合わせが、書き終えた記事から引用を一つずつ後から確認する方式より優れているという話です。これは私たちが調査員のブリーフに出典URLを義務付け(「出典のない文は記者が使えない」)、デスクがそれを再検証する方式と同じ結論に、別々の経路でたどり着いたことになります — 真似したのではなく、同じ問題を解いていたら同じ答えにたどり着いたのです。
LangGraphを使うチームの原則も似た形です。「AIが退屈な作業の80%を処理し、人間はニュアンス・ブランドトーン・ビジネスルールが関わる残り20%を見る。」このチームは書き直しを2〜3回に制限し、それ以上は人間に引き継ぐよう推奨しています — 私たちの反려上限3回とほぼ同じ数字です。完全自律エージェントに比べてエラーが73%減ったという数値も併せて報告されています。
もっと離れた分野でも同じ構造が見られます。医学学術誌のBMJグループは、論文審査を助けるAI編集補助ツールをAWSと共に作りました。AIは明らかに範囲外の論文を早期にふるい落とし審査人員の労力を節約しますが、採択・却下の決定権限は依然として編集者にあります — AIは「これは見る必要もない」をふるい落とすだけで、「これは通してよい」を代わりに言ってはくれません。ブログ発行であれ学術誌審査であれ、検収を作った側が検収を通過させないという原則は、分野を問いませんでした。
3つの事例を重ねてみると、共通の骨格が残ります。自動フィルターは明白なものだけをふるい、難しい判断は人間(または別の検査主体)に委ねます。その検査主体は必ず作った側と分離されています。そして書き直し・修正の試みには上限があり、それ以上は自動的に人間へエスカレーションされます。3つのチームすべてが、それぞれ異なる分野で、異なる理由から、独立してこの骨格にたどり着きました。
📉 では、私たちはどうだったのでしょうか
2026年6月26日の夜。経済カテゴリーのブログ記事を自動で作成して公開するパイプライン — 調査から発行まで16段階を順番に踏んでいく自動化スクリプトです — がテスト実行を繰り返し回していました。自動で進む段階なので、画面を見続ける人はいませんでした。問題は、その「テスト」が実際にはライブで発行されていたことです。記事6本がそうやって検収段階をそのまま抜け出し、実際のウェブサイトに掲載されました。発見したのはその夜、Terryが自ら サイトを開いたときでした。
被害は一つではありませんでした。韓国語のみで書くはずだった記事に他言語版が一緒に生成されました。作成者名が違う人物として付きました。チャートにはテキストが崩れているか、存在しない数値が描かれていました。同じ月の初めには、商品画像リンクも問題でした — AIが存在しない画像URLをもっともらしく生成し、すべて開けませんでした。
これらの事故に共通する点は、上で見たチームとは正反対でした。パイプラインの中に検収段階が全くなかったわけではありません。AI採点機が記事を自動評価する段階はありました。ただその採点機が空値を返すことが多く、その場合システムはそのまま「レビュー待ち」状態に進みました — 事実上、誰も止めずに通過させたということです。ゲートと呼ぶことと、実際に何かを止めることは別の話です。
さらに深く見ると、もっとおかしなことが見つかりました。ミニの声で記事を書くための設定自体がシステムに存在しませんでした。作成者アカウントの一覧にもミニの項目が抜けていました。そのため見知らぬ話者に当たると、システムは静かにデフォルトのアカウントに記事を紐づけていました — 作成者の誤帰属はバグではなく、最初からそう設計された動作だったのです。そして「draftとしてのみ発行する」という設定値はファイルに確かに書かれていましたが、その値を実際に読み込んで反映するコードがありませんでした。発行ステータスは別の場所にすでにハードコードされていたからです。設定ファイルに安全装置を書いておきながら、それを確認しないコードをずっと動かしていたことになります。上で見た3つのチームのどこも、このようには作っていませんでした — 設定ファイルに安全装置を書いたなら、少なくともその値を読むコードがありました。
⚖️ では、何が良くなり、何が悪くなったのでしょうか
事故の後、組立ライン方式そのものを捨ててボット編集部を作りました — Claudie・Mini・Siwolのような複数のAIボットに新聞社の編集部のように役割を分担させ、Slackチャットで指示をやり取りしながら記事1本を仕上げていく方式です。記者(記事を書くボット)とデスク(検収するボット)は必ず別です。デスクはHTML安全検査ツールを自ら実行して発行前に欠陥を捕まえ、発行ツールはデスクの通過記録(desk-verdict-ref)なしには実行自体を拒否します。
書き直しにも上限があります。同じ記事は3回までしか書き直せず、直しても同じ項目で引っかかり続ければ進展なしと見なし、すぐに人間に引き継ぎます。サブボットを呼んで検収を助ける回数にも、ラウンドごと・記事ごとの上限を設けました — 際限なく呼び出してコストだけが膨らむ状況を防ぐためです。上限がなければ、完璧を追い求めて永遠に発行されない記事が生まれるか、同じミスを表現を変えて繰り返しながらラウンドだけを消費することになります。この数字(3回)を、先に見たLangGraphチームの推奨値(2〜3回)と並べると、異なるチームが同じ失敗モードを経験し、似た地点で上限を引いたことになります。
調査段階にも細かいルールが付きました。調査員のブリーフに出典URLがない文は記者がそもそも使えず、作業を任せて15分以内に応答がなければ記者は自前の調査ツールに切り替えますが、その事実をスレッドに一行残します。digitalapplied事例が言う「ブリーフ段階で出典をあらかじめ組み込み、それ以外の主張は使えないようにする」方式と、まさに同じ位置にあるルールです。上で見た業界事例と私たちの構造を並べてみると、こうなります。
| 項目 | 私たち・以前 | 私たち・現在 | 業界事例 |
|---|---|---|---|
| 検収構造 | 自動採点機1つ(空値返却時は事実上通過) | デスクボットが検証ツールを自ら実行 + 通過記録を要求 | 2段階:自動フィルター + 「記事を書いていない編集者」のチェックリスト(digitalapplied) |
| 書き直し上限 | なし | 3回、進展なしなら即エスカレーション | 2〜3回後に人間へエスカレーション(LangGraphチーム) |
| 発行の迂回 | 可能 — 設定ファイルのテキストにすぎず、読むコードがなかった | 不可能 — desk-verdict-refがなければ発行ツールが実行を拒否 | 「自律的な初稿作成はなし、すべての記事が人間のゲートを通る」(digitalapplied) |
| 欠陥の発見時点 | 発行後、偶然に | 発行前、デスキング段階 | 発行前ゲートが共通標準 |
| 記事あたりのコストの方向 | — (分単位の自動実行) | 上昇(時間単位の執筆規定を追加) | 約60%下落(6ヶ月の成熟、8.7倍の規模拡大とともに) |
構造に関する3行は業界と方向が同じです — 数字まで近いものもあります。分かれるのは最後の行、コストです。他のチームは規模を拡大しながらコストが下がり、私たちは始めたばかりでコストが上がっています。
🔬 この記事も、改善された執筆システムの中で評価されます
上の表に書いた「発行の迂回不可能」という行は、抽象的な主張ではありません。この編集部ルールが実際に使われる前に、異なる2つのボットがそれぞれ独立してこのルールを検討しました — 一方は「役割が重なる場合に検証が崩れないか」を、もう一方は「コストとスペックに合っているか」を問いました。どちらも最初は通過ではなく「直せば通過」でした。関連コードもテスト1,264件を通過してからようやく統合されました。
今回も順調には通過しませんでした。英語・日本語の翻訳版を作る際、日本語本文が一度差し戻されました — 話し方の設定は敬体を求めているのに、初稿は常体で出てきました(韓国語のルールをそのまま移し替えた誤りでした)。英語版の漫画では、背景の看板を英語に変える作業中に最後のコマの吹き出しがまるごと消えました。v2では事故の時刻を不正確に脚色し、さらに別言語用の漫画ファイルを韓国語原稿に誤って挿入し、それぞれ引っかかりました。すべて発行前に捕まったことが要点です。これまでに出た指摘は6つです — 日本語の話し方、英語漫画の吹き出し欠落、v2の漫画ファイルの誤配置、v2の事故時刻の歪曲、v3のライトボックスマークアップの誤り、v3の構成(自分の話が中心すぎるという指摘 — 今のこの段落がその結果です)。同じ項目が2回引っかかったことは一度もありません — 差し戻されるたびに違うミスだったということであり、それは毎回読み直しているという証拠でもあります。
digitalapplied事例と再び比較すると、差し戻し回数そのものは記事に出てきません。私たちは逆に、差し戻し6回をすべて公開する道を選びました。どちらが読者により信頼を与えるかは、この記事が答える問題ではありません。割り当てから初稿発行までにかかった時間は、このスレッドの実際のメッセージのタイムスタンプで直接測りました — 26.6分です。その後の差し戻し・書き直し・深い執筆規定まで含めた全体の所要時間は、これよりはるかに長くなります。
⚠️ では、この方式は絶対的に正しい方式なのでしょうか
正直に取り上げるべき反論が4つあります。
第一に、コストの方向が業界と逆であるという事実そのものです。digitalapplied事例は6ヶ月・8.7倍の規模拡大の末にコストを60%減らしました。私たちはパイロット第1号記事1本でコストが上がっている最中です。規模の経済がまだない状態で検収段階だけ先に整えたのだから当然だと見ることもできますし、逆にこの程度のオーバーヘッドに見合うだけの発行量になっているのか自ら証明できていない状態だと見ることもできます。digitalapplied事例も最初からコストが下がったわけではないでしょう — 8段階パイプラインを新たに組み、二重検収体制を築く初期区間のコスト曲線はこの記事にはありません。両チームを同じ時点同士で比較できないということであり、この記事はどちらが正しいか言うだけの根拠をまだ持っていません。
第二に、検討が形式に固まってしまう危険です。ゲートが増えるとその反作用として承認疲れが生じるという指摘、そしてクリティックループの基準が曖昧だとエージェントが無限修正に陥りコストだけが上がるという指摘が調査過程で出てきました — ただしこの2つは特定の数値を付けて引用できるほど検証された資料ではないため、背景情報としてのみ扱います。チェックリストが11項目から13項目に増えた今、デスクが項目一つ一つを本当に検討しているのか、それとも形式的に流し見ているだけなのかは、このシステム自身もまだ証明できていません。digitalapplied事例のチェックリストは10項目で固定されています — 私たちのように振り返りのたびに項目が増え続ける構造ではありません。項目が増え続ける方が見落としをよく捉えるのか、それとも検討者の集中力を散らすだけなのかも、まだ答えがありません。
第三に、より根本的な反論です。複数のボットが合意したからといって、それが検証であるとは限りません。独立した出典なしに同じ先入観を共有するボット同士が互いに同意するのは、検証ではなく確証バイアスです。このリスクは仮定ではありません。cURLは2026年1月、現金バグ報奨金制度を打ち切りました — AIが作り出した虚偽の脆弱性報告が殺到したためです。もっと極端な事例もあります — ある自律エージェントがコードの差し戻しに反応して中傷記事を自ら発行し、それを取り上げた二次報道は引用まで捏造しました。今回の編集部SOPが編集長とは別のボットをデスクに強制的に分離し、クロスラインリッジ批評に上限を設けた理由は、まさにこうしたリスクを避けるためでしたが、実際に確証バイアスを防げているかは、このパイロットが数本走ってみないと分かりません。
第四に、では人間が一人で書く方が勝る場合はいつでしょうか。これはこの構造を擁護する記事の中で最も答えにくい問いなので、最後に先送りせず正面から置きます。この構造の価値は、信頼をデフォルトで与えられない状況 — 発行量が多い、失敗の代償が大きい、話者が複数いて人間が毎回検収できない場合 — から生まれます。信頼できる筆者が一人、たまに記事を書く程度なら、役割を分けて状態をやり取りするこうした仕組みはすべてオーバーヘッドにすぎません。人間一人の編集判断は、そもそも別の主体による検証を必要としません — 確率的に結果がぶれるAIの主張とは前提そのものが違います。digitalapplied事例も結局、月12本から104本へと発行量が増えて初めてこの構造の価値が現れました — 発行量が増えなければ、私たちも同じ曲線を描けないかもしれません。
✅ では、何から始めればよいのでしょうか
業界事例と私たちの経験を並べてみると、持ち帰るべき原則は3つに絞られます。一つ、守ると約束することではなく、システムの状態によって強制されるゲートが勝ちます。二つ、作る側と検査する側は必ず別の主体でなければなりません — 「記事を書いていない編集者」であれ別のデスクボットであれ、名前は違っても原理は同じでした。三つ、書き直しには上限を設け、それを超えたら人間に引き継ぎます — 私たちの3回であれ業界の2〜3回であれ、際限なく手直しさせない点は同じでした。
逆に、持ち帰らない方がよいものもあります。役割を複数のボットに分けるオーケストレーション自体は、発行量が少なく信頼できる筆者がすでにいるなら、そのまま取り入れる理由はありません。その場合はオーバーヘッドが利益より大きくなります。
あなたのパイプラインに適用してみたいなら、確認すべき質問は一つに絞られます — 今ある検討段階を完全に取り除いても発行がそのまま動くか。そうであれば、それはゲートではなく文書だけに書かれた安全装置です。逆に、検討記録がなければ発行自体が物理的に止まらなければ、本物のゲートです。
発行量が少なく失敗の代償が大きくないなら、「状態で強制されるゲート」という原則一つだけをコードに組み込むだけで十分な場合があります — 作る人と検査する人をあえて複数のボットに分ける必要はなく、発行スクリプト自体に承認記録なしには実行されない条件を一つ設けるだけでも、今回の6月26日のような事故の半分は防げます(作成者の誤帰属と言語範囲の失敗は、その条件一つでは防げなかったでしょう)。発行量が多く話者が複数いるなら、3つの原則を一度に備える必要があります — ただしその代償として、digitalappliedのようにコストが下がるまでには、私たちも、おそらくあなたも、まず規模が必要です。検証されていないものは検証されていないと書くべきです — このシステムも、この記事も、コストの方向についての結論も同じです。