Claude Codeの誤操作を防ぐ。ProbityでAIの危険な行動を強制遮断する方法

開発現場でAIエージェントに「テストを先に書け」と指示しても、無視して実装から書き始めるケースがある。プロンプトによる指示だけでは、AIの暴走や誤操作を100%防ぐことはできない。

AIの判断に頼る守りは、条件が崩れた瞬間に突破される。事故を防ぐ唯一の回答は、ルールをプロンプトではなく「強制的な遮断システム」として組み込むことだ。

ガードレールツールであるProbityは、物理的なコマンド制限やテスト駆動開発の強制を機械的に行う。AIに判断させず、失敗を前提に物理的な出口を塞ぐ多層防御の考え方を解説する。

AIエージェントの暴走を物理的に止めるガードレールツール「Probity」

AIコーディングエージェントの自律性が高まる一方で、開発現場ではAIがテストを無視して実装を書き始める現象が起きている。プロンプトによる指示だけでは、AIの行動制御率を100%にすることはできない。

こうした課題を解決するため、Probityが開発された。Probityは、AIエージェントがファイル変更やシェルコマンドを実行する直前に割り込み、設定されたルールへの違反を機械的に検知して操作を強制遮断するツールだ。

しんたろー：
プロンプトで「テスト先に書け」と念押ししても、Claude Codeは平然と無視して実装ファイルを作り始める。指示ではなく仕組みで止める方向にシフトしたのは、開発現場のリアルな課題だと感じた。

Probityは、従来のガードレールツールで必要だった複雑な環境構築を不要にする。導入に必要なNode.jsのバージョンは22以上で、実行するコマンドは1つだ。

主な仕様と特徴は以下の通りだ。

* 各エージェントの公式SDKを利用するため、専用のAPIキーや追加契約は0件

* VitestやJest、pytestなど各テストツール固有のレポーター設定が不要

* 標準で搭載されている組み込みルールは5つ

* Claude Code、Codex、GitHub Copilot CLIなどの主要エージェントに対応

Probityは、AIエージェント自身のセッション履歴を直接解析する。プロジェクト直下に設定ファイルであるprobity.config.tsを置くだけで同一ルールを適用できる。

具体的な挙動として、テストが失敗していることを確認せずに実装コードを書こうとした場合、Probityがコマンド実行を即座にブロックする。ブロックした理由と次に取るべき修正行動をAIエージェントへ自動でフィードバックする。

また、ProbityはTDDの強制だけでなく、特定の文字列パターンを禁止するルールや危険なファイル操作の遮断にも対応している。

AIの判断力に依存する守りは、条件が崩れれば容易に突破される。Probityのようなリアルタイムガードレールによるコマンド制限に加え、OSレベルでの実行権限の制限や、生データを直接検証する検収コードの導入といった多層防御が求められている。

なぜAIの「賢さ」に頼る防御は現場で破綻するのか

AIエージェントに「必ずテストを先に書いてから実装して」と指示しても、AIは約束を破る。コンテキストが長くなったり、複雑なタスクに集中したりすると、指示したルールは頭から抜け落ちる。

一番恐ろしい失敗は、エラーを出して止まることではない。誤った処理や数値の計算ミスをしたまま、それらしい分析結果と説得力のある説明を出力し続ける「もっともらしい失敗」だ。

AIが綺麗な解説文を生成しても、結果の正しさを保証するわけではない。人間はAIが作った「筋の通った説明」を見ると、ついコードやデータの直接的な検証を怠ってしまう。

しんたろー：
Claude Codeに「TDDで書いて」と頼んで「わかりました！」と返事された1分後、テストも書かずに実装コードを生成し始める。AIの「理解しました」は、現場の新人の「わかりました（わかってない）」と同じくらい信用できないと思った。

この問題を解決するには、AIの運用思想を「指示による規律」から「物理的なガードレール」へ切り替える必要がある。AIの判断力を信頼せず、失敗することを前提としたシステムを組む。

Probityは、AIエージェントがファイル操作やコマンド実行を行おうとした瞬間、その直前でルール違反がないかチェックする。違反していればコマンドを強行させず、物理的にその場でブロックする。

