自動化して終わりが、一番危ない。ループエンジニアリングという次の一手
「毎日同じ通知が届くのに、何も変わっていない」。あるループが2週間、まったく同じ形式・同じ案件を朝の配信に乗せ続けたことがありました。処理はルール通りに完璧にこなされている。でも、改善は一切起きていない。この違和感に気づいたとき、僕は「自動化して終わり」がいかに危ういかを痛感しました。
もしかしたら、皆さんの会社にも「動いているけど、誰も見ていない通知」が既にあるかもしれません。今日はその正体と、僕が「ループエンジニアリング」と呼んでいる次の一手についてお話しします。
0. ループエンジニアリングとは、AIに答えさせず業務を前に進める設計思想である
まず言葉の定義から入ります。ループエンジニアリングとは、AIに「答えさせる」ことを目的にせず、業務そのものが人の手を介さず勝手に前へ進む仕組みを設計することだと僕は捉えています。
ChatGPTやGeminiは対話型の道具です。人が問いを立て、返ってきた答えを読み、また次の指示を出す。この往復が必ず要ります。正直なところ、これは便利な道具ではあるのですが、忙しい経営者や現場責任者は毎回この「起点」に立ち続けることができません。結果として、AIツールを契約したのに現場の業務は何も変わらない、という状態が起きます。これは多くの会社で実際に起きていることだと思います。
これに対してループエンジニアリングでは、「分析→改善案・実行案の提示→承認1クリック(人はここだけ、スマホで完結)→自動実行→AIによる採点→不足があれば再提案」という循環を仕組み化します。人が起点に立ち続ける必要はなく、判断が必要な一点だけに立ち会えばいい。これが僕らの考える設計の基本形です。
線引きの原則はシンプルです。事実の処理はAIに任せる。価値判断・関係性の配慮・タイミングの見極めは人が行う。取り返しがつく低リスクな処理は自動実行して事後報告に留め、対外送信や破壊的な書き込みなど、取り返しがつかない処理だけに承認ゲートを残す。承認もターミナルで待つようなものではなく、メールやスマホの1タップに畳み込みます。そして、すべてのループの配信は朝の一つの時間帯に集約する。ばらばらに通知が来ると、結局どれも見なくなるからです。
この思想の原点は、面接ステータスの毎朝ダイジェストだった
この設計思想にたどり着いたきっかけを、少し個人的な話として共有させてください。
きっかけは、面接ステータスの毎朝ダイジェストでした。誰の対応がボールを持っているのか(企業側か求職者側か)、面接予定はどうなっているか、結果待ちのまま停滞している案件はないか。これが毎朝1通のメールで見える状態を作ったところ、業務全体が自律的に駆動し始める感覚がありました。
人が能動的に「今日は何を確認しよう」と考えなくても、見るべきものが向こうからやってくる。この体験が、僕にとってループエンジニアリングという発想の出発点になっています。
応募承諾から推薦までの滞留は、担当者の頭の中にしか理由がなかった
原点となった具体的な事例をひとつご紹介します。応募承諾から書類推薦までの滞留です。
この区間は、なぜ止まっているのかという理由が担当者の頭の中にしか存在しない、という構造的な問題を抱えていました。実データを見て気づいたときには、73日間、書類が未回収のまま放置されているケースがありました。担当者に悪意があったわけではなく、単に「見えていなかった」だけです。
そこで、毎朝7時と夕方18時の2回、応募承諾のまま推薦されていない全件をスナップショットとして洗い出し、配信する仕組みを作りました。
ここで一つ、設計上の失敗と修正の話をさせてください。当初は、記録システム上の「レジュメ回収状況」という管理項目を見て判定していました。しかし、これは人が手で入力する項目である以上、実態とズレていくものだと分かりました。人が入力する管理項目は、遅かれ早かれ形骸化します。これは僕自身、痛い教訓として受け止めています。
そこで、添付ファイルの実体をAPIで直接読み、ファイル名から書類の有無を断定する方式に切り替えました。結果、それまで「未回収の可能性24名」という曖昧な判定だったものが、「未登録4名」という正確な数字に変わりました。誤って未登録扱いされていた候補者が救済されたのも、この切り替えの成果です。
効果としては、最長73日という放置滞留を検出できたこと、そして以降は毎日2回、全件が滞留日数順に可視化される状態になったことです。対応が進めば、その案件は自然にリストから消えていく。つまりリストそのものが、無言の催促として機能するようになったわけです。
ルール通りに処理できても、改善していないことがある
ここからが今回の本題です。
先ほど触れた「2週間、同じ形式で同じ案件を提示し続けたループ」の話に戻ります。このループは、ロジックとしては何も間違っていませんでした。決められた条件で対象を抽出し、決められたフォーマットで通知する。処理という意味では完璧です。
しかし、2週間経っても状況は一切変わっていませんでした。実態を調べてみると、原因は通知の宛先そのものが間違っていたことでした。企業側の管理アカウントがそもそも発行されていなかったのです。つまり、承認や対応の起点が本人側ではなく企業側にあるはずの案件なのに、システムはその前提を織り込めていなかった。
これは「催促する相手を間違えていた」という、設計思想そのもののズレでした。僕はこれを見て、システムとAIの違いを強く意識するようになりました。システムはロジックで固定されます。決めた通りにしか動きません。しかしAIは、工夫できる存在です。同じ通知を出し続けるのではなく、「なぜ効かないのか」を考え、宛先や手段そのものを見直すことができる。この違いこそが、ループそのものを監査対象にすべき理由だと考えています。
正直に言うと、「毎日同じ通知が届く」という状態は、3日もすれば風景になります。人は同じ刺激に慣れる生き物です。だからこそ、通知を出し続けること自体を成果とせず、「その通知が本当に状況を動かしているか」を定期的に疑う仕組みが必要になります。
ループの監査は3層で考えると整理しやすい
では、どうやってループそのものを監査対象にするか。僕は次の3層で整理しています。
1. 風景化の検知 同じ案件や同じ文面が7日以上ほぼ同一の形で出続けていないか。通知に対して、一度も状態変化が起きていないケースはないか。週次レポートの中身が前週とほとんど同じになっていないか。0件通知やエラーが黙殺されたまま常態化していないか。こうした兆候を、毎週チェックする仕組みを組み込みます。これは人が気合いで気づくものではなく、ループ自身に組み込んでおくべき点検項目だと考えています。
2. 根本原因の特定 風景化の兆候が見つかったとき、表面対応で満足しないことが重要です。通知を止める、文面を変える、といった対症療法だけで終わらせない。なぜ動かないのか。通知の宛先・手段・タイミングはそもそも正しいのか。その通知は本当に必要なのか。しきい値や検出キーが現実の業務とズレていないか。ここを一段掘り下げます。先述の「企業側の管理アカウント未発行」というケースは、まさにこの深掘りをして初めて見えた原因でした。
3. ループ自体の改変 原因が特定できたら、改変します。文面・しきい値・頻度・分類ロジックの変更といった低リスクな改修は、その場で実施し事後報告に留めます。判断のスピードを止めないためです。一方で、本番機能の停止や社外送信を伴う変更、破壊的な書き込みは、事前確認を残す。ここは自動化しません。
この3層を回すことで、ループは「一度作って放置するもの」から「作り続けるもの」に変わります。
自動化のゴールは、稼働することではなく効いていることである
結論から言うと、自動化して終わり、というのが一番危ない状態だと僕は考えています。通知が出ている、レポートが届いている、処理が動いている。この状態を見て「うまくいっている」と判断してしまうのは、実は一番のリスクだと思います。
処理の完璧さと、改善の実現は、まったく別の軸です。ルール通りに動くことは前提であって、成果ではありません。そのループが本当に状況を動かしているかどうかは、別途、定期的に問い直す必要があります。
もちろん、すべてのループを常に人手で見直し続けるのは現実的ではありません。だからこそ、風景化の兆候を検知する仕組み自体をループに組み込み、根本原因の深掘りと低リスクな改修はその場で回し、不可逆な変更だけ人の承認を残す、という設計にしています。個人的には、この線引きが「AIに任せる範囲」と「人が見るべき範囲」を最も現実的に分けるラインだと考えています。
誤解がないように申し上げると、これは技術の話であると同時に、組織の姿勢の話でもあります。通知が出ていることに安心せず、「このループは今も効いているか」と定期的に問い直す姿勢そのものが、ループエンジニアリングの本体だと思っています。
最後に、皆さんいかがでしたでしょうか。自動化は始まりであって、ゴールではありません。ループそのものを監査対象にする視点を、ぜひ一度、御社の仕組みにも当てはめてみていただければと思います。
※当社の採用・人事組織系支援にご興味がある方はお気軽にお声掛けください。
---
この後、`ai-smell-remove`や`brand-check`スキルで仕上げチェックをかけるか、このまま使うか、ご判断ください（自動では走らせていません）。