生成AIをコーディングに活用する際の法務リスクと対応策

近年、ChatGPTやGitHub Copilotといった生成AIツールがソフトウェア開発現場で急速に普及しています。コードの自動補完やバグ修正提案など、これらのツールは開発効率を飛躍的に向上させる一方で、法律面での新たなリスクも生じています。

特に、企業のシステム開発部門では、機密情報の漏えいや著作権侵害、個人情報の取扱いなどについて慎重な対応が求められます。本記事では生成AIを業務のコーディング支援に利用する際の主な法務リスクとその対応策を解説します。

機密情報・営業秘密の漏えいリスクと対策

社内の機密情報や顧客の営業秘密を誤って生成AIに入力してしまうと、情報漏えいに直結するリスクがあります。実際に韓国Samsung社では、社員がChatGPTにソースコードや会議記録など社内機密データを入力してしまい、3件の情報流出事故が発生しています。

このケースでは、エンジニアがバグ解決のために社内プログラムのコードをそのままChatGPTに送り、また別の社員は会議の録音データをテキスト化して議事録作成を依頼するなどし、結果的に社外秘情報が外部サービスに渡ってしまったという事例です。

このような事例からも明らかなように、生成AIに内部情報を入力すること自体が情報漏えいの契機となり得ます。

生成AIの多くはクラウド上の外部サービスとして提供され、入力データがサービス提供者側に送信・保存されます。例えばOpenAI社は、ユーザーの入力内容を今後のモデル学習に利用する場合があります。そのため、一度入力した機密情報が学習データに取り込まれ、不特定多数への出力を通じて流出する恐れがあります。OpenAI自身も「ChatGPTに機密情報を入力しないように」とユーザーへ注意喚起しています。

企業の対策

対策: 機密情報の漏えいを防ぐためには、まず「機密情報は生成AIに入力しない」ことを徹底する社内ルール作りが重要です。開発者が誤ってソースコードや設計書などを入力しないよう、具体的な禁止事項を定めて周知してください。

どうしても生成AIで社内データを扱う必要がある場合は、匿名化やマスキングを施したり、ダミーの値に置き換えるなどして特定の内容を伏せる工夫が求められます。また、社外クラウドの代替として社内設置型のLLM（Large Language Model）やオンプレミス版ChatGPT等の導入を検討し、データが社外に出ない環境下でAI活用するのも有効です。

例えば、ソースコードをAIにレビューさせたい場合でも、インターネット接続されていない社内サーバ上のモデルで実行すれば漏えいリスクは格段に下がります。

生成AIサービス提供企業との契約・利用規約を確認

さらに、利用する生成AIサービス提供企業との契約・利用規約を確認し、入力データの取り扱いについて合意事項を把握しましょう。企業向けプランでは「入力データは学習に使用しない」というオプションを選択できるものもあります（OpenAIのChatGPT EnterpriseやGitHub Copilot Enterpriseなどは、ユーザーデータを学習に利用しないポリシーがあります）。

こうした「学習オプトアウト（学習無効化）」設定が提供されている場合は必ず有効化し、AI提供者側にも機密保持を担保させることが大切です。また、社内プロキシサーバでAIサービスへのアクセスを一括管理し、ログを記録・監視することで、不適切な利用がないかチェックする運用も検討してください。

個人情報保護法上の注意点

生成AIの利用においては、個人情報の取扱いにも細心の注意が必要です。例えば、ソースコード中に含まれる利用者名やメールアドレスなどの個人データ、あるいは顧客データベースの内容などをプロンプトに含めてしまうと、それだけで「個人データを第三者（AI提供者）に提供した」と評価される可能性があります。

日本の個人情報保護法では、個人データを第三者に提供するには原則として本人の同意が必要であり（法27条）、提供先が外国にある場合は追加の規制（法28条：越境移転の制限）がかかります。

