業務プロセスの改善｜進め方6ステップ・ECRS・BPRとの違いと、AIをどこに組み込むか

僕の実家の合鍵は、長いあいだ1本しかありませんでした。増やせばいいのは分かっていたのですが、増やすと失くしたときが怖い、と思っているうちに何年か経っています。

そのあいだ、僕が鍵を持って出た日は、兄弟が誰も家に入れませんでした。近所で時間をつぶしてもらうことになります。鍵は正しく管理されていて、正しく誰の役にも立っていませんでした。

この合鍵と同じことが、AIの仕事でも起きました。AI（人の指示をもとに文章作成や操作を行う人工知能）による自動化が進む昨今、「寝ている時間に、いかに翌朝までの仕事を依頼しておけるか」「そのあいだ、自分の指示なしで仕事が自律的に進むか」ということが、生産性に大きな影響を与えるようになってきました。そして僕も、寝る前に大きめな指示を出したり、自律モード（AIが途中の判断も自分で行い、連続して作業する機能）を有効にしたりすることが習慣化していました。

いつものように夜のうちに仕事を依頼して、翌朝パソコンを開いたら、前の晩から1行も進んでいませんでした。

AIに障害が起きたのだと思って、あちこち調べました。電源、空き容量、権限（AIに許す操作の範囲）。外側から順に、10分ほどかけて潰していきます。

最後に画面をよく見たら、真ん中に小さな窓が出たままでした。「ブラウザを操作してよいですか」と聞かれたところで、やり取りが止まっています。ブラウザとは、Webページを表示・操作するソフトのことです。窓が出たのは夜中で、僕はそのとき寝ています。

止めていたのは、僕でした。

先に一行だけ置きます。人の承認を工程の中に置くと、人がいない時間にすべて止まります。 やっかいなのは、止まったことが記録の上では見えないことです。むしろ、完了したように読めてしまいます。

この晩やらせていた仕事

やらせていたのは、ネット通販で子ども向けの離乳食を売る事業の注文処理画面の修正でした。この通販事業は、大企業と僕の会社の共創事業（企業同士が協力して新しい事業をつくる取り組み）で、まず小さく作って現場で売ってみるMVP（本格展開の前に必要最小限の形で価値を確かめる製品）として立ち上げたものです。この共創事業で、僕の会社は注文処理画面を開発する役割です。

商材は、常温で保存できるパウチの離乳食です。冷蔵ではないぶん、まとめ買いと定期便が多くなります。

修正の対象は、倉庫で箱を詰める担当者が朝いちばんに開く「出荷準備」の画面です。前日までに入った注文が上から並んでいて、担当者はそれを見ながら詰めていきます。画面の下には、電話で入った追加注文をその場で手入力するための欄と、「追加」のボタンが付いています。

困っていたのは、キャンセルが入った注文を、画面から消せないことでした。注文は足せるのに、取り下げられない。担当者は、キャンセルが入った注文に付箋を貼って、印をつけていました。 剥がし忘れると、キャンセル済みの箱がそのまま出ていきます。

直す内容は3つです。各行の右に「取消」を置いて、押したら消えるようにする。ぜんぶ消えたときは「本日の出荷分はありません」と出す。そして、何も入れずに「追加」を押したときは、入力欄を赤くしてカーソルをそこへ戻す。品名の空いた行が紛れ込むのを防ぐためです。

ここまでで、開発者が作業すれば半日ほどかかる分量になります。

この修正を、AIに任せていました。使っているのは、僕の会社で作った開発用のソフトウェアです。指示を一度出すと、AIが自分でコード（ソフトウェアを動かす命令文）を書き、動くかどうかを確かめ、できたところまで文章で報告してきます。

夕方に指示を出してパソコンを閉じ、朝にその報告を読む。日中に開発者が作業を見守り続けずに済むからです。

AIが何かを実行する前に、人が中身を見て通す仕組みのことを、ここでは「確認」と呼びます。危ない操作を勝手にやらせないための歯止めで、業務プロセス（仕事を進める一連の流れ）にAIを組み込むときは、まずこれを設計します。

今日は、その確認をどこに置くかで結果が変わった、という話をしていこうと思います。

前置きはさておき、本題に入ります。

