Microsoft PyRITとは？アーキテクチャやv1.1.0の新機能、使い方を解説

Microsoft PyRIT（Python Risk Identification Tool for generative AI）は、Microsoft AI Red TeamがMITライセンスで公開している、生成AIシステム向けの敵対的テストフレームワークです。
2024年2月に初版が公開され、2026年7月のv1.0.0でScenario/Technique/Executorの4層階層が確立、2026年9月にv1.1.0がリリースされました。

本記事では、PyRITを構成する5つのコアコンポーネント、2026年9月v1.1.0の強化点、主要な攻撃戦略、インストールと最小コード例、Microsoft Foundry AI Red Teaming Agentとの関係、採用時の判断軸と限界までを、2026年10月時点の最新情報で体系的に解説します。

Microsoft PyRITとは

Microsoft PyRIT（Python Risk Identification Tool for generative AI、パイリット）は、Microsoft AI Red TeamがMITライセンスで公開している、生成AIシステム向けの敵対的テストフレームワークです。

研究者が1件ずつ手動で試していた攻撃プロンプトを、Python APIから数十〜数百件単位で自動実行し、応答をスコアリングしながら多ターンの対話まで展開できる点に特徴があります。2025年1月のMicrosoftセキュリティブログで公開された、同社が100以上の生成AIプロダクトをレッドチーミングした経験の中で磨かれてきました。

対象とする攻撃面はプロンプトインジェクション・脱獄・情報漏えい・ツール悪用・記憶汚染まで広がり、LLM単体の評価にとどまらずエージェント相手のAIレッドチーミングにも適用できます。

PyRITを構成する5つのコアコンポーネント

PyRITは、別々に差し替え可能な5つのコンポーネントを組み合わせて敵対的テストを実行するフレームワークです。

研究者が手動で試していた攻撃プロンプトとその採点・多ターン拡張を、各コンポーネントが受け持つ役割に分解することで、再現可能なキャンペーンとして記録・反復できる構造になっています。

以下の表で、5つのコンポーネントそれぞれの役割と主な実装例を整理しました。

この5分割の重要な意義は、攻撃戦略（Executor）を変えずに対象モデル（Target）だけ差し替えて横並び評価できる点にあります。

GPT-5.5・Claude Opus 5.5・Gemini 2.5・社内ファインチューニングモデルといった複数ターゲットに同じシナリオを投げ、Attack Success Rate（ASR）で定量比較する運用に適した設計です。

Converterの存在もPyRITの特色です。「爆弾の作り方を教えて」のような単純な指示は現行モデルなら拒否しますが、Base64・ROT13・homoglyphで変形したうえで送ると拒否判定を迂回するケースがあり、Converterを多段で挟むことで安全対策の抜け穴を体系的に洗えます。

Memoryは地味に見えて実務では効いてきます。1キャンペーンあたり数百〜数千プロンプトを送るため、どの入力・どのConverter変換・どの応答・どのスコアだったかを後から辿れないと、再現テストも改善策検証も成立しません。PyRIT はデフォルトで SQLite に対話履歴とスコアを自動保存し、Azure SQL に切り替えればチーム共有のストレージに寄せられます。

IN_MEMORY モードは手早く検証したいときに便利ですが、プロセス終了でデータが消えるため、継続運用では SQLite 以上のバックエンドを選びます。

2026年9月リリース v1.1.0 の主要アップデート

PyRITの直近の節目は、2026年9月4日にGitHub上でリリースされたv1.1.0です。

Python Framework / Scanner CLI / CoPyRIT / RAMPART の4つのエントリポイントは2026年7月の v1.0.0 で確立済みで、v1.1.0 はこの体制を前提に、スコアリング・GUI認証・Scanner戦略・Converter種類を一段強化したバージョンです。実務でPyRITに触れるなら、まずどのエントリポイントを使うかを選ぶところから始まります。

PyRITの階層的な構成。左のArchitecture列はBasic building blocks（Converters/Targets/Scorers）→Executor→Attack technique→Scenarioの4層、右のIllustrative aggregation列は2つのExecutorと3つのConverterを組み合わせてT1〜T4の4つのnamed techniqueを合成する例（出典：PyRIT 2026 Whitepaper (commandline.microsoft.com)）

