形式エラーは減っても「嘘」は減らない。JSON Mode導入の法的リスクと実務的防衛策

記事本文

導入部

「GPT-4 TurboのJSON Modeを使えば、データ抽出の精度が劇的に上がる」。そんな話を聞いて、自社のDX推進施策に取り入れようと検討されている方も多いのではないでしょうか。

確かに、システム開発の現場から見れば、JSON Modeは画期的な機能です。これまで「波括弧が足りない」「カンマの位置がおかしい」といった理由で頻発していたパースエラーが激減し、開発工数は大幅に削減されます。システムが落ちることなく、スムーズにデータが流れるようになることは、プロジェクトマネジメントの観点からも非常に魅力的であり、ROI（投資対効果）の向上に直結します。

しかし、実用的なAI導入を成功させるためには、あえて厳しい現実にも目を向ける必要があります。

「システムがエラーを吐かずに動くこと」と、「正しいデータが処理されていること」は、全く別の話です。

むしろ、JSON Modeによって形式的なエラーが出なくなることで、「もっともらしい嘘（ハルシネーション）」がシステム深部にまで音もなく入り込んでしまうリスクが高まっていると言えるのです。

システムがエラーを出して止まってくれれば、人間は異常に気づけます。しかし、AIが自信満々に嘘のデータを正しい形式で出力し、システムがそれを正常に処理してしまったらどうなるでしょうか。誤った請求書の発行、誤った発注、契約違反となる条項の見過ごしなど、これらはすべて後になって「法的責任」という形で企業に襲いかかります。

この記事では、技術的な利便性の裏に潜む「法的リスク」の正体を解き明かし、AIを安全にビジネスに組み込むための実践的な防衛策について、プロジェクトマネジメントの視点も交えながら詳しくお話しします。

JSON Mode導入前に知るべき「技術的信頼性」と「法的責任」の乖離

まず、直面している問題の本質を論理的に整理しましょう。技術者が語る「信頼性」と、法務やビジネス側が懸念すべき「信頼性」の間には、大きなギャップが存在します。

形式（Syntax）の保証は内容（Semantics）の真実性を意味しない

JSON Modeとは、「AIに対して、必ず特定のフォーマット（JSON形式）で返答するように強制する機能」です。これにより、プログラムはAIの返答を機械的に読み取ることができるようになります。

ここで重要なのは、この機能が保証するのはあくまで「形式（Syntax）」だけであるという点です。

例えば、契約書のPDFから「契約終了日」を抽出するタスクを想像してください。元の文書に「2025年3月31日」と書いてあるのに、AIが幻覚を見て「2026年3月31日」と出力したとします。

• 従来のAI: 「契約終了日は2026年3月31日だと思います」といった自然言語混じりの返答をしがちで、プログラムが日付を取り込もうとするとエラーになり、人間が気づくチャンスがありました。
• JSON Mode: {"contract_end_date": "2026-03-31"} という、プログラムにとって完璧に読み取り可能な形式で出力します。

システム側から見れば、これは「成功」です。しかし、ビジネス側から見れば、これは「致命的な誤り」です。形式が整っているがゆえに、この誤りは人間のチェックをすり抜け、データベースに格納され、自動更新処理のトリガーとなってしまうかもしれません。

これが「形式的整合性の罠」です。技術的な安定性が向上したことで、皮肉にもデータの真実性を検証するハードルが上がってしまったのです。

構造化データ抽出における「もっともらしい嘘」のリスク

AI、特に大規模言語モデル（LLM）は、確率に基づいて「次に来るもっともらしい言葉」を紡ぐ仕組みです。事実に基づいているかどうかではなく、文脈的に自然かどうかが優先されます。

JSON Modeを使用しているときも、この根本的な性質は変わりません。むしろ、指定されたJSONスキーマ（データ構造の定義）に合わせようとするあまり、「空欄にするよりは、何か埋めておいた方が形式的に正しいだろう」とAIが判断し、存在しないデータを捏造してしまうケースさえあります。

例えば、顧客情報の抽出において、元のテキストに「電話番号」の記載がないにもかかわらず、JSONの必須項目を埋めるために架空の番号を生成してしまうような事象です。これがもし実在する他人の番号だったらどうなるでしょうか。個人情報保護法違反やプライバシー侵害のリスクに直結します。

AI利用における現行法の基本スタンス

このようなAIの誤りによって損害が発生した場合、法的にはどう扱われるのでしょうか。

現時点での法的なコンセンサスは、「AIはあくまで道具（ツール）であり、その結果に対する責任は使用者（ユーザー企業）にある」というものです。