① 教科書どおりに、危ないところへ人の承認を置いた

業務プロセスとは

業務プロセスとは、ひとつの仕事が始まってから終わるまでの、作業と受け渡しの並びのことです。受注処理なら「注文を受ける → 在庫を確認する → 出荷を指示する → 請求する」の一連がそれにあたります。

単体の作業ではなく、作業と作業のあいだの受け渡しまで含むのが特徴です。遅れは作業の中ではなく、たいてい受け渡しのところで生まれます。

業務プロセス改善とは

業務プロセス改善とは、その並びを見直して、かかる時間・人手・ミスを減らすことです。個々の作業を速くする「業務効率化」より、対象が1段広くなります。

速くする前に「その作業は要るのか」を問えるのが、プロセス改善が効率化と違うところです。作業を速くしても、その作業ごと不要だったなら、効果は残りません。

業務プロセスと業務フローの違い

	指すもの	粒度
業務プロセス	仕事の流れそのもの	目的・担当・順序。何のための流れかを含む
業務フロー	その流れを図に描いたもの	記号と矢印。描き方の作法がある

フローはプロセスの表現方法のひとつです。図を描くこと自体が目的になると、きれいな図ができて何も変わらない、が起こります。業務フローの描き方は業務フローの書き方｜四角と矢印を描いても、どこが遅いか分からないに整理しています。

業務プロセス改善が注目される背景

外側の事情は、大きく2つです。

• 業務の煩雑化 — 使うシステムと関係先が増え、1つの仕事が複数のツールをまたぐようになった
• 人手不足 — 人を増やして処理量を上げる手が、そもそも取れなくなった

2つ目が効いています。かつては「忙しくなったら人を足す」が選べたので、プロセスの粗さは吸収できました。足せなくなった時点から、並びそのものを直すしかなくなります。

業務プロセス改善の目的

現場で挙がる目的は、次の4つに収まります。どれを主目的に置くかで、手を入れる場所が変わります。

• 時間を減らす — 着手から完了までの日数を短くする
• 人手を減らす — 同じ量を、少ない人数で処理できるようにする
• ミスを減らす — 転記や確認漏れが起きない形にする
• 属人化を解く — その人がいないと止まる状態をなくす

4つを同時に狙うと、どれも中途半端になります。「今回は日数」と決めると、削る対象が自動的に絞れます。

DX・働き方改革との関係

DXはデジタルで事業のあり方ごと変えること、働き方改革は労働時間と働く場所の制約を変えることです。業務プロセス改善は、そのどちらにとっても手前の工程になります。

いまの流れを把握しないままツールを入れると、紙でやっていた非効率をそのまま画面に写します。DXが「システムを入れただけ」で終わる典型が、この順番の逆転です。

BPR・BPMとの関係

	対象	進め方
業務プロセス改善	いまの流れの一部	現状を土台に、悪い箇所を直す
BPR（業務改革）	流れの前提ごと	いまの形を白紙に戻して組み直す
BPM（業務プロセス管理）	改善を回し続ける仕組み	モデル化 → 実行 → 監視 → 改善を継続する

順番があります。改善で足りるかを先に確かめ、部分最適では追いつかないと分かったときにBPRへ上がります。いきなりBPRを掲げると、現場が付いてきません。

改善で得られるもの1｜処理にかかる時間と人手が減る

待ち時間と重複作業が消えるぶん、同じ量をより短く、より少ない人数で処理できます。

効果は「作業時間」ではなく「着手から完了までの日数」で測ってください。作業時間だけを見ると、待ち時間に隠れた遅れが数字に出ません。

改善で得られるもの2｜DXの土台ができる

流れが図になっていると、どこをデジタル化すべきかが判断できます。可視化されていない業務は、システム化の見積もりも出せません。

改善で得られるもの3｜属人化とリスクが下がる

手順が文書になっていれば、担当者の異動や退職で止まりません。監査やコンプライアンスの説明も、流れが定義されていればそのまま出せます。

属人化は「その人が優秀だから」起きるのではなく、「手順が書かれていないから」起きます。人を責めても解けません。

改善の手法1｜業務フロー図による可視化

