「既存プロダクトに AI 機能を 1 つ追加してほしい」と依頼された後、手元の要件定義書テンプレートを開いて手が止まる。機能要件欄に「AI チャット機能」と書いたものの、精度をどう定義するか、幻覚（ハルシネーション）が起きたときの挙動、コストの上限、モデル差し替えの想定など、どこに何を書けばいいのか分からない――そんな詰まり方をしている方は少なくありません。
通常のシステム開発の要件定義書は「決定論的な機能」を前提に設計されています。ボタンを押せば決まったレコードが登録される、ある条件を満たせば決まった通知が飛ぶ、といった具合です。ところが AI 機能は同じ入力でも出力が揺れる「確率的」な振る舞いをするため、既存テンプレートの機能要件・非機能要件・運用要件の各章に、そのままでは埋まらない空欄ができてしまいます。
難しさの本質は「既存テンプレートを捨てて AI 専用テンプレートに乗り換える」ことではなく、「既存の各章にどんな項目をどう追記するか」を機能単位で決めきれない点にあります。プロジェクト全体を語る総論記事は多くありますが、目の前の 1 機能をどう書き足すかの実務手順に落とし込まれた情報は意外と少なめです。
本記事では、既に要件定義書テンプレートを持っている PdM・プロダクトオーナー・情シスの方を想定読者に、既存テンプレートの「機能要件」「非機能要件」「運用要件」の各章に AI 機能をどう追記すべきかを、5 つの観点（機能要件・非機能要件・プロンプト設計・モデル選定・フォールバック）で整理します。最後にそのまま使える追記例と発注前チェックリストを提示し、開発会社に「まずここまで詰めた」と共有できる状態を目指します。
なお「AI 機能を 1 つ追加する」ではなく「AI そのものが主軸のプロジェクト」を検討している方は、より上流の観点（学習データ・PoC・継続学習・倫理）まで含めた全体像を扱った関連記事AIプロジェクトの要件定義ガイドを先にご覧ください。本記事はそこから先の「1 機能に落とし込む段階」に特化しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
既存の要件定義書テンプレートだけではAI機能を書き切れない理由
まず、なぜ既存テンプレートをそのまま流用すると開発会社との認識齟齬が生まれるのかを整理します。「既存テンプレのどこに何を書き足せばいいか分からない」という詰まりの正体は、多くの場合ここにあります。
決定論的な機能要件と確率的なAI機能の書き方の違い
通常の機能要件は「入力 X に対して出力 Y を返す」を厳密に定義できます。仕様書に「同一入力に対して同一出力を返すこと」と書き、テストケースで期待値と実測値を比較すれば合否が判定できます。
一方、LLM を含む AI 機能は同じ入力でも実行ごとに出力が揺れます。要約タスクなら「ほぼ同じ意味だが文言が違う要約」が返り、分類タスクなら「95% の確率で正しいラベル、5% の確率で誤ったラベル」を返す、といった具合です。これを既存テンプレートの「入力→出力」欄に一意に記述しようとすると、どうしても書ききれない空欄が発生します。
必要なのは以下 3 つの追記です。
- 想定入力と想定出力の代表例を複数パターン記載する（絶対値ではなく代表サンプル）
- 許容出力の範囲（何を正解とみなし、何を不正解とみなすか）を定義する
- 精度を評価する方法（後述する評価データセットとレビュー体制）を先に決めておく
これらは通常の機能要件章では触れられないため、既存テンプレートに追記スペースを設ける必要があります。
既存テンプレをそのまま使うと起きる3つの認識齟齬
現場で頻出する認識齟齬は次の 3 つです。いずれも既存テンプレートの空欄が原因で発生します。
-
「精度」の解釈がずれる 発注側は「精度 99% 以上」と書いたが、開発側は「何をもって正解とするか」の合意がないままリリース。運用開始後、精度計測のたびに数字が変わり議論が発散する。
-
モデル指定なしで発注される 発注側は「LLM を使う」とだけ記載し、開発側は「安価な OSS モデルで組んだ」。発注側は「GPT-4 相当の品質」を期待していたため乖離が発覚するのはリリース直前。
-
プロンプトの変更管理が抜ける 発注側は「プロンプトは追加コストなしで直せるはず」と考え、開発側は「プロンプト変更のたびに評価テストを再実施する必要がある」と主張。運用開始後にプロンプト修正の見積で揉める。
これらはいずれも「AI 特有の項目を要件定義書に書いていなかった」ことに起因します。裏返せば、要件段階でここを埋めておけば大半の齟齬は防げます。
本記事の対象範囲（1機能追加 vs AIプロジェクト全体）
本記事は「既存プロダクトに 1 機能として AI を追加する」ケースに絞ります。具体的には次のような機能追加を想定しています。
- 既存の問い合わせ画面に AI チャットボット機能を追加する
- 既存のドキュメント管理システムに AI 要約機能を追加する
- 既存のチケット管理システムに AI カテゴリ分類機能を追加する
一方、下記のような「AI そのものが主軸のプロジェクト」は本記事の対象外です。これらは学習データ設計・PoC・継続学習・倫理観点まで含めた総合的な要件定義が必要なため、専用の記事に整理を委ねます。
- 独自 LLM のファインチューニング前提プロジェクト
- 機械学習モデルの新規開発（画像認識・音声認識など）
- MLOps 基盤の構築プロジェクト
もし読者の状況が後者に近いと感じた場合は、AIプロジェクトの要件定義ガイドを先に確認してから本記事に戻ることをおすすめします。前段の意思決定（そもそも AI プロジェクトとして立ち上げるか、既存プロダクトの一機能として組み込むか）で判断軸が変わるためです。
AI機能の「機能要件」欄に追記する4項目
ここから、既存テンプレートの「機能要件」章に AI 特有の項目をどう追記するかを整理します。既存の入力・出力・画面仕様の記述はそのまま活かし、以下 4 項目（RAG を組む場合は 5 項目）を追記する構成を推奨します。
想定入力・想定出力・許容出力範囲を定義する
AI 機能の入力と出力は「代表サンプル + 許容範囲」で書きます。以下の順に埋めていくと抜け漏れを防げます。
- 想定入力の代表パターン: 短文・長文・記号混じり・空入力など、実際に想定される入力を 5〜10 件列挙する
- 想定出力の代表サンプル: 各入力に対する期待出力を文字数目安・トーン・構造とセットで示す
- 許容出力の範囲: 「多少表現が異なっても意味が保存されていれば OK」「事実誤りは NG」「個人情報の漏洩は絶対 NG」など、合否ラインを言語化する
- 禁止出力: 差別的表現・機密情報・特定固有名詞など、絶対に出してはいけない出力を明記する
「絶対に正解」ではなく「許容範囲」を先に決めることが、後述の精度評価や運用要件の土台になります。
モデル/API選定基準を書く（LLM API種別・自社運用 vs マネージド）
「LLM を使う」だけの記述は避け、以下を要件段階で決めておくと開発会社とのすり合わせが早くなります。
項目 | 記載例 |
|---|---|
利用するモデル種別 | 大規模商用モデル（GPT-4 相当・Claude Sonnet 相当）/ 中規模モデル / 小規模 OSS モデル |
提供形態 | マネージド API（OpenAI / Azure OpenAI / Anthropic / Bedrock 等）/ 自社ホスティング / エッジ実行 |
選定理由 | 精度優先 / コスト優先 / データ主権優先 / レイテンシ優先 のどれを最重視するか |
切替可能性 | 将来的にモデルを差し替える可能性の有無（プロバイダロックインを避けたい場合は抽象化層を要件化） |
要件段階でモデル名を 1 社に固定する必要はありませんが、「候補群」と「選定基準の優先順位」までは決めておきます。これがないと開発会社ごとに提案されるアーキテクチャが大きくばらつき、見積比較が困難になります。
プロンプト設計方針とバージョン管理ルールを明記する
プロンプトは「実装成果物」であり「運用中に変更されるもの」でもあります。要件段階では次の 3 点を明記しておきます。
- プロンプトはコード資産として扱う: プロダクトのソースコードと同じリポジトリでバージョン管理する（別 SaaS・別 Notion で管理すると変更履歴と実装の紐付けが失われる）
- プロンプト変更時の承認フロー: 誰がレビューし誰が承認するかを決める（プロダクトの挙動を変えるため、コード変更と同等の扱いにする）
- プロンプト変更時の評価再実施: プロンプトを変えたら評価データセット（後述）で再評価することを要件化する
「プロンプトは追加コストなしで直せる」という誤解を防ぐ意味でも、要件段階で「プロンプト変更 = コード変更 = 評価テスト再実施」を合意しておくと運用フェーズの見積揉めを予防できます。
人間介在ポイント（Human-in-the-Loop）を明示する
AI 機能をリリースする際、100% 自動で動かすのか、人間が中間・最終レビューを行うのかは要件段階で決めます。以下 4 パターンから選び、必要に応じて画面仕様に反映します。
パターン | 説明 | 代表例 |
|---|---|---|
完全自動 | AI 出力をそのままユーザーに提示 | チャットボットの一次回答 |
提示前レビュー | 内部担当者が承認後にユーザーへ提示 | 顧客への自動メール文案 |
事後レビュー | ユーザーには先に提示し、内部で事後監査 | AI 要約結果 |
フィードバック収集のみ | ユーザーに「不適切」ボタンを提供 | 分類結果の修正フィードバック |
パターンによって画面設計・権限設計・ワークフローが大きく変わるため、後工程で決めると設計が二度手間になります。
RAGを組む場合の追記項目（検索対象・更新頻度・引用の明示）
RAG（Retrieval-Augmented Generation：外部データを検索して LLM の回答に反映する構成）を組む場合は、上記 4 項目に加えて以下を追記します。
- 検索対象データの範囲: どのシステムのどのテーブル/ファイル/ページを検索対象にするか（PDF・Notion・社内 Wiki・データベース等）
- 更新頻度: 検索対象データの更新をいつ何のトリガーで反映するか（リアルタイム / 日次バッチ / 手動）
- アクセス権制御: 検索対象データに閲覧権限がある人にのみ結果を返すかどうか（社内秘情報を含む場合は必須）
- 引用の明示: 回答文中に出典（元ドキュメント名・URL・更新日）を明示するかどうか
- 検索ヒットなし時の挙動: 参照可能な情報がなかった場合に「分かりません」と返すか、LLM の一般知識で回答するか
RAG は精度と信頼性を上げる一方で、検索対象の権限管理を誤ると情報漏洩事故につながります。要件段階で権限モデルを決めきっておくことが重要です。
AI機能の「非機能要件」欄に追記する4項目
続いて、既存テンプレートの「非機能要件」章に追記する項目です。従来の性能・可用性・セキュリティに加え、AI 特有の指標を 4 つ書き足します。
精度目標をビジネス指標に翻訳して書く
「精度 99% 以上」と書きたくなりますが、これだけでは開発会社との合意になりません。以下の 3 段階で書き下します。
- ビジネス指標: この AI 機能が達成したい業務成果（例: 一次回答時間を 50% 短縮、分類作業工数を 30% 削減、問い合わせ自動応答率 60%）
- AI 指標への翻訳: ビジネス指標を達成するために必要な AI 性能（例: 分類正解率 90% 以上、要約の情報カバー率 85% 以上、チャット応答の適合率 80% 以上）
- 測定方法: どの評価データセットで、誰が、どの頻度で測定するか
「99% 以上」のような単一値ではなく、目標値・許容下限値・測定方法 の 3 点セットで書くと、開発会社が達成可能性を判断しやすくなります。目標値と許容下限値を分けるのは、「目標には届かないがビジネス上許容できる下限」を先に決めておくことで、リリース可否判断がぶれないようにするためです。
レイテンシ・スループット目標を書く
LLM API は一般的な CRUD API より応答が遅く、生成トークン数によって秒単位で変動します。以下を要件化します。
- 単一リクエストのレイテンシ目標: 例「初回トークンまで 1 秒以内、最終応答まで 5 秒以内」
- ストリーミング応答の要否: ユーザーに逐次表示するか、完成後に一括表示するか（体感速度は大きく変わる）
- 同時実行数: ピーク時に何セッションを同時処理できる必要があるか
- タイムアウト時の挙動: 何秒でタイムアウトし、その時ユーザーには何を返すか
特にチャット系機能では「ストリーミング応答するかどうか」で UX が根本的に変わります。要件段階で決めておかないと画面設計と実装がずれます。
コスト上限（月額API費用上限）を書く
LLM API は多くが従量課金（入力トークン数・出力トークン数に比例して課金）です。月額のコスト上限を要件化しておかないと、想定以上の利用があった際に無防備に費用が跳ね上がります。
- 月額予算の上限値: 例「本機能単体で月額 30 万円まで」
- 予算超過時の挙動: 超過時にサービスを止めるか、機能を縮退するか、追加課金を許容するか
- モニタリング要件: 日次・週次で使用量をアラート通知する仕組みを実装するかどうか
- 1 リクエストあたりのトークン上限: 想定外に長い入出力による単発コスト暴走を防ぐ
上限値を出すには「想定 MAU × 1 ユーザーあたり月間リクエスト数 × 1 リクエストあたり平均トークン数 × 単価」の試算が必要です。要件書には試算前提と結果の両方を残しておくと、後日の見直しがしやすくなります。
セキュリティ・プライバシー要件を書く
LLM を使う機能では、従来のセキュリティ要件に加えて以下を追記します。
- 入力データの送信範囲: どのクラウドの LLM API に何のデータを送るか（顧客情報・機密情報を送信してよいかの合意）
- プロンプトインジェクション対策: ユーザー入力が LLM への指示を上書きしないよう、入力バリデーション・システムプロンプト分離を実装する
- 出力の後処理: 個人情報・機密情報を含む出力をフィルタリングする仕組みの有無
- ログ管理: プロンプト・応答をログとして保存する場合、保存期間・アクセス権限・削除ポリシーを定める
- モデルプロバイダの学習利用: API に送信したデータをプロバイダのモデル学習に使われない設定になっているかを明記する
プロンプトインジェクションは OWASP Top 10 for LLM Applications 2025 でも 2 年連続で最も重大な脆弱性の 1 つ（LLM01）に位置付けられており、要件段階での対策合意は必須です。RAG や後段のフィルタだけでは完全には防げないため、権限最小化・入出力フィルタ・重要操作への人間承認を組み合わせる方針を要件書で先に決めておきます。
より AI 開発全般で通常のシステム開発とどう違うか（精度・学習データ・ハルシネーションの 3 観点）を発注担当者向けに整理した記事としてAI開発で失敗しない要件定義の書き方も併せて参考にできます。
見落としがちな「運用要件」欄に追記する3項目
機能要件と非機能要件を書き終えて安心しがちですが、運用要件章にも AI 特有の追記項目があります。ここを埋めておかないと、リリース後に「想定外のトラブル」が続発します。
ハルシネーション時のフォールバック挙動を要件化する
LLM は事実と異なる出力（ハルシネーション）を生成することがあります。「起こさない」を目標にするのは非現実的なので、「起きた時にどう振る舞うか」を要件化します。
- 検出方法: 事実確認可能な項目（数値・固有名詞・日付）については後段でルールベースの検証を挟むかどうか
- フォールバック挙動: 検出時にユーザーへ「分かりません」と返すか、有人対応にエスカレーションするか、警告付きで結果を提示するか
- 免責文言: AI 回答である旨・利用時の注意点をユーザーに提示するか
- 報告と改善のループ: ユーザーから「誤り」の指摘を受けた際、誰がトリアージし、どの頻度でプロンプト/評価データセットに反映するか
「AI がミスすること」を前提とした運用設計が入っていない要件定義書は、リリース後に必ず火を噴きます。要件段階で「ミスは前提、その時どうするか」を書き切っておきます。
モデル差し替え・バージョン更新のルールを明記する
商用 LLM API は数ヶ月〜1 年程度でモデルバージョンが更新され、旧バージョンが廃止されることもあります。要件書に以下を含めます。
- バージョン固定の方針: 常に最新版を使うか、特定バージョンを固定するか（後者は精度の再現性が高いが、廃止時の移行工数が発生）
- バージョン更新時の評価再実施: モデルバージョンが変わったら、後述する評価データセットで自動再評価する仕組みを実装するかどうか
- モデル廃止時の対応: プロバイダから廃止通知を受けた際の移行スケジュール・予算の考え方
- マルチプロバイダ運用: 特定プロバイダに依存せず、抽象化層を挟んで別プロバイダに切り替えられる構成を要件化するか
これらは「今すぐ発生しない」ため要件段階で抜け落ちがちですが、記述しておくと発注後の追加見積・仕様変更を減らせます。
評価データセットとレビュー体制を要件化する
AI 機能の品質は「評価データセットで継続的に測定する」ことが前提です。要件書には以下を含めます。
- 初期評価データセットの構築責任者と件数: 発注側 or 開発側が用意するか、件数の目安（分類なら 100〜500 件、要約なら 30〜100 件が現場相場）
- 評価データセットの更新頻度: 新しいユースケースや失敗事例が出た際にデータセットに追加する頻度・担当者
- 評価の自動化範囲: 完全自動化する項目（正解ラベルと照合可能な指標）と、人手評価が必要な項目（自然文の妥当性・トーンなど）を分ける
- レビュー会体制: 月次または四半期で AI 精度レビュー会を開催するか、参加者は誰か
評価データセットとレビュー体制がない状態で AI 機能をリリースすると、「精度が下がっているかどうか」すら分からなくなります。要件段階で運用体制まで含めて合意しておくことが、長期的な品質維持の鍵です。
そのまま使える追記シート・記載例
ここまでの内容を、既存テンプレートにコピーして使える形式に整理します。各章の追記例として、AI チャットボットを例にした記載サンプルを提示します。
機能要件章の追記例
以下は既存テンプレートの機能要件章末尾に追記する想定のサンプルです。
項目 | 記載例（AI チャットボット機能） |
|---|---|
想定入力パターン | 短文質問（20 字前後）/ 長文質問（200 字以上）/ 複数質問併記 / 誤字脱字あり / 記号のみ / 空入力 |
想定出力サンプル | 200〜400 字の要約回答＋関連 FAQ リンク 3 件（詳細サンプルは別紙） |
許容出力範囲 | 意味が保存されていれば表現の揺れは可 / 事実に基づく数値・日付は正確であること / 出典元が特定できない情報は「一次情報を確認してください」と返す |
禁止出力 | 顧客の氏名・電話番号・メールアドレスの復唱 / 医療・法律・投資に関する断定的助言 / 競合サービス名の言及 |
利用モデル候補 | GPT-4o 相当 / Claude Sonnet 相当 / 精度優先で選定、月額コスト上限内に収まる範囲で決定 |
提供形態 | マネージド API（Azure OpenAI もしくは Anthropic API） |
プロンプト管理 | プロダクトのソースコードと同じリポジトリで管理 / 変更時は PR レビュー必須 / 変更時に評価データセットで再評価 |
Human-in-the-Loop | フィードバック収集型（「役に立った/立たなかった」ボタンをユーザー画面に表示、事後監査は運用チームが週次で実施） |
RAG 対象データ | 社内 FAQ サイト（週次バッチ更新） / サービス利用規約 PDF（改訂時に手動更新） |
引用の明示 | 回答文末尾に参照元ページのタイトルと URL を最大 3 件表示 |
検索ヒットなし時 | 「関連する情報が見つかりませんでした」と返し、有人チャット窓口へのリンクを提示 |
非機能要件章の追記例
項目 | 記載例（AI チャットボット機能） |
|---|---|
ビジネス指標 | 一次回答時間を有人対応比 70% 短縮 / FAQ ページ経由の解決率を現状 30% → 50% に向上 |
AI 指標（目標） | 適合率（適切な回答が返る割合）85% 以上、関連 FAQ 提示のヒット率 70% 以上 |
AI 指標（許容下限） | 適合率 75% を下回った場合はリリース見送り、または縮退運用（有人窓口へのリダイレクト強化） |
測定方法 | 事前構築した評価データセット 200 件を用いて、月次で自動評価＋人手サンプリング検証 |
レイテンシ | 初回トークンまで 1.5 秒以内、最終応答まで 6 秒以内、ストリーミング応答必須 |
同時実行数 | ピーク時 50 セッション並行 |
コスト上限 | 月額 20 万円まで（本機能単体、モデル API 課金のみ） / 超過見込み時は日次アラート、超過時は縮退運用 |
セキュリティ | ユーザー入力に対するプロンプトインジェクション対策必須（システムプロンプトと入力の分離・入力バリデーション） / API 送信データはモデル学習に使用しない設定を必須 |
プライバシー | 顧客の個人情報（氏名・連絡先・契約 ID）を LLM API に送信しない（送信前にマスキング処理） |
ログ管理 | プロンプト・応答を 90 日間保存 / アクセスは運用チームリードのみ / ユーザー要請で個別削除可能 |
運用要件章の追記例
項目 | 記載例（AI チャットボット機能） |
|---|---|
ハルシネーション検出 | 数値・日付・固有名詞について、RAG 検索結果に含まれない値を出力した場合は警告フラグを立てる |
フォールバック挙動 | 警告フラグ立った回答は「情報の正確性を確認してください」の注記を付与、または有人窓口誘導 |
免責文言 | チャットウィンドウ上部に「AI が回答しています。重要な判断は公式情報でご確認ください」を常時表示 |
モデルバージョン方針 | 特定バージョンを固定 / 廃止通知を受けたら 3 ヶ月以内に移行 / 移行時は評価データセットで再検証 |
モデル差し替え | プロバイダ抽象化層を実装し、GPT / Claude を切替可能に |
評価データセット | 初期 200 件を発注側と開発側で協力構築 / 月次で 10〜30 件追加 |
レビュー会 | 月次 1 回（AI 精度・コスト・失敗事例のレビュー、参加者: PdM・開発リード・運用リード） |
障害時対応 | LLM API 障害時はチャット機能を停止し、「現在ご利用いただけません」表示＋有人窓口誘導 |
発注前に開発会社へ共有すべき5つの資料
要件定義書を渡す際、以下 5 点をセットで共有すると初回見積の精度が上がります。
- 要件定義書本体: 上記の追記を反映したもの
- 想定入力・想定出力のサンプル集: 実データに近い 30〜50 件（機密情報は伏せる）
- 初期評価データセット案: 100〜200 件程度の「入力・期待出力・NG 出力」の 3 列表
- コスト試算の前提: 想定 MAU・1 ユーザーあたり月間リクエスト数・上限予算
- 既存システムのアーキテクチャ図: AI 機能をどこに組み込むかを示す
これらは「要件定義書に書ききれない補足資料」の位置付けで、開発会社が要件書だけでは想像できない前提を補完します。
よくあるNGな書き方と改善例
ここまでのポイントを踏まえて、現場で頻出する 3 つの NG 記述と、書き直しの型を示します。自分の書いた要件書が該当していないか、Before/After 形式でご確認ください。
NG1「精度99%以上」と書いてしまう
Before: 「AI チャットボットの精度は 99% 以上とする」
After:
- ビジネス指標: 一次回答時間を有人対応比 70% 短縮
- AI 指標（目標）: 適合率 85% 以上
- AI 指標（許容下限）: 75%（下回った場合は縮退運用）
- 測定方法: 評価データセット 200 件で月次自動評価＋人手サンプリング
数字を書くのではなく「何を、どう測って、達成/未達をどう判断するか」まで書くと開発会社が達成可能性を判断できます。特に「精度」の分子・分母が両者で違うことが齟齬の最大要因なので、測定方法の明記が重要です。
NG2 モデル指定なしで発注する
Before: 「LLM を使用したチャットボット機能を実装する」
After:
- 利用モデル候補: GPT-4o 相当 / Claude Sonnet 相当
- 提供形態: マネージド API（Azure OpenAI もしくは Anthropic API）
- 選定基準の優先順位: 1. 精度 → 2. データ主権 → 3. コスト → 4. レイテンシ
- 切替可能性: プロバイダ抽象化層を実装（将来的な差し替えを想定）
モデル名を 1 社に絞る必要はありませんが、候補群と選定基準までは要件化します。「候補 A/B から選定基準に照らして開発会社が推薦」と書けば、開発会社の技術判断も活かせます。
NG3 プロンプトを別ドキュメントで管理する
Before: 「プロンプトは Notion で管理し、運用中に随時修正する」
After:
- プロンプトはプロダクトのソースコードと同じリポジトリでバージョン管理
- 変更時は PR レビュー必須（承認者: 開発リード）
- 変更時は評価データセット 200 件で再評価を実施し、結果を PR に添付
- 評価で許容下限を下回った変更はマージ不可
プロンプトを Notion や別 SaaS で管理すると、コード変更と評価テストの紐付けが失われます。運用開始後にプロンプトを直したら精度が下がった、といった事故を防ぐには、コード資産として扱う方針を要件段階で合意することが重要です。
まとめと次のアクション
AI 機能を 1 つプロダクトに組み込む際、既存の要件定義書テンプレートに追記すべき項目を以下の 5 観点で整理してきました。
- 機能要件: 想定入出力・許容出力範囲・モデル選定基準・プロンプト管理・Human-in-the-Loop・RAG 設計
- 非機能要件: 精度目標（ビジネス指標＋許容下限＋測定方法）・レイテンシ・コスト上限・セキュリティ
- プロンプト設計: コード資産としての管理・変更承認フロー・変更時の評価再実施
- モデル選定: 候補群・選定基準の優先順位・バージョン方針・切替可能性
- フォールバック: ハルシネーション検出と代替挙動・評価データセットとレビュー体制
これらを既存テンプレートに追記した要件書と、想定入出力サンプル・初期評価データセット案・コスト試算前提・既存アーキテクチャ図をセットで開発会社に共有すれば、見積・技術検討フェーズに進める状態になります。
もし本記事を読んだ結果「これは 1 機能追加ではなく AI プロジェクト全体として検討すべき」と感じた場合は、AIプロジェクトの要件定義ガイドで全体像を、AI開発で失敗しない要件定義の書き方で AI 開発全般の要件定義の勘所を確認してから、改めて上流工程を組み直すことをおすすめします。
関連情報
AI 機能の要件整理を発注に向けてさらに具体化したい方は、お役立ち資料から発注前の要件整理・比較検討に活用できる資料をご覧いただけます。要件定義段階から個別のご相談がある場合は、お問い合わせフォームからもご連絡いただけます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 既存の要件定義書テンプレートを丸ごとAI専用に作り直す必要はありますか？
作り直す必要はありません。機能要件・非機能要件・運用要件の各章に、AI特有の項目（学習データの範囲・精度目標・ハルシネーション対応など）を追記する形で対応でき、既存の入力・出力・画面仕様の記述もそのまま活かせます。
- 「精度99%以上」のように目標値だけ発注先に伝えれば十分ですか？
不十分です。目標値・許容下限値・測定方法の3点セットで書かないと「何をもって正解とするか」の合意が取れず、発注先とのAI精度の解釈がずれたまま開発が進み、納品後に想定と異なる誤判定が頻発しても契約上の是正を求めにくくなります。
- モデルやAPIの種類まで発注前に決めておく必要がありますか？
モデル名を1社に固定する必要はありません。ただし候補群と選定基準の優先順位（精度・コスト・データ主権・レイテンシのどれを重視するか）までは要件段階で決めておくと、開発会社ごとの提案のばらつきを防げます。
- プロンプトはNotionなど別ドキュメントで管理してはいけませんか？
避けるべきです。別ドキュメントで管理すると変更履歴が追跡できず、誰が何を変更して精度が劣化したのか原因を特定できなくなるため、ソースコードと同じリポジトリでバージョン管理し、コード変更と同等にレビュー・再評価を要件化することをおすすめします。
- ハルシネーション（AIの誤り）は要件定義書でどう扱えばいいですか？
「起こさない」ことを目標にするのではなく、「起きた時にどう振る舞うか」（検出方法・フォールバック挙動・免責文言）を要件化します。例えば信頼度が閾値を下回る場合は自動回答を保留し人による確認に回すといった具体的な振る舞いまで、誤りの発生を前提に先に合意しておくことが重要です。
