MicrosoftのRAMPARTとClarityがAIエージェント開発の安全性をどう変えるのか

企業でAIエージェントを使うケースが急増しています。社内データを読み取り、APIを呼び出し、ツールを操作しながら業務を自動化できる一方で、プロンプトインジェクションや危険なコマンド実行など新しいセキュリティリスクも生まれています。

この課題に対応するため、Microsoftは2026年5月、AIエージェントの安全性を開発プロセスに直接組み込むための2つのオープンソースツール 「RAMPART」 と 「Clarity」 を公開しました。

従来のように「開発の最後にセキュリティチェックをする」のではなく、設計・開発・テスト・インシデント分析までを通して安全性を継続的に検証するという考え方が特徴です。

AI安全性を開発ライフサイクルに組み込む

Microsoftのアプローチは役割分担が明確です。

• Clarity：設計段階でリスクを整理
• RAMPART：開発・テスト段階で安全性を自動検証

この2つを組み合わせることで、

1. 設計段階でリスクを特定する
2. そのリスクをテストとして実装する
3. 新しい失敗を将来の回帰テストとして追加する

というフィードバックループを作ることができます。

RAMPART：AIエージェント専用の攻撃テストフレームワーク

**RAMPART（Risk Assessment and Measurement Platform for Agentic Red Teaming）**は、AIエージェント向けに設計されたテストフレームワークです。通常の利用シナリオだけでなく、攻撃や誤用を想定したテストを自動化できます。

pytestと統合されたテスト環境

RAMPARTはPythonのテストフレームワーク pytest とネイティブに統合されています。つまり、開発者は通常のユニットテストを書くのと同じ方法で、AIエージェントの安全性テストを書けます。

これにより、以下のようなワークフローが可能になります。

• 通常のアプリテストと一緒に安全性テストを実行
• CI（継続的インテグレーション）で自動実行
• 問題が見つかればビルドを停止

AI安全性が日常的な開発作業の一部になります。

攻撃シナリオをテストコードとして定義

RAMPARTでは、実際に起こり得る攻撃やリスクをテストケースとして記述できます。例えば次のようなケースです。

• プロンプトインジェクション攻撃
• 安全ポリシーを回避しようとする指示
• 危険なツール呼び出し（例：危険なシェルコマンド）
• 機密情報の外部送信

テストは「エージェントが安全に拒否できるか」を検証する形で実行されます。

レッドチームの発見を回帰テストに変える

AIシステムでは、セキュリティ調査で見つかった問題が再発することがよくあります。

RAMPARTは、一度見つかった脆弱性を永続的な回帰テストに変えることを目的としています。

例えば：

• レッドチームがプロンプトインジェクションを発見
• その攻撃をテストケースとして追加
• 将来のコード変更で再び発生した場合にCIで検知

この仕組みによって、セキュリティ調査の成果を長期的な品質保証に活用できます。

AI特有の「確率的挙動」に対応

従来のソフトウェアと違い、AIエージェントの挙動は**確率的（同じ入力でも結果が変わる可能性がある）**です。

そのため、1回のテスト成功だけでは安全性を保証できません。

RAMPARTは同じリスクシナリオを繰り返し実行し、時間を通じた挙動の変化や安全性の後退（regression）を検出する設計になっています。

CI/CDパイプラインとの連携

RAMPARTはCI環境で実行できるため、次のような変更を自動的にチェックできます。

• プロンプトや指示文の変更
• 使用モデルの変更
• 外部ツールやAPIの追加
• RAGのデータソース変更
• セーフティポリシー更新

安全テストに失敗した場合、デプロイ前に問題を検出できます。

Clarity：コードを書く前に安全性を検討する

RAMPARTが「テストの仕組み」だとすれば、Clarityは設計段階の思考ツールです。

MicrosoftはClarityを、AIエージェント設計のための**構造化された“相談相手（sounding board）”**と説明しています。

開発チームは次のような問いを整理できます。

• エージェントは何をすべきか
• 何をしてはいけないのか
• どのツールや権限が必要か
• 想定される誤用や攻撃は何か
• どんなテストや防御策が必要か

このプロセスにより、設計ミスを早期に発見できます。設計段階での修正は、開発後に修正するよりもはるかにコストが低いとされています。

インシデント後の分析にも活用

Clarityは開発前だけでなく、問題発生後の分析ツールとしても使えます。

例えば、

• RAMPARTテストが失敗
• 本番環境で想定外の挙動が発生

といった場合、Clarityで設計前提を見直し、次の点を検証します。

• 見落としていたリスク
• 不足していたガードレール
• 新しく追加すべきテスト

その結果をRAMPARTの新しい回帰テストとして追加することで、システムは徐々に強化されていきます。

エンタープライズAIにとっての意味

企業のAIエージェントは次のような複雑な環境で動作します。

• 社内データベース
• APIや業務システム
• 外部サービス
• ユーザー入力

このため、プロンプトインジェクションやツール誤用は実際の業務リスクや情報漏えいにつながる可能性があります。

MicrosoftのRAMPARTとClarityは、こうした問題に対して

• 設計段階でリスクを整理
• CIで攻撃シナリオを継続的にテスト
• 失敗を将来の回帰テストに変換

という方法で、AI安全性を継続的なエンジニアリング活動として扱うことを目指しています。

AIエージェントがより自律的になるほど、こうした「開発プロセスに組み込まれた安全設計」は、企業システムを構築する上で欠かせない要素になっていくと見られています。