100%コードをClaude Codeが書いて、一通りの機能実装をしてリリースしてみた話です（ブログ公開は許可取得済み）。
最近はめっきりコードを自分で書きませんね。
かつてはJetbrainも愛用してましたが、大昔に解約済みです。
VSCodeも正直いらないのですが、Markdownファイルのプレビューに使っているので手放せません。お気に入りのMarkdownプレビューアプリが見つかってしまったらアンイストールしたいと思います。
ちなみにブログはサボらず私自身が書いてます、文字を書くこと自体が楽しいのでその楽しさまでは奪われないようにしないと（？）
アプリケーションの本番実装をClaude Codeが100%書く
個人アプリやちょっとしたツールをClaude Codeが全部書くのはもう通常営業なのでよいとして、かつて本番運用しているアプリケーションをClaude Codeがすべてを書くことにやや不安があった時期がありました。
皆さんお忘れでしょうが、2026年明けまでは「AIが全部を自律的に書くなんてありえん！」くらいは思っていたんですよ。
思い出して……このやりとりを……。AnthropicがClaude Codeを使って約一週間半でClaude Coworkを完成させたやつです。
How much of it did Claude Code write? https://t.co/OQHfuvyr71
— Alex Volkov (Thursd/AI) (@altryne) 2026年1月12日
僕はこの「All of it」に感動したんです。
ハーネスをつけることで本番運用に耐えられるコードをAI自身が実装できるんだという世界観を彼ら自身が見せてくれたと思います。
まだこの回答から2ヶ月程度しか経ってないことが衝撃です。
環境と状況
- Claude Codeを利用。モデルはOpus 4.5とOpus 4.6（2026年2月5日にリリースされた）
- レビュアーは人であるが、組織が導入しているGithub Copilotを利用したり、GitHub Actionsを経由したClaudeが行うケースもあった
- 自分では一切ファイル編集しない。VSCodeを開いてもMarkdownのプレビュー機能にとどまる
- 業務委託先の仕事であり、日中のすべての時間を使うことはできてない（もし全部使ってたらもっと早かったかも）
詳細分析
ここからはClaude Code自身にPRを検索してもらい、期間中のPRやコード数について調べてもらいました。 なお実装内容に関する細かい話はしません。
S3へのコンテンツアップロード機能を3ヶ月で構築した記録 — PR数・コード量・生産性を振り返る
はじめに
2026年1月から3月にかけて、プロダクトにS3へのコンテンツアップロード機能をゼロから構築しました。インフラ（Terraform）からバックエンド（Rails + Lambda）、フロントエンド（TypeScript）まで、フルスタックで実装した約3ヶ月間の開発記録を、PR数・コード行数・稼働時間のデータとともに振り返ります。
あわせて、同時期に取り組んでいたClaude Code（AIコーディングエージェント）の設定・カスタマイズに関するPRも別軸で集計しました。
何を作ったのか
ユーザーが画像やPDFをドラッグ＆ドロップでアップロードし、S3に保存・CloudFront経由で配信する機能です。アーキテクチャとしては以下のレイヤーに分かれます。
- インフラ層（Terraform） — S3バケット、CloudFront、API Gateway、Lambda、IAMポリシー
- 認証基盤 — JWT Authorizer（API Key方式から移行）、JWKSエンドポイント
- バックエンド（Rails + Lambda） — Presigned URL発行、アップロード/ダウンロード/削除コントローラー
- フロントエンド（TypeScript） — D&D/ペーストアップロードUI
集計方法
GitHub CLIの gh pr list --search を使い、S3・upload・JWT・Lambda 等のキーワードでマージ済みPRを横断検索しました。2つのリポジトリ（アプリケーション本体 + インフラ）を対象に、自分が作成したPRをフィルタリングし、重複を排除しています。
S3アップロード機能：全体サマリー
| 指標 | 値 |
|---|---|
| 合計PR数 | 24 PR |
| 追加行数 | 8,453行 |
| 削除行数 | 1,071行 |
| 純増行数 | 7,382行 |
| 期間 | 約3ヶ月 |
| 総稼働時間 | 129.5時間 |
| 1PRあたりの平均時間 | 5.4時間/PR |
リポジトリ別の内訳
| リポジトリ | PR数 | +行 | -行 | 純増 |
|---|---|---|---|---|
| インフラ（Terraform） | 8 | 577 | 331 | 246 |
| アプリケーション（Rails + Lambda + TS） | 16 | 7,876 | 740 | 7,136 |
| 合計 | 24 | 8,453 | 1,071 | 7,382 |
月次推移と生産性
月別の稼働時間を記録していたので、時間あたりの生産性も算出しました。
| 月 | 稼働時間 | PR数 | 純増行 | 行/時間 | フェーズ |
|---|---|---|---|---|---|
| 2026-01 | 32.5h | 7 | 2,854 | 87.8 | Lambda + JWT認証 |
| 2026-02 | 75h | 13 | 3,055 | 40.7 | Rails接続層 + 削除機能 |
| 2026-03 | 22h | 4 | 1,473 | 67.0 | フロントUI統合 |
| 合計 | 129.5h | 24 | 7,382 | 57.0 |
月次推移から読み取れること
1月が行/時間で最高効率（87.8行/h）でした。 Lambda Function本体とJWT認証基盤を32.5時間で構築。新規コードの書き下ろしが中心で、既存コードとの調整が少ないフェーズは速度が出ます。
2月は最低効率（40.7行/h）だが最大PR数（13 PR）。 Rails側の接続層は既存コードとの整合性、テスト、レビュー対応など「行数に現れない作業」が多い月でした。75時間という最大稼働がそれを裏付けています。
3月はPR数が最少（4 PR）だが効率は回復（67.0行/h）。 フロントUI統合フェーズでは、既に出来上がったバックエンド基盤の上に乗せる形なので、1PRあたりの粒度が大きくなりました。
全体を通して、インフラ → 認証基盤 → バックエンド → フロントエンド というボトムアップ構築の流れが月次推移にきれいに現れています。
別軸：Claude Code設定のPR集計
S3機能開発と並行して、Claude Code（AIコーディングエージェント）のプロジェクト設定にも投資していました。
| 指標 | 値 |
|---|---|
| PR数 | 11 PR |
| 追加行数 | 2,364行 |
| 削除行数 | 206行 |
| 純増行数 | 2,158行 |
主な内容は以下のとおりです。
- 初期環境設定・GitHub Workflow導入
- カスタムスキル（Git運用・worktree・コードレビュー・規約チェック）
- PreToolUse hookによる破壊的コマンドの防御
- チームエージェント定義（team-lead / reviewer / refactorer）とSupervisor分離アーキテクチャ
- MCP（Serena）セマンティック解析の統合
開発ツールの整備と機能開発を同時に進めたことで、後半の生産性に寄与した部分はあると思います。
両軸の合算
| 指標 | S3アップロード | Claude Code設定 | 合計 |
|---|---|---|---|
| PR数 | 24 | 11 | 35 |
| 追加行数 | 8,453 | 2,364 | 10,817 |
| 削除行数 | 1,071 | 206 | 1,277 |
| 純増行数 | 7,382 | 2,158 | 9,540 |
おわりに
「S3アップロード」という一つの機能を切り口にPRを集計してみると、インフラ構築から認証基盤、バックエンド、フロントUIまでの積み上げ過程が可視化できました。
特に印象的だったのは、行/時間の効率がレイヤーによって大きく異なること。新規書き下ろしが中心の1月は87.8行/hだったのに対し、既存コードとの統合やテスト・レビュー対応が増える2月は40.7行/hまで下がりました。「生産性」を行数だけで測ることの限界が、自分のデータからもはっきり見えた結果でした。
補足と感想
実装はClaude Codeが全て行いましたが、その手前の実装計画や都度判断はまだ人が介入していました。レビューも同様です。
あくまでコードを書く仕事を移譲すること自体は2026/03/15時点で可能ということが十分にわかります。物量で人間が勝てる気もしないです。
今後の課題としては、
- 実装方針が正しいか・致命的な実装がないか、などの確認はAI自身がループして行ったが、果たしてそれで良いのか？は最終的に人間が確認する時間が必要だったこと
- フロントエンドのテストが手動だったために一番時間がかかってしまったこと
- レビューに人を介すること
これらを解決することでもう少しスピードが出そうだなと思います。
ただしレビューの多くを人間がやるのはもう厳しいかもという体感です。私も業務委託なので常に見ていられるわけではないですし、もうAI同士がPRを作ってPRを分析してレビューしておいてほしいです。
それで、いっちゃんいい状態のものを人間が見て、Mergeボタン押させてほしい。それくらいレビューやテストがボトルネックに感じました。
実装計画の流れ
いきなりすべてを書いてもらうことは絶対にありません。まずはissue、そして実装計画です。Claude Code自身にissueを書かせ、そこからissueを分離してもらいました。
2月くらいからAgent Teamsという並列実行が公式でresearch previewとして公開されたので、issueをもとにPRがバカスカ上がってくるように。
といいつつ、issueの内容が薄かったりテストが曖昧だとトンデモPRを上げてくるのでここで人間が必要でした。今ならもうちょっと違うやり方がありそうだが。
既存コードを修正するときは、先に「現在の実装を調査して、その結果をtmp/に配下に残しておいて」と指示して、PRを作るときに参照させていました。これをするだけで、「現在の実装を確認します」みたいなステップが省略されたのでよくやってます。
おわりに
とにかくAIをぶん回すことでしか得られない栄養と、ノウハウみたいなのがいっぱいあるんですが、ベストプラクティスなのかどうかわからない中やっています。 ベストプラクティス、探している間にベストが更新させるので今の時期は諦めたほうがいいと思っています。
とにかくAIを動かしていくぜという気持ちで毎日回していたら、3ヶ月で本番リリースできていたので、まじで面白い時代になりました。
そして、次のタスクが始まるのです。
