見出し画像

「ITニュース」｜Microsoft RAMPART / Clarity — エージェント安全を CI と設計段階に載せる

まるしょー｜ITニュース分析配信

はじめに

Microsoft は 2026年5月20日、Security Blog で、エージェント開発向けのオープンソース（OSS）ツール RAMPART と Clarity を公開しました。

RAMPART は、既存の AI レッドチーミング基盤 PyRIT の上に載せた pytest 連携の安全テスト枠組みです。脅威モデルに沿ったシナリオをテストとして書き、継続的インテグレーション（CI） で通過・失敗を判定できる、と説明されています。Clarity は、コードを書く前に問題定義・失敗モード・意思決定を整理し、リポジトリ内の `.clarity-protocol/` ディレクトリに人間が読める Markdown として残す 設計支援ツールです。

Microsoft の位置づけは、「AI の安全は一度きりのレビューではなく、継続的なエンジニアリングの習慣にすべきだ」というものです。同日の Security Blog では、@antv npm 侵害（Mini Shai Hulud） も別記事で公開されており、「エージェントが外部データを読むときの注入」 と 「ビルドが悪意あるパッケージを読むときの侵害」 が同じ日に並んだ、という読み方もできます。

読みどころは次の3点です。

  • RAMPART が「レッドチームの報告書」を pytest の回帰テスト に変える設計

  • Clarity が「実装の速さ」より 要件と失敗モードの言語化 を先に置く設計

  • PyRIT と RAMPART の役割分担（探索と固定化）を誤解しないこと

※本記事は Microsoft Security Blog・GitHub の公開情報をもとにした一般的な整理です。契約、法務、セキュリティ、監査、本番導入の判断は、自社の規程、最新の公式ドキュメント、専門家・担当部門の確認に従ってください。無許可の侵入テストや、本番相当の環境への攻撃的検証は、法務・契約・社内規程に従ってください。Microsoft への取材は行っていません。

この記事での用語


1. 何が起きたのか（結論）

先に結論です。

  • 2026年5月20日、Microsoft が RAMPART と Clarity を OSS として公開した

  • RAMPART は PyRIT ベースで、pytest テスト＋CI ゲートにより、プロンプト注入などのシナリオを 回帰テスト にできる

  • Clarity はデスクトップ／Web／コーディングエージェント埋め込みで動き、設計段階の仮定検証と `.clarity-protocol/` への記録を行う

  • ブログでは、企業内 AI が「答えるだけ」から 「世界の中で行動する」 段階に入り、安全方程式が変わった、と説明されている

  • フィードバック窓口として aisafetytools@microsoft.com が案内されている

忙しい方向けに一言でいうと、
Microsoft は、エージェント量産のタイミングで「安全を年1回のレッドチーム」から「pytest と設計メモが回る開発フロー」へ寄せる OSS を二つ出した、というニュースです。

2. 公式情報ベースの要点

2-1. RAMPART — レッドチームの知見を pytest に載せる

Security Blog では、RAMPART は次のように説明されています。

  • PyRIT（構築後のブラックボックス探索向け）の上に、構築中のエンジニア向けに置かれた枠組み

  • 開発体験は 統合テストに近い。脅威モデルからシナリオを書き、薄いアダプターでエージェントに接続し、合格／不合格 を返す

  • 新しいツールやデータソースをエージェントに足す PR に、対応する安全テストを同梱できる

  • レッドチームや本番インシデントの再現結果を RAMPART テストにエンコード し、変更のたびに走らせて サイレントな退行 を防ぐ

従来のテストとの違いとして、ブログは次を挙げています。

リポジトリ: microsoft/RAMPART

2-2. Clarity — 実装前に「why」を残す

Clarity は、実行を速くする AI ではなく、正しいものを作っているかを問う AI として位置づけられています。

  • デスクトップアプリ、Web UI、コーディングエージェントへの埋め込みで利用可能（README）

  • 問題の明確化、解の探索、失敗分析、意思決定の追跡をガイド

  • 失敗分析では、複数の AI thinker がセキュリティ・人的要因・敵対的シナリオ・運用など 別角度 から独立に検討し、チームが結果をまとめる

  • 成果物は `.clarity-protocol/` に Markdown で保存。コミット・PR レビュー・diff する想定

  • ドキュメント間の 依存関係 を追い、問題定義が変わったときに解や失敗分析の 陳腐化 を促す

README で案内されている LLM プロバイダの例は、Anthropic（Claude）、OpenAI（GPT）、Azure AI、GitHub Copilot、Google Gemini です。利用時は API キー・ログ・データ送信 を自社ポリシーで確認してください。

リポジトリ: microsoft/clarity-agent

2-3. PyRIT と RAMPART — 置き換えではなく二段構え

混同しやすいのは「PyRIT が不要になった」という読み方です。公式は対比を明示しています。

ブログでは、両者は 相互に補強 し、レッドチームの発見 → RAMPART テスト化 → 以降の変更で再検証、という流れが想定されています。Clarity で残した設計意図と、RAMPART の具体テストは、Microsoft の言葉では spec-driven（仕様駆動）でエンジニアリングネイティブな AI 安全 の一部、と位置づけられています。

3. なぜ今か — 公式が語る「能力のシフト」

