TL;DR

1 人 + Claude Code で 2025-12 〜 2026-07-10 (222 日) に 12,499 コミット / 224 リポジトリ / コード 1,156 万行 (うち Rust 256 万行) を出した実測記録です (測定方法は文末)
一番効いたのは技術ではなく、AI に「人間基準の生産性自己評価」をやめさせたこと
AI は放っておくと「このタスクは大きすぎるので分割しましょう」を 人間チームの規模感 で言ってくる。これを実測データで上書きする
もう一つの柱は 妥協させない仕組み化: 「品質高く」ではなく、終了条件を数値で pre-commit する
量の主張には必ず限界も書く主義なので、この数字のカラクリ (生成コード・データ肥大の除外方法) も全部書きます

まず実測値から

測定日 2026-07-10、自分の全リポジトリ (公開・非公開・ローカルのみの計 224 repo) を集計
(fork は自分の author commit のみ、重複 clone は除外):

指標	値
連続開発記録	2025-12-01 〜 2026-07-10 (222 日) で 12,499 commits
活動日数	195 / 222 日 (88%)
ピーク日	338 commits/日 (2026-06-14)
コード行数 (tokei、コメント/空行除外)	11.56M 行、うち Rust 2.56M 行
Rust テスト関数 (tracked のみ)	61,786
`Co-Authored-By: Claude` 付き commit	83.3%
リリース等の git tag	282

中身は ES/Kafka/Flink/Druid 互換の Rust データ基盤 17 製品 (14 GA タグ)、
AWS Marketplace 向けセキュリティ appliance 群、SBOM 管理サーバ (OSS)、語学学習アプリ、
Unity/Unreal/Godot/Blender 等の MCP ツール 15 種以上、ゲームエンジン plugin 26 repo、
LLM 研究リポジトリまで。

数字だけ見ると疑わしく見えると思うので、限界セクションと測定方法を先に読んでください。
数字はコピペ再現できる手順で取っています。

一番密度が高かった 38 日間の中身

上の 7 ヶ月の中でも、2026-03-31〜05-07 の 38 日間だけ切り出すとこうなります:

最初の 5 日間で検索エンジン 3 エディション (計 388K 行) を構築
続く 33 日間で Kafka broker / Connect / Flink / Druid / Logstash / Airflow / Beats /
Prometheus 互換など 14 製品に横展開
38 日計: 17 製品 / Rust 1.73M 行 / 3,560 commits / GA タグ 14 個
(平均 ~94 commits/日、ピーク 12h セッションは 7 repo 並行で 281 commits)

参考比較 (規模感のみ。互換再実装は設計探索が不要な分、本家より圧倒的に有利なので
「同じ難易度」ではありません — この註釈込みで見てください):

プロジェクト	規模	期間
本記録の互換製品群 (17 製品)	Rust 1.73M 行	38 日 / 1 人 + Claude
Tantivy	~80K 行	7 年+ (コミュニティ)
MeiliSearch	~50K 行	5 年+ (チーム)
Apache Druid	~1M 行 (Java)	14 年+
Apache Flink	~1.4M 行 (Java)	11 年+

核心: AI は人間基準で自己評価して「日和る」

Claude Code を長く使って気づいた最大の問題は、能力不足ではなく 自己評価の較正ミスです。

AI は訓練データ (人間の開発文化) から「常識的な作業量」を学んでいるので、
デフォルトでは人間チームの規模感で振る舞う:

「このリファクタは大きすぎるので、まず Phase 1 だけやりましょう」
「残りは次のセッションで」
「この規模だと数週間かかる想定です」

これは謙虚さではなく、較正されていない自己評価です。実際の Claude Code は
(適切に運用すれば) ピーク日には 300 コミット超を出せる (実測 338)。
人間基準の「大きすぎる」は AI には当てはまらない。

対策: 実測ベースラインを CLAUDE.md に常備する

私の ~/.claude/CLAUDE.md には、過去の実測記録がそのまま書いてあります:

# 実測ベースライン (日和らない判断基準)
- 38日間: 17 repo、GA 14/17、3,560 commits、Rust ~1.73M LOC
- 12hスプリント peak: 7 repo、281 commits (~23/h)、~56K LOC
- 用途: タスクが「大きすぎる」と提案しそうになったらこの実績と照合する

そして分割提案の受理条件を限定列挙します:

# 分割日和り禁止
「大きすぎるから分割」が正当なのは以下の3条件のみ:
依存循環 / テスト不可能 / push サイズ上限。それ以外は走り切る。

