公開日 2026年8月18日・約8分で読めます

承認フロー自動化の落とし穴。AIの判断待ちを溜めない決定受信箱

承認フロー自動化の落とし穴は、AIに業務を任せるほど「人間の承認・判定待ち」だけが仕事として残り、複数の自動化に散らばって滞留することです。対策は承認そのものの自動化ではなく、散らばる判断待ちを毎朝1枚に集めて回収する仕組み。僕はこれを「決定受信箱」と呼び、自社で実運用しています。

この記事では、実際に動いている決定受信箱の作り方を5ステップで公開します。あわせて、収集対象への登録漏れで判断が届かず、ブログの新規企画が4日間止まった僕の実話も書きます。承認待ちが業務のボトルネックだと感じている経営者と、AI自動化を広げている実践者に向けた記事です。

承認フロー自動化の落とし穴。AIに任せるほど人間の判断待ちが残る

承認フローの自動化というと、紙の稟議を電子化して回覧を速くする話が中心です。それ自体は正しいのですが、AIに業務を任せ始めた会社には、その手前にもっと大きな落とし穴があります。

実行は自動化できても、承認は人間に残る

AIへの任せ方が上手くいくほど、実行の部分は人間の手を離れていきます。僕の会社では、ブログ記事の企画・執筆、日々のリサーチ、SNS投稿のドラフト作成といった業務がそれぞれ自動で回っています。こうした仕組みを僕は「ハーネス」と呼んでいます。AIに業務を任せて回すための、実行と検査の一式くらいの意味です。

ただし、どの仕組みにも必ず「人間の判定」を挟む場所を残しています。新しい企画を採用するか。この施策に踏み切るか。実行はAIでも、責任を伴う承認・判定は人間の仕事として残す。ここまでは設計どおりです。

落とし穴はその先にあります。

判断待ちは1カ所ではなく、あらゆる場所に散らばる

自動化が1つなら、判断待ちにはすぐ気づけます。問題は5個、10個と増えたときです。Aの仕組みは記録ファイルの中に「採否待ち」と書き、Bの仕組みは通知を1回出して終わり、Cの仕組みはそもそも判断待ちを書き出す場所を持っていない。依頼の出し方が仕組みごとにバラバラなので、人間側は「いまどこに何の判断待ちがあるか」を全部は覚えていられません。

その結果、実行側は速くなったのに、AIに任せる範囲を広げるほど、残った人間の判断が全体の速度を決めるようになります。承認フローの一般論でも、滞留の主因は「承認者の不在・多忙」とされます。AI運用ではさらに条件が悪く、承認依頼を出してくる相手が人間ではなく多数の自動処理なので、依頼は夜中も休日も増え続けます。溜まる速度が違うんです。

判断が届く経路が無いと自動化は止まる。新規企画が4日止まった実話

これを設計論ではなく、実際に痛い目を見た話としてします。

エラーゼロのまま、企画だけが止まった

僕はこのブログの記事制作を、企画から下書き投稿までAIで自動化しています。全体像は次の記事に書きました。

2026年8月5日から8日までの4日間、この仕組みで新しい記事の企画が1本も立たなくなりました。

止まり方が厄介でした。エラーは1度も出ていません。企画の在庫が尽きたとき、次に進むには「このトピック案を採用するか」という僕の判定が必要でした。自動処理は毎回律儀に「在庫ゼロのため停止。判定待ちは未記入」という記録を残し、再開には僕の一言が要ると明記までしていました。同じ内容の停止記録は、前後の期間を含めて14回分積み上がっています。

原因は判断の難しさではなく、経路の欠落

ではなぜ僕は4日間も判定を書かなかったのか。サボっていたわけではなく、判断待ちの存在自体が僕に届いていなかったからです。

当時すでに僕は、各仕組みの判断待ちを1枚に集める決定受信箱の運用を始めていました。ところがブログの自動化は、受信箱が収集する対象の一覧（後述するレジストリ）に登録されていませんでした。しかも判断待ちが所定の起票形式ではなく、記録ファイルの中の散文メモとしてしか存在していなかった。つまり何回停止ログを積んでも、構造的に受信箱に載りようがなかったんです。8月5日の自動処理自体が、この根因をログに特定していました。

判断が止まっていた原因は、判断の難しさではなく、届く経路の欠落でした。必要だった判定は「採用か、却下か」の一言です。一言で済む判断が、経路が無いだけで4日分の生産を止めました。承認フローの自動化で本当に設計すべきは、承認ボタンの置き場所ではなく「判断が確実に人間へ届く経路」だと、このとき骨身に染みました。

