業務システムにAI機能を載せる前に｜要件と期待値の整理
「今動いてる業務システムに、AI機能も付けられない？」—— そう言われた瞬間、頭の中に一気にいろんな問いが浮かびますよね。どこに、何を、どう載せるのか。既存の処理を壊さないか。データはそのまま渡していいのか。指示はふわっとしているのに、動き出せば「思ってたのと違う」と言われそうな予感もある。そんな場面、ありますよね。
ここでいきなり実装から入ると、後で一番つらいことになります。AI機能は「動くかどうか」だけでなく、「どこまで正しく、どこは間違える前提で運用するか」を決めていないと、リリースしてから毎日その後始末に追われます。だからこそ、作り始める前に、要件と期待値を6つだけ言葉にしておく——これがいちばん効く準備です。この記事では、その6つを明日から一歩ずつそろえられる形で、一緒に整理していきます。
結論：業務システムにAI機能を載せる前に、実装より先に次の6つを言葉にします。①目的（どの業務のどこを楽にするのか）→ ②入力と出力（何を渡し、何が返ってくるか）→ ③許容できる誤り（どこまでの間違いなら実務が回るか）→ ④人の確認（どこで人がチェック・承認するか）→ ⑤非機能（速度・費用・データの取り扱い）→ ⑥やめる条件（どうなったら止める・戻すか）。この6つがそろうと、作るものが小さく定まり、運用の負担と手戻りが大きく減ります。最後のチェックリストを、着手前の打ち合わせに持っていってください。
「AI機能を付けて」という指示が曖昧なのは、頼む側もまだ完成形を描けていないことが多いだけで、あなたが責められる話ではありません。むしろ最初に要件を言葉にできる人がいると、そのプロジェクトはそこから現実的に動き出します。
「動くAI」と「運用できるAI機能」は、別ものです
デモで「動いた」AIと、毎日の業務で「使い続けられる」AI機能は、実は別のものです。
デモは、うまくいく入力を選んで見せられます。でも本番の業務システムには、想定していない入力も、例外だらけのデータも、急いでいる利用者も流れ込んできます。AIはもっともらしく間違えることがある道具なので、「たまに間違える」を前提に、その間違いを誰がいつ拾うのかまで設計しておかないと、運用が回りません。
だから、ここでいきなり実装に入るのは危険です。 やることは難しい技術ではなく、「載せる前に決めておくべきこと」を6つに分けて、依頼者と一緒に言葉にすること。これは丸投げを押し返す作業ではなく、まだ言語化されていない要件を肩代わりして、プロジェクトを前に進める仕事です。順に見ていきましょう。
要件1：目的——どの業務の、どこを楽にするのか
最初に確認するのは、AIの種類でも精度でもなく、「この機能で、どの業務のどこが良くなればうれしいのか」です。
- どの業務の、どの作業を対象にするのか（全部ではなく、一箇所に絞る）
- 何を良くしたいのか（時間？ 抜け漏れ？ 人手不足？ ばらつき？）
- それは本当に「AIで」やるのが効くのか、既存の仕組みで足りないか
聞き方の例：「今回の狙いは、たとえば『問い合わせの一次仕分けにかかる時間を減らす』という理解で合ってますか？」 相手が「そうそう」と言えば、目的が一文になります。この一文が、後のすべての判断の基準です。ここがぼやけたまま「とりあえずAIを載せる」と進むと、何を作っても「ちょっと違う」が続きます。
要件2：入力と出力——何を渡し、何が返ってくるか
目的が見えたら、AI機能を「入り口」と「出口」で具体化します。ここが決まると、作るものの輪郭が一気にはっきりします。
- 入力：AIに何を渡すのか（問い合わせ文？ 帳票の内容？ 過去の記録？）。その形は毎回そろっているか、バラバラか
- 出力：何が返ってくれば業務で使えるのか（分類の候補？ 要約？ 下書き？ 数値？）
- 出力は、その後の業務フローのどこに、どんな形で流れ込むのか
ポイントは、出力を「そのまま結果」にしないことです。 たとえば「問い合わせを自動で振り分ける」なら、いきなり振り分けを確定させるのではなく、まず「振り分け先の候補を出す」までにする。出力を提案（たたき台）として受け取り、確定はこの後の要件4で人がはさむ——この形にしておくと、間違えても事故になりません。
要件3：許容できる誤り——どこまでの間違いなら、実務が回るか
AI機能で一番もめるのは、実はリリース後です。 「思ったより間違える」と言われて初めて、人によって"許せる間違い"の線が違うことが露呈するからです。だから基準は、作る前にそろえておきます。
- この業務で、AIが間違えたときに起きることは何か（軽い手直し？ 取り返しのつかない処理？）
- どのくらいの精度なら、実務として回るのか（100点は求めない）
- 間違えても軽傷で済む使い方になっているか（確定ではなく提案にとどめる、など）
大事なのは、「間違いをゼロにする」ではなく「間違えても被害が小さい形にする」という発想です。 AIは一発で満点を出す道具ではありません。だから、精度を上げる努力と同じくらい、「間違えても、人が気づいて直せる場所に置く」設計が効きます。取り返しのつかない処理（削除・確定・外部への送信など）は、AI単独では実行させない——この線を先に引いておきましょう。
要件4：人の確認——どこで、誰がチェックし、承認するか
AIの出力は人がレビューする前提です。その「人」と「場所」を、業務フローの中に先に置いておきます。
- AIの出力を、誰が最終的に確認・承認するのか
- 確認は全部に対して行うのか、あやしいものだけ抜き出して行うのか
- 確認しやすい形で出力が表示されるか（元の入力と並べて見られるか）
この「人が確認を挟む形」は、ヒューマン・イン・ザ・ループ（human-in-the-loop：AIの処理の途中に人の判断を入れる作り方）と呼ばれ、業務システムでは一番現実的で無理のない形です。 全件を人が見るのが重ければ、「AIが自信のないものだけ人に回す」といった振り分けもできます。→ 組み方は人の確認を挟むAIワークフロー（HITL）の設計にまとめています。まずは「確定の前に、必ず人が一度見る場所がある」——ここだけ押さえれば十分です。
要件5：非機能——速度・費用・データの取り扱い
機能が動くことと、業務で使い続けられることの間には、速度・費用・データという現実的な壁があります。ここは技術というより、運用と組織のルールの話です。
- 速度：利用者が待てる時間に、出力が返ってくるか（画面の裏で時間がかかりすぎないか）
- 費用：AIのAPIは使った分だけ費用が増えます。想定の件数で、月いくらになりそうか
- データ：社内データ・個人情報・機密を、外部のAIサービスに渡してよい区分か
特に機密情報の取り扱いは、後から問題になると一番重いところです。 「この業務データ、外部のAIに渡してよい区分ですか？」と、動かす前に一拍置いて確認する。判断できる人が社内で分からなければ、外部への持ち出し可否は情シス、個人情報や契約上の縛りは法務、というように当たりを付けると聞きやすくなります。→ 線引きの考え方は社内データをAIに渡すときの線引き、費用の見積もりはAI APIの料金・レート制限を見積もるもあわせてどうぞ。
要件6：やめる条件——どうなったら止める・戻すか
最後に、「うまくいかなかったときの逃げ道」を先に決めておきます。ここを決めておくと、思い切って小さく試せます。
- どうなったら「この機能は一旦止める」と判断するのか（誤りが多すぎる、費用が想定を超える、など）
- 止めたとき、AIなしの元の業務フローに戻せるようになっているか
- まず一部の利用者・一部の業務だけで試し、問題なければ広げる形になっているか
AI機能は、「止められる」「元に戻せる」からこそ、安心して載せられます。 最初から全社・全業務に一気に入れず、1つの業務・一部の利用者で小さく試す。おかしければ、AIを外して元のやり方に戻す道を残しておく。この「戻る道」があるだけで、リリースの心理的な重さがずいぶん軽くなります。
明日からやること（小さく始める3つ）
全部を一度の打ち合わせでそろえようとすると重いので、まずこの3つから。
- 目的を一文で書いて、依頼者に確認する：「この機能で、〇〇の作業を△△したい、で合ってますか？」とメッセージ1本。要件1が片付きます。
- 出力を「提案」にとどめ、人の確認を1か所置く：確定ではなく候補を出す形にするだけで、要件3・4の事故がまとめて軽くなります。
- データを外部AIに渡してよいか、先に聞く：「この業務データ、外部AIに入れてよい区分ですか？」の一言。要件5の一番重い事故を防げます。
業務システムにAI機能を載せる前の確認チェックリスト
着手前の打ち合わせや、依頼者へのメッセージにそのまま使えます。一度に全部でなく、今日は埋められる所だけで十分です。
まずはこの3つだけ埋まれば、設計に進んでOK：
- 目的を一文にできた（どの業務のどこを楽にするか）
- 出力を「提案」にとどめ、人が確認する場所を決めた
- データを外部AIに渡してよいか確認した（可否の当たりがついた）
要件1：目的
- 対象の業務・作業を一箇所に絞れたか
- 何を良くしたいか（時間・抜け漏れ・ばらつき等）を言葉にできたか
- 本当に「AIで」やるのが効く話か確かめたか
要件2：入力と出力
- AIに渡す入力の中身と形を決めたか
- 業務で使える出力の形（候補・要約・下書き等）を決めたか
- 出力を「確定」ではなく「提案」として受け取る形にしたか
要件3：許容できる誤り
- 間違えたときに何が起きるかを洗い出したか
- 実務が回る精度のラインを（できれば例で）決めたか
- 取り返しのつかない処理をAI単独で実行させない形にしたか
要件4：人の確認
- 出力を最終確認・承認する人を決めたか
- 全件確認か、あやしいものだけ確認かを決めたか
- 入力と出力を並べて確認できる形にしたか
要件5：非機能
- 利用者が待てる速度に収まるか確認したか
- 想定件数での費用感を見積もったか
- 機密・個人情報を外部AIに渡してよいか確認したか
要件6：やめる条件
- 「止める」と判断する線を決めたか
- AIなしの元の業務フローに戻せる形にしたか
- 一部の業務・利用者で小さく試す形にしたか
最後に
「このシステムにAI機能を付けて」と言われて身構えるのは、あなたが対応できないからではありません。 その一言が、まだ要件になっていないだけで、それを整理して形にできる人が、いまその現場で一番必要とされている人です。
6つ全部でなくても、今日ひとつ「目的を一文にする」ができたなら、それはもう確かな一歩です。 AI機能を作り始める前に、まず何をさせたいのかを言葉にする。そこから、小さく試して、戻せる形で載せていく。一歩ずつで大丈夫です。
よければ、こちらも
- AIのPoCで合意を取る手順｜小さく試して見せて決める——「本当に使えるか」を先に確かめてから載せたいときに。
- 人の確認を挟むAIワークフロー（HITL）の設計——要件4の「人の確認」を具体的に組みたいときに。
- AIの出力が不安定なときのフォールバックとリトライ設計——載せた後、出力の不安定さに備えたいときに。