Claude Codeで感じたAIとソフトウェア開発の未来
先週、2月24日[1]にClaude Codeのresearch preview版がリリースされました。↓の動画では、Claude Codeによる次のような作業の様子が紹介されており、エキサイティングです。
- リポジトリの内容を理解して説明させる
- 追加機能を要求して実装させる
- ビルドおよびテストが通るまで試行錯誤させる
週末に時間が取れたので、早速Claude Codeを触ってみました。その結果、
- ソフトウェア開発の方法が大きく変わりそう
- AIエージェントを前提に自分が変わらなければならない
と感じたので、所感をまとめることにしました。
なお、まだリリースから日が浅く週末に触っただけなので、ファーストインプレッションであることにご留意ください。また、僕はこれまで他のAIエージェントによるソフトウェア開発の経験がないので、それらとの比較もできません。
AIのやり方に人間が歩み寄る
Claude Codeを使ってみてまず感じたのは、自分が思い描くものをそのまま作らせようとしてはダメだということです。
たとえば、プログラムの設計を例に考えてみましょう。仕様を元にどのように実装しようか、色々考えると頭の中にエレガントでイケてる設計が思い浮かびます。AIがそれをぱぱっとコードにしてくれれば最高です。しかし、それは落とし穴です。
- 自分の考えを正確にAIに伝えるには時間がかかる
- 正しく伝わらなかったときに、間違いを指摘してAIに理解させ、正しく修正させるにも時間がかかる
- そもそも、「エレガントでイケてる設計」を練るのにも時間がかかる
AIはすごいスピードで作業を進めることができるので、ボトルネックになるのは人間です。 そのため、上記のようなコミュニケーションや思考に時間をかけていると、AIの力を最大限に発揮することができません。ともすれば、最初から自分でやった方が速かったということにもなりかねません。
「エレガントでイケてる設計」を練るのも、ゼロベースで考えるよりもまずはAIにコードを書かせてみて、それをベースに改善案を挙げていった方が、思考負荷も小さく結果的に速いです。
よくDXで「業務に合わせてシステムを作るのではなく、システムに合わせて業務を変える」ことの重要性が説かれますが、それと同じように、AIエージェント時代の開発では「自分のやり方でAIに作らせるのではなく、AIに合わせて（AIのやりやすいように）開発のやり方を変える」必要があるのだと思います。
とはいえ、AIに完全に任せてしまうと、コードベースはどんどん自分にはメンテ不能な方向に育ってしまいます。自分で考え込みすぎずにAIに書かせながら、適宜軌道修正を挟みつつ、メンテ可能な範疇に留めるくらいが良い塩梅なのではないかと思います。
たとえば、僕が体験した範囲だと、AIが class ベースでどんどんコードを作り始めてしまいました。Swiftは値型中心の言語なので struct を利用する方が適しているケースが多いです。 struct で表現できる箇所は struct に修正するように指示しました。継承が使われていて、すぐには修正できなそうな箇所は放置していたのですが、後でComplete Concurrency Checkingに引っかかり、ビルドエラーを解消するためにAIはあらゆるものに @MainActor を付けて回り始めました。
その後、僕が手動で問題を解決して、不要な @MainActor を消して回りました。そのように軌道修正を挟まないと、おそらく class だらけ、 @MainActor だらけのコードになってしまっていたでしょう。これはSwift（の特に比較的新しい機能）に対するAIの理解が浅かっただけで、TypeScriptなどのよりメジャーな言語では違うのかもしれません。しかし、たとえそのような言語でも、ライブラリやフレームワークの最近のアップデートには追従できないなどあるでしょう。同じような軌道修正は必要になるのではないでしょうか。
ただ、最近バズっているmizchiさんの記事には
Cline は暴走列車みたいなもので、最初の指示以外は人間なんかどうでもいいと思っているフシがある。その結果、これ抜きに実現できない速さを獲得し、自分はこれ無しで我慢できなくなった。正直、かなりの中毒性がある。
— mizchi, "CLINEに全部賭けろ"
とあるので、もしかすると、人間の関与を極力減らしてAIに暴走させることで、違う地平が見えてくるのかもしれません。
いずれにせよ、 AIエージェントを使うときのメンタリティとしては、自分の開発効率を上げるツールではなく、何でも命令できる部下だと思った方が良いように思います。 自分でコードを書くのではなく部下にコードを書いてもらう場合は、ある程度はその人の書き方を尊重するのではないかと思います。そのような関わり方をすれば、自分のやり方をある程度妥協し、部下も含めたチームとしての最大効率を考えやすいのではないでしょうか。
AIに適したコードとは
前節で「AIがやりやすいように」「AIが作りやすいように」と述べましたが、それをもう少し掘り下げてみます。
AIエージェントを前提とすると、
- 凝った作り込みはAIの理解を妨げネガティブに働く
- 一般的な書き方をしたわかりやすいコードの方が適している
ように思います。
たとえば、 コードの冗長性を排するための複雑な工夫をするよりも、多少の冗長性を許容しても平易で読みやすいコードの方が適している ように感じました。 一般的なプログラミングのプラクティスにおいては、冗長なコードは変更時に多重修正が必要となるため、メンテナンス性が悪いとされます。しかし、AIエージェントはそれらを指示一つでまとめて修正してくれます。
この考え方はDRY(Don't repeat yourself)によく似ているように思います。勘違いされがちですが、DRYはコードに閉じた話ではなく、本来はドキュメントも含めた重複を防ぐ話です。たとえば、データベーススキーマを記述したドキュメントがあり、それが正であれば、ドキュメントの修正が実際のデータベースやコードに機械的に反映されなければなりません。また、DRYではたとえコード上で冗長でも、それが生成物であれば問題にしません。データベースの例では、ドキュメントと実際のデータベースとコードで三重にデータベーススキーマが扱われていても、ドキュメントが主であり生成物は従なので問題ありません。
もし、AIへの指示が主・そこから生み出されるコードが従で、新しい指示一つで該当箇所がすべて修正できるなら、ある意味でDRYが成立していると言えます。これは少し極端な論かもしれませんが、少なくとも僕はClaude Codeを使って開発していて、冗長性に対する許容度が上がるのを感じました。
その他にも、
- 関連する処理はコード上でも近くに配置する（コードベースの中をジャンプし回るようなケースは、名前から処理がうまく推測できないと、AIの理解を妨げる可能性がある）
- 単体テストしやすい作りにする（人間が書く場合でも同じだが、AIが自律的にコードの正しさを検証できるようにすることは重要）
- ファイルやモジュールを適切に分割し、わかりやすい名前を付ける
なども重要になるのではないかと思います。このあたりはまだ実感するほど使い倒せてないですが。
僕が実際に取った方法は、できるだけ最初からAIに書かせるということです。そうすれば、AIが学習した一般的なパターンで、平易なコードが書かれることが多いです。 適宜軌道修正しながら、あまり自分の色を出しすぎて複雑化しすぎないくらいのバランスに注意しました。結果的に、理想的とは言えないけれど人間にもAIにもわかりやすいコードで、僕がゼロからあれこれ考えて進めるより3倍くらい速く開発を進められたのではないかと思います。
少し違った観点では、ファイルを適度に分割することで、コストを抑える効果があるかもしれません。ファイルの読み込みは入力トークンとして課金されてしまうので、ファイルを適切に分割することで、AIが必要な部分だけを読み取るのを助けられるのではないかと思います。
ただ、これもサム・アルトマンが言っているように、
The cost to use a given level of AI falls about 10x every 12 months, and lower prices lead to much more use.
— Sam Altman, "Three Observations"
今後も1年でコストが10分の1になりつづけるのであれば、近い将来、あまり大きな問題でなくなるかもしれません。もしくは、AIエージェントツールがもっと賢くなって、ピンポイントで必要な箇所だけ読み取る精度が向上すれば問題が解決するかもしれません。
また、今回は比較的小さなコードベースで試したので、巨大なコードベースではうまく機能しないかもしれません。現時点では、適切にモジュールを分割して、コードベースの大きさをコントロールすることが重要かもしれません。しかし、今後コンテキストウィンドウが広がり、コストが下がれば巨大なコードベースも問題にならなくなるかもしれません。
まとめ
- Claude Codeのresearch preview版がリリースされたので使ってみた
- ソフトウェア開発のあり方が大きく変わるように感じた
- AIに爆速開発させるために、自分のやり方をある程度妥協してAIがやりやすいようにする
- 人間がボトルネックなので、人間が考えすぎる前にAIにやらせてみる
- メンテ不能の代物ができあがらないように、適度に指示を与えて軌道修正させる
- AIの理解を妨げるような過度に凝ったテクニックや作り込みを行わない
- AIの書き方をベースにすることで、AIが学習したパターンに乗りやすい
ファーストインプレッションなので、今後使い込むことで考えも変わってくるかもしれません。また、今後のAIの進化で大きく状況が変わるかもしれません。ひとまず、現時点の所感でした。
今後AIエージェントを取り巻く状況がどのように変わっていくかわかりませんが、AIエージェントがソフトウェア開発のあり方を大きく変えていくのはほぼ間違いないと思います。Claude CodeでもCursorでもClineでも何でもいいので、まずは触ってみることをおすすめします。
-
日本日時では2月25日 ↩︎
Discussion