AIにPowerShellを渡す前に、「判定不能」を安全側へ分けた話

今日は、AI開発支援で使うPowerShellコマンドの安全確認ツールを見直した。

きっかけは、危険な操作を警告する仕組みを作っている途中で、「検知できたもの」より「正しく判定できなかったもの」をどう扱うかが重要だと気づいたことだった。

例えば、セキュリティ機能を無効化するコマンドは文字列から検知できる。しかし、コメントや引用符が混ざる場合や、実際にどのPowerShellで実行されるか確認できない場合まで、すべて安全・危険の二択にすると誤判定が起きる。安全と言い切れないものを、見逃し扱いにしてはいけない。

そこで判定結果を「検知あり」「検知なし」「判定不能」「部分評価」に分けた。実行環境を証明できない入力は、無理に推測せず判定不能として表示する。警告理由は固定コードと固定文言から組み立て、入力されたコマンド本文をログや応答へそのまま残さないようにした。

特に重視したのは、安全確認のために対象コマンドを実行しないことだった。評価はメモリ内で行い、疑わしい入力、評価不能、評価器の失敗、入力不一致では、コマンド実行・保存・ネットワーク通信・子プロセス起動が0回になることを確認した。

CLIの合成試験では、3種類の検知ルール、非検知、判定不能、部分評価、コメントと引用符、未知の理由コード、評価器とCLIの失敗まで10件すべて通過した。Codexの実行前フックにも一度だけ接続し、通常の表示を混ぜず構造化した案内だけを返すところまで確認している。本番運用はまだ始めず、画面表示と例外時の挙動を追加で確認する予定だ。

AIを使った自動化では、動かす機能と同じくらい「判断できないときに止まれる設計」が大切だと感じた。

PowerShellや業務自動化の安全確認、既存ツールへの実行前チェック追加など、小規模な調査・試作からご相談いただけます。現在の運用を確認し、止める条件と記録範囲を整理して進めます。