導入・選定

AIを活用したサービスは、企業にどこまで提供できるか。責任範囲の引き方

AIを組み込んだサービスを企業へ提供するとき、どこまでを引き受け、どこからを相手の責任とするか。この線引きが曖昧なまま始まる案件が少なくありません。この記事では、公的なガイドラインを手がかりに、責任範囲の引き方を整理します。

3つの立場を区別する

総務省と経済産業省が公表した「AI事業者ガイドライン（第1.1版）」は、AIの事業活動を担う主体を「AI開発者」「AI提供者」「AI利用者」の3つに大別しています。

この区分が実務で効きます。自社がどの立場なのかで、負うべき責任の範囲が変わるためです。

• AI開発者／モデルそのものを作る。基盤モデルの開発企業が該当
• AI提供者／AIを組み込んだシステムやサービスを提供する。受託開発やSaaSはここ
• AI利用者／事業活動でAIシステムやサービスを利用する

受託でAI活用サービスを作る場合、多くは「AI提供者」にあたります。モデルは他社製、利用するのは顧客、その間をつなぐ立場です。この位置づけを契約書に明記しておくだけで、後の議論が整理されます。

提供できる範囲

AI提供者として引き受けられるのは、おおむね次の範囲です。

• 業務への組み込み設計／どの工程にAIを入れ、どこを人が判断するかの設計
• データの整備と接続／社内データを利用可能な形に整える
• 出力品質の一定水準の担保／評価基準を定め、その水準を満たすまで調整する
• 運用の仕組み／誤りが出たときの検知、記録、修正の流れ
• 教育／使う側が正しく扱えるようにする

重要なのは、「出力品質の担保」は水準を定義してはじめて約束できるという点です。「精度を上げる」ではなく「この評価データで正答率◯％」といった形で合意する必要があります。

提供できない範囲

一方、引き受けるべきでないものがあります。

出力が常に正しいことの保証。現在の生成AIは確率的に出力するため、誤りが出ないことは保証できません。これを約束する契約は、履行不能な約束です。

AIの判断結果に対する最終責任。採用、与信、医療、法務など、人の権利に関わる判断をAIに委ねる設計では、人が最終決定を行う工程を必ず残すべきです。ガイドラインも人間による監督の重要性を示しています。

入力データの適法性。顧客が持ち込むデータに個人情報や第三者の著作物が含まれる場合、その適法性は提供者側では確認しきれません。

これらを断ることは、消極的な姿勢ではありません。実現できない約束をしないことが、長く取引を続ける条件です。

契約で定めるべき5項目

線引きを文書にするなら、最低限これだけは必要です。

• 品質の定義／何をもって完成とするか。評価データと合格基準を具体的に書く
• 誤りが出た場合の扱い／修正の範囲、対応の期限、責任の限度
• データの取り扱い／預かるデータの範囲、保存期間、学習利用の可否、返却・削除
• 使用するモデルの明示／どのAIを使うか。仕様変更や提供終了時の対応
• 成果物の権利／AIが生成した部分の権利関係と、再利用の可否

4つ目は近年とくに重要になっています。モデルの提供元が仕様を変えたり提供を終了したりする可能性があり、その際に誰が費用を負担するかを決めておく必要があります。

依頼する側が確認すべきこと

発注者の立場からも、確認しておくべき点があります。

どのモデルを使うのか。「AIを使います」だけでは、性能もコストも予測できません。

データはどこへ送られるのか。国外のサーバーを経由する場合、社内規程に抵触しないかを確認します。

学習に使われるのか。入力したデータがモデルの学習に使われるかどうかは、契約で確認できます。

人が確認する工程はどこか。全自動の提案には注意が必要です。誤りが起きたときに止められる箇所があるかを見ます。

現実的な進め方

総務省の調査では、日本企業で何らかの業務に生成AIを利用しているのは55.2％、活用方針を定めている企業は49.7％とされます。方針が未定のまま個別案件が動いている組織が相当数あることを示しています。

この状況で有効なのは、小さく始めて範囲を広げる進め方です。

第一段階は、影響が限定的な業務から始めます。社内向けの要約、下書きの生成、分類の補助。誤りが出ても取り返しがつく領域です。

第二段階で、人の確認を挟んだ顧客向け業務へ広げます。第三段階で自動化の範囲を検討します。

最初から基幹業務に入れる提案は、提供側にとってもリスクが高すぎます。

提供側にとっての意味

責任範囲を明確にすることは、引き受ける仕事を減らすことではありません。

できないことを先に言える会社は、できることの信頼度が上がります。とくにAI領域では、過大な期待を持たれたまま始まる案件が失敗の典型です。

また、範囲が明確であれば見積もりの精度が上がり、追加作業の交渉もしやすくなります。曖昧なまま受注した案件は、必ずどこかで無償の追加対応を生みます。

ガイドラインは法的拘束力のないソフトローとされますが、契約の議論をする際の共通言語として使えます。「ガイドラインではこう整理されています」と示せることには、実務上の価値があります。

よくある相談と、その扱い方

実際に持ち込まれる相談を、扱い方とともに整理します。

「AIで全部自動化したい」。まず、どの工程を自動化するのかを分解します。全工程を一度に扱う提案は失敗します。誤りが出たときに、どこで止めるかを設計できないためです。

「精度100％にしてほしい」。現在の生成AIでは約束できません。代わりに、誤りが出たときの検知と復旧の仕組みを提案します。精度ではなく、影響の大きさを管理する発想への転換です。

「他社の事例と同じものを」。データも業務も違うため、同じ結果にはなりません。事例のどの部分が自社に当てはまるかを、先に検証する工程を提案します。

いずれも、要望を断るのではなく、実現可能な形に翻訳するのが提供者の役割です。

見積もりの考え方

AI活用案件では、従来の見積もり方法が合わない場面があります。

• 検証の工数を分ける／実現可能性の確認と、実装は別の契約にする
• データ整備を明示する／多くの案件で最も工数がかかる部分。曖昧にすると必ず超過する
• 調整の回数に上限を置く／出力の調整は際限なく続けられるため、回数か期間で区切る
• 運用費用を分けて示す／API利用料は従量課金。使用量の想定と、超過時の扱いを決める

1つ目が最も重要です。実現できるかどうか分からない段階で全体を請け負うと、できなかった場合の損失をすべて負うことになります。小さく検証してから本開発に進む二段階の契約が、双方にとって安全です。