AI の安全な障害調査環境を考える #1

はじめに

SRE部の村上です！

前回は AI の安全な開発環境を構築するためにはどうしたらよいだろうという雑記を書きましたが、今回はより実戦的な場面について考えてみたいと思います。

インシデントは SRE のスコープと密接に関連しており、我々もインシデント対応のブラッシュアップに力を注いでいますが、その中で AI をインシデント対応に活用するということは当然考えるべき方策です。

AI の活用戦略として「障害発生時の一次調査の自動化」は非常に有効な戦略です。
環境へのアクセスと GitHub, Notion 等への接続を渡すと、人間がやると1時間程度かかるような調査を15分程度で実施できます。
勿論、中身は一次調査としては全く遜色ないレベルです。

しかし、「AI にうっかり破壊的操作をされてしまい二次災害が起きる可能性」は当然存在します。
そして、自動化を行うということは既存業務を何倍も高速化するということになり、即ちこれは、あるウィンドウ期間における二次災害の確率が AI に委譲することにより上がっていると考えられます。

よって、「二次災害が起きる可能性」を排除しなければ AI を業務に組み込むことはできません。

そこで、今回から2回に渡り、どのように安全に一次調査を行わせるかについて1つのアイディアを述べていければと思います。

尚、今回利用する AI は Claude Code on Local（非 Docker 環境）、Workload の環境は Google Cloud として話を進めたいと思います。

前提: AI に関する話

確率的な振る舞い

「AI にいくら指示したとしても守ってくれない」というのはみなさんも経験があると思います。

これは、AI はその性質上確率的に振る舞うため（人間もですが）であり、つまり「このコマンドは危険だから打っては駄目だよ！」と伝えてもそれが守られない確率が数% は常にある、ということです。

ですので、特に Context が増えるに従い誤った判断をしてしまい、破壊的操作を実行されてしまう可能性があるということになります。

Bash ツールという諸刃の剣

Claude では Bash ツールというものが存在します。

これは Local に存在するあらゆるコマンドを実行できる極めて強力なツールであり、つまりこれの存在が非常に厄介であるということです。

勿論、それに対して「このコマンドは弾く」といった設定は可能です。

~/.claude/settings.json ファイルに「許可しないコマンド」を定義することができます:

			
{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)"
    ]
  }
}

		

本題: 破壊的操作をどう防ぐか

基本の考え方

セキュリティに代表されるように、IT における守りの戦いというのは非常に難しく、少しでも穴があるとそこから決壊するという特性があります。

この問題に対しての典型的な戦略として、「複数の手段を取ることで、ある手段での失敗をカバーする」という方法が取られるかと思います。

例えば、社内システムであれば、

まず IP 制限を使い社内ネットワークからのみアクセスを許可するようにし、
それを突破されても認証・認可で弾く

…というのが典型的なやり方になります。

この考え方を今回の話に応用するならば、

まず、Claude の Bash ツールで実行できるコマンドを制限し、
それを突破されても Google Cloud の認証・認可で弾く

…という考えになりそうです。が…

`permissions.deny` に書くという非現実的な戦い

それでは、まずは AI に実行させたくないコマンドを実行させないようにする事を考えたいと思います。

つまりそれは、 gcloud で実行させたくないコマンドを ~/.claude/settings.json の permissions.deny に列挙することになるわけですが、サービスごとに列挙するにはコマンド数多すぎて現実的ではなさそうなのと、そもそも bash -c で容易に回避できるという問題があります。

所定の権限でどう実行させるか

次に認証・認可…即ち IAM です。

一番シンプルなアプローチは「自らの権限を絞っておく」ということになりますが、実際の業務では「自分は運用作業で破壊的操作を行いたいケースがある」ので採用しづらいと思います。

そこで、次点として考えられる戦略としては「権限を絞った Service Account を作成し、その Service Account に成り代わって実行する」ということになります。

gcloud においては以下のコマンドで指定した Service Account に成り代わることができます:

			
gcloud --project=some-project --impersonate-service-account=foobar@some-project.iam.gserviceaccount.com ...

しかし、ここまで考えたところで、Bash ツールにおいてこのコマンドを強制させる術がやはりありません。

環境変数等での既定 Service Account の指定はできますが、 unset が可能であったりそもそも設定を忘れたりする可能性があります。

このように中々難しい状況となってしまっていますが、この問題の根本としては「Bash ツール」にあるのではと考えています。
即ち、Bash ツールが万能すぎるために何でも実行できてしまい、この問題が起きるのではないかと。

であれば、この万能ツールを封印しながら、Google Cloud にアクセスし調査する方法を確立できれば良いと考えられます。

次回は、この問題を解決する1つの方法として、sub agent + mcp を活用する方法を提示します。

HAKUHODO Technologies SRE Tech Blog