AIを既存業務へ足すだけでは、なぜ成果が出ないのか？人間・AI・システムで業務フローを再設計する9つの視点
AIを導入すると、一つひとつの作業は確かに速くなります。
会議録の初稿が数分でできる。問い合わせを分類できる。調査結果を要約できる。報告書や提案書の下書きも短時間で作れる。
ところが、しばらく運用すると、別の違和感が出てきます。
AIが作った内容を人がすべて確認する。別のシステムへ転記する。上司の承認を待つ。メールやチャットで共有する。次の会議で、改めて進捗を確認する。
AIを使う工程は速くなったのに、依頼が発生してから仕事が完了するまでの時間は、それほど短くなっていない。
これは、AIの性能が低いからとは限りません。
既存業務の一工程へAIを追加しただけで、その前後にある待ち時間、重複入力、引き継ぎ、判断、承認、例外処理が残っている可能性があります。
フェーズ8では、一つの繰り返し業務を標準化し、人間確認付きで半自動化しました。
フェーズ9では、さらに視野を広げます。
AIを既存工程へ挿入するのではなく、顧客や利用者へ価値が届くまでの流れ全体を、人間・AI・既存システムの役割から組み直します。
今回は、AI活用成熟度12フェーズのフェーズ9「AI前提の業務フロー再設計」として、部分的な効率化を業務全体の成果へつなげる方法を整理します。
AI活用成熟度12フェーズの記事一覧
フェーズ8で個別業務を安定させた次は、前後の流れを組み直す
フェーズ8では、繰り返し業務を次のように整えました。
必要な入力を決める
作業と判断を分ける
AIと人間の担当範囲を決める
標準出力と完了条件を定義する
例外、停止、手動復帰を設計する
別担当者でも再現できるか試す
これにより、一つの仕事を一定品質で繰り返せるようになります。
しかし、個別業務が安定すると、前後にある別の問題が見え始めます。
例えば、会議録からタスク候補を抽出する業務を半自動化したとします。抽出作業は速くなりました。しかし、その前後には次が残っているかもしれません。
会議前に必要な情報が集まっていない
会議中に過去の経緯を確認する時間が長い
会議後に複数人が同じタスクを登録する
議事録、メール、タスク台帳へ同じ内容を転記する
担当者の承認待ちで登録が止まる
未完了タスクが次回まで追跡されない
次の会議で全件を再び口頭確認する
この状態では、会議録の作成時間だけを短くしても、会議業務全体の成果は大きく変わりません。
フェーズ8が「一つの仕事を安定させる段階」なら、フェーズ9は「仕事同士のつながりを価値から組み直す段階」です。
一方、設計した業務フローをAPI、MCP、エージェント、データベース、権限管理などで安全に動かすのは、次のフェーズ10です。
フェーズ9では、まず「どのように働くべきか」を確定します。
フェーズ9は、AIを使う工程を増やす段階ではない
AI前提の業務フロー再設計と聞くと、多くの工程へAIを導入する話に見えるかもしれません。
しかし、フェーズ9の中心は、AIの利用箇所を増やすことではありません。
依頼や問題が発生してから、顧客や利用者へ価値が届くまでの流れを見直すことです。
AIを追加するだけでは、既存の制約も残る
典型的なのは、既存フローの一部だけをAIへ置き換える方法です。
依頼を受ける
→ 担当者が情報を整理する
→ AIが下書きを作る
→ 担当者が全面確認する
→ 別システムへ転記する
→ 上司が承認する
→ メールで共有する
→ 完了AIによって下書き時間は短くなります。
しかし、情報整理、全面確認、転記、承認待ち、共有は変わっていません。場合によっては、AI出力を確認する工程が追加され、以前より作業が増えることもあります。
一つの工程の高速化と、全体リードタイムの短縮は違う
業務改善を評価するときは、「AI処理に何分かかったか」だけを見てはいけません。
見るべきなのは、依頼発生から完了までの総時間です。
例えば、下書き作成が120分から10分になっても、その後の承認に3日かかるなら、顧客が受け取るまでの時間はほとんど変わりません。
反対に、AIの処理時間がそれほど短くならなくても、必要情報を最初にそろえ、判断の重複や差し戻しを減らせれば、全体のリードタイムは短くなる可能性があります。
業務フロー再設計は、すべてを作り直すことでもない
「再設計」という言葉から、大規模なシステム刷新や組織変更を想像する必要はありません。
既存の有効な手順や統制まで捨てる必要はありません。まずは次のような変更から始められます。
同じ情報を一度だけ入力する
会議前に未完了事項を集約する
AIには候補だけを作らせる
人間確認を重要判断へ限定する
承認不要な低リスク案件を分ける
例外案件だけ専門担当者へ送る
次工程がそのまま使える形式で出力する
変更すべきなのは、価値を生まない工程や、AI導入によって役割が重複した部分です。
AI前提とは、AIへすべて任せることではない
AI前提の業務とは、AIが自律的にすべてを処理する業務ではありません。
AIの得意な作業を前提に、人間とシステムの役割も再定義する業務です。
例えば、AIが大量の情報を整理できるなら、人間は資料を一から読むのではなく、判断が必要な差分や例外を確認できます。
AIが候補を抽出できるなら、既存システムは確定した情報と処理状態を保持できます。
人間は、目的、優先順位、採否、例外、責任を担います。
AIの仕事を増やすのではなく、AIが使えることによって、人間とシステムの仕事も変える。
これがフェーズ9の意味です。
最初に「この業務は何の価値を届けるのか」を決める
業務フローを描く前に、最初に確認すべきことがあります。
この業務は、誰のどの状態を変えるために存在するのか。
ここが曖昧なままでは、どの工程を削り、どの工程を残すべきか判断できません。
帳票や会議ではなく、利用者の状態変化から考える
「議事録を作る」「週次会議を開く」「報告書を提出する」は、業務上の活動です。それ自体が最終目的とは限りません。
例えば会議業務の目的は、次のように考えられます。
必要な意思決定を行う
課題と責任者を明確にする
未完了事項を追跡する
リスクを早期に発見する
次の行動を開始できる状態にする
この目的から考えると、読みやすい長文の議事録を作ることより、決定、担当、期限、未解決事項を正確に確定する方が重要かもしれません。
業務目的が曖昧なままでは、不要工程を判断できない
ある帳票が必要かどうかは、その帳票が存在するかではなく、後工程でどう使われているかで判断します。
次を確認します。
誰が読むのか
読んだ後に何を判断するのか
その判断に全項目が必要か
別のシステムに同じ情報がないか
保存義務や監査上の要件があるか
作成されなくなった場合、誰が困るか
「以前から作っている」「上司へ送っている」という理由だけでは、工程を残す根拠として弱い場合があります。
内部効率と、顧客・現場への価値を分ける
AI導入で社内作業が短くなっても、顧客への回答が遅いままなら、顧客価値は改善していません。
反対に、顧客対応が速くなっても、現場の確認負担や事故リスクが増えているなら、持続可能な改善とはいえません。
業務フロー再設計では、少なくとも次を分けます。
顧客・利用者へ届く価値
現場担当者の負担
管理者の監督負担
品質・安全性
コスト
処理速度
一つの指標だけを改善すると、別の場所へ負担が移る可能性があります。
AI利用を目的や最終KPIにしない
AI利用率、生成回数、エージェント実行数は、活動量を示す指標にはなります。
しかし、業務成果そのものではありません。
AIを使わずに不要工程を廃止した方が効果的なら、そちらを選ぶべきです。
フェーズ9で問うのは、「どこへAIを入れるか」ではなく、**「どうすれば価値が短く、正確に、持続可能な形で届くか」**です。
As-Isでは、作業だけでなく待ち時間と引き継ぎを可視化する
現在の業務、つまりAs-Isを描くとき、多くの場合は作業工程だけが記録されます。
しかし、実際のリードタイムを長くしているのは、作業より待ち時間や引き継ぎかもしれません。
開始点と終了点を決めなければ、部分最適になる
「報告書作成業務」を改善するとしても、開始点と終了点によって対象は変わります。
開始点の候補は複数あります。
担当者が作成を始めた時点
必要データがそろった時点
顧客から依頼を受けた時点
前工程が完了した時点
終了点も同様です。
下書きが完成した時点
上司が承認した時点
顧客へ送信した時点
顧客が内容を利用できた時点
作成開始から下書き完成だけを見ると、AIによる改善効果は大きく見えます。
依頼発生から顧客利用までを見ると、別のボトルネックが見える可能性があります。
作業・判断・待ち・引き継ぎを分けて記録する
As-Isでは、工程を最低でも次の4種類へ分けます。
作業：入力、作成、分類、転記、登録
判断：採否、優先順位、承認、例外判定
待ち：情報待ち、承認待ち、システム待ち
引き継ぎ：担当者・部門・システム間の受け渡し
すべてを同じ四角形で描くと、どこが問題なのか分かりにくくなります。
実作業は合計2時間でも、承認待ちが2日、追加情報待ちが1日なら、改善対象は作業速度だけではありません。
重複入力、転記、差し戻し、会議を数える
AI導入後も残りやすい非効率は次です。
同じ顧客情報を複数システムへ入力する
AI出力を別の帳票へ貼り付ける
担当者と管理者が同じ内容を確認する
資料、チャット、メールで同じ報告をする
不足情報のために差し戻す
状況確認だけの会議を開く
一回ごとの負担が小さく見えても、件数が多ければ全体へ大きく影響します。
公式手順と実際の運用を分ける
規程やマニュアル上の手順と、現場の実際の手順が違うことがあります。
現場が勝手にルールを破っているとは限りません。正式手順が現実に合わず、補助的な表計算、チャット、個人メモで不足を補っている可能性があります。
As-Isでは、公式フローだけでなく、実際に使っている次のものも確認します。
個人管理表
手作業の転記
非公式な承認
チャット上の確認
口頭での例外処理
担当者だけが知っている復旧方法
これらを無視してTo-Beを作ると、新しい業務でも同じ非公式運用が再発します。
正常ルートだけでなく例外ルートも描く
正常な入力が届き、AIが正しく処理し、承認者がすぐ反応する場合だけを描いても、現場では使えません。
少なくとも次を確認します。
必須情報が不足している
入力同士が矛盾している
AIの出力を確定できない
担当者や承認者が不在
承認期限を超えた
外部システムが停止している
権限が不足している
処理途中で要件が変わった
誤登録を取り消す必要がある
例外ルートは、正常ルートの補足ではありません。
現実の業務フローを構成する正式な一部です。
不要工程をAI化せず、削除・統合・簡略化する
As-Isが見えたら、すぐに各工程へAIや自動化ツールを割り当てるのではありません。
先に、工程自体が必要かを確認します。
「今あるから必要」と考えない
既存工程には、過去のシステム制約や組織構造に合わせて作られたものがあります。
以前は必要でも、現在は別の方法で目的を満たせるかもしれません。
確認する問いは次です。
この工程は何を防いでいるか
この工程がなければ何が起きるか
後工程で本当に使われているか
法令、契約、監査上の要件か
AIや既存システムで別の形へ代替できるか
前後工程と統合できるか
目的を説明できない工程を、そのままAI化してはいけません。
AI出力と既存帳票が重複していないか確認する
AIによる要約や分析を追加した後も、従来の報告書を同じ形式で作り続けるケースがあります。
結果として、次の二重作業になります。
AI向けの入力を準備する
AI出力を確認する
従来帳票へ転記する
従来どおりメールで報告する
AI出力が後工程で使えるなら、従来帳票を削除または簡略化できないか検討します。
一方、法的保存、監査、顧客要件がある帳票は、単に不要と判断してはいけません。
後工程で使われていない情報を作らない
資料に多くの項目があっても、実際の意思決定で使われているのは一部かもしれません。
各項目について確認します。
誰が使うか
何の判断に使うか
入力しない場合の影響
別の情報から取得できないか
更新頻度は適切か
使われない情報をAIで効率よく作ることに、大きな価値はありません。
承認は目的とリスクから必要性を再判定する
承認には、誤りや不正を防ぐ役割があります。
しかし、過去の事故や責任分担を理由に承認が増え続けると、業務が止まります。
各承認について次を確認します。
何を判断する承認か
どのリスクを抑えるか
承認者だけが持つ情報や権限は何か
低リスク案件にも同じ承認が必要か
事後監査へ移せないか
同じ内容を複数人が承認していないか
承認を減らすこと自体が目的ではありません。
影響が大きく、後から戻しにくい判断へ承認を集中させることが目的です。
まとめ処理とリアルタイム処理を使い分ける
すべてを発生直後に処理する必要はありません。
低緊急度の分類や集計は、一定時間ごとにまとめて処理した方が効率的な場合があります。
一方、事故、顧客解約、セキュリティ問題などは、リアルタイムに近い検知が必要かもしれません。
処理方式は、AIの能力ではなく次で決めます。
緊急性
件数
必要な最新性
処理コスト
承認者の対応可能時間
失敗時の影響
AI・人間・既存システムへ役割を再配置する
不要工程を減らしたら、残った仕事をAI、人間、既存システムへ再配置します。
ここでは「どれが一番優れているか」ではなく、それぞれが何を安定して担えるかを見ます。
フェーズ9で確認する視点は、次の9つです。
提供価値・目的
開始点・終了点
作業・判断・待ち・引き継ぎ
不要工程・重複・手戻り
AI・人間・既存システム
情報・中間成果物・状態
順次・並列・条件分岐
承認・例外・復旧
KPI・ガードレール・撤退条件
これは成熟度を点数化する9段階ではありません。
一つの業務フローを設計するときに、行き来しながら確認する9つの視点です。
AIは、曖昧な情報の整理・候補化・変換を担う
AIが支援しやすいのは、次のような作業です。
非構造化文章から項目を抽出する
内容を分類する
複数資料を要約する
指定形式へ変換する
下書きや候補を作る
矛盾や不足候補を示す
例外の可能性を知らせる
ただし、候補を確定事項として扱わない設計が必要です。
AIが出した情報には、状態を付けます。
候補
未確認
要確認
承認済み
却下
対象外
既存システムは、確定情報・権限・状態を保持する
AIとの会話履歴だけを、業務の正式記録として扱うべきではありません。
確定した顧客情報、契約、支払い、タスク、承認状態などは、正式な業務システムや台帳で保持します。
既存システムが担う代表的な役割は次です。
正式データの保存
一意なID
権限管理
処理状態
更新履歴
検索
他工程との接続
AIは情報を整理できますが、どの情報が正式かを保持する仕組みは別に必要です。
人間は、目的、例外、採否、責任を担う
人間が保持する代表的な役割は次です。
何を達成するか決める
判断基準を設定する
例外を解釈する
相反する価値を比較する
AIの候補を採用・却下する
外部影響を伴う操作を承認する
失敗時に停止・復旧を判断する
結果に責任を持つ
すべての人間作業を残すという意味ではありません。
人間に残すべきなのは、AIが処理した結果を一から再作成する仕事ではなく、目的と影響に関わる判断です。
同じ判断を複数人が繰り返さない
複数の担当者が、同じ情報を別々に確認していることがあります。
二重確認が必要な高リスク業務もありますが、単なる責任回避で承認が重なっている場合もあります。
各判断について次を決めます。
誰が判断するか
判断に必要な情報は何か
誰へ結果を共有するか
再判断が必要になる条件は何か
代理承認者は誰か
判断者と情報が明確なら、不要な確認の往復を減らせます。
一人の人間や一つのAIへ業務全体を集中させない
業務全体を一つのAIエージェントへ任せれば、簡単に見えます。
しかし、目的の違う工程、異なる権限、高リスク操作を一つへ集中させると、失敗原因や責任境界が見えにくくなります。
人間についても同じです。
一人の熟練者だけがすべての例外を処理する設計は、属人化と滞留を生みます。
役割は、業務上の責任と必要能力に応じて分けます。
業務の依存関係に応じて、処理の組み方を選ぶ
業務フローは、すべてを一列に並べる必要はありません。
工程間の依存関係、リスク、必要な判断によって処理の組み方を変えます。
ここでは実務上よく使う代表例として、次の5パターンに整理します。
順次処理
並列処理
条件分岐
人間介入
反復・改善ループ
これは網羅的な公式分類ではありません。
業務設計時に、処理の依存関係を考えやすくするための実務整理です。
前工程の結果が必要なら順次処理にする
後工程が前工程の確定結果を必要とする場合は、順番に処理します。
契約条件の確認
→ 請求条件の確定
→ 請求書作成
→ 送付承認契約条件が確定していない状態で請求書を作れば、後から手戻りが発生します。
すべてを並列化すれば速くなるわけではありません。
独立して進められる作業は並列化する
複数の作業が互いの結果を必要としないなら、同時に進められます。
例えば、提案準備で次を並列化できます。
顧客情報の整理
市場情報の調査
過去案件の検索
リスク候補の抽出
最後に結果を統合し、人間が判断します。
並列化によって時間を短くできますが、統合時に重複や矛盾を処理する必要があります。
入力・リスク・信頼度によってルートを分ける
すべての案件を同じルートへ流す必要はありません。
例えば問い合わせ対応なら、次のように分けられます。
低リスク・FAQ一致
→ 回答案作成
→ 簡易確認
→ 送信
重要顧客・補償関連
→ 管理者確認
→ 個別回答
法務・安全・個人情報
→ 専門担当者へ分岐条件は、AIの感覚だけに任せず、できる限り説明可能な条件にします。
人間介入は、判断内容と待機状態まで設計する
人間の入力が必要なとき、ワークフローは失敗したわけではありません。
「承認待ち」「追加情報待ち」といった状態です。
Microsoftの承認ワークフローでも、承認要求後は承認者の応答まで処理を待機させます。人間介入を含むAIワークフローでも、承認や追加質問を明示的な処理として設計できます。
業務設計では次を決めます。
誰の入力を待つか
何を判断してもらうか
必要資料は何か
回答期限
期限超過時の処理
代理担当者
承認、差し戻し、中止の次ルート
「人間が確認する」とだけ書くのでは不十分です。
反復ループには終了条件を置く
AIへ「十分な品質になるまで改善する」と指示すると、処理が終わらない可能性があります。
Google Cloudの公式設計資料でも、ループ型の処理は終了条件が適切でなければ無限に実行されるリスクがあると説明されています。
反復処理には次を決めます。
最大回数
合格条件
改善が止まった場合の処理
コスト上限
時間上限
人間へ渡す条件
「納得するまで」ではなく、観察可能な終了条件が必要です。
情報と中間成果物を設計すると、引き継ぎが安定する
業務フローは、担当者やシステムを矢印でつなぐだけでは動きません。
工程間で何を受け渡すかを決める必要があります。
会話履歴だけを状態管理に使わない
AIとの会話には、途中の検討、誤った案、撤回された条件も含まれます。
会話履歴だけでは、何が正式に確定したか分からなくなります。
次を別に保持します。
現在の処理状態
確定した入力
未確認事項
承認結果
差し戻し理由
次の担当者
完了条件
更新日時
会話は検討の記録として使えますが、正式状態の原本とは分けます。
中間成果物は、次工程が使える形式にする
前工程が読みやすい文章を作っても、次工程で再度情報を抽出する必要があれば効率的ではありません。
中間成果物には、次工程が必要とする項目を含めます。
例えば、問い合わせ分類の出力なら次です。
問い合わせID
顧客
分類候補
リスク区分
根拠
不足情報
推奨ルート
現在状態
人間向けの説明と、次のシステムが使う構造化情報を分ける場合もあります。
未確定・承認済み・差し戻しを区別する
同じ項目でも状態が違います。
AIが抽出した候補
担当者が確認した内容
管理者が承認した内容
後から撤回された内容
これらを一つの項目へ上書きすると、どの時点で何が正しかったか追えません。
業務上必要な状態を定義し、遷移条件を決めます。
一つの情報を複数システムで別々に更新しない
顧客名、担当者、期限などを複数の台帳で個別更新すると、不一致が起きます。
どの情報をどこで正式管理するかを決めます。
他の成果物は正式情報を参照して作ります。
フェーズ6で扱ったSource of Truthを、業務フローの状態管理へ接続する考え方です。
誰がいつ何を変更したか追えるようにする
重要な業務では、最終結果だけでなく変更履歴が必要です。
最低限、次を確認できるようにします。
誰が変更したか
いつ変更したか
何を変更したか
変更前は何だったか
変更理由
どの承認に基づくか
ログやトレースの技術的な実装はフェーズ10、継続的な監査と評価はフェーズ11で扱います。
フェーズ9では、業務要件として何を記録すべきかを決めます。
承認・例外・復旧は、通常ルートと同じ重要度で設計する
業務フローの図は、正常ルートだけを中央に描き、例外を小さな注記へ追いやりがちです。
しかし実務では、承認待ち、入力不足、システム障害が多くの時間を占めます。
承認待ちを正式な業務状態として扱う
「担当者へ確認中」という状態を、チャットや口頭だけで管理してはいけません。
次を記録します。
承認対象
承認者
依頼日時
回答期限
現在状態
差し戻し理由
次の工程
これにより、どこで業務が止まっているか把握できます。
承認地点は、影響が大きく戻しにくい場所へ置く
すべての工程に承認を置けば安全になるわけではありません。
承認者が内容を十分に確認せず、形式的に通す可能性もあります。
承認は、次のような地点へ集中させます。
顧客・外部への送信前
金銭・契約の確定前
個人へ重大な影響を与える処理前
取り消しにくい変更前
例外ルートへ移る判断時
低リスクで修正可能な中間処理は、サンプル監査や事後確認へ移せる場合があります。
人間監督が必要な箇所は一律に決めず、利用文脈、影響、既知の限界、リスクと結びつけて設計する必要があります。
例外は通常フローへ押し込まず、別ルートへ送る
例外を通常ルールの追加分岐として増やし続けると、フローが読めなくなります。
例外は分類して、適切な担当へ渡します。
入力不足
情報矛盾
高リスク
標準対象外
判断不能
権限不足
システム障害
重複処理の疑い
例外ごとに、処理を止めるのか、情報を補うのか、専門担当者へ送るのかを決めます。
エスカレーション先と期限を決める
「分からなければ上司へ確認する」だけでは、誰にいつまでに依頼するか不明です。
エスカレーションでは次を定義します。
条件
送付先
必要情報
回答期限
代理担当者
期限超過時の処理
最終責任者
例外ルートにも完了条件が必要です。
失敗時にどの地点まで戻るか決める
処理途中で失敗したとき、最初からやり直す必要があるとは限りません。
例えばAI抽出後の登録だけが失敗したなら、承認済み情報を再利用できる可能性があります。
業務要件として次を決めます。
最後に確定した状態
再開可能な地点
再確認が必要な情報
再実行してはいけない操作
二重送信・二重登録を防ぐ確認
チェックポイント、冪等性、再試行の技術実装はフェーズ10で扱います。
旧フローへ戻す条件を用意する
新しいTo-Beフローが常に使えるとは限りません。
次の場合に、手動または旧フローへ戻す条件を決めます。
AIや連携システムが利用できない
品質が下限を下回った
重大インシデントが発生した
例外率が想定を超えた
処理滞留が増えた
現場の負担が許容範囲を超えた
ロールバックは失敗を認める行為ではありません。
業務を継続するための正式な安全策です。
KPIは処理件数ではなく、価値・速度・品質・負担を測る
業務フローを変更したら、成果を測ります。
AI利用件数だけでは、業務改善の成否を判断できません。
総リードタイムと待ち時間を分ける
総リードタイムは、依頼発生から完了までの時間です。
その中を次に分けます。
実作業時間
AI処理時間
人間作業時間
承認待ち
情報待ち
システム待ち
差し戻しによる手戻り
AI処理時間が短くても、待ち時間が増えていれば全体は改善しません。
品質と例外を別々に測る
正常案件の品質が高くても、例外案件で重大な失敗が起きる可能性があります。
次を分けて確認します。
必須項目の欠落率
誤分類率
訂正率
差し戻し率
例外率
例外の未処理件数
外部送信後の訂正数
重大インシデント
平均値だけで重大な少数事例を隠さないことが重要です。
現場負担と顧客影響をガードレールにする
処理件数が増えても、現場の確認負担が過大になれば運用は続きません。
また、速度が上がっても顧客への誤回答が増えれば成功ではありません。
ガードレールとして次を置きます。
人間確認時間の上限
残業や作業集中の増加
誤送信・誤登録
顧客からの訂正要求
プライバシー・機密事故
従業員の心理的負担
手動復帰の頻度
KPI改善とガードレール悪化が同時に起きたら止める
処理速度が改善しても、重大な誤りや現場負担が増えていれば、継続すべきとは限りません。
パイロット前に次を決めます。
成功条件
修正条件
一時停止条件
撤退条件
再開条件
評価結果に応じて設計を変更できるようにします。
ケース：会議から改善チケットまでの流れをAI前提で再設計する
フェーズ8では、「会議録からタスク台帳への反映」を半自動化しました。
今回は、その前後を含めて会議業務全体を見直します。
As-Isでは、会議の前後で情報が分散する
従来の流れは次のようになりがちです。
各自が資料を準備
→ 会議中に状況を口頭報告
→ 参加者が個別にメモ
→ 担当者が議事録を作成
→ メールやチャットで共有
→ 各自がタスクを登録
→ 進捗が複数場所へ分散
→ 次回会議で再度口頭確認この流れには、複数の問題があります。
会議中に事実確認へ時間を使う
同じ情報を複数人が記録する
議事録とタスクが分離する
タスク登録が担当者任せになる
期限超過を会議まで発見できない
次回会議で過去の内容を再説明する
フェーズ8では、会議後の一工程を安定させた
フェーズ8での改善は次です。
文字起こし
→ AIが決定・課題・担当・期限候補を抽出
→ 人間が確認
→ 承認済み情報だけをタスク台帳へ登録これにより、会議後の記録と登録は安定します。
しかし、会議前の準備や、登録後の追跡はまだ別です。
To-Beでは、会議前から次回までを一つの流れにする
AI前提で再設計すると、次のようになります。
会議前
未完了タスク・進捗・期限超過・指標・課題を集約
↓
会議の議題候補を作成
↓
人間が議題と優先順位を決定
↓
会議中
事実報告ではなく、判断が必要な論点へ集中
↓
会議後
AIが決定・未決・課題・担当・期限候補を抽出
↓
人間が決定内容、担当、期限、共有範囲を承認
↓
確定情報を正式台帳へ一度だけ登録
↓
未完了タスクを継続追跡
↓
遅延・例外・繰り返し問題を改善チケット化
↓
次回会議では前回との差分と判断事項だけを確認再設計によって削除・変更する工程
このTo-Beでは、次を見直します。
各自の個別メモを正式記録にしない
会議で全件の進捗を口頭報告しない
議事録全文の表現修正へ過剰な時間を使わない
メール共有とタスク登録を別工程にしない
同じ内容を複数の台帳へ入力しない
次回会議で全タスクを一から読み上げない
削除するのは、記録や確認そのものではありません。
価値につながらない重複です。
AI・人間・システムの役割を分ける
AIは次を担います。
未完了情報の集約
期限超過・停滞候補の抽出
議題候補の作成
会議内容の構造化
タスク候補の抽出
例外・繰り返し問題の検出
人間は次を担います。
会議の目的
議題と優先順位
正式な決定
担当と期限
例外判断
公開範囲
施策の継続・中止
正式システムは次を担います。
確定タスクの保存
状態管理
担当・期限
更新履歴
通知
検索
ダッシュボード
例外は確認待ちへ分ける
次は自動登録しません。
決定か提案か不明
担当者が未定
期限が曖昧
複数の発言が矛盾している
機密情報を含む
既存タスクと重複している
権限が不足している
重大なリスクを含む
確認待ちのまま放置せず、担当者と期限を付けます。
KPIとガードレールを分ける
このTo-Beでは、次を測ります。
会議時間
状況報告に使った時間
判断に使った時間
会議後の記録時間
タスク登録までの時間
担当・期限の欠落率
未完了タスクの滞留
重複タスク
次回会議での再説明時間
参加者の準備負担
一方、次をガードレールにします。
誤った決定事項の登録
未承認タスクの外部共有
機密情報の誤共有
過剰な通知
AI確認作業の増加
会議外での作業負担増加
実務テンプレート：AI前提の業務フロー再設計キャンバス
一つの部門横断業務を選び、次のキャンバスを埋めてみてください。
業務名：
1. 提供価値
対象者：
現在の課題：
届ける状態変化：
価値が届いたと判断する条件：
2. 対象範囲
開始点：
終了点：
対象外：
前工程：
後工程：
3. As-Is
現在の工程：
各工程の担当者：
使用システム：
入力：
出力：
判断：
待ち時間：
引き継ぎ：
重複入力：
差し戻し：
例外：
非公式な運用：
4. 現在の問題
主要ボトルネック：
不要工程：
情報不足：
判断の重複：
責任の曖昧さ：
現場負担：
顧客への影響：
リスク：
5. 削除・統合・簡略化
削除する工程：
統合する工程：
簡略化する工程：
維持する工程：
維持する理由：
6. To-Beの役割分担
AI：
人間：
既存システム：
専門担当者：
運用責任者：
最終責任者：
7. 処理パターン
順次処理：
並列処理：
条件分岐：
人間介入：
反復処理：
バッチ処理：
リアルタイム処理：
8. 情報と中間成果物
標準入力：
中間成果物：
次工程が必要とする項目：
正式な情報源：
未確定情報：
根拠：
保存先：
9. 状態
未着手：
処理中：
追加情報待ち：
承認待ち：
差し戻し：
承認済み：
完了：
中止：
再開：
10. 承認
承認対象：
承認者：
判断基準：
必要資料：
承認期限：
代理承認者：
差し戻し先：
承認不要条件：
11. 例外・エスカレーション
想定例外：
検知条件：
処理を止める条件：
エスカレーション先：
回答期限：
期限超過時の処理：
専門確認が必要な条件：
12. 復旧
最後に確定した状態：
再開地点：
再実行できる工程：
再実行してはいけない操作：
手動復帰：
旧フローへ戻す条件：
13. KPI
総リードタイム：
実作業時間：
待ち時間：
引き継ぎ回数：
重複入力数：
差し戻し率：
例外率：
最終品質：
顧客価値：
現場負担：
コスト：
14. ガードレール
許容しない事故：
品質下限：
負担上限：
コスト上限：
滞留上限：
一時停止条件：
撤退条件：
15. パイロット
対象範囲：
対象者：
期間：
比較対象：
正常ケース：
例外ケース：
成功条件：
修正条件：
一時停止条件：
撤退条件：
運用改善責任者：最初から全社業務を対象にする必要はありません。
一つの部門横断フロー、または一つの顧客接点から始めます。
AI前提の業務再設計が適さない場合もある
AI前提の再設計は、すべての業務で実施すべきものではありません。
業務量が少なく、変更コストが効果を上回る
低頻度で、現在の手順でも大きな問題がないなら、詳細なTo-Beを作るコストが見合わない場合があります。
業務の目的や責任者が定まっていない
何を改善する業務か、誰が最終責任を持つかが曖昧な状態で、AIワークフローを作るべきではありません。
技術を導入しても、判断の対立や責任の空白は解消しません。
既存システムの制約が強く、接続コストが高い
理想的なTo-Beが描けても、基幹システムや契約上の制約によって実現できないことがあります。
手作業をすべて悪いとみなさず、投資対効果から段階的な案を作ります。
正常ルートより例外ルートが多い
ほぼすべての案件で個別判断が必要なら、固定的なワークフローを複雑化するより、情報整理や判断支援だけにAIを使う方が適切かもしれません。
現場が新しい運用を保持できない
To-Beが論理的でも、入力負担、教育、問い合わせ対応、保守が現場の能力を超える場合は定着しません。
設計時に運用担当者を参加させ、小規模なパイロットで確認します。
重要データへ安全にアクセスできない
必要な情報を取得できない、または権限・プライバシー上の問題が解決していない場合、AIを組み込む前に情報管理を整える必要があります。
改善効果を測れない
導入前の時間、品質、例外、負担が分からなければ、変更後の効果を判断できません。
最低限の基準値を取得してから始めます。
一時的な製品機能だけを理由にしている
新しいAI機能が利用できることと、その機能が業務課題を解決することは別です。
製品が変わっても残る業務目的、判断基準、情報、責任を先に設計します。
フェーズ9の到達条件
次を満たせれば、フェーズ9の実践が進んでいると判断できます。
業務が届ける価値を説明できる
開始点と終了点が明確である
As-Isが現場の実態に基づいている
作業、判断、待ち、引き継ぎを区別している
正常ルートと例外ルートが見える
不要工程、重複、手戻りを削減している
AI、人間、既存システムの役割が明確である
中間成果物と正式な情報源を定義している
業務状態と状態遷移を定義している
順次、並列、条件分岐、人間介入を使い分けている
承認、例外、エスカレーションを設計している
停止、再開、手動復帰の条件がある
KPIとガードレールがある
限定範囲でパイロットしている
現場で継続運用できる
継続、修正、一時停止、撤退を判断できる
運用改善の責任者が決まっている
最も重要なのは、図として美しいTo-Beを作ることではありません。
現場で実際に動き、問題が起きたときに止まり、直し、続けられることです。
次フェーズでは、設計したフローを安全に動かす実行基盤を作る
フェーズ9では、業務の目的、工程、役割、情報、状態、承認、例外を設計しました。
次に必要になるのは、このフローを実際に動かす仕組みです。
どのモデルを使うか
どの情報を渡すか
どのツールへ接続するか
APIやMCPをどう使うか
どの状態を保存するか
どの権限を与えるか
どこで人間承認を要求するか
失敗をどう検知するか
どこから再開するか
テスト環境と本番環境をどう分けるか
これがフェーズ10「AI実行基盤・ハーネス設計」です。
順序は重要です。
技術基盤を先に作り、その機能へ業務を合わせるのではありません。
先に価値が届く業務フローを設計し、そのフローに必要な技術だけを選ぶ。
この順序によって、AI導入を、機能の追加ではなく業務成果へ接続できます。
まとめ：AI工程ではなく、価値が届くまでの流れを見る
AIによって一つの作業が速くなることには価値があります。
しかし、その作業の前後に待ち時間、転記、重複確認、承認、例外処理が残れば、業務全体は大きく変わりません。
フェーズ9で確認するのは、次です。
この業務は誰へ何の価値を届けるのか
依頼発生から完了まで、どの工程があるか
どこで待っているか
何を重複しているか
どの工程を削除・統合できるか
AI、人間、システムは何を担うか
どの情報をどこで確定するか
順次、並列、分岐をどう使うか
承認や例外をどう処理するか
失敗時にどう止まり、どこから戻るか
何を測って継続・修正・撤退を決めるか
AI前提の業務再設計とは、すべてをAI化することではありません。
AIができることを前提に、不要な作業を減らし、人間の判断を重要な場所へ集中させ、情報と状態を途切れずにつなぐことです。
フェーズ8では、一つの仕事を再現可能にしました。
フェーズ9では、その仕事が前後の業務とどうつながり、最終的な価値へどう届くかを組み直します。
一工程の速度ではなく、流れ全体を見る。
それが、AI活用を個人の効率化から、本当の業務変革へ進める分岐点になります。
関連記事
AI導入を個人の効率化で終わらせず、業務、知識、権限、評価を含む企業変革へ進める考え方はこちらで整理しています。
プロンプトだけでなく、コンテキスト、ツール、状態、評価、権限まで設計対象が広がった背景はこちらで解説しています。
AIで作れるものが増えるほど、目的、優先順位、停止条件を保持すべき理由はこちらで詳しく考察しています。
企業で実行する場合
この記事で扱った業務フロー再設計を、自社の研修、業務棚卸し、AIワークフロー設計、システム開発、導入後の改善運用へ落とし込みたい場合は、支援内容を以下の記事にまとめています。
生成AIを導入した。でも、業務は変わらなかった。そんな企業へ研修から業務設計・開発・改善運用まで支援します
AI活用成熟度12フェーズの記事一覧
出典・参考資料
Microsoft, Build a workflow in Microsoft Foundry.
Microsoft, Microsoft Agent Framework Workflows.
Microsoft, Create and test an approval workflow with Power Automate.
Microsoft, Get started with Power Automate approvals.
Google Cloud, Choose a design pattern for your agentic AI system.
Google Cloud, Multi-agent AI system in Google Cloud.
NIST, Artificial Intelligence Risk Management Framework 1.0.
NIST, AI RMF Core.
NIST, AI RMF Playbook.
NIST, AI RMF Playbook — Map.
