「AIで請求書の仕分けを自動化したら、ある月だけ誤って別部署の費目に振り分けられていて、決算で発覚しました。これは作った会社の責任ですか、それとも使った私たちの責任ですか」——AI機能を組み込んだシステムを引き渡したあと、こうした問い合わせは珍しくありません。発注側は「自動化を請け負った以上、間違いも込みで責任を持つはずだ」と考え、受託側は「AIの判定は確率的なもので、100%を保証したつもりはない」と考える。同じ契約書を前にして、両者の前提がそもそも噛み合っていないのです。
この食い違いの根っこには、AIという技術の性質があります。従来のシステムは「仕様どおりに動けば正解」でしたが、AIは学習データから帰納的に振る舞いを獲得するため、未知の入力に対する精度をあらかじめ保証することが原理的に難しい。だからこそ経済産業省の「AI・データの利用に関する契約ガイドライン」も、AI開発は通常の請負と同じには扱えないとして、アセスメント・PoC・開発・追加学習という多段階の進め方を提案しています。本記事は「AI開発をどう進めるか」ではなく、その一歩手前の問い——AIの誤作動・誤判定で損害が出たとき、その責任を発注側と受託側がどう分け合うのか。それを契約・設計・運用の三つの層でどう線引きするか——に絞って、受託を請け負う立場から整理します。
「請け負った=結果を保証した」がAIでは崩れる
まず押さえるべきは、契約の型の話です。システム開発の契約は大きく請負型と準委任型に分かれます。請負は「成果物の完成」に対して責任を負い、できあがったものが約束した品質を満たさなければ契約不適合責任（旧・瑕疵担保責任）を問われます。準委任は「善管注意義務をもって作業すること」に対して責任を負い、結果そのものは保証しません。
通常のシステムなら「請負で、仕様どおりに作る」で済みます。問題は、AIの精度を請負の対象にできるかです。学習データの量と質に精度が依存し、本番で来る入力を事前に網羅できない以上、ベンダーが「正答率99%を完成義務として保証する」のは現実的ではありません。実務では、AIの中核部分は準委任（一定の精度を目指して努力する）、その周辺の通常のソフトウェア部分は請負、というように同じプロジェクトの中で契約の型を使い分けることが多くなります。
| 契約の型 | 負う責任 | AI機能に向くか |
|---|---|---|
| 請負型 | 成果物の完成・契約不適合責任 | 通常のソフト部分に向く。AI精度の保証には不向き |
| 準委任型 | 善管注意義務（プロセス）。結果は保証しない | AIモデルの生成・チューニングに向く |
ここで一番危険なのは、契約書には「請負」と書いてあるのに、AI部分の精度について何の合意もしていない状態です。発注側は「請負だから結果も込み」と読み、受託側は「AIだから努力義務のつもり」と読む。引き渡し後にトラブルが起きてから、この読みの差が表面化します。だからAIを含む案件では、契約の型をどこで切り替えるか、そしてAI部分について何を保証し何を保証しないかを、契約段階で明文化しておく必要があります。引き継ぎや改修のたびに「なぜこの設計にしたのか」が分からなくなる問題はドメイン知識の置き場所を整理する記事でも触れましたが、責任分界もまさに「あとから経緯が分からなくなる」典型です。
契約で線を引く — 何を保証し、何を除外するか
契約レベルでの線引きは、つきつめると「保証する範囲」と「除外する範囲」を具体的に書き分ける作業です。経済産業省が2025年に公表した「AIの利用・開発に関する契約チェックリスト」も、責任分担・精度の取り扱い・データの権利といった論点を契約前に確認するよう促しています。受託の現場で特に効くのは、次の三点を明示することです。
ひとつは、精度の位置づけを「保証値」ではなく「目標値」として扱うこと。SLAの実務でも、AIの誤出力は性能のばらつきの問題であって、精度未達に対して金銭補償を約束するのは無理があるとされ、補償は再学習やモデル調整の努力義務、あるいはサービスクレジットで対応するのが現実的だと整理されています。「正答率◯%以上を保証する」と書くのではなく、「◯%を目標とし、未達の場合は再学習で改善に努める」と書く。この一語の違いが、後の賠償責任の有無を大きく分けます。
ふたつめは、除外事由を具体的に書くこと。AIの出力は入力データの質に強く依存するため、発注側が渡したデータが偏っていたり不正確だったりした場合の精度低下は、受託側の責任から外すと定めておく。これは受託側を守るためだけでなく、「精度が出ないのは誰の入力のせいか」という不毛な押し付け合いを避けるためでもあります。
みっつめは、賠償の上限を定めること。情報サービス産業協会（JISA）のモデル規約でも、損害賠償の上限を概ね一か月分の利用料金とし、特別損害や逸失利益は対象外とする形が一般的です。AIの誤判定が連鎖して大きな二次被害（決算修正、取引先への賠償など）につながったとき、受託側が無限の責任を負わないよう上限を設けておくことは、対価とリスクの釣り合いを取るうえで不可欠です。
ただし注意したいのは、上限や免責を書けばそれで安心、ではないということです。賠償制限条項は、受託側に重過失があった場合には適用されないと判断されることがあります。「免責を書いたから何をしても許される」のではなく、あくまで「誠実に作ったうえで、なお残るリスクの上限を合意する」ものだと理解しておくべきです。
設計で線を引く — 誤判定を「人に戻す」境界をどこに置くか
契約で責任を分けても、それだけでは現場の損害は防げません。むしろ受託側が本当に価値を出せるのは、そもそも誤判定が致命傷にならないように設計しておくところです。ここで鍵になるのが、ヒューマン・イン・ザ・ループ（HITL）という考え方です。
HITLは「AIの判定プロセスに人間の確認・介入を組み込む」設計原則で、AIの説明責任や安全性を担保する手段として位置づけられています。重要なのは、ただ人間を挟めばよいのではなく、どの判定を自動で通し、どの判定を人間に戻すか、その境界を業務リスクに応じて設計することです。全件を人が確認するなら自動化の意味がなく、全件を自動で通すなら誤判定がそのまま損害になる。その中間を、案件ごとに引くわけです。
実務では、AIの確信度（スコア）を使った段階設計がよく機能します。
| 確信度 | 処理の流れ | 責任の所在 |
|---|---|---|
| 高い | 自動で確定。事後にサンプリング監査 | 仕組みを設計した受託側 + 監査体制を回す発注側 |
| 中くらい | 人間がレビューして承認・却下 | 最終判断をした発注側の担当者 |
| 低い | 自動処理せず、必ず人間に差し戻す | 発注側（AIは判断を放棄している） |
この設計の利点は、技術的な安全装置であると同時に、責任の所在を可視化する点にあります。確信度が低い案件を人間に差し戻していれば、そこで起きた誤りは「AIが勝手に間違えた」ではなく「人間が確認したうえでの判断」になる。逆に、確信度が高いとされた領域で誤判定が起きたなら、それは仕組みを設計した側の課題として、再学習や閾値の見直しに入る。境界を明示しておくことで、トラブル時に「どちらの責任か」を後付けで争わずに済むのです。
加えて、誤作動時のフォールバックを用意しておくことも設計上の責任分界に直結します。AIの判定APIが応答しない、明らかに異常な出力を返す、といった事態のとき、システムが無言で誤った値を採用してしまうのか、それとも安全側に倒して人間のキューに積むのか。これを決めていないと、障害がそのまま損害に直結します。AIの判定を「いつでも間違えうる外部からの不確実な応答」として防御的に扱い、安全側に倒す境界を設けておくのが筋です。共通化や抽象化を急ぐと逆に壊れやすくなるという早すぎる共通化の落とし穴を扱った記事と同じく、フォールバックも凝った仕組みより「確実に人へ戻す」素直な経路を優先するほうが安全です。
運用で線を引く — ログと監査が「証拠」になる
三つめの層は運用です。どれだけ契約と設計で線を引いても、実際に誤判定が起きたとき「いつ、どの入力に対して、AIが何を返し、誰がそれをどう扱ったか」が残っていなければ、責任の所在は水掛け論になります。
ここで効くのが、判定ログと人間の介入履歴を残す運用設計です。AIの入力・出力・確信度、そして人間がレビューで承認したか却下したかを記録しておけば、トラブルが起きたときに「設計どおりに人間に戻されていたか」「人間が確認したうえでの判断だったか」を事実で示せます。AI利活用における民事責任の議論でも、因果関係や責任の所在を立証できるかが論点になりますが、その立証を支えるのは結局このログです。発注側にとっても、サンプリング監査でAIの精度の劣化に早く気づける利点があります。
弊社が受託したある社内文書の自動分類システム（業種・社名は伏せます）でも、この三層の線引きが効きました。当初の引き合いは「AIで全自動分類したい」というものでしたが、誤分類が機密区分のミスに直結する業務だったため、請負一本での「全自動の精度保証」は受けられないとお伝えしました。代わりに、AI部分は準委任で目標精度を合意し、確信度が一定以下の文書は必ず担当者の確認キューに積む設計にしました。確信度が高いものだけ自動確定し、それも月次でサンプリング監査を回す。さらに、入力文書・分類結果・確信度・担当者の最終判断をすべてログに残しました。
運用開始後、実際に誤分類が一件見つかりましたが、ログを追うと「確信度は高かったが、過去に例のない様式の文書だった」ことが分かり、その様式を学習に追加して閾値を調整することで解決できました。重要なのは、この一件が「誰のせいか」をめぐる争いにならなかったことです。設計上どこまで自動に任せ、どこから人間に戻すかを契約段階で合意し、ログでその通り運用されていたことを示せたため、原因究明と改善にまっすぐ進めたのです。大規模な刷新でAIを足場にする場合にこそ、こうした責任分界の合意が効いてくる点はAI支援でレガシーを移行する記事でも触れたとおりです。
受託として、どこから合意を始めるか
「AIで自動化できます」という一言は、技術の話であると同時に、責任を誰がどこまで飲むかという経営判断の話でもあります。受託を請け負う側に必要なのは、できることを大きく見せることではなく、保証できる範囲と保証できない範囲の境界を、契約・設計・運用の三つの層で具体的に引いて見せることです。発注側にとっても、その境界が明示されていることは、トラブルを未然に防ぎ、起きたときに泥沼を避ける安全装置になります。
最初の一歩としては、いま検討中・運用中のAI自動化について、「誤判定が一件起きたら、誰がどう気づき、誰が責任を負い、どう直すのか」を一枚の紙に書き出してみることをお勧めします。その紙が白いままなら、それは契約・設計・運用のどこかに線が引かれていないサインです。
AIを使った自動化を検討しているが誤判定のリスクと責任の所在が整理できていない、ベンダーから「AIで自動化できます」と提案されたが何を保証してくれるのか分からない、既存のAI機能の責任分界を契約・設計の両面で見直したい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。ご要件を伺ったうえで、どこまでを自動に任せ、どこから人間に戻し、何を契約で保証し何を除外するかを、実装まで見据えて一緒に線引きします。
