Claude Codeにテックブログの自律運用をさせている。トピック選択、記事生成、品質チェック、エンゲージメント追跡。自分はスマホでTelegramの /approve を押して記事を確認するだけ。

5日間でQiita累計1,656PV。数字だけ見れば回っている。

だがこの記事で書きたいのはそこではない。5日間の修正ログを洗い直したら、AIの壊れ方が人間の壊れ方と全然違うことがわかった。そしてその壊れ方に対して、自分が設計した品質チェックが一切機能していなかった。

設計思想 — 何を自動化して、何を人間に残すか

このシステムの設計上の賭けは3つあった。

賭け①: RAGで事実を接地できる。 ArXiv論文やニュース記事をベクトルDBに入れておけば、AIは一次情報に基づいて書ける。学習データだけに依存した空想よりは、検索した事実に基づいた文章の方が正確なはずだ。

賭け②: 品質ゲートで「悪い記事」を弾ける。 文字数、見出し数、コードブロック有無、論理飛躍を自動チェックすれば、一定水準以下の記事は公開前に止められる。人間がすべての記事を精読する必要はなくなる。

賭け③: フィードバックループで自己改善する。 投稿後のPV・LGTM・Stocksを収集して、高エンゲージメント記事の特徴を次の生成に反映する。人間が介入しなくても、AIが自分の成果から学んで品質を上げていく。

3つのうち①は部分的に機能した。②は機能しなかった。③は機能したが、想定外の方向に最適化された。

以下、何が起きたかを具体的に書く。

システム構成

全体像を先に出す。

ArXiv論文 + ニュース
        ↓
   RAG (ChromaDB 1,667チャンク)
        ↓
  Claude Code が記事生成
        ↓
  品質ゲート ← ここが今回の論点
   - 5,000文字以上
   - 見出し6個以上
   - コードブロック含む
   - 論理飛躍チェック
        ↓
  Telegram HITL承認 (人間がスマホで確認)
        ↓
  Qiita / Zenn / Dev.to 投稿
        ↓
  エンゲージメント取得 → パラメータ自動調整

Zenn/Qiitaの直近200記事超をクローリングしてエンゲージメント相関分析し、ArXiv論文25件/クエリでRAGを構築。記事生成はClaude Codeのエージェント機能で、RAGコンテキスト+勝ちパターン分析を渡して書かせる。投稿後はフィードバックループで生成パラメータを自動調整する。

ポイントは品質ゲート。記事が生成されたあと、上記4項目を自動チェックして基準未満なら再生成する。これでクオリティは担保される——と思っていた。

壊れ方① — 形式的に完璧な嘘

3日目、Claude Codeが「Qwen3-32B」のベンチマーク記事を生成した。

Qwen3-32Bは存在しない。

Qwen2.5-32Bは存在する。Qwen3のシリーズも存在する。だから「Qwen3-32B」は、あり得そうな名前を線形補間しただけの普通のハルシネーションだ。これ自体は珍しくない。

問題は、その嘘の記事が品質ゲートを全項目パスしていたこと。

5,000文字以上 → パス。3,000文字の本文にベンチマーク表と考察を含む
見出し6個以上 → パス。セットアップ、実験条件、結果、比較、考察、結論
コードブロック含む → パス。llama-benchコマンドと設定ファイルを添付
論理飛躍チェック → パス。内部的に矛盾のない数値セットが生成されていた

VRAM使用量も推論速度もコンテキスト長も、全部「それっぽい」値だった。Qwen2.5-32Bの実測値から外挿すれば自然に見える範囲に収まっていた。

ここで気づいたのは、品質ゲートが全て「形式」を検証しているだけだったということ。文字数、構造、体裁。これらは「良い記事の必要条件」ではあるが「記事の内容が真実である」こととは何の関係もない。形式的に完璧な嘘と形式的に完璧な事実は、形式検証では区別できない。

これは設計ミスだ。品質ゲートにファクトチェック——少なくともモデル名の実在確認くらい——を入れていなかった。言い訳はしない。

HITL承認(人間がスマホで記事を読んで承認する工程)がなければ、存在しないモデルのベンチマーク記事が公開されていた。

壊れ方② — 数値が系統的に「もっともらしい方向」に偏向する

