Copilot が書いたコード、所有権は誰に？ エンジニアリングチームが見落としがちなガバナンスのギャップ

エンジニアがクライアントのサイト用コードを作成するために Copilot を開く。数秒で、手作業で書くよりはるかに時間がかかっていたコードが提示される。多くのウェブ開発者やサイト最適化を行う企業にとって、次のように考えるのは普通だ：そのコードは信頼できるか？安全か？実装前にレビューすべきか？ これらの質問はすべて、AI 支援コーディングの責任は誰が負うのか、そして最も重要なことは、生産性向上の所有権は誰にあるのか、という一つの問いに集約される。

AI がエンジニアリングチームに同じ時間でより多くの作業を完了させることを可能にすれば、その経済的価値はすべての関係者にとってより大きな利益となる。開発者が時間を節約できること、雇用主が節約した時間からより多くの価値を得られること、あるいはクライアントが余裕のある時間で支払った分を受け取れることが考えられる。節約した時間がどのように活用されようとも、最も重要なのは作業のガバナンスと価格設定である。

AI とコーディングは避けられないものとなりつつある

AI コーディングツールは急速に普及し、主流の開発へと浸透しつつある。 2025 Stack Overflow Developer Surveyによると、回答者の84%が開発プロセスで AI ツールを使用中、または使用予定であることが分かった。

ウェブ開発者のワークフローに AI を導入することは一般的になりつつあるが、その信頼性については依然として躊躇がある。同じ調査では、46% が AI の出力精度に完全な自信を持っておらず、約66% が「ほぼ正しいが完全ではない」AI ソリューションに不満を抱いていることが明らかになった。

形成されつつある AI コーディングに関する議論は、コードがより価値を生むかどうかやその保証責任者よりも、むしろその信頼性に関するものが中心である。

AI が時間と成果の関係を崩す

ソフトウェア開発の報酬は常に、エンジニアリングの成果がエンジニアリングの労力と密接に関連しているという前提に依存してきた。しかし、生成 AI がその等式を複雑にしている。

95 人の開発者を対象とした統制実験で、GitHub Copilot にアクセスできた参加者は、特定の JavaScript HTTP サーバー課題を、アクセスできなかった者よりも55.8%速く完了したことが判明した。

この結果は、AI が開発を加速させ、品質を犠牲にしない可能性があることを示している。ただし、これらの数値は実験が非常に特定のプログラミング課題に限定されていたために得られたものである。課題は確かに速く完了したが、Copilot が組織全体の生産性を55.8%向上させることを意味するわけではない。

別の研究がこの考えを例証している。 96 名のフルタイム Google ソフトウェアエンジニアを対象とした試験では、AI を使用した開発者はエンタープライズ向けタスクを約96 minutesで完了したのに対し、使用しなかった者は114 minutesかかったことが判明した。研究者の調整後の推定では、完了時間が約21% reduction in completion time短縮されたことを示唆している。しかし、本研究は AI コードの品質を検証せず、技術への依存に関する公平性の問題にも触れていない。

AI がコーディング時間を遅くする証拠もある。 ランダム化研究では、16 人の経験豊富なオープンソース開発者が、よく知っているリポジトリの 246 件の実案件に取り組んだ。2025 年初頭に利用可能だったツール（Claude Sonnet 3.5・3.7、Cursor Pro など）を使用した結果、タスク完了に約19%余分に時間がかかり、多くの人がこれらのツールで時間が節約できると想定していたにもかかわらず、逆に遅くなったことが示された。

これらの研究は、AI が開発者の作業を速めるという期待を覆す。むしろ、ウェブ開発を提供する企業やそのクライアントにとって、開発者の時間と価値が予測しにくくなっている。

誰も語らない価格問題

Time & Material（T&M）は、ソフトウェア購入においてウェブ開発で一般的なモデルであり、繰り返し発生する業界課題、すなわち変化し続けるプロジェクトに対応する。

このモデルでは、開発開始前にすべての機能やタスクを定義する必要はなく、プロジェクトが進行・変化するにつれてエンジニアリング時間に対して支払うことができる。

しかし、AI はこの実績あるモデルに障害をもたらしている。報酬がエンジニアリング時間に直結しているため、開発が効率化するとクライアントの請求可能時間が減少する可能性がある。AI が同等の成果を短時間で実現すればクライアントに価値を提供できるが、請求時間の減少は提供者の収益減少を意味する。

解決策は開発者に作業を遅くさせることではない。T&M モデルは現在、価格設定とインセンティブの設計に構造的な課題を抱えている。時間単価で価値を測ることは限界がある。購入者はエンジニアリング時間の単価は正確に把握できても、望む成果を得るために必要な総投資額については不確実なままであることがある。

AI がエンジニアリングの生産性を変えるにつれ、質問は次のように変わるかもしれない：

