AI料金改定に耐える見積もりと契約条項

先に結論を書きます。AIサービスの料金体系は、開発案件の途中でも変わる前提で見積もりと契約を組むべきです。具体的には、開発費と運用費を同じ見積書の中で別の性質の費目として分け、単価が変わったときの扱いをあらかじめ契約文に書いておくこと。この2点さえ押さえておけば、値上げや課金単位の変更が起きても「誰が負担するのか」で揉める場面はほぼ防げます。

この記事では、受託開発で業務システムにAIを組み込む場合を想定し、料金改定がどこに効いてくるのか、見積書と契約書のどこを直せばよいのか、そして実装側で何を用意しておくと切り替えが楽になるのかを順に整理します。

AIサービスの料金体系はなぜ変わるのか？

生成AIのAPI（外部のプログラムから機能を呼び出す仕組み）は、多くがトークン課金です。トークンとは文章を細かく区切った単位で、日本語なら数文字で1トークンというイメージです。入力トークンと出力トークンで単価が分かれているのが一般的で、ここが改定の主な対象になります。

ただし、変わるのは単価だけではありません。受託開発の見積もりに影響が出るのは、むしろ次のような「構造の変更」です。

特に厄介なのがモデルの提供終了です。単価が下がったとしても、動いていたモデルが使えなくなれば、プロンプト（AIへの指示文）の調整と出力品質の再確認が必要になります。値下げのニュースが、現場では追加工数として現れるわけです。

見積もりのどこが壊れるのか？

よくあるのは、AI利用料を開発費に含めて一式で出してしまうパターンです。受注側は開発期間中の単価を前提に積算しますが、運用が始まったあとの単価は誰も保証できません。結果として、保守フェーズに入ってから「聞いていた金額と違う」という話になります。

もう一つは、試算の前提を書かずに月額だけを提示するケースです。「月5万円程度」とだけ書かれた見積書は、処理件数が想定の3倍になった時点で意味を失います。前提を書いていなければ、発注側は「月5万円で固定」と読みますし、受注側は「あくまで目安」と言うつもりだった、という食い違いが起きます。

費用がどこで膨らむかという話は、AI費用の膨張は3層の上限設計で止まるでも扱っています。見積もりの精度は、結局のところ「どこに上限を置いたか」を書けているかどうかに帰着します。

見積書はどう分ければよい？

費目を性質で3つに分けるのが、もっとも揉めにくい形です。

そのうえで、従量費には試算の前提を必ず併記します。書くべきは、対象業務、想定件数（月あたり）、1件あたりの平均入出力トークン数、採用モデル名、試算時点の単価、そして試算日です。この6項目が揃っていれば、あとで実績と比べたときに「件数が増えたのか、単価が変わったのか、プロンプトが長くなったのか」を切り分けられます。

従量費の扱いは、実費精算（上限を設けたうえで実額を請求）か、定額に丸めて一定の幅を超えたら再協議、のいずれかが現実的です。どちらを選ぶにせよ、再協議の引き金となる条件を数字で書いておくことが要です。「大幅に変動した場合」では引き金になりません。

契約書には何を書いておくべき？

料金改定を想定した条項は、次の4つを押さえておけば大きな抜けは出にくくなります。

• 第三者サービスの条件変更に関する条項 — AI提供事業者の単価・課金単位・提供終了などの変更は受注者の責めに帰さないものとし、影響が出た場合は協議のうえ対価または仕様を見直す、という趣旨を明記します。
• 再協議の発動条件 — 「従量費の月額実績が見積もり前提額の一定割合を超えた月が連続したとき」のように、客観的に判定できる条件を書きます。割合と期間は案件ごとに決めます。
• モデル変更時の作業区分 — 提供終了や上位モデルへの移行に伴う再検証を、保守範囲に含めるのか別途見積もりとするのかを先に決めます。ここを曖昧にすると、移行のたびに交渉が発生します。
• 精度水準の扱い — モデルが変われば出力も変わります。契約上の品質水準をどう定義するか、変更後にどこまで再現を求めるかを決めておきます。

契約の枠組み自体については、経済産業省の「AI・データの利用に関する契約ガイドライン」や、IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」が参考になります。いずれも料金改定そのものを主題にしたものではありませんが、探索的な開発工程を請負と準委任にどう割り振るかという考え方は、従量費の責任分界を整理するうえでも使えます。精度・データ・権利という前提の詰め方は、AI開発の契約前に決める3論点でも整理しています。

実装側では何を用意しておく？

契約文だけで備えるのには限界があります。切り替えが技術的に重ければ、条項があっても実行できません。最低限、次の4点は初期設計に入れておきたいところです。

1. モデル名と接続先を設定値にする — コードに直接書かず、設定ファイルや環境変数から読む形にします。これだけで移行の工数が大きく変わります。
2. AI呼び出しを1箇所にまとめる — 業務ロジックから直接APIを叩かず、間に自社の薄い層を挟みます。乗り換え時の修正範囲が限定されます。詳しくはAIを乗り換えられる設計 — 費用はどこに出るかで触れています。
3. トークン数と呼び出し回数を記録する — 機能別・ユーザー別に残しておくと、単価が変わったときの影響額を即座に試算できます。記録がないと、改定通知を受け取っても判断材料がありません。
4. 評価用の入出力セットを残す — 業務で実際に通した入力と、合格とみなした出力を数十件ためておきます。モデルを変えるときの比較基準になります。

たとえば次のような場面です。見積書作成を支援する機能を納品した半年後、使っていたモデルの提供終了が告知された。評価セットが残っていれば、後継モデルで同じ入力を流して差分を見るだけで済みます。残っていなければ、現場担当者に再度ヒアリングするところからやり直しになります。

改定の通知が来たら何をする？

手順を決めておくと、慌てずに済みます。

• 変更内容を分類する（単価、課金単位、提供終了、制限変更のどれか）
• 記録してある実績トークン数に新単価を当て、月額の増減を試算する
• 増減が再協議の発動条件に達するかを契約文と照合する
• 達する場合は、試算根拠を添えて発注側に共有し、対価見直しか仕様調整かを協議する
• 提供終了を伴う場合は、評価セットで後継モデルを検証し、移行計画と期日を提示する

重要なのは、受注側から先に数字を出すことです。影響額を自分で試算して提示できれば、交渉は事実の確認から始まります。実績ログを取っていない場合はここで止まるため、結局は設計段階の準備に戻ってきます。

まとめ

AIサービスの料金体系は、単価だけでなく課金単位やモデルの提供可否まで含めて変わります。受託開発側が備えるべきことは、次の3点に集約されます。

• 見積書で開発費・固定運用費・従量費を分け、従量費には試算の前提6項目（対象業務、想定件数、平均トークン数、モデル名、単価、試算日）を書く
• 契約書に、第三者サービスの条件変更への対応、再協議の発動条件、モデル変更時の作業区分、精度水準の扱いを入れる
• 実装では、モデル名の外部設定化、呼び出し層の集約、トークン実績の記録、評価セットの保管を初期から用意する

料金改定は避けられない前提条件です。防ぐものではなく、起きたときに短時間で判断できる状態を作っておくものと捉えると、見積もりと契約で書くべき内容ははっきりしてきます。