結論：機能より先に、業務・正解・失敗時を決める
AIシステムの要件定義では、何を作るかだけでなく、どの業務をどれだけ改善するか、AIの出力を何で評価するか、誤回答や外部障害でどう止めて人へ戻すかを決めます。以下の30項目を発注者と開発者で埋めると、見積もりと検収のずれを減らせます。
| 1. 対象業務 | どの業務を改善するか開始点・終了点・担当者・月の件数を書く |
|---|---|
| 2. 現状値 | 時間・費用・ミスを測る導入前の基準がないと効果を比較できない |
| 3. 成功条件 | KPIと合格値を決める削減時間、修正率、対応件数、回収期間など |
| 4. 利用者 | 誰がいつ使うか社内担当者、管理者、顧客、取引先を分ける |
| 5. 権限 | 閲覧・編集・承認を分ける役割ごとに見られるデータと実行できる操作を決める |
| 6. 業務フロー | 導入後の手順を書くAIの前後で人と既存システムが何をするか |
7〜12：AIの役割・出力・合格基準
| 7. AIの役割 | 生成・分類・検索・実行AIが提案するだけか、外部サービスを操作するか |
|---|---|
| 8. 対象外 | AIに任せない判断金銭、契約、採用、医療、安全など重要判断を分ける |
| 9. 人の承認 | どこで確認するか送信、更新、予約確定、削除など重要操作の直前 |
| 10. 出力形式 | 文章・JSON・項目・言語長さ、文体、必須項目、禁止表現も決める |
| 11. 評価データ | 実例と正解を用意するよくある例、難しい例、対象外、攻撃的入力を含める |
| 12. 合格基準 | 精度を測定可能にする母数、正解条件、許容失敗、再試験方法まで決める |
「高精度なAI」では検収できません。固定した評価データ、正解条件、重大な誤り、許容件数を決めます。AIが外部サービスを操作する場合は、提案と実行を分け、重要操作の直前に人の承認を置きます。
13〜18：データ・機密情報・外部連携
| 13. 参照元 | 正本を一つ決める規程、FAQ、商品、予約、顧客情報のどれを信頼するか |
|---|---|
| 14. データ形式 | PDF・表・画像・DB等文字抽出、分割、重複、表記ゆれへの対応を確認 |
| 15. 更新方法 | 誰がいつ更新するか更新頻度、公開前確認、古い情報の削除方法を決める |
| 16. 機密区分 | 入力可能・禁止を分ける個人情報、営業秘密、契約情報、認証情報を分類 |
| 17. 保存と学習 | 保存先・期間・二次利用AI提供者の学習利用、ログ保存、削除依頼を確認 |
| 18. 外部連携 | APIとアカウントを特定LINE、予約、会計、メール、CRMなどの所有者も決める |
データの量より、どれを正本とするか、誰が更新するかが重要です。個人情報や営業秘密は、入力可否、保存先、保存期間、AI提供者による学習利用、削除方法まで確認します。
19〜24：機能・性能・障害・停止
| 19. 画面・機能 | 必要操作を利用者別に書く入力、検索、履歴、承認、管理、エクスポートなど |
|---|---|
| 20. 応答性能 | 待てる秒数と同時利用数通常時と混雑時、タイムアウト後の表示を決める |
| 21. 利用量と上限 | 回数・文字数・月額上限API従量費の警告、制限、停止条件を決める |
| 22. 認証・監査 | ログイン・権限・操作記録誰が何を見て実行したか追跡できるようにする |
| 23. 障害時 | 再試行・代替・人への引継ぎAIや外部APIが止まっても業務を続ける方法を決める |
| 24. 停止方法 | 自動実行をすぐ止められる管理者の停止、回数上限、異常検知後の動作を決める |
正常時の動作だけでは足りません。AI、データベース、LINEなどの外部サービスが止まったときに、再試行するのか、人へ引き継ぐのか、業務全体を止めるのかを決めます。
25〜30：範囲・費用・成果物・検収・保守
| 25. 対象範囲 | 含む・含まないを列挙「AI開発一式」ではなく業務・画面・連携ごとに分ける |
|---|---|
| 26. 役割分担 | 発注者・開発者の担当データ準備、確認、意思決定、アカウント発行を割り当てる |
| 27. 費用・日程 | 初期・従量・保守を分ける追加変更の単価、期限、遅延時の扱いも確認 |
| 28. 成果物・権利 | 何を誰が所有するかコード、データ、設定、評価結果、手順書、再利用条件 |
| 29. 検収 | 確認方法と期間を決める評価データ、合格基準、不合格時の修正・再検査を合意 |
| 30. 保守・終了 | 公開後と解約後を決める不具合、モデル変更、引継ぎ、データ返却・削除を確認 |
PoCと本番、初期制作費と従量費、不具合と仕様変更を分けます。検収は画面が動くことだけでなく、評価データによる品質、応答時間、費用上限、安全な停止まで対象にします。
そのまま使える要件定義の最小テンプレート
| 目的 | 月○時間の作業を○時間へ削減対象業務と現状値を一文で書く |
|---|---|
| 利用者 | 担当者○人・管理者○人権限と利用場面を分ける |
| AIの範囲 | 候補作成まで。送信は人が承認任せること・任せないことを対で書く |
| データ | 社内FAQを正本として毎月更新入力禁止情報と保存期間も書く |
| 合格 | 固定100件中90件以上・重大誤り0件例。業務の影響に合わせて数値を決める |
| 費用 | 初期○円・月額上限○円外部API、保守、追加変更を分ける |
| 納品 | 画面・コード・設定・評価結果・手順書アカウント所有者と引き継ぎ方法も書く |
最初から完璧な文書は不要です。この7項目を仮置きし、相談とPoCの結果で30項目へ広げます。分からない欄を空白にすることも、確認が必要な論点を見つける作業になります。
AIシステムの要件定義を作る7つの手順
実装方法から入らず、業務、利用者、AI、データ、評価、契約の順で具体化します。
STEP 1 一業務と現状値を決める
対象を広げず、開始・終了・件数・時間・ミスを一枚にまとめます。
STEP 2 利用者と導入後の流れを書く
人、AI、既存システムの順序と、役割ごとの権限を整理します。
STEP 3 AIに任せる範囲と承認を決める
提案だけか実行までか、重要操作の前に誰が確認するかを決めます。
STEP 4 データと正解例を準備する
参照する正本、入力禁止情報、評価に使う実例と正解を用意します。
STEP 5 合格基準と失敗時の動きを決める
精度、時間、費用、安全性を数値化し、停止・引継ぎ方法を決めます。
STEP 6 成果物・費用・検収を合意する
対象外、権利、外部費、修正回数、検収期間、保守範囲を書面にします。
STEP 7 PoCで要件を確かめて更新する
2〜4週間の小さな検証で、想定と現場の違いを要件へ反映します。
要件を具体化する関連記事
小さな検証はAI PoCの費用・期間・進め方、発注先の比較はAI導入支援会社の選び方、実行型AIの安全設計はAIエージェントとはで確認できます。
公的な要件定義・契約資料も確認する
IPAは、発注者と開発者の認識違いを減らすための要件定義、非機能要求、モデル契約書を公開しています。経済産業省のAI契約チェックリストは、データ、入力、出力、知的財産権などAI特有の契約論点を整理しています。実際の契約では個別事情に応じて専門家へ確認してください。
参考：IPA「企画・要件定義」／IPA「情報システム・モデル取引・契約書」／経済産業省「AIの利用・開発に関する契約チェックリスト」
よくある質問
AIシステムの要件定義とは何ですか？
AIで改善する業務、利用者、データ、AIに任せる範囲、人の承認、品質、安全性、費用、成果物、検収、公開後運用を、開発前に発注者と開発者で合意することです。
通常のシステム要件定義と何が違いますか？
画面や機能に加え、AIは同じ入力でも結果が変わる可能性があります。そのため、評価データ、正解条件、許容する失敗、人の確認、利用上限、停止方法、モデル変更後の再評価が必要です。
AIの精度は何％に設定すればよいですか？
一律の正解はありません。「精度95％」だけでなく、どの評価データを何件使い、何を正解とし、重大な誤りを何件まで許すかを業務リスクに合わせて決めます。
要件定義は発注者と開発会社のどちらが作りますか？
業務目的、現状、正本、重要判断は発注者が示し、技術方式、評価方法、非機能要件は開発者と共同で具体化します。どちらか一方だけでは実務とのずれが起きやすくなります。
要件定義の前にPoCをしてもよいですか？
最小限の仮説と評価条件を決めたうえでPoCを行うのは有効です。検証結果を使って、データ、品質、操作、費用、安全性の要件を更新します。
30項目を一緒に整理して、動く形まで作ります
現在の業務、件数、例外、参照資料を確認し、AIに任せる範囲、人が承認する範囲、PoCの合格基準と費用を整理します。要件定義から実装、公開後改善まで一人で担当します。
LINE で相談する