例えば、Claude Codeのセッション履歴を監視し、テストが失敗した記録がない状態での実装ファイルの変更を機械的に弾く。AIに「TDDを守るべきか」を判断させるのではなく、守らなければコードが書けない環境を作る。

プロンプトインジェクション対策も同じ構造だ。AIが悪意ある指示を見抜いて止まってくれれば良いが、次も同じように見抜ける保証はない。

実行環境そのものを制限する。curlやwgetといった外部通信を行う危険なコマンドの実行権限をあらかじめ奪っておく。コンテナレベルで外のネットワークへ接続できない状態にしておく。

データ処理においても同様だ。AIの集計結果や「問題ありません」という自己報告を鵜呑みにしてはいけない。処理の中間結果をCSVなどの形式で出力させ、AIとは独立した検収コードで再計算して数値を突き合わせる。

AIに作業を行わせる一方で、検証は人間が書いた決定論的なプログラムに委ねる多層防御が不可欠だ。AIの自律性を伸ばせば作業量は増えるが、自由度を与える場所は「境界の中」だけに限定する。

実務の開発フローに組み込む3つのガードレール

AIが動く環境そのものにプログラマブルな制約を物理的に組み込む。実務で取り入れるべきアクションは3点だ。

1. 危険操作のコマンドレベルでの遮断

プロンプトに「ファイルを勝手に削除しないでください」と書く運用は避ける。Probityのようなガードレールツールを導入し、実行可能なシェルコマンドをシステム側で制限する。

rm -rf による一括削除や、curl や wget を使った未承認の外部送信は、AIの判断に関わらず物理的にエラーにする。通信ポートや権限が塞がれていれば悪意あるデータ流出は起きない。

2. TDDの強制と検収コードによる二重チェック

AIはテストコードを書く前に実装を終わらせようとする。失敗したテスト結果がログに存在しない状態でのコード編集を自動でブロックするルールを設定する。

AIが吐き出した「実装が完了しました」という報告をそのまま信じてはいけない。処理の中間結果をCSVなどの形式で出力させ、AIとは独立した検収用のスクリプトを実行して数値を自動照合する。

3. ワークスペースごとの影響範囲の固定

AIが参照してよいファイルをパス指定で明確にし、領域外のファイルを推測で編集できないよう参照権限を分離する。コンテキスト内に存在しないファイルをAIが推測で補完しようとした場合は、作業を即座に停止させるルールを敷く。

しんたろー：
Claude Codeに指示を出して離席したら、気を利かせたAIが別ブランチのファイルまで書き換えていたことがある。賢いAIほど勝手な解釈で動く。プロンプトで説教するより、設定ファイルで物理的な壁を立てるほうが確実だと痛感した。

よくある質問

Probityと既存のCI/CDパイプラインはどう使い分けるべき？

CI/CDはコミット後の品質保証を担う仕組みだ。一方のProbityは、AIエージェントがコードを書き換えている最中にリアルタイムで割り込むガードレールとして機能する。開発中のルール違反はProbityで即座に遮断し、リポジトリ全体の整合性はCI/CDで担保する設計がベストだ。

AIが起こす「もっともらしい失敗」はどうやって検知する？

AIが出力した解説や集計結果を鵜呑みにせず、生データや中間結果を別経路で検証する仕組みを置くことだ。集計作業を任せた場合、結果だけでなく中間生成したCSVファイルを出力させ、別のスクリプトで自動再計算して突き合わせる。

プロンプトインジェクション対策はどこから着手すればいい？

まずはAIエージェントが実行できるコマンドのホワイトリスト化から始める。AIの知識や倫理観に頼って悪意ある指示を見抜こうとするのは筋が悪い。OSやコンテナのレイヤーで外部通信や危険なファイル操作を絞り込み、物理的に実行不能な環境を作るほうが確実だ。

まとめ

AIの「賢さ」に頼った防御には限界がある。Probityのような機械的ガードレールで物理的に危険な操作を遮断する構造を作ることが、現場の事故を防ぐ現実解だ。

AIを過信せず「失敗しても安全な構造」をシステム側に用意しておく。AIエージェントの自律性を事故に変えないためのガードレール構築が重要だ。