AIを入れる前に、必ず求める20項目を決める

自社に対し、生成AIのサービスの提案が続いていないでしょうか。どれも良さそうに聞こえます。しかし自社に必要かどうかを判断できる人が、社内にいないかもしれません。

選ぶ前に決めておくのは、相手に何を求めるかです。

政府が事業者に求めるのは、33件の要求事項

デジタル庁が2026年6月12日、生成AIの調達・利活用に係るガイドラインを2.0版に改定しました。初版は2025年5月27日です（同ガイドライン）。

このガイドラインの位置づけは、参考ではありません。原典は「政府情報システムの整備及び管理に関するルールとして遵守する内容を定めたドキュメント」としています。2.0版の内容が施行されるのは、2026年9月1日です（同ガイドライン概要）。

付いている別紙の一つが、調達チェックシートです。原典の説明はこうです。「生成AIシステムを調達する際に、事業者を評価・選定するための項目を整理したものである」（同、別紙3）。

並んでいるのは、評価観点が21、その下の要求事項が33件です。要求事項は「調達仕様書で事業者に遵守を求める内容」と説明されています（同、別紙3）。

評価観点の21は、三つに分かれます。事業者の体制を見る「組織要件」が五つ。作り方と続け方を見る「開発・運用工程要件」が六つ。出てくるものの中身を見る「生成AIシステムの基本機能要件」が十です（同、別紙3）。

33件のうち20項目が、原則として必ず求めるもの

要求事項には、「評価・選定時の項目の分類」が付いています（同、別紙3）。

基本項目の扱いは、原典に書かれています。「調達時に応募者に求める事項として盛り込むことを原則とする」（同、別紙3）。

加点項目は別の扱いです。「必須ではないが考慮した方が良い観点であり、評価項目に含める場合、加点要素とすることを想定とする項目」（同、別紙3）。

求める項目と、加点にする項目が、あらかじめ分けてあります。

中身も具体的です。ベンダーロックインの回避には五つの要求事項が並んでいます。そのうち基本項目は二つです。「利用している生成AIモデルはバージョン情報を含めて明示可能であること」と、「生成AIシステムのアーキテクチャ設計と実装において、ベンダーやシステムの移行の容易性も踏まえた開発や運用が可能であること」（同、別紙3）。

説明可能性の要求事項も一文です。「出力根拠が技術的に合理的な範囲で確認できる状態とするよう対策していること」（同、別紙3）。この一文を、そのまま事業者に求める条件にできます。

条件が付く7項目は、自社の使い方で決まる

残る13項目のうち、7項目には条件が付いています（同、別紙3）。

三つは「不特定外部者（一般国民等）による府省庁外利用の場合」です。出力を人間から発せられた情報と区別できるようにすること、意思決定の不当な誘導を防止すること、有害なバイアスや不当な差別の出力を制限すること（同、別紙3）。

残る四つは、扱うものと求める水準で決まります。個人情報を取り扱う場合、知的財産等を取り扱う場合、生成AIモデルに学習を行わせる場合、そして高い信頼性が求められる場合です。

自社がどれに当たるかは、使い方を決めないと分かりません。先に決めるのは、どの業務に使うかです。

約款に同意しただけでは、要機密情報を扱えない

原典は、約款だけで使うサービスを別に扱っています。「不特定多数の利用者に対して提供され、かつ定型約款や規約等への同意のみで利用可能となるクラウドサービス型の生成AIシステムを業務で利活用する場合には、原則として要機密情報を取り扱うことはできない」（同ガイドライン）。

約款に同意することと、条件を決めることは別です。

導入の類型も三つに分かれています。A は個別開発をせず、約款への同意だけで使う形です。原典は「原則、要機密情報を扱わない想定」としています。B は個別開発をせず、約款への同意に加えて個別契約を結ぶ形。C は個別開発をして、個別契約を結ぶ形です（同ガイドライン）。

A のときにやることも書かれています。調達チェックシートと契約チェックシートの要求事項が不要かどうか、そしてこれらに記載された内容と矛盾がある約款項目がないかを確かめる。矛盾があるなら、B か C の形で発注することを検討するとあります。

契約で決めるのは、入力と出力とノウハウと成果物

もう一つ、契約チェックシートがあります。原典の説明は「生成AIシステムを調達する際に、契約に盛り込むことを検討すべき事項を整理したものである」（同、別紙4）。

取決め事項は9件で、すべて基本項目です（同、別紙4）。

入力については二つあります。インプットそのものと、インプットの処理成果です。原典は、事業者がインプットを自由に利用できる可能性があるため、目的外利用禁止義務として定めるとしています。

出力についても二つです。アウトプットと、アウトプットの処理成果。それぞれ定義、権利帰属、外部提供の条件を決めます。

そしてノウハウがあります。事業者と自社のノウハウを知的財産として定義し、互いの利用条件と権利帰属を決める。原典は「ノウハウの定義に合致しない情報については、適用法令による制限がない限り、事業者がノウハウを自由に利用できる可能性がある」と書いています（同、別紙4）。

残るのは、期待品質を満たす義務、成果物の定義と権利帰属、インシデント発生時の事業者の対応義務、そして期待品質が満たされなくなった場合に原因を特定し改善措置を講じることです。

成果物の項目には、注意が付いています。原典は、生成AIシステムの開発で生成AIモデルそのものが納品物でないときは、システムコンポーネントを納品物として明確にする必要があると書いています。

インシデントの項目には、求める中身が書かれています。被害を最小限に食い止めること、そして原因を特定するための情報やデータの提供。原典はその括弧の中で「具体的には生成AIシステムの学習データやアルゴリズムを含み得る」としています（同、別紙4）。

明日からできること

決めるのは、次に生成AIのサービスを選ぶときに、相手へ何を求めるかです。

まず、いま使っているものがどの類型かを見ます。約款に同意しただけならAです。Aなら、要機密情報を入れていないかを確かめます。

次に、基本項目の20項目を、事業者に求める条件として書き出します。選ぶ作業は原典が済ませています。提案を比べる軸が、そこで揃います。

条件が付く7項目は、使い方を決めてから当てはめます。社外の人が使うか、個人情報を入れるか、学習させるか、高い信頼性が要るか（同、別紙3）。

契約を結ぶ手前で、9件の取決め事項を見ます。入力と出力に、それぞれ「処理成果」という項目があります。出てきたものだけでなく、その途中で作られたものにも決めることがあります。

このガイドラインは政府職員向けです。ただし原典は、独立行政法人と指定法人に準拠した取り組みを期待し、地方公共団体にも参考とされることを期待すると書いています。民間の発注にもそのまま使えると考えています。求める項目を決める作業は、発注する側なら同じだからです。