AI導入後の業務は、どこまで再設計すべきか

Dillonらの66社・7,137人の無作為化実験では、生成AIを実際に使った人のメール時間が週約2時間減りましたが、仕事の量や構成に統計的に検出できる変化はありませんでした。[1] 個人が変えられるメール作業は短くなっても、会議、承認、役割分担のように他者との調整が必要な工程は自動では変わりません。

業務フローを、受付、作成、確認、例外判断、承認、確定、顧客・次工程への引渡しへ分けます。AIが直接触れた工程だけでなく、各工程の到着量、処理量、待ち時間、差し戻しを同じ案件IDで追います。一工程の時間が短くなっても、確定件数と端から端の時間が変わらなければ局所改善として報告します。

仕事量が変わらない理由は、AIが弱いことだけではありません。需要が一定、次工程の容量が固定、確認基準が厳しくなった、浮いた時間が別業務へ使われたという代替説明があります。[1] 工程ごとに競合仮説を置き、最初に詰まりが移った場所を再設計対象にします。

• FLOW：案件が受付から確定まで通る工程と所有者を描く
• QUEUE：各工程への到着、処理、待ち、滞留を測る
• REWORK：差し戻し元、修正理由、再通過回数を記録する
• OUTCOME：局所時間ではなく確定件数と端から端の時間を主要指標にする

Dell’AcquaらはP&Gの791人を、AI有無と個人・二人チームの条件へ無作為に割り付けました。AIを使う個人はAIなしのチームと同等の成果を示し、R&Dと商務の専門偏りも小さくなりました。[2] さらに工程分解では、AIは案の生成品質を主に高め、人の判断は評価・選択で価値を保つことが示されました。[2]

この結果は、AIがすべてのチームを代替する証拠ではありません。一社の短時間の製品開発課題で、長期実装や顧客成果は測っていません。[2] ただし、役割を『企画職』『専門家』という職務名で固定せず、候補生成、根拠確認、比較評価、例外判断、最終承認へ分けて試す根拠になります。

工程ごとに、人のみ、AIのみ、人とAIの候補を置きます。生成はAI、評価は人と決め打ちせず、品質、時間、検証可能性、失敗影響、受け渡し負荷を測ります。人へ残す工程には、単に責任者と書くのではなく、何を見て棄却し、どこで止め、誰へ戻すかを手順として定義します。

• GENERATE：候補・草案・探索を作る工程
• VERIFY：根拠、数値、規則、入力の不足を確認する工程
• SELECT：複数案を目的と制約に照らして選ぶ工程
• EXCEPTION：標準外、重大影響、根拠不足を判断する工程
• APPROVE：結果と残余リスクを引き受け確定する工程

Brynjolfssonらが5,172人のカスタマーサポート担当者を分析した研究では、AI支援で1時間あたり解決件数が平均15%増え、効果は経験の浅い・低スキルの担当者で大きく、最上位層では速度の改善が小さく品質がわずかに下がる結果も示されました。[3] 同じ工程でも担当者と案件によって配置の価値が違います。

AIを全員へ同じ形で置くのではなく、案件難度、担当者の経験、過去事例の豊富さ、出力の検証可能性で区分します。経験の浅い人への知識移転として有効でも、熟練者の例外判断を同じ提案で上書きすれば価値が下がる可能性があります。[3] 平均改善を一律配置の根拠へしません。

適用境界は固定表ではなく、誤りと例外から更新します。AI提案をほぼ修正せず確定できた区分、根拠不足で保留した区分、専門家が大幅修正した区分、重大誤りが出た区分を分けます。利用率ではなく、どの区分で工程配置が成立したかを月次で見直します。

確認へ送る比率が変わらなければ、作成量の増加が確認者への到着量を増やすという運用上の仮説を置きます。2025年6月の著者版では、三社・4,867人の開発者実験で、割付を実利用の操作変数とした推定では利用による週の完了pull request 26.08%増が報告されました。この推定は追加仮定を要し、アクセス付与の平均効果とは異なります。企業別推定はばらつき、割付と業務条件も異なりました。[4]

