その日のあらすじ
三つのサービスを AI エージェントと開発してきた半年分の記録から、実際に壊れた事故と、そのとき足した対策を集めました。並べ直して分かったのは、壊れやすさを分けていたのが作業の難しさではなく、三つの条件だったことです。三つとは、後から戻せる作業かどうか、出来た成果を人手を借りずに確かめられるかどうか、そして AI に必要な文脈が届いていたかどうか、です。この記事では、条件ごとに実際の事故と対策を見て、三つが同時に悪いときに何が起きたか、外部の研究がこの見分け方をどう裏づけているか、そしてこの見分け方が届かない領域まで書きます。
三つの条件で、壊れやすさが見分けられた
なぜある作業は AI に任せてもすんなり終わり、ある作業は任せたせいで重く壊れるのでしょうか。それが知りたくて、去年の暮れから今年の盛夏までのおよそ半年強、三つのサービスの開発で起きた事故と、事故のたびに足した対策の記録を並べ直してみました。すると、壊れた側の作業には共通の形がありました。後から戻せない操作を含んでいたか、守れたかどうかを機械で確かめられない約束に頼っていたか、判断に必要な文脈が AI に届いていなかったか、のどれかです。逆に、三つがそろっている作業は、任せてもほとんど壊れていません。
先に断っておくと、これは僕の三つのサービスの記録を数え直した観察であって、壊れた件数と壊れなかった件数を厳密に集計した統計ではありません。それでも、事故の記録を読み返すほど、この三つで壊れ方がほぼ説明できてしまうのです。順に見ていきます。
戻せる作業と、戻せない作業
いちばん重い壊れ方は、戻せない操作で起きました。実例を一つ挙げます。外部の非同期のコーディングエージェントが、古い状態の本流から派生したまま複数の変更を統合してしまい、直前に取り込まれていた五つ分の変更がまるごと消えたことがあります。復旧は、問題の変更をまとめて取り消して消える前と等価な地点へ戻し、取り込む価値のある部分だけを別の変更として作り直し、検査の一式を全部通してから確定する、という手順になりました。以後、統合の前に、派生元が本流の最新を含んでいるかを差分で確かめる運用にしています。
もう一つの型は、作業ディレクトリの取り違えです。AI は隔離した作業用のコピーで働く決まりなのに、指定を誤って、主たる作業コピーへ状態を変える git のコマンドを実行してしまう事故が繰り返し起きました。ここで効いたのは、規約に書いて守らせることではありません。同じ事故は規約を書いた後も再発しました。だから、AI が道具を呼び出す一つ手前に、隔離したコピーの指定が無い状態変更のコマンドを機械的に拒否する仕組みを入れました。読み取りだけのコマンドと、本流に追いつくための取り込みは通します。人が意図して行う修復は、これまでどおり手でできます。似た発想で、破壊的な初期化ややり直しの前には、作業ツリーに未保存の変更が無いことを確かめる決まりも足しました。未保存の作業を消すのは、戻せない事故の典型だからです。
まとめると、戻せない操作は、人が気をつける約束では止まりませんでした。機械的に止めるか、戻せる形に作り替えてから渡すか、のどちらかが要ります。
確かめられる作業と、確かめられない作業
二つ目の条件は、AI が約束を守れたかどうかを、人の目や AI の自己申告に頼らずに確かめられるか、です。
守れたかを機械で確かめる形に作り替えた作業は、壊れにくくなりました。たとえば、利用者の端末のローカル以外へデータを流さないという設計の原則を持つアプリでは、原則を文書に書くだけでなく、許す保存先を三つに限り、それ以外の永続層や既知の外部の保管サービスへの送信がコードに紛れ込んでいないかを検査で止めています。面白いのは、検査自身が壊れていたら誰も気づけない点で、そのために、わざと引っかかる見本を仕込んで検査が本当に反応するかを検査させる段も入れました。別のサービスでは、再現を禁じられた参照資料の本文が読者の画面へ流出しうる経路を、AI のタグ付けの正しさにもデータの値の正しさにも依存しない実装の側のガードで塞ぎ、分類が不明なときは安全側へ倒すようにしました。失敗する検査を先に書いてから、それが通るまで直す順序で確かめています。
確かめられない作業は、逆の壊れ方をしました。性能改善を提案する自動のエージェントは、同じ主題について、少しずつ違う直し方の提案を出しては引っ込め、を何度も繰り返しました。対策は、性能改善の変更に改善前と改善後の実測値を必須にしたことです。観測できるはずだという主張だけでは通しません。あわせて、既に守りがある箇所へ守りを重ねるだけの変更は事前の確認を義務づけて止め、本物の仕組みを検証しない見せかけのテストも禁じました。
外部の議論にも、同じ向きの注意があります。AI の申告する確信度は当てにならず、九割の確信だと言っているのに実際の正答は七割五分ほどだった、という観測が公開されています。守れたかどうかは、申告ではなく検査で確かめるしかありません。
文脈が届いた作業と、届かなかった作業
三つ目の条件は、判断に必要な文脈が AI に届いていたか、です。ここの壊れ方は、指示のうまさとは別のところで起きます。
外部の非同期のコーディングエージェントは、規約に反する変更を量産したことがあります。原因を追うと、取り込まずに閉じたときのレビューの指摘が、次に別の作業を受ける同じエージェントには届いていませんでした。対策は、エージェントが作業の開始時に必ず読む場所へ、規約そのものを直接書き込むことです。読む宣言を推奨から必須へ上げ、前に閉じられた同種の変更の理由の参照も義務づけました。
規約を守ったのに壊れた例もあります。あるモバイルアプリの開発では、本流への取り込みの後に開発サーバを立て直す決まりを各セッションが真面目に守った結果、複数のセッションが同じポートを奪い合い、互いを落とし合う衝突が起きました。全員が規約に従い、全員が互いを置き去りと認識して、悪循環になったのです。誰か一人が悪いのではありません。共有の資源では、各自の文脈だけでは全体の衝突を避けられない、という構造の問題でした。立て直しは自動の責務から外し、人が明示に指示したときだけ、他のセッションの分が立っていないかを確かめてから起動する形にしています。
自然文の意味の取り違えも、この条件に入ります。あるアプリに、利用者が自然な文で書いた希望を、検索の絞り込みの条件へ変換する機能があります。そこで、人目を気にせず静かに過ごしたい、という希望が、家族向けでゆったり、という正反対の条件に変換されたことがありました。書かれていない概念を、AI が補ったつもりで勝手に足したのが原因です。この作業はやり直せますし、結果も画面ですぐ見えます。それでも、希望の文の意味という文脈が曖昧なだけで壊れました。直しは二つです。希望の意味だけを忠実に言い換えて、書かれていない概念を足さない、と指示を変えました。そして、静かに過ごしたい、と、家族向けでにぎやか、のような取り違えやすい正反対の組を、具体例としてプロンプトへ足しました。
古い情報をつかんで壊れた例もあります。隔離した作業コピーを切ったのに、起動時の古い主たる作業コピーを調査で読んでしまい、ある機能が無いと繰り返し誤って判断した事故です。以後、コピーを切ったら読み取りも含めて対象をその配下に限る決まりにしました。
三つが同時に悪いとき
最も重い事故は、三つの条件が同時に悪い側にあるときに起きました。外部サービスとつながる登録の口を、実在しうる形式のアドレスで検証してしまい、見ず知らずの相手へ確認のメールが本当に送られたことがあります。送ってしまったメールは取り消せません。成否を安全に確かめる手段も乏しく、実在しうるアドレスという危うさも文脈として届いていませんでした。以後、外部への副作用を起こす口を叩くときは、実在しうるドメインを絶対に使わず、まず管理画面で副作用の機能そのものを一時的に止め、それが無理なときだけ規格で届かないと決められた予約済みのドメインを使う、という手順を、毎セッションが必ず読む場所の絶対の決まりにしています。
外での議論と、この見分け方が届かないところ
この三条件は、僕の発明ではありません。日々の実務の中で見つけ直したものが、外部の議論とそのまま重なっていました。2026 年 2 月に公開された委譲の枠組みの論文は、AI への委譲の適否を、取り消せるか、独立に検証できるか、意図と役割と境界が明確か、判断の重大さはどうか、という相互に働く条件で整理しています。僕の三条件は、このうち可逆性と検証可能性と文脈の明確さに対応します。取り消せることは承認を省く十分条件にならない、承認の判定は AI に実行時に交渉させず実行の層で機械的に強制すべきだ、という外部の設計論も、僕が事故の後に置いた対策と同じ向きでした。
一方で、この見分け方が届かない領域もあります。価値判断や倫理に関わる主観的な作業は、そもそも明確に仕様へ落とせず、検証の枠組みの外に出ると、先の論文も明示しています。前例のない新しい場面も、同じたぐいに置けるだろうというのが僕の考えです。三条件は、当てはめれば必ず答えが出る公式ではありません。
それでも、AI に任せて壊れるかどうかは、任せる前にだいたい見当がつきます。だから僕は、壊れやすい作業ほど、壊れても戻せる形と、壊れたと機械で気づける形へ、任せる前に作り替えてから渡すようにしています。繰り返しますが、これは半年分の観察であって、法則として証明したものではありません。母数も多くありません。それでも、任せる前にこの三つを問うだけで、重い事故はかなり手前で避けられるはずです。あなたの現場の記録ではどう見えるか、いつか持ち寄れたらうれしいです。
参考にした研究
- Tomašev, Franklin, Osindero「Intelligent AI Delegation」arXiv 2602.11865 (2026-02-12)
- digitalapplied「Human-in-the-Loop Escalation Design for AI Agents」(2026-06-07)