- 公開日:
AIコーディングと新時代の開発スタイル
- Authors
- Name
ClaudeとClaude Codeを使ったAIコーディング(Vibe Coding)に夢中になっている。止められない時代の変化を感じた。
先ほど次のGo言語パッケージを公開したのだが、READMEにいたるまで100% AIによるコーディングである。
機能はシンプルだが、テストがかなり充実している。自分で書くとなると(そもそもこのテストが書ける自信すらないが)、数日〜1週間を要したと思う。しかしClaudeによる所要時間はたった3時間だ。
開発手順
設計ディスカッション
Claude Codeがプログラミングを自動で行うとは言え、抽象的な指示では期待するものは出てこない。そこでまずはClaudeとディスカッションして設計を進める。
Claude CodeはCLAUDE.mdという設計書に基づいてコーディングを自動的に進めるので、まずはClaudeと相談しながらCLAUDE.mdファイルを一緒に作り上げていく。
- 「コンポーネントとinterfaceを考えてみて」
- 「XXの部分は冗長だから、〜のような仕様にしてみて」
- 「XXは不要です。代わりにYYを追加して」
- 「テストはどんな方針で行う？ XXについては重点的にテストしたい」
などと対話を進めると、「確かに自分ならこう作るかな」という設計に近づいていく。むしろ自分では思いつかないアプローチも提案してくれるのも面白い。
コーディング
最後に「これまでの内容をXXXという章立てで、CLAUDE.mdに英語でまとめて」と指示する。違うかもしれないが、CLAUDE.mdはどうやら英語限定のようで、Claude Code自身も英語で書き換えてしまう。
今回、CLAUDE.mdに記載してもらったのは以下のような情報だ。
- プロジェクトの目的と意義
- コンポーネントとinterfaceの基本設計
- テストの方針
- ファイルマップ
少し大きなプロジェクトの場合は、「どんな手順で実装すすめるといいかな」と聞いてみるのもよい。
Claude Codeでもいきなり全体をコーディングさせるのではなく、まずは細かく部分的な指示をする。
- 「XX.goとXX_test.goを書いてみて」
- 「XX_extended_test.goを書いてみて」
やはりコーディングを進めていくうちに、設計を変えたい点も出てくる。それも都度指示してコーディングを進める。
また、AIによるコーディングは意外と粗もある。外見的には上手く動いているが、こうした方がいいと思う点は出てくる。特にスピードと堅牢性のトレードオフは微調整があった。
パッケージング
最後に「README.mdを英語で、README.ja.mdを日本語で書いて。相互にリンクさせて」と指示して、説明文書を書いてもらう。
「パッケージとして公開する上で、他に用意した方がいいことある？」と聞いてもよい。
この辺りのエコシステムへの適合ノウハウも、自分よりAIの方がはるかに頼もしい。
自分用のOSSと考えブラックボックスを許容する
AIが生成したコードを精査したかというと、そこまでしていない。ざっと眺めはするが、特にテストコードは大部分がブラックボックスである。
その完全に掌握できないところがAIコーディングに対する最も大きな不安だったが、この数日で完全に意識が変わった。
私たちがOSSを用いるとき、そこまでコードを掌握するだろうか？ 外形として期待通りに動作すればそれを用い、何か問題があればソースコードを追跡するだろう。
AIによる成果物もそれでよいと思い至った。要は自分の成果物ではなく、「自分用に誰かが作ってくれたOSSパッケージ」だと思うことにしたのだ。
テストコードの記述がタダ
テストコードを書くのが好きという人もいるだろうが、おそらく少数である。テストコードは自分の身を助くもであるが、ユーザーには直接、価値をもたらすものではない。だから個人的にはモチベーションが低い。
モチベーションが低いから精度も荒くなる。できるとわかってても処理が複雑だと面倒臭い。あとで仕様変更があると書き直しになると思うと気が重い。手を抜いてしまうことが多かった。
AIに任せるとそんなテストコードを任せ放題になる。使用変更があっても何度でも頼めばよいのだ。これが一番嬉しい。
ドキュメントの同期
AIによるコーディングの嬉しいもう一つのポイントはドキュメントの同期だ。仕様変更などはドキュメントへの変更も同時に行なってくれる。
ドキュメントもテストと同様、書いても動くものではないので動機が弱い。したがって更新が後回しになるのが常であったが、AIがやってくれるのであれば心配の種がひとつ減る。
Go言語の相性
まだGo言語でしか本格的なVibe Codingは行っていないが、AIとの相性がよいように感じる。
Go言語は、言語もエコシステムもシンプルだ。シンプル過ぎて人間が書くには敬遠する人もいるが、AIが大量生産してくれる分にはその問題はない。
逆に言語的にシンプルであるのは、読みやすさにもつながる。難解さがないので、時間をかけて解読すれば理解できる。
型安全であるのもAIと相性がよい。このように人間とAIの橋渡しをする言語としてGo言語は妙にピッタリはまる印象がある。
重複の許容
ドキュメントの維持に近い話で重複コード、重複ロジックに対する更新もAIは強い。
ほとんど同じコードAとA'があると、Aは直したのにA'は忘れてしまうことが起こりうる。だから重複するコードは一つに共通化するのがプラクティスとされる。
ところが今度は、重複部分の修正が思わぬ副作用を生むことがある。その方が影響範囲を特定しにくく問題が厄介になることがある。
その点、AIであれば重複コードを見落とすことがない。明らかにまとめた方がよい場合は別だが、AIによるコーディングでは無理に共通化してバリエーションと依存関係が複雑になるなら、重複を許容してもよい可能性がある。
プログラミングのプラクティスは精神力から性能へ
人間の精神は曖昧で不安定で消耗しやすく個人差がある。そんな脆弱性をプロセスで矯正し、スループットを最大化した組織が基本的には強かった。その最たる例が軍隊だと言えばわかりやすいだろう。
プログラミングに関するプラクティスも同様に人間の脆弱性を補うプロセスであることが多い。
しかしAIには人間のような精神的脆弱性がない。だから人間用に整えられたプロセスが要らない。むしろ邪魔になる可能性もある。
一方、精神的な脆弱性はないが機械である以上、性能という制約がある。実際、Claude Codeもコードベースが拡大してくると、思考と応答が明らかに長くなる。
したがって今後は、人間の脆弱性ではなく、AIの性能を優先したプラクティスを実践する組織がスループットを最大化するだろうと感じた。
マイクロサービス的な設計思想
人間の精神力ではなく、AIの性能が制約になる時代の設計思想はモノリシックではなくマイクロサービスだ。
機能をAIに適した小さな部品に分割し、その部品が責任を果たすようにがっちりと実装する。テストが書き放題なので、部品は頑健に作りやすくなる。
そして外部依存を完全に抽象化し、ドメインロジックをがっちり担保するコードとテストを書く。
ログを冗長に出力することも考えられる。以前はログを出しすぎると有意な情報を見落とす恐れがあったが、AIであればその心配もない。
最後に頑健な部品を頑健なロジックに結合する。そのようなプログラミングがAI時代に適しているのではないかと感じている。