INSIGHT
AI生成コードを会社で使う前に——出所と利用条件を引き継ぐ
どの版に何が入っているか、利用条件を確認できる記録をどう渡すか。
AIを使って短期間で作った社内ツールを、顧客にも配布する話が出た。開発担当は「コードはAIが生成したので、既存製品をコピーしたわけではありません」と説明する。一方、画面の裏では複数の外部ライブラリが動いている。何を確認済みとし、どこを法務や知的財産の担当へ渡すべきでしょうか。
「AIが書いた」は作成方法の説明です。コードや素材の出所、組み込んだ部品、配布や改変の条件を確認した結果ではありません。作成者を疑うのではなく、会社が使い続けられる記録として、自分で分かったことと未解決を残し、受け取ったコードでも同じ記録を確かめます。
生成した部分と、組み込んだ部品を分ける
アプリケーションには、自社で書いたコード、AIが出したコード、外部のライブラリやサービス、画像・フォントなどが含まれます。依存部品は、仕組みが動くために取り込む外部の部品です。AIが生成した短いコードでも、外部部品を呼び出していることがあります。
最初の一覧には、次を並べます。
- 部品やサービスの名称、版
- 入手先と確認日
- 仕組みのどこで使うか
- 社内利用だけか、顧客へ配布・提供するか
- 利用条件を確認した資料
- 分からない点と、確認する担当
この一覧は、生成経緯を完全に証明するものではありません。確認対象を見つけ、担当交代や更新時に同じ部品へ戻るための入口です。自社で書いた部分、外部部品、顧客から預かったコードを混ぜず、分からない欄を推測で埋めません。
「AI生成」という一つの箱をやめ、実際に配布・実行するコードと部品を名前と版で確認します。
ライセンス確認は、個別の法的結論と分ける
ライセンスは、コードや素材を利用する条件を示す取り決めです。利用、改変、配布、表示、ソース提供などの条件は部品ごとに異なり得ます。ライセンス名を一覧へ書くだけでなく、自社の使い方に関係する条件を確認します。
文化庁のAIと著作権に関する公開資料 は、学習、生成、利用、生成物の著作物性、他者の権利侵害を分けて考える資料を提供しています。個別コードについて侵害の有無を決める法的判定でも、新しい拘束的なルールでもありません。類似検索で一致が出なかったことだけで、権利上の問題がないと保証することもできません。
開発側は、部品、版、入手先、確認した条件を示す。業務側は、社内利用、顧客提供、販売、改変など実際の使い方を示す。法務・知的財産の担当は、未解決の条件を個別の利用と契約に照らします。「適法ですか」とコード一式を丸ごと渡す前に、問いを部品と利用場面へ分けます。
自分で作った場合も、受け取った場合も、その版の記録をそろえる
自分で作った場合は、いま渡す版に入った部品、利用条件の資料、未確認の点を記録します。外部や別部署から受け取った場合は、同じ項目を作成者へ尋ねます。どちらも「確認済み」の一語ではなく、何をどの資料で確かめたかまで結び付けます。
社内開発でも同じ受領表を使います。作成者の記憶だけに置くと、担当交代や更新時に確認をやり直せません。新しい部品を追加した、版を上げた、社内利用から顧客提供へ変えたときに、どの欄を更新するかを決めます。
OpenChainのライセンスコンプライアンスに関する資料 は、オープンソースの利用条件を扱う組織の役割、プロセス、継続性を考える参考になります。規格への適合が個別部品の遵守を保証するわけでも、AI生成コード専用の義務でもありません。確認を個人の記憶から組織の受渡しへ変える材料です。
受領するのは「問題なし」という結論ではなく、確認した部品、根拠、残る問い、次に更新する人です。
公開判断は、動作と利用条件を別の欄にする
動作試験に合格したことと、配布・改変の条件を確認したことは別です。公開前の資料では、機能の試験結果と、出所・部品・利用条件の確認結果を二つの欄に分けます。
NISTのSecure Software Development Framework 1.1 は2022年の最終版で、設計、レビュー、実行コードの検証、部品の来歴、公開後の脆弱性対応などを扱います。AI生成コード専用の枠組みではなく、AIで作ったコードへどう当てはめるかは編集上の応用です。全項目の一律適用や、個別製品の品質保証を意味しません。
公開を判断する担当は、確認結果を基に次の三つから選びます。
- 確認済みの部品と配布範囲で公開する
- 不明な部品を外す、または社内利用に必要な条件を確認できた範囲に限定する
- 顧客への配布条件や重要部品の出所を確認できるまで、その範囲を保留する
すべての由来を完全に証明できる、と宣言することがゴールではありません。会社が実際に行う配布・改変について、確認済みと未解決を説明できる状態をつくります。
社内利用なら無条件で使える、という意味ではありません。利用自体の許諾や有料契約、表示などの条件が残る場合があります。社内試用も含めて条件が分からなければ、その部品を使う範囲を保留します。
変更時に、一覧を更新する人まで決める
公開時に一覧を作っても、部品は更新され、利用範囲も変わります。版を上げたとき、新しい依存部品が増えたとき、顧客提供を始めるときに、誰が一覧と利用条件を見直すかを決めます。
会議では、たとえばこう合意できます。
「顧客へ配布する機能に含まれる部品名・版・入手先を開発担当が一覧にする。ライセンス資料と未解決事項を法務へ渡し、顧客契約と配布方法を照合する。配布条件が未確認なら顧客提供を保留し、社内試用についても必要な条件を確認する。部品追加・版変更・配布先変更の際に一覧を更新し、製品責任者が公開範囲を決め直す」
出所と利用条件の確認は公開前の一回ではなく、部品と使い方が変わるたびに引き継ぐ仕事です。
公開前に、その版の部品・配布先・利用条件を確認した記録を渡す
AIでコードを速く作れたことは、開発の成果です。会社が使い、配布し、改変するには、実際の部品と利用条件を別に確認します。
自分が作った、または受け取った一つの版について、部品・入手先・使い方を並べてください。条件が分からない部分は法務や開発の担当へ質問し、必要な許諾が確認できない利用は保留します。自分の制作記録を次の担当が読める形へ残すことから始められます。