結論

AI開発の納品物は、ベンダーが書いたコードよりも第三者コンポーネント(OSSライブラリ、外部API、事前学習モデル、データセット)の方が体積として大きいのが普通です。この構成部品を発注側が把握していないと、ライセンス違反、脆弱性対応の遅れ、依存サービスの終了という3種類の事故に対して、発注側は打つ手を失います。対策は、納品要件として第三者コンポーネント開示台帳(SBOM相当+AI特有項目)の提出を契約に入れ、保守フェーズでも更新差分を出させ続けることです。台帳は作らせて終わりではなく、四半期ごとの棚卸しで実際に使います。

開示台帳とは何か: SBOMにAI項目を足す

第三者コンポーネント開示台帳とは、納品物に含まれる自社開発以外のすべての部品について、名称、バージョン、提供元、ライセンス、利用条件、用途を一覧化した文書のことです。ソフトウェア部品表(SBOM)の考え方が基礎になり、経済産業省もSBOM導入の手引を公開しています。AI開発では、これに次の項目を追加します。

「ライセンスはすべて適切に処理しています」という回答だけで台帳の提出がないベンダーは、そもそも自社の依存関係を管理できていない可能性があります。RFP段階でサンプル台帳の提示を求めると、管理成熟度の選別になります。

ライセンス確認の観点

台帳を受け取ったら、発注側が最低限確認するのは3点です。第一に、GPL/AGPL系のコピーレフトライセンスが含まれる場合、自社の利用形態(社内利用か、外部提供か、ソース開示義務が発生するか)との整合。第二に、事前学習モデルのライセンス(独自条項を持つものが多い)における商用利用条件、ユーザー数・売上規模の閾値、出力の利用制限。第三に、外部APIの利用規約における入力データの二次利用(モデル学習への利用)の有無とオプトアウト設定です。

判断に迷うライセンスが出てきた場合の相談先(法務、外部弁護士)と判断記録の残し方も決めておきます。「前案件で使ったから大丈夫」という前例主義は、ライセンス条項の版が変わっていると通用しません。台帳にはライセンス文書の版とURLまで記録させてください。

脆弱性対応との接続

台帳の最大の実用価値は、脆弱性公表時の影響範囲特定です。広く使われるライブラリに深刻な脆弱性が出た際、台帳があれば「自社システムに該当バージョンが含まれるか」を数分で回答できます。台帳がなければベンダーへの調査依頼から始まり、その間リスクに晒され続けます。

保守契約には、重大脆弱性(CVSS 9.0以上など基準を明記)の公表から影響調査報告までの期限(例: 3営業日)と、パッチ適用の費用区分(保守内か都度見積か)を書いてください。IPAの「安全なウェブサイトの作り方」や脆弱性対策情報データベース(JVN)を、対応トリガーの参照先として契約に明示する方法もあります。

サービス終了・提供条件変更への備え

外部AI APIと事前学習モデルには、提供終了・料金改定・規約変更のリスクが常にあります。台帳の各行に「代替手段」列を設け、主要な依存先については代替候補と切替工数の見積をベンダーに一度書かせておくと、実際に終了通知が来たときの初動が変わります。特定モデルへの依存が深い設計(プロンプトがモデル固有の挙動に依存している等)は、この列を書く過程で顕在化します。

保守フェーズでの更新運用

台帳は納品時の1回きりでは陳腐化します。運用ルールとして、依存関係を変更するリリースのたびに台帳の差分を添付させ、四半期に1回は発注側が棚卸し(新規追加の承認記録、削除済み部品の確認、ライセンス版の変更確認)を行います。棚卸しは1-2時間の定例作業で済みますが、これを怠ると数年後のシステム更改時に「何に依存しているか誰も知らない」状態に戻ります。更改やベンダー切替の際、この台帳は移行先ベンダーへの最重要引き継ぎ文書になります。

実務チェックリスト

• 開示台帳の提出を納品要件として契約に書いたか
• 台帳にAI特有項目(モデル・API・データセット・ベクトルDB)を含めたか
• RFP段階でサンプル台帳を提示させ管理成熟度を確認したか
• コピーレフト系ライセンスと自社利用形態の整合を確認したか
• 外部APIの入力データ学習利用とオプトアウト設定を確認したか
• 重大脆弱性の影響調査期限と費用区分を保守契約に書いたか
• 主要依存先の代替手段列を記入させたか
• 四半期棚卸しの担当者と手順を決めたか

図解で確認するポイント

この記事の画像は、1つのシステムが多数の外部部品で構成され、それらが一覧表に整理されて確認される構造を文字なしで図解しています。システムの中身を部品単位で可視化することが、リスク管理の前提であることを示しています。

AllAI内での次の行動

権利帰属との関係は成果物IP帰属の契約別紙チェックリスト、セキュリティ評価全体はベンダーセキュリティ質問票ガイドが隣接テーマです。依存の深さはロックイン評価にも直結するためベンダーロックイン出口計画ガイドも確認してください。発注要件の整理はAI発注診断、部品管理を開示できる会社はAI開発パートナーで比較できます。

FAQ

Q. SBOMの標準形式(SPDX、CycloneDX)で求めるべきですか? A. ベンダーがツールで生成できるなら標準形式が望ましいですが、形式より網羅性が先です。標準形式のSBOMにAI特有項目(モデル、API、データセット)が入らない場合は、補足表を追加してもらってください。

Q. ベンダーが「台帳は社外秘」と拒否したら? A. 納品物の構成部品を発注者に開示できない理由は通常ありません。再委託先のノウハウ部分は秘密保持契約の範囲で開示させれば足ります。開示自体を拒むベンダーは、ライセンス管理をしていない可能性を疑うべきです。

Q. 内製の保守チームがいない場合、棚卸しは誰がやりますか? A. 保守ベンダーに棚卸しレポートの提出を義務づけ、発注側は承認だけ行う形でも成立します。ただし新規部品の追加承認だけは発注側判断に残してください。知らない間に依存が増えるのを防ぐ最後の関門です。

Q. 生成AIのモデルバージョンアップも台帳の対象ですか? A. 対象です。同じAPIでもモデル版が変わると出力挙動と料金が変わります。モデル版の変更は台帳更新+変更管理(影響確認テスト)の両方を通す運用にしてください。

出典と確認日

• 経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引」: https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html (確認日: 2026-07-10)
• IPA「情報セキュリティ」: https://www.ipa.go.jp/security/ (確認日: 2026-07-10)
• JVN「脆弱性対策情報データベース」: https://jvn.jp/ (確認日: 2026-07-10)
• 経済産業省「AI・データの利用に関する契約ガイドライン」: https://www.meti.go.jp/press/2018/06/20180615001/20180615001.html (確認日: 2026-07-10)