要求定義と要件定義の違い：AI導入で何を作るかの決め方 〜AX推進入門 第4回〜

「経費精算をAIで楽にしたい」だけでは、何を作るかは決まらない

経理の部長から「経費精算をAIで楽にしたい」と相談されたら、推進担当は最初に何を決めればよいでしょうか。この一言のままベンダー（開発・導入を請け負う外部の会社）に相談したとします。すると、申請の入力を手伝うAIを提案するベンダーもあれば、領収書を読み取るAIを提案するベンダーもあります。自分でAIに作らせても、AIは言われたとおりに何かを作りますが、それが経理の困りごとを解くとは限りません。

この記事は、AX推進入門シリーズ（全10回）の第4回です。シリーズの一覧はこちら。

何を作るかは、「要求定義」と「要件定義」の2段で決めます。AX（AIトランスフォーメーション。AIを前提に業務や組織を変えること）では、作る作業はほぼAIに任せられるようになりました。そのぶん推進担当の仕事は、作る前のこの2段が中心になっています。

要求定義は「何を実現したいか」、要件定義は「何を満たすべきか」を決める

要求定義と要件定義は、システム開発で一般的に使われる工程の呼び名です。工程の分け方は、IPA（情報処理推進機構）の「共通フレーム2013」が共通の枠組みとして整理しています。

要求定義は、何を実現したいかを決めることです。今の業務の姿（As-Is）を整理し、何に困っているか（課題）と、何のために変えるか（目的）を確かめます。決めるのは、推進担当と現場です。

経費精算で言えば、As-Isは「上長が承認した後、経理の担当者が全件の領収書を規程と照らして目で確かめている」です。課題は「月末に申請が集中して確認が締めに間に合わず、差し戻しが何往復もする」ことです。目的は、月末の確認を締めに間に合わせ、差し戻しの往復をなくすことです。

要件定義は、要求定義で決めたことを満たすために、業務とシステムが何を満たすべきかを確定させることです。要件定義の中には、業務として満たすべきことを決める「業務要件」と、AIのシステムが満たすべきことを決める「システム要件」があります。

業務要件は、業務としてのTo-Beを決めるものです。To-Beは求める業務の姿で、As-Isと対で使います。業務フローや、例外に業務として誰がどう対応するかも、ここで決めます。To-Beは業務の言葉で書きます。この例なら「AIが全件を規程と照らして『問題なし』と『要確認』に分け、経理は支払いの直前に要確認の申請を中心に確かめる。差し戻しは1回で終える」です。

業務要件でも、AIでどこまでできそうかの当たりはつけます。それでも、決めるのはあくまで業務の話です。誰が・いつ・何を確かめ、問題があればどこへ戻すかまでを、推進担当が現場と一緒に決めます。

システム要件は、AIのシステムが満たすべきことを決めるものです。何を判定し、何を人に回し、どの精度・速さで動くかを決めます。この例なら「全件の領収書を読んで規程と照らし、判定できない申請は経理に回す。月末に申請が集中しても、締めまでに仕分け終える」です。決めるのは推進担当で、ベンダーに頼むならベンダーと詰めます。

どう作るか（How）は、要件定義の次の「設計」で決めます。実際には、現場が使う画面や操作の流れを決める画面設計・UX設計（UXは、使う人が操作を通して得る体験）も、設計で行います。設計はベンダーか作る人が担い、細部はAIで詰めます。

システム要件や設計を詰めると、To-Beのとおりには作れないと分かることもあります。そのときは業務要件に戻り、To-Beを理想から譲って、作れる形に直します。たとえば手書きの領収書をAIが十分に読めないなら、「手書きの分だけは経理が全件を確かめる」というTo-Beに直します。

要求定義、要件定義、設計の境目に、はっきりした線は引けません。それでも「何を実現したいか」「何を満たすべきか」「どう作るか」で大枠を分けておくと、誰と何を決めるのかがぶれません。

なお、何を作るかを決める途中に、もう一段小さな要求定義が含まれることがあります。To-Beを描くために、AIが手書きの領収書を読めるかをPoC（本格導入の前に、小さく作って効果と実現性を確かめる検証）で先に確かめる場合です。そのPoCにも、小さな要求定義と要件定義があります。この記事では、業務改善全体の要求定義と要件定義を軸に話を進めます。