誰が・何を・どの順で・誰に渡すかを、記号と矢印で1枚にします。これをやらずに改善案から入ると、全員が別の流れを想像したまま議論します。

実務のコツは、理想ではなく現状を描くことです。「本来はこうあるべき」を描くと、いま起きている迂回路が図から消えます。

改善の手法2｜ECRSの原則

見直す順番を決める原則です。上から順に検討するのが要点です。

	意味	効果
Eliminate（排除）	その作業をやめられないか	最も大きい
Combine（結合）	複数の作業をまとめられないか	大きい
Rearrange（交換）	順番や担当を入れ替えられないか	中
Simplify（簡素化）	その作業を簡単にできないか	小さい

現場の改善案は、たいていSから出てきます。入力を楽にする、フォーマットを揃える。Eから順に問い直すと、そもそも不要だった報告書が見つかります。

改善の手法3｜ボトルネック分析

全体の速度は、いちばん遅い工程で決まります。そこ以外を速くしても、全体は変わりません。

探し方は、各工程の「滞留している件数」を数えることです。作業時間ではなく、順番待ちの山ができている場所が答えです。

改善の手法4｜業務プロセスへのAIの組み込み

近年はここに、生成AIやAIエージェントを組み込む選択肢が加わりました。判断を含む工程を任せられるようになったのが、RPAとの違いです。

	向いている工程	限界
RPA	手順が完全に固定された転記・登録	画面や様式が変わると止まる
生成AI	文章の要約・分類・下書き	合っているかを人が確かめる時間が要る
AIエージェント	複数の道具を使って手順を最後まで実行する	途中で人の承認を挟むと、人がいない時間に止まる

3行目の限界は、設計の話であって性能の話ではありません。この記事の後半は、そこを1箇所だけ変えた記録です。

進め方1｜現状を把握して可視化する

いま実際にどう流れているかを、担当者に聞きながら図にします。

聞くだけでなく、実物を見せてもらってください。説明では出てこない「Excelに一度貼ってから入れ直す」といった迂回路が、ここでしか見つかりません。

進め方2｜課題を洗い出して整理する

図の上で、遅い箇所・戻りが発生する箇所・人によって結果が変わる箇所に印を付けます。

「大変です」は課題ではありません。何件を、何分で、何回やり直しているか。数えられる形にするまで課題になりません。

進め方3｜改善の目標を設定する

どの指標を、いつまでに、どこまで動かすかを決めます。

指標は1つに絞ります。「時間も件数もミスも」と並べると、どれを優先するかの判断が現場に丸投げされます。

進め方4｜改善案を立てて実行計画にする

ECRSの順に案を出し、効果と手間で並べ替えます。誰が、いつ、何を変えるかまで落として、はじめて計画になります。

実行計画には「元に戻す条件」も書いてください。戻し方が決まっていない変更は、現場が試すのを怖がります。

進め方5｜実行する

一部の部署や一部の案件から始めます。

全社一斉に変えると、うまくいかなかったときに原因が分かりません。比べる対象を残しておくのが、あとで効きます。

進め方6｜効果を検証して定着させる

決めた指標が動いたかを測り、動いていなければ原因を戻って探します。

定着は、手順書ではなく「元の手順に戻れない状態」で担保されます。旧フォーマットを残したままにすると、繁忙期に必ず戻ります。

成功させるポイント1｜経営層と現場の両方を巻き込む

経営層だけで決めると現場が動かず、現場だけで進めると権限の壁で止まります。決裁できる人と、実際に手を動かす人を、同じ場に置いてください。

成功させるポイント2｜小さく始めて段階的に広げる

1つの業務、1つの部署から始めます。成功した1件が、次の部署を説得する材料になります。

成功させるポイント3｜定期的に現場へ聞きに行く

改善後の流れが、実際にそのとおり回っているとは限りません。迂回路は、聞かれなければ報告されません。月に一度、実物を見に行くだけで見つかります。

成功させるポイント4｜継続的に回す

一度直して終わりにすると、扱う量や関係先が変わったときにまた崩れます。見直す日を年間の予定に入れておくのがいちばん確実です。

改善に使えるツールとサービス

自前でやるか、道具を入れるか、外に出すか。判断の目安を並べます。

	向いているとき	注意点