OpenAIやMicrosoftなどの主要ベンダーは、AIモデルのアップデートを頻繁に行っています。GPT-4oなどのモデルでは、コーディング能力や複雑なタスク処理、長文理解の精度が向上しており、以前のモデルと比較してハルシネーションのリスクは低減されつつあります。また、古いモデルは順次廃止され、より高性能なモデルへと統合されていく流れにあります。

しかし、どれほどモデルが高性能化しても、ベンダー各社は利用規約（ToS）において出力内容の正確性を保証しない旨を明記しています（免責条項）。したがって、「最新のAIが間違えたから」という言い訳は、対外的な取引や法的紛争においては通用しません。

むしろ、AIという「確率的に誤りを含む可能性のある道具」を使用していることを認識しながら、適切な監督や確認を怠ったとして、使用者側の過失や善管注意義務違反が問われる可能性が高いのです。この法的リスクは、技術的な機能（JSON Mode等）を使っても解消されるものではないことを肝に銘じておく必要があります。

AIデータ抽出ミスにおける法的論点と責任の所在

では、具体的にどのような法的責任が発生しうるのか、もう少し解像度を上げて見ていきましょう。エンジニア任せにせず、プロジェクト全体で握っておくべき「責任の境界線」を整理します。

契約不適合責任とAI生成データの扱い

AIを用いて作成・抽出したデータに基づき、成果物やサービスを提供する場合、そのデータに誤りがあれば契約不適合責任（旧：瑕疵担保責任）を問われる可能性があります。

市場調査レポート作成サービスにおいて、データ収集にAIを活用するケースを想定してみましょう。JSON Mode等で抽出した数値データに誤りがあり、それを信じたクライアントが投資判断を誤って損害を被った場合、サービス提供側は「種類、品質又は数量に関して契約の内容と適合しない」履行を行ったとして、追完請求（やり直し）、代金減額請求、損害賠償請求、あるいは契約解除の対象になり得ます。

ここで押さえておくべきポイントは、「最新のAIモデルを使っていたこと」は免責事由にならないという事実です。前述の通り、AIモデルはGPT-4oなどの最新モデルへと進化を果たし、推論能力や長大なコンテキストの処理能力は飛躍的に向上しています。しかし、どれほどバージョンが上がっても、ハルシネーション（もっともらしい嘘）のリスクが完全に排除されたわけではありません。むしろ、「AIによる自動生成を含みます」と事前に明示し、かつ「精度の限界があるため、最終的な確認はクライアント側で行ってください」といった特約を結んでいない限り、プロフェッショナルとしての完全な履行責任を負う形になります。

AIが抽出した顧客データに誤りがあった場合の個人情報保護法上のリスク

個人情報を含む非構造化データ（メール文面や通話ログなど）から、AIを使って氏名や住所、属性情報を抽出してデータベース化するケースも頻繁に見受けられます。

ここでAIが誤った情報を抽出・登録してしまった場合、個人情報保護法における「正確性の確保」（第22条）に抵触する恐れがあります。同条では、個人情報取扱事業者に対し、利用目的の達成に必要な範囲内において、個人データを正確かつ最新の内容に保つよう努める義務を課しています。

また、AIが文脈を読み違えて実在しないセンシティブ情報（病歴や信条など）を勝手に付与してしまった場合、本人の同意なく要配慮個人情報を取得・保管しているとみなされるリスクもゼロではありません。これは、AIのハルシネーションが単なる「ミス」を超えて「権利侵害」に発展するパターンと言えます。データクレンジングの工程を省略し、AIの出力をそのままシステムに流し込む運用は、善管注意義務違反に問われる余地を残します。

ベンダー、ユーザー企業、担当者の三者間責任分界点

責任の所在を整理すると、以下のようになります。技術の進化に伴い、ベンダー側のサービス体系も変化していますが、法的な責任構造の基本は変わりません。

1. AIベンダー（OpenAI等）:
   原則として免責です。GPT-4oのような最新の高性能モデルへと移行し、より高度なタスク処理が可能になっても、多くのAPI利用規約では「Output（生成結果）の正確性」までは保証されません。サービス自体が停止していた場合などを除き、出力内容の誤りによる損害についてベンダーが責任を負うことは稀です。規約では通常、「Outputはお客様の所有物であり、その利用リスクもお客様が負う」と明記されています。

2. ユーザー企業（貴社）:
   対外的な全責任を負います。AIの選定責任、監督責任、そして出力結果を利用したことによる結果責任です。たとえGPT-4oのような最新の高精度モデルを採用していたとしても、誤ったデータを出力した場合の責任は利用企業にあります。民法715条（使用者責任）の考え方を類推すれば、AIを「被用者（従業員）」のように見立て、その監督不行き届きとしての責任を会社が負う構図に似ています。

