AIが書いたコードは誰の責任か?企業が直面するガバナンスの空白
GitHub CopilotやCursor、Claude Codeなどを使ったAIコーディングは、多くの開発現場で当たり前になりつつあります。動機は単純で、簡単な指示で速く書けるから。
しかし今、問われているのはそこから先です。本当に開発の効率を上げ、プロジェクト全体の品質に貢献できているのか?組織として適切に管理できているのか?
ツールの導入は進んでも、ガバナンスが未整備な例は少なくありません。「取りあえず動くコードが出力される」ことと、「安全で品質の保証されたコードである」ことは、別の話です。今回の記事では、この辺りを考察してみましょう。
AIコードが抱える5つのリスク
1.セキュリティーの脆弱性
AIは「動作するコード」を優先して生成します。しかし、「安全なコード」かどうかは別の問題。
スタンフォード大学が発表した研究では、GitHub Copilotが生成したコードの約40%に何らかのセキュリティー上の欠陥が含まれていました。SQLインジェクションや不適切な認証処理など、基本的な脆弱性がそのまま含まれるケースも確認されています。
日本では、情報処理推進機構(IPA)が公表した「テキスト生成AIの導入・運用ガイドライン」でも、AIが生成したコードに不十分な設定や脆弱なパターンが含まれるリスクが明示されています。AIはインターネット上の大量のコードを学習していますが、そこには安全でないパターンも無数に含まれています。
▼参照: [2211.03622] Do Users Write More Insecure Code with AI Assistants? ─ Stanford University
https://arxiv.org/abs/2211.03622
2.ライセンスと著作権の問題
AIが生成するコードは、学習データに含まれるオープンソースコードの影響も受けます。GPLなどのコピーレフト型ライセンスのコードが商用製品に混入した場合、ソースコード全体の公開義務が生じるリスクがあります。
2022年に提訴されたGitHub Copilotに対する集団訴訟(Doe v. GitHub)は、この問題を法廷に持ち込んだ最初の事例として注目されました。著作権侵害に関する主要な請求は2024年6月に地裁で棄却されましたが、オープンソースライセンス違反と契約違反の2点については審理が継続。さらに2024年9月には控訴審への移送が認められ、同年12月に控訴裁判所が受理しています。その判断は、AIコード生成ツール全体の法的な扱いに影響する可能性があり、引き続き注目が必要です。
▼参照:
3.品質と保守性の劣化
AIは「取りあえず動く、それらしいコード」を生成することに長けていますが、正確とは限りません。存在しないAPIを参照したり、廃止済みのライブラリを呼び出したりするハルシネーションは日常的に発生します。
より深刻なのは、誰も中身を理解していないコードが積み重なっていく問題です。後々のメンテナンスまでは考えずに乱造されたコードを、人間が後追いで保守・管理するのは非常にストレスフル。多くの場合、チェックできるだけのスキルを持つ特定のエンジニアへの負荷が集中しがちです。
AIが書いてAIがレビューし、人間を実質的に素通りさせる運用が広がると、障害が発生した時に原因をトレースする機能が失われていきます。これは、気づかないうちに組織を蝕んでいく、技術的負債の新しい形と言えます。
4.情報漏洩と「野良AI」の拡大
忙しい情シスに社内発注しなくても、自分の手元で簡単かつ便利にアプリが生成できる時代です。だからこそ、「シャドーAI(野良AI)」の問題は見逃せません。
かつてExcelマクロやRPAが現場の独断で広がったように、今はAIコーディングツールが承認なしに使われるケースが急増しています。ただし、その影響はRPAとは比べものにならないほど深刻です。AIツールへの入力内容が外部サーバーに送信され、学習データに組み込まれる可能性があるからです。
IBMの調査によると、従業員の38%が雇用主の許可なくAIツールで機密情報を共有していると認めています。また、AIツールに入力されるデータの27.4%が機密情報に該当するという報告もありました。現場のエンジニアに限らず全ての従業員が、「情報資産を無条件に扱わない」「プロンプトは社外秘」という感覚を持てているかどうか、組織として適切に教育することが不可欠です。
▼参照:
▼参照:生成AIが情報漏えいを引き起こす?「シャドーAI」のリスクと対策を解説! | NTT docomo Business Watch | NTTドコモビジネス 法人のお客さま
https://www.ntt.com/bizon/shadow-ai.html
5. アカウンタビリティーの空白
自動運転でも指摘される大きな問題ですが、AIが書いたコードにバグが発生したとき、責任はどこにあるのでしょうか?「AIがやった」は免責になりません。開発者か、ツールベンダーか、導入を承認した経営層か…
現行の法制度は、AIを責任主体と見なすことを想定していません。結局、その説明責任(アカウンタビリティー)は企業が引き受けるしかないのですが、その判断基準を持っている組織がまだ少ないのが現状です。
▼参照:自動運転による事故と刑事責任 及び倫理との関係について – 法政大学教授 今井猛嘉 – 日本学術会議
https://www.scj.go.jp/ja/event/pdf3/340-s-0916-s8.pdf
世界の動きと日本の現在地
さて、ここで一旦、マクロな視点で考えてみましょう。
ITサービスを規制するアプローチは、国や地域によって大きく異なります。AIやクラウドサービスがほぼアメリカ主導で進んでいる以上、これらは自社のビジネスが日本国内のドメスティックなマーケットか、グローバルに展開しているかには関係ありません。すべての日本企業が何らかの影響を受けます。
まず、AIで世界をリードするアメリカはNIST AI RMF(AIリスク管理フレームワーク)を軸に、産業界の自主的取り組みを重視しています。GoogleやOpenAI、Microsoftなどビッグテックは社内AI利用ガイドラインを整備・公開していて、法的強制力より実務的なベストプラクティスの積み上げを優先するスタンスです。
一方、EUはリスクベースの法規制を選んでいます。2024年に成立したEU AI Actは、AIシステムをリスクレベルで分類し、高リスクとされるシステムには説明責任と外部監査の義務を課します。コード生成ツールが直接の規制対象かどうかは用途次第ですが、「企業が責任を持つ」という方向性は明確です。
さらに、中国は2023年に生成AIサービス規定を施行し、国家主導で迅速に規制を整備しました。
この三者のアプローチは根本的に異なり、グローバルな統一基準はまだ存在しません。トランプ政権がビッグテックに融和的な政策を進める一方で、EUとの溝が深まっているのは、世界経済フォーラム(ダボス会議)などでもより顕著になっています。
日本企業はアメリカとEUそれぞれの規制への対応を迫られながら、国内の法整備を待つという複雑な立場に置かれています。経済産業省は2024年に「AI事業者ガイドライン」を公表しましたが、法的拘束力はなく、企業の自主判断に委ねられている部分が大きい状況です。
▼参照:
▼NIST AI Risk Management Framework
https://www.nist.gov/system/files/documents/2023/01/26/AI%20RMF%201.0.pdf
▼AI事業者ガイドライン ─ 経済産業省(2024年)
https://www.meti.go.jp/press/2024/04/20240419004/20240419004.html
国や地域よりも小さな範囲でもう一点意識しておきたいのが、特定ベンダーへの依存リスクです。特定のAIプラットフォームへの依存が深まるほど、そのツールのポリシー変更や料金改定が自社の開発体制を直撃します。ワークフローの中で使い込んでいる状態ほど、別のプラットフォームへ簡単には移行できません。
ガバナンスとはセキュリティーや品質だけの問題ではなく、組織としての主体性をどう保つかという問いでもあります。
企業が今、すべき5つのアクション
IT企業かどうかに関わらず、もはやAIコードの利用を禁止することは現実的ではありません。NRIの調査によると、日本企業の57.7%がすでに生成AIを導入済みです。現場への浸透はすでに進んでいるため、必要なのは禁止ではなく、ガードレール付きの活用です。
▼参照:
ここで、日本企業が今すぐ着手できる5つのアクションを挙げます。御社はそれぞれどの程度具体的に進んでいるでしょうか?
1.AI利用ポリシーの文書化
どのツールを、どの用途に、どの情報と組み合わせて使っていいか・ダメかを明文化します。組織として「何となく使っている」リスク状態から抜ける第一歩です。
2. レビュープロセスの見直し
AIが生成したコードを人間がレビューするフローを明示的に組み込みます。自動セキュリティースキャンツール(SonarやSnyk、Aikidoなど)との組み合わせも有効です。
3. ライセンスチェックの仕組みづくり
FOSSAやBlackDuckなどのライセンス管理ツールを導入し、コード混入リスクを継続的に監視するのも有効な手段です。
▼アプリケーション・セキュリティ・ソフトウェア(AppSec) | ブラック・ダック
https://www.blackduck.com/ja-jp.html
4. プロンプトガイドラインの整備
社内情報や顧客情報、ソースコードをAIツールに入力する可否を、情報分類に基づいて定めます。これは「野良AI」対策の核心となります。
5. 担当者または委員会の設置
ガバナンスは文書だけでは機能しません。実際に運用を回す人と、組織としての意思決定の場が必要です。既存のセキュリティー体制を拡張するのが現実的でしょう。
自社で判断軸を持つ、厳しくも必要な姿勢
AIに関する法整備は、世界的にも追いついておらず、大企業でも十分とは言い切れません。標準化の議論は進んでいますが、技術革新と社会情勢の変化スピードは留まるところを知らないため、企業を守るルールが整うまで待てる状況でもりません。
つまり、本来であれば国際機関や国、業界団体などの上位レイヤーで決めるべきことを、個々の組織が判断する必要があるという、非常に厳しい状況にあります。AI活用を野放しにする危険性 vs 禁止することで失われる競争力。AIで生成され続ける膨大なコードをレビューする、エンジニアが疲弊してしまわない体制。特定プラットフォームやベンダーへの依存が、開発体制を直撃するリスク回避。さまざまな条件の間で自社の判断軸を持つことが、企業のDX戦略に求められています。
BlueMemeが提唱する「デジタルエージェントサービス」は、適切に管理されたAIとローコード・ノーコード活用を組織として実装するための考え方です。プラットフォームやツール導入の効果を最大化しながら、ガバナンスの空白を埋めていく─その具体的なアプローチについては、私たち自身が日々、経験を積み重ねています。ぜひ、御社の最適なソリューションについて、一度ご相談ください。
お問い合わせ一覧 | 株式会社BlueMeme










