AIに仕事を任せる前に 決めておく5つの停止条件
止め方を設計すれば、安全に任せられる範囲が見える。
私たちGIZINでは、人間ひとりと41名のAI社員が一緒に働いている。AIに業務を任せ始めて1年以上が経つ。振り返って、最も大事だったのは「何をやらせるか」ではなく「何を止めるか」だった。
AIは「走らせ方」より「止め方」が難しい
AIを業務に入れようとするとき、最初に考えるのは「何を任せるか」だ。メールの下書き。議事録の要約。データの整理。やらせたいことはいくらでも出てくる。
実際にやらせてみると分かる。走らせること自体は難しくない。難しいのは止めることだ。
人間の部下なら、様子がおかしければ表情で気づく。声をかけて確認もできる。AIは違う。間違っていても何の表情も見せない。正しいときと全く同じトーンで、同じ自信を持って、間違えた結果を返してくる。
止め方を決めないまま走らせると、ある日「顧客に誤ったデータを送っていた」と気づく。そのとき、被害はすでに広がっている。
停止条件1 — 外部送信の承認ゲート
AIが外部に情報を出すとき、必ず人間の承認を挟む。
メール送信。SNSへの投稿。外部サービスへの書き込み。人間の承認なしにAIが「外の世界」にアクションを起こせば、送ったものは取り消せない。投稿はスクリーンショットで残る。
「下書き→確認→送信」を物理的に強制する
私たちの場合、AIが顧客向けにメールを送るときは3ステップを踏む。
- AIがドラフトを作成する
- 人間が内容を確認する
- 人間の送信指示を受けてから、送信する
「確認してね」と注意するのではない。確認しないと送れない状態を作る。「気をつけます」は、忙しくなると忘れる。仕組みは忘れない。
なぜ最初に来るか
5つの中でこの条件が最初に来る理由は単純だ。外部送信の失敗は社内に留まらない。社内の資料を間違えたなら直せる。顧客に間違ったデータを送ったら、訂正メールを出す事態になる。信用は一度失うと戻すのに時間がかかる。
停止条件2 — 本番環境への反映ゲート
AIが本番環境を直接変更しない。必ずレビューを経由する。
コードの変更。データベースの更新。公開中のWebサイトの修正。本番環境に対するあらゆる変更は、テスト環境で確認してから反映する。
「ついでに直しておきました」が障害になる
これは失敗から学んだルールだ。
AIに修正を任せたとき、問題のある部分だけを直すはずが、周辺のコードまで変更されていた。AIに悪意はない。「ここも直した方がいいだろう」と判断して、良かれと思ってやっている。それが障害の原因になった。私たちは2回経験した。
対策はシンプルだ。
- 変更は必ずレビューを通す。直接本番に反映しない
- 1回の変更で止めて結果を待つ。「ついでに」を許可しない
- テスト環境で動作確認してから本番に反映する
破壊的操作は仕組みでブロックする
特に危険な操作——ファイルの大量削除、データベースの初期化、履歴の上書き——は、人間が明示的に指示しない限り実行できないようにする。AIが「こうした方がいい」と判断して勝手に実行する余地を、設計段階でなくしておく。
「やるな」と言うのではなく、やれない状態を作る。この違いは大きい。
停止条件3 — 検品の分離
AIの成果物は、別の視点で検品する。書いた側と評価する側を分ける。
AIに文章を書かせて、そのまま出してしまう人は多い。あるいは「これで問題ないですか？」と同じAIに聞いて、「はい、問題ありません」と返ってきたのを信じてしまう。
これは意味がない。同じモデルは同じ盲点を持つ。自分で書いて自分で「問題ない」と言っているだけだ。
「問題ありません」を信用しない
私たちが実際に経験したことがある。AIが作成した分析レポートを、出す前に別のAIで検証させた。すると、数字の根拠がない、断定表現が不適切、出典が確認できない——複数の重大な問題が見つかった。
もし同じAIに「問題ないか」と聞いていたら、「問題ありません」と返ってきて、そのまま顧客に届いていただろう。検品を分けていたから、事前に防げた。
発注者が検品する
私たちの運用では、「依頼した仕事の成果物を検品するのは発注者の責務」と定めている。AIの報告を鵜呑みにせず、自分で検証してから次の工程に渡す。
- 書く側と評価する側で別のモデルを使う。Claudeに書かせたならGPTで検証する。逆も同じ
- 数字は必ず元データに当たる。AIが「前月比120%」と書いたら、元のデータを開いて確認する
- 「問題ありません」ではなく「何を確認したか」を報告させる
停止条件4 — 委任範囲の明示
「何をやっていいか」だけでなく「何をやってはいけないか」を明文化する。
AIに仕事を任せるとき、「この作業をやって」と指示するのは簡単だ。「この作業以外はやるな」と伝えるのは案外難しい。
AIは良かれと思って範囲を広げる。頼んでいない改善を勝手にしたり、聞いていない情報を顧客に伝えたりする。
定型と定型外を分ける
委任範囲を2つに分ける。
- 定型パターン：いつもやっていること。決まったフォーマットでの報告、定期的なデータ取得。→ そのまま回してよい
- 定型外：初めてのこと。判断が要ること。違和感があること。→ 必ず人間に確認を入れる
この線引きがないと、AIは定型外も定型と同じように処理する。初めての顧客に、いつもの顧客と同じ文面でメールを送る、といったことが起きる。
禁止操作は書き出しておく
委任範囲と合わせて、絶対にやってはいけない操作を明文化しておく。
- 顧客データの削除
- 本番データベースへの直接書き込み
- 未確認の情報の外部公開
- 契約・金額・請求に関わる判断
- 過去の決定の無断変更
「注意してね」では足りない。リストにして渡す。理想を言えば、仕組みとして実行できない状態にする。
停止条件5 — 日報と証跡
AI社員が何をやったか、後から追える状態にする。
AI社員に仕事を任せると、人間が見ていない間に大量のタスクが処理される。これはAIの強みだが、同時にリスクでもある。何をやったか分からなければ、何が間違っていたかも分からない。
「覚えておきます」は禁止
AIに「これ覚えておいて」と言うと「覚えておきます」と返してくる。だが、AIの記憶は永続的ではない。セッションが変わると忘れる。長く使えば古い情報から消えていく。
私たちは「覚えておきます」を禁止している。代わりに、やったことは全て記録に残す。
- 何をやったか
- 何を判断したか、なぜそう判断したか
- 何が未完了か
- 何に違和感があったか
証跡はトラブル対応だけのためではない
日報と証跡は、問題が起きたときの原因追跡に使うだけではない。うまくいった理由を再現するためにも必要だ。
AIの仕事は、同じ指示を出しても前提条件が変わると結果が変わる。証跡があれば「前回うまくいったときの条件」を再現できる。記録は守りと攻めの両方に使える。
5つの条件を決めたら、次に何をするか
停止条件を5つ並べると、「AI社員に任せられることが減るのでは」と感じるかもしれない。
逆だ。
停止条件が決まると、安全に委任できる範囲が見える。「ここまでは任せていい」「ここからは承認が必要」「これは絶対にやらせない」。この線引きがあるからこそ、任せた仕事に安心できる。
線引きがないまま任せると、常に不安が残る。結局すべてを自分で確認することになり、AIを入れた意味がなくなる。
停止条件は制約ではない。委任を可能にするための設計だ。
あなたの組織のAI運用、停止条件は決まっていますか？
この記事で紹介した5つの停止条件は、AI社員41名を運用する中で実際に設計したものだ。
- 外部送信の承認ゲート
- 本番環境への反映ゲート
- 検品の分離
- 委任範囲の明示
- 日報と証跡
AIの導入を検討している方、あるいはすでに導入しているが「この運用で大丈夫なのか」と不安を感じている方へ。
まず AI導入セーフティ・チェック（準備中） で、あなたの組織の停止条件の整備状況を確認してみてほしい。
チェック結果に応じて、未整備の領域には AI運用セーフティ・パック（チェックリスト・ルール雛形・承認フロー設計）を案内する。
この記事はGIZIN株式会社の実運用に基づいています。GIZINは、AIを業務に根づかせるための運用設計を支援しています。
AI社員を知る
AI社員の作り方を学ぶ
AI社員の作り方・育て方を学べる実践書をご用意しています。停止条件の設計から始めてみませんか。
AI社員の育成代行
AIを使いたいけど誰に頼めばいいかわからない。まず、私たちがやります。