システム要件定義書の書き方 記載項目・作成手順・サンプル構成と失敗しないポイントを解説

「システム開発を外注したいが、要件定義書に何を書けばよいかわからない」「要件定義が曖昧なまま開発が進み、完成後に認識のずれが発覚した」といった悩みは、システム開発を発注する企業の担当者に共通するものです。要件定義書は、開発の成否を大きく左右する文書でありながら、書き方を体系的に学ぶ機会は多くありません。

この記事では、システム要件定義書の役割、記載すべき項目、作成手順、サンプル構成、書くときのポイント、AI開発ならではの注意点までを、公的機関のガイドも参照しながら整理しました。まずは、この記事の要点を表で確認してください。

確認したいポイント	結論	詳細
システム要件定義書とは？	開発の前提を関係者で合意する文書	システムで実現する機能・性能・範囲・体制を明文化し、設計以降の基準となる。発注側が主体で作成する
何を記載すればよい？	目的・範囲・機能・非機能・体制が柱	背景と目的、現状と課題、スコープ、機能要件、非機能要件、構成、画面・データ、移行・運用、体制・予算、制約
作成の手順は？	目的→現状分析→要求整理→文書化→合意	業務部門へのヒアリングで要求を集め、優先順位を付けて具体化し、レビューで関係者の合意を得る
失敗しないポイントは？	曖昧さを排し優先順位と変更ルールを決める	数値で書く、対象外を明記、要件にIDと優先度を付け、変更管理の手順を事前に合意しておく

この記事でわかること

• システム要件定義書の役割と、要求定義書・RFP・基本設計書との違い
• 要件定義書に記載すべき10の項目と、それぞれに書く内容
• ヒアリングから合意形成までの作成手順
• 目次と機能要件・非機能要件のサンプル構成
• 曖昧さを排除するための書き方のポイントと、AI開発における要件定義の注意点

システム要件定義書とは

システム要件定義書とは、開発するシステムが「何を実現し、どのような条件を満たすべきか」を明文化した文書です。発注者と開発者が同じゴールを共有するための土台であり、設計・開発・テストといった後続の工程はすべてこの文書を基準に進みます。ここでは、要件定義書の役割、関連文書との違い、作成の主体、作らない場合に起こる問題を整理します。

要件定義書の役割

要件定義書には、大きく2つの役割があります。1つは、発注者と開発者の間で「作るもの」についての共通認識を作ることです。口頭やメールのやり取りだけでは認識のずれが生じやすく、完成後に「思っていたものと違う」という事態になりかねません。

もう1つは、後続工程の基準になることです。基本設計・詳細設計・テストは要件定義書に書かれた内容をもとに進められ、検収時にも「要件を満たしているか」が判断基準になります。要件定義書は契約の根拠であり、プロジェクト全体の判断の拠り所になる文書といえます。

要求定義書・RFP・基本設計書との違い

要件定義書と混同されやすい文書に、要求定義書、提案依頼書（RFP）、基本設計書があります。それぞれの位置づけは次のとおりです。

• 要求定義書：発注側が「こうしたい」という要望や業務上の課題を整理した文書。実現可能性は問わない
• 提案依頼書（RFP）：発注側が開発会社に提案を求める際に、要求や条件をまとめた文書。要件定義の前段階に位置する
• 要件定義書：要求をもとに、システムとして「何を実現するか」を実現可能な形で確定した文書
• 基本設計書：要件定義書をもとに、システムを「どのように実現するか」を設計した文書

つまり、要求は「やりたいこと」、要件は「やると決めたこと」、設計は「どう作るか」という関係です。要件定義書は、要望を取捨選択し、実現する範囲を確定させる文書である点を押さえておきましょう。

誰が作成するのか

独立行政法人情報処理推進機構（IPA）が公開している「ユーザのための要件定義ガイド 第2版」では、システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザー企業側にあるとされています。このガイドは、要件定義で発生しやすい48の問題と、その解決のための128の勘どころをまとめたもので、発注側の担当者にとって参考になる内容です。

（出典：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版」 https://www.ipa.go.jp/archive/publish/tn20191220.html）

