AIを使った仕組みをつくろうと決めたものの、「AIでいい感じに処理してほしい」から先の言葉が出てこず、打ち合わせが何度も振り出しに戻る——発注後の要件定義でよくある状態です。この記事では、提案依頼書をつくる前段階ではなく、発注が決まった後に仕様を確定させる工程に絞り、現行業務フローの書き出しから「完成とみなす条件」の決め方までを6手順で整理します。
- 現行業務フローを書き出す 人が何を見て何を決めているかを分解
- 入力データを棚卸しする 形式・量・入手経路・欠損を確認
- 出力形式を決める 誰が次に何をするかから逆算
- 例外処理を洗い出す 想定外が来たときの扱いを先に決める
- 受入条件を定義する テストケースと合否の判定方法を書く
- 運用後の見直し方を決める 誰がいつ何を見て直すか
なぜ「AIでいい感じに」で止まるのか
要件がまとまらない案件には、いくつか共通した状態があります。ひとつは、現行業務が属人的で、手順書がないか実態と合っていないこと。もうひとつは、AIに任せたい範囲と人が判断する範囲の境目が決まっていないことです。
この二つが未確定のまま「精度はどのくらい出ますか」という話を始めると、何を正解とするかの定義がないため、議論が進みません。精度は、入力と出力と判定基準が決まって初めて測れる値です。
さらに、AIを使うと決めたこと自体が目的化していると、そもそもAIが適した領域かの見極めが抜けます。ルールで書ける処理、集計で足りる処理、人が判断したほうが早い処理が混ざっている業務は珍しくありません。
要件が固まらない原因の多くは、AIの性能ではなく、現行業務と正解の定義が書かれていないことにあります。
手順1・2：業務フローと入力データを書き出す
現行業務フローの書き出し
最初にやるのは、今どうやっているかを工程単位で書くことです。理想の姿ではなく、現実の手順を書きます。
- 誰が（役割）
- いつ・どの頻度で
- どこから情報を受け取り（メール、紙、基幹システムの画面など）
- 何を見て、何を基準に判断し
- どこへ結果を渡すか
判断の部分は「経験で分かる」で止めず、過去の具体例を3〜5件挙げて、そのときに何を見たかを聞き取ると書き起こしやすくなります。担当者が複数いる場合は、人によって手順が違う箇所に印を付けておきます。そこが後で例外処理の候補になります。
入力データの棚卸し
次に、仕組みに渡すデータを確認します。確認する項目は次のとおりです。
| 確認項目 | 具体的に見ること |
|---|---|
| 形式 | PDF、画像、Excel、API、手入力のどれか |
| 量 | 1日・1か月あたりの件数と繁閑の差 |
| 入手経路 | 誰が置くのか、自動で届くのか |
| 品質 | 欠損、表記ゆれ、重複、スキャンの傾き |
| 制約 | 個人情報の有無、社外持ち出しの可否 |
品質の確認は、きれいなサンプルだけでなく、現場で「扱いにくい」とされている実物を数件もらうことが重要です。きれいな例だけで設計すると、稼働後に想定外が集中します。
手順3・4：出力形式と例外処理を決める
出力は「AIの答え」ではなく「次の人の作業に使える形」から逆算して決めます。項目名、データ型、桁数、ファイル形式、連携先のどこに入るかまで書きます。ここが曖昧だと、動くものはできても現場で使われません。
併せて決めるのが、確信が持てないケースの扱いです。出力に「確認が必要」という状態を持たせるかどうかで、運用の設計が変わります。
自動で確定させる
- 誤りが出ても後工程で気づける
- 件数が多く、人の確認が現実的でない
人の確認を挟む
- 誤りが金額や契約に直結する
- 判断材料が入力に含まれていないことがある
例外処理の洗い出しでは、手順1で印を付けた「人によって扱いが違う箇所」と、現場が覚えている過去のトラブルを並べます。想定外が来たときに、止めるのか、保留に回すのか、暫定値を入れて記録を残すのか。方針を文章で決めておくと、開発中の仕様確認が減ります。
手順5：受入条件を「テストケースと判定方法」で書く
完成の定義は、機能一覧ではなくテストケースで表します。少なくとも次の3点をセットで書きます。
- 入力：実データに近いサンプルを何件、どの種類で用意するか
- 期待する出力：項目ごとに、何をもって正しいとするか
- 判定方法：誰が、どの手順で、どこまで一致すれば合格とするか
AIを使う処理では、全件完全一致を合格条件にすると現実的でない場合があります。その場合は、項目ごとに扱いを分けます。たとえば「金額と日付は全件一致が必要」「摘要の表記ゆれは差異として許容する」といった形です。許容する差異は、文章で具体的に書いておきます。
テストデータは、要件定義の段階で「誰がいつまでに用意するか」を決めておきます。ここが決まっていないために検収が遅れる案件は少なくありません。
受入条件は、入力サンプル・期待する出力・判定手順の3点を文章にして、開発着手前に双方で合意しておきます。
手順6：運用後の見直し方まで決めておく
AIを含む仕組みは、入力データの傾向が変われば出力も変わります。稼働後に誰が何を見るかを決めていないと、気づいたときには現場が手作業に戻っている、という状態になりがちです。
- 日々の運用で、誰が異常に気づく立場にあるか
- 月次で見る指標（処理件数、人が修正した件数、保留になった件数）
- 修正の記録をどこに残すか
- どの程度の変化があれば見直しを検討するか
指標は多くせず、修正件数と保留件数のように、現場が自然に記録できるものから始めるほうが続きます。
外部に依頼するときの進め方
社内だけで手順1〜6を書き切るのが難しい場合、要件定義の工程から外部に入ってもらう選択肢があります。その際に見るべきは、開発そのものよりも、現行業務の聞き取りと、PoCで何を検証するかの設計まで扱えるかどうかです。
株式会社ALTのAIコンサルティング・システム開発では、AI活用領域の見極め、構想・ロードマップの策定、PoC設計と効果検証、要件定義、開発、既存環境との連携、運用改善までを支援しています。どの工程から入るかは案件の状況によって変わるため、まず現状の業務フローと手元にあるデータを持ち寄って整理するところから相談するのが現実的です。
よくある質問
Q: 現行業務に手順書がなく、担当者ごとにやり方が違います。どこから手を付ければよいですか。
A: 手順書を先に整えようとせず、直近の処理実例を3〜5件取り上げて、担当者が何を見て何を決めたかを聞き取る方法から始めてください。人によって違う箇所は無理に統一せず、違いをそのまま記録します。その差分が、後の例外処理の検討材料になります。
Q: 精度が何％必要かと聞かれますが、答えられません。
A: 数値を先に決める必要はありません。先に「誤った出力が出たとき、誰がいつ気づき、どんな影響が出るか」を整理してください。影響が大きい項目は人の確認を挟む設計にし、影響が小さい項目は許容範囲を文章で書く、という順で考えると、必要な水準が具体化します。
Q: PoCをやるべきか、いきなり開発に進むべきか迷っています。
A: 入力データの品質にばらつきがある、過去に同種の処理を自動化した経験がない、といった場合は、限定した範囲で検証してから判断するほうが手戻りが少なくなります。その際も、検証の合格条件を先に決めることは同じです。何を確かめるための検証かが決まっていないPoCは、結論が出ないまま終わりやすい点に注意してください。
まとめ
AIの要件定義が止まる原因は、多くの場合、AIの能力ではなく、現行業務と「正解」が文章になっていないことにあります。現行フローの書き出し、入力データの棚卸し、出力形式の決定、例外処理の洗い出し、受入条件の定義、運用後の見直し方——この6手順を順に埋めていけば、議論の対象が「いい感じ」から具体的な項目へ移ります。
とくに受入条件は、開発着手前に合意しておくことで、検収時の認識違いを減らせます。社内だけで整理が難しい場合は、要件定義の工程から外部の支援を検討してください。
