AIシステム開発の現場において、最近特に増えている深刻な相談があります。
「納品したAIチャットボットが、たまに不正なJSONを返して管理画面を落としてしまう。クライアントからはバグとして修正や損害賠償を求められているが、生成AIの挙動は100%制御できないのではないか」といった声です。
このような課題は、多くの開発現場で共通して見られます。従来のシステム開発において「仕様通りに動くこと」は当たり前の品質基準でした。if文は必ず条件通りに分岐し、データベースは必ず指定されたスキーマでデータを返します。しかし、確率的に次のトークンを予測する生成AI（LLM）において、「100%決まったフォーマットで出力すること」を保証するのは、技術的に極めて困難です。
では、開発ベンダーは「AIだから仕方ない」で済ませられるのでしょうか？
残念ながら、答えは「No」である可能性が高いです。特にB2Bの受託開発において、事前の合意形成や技術的な安全策が不十分な場合、それは「契約不適合（旧：瑕疵）」とみなされ、修正義務や損害賠償責任を負うリスクがあります。
今回は、AI機能を実装するすべてのPM、エンジニア、そして法務担当者に向けて、「AIの出力崩れ」という時限爆弾を解除するための、技術と契約の両輪について、実践的な視点から体系的に解説します。
※本記事は実務経験に基づく知見を提供するものであり、法的な助言を代替するものではありません。個別の契約事案については、必ず弁護士等の専門家にご相談ください。
AIシステム開発における「確率的挙動」と法的リスク
まず、私たちが扱っている「生成AI」という素材の特殊性を、法的なリスクの観点から再確認しましょう。ここを曖昧にしたままプロジェクトを進めることが、後の炎上案件を生む最大の要因です。
JSONパースエラーが引き起こす業務停止リスク
多くのAIアプリケーションでは、LLMからの出力をプログラムで処理するために、JSONやYAMLといった構造化データを要求します。例えば、顧客からの問い合わせメールをAIで解析し、CRMシステムに登録するために以下のようなJSONを返すシステムを想像してください。
{
"category": "complaint",
"priority": "high",
"summary": "商品の発送遅延に関する苦情"
}
ところが、LLMは確率的に動作するため、1000回に1回、あるいはプロンプトが複雑になればもっと高い頻度で、以下のような「壊れた出力」を返すことがあります。
- 事例1：閉じ括弧の欠落
{ "category": "complaint", ...（途中で途切れる） - 事例2：余計な説明文の混入
はい、解析結果は以下の通りです。 { "category": ... }（JSONの外にテキストがある） - 事例3：エスケープ処理のミス
{ "summary": "顧客が"遅い"と言っている" }（ダブルクォートの中でダブルクォートを使ってしまい、JSON構文エラーになる）
これらの出力がそのままバックエンドシステムに渡されると、JSONパーサー（解析機）は例外エラー（Exception）を吐いて処理を停止します。もし、このエラーハンドリングが適切になされていなければ、システム全体がクラッシュしたり、その顧客データが消失したりする可能性があります。
「たかがデータ形式のエラー」と思うかもしれません。しかし、これが重要な受発注処理や金融取引に関わるシステムで発生した場合、その損害は計り知れません。
従来の決定論的システムとの違い
従来のシステム開発では、入力Aに対して必ず出力Bが返ることが保証されていました。これを「決定論的（Deterministic）」といいます。バグがない限り、計算結果は常に同じです。
対して、生成AIは「確率的（Probabilistic）」です。同じプロンプトを入力しても、モデルの機嫌（乱数シードや温度パラメータ）次第で出力が変わります。これは、システム開発の契約において非常に厄介な問題を引き起こします。
- 従来: バグ＝開発者のミス＝修正責任あり
- AI: エラー＝確率的な仕様？＝責任の所在が不明確
発注者は「システムなんだから動いて当たり前」と考えます。一方で開発者は「AIの性質上、たまに間違うのは仕様」と考えがちです。この認識のギャップが、法的紛争の火種となります。
AI出力の不安定さが招く契約トラブル事例
実際に発生しやすいトラブル事例を紹介します。
一般的な企業が「社内文書検索AI」を開発会社に発注したケースを想定してみましょう。仕様書には「検索結果をJSON形式でAPI連携し、社内ポータルに表示する」と記載されていました。納品後の受入テストでは問題ありませんでしたが、本番運用開始後、特定の専門用語を含む質問をするとAIがJSON形式を崩し、ポータル画面が真っ白になる（ホワイトアウト）現象が頻発しました。
発注者は「仕様書通りに動かないのは契約違反だ」として、改修費用の負担だけでなく、システム停止による業務遅延の損害賠償を請求しました。開発会社は「生成AIの特性であり、回避不可能」と主張しましたが、契約書に免責事項が明記されていなかったため、非常に苦しい立場に追い込まれました。
このように、技術的な「パースエラー」は、一瞬にして法的な「債務不履行」の問題へと発展するのです。
法的論点：AIの出力ミスは「契約不適合」にあたるか
では、法律の観点からこの問題をどう見るべきでしょうか。2020年の民法改正により、「瑕疵担保責任」という言葉は廃止され、代わりに「契約不適合責任」という概念が導入されました。これがAI開発において非常に重要な意味を持ちます。
民法改正後の「契約不適合責任」の解釈
民法第562条（買主の追完請求権）には、以下のような趣旨が規定されています。
引き渡された目的物が種類、品質又は数量に関して契約の内容と適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。
ここでのポイントは「契約の内容と適合しているか」です。
もし仕様書や契約書に「ユーザーの質問に対して、JSON形式で回答データを生成する機能」とだけ書かれており、エラー率に関する言及がなければ、発注者は「100%正しくJSONを生成すること」が契約内容だと期待するのが通常です。
その場合、AIが不正なJSONを出力してシステムが動かないことは、「品質に関して契約の内容と適合しない」と判断される可能性が高くなります。つまり、「AIだから仕方ない」という言い訳は、契約書にその旨が明記されていない限り、法的には通用しにくいのです。
仕様書と実挙動の乖離
システム開発における「仕様書」は、契約内容を具体化した文書として扱われます。
- 仕様書：出力フォーマットはJSONとする。
- 実挙動：5%の確率でJSON以外の文字列が含まれる。
この乖離は、明確な契約不適合です。開発ベンダーがこの責任を回避するためには、仕様書の段階で「出力フォーマット」の定義を工夫する必要があります。
例えば、「出力フォーマットは原則としてJSONとするが、LLMの特性上、稀に形式が崩れる場合がある。その際はエラーコードを返し、ユーザーに再入力を促す仕様とする」といった記述があれば、形式崩れ自体は「仕様の範囲内」となり、契約不適合にはあたりません。
「バグ」と「AIの仕様」の境界線
ここで問題になるのが、どこまでが「AIの仕様」で、どこからが「開発者の技術不足（バグ）」なのかという境界線です。
もし、プロンプトエンジニアリングが稚拙で、本来防げるはずの形式崩れが頻発しているなら、それは「AIの仕様」ではなく「開発者のスキル不足」とみなされます。ここで問われるのが、次章で解説する「善管注意義務」です。
「善管注意義務」としてのプロンプト制御技術
準委任契約（多くのAI開発やコンサルティング契約で採用される形態）において、受託者は「善管注意義務（善良な管理者の注意義務）」を負います（民法第644条）。これは、「プロとして通常期待されるレベルの注意を払って業務を行う義務」のことです。
AI開発において、JSON出力を安定させるための技術的対策を怠ることは、この善管注意義務違反に問われるリスクがあります。
技術的努力義務の証明としてのプロンプト設計
現在、LLMから安定した構造化データを得るための技術は確立されつつあります。開発ベンダーが「AIの出力は制御できない」と主張したとしても、裁判所や第三者機関が「いや、今の技術水準ならこれくらいの対策は常識でしょう」と判断すれば、過失ありとされます。
具体的には、以下の技術的対策を行っているかが焦点となります。
- 明確なシステムプロンプト: 出力形式を厳格に指示しているか。
- 推論手法とFew-Shotプロンプティング: 出力例（Example）を提示して形式を学習させているか。2026年現在、Chain-of-Thought（思考の連鎖）は手動のプロンプト指示から、モデル側で推論の深さを自動調整する「適応型思考（Adaptive Thinking）」や「ツール統合型CoT」へと進化しています。ClaudeやGeminiのようなモデルでは、APIパラメータで思考レベル（High/Maxモードなど）を制御することが新たな推奨事項となっており、これらを組み合わせることで飛躍的な精度向上が期待できます。
- モデル固有機能の活用: JSON ModeやFunction Calling（Tool Use）を使用しているか。
- バリデーション層の実装: 出力後のチェック機構を備えているか。
これらを実装せずに「エラーが出ました」と言っても、それは「手抜き」と判断されるだけです。
JSON ModeとFunction Callingの活用は必須か
主要なLLMには、「JSON Mode」や「Function Calling（Tool Use）」といった、構造化データ出力を強制・支援する機能が搭載されています。
特に2026年2月には、OpenAIのGPT-4oなどの旧モデルが廃止され、より高度な推論とツール実行能力を備えたGPT-5.2（InstantおよびThinking）へと主力が移行しました。同時に、Anthropicからも自律的なPC操作や長文推論が大幅に向上したClaude Sonnet 4.6がリリースされています。
こうしたモデルの世代交代に伴い、開発者は古いAPI指定を更新し、最新モデルの挙動を検証する移行ステップを速やかに踏む必要があります。旧モデルの廃止によるシステム停止リスクを回避しつつ、モデルが進化しても以下の機能の活用は依然として必須の対策です。
- JSON Mode: モデルに「必ず有効なJSONを返す」よう強制するモード。これを使うだけで、構文エラーの確率は激減します。
- Function Calling / Tool Use: 自然言語ではなく、事前定義した関数（スキーマ）への引数としてデータを出力させる機能。これにより、型（String, Integer, Boolean）の遵守も期待できます。
実務的な感覚として、現在これらの機能が利用可能なモデルを使っているにもかかわらず、単なるテキスト生成（Completion）でJSONを出力させようとしてエラーを起こすのは、善管注意義務違反に近いと言わざるを得ません。これらはもはや「裏技」ではなく「標準的な実装作法」だからです。
スキーマ定義による制約の明確化
さらに踏み込んだ対策として、PydanticやZodといったバリデーションライブラリとLLMを組み合わせる手法があります。LangChainなどの主要フレームワークでは、これらのライブラリ（Pydantic V2など）との統合が進んでおり、型定義を利用した出力制御が標準的にサポートされています。
# Pydanticによるスキーマ定義の例（Python）
from pydantic import BaseModel, Field
class CustomerIntent(BaseModel):
category: str = Field(..., description="問い合わせのカテゴリ")
urgency: int = Field(..., description="緊急度（1〜5）")
requires_callback: bool = Field(..., description="折り返し電話が必要か")
このようにプログラムコードとしてデータ構造（スキーマ）を定義し、それをLLMに強制することで、出力の安定性は飛躍的に向上します。
ここまでやって初めて、開発側は「専門家として成すべき技術的対策を講じた上で、それでも発生するエラーは現在の技術的限界（＝不可抗力）である」と論理的に主張できるのです。
防御的な契約条項と仕様書の策定ポイント
技術的な対策を尽くしても、リスクをゼロにすることはできません。そこで重要になるのが、最後の砦となる「契約書」と「仕様書」です。PMやエンジニアも、法務任せにせず、技術的実態に即した条項を提案する必要があります。
「精度の非保証」をどこまで具体化するか
多くのAI開発契約書には「精度の保証はしない」という条項が入りますが、これだけでは不十分です。「精度」とは何を指すのかが曖昧だからです。
より具体的に、以下のような文言を盛り込むことを推奨します。
条項例：生成AIの特性に関する確認事項
乙（開発者）は、本システムに組み込まれる生成AIモデルについて、その出力結果の正確性、完全性、および特定のフォーマット（JSON/YAML等を含むがこれに限られない）への完全な適合性を保証しないものとする。甲（発注者）は、生成AIが確率的に動作する性質上、一定の割合で誤った情報や不正なデータ形式を出力する可能性があることを承諾し、これを理由として乙に契約不適合責任を問わないものとする。
ポイントは、「フォーマットへの適合性」も保証対象外であると明記することです。これにより、JSONパースエラーが直ちに契約違反になるリスクを回避できます。
エラー発生時の免責条項の書き方
システム障害が発生した場合の責任分界点も明確にしておく必要があります。
特に、AIモデルのAPI（OpenAI APIやその他LLMプロバイダー）自体の障害や、モデルの仕様変更によって出力形式が変わってしまった場合の免責は重要です。
昨今のAI業界では、モデルのアップデートサイクルが非常に早く、セキュリティポリシーの変更や、特定の機能（Codex系モデルなど）の統合・廃止が頻繁に行われます。また、医療やコーディングなどに特化した新しいモデルが次々と発表される一方で、既存モデルの挙動が微調整されることも珍しくありません。
したがって、以下のように外部要因による変動リスクを網羅的にカバーする条項が必要です。
条項例：外部サービスの変更・停止
本システムが利用する第三者のAIモデル（API）の仕様変更、モデルの統廃合、サービス停止、または精度の変動に起因して生じた本システムの不具合や損害について、乙は一切の責任を負わないものとする。また、APIプロバイダーの利用規約変更や安全性基準の厳格化により、特定の出力が制限された場合も同様とする。
注意点: 利用するAPIの最新情報は、必ず各プロバイダーの公式サイトや公式ドキュメントで確認してください。ニュース記事や噂レベルの情報（L3情報）ではなく、公式発表（L1情報）に基づいたリスク評価を行うことが重要です。
再生成（リトライ）ロジックの仕様化とコスト負担
契約書だけでなく、仕様書（要件定義書）にも防御策を埋め込みます。それが「リトライロジック」の明文化です。
AIが不正なJSONを返した場合、システム側で自動的に再生成（リトライ）を行う設計にするのが一般的です。しかし、リトライにはコスト（API利用料と待ち時間）がかかります。
- 仕様記述例:
「AIからのレスポンスが規定のJSONフォーマットに適合しない場合、システムは最大3回まで自動的に再生成を試みる。3回失敗した場合は、ユーザーにエラーメッセージを表示し、処理を中断する。」
このように「エラー時の挙動」まで仕様として定義しておけば、3回失敗してエラー画面が出ても、それは「仕様通りの動作」であり、バグではありません。
また、リトライによって増加するトークン課金を誰が負担するかも、契約時に合意しておくべき重要なポイントです（通常は実費として発注者負担とするケースが多いですが、明記がないと揉める原因になります）。
運用フェーズでのリスク管理とSLA
無事にシステムを納品した後も、リスク管理は続きます。SaaS型のAIモデルは生き物のように変化するため、運用フェーズでの監視（モニタリング）が欠かせません。
継続的なプロンプトメンテナンスの必要性
「一度作ったプロンプトは永久に使える」というのは幻想です。モデルのバージョンアップによって、以前は完璧に動作していたプロンプトが、急に言うことを聞かなくなる（または過剰に反応する）ことがあります。
運用保守契約を結ぶ際は、単なる「サーバー監視」だけでなく、「プロンプトの定期的な評価と調整」をスコープに含めることを提案しましょう。これが、クライアントにとってもシステムの安定稼働というメリットになり、開発ベンダーにとっては継続的な収益源となります。
モデルアップデートと廃止リスクへの対応
OpenAIなどのAIプロバイダーは、頻繁にモデルを更新し、世代交代を進めています。ここで重要なのは、単なる機能追加だけでなく、「旧モデルの廃止（Deprecation）」というリスクがある点です。
例えば、かつて主力だったモデルは、より高性能かつ高速な後継モデルへの移行に伴い、提供が終了しました。このように、特定のモデルバージョンに依存していると、そのバージョンの提供終了に伴いシステムが機能しなくなる可能性があります。
リスクを最小化するための鉄則は以下の通りです：
- バージョンの固定（Pinning）： APIリクエスト時は「latest」ではなく、具体的な日付付きバージョンを指定します。これにより、意図しない自動アップデートによる挙動変化を防ぎます。
- 廃止スケジュールの監視： 固定したバージョンもいずれ廃止されます。公式の廃止予告を常に監視し、サポート終了期限までに最新モデルへの移行検証を行う計画的な運用が必要です。
- 検証環境の維持： 新モデルでの挙動を確認するためのテストベッドを常設し、強制的な切り替えが発生しても即座に対応できる体制を整えます。
ログ保存と証跡管理の重要性
万が一、トラブルが発生して損害賠償の話になった時、プロジェクトを守る重要な要素となるのが「ログ」です。
- 入力されたプロンプト
- AIが返した生のレスポンス（Raw Text）
- パースエラーの内容
これらを全て記録しておきましょう。「AIが変なJSONを返した」という証拠があれば、それがAPI側の問題なのか、プロンプトの問題なのかを切り分けることができます。特に、APIプロバイダー側の不具合であった場合、ログがなければそれを証明できず、開発ベンダーが濡れ衣を着せられることになりかねません。
まとめ：技術と契約の両輪で守るAI開発
AIによるJSON出力の不安定さは、エンジニアにとっては「技術的課題」ですが、PMや経営層にとっては「経営リスク」そのものです。
- 技術的対策（善管注意義務）： JSON Mode、Function Calling、Pydantic等を駆使し、プロとして恥ずかしくない実装を行う。
- 契約的対策（リスクヘッジ）： 生成AIの特性（確率的挙動）を前提とした免責条項と、エラー時の仕様（リトライ等）を明文化する。
- 運用対策（証跡管理）： バージョン固定とログ保存で、変化とトラブルに備える。
この3つをセットで実行することで初めて、私たちは「AIという暴れ馬」をビジネスの現場で安全に乗りこなすことができます。
「技術で解決できないことは、契約で解決する」。この視点を持つことが、AI時代のPMには不可欠です。
最後に、進行中のプロジェクトが法的な落とし穴に落ちることなく、AIの価値を最大限に発揮できることを願っています。まずは、現在進行中のプロジェクトの契約書と仕様書を、この視点で見直してみてください。
さらに詳しい対策や、プロジェクトで使えるチェックリストについては、専門的なガイドラインや公式ドキュメントを参考にすることをおすすめします。
コメント