実務では、開発会社がヒアリングを行い、要件定義書の作成を支援するケースが一般的です。ただし、業務の内容や解決したい課題を知っているのは発注側であり、最終的な決定権と責任も発注側にあります。開発会社に丸投げするのではなく、発注側が主体となり、開発会社の専門知識を借りて作り上げることが、質の高い要件定義書につながります。

要件定義書がないと起こる問題

要件定義書を作らずに、あるいは曖昧なまま開発を始めると、次のような問題が起こりやすくなります。

• 完成したシステムが業務に合わず、使われないまま終わる
• 開発の途中で追加要望が次々と発生し、費用と納期が膨らむ
• 「言った・言わない」の争いになり、発注者と開発会社の関係が悪化する
• テストや検収の基準がなく、品質を判断できない
• 運用開始後に想定外の負荷や障害が発生する

システム開発の失敗の多くは、実装よりも上流工程の不備に原因があるといわれています。要件定義に時間をかけることは、後工程の手戻りを防ぐための最も効果的な投資です。

システム要件定義書に記載する項目

要件定義書の様式はプロジェクトによって異なりますが、記載すべき項目はある程度共通しています。ここでは、一般的なシステム要件定義書に含める10の項目と、それぞれに書くべき内容を解説します。自社のプロジェクトに合わせて取捨選択してください。

1. プロジェクトの背景・目的・ゴール

なぜこのシステムを開発するのか、その背景と目的を最初に記載します。「受注処理に時間がかかっている」「顧客データが部門ごとに分散している」といった課題と、システム化によって達成したい状態を明確にします。

ゴールは「受注処理時間を1件あたり15分から5分に短縮する」「問い合わせ対応の一次回答率を80％以上にする」のように、できるだけ数値で測定できる形で書くことが重要です。目的が明確であれば、後の要件の取捨選択で迷ったときの判断基準になります。

2. 現状の業務と課題

システム化の対象となる現在の業務の流れ（As-Is）と、そこにある課題を整理します。業務フロー図や、担当者・使用ツール・所要時間・発生している問題点を記載します。

現状を正確に把握していないと、システム化によって何が変わるのかを説明できません。現場の担当者へのヒアリングをもとに、実際の業務の流れを具体的に記述することで、開発会社も業務を理解しやすくなります。

3. システム化の範囲（スコープ）と新しい業務フロー

どの業務をシステム化し、どの業務は対象外とするのかを明記します。あわせて、システム導入後の業務の流れ（To-Be）を業務フロー図などで示し、システムがどこで使われるのかをわかるようにします。

スコープが曖昧だと、開発中に「これも含まれると思っていた」という認識のずれが生じます。対象外とする業務も明示的に書くことが、追加要望による費用と納期の膨張を防ぐポイントです。

4. 機能要件

システムが備えるべき機能を、業務単位や画面単位で整理して記載します。「受注登録機能」「在庫照会機能」「帳票出力機能」といった単位で、それぞれの機能が何を入力として受け取り、どのような処理を行い、何を出力するかを記述します。

すべての機能を同じ優先度で書くと、予算や期間が足りない場合に何を削るか判断できません。各機能に「必須」「重要」「あれば望ましい」などの優先度を付けることで、開発の段階分けや費用調整がしやすくなります。

5. 非機能要件

非機能要件とは、機能そのもの以外にシステムが満たすべき品質や条件のことです。見落とされやすい項目ですが、運用開始後のトラブルの多くは非機能要件の不備に起因します。代表的な項目は次のとおりです。

• 性能・拡張性：同時利用者数、応答時間、処理件数、将来のデータ増加への対応
• 可用性：稼働時間帯、許容される停止時間、障害時の復旧目標
• セキュリティ：認証方式、アクセス権限、通信やデータの暗号化、ログの保存
• 運用・保守性：バックアップ、監視、障害対応の体制、メンテナンス時間
• 移行性：既存システムからのデータ移行の方法と期間
• ユーザビリティ：対応端末やブラウザ、操作性、アクセシビリティ

非機能要件は「速く」「安全に」といった表現では意味をなしません。「ピーク時に同時100ユーザーで画面表示3秒以内」のように数値で定義することが求められます。IPAが公開している「非機能要求グレード」を参考にすると、項目の抜け漏れを防ぎやすくなります。

6. システム構成・技術要件

システムの全体構成、利用するクラウドサービスやサーバー、データベース、開発言語、外部サービスとの連携方法などを記載します。既存システムとの接続がある場合は、そのインターフェースの仕様も明記します。