3. 担当者（従業員）:
   社内規定や業務フローに従わずにAIを漫然と利用し、重大な過失によって会社に損害を与えた場合、会社から求償される可能性があります。逆に言えば、会社としては担当者を守るためにも、明確な運用ルール（ここまでAIに任せてよい、ここからは人間が目視で確認する、など）を策定する義務があると言えるでしょう。

リスクシナリオ別：構造化データ抽出の法的リスク評価

抽象的な議論だけでなく、具体的な業務シーンでどのような事故が起きうるか、シミュレーションしてみましょう。JSON Modeの「形式的な正しさ」が仇となるシナリオです。

ケース1：契約書からの条件抽出ミスによる履行遅滞

• 状況: 大量の取引基本契約書をPDFで受領し、AIで「支払サイト」や「納品期限」を抽出して基幹システム（ERP）に自動登録するフローを構築。
• 事象: 対象となる契約書の「月末締め翌々月末払い（60日サイト）」という記述を、AIが文脈を取り違えて「翌月末払い（30日サイト）」としてJSON出力。システムは正常にこれを取り込み、経理システムが30日後に支払いを実行しようとする。
• 結果: このケースでは「早く払う」分には法的問題は少ないかもしれません。しかし逆のパターン、つまり「30日サイト」を「60日サイト」と誤認した場合は深刻です。支払遅延が発生し、遅延損害金の請求や、最悪の場合は信用毀損による取引停止、契約解除に至ります。
• 法的リスク: 債務不履行責任。AIの読み間違いは正当な抗弁になりません。

ケース2：請求書データ化時の金額誤認識と経理処理

• 状況: 受領した請求書画像をOCRし、LLMで明細行を構造化データに変換。
• 事象: 手書き文字や複雑なレイアウトの影響で、数量「1」と単価「100,000」の行を、数量「10」と誤認識。JSON Modeは指定された数値型（Number）で {"quantity": 10, "unit_price": 100000} と出力。
• 結果: 承認フローが形骸化していた場合、桁違いの金額で支払処理が回ってしまいます。過払金の返還請求は可能ですが、相手方が悪意を持っていたり、すでに倒産していたりすれば回収不能となります。
• 法的リスク: 善管注意義務違反（取締役や担当者の責任問題）。また、税務申告における過少・過大申告による追徴課税リスク。

ケース3：医療・金融など規制産業でのデータ構造化ミス

• 状況: 金融機関の業務において、顧客の提出書類から「年収」や「勤続年数」をAIで抽出し、融資審査のスコアリングに利用。
• 事象: AIが注釈部分（「※ただし副業収入を含む」など）を読み飛ばし、本業収入のみを抽出、あるいは逆に過大な数値を抽出。
• 結果: 誤ったデータに基づく融資実行、あるいは不当な融資拒絶。
• 法的リスク: 関連法規上の監督指針違反、顧客に対する説明義務違反。もしAIのバイアスによって特定の属性に不利な抽出傾向があった場合、差別的取り扱いとして訴訟リスクにも発展します。

防御策としての契約・規約・運用ルールの設計

脅かすような話が続きましたが、ここで諦める必要はありません。リスクがあることを前提に、適切な「防波堤」を築けばよいのです。プロジェクトマネジメントの観点から、実用的なAI導入を成功させるための具体的なアクションプランを提示します。

HITL（Human-in-the-Loop）を義務付ける社内規定の策定

最も確実な防御策は、「AIの出力をそのまま最終決定としない」というプロセスを業務フローに組み込むことです。これを HITL（Human-in-the-Loop：人間がループの中に入る） と呼びます。

社内の「AI利用ガイドライン」において、以下の区分を明確に定義しましょう。

1. 完全自動化OK: 社内用の参考資料整理など、誤りがあってもリスクが軽微な業務。
2. 要確認（HITL）: 契約処理、支払処理、対外発表など、誤りが金銭的・法的損害に直結する業務。ここでは「AIによる抽出結果を人間が原典と突き合わせて確認し、承認ボタンを押す」プロセスを必須とします。

特にJSON Modeを使う場合、「システム連携が容易」だからといって、人間の承認ステップをAPIでスキップさせない設計が重要です。

対外サービス提供時の利用規約における免責条項の書き方

自社サービスにAI機能を組み込んで顧客に提供する場合、利用規約（ToS）の改定は必須です。以下の要素を盛り込むことを専門家と相談して進めてください。

• AI利用の明示: 本機能はAI技術を利用しており、確率的に誤った情報を生成する可能性があること。
• 正確性の非保証: 生成されたデータの正確性、完全性、特定目的への適合性を保証しないこと。
• ユーザーの確認義務: AIが生成したデータを利用して行う一切の行為（発注、契約、意思決定など）については、ユーザー自身の責任において内容を確認・判断すること。
• 免責範囲: AIの誤作動や誤情報に起因する損害（逸失利益などを含む）について、提供側は責任を負わない、あるいは責任範囲を限定（利用料金の範囲内など）すること。