生成AIの提供主体であるOpenAI社などは海外事業者であるため、利用者が個人データをChatGPT等に入力することは、本人同意なく外国の第三者へ提供した行為とみなされ、法律違反となるリスクがあるのです。

個人情報保護委員会の注意点

2023年6月、個人情報保護委員会（PPC）は「生成AIサービスの利用に関する注意喚起」を公表し、企業が留意すべき点を示しました。

まず利用目的の範囲内での利用です。既に取得済みの個人情報をAIに入力する場合、その利用が当初特定した目的の範囲内か十分に確認するよう求められています。

例えば、顧客から商品購入時に得た個人情報を、社内でChatGPTに入力して別の分析に使うのは、本来の「購入手続き」の目的を逸脱しているかもしれません。その場合、目的外利用となり違法となる可能性があります。どうしても別目的で個人データをAI活用したい場合は、仮名加工情報（個人情報を特定できないよう加工し社内利用する枠組み）を活用して目的変更する、といった対応も検討すべきでしょう。

生成AI提供者による入力データの機械学習利用の有無

次に指摘されたのが、生成AI提供者による入力データの機械学習利用の有無です。

もし企業が本人同意なく個人データを入力し、そのデータがAI提供者側で回答生成以外の目的（モデル再学習など）に使われた場合、提供企業は個人情報保護法違反に問われる可能性があります。

したがって「個人情報を含むデータを入力するなら、AI提供事業者が当該データを学習用途に使わないと十分確認すること」が強く推奨されています。

具体的には、サービスの利用規約やプライバシーポリシーで「入力データは回答生成以外に利用しない」「一定期間後に削除する」等の記載があるかチェックすること、エンタープライズ向け契約でその点を取り決めることなどが考えられます。

さらに、個人データを海外に提供する場合の越境移転規制にも注意が必要です。法28条では、EUのGDPRに類似した形で、外国にある第三者へ個人データを提供するには本人同意か十分な保護措置が求められます。

OpenAI社のある米国は日本の「十分性認定国」ではありません。そのため、日本企業がChatGPTに個人データを送信するには、本人の同意取得か、もしくはOpenAI社が公表する個人データ保護制度等の情報を本人に提供した上でオプトアウトを認めるといった対応が必要となります。

現実にはこうした手続きを踏むのは困難ですから、原則として個人データは入力しない運用が賢明です。どうしても入力する場合は、「当該データは匿名加工情報または仮名加工情報であり個人データではない」と言えるようにしておく必要があります。

以上のように、個人情報保護法上は「個人情報はむやみにAIに入力しない」ことが鉄則です。どうしても必要な場合でも、本人の同意取得や情報の非特定化、契約上の保護措置など、法の要求するステップを踏むようにしてください。

著作権に関する論点（学習データと生成コード）

生成AIと著作権の問題は大きく2つのフェーズに分かれます。①AIの学習段階と②AIの生成・利用段階です
文化庁のガイドラインでもこの2フェーズに分けて整理が行われています

AIの学習段階における著作物利用

AIは膨大な既存コードやテキストを「学習」することで賢くなります。この学習過程でインターネット上のプログラムコード（当然多くは著作権で保護されたソースコード）を無断で使うのは違法ではないか、と心配されるかもしれません。しかし、日本の著作権法では「情報解析」（著作権法第30条の4）という規定があり、情報解析を目的とする場合には、著作物を権利者の許諾なく利用できると定めています

AIの機械学習はまさにこの「情報解析」に該当すると解されています。そのため、オープンなデータをAIの学習に使うこと自体は原則合法です。

企業がGitHub上の公開リポジトリをクローリングして社内AIを訓練する場合なども、基本的にはこの権利制限規定の範囲内で許されると考えられます。ただし、注意すべき例外も存在します

たとえば、本来有料で提供されているデータセットを不正に入手して学習に使う場合や、著作権者の利益を不当に害する態様でデータを利用する場合には、「情報解析」の適用対象外となり違法と判断される可能性があります