決定受信箱とは？散らばる判断待ちを毎朝1枚に集める仕組み

毎朝1枚だけ見ればいい、という状態を作る

決定受信箱とは、複数の自動化が出す人間の判断待ちを1枚のファイルに集約し、人間が記入した判定を各仕組みの記録へ自動で書き戻す仕組みです。ポイントは3つあります。

判断待ちの「書式」を全仕組みで統一する（起票形式）
収集する対象を明示的に登録する（レジストリ）
人間の仕事は「空欄を埋める」ことだけに絞る

紙の稟議の電子化と違い、対象はツール1つではありません。どんなツールで作った自動化でも、同じ書式で判断待ちを書かせて、横断で1枚に集めるのが本体です。

実物の受信箱はこうなっている

僕の受信箱の実物は、冒頭にこういう1行が入ったテキストファイルです。

判定待ち: 11件 / 最古 5日 / 本日の判定 0件 / 滞留中央値 4日

これは2026年7月26日の実物の冒頭行です。この下に、仕組みごとの判断待ちが並びます。1件あたり、内容の見出し1行と「判定: ____」という空欄1行だけ。僕は朝にこの1枚を開き、空欄に「採用」「却下」「保留」と書き込むだけです。判断に材料が要る項目は、見出しから元のファイルへ飛べるようにしてあります。

読む場所を1カ所にして、書く量を一言にする。これだけで、散らばっていた判断待ちの回収が、朝の日課として成立するようになりました。

決定受信箱の作り方5ステップ

僕の実運用そのままの手順です。特別なツールは要りません。テキストファイルと簡単なスクリプトで作れますし、最初は手動運用でも成立します。

判断待ちを起票形式で書かせる

各自動化に、人間の判断が必要な項目を「判定: ____」の空欄1行で書き出させます。あわせて、どの仕組みの・どの案件の・どのファイルへ戻す判断かというメタ情報を添えます。空欄が「ここからは人間の番」という機械にも人間にも読める合図になります。

収集対象レジストリに自動化を登録する

受信箱が収集する対象を、一覧ファイルに1行ずつ明示的に列挙します。登録の無い自動化の判断は受信箱に載らず、構造的に人間へ届きません。僕の4日停止の原因はまさにこの登録漏れでした。新しい自動化を作ったら、レジストリへの登録までがワンセットです。

毎朝1枚の受信箱に集約する

レジストリの全対象から「判定: ____」の空欄を集め、1枚のファイルに整形して毎朝届けます。冒頭には件数・最古の滞留日数・滞留中央値を表示します。僕はこの集約をコマンド1回の自動処理にしていますが、最初は朝の手動集めでも十分です。

記入した判定を各正本へ書き戻す

人間が空欄を埋めたら、その値を各仕組みの元ファイルへ書き戻します。僕は検証、反映、照合の3段階を通し、書き戻しに失敗した判定は消さずに翌朝の受信箱へ「未反映」として再掲する設計にしています。記入したのに反映されない事故が、いちばん運用の信頼を壊すからです。

滞留日数を計測する

起票から判定までの日数を測り、受信箱の冒頭に常時表示します。滞留中央値が伸び始めたら「判断が難しくなった」ではなく「仕組みのどこかが壊れている」合図として扱い、経路から点検します。

最初の一歩は「起票形式を決める」だけでいい

5ステップを初日に全部作る必要はありません。効果が大きいのは①の起票形式の統一です。「判定: ____」というたった1行の書式を全部の自動化で揃えるだけで、判断待ちは機械で集められる対象に変わります。集約を毎朝決まった時刻に走らせたくなったら、定時実行の組み方はClaude Codeの定時実行の記事にまとめています。

運用の原則。判断そのものはAIに代行させない

最後に、この仕組みを回すうえで一番大事な原則を書きます。

承認の代行と、承認フローの自動化は別物

「承認フロー自動化」と検索する人の一部は、承認そのものをAIに任せて手離れさせたいはずです。僕はそれをやりません。僕の受信箱の運用規約には、最初にこう書いてあります。

判定の代行禁止。人間が書いた、言った判定だけを転記する。値は発話から一字一句。

AIがやってよいのは、判断待ちを集めること、人間の判定を一字一句そのまま運ぶこと、書き戻した結果を照合することまでです。AIが「たぶん採用だろう」と空欄を埋め始めた瞬間、受信箱は承認フローではなく、ただの事後報告に変わります。自動化してよいのは判断の「届け方と回収」であって、判断そのものではない。これがこの記事の結論です。