AI導入前に業務フローを作る理由｜PoCを失敗させない7項目
「社内にChatGPTを入れたが、使う人と使わない人が分かれた」
「AIエージェントのPoCを作ったが、何をもって成功とするか決まっていない」
「ツールの比較は進んだが、現場業務のどこへ入れるか決まらない」
AI導入の相談で起きやすいのが、この3つです。原因はAIモデルの性能だけではありません。対象業務、判断する人、例外時の対応、導入前の基準値が曖昧なまま、ツール選定から始めていることが大きな要因です。
Root onでは、AIツールを比較する前に、対象業務を一枚のフローへ整理します。この記事では、その理由と、PoC前に決める7項目を解説します。
AI導入は「チャット」から「業務」へ移っている
2026年のAI活用では、質問へ答えるチャットだけでなく、問い合わせを分類する、文書を確認する、システムへ登録する、担当者へ依頼する、といった複数工程の自動化が増えています。
しかし工程が増えるほど、AIの回答精度だけでは運用できません。
- 今どの作業まで進んでいるか
- どこで失敗したか
- 人が確認すべきか
- 同じ処理を二重実行していないか
- 誰が何を承認したか
- 結果をどの指標で評価するか
AWSも、AIエージェントを本番業務へ広げる際には、作業項目の状態管理、例外処理、人の介入、権限、ログが重要だと説明しています。PoCで一度正しく動くことと、日々の業務で安全に使い続けられることは別です。
だからこそ、最初に業務フローが必要です。
作業手順だけを書いても足りない
業務フローというと、作業を左から右へ並べた図を想像するかもしれません。しかしAI導入に使うフローには、作業順に加えて次の情報が必要です。
- 対象業務の開始と終了
- AIへ渡す入力データ
- AIが行う処理
- 人に残す判断
- 例外と失敗時の戻し先
- 結果を記録する場所
- 導入前後を比べる評価指標
図は、法人サイトの問い合わせ対応を架空データで再現した例です。問い合わせを受けると、受付担当が不足情報や営業提案を確認し、AIがテーマと緊急度を分類して回答案を作ります。ただし、顧客への送信、見積り、契約に関わる判断は人が承認します。
重要なのは、AIができることを塗るだけではありません。AIに任せない判断と、失敗時の戻し先を先に置くことです。
1. 対象業務の開始と終了を決める
「問い合わせ対応をAI化する」だけでは範囲が広すぎます。
開始を「問い合わせフォームの送信」、終了を「顧客へ初回回答し、対応履歴を記録」と定義すれば、対象範囲が明確になります。受注後の提案や契約は別業務として切り分けます。
PoCは、開始と終了を一文で言える大きさにするのが基本です。
2. 入力データを決める
AIが参照するデータを列挙します。
- 問い合わせ本文
- 会社名、連絡先
- サービス一覧
- よくある質問
- 対応履歴
- 価格・契約条件
ここで、個人情報や未公開価格を含むか、誰が更新するか、どれを正しい情報源とするかを確認します。「資料を入れれば答えられる」ではなく、正解の根拠になる資料を誰が管理するかまで決めます。
3. AIが行う処理を小さく分ける
AIに「問い合わせ対応を任せる」と指示するのではなく、処理を分けます。
- 内容を分類する
- 不足項目を検出する
- 担当候補を選ぶ
- 回答案を作る
- 根拠を提示する
処理を分けると、どこで誤ったかを確認しやすくなります。評価も「最終回答がよいか」だけでなく、分類精度、根拠の正しさ、担当選定の妥当性に分解できます。
4. 人に残す判断を決める
AI導入では、何を自動化するかより、何を自動化しないかが重要です。
たとえば次の操作は、人の承認を残す候補です。
- 顧客への送信
- 見積金額の確定
- 契約条件の提示
- 個人情報の更新
- 権限の付与・削除
- 支払い・返金
AWSの人間参加型ワークフローに関する解説でも、データベース変更など重要な操作では、人の確認を組み込む必要性が示されています。
5. 例外と失敗時の戻し先を決める
通常パターンだけでなく、例外を先に書きます。
- 情報が不足している
- 複数サービスに該当する
- 営業提案・採用・サポートが混在する
- 機密情報が含まれる
- AIが確信を持てない
- システム連携に失敗した
例外ごとに「受付担当へ戻す」「責任者へ上げる」「処理を止める」を決めます。AIが分からないまま進むより、止まり方を設計する方が本番運用では重要です。
6. 記録する場所と項目を決める
問い合わせを処理して終わりでは、改善できません。
- 受付時刻
- 分類結果
- AIの回答案
- 人の修正内容
- 承認者
- 送信時刻
- 商談化・不成立
- 例外・エラー
これらをCRM、チケット、表計算など、既存運用に合う場所へ記録します。最初から大きなシステムを作らず、PoCでは表計算で基準値と結果を残す方法もあります。
7. 導入前後を同じ指標で測る
AI導入後に「便利になった気がする」と評価しても、投資判断には使えません。導入前に基準値を取ります。
Root onでは、次の4観点で指標を考えます。
| 観点 | 指標例 |
|---|---|
| 時間 | 初回回答時間、担当者の作業時間、待ち時間 |
| 品質 | 分類精度、修正率、誤送信、手戻り |
| 収益 | 対応件数、商談化率、機会損失 |
| リスク | 情報漏洩、未承認送信、監査できない処理 |
PwCの2026年調査では、AIによるリターンは一部の先行企業へ集中しており、AI活用の数だけでなく、データ、ガバナンス、運営方法などの基盤が成果を分けるとしています。Deloitteの経営層調査でも、測定可能なROIをすでに得ている回答は一部にとどまります。
削減率を先に約束するより、何を測り、どの条件なら続けるかを決めることが現実的です。
Root onが業務フローを先に作る理由
Root onは、複数部門にまたがる業務整理、業務機能一覧、施策横断管理、AIツール比較、効果測定の支援を行ってきました。
その中で繰り返し起きたのは、システムやAIの問題に見えて、実際には次の判断が未整理だったという状況です。
- 誰の業務を変えるのか
- 現在はどの帳票・システムを使っているか
- どの条件で分岐するか
- 例外を誰が判断するか
- 新しい運用をいつ始めるか
業務フローを作ることは、きれいな図を作ることではありません。経営、現場、IT、ベンダーが同じ業務を見て、決められる状態を作ることです。
まとめ
AI導入前に決めるのは、ツール名ではなく次の7項目です。
- 開始と終了
- 入力データ
- AIが行う処理
- 人に残す判断
- 例外と戻し先
- 記録
- 評価指標
これらが決まっていれば、ツール比較、見積り、PoC、評価、本番化がつながります。決まっていなければ、高性能なモデルを使っても「試して終わり」になりやすくなります。
AI導入の対象業務を整理したい方へ
業務フロー、リスク、優先順位、90日ロードマップまで、実務に接続できる形で整理します。機密情報や実データをフォームへ入力する必要はありません。
参考資料
- AWS – Scaling agentic workflows with native case management（2026-07-10）
- AWS – AgentOps: Operationalize agentic AI at scale（2026-06-01）
- AWS – Implement human-in-the-loop confirmation with Amazon Bedrock Agents（2025-04-09）
- PwC – How leading companies generate ROI from AI（2026-05-27）
- Deloitte – CFO Insights: AI cost, risk and ROI（2026-03-19）