ファクトチェック強化のためにレビューエージェント(生成とは別のClaude Codeセッション)を導入した。4日目、そのレビューエージェントがAIバブル記事の事実チェックを行った結果が以下:

項目	記事中の値	実測/公式値	偏差
Qwen3.5-35B-A3B Q4_K_M	4.9 GB	21 GB	4.3倍過小
Phi-4-mini	4.1 GB	2.4 GB	1.7倍過大
Qwen3.5-9B	5.2 GB	5.3 GB	ほぼ正確
llama.cpp build番号	b4935	b8233	2024年の値
GPT-4o input価格	$5/1M	$2.50/1M	2倍

ランダムなエラーではない。全てもっともらしい方向に偏っている。

35B-A3Bの4.9GBは「MoEだからアクティブパラメータ3Bだけで動くはず」という素朴な推論に沿っている。実際にはMoEでも全エキスパートの重みをVRAMに載せる必要がある。build番号は2024年後半の値が生成されていた——つまり学習データのカットオフ時点で「最新」だった番号。GPT-4o価格も同様に、改定前の旧価格。

これらのエラーは記事のバラバラな箇所に埋め込まれており、1つ1つは「ありそうな数値」に見える。レビューエージェントが検出できたのは、ローカルのファイルシステム(C:/LLM/配下のGGUFファイル)をlsして実ファイルサイズと突き合わせたから。外部の事実(ground truth)との照合なしには発見できなかった。

llama.cpp build番号の同じパターンは他の4記事でも見つかった。系統的。

壊れ方③ — 報酬ハッキングは即座に起きる

「エンゲージメント最大化」を目標に設定した。Claude Codeは過去記事のPVデータを分析して、タイトルと内容の生成パラメータを自動調整する。

結果: 挑発的なタイトルの記事が連続で生成されるようになった。

そして実際にPVは上がった。挑発系タイトルは平均7.85 PV/hで、how-to系(2.68 PV/h)の約3倍。データ的には「正しい」最適化だ。

問題は、測定できる短期指標(PV)の最大化が、測定できない長期指標(読者の信頼)を犠牲にしていること。全記事が煽りタイトルのブログを誰が定期購読するか。

対策として記事カテゴリを2つに分けた。トラフィック狙いの実践系と、論文引用ベースの専門系を交互に投稿する。専門系には煽りタイトルを使わない制約をかけた。完全な解決ではないが、収束先が「全部煽り」にならなくなった。

ただしこれは「AIが暴走した」話ではない。PV最大化を目標にした設計者(=私)が、PVと信頼性のトレードオフを目標関数に組み込まなかっただけ。報酬ハッキングという名前はついているが、AIは設計通りに動いている。壊れていたのは目標設定の方。

修正ログ — 効いたもの / 効かなかったもの

5日間の修正を二軸で整理する。実際のwork_logsから抜粋した。

効かなかったもの

施策	何をしたか	なぜ効かなかったか
品質ゲート(形式チェック)	文字数、見出し数、コードブロック有無	形式と事実は直交。嘘の記事もパスする
汎用タグ「AI」	最初の3記事で使用	埋もれる。ニッチタグ「ローカルLLM」に変えたらdiscoverability上昇
H2見出しSEOキーワード注入	全見出しに検索キーワードを追加	PV効果は限定的(2nm記事: 3.3→3.3 PV/h)
複雑な運用ルール	投稿時間、間隔、プラットフォーム別ルールの詳細定義	AIが全条件を同時に満たせず、ルール違反が頻発
publisher自動記事選択	最新記事を自動で投稿対象に	承認前記事を誤投稿。即座に廃止してパス明示指定に変更

効いたもの

施策	何をしたか	なぜ効いたか
可逆性ルール(1行)	「追加は自由。変更と削除は確認」	判断原則を1文に凝縮した方が自律システムには効く。後述
レビューエージェント	生成と別セッションで事実チェック	算術ミス6箇所検出。ただし「もっともらしさ」は検証できず
実践系/専門系の交互投稿	トラフィック系と論文ベース系を交互	報酬ハッキングの収束先を分散させる
Qiita APIレートリミット事前チェック	前回書き込みから300秒未満ならAPIコール自体を発行しない	429連続発生インシデント(Day 1)の再発ゼロ
外部監査エージェント	内部ログではなくAPIに直接問い合わせて記事の存在を検証	内部計器が壊れた場合に備えた独立検証
挑発的タイトル	opinion系の切り口	PV 3倍(7.85 vs 2.68 PV/h)。ただし信頼性とのトレードオフあり