業務可視化ツール	流れが誰にも把握できていない	図が増えるだけで終わることがある
ワークフローシステム	申請・承認の回覧に時間がかかっている	紙の様式をそのまま写すと効果が出ない
RPA	転記・登録が定型で大量にある	画面が変わると止まる。保守の担当が要る
BPO・アウトソーシング	定型業務をまとめて外に出したい	中の手順が社内から見えなくなる
コンサルティング	社内に可視化の経験がない	実行まで含む契約かを確認する

最後の行が実務では効きます。現状分析と改善案の提出までで終わる契約だと、いちばん手間のかかる「実行と定着」が社内に残ります。

改善アイデア1｜申請・承認業務をデジタル化する

稟議、経費、休暇。紙と押印で回っているものを電子化すると、回覧の待ち時間が消えます。

電子化するときに、承認者の数を見直してください。紙のまま電子にすると、押印待ちが承認待ちに変わるだけです。

改善アイデア2｜データの集計・管理を一元化する

部署ごとのExcelを1箇所に集めると、転記と突き合わせの作業がまとめて消えます。

一元化の効果は、集計作業の削減より「数字が食い違わなくなること」に出ます。会議の前半が数字の擦り合わせで終わる、が無くなります。

確認をどこに置くかという設計は、素直に教科書どおりでした。

外に影響が出る操作には、実行の直前に人の確認を挟む。ブラウザを開くもの、動作確認用のサーバー（画面を動かして試すためのコンピューター上の仕組み）を立てるもの、インターネットで検索するもの。この3系統の操作に確認を置きました。

この置き方は、ちゃんと動きました。人が画面の前にいるあいだは、確認が出て、通して、先へ進みます。危ないことは何も起きません。

人がいる時間だけ走らせていたあいだ、この設計で困ったことは0件でした。

ここまでが、業務プロセス改善の教科書どおりの整理です。可視化して、課題を数え、ECRSで削り、小さく試して、定着させる。AIを組み込むときも、この順番は変わりません。

この記事の後半で扱うのは、その順番どおりに進めたあとの話です。危ないところに人の確認を置く——教科書どおりのその設計が、誰がいつ働くかを変えた瞬間に、何を意味しはじめるのかを見ていきます。

② 止まっていたのは、確認の窓1件ではなかった

その朝、目に見えていたのは確認の窓1件だけでした。

ただ、AIが夜のあいだに残していた作業の記録を開いてみると、止まっていたのはそれだけではありませんでした。ブラウザを操作する道具が2件、パソコンの画面そのものをマウスとキーボードで操作する道具が1件、それに動作確認用のサーバーを立てる処理が1件。人の承認を置いた3系統に対応する道具は4件ありました。その4件が、そろって同じ理由で動けなくなっています。

記録に残っている理由は1行です。「権限承認待ちで駆動不能」。その横に、原因が書いてあります。「ユーザー不在のため承認が得られない」。

当たり前です。夜中に確認する人がいません。

止まったのが一度きりなら、まだ話は簡単でした。

次の晩も、同じ承認待ちで止まっています。 記録には、前の晩と同じ理由だと一言あるだけでした。原文はそっけなく「cycle-2 と同一の制約」です。

あとから過去の作業記録をまとめて検索したら、「承認待ちで止まった」という趣旨の記述が、記録ファイル17本に、29件残っていました。気づいていなかっただけで、ずっと起きていたことになります。

③ そのうえ、取消ボタンの件は「完了」になっていた

止まったはずの2晩目の作業は、失敗として記録されていません。完了しています。 ここに気づくまでに、いちばん時間がかかりました。

からくりはこうです。本物のブラウザが開けないので、AIは代わりに、ブラウザの動きだけを真似た小さな仕掛けを自分で書き、その上で取消ボタンを試していました。

AIが確かめた項目は21件、すべて通っています。押したら1件減ること。減ったぶんが保存にも反映されること。ぜんぶ消したら「本日の出荷分はありません」が出ること。何も入れずに「追加」を押したら、赤い枠が付いてカーソルが入力欄に残ること。

「取消」の2文字が、保存するときに品名の文字列へ混ざらないことも見ています。ここは実際に起きやすい不具合です。行に書かれた文字をまとめて読み取って保存すると、ボタンに書かれた「取消」まで品名へ入ってしまうからです。読み取る範囲からボタンを外して、避けてありました。