技術的な選定は開発会社の提案に委ねる部分もありますが、自社で指定すべき制約（既存環境との互換性、利用できるクラウド、セキュリティポリシー）は発注側が明示する必要があります。

7. 画面・帳票・データ要件

システムが提供する画面の一覧と各画面の概要、出力する帳票の一覧、扱うデータの項目と形式を記載します。画面遷移図やデータ項目の一覧表があると、開発会社との認識合わせが進みやすくなります。

データ要件では、項目名・型・桁数・必須かどうかに加えて、マスタデータの管理方法やコード体系の標準化についても触れておくと、設計段階での手戻りを減らせます。

8. 移行要件・運用要件

既存システムからのデータ移行の範囲と方法、移行期間中の並行運用の有無、切り替えのタイミングを記載します。あわせて、運用開始後の体制、問い合わせ窓口、障害時の連絡経路、定期メンテナンスの方針も定めておきます。

移行と運用は開発が終わってから考えがちですが、要件定義の段階で決めておかないと、稼働直前に体制が整わず稼働が遅れることがあります。「作って終わり」ではなく「使い続ける」前提で要件を定めることが大切です。

9. 体制・スケジュール・予算

発注側と開発側の役割分担、責任者、意思決定の方法、進捗報告の頻度を記載します。マイルストーンごとのスケジュールと、開発費用・運用費用の概算も明記します。

特に発注側の担当者がどれだけ時間を割けるかは、要件定義以降の進行を大きく左右します。発注側の関与の度合いと責任範囲を明文化しておくと、プロジェクトの停滞を防ぎやすくなります。

10. 前提条件・制約事項・用語定義

法規制や社内規程による制約、利用できる予算や期間の上限、依存する外部要因などの前提条件を記載します。また、業務用語やシステム用語の定義をまとめておくと、関係者間の解釈のずれを防げます。

同じ言葉でも部門によって意味が異なることは珍しくありません。用語集を用意し、文書内で一貫した言葉を使うことは、地味ですが認識のずれを減らす効果的な方法です。

【無料資料のご案内】 要件定義から開発・運用までを一貫して支援するサービスの内容や、要件定義の進め方をまとめた資料を無料でご用意しています。まずは概要を確認したい方は、以下から資料をご請求ください。 ▶ 資料請求はこちら（https://nextscale.co.jp/service-document/）

システム要件定義書の作成手順

要件定義書は、いきなり文書を書き始めるのではなく、目的の確認からヒアリング、整理、文書化、合意形成という手順を踏んで作成します。ここでは、発注側の担当者が押さえておきたい5つのステップを解説します。

ステップ1：目的とゴールを明確にする

最初に、経営層や事業責任者と「なぜシステムを作るのか」「何が達成できれば成功なのか」を確認します。この段階で目的が曖昧だと、後のヒアリングで要望が際限なく膨らみ、要件の取捨選択ができなくなります。

目的は、業務効率化・売上向上・コスト削減・顧客満足度向上など、経営上の課題と結び付けて定義します。判断に迷ったときに立ち返れる基準として、目的とゴールを文書の冒頭に置きましょう。

ステップ2：現状業務を分析し、関係者にヒアリングする

システム化の対象となる業務について、実際に作業している担当者にヒアリングを行い、業務の流れ・使用しているツール・困っていることを洗い出します。管理者と現場担当者では課題の見え方が異なるため、複数の立場から話を聞くことが重要です。

ヒアリングの結果は業務フロー図や課題一覧として整理します。「現在どうなっているか」を正確に把握してから「どう変えるか」を考えることが、実態に合わない要件を防ぐ基本です。

ステップ3：要求を整理し、優先順位を付ける

集めた要望をすべて要件にすると、予算と期間を超えてしまいます。目的への貢献度、業務への影響、実現の難易度、費用などを基準に、要望を「必須」「重要」「あれば望ましい」「今回は対象外」に分類します。

優先順位付けの際は、要望を出した部門との調整が必要になります。目的とゴールに照らして判断し、対象外とした理由も記録しておくことで、後から「なぜ入っていないのか」という議論を避けられます。

ステップ4：要件を具体化し、文書にまとめる