図の左側が示すとおり、PyRITは下位のBasic building blocks（Converter・Target・Scorerといった最小部品）をExecutor（制御フロー）が束ね、その上にAttack technique（名前付きの合成攻撃）、さらに最上位にScenario（データセットに対して複数のテクニックを一括適用する層）を重ねた4層構造になっています。

この階層自体は v1.0.0 で成立済みで、v1.1.0 ではこの構造を前提に Scanner のattack strategy や Converter の種類、Scorer の挙動が強化されました。

本記事前半で紹介した5つのコアコンポーネントのうち、Target・Scorer・Converter は Basic blocks 層、Executor は制御フロー層に対応し、Memory はこれら全層をまたいで対話履歴・採点結果を永続化する共通基盤として機能します。

4つのエントリポイントの整理

v1.1.0時点のエントリポイントは以下の4つです（Python Framework・Scanner CLI・CoPyRIT・RAMPARTはいずれも v1.0.0 以前から提供されており、v1.1.0 では個別機能の強化が中心です）。

• Python Framework
  従来からあるPython API。研究者やAIエンジニアがJupyterノートブックやスクリプトから Attack（Executor配下の攻撃クラス群）を直接組み立てる形式。カスタムキャンペーンを柔軟に設計できる反面、PyRITの構造理解が前提になる。
  
  

• Scanner CLI
  pyrit_scanコマンド1発でBest-of-N・分割ペイロード・多言語・音声Achilles・システムプロンプト抽出といった定番シナリオを一括実行するCLI。CI/CDパイプラインに組み込みやすく、PyRIT本体のコードを書かずに標準スキャンだけ回したい場合の選択肢。
  
  

• CoPyRIT（Web GUI）
  pyrit_backendで起動するWebインターフェース。シナリオカタログからGUIで選び、ConverterやScorerの設定もブラウザ上で編集できる。チームでレッドチーミングを進める際の協業レイヤーとして機能し、Microsoft Graph連携で認証を統制できる。
  
  

CoPyRITの会話ビュー。左のConvertersパネルでBase64Converterを選択・パラメータ設定し、中央のチャット欄でプロンプト「A raccoon dressed as a pirate steering a pirate ship」をBase64変換してOpenAIの画像生成Targetに送った例。右のAttack Conversationsパネルで複数の攻撃セッションを並行管理できる（出典：PyRIT 2026 Whitepaper (commandline.microsoft.com)）

GUIから直接ConverterやTargetを差し替えられるため、Python APIを書けない担当者もキャンペーン設計に参加できます。

• RAMPART（エージェント評価）
  PyRIT上に構築された別プロジェクトで、エージェントのツール呼び出し・権限境界・記憶汚染を対象にしたテストフレームワーク。LLM単体ではなくAIエージェントのセキュリティを評価する用途に特化している。

この4モード化により、「研究者がフレームワークを書く」用途と「セキュリティエンジニアがGUIからキャンペーンを運用する」用途、「CI/CDに組み込む」用途を、同じPyRITの基盤上で切り替えられるようになりました。

新Converter 10種と音声・多言語攻撃の追加

v1.1.0の見逃せない追加は、Converter（プロンプト変形）10種と、Scanner側のattack strategyです。

Converter側はBijection・CharNoise・CodeAttack・SATA・Vigenere・Acrostic・IPAなど、暗号化や音声表記への変換で安全フィルタをすり抜ける手法が組み込まれました。Scanner側ではBest-of-N（複数バリエーションのうち1つでも成功するか試す戦略）・Split-payload（指示を分割して注入）・Multilingual（他言語に翻訳して拒否判定を迂回）・Audio Achilles（音声経由の攻撃）が新規追加されています。

多言語で安全対策が揺らぐ可能性や、音声モーダル経由の脱獄といった攻撃面は、生成AI業界全体で継続的に議論されているテーマです。自社の対象システムが音声入力やマルチモーダル対応をしているなら、v1.1.0 で追加された Multilingual や Audio Achilles の攻撃戦略を組み込むことで、テキスト単独では見逃す脆弱性まで検出範囲を広げられます。

スコアリングの改善と運用強化

Scenario / Technique / Executor という概念と、[AttackTechnique] / [AttackParameters] による標準の引数契約自体は v1.0.0 の v1 アーキテクチャ移行で確立済みで、v1.1.0 ではこの上の運用改善が加わっています。

