AIに任せる前に、戻せるようにする｜「作っていいですか」を減らす条件は1つだけ

「こういうツールを作ってもいいですか」と部下から相談が来る。中身を聞いて、方向性を確認して、では進めてください、と返す。ここまでで数日かかることがあります。

そして、実際に作ってみると15分で終わる。相談していた時間のほうが、作る時間より長い。

AI活用が進んでいる会社と、止まっている会社の差は、ツールでもスキルでもなく、たいていここにあります。作るコストが劇的に下がったのに、作るコストが高かった時代の承認フローが、そのまま残っている。

この記事の要点

• 承認フローは「作るのが高くつくから、方向性を先に確かめる」ための仕組み。作るコストが下がると、確認のほうが高くつく逆転が起きる
• ただし「許可を取るな」は乱暴。減らしてよい条件はひとつだけで、元に戻せること
• 戻せる／戻せないの線は、社内か社外かではなく、外に出たか・お金が動いたか・消えたかで引く
• 戻せる状態は自然には手に入らない。変更履歴・退避と復元手順・機械の検品の3つを先に置く必要がある
• 当社は自社の自動化でこれを運用しており、実際に変更を丸ごと元に戻せる記録を全件分残している。戻せない領域（送信・公開・削除）は、いまも人が判断している

承認フローは「作るのが高い」時代の設計

そもそも、なぜ作る前に許可を取るのでしょうか。

作るのに1ヶ月かかるからです。方向性が違っていたら1ヶ月が消える。だから着手前に方向性を確認する。これは完全に合理的な設計でした。

いま、その前提が変わりました。方向性が違っていても、失うのは15分です。この状況で数日かけて方向性を確認するのは、費用対効果が逆転しています。しかも確認のために資料を作り、会議を設定し、決裁者の時間を使う。確認のコストのほうが、失敗のコストより高い。

だから、作ってしまったほうがいい。実物を見ながら「これは違う」と言うほうが、企画書を読みながら想像で判断するより、はるかに正確でもあります。

ただし、条件はひとつあります

とはいえ「許可を取らずに何でもやっていい」は、当然ながら危険です。

分かれ目はひとつだけです。元に戻せるかどうか。

• 社内の集計ツールを勝手に作り替えた → 気に入らなければ戻せる。先にやってよい
• 顧客に見積書を送ってしまった → 戻せない。先にやってはいけない

この線引きは、社内か社外か、という分け方とは少し違います。社内向けの操作でも、データを消してしまえば戻せません。判断材料は3つです。

現場のルールとしては、この4行を貼り出しておけば十分に機能します。「AI活用ガイドライン」を何十ページも作るより、判断できる粒度まで削ったほうが守られます。

「戻せる」は、放っておくと手に入らない

ここが実務のポイントです。戻せることは前提条件なのに、何もしなければ戻せません。

AIに作業を任せると、ファイルが書き換わります。そのとき、どこが変わったのかが分からない状態だと、気に入らなくても元に戻せない。「たぶんここを直したはず」で手作業で戻すことになり、結局こわくて任せられなくなります。

当社が自社の自動化で置いているのは、次の3つです。特別なものではありません。

1. 変更履歴を残す

何をいつ誰が（どのAIが）変えたのかを、差分の形で残します。開発の世界で長く使われている仕組みをそのまま使うだけです。これがあると、変更を確認してから採用するか決められるようになります。任せる範囲を広げられるのは、この一点があるからです。

2. 退避と復元手順をセットで書く

当社では、自動化の仕組みに手を入れるたびに、変更前のファイルを退避し、元に戻すためのコマンドを文章で残しています。「何をなぜ変えたか」と「戻し方」が同じ場所にある状態です。

一見おおげさですが、効果は逆方向に出ます。戻し方が書いてあるから、思い切って変えられる。戻せない変更は慎重にならざるを得ず、結果として何も変わりません。

3. 機械に検品させる

人が毎回チェックするルールは、忙しくなった週に必ず飛びます。だから、決まった条件のチェックは機械にやらせます。

当社の場合、日々の発信や更新が「本当に実行されたか」「記録に漏れがないか」を、プログラムが数えて判定します。ここで大事なのは、判定をAIにさせないことです。AIは解釈が入るので、都合よく「問題ありません」と言えてしまいます。機械は、条件を満たさなければ止まります。

それでも失敗はします

正直に書きます。この3つを置いていても、失敗はします。

当社では、毎朝の自動レポートがエラーも出さずに送信されなかったことがありました。途中までは正常に動いていて、最後の送信だけが空振りしていた。誰にも通知されず、指摘されるまで丸1日気づきませんでした。

このとき復旧が早かったのは、変更履歴と経緯の記録が残っていたからです。どの変更のあとに起きたのか、以前はどう動いていたのかを、記憶ではなく記録から辿れました。

そして直したのは、原因そのものよりも設計のほうでした。落ちたことを検知する経路が無かったことが本当の欠陥だったので、別のタイミングで走る処理が「今日、実際に送られたか」を検品する形に変えました。

戻せる状態を作るというのは、失敗しなくなることではありません。失敗しても、その日のうちに戻せることです。

「先に作る」を根づかせる進め方

いきなり全社で承認をなくすと、まず事故が起きます。順番があります。

1. 戻せる領域を、先に文章で決める。 上の4行の表で十分です。決めるのは決裁者の仕事です
2. その領域だけ、承認なしにする。 「この範囲は相談不要、やってから見せてください」と明示的に言う
3. 戻せる仕組みを先に入れる。 履歴・退避・検品。ここを飛ばして2だけやると、単なる無法状態になります
4. 戻せない領域は、これまで通り承認を取る。 ここを曖昧にしないことが、1〜3を守らせる担保になります

当社自身、送信・公開・削除といった戻せない操作は、いまも人が判断しています。自動化していないのではなく、意図してそこに線を引いています。

よくある質問

Q. 部下が勝手に作ったものが乱立して、収拾がつかなくなりませんか。

なります。ただしそれは、捨てる判断を誰もしていない場合です。作るのが安いということは、捨てるのも安いということです。使われていないものを定期的に消す時間を取れば、乱立は問題になりません。

Q. 履歴を残す仕組みを入れるのに、専門知識が要りませんか。

開発の現場で標準的に使われている仕組みをそのまま使います。操作は対話で済む範囲まで簡単になっているので、非エンジニアの方でも扱えます。当社の導入支援でも、最初に整えるのはここです。

Q. 「先に作る」は、うちの業界では受け入れられない気がします。

全社でやる必要はありません。戻せる領域だけです。むしろ、戻せない領域の承認をこれまでより厳格にする、という言い方のほうが通りやすいことが多いです。

Q. 承認を減らしても、決裁者の負担は変わらないのでは。

「作っていいですか」の相談は減りますが、出来上がったものを見る量は増えます。そちらは別の設計が要ります。判断に必要な粒度まで圧縮して届ける方法をAIで現場が速くなるほど、承認で詰まるにまとめています。