AI関連のニュースは毎週のように流れてきますが、受託開発の現場で「見積もりの出し方」や「契約書の文言」まで変えたものは、そう多くありません。本稿では、弊社が業務システムの受注開発を進めるなかで、実際に見積・契約・納品のやり方を変えざるを得なかった論点に絞って整理します。新機能の紹介ではなく、発注する側・される側の双方が事前に決めておくべきことの話です。
なお、本稿で触れる法令・ガイドラインは名称と公表年を添えていますが、施行時期や運用は変わり得ます。実際の判断では最新の原文をご確認ください。
1. 見積もりの重心が「開発」から「評価と運用」に移った
数年前のAI案件は、モデルを自社データで追加学習させる「ファインチューニング」が前提でした。学習データの整備と学習環境の構築に工数の多くが乗っていたわけです。
現在は、汎用的な大規模言語モデルをAPI（外部のソフトウェア機能を呼び出す仕組み）経由で使い、自社データは検索して渡す構成が主流です。いわゆるRAG（Retrieval-Augmented Generation／検索拡張生成。質問に関連する社内文書を検索し、その内容と一緒にAIへ渡す方式）です。この変化で、見積書の内訳そのものが変わりました。
| 項目 | 従来型の業務システム | AI機能を含むシステム |
|---|---|---|
| 要件定義 | 画面と帳票の仕様を固める | 加えて「AIに任せる範囲」と「人が確認する工程」を決める |
| 実装 | 工数の中心 | 相対的に比率が下がる |
| テスト | 仕様通りか（合否が明確） | 評価用データでの正答率測定（合否基準の合意が必要） |
| 運用 | 保守費として別枠 | API従量課金＋精度の継続監視が初期から必須 |
特に重要なのが評価工数です。「それらしい答えを返すか」ではなく「業務で使える水準か」を測るには、実データに基づく評価セットを作る必要があります。ここを見積もりから落とすと、納品直前に「思ったより使えない」という最も避けたい事態になります。
2. ランニングコストが見積もりの主役になった
AIのAPI利用料は、処理した文章量（トークン：AIが文章を扱う最小単位。日本語では概ね1文字が1〜2トークン）に応じた従量課金です。開発費が一度きりなのに対し、こちらは毎月発生し続けます。
モデル単価は全体として下がる傾向にありますが、同時に「一度の処理で参照する文書量」が増えやすいため、実際の月額が読みにくいという問題が残ります。見積もり段階で次の点を発注者と握っておくことを勧めます。
| 変動要因 | 設計上の対策 | 契約上の扱い |
|---|---|---|
| 利用回数が想定を超える | 利用上限・アラートの実装 | 上限超過時の費用負担を明記 |
| 参照文書が長大化する | 検索の絞り込み、要約の事前生成 | 対象文書量の前提を仕様書に記載 |
| モデルの値上げ・提供終了 | モデル差し替え可能な設計 | 外部要因による変更の費用区分 |
| 高性能モデルの常用 | 処理ごとにモデルを使い分ける | 品質とコストの優先順位を合意 |
API費用の扱いは、実費を発注者名義のアカウントで直接負担してもらう方式と、開発会社が立て替えて月額に含める方式があります。前者のほうが透明性が高く、トラブルが少ない印象です。
3. 外部連携の「つなぎ方」が標準化されつつある
AIを社内の基幹システムやファイルサーバーとつなぐ部分は、これまで案件ごとの独自実装でした。ここにMCP（Model Context Protocol。Anthropicが2024年に公開した、AIと外部データ・ツールを接続するための共通仕様）のような標準が登場し、既存のコネクタを再利用できる場面が増えています。
実務上の効果は、接続部分の工数が読みやすくなったことです。一方で、新たなボトルネックとして浮上したのが権限設計です。AIが社内データにアクセスできるということは、「誰がどの情報まで見られるか」をAI経由でも守る必要があるということです。
たとえば次のような場面です。営業部門向けのAIアシスタントを導入したところ、共有フォルダの奥に置かれていた人事評価の下書きファイルまで検索対象に含まれてしまう。既存のフォルダ権限が曖昧なまま運用されていた組織では、十分に起こり得ます。
そのため、納品物に接続仕様書と権限マトリクス（どの利用者グループがどのデータソースを参照できるかの一覧）を含めることを標準化しました。AI導入が、結果的に既存のアクセス権限の棚卸しを強制する形になっています。
4. 最大の論点は「どう検収するか」
従来の請負契約は「仕様通りに動くこと」を納品の条件にできました。AIを含む機能は確率的に動作するため、100%の正答を保証できません。ここを曖昧にしたまま契約すると、検収で揉めます。
現場で有効だったのは、次の進め方です。
- 評価用データを発注者側が用意する：実際の業務データから、入力と「正解とみなす出力」の組を数十〜数百件作る
- 合格基準を数値で事前合意する：たとえば「評価セット100件に対して、担当者判定で許容可能な出力が80件以上」といった形
- 誤りの重さを分ける：間違えても実害が小さい誤りと、絶対に起こしてはいけない誤り（金額の取り違え、個人情報の混入など）を分類し、後者はゼロ件を条件にする
- 契約形態を工程で分ける：精度が読めない検証フェーズは準委任契約、仕様が固まった実装フェーズは請負契約
上記の数値は説明のための仮の例です。実際の基準は業務の性質によって大きく変わります。重要なのは、「誰が、どのデータで、何件中何件を合格とみなすか」を契約書または仕様書に書くことです。
5. 法令・ガイドラインが契約書に降りてきた
規制そのものより、「取引先からの要求事項」として降りてくるルートが実務に効いています。
- EU AI Act（欧州連合のAI規則、2024年成立）：リスクに応じた分類を行い、段階的に適用される枠組みです。高リスク分野に関する義務は2026年以降に本格適用される予定とされています。日本国内のみで完結する業務システムに直接適用されるものではありませんが、EU向けに製品・サービスを提供する企業がサプライヤーに説明を求める形で波及します。
- AI事業者ガイドライン（総務省・経済産業省、2024年公表、その後改定）：法的拘束力を持つものではありませんが、社内規程や発注仕様書の参照先として使われる場面が増えています。
- 人工知能関連技術の研究開発及び活用の推進に関する法律（2025年成立）：推進と基本理念を中心とした内容で、罰則による直接規制を主眼とするものではないと理解されています。
- AIと著作権に関する考え方について（文化審議会著作権分科会法制度小委員会、2024年）：学習段階と生成・利用段階を分けた整理が示されています。社内文書以外を学習・参照させる場合は確認が必要です。
- 個人情報保護法：外部のAI APIに個人データを送る行為が「委託」にあたるのか「第三者提供」にあたるのかの整理は、設計段階で必ず詰める論点です。利用規約上、入力データが学習に使われない設定になっているかの確認も含みます。
結果として、納品時にAIの入出力ログを一定期間保持する設計と、どのモデルをどの用途で使っているかの一覧を求められるケースが増えました。後から追加すると高くつくため、初期設計に含めるべき項目です。
6. 発注側の準備で見積もりは下げられる
同じ要件でも、発注側の準備状況で見積額は変わります。効果が大きいのは次の3点です。
- データの所在と権利を整理しておく：どのサーバーの、どの形式のファイルを、誰の承認で使えるか。ここが未整理だと調査工数がそのまま乗ります
- 自動化の線引きを決めておく：「AIが下書きし、人が承認する」のか「AIが最終出力まで行う」のか。後者は求められる精度水準が跳ね上がり、費用も検証期間も増えます
- 評価の責任者を1人決める：出力の良し悪しを判定できる業務担当者を指名してください。複数人の感覚で判定すると基準が揺れ、検収が終わりません
まとめ
2026年前後のAI開発で実務に効いた変化は、モデルの性能そのものよりも、「評価・コスト・権限・検収・記録」という運用側の論点が、見積もりと契約の中心に移動したことに集約されます。
裏を返せば、発注前に「どのデータを使い、どこまで自動化し、何をもって合格とするか」の3点を決めておけるかどうかで、プロジェクトの成否と費用の大半が決まります。技術選定は、その後の話です。
AIを組み込んだ業務システムの導入をご検討の際は、まずこの3点を社内で言語化するところから始めることをお勧めします。整理が難しい場合は、要件定義の前段として短期の検証フェーズを設ける進め方もご相談ください。