Claude Code Deep Diveの要点まとめ
Claude Code Deep Dive
AIが生成したコードのレビュー戦略
AIは大量のコードを生成するため、人間がすべてを精読するのは非現実的です。そこで、以下のような工夫が議論されました。
-
テストをレビューの中心に置くアプローチ（T-Wada氏）
- テストファーストの実践: まず人間が最初のテストコード（ひな形）を書き、AIにそのひな形に沿ってテストケースを追加させる。ゼロからAIに作らせると「博打」になるが、この方法なら品質をコントロールしやすい。
- 少量ずつの生成とレビュー: 機能単位で細かくテストを生成させ、その都度レビューする。これにより、一度にレビューする負荷を軽減し、手戻りを防ぐ。
- プロダクトコードかテストコードのどちらかをレビュー: 両方をレビューするのは大変なため、どちらか一方をしっかりレビューすることで、作っているものの実態を把握する。
-
外部仕様（API）に絞ったテスト（Mizchi氏）
- エンドツーエンドテストから作成: ライブラリの外部に公開しているシンボル（API）に対するテストをまず作成する。
- 内部実装は信頼する: 公開APIのテストが通っていれば、内部の実装がどうなっているかは問題が起きるまで深追いしない。これにより、レビューのスコープを限定し、効率を上げる。
- ドキュメントを生成・レビュー: VitePressなどでドキュメントを生成させ、その内容を読むことでテストの代わりとすることもある。
プロジェクト全体の品質を保つための知見
個別のコードレビューだけでなく、プロジェクト全体の品質を維持するための重要な視点も共有されました。
-
初期設計の重要性:
- プロジェクトの初期に用意する「ボイラープレート（ひな形）」が、最終的な品質を大きく左右します。最初の設計が曖昧だと、後で大規模な手戻りが発生しがちです。
- 人間向けの資産をAIに活用させる: 既存のコードジェネレーターなど、人間向けに作られたツールでも、カスタムインストラクションで使い方を教えればAIは上手に活用してくれます。これにより、AIに一から作らせるよりも質の高いコード生成が期待できます。
-
開発環境のスケーラビリティ:
- 「AIの導入は、開発チームが急にスケールしたのと同じ」。このスケールに耐えられるだけのCI/CDプロセスやテスト環境の整備が不可欠です。これまで開発プラクティスに真面目に取り組んできたかどうかが問われる「試金石」になると述べられています。
最初のテストは人間が書く（T-Wada氏）
AIにコードを書かせる上で、品質をコントロールするための非常に実践的な知見です。
- AIによるゼロからの生成は「博打」: AIにゼロからテストコードを生成させると、意図しないものが出来上がる可能性が高い「博打」になってしまうと指摘しています。
- 人間が「ひな形」を作る: そこで、まず人間が最初のテストコードを書き、そのプロジェクトにおける「テストの書き方」のひな形を示します。
- AIは「ひな形」に沿って追加する: その後、AIに対して「このひな形に沿って、こういうケースのテストを追加して」と指示することで、人間が意図した通りの質の高いテストコードを効率的に増やすことができます。これは、AIの能力をうまく引き出しつつ、プロジェクトの品質を維持するための重要な工夫です。
AIへの指示の出し方（プロンプトの工夫）
AIの能力を最大限に引き出すための、具体的な指示の出し方についても言及されました。
-
定量的で明確な目標を与える:
- 「良いコードを書いて」のような曖昧な指示ではなく、「コードを5000行削って」「テストカバレッジを90%にして」といった具体的な数字で目標を示すことが非常に有効です。
- 「良いコードとは何か」を人間が言語化し、評価可能な形でAIに伝える必要があります。
-
AI自身に評価と修正を行わせる:
- AIにコードを生成させるだけでなく、「Similarity TS」のようなツールでコードの重複を検出し、その結果をAIに渡して「この重複をどう解釈してリファクタリングすべきか」を考えさせる。
- AIに「評価関数」を与えることで、AI自身が自己修正するサイクルを回せるようになり、スケーラビリティが向上します。
これらの議論から、AIとの協業においては、人間が「アーキテクト」や「レビュアー」としての役割をより強く意識し、AIをうまく導くための戦略的な関わり方が重要であることが示唆されています。
コストを恐れず「使えるだけ使う」という感覚（Mizchi氏）
当初はコストを気にして恐る恐る使っていたものの、途中から「使えるだけ使えばいい」という感覚に変わった、という話です。これは単なる精神論ではなく、AIの活用によって開発のスタイルそのものが変化したことを示唆しています。
- 背景: Claude Maxのような高性能なモデルはコストがかかり、Mizchi氏自身も一晩で1000ドル以上課金された経験があるとのことです。当初は200ドルの無料枠を意識していましたが、それではAIのポテンシャルを最大限に引き出せないと気づきます。
- 開発スタイルの変化: これまでのプログラミングが「丁寧に実装を育てる」ものだったのに対し、AIを使うと「並列で大量に試して、結果が悪ければ全て捨てる」という、人間相手では不可能なアプローチが可能になりました。
- 容赦ない仮説検証: この「使い捨てる」感覚により、ライブラリの動作検証のような少し面倒なタスクも、AIにスニペットを書かせて即座に試すなど、仮説検証をためらうことなく、かつ高速に回せるようになりました。コストはかかるものの、それ以上に得られる開発スピードや試行回数の増加に価値があるという考え方です。
その他の重要な知見や細かい工夫
パネルディスカッションでは、他にもAI時代における開発のヒントが数多く語られました。
-
AI向けのツールや言語の必要性（Mizchi氏）:
- 現在のプログラミング言語やLSP（Language Server Protocol）は人間向けに作られており、AIには冗長な部分がある（例：行と文字位置での指定）。AIには構文木を直接操作させるようなインターフェースが向いているのではないかと提言しています。
- AIがコピペでコードを散らかす問題に対し、コードの重複を検出する自作ツール「Similarity TS」をAIに実行させ、重複箇所をAI自身に解釈・リファクタリングさせるという試みを紹介。AI向けのツールを用意し、AIに自己評価・修正させるサイクルの重要性を示しました。
-
GUI開発の難しさと工夫（平グラム氏）:
- iOSアプリなどのGUI開発は、コードを書いてからシミュレーターで確認するまでのサイクルが長く、AIとの相性が悪いという課題があります。
- 対策として、FigmaのスクリーンショットをAIに見せつつ、HTMLの構造だけは人間が書き、細かいCSSの装飾をAIに任せるなど、人間とAIの役割分担を工夫しているとのことです。
-
知識やアルゴリズムの再利用が容易に:
- これまでなら「あのアルゴリズムどうだっけ？」と調べて実装していたようなコンピューターサイエンスの知識を、AIに聞けばすぐにコードとして引き出せるため、知識の再利用性が格段に向上したと語られています。
その他
平グラム氏による発表「Deep Dive into Claude Project」
Claude Codeの.cloudディレクトリの構造や、会話ログ（JSON Lines形式）の詳細な解説がありました。
サブエージェントの仕組みや、スラッシュコマンドの実行についても触れられています。
会話ログを分析することで、Claude Codeの動作を深く理解し、プロンプトの最適化に役立つと述べられています。
参考
Discussion