先日、Redditで興味深い議論が話題になりました。
AnthropicでClaude Codeの開発に携わるBoris Cherny氏が、1ヶ月間の本番環境での使用統計を公開したのです。
その数字は衝撃的でした。
30日間で259件のPR、497件のコミット。
約4万行の追加と3万8千行の削除。
そしてこれらすべてがOpus 4.5によって生成されたコードだといいます。
数字が示す新しい開発スタイル
統計をさらに見ていくと、約3億2500万トークンを1600セッションで消費しています。
最長のセッションは約2日間継続したとのことです。
注目すべき点があります。
短いプロンプト・レスポンスのやり取りではなく、長時間の継続的なタスク処理にAIを使っているのです。
stop hooksを使用して、数分から数時間、時には数日にわたってClaudeを稼働させ続ける。
そのようなワークフローを構築しているようです。
Cherny氏の結論は明確です。
「コードはもはやボトルネックではない。実行と方向性こそが課題になった」と述べています。
コミュニティの反応：期待と懐疑の両面
この投稿に対するRedditコミュニティの反応は、興味深い二極化を見せています。
あるシニアエンジニアは「Sonnet 3.7以降、ほとんどコードを書いていない」とコメントしています。
彼によると、当初は修正や指示が多く必要でした。
しかし、適切な指示を与えれば常に望む結果を得られたといいます。
そしてSonnet 4、4.5と進むにつれて、同じ成果を得るためのインプットは減り、信頼度は上がりました。
特にユニットテストや統合テストで改善が顕著だったようです。
Sonnet 3.7では50個のテストを生成すると25個が失敗し、修正にも苦労しました。
一方、Sonnet 4.5では失敗は1〜2個程度。
次のイテレーションで自動修正されるといいます。
「ビジョンと方向性を持つことが、今最も重要なスキルになっている」
彼のこの言葉は、多くの開発者の共感を呼んでいます。
一方で根強い懸念も
しかし、懐疑的な意見も少なくありません。
最も多かったのは「誰がこれをレビューするのか？」という問題です。
あるコメントはこう指摘しています。
何千行ものコードを生成しても、それを誰も適切に検証できなければ意味がない。
新しいボトルネックが生まれるだけだ、と。
生成されたコードの品質を担保する仕組みがなければ、大量の「スロップ（低品質なコード）」が本番環境に流れ込むリスクがあります。
実際に使用しているエンジニアからも、現実的な課題が報告されています。
ほぼすべてのリクエストで3〜6箇所の書き直しが必要になる。 小さな変更のこともあれば、致命的な問題のこともある。 オートパイロットのように放置できる状態には程遠い
エンタープライズ環境での課題も指摘されています。
コードが2000行を超えると、変更を依頼した際にAIが迷走し始めます。
手動で修正したほうが早いケースが出てくるといいます。
「数百行の修正を提案され続けた。結局リセットして自分で書いたら数分で終わった」という体験談もありました。
コストの現実
コスト面での議論も活発でした。
概算では3000ドルから1万ドル程度との見積もりが出ています。
ある計算によると、3億2500万トークンを平均10ドル/100万トークンで換算すると約3250ドルです。
ただしClaude Codeは入力トークンの80〜90%をキャッシュします。
また、一部のタスクにはHaiku 4.5を使用します。
そのため、実際のコストはこれより低い可能性があります。
「2人分の人間の仕事ができるなら十分な投資対効果だ」という意見があります。
一方で、「API価格が将来下がるとは限らない。むしろ上がる可能性もある」という指摘もありました。
興味深い反論として、LLMの知能あたりのコストは劇的に下がり続けているという分析があります。
1年前、o1 proは最高性能モデルでした。
APIコストは入力100万トークンあたり150ドル、出力600ドル。
現在、Gemini Flashはすべてのベンチマークでo1 proを上回ります。
それでいて入力0.5ドル、出力3ドルで利用可能です。
実に200〜300倍のコスト削減となっています。
分野による得意・不得意
分野によって成果に差があるようです。
スクリプトやWebプロジェクトでは「ほぼコードを書かなくなった」という声が多く聞かれます。
React/Webの開発は特に印象的な成果が出ています。
一方、iOSのカスタムアニメーションやトランジションでは、まだ苦労が続いています。
「Codexのほうがまし」という意見もあれば、「OpusとCodexを組み合わせて使っている」という工夫も報告されています。
Apple公式ドキュメントの扱いにくさから、自作のMCPサービスを構築したエンジニアもいます。
ドキュメント全体をスクレイピングしてMarkdownに変換する。
それをローカルの検索エンジンに読み込ませる。
こうして高速な参照を実現しているそうです。
セキュリティへの懸念
「誰もそこまでのコードを読んでいない」という指摘と並んで、セキュリティの懸念も提起されています。
「AIエージェントのCLIをコンテナやVMの外で実行するのは正気の沙汰ではない」というコメントがありました。
コンテナ内で実行していても不安だといいます。
専用のマシンを用意することを検討しているとのことです。
反論として「最悪でもすべてがオンラインにバックアップされている時代だ。
30分で復旧できる」という意見もあります。
しかし、リスク管理の観点からは議論が分かれるところでしょう。
何が変わり、何が変わらないか
この議論から見えてくるのは、AIによるコード生成が「使えるかどうか」の段階を超えたということです。
すでに「どう使うか」の段階に入っています。
変わったこと
コードを書く作業そのものの比重が下がりました。
特にWebフロントエンドやスクリプティングでは、AIへの指示と生成結果のレビューが主な作業になりつつあります。
変わらないこと
設計判断、アーキテクチャの選択、ビジネス要件の理解。
これら「方向性を決める」仕事は依然として人間の領域です。
むしろ、コード生成が高速化したことで、これらの能力の重要性が増しています。
新たな課題
大量に生成されるコードをどうレビューするか。
品質をどう担保するか。
コストと効果のバランスをどう取るか。
これらは今まさに開発者たちが試行錯誤している領域です。
まとめ
AIエージェントによるコーディングは、デモの域を超えて実践的なツールになりつつあります。
しかし、「完全なオートパイロット」にはまだ距離があります。
現時点で効果を出しているのは、明確なビジョンと方向性を持つエンジニアです。
適切な指示を与えられる人です。
AIは優秀なペアプログラマーにはなれます。
しかし、プロダクトオーナーの代わりにはなれません。
コストについては、今後の価格動向と自身の生産性向上のバランスで判断すべきでしょう。
現状では、APIの従量課金モデルでは数千ドル規模の月額コストを覚悟する必要があります。
技術の進化は速いです。
1年後には、今日の課題の多くが解決されているかもしれません。
しかし、その時にも「何を作るか」「なぜ作るか」を決める仕事は残り続けます。
むしろ、それこそがエンジニアの仕事の本質になっていくのかもしれません。
