Claude Code 導入Before/Afterを数字で検証する — blog-agentsの3ヶ月

「変わった気がする」を数字で語ろう

Claude Codeを本格運用して3ヶ月が経った。よく「速くなった」「楽になった」と語られるが、体感には再現性がない。聞いた側には何も伝わらない。

本記事では、blog-agents の実ファイル・実ログをもとに、wc -l で誰でも確認できる数字だけで語る。Before は「Claude Code を使い始める前の状態（0の状態）」、After は「2026-05-20 時点の実測値」だ。

定性的な話——パイプラインが壊れた話や脱線したエピソード——はblog-agents実体験記事（2026/05/19）に譲る。この記事は数値検証の記録として書く。

ナレッジ蓄積：0行から3,021行へ

数字の変化が一番わかりやすいのはナレッジ層だった。

CLAUDE.md は 62行しかない。200行制限の約30%で、意図的に薄く保っている。ただしその下に 3,000行超の蓄積層がある。CLAUDE.md が「指示書」なら、knowledge/ は「組織の暗黙知を明文化したドキュメント群」だ。

この構造が「指示する道具」と「知識を持つ道具」の境界線になっている。Writerエージェントは毎回の執筆前に writer-lessons/general.md と feedback-log.md を読む。Tone-checkerは patterns.md の36パターンを参照してからレビューを始める。

ナレッジがなかった頃は、毎回「太字インラインヘッダーを使わないで」「三点列挙のまとめを避けて」と指示し直していた。同じ修正を繰り返すのは、ナレッジが蓄積されていない証拠だ。

knowledge/ の設計思想についてはknowledge/ 詳解記事に詳しく書いた。

自動化：Hookとログ累積125,047行

自動化の層も、数字にすると実感がわく。

PreToolUse Hookが全 tool呼び出しを記録する。80日で125,047行——1日あたり1,563行のペースで自動記録されている計算になる。

この記録は何に使うか。まず「承認したつもりがなかったコマンド」の事後検証ができる。Claude Codeが何を実行したかを後から確認できる監査ログとして機能する。

Stop Hookは、前回のStop以降に Δ20件以上のtool呼び出しがあった場合に通知する。「気づかないまま大量のファイルが書き換わっていた」という状況を防ぐ仕組みだ。

Before はすべて記憶頼りだった。「あのとき何をやったっけ」が追跡できなかった。Hookの詳細はHooks実例記事（80日ログ）でまとめている。

役割分離：サブエージェント6 / スキル6

パイプラインの構造変化は、このテーブルが一番わかりやすい。

Before は「ひとつのプロンプトに全部を詰める」スタイルだった。リサーチも執筆もトーンチェックも一度に依頼する。当然、品質にばらつきが出る。

After は責務が分離している。たとえばPlagiarismエージェントは執筆内容には関与せず、数値・引用・出典の検証だけに集中する。この専門化によって、5/19のワークフロー記事で「Agent Teams実験フラグの記述漏れ」を1件救出した。単一プロンプトでは見落としていた可能性が高い。

6つのカスタムスキルによって、よく使うパイプラインをコマンドとして定義している。/article-pipeline <テーマ> を呼ぶだけで全6ステップが順に動く設計だ。スキルの設計判断はSkill設計記事に書いた。

数値で見えない変化

ここからは実測ではなく、主観的な観察として書く。数値化が難しい変化を、数値化が難しいと明示した上で記録しておく。

変化を感じるのは、作業の「前提」が変わったことだ。5月の22本は全部「リサーチ→Auditorレビュー→Writer」という順で進めた。Before は手が動き始めてから方向が決まることが多かった。Planを立てる前に書き始める、という癖が減った。

/usage /cost を毎セッション確認する習慣もついた。Hookログを眺める頻度も上がった。「使っている」から「観測している」に変わった感覚がある。

もうひとつ染みついたのが「壊れる前提の設計」だ。researcherが2回脱線し、auditorがusage limitに達し、コスト数値が捏造で削除された。これらを経て、main agentがリカバリ役を担う構造が自然になった。エージェントを「信頼して任せる」のではなく「失敗するものとして設計する」ほうが、現実に近い。

Beforeに戻れない不可逆性

3,021行の knowledge/ を捨てて手動執筆に戻せるか。答えはノーだ。

2,402行の feedback-log.md は過去の全レビュー結果の集積だ。これを頭に入れたまま手動で品質を保つのは、現実的ではない。

Plagiarismチェックを毎回手動でやれば、1記事あたり1〜2時間が追加でかかる計算になる。Tone-checkerの34パターンを記憶ベースで網羅するのも難しい。

「ナレッジが育つほど元に戻れなくなる」という不可逆性が生まれている。これは Claude Code 単体の効能というより、Claude Code が積み上げてきた組織知の効能だ。Claude Code はトリガーに過ぎず、蓄積された知識構造そのものが資産になっている。

累計146本（4月124本 + 5月22本）という記事数も、このインフラなしには維持できない水準だ。

3ヶ月後の自分に問いを渡すとすれば、「knowledge/ が10,000行になったとき、何が変わるか」——それが今の関心事だ。

*内部リンク一覧*

• blog-agents実体験（エピソード）
• Hooks実例（80日ログ）
• knowledge/ 詳解（3,021行の内訳）
• Skill設計（6スキルの設計判断）