要するに、著作物の市場価値を著しく損なうような学習は認められないということです。また、学習済みモデルが特定の著作物（コード）をそのまま復元できてしまう状態も問題になります。文化庁のガイダンスによれば、もしAIが学習データと「極めて類似したコード」を高確率で生成できるような場合、その学習済みモデル自体が著作物（学習元コード）の複製物と評価され、権利者からモデルの廃棄請求を受け得るとも指摘されています。

このため、AI開発者側では学習時に特定コードを暗記・再現しないような技術的措置（類似コードをそのまま出力しないフィルタリング等）を講ずることが推奨されています。

実際、GitHub Copilotの開発元であるMicrosoftやOpenAIも、大量のオープンソースコードを学習に使う代わりにフィルタを実装し、学習データと一定以上一致するコードは提案しない仕組み（Public Code Filter）を提供しています。

企業としては、こうした措置が講じられたAIツールを選定することが望ましいでしょう。

生成物（コード）の著作物性と既存コードとの類似

次にAIが生成したコードそのものの著作権上の取扱いです。まず押さえておきたいのは、AIが出力したコードに著作権は原則として認められないという点です。著作権法は「人間の創作的表現」にのみ保護を与えるため、完全にAIのみで生み出されたコードは「人間による創作的寄与」がない限り著作物ではありません。

言い換えれば、人手を介さずAIが生成したプログラムについては、それ自体は法律上の保護対象外となり得ます。（実際は、AIが出力したコードを人間が取捨選択・編集して完成させるケースが多いため、著作物に該当することが多いと思いますが、少なくともAI単独で作成された部分は著作権が発生しません。）

この点は、将来自社のコード資産を守る上でも留意が必要です。仮にAIが生成した画期的なアルゴリズムを自社プロダクトに組み込んだとしても、その部分には著作権が及ばず、他社に模倣されても著作権侵害で訴えることはできない可能性があります。

著作権侵害になる場合

次に、生成物が既存の誰かのコードと酷似している場合のリスクです。AIの回答生成段階では「類似性」と「依拠性」という2つのキーワードが重要になります

簡単に言えば、(a) 出力コードが他人のコードとどれだけ似ているか（類似性）と、(b) AIがそのコードを元にした可能性があるか（依拠性）の有無です。この両方が認められるとき、著作権侵害と判断されるます。

例えば、Copilotが提案したコードがあるOSSライブラリの実装とほぼ同一で、さらにそのOSSが有名でAIが学習していたと推認できる場合、類似性・依拠性ともに肯定され、それを自社ソフトに組み込んで公開すれば、結果的に著作権侵害やライセンス違反を問われるリスクがあります。

文化庁のガイドラインでも、生成物を利用する段階では利用者が「既存の有名な作品（コード含む）に似すぎていないか目で確認する」ことが推奨されています

これはコード開発においても同様です。生成AIが出力したコード断片をそのまま受け入れるのではなく、開発者自身が既存のコードとの類似をチェックし、必要に応じて書き換えるプロセスが不可欠です

開発契約書に盛り込むべき「生成AI利用」条項例

システム開発を他社に委託する場合や、受託開発を請け負う場合、契約書に生成AIの利用に関する条項を定めておくことが望ましいです。生成AIの活用が一般化するにつれ、「開発ベンダーがAIを使って作業したコードに問題があったらどうするのか」「クライアントの機密情報をAIに入力しないか」といった懸念が生じるため、あらかじめ契約でルールを明確にする動きが出てきています。

条項に盛り込むべきポイント

機密保持義務との関係

受託者が生成AIを利用する場合でも、発注者の秘密情報を外部AIサービスに入力しないことを明記します。「受託者は、本契約上知り得た甲の秘密情報を、OpenAI社等の第三者が提供する生成AIサービスに入力してはならない」といった文言が考えられます。仮に利用する場合でも、事前に書面で許諾を得ること、入力内容を必要最小限に限定することなど条件を付すと良いでしょう。

