数ヶ月前、私のチームは実験を終えました。それは、AIコーディング支援を使って完全に複雑なプロダクションアプリケーションを構築することでした。アプリは出荷され、動作しています。しかし、そこに至るまでの教訓は、過去10年間に使用したどのツールよりもソフトウェア開発についての考え方を変えました。
これが私たちが学んだことです。
新奇から必要性へ
AIコーディングエージェントとの関係は大まかに3つのフェーズで進化してきましたが、多くのエンジニアも同じ道を歩んできたのではないかと思います。
2024年、ChatGPTは好奇心の対象でした。概念を説明したり、メールを下書きしたり、時には問題を解決するためのラバーダッキングとして役立ちました。実際のコーディングツールとしては？おもちゃのように感じました。
2025年初頭、IDEに統合されたアシスタントの波が到来しました—Cursor、Windsurf、新しいCopilotです。これらは興味深いものでした。より良いオートコンプリート（タブを押し続けるだけ）、より良いコンテキスト内の提案。しかし、基本的にソフトウェア開発の方法は変わっていませんでした。私たちはまだコードを書いていましたが、少しだけ速くなっただけです。
2025年後半に何かが本当に変わりました。Claude Codeが登場しました。そして、数週間真剣に使用した後、気づきました：これは本物です。私たちは新しい時代にいます。
今日、2026年、私は自分自身に問い続けている同じ質問をあなたに尋ねます：ソフトウェア開発において最も重要なツールは何ですか？
1年前、答えは明白でした—IDEです。そこがコードが生成される場所でした。今日、私にとってIDEはGit統合された重いテキストビューアになりました。出荷されるコードの1%を手動で変更するかもしれません。実際のソフトウェア開発は別の場所に移動しました。
AI支援開発はどのようにしてコードレビューのボトルネックを生むのか？
スピードはそれ自体で問題を生み出し、業界全体がそれを感じ始めています。
Gartnerはそれを明確に述べています：「AI支援開発は、エンジニアリングチームがコードレビューの能力を増やすことなく劇的に多くの新しいコードを生成するため、重要なレビューのボトルネックを生み出しました。」
数学は厳しいです。AIは数分でコードを書きます。それをよくレビューするには数時間かかります。そして、エンジニアは次のような偽の選択肢に直面します：
- すべてをレビューすると、あなたがボトルネックになります。AIで得たスピードの利点は？消えます—PRキューで燃え尽きます。
- 何もレビューしないと、速く出荷できますが、バグが蓄積し、脆弱性がすり抜け、技術的負債が積み重なり、コードベースへの信頼が静かに崩壊します。
それは負ける状況であり、私たちは何か違うことを試みました。
私たちが実際に構築していたもの
私たちが構築していたアプリケーションは、Claude CodeのようなCLIエージェントを補完するデスクトップアプリであり、その力にUIの明確さをもたらし、カジュアルユーザーをパワーユーザーに変えるツールを追加します。これは、IDEを逆さまにしたようなものです：自分でコードを書くのではなく、AI生成コードをレビューすることに焦点を当てています。
これは小さなアプリではありません。Reactを使用したElectronアプリケーションであり、複数のバックエンドサービス、組み込みのターミナル、Connected ModeでのSonarQube for IDEを備えており、Windows、MacOS、Linuxで動作する必要があります。これは実際のプロダクションの複雑さを持っていました。
私たちは非常に速く出荷しました。数日かかるはずの機能が数時間で実現しました。そのスピードは爽快でした。
しかし、疑問は消えませんでした。
アプリが動作しているなら、コードをレビューする必要があるのでしょうか？もしそうなら、どの程度深く？もしそうでないなら、これが本番で失敗しないという自信はどこから来るのでしょうか？
そして徐々に、スピード自体が揺らぎ始めました。アプリが複雑になるほど、他の何かを壊さずに出荷するのが難しくなりました。機能を正しく実現するための反復が増え、AIが前日に書いたコードをデバッグする時間が増えました。
その時、基本的なことがクリックしました。
すべてのセッションが新しいソフトウェア開発者です
すべてのセッション、それは異なる「人」です。それはあなたのコードベースを初めて見ます。それは前回何をしたかを覚えていません。それがなぜ特定の方法で構築されたのかを覚えていません。それには傷跡も、共有されたコンテキストも、あなたのパターンに対する筋肉記憶もありません。
新しいエンジニアをチームに迎えるとき、彼らがコードベースを内部化するのに数週間、時には数ヶ月かかることを受け入れます。AIの場合、毎回のセッションで新しいエンジニアを迎え入れているのです。そして、ランチで一緒に座って、その奇妙なモジュールの歴史を説明することはできません。
その問題をそのように見たとき、私たちは立ち止まりました。大規模なリファクタリングを行いました。再構築しました。ゼロからアーキテクチャを再考しました。
そしてそのプロセスを通じて、真の質問が結晶化しました：どうすれば毎回異なる人が生成するコードに一貫性をもたらすことができるでしょうか？
答えはより良いプロンプトではありません
この部分は私を驚かせました。
答えは洗練されたCLAUDE.mdではありません。それは完璧なスキルファイルでもありません。それはより賢いシステムプロンプトでもありません。それらは役立ちます—それらは基本ですが、それらがレバレッジのある場所ではありません。
レバレッジはコードベース自体にあります。
AIを非常に才能のあるソフトウェア開発者と考え、毎回のセッションで初めてあなたのコードに遭遇する—それが文字通り起こっていることです—と考えると、コードベースが教育的なアーティファクトとしてどれほど重要であるかが理解できるようになります。それは単なるコードではありません。それはドキュメントです。それはAIが確実に持っている唯一のコンテキストです。
人間のチームメイトは時間とともにチームの癖に適応します。AIにはその猶予はありません。すべてのセッションはゼロから始まります。したがって、あなたのコードベースは、人間の場合に部族知識によって行われる作業を行わなければなりません。
実際に効果があった3つのルール
これが私たちにとって最大の違いをもたらしたものです。
1. 読みやすいアーキテクチャとファイル構造
AIの前では、ファイルを構造化して自分やチームメイトが物を見つけられるようにしていました。内部の規約があり、人々はそれを学びました。今では、AIは毎回ゼロから始めます。あなたの構造は本のように読みやすく、コンテキストがなくても誰かが冷静にナビゲートできるほど明白でなければなりません。
2. 厳格なサイズ制限
私たちは厳しいルールを施行しました：500行を超えるファイルはありません。これは実際には、他のプロジェクトで何年も無視していたSonarQubeルールから直接来たものです。私たちはそれと交渉するのをやめました。「600は500よりそれほど悪くない」と言うのをやめました。
コード品質の違いはすぐに顕著になりました。小さなファイルは変更の影響範囲が小さく、より集中したコンテキストウィンドウを持ち、責任が明確になります。AIはファイルを取得し、ファイルを理解し、ファイルを編集します—千行の神クラスで迷子になるのではなく。
3. 絶対的一貫性
あるコンポーネントがある方法で構築され、別のコンポーネントが別の方法で構築されている場合、AIは正しいパターンを特定するのに苦労します。私たちの具体的な痛点の一つ：ある場所ではreact-queryを使用し、他の場所では生のfetch呼び出しを使用していました。パターンが一貫していない場合、AIは間違ったものを選びます—ランダムに、または最悪の場合、最悪のものを。パターンが一貫している場合、AIは自然にそれに従います。
私たちはアプリケーションをゼロから構築し、飛行中にリファクタリングを行わなければなりませんでした。既存の大規模なコードベースがある場合、良いニュースは、AIを使用したリファクタリングがこれまでになく安価になっていることです。部分を選び、クリーンアップし、それをすべての後続の参照として使用します。それが針を動かすかどうかを確認します。適応し、さらにリファクタリングします。
そして明確にするために、私たちは深い最適化や大規模なアーキテクチャの変更について話しているのではありません。ファイル構造、ファイル名、関数の抽出について話しています。基本的なことです。退屈なことです。しかし、それが非常に重要であることがわかりました。
AIがほとんどのコードを書いているときにコードをレビューする正しい方法は何ですか？
アーキテクチャが整ったら—これは一度限りのイベントではなく継続的な実践です—次の質問はそれを維持する方法です。コードレビューは明らかな答えです。しかし、ほとんどのコードがAIによって書かれている場合、コードレビューはどのように見えるのでしょうか？
任意のPRを開いてください。その画面で最も重要な情報は何ですか？
1年前、私はその差分自体だと言っていたでしょう。実際のコードです。私はすべての行を読みました。
今日、それは変更されたファイルのリストです。
私は自分のアーキテクチャを知っています。AIに何を依頼したかを知っています。だから結果を見たとき、ファイルリストは私が知る必要があるほとんどすべてを教えてくれます：
- AIが予期しないファイルを変更した場合、その理由を理解する必要があります。
- 私のリクエストが簡単だったのにAIが100行を変更した場合、それは疑わしいです。何かが間違っています。
- 200行だったファイルが今では1,000行になっている場合、構造は改善されておらず、悪化しています。何かを分割する必要があります。
- 認証、支払い、データアクセス、状態管理、あなたのドメインで重要なものに触れた場合、それが私がゆっくりと慎重にレビューする部分です。すべてではありません。重要な部分だけです。
ある時点で、変更が安全であり、あなたの基準に合致しているかどうかを確認する一貫した方法が必要です。
これらの問題を見つけるためにすべての行を読む必要はありません。変更の形がAIが意図を理解し、変更が適用された後もアーキテクチャがまだクリーンであるかどうかを教えてくれます。
検証レイヤー
その他のすべて—重複、カバレッジの欠如、コードの臭い、小さな問題の長い尾—私はSonarQubeを検証レイヤーとして委任します。
すべてをキャッチするでしょうか？いいえ。
出荷に自信を持てるほどキャッチするでしょうか？はい。
明確にするために、これは私がコードを全く読まないという意味ではありません。コードはまだ私の責任です。しかし、何が敏感で注意が必要で、何がSonarQubeが品質基準を満たしていると言っている場合に十分であるかを知ることも私の責任です。レビュアーの仕事は、行ごとの精査からトリアージにシフトしました—どこに注意を払うべきか、どこで安全ネットを信頼するべきかを知ることです。
AIを使用する際にスピードとコード品質はどのように連携するのか？
これがクリックすると、あなたに有利に作用するフィードバックループが得られます。
クリーンなアーキテクチャはAIにパターンを追従させ、より良いコードを書くように導きます。SonarQubeは見逃したものをキャッチします。あなたは決定をレビューし、詳細をレビューしません。自信を持ってスピードで出荷します。そして、コードベースが変更ごとに健全であり続けるため、AIは引き続き良いコードを書きます。
私たちにとってスケールしたのは、単に速く生成することではありませんでした。それはよりタイトなループを作成することでした：クリーンなコードベースでAIをガイドし、変更を検証し、問題が複雑化する前に修正します。
スピードと自信は緊張状態にあるのをやめます。適切なセットアップがあれば、それらは共存します。
月曜日から考えるべき3つのこと
これから何も得られない場合でも、これらの3つを持ち帰ってください。
1. コードを異なる視点で見てください。 毎日、初めてコードベースを見たとしたらどうでしょうか？ナビゲートしやすいですか？アプリケーションの各部分がどこに属しているかが明らかですか？答えが「非常に」でない場合、AIはすべての変更でその税金を支払っています。
2. LLMはあなたのジュニア開発者ではありません。 そのように考えるのをやめてください。それは新しい、非常に才能のある人であり、毎回セッションを開始するたびに新しい人です。それは昨日を覚えていません。それはコンテキストを引き継ぎません。あなたのコードベースが彼らを教えなければなりません。
3. コード品質はオプションではありません。 AIがそれを解決するだろうと考えるかもしれません。私の経験から、それは希望的観測です。AI生成コードの品質は、既存のコードベースの品質とそれに適用されるすべての変更に直接依存します。より良い品質が入力されれば、より良い結果が得られます。
ボトルネックは現実です。しかし、それはスピードと自信の選択ではありません。それは、エンジニアリングの努力をどこに投資するかの選択です：より多くのコードを書くことに、またはAIがあなたの代わりに良いコードを書くことを可能にするコードベースを形成することに。
私はどちらに賭けているか知っています。