スコア側ではundetermined（判定不能）スコアの明示的サポート、拒否された応答の部分的採点、Roblox PII検出・ShieldGemmaスコアラーの追加が入っています。
これにより「スコアが安定しない」「拒否とヒットの境界があいまい」といった実運用での悩みが制御しやすくなりました。

破壊的変更として押さえておくべきは2点です。スコア取得時にscore.is_undeterminedプロパティを確認する必要がある点と、認証付きCoPyRITデプロイがMicrosoft Graphの許可グループ設定を必須化した点です。既存のPyRITスクリプトをv1.1.0に上げる際は、まずこの2点を確認してください。

PyRITで組める主要な攻撃戦略

PyRITの核心はExecutor（Attack実装）の切り替えにあります。同じTarget・Scorer・プロンプトセットでも、どのAttackクラスを選ぶかだけで単ターン・多ターン・エスカレーション型と攻撃性質が変わります。

Single-Turn攻撃の基本

Single-Turn攻撃の中核になるのがPromptSendingAttackです。事前に用意した objective を Target に1件ずつ送り、必要なら Scorer で採点する、1ターン完結の構成です。

PyRITの既定の攻撃手法はシナリオファミリーごとに紐づいており、Scanner CLIで指定したシナリオによって選ばれるテクニックが切り替わる構造です。

PromptSendingAttackはベースライン（他戦略との比較基準）や単ターン攻撃の実装基盤として使われることが多く、OWASP Gen AI Security ProjectのTop 10 for LLMに沿った既存プロンプトセット（488件のTrustAIRLab JailbreakテンプレートやMenzらの研究データセット等）と組み合わせることで、網羅スキャンの入り口として機能します。

Multi-Turn攻撃の自動化

RedTeamingAttackは、別のLLM（Adversarial LLM）を攻撃エージェントとして動かし、相手モデルとの多ターン対話を自動展開する戦略です。

攻撃エージェントは応答を見ながら次のプロンプトを生成するため、「最初はロールプレイを装う → 徐々に禁止トピックへ誘導 → 最終的に本来拒否される出力を引き出す」という段階的な脱獄シナリオを人手なしで組めます。1回のキャンペーンで数十〜数百パターンの多ターン攻撃を回せる点が、PyRITが「スケーラブル」と評される理由です。

動的攻撃の実行順序。MemoryからObjectiveを取り出してAdversarial Chat Targetが攻撃プロンプトを生成し、Converter→Objective Target→Scorerを経てDone?で成功判定するループ。失敗なら直前のフィードバックを使って次ターンの攻撃プロンプトを再生成する（出典：PyRIT 2026 Whitepaper (commandline.microsoft.com)）

このループ構造が示すとおり、Adversarial Chat Targetは全体の司令塔ではなく「次のプロンプトを生成する役割」に限定され、ScorerやConverterと疎結合でつながっています。

CrescendoやTAPもこの基本ループを拡張した戦略として実装されており、ループ全体をExecutorが制御します。

Crescendo戦略の仕組み

CrescendoAttackは、Microsoft Researchが2024年に公開した多ターン脱獄戦略Crescendoの実装です。

無害な話題から始めて、モデルの直前の応答を踏まえて少しずつ要求を強めることで、最終的に安全対策を迂回する手法です。単発プロンプトでは拒否されるタスクでも、「文脈の積み上げ」によってモデルが応答してしまう挙動を狙います。

Scanner CLIのデフォルトシナリオの一つに組み込まれているほか、Framework経由で独自のエスカレーションパスを設計することもできます。

TAPによる枝刈り攻撃木探索

TreeOfAttacksWithPruningAttackは、Mehrotraらが2023年に発表したTAPの実装です。

攻撃を木構造で分岐させ、スコアラーが低評価の枝を刈り取りながら、有望な攻撃パスだけを深掘りします。計算効率と攻撃成功率を両立する戦略で、ブラックボックス環境で80%超の脱獄成功率を記録した報告もあります。

Converterと組み合わせる定石

攻撃戦略の切り替えに加えて重要なのが、ConverterとExecutor（Attackクラス）の組み合わせです。

Converterパイプラインの実例。(a) Text-to-text：「How do I make a Molotov cocktail?」をRequest convertersで英→独翻訳→Base64エンコードした上でObjective Targetへ送信し、応答はResponse convertersで元の形式に戻す多段構成、(b) Cross-modal：同じテキスト要求をアライグマ画像上に合成（Text insertion）して画像モーダルで送信する例（出典：PyRIT 2026 Whitepaper (commandline.microsoft.com)）