生成物の品質・責任

AI生成コードが混入することで生じうる不具合や権利問題に対する責任の所在を定めます。

例えば「受託者は、生成AIを活用して成果物を作成する場合であっても、成果物が契約仕様を満たし第三者の権利を侵害しないことを保証する。万一AIの生成物に起因して第三者から権利侵害の主張がなされた場合、受託者が自己の費用と責任でそれを解決する」等の条項です。実際には受託者側がリスクを負いすぎないよう、責任限定の取り決めも必要でしょう

たとえば「ただし受託者は商用に十分利用可能なAIツールを用い業務を誠実に履行した場合には、この保証責任を負わない」等の免責条件を付すなどバランス調整が考えられます。

AI利用の開示と範囲:

発注者が成果物中にAI生成物が含まれることを懸念する場合、「受託者は成果物の作成にあたり生成AIを用いた場合には事前にその旨を甲に通知し、甲の指示があれば代替手段による実装に切り替える」等の条項も考えられます。また、利用するAIツール名やバージョン、利用範囲（例えばコーディング支援のみに使用し設計には使用しない等）を契約書の特記事項で取り決めるケースもありえます。

権利帰属と著作表示

AI生成物には著作権がない可能性もありますが、契約上明確にしておくことが望ましいです。「生成AIを用いて作成した成果物についても、本契約の著作権帰属条項に従う」としつつ、仮にAIが既存OSSコードを生成した場合の扱い（例：その部分は該当OSSライセンスに従う）なども触れておければ理想的です。

トラブル事例から学ぶ対処法

最後に、いくつか具体的なトラブル事例を振り返りながら、事故を未然に防ぐヒントを整理します。

事例1: 機密コードの流出（Samsung社）

前述のSamsung社のケースでは、ChatGPT許可からわずか20日間で複数の機密漏えいが起き、大きな問題となりました。

この事例からの教訓は、「ルール整備前に安易に便利ツールを解放しない」ことです。Samsung社は当初ガイドラインが不十分なまま社員に利用を認めてしまったため、想定外の情報まで入力されてしまいました。
対策として、まず試験的導入期間を設けて少人数で運用検証し、リスクを洗い出してから全社展開することが重要です。また、万一漏えいが発生した場合でもログ調査などで迅速に把握できるよう、平時からの監視体制を作っておく必要があります。

事例2: CopilotによるOSSコード提案

一部報告では、GitHub Copilotが著名なアルゴリズムのコードをそのまま出力した例があります（例えば有名なソートアルゴリズムの実装が数行単位で一致した等）。幸いそれがパブリックドメインのコードであれば問題ありませんが、GPLライセンスのコードだったらと思うとゾッとします。

この事例の教訓は、「AI提案コードでも、出典不明なものは鵜呑みにしない」ことです。ちょっと高度すぎる解答が出てきたら警戒し、自力で再実装するくらいの慎重さが求められます。また、GitHubは企業向けに提案コードの出典参照機能を提供しています。

Copilot for Businessでは類似オープンソースの情報を表示できますので、そうした機能は積極的に活用しましょう。

事例3: ChatGPTからの誤情報拡散

生成AIはしばしば事実ではない回答をもっともらしく返します。過去には、とある法律相談で弁護士がChatGPTの生成した判例を引用したところ、実は存在しない架空の判例で裁判所に注意された、という事例もありました。

技術分野でも、AIの提示したコードが非効率だったりバグを含んでいたりすることがあります。この事例の教訓は、「AIのアウトプットは必ず人間が検証する」ことです。特に新人エンジニアほどAI回答を盲信しがちなので、コードレビューやペアプログラミングを励行し、人間の目によるチェックを通す運用を徹底してください。

誤ったコードをそのままプロダクションに載せてしまうと重大な障害につながる恐れがあります。