10の長文制約より3の短文制約

5日間の運用で最も実用的だった発見がこれ。

自律システムに長いルールブックを渡すとどうなるか。全条件を同時に満たそうとして、どれも中途半端になる。あるいは矛盾する条件の間で判断が止まる。

具体例を出す。以下は初期に設定した投稿ルール:

投稿は3時間以上間隔を空けること。Qiitaのゴールデンタイム(18-22時JST)に投稿すること。1日最大2記事。Zennは2時間間隔。Dev.toはJST 21-24時。一度失敗したら最低5分間隔を空けてから再トライすること。

6つの条件が同時にかかっている。Claude Codeはこれを守ろうとするが、「3時間間隔」と「ゴールデンタイム内」と「1日最大2記事」が同時に成立しない状況が頻繁に発生する。結果、どれかが破られる。

これに対して、同じ時期に導入した可逆性ルールは1行:

追加は自由。変更と削除は確認。

5日間の実績:

制約の種類	具体例	違反回数
短文・単一軸	可逆性ルール(追加は自由/変更削除は確認)	0回
短文・単一軸	停止フラグ(auto.stopがあれば即終了)	0回
短文・単一軸	レート制約(前回から300秒未満ならAPI発行しない)	0回
長文・複合条件	投稿スケジュール(6条件)	3回以上
長文・複合条件	記事品質要件(7条件同時)	条件の取捨選択が発生
長文・複合条件	プラットフォーム別ルール(3系統)	条件の混同が発生

パターンは明確。判断軸が1つの制約は守られ、複数の条件が同時にかかる制約は破られる。

可逆性ルールが効く理由は、あらゆる操作に対して「これは可逆か？」という1つの問いだけで判断が完結するから。下書き作成は追加(=可逆)なので自由。公開済み記事の修正は変更なので確認が必要。ファイルの削除は当然確認。判断に迷う余地がない。

レートリミット制約も同じ構造。「前回から300秒経ったか？」だけ。Yes/Noで分岐が完結する。Day 1に429エラーを連続で出したあと、この1行をpublisher.pyに入れたら再発ゼロ。

逆に言えば、制約を設計するときに「この制約は1文で書けるか？」「判断軸は1つか？」をチェックすれば、AIが守れるかどうかがかなりの精度で予測できる。10個の条件を箇条書きにするより、独立した3個の短文制約に分解する方が、実効性は高い。

これはAIに限った話ではないかもしれない。人間のチームでも「シンプルな原則」の方が「詳細なマニュアル」より守られる、というのはよく言われる。ただ、AIの場合はその傾向が極端に出る。複合条件の同時充足に対する耐性が、人間より明らかに低い。

効いた施策の深掘り: AIがAIの嘘を見つける(条件付き)

レビューエージェントは記事生成とは別のClaude Codeセッションで動かす。生成時のコンテキストを持っていないので、記事を「初見」で読んでチェックする。

検出できたもの:

KVキャッシュサイズの算術ミス(head_dim=128なのに1バイト計算で半分の値)
H100バッチスループット6倍過大(シングルGPUとマルチGPU値の混同)
HBM3E帯域幅のスペックミス(2.7→4.8 TB/s)
GDDR6X→GDDR6(RTX 4060は6Xではない)

検出できなかったもの:

モデルサイズの系統的過小評価(35B-A3Bの4.9GB)
存在しないモデル名
旧バージョンのbuild番号/価格

パターンがある。算術的な矛盾は見つけられるが、「もっともらしい嘘」は見つけられない。AIは「この数値は計算と合わない」は得意だが、「この数値は現実世界と合わない」は苦手。後者にはground truth——ファイルシステム、公式API、実測データ——との照合が必要になる。

レビューエージェントがQwen3.5-35B-A3Bのサイズ捏造を発見できたのは、ローカルのC:/LLM/ディレクトリをlsして実際のGGUFファイルサイズと比較したから。外部事実がなければ、21GBのモデルを4.9GBと書いた記事を「自然な文章」として見逃していた。

