AIによる業務自動化の事例を探すと、「何ができるか」の一覧はすぐ見つかります。ところが、それを実際に本番の業務に載せる段になると、まったく別の問題が出てきます。
自動化で本当に怖いのは、動かないことではありません。間違った相手に対して、正しく動いてしまうことです。この記事では、当社が自社サイトの運営で実際に動かしている4つの自動化——すべてClaude Codeで作ったもの——と、それを本番に載せるために入れた3つの安全装置を書きます。後者が本題です。
結論｜「気をつける」ではなく「間違えられない形」にする
自動化を業務に載せるとき、事故は必ず「気をつけていたのに」という形で起きます。人間の注意力で防ぐ設計は、忙しい日に必ず破れます。
- 送信先が想定と違ったら、処理そのものを止める
- 実行の入口を1つに固定して、別の環境で動く経路を消す
- 触ってほしくない項目は、そもそも送信内容に含めない
3つとも、当社が実際に事故を踏みかけてから入れたものです。先に、何を自動化しているのかを簡単に書きます。
なお、ここで使っているClaude Codeそのものが何なのかは、Claude Codeとは？非エンジニア・経営者向けに、仕組みと「自社で使えるか」まで解説で先に説明しています。
何を自動化しているか（4つ）
どれも特別なものではありません。毎週発生する、手順の決まった作業です。4つともClaude Codeで作り、今も毎週動いています。
- 記事に入れる画像を自動で作り、記事の該当位置に差し込む｜絵柄の指定を1か所にまとめてあるので、誰がやっても雰囲気が揃います
- アクセス解析の数字を、毎回同じ形で取ってくる｜手で拾うと、先月含めた項目を今月忘れる、といったブレが出ます
- 検索キーワードの需要を調べて表に書き出す｜書こうとしたテーマの関連語を17個測って全部ゼロだった、という「書かない判断」が数十分で出せます
- 書き上げた原稿を、下書きとしてサイトへ投稿する｜公開はしません。理由は安全装置3で書きます
選ぶ基準として1つだけ挙げるなら、「間違えても取り返しがつく作業から始める」ことです。最初の題材で本番データを壊すと、社内の空気が終わります。
安全装置1｜送信先が本番でなければ、1バイトも送らずに止める
当社は、本番のサイトとは別に、構築用の環境を持っています。設定を間違えて、本番向けの更新処理を別の環境へ送りかけたことがありました。逆方向であれば、本番を壊していた事故です。
いまは、更新処理を実行する直前に「これから接続しようとしている先が、想定した本番のアドレスか」を機械的に照合しています。違っていたら、そこで中断します。1バイトも送りません。
重要なのは、これが「確認画面を出す」ではないことです。確認画面は読み飛ばされます。照合して、違ったら処理そのものを止める。人間が判断する余地を残さないのが要点です。
自社に置き換えるなら、「本番の顧客データベースに書き込む処理が、テスト用に向いていないか」を実行前に照合するのと同じ話です。宛先を持つ処理には、ほぼ例外なく必要になります。
安全装置2｜実行の入口を1つに固定する
複数の事業や複数のアカウントを扱っていると、別の会社の環境で処理が動いてしまうという事故が起こり得ます。実際、当社は別事業のアカウント設定を掴んだまま画像生成を走らせかけたことがあります。
対策は単純です。処理を直接呼び出せないようにして、専用の入口を1つだけ用意しました。その入口が、使うアカウントと設定の置き場所を毎回固定します。直接呼び出す経路は、使わないというルールではなく、通っても正しい設定が当たる形にしてあります。
これも「気をつける」を設計に置き換えた例です。「実行前に環境変数を確認する」という運用ルールにしていたら、確実にいつか忘れます。入口を1つにすれば、忘れる場所がなくなります。
自社の業務で似た構造がないかは、実際の流れを見れば分かります。30分・無料・オンライン可の個別相談で、自動化したい業務を3つ挙げていただければ、必要な安全装置まで含めて整理してお返しします。売り込みはしません。
安全装置3｜公開状態を、送信内容に含めない
3つ目が、いちばん見落とされます。
記事を更新する処理は、記事の情報をまとめて送るのが普通の作り方です。ところがその「まとめて」の中に公開・非公開の状態が含まれていると、本文を直すだけのつもりで、下書きが公開されます。
だから、更新処理が送る項目を「本文」と「画像の指定」だけに絞りました。公開状態は送りません。送らなければ、変わりようがありません。
この考え方は応用が利きます。「触ってほしくない項目は、権限で守るのではなく、そもそも送信内容から外す」。権限設定は複雑になりがちですが、送らないという判断は単純で、後から読んでも意図が分かります。
顧客データで言えば、住所を更新する処理に契約状態の項目を含めない、といった話です。含めた瞬間、いつか誰かが意図せず書き換えます。
3つに共通していること
並べてみると、3つとも同じ発想でできています。
- 注意力に頼らない。ルールで守るのではなく、間違えられない形にする
- 確認画面を増やさない。確認は読み飛ばされる。止めるなら処理そのものを止める
- 危ないものは、権限で守るより「渡さない」。渡さなければ壊れません
逆に、やらなかったことも書いておきます。細かい権限設定を作り込むことはしていません。小さな組織では、権限表そのものが複雑になって、誰も正しく保てなくなるからです。「送らない」「入口を1つにする」のほうが、後から読んで意図が分かります。
自社で入れるなら、どこからか
3つ全部を最初から入れる必要はありません。優先順位は、壊れたときの被害の大きさで決まります。
- 宛先を持つ処理があるなら、安全装置1を最優先。書き込み先を間違える事故が、いちばん被害が大きい
- 複数の事業・環境を扱っているなら、安全装置2。1つの環境しか無い会社は後回しで構いません
- 外部に見える状態を持つものを触るなら、安全装置3。公開・非公開、送信済み・未送信など
どれも、作るのは難しくありません。難しいのは、事故を踏む前に入れておくと決めることです。当社は3つとも、踏みかけてから入れました。
よくある質問
小さい自動化にもここまで必要ですか？
判断基準は規模ではなく「壊れたとき、元に戻せるか」です。手元のファイルを整形するだけなら不要です。外部に書き込む処理なら、小さくても宛先の照合は入れてください。
プログラミングができなくても入れられますか？
「何を止めるべきか」を決めるのは業務側の判断なので、そこは自社で決められます。実装は日本語で指示しながら進められますが、最初の1つは分かる人と一緒に入れたほうが安全です。
安全装置を入れると、自動化の効果が落ちませんか？
落ちません。3つとも、正常時には何も起きない仕組みです。処理が遅くなることも、手作業が増えることもありません。効果が落ちるのは、確認画面を増やしたときです。
まとめ
- 自動化で怖いのは動かないことではなく「間違った相手に正しく動いてしまうこと」
- 安全装置1｜送信先が想定と違ったら、1バイトも送らずに処理を止める。確認画面ではなく中断にする
- 安全装置2｜実行の入口を1つに固定し、別環境・別アカウントで動く経路そのものを消す
- 安全装置3｜公開状態のように触ってほしくない項目は、権限で守るより送信内容から外す
- 共通するのは「気をつける」を設計に置き換えること。注意力で防ぐ設計は忙しい日に破れる
- 優先順位は壊れたときの被害の大きさで決める。宛先を持つ処理があるなら1から
自動化したい業務と、そこに要る安全装置は、実際の業務を見れば決まります。30分・無料・オンライン可の個別相談をご利用ください。
まずは30分、無料の個別相談で整理しませんか
30分・無料・オンライン可・売り込みなし。気になっている業務を3つ挙げていただき、その場で「AIに置き換わる／半分楽になる／向かない」に仕分けしてお持ち帰りいただきます。
テレビ・新聞で取り上げられました