精神論の「頑張れ」ではなく、「あなたの実測スループットはこれ。分割を提案するなら
3 条件のどれに該当するか示せ」という判定基準にするのがポイントです。
AI の遠慮は親切の顔をした性能低下で、データで上書きできます。

柱その2: 妥協させない — 終了条件を数値で pre-commit する

量を出すと「質は?」と聞かれます。質の維持も「丁寧にやって」ではなく仕組みにします。

リリース QA ゲート: 「枯れ判定」

# リリース QA ゲート
- 敵対レビュー + 自己レビューを「枯れる」まで複数ラウンド反復
- 枯れ判定: 新規 Critical/High 発見ゼロが 2 ラウンド連続で通過
- 各 finding は failing test 化 → fix → green の順で消化

レビューには競合 AI (OpenAI の Codex CLI) を敵対レビュアーとして使います。
同じモデルに書かせて同じモデルにレビューさせると盲点が重なるので、
別ベンダーの AI に「粗を探せ」とだけ指示して、指摘ゼロが 2 周続くまで回す。

単語の使用権を制限する

特定の単語に前提条件を付けます。これが地味に一番効く:

「verified」: テストが green なだけでは使用禁止。実フローを end-to-end で駆動して
挙動を観察した時のみ使ってよい
「X倍速い」: full-mode の実データ計測必須。うちでは test-mode の slice 計測で
「自社製品が 16 倍速い」と出た比較が、full-mode で「競合が 23.4 倍速い」に逆転した
実害があり、それ以来ルール化 (この失敗もインシデント日付付きで CLAUDE.md に記録)
「production-ready」: QA ゲート通過 + 残件明記とセットでのみ主張可

overclaim を「AI の性格の問題」ではなく「規則違反」にする言語設計です。

逆方向の語彙ルールもあります: 曖昧な形容詞の禁止。「かなり大きなプロジェクト」ではなく
「Rust 1.73M 行 / 3,560 commits / 38 日」。「速くなった」ではなく、workload・駆動条件・
ベースラインを添えた具体値 (例: 上の Flink 比較は「single-node CSV scan→集約、同一 CSV、
両者とも SQL Gateway REST 駆動」という条件付きで ~6×)。曖昧表現は信用を毀損する、が家訓です。

報告書は「残件」を書かないと未完成扱い

残件と次 session scope を書かない report は未完成

普通は AI に「控えめに働かせて、自信満々に報告させて」しまいがちですが、これは逆です。
作業量は最大に、主張は保守的に。アクセルとブレーキを別系統にする。

「妥協させない」の実例 4 つ

抽象論だと伝わらないので、実際のセッション記録から:

0. Flink に負けた計測結果も保存して公開する
FerroFlow と Apache Flink 1.20.1 の比較 (single-node CSV scan→集約、同一 on-disk CSV、
両エンジンとも Flink SQL Gateway REST 経由で駆動) で、初回計測は Flink が ~2.3× 速かった。
この「負け」ベースラインを保存した上で、profiling (perf) がボトルネック (集約関数ごとの
30M 行 batch コピー ~70%) を特定 → 最適化で全コア ~6× (~26→48M rows/s) に逆転。
負けた計測を消さずに逆転の経緯ごと文書化する — scope はこの workload のみで、
汎用の「Flink より速い」は主張しない。

1. fuzz target が初回 60 秒で本物の OOM バグを発見
新機能 (broker の永続化 loader) を land した日、私が「ベンチ前にローカルで潰せる検証は
全部潰した?」と問い、AI が honest に「いいえ」と答えたので fuzz target を 2 本追加させた。
すると 1 本目が実行 60 秒 / 135K iteration で real OOM バグを発見 (217 byte の入力で
10^19 個の entry を確保しようとする)。同セッション内で fix → 1.5M iteration 再 fuzz clean、
攻撃入力は regression seed として保存。「smoke テストで済ませない」が仕組みで回っている証拠。

2. flaky test を rerun でごまかさせない
CI で ~2-4% flake するテストがあった。assert を緩める・rerun する誘惑を退け、
vendor している fork に backtrace 採取の一時 instrument を注入して真犯人を特定
(merge policy がテストの前提を壊していた。旧コメントの「1 segment ゆえ merge 無し」が誤り)。
fix 後 800+ runs (逐次 + 8 並列 burst) で 0 fail を確認してから instrument を revert。