To-Beの「最初のピン」は、業務を知る推進担当が打つ

何を作るかを決めるうえで一番大事なのは、業務要件でTo-Beの最初のピンをどこに打つかです。最初のピンとは、To-Beを描くときに最初に決める「どの業務の、誰の仕事を、どう変えるか」という一点のことです。ピンは業務の言葉で打ち、後の決めごとは、すべてこれに従います。

To-Beは描き方の選択肢がいくらでもあるため、最初のピンの打ちどころを間違えると、全体が成り立たなくなります。経費精算で詰まっているのは経理の照合なのに、「申請する社員がAIに話しかけるだけで入力できる」所にピンを打ったとします。入力は楽になっても、月末の確認の詰まりは残ったままです。

筋の良いピンは、要求定義で挙げた課題を直接解く位置にあります。この例なら「経理が全件を目で照合している所を、AIが先に仕分ける形に変える」がそれにあたります。ここが決まれば、誰が何をいつ確かめるか、差し戻しをどう回すか、といった後の決めごとが順に決まっていきます。

ピンを打つには、業務と現場のことと、AIで何ができるかを、同時に知っている必要があります。片方しか知らない人が打つと、AIでは実現できない所か、作れても業務の困りごとを解かない所にピンが刺さります。

社内の推進担当の強みは、業務と現場を知っていることです。足りないAIの知識は、自分でAIを触って確かめる、ベンダーに聞く、他社の事例を調べる、といったやり方で補えます。経費精算なら、手元の領収書を何枚かAIに読ませてみるだけでも、どこまで読めるかの当たりがつきます。ただし、ベンダーに聞くのはAIの知識までにして、ピンを打つことまで任せきりにはしません。業務を知らない人が打つと、筋の悪い所に刺さりやすいからです。

要求定義で現場に聞くところから、To-Beを描くまでの流れは、「現場に聞く → 整理する → 業務を理解する → To-Beを描く → 現場に確かめる」です。このうち、聞いた内容を整理して業務フロー図にするのはAIでできます。一方で、現場に聞くことはAIに任せられません。どこを深掘りするかを決め、どこにどんなデータがあるかや、決まった手順どおりに処理できないケース（例外）までを聞き出すのは、人の仕事です。理想のTo-Beを描くことも、まだAIには任せられません。

経費精算なら、「差し戻しになるのはどんな申請が多いですか」「領収書の画像はどこに保存されていますか」と聞きます。「規程には書いていないけれど、実際には認めている例外はありますか」も欠かせない問いです。答えを受けて、どこをさらに掘り下げるかをその場で決めるのが、AIに任せられない部分です。

ピンさえ筋良く打てれば、その先のシステムの細部は、作りながらAIで詰められます。

例外は、業務としての対応と、システムでの見分け方の2段で決める

例外の扱いは、多くの件で仕組みが動くことを先に目指し、残りのフォローを別に決めるのが基本です。たとえば申請の90%には読める領収書の画像が付いていて、10%は画像が無いかぼやけているとします。それなら90%で動く仕組みを先に作り、10%は別の手順で受けます。使う人の予期せぬ動き、たとえば1枚の写真に何枚もの領収書をまとめて撮って添付するようなことも、同じように扱います。

例外の出どころは、次の3つです。

• データ：記録の欠けや揺れ（領収書の画像が無い、店名の書き方がばらばら）
• AIの精度：AIの読み違いや判断の誤り（金額の桁を読み違える）
• 業務プロセス：業務にもともとある例外（規程の上限を超える宿泊費も、部長の事前承認があれば認める）

1段目は、業務としての対応です。業務要件で、どんな例外があり、業務として誰がどう対応するかを決めます。具体的には、人がどこで確かめ、誰が承認し、どこへ差し戻すかです。たとえば「画像が読めない申請は、経理が社員に再提出を頼む」と決めます。例外はAIだけでは洗い出せません。現場に聞く段階で、取りこぼさずに拾っておきます。

