ストーリー
田
田中VPoE
「As-Is分析が終わり、AI×人間の協業モデルも設計した。いよいよTo-Be（あるべき姿）のプロセスを設計するフェーズだ。」
あなた
「As-IsのボトルネックをAIで解消するイメージですか？」
あ
田
田中VPoE
「単にボトルネックを解消するだけではない。AIの導入によって、プロセスそのものの判断ポイントや分岐ロジックが変わる。例えば、承認フローはAIの確信度によって動的に変わるし、例外処理の定義自体が変わるんだ。」
To-Be設計の原則
As-IsからTo-Beへの変換で守るべき原則
| 原則 | 説明 | やりがちな間違い |
|---|---|---|
| 業務目的を維持する | AIは手段であり、業務目的は変わらない | AIの機能に合わせて業務目的を変えてしまう |
| エンドツーエンドで設計 | 部分最適ではなく全体最適を目指す | 1タスクだけAI化して前後工程が非効率に |
| 判断ポイントを再設計 | AI導入で判断基準そのものが変わる | As-Isの判断ロジックをそのまま残す |
| 例外を明示的に定義 | AIが処理できない例外ケースを事前に想定 | 正常系だけ設計して例外で破綻 |
| 段階的に移行可能にする | Big Bangではなく段階的に切り替えられる設計 | 一気に切り替えてロールバック不能 |
4つの再設計パターン
パターン1: 自動化（Automation）
人間が行っていたタスクをAIに置き換える。
| 適用条件 | AI技術 | 効果 |
|---|---|---|
| 定型的な繰り返しタスク | RPA + AI-OCR | 処理速度10倍から100倍 |
| パターン認識タスク | 機械学習（分類・回帰） | 24時間稼働可能 |
| テキスト処理タスク | LLM（大規模言語モデル） | ヒューマンエラー削減 |
パターン2: 簡素化（Simplification）
不要なステップを削除し、プロセスをシンプルにする。
| 適用条件 | 手法 | 効果 |
|---|---|---|
| 承認層が多すぎる | AIリスク判定による承認層の動的変更 | 承認待ち時間の大幅削減 |
| 重複作業がある | データの一元管理 | 二重入力の排除 |
| 形骸化したチェック | AI自動チェックで代替 | 手動チェックの削減 |
パターン3: 統合（Integration）
複数の分断されたプロセスを統合する。
| 適用条件 | 手法 | 効果 |
|---|---|---|
| 部門間で同じデータを別々に処理 | データプラットフォームの統合 | データの一貫性向上 |
| 複数システムを手動で連携 | API連携 + AIオーケストレーション | 手動連携の排除 |
| 同種の業務を部門ごとに実施 | 共通AIサービスの構築 | スケールメリット |
パターン4: 並列化（Parallelization）
順次処理していた工程を並列に実行する。
| 適用条件 | 手法 | 効果 |
|---|---|---|
| 依存関係のないタスクが直列 | AIによる同時処理 | リードタイム短縮 |
| 承認が直列に並んでいる | 条件付き並列承認 | 承認時間の短縮 |
| 一括バッチ処理 | リアルタイムストリーム処理 | 待ち時間の解消 |
NetShop社 請求書処理のTo-Be設計
As-Is vs To-Be比較
| 観点 | As-Is | To-Be |
|---|---|---|
| 受領方法 | メール/郵送で手動受領 | メール自動取込 + 郵送はスキャン後取込 |
| データ変換 | 手入力（15分/件） | AI-OCR自動変換（10秒/件） |
| 照合 | 手動で画面比較 | AI自動マッチング |
| 判断ポイント | 一律で課長承認 | 金額・リスクに応じた動的承認 |
| 支払い | 週次バッチ処理 | 承認後即時処理（日次バッチ） |
| 所要時間 | 5.2日 | 目標: 1.5日 |
To-Beプロセスフロー
[レーン: AIシステム]
(開始) → [メール自動監視・PDF取得]
→ [AI-OCR: 請求書データ抽出]
→ <OCR確信度チェック>
+-- 95%以上 → [自動データ登録]
+-- 95%未満 → [人間確認キュー]
→ [AI: 発注書自動照合]
→ <照合結果>
+-- 完全一致 → [照合完了]
+-- 軽微な差異（金額差5%以内） → [差異フラグ + 自動続行]
+-- 重大な不一致 → [人間確認キュー]
→ <動的承認判断>
+-- 5万円未満 + 照合一致 + 既存取引先 → [自動承認]
+-- 5万円から10万円 → [担当者承認]
+-- 10万円から100万円 → [課長承認]
+-- 100万円以上 → [部長承認]
→ [日次バッチ支払い処理]
→ (終了)
[レーン: 経理担当]
[人間確認キュー] → [OCR結果の確認・修正]
or [照合不一致の調査・修正]
→ [修正結果をAIにフィードバック]
[レーン: 経理課長]
[承認依頼通知] → [ダッシュボードで一覧確認]
→ [承認 / 差し戻し]
[レーン: 財務部長]
[高額案件の承認依頼] → [承認 / 差し戻し]判断ポイントの再設計
| 判断ポイント | As-Is | To-Be | 変更理由 |
|---|---|---|---|
| OCR確認要否 | 全件手入力 | 確信度95%以上は自動、未満は人間確認 | AI-OCR精度に基づく効率化 |
| 照合判断 | 全件手動 | 完全一致は自動、差異5%以内はフラグ | AIマッチングの活用 |
| 承認判断 | 全件課長承認 | 金額とリスクで動的にルーティング | 承認ボトルネックの解消 |
| 支払いタイミング | 週次バッチ | 日次バッチ（将来は即時） | 支払い遅延の解消 |
NetShop社 問い合わせ対応のTo-Be設計
To-Beプロセスフロー
[レーン: 顧客]
(開始: 問い合わせ) → <チャネル>
+-- チャット → [AIチャットボット応答]
+-- メール → [AI自動分類 + ドラフト作成]
+-- 電話 → [音声認識 + リアルタイムAI支援]
[レーン: AIシステム]
[問い合わせ内容のNLP分析]
→ [カテゴリ自動分類]
→ [感情分析]
→ <自動回答可能?>
+-- はい（FAQ一致度80%以上 + 感情スコア低）→ [AI自動回答]
| → <顧客満足?>
| +-- はい → [対応記録自動生成] → (終了)
| +-- いいえ → [人間にエスカレーション]
+-- いいえ → [人間にルーティング（スキルベース）]
[レーン: 一次対応]
[AI支援画面表示]
- 顧客情報サマリー
- 過去の対応履歴
- 推奨回答候補3つ
- 関連FAQリンク
→ [人間が回答作成（AIドラフトを編集可）]
→ [対応記録自動生成]
→ (終了)
[レーン: 二次対応]
[エスカレーション受付]
→ [AI: 関連情報の自動収集]
→ [専門対応]
→ [対応記録自動生成]
→ (終了)複合パターンの適用効果
請求書処理への4パターン適用:
1. 自動化: AI-OCRによるデータ変換の自動化
2. 簡素化: 低リスク案件の自動承認で承認ステップ削減
3. 統合: 発注システムとの自動連携で照合工程を統合
4. 並列化: OCRと照合の並列実行でリードタイム短縮
結果:
処理時間: 5.2日 → 1.5日（71%削減）
人件費: 年間4,550万円の損失 → 推定600万円に削減
品質: 照合ミス率 25% → 目標5%以下まとめ
| 項目 | ポイント |
|---|---|
| To-Be設計原則 | 業務目的維持、エンドツーエンド、判断ポイント再設計、例外定義、段階的移行 |
| 4つの再設計パターン | 自動化、簡素化、統合、並列化を組み合わせて適用 |
| 請求書処理 | AI-OCR、自動照合、動的承認、日次バッチで5.2日から1.5日へ |
| 問い合わせ対応 | AIチャットボット、感情分析、スキルベースルーティング |
チェックリスト
- To-Be設計の5つの原則を理解した
- 4つの再設計パターンの特徴と適用条件を説明できる
- As-IsとTo-Beの比較表を作成できる
- AI導入による判断ポイントの再設計ができる
次のステップへ
次は「AIワークフロー設計」として、AIの処理フローの具体的な設計手法を学ぼう。
推定読了時間: 30分