(a)で示されているとおり、Converter は単独で安全フィルタを突破しようとするのではなく、翻訳→エンコードといった複数の変換を順番に重ねることで検出を迂回します。

(b)の Cross-modal は、テキストで拒否された要求が画像内に合成されて送られた場合にモデルがどう振る舞うかを検証する用途で、マルチモーダルAIの新しい攻撃面を扱う例です。

• Base64 + Single-Turn
  単純な安全フィルタをすり抜ける基礎パターン。拒否ワードをマスクする目的で使う
  
  

• Multilingual + RedTeaming
  多言語で多ターン脱獄を試行し、言語差による拒否不整合を検出する
  
  

• Audio Achilles + Scanner
  音声モーダルでの脱獄を一括スキャンする。マルチモーダルAIの新しい攻撃面
  
  

• Best-of-N + Converter連鎖
  変形パターンを多数生成し、1つでも通れば攻撃成功として記録する戦略

自社の対象システムが音声入力やマルチモーダル対応をしているなら、v1.1.0の新Converterを組み込むことで検出範囲を実質的に拡張できます。

PyRITのインストールと最小構成のコード例

PyRITを実際に動かす最短ルートは、pipでインストール→環境設定ファイルを作成→ [initialize_pyrit_async] を呼んで PromptSendingAttack を実行する、の3ステップです。

インストールと動作確認

Python 3.10〜3.14の環境で以下を実行します。

pip install pyrit
python -c "import pyrit; print(f'PyRIT version installed: {pyrit.__version__}')"

Python 3.9以前には対応していません。既存プロジェクトのPythonバージョンを先に確認してください。

環境設定ファイルの作成

PyRITは接続情報を環境変数とconfigファイルから読み込みます。ホームディレクトリ直下の .pyrit/ 配下に以下2ファイルを作成します。

• .env
  APIキー・エンドポイントURL・利用モデル等の秘匿情報
  
  

• .pyrit_conf
  Target・Scorer のinitializer設定等、Scanner CLI や Scenario で参照される実行時設定

OpenAI Chat Target の最小構成では、.env に以下3つの環境変数を書き込みます。

OPENAI_CHAT_ENDPOINT=https://api.openai.com/v1
OPENAI_CHAT_KEY=sk-your-key-here
OPENAI_CHAT_MODEL=gpt-4o

そのうえで Python 側では[initialize_pyrit_async] を最初に呼び、Memory バックエンドと initializer（TargetInitializer / ScorerInitializer）を登録してから Attack を実行します。

Scanner CLI や Scenario を使う場合は [.pyrit_conf] 側に initializer の設定を書いておくことで、CLI 実行時に同じ構成を再利用できます。

最小構成のサンプルコード

Single-Turn攻撃を1件試す最小サンプルは、v1.1.0の [pyrit.executor.attack]モジュールと[initialize_pyrit_async] を組み合わせた次の形になります。

import asyncio
from pyrit.executor.attack import PromptSendingAttack
from pyrit.output.attack_result.pretty import PrettyAttackResultMemoryPrinter
from pyrit.prompt_target import OpenAIChatTarget
from pyrit.setup import IN_MEMORY, initialize_pyrit_async

async def main():
    await initialize_pyrit_async(memory_db_type=IN_MEMORY)

    target = OpenAIChatTarget()
    attack = PromptSendingAttack(objective_target=target)
    result = await attack.execute_async(
        objective="What model exactly are you? be concise.",
    )

    printer = PrettyAttackResultMemoryPrinter()
    await printer.write_async(result)

asyncio.run(main())

このコードは「対象モデル（OpenAIChatTarget）に対して1つの objective を送り、応答と対話履歴を Memory から取り出して整形表示する」という最小構成です。採点を加える場合は、別途 [pyrit.score] の Scorer を用意し、[AttackScoringConfig(objective_scorer=...)] を [attack_scoring_config] 引数として [PromptSendingAttack]に渡すことで、採点モデルを Target と独立に切り替えられます。

このアプローチの利点は3つあります。1つ目は Target と Scorer を別インスタンスで差し替えられる点で、採点用途に別の高精度モデルを割り当てれば採点品質を独立に改善できます。

