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 群)