問題として挙がったものは、0件です。

つまり、朝に届く報告だけを見ると順調そのものです。取消ボタンは付いた、と読めます。

しかし、通っていたのは、本物のブラウザでの検証ではなく、代わりの仕掛けを使った検証でした。報告の最後には、本物のブラウザで見た目とカーソルの動きを目で確かめてはいない、と小さく書いてあります。原文は「実機ブラウザでのCSS見た目・フォーカス挙動の目視確認は未実施」です。ここでいうCSSは画面の見た目を整える設定、フォーカスは文字入力を受け付ける位置を指します。

押したら消える、という理屈は21件分確かめられています。ただ、その「取消」が画面のどこに、どんな大きさで出ているのかは、誰も見ていません。 赤い枠が本当に赤く見えるのかも、品名とボタンが重なっていないのかも、確かめていません。

この画面は、倉庫で箱を詰めながら押されます。 品名の真上にボタンが重なっていたら、押し間違えます。付箋を剥がし忘れるのと、同じ事故です。取消ボタンについて確かめられたのは、半分でした。

確認待ちは、処理を止めるだけではありませんでした。本物のブラウザが使えないため、AIは代わりの仕掛けを使って検証していました。 そして、検証が不足していることは、報告の上では分かりません。

④ 原因を1件に絞る

原因の候補はいくつも思いつきます。無人で回す設計が甘い。道具の選び方が悪い。記録の書き方が緩い。

ただ、絞ると1件でした。

確認を「実行の瞬間」に置いていたこと。

実行の瞬間というのは、人がいるとは限らない時刻です。そこに人の判断を要求する設計は、人が席にいることを当てにしています。人がいない前提で組んだ仕組みに、人の在席を前提とする確認が1件だけ混ざっていた。それだけでした。

⑤ 直したのは1箇所だけ

やったことは、確認の時点を動かすことだけです。

実行の瞬間ではなく、始める前に寄せました。その晩に使ってよい道具の一覧を、走らせる前に人がまとめて見て、通しておく。走り出したあとは、AIは何も聞いてきません。

同時に、AIへの指示にもう1行足しました。代わりのやり方で通したときは、何が確かめられていないかを必ず書き残す、という決まりです。原文では「代替検証の質は明示的に限界を記録する」と書いています。完了に見えてしまう問題への手当てです。

以後は、この確認時点を守ることにしました。代わりのやり方で確かめられなかった点も、必ず記録します。

⑥ あとで知った ── すでに名前がありました

しばらくして、OpenAIが出している実務ガイドを読み、手が止まりました。AIに指示を渡したあと、自律的に作業を進めさせる仕組みをどう組むか、という内容です。ガイドはこの仕組みをエージェント（目標に向けて必要な作業を自律的に進めるAIの仕組み）と呼んでいます。

そのガイドには、人の介入を掛ける条件が2件しか書かれていません。ひとつは「失敗の閾値を超えたとき」。やり直しや操作の回数に上限を置き、そこを超えたら人へ渡す。もうひとつは「不可逆、または高リスクな行為」。取り消しのきかない操作のことです。

工程ごとに人の承認を置け、とはどこにも書いてありません。

代わりに書いてあったのが、エージェントの「run」という考え方でした。run（AIに一連の作業を実行させる単位）は終了条件に達するまで回すループとして定義され、その終了条件として4件が挙げられています。決められた道具が呼ばれたとき、決められた形の答えが出たとき、エラーが出たとき、そしてAIとのやり取りの回数が上限に達したとき。

つまり、人が見るのはループの境界であって、ループの中の各工程ではない、ということです。ここでいう境界は、一連の作業を始める前と、終了条件に達して止まったあとを指します。

「実行の瞬間から着手前へ動かした」というのは、言葉を知らないまま、確認をループの境界に置く形へ寄せていただけでした。新しい理屈は、ひとつも要りませんでした。

⑦ 変えてみて、何が良くなって、何を失ったか

名前を知ったので、今度は意識して形を合わせました。確認を、境界の2件だけに置き直します。始める前の一括した確認と、取り消しのきかない操作に対する実行時の停止。この2件です。