AIモデルのバージョニング管理とトレーサビリティの確保

万が一トラブルが発生した際、「なぜその間違いが起きたのか」を事後検証できる体制が必要です。特にAIモデルは頻繁にアップデートされ、同じプロンプトでも時期によって出力が変わる可能性があります。

• プロンプトの記録: どのような指示（プロンプト）でそのデータを抽出したか。
• 元データの保存: 抽出元となったテキストやファイルは何か。
• モデルバージョンの記録: 使用したのが GPT-4 なのか GPT-4o 系なのかだけでなく、具体的なバージョン識別子（例：gpt-4o-2024-08-06 など）まで記録しているか。

AIモデルは、GPT-3.5からGPT-4、そしてGPT-4o系へと急速に進化し、古いモデル（GPT-3.5など）は廃止やレガシー化が進んでいます。API利用時は、単にモデル名を指定するだけでなく、レスポンスに含まれる正確なバージョン情報をログとして保存しておくことが、訴訟リスクへの備え（証拠保全）としても、原因究明と再発防止のためにも極めて重要です。

導入決定のための法務チェックリスト：JSON Mode活用版

最後に、AI導入のGo/No-Goを判断する際に、プロジェクトチーム全体でチェックすべき項目をリスト化しました。技術担当者や法務担当者とのすり合わせにご活用ください。

データプライバシーとモデル選定（学習利用とライフサイクル）

• API利用のデータポリシー確認: Web版チャットツールではなくAPIを利用する場合、一般的に入力データは学習に利用されませんが、各プロバイダーの最新の利用規約で「Zero Data Retention（データ保持なし）」オプションやオプトアウト設定が適用されているか、必ず確認が必要です。
• Azure OpenAI等の活用: 高度なセキュリティが求められる場合、Azure AI Foundry（Azure OpenAI）の利用が有力な選択肢です。入力データが学習に使われないことに加え、PII（個人特定情報）検出などのコンテンツフィルター機能を詳細に構成できるため、コンプライアンス準拠が容易になります。
• モデルのライフサイクル（廃止リスク）の確認: AIモデルの更新サイクルは非常に高速です。特定のモデルバージョンにはサポート終了日（Deprecation）が設定されており、例えばAzure OpenAIでは古いモデルの新規デプロイ制限や廃止が定期的に実施されます。長期契約のシステムにおいて、モデル廃止に伴う強制アップデートのリスクヘッジや、移行計画が含まれているかを確認してください。

出力データの検証プロセス（Verification）の確立

• 検証ロジックの実装: JSON ModeやStructured Outputsで返ってきたデータに対し、ビジネスロジックによる厳格なバリデーション（妥当性確認）を実装しているか確認します（例：抽出された日付が未来すぎないか、金額が異常値ではないか）。
• 信頼性評価の仕組み: 従来のモデルではLogprobs（確信度スコア）が活用されてきましたが、最新の推論モデル（o1シリーズ等）やResponses APIを利用する場合、評価手法が異なる可能性があります。使用するモデルの特性に合わせ、確信度が低い場合に自動的に人間の確認フローへ回す仕組みが実装されているか確認してください。
• 原典参照性の確保: 抽出されたデータが、元文書の「どこ」から引用されたのかをハイライト表示するなど、人間が確認しやすいUIになっているか。これは説明責任を果たす上で重要です。

有事の際のエスカレーションフロー

• インシデント対応: AIによる誤情報（ハルシネーション）や不適切な出力で顧客クレームが発生した場合の連絡系統は決まっているか。
• スイッチオフ機能（キルスイッチ）: AI機能に重大な欠陥や予期せぬ挙動が見つかった際、即座にその機能だけを停止し、手動運用に切り替えるBCP（事業継続計画）はあるか。

まとめ

構造化出力を支援する機能（JSON Mode等）は、システム開発の効率を劇的に高める強力な武器です。しかし、その「形式的な完璧さ」に目を奪われ、中身の「真実性」を確認するプロセスがおろそかになれば、企業は予期せぬ法的リスクを抱え込むことになります。

AIは魔法の杖ではなく、あくまで高度な確率計算機であり、ビジネス課題を解決するための「手段」に過ぎません。「エラーが出ない＝正しい」という思い込みを捨て、「エラーは出ないが、嘘をつくかもしれない」という前提でガバナンスを構築すること。それが、AI時代においてROIを最大化し、プロジェクトを成功に導くための鍵となります。

技術の進化を止めるのではなく、適切なルールと運用フローの力でその手綱をしっかりと握り、安全かつ実用的にビジネス価値を引き出していきましょう。