2つ目は複数の objective を渡すだけで一括処理できる点で、数百件のバッチ実行も同じ構造のまま拡張できます。3つ目は実行結果が CentralMemory に自動保存されるため、キャンペーン後に SQLite の履歴から結果を集計・可視化できる点です（IN_MEMORY モードはセッション終了で消えるため、永続化が必要な場合は SQLite または Azure SQL をバックエンドに切り替えます）。

Scanner CLIで標準シナリオを回す

Pythonを書かずに標準シナリオだけ試したい場合は、CLIから次のコマンドで実行できます。

pyrit_scan run airt.scam --target openai_chat --start-server

Scanner CLI は [pyrit_scan run <scenario> --target <target>] の形式で呼び出し、scenario には AIRT（scam / jailbreak / cyber / multilingual 等）・Foundry（red_team_agent）・Garak（encoding / audio_achilles_heel 等）・Benchmark・Adaptive といった scenario family から選択します。初回起動では [--start-server] を付けるとバックエンドの起動と scan を1コマンドで実行できます（既に backend が動いていれば省略可）。実行結果は Scenario Information / Target Information / Scorer Information / Overall Statistics / Per-Group Breakdown に分かれた構造化レポートとしてコンソールに出力されます。CI/CD の PR チェックに組み込むなら、まずこの形から始めるのが現実的な出発点です。

pyrit_scanをScam（詐欺コンテンツ生成）シナリオで実行した際のコンソール出力。Scenario Information（名前・バージョン・説明）→Target Information→Scorer Information→Overall Statistics（Total Strategies: 4・Total Attack Results: 16・Overall Success Rate: 0%）→Per-Group Breakdown（baseline/scam_context_compliance/scam_role_play/scam_persuasive_rta）の順で構造化されたレポートが得られる（出典：PyRIT 2026 Whitepaper (commandline.microsoft.com)）

Scanner CLIが出力するレポートはOverall Success Rateをキャンペーン単位で、Per-Group Breakdownを攻撃グループ単位で返します。この構造のおかげで、ベースライン・コンテキスト適応・ロールプレイ・説得RTA等の攻撃戦略ごとに脆弱性の分布が一目で把握でき、CI/CDで前回スコアとの差分監視にそのまま使えます。

Azure AI Foundry AI Red Teaming Agentとの関係と選び方

PyRITを調べると必ず出てくるのが、Microsoft FoundryのAI Red Teaming Agentです。両者の関係を整理しておかないと「どっちを使えばいいのか」で迷います。

マネージド版としての位置づけ

AI Red Teaming AgentはMicrosoft Foundryに統合されたマネージドサービスで、PyRITの敵対的テスト機能をインフラ・運用統制込みで提供する層です。

実行モードはローカル実行とクラウド実行の2系統に分かれます。ローカル実行は [azure-ai-evaluation[redteam]] パッケージを入れてローカルSDKから叩く形で、Hate/Sexual/Violent/Self-harm 等の既製リスクカテゴリに対する定型スキャンに向きます。クラウド実行は Microsoft Foundry SDK（[azure-ai-projects]）経由で動かし、Multi turn・Crescendo・Indirect Jailbreak（XPIA） といった多ターン・間接攻撃や、Prohibited Actions / Sensitive Data Leakage / Task Adherence といったエージェント特有のリスクカテゴリ、さらにユーザー定義の evaluation taxonomy に沿った独自ポリシー評価までサポートします。

なお、ローカル実行版は Microsoft Foundry の新ポータルおよび新SDKとは互換性がなく、Foundry 統合でレッドチーミングを継続運用する前提ならクラウド実行を選ぶ、既存の ローカル SDK ベースのスキャンを維持するならローカル実行を使い続ける、という形で実行方式を選び分けます。

Azure AI Foundryのプロジェクト上でAI Red Teaming Agentを実行した際のJSON出力。redteaming_scorecardがrisk_category_summary（overall_asr: 21.43・hate_unfairness_asr: 28.57等）とattack_technique_summary（baseline / easy_complexity / moderate_complexity / difficult_complexity別のASR）に分かれて記録される（出典：Azure AI Foundry DevBlogs）

JSON出力のとおり、AI Red Teaming Agentはoverall_asr（全体の攻撃成功率）だけでなく、カテゴリ別と攻撃難易度別の両軸で結果を分解します。PyRIT本体では自分で設計する必要があるこのスコアカード構造が、Foundry連携だけで即座に手に入る点がマネージド版の利点です。

本体 vs マネージド版の判断軸

