AIエージェントがメールを読み、社内システムにアクセスし、自律的にコードを書いて実行する時代——そんな「行動するAI」を、私たちはどうやって安全に使えるようにすればいいのでしょうか。Microsoftが2026年5月20日に公開した2つのオープンソースツール「RAMPART」と「Clarity」は、その答えを「開発の最前線」に持ち込もうとしています。レッドチームの知見をpytestで書けるテストに変え、コードを書く前の設計段階から「そもそも何を作るべきか」を問い直す——AI安全性を、年に数回のレビューから日々のエンジニアリングの一部へ。業界最大手が仕掛けた、この静かなパラダイムシフトの全貌をお届けします。
Microsoftは2026年5月20日、AIエージェント開発における安全性を継続的に検証するためのオープンソースツール2種、「RAMPART」と「Clarity」を公開した。RAMPARTはMicrosoftが既に公開しているレッドチーミング自動化フレームワークPyRIT上に構築されたエージェント向けテストフレームワークであり、pytest形式でテストを記述してCIに組み込むことができる。クロスプロンプトインジェクション攻撃のシナリオに対応し、確率的なLLM挙動に対しては「少なくとも80%の実行で安全であること」といった統計的トライアルもサポートする。
一方のClarityは、コードを書き始める前の設計段階で前提を問い直す対話型ツールで、デスクトップアプリ、Web UI、コーディングエージェント組み込みの形態で動作する。対話結果はリポジトリ内の.clarity-protocol/ディレクトリにmarkdownファイルとして保存され、Gitで差分管理される。複数のAI「シンカー」がセキュリティ、ヒューマンファクター、敵対的シナリオ、運用面から独立して失敗分析を実施する。発表はMicrosoft AI Red Teamのラム・シャンカル・シヴァ・クマール氏による。
From: 
Introducing RAMPART and Clarity: Open source tools to bring safety into Agent development workflow
【編集部解説】
このニュースを読み解くうえで、まず押さえておきたいのは、AIエージェントというカテゴリの「立ち位置」が、ここ1〜2年で根本的に変わったという点です。かつてのLLMは「テキストを生成する道具」でしたが、いまや業務システムに接続し、メールを読み、CRMから顧客情報を引き出し、コードを書いて実行する「行為主体(エージェント)」になりました。MicrosoftのRam Shankar Siva Kumar氏が「方程式が変わった」と表現したのは、まさにこの質的転換を指しています。
RAMPARTという名称は、CyberScoopや他社の報道で明らかになったとおり、Risk Assessment and Measurement Platform for Agentic Red Teaming の頭文字を取ったものです。基盤となっているPyRITは、Microsoft AI Red Teamが100以上の内部運用で実戦投入してきたフレームワークで、GitHub上で公開されています。今回のRAMPARTは、その「研究者向けの探索ツール」を「開発者の日常ワークフロー」へと再構成し直した成果物だと位置づけられます。
ここで注目したいキーワードが「シフトレフト(shift-left)」です。これはセキュリティ業界で長く使われてきた概念で、テストや検証を開発ライフサイクルの「左側」、つまりより早い段階に移すという意味を持ちます。RAMPARTは安全性テストをpytestと同じ感覚でCIに組み込めるようにし、Clarityはコードを書き始める前の設計段階まで踏み込む——両者を合わせることで、AI安全性の検証ラインが一気に上流へ引き上げられる構図です。
特に技術的に重要なのは、RAMPARTが「統計的トライアル」をサポートしている点です。従来のソフトウェアテストは決定論的で、同じ入力に対しては同じ出力が返るのが前提でした。しかしLLMの挙動は確率的で、同じプロンプトでも結果がぶれます。「80%以上の試行で安全であること」といった確率ベースの合格基準を設定できる設計は、AI時代のテスト哲学そのものを書き換える試みと言ってよいでしょう。
Clarityのほうは、毛色がやや異なります。これは「対話型の設計レビューツール」であり、複数のAI「シンカー」がセキュリティ、ヒューマンファクター、敵対的シナリオ、運用といった観点から独立してプロジェクトに突っ込みを入れます。成果物が .clarity-protocol/ ディレクトリにmarkdownで保存され、Gitで差分管理できるという思想は、ドキュメンテーションをソースコードと同等の一級市民として扱う「Docs as Code」の流れに合致しています。
ポジティブな側面として最も大きいのは、レッドチームの知見が「個別レポート」として埋もれず、再実行可能なテスト資産として横展開できることです。あるエージェントに効いたクロスプロンプトインジェクションは、別のエージェントにも変種を加えて効く可能性が高いため、業界全体での知見蓄積が加速する可能性があります。Microsoftがこれをオープンソースで出した戦略的意図も、ここにあると考えられます。
一方、潜在的なリスクや限界も冷静に見ておく必要があります。RAMPARTはあくまでも「テストフレームワーク」であって、テストケース自体は開発者が書かねばなりません。テストの網羅性が不十分なまま「RAMPARTでチェック済み」というラベルが独り歩きすれば、かえって安全性の幻想を生む危険もあります。また、攻撃手法そのものが公開されることで、敵対者側の学習材料にもなり得るというデュアルユース問題は常につきまといます。
規制との関係では、2025年12月に公開されたOWASP Top 10 for Agentic Applicationsや、2026年3月27日に更新されたNIST AI RMF Playbookといった国際的なガイドラインの流れと、今回のツール群は明確に呼応しています。「方針を測定可能な形に落とし込む(policy-to-measurement)」という発想は、今後のAI規制への対応コストを下げる実装基盤になる可能性があります。
長期的な視点で見れば、これはAI安全性が「定期的なレビュー」から「継続的なエンジニアリング規律」へと移行する象徴的な一歩です。CI/CDがソフトウェア開発の常識になったように、AI安全性テストもパイプラインに組み込まれることが当たり前になる未来——その地ならしを、業界最大手のMicrosoftが自ら主導している点に、innovaTopiaとして注目したいニュースだと言えるでしょう。
【用語解説】
エージェント型AI(Agentic AI)
単にテキストを生成するだけでなく、外部システムへアクセスし、ツールを呼び出し、ユーザーに代わって行動を起こすAIの総称。メール送信、データベース照会、コード実行などを自律的に行う。
PyRIT(Python Risk Identification Tool)
MicrosoftのAI Red Teamが開発・公開している、生成AIシステムを対象としたレッドチーミング用オープン自動化フレームワーク。RAMPARTはこの上に構築されている。
レッドチーミング(Red Teaming)
システムの脆弱性や安全性の問題を、攻撃者の視点から擬似的に攻撃して洗い出す手法。元は軍事用語で、近年はAI安全性評価の文脈で広く使われる。
クロスプロンプトインジェクション(Cross-Prompt Injection/間接プロンプトインジェクション)
メール、文書、Webページなど外部データソースに悪意ある指示を埋め込み、それを処理したAIエージェントの挙動を間接的に乗っ取る攻撃手法。OWASP Top 10 for LLM ApplicationsのLLM01: Prompt Injectionに含まれる主要リスクの一種として扱われる。
pytest
Pythonにおけるデファクトスタンダードのテスティングフレームワーク。RAMPARTはこれにネイティブ対応しており、開発者は通常のテストと同じ感覚で安全性テストを記述できる。
CI(継続的インテグレーション)
コード変更のたびに自動でビルド・テストを実行する開発手法。RAMPARTのテストをCIに組み込むことで、エージェント変更時の安全性退行を自動検出できる。
バイブコーディング(Vibe Coding)
AIに自然言語で意図を伝えて素早くコードを生成・実装するスタイル。実行は容易になる一方、「何を作るべきか」の設計判断が後回しになりやすいという課題が指摘される。
シフトレフト(Shift-Left)
セキュリティや品質検証を、開発ライフサイクルのより早い段階(設計・実装初期)に前倒しする考え方。早期発見ほど修正コストが小さいという経験則に基づく。
AI Red Team
Microsoftが2018年に設立した、自社AI製品の安全性を敵対的視点から評価する専門組織。記事の著者ラム・シャンカル・シヴァ・クマール氏が同チームの創設者。
シンカー(Thinkers)
Clarityにおいて、セキュリティ、ヒューマンファクター、敵対的シナリオ、運用面など異なる観点から独立してシステムを検査する複数のAIアセスメント役の呼称。
policy-to-measurement(方針から測定へ)
抽象的な安全方針を、具体的に測定・検証可能なメトリクスやテストへ落とし込むアプローチ。Microsoftが本発表で示す考え方の一つ。
【参考リンク】
Microsoft Security Blog(外部)
Microsoftのセキュリティ研究成果や製品発表を公式に発信する公式ブログ。本件原文の掲載元。
PyRIT 公式GitHubリポジトリ(外部)
Microsoft AI Red Teamが開発する生成AIレッドチーミング自動化フレームワーク。RAMPARTの基盤。
RAMPART 公式GitHubリポジトリ(外部)
エージェント型AI向けpytestネイティブな安全性・セキュリティテストフレームワーク本体。
Clarity 公式GitHubリポジトリ(外部)
設計意図を抽出し失敗を可視化する対話型ツール。Web解析の「Microsoft Clarity」とは別製品。
AI Red Teaming Agent(Microsoft Learn)(外部)
Microsoft FoundryにおけるAI Red Teaming Agentの概念と運用ガイドラインを示す公式ドキュメント。
pytest 公式サイト(外部)
RAMPARTが採用するPython向けテスティングフレームワークの公式ドキュメント。
OWASP Gen AI Security Project(外部)
LLM/生成AIアプリケーションのリスク分類を業界横断でまとめる標準的プロジェクト。
NIST AI Risk Management Framework(外部)
米国立標準技術研究所のAIリスク管理参照枠組み。Govern/Map/Measure/Manage構成。
【参考記事】
Microsoft Open-Sources RAMPART and Clarity to Secure AI Agents During Development(The Hacker News)(外部)
RAMPARTの正式名称、pytestネイティブ性、クロスプロンプトインジェクション等への対応を整理した解説記事。
Meet Rampart and Clarity, Microsoft’s new red team combo AI agents(CyberScoop)(外部)
AI Red Team創設者シヴァ・クマール氏のインタビューを交え、チーム立ち上げ経緯と戦略を伝える。
Microsoft Releases Open Source AI Safety Tools for Agent Development(Campus Technology)(外部)
CIパイプライン組み込み型のテストモデルと、エンジニアが所有権を持つ運用形態の新規性を強調する。
Microsoft Releases Rampart And Clarity Tools To Improve AI Agent Safety(Petri)(外部)
AI安全性を「定期チェック」から「継続的なエンジニアリング規律」へ変える方針と再現可能テストの意義。
PyRIT AI Red Teaming: Metasploit for LLMs(ToxSec)(外部)
PyRITの構成要素と、100以上の内部運用実績を解説する技術記事。
【関連記事】
Microsoft Defender、AIエージェント向けランタイム保護機能を発表—プロンプトインジェクション攻撃に対応
本記事(RAMPART/Clarity)は開発時のシフトレフト型テスト、こちらはランタイム保護を扱う補完関係。両者を合わせるとMicrosoftのエージェント安全性戦略の全体像が見える。
Agentic AI Foundation｜エージェント時代の標準化が動き出した——AAIFとA2Aが描く設計図
Microsoftも関与するエージェント時代の標準化の動き。本記事の「engineering-native AI safety」の潮流と接続する。
AIが許可を求めなくなる時代へ:BCGが示す4つのリスク管理フレームワークと企業の備え
エージェント型AIのリスク管理フレームワーク「FAST」の解説。policy-to-measurementの議論と接続できる。
AIブラウザエージェントが新たなインサイダー脅威に、96%の企業が導入意向も準備不足
OWASP Top 10 for LLM Applicationsとエージェント脅威の文脈を共有。プロンプトインジェクションが第1位に位置づけられる背景を補完する。
Anthropic「MCP」プロトコルにシステミックな脆弱性、1.5億ダウンロードに波及か
AIエージェントが「読む・書く」から「実行する・行動する」段階へ移行した文脈を共有。本記事冒頭の問題意識と直結する。
AIエージェント・フィジカルAI時代の「攻めのガバナンス」― AI事業者ガイドライン更新内容(案)を読み解く
AIエージェント時代の規制・ガバナンス議論を国内視点で整理。NIST AI RMFやOWASP動向との対比で読むと立体的に理解できる。
【編集部後記】
AIエージェントが「文章を書く存在」から「実際に行動する存在」へと変わりつつある今、安全性をどう設計に組み込むかは、開発者だけの課題ではなくなってきているように感じます。
みなさんが日常で使っているサービスにも、近い将来エージェント型AIが組み込まれていくはずです。そのとき「このエージェントは何ができて、何をしてはいけないのか」という線引きが、誰によって、どんなプロセスで決められているのか——少しだけ気にしてみると、テクノロジーとの付き合い方が変わってくるかもしれません。みなさんは、自分の代わりに動いてくれるAIに、どこまで任せたいと感じますか?
