AIに環境の監視を任せて分かった、検知と修復の間にある境界線

概要

Claude Codeに自分の開発環境の安全チェック・自動バックアップ・全体の棚卸しを任せる場面が増えてきました。「壊れていないか確認して」と頼めば、設定や記録を実際に見に行って報告してくれます。

ただ、この数週間で同じパターンの壁に3回ぶつかりました。共通していたのは、「問題を見つけるところまではAIが正確にたどり着けるが、直す最後の一手には必ず人間の実行が要る場所が残る」という構図です。

技術的な話に見えますが、根っこは「AIにレビューしてもらっても、直すのは結局自分の作業になる」という、レビューや確認をAIや他者に任せている人なら誰でも心当たりのある感覚だと思います。

事例1: 警告は鳴っていたが、直す材料がなかった

週次の安全チェックが、AIの操作範囲を安全な範囲に閉じ込めておく仕切り(サンドボックス相当の設定)が外れていたことと、危険な操作を止めるための禁止コマンドリストが大量に消えていたことを検知していました。しかも最初に見つかった週から3週連続、同じ内容のまま警告が鳴り続けていました。

原因を追わせたところ、その設定ファイル自体が変更履歴を残す仕組み(バージョン管理)の対象から外れていたことが分かりました。警告は出せても、いつ・何が原因で消えたのかを追跡する記録がどこにも残っていなかったわけです。

# 設定ファイルがバージョン管理の対象に入っているか確認する
git ls-files --error-unmatch path/to/settings.json 2>&1 \
  || echo "[WARN] このファイルはバージョン管理外です"

禁止コマンドリストは一部を復元できましたが、控えがない項目は復元できませんでした。警告を出す仕組みと、原因を追跡できる仕組みは別物だと痛感した事例です。監視対象の設定ファイルほど、変更履歴を残す仕組みの対象に入れておく必要があります。

さらに、今回の状態を「正しい状態」として記録し直す操作は、AI自身の安全装置が「監視の基準そのものを書き換える操作」として自動的に止めました。妥当な挙動だとは思いますが、結果として最後の1コマンドは自分のパソコンから直接実行する必要がありました。

事例2: 直したはずが、実行そのものが途中で止まっていた

設定ファイル一式を自動でバックアップする仕組みも、ファイルを1つ書き換えた日から3日間、誰にも気づかれずに止まっていました。

原因は、実行前に「本当にやりますか」と確認を求める画面が1つ挟まっただけで、そのあとに続くはずだった一連の処理が丸ごと巻き添えで止まっていたことです。1つの確認プロンプトが、後続処理全体を止めるボトルネックになっていました。

AIに直させたあとも、もうひと展開ありました。「実行した」と報告があったのに、バックアップ先の中身は変わっていなかったのです。調べると、直前にお願いした削除操作がAIの操作できる範囲の外だったために実行できず、その後に続くはずだったバックアップ処理まで一緒に止まっていたことが分かりました。

# 「コマンドが完了した」だけでなく、対象ファイルの更新有無まで確認する
find backup_dir -newer expected_source -type f
# 何も出力されなければ、バックアップは実際には走っていない

「実行完了」というログの報告を鵜呑みにせず、期待した副作用(この場合はバックアップ先のファイル更新)が実際に発生しているかまで確認して初めて「直った」と言えます。

事例3: 総点検で出てきたのは、AIには触れない場所

環境全体を棚卸ししたときも、似た構図が出てきました。参照先のファイルがすでに存在せず、動いているふりをして再起動を繰り返すだけの自動処理や、何のために動いているか特定できないまま残っている処理が複数見つかりました。

加えて、外部サービスとの連携設定を整理する項目は、そもそもAIが触れられる設定ファイルの中にはなく、Webサービス側のアカウント設定の中にしかないことも分かりました。ローカルの設定ファイルを全部読める権限があっても、外部サービスの管理画面にログインして操作する権限は別物です。この境界線は、AIに環境チェックを任せる前提として意識しておく必要があります。

3つに共通していたこと

3つの事例とも、問題を見つけるところまではAIが実際の記録を正確に見に行って特定できています。止まっていたのは、いつも直す側の一歩でした。

• 変更の記録が残っていない(事例1)
• AIの操作できる範囲の外に処理が依存している(事例2)
• そもそも設定がAIの触れられる場所の外(ローカルファイルではなく外部サービスのアカウント設定)にある(事例3)

壁の種類は毎回違いますが、共通しているのは「AIが検知できる範囲」と「AIが実行できる範囲」が一致しないということです。検知は環境の読み取りだけで完結しますが、修復は書き込み権限・外部サービスへのアクセス権限・場合によっては人間の最終承認が必要になり、検知よりも狭い範囲でしか完結しません。

実務上の対策

• 監視対象の設定ファイルは必ずバージョン管理下に置く。警告だけ出て原因追跡ができない状態を避けるため
• 後続処理があるスクリプトには、途中の確認プロンプトが後続を巻き込んで止めていないかをテストする。特に「AIの操作範囲外の操作」を挟むコマンド列は、そこで静かに止まる前提で設計する
• 「実行した」という報告と、期待した副作用が実際に発生したことの確認を分ける。ログの有無ではなく、対象ファイルの更新日時やハッシュ値など、実体を確認する
• AIが読み書きできる範囲と、外部サービスの管理画面でしか変更できない設定を、最初に切り分けておく。棚卸しの対象リストを作る段階で「ここから先は人間の作業」を明示しておくと、後で慌てない

まとめ

監視や自動化を増やすほど、確認作業自体は楽になります。ただし「AIが見つけられる範囲」と「人が直せる範囲」は一致しません。検知は環境の読み取りだけで完結しますが、修復には書き込み権限・外部サービスへのアクセス・時には人間の承認が必要で、検知よりも常に狭い範囲でしか完結しないのです。

AIに監視を任せる設計をするときは、検知と修復を同じ範囲だと想定せず、最初から「どこまではAIが直せて、どこからは人間が実行するのか」を切り分けておくことをおすすめします。