株式会社リソース・シェアリング スポンサードサーチ
生成AIの業務活用が定着してから2年以上。ChatGPTやClaude Codeなど、複数のAIツールが競合する中で、「要件定義書をAIに作らせる」という取り組みは、特にDX推進担当者や中小企業の経営者の間で標準的な手法になりました。
実際、2024年のAI出力と比べると、2026年のAI生成要件定義書は格段に改善されています。機能一覧の網羅性、非機能要件の項目化、権限管理表、業務フローの可視化など、AIが出力する要件定義の「構造と形式」は、もはやプロフェッショナルレベルに達しています。
しかし、同時に新しい課題が出現しています。
「構造は整っているのに、なぜか開発が進まない」「数値基準が決まらず、性能要件で揉める」「初期リリースのスコープが肥大化し続ける」——こうした課題を、弊社が支援した案件で複数目撃しています。
実は、AIが出力した要件定義には、今なお致命的な「抜けパターン」があります。それを知らないまま進めると、開発後半で判断ミスが発生し、かえってコストと時間を失う結果になります。
この記事では、実際にAIに要件定義を作らせた例を示し、「AIが解決できるようになった部分」と「依然として人間が判断すべき部分」を具体的に解説します。
AIが改善したこと・依然として課題なこと
実際のAI出力例（2026年）
弊社が実際に試してみたところ、ChatGPT に同じプロンプトを投げると、以下のような出力が得られました。
受注管理Webシステム 要件定義書
- 背景・目的
現在、受注情報をExcelで管理しているが、受注数の増加に伴い、入力ミス、更新漏れ、ファイル共有の煩雑化が発生している。- 対象範囲
- 対象業務：受注登録、受注確認、ステータス管理、顧客管理、商品管理、CSV出入力
- 対象外：高度な在庫引当処理、会計システムへの自動連携、配送会社APIとの連携
- 利用者・権限利用者区分主な利用内容管理者ユーザー管理、マスタ管理、全受注データの閲覧・編集受注担当者受注登録、受注編集出荷担当者出荷対象確認、ステータス更新経理担当者売上確認、CSV出力閲覧者受注情報の閲覧のみ
- 業務フロー
現行フロー（AS-IS）：顧客→Excel入力→確認→出荷・請求への手作業転記
新フロー（TO-BE）：顧客→Web入力→全員がリアルタイム確認→自動集計
AIが改善した部分
2024年との比較で、以下は大幅に改善されました。
- スコープの明確化 — 「対象業務」「対象外業務」が区分けされている
- ステークホルダーの特定 — 5つの利用者区分と権限マトリクスが記載されている
- 業務フローの可視化 — AS-IS（現行）と TO-BE（新システム後）が分離されている
- 非機能要件の項目化 — 性能、セキュリティ、可用性が体系的に記述されている
これらは、2024年時点のAI出力では、ほぼ全て欠けていた要素です。
依然として残る課題
しかし、出力を詳細に見ると、3つの致命的な「抜けパターン」が存在します。
AIが出力した要件定義に依然として残る3つの課題
2026年のAI出力は、ステークホルダー特定も対象外業務の明記も、業務フロー可視化も、実現しています。では何が足りないのか。
課題1 ビジネスインパクト（数値）がない。判断基準がない
AI出力の要件定義書に「背景・目的」セクションはあります。しかし、経営判断に必要な根拠がありません。
例えば、以下の問いに答えていません。
- 現在、Excelで管理することによる具体的なコストは？
例：「月平均150件の受注のうち、平均3件のミスが発生し、修正に1件あたり30分かかっている → 月額75時間 × 時給2,000円 = 月額15万円の損失」 - 本システム導入により何が改善するのか、数値で？
例：「ミス件数を50%削減 → 月額7.5万円のコスト削減」「受注確認時間を現在の6時間から2時間に短縮 → 年間1,040時間削減」 - それは経営上、いかほどのインパクトか？
例：「年間90万円のコスト削減、営業担当者が月間4時間解放される」
なぜこれが重要なのでしょうか？
AI出力には「受注情報の一元管理」「効率化」という抽象語がありますが、「では今、具体的にいくら損失しているのか」が不明です。そのため、開発会社との予算交渉、経営層への投資決済、優先度判定のすべてが曖昧になります。
課題2 数値基準の根拠がなく、なぜその値か説明できない
AI出力の非機能要件には「性能：一覧表示は3秒以内」「稼働率：99%」「同時接続数：10〜30名」と記載されています。
しかし、なぜその値か根拠がありません。
例えば「同時利用者10〜30名」という想定については。
- 現在のExcel利用者は何名か？
- 今後の成長見通しは？
- 全員が同時にアクセスするシナリオはあるか？
これらが不明であれば、開発会社は「一般的な想定」で実装しますし、本番稼働後に「想定以上の同時接続が発生して性能が低下」というトラブルが起きる可能性があります。
なぜこれが重要なのでしょうか？
非機能要件の数値は、ビジネスリスクに基づいて定義すべきです。「3秒を超えると、ユーザーが操作を待ちきれず、重複入力が発生する」「99%の稼働率では、月に約7時間止まることになり、顧客への納期遅延で信用喪失のリスク」——こうした根拠が非機能要件として出てきていないのです。
課題3 「要求定義」が欠けている。そもそも何のためにシステムを作るのか不明
これは、実は最も重大な欠落です。
AI出力の要件定義書には「背景・目的」というセクションはありますが、経営判断に必要な要求定義がありません。
「要求定義」と「要件定義」の違いを理解していますか？
- 要求定義：「何のために、何を解決するために、このシステムを作るのか」という経営層の判断基準。
- 要件定義：「その目的を達成するために、どんな機能・非機能・スコープで実装するか」という技術的な仕様。
AIが出力するのは「要件定義」（機能一覧、スコープ、非機能要件）です。しかし、要求定義（なぜそれが必要なのか、実装のビジネスインパクトは何か）は、AIには定義できません。
例えば、以下のようなケースを想定してみます。
- 「Excelで管理することで、月額いくらの損失が出ているのか」
→ AI出力：「受注数の増加に伴い、課題が発生している」（具体的ではない）
→ 必要な要求定義：「月平均150件の受注のうち、3件のミス、1件あたり30分の修正 = 月額15万円の損失」 - 「本システム導入で何が改善するのか」
→ AI出力：「受注情報を一元管理する」（抽象的）
→ 必要な要求定義：「ミス件数を50%削減して月額7.5万円のコスト削減」「営業担当者が月間4時間解放される」
要求定義なしで開発を進めると、以下のような重大な齟齬が起きていしまいます。
- スコープ決定の根拠がない → 「あの機能も欲しい」と言われたとき、判断できない
- 予算交渉ができない → なぜこの金額が必要なのか説明できない
- 優先度がつけられない → 複数の機能候補があるとき、どれを優先すべきか決められない
- 成功の定義がない → 実装後に「果たして成功したのか」を判定できない
弊社が支援した案件の中には、クライアント企業が要求定義を十分に行わないまま開発を進めてプロジェクトが炎上して、弊社にご相談があるケースがあります。
現場感覚として、炎上案件のほぼ100％が要求定義が曖昧なままプロジェクトが進んだ事が原因としてあげられます。これはAIを使った要件定義を行う前に、要求定義をしっかりやっておく事が重要なのです。
人間にしかできない判断はどこにあるのか
「ではAI出力の要件定義は使えないのか」というと、そうではありません。ただし、AI出力を有効に活用するには、人間が判断しなければならない部分が4つあります。
弊社が支援する案件で実感しているのは、この「人間の判断が入る」フェーズこそが、プロジェクト成否を左右するということです。
経営層・業務部門・IT部門の三者が、自分たちの経験と知識を持ち寄り、協議と合意を積み上げる——その過程がなければ、AIが出力した「キレイな要件定義書」は、単なる「絵に描いた餅」になります。
弊社のアプローチは、以下の2段階です。
- 要求定義フェーズ：「なぜこのシステムが必要か」をビジネスレベルで言語化する（人間の経営判断が必須）
- 要件定義フェーズ：その要求定義を実現するために、AIが出力した要件定義を補完する（人間の現場知識が必須）
ステップ1：要求定義を定義する（これはAIにはできない）
ここが、人間にしかできない最初の判断です。
経営層・業務部門・IT部門の三者が、自分たちの経験に基づいて、以下を明確にします。
1. 現状の具体的なコスト・課題を数値化
- 「Excelで管理することで、月々いくら損失しているのか」
- 「時間・工数・ミス・機会損失など、定量化できる指標を全て抽出」
例：
月間受注件数：150件
ミス率：2%（3件/月）
修正時間：1件30分 = 月75時間
時給2,000円 = 月額15万円の損失
年間：180万円の損失2. 本システム導入による改善の目的を定義
- 「ミス率を何%削減するか」
- 「作業時間を何時間短縮するか」
- 「それにより年間いくら削減できるか」3.
3. 実現するゴールを明確に、投資対効果（ROI）を計算
- システム開発費用：300万円
- 年間削減効果：180万円
- 回収期間：2年
- 「この投資判断は妥当か」を経営層が判定
ステップ2：要求定義に基づいて、要件定義を補完する
要求定義が定まれば、以下のアプローチでAIで作成する要件定義を人間が補完します。
アプローチ1 「なぜ」の問いを5段階深める（人間の実務経験が活きる）
AI出力した「背景・目的」は、あくまで一般的な説明です。それに対して、経営層・業務部門が自分たちの実務経験から、以下の問いを繰り返します。
- 「受注数が増えたため」→ 実際に、Excelのどの作業が最も困っているのか
- 「困っている」→ 具体的にどんな損失が出ているのか（工数・ミス件数・機会損失）
- 「損失がある」→ このシステムで解決した場合、1年後にどんな数字が変わるか
- 「数字が変わる」→ その変化を出すために、本当に必要な機能は何か
- 「必要な機能」→ それをフェーズ1でやる理由は？フェーズ2に回せないか
ここで重要なのは、経営層が現状の課題を具体的に実感することです。
その実感があってこそ、後の優先度判定や予算交渉が説得力を持ちますが、AIはこの「経営層の腹落ち」を作ることができません。
この「なぜの深掘り」によって本当に作るべきものが浮かび上がってきますので、AIが出力した機能一覧は、この問いを通過したものだけを残していきます。
アプローチ2 利害関係者ごとにヒアリングを行う（人間の現場経験が必須）
AIが出力する要件定義をたたき台として、実際に現場担当者とヒアリングを行います。ここで重要なのは「この要件定義を見て、どう思いますか？」という問いかけであり、現場を知っている人間にしかできない判断があります。
- 「この機能は実際に使いますか？」（AIが出力した機能の「本当の必要性」）
- 「現場ではどんな手順で受注を処理していますか？」（実務の流れはAIには見えない）
- 「Excelで困っている具体的な場面はどこですか？」（経営層の「困っている」と現場の「困っている」は違う）
このヒアリングによって、AIが出力した機能の中に「誰も使わないもの」「実態に合わないもの」が見つかりますし、逆に「AIが出力していないが絶対に必要なもの」も発見できます。この「ギャップの発見」こそが、人間の現場経験による知見や経験が必要となる部分であり、人間が関わらないといけない部分です。
アプローチ3 「やらないことリスト」を明示的に作る（人間の優先度判定が必須）
ここも、AIにはできない判断であり、要件定義の最終版には必ず「今回のスコープ外」を明記します。
【今回の対象外（フェーズ2以降で検討）】
- 仕入れ管理・発注管理機能
- 複数倉庫の在庫管理
- 会計ソフトとの自動連携
- スマートフォン専用アプリ
- ECサイトとのAPI連携「やらないこと」を決める——これは経営判断そのものです。
限られた予算・期間の中で「何を優先するか」を決めるのは、経営層・業務部門の責任です。AIが出力した機能一覧には「やるべきもの」と「やらないもの」の区分がありません。その判断を下すのは人間です。
このリストに、関係する全員の承認をもらいます。
後から「やっぱりあの機能も」と言われたとき、「これはフェーズ2で検討することに合意済みです」と返せる根拠になります。この「合意」を作ることが、プロジェクトの仕様が膨らんで炎上することを防ぐ最大の防壁です。
アプローチ4 現場の業務フローを「AS-IS」で書き起こす（人間の実務知識が最も重要）
AIから出力される機能一覧は、一般的な業務に必要な機能であり、その会社固有の業務の流れではありません。
この会社独自の業務プロセスを理解しているのは、実際に業務に携わる人間だけであり、現場の実態を反映させるには、現在の業務フロー（AS-IS）を図や手順書の形で書き起こすことが必要となります。
具体的には、担当者に「今日1日の受注業務を時系列で教えてください」と聞き、そのまま書き起こします。「Excelを開く→受注番号を手入力→担当者にメールで連絡→倉庫に電話して在庫確認→…」という手順が出てきたとき、「その電話確認はシステムでどう置き換えますか？」「このメール通知は自動化しますか？」という問いが、要件として必要な機能を具体化していきます。
弊社が支援したプロジェクトでは、この「AS-ISの聞き取り」の段階で、経営層が知らなかった業務が見つかることがあります。
例えば、受注管理システムの導入予定案件で、実は現場担当者が「単なるExcel入力」の他に「顧客の過去注文との照合」や「不良品の実績追跡」といった付加的な業務を行っていた——このような「公式な業務フロー図に載っていない業務」が、後々の要件漏れを招きます。この隠れた業務を引き出せるのは、現場を信頼して丁寧にヒアリングする人間の力です。
このAS-ISの整理によって、AI出力の機能一覧と「実際に業務で必要なもの」のギャップが可視化されます。AIが抽出した機能の中に「実際には使わない機能」が含まれること、逆に「AIが出力していないが絶対に必要な機能」が見つかることは、ほぼ必ず起きます。
アプローチ5 非機能要件に「数値の合意」を取る（人間のビジネス判断が最終決定権）
セキュリティ対応や稼働保証という言葉だけでは、開発会社と発注者で解釈が大きく異なります。要件定義の段階で、以下のような数値基準をすり合わせておくことが重要です。
- 稼働率：99%か99.9%か（年間の許容ダウンタイムは87.6時間か8.7時間か）
- 目標復旧時間（RTO: Recovery Time Objective）：障害発生から何時間以内に復旧するか
- 性能：何人の同時アクセスで、レスポンスタイムは何秒以内か
- バックアップ保存期間：何日分を何世代保持するか
- セキュリティ：二要素認証・IPアドレス制限は必要か
ここが、経営判断としての最終決定地点です。
これらの数値は、技術的に難しいかどうかではなく「業務上どのくらいの障害リスクを許容できるかというビジネス判断です。開発会社に決めてもらうのではなく、発注者側が「このシステムが1時間止まったとき、業務・売上にどんな影響があるか」を起点に定義する必要があります。
弊社が支援したプロジェクトでは、経営層が費用感の問題で24時間365日のシステム保守ではなく、平日営業時間内対応で十分だろうと考えていたケースがあります。しかし、そのことにより夜中にサーバの障害でサービスが停止し、その間の受注ができなかった、ということが発生しました。
これは、経営者自身が自社サービスの価値の源泉が「止まっても影響がでないサービス」と考えているか、「止まると問題が出るサービス」と考えるのかについて、理解ができていなかったから発生したものです。
また、この判断ができるのは、会社の事業特性を知っている経営層だけです。
数値が合意されていれば、開発会社は「最低限の対応」ではなく「合意した水準」での実装やサービス提供を行います。一方、この合意がなければ、開発後に「稼働率の不足」や「セキュリティ基準の相違」で紛争が生じてしまいます。
AIと人間の役割分担 人間にしかできない「腹を括った決断」
AIに要件定義を作らせることは、否定しませんし、今では業務効率化のために積極的に活用すべきです。
ただし、AIができるのはあくまでも「業務支援であり」ということを正しく理解しておく必要があります。AIが得意なことと、人間が担うべきことは、明確に分かれているのです。
AIが力を発揮する作業
- 機能の抜け漏れチェック（「このシステムに必要な一般的な機能は他にありますか？」）
- 非機能要件の項目出し（「受注管理システムで設定すべき非機能要件の観点を列挙してください」）
- 類似システムの調査（「同様のシステムを導入した企業の一般的な課題は何ですか？」）
- ヒアリング質問リストの生成（「ステークホルダーヒアリングで確認すべき質問を作ってください」）
このように、AIは「枠組み」「観点」「一般的なパターン」を生成するのに優れています。
人間が担うべき判断（AIには絶対にできない）
- このシステムの目的と「解決後の状態」を言語化すること
- 現状、いくら損失しているのか、経営層が実感すること
- どの機能を今回やる・やらないかの優先度決定
- 現場が本当に困っていることの把握（隠れた業務の発掘）
- 非機能要件の数値基準をビジネスリスクに基づいて設定すること
- 利害関係者間の調整と合意形成
一方、AIは計算ができますが、腹を括る決断はできません。
「月15万円の損失だから、300万円のシステム開発に投資する価値がある」と経営層が納得し、かつ関係者全員が「これで納得した」という状態を作る、これは人間にしかできません。
要件定義の本質は、関係者全員が同じ絵を描いている状態を作ることです。
この合意を作る過程こそが、プロジェクト成否の分岐点です。これは生成AIでは代替できません。AIで要件定義が速く簡単に作れるようになったからこそ、逆に人間にしかできない判断の重要性が浮き彫りになっています。
「人間の判断」がなければ、AIの出力は役に立たない
見てきたように、AIが出力する要件定義は、機能一覧のたたき台としては有効ですが、3つの致命的な欠落があります。
- ビジネスインパクト（数値）がない：なぜ今作るのか、実装で何が改善するのか、定量化されていない
- 数値基準の根拠がない：なぜ3秒か、なぜ99%か、ビジネスリスクとの紐づけがない
- 要求定義がない：そもそも「何のためにシステムが必要か」という経営判断の根拠が不明
特に第3点が重大です。
AIは「与えられた情報」を構造化することは得意です。しかし「何のために」という目的を定義することはできません。
「現状、何が問題となっているのか」「本システムで何が変わるのか」「その変化は経営上、いかほどの価値があるのか」——これらは、経営層と業務部門が、自分たちの経験と知識を持ち寄って初めて言語化できる判断です。
要求定義なしで要件定義を進めると、様々な問題が発生します。
- スコープ決定ができない → コスト増が止まらない
- 優先度がつけられない → 機能が肥大化する
- ROIが計算できない → 成功/失敗の判定ができない
このため、ITプロジェクトでは「要求定義 → 要件定義 → 実装」という順序は変わらないのです。
この不変の順序を忘れて、「AIが作った要件定義書があるから、もう十分」と判断する企業が増えています。しかし、それは大きな誤解です。AIが作った「キレイな要件定義書」よりも、経営層・業務部門・IT部門が協議して「何のためにシステムを作るのか」を言語化した数ページの要求定義の方が、100倍価値があります。
我々は「課題を言語化しゴールへの到達をバックアップする・というミッションのもと、以下を提供しています。
- 要求定義フェーズ：現状の損失を数値化し、投資効果を計算する伴走
- 要件定義フェーズ：AIが出力した仕様を、要求定義に基づいて補完・検証する
- 実装・運用フェーズ：要求定義に照らして、成功を測定する
この3段階を丁寧に行ったプロジェクトと、要求定義を省略したプロジェクトでは、開発後半のトラブル発生率に歴然とした差が出ます。
なお、「どんなシステムを作るか」が固まっている場合でも、CS-Cartが公式にリリースしているCS-Cart国際版のようなパッケージを活用する選択肢もあります。パッケージはすでに一定の非機能要件を満たした状態で提供されるため、「ゼロから要件を定義する」コストを大幅に削減できます。
「AIで要件定義を進めているが精度が不安」「IT導入を要件定義の段階から支援してほしい」という方は、お気軽にご相談ください。弊社では、要求定義・要件定義から構築・運用まで一貫した伴走型のサポートを提供しています。
経営者の負担を減らすために
2026年のAI技術は、本当に優れたものになりました。ただし、その優秀性が新たなリスクを生んでいることに、気づいている人は少ないようです。
AIが「要件定義書という立派な書類」を数分で出力するようになったため、経営層が「では開発会社に渡しましょう」と決断しやすくなりました。その書類には、機能一覧もスコープも権限も、見た目としては完備されています。
しかし、その要件定義書には「なぜそうするのか」という要求定義が欠けています。
この欠落は、開発が進むほど致命的になります。開発途中で「やはりこの機能も必要だ」という要望が出たときに、「では初期リリースでは何を優先するのか」という判断ができません。根拠がないからです。そして気づいた時には、プロジェクトは予算も期間も肥大化しています。
我々が見てきた失敗パターンは、例外なく「要求定義を共有しないまま、要件定義だけを詳細にした」案件です。
逆に成功しているプロジェクトは、要求定義フェーズで「現状の損失を数値化する」ことを徹底しています。それにより、経営層・業務部門・IT部門の三者が「同じ目標を見ている」状態になります。その状態から出発した要件定義は、後発的な判断がスムーズに進みます。
AIは今、「構造化」という最後の砦まで自動化しようとしています。その自動化を使うなら、むしろ最上流の「要求定義」こそ、人間が丁寧に、時間をかけて定義すべきです。
そこが曖昧なまま、AIが出力した「キレイな要件定義書」を握りしめて、開発に進むことほど危険なことはなく、最終的には経営者の負担が増えるだけなのです。
AI時代だからこそ、戦略は人と一緒に考えることが、最初の一歩です。
開発やコンテンツ生成はAIが担える時代になりました。しかし、何を作るか・どこを目指すかという問いに答えるのは、依然として人の仕事です。
DX推進や新規事業の立ち上げで壁にぶつかる企業の多くは、ソリューションの導入や社内人材への丸投げに終始し、課題の本質が言語化されないまま進んでしまっています。
経営とITの両方を理解した人間が、経営者と並走しながら要求定義・要件定義の段階から一緒に考える。AIはこのプロセスを補助できますが、主役にはなれません。
まだ課題が言語化できていない段階からでも、遠慮なくご相談ください。一緒に考えます。
AIが生成できないのは「実績と信頼」
ECサイトやマーケットプレイスサイトはCS-Cart国際版（公式）という選択肢
AIはコードを書けます。しかし、長年の実運用で磨かれたロジックや、世界中の事業者が検証したセキュリティを、プロンプト一つで再現することはできません。
CS-Cart国際版（公式）は、自社EC・越境EC・BtoB EC・マーケットプレイスに対応した豊富な実績ある機能をパッケージとして提供しています。
構築コストを抑えながら、堅牢なECサイトを立ち上げることができます。
スポンサードサーチ