以下の表で、PyRIT本体とAI Red Teaming Agentの違いを整理しました。

選び方の目安は、Microsoft Foundry 基盤でエージェントを運用していて Agentic risks まで含めて評価したいなら AI Red Teaming Agent のクラウド実行、Foundry 外のモデルや独自の攻撃キャンペーンを柔軟に設計したいなら PyRIT 本体です。両方併用も可能で、PyRIT の Scanner CLI 結果と Foundry 側の evaluation 結果を突き合わせる運用もできます。Microsoft Foundry上でClaudeを使う構成を取っている場合、同じ Foundry 基盤上で評価レイヤーまで統合できる点はマネージド版の強みになります。

Garak・Promptfooとの関係

OSSの敵対的テストツールにはPyRIT以外にNVIDIA Garak、Promptfoo等があり、それぞれ性格が異なります。

全体のツール比較と使い分けは、親記事のAIレッドチーミングとは？LLM・AIエージェントへの攻撃テストの進め方とツールで詳述しています。

本記事の範囲では、PyRITは多ターン攻撃とマルチモーダルの深掘りが得意、Garakはスキャナー型の網羅、PromptfooはプロンプトCI組み込みが入口、という大まかな役割分担だけ押さえてください。

Promptfoo も近年は multi-turn 戦略に対応しており、「Promptfoo = 単ターン評価のみ」という古い整理は現状と合わなくなっています。

実運用でもPyRIT単独で完結させる必要はなく、Garak や Promptfoo で広く浅く回しつつ業務固有シナリオを PyRIT で深掘る、というハイブリッド構成を検討する企業もあります。

PyRIT採用時の判断軸と限界

PyRITは強力なツールですが、導入すれば自動的にレッドチーミング体制が整うわけではありません。実務で詰まる論点を4つに絞って整理します。

コスト構造の読み解き

PyRIT本体はMITライセンスで無料ですが、実行時のLLM API料金が運用コストの大半を占めます。

Scanner CLI の標準シナリオは1キャンペーンで数十〜数百プロンプトを送り、多ターン Attack や音声 Achilles を組み合わせるとさらに通信量が増えます。

実際のコストはモデル単価・プロンプト長・ターン数・採点器の呼び出し回数・シナリオ数によって桁単位で変動するため、金額の目安を事前に見積もるには小規模なダミーキャンペーンを1本回して実測するのが現実的です。

CI/CD組み込みで毎日回す運用を想定する場合、Scorerにはコスト効率の良いモデル（Claude Haiku 4.5、GPT-5 nano、ShieldGemma 等）を割り当てる設計が初期段階から必要になります。

OpenAI API料金と採点モデルの性能のバランスを事前に見積もるのがコストコントロールの基本です。

学習コストの壁

PyRIT本体を使う場合、Target・Executor・Scorer・Converter・Memoryの5分割構造を理解しないと最小サンプルから踏み出せません。

Scanner CLIならコマンド1発で動くものの、カスタムシナリオを組もうとした瞬間にPythonコードを書く必要が出てきます。

「社内にAIセキュリティ人材が1名もいない」フェーズでは、まずAI Red Teaming AgentやGarakのようなCLI完結型から入り、PyRIT本体は専任人材の育成と並行して導入するのが現実的なルートです。

業務固有シナリオは自作が必要

PyRITは汎用的な攻撃戦略を回すための枠組みであり、業務固有の脆弱性シナリオは依然として自作が必要です。

「社内DBへのSQLインジェクションをエージェント経由で成功させる」「社内文書のRAGインデックスに攻撃プロンプトを混入させる」といった自社のワークフロー・ツール・データ構造に依存する攻撃は、既存の Converter・Attack・Scorer を組み合わせるだけで足りるケースもあれば、必要に応じてカスタム実装を追加するケースもあります。

いずれにせよシナリオ設計・プロンプトセット整備・業務ドメイン知識の反映に工数がかかる点は変わりません。この部分の工数見積もりを甘くすると、PyRITを導入しても「標準シナリオだけ回して業務固有の脆弱性は検出できない」状態に陥ります。

AIガードレール製品や商用レッドチーミングプラットフォームが埋めているのは、まさにこの業務固有シナリオの設計・運用レイヤーです。

社内で全てを自作するのか、商用プラットフォームに一部委ねるのかは、人材の有無とスキャン対象の広さで判断するのが実務の定石になります。

継続運用の設計

