Martin Brennan
Jan 7, 2026 • 7 min read
すべてのエンジニアが今や手元にコードを生成するマシンを持っており、エンジニアとしてAIツールを使うことを現実的に避けられない時代に急速に近づいています。たとえ自分自身では何とか使わずに済んだとしても、同僚のほとんど、あるいは全員がすでにAIツールを使い、同じコードベースにコントリビュートしているという事実に適応しなければなりません。問題は、作ることが編集よりもはるかに簡単になった今、個々のコントリビューターが品質を維持するために何ができるか、という点です。
洪水のように押し寄せるコード
テクノロジーが創造の摩擦とコストを下げると、量は爆発的に増加します――しかし量が質を意味することはほとんどありません。
AIも例外ではありません。公開・非公開を問わず、あらゆるコードベースでプルリクエストに使われており、生成されるコントリビューションの品質に対する配慮の度合いもさまざまです。AIマシンは、人間がそれを読んで意味と正確さを判断するよりも速くもっともらしいアウトプットを生成できますし、削減するよりも生成する方がはるかに得意です。
テックリードとして、私の仕事の一部は、自分が担当するコードベースのセクションにおいて品質の番人であることです。人間のコントリビューターとの関係では、品質には常に融通が利く部分があります――完璧は善の敵であり、バグ修正や機能追加のあらゆる変更に何時間も頭を悩ませていたら、何もリリースできません。しかし人間のコントリビューターとは、こうしたトレードオフを意識し、互いに信頼と理解を共有し、この技術的負債がいつか返済を求めてくるかもしれないという認識を持てます。
AIコントリビューターにはそのいずれもありません。記憶もなく、信頼も理解もなく、今自分がやっていることが将来どこかで誰かに何時間もの苦労と苦悩をもたらすかもしれないという認識もありません。AIツールは歴史もなく、人間が長年かけて積み上げてきた学習経験もない、一時的な存在の中に生きており、何かを間違えても一切の結果を負いません。品質はAIツールと同義であることはしばしばありません。プロジェクトの標準を維持するためには、人間のパイロットによる慎重な指導とキュレーション、そしてCLAUDE.mdファイルのようなガードレールが必要です。
不注意に使われた場合、AIのコントリビューションはレビュアーの時間とエネルギーを大きく消耗させる可能性があります。AIコードはレビューに時間がかかり、上述の理由から人間が生成したコードよりも信頼性が低いため、信頼の欠如につながります。レビュアーは「自分で書くほど気にかけなかったのなら、なぜ私が読むほど気にかけなければならないのか」という思考に陥ることがあります。AIの不注意な使用は、同僚間の信頼や関係の侵食につながり、生産性全体の低下を招く可能性があります。
共有された責任
コードレビューとソフトウェアの品質は、コントリビューターとレビュアーの間で共有される責任のやり取りです。今まで以上に、ソフトウェアエンジニアリングにおける人間的要素を忘れてはなりません。コントリビューターの責任は変わっていません：
- コードは合意されたスタイルと規約に従い、適切にテストされていなければなりません
- コントリビューターは自分のプルリクエストを理解し、その変更が正しいこと、関連する問題とトレードオフが適切に考慮されていることを最善の知識に基づいて認め、責任を持ちます
- コントリビューターは、レビュアー、同僚、そして将来の自分自身のために、変更に関する十分なコンテキストを提供しています
- コントリビューターはオープンな姿勢でレビューに臨み、特にAIが関与している場合は、広範なフィードバックや修正が発生する可能性を想定しています
- コントリビューターは、コードベースへのあらゆる変更において、短期的な利益と長期的な技術的負債の間の複雑なトレードオフを理解しています
レビュアーの責任も同様に変わっていません：
- レビュアーは、すでに熟知しているコードベースの領域についてガイダンスを提供する機会として活用するか、レビューのプロセスを通じてコードベースの新しい領域について学ぶ機会として活用すべきです
- レビュアーは、合意された品質基準、スタイルと規約、テスト基準を守るよう努めるべきです
- レビュアーは、自分の役割が完璧なコードの仲裁者であることではないと理解しており、コントリビューターとの適切なコミュニケーションが行われていれば、プルリクエストに未解決の問題があっても今マージして後で戻ってくる方が賢明な場合があります
これはAIとどう関係するのでしょうか？
端的に言えば：PRの一部、あるいはすべてをAIが書いたかもしれないからといって、誰も責任を免除されることはありません。コントリビューターはPRをポイっと投げて手を洗うことはできませんし、レビュアーはAIコードに対処したくないからといってPRに形式的なスタンプを押したり回避したりすることはできません。長期的な配慮の欠如は、あらゆるソフトウェアプロジェクトにとって毒です。
日々の現実確認
AIツールを使うことの一部は、いつ使用をやめるかを知ることです。AIは思考の流れにはまり込むことがよくあり（この点ではこれらのツールは人間によく似ています）、単純に間違っているその道を進み続けることがあります。これはコンテキストの汚染が原因であることもあれば、AIがコードベースについて十分なコンテキストをメモリに読み込めないことが原因であることもありますし、単純に問題が複雑すぎるか、プロンプトが品質の高い結果に至るのに十分でないことが原因であることもあります。
コーディングは思考であり、エッセイを書くときのように最初の草稿をたどたどしく書き進めることで、AIツールのアウトプットを読むだけでは得られない、解こうとしている問題についての重要な洞察が得られます。問題を手作業で解決することは、AIツールと長々とやり取りするよりも時間効率が高いことがよくあります。
自分でやること、休憩を取ること、一晩寝かせること、その他の方法は、はるかに効果的で、レビュー時に自信を持って責任を持てる品質の高い結果につながることがあります。そしてレビュアーも、解決策に注がれた余分な思考に感謝するでしょう。
一般的に言って、AIはまったく新しいクリエイティブなソリューションを書くよりも、バグの修正、スクリプトの作成、ラバーダックやコパイロットとしての役割に向いています。人間はクリエイティブな存在であり、それは私たちの最も貴重な贈り物の一つです。協力する能力や、世界を支配するのに役立ったツールを作る能力（まるで自分で考えているように見えるツールや、他のツールを作るためのツールさえも）と並んで。
コードはまず人間のためにある
コードは最終的には機械が消費するためのものですが、それを書き、読み、責任を持つのは人間であり、これが近いうちに変わるとは思えません。AIツールを使いながらも、人間の理解と思考を最大化すべきです。これを念頭に置かなければ、誰もコードを書いたりレビューしたりするプロセスに真に関与しておらず、すべてをAIに任せてしまったために、誰もコードを理解できないコードベースにすぐに埋まってしまうでしょう。
そして、何かが必然的に問題になったり技術的負債が耐えられなくなったりしたとき、全員がゼロからコンテキストを積み上げることになります。現在の世界では、少なくとも一人か二人、あるいはそれ以上の親しみのある人がいる可能性が高いのに対して。これは望ましくない状態であり、品質に適した環境ではありません。AIのシロアリによって長年かけて基盤が食い荒らされると、構造全体が崩壊し始めるでしょう。
常に自分自身にこの問いを投げかけてみてください：「このAIコードを後から対処しなければならない人になりたいか？」そして答えがノーであれば、関わる人間のためにまだ調整が必要な部分があります。コード品質を維持し、AI時代に持続可能な形で働くためには、マシンよりも現在と未来の自分たちを優先しなければなりません。
信頼せよ、しかし確認せよ
これらすべての知識を踏まえて、エンジニアがAIツールを使いながら互いを尊重し、作業の品質を保ちつつ持続可能に働く方法があります。
これらのツールを使うとき、あるいはそれを使った人の作業をレビューするとき、あなたのマントラは常にロナルド・レーガンが有名にしたロシアのことわざ……「信頼せよ、しかし確認せよ」であるべきです。
PRをレビューする際、プログラマーは日常的に「スニフ（臭い）」テストを行います。PRがAI使用のスニフテストに失敗するパターンはいくつかあります：
- 絵文字、ダッシュ、箇条書きが多い非常に冗長なPRの説明
- コード内のコメントの過剰な使用、特にテストファイル内
- コードベース内の他の例や共通パターンと合わない不自然なコードスタイル
- 「最初の草稿」状態に見えるコード。二度見やリファクタリングなしにそのまま置かれたように見えるもの
- コードがコードベースの残りの部分の「雰囲気」に合っていないサイン。それを書いたものがコードの他の部分を認識していない可能性があること
- 車輪の再発明をしているコード。例えば、プロジェクトにすでにモーダルウィンドウコンポーネントがあるのに新しいJavaScriptモーダルウィンドウパターンを作成しているなど
これらのサインに気づいたら……確認してください。
コントリビューターにAIを使ったかどうか、そしてコードが何をしているか理解しているかを確認してください。気を悪くするべきではありません。これは私たち全員が今生きている現実に過ぎません。人間が生成したコードと同様にガイダンスを提供してください。人間が生成したコードと同じ基準を維持し、「わからない、AIが書いたから
」を免罪符として受け入れないでください。
AIツールを使って他のAIのアウトプットを検証することもできます。最近私が行ったレビューからの実践的な例を紹介します。左側にAIコードのように見えるものを見つけ、経験から複数の改善点があると思いましたが、一つひとつを探し出すのに時間をかけたくありませんでした。そこでそれをChatGPTに入力し、よりクリーンまたはよりイディオマティックな方法があるかどうかを聞き、提案が正しいことを確認した上でレビューに取り入れました：
私がしなかったことは、コントリビューターにChatGPTの会話へのリンクを貼ったり、大量のAIテキストのスクリーンショットを送ったりすることです。私はAIをコントリビューションの品質を高めるために使用し、自分の時間もコントリビューターの時間も無駄にしませんでした。AIは助けましたが、支配はしませんでした。
次はどうなるのか？
より多くのソフトウェアエンジニアやデザイナーがテクノロジーを採用し、ツールが改善されて日常的なワークフローとより統合されるにつれ、AIが生成するコントリビューションは加速するでしょう。すべてのソフトウェアが完全にAIによって書かれるようなAGIの頂点に近いうちに達することはないでしょうが、変更セットごとに使用されるAIの量は「まったく使用されていない」から「コードとテキストのすべての行に使用された」までのスケールのどこかにあると仮定すべきです。
品質を維持するためには、これを常に念頭に置き、コントリビューター、レビュアー、メンテナーとして協力し合い、人間的要素を決して忘れないことが必要です。AIはソフトウェアプロジェクトにとって呪いではなく恩恵となり得ます。しかしその区別をつけるのは私たち次第です。
原文はこちら：
Good Loopでは、Discourseのセルフホスティングを安価で提供しています。開発元であるCDCK社の協力のもと、公式ブログ記事の翻訳・公開など、日本での普及にも努めています。