優先順位を付けた要求を、システムとして実現可能な要件に落とし込みます。機能ごとに入力・処理・出力を定義し、非機能要件は数値で表現します。この段階で開発会社の技術的な知見を借り、実現方法や概算費用の妥当性を確認します。

文書化の際は、前章で紹介した項目に沿って構成すると抜け漏れを防げます。技術者でない関係者が読んでも理解できる表現を心がけ、図や表を活用してわかりやすくまとめましょう。

ステップ5：レビューと合意形成を行う

作成した要件定義書を、経営層・業務部門・情報システム部門・開発会社のそれぞれにレビューしてもらい、指摘を反映します。特に業務部門には「この内容で業務が回るか」という観点で確認してもらいます。

すべての関係者の合意を得たうえで、要件定義書を確定版として承認し、以降の変更は変更管理の手続きに従うことを取り決めます。承認された要件定義書が、以降の設計・開発・検収の基準になることを全員で確認しておきましょう。

システム要件定義書のサンプル構成

ここでは、実際に要件定義書を作成する際の参考として、目次の例と、機能要件・非機能要件の記述例を紹介します。プロジェクトの規模や内容に合わせて、必要な章を追加・削除して活用してください。

目次の例

一般的なシステム要件定義書の目次構成は次のとおりです。

• 1. はじめに（文書の目的、対象読者、用語定義）
• 2. プロジェクト概要（背景、目的、ゴール、体制、スケジュール）
• 3. 現状の業務と課題（業務フロー、課題一覧）
• 4. システム化の範囲（対象業務、対象外業務、新業務フロー）
• 5. 機能要件（機能一覧、機能ごとの詳細、優先度）
• 6. 非機能要件（性能、可用性、セキュリティ、運用・保守、移行）
• 7. システム構成・技術要件（構成図、外部連携、制約）
• 8. 画面・帳票・データ要件（画面一覧、帳票一覧、データ項目）
• 9. 移行・運用要件（移行計画、運用体制、保守方針）
• 10. 前提条件・制約事項、変更管理のルール

小規模なプロジェクトであれば数ページから十数ページ、基幹システムの刷新などでは数十ページから百ページを超えることもあります。分量よりも、必要な判断がすべて書かれているかを重視しましょう。

機能要件の記述例

機能要件は、一覧表と個別の詳細説明を組み合わせて記述すると管理しやすくなります。一覧表の例は次のとおりです。

• 要件ID：F-001
• 機能名：受注登録
• 概要：営業担当者が顧客からの注文内容を登録する
• 入力：顧客ID、商品コード、数量、納品希望日
• 処理：在庫を確認し、在庫不足の場合は警告を表示。登録後に受注番号を採番する
• 出力：受注番号、登録完了通知（メール）
• 優先度：必須
• 備考：既存の顧客マスタと連携する

要件IDを付けておくと、設計書やテスト仕様書との対応関係を追跡でき、変更が発生した際の影響範囲も把握しやすくなります。1つの要件に1つのIDを付け、粒度を揃えることが運用のコツです。

非機能要件の記述例

非機能要件は、項目・要求水準・測定方法をセットで記述します。例を挙げると次のようになります。

• 性能：通常時の画面応答時間は2秒以内、ピーク時（同時接続100ユーザー）でも3秒以内
• 可用性：稼働時間は平日7時〜22時、計画停止は月1回・深夜帯4時間以内、年間稼働率99.5％以上
• セキュリティ：IDとパスワードに加えて多要素認証を必須とする。操作ログを1年間保存する
• バックアップ：データベースを毎日1回フルバックアップし、30日分を保持する
• 拡張性：3年後のデータ量（現在の2倍）でも性能要件を満たすこと

IPAの「非機能要求グレード」では、これらの項目をシステムの重要度に応じたレベルで整理しており、自社のシステムに求める水準を決める際の参考になります。要求水準を数値化し、どう測定するかまで決めておくと、検収時の判断が明確になります。

【無料相談のご案内】 「自社のプロジェクトで要件定義書に何を書くべきか」「要件定義からAI開発まで相談したい」といった具体的なご相談は、無料の相談予約からお気軽にお問い合わせください。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

要件定義書を書くときのポイント

要件定義書は、項目を埋めれば完成するものではありません。読み手が正しく理解し、後工程で迷わずに使える文書にするためには、書き方にも配慮が必要です。ここでは、質の高い要件定義書に共通する5つのポイントを解説します。