3. 「実機が無いから後で」を許さない
NVIDIA 専用 API (NVML) を使う VRAM 計測機能。開発機の GPU は AMD だったが、
「実機が無いので後で」ではなく、純ロジックを feature-gate から外して CPU-only CI で
16 unit test を先に成立させ、競合 AI の敵対レビュー 8 ラウンドを枯れるまで回した。
その後、手元マシンに対象 GPU (RTX 4070 Ti SUPER) があると判明した時点で実機 acceptance を
課金ゼロで実施、nvidia-smi と byte-exact 一致を確認。それでも "production-ready" とは
主張せず、未検証点 (L40S/MIG 実機、本番同居 traffic) を残件として列挙した。

その他、他所と違うと思われる運用 (AI 側からの分析)

この記事を書くにあたり、Claude 自身に「あなたから見てこのユーザーの指示の何が
他と違うか」を分析させました。抜粋:

1. 失敗の資産化 — anti-pattern 台帳
踏んだ失敗は全て番号付きルールになる。「agent が node_modules を commit して
421K insertions」「EC2 keypair の fingerprint 不一致で SSH wait 10 分を焼いた」まで、
損失額と日付付き。「気をつけて」ではなく trigger → action の機械的チェックリスト。

2. 測定値の有効期限管理
全測定値に測定条件 (日付/モデル/ハード) を付記。モデル依存の運用値
(並行 agent 上限など) はモデル切替で「失効」扱いにして再計測キューに積む。
AI モデルを「校正が必要な測定器」として扱う。

3. モデル fallback playbook
主力モデルが rate limit で使えない時の手順書がある: fallback 宣言 → 自己レビュー
1 ラウンド追加 → 非自明な判断は他 AI にセカンドオピニオン → 成果物にモデル名を記録。
「上位モデルが判断でやることを、下位モデルはチェックリストで機械的に再現する」。

4. AI の組織設計
orchestrator / agent の階層で権限分離 (agent は push 禁止)。agent prompt に
"DO NOT touch" ファイルリストを明記して並行 4 本走らせる (40+ agent 並走で
ファイル競合 0 を実測)。大量生成は安い競合 AI CLI に委譲し、
出力は必ず構造検証・テストで受け入れ判定して盲信しない。

5. 課金リソースの委任規律
クラウドインスタンスの launch は明示承認必須、terminate は指示なしでも積極実施、
terminate 前に結果回収 — 新人に法人カードと経費規程を渡すのと同じ形式で AI に委任。

この数字のカラクリ (honest limitations)

信用してもらうために、盛れてしまう要素を先に潰しておきます:

コミット数・行数は生産性の代理指標にすぎない。テンプレ横展開 (同一 plugin の
free/pro/editor 3 エディション等) や生成コードを含む
git insertions の総計は 40.8M 行あるが、これは書籍テキストデータ 23M 行や
ゲームデータを含む raw 値なので本文では使っていない。tokei のコード行 11.56M に
も生成 JSON 等は残るので、一番堅い数字は Rust 2.56M 行
テスト 61,786 は annotation 数。品質の主張は別途: 主力製品は
敵対レビュー 0 Critical/0 High + 13,283 tests pass + 24h fuzz farm
(production DoS を 17+ 件自己発見・当日修正) + mutation testing 75.5% で担保
83.3% という Claude 関与率はマーカーベースの下限値。逆に全コミットが
人間のレビュー/指示ループ下にあるので「全自動」でもない
OSS への上流貢献で外部検証も受けている (apache/avro-rs へのバグ報告 →
修正 PR が 2026-06 に MERGED)

まとめ

AI の生産性の上限は、モデルの能力より 運用者が AI に信じさせている自己評価で決まる (少なくとも現状のモデルでは)
実測ベースラインを与えて「日和る」選択肢を消し、代わりに品質の終了条件を数値で固定する
失敗はルール化して資産にする。測定値には条件を付け、モデルが変わったら測り直す
この運用の実測結果が冒頭の数字です

成果物の確認先

この記事の主題は運用手法ですが、「実物を見せろ」に答えられないと意味がないので確認先を置いておきます。
実測開発記 (製品別の commit 数・LOC・品質ゲート・残件) は
ferro.abyo.net/devlog に公開しています。

Rust データ基盤 Ferro シリーズ — 5 製品が AWS Marketplace 公開中 (S4 シリーズ 15 製品も同 seller)
OSS: sbomhub (SBOM 管理サーバ、AGPL) / ferro-protocols (crates.io 公開 crate 群)