2段目は、その例外をシステムがどう見分け、どう人に回すかです。何を満たすべきかはシステム要件で、仕組みは設計で決めます。システム要件なら「画像が読めない申請や、読んだ金額が申請額と合わない申請は、必ず経理に回す」です。設計では、そうした申請に「要確認」の印を付けて経理の確認待ちに回す仕組みを決めます。申請ごとに「確認待ち」「差し戻し中」のような状態を持たせるのも、設計で決めることです。

洗い出した例外は、作った後のテストで確かめる項目に入れます。どの例外がどう人に回るかを、実際に動かして確かめるためです。AIのミスをどう評価し、どこまで許すかは、第6回（AIのミスはどこまで許容するか：精度の測り方とリスクの決め方）で扱います。

設計では、大枠を人が決め、細部はAIで詰める

設計のうち、システムの大枠と、例外の見分け方・人への回し方の仕組みは、人が決めます。ベンダーに頼むならベンダーが、自分で作るなら推進担当が決めます。経費精算なら、どの判断をAIの推論（AIに文章や画像を読ませて答えを出させること）に任せ、どこを決まった処理で固めるかが大枠です。判定できない申請をどう見分けて確認待ちに回すかも、ここに入ります。

画面設計・UX設計も、設計で行います。経理の担当者が要確認の申請をどの画面で、どの順に確かめるかといったことです。画面と操作の流れは、現場に動く画面を見せながら決めます。動く画面を見せて進めるやり方は、第8回（AXが進まない会社で、上と現場を動かして社内合意をつくる方法）で扱います。

一方で細部、たとえば「要確認」に添える理由の書き方や画面の並び順は、AIで詰められます。第3回（AI導入の進め方：7つのステップと、人とAIの分担）で見たとおり、作るのと直すのが安くなったので、細部は作りながら決めて構いません。

動きを保証したい所は、ワークフローに寄せる

設計で決める大事なことの1つが、ワークフローと自律型エージェントのどちらで作るかです。

ワークフローは、処理の順序が完全に決まっている作りです。決まった手順の中に、部分的にAIの推論を挟むこともできます。毎回同じ順で動くので動きがぶれない代わりに、例外への柔軟性は弱くなります。

自律型エージェントは、何をどの順でやるかをAIが決める作りです。例外にも柔軟に対応しやすい一方で、毎回どう動くかは保証しにくくなります。

自律性（AIに判断を任せる度合い）と決定性（毎回同じに動くこと）は、片方を取るともう片方が下がる関係にあります。そこで、動きを保証しなければならない所はワークフローに寄せます。

この見方は、精度を上げたいときにも使えます。たとえば1000ページの書類をAIに全部確認させたいとき、自律型エージェントに任せると、途中でサボって一部を飛ばすかもしれません。1ページずつループ（同じ処理の繰り返し）で回してAIに渡すワークフローにすれば、確実に全ページを見ます。

経費精算の例なら、申請を1件ずつ順に取り出し、領収書が規程に合うかの判定だけをAIに任せるワークフローにできます。支払いにつながる処理なので、どの申請も必ず同じ順で確かめられる作りにしておきたい所です。

この観点は、ベンダーが出してきた設計を読むときにも使えます。「ここは必ずこの順で動きますか」「ここはAIに判断を任せていますか」と聞けば、動きを保証している所と、AIの判断に任せている所を区別できます。自分でAIに作らせる場合も、同じ問いで自分の作りを確かめます。

成果物のイメージ：IO定義書と開発仕様

要件定義と設計は、それぞれ形のある成果物に落とします。推進担当が自分で作る場合も、ベンダーに出してもらう場合も、次の形を目安にすると、決めるべきことの抜けに気付けます。

業務要件の成果物：IO定義書と業務フロー図

IO定義書は、To-Beの工程ごとに、入力（インプット）と出力（アウトプット）を決める表です。IOは Input と Output の頭文字です。To-Beを業務の言葉で固めるための、業務要件の成果物です。

冒頭には、入出力を決めるときの3つの原則を置きます。この3つに沿って入出力を決め、業務をやり直しなく回せるようにします。

• 入力も訂正も、データの出どころになるシステムで行う（金額の誤りは、AIが出した結果ではなく経費精算システムの申請で直す）
• 確認は、そのアウトプットを次に使う担当が、使う直前に行う（確認者・観点・NGのときの戻し先を、あらかじめ固定する）
• 差し戻しは1回で終える（締め日に間に合わせるため往復を作らず、締め後の訂正は翌月に回す）