曖昧な表現を避け、数値と具体例で書く

「使いやすい画面」「高速な処理」「十分なセキュリティ」といった表現は、読む人によって解釈が異なります。「3クリック以内で登録を完了できる」「1,000件の検索を2秒以内に表示する」のように、数値や具体的な条件で書きましょう。

数値化が難しい要件は、具体例や参考となる既存システムを示すことで解釈の幅を狭められます。第三者が読んで同じ理解に至るかを基準に、表現を見直すことが大切です。

読み手を意識した構成にする

要件定義書は、経営層・業務部門・情報システム部門・開発会社という、知識も関心も異なる複数の読み手が使います。専門用語には説明を添え、全体像から詳細へと進む構成にすると、どの立場の読み手も理解しやすくなります。

経営層には目的とゴール、業務部門には業務フローと機能、開発会社には機能・非機能・技術要件が主な関心事です。誰が、どの章を、何のために読むのかを意識して構成しましょう。

対象外の範囲も明記する

実現する範囲だけでなく、「今回は対象外とする業務・機能」も明記します。対象外の記載がないと、発注側は「当然含まれる」と考え、開発側は「言われていない」と考える、という認識のずれが起こります。

対象外とした理由や、将来のフェーズで検討する予定があるかも書いておくと、関係者の納得を得やすくなります。「やらないこと」を決めることが、「やること」を守ることにつながります。

要件にIDと優先度を付けて管理する

すべての要件に固有のIDを付け、優先度を明示します。IDがあれば、設計書やテスト項目との対応付け、変更時の影響範囲の特定、進捗の管理が容易になります。

優先度があれば、予算や期間の制約が生じた際に、何を残し何を後回しにするかを迅速に判断できます。要件を「管理できる単位」に分解することが、プロジェクトの柔軟性を高めます。

変更管理のルールを決めておく

要件定義書を確定した後も、業務環境の変化や検討の深まりによって変更が必要になることはあります。重要なのは変更を禁じることではなく、変更の申請・影響評価・承認・反映の手順をあらかじめ決めておくことです。

変更が費用や納期に与える影響を評価し、発注側の責任者が承認してから反映する流れにしておけば、無秩序な追加要望による混乱を防げます。変更の履歴を残し、常に最新版がどれかを明確にする運用も欠かせません。

AI開発における要件定義の注意点

AIを組み込んだシステムの開発では、従来のシステム開発とは異なる要件定義の考え方が必要です。AIは「決められたとおりに動く」ものではなく、データから学習して確率的に判断するため、要件の定め方を誤ると「精度が出ない」「使えない」という結果になりがちです。ここでは、AI開発で特に注意したい4つのポイントを解説します。

精度の目標と評価指標を要件にする

従来のシステムでは「入力Aに対して出力Bを返す」と明確に定義できますが、AIは常に正解を返すわけではありません。そのため、「正解率90％以上」「誤検知率5％以下」のように、求める精度の水準と、その測定方法を要件として定義する必要があります。

また、100％の精度は現実的ではないため、AIが誤った場合に人がどう確認・修正するかという業務上の対応も要件に含めます。精度の目標は業務上の許容範囲から逆算し、開発会社と実現可能性を確認しながら設定しましょう。

学習データの要件を定義する

AIの性能は学習データの量と質で決まります。どのようなデータをどれだけ用意できるか、データにラベル付け（アノテーション）が必要か、誰がどのように行うかを要件定義の段階で明確にします。

データが不足している、品質にばらつきがある、権利や個人情報の問題で使えないといった問題は、開発が始まってから発覚すると大きな手戻りになります。データの入手可能性と品質の確認を、要件定義の一部として組み込むことが重要です。

PoCを前提に段階的に要件を固める

AI開発では、実際にデータを使って試作しなければ、目標の精度が達成できるかどうかわかりません。そのため、最初にすべての要件を確定させるのではなく、PoC（概念実証）で実現可能性を検証してから本開発の要件を固める進め方が一般的です。

要件定義書には、PoCの目的・検証項目・成功基準・期間を記載し、その結果に応じて本開発の要件を見直す前提を明記しておきます。「検証してから決める」部分と「最初から決める」部分を分けて書くことが、AI開発の要件定義のコツです。