Security Blog の冒頭では、企業内 AI が メール・CRM・コード実行・多数の接続システム に手を伸ばす段階に入り、「行動できるものは、意図しない行動もしうる」と書かれています。

公開情報から読み取れる投資理由は、おおむね次の4つに整理できます（いずれもブログの「Why we are investing」に対応）。

  1. 設計ミスが高コスト — ツール接続やフローを十分検討せず進め、レッドチームで初めて問題が出たときには 作り直し になりがち。実装（how）より目的（why） が後回しになる、いわゆる高速プロトタイピング文化への対応。

  2. レッドチーム知見の閉じ込め — ある製品で有効だった攻撃パターンは他製品にも転用しうるが、個別レポートに留まりがち。知見を 実行可能な資産 にしたい。

  3. インシデント対応の再現性 — 確率的な LLM では、再現と修正検証が手作業になりがち。反復可能なエンジニアリングプロセス にしたい。

  4. 一度きりのレビューからの脱却 — Clarity で意図と仮定を残し、RAMPART でテストを走らせ続ける。生きた成果物 として安全を扱う。

OWASP などが エージェント向けアプリケーション の脅威整理を公開していることは、業界全体の文脈として言及できます（Securing Agentic Applications Guide 等）。ただし、本件の直接のトリガーとして OWASP を挙げているかは、Microsoft ブログでは明記されていません。

4. 混同しやすい点

5. 読者別 — 公式が想定しうる動きと、現場での一手

エンタープライズ展開の相談先として、ブログは aisafetytools@microsoft.com を案内しています。

6. 短期・中期・長期の整理

時間軸の定義（本稿内）

  • 短期: 0〜3か月

  • 中期: 3か月〜1年

  • 長期: 1年以上

6-1. 短期（0〜3か月）

予想される動き — PyRIT 利用チームや先進的なエージェント開発チームが、PoC パイプライン（pytest＋統計試行＋CI）を試す。Clarity の `.clarity-protocol/` が、設計メモ（ADR に近い運用）として一部プロジェクトに載る可能性がある。

不確実性 — 公開直後はコミュニティ規模が小さく、アダプター実装や CI への LLM 呼び出しコストが障壁になりうる。確率テストの Flaky（不安定な失敗） でパイプラインが騒がしくなるリスクもある。

効果が出にくい条件 — レッドチームが 年1回 のまま。CI に外部 API を載せられない。急を要する脅威が クロスプロンプト注入以外 だけのとき、カバレッジ不足が目立つ。

6-2. 中期（3か月〜1年）

予想される動き — 「エージェントの PR に安全テスト同梱」がテンプレ化し、Clarity 成果物と RAMPART テストが 同一リポジトリで diff レビュー される運用が増える可能性がある。

不確実性 — 他ベンダの 同等 CI 枠、マルチモデル による閾値のぶれ、日本語・国内業務 向けペイロードの不足。ノーコード型エージェントビルダー中心の組織では pytest 連携が効きにくい。

効果が出にくい条件 — 法務が AI 生成の `.clarity-protocol/` を監査証跡として認めない。開発が ホスト型マネージドエージェント だけに寄り、顧客側テストよりベンダ保証に依存する。

6-3. 長期（1年以上）

予想される動き — エージェント安全が、従来の静的解析・動的解析（SAST／DAST）に近い 開発ライフサイクルの標準枠 の一角になる、という業界方向性は読み取れる（Microsoft は「continuous engineering discipline」と明記）。レッドチーム知見の OSS テストカタログ が共有され、回帰テストの相互運用が進む可能性もある。

不確実性 — 規制が要求する証跡形式との整合、攻撃手法の陳腐化による 形骸化、自律エージェントの行動空間拡大に evaluator が追いつかないこと。

効果が出にくい条件 — 単一ベンダ閉域で OSS 資産が流通しない。業界全体が ベンダ側の保証 に責任を寄せ、顧客 CI テストが不要とみなされる。

7. まとめ

今回のポイントを一言でまとめると、
Microsoft は、エージェントが「答える」から「動く」段階に合わせ、安全をレポートから pytest と設計メモへ移す OSS を二つ公開した、ということです。

  • 2026年5月20日、Security Blog で RAMPART と Clarity を OSS 公開

  • RAMPART — PyRIT 上の pytest＋CI。成熟カバレッジの中心は クロスプロンプト注入。統計的合格 を前提

  • Clarity — 実装前の why と失敗モードを `.clarity-protocol/` に。複数 LLM プロバイダに対応（README）

  • PyRIT は探索、RAMPART は固定化 — 置き換えではない二段構え

  • 同日の npm 侵害 記事とは レイヤが異なる（ビルド vs ランタイム挙動）

開発チームは、まず 注入シナリオ 1 本 を CI に載せる試みから始め、PM・アーキテクトは Clarity で要件の言い換え を先にやる。セキュリティは レポート納品で終わらせずテスト資産を残す ルールを検討する、という切り口が現実的です。

主な参照

免責

本記事は公開情報をもとにした一般的な整理です。OSS の API・閾値・カバレッジは変更されうます。契約、法務、セキュリティ、監査、本番導入、無許可の侵入テストは、Microsoft および関連ベンダーの最新ドキュメント、自社の契約・設定、社内規程、専門家・担当部門の確認に従ってください。投資判断の材料ではありません。

【PR】
私も転職エージェントを利用して転職しました。


いいなと思ったら応援しよう！