この記事で分かること
- 目的やKPIを、検証できる業務要件に変える方法
- データ、権限、システム連携、非機能要件で確認する項目
- AIの評価基準、受入条件、運用保守を仕様にする考え方
- 契約前に明確にする成果物、変更手順、発注側とベンダーの役割
発注仕様書は、ベンダーへ渡す「判断の前提」をそろえる文書
発注仕様書と呼ぶ書類の形式は会社や案件によって異なります。RFP、要求仕様書、提案依頼書、要件一覧などの名前が付いていても、重要なのは書名ではなく、候補会社が同じ条件で提案できる情報が揃っていることです。業務の背景、対象範囲、用意できるデータ、利用者、希望する時期、判断できていない点を開示し、各社に「どの前提で、何を、どこまで行う提案か」を回答してもらいます。
発注側がすべての技術方式を先に決める必要はありません。むしろ、業務上の制約と達成したい結果を明記し、方式の提案はベンダーに求める方が適切な場面があります。その場合も、提案書には採用する方式だけでなく、選定理由、別案との違い、必要となるデータや環境、リスク、運用費用、未確定の条件を書いてもらいます。仕様書を「答えを指定する文書」と「必要な結果と制約を伝える文書」に分けると、固定する項目と提案を募る項目が見分けやすくなります。
このページで紹介する項目は、すべてを一律に必須化するチェックリストではありません。対象業務や扱う情報、AIの出力が人や顧客へ与える影響に合わせて、必要な深さを選びます。まずは未確定事項も含めて書き出し、誰がいつ判断するかまでセットで管理しましょう。
目的とKPIは、現在の業務と比べられる形で書く
「AIを導入する」「業務を効率化する」だけでは、何を作るべきか、成功したといえるかを判断できません。対象の部署や作業、現在の手順、困っている場面、変更後に期待する状態を説明します。たとえば、問い合わせの回答案を作る仕組みなら、受付から回答までのどの工程を支援するのか、現状は誰がどの資料を見ているのか、AIの案を誰が確認するのかを書き分けます。
KPIは業務で実際に測れる指標を選びます。作業時間を短縮したいなら、対象となる作業の開始・終了時点、計測者、対象件数、比較する期間を定義します。確認負荷を下げたい場合は、AIの出力を修正した回数や確認にかかる時間が候補になります。問い合わせ対応なら、初回回答までの時間と、誤案内を防ぐための人の確認負荷を同時に見るなど、速さだけでなく品質や安全性も並べておくと、指標の一つだけを良くする提案を避けられます。
導入前の実績値がすぐに取れない場合は、発注前に短期間の計測を行うか、初期段階の調査成果物としてベンダーへ求めます。導入後に都合のよい指標へ入れ替えないよう、指標の定義、対象データ、測定者、評価タイミングを記録してください。数値目標を仮置きする場合には、合意済みの目標と区別し、仮置きの見直し条件も添えます。
業務目的と現状を一枚にまとめる
仕様書の冒頭に「対象業務」「現状の困りごと」「変更後の姿」「測る指標」「判断する人」を短くまとめると、担当者やベンダーが後続の要件を読む軸になります。たとえば、作業時間を減らすことが目的でも、重要な案件の見落としを許容しないなら、その制約を先に置きます。AIを使わずに画面改善や検索機能で解決する案も、比較候補として残しておきます。
AIに任せる範囲と、システムの対象範囲を切り分ける
「AIで自動化する」とだけ書くと、AIが候補を提示するのか、担当者の承認後に処理するのか、無人で確定まで行うのかが伝わりません。AIが受け取る入力、返す出力、出力後の人の作業、例外の扱い、最終判断者を業務フローに沿って記述します。特に、顧客への回答送信、発注、審査など、結果が社外や重要な業務判断へつながる処理は、確認や差し戻しの段階を明確にします。
システムの境界も定義します。新しく作る画面だけでなく、既存の基幹システム、顧客管理、文書保管、認証基盤などとの接続が必要かを記載します。どのシステムを正本として扱うか、誰がデータを更新するか、手入力やファイル受け渡しが残るかも整理します。連携先が決まっていなければ、候補、確認担当、決定期限、未決のまま進める場合の暫定方式を明示しましょう。
対象外も同じくらい重要です。最初のリリースで対応しない部署、データ形式、言語、例外処理、既存機能の改修を一覧にします。「後から追加するかもしれない」項目は、今回の見積範囲と混同しないよう、将来候補として別欄に置きます。範囲が決まっている項目と未決事項を分けておくと、追加要望が出たときに、費用・期間・テストへの影響を相談しやすくなります。
利用データと権限は、出所から削除まで追えるようにする
AIの性能や安全性は、モデルだけで決まりません。入力するデータの種類、内容の正確さ、更新状況、利用できる目的、アクセス権限、保管方法が設計に影響します。発注側でデータの出所や利用可否を確認し、ベンダーには不足する加工、匿名化、分類、検索用インデックス化などの作業を提案してもらいます。データの整備そのものを委託する場合も、業務として正しい内容かどうかを誰が承認するのかは分けて記載します。
| 確認項目 | 仕様書に書く内容 |
|---|---|
| データの種類と出所 | 文書、画像、音声、履歴などの区分、管理部署、元システム、利用可能なサンプル |
| 状態と更新 | 欠損、表記ゆれ、古い情報の有無、更新頻度、正本、更新を承認する担当 |
| 機密性と利用範囲 | 個人情報・機密情報などの分類、利用目的、共有できる相手、持ち出しや二次利用の可否 |
| 保管と終了時の処理 | 保存先、保存期間、バックアップ、削除・返却の方法、終了確認の証跡 |
| 外部サービスへの送信 | 送信項目、送信先の区分、ログや学習利用の扱い、接続条件、変更時の通知 |
本番データを使う前に、検証用データの作り方と持ち出し制限を決めます。テストのために実データを複製する場合は、閲覧者、保管場所、利用期限、削除担当を明記します。ベンダーやクラウドなど第三者が関わるときは、どの事業者がどの情報を扱い、再委託や国外保管があるかを回答してもらいます。法令上の評価や契約条項の確定は自社の法務・情報管理担当が行い、発注仕様書では確認対象と判断責任者を明らかにしてください。
データの流れと権限範囲を見える化する
入力データがどこから来て、誰が閲覧し、どの処理を経て、どこへ保存され、いつ削除されるのかを、簡単な図か一覧にします。AIに渡してよい情報と、担当者だけが扱う情報を区別し、権限のない利用者が検索結果やログから情報を見られないことも要件にします。ベンダーにはデータフロー図とアクセス権限表の作成を依頼し、発注側が承認する工程を決めてください。
機能要件は、画面・入力・出力・例外をひとまとまりにする
機能一覧は、業務の場面ごとに「誰が、何を入力し、システムが何を返し、利用者が次に何をするか」を書きます。AIを組み込む場合は、通常の画面や連携に加えて、AIの出力、根拠表示、編集・承認、再実行、利用者からの誤り報告など、出力を業務へ接続する動作が必要になることがあります。画面の見た目だけでなく、操作権限や保存される履歴まで含めましょう。
- 利用者の役割ごとに、閲覧・実行・編集・承認できる操作
- 必須入力、任意入力、不足情報や想定外形式に対する応答
- AIの回答・候補・分類結果と、必要な場合の根拠や参照元
- 人による確認、修正、差し戻し、確定後の連携先
- 処理失敗、タイムアウト、AIを使えないときの手動代替
- 操作履歴、再実行、問い合わせや誤り報告の記録
既存システムと接続する場合、連携方向、項目、頻度、失敗時の再送、重複処理を避ける方法、テスト環境を仕様に加えます。連携仕様が公開されていない場合は、調査を誰が担当するかを先に決めます。対象となる業務や技術上の前提がまだ整理できていないなら、AIシステム開発の要件定義で扱う精度・データ・責任範囲の整理も参照しながら、発注前に決定事項を洗い出せます。
非機能要件は、性能・可用性・セキュリティを測れる条件にする
非機能要件は「安全で使いやすいこと」「速く動くこと」という希望だけで終わらせず、利用環境と確認方法をセットにします。稼働時間、同時利用者、対象データ量、応答時間の測定方法、障害時に許容できる停止、バックアップからの復旧、問い合わせ窓口などを、業務の影響に合わせて定めます。まだ数値が決められない項目は、ベンダーの標準値を回答させ、比較後に発注側が決定する項目として扱います。
AIの出力品質とアプリケーションの性能は分けて考えます。たとえば、画面表示が速いこと、分類結果が業務に合うこと、回答に根拠が付くことは別々に測る要件です。生成AIを使う仕組みなら、出力のばらつきや外部モデルの変更も前提に、バージョン管理、評価の再実施、利用者への周知方法を決めます。ベンダーには、選定するモデルやサービスの識別情報、変更が及ぼす範囲、代替案と移行作業を説明してもらいます。
セキュリティでは、認証と権限、通信・保存時の保護、ログの閲覧者と保存期間、秘密情報の管理、脆弱性の検査と修正報告、委託先管理、インシデント連絡を確認します。生成AIの場合は、利用者入力を通じた不適切な指示、検索対象のアクセス制御、回答に含まれる機密情報、根拠のない出力など、対象業務で起こり得る失敗を洗い出します。仕様書には抽象的な「AIセキュリティ対応」ではなく、試験項目、報告物、合格後も継続して監視する担当を記述します。
2026年3月31日公表の日本の「AI事業者ガイドライン」第1.2版は、AI開発者・提供者・利用者に関する事項をそれぞれ整理し、主体共通の指針やAIガバナンスも扱っています。発注仕様書で、開発会社だけでなく自社が担う説明、利用者教育、監視、問い合わせ対応まで区別しておく考え方の参考になります。ガイドラインの記載をそのまま契約要件とみなすのではなく、案件のリスクと自社のルールに応じて確認範囲を決めましょう。
評価と受入条件は、テスト方法・対象・合格後の対応まで決める
受入条件を「AIの精度が十分であること」とだけ定めると、何をもって十分と判断するのかが残ります。AIの用途ごとにテストケースを用意し、正解や期待する動作、許容できない誤り、評価者、再試験の手順を決めます。既存の評価データを使う場合は、学習・調整に用いたデータと最終評価に使うデータをどう分けるかもベンダーと合意し、評価対象が後から変わらないよう版を記録します。
| 評価の観点 | 仕様書に置く確認条件の例 | 残す証跡 |
|---|---|---|
| 通常ケース | 代表的な入力で必要な出力や処理が得られるか | 入力例、期待結果、実行結果、評価者 |
| 例外ケース | 情報不足、古い資料、対象外の依頼で安全に保留できるか | 失敗条件、警告・差し戻しの動作、未対応範囲 |
| 誤りの影響 | 重大な誤分類や根拠のない回答をどう検知し、誰が止めるか | 重大度、対応担当、再発防止、再試験記録 |
| 運用負荷 | 人の確認時間や修正量など、導入目的に関わる指標を満たすか | 測定方法、対象件数、比較条件、測定期間 |
合格条件には、ソフトウェアの納品物だけでなく、マニュアル、管理者向け手順、セキュリティ検査の結果、運用担当への説明、未解決事項の一覧などを含めます。条件付きで受け入れる場合は、利用範囲の制限、残課題の担当者、解消期限、未解消時の停止や手動手順も決めます。評価に必要なデータや業務担当者を発注側が用意するなら、その準備期限も工程に記載してください。
評価と受入を運用開始までつなぐ
受入テストの結果は、合格・条件付き合格・不合格などの判定だけでは十分ではありません。評価対象のバージョン、テストデータ、実行者、想定との差、修正内容を記録し、リリース後の監視項目とつなげます。プロジェクトの途中でモデルやデータが変わった場合に、どの試験をやり直すかも定義しておけば、本番環境に移した後の再評価を契約範囲と調整しやすくなります。
AIシステム会社へ依頼する前に、見積もりの前提や期間、失敗しやすい条件を押さえたい場合は、AIシステム会社に頼む前の費用・期間・発注術も参考になります。評価で扱うデータの整備方法を詳しく検討する際は、AIシステム開発に必要なデータの整備・評価も確認してください。
工程と成果物は、各段階の完了条件と合わせて依頼する
発注仕様書には、開発の開始から運用引き継ぎまでの工程を記載し、各段階で何を確認するかを設定します。たとえば、業務・データ調査、方式の比較、小規模な検証、要件確定、実装、受入テスト、限定導入、本番移行という流れが考えられます。案件に必要な工程を選び、検証結果によって本開発を進めるか見直すかの判断者を決めます。PoCを実施する場合は、検証して分かることと、製品化の範囲を混ぜないようにします。
成果物は「設計書一式」のような曖昧な名前ではなく、中身と利用目的を明記します。画面・連携・データの設計書、構成図、テスト計画と結果、利用者・管理者マニュアル、操作ログの仕様、運用手順、障害時の連絡先など、発注側が引き継ぎや保守に使う資料を列挙します。ソースコード、設定値、プロンプト、モデルやライブラリの識別情報などを受け取るか、どの形式で保管するかも契約と合わせて確認します。
各工程の出口には、発注側が確認する資料と承認する担当者を置きます。前の工程が終わっていないのに次の作業へ進む場合は、その影響や未決事項を記録します。提案依頼時点で納期や予算が固定されているなら、ベンダーには前提が崩れた際の優先順位や縮小案も示してもらい、範囲の調整方法を合意しましょう。
運用保守では、誤り・障害・モデル変更を誰が扱うか決める
本番稼働後にAIが想定外の出力をしたとき、利用者がどこへ報告し、誰が影響を判定し、どの条件でAI機能を止めるかを決めます。障害対応は、連絡先と受付時間、初動の目安、調査に必要な情報、復旧報告、原因と再発防止まで含めて定義します。重大な処理をAIが止まった状態でも続けられるよう、手動への切り替えや代替手段も仕様に含めます。
データや業務が変わると、導入時には十分だった評価が合わなくなることがあります。利用状況、誤り報告、回答の修正、入力データの変化など、業務上意味のある項目を監視対象にします。定期的な確認の頻度、判定する担当者、改善を提案する窓口、再学習や追加開発の見積方法を契約前に相談してください。毎月の監視が必要か、重大な更新時だけ再試験すればよいかは、用途とリスクに応じて決めます。
外部モデルやサービスの更新、料金体系・提供条件の変更が起きた場合に備え、ベンダーからの通知方法、影響調査、変更の承認、テスト、切り戻しを定義します。モデルを同じ名称のまま変更する場合でも、業務への影響を確認する責任者を置きます。データを使った追加調整を予定するなら、その作業の費用、判断条件、検証データ、成果物、作業後にデータをどう扱うかを合意しておきましょう。
契約では、データ・成果物・変更・終了時の扱いを具体化する
契約で確認する内容は、開発範囲、納品物、受入の方法、変更手続き、支払条件だけではありません。発注側が提供するデータ、開発会社が利用する既存ソフトやモデル、個別に作るプログラムや資料について、利用できる人・目的・期間・終了時の扱いを整理します。著作権や知的財産などの権利関係は案件の契約内容や適用法令で異なるため、仕様書に「自社が必要とする利用・改修・保守の範囲」を書き、契約条文は法務担当と確定します。
データの共有・利用やAI開発を伴う契約を検討するときは、総務省・経済産業省のAI事業者ガイドライン第1.2版に付属する、AI・データ利用の契約ガイドラインを参照する際の留意事項も確認材料になります。公的な指針を読むだけで個別契約の条件が決まるわけではありません。自社のデータを開発・検証・運用のどの段階で使うか、開発会社が保存するか、終了時に返却・削除できるかなどを具体的な質問にして、契約担当者と回答を残してください。
仕様変更を管理するためには、変更提案の受付窓口、影響見積もりの範囲、承認者、更新する文書やテスト、納期・費用の再合意手順を決めます。口頭で合意した追加作業が積み重なると、当初の価格や受入条件と何が違うか追いにくくなります。作業の開始条件を「影響を確認した後、指定者が承認すること」と文書化し、記録を残しましょう。
保守を終了したりベンダーを変更したりする際の移行も、契約前に確認します。データ、コード、設定、手順書をどの形式で引き渡すのか、引き継ぎ支援は何を含むのか、第三者サービスの契約を誰が引き継ぐのか、アカウントをいつ閉じるのかを決めます。将来の担当会社が作業を再開できるだけの情報が残るか、具体的な成果物一覧で確認してください。
役割分担は、決める人・作業する人・承認する人を分ける
発注仕様書に「ベンダーと協議のうえ決定」と書いても、協議を始める人や最終決定する人が不明なら、重要な論点が保留になり続けます。業務目的と受入条件の責任は誰が持つか、データを出せるか誰が確認するか、セキュリティを誰が承認するか、稼働後の問い合わせを誰が受けるかを決めます。開発会社が専門作業を担っても、業務上の正しさや社内ルールの判断を代行できるとは限りません。
| 役割 | 発注側で決める事項 | ベンダーへ依頼する作業の例 |
|---|---|---|
| 業務責任者 | 目的、優先順位、業務上許容できる誤り、受入承認 | 業務フロー整理、実現方法の提示、運用制約の説明 |
| データ管理者 | 正本、利用可否、内容の正しさ、社内の閲覧権限 | データ調査、加工・取込の設計、品質課題の報告 |
| 情報管理・セキュリティ担当 | 社内基準、例外承認、監査・事故時の社内窓口 | 構成説明、アクセス制御、検査結果、事故連絡体制の提示 |
| プロジェクト責任者 | 予算、スケジュール、変更、段階ごとの継続判断 | 計画、進捗、課題・リスク、費用差分の報告 |
| 開発会社 | 社内承認や決定に必要な担当者を指定 | 合意した範囲の設計・開発・試験・納品・引き継ぎ |
AIの開発、サービス提供、社内利用を同じ会社が担わない案件もあります。クラウド事業者、既存システム会社、AI機能を作る会社、自社の利用部門の間で、障害調査やモデル変更の責任が抜けないようにします。2026年時点の日本のAI事業者ガイドラインも主体別の構成を採っています。隣り合う会社同士でどこまでを引き受けるか、連絡先と引き継ぎ点を仕様書の役割表に残すと、契約後の「相手の範囲だと思っていた」を減らせます。
提案依頼では、回答形式をそろえて比較可能にする
仕様書を複数社へ渡すなら、提案書で回答してほしい項目をあらかじめ指定します。技術名や構成図だけではなく、要件への適合状況、提案の前提、未対応範囲、発注側に求める作業、費用に含む工程、追加になり得る条件、運用後の支援内容を回答してもらいます。わからないことを「対応可能」とだけ答えず、確認方法や判断時期を記述するよう依頼してください。
- 各要件への対応可否と、実現方法・根拠・制約
- AIモデルや外部サービスの選定理由、変更時の影響と代替案
- データ準備や社内担当者の作業、発注側が準備する環境
- 工程別の成果物、確認者、受入条件、未確定事項
- 開発・検証・運用それぞれの費用と、追加費用が生じる条件
- セキュリティ、障害、データ削除、引き継ぎに関する回答
提案を比べるときは、総額の安さより、同じ対象範囲を見積もっているかを確認します。PoCのみの金額と本番運用を含む金額、初期開発費と継続費、発注側が別途契約する費用を分けて並べます。要件を満たさない提案は「不可」として理由を書いてもらい、妥協案があるなら、どの品質や範囲が変わるかを説明してもらいましょう。
依頼時点で仕様が固まっていなくても、調査工程を分ける方法があります。初期調査の成果物として、業務フロー、データ課題、候補方式、概算と未確定事項を納品してもらい、その結果で本開発の範囲を改めて見積もります。契約前の整理段階では、要件定義で決めるべき精度・データ・責任範囲や、データ準備と評価の基本を参照して、社内で回答できる項目と専門調査が必要な項目を分けるのも有効です。
発注仕様書に転記できる確認欄
次の項目を埋めると、提案依頼や初回のベンダー相談で議論を始めやすくなります。すべての項目を発注側だけで決定する必要はありません。空欄には「誰が、いつ、何を確認して決めるか」を書き、判断待ちのまま開発着手する場合にどの範囲を保留するかも残してください。
| 仕様書の項目 | 記入する質問 |
|---|---|
| 背景・目的 | 対象業務、現状の課題、改善後に実現したい状態は何か |
| 対象範囲 | 対象部署・利用者・業務・データと、今回の対象外は何か |
| AIの役割 | 入力、出力、人の確認、例外処理、最終判断者は誰か |
| 評価と受入 | テスト対象、評価方法、重大な失敗、合格者、残課題の扱いは何か |
| 非機能・セキュリティ | 利用環境、性能、権限、ログ、保存・削除、障害時の対応は何か |
| 運用と責任 | 監視、問い合わせ、モデル変更、改善、社内外の連絡先は誰か |
| 契約と成果物 | 費用・期間、変更手続き、納品形式、権利、終了時の移行条件は何か |
よくある質問
発注仕様書を書く前に、AIモデルを決めておく必要がありますか？
必ずしも先に決める必要はありません。先に対象業務、入力と出力、扱えるデータ、必要な応答、許容できない誤り、セキュリティ条件を整理します。その条件を満たす方法を提案会社に比較してもらい、費用、制約、運用後の変更方法を確認してから選定すると、技術名だけで方式を決めることを避けられます。
AIの精度は、受入条件に何％と書けばよいですか？
一つの割合だけでは、業務で重要な誤りやテスト条件を表しきれない場合があります。評価するデータとその版、通常例・例外例、分類や出力の種類、重大な失敗、人が確認する範囲、結果の記録方法を先に定めます。業務に合う指標や閾値は対象データを使って検討し、発注側の業務責任者が承認してください。
データの準備を開発会社に任せてもよいですか？
形式変換、重複整理、取込機能の作成などは委託できます。ただし、データが業務上正しいか、目的の利用が社内で認められるか、更新時にどの記録を正本にするかは、発注側で判断者を指定します。準備後のデータ品質を誰が確認するかも、成果物と受入条件に含めてください。
要件が全部決まっていない段階でも、見積もりを依頼できますか？
依頼できます。その場合は、確定事項、仮置き、未決事項を分け、未決事項を確定するための調査や小規模検証を別工程として提案してもらいます。各社が異なる前提で価格を出さないよう、共通の回答様式を渡し、前提が変わった場合の費用・納期の見直し方法も確認してください。
契約書と発注仕様書はどちらに詳しく書けばよいですか？
業務要件、成果物、テスト方法、役割分担などの技術・運用上の詳細は仕様書や合意した別紙で管理し、契約書には文書の優先関係や変更方法などを含めます。具体的な契約条項の整理は案件ごとに異なるため、法務担当や専門家と確認してください。仕様書だけで契約上の責任や権利が自動的に確定すると考えず、契約との整合を確認することが大切です。
まとめ：目的・評価・責任をそろえてから開発会社を選ぶ
AIシステム開発を成功へ導く発注仕様書では、業務の目的、対象範囲、AIと人の役割、データの利用条件、非機能要件、評価と受入、運用、契約上の確認事項を切り分けて記載します。特に、達成したい結果だけでなく、測る方法と失敗時の動作、発注側が決める人まで明記すると、ベンダーの提案や見積もりの前提を比べやすくなります。
最初からすべての技術を確定させる必要はありません。決定済みの条件、比較提案を求める条件、調査が必要な条件を分けて、各項目の判断者と期限を置きましょう。仕様書ができたら、業務・データ・情報管理・運用の担当者がそれぞれの責任範囲を確認し、合意できた範囲から段階的に発注します。