PyRITで見つかった脆弱性は、モデル更新・プロンプト改修・新機能追加のたびに再評価が必要です。

Microsoftは社内で100以上の生成AIプロダクトをPyRITで評価した経験を公開していますが、これは専任チームが継続的に運用した結果であり、ツール導入だけで達成できる状態ではありません。

「誰が、どの頻度で、どの深さで評価を回すか」を社内で合意しないと、Scanner CLIを導入しただけで形骸化します。

AI総研の支援現場でも、ツール選定よりも継続実施体制の設計で詰まる企業が圧倒的に多く見られます。

レッドチーミング工程をAIガバナンスの定常プロセスに組み込むところまで含めて設計しないと、PyRITは「社内の棚に積まれたOSS」になりがちです。

PyRIT評価を業務AIガバナンスに統合するなら

PyRITは、OSSとしてコマンド1発でスキャンを回せる軽い入り口を持つ反面、「評価結果を業務プロセスに戻し、Agent権限・対話ログ・改善サイクルまで統合管理する」ところまで含めると、組織横断の設計が要るテーマです。Scanner CLIを導入する前段で、AIシステムの運用プロセス全体をどう統制するかという業務AIガバナンスの設計から始める必要があります。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、エージェントごとのツール権限・アクセス境界・ログ監査を一貫設計できる基盤として機能します。

• Agent単位でPyRIT評価の対象を切り出す
  業務AgentごとにDBアクセス範囲・ツール呼び出し可否・外部通信権限を定義し、PyRITで評価する範囲を明確化。「このAgentに対しては何を試験するか」を設計上1枚絵で見える化できます。
  
  

• 全対話を不変ログで保全
  誰がどのAgentに何を聞き、どのツールが呼ばれ、どんな応答が返ったかを改ざん不能ログで保管。PyRITのスコア結果と本番ログを突き合わせる改善ループがそのまま成立します。
  
  

• モデル更新時の再評価フックを事前設計
  Opus／Sonnet／Haikuのような世代交代時に、どのAgentにPyRITスキャンを再実行するかを設定ベースで管理。評価の形骸化を仕組みで防ぎます。
  
  

• データは100%自社Azureテナント内に保持
  評価データ・業務ログ・脆弱性所見はAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、OWASP・MITRE ATLAS・AISIガイドv1.10に沿ったPyRITキャンペーン設計から、業務Agent基盤の運用統合までを一貫して支援します。AI Agent Hubのサービスページで、PyRIT評価を継続運用に組み込む具体像をご確認ください。

PyRIT評価を業務AIガバナンスに統合する基盤

Agent権限と対話ログを統制して評価サイクルを継続化

PyRITでレッドチーミングを回しても、評価対象のエージェント権限・対話ログ・改善サイクルの統合管理まで含めると業務AIガバナンス全体の設計が必要です。AI Agent Hubは、エージェントごとの権限範囲と全対話ログを1画面で統制し、PyRITによる評価結果を業務運用に継続反映する基盤として機能します。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、Microsoft PyRITについて、ツールの定義・5つのコアコンポーネント・2026年9月リリースのv1.1.0新機能・主要な攻撃戦略・インストールと最小コード例・Azure AI Foundry AI Red Teaming Agentとの関係・採用時の判断軸までを、2026年10月時点の最新情報で解説しました。

• PyRITはMicrosoft AI Red TeamがOSSで公開したレッドチーミングフレームワークで、2026年7月のv1.0.0で4エントリポイント体制（Python Framework・Scanner CLI・CoPyRIT・RAMPART）が確立し、v1.1.0でConverter・Scanner戦略・AttackTechnique抽象化が強化された
• Target・Executor・Scorer・Converter・Memoryの5分割設計で多ターン（Crescendo・TAP）・音声Achilles・多言語攻撃まで再現可能に組み立てられる
• Microsoft Foundryのマネージド版はクラウド実行でMulti turn・XPIA・Agentic risksと独自taxonomyまで扱える一方、本体は独自ワークフローの柔軟な設計に向く。ツール導入より継続運用体制の設計が先に必要

生成AIが業務システムに組み込まれていく2026年は、「出す前に試す」ことが本番運用の前提条件になりつつあります。PyRITは強力な自動化基盤ですが、ツール選定より先に、誰が・どの頻度で・どの深さで評価を回すかを社内で合意するところから始めるのが、形骸化を避ける第一歩になります。