経費精算に当てはめると、2つ目の原則の確認者は経理の担当者で、確認するのは支払いデータを作る直前です。観点は規程の上限と領収書の日付・金額、NGのときの戻し先は申請した社員、と決めておきます。確認者や観点が日によって変わらないので、確認の結果がばらつきません。

その下に、インプット定義とアウトプット定義を工程ごとに書きます。インプット定義には、前提条件、誰に、いつ、何を、どう出してもらうか（形式と手段）、どこに入れるか、次の受け手、期限を書きます。アウトプット定義には、誰が、いつ、何を、どこで、どの観点で確かめ、OKなら次はどこへ、NGならどこへ戻すかを書きます。

全工程を流れの順に並べた工程別の一覧も付け、担当とインプット・アウトプットを対応付けます。AIが受け持つ工程は色を変えておきます。ここで書くのは「この工程はAIが受け持つ」という業務上の役割までで、AIの中でどう処理するかは書きません。それは設計で決めることです。

最後に、要確認事項の一覧を付けます。業務フロー図だけでは決まらない点を、現場と合意するためのものです。論点、確認したい内容、こちらの想定、影響する入出力、確認先、回答欄の項目で並べます。経費精算なら、差し戻しの期限、社員への連絡の手段、締め後に出た訂正の扱いなどが並びます。

業務フロー図は、As-Isを要求定義で描き、To-Beを業務要件で描きます。As-IsとTo-Beを並べ、変わる所だけを強調します。確認がOKだった場合と差し戻しがあった場合のように、パターンを分けて描くと、その場合に通らない工程がはっきりします。本番に切り替える前に、今の運用を続けながら新しい仕組みも並行して動かし、結果を比べてから切り替えることも明記しておきます。描き方の詳細は、第5回（業務フローの作り方と、AI導入のROIの出し方）で扱います。

設計の成果物：開発仕様

開発仕様は、To-Beをシステムでどう実現するかを書いた文書で、設計の成果物です。システム要件で決めた、何を判定し何を人に回すかを、作り方まで落とします。業務全体ではなく、AIが受け持つ工程だけを「入力・処理・出力」で書きます。処理の中身は、判定の分岐ツリー（条件ごとに枝分かれしていく図）で示します。経費精算なら、まず「画像が読めるか」で分け、読めなければ要確認にします。読めたら「読んだ金額が申請額と合うか」、合えば「規程の上限以内か」と順に枝分かれさせ、上限を超えていれば事前承認の記録を見に行きます。

ほかにも、開発仕様には次のような中身が入ります。

• 申請1件ごとに状態を持つ：それぞれの申請が「AI確認済み」「経理の確認待ち」「差し戻し中」「確定」のどれにあるかを記録する。次の宛先の自動決定、未対応の人へのリマインド、訂正前後の見比べに使える
• AIの推論は一部だけ：領収書を読んで規程に合うかを判定する所だけをAIに任せ、どちらとも言えないものは人へ回す。金額の集計、差し戻しの宛先、状態の更新は決まった処理で行う
• 支払い以降の手順を変えない：支払いデータは、今の会計システムに取り込んでいるのと同じ形式で書き出し、その後の手順をそのまま使えるようにする
• 補助の対応表：勘定科目ごとの規程の上限、社員と上長の対応
• 例外を人に回す先：画像が読めない申請は、要確認の印を付けて経理の確認待ちに回す（その後に経理が社員へ再提出を頼むのは、業務要件で決めた業務の対応）

AIに任せる判断はごく一部で、周りは決まった処理で固めています。前の節の「動きを保証したい所はワークフローに寄せる」を、成果物の形にするとこうなります。

自分で作るときも、ベンダーに頼むときも確かめること

推進担当が自分で作る場合も、ベンダーに出してもらう場合も、2つの成果物で次の点が埋まっているかを確かめます。

• IO定義書の各工程で、確認者・観点・NGのときの戻し先が決まっているか
• 要確認事項が、現場と合意できているか
• 開発仕様で、AIの推論に任せる判断がどこかが書かれているか
• 洗い出した例外のそれぞれに、人に回す先とテストの項目があるか
• 出力の形が今の様式と同じで、その後の手順を変えずに済むか