同じ取消ボタンの改修を、もう一度無人で走らせました。止まりませんでした。朝いちばんに本物のブラウザで開いてみたら、取消ボタンが品名の右端に寄りすぎていて、長い商品名のときに折り返して重なっていました。 21件では出てこなかった不具合です。直すのに5分かかりました。

ただ、代償があります。3件書いておきます。

1件目。確認の粒度が粗くなりました。 始める前にまとめて通すので、走行中の細かい歯止めは消えます。だから取り消しのきかない操作だけは、実行時の確認に残さざるを得ません。全部を始める前に寄せると、今度は取り返しがつかなくなります。

2件目。事前に何を使うか読み切る必要が出ました。 途中で想定外の道具が要る展開になると、そこで止まります。止まる場所が、前に移っただけです。実際、道具の一覧を書き出す作業が、走らせる前の準備に10分ほど増えました。

3件目。確かめていないことの記録が増えました。 「これは確かめていない」という行が毎回残るので、朝に届く報告は前より汚くなります。ただ、これは失ったものではないと思っています。前は、汚れが見えないだけでした。

⑧ 現場で置くなら、この3行の表

業務プロセスにAIを組み込むとき、この共創事業では次の表のように整理しています。

確認の置き場所	何を掛けるか	人がいない時間に
始める前（一括）	その回で使う道具・触る範囲	止まらない
実行時（個別）	取り消しのきかない操作だけ	止まってよい
~~工程ごと~~	~~各工程の出力を1つずつ確認~~	全部止まる

3行目をやらない、というだけの表です。ただ、最初に作る設計はたいてい3行目から始まります。危ないところに承認を置きたくなるのは、正しい直感だからです。

確認をどこに置くかの判断に迷ったら、問いは1件だけです。「この操作は、取り返しがつくか」。 つくなら実行時に止めない。つかないなら、人がいない時間は動かさない。

取消ボタンを画面に足すのは、取り返しがつきます。だから夜に走らせてよい。一方で、その日の出荷データを消す処理は取り返しがつきません。こちらは朝まで待たせます。

この線引きは、扱っている商品には依存しません。 出荷でも、請求でも、予約の取り消しでも、問い合わせへの自動返信でも同じです。その操作をやり直せるかどうかだけを見ます。

⑨ この置き方が効き続ける理由

モデル（AIの中核となる仕組み）が賢くなっても、確認を境界に置く構造は変わらないと考えています。

確認は、AIの能力を補うためのものではないからです。取り返しのつかなさに対する保険です。取り返しのつかなさは、モデルの性能とは無関係に、業務そのものの性質として残ります。出荷したものは、賢いモデルが出荷しても戻ってきません。

一方で、工程ごとの確認は、モデルが賢くなるほど無駄になります。確認しても素通りするだけの場面が増えるからです。そして素通りする確認は、人がいない時間には無駄では済まず、停止になります。

だから、モデルが賢くなるほど、確認を境界に寄せる設計がより適切になります。

このあたりの設計を実際の業務に落とす話は、業務自動化のページに整理しています。止まっている工程があれば、こちらからご相談ください。

いまは、確認の窓が朝にまとめて1件だけ出ます。通すのに1分もかかりません。外側から順に疑っていく10分は、もう発生していません。

ただ、その1分すら惜しくなって、自動で通す仕組みを作りかけました。半分ほど書いたところで手が止まり、そのまま放ってあります。

以上です。

▶ この記事のテーマを実務で相談する: AI業務自動化

業務プロセス改善のよくある質問

業務プロセス改善と業務効率化は何が違いますか？

業務効率化は個々の作業を速くすることで、業務プロセス改善は作業と受け渡しの並びそのものを見直すことです。対象が1段広くなるぶん、「その作業は要るのか」を問えるのが違いです。作業を速くしても、その作業ごと不要だったなら効果は残りません。だからECRSでは、簡素化（S）ではなく排除（E）から順に検討します。

業務プロセスと業務フローの違いを教えてください。