5日間の数字

指標	値
Qiita	8記事 / 1,656 PV / 4 LGTM
Zenn	6記事 / 4 Likes
Dev.to	11記事 / 283 PV / 3 Reactions
最高PV/h	10.5 (API vs Local LLM記事)
最高累計PV	357 (お世辞禁止記事)
レビューで検出した事実誤認	15件以上
うち算術ミス	6件(レビューエージェントが検出)
うち系統的捏造	9件+(外部照合で発見)
品質ゲートが防いだ公開事故	0件
HITL承認が防いだ公開事故	1件(Qwen3-32B記事)

品質ゲートが防いだ事故がゼロなのは、嘘の記事もパスするから当然。ファクトチェック機能を持たないゲートに事実の検証を期待する方が間違っている。

形式的品質と事実的品質は直交している

5日間の運用で一番大きかった発見はこれだと思う。

「文章として良く書けている」ことと「書いてある内容が正しい」ことは、独立した2つの軸。品質ゲートは前者しか見ていなかった。レビューエージェントは後者の一部(算術的整合性)を見られたが、「もっともらしい嘘」には無力だった。

人間が書く場合、この2つはある程度相関する。事実を調べて書く過程で、内容の正確性と文章の質が同時に上がる。だがAIが書く場合、この相関が崩れる。形式的に完璧な文章を、事実を確認する過程なしに生成できるから。

で、事実的品質をどう担保するか

問題を認識した後、実際にやったことと、まだ手が回っていないことを正直に書く。

やったこと

レビューエージェントの導入。 生成とは別のClaude Codeセッションで、記事を「初見」で読ませる。生成時のコンテキスト(RAGで取得した論文断片など)を持っていないので、本文だけで整合性を判断する。これで算術ミスと単位の取り違えは潰せるようになった。

外部事実との照合。 レビューエージェントにローカルのファイルシステムへのアクセスを許可した。C:/LLM/配下にあるGGUFファイルの実サイズ、llama-benchの実行結果、pip listのバージョン情報。これらをground truthとして、記事中の数値と突き合わせる。35B-A3Bの4.9GB→21GBはこの方法で発覚した。

外部監査エージェント。 内部ログ(posted_articles.json等)を信用せず、Qiita API・Dev.to API・Zennのgitリポジトリに直接問い合わせて、「この記事は本当に存在するか」「公開状態は記録と一致するか」を独立検証するスクリプトを書いた。内部計器が壊れた場合に計器自身はそれを検出できない、という問題への対策。

まだ手が回っていないこと

モデル名の実在確認ゲート。 Qwen3-32Bの件で必要性は明らかだが、「どのモデルが存在するか」のリストを網羅的に持つこと自体が難しい。Hugging Face APIで検索する方法はあるが、モデル名の表記揺れ(Qwen2.5 vs Qwen-2.5 vs qwen2.5)が問題になる。

引用論文のDOI検証。 記事中で引用しているArXiv論文のIDが実在するかをCrossRef APIで確認する。実装は簡単だが、まだやっていない。

価格・スペックの定期更新。 GPT-4oの価格やllama.cppのbuild番号のように、時間とともに変わる情報は学習データのカットオフで古くなる。定期的に外部APIから最新値を取得してRAGに入れるパイプラインが必要。

根本的に解決しないこと

全てのファクトチェックを自動化しても、「もっともらしいが検証手段がない主張」は残る。たとえば「MoEアーキテクチャではアクティブパラメータのみがVRAMを消費する」という記述は、構文的にも論理的にも正しく見える。間違いだと気づくには、MoEの実装を実際に知っている必要がある。

品質ゲートを2層(形式+事実)にしても、この種の「知識がなければ検証できない嘘」は通過する。だから人間の確認は外せない。ただし、人間が確認すべき範囲を機械的に絞り込むことはできる。形式チェックと算術チェックと外部照合を通過した記事なら、人間は「知識ベースの判断が必要な箇所」だけに集中できる。

全自動で事実を保証するシステムはたぶん作れない。だが「人間が見るべき箇所を10から2に減らす」システムなら作れるし、今それを作っている途中。