ベンダーが出してきた成果物でこれらが空いていれば、そこがまだ詰め切れていない所です。

推進担当が押さえる要点

• 要求定義で何を実現したいかを決め、要件定義で業務とシステムが満たすべきことを確定させる。どう作るかは設計で決める
• 要求定義と業務要件は推進担当が現場と決め、システム要件は推進担当が決める（ベンダーに頼むならベンダーと詰める）
• To-Beの最初のピンは、業務要件の中で、業務と現場を知る推進担当が打つ。AIの知識は、触る・聞く・調べるで補う
• 現場への聞き取りは人がやる。聞いた内容を整理して図にするのはAIに任せられる
• 例外は、業務として誰がどう対応するか（業務要件）と、システムがどう見分けて人に回すか（システム要件と設計）に分けて決める
• 設計では画面設計・UX設計も行う。動きを保証したい所はワークフローに寄せ、AIの推論は必要な所だけに使う
• 細部は作りながら決め、確かめながら直す

まとめ：業務の姿を決めてから、実現の方法を決める

AIで何を作るかは、何を実現したいかを決める要求定義と、業務とシステムが何を満たすべきかを確定させる要件定義の2段で決めます。どう作るかは、その次の設計で決めます。要の1つは業務要件で打つTo-Beの最初のピンで、業務と現場を知る推進担当が、AIの知識を補いながら打ちます。例外は、業務としての対応とシステムでの見分け方に分けて決め、洗い出したものはテストの項目に入れます。設計では、画面と操作の流れも決め、動きを保証したい所をワークフローに寄せます。

次の第5回（業務フローの作り方と、AI導入のROIの出し方）では、To-Beを描くための業務フロー図とデータの整理を扱います。要求定義と業務要件がそろえば、作る前にROI（投資に対してどれだけ効果が返るか）を出せます。その出し方もあわせて整理します。

シリーズの目次

• AXとは？DXとの違いと、AIを前提に業務を組み直す考え方 〜AX推進入門 第0回〜
• 生成AIを全社員に配っても使われない理由と、利用率を上げる進め方 〜AX推進入門 第1回〜
• AX推進の体制づくりと、推進担当が着任して最初にやること 〜AX推進入門 第2回〜
• AI導入の進め方：7つのステップと、人とAIの分担 〜AX推進入門 第3回〜
• 要求定義と要件定義の違い：AI導入で何を作るかの決め方 〜AX推進入門 第4回〜（この記事）
• 業務フローの作り方と、AI導入のROIの出し方 〜AX推進入門 第5回〜
• AIのミスはどこまで許容するか：精度の測り方とリスクの決め方 〜AX推進入門 第6回〜
• AI導入の費用相場と予算の取り方、ベンダーの選び方 〜AX推進入門 第7回〜
• AXが進まない会社で、上と現場を動かして社内合意をつくる方法 〜AX推進入門 第8回〜
• AIで人を減らさずに成果を出す、リソースシフトとリスキリングの考え方 〜AX推進入門 第9回〜

関連記事

• AI導入の進め方：7つのステップと、人とAIの分担 〜AX推進入門 第3回〜：要求定義・要件定義・設計が、プロジェクト全体のどの段階にあたるか
• 業務フローの作り方と、AI導入のROIの出し方 〜AX推進入門 第5回〜：To-Beの業務フロー図の描き方と、例外の出どころになるデータの整理
• AIのミスはどこまで許容するか：精度の測り方とリスクの決め方 〜AX推進入門 第6回〜：洗い出した例外とAIの見落としを、どう評価して許す範囲を決めるか
• AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール：例外を人に回す動線を、承認としてどう組むか

参考資料

• IPA「SEC BOOKS：共通フレーム2013」（2013年3月、https://www.ipa.go.jp/publish/secbooks20130304.html （2026年11月9日確認））

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の言葉で言えば、Askhubは、要件定義と設計で決めた「AIに任せる判断」と「人に回す例外」を、承認と判断ログを備えた形で動かす基盤にあたります。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連するページ：製品の全体像、伴走支援

AIで何を作るか、To-Beの描き方から相談したい方は、お問い合わせからご連絡ください。