業務プロセスは仕事の流れそのもの、業務フローはその流れを記号と矢印で図にしたものです。フローはプロセスの表現方法のひとつにすぎません。図を描くこと自体が目的になると、きれいな図ができて何も変わらない、が起こります。描くときは理想ではなく現状を描いてください。理想を描くと、いま起きている迂回路が図から消えます。

業務プロセス改善の進め方を教えてください。

6ステップです。現状を把握して可視化する、課題を洗い出して数えられる形にする、指標を1つに絞って目標を決める、ECRSの順に改善案を立てて実行計画にする、一部の部署や案件から実行する、効果を検証して定着させる。実行計画には「元に戻す条件」も書いてください。戻し方が決まっていない変更は、現場が試すのを怖がります。

ECRSの原則とは何ですか？

改善を検討する順番を決める原則で、Eliminate（排除）・Combine（結合）・Rearrange（交換）・Simplify（簡素化）の頭文字です。上から順に検討するのが要点で、効果もこの順に大きくなります。現場から出てくる案はたいてい簡素化から始まりますが、排除から問い直すと、そもそも不要だった報告書が見つかります。

業務プロセス改善とBPR・BPMはどう違いますか？

業務プロセス改善はいまの流れを土台に悪い箇所を直すもの、BPR（業務改革）はいまの形を白紙に戻して前提ごと組み直すもの、BPM（業務プロセス管理）は改善を回し続ける仕組みです。順番があり、改善で足りるかを先に確かめ、部分最適では追いつかないと分かったときにBPRへ上がります。いきなりBPRを掲げると現場が付いてきません。

業務プロセスにAIを組み込むとき、人の承認はどこに置くべきですか？

その回で使う道具と触る範囲は、AIが仕事を始める前にまとめて確認します。走り出したあとは工程ごとに承認を求めず、取り消しのきかない操作だけを実行時の停止対象にします。工程の途中に承認を置くと、人がいない時間にはそこで仕事が止まります。判断するときは、その操作をやり直せるかどうかを基準にします。

AIエージェントが夜間の無人運用で止まるのはなぜですか？

実行の瞬間に人の承認を求める設計が、人の在席を前提としているためです。記事の事例では、ブラウザ操作、パソコン画面の操作、動作確認用サーバーの処理に関わる道具4件が、ユーザー不在のため動けませんでした。同じ制約で2晩続けて止まり、過去の記録ファイル17本には承認待ちの記述が29件残っていました。AIや電源の異常ではなく、確認を置いた時点が原因でした。

AIの作業報告が完了でも、確認が必要なのはなぜですか？

AIは本来の道具が使えないと、代わりの仕掛けで検証して完了と報告することがあるためです。記事の事例では代替環境のテスト21件がすべて通り、問題は0件とされました。しかし、本物のブラウザでの見た目とカーソルの動きは確認されず、長い商品名で取消ボタンが重なる不具合が残っていました。代替検証を使ったときは、何を確かめていないかを必ず記録する必要があります。

AI自動化で実行時にも人の確認を残すべき操作は何ですか？

取り消しのきかない操作や、高リスクな操作です。記事では、取消ボタンを画面に追加する変更はやり直せるため、夜間に進めてよい操作としています。一方、その日の出荷データを消す処理は取り返しがつかないため、朝まで待たせます。出荷、請求、予約の取り消し、自動返信でも、扱う商品ではなく、その操作をやり直せるかどうかで判断します。

AIエージェントには、どのような場合に人が介入すべきですか？

記事で参照したOpenAIの実務ガイドでは、失敗の閾値を超えたときと、不可逆または高リスクな行為の2つが人の介入条件です。失敗の閾値は、やり直しや操作の回数に上限を設け、超えたら人へ渡す考え方です。通常の処理は終了条件まで回すループとして扱い、人は各工程ではなくループの境界を見ます。実務では、着手前の一括確認と、取り消しのきかない操作に対する実行時の停止へ確認を寄せます。

承認を着手前にまとめるデメリットは何ですか？

確認の粒度が粗くなり、走行中の細かな歯止めが減ります。また、その回に使う道具を事前に読み切る必要があり、想定外の道具が必要になればそこで止まります。記事の事例では、道具の一覧を書き出す準備が10分ほど増えました。確かめていない項目も毎回記録するため報告は以前より長くなりますが、未確認事項を見える状態にできます。