• 「開発者1時間のコストはどれくらいか？」→「開発者時間が少なくなると価値はどう変わるか？」

METR の調査結果はこの質問をさらに複雑にする。開発者が実際には時間がかかるにもかかわらず時間を節約できると信じている場合、AI の導入や認識された生産性向上だけでは財務的価値を示すには不十分である。だからこそ、組織は実際に起きたことを測定できるガバナンスが必要になる。

ガバナンスのギャップには4つの所有者がいる

AI 支援開発に関するガバナンスを議論する際は、開発者が使用できるツールを規定するポリシーだけにとどまってはならない。
エンジニアリング組織が定義すべき所有権は少なくとも4種類ある。

1. コードの所有権は誰にあるか？

AI は実装を生成できるが、責任のない開発の口実にはなり得ない。コードが本番環境に到達するまで、レビュー・テスト・承認に対して責任を持つ人物が必要である。

2. リスクの所有権は誰にあるか？

高速なコードは、他の箇所で問題を引き起こさない限り価値がある。 AI 生成コードに関する実証的研究では、対象とした Python スニペットの 29.5% と JavaScript スニペットの 24.2% にセキュリティ上の弱点があることが判明した。また、43 の Common Weakness Enumeration カテゴリにまたがる弱点も特定された。

しかし、研究では、静的解析の警告を Copilot Chat にフィードバックすることで、特定されたセキュリティ問題の最大55.5% を修正できることが分かった。この研究は、AI がコーディング上の問題を生み出し解決できることを示す一方で、組織はその出力を検証するプロセスを整備する必要があることを示唆している。

NIST’s SP 800-218Aは、生成 AI とデュアルユース基盤モデルに対応するベストプラクティスを組み込んだ Secure Software Development Framework を拡張することで、この原則を反映している。

3. 生産性向上の所有権は誰にあるか？

商業契約を最初から明確にすることは、効率向上の受益者を決定する上で不可欠である。AI はクライアントの支出を削減したり、チームがより多くのソフトウェアを提供できるようにしたり、プロジェクト終了時に金銭的利益をもたらさない場合もある。

変わらないのは、透明性のあるプロセスと合意された品質の作業を提供する必要性である。

4. 優先順位付けの所有権は誰にあるか？

AI は機能の生成を安価かつ迅速にできるが、それらの機能が必要かどうかを判断することはできない。

実際、開発能力が向上すると優先順位付けの重要性が増す。チームがより速く構築・実験できるようになると、利用可能な予算を正当化できる成果と、放棄すべきアイデアを誰かが決定しなければならない。

AI ガバナンスが財務課題になる

これらの質問は AI ガバナンスの重要性を高める。時間単価が似通った2つの開発パートナーを想像してみよう。

一方は AI を堅牢なエンジニアリングプロセスに統合し、必要な成果を格段に速く達成するが、もう一方は時間がかかる。時間単価だけを比較しても、購入者は実際にどのようなプロセスが行われるかについてはほとんど分からない。

購入者は次の点を評価する必要がある：

• 総期待投資額
• 超過費用の責任
• AI 生成作業に対する品質管理
• 効率向上の分配方法

T&M は、両者がサービスの不確実性を認識した上で受け入れるのであれば、依然として有用である。要件や成果物が安定している場合、固定価格の契約も機能する。

しかし、AI は代替的な構造を検討する価値ももたらす。一つのアプローチは、スコープは柔軟に保ちつつ最大財務上限を設定することだ。その上で、機能はビジネス価値に基づいて優先順位付けできる。

エンジニアリングがより効率的になると、得られる成果は追加の請求時間ではなく、製品機能の拡張に転換できる。商業的インセンティブはエンジニアリングのインセンティブと同様の結果を促すべきであり、できるだけ効率的により有用なソフトウェアを創出することを目指すべきである。

同じ AI の議論

エンジニアリングリーダーは、商業的インセンティブがデリバリーにどのように影響するかを理解する必要がある。財務・調達チームは、AI 支援エンジニアリングが主張された効率性を測定可能な価値として実現しているかを評価できるだけの可視性を必要とする。

つまり、成熟した AI ガバナンスは、承認済みモデルリストやセキュリティ制御、データポリシー、コードレビュー要件で止まってはならない。責任、財務リスク、優先順位付け、そして生産性向上の所有権にまで対処する必要がある。

しかし、テクノロジー予算にはるかに大きな影響を与える第二の所有権の質問がある：AI がソフトウェアの構築速度を変えるとき、創出または喪失した価値の所有権は誰にあるのか？

高速なエンジニアリングが実際により良い製品を生み出し、投資をコントロールし、測定可能なビジネス成果を達成できるかを判断できる組織こそが、競合他社に先んじることができるだろう。

もし明日、開発チームが AI を導入したとして、現在のガバナンスや商業モデルは、その導入がデリバリーに価値をもたらしたかどうかを教えてくれるだろうか？