2026.09.21
AI調達仕様書を失敗なく作る実務ガイド
IT関連
AI調達仕様書は、生成AIやAIシステムの導入成果を左右する設計図です。機能を列挙するだけでは不十分で、業務課題、データ、セキュリティ、契約条件を一貫して定義する必要があります。
公共調達では、情報化企画書からRFI、参考見積もり、仕様書作成、入札、契約、検収へと進みます。標準的に約8ヶ月を要するため、初期の要件整理が曖昧だと、後工程の修正コストが大きくなります。
本記事では、自治体・行政機関を中心に、民間企業にも応用できる仕様書の構成、生成AIの安全な活用方法、競争性を保つレビュー、運用・契約までを実務順に解説します。
AI調達仕様書の役割と作成の全体像
仕様書は調達の公平性と成果を決める
仕様書の役割は、発注者が達成したい業務成果を、参加事業者が同じ条件で提案・見積もりできる形に変換することです。曖昧な表現は認識差を生み、導入後の追加費用や納期遅延につながります。
特にAI導入では、「チャットボットを入れる」といった手段から書き始めず、問い合わせ削減、審査時間短縮、知識検索改善など、解決したい業務課題と測定指標を先に定めます。
経済産業省には70以上の既存システムがあります。既存環境との連携、データの所在、担当部門の権限を把握せずに新規AIを調達すると、重複投資や連携不能のリスクが高まります。
- 業務上の課題と到達目標を分けて記載する
- 事業者が比較可能な評価条件を明示する
- 既存システム・制度・運用との整合を確認する
調達開始から落札までの標準的な流れ
調達は、情報化企画書で目的と予算の妥当性を固めることから始めます。その後、RFIで市場の製品・技術・供給体制を調べ、参考見積もりで仕様と予算の釣り合いを検証します。
次に、調査結果を基に要求事項を仕様書へ落とし込みます。入札公告後には質問回答を行い、提案・価格・体制を評価して落札者を決定します。要件確定前に公告を急ぐと、質問が集中しやすくなります。
仕様書作成だけでも20～50人日の工数がかかることがあります。作成担当、業務部門、情報セキュリティ部門、契約部門のレビュー日程を先に確保し、差戻しを減らす進め方が重要です。
| 工程 | 主な作業 | 確認の焦点 |
|---|---|---|
| 企画 | 課題・効果整理 | 目的と予算 |
| RFI | 市場調査 | 実現性と選択肢 |
| 仕様作成 | 要件・評価基準化 | 公平性と明確性 |
| 入札・契約 | 質問回答・審査 | 透明性と履行体制 |
| 検収・運用 | 受入確認・改善 | 成果と継続性 |
- 企画段階で成果指標と対象範囲を定める
- RFIで市場性と実現可能性を確認する
- 参考見積もりで予算・工数・契約期間を検証する
関係者と決裁の役割を先に決める
円滑な調達には、誰が要件を決め、誰が承認し、誰が検収するかを早期に定義することが欠かせません。担当者一人に文章作成と判断を集中させると、業務知識や統制面の抜けが起こります。
業務部門は現場課題と受入条件、情報部門は連携・運用・セキュリティ、契約部門は競争性と契約条項を担当します。責任分界を文書化すれば、事業者との質疑でも一貫した回答をしやすくなります。
教育分野では、宇部市立中学校12校を対象にした案件のように、学校、教育委員会、利用者、保護者など関係者が広がります。利用対象と意思決定者を混同せず、説明責任の窓口を定めましょう。
- 業務責任者とシステム責任者を区別する
- 承認者・相談先・最終決裁者を一覧化する
- 利用者への説明と問い合わせ窓口を設ける
要件を漏れなく整理する仕様書の基本構成
業務要件は利用場面と成果から定義する
業務要件は、誰が、どの場面で、何を完了できるべきかを記すものです。「AIを活用する」ではなく、対象業務、入力情報、判断者、出力物、完了基準を一連の業務フローとして明確にします。
例えば学校向けサービスなら、市立中学校12校の中学1～3年生、約3,700人を対象とし、年5回を想定する、といった利用条件が規模設計の土台になります。対象者数はライセンス、サポート、回線負荷にも影響します。
導入効果は、処理時間、誤入力率、問い合わせ件数、利用率などで測定します。定量化が難しい場合も、現行手順と導入後手順を比較できる受入シナリオを作り、検収時の判断を可能にします。
- 利用者・対象業務・利用頻度を具体化する
- 入力から出力、承認までの流れを描く
- 検収できる成果指標と受入条件を設定する
機能要件は操作と連携を検証可能に書く
機能要件は、利用者が実行する操作とシステムの応答を確認できる粒度で書きます。「検索機能を提供する」だけで終えず、検索対象、権限別の表示範囲、保存可否、出力形式まで定義します。
生成AIを含む機能では、回答生成、根拠表示、プロンプト履歴、管理者による利用状況確認、禁止語設定などを分けて記載します。AIの回答内容を自動で確定させず、人が確認する業務設計も必要です。
外部システム連携では、APIの有無だけでなく、連携項目、同期頻度、エラー時の通知、再送方法、責任分界を示します。データ移行についても、移行元・移行先・件数確認・復旧手順を要件化します。
- 操作単位で入力、処理、出力、例外を定義する
- AI回答の確認者と修正方法を決める
- API連携とデータ移行の検証条件を明記する
非機能要件は運用できる水準に具体化する
非機能要件は、性能、可用性、セキュリティ、保守性を測る条件です。曖昧な「安定稼働」ではなく、利用時間帯、同時接続、障害通知、復旧目標、バックアップ範囲を業務影響に合わせて定めます。
利用環境は、OSをWindows10／11、ブラウザをGoogle Chrome／Microsoft Edgeとするように、対象端末と対応範囲を明示します。庁内ネットワーク、LGWAN、持ち出し端末の利用可否も確認が必要です。
アクセシビリティ、監査ログ、災害時の継続利用、データ保管場所も軽視できません。IPAの非機能要求グレードを参照しつつ、自組織に必要な水準へ絞り込むと、過剰仕様を避けられます。
- 利用環境と対応ブラウザを明確にする
- 障害対応・バックアップ・復旧条件を定める
- 監査ログとアクセシビリティの要件を確認する
生成AIで原案を作る際の安全な使い方
生成AIは原案作成と論点抽出に活用する
生成AIは、完成版を自動作成する道具ではなく、原案と確認論点を速く作る補助者として使うと有効です。業務目的、対象者、現行資料、庁内様式を入力し、章立てや不足質問を出力させます。
初期条件を適切に設定すれば、調達仕様書の90～95％を自動的に作成できるサービスもあります。また、初めてでも1時間程度で仕様書のたたき台を出力できるという実績もあります。
ただし、その数値は完成品質を保証するものではありません。制度、調達条件、技術制約は案件固有であり、生成文を貼り付ける前に、担当部門が根拠資料と照合する工程を必ず置きます。
- 既存様式と業務資料から章立ての原案を作る
- 不足している要件を質問形式で洗い出す
- 出力文を根拠資料と照合してから採用する
入力データは分類して持ち込む
AI利用時は、入力してよい情報を事前に分類することが最重要です。公開済み資料、庁内限定資料、個人情報・機密情報を分け、機密性が高い情報は外部サービスへ無加工で入力しない運用を徹底します。
過去仕様書には、担当者名、連絡先、未公表の予算、脆弱性情報が残る場合があります。マスキング、要約、アクセス権限の限定を行い、どの資料を誰がいつ入力したかをログで追跡できるようにします。
契約前には、入力データがモデル学習へ利用されるか、保存場所はどこか、保持期間はどの程度かを確認します。これらを説明できないサービスは、行政・重要業務での利用対象から外す判断が必要です。
- 公開・内部・機密の情報区分を定める
- 個人情報と未公表情報をマスキングする
- 学習利用、保存先、保持期間、ログを確認する
質問設計で出力の品質を上げる
品質を高めるには、一度に完成文を求めず、質問を分割する方法が有効です。最初に業務課題、次に利用者、続いて機能・非機能・契約条件を質問し、各回答を人が確認してから統合します。
プロンプトには、参照してよい資料、採用してはいけない仮定、出力形式、根拠不明箇所の表示方法を指定します。「不明な場合は推測せず、確認質問を返す」と明記すると、もっともらしい誤記を減らせます。
過去の類似案件、入札情報、落札金額を参照する場合も、案件規模、地域、契約期間、物価状況の違いを確認します。類似性だけで価格や要件を転用せず、比較条件を記録に残しましょう。
- 要件領域ごとに質問を分けて確認する
- 根拠不明の箇所を明示させる
- 類似案件は条件差を確認して参照する
AI調達仕様書を人が検証するレビュー基準
レビューは根拠・公平性・実現性の順で行う
AI調達仕様書のレビューは、根拠、競争性、実現性の順で進めると効率的です。まず、記載された業務課題や制度要件が原資料に基づくかを確認し、生成AIが補った推測を除外します。
次に、特定企業の製品名、独自機能、不要に限定的な認証条件がないかを確認します。必要な場合は固有名詞ではなく性能・互換性・運用条件で表現し、同等以上の提案を認める考え方を示します。
最後に、予算、期間、体制で実現可能かを検討します。参考見積もりやRFIの回答と比べて過大な要求になっていないか、導入後に職員が運用できるかを、現場担当者と一緒に判断します。
- 各記載の根拠資料を確認する
- 競争を不当に制限する表現を除く
- 予算・期間・運用体制との整合を確認する
ハルシネーションは受入基準で検出する
生成AIの誤りは、文章の自然さではなく、検証可能な受入基準で検出します。制度名、法令、技術仕様、数字、参照URLなど、誤りの影響が大きい項目を優先して原典と照合します。
レビュー表には、「根拠あり」「確認中」「削除」「要修正」の状態を設けます。根拠を示せない要件は採用せず、事業者へ確認すべき事項は質問事項として分離することが、安全な判断につながります。
一度のレビューで終えず、業務部門、情報セキュリティ部門、契約部門がそれぞれ確認します。AIの生成履歴、修正理由、承認者を残せば、監査や次回調達での説明可能性も高まります。
- 数字・制度・技術条件を原典と突合する
- 確認状態と修正理由をレビュー表に残す
- 部門横断で承認し、履歴を保存する
プロトタイプと質問回答で要件を磨く
仕様の曖昧さを減らす最短の方法は、重要な画面や業務フローをプロトタイプで確認することです。利用者が実際の操作場面を想像できるため、文書だけでは見つからない権限、入力項目、例外処理を発見できます。
公告前には、現場職員によるセルフチェックを実施します。「この条件で日常業務が止まらないか」「利用者へ説明できるか」「障害時の代替手段があるか」を確認し、改善点を仕様へ反映します。
公告後の質問は、すべての参加者に同じ条件で公開します。個別事業者とのやり取りで要件を実質変更しないよう、回答が仕様変更に当たる場合は、必要な手続と期限見直しを行います。
- 利用者が触れる画面・帳票を先に試作する
- 例外処理と障害時の代替手段を確認する
- 質問回答を公平に公開し、変更履歴を残す
契約・運用・検収まで見据えた発注条件
利用条件と支援範囲を具体的に定める
運用開始後の混乱を防ぐには、利用者数、アカウント数、利用期間、支援内容を仕様に書くことが必要です。対象校ごとに各校10アカウントのように、配布単位と追加時の扱いを明確にします。
利用期間は、令和7年7月1日から令和8年3月31日までのように開始・終了日を明記し、更新、データ返却、アカウント停止の手順も定めます。試行利用と本格利用の条件は分けて考えるべきです。
操作説明会、管理者研修、問い合わせ対応、障害連絡、定例報告の有無も重要です。導入だけを成果とせず、利用定着に必要な伴走支援を調達範囲に含めることで、現場の不安を抑えられます。
- 利用者・アカウント・期間を数量で定義する
- 研修・問い合わせ・障害対応の窓口を定める
- 更新・終了時のデータ返却条件を決める
保守と責任分界を契約条件に落とし込む
保守条件では、障害時の連絡方法、一次回答、復旧報告、原因分析の範囲を定めます。稼働率だけでなく、業務停止の影響度に応じて優先度を分類すると、双方の対応判断がぶれません。
業務終了後1年間は瑕疵担保責任とする条件のように、成果物の不備をどの期間・範囲で修補するかを確認します。AIモデルの出力内容と、システム障害・設定不備の責任は分けて規定する必要があります。
損害賠償、再委託、秘密保持、知的財産権、支払方法も契約前に整理します。特にAIサービスでは、入力データの権利帰属と、出力結果の利用範囲を曖昧にしないことが重要です。
- 障害優先度と報告内容を定める
- 瑕疵担保の期間と修補範囲を明確にする
- データ・知的財産・再委託の条件を確認する
検収後は利用実態を測定して改善する
検収は、納品物の確認だけでなく、業務要件が満たされたかを判定する工程です。機能試験、権限試験、セキュリティ確認、操作説明、データ移行結果を、事前に定めた受入基準に沿って記録します。
運用後は、ログを用いて利用者数、利用頻度、よく使われる機能、エラー、問い合わせを分析します。利用が低い部署は、操作性、権限、研修、業務フローのどこに障害があるかを確認します。
ALION株式会社のように、専属チームで伴走する開発体制を選ぶ場合も、要望を都度追加するのではなく、改善要望の受付、優先順位付け、リリース判定の手順を合意しておくことが大切です。
- 受入試験の結果と未解決事項を記録する
- 利用ログと問い合わせを定期的に確認する
- 改善要望の受付・優先順位・反映手順を決める
まとめ
AIを活用した調達では、原案作成の速さだけでなく、要件の根拠、競争性、情報管理、検収可能性を一体で設計することが成功条件です。生成AIは下書きと論点整理に活用し、最終判断は複数部門による検証で担保しましょう。
要点
- 業務課題と成果指標を先に定め、機能から書き始めない
- 生成AIの出力は根拠資料と照合し、推測を仕様へ残さない
- 特定事業者に偏らない性能・運用条件で競争性を確保する
- 入力データの分類、保存、学習利用、ログ管理を確認する
- 契約、保守、検収、改善までを発注条件に含める
まずは現行の仕様書や要件メモを見直し、業務要件・非機能要件・データ管理・レビュー担当者の4点を一覧化してください。複雑なAI導入では、業務と技術の双方を理解する開発パートナーに早期から相談することが有効です。
よくある質問
Q1. 生成AIで作った仕様書をそのまま入札に使えますか？
そのまま使うべきではありません。業務部門、情報セキュリティ部門、契約部門が、根拠、競争性、実現性、個人情報の取扱いを確認し、修正・承認した版を使用してください。
Q2. 特定製品を想定している場合、仕様書にはどう書けばよいですか？
製品名ではなく、必要な性能、連携方式、運用条件、セキュリティ要件で記載することが基本です。固有の条件が不可欠な場合は、その必要性を文書化し、同等以上の提案可否も検討します。
Q3. AIサービスの仕様書で必ず確認すべきデータ条件は何ですか？
入力可能なデータの区分、保存場所、保持期間、モデル学習への利用可否、アクセス権限、操作ログ、契約終了時の削除・返却方法を確認します。
Q4. 非機能要件はどこまで細かく書くべきですか？
業務停止や情報漏えいの影響に見合う粒度で書きます。利用時間、対応端末、障害連絡、バックアップ、復旧、監査ログ、アクセス制御などを、検証可能な条件として定義することが重要です。
Q5. RFIと参考見積もりはなぜ必要ですか？
市場にある選択肢、実現可能な機能、導入体制、概算費用を把握し、過度な要求や予算不足を防ぐためです。仕様書の競争性と実現性を確認する材料になります。
参考文献・出典
 #…
metidx-gov.note.jp
  [OUR POLICY うるるらしさ](/our_policy)…
www.uluru.biz
PR TIMESのご利用について 資料をダウンロード # 調達仕様書作成に生成AIが伴走－“質問に答えるだけ”で、原案をスピード作成！調達インフォが「仕様書原案作成機能」を提供開始 ## ～公共調達DXを推進、職員の負担軽減と生産性向上を支援～ 株式会社うるる…
prtimes.jp