現行の掲載要旨にもこの数値は残りますが、掲載版の方法全文を取得できず、著者版との差分は未確認です。出力量の増加をそのまま完成量とせず、レビュー、試験、マージまで追う必要があります。

例外キューには、根拠不足、規則競合、重大影響、顧客固有条件、AIと人の不一致を入れます。通常案件をAIで速く処理するほど、専門家には難しい案件だけが集中し、一件あたりの確認時間が増える可能性があります。件数だけでなく難度、滞留時間、再発、同じ専門家への集中を追います。

ボトルネックが移ったら、上流の利用率を下げる、出力をまとめる、低影響区分だけ自動確定する、確認基準を明確にする、専門家へ渡す情報を増やすという複数案を試します。レビュー残業や無償の持ち帰りで流量を維持した場合は改善と認めず、負荷移転として記録します。

• ARRIVAL：AI前後で次工程へ届く件数と難度を測る
• SERVICE：確認・承認に使える時間と処理能力を測る
• BACKLOG：例外の件数、年齢、再発、担当集中を追う
• TRANSFER：別部署、時間外、外注へ移った負荷を総量へ戻す

時間短縮は、再配分されるまで組織成果ではありません。Dillonらの研究で仕事量・構成の変化が検出されなかったことは、個人へのアクセスだけでは余力の使途が決まらない可能性を示します。[1] 一方、Brynjolfssonらの研究は、安定したサポート工程で処理量と品質へ接続できる条件があることを示します。[3]

再配分先は、需要待ちの処理、顧客との対話、品質確認、改善、学習、負荷軽減などから事前に選びます。すべてを処理量へ変える必要はありません。時間外労働の削減や、今までできなかった品質確認も成果になり得ます。ただし、何へ移したかを記録せず人件費削減と処理増を同時に計上しません。

仮想例として、初稿作成の時間が大きく短くなっても、担当者が別の会議へ吸収されれば案件のリードタイムは変わりません。確認標本の拡大へ再配分し重大誤りが減ったなら、価値は速度ではなく品質回避です。再配分先、受益者、確認方法を工程変更票へ置き、一定期間後に実現を確認します。

• CAPACITY：短縮した時間の量と発生する役割を記録する
• DESTINATION：処理量、品質、顧客、学習、負荷軽減のどこへ移すか決める
• REALIZATION：再配分先で実際に成果が変わったか確認する
• NO DOUBLE COUNT：同じ余力を人件費削減と処理増へ二重計上しない

業務再設計は新しい手順書を一度配って終わりではありません。対象区分、AIと人の工程、入力、確認、例外、承認、再配分、停止を一つの変更版として記録します。旧手順と並行できる期間を置き、端から端の成果と品質の下限、例外滞留と負荷の上限を満たした範囲だけ新手順へ移します。

研究間では、日常ツールへの広いアクセスで仕事構造が動かない結果、限定工程で処理量が増える結果、短時間の開発課題で専門境界が変わる結果が併存します。[1] [2] [3] これは矛盾ではなく、業務、技術、調整、評価単位が違うことを示します。自社フローではどの条件に近いかを比較し、数字だけを移植しません。

月次の工程審査では、利用率ではなく、確定件数、端から端の時間、品質下限、再作業、例外滞留、専門家負荷、再配分成果を見ます。改善しない場合は、AIを外すだけでなく、対象区分、受け渡し情報、確認容量、再配分先という競合仮説を一つずつ変えます。戻せない変更は最初の対象にしません。

• BASELINE：旧手順の流量、品質、例外、負荷を保存する
• VERSION：工程配置と境界条件を変更版として記録する
• PARALLEL：代表案件で旧新手順を同期間に比較する
• ROLLBACK：品質下限を下回るか、例外滞留・専門家負荷の上限を超えた区分を戻す