AI開発の費用や進め方、開発会社の選び方については、AI受託開発の費用相場と開発会社の選び方の記事で詳しく解説しています。

運用・再学習・監視の要件を含める

AIは運用開始後に、データの傾向の変化によって精度が低下することがあります。精度をどのように監視するか、どのタイミングで再学習するか、再学習のためのデータをどう蓄積するかといった運用要件を、要件定義の段階で定めておきます。

また、AIの判断根拠の説明が必要かどうか、法規制やガイドラインへの対応が必要かどうかも確認します。AIは「作って終わり」ではなく「育て続ける」前提で要件を定義することで、運用開始後の混乱を防げます。

要件定義でよくある失敗と対策

要件定義の失敗パターンは、多くのプロジェクトで繰り返し見られます。ここでは代表的な4つの失敗と、その対策を整理します。自社のプロジェクトで同じ状況になっていないか、確認しながら読み進めてください。

要件の抜け漏れが後から発覚する

業務の一部がヒアリングから漏れていた、例外的なケースの処理が定義されていなかった、といった抜け漏れは、テストや運用開始後に発覚すると大きな手戻りになります。

対策としては、業務フローをもとに機能を洗い出す、非機能要件のチェックリストを使う、複数の立場の担当者にレビューしてもらう、といった方法があります。「通常の流れ」だけでなく「例外時の流れ」も確認することが、抜け漏れを減らすポイントです。

要求が膨らみ、予算と期間を超える

ヒアリングで出た要望をすべて盛り込んだ結果、当初の予算と期間で収まらなくなるケースは非常に多く見られます。関係者の要望を断りにくいという事情も背景にあります。

対策は、目的とゴールを基準に優先順位を付け、必須要件とそれ以外を明確に分けることです。第1フェーズで実現する範囲を絞り、残りは次のフェーズで検討するという段階的な進め方が、予算と期間を守りつつ関係者の納得も得やすい方法です。

関係者の合意が取れていないまま進む

情報システム部門と開発会社だけで要件を固め、業務部門や経営層の確認を経ずに開発が進むと、完成後に「業務に合わない」「投資対効果が説明できない」といった問題が起こります。

対策は、要件定義書の承認プロセスに業務部門と経営層を組み込むことです。要件定義書を関係者全員が確認し、承認した記録を残すことで、後からの認識のずれを防ぎ、責任の所在も明確になります。

開発会社に任せきりにする

「専門家に任せれば大丈夫」と要件定義を開発会社に丸投げすると、業務の実態と乖離した要件になったり、開発会社に都合のよい範囲で要件が決まったりする恐れがあります。

要件を決める責任は発注側にあります。発注側の担当者が業務を説明し、開発会社の提案を理解したうえで判断する体制を作りましょう。発注側の主体性と開発会社の専門性を組み合わせることが、質の高い要件定義の前提です。社内に知見が不足している場合は、要件定義の段階から伴走してくれる会社を選ぶのも一つの方法です。

システム開発やAI活用の進め方については、NextScaleのコラム一覧でも関連記事を公開しています。

【無料相談のご案内】 要件定義の進め方に不安がある方、AIを組み込んだシステム開発を検討している方は、以下から無料の相談予約をご利用ください。自社の課題整理から要件定義、開発・運用までを一貫してご支援します。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

まとめ

システム要件定義書は、開発するシステムが「何を実現し、どのような条件を満たすべきか」を明文化し、発注者と開発者の共通認識を作る文書です。設計・開発・テスト・検収のすべてがこの文書を基準に進むため、開発の成否を左右する重要な工程といえます。

記載する項目は、目的とゴール、現状と課題、スコープ、機能要件、非機能要件、システム構成、画面・データ要件、移行・運用要件、体制・予算、前提条件と制約が柱になります。曖昧な表現を避けて数値で書く、対象外を明記する、要件にIDと優先度を付ける、変更管理のルールを決めることが、質の高い要件定義書に共通するポイントです。

AI開発では、精度目標・学習データ・PoC・運用と再学習の要件を加える必要があります。要件定義は発注側が主体となる工程ですが、社内の知見だけで進めることが難しい場合は、要件定義から伴走してくれる開発会社に早い段階で相談し、実現可能な要件を一緒に固めていくことをおすすめします。