GitHub Copilot や Cursor、Amazon Q といったAIコーディング支援ツール（コードを自動生成するAIアシスタント）の導入判断で悩んでいるアーキテクトやテックリードに向けた内容です。ベンチマークの精度競争とは別に、実運用で効いてくる非機能面のコストを整理します。
AIコーディング支援ツールの評価は、LeetCodeのような難問での正答率やIDE統合の滑らかさで語られることが多いです。ですが現場で本当に効いてくるのは、生成されたコードをレガシー資産や既存の設計規約にどう統合するかという問題です。この統合コストを見誤ると、生産性向上のはずの投資が技術的負債の増加に転じます。
この判断がなぜ必要か
AIコーディング支援ツールは「コード生成の速度」を売りにしています。
しかし生成が速いことと、開発が完了するまでの速度が速いことは別の話です。
人間が自分でコードを書く場合、書く行為自体が思考のプロセスです。
なぜこの抽象化を選んだか、どこにエッジケースがあるか、書いた本人はすでに理解しています。
AIが生成したコードでは、この理解のリンクが切れます。
開発者は生成物を読み、ロジックを理解し、正しさを検証し、既存コードベースに統合する必要があります。
この「読む・理解する・検証する・統合する」という一連の作業負荷を「認知負債（Cognitive Debt）」と呼びます。
コードを書く時間が減っても、検証と統合にかかる時間が増えれば、トータルの開発期間は短縮されません。
複雑なビジネスロジックの領域では、検証コストが生成で節約した時間の50〜70%に達するという指摘もあります。
単純なボイラープレート（決まり文句的な定型コード）であれば時間短縮の効果は正味で残りますが、複雑な領域ではネットの効果がマイナスになるケースも出てきます。
もう一つの技術的な制約が、LSP（Language Server Protocol、IDEと言語サーバーの通信規格）の限界です。
VS CodeやIntelliJがTypeScript Language ServiceやPyright、Gopltsといった言語サーバーと連携し、定義への移動や参照検索、ホバー情報を提供する仕組みがLSPです。
AIコーディング支援ツールはコンテキスト（生成の前提となる情報）を得るためにLSPに依存する場合があります。
しかしLSPが返す情報は範囲とサイズに制約があり、大規模なモノレポや複雑な依存関係を持つコードベースでは、AIが把握できるコンテキストの窓（コンテキストウィンドウ）が実質的に狭められます。
判断軸
AIコーディング支援ツールをどこまで、どの範囲に導入するかを決めるには、以下の軸で自分たちのプロジェクトを評価するのが実用的です。
検証コスト比: 生成されたコードを読んで検証する時間と、生成にかかった時間の比率です。
単純なCRUD処理やテストコードの雛形なら比率は低く、複雑な非同期処理や分散システムのロジックでは比率が高くなりがちです。
コードベースの複雑度: レガシー資産の量、暗黙のドメイン知識、モジュール間の結合度です。
結合度が高いモノリスでは、AIが生成した変更が予期しない箇所に影響を及ぼすリスクが上がります。
LSPの実効範囲: 使っている言語・フレームワークの言語サーバーが、リポジトリ全体の型情報や参照関係をどこまで正確に返せるかです。
TypeScriptやGoのように型情報が明示的な言語は比較的安定しますが、動的型付け言語や巨大なモノレポでは精度が落ちやすくなります。
非機能要件への影響範囲: 生成コードがセキュリティ境界、パフォーマンスクリティカルな経路、可用性に直結する箇所に触れるかどうかです。
認証処理やレート制限、リトライロジックのような箇所は、生成後のレビューコストが跳ね上がります。
選択肢の比較
| 導入パターン | 適した場面 | 認知負債のリスク | LSP依存度 |
|---|---|---|---|
| 補完中心（インライン提案のみ） | 単純なCRUD、テスト雛形、定型的なボイラープレート | 低い | 低い（単一ファイル内で完結） |
| エージェント型（複数ファイル自動編集） | 小〜中規模の機能追加、明確な仕様がある改修 | 中〜高い | 高い（リポジトリ横断の参照が必要） |
| レビュー支援（生成コードの説明・要約） | レガシーコードの理解、既存PRのレビュー補助 | 低い | 中程度 |
| フルオート運用（人間レビュー最小化） | 非本番環境の実験コード、プロトタイプ | 非常に高い（本番には未検証） | ツール依存 |
ケース別の推奨
単純な定型処理が多く、コードベースの結合度が低いプロジェクトなら、補完中心の導入から始めるのが妥当です。
検証コストが低い領域なので、生産性向上の効果がそのまま残りやすくなります。
複雑なドメインロジックを持つが、仕様がドキュメント化されていて明確な場合は、エージェント型を限定的に試す価値があります。
この場合、生成後のコードレビュー工程を通常より厚めに確保しておく設計が必要です。
レガシーコードの理解に時間がかかっている、あるいは新規参画メンバーのオンボーディングが課題になっているなら、レビュー支援型の活用が現実的です。
コードを書かせるのではなく「説明させる」用途に絞ることで、認知負債の発生源そのものを減らせます。
認証・決済・レート制限のようにセキュリティや可用性に直結する箇所については、生成コードをそのまま採用せず、必ず既存のコードレビュー基準を通す運用にすべきです。
これは導入パターンに関わらず共通の判断基準です。
あえて見送るべき条件
モノレポの規模が大きく、使用中の言語サーバーが横断的な参照解析に時間がかかる、または精度が不安定な場合は、エージェント型の全面導入は見送るべきです。
まずは自分たちのIDEやCIで、言語サーバーの応答速度と精度を確認してから判断するのが安全です。
チームにAI生成コードをレビューする時間的余裕がない場合も、導入拡大は見送るべき条件に入ります。
生成速度だけが上がり、検証フェーズがボトルネックとして残るなら、リードタイム全体は短縮されません。
監査要件が厳しい業界（金融・医療など）でコード生成の説明責任が求められる場合、フルオート運用は避け、生成過程を人間が追跡できる運用に留めるべきです。
導入前に確認すること
判断のスタート地点は、実際のプロジェクトで「検証コスト比」を小さく測ってみることです。
AIに書かせた関数と、同等の複雑さを持つ既存コードのレビュー時間を比べれば、自分たちの領域での比率が見えてきます。
次に、使用中の言語サーバー（TypeScript Language Service、Pyright、gopls など）が、実際のリポジトリ規模でどこまで正確に参照解析できるかを、IDEのGo To DefinitionやFind Referencesの応答で確認してください。
最後に、セキュリティや可用性に関わる箇所については、AIコーディング支援ツールの適用範囲から意図的に外すか、レビュー体制を強化する運用ルールを先に決めておくことが、技術的負債を増やさない導入の前提になります。