AI開発 第三者コンポーネント利用の開示台帳
AI受託開発で使うOSSや外部APIなど第三者コンポーネントを、セキュリティ・法務・開発が開示台帳で管理する項目、確認、費用の見方を整理します。

結論
AI受託開発で使うOSS、外部API、商用ライブラリ、外部モデルなどの第三者コンポーネントは、納品後に把握するのではなく、開発中から開示台帳で一覧化することが重要です。セキュリティ、法務、開発担当が、構成一覧(SBOM)、ライセンス条件、脆弱性情報を台帳に集約すると、ライセンス違反や脆弱性の見落としを防げます。
この記事は、「何が使われているか分からない」まま納品を受けてしまう発注者向けに、第三者コンポーネントを開示させ管理する台帳の作り方をまとめます。台帳がないと、ライセンス制約や脆弱性への対応が後手に回ります。
開示台帳とは何を管理する資料か
開示台帳とは、成果物に含まれる第三者コンポーネントを、名称、バージョン、ライセンス、用途、提供元とともに一覧化した資料です。ベンダーの技術選定を否定するためではなく、発注者が権利と安全の観点でリスクを把握し、対応を判断するための資料です。
台帳を作る前に、開示の対象範囲(直接依存だけか推移的依存も含むか)、更新頻度、確認の担当を契約で合意します。開示義務を契約に書いていないと、詳細を出してもらえないことがあります。
開示項目の対応表
台帳には、コンポーネントごとに次の項目を記録します。表は自社のリスク観点に合わせて調整します。
| 開示項目 | 内容 | 確認のポイント |
|---|---|---|
| 名称・バージョン | 使用しているOSS/API/ライブラリ | バージョンが特定されているか |
| ライセンス | 適用ライセンス種別 | 再配布・公開・改変の条件 |
| 用途 | どの機能で使うか | 中核か補助か、代替可能か |
| 提供元・保守状況 | 提供元、更新頻度 | 保守が継続しているか |
| 既知の脆弱性 | 公表された脆弱性 | 対応状況、影響の有無 |
表で項目を並べるだけでなく、ライセンス条件が自社の利用形態(社内利用、外部提供、再配布)と両立するかを文章で確認します。特に、コピーレフト系ライセンスは公開義務が生じる場合があり、成果物の権利と関係します。外部APIや外部モデルは、データの送信範囲と利用規約も確認します。
開示運用と承認の進め方
台帳は、開発中から更新し、検収時に最新版を受け取ります。コンポーネントの追加・更新があれば台帳を改訂し、改訂日を記録します。ライセンスや脆弱性に問題があるコンポーネントは、代替や対応を協議し、判断を記録します。契約で、開示義務、更新義務、脆弱性発見時の通知義務を定めておきます。
データ・セキュリティ・ログの扱い
外部APIや外部モデルを使う場合、どのデータが外部へ送信されるか、送信先の保存・学習利用の有無を確認します。入力してよい情報と禁止情報を、外部連携ごとに整理します。脆弱性情報は継続的に監視し、対応状況を台帳に記録します。個人情報を外部へ送る場合は、委託や第三者提供の扱いを確認します。
費用と保守の見方
第三者コンポーネントは、商用ライセンス料、外部API利用料、保守や更新の費用が継続的に発生します。台帳で費用が発生するコンポーネントを可視化すると、運用コストを見積もれます。保守が止まったコンポーネントは将来のリスクになるため、代替の検討費用も見込みます。ライセンス違反の是正費用は大きくなり得るため、事前確認の価値が高いです。
実務チェックリスト
- 開示の対象範囲(推移的依存を含むか)を契約で決めたか
- 名称・バージョン・ライセンス・用途を台帳に記録したか
- ライセンス条件が自社の利用形態と両立するか確認したか
- コピーレフト系の公開義務の有無を確認したか
- 外部APIやモデルへのデータ送信範囲を確認したか
- 既知の脆弱性と対応状況を記録したか
- 台帳の更新義務と脆弱性通知義務を契約で定めたか
- 継続費用(ライセンス・API・保守)を可視化したか
チェックリストは、契約時、コンポーネント追加時、検収前に確認します。開示台帳を最新に保つと、脆弱性対応やライセンス確認がすぐにできます。
図解で確認するポイント
この記事の画像は、第三者コンポーネントを一覧化し、ライセンスや脆弱性の観点で確認する流れを、複数のカードと接続線で表しています。文字や宣伝を入れず、どの項目を台帳で管理するかを視覚的に確認できるようにしています。
AllAI内での次の行動
まず AI発注診断 で外部連携の想定を整理してください。関連する実務は AI開発 成果物IP帰属の契約別紙チェック と AI開発 セキュリティ指摘の是正完了証明 で確認できます。開発会社の比較は AI開発の発注支援、既製サービスの選択肢は AI/SaaS比較 も合わせて確認します。
FAQ
Q. 第三者コンポーネントの開示はどこまで求められますか? A. 契約で範囲を決めます。直接依存だけでなく、推移的依存(依存先が依存するもの)まで求めるかを合意しておくと網羅性が上がります。
Q. OSSを使うと自社の成果物の権利はどうなりますか? A. OSSのライセンスに従う必要があり、コピーレフト系では公開義務が生じる場合があります。利用形態と両立するかを台帳で確認します。
Q. 外部APIの利用で注意することは何ですか? A. どのデータが外部へ送信され、送信先で保存や学習に使われるかです。入力禁止情報を整理し、利用規約を確認します。
Q. 脆弱性はどう管理しますか? A. 台帳で既知の脆弱性と対応状況を記録し、継続的に監視します。契約で脆弱性発見時の通知義務を定めておくと対応が速くなります。
出典と確認日
- 独立行政法人情報処理推進機構(IPA)「AIセキュリティ」: https://www.ipa.go.jp/security/ai/index.html (確認日: 2026-07-10)
- 独立行政法人情報処理推進機構(IPA)「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
- 文化庁「著作権制度に関する情報」: https://www.bunka.go.jp/seisaku/chosakuken/ (確認日: 2026-07-10)
関連する記事・ガイド
- AI開発会社ガイドBest-of-N: OpusAI開発 本番KPI未達時の契約見直し会議
AIシステムの本番KPIが未達のとき、事業責任者・PM・調達が開く契約見直し会議の論点、証跡、判断、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 検収後クレームの紛争証跡ワークフロー
AI受託開発の検収後にクレームや紛争が起きたとき、法務・PM・経理が証跡を整理するワークフロー、紛争段階、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 障害時ベンダー連絡のエスカレーション表
AIシステムの障害時に、運用・情シス・ベンダーが使うエスカレーション表の作り方、連絡基準、証跡、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 運用マニュアル検収の版管理
AI受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。