AI機能を入れる前に業務フローを整理すべき理由

「うちもAIを入れたい」という相談を受けたとき、まず聞くのは「AIで何を作りたいか」ではなく「今、何が一番遅いか、あるいは一番ミスが多いか」です。この問いに即答できないまま「AI機能」の話が先行すると、高い確率で使われない機能ができあがります。この記事では、AIを入れる前に整理すべき業務フローの見直し方を、実務的な順番で説明します。

なぜ「AIを入れたい」から始めると失敗するのか

AIは強力な部品ですが、部品である以上「どこに組み込むか」を間違えると効果が出ません。よくある失敗パターンは次の3つです。

• 目立つ工程にAIを当ててしまう。デモ映えする機能(チャットボット、要約、自動生成)から着手した結果、実際の業務時間はほとんど短縮されない。問い合わせ対応の一次回答をチャットボット化しても、そこがボトルネックでなければ全体のリードタイムは変わらない。
• AIが得意でない判断を任せてしまう。例外対応や責任の所在が絡む判断をAIに寄せた結果、人間が結局チェックし直すことになり、工程が1つ増えただけになる。「AIが下書きを作る→人が全文チェックする」構成は、チェックに元の作業と同じ時間がかかるなら効果はゼロに近い。
• PoCで止まる。「動くデモ」はできたが、本番データ・本番運用に乗せる前提が整っておらず、検証だけして終わる。

これらはすべて、AIの技術力ではなく業務フローの理解不足が原因です。AIを検討する前に、まず今の業務フローを分解する必要があります。

ステップ1: ボトルネックを「時間」と「ミス」で分解する

業務フローの見直しは、感覚ではなく数字から始めます。以下を洗い出してください。

• その工程に誰が何分かけているか(担当者の体感ではなく、実測または直近1〜2週間のログ)
• ミスや手戻りの発生頻度とその後工程への波及コスト
• その工程が属人化しているか(特定の1人しかできない状態か)

実測の方法は難しく考えなくていい。専用ツールがなくても、対象の担当者に1〜2週間、工程ごとの開始・終了時刻をSlackやスプレッドシートに記録してもらうだけで、体感とのズレが見えてきます。「資料作成が重い」と思っていたら、実は資料作成自体は20分で、前工程のデータ収集(複数システムからのコピペ)に1件あたり40分かかっていた、というケースは珍しくありません。ボトルネックはしばしば「作業」ではなく「その前工程」に隠れています。

「時間がかかっている」と「重要」は別軸です。1日30分の定型作業を自動化するより、月1回だが差し戻しが多く炎上を生む工程を直すほうが、事業へのインパクトが大きいことは珍しくありません。ボトルネックは「頻度 × 1回あたりのコスト」で見るのが基本です。月間発生回数と所要時間・手戻りコストを掛け合わせ、上位2〜3工程に絞り込むと優先順位がぶれません。「全部大事」という結論になった場合は、まだ分解が粗い証拠です。

ステップ2: AIに任せる部分と人が判断する部分を切り分ける

ボトルネックが特定できたら、その工程を「判断」の性質で仕分けます。

• パターン化できる判断(過去事例に沿った分類・抽出・下書き生成)→ AIに向いている。例: 過去の問い合わせを見ればカテゴリが決まる一次仕分け、契約書のフォーマットに沿った項目抽出、定型メールの下書き生成。
• 責任が発生する最終判断(承認、金額決定、顧客への回答内容の最終確認)→ 人に残す。例: 与信判断、返金・値引きの可否、クレーム対応の最終文面。
• 例外・エッジケースの処理→ 最初は人が対応し、パターンが溜まってからAI化を検討する。例: 過去に前例のない問い合わせ、複数部門が絡む承認フロー。

ここを曖昧にしたまま「AIに全部任せる」設計にすると、例外が出るたびに人が割り込む羽目になり、かえって工程が複雑になります。逆に「人がAIの出力を毎回全部見直す」設計だと時間短縮効果が消えます。

判断の分かれ道は、「AIの誤りが起きたときに、誰がどれだけのコストを負うか」を先に言語化しておくことです。誤字レベルの下書きミスなら人が直せば済みますが、金額や納期を誤って顧客に送ってしまう性質のものは、そのまま次工程に流す設計にはできません。逆に「精度80%でも残り20%を人が拾えばいい」と割り切れる工程は、早期にAI化して構いません。AIの出力をどこまで信用して次工程に流すかを、精度が見えてから決める設計にしておくことが重要です。

この切り分けができると、必要な技術要素(既存LLM APIの組み合わせで足りるのか、自社データでのチューニングが要るのか)も自然と見えてきます。技術選定の考え方はAI・LLM活用の技術ページにまとめています。既存システムに手を入れる形でAIを組み込む場合は、既存プロダクト改修の着手前チェックも参考になります。

ステップ3: データが「AIに渡せる状態」か確認する

業務フローが整理できても、判断に使う情報がExcelに分散していたり、担当者の頭の中にしかなかったりすると、AIは機能しません。最低限「これがないとAIが機能しない」チェック項目は次の3点です。

• 電子化されているか: 紙の帳票をスキャンしただけ、PDFの中に表が画像として埋まっているだけ、といった状態は「電子化されている」ように見えて実際はAIが読み取れない。
• 過去の正解・不正解の実例が件数として残っているか(目安として数十〜数百件単位)。承認/却下の実績が消去済みだったり口頭伝達で完結していたりすると、学習・評価の材料がない。
• 表記ゆれなく同じ粒度で揃っているか(同じ項目が担当者ごとに違う書き方をされていないか)。個人情報・機密情報が含まれる場合は外部API送信の可否も社内で整理しておく。

このデータ整備は地味ですが、AI導入プロジェクトの遅延理由として最も多い要因です。社内にドキュメントやPDFが大量にあり、そこから情報を取り出したい要望であれば、AIによる書類処理の後付け導入も参考になります。

「AIを入れれば解決する」が失敗する典型シナリオ

• 入力が非定型なのに定型処理を前提にする: フリーフォーマットの問い合わせメールを、決まったテンプレートの入力と想定してAI分類器を作ると、文面の揺れに対応できず精度が実用レベルに届かない。
• 正解データが担当者の頭の中にしかない: 「ベテランなら見ればわかる」判断基準を学習データ化できず、AIの出力を評価する基準そのものが存在しない。
• 例外処理のコストを見積もっていない: 例外が全体の5%でも1件あたりの対応コストが通常業務の10倍かかるなら、AI化後もその5%のために人員体制を維持する必要があり、期待したコスト削減が出ない。
• 担当者の合意なくツールだけ入れる: 現場が「監視されている」と感じると正しいデータが入力されなくなり、改善サイクルが回らなくなる。

共通するのは「業務フローの整理をせずに機能から入る」ことです。分類・仕分け業務でAI化を検討している場合は、分類ワークフローへのAI導入も参考になります。

ステップ4: PoCで終わらせないための設計

PoCがPoCで終わる最大の理由は、「精度が本番運用に耐えるか」を検証する前に「動くかどうか」で満足してしまうことです。PoCの段階で以下を決めておくと、本番移行の判断がしやすくなります。

• 成功基準(精度・処理時間・削減できる工数を数値で。例:「一次仕分けの正答率90%以上」「対応時間を15分→5分に短縮」)
• 失敗時のフォールバック(AIが自信のない出力をどう扱うか。確信度スコアがしきい値を下回ったら自動で人に回す、といった具体的な線引き)
• 本番投入の判断者と判断タイミング(誰が何を見て決めるか。事前に決めておかないと、PoC後に「じゃあ誰が判断するのか」で止まる)
• 本番データでの検証期間(デモ用の整えられたデータでなく、実際の雑多なデータでどの程度精度が落ちるかを確認する期間)

これらを決めずに始めたPoCは、良い結果が出ても「で、次どうする?」で止まります。本番運用への移行の落とし穴はAIのPoCを本番導入まで進める方法で詳しく解説しています。

まとめ

• AI機能の検討は「何を作るか」ではなく「業務フローのどこが本当のボトルネックか」を、実測とコストの掛け算で数字として特定することから始める。
• AIに任せる判断と人に残す判断を、誤りが起きたときの責任とコストの大きさで先に切り分け、データがAIに渡せる状態か(電子化・件数・粒度)を確認する。
• 「入力が非定型」「正解データが属人化」「例外処理コストの見落とし」「現場の合意不足」は典型的な失敗パターンなので、事前に潰しておく。
• PoCの段階で成功基準・フォールバック・本番投入の判断軸・本番データでの検証期間を決めておかないと、検証で終わる。

torcheees はAI機能開発の支援を、要件整理の段階から行っています。「AIを入れたいが、どこから手をつければいいか分からない」という段階でも、業務フローの棚卸しから一緒に整理する「要件整理・開発診断」(1〜4週間)をご用意しています。まずはお問い合わせから、現状の業務フローをお聞かせください。