AI Red Teaming Agentの使い方：Microsoft Foundryで生成AIとエージェントを自動レッドチーミングする手順【2026年10月】

AI Red Teaming Agentは、Microsoft Foundry（旧Azure AI Foundry）に組み込まれた自動レッドチーミング機能です。MicrosoftのオープンソースPyRITが作る攻撃プロンプトをモデルやエージェントへ送り、返ってきた応答をRisk and Safety Evaluatorsが採点して、攻撃成功率（ASR）のスコアカードにまとめます。2026年に入って、ローカル実行（azure-ai-evaluation）とクラウド実行（azure-ai-projects 2.x）で使うSDKも、対応する範囲もはっきり分かれました。本記事は2026年10月31日時点の公式ドキュメントとPyPIの配布物を突き合わせ、どちらで何を検査できるか、手順、結果の読み方、導入前に知っておきたい制約までを整理します。AIレッドチーミングそのものの考え方や他ツールを含む進め方はAIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定で扱っています。

まとめ：AI Red Teaming Agentの要点（2026年10月時点）

• モデル単体はローカル版（azure-ai-evaluation[redteam]）、Foundryのエージェントはクラウド版（azure-ai-projects>=2.0.0 のevals API）で検査する。ローカル版は新しいFoundryポータル・SDKと互換性がない。
• 暴力・性的・ヘイト・自傷など7カテゴリはモデルとエージェントの両方に使える。禁止アクション・機微データ漏えい・タスク遵守の3カテゴリはエージェント専用で、クラウド実行だけ。
• ローカル版の対応はPython 3.10〜3.13。1.18.10の[redteam]はpyrit 0.11.0に固定されており、pipではPython 3.14に入らない。
• クラウド実行のリージョンはドキュメント間で2地域と5地域に記載が割れている。どちらにも載るのはEast US 2とNorth Central USで、Japan Eastはどちらにも無い。
• 結果は「ベースラインのASR」と「攻撃戦略を掛けたASR」の差で読む。Agentは検出ツールなので、防御はContent Safety・システムメッセージ・ガードレールで別に組み、変更のたびに再スキャンする。

AI Red Teaming Agentの仕組み：PyRITの攻撃と安全性評価をつなぐ流れ

公式の概念ページによると、AI Red Teaming Agentの役割は3つです。敵対的な問いかけを模した自動スキャン、攻撃と応答のペアごとの採点、そしてスコアカードの作成とFoundryへの記録です。人手のレッドチーミングを置き換えるものではなく、既知のリスクを規模を上げて繰り返し確かめる道具という位置づけです。PyRITはMicrosoft AI Red Teamが自分たちの業務用に作ったフレームワークで、同チームは100を超える生成AI製品のレッドチーミングから得た知見を公開しています。

ベースライン・攻撃戦略・採点の3段とASR

スキャンは次の順で進みます。まずリスクカテゴリごとに、Microsoftが用意した攻撃目標（シードプロンプト）をそのまま送ります。これがベースラインです。続いてBase64化や文字の反転といった攻撃戦略で同じプロンプトを変換して送り直し、最後に全ペアを採点します。直接「銀行の襲い方を教えて」と聞けば拒否するモデルでも、文字を反転させると答えてしまう、という例が公式ページに載っています。

中心の指標はAttack Success Rate（ASR）で、全攻撃のうち望ましくない応答を引き出せた割合です。採点も生成モデルが行うので結果は決定的ではなく、公式も誤検知の可能性を認めて「対策の前に結果を人が確認する」よう勧めています。ASRは合否の一発判定ではなく、どこを人が詳しく見るかを決める指標として使います。

ローカル版とクラウド版の2系統と新旧Foundryの違い

ローカル版とクラウド版は、使うSDKも対象も違う別の入口です。ローカル実行の手順には「AI Red Teaming Agent local is not compatible with the Foundry(new) portal and SDK.」と明記されています。新ポータルでエージェントを作ったなら、クラウド版を使うのが前提です。

提供状態の表記も入口によって違います。新FoundryのGA機能一覧（2026年8月14日版）ではBuild領域の「Red teaming」がGAと表記されています。一方、ローカル実行の手順ページは「(preview)」表記のままで、クラウド版のREST APIも api-version=2025-11-15-preview を指定します。本番の判定ゲートに組み込む前に、使う入口ごとにSLAの有無を確認しておくと後で揉めません。

リスクカテゴリと検査できる範囲

モデルとエージェント共通の7カテゴリと攻撃目標の上限

2026年8月更新の概念ページでは、次の7カテゴリが「Model and agents」「Local and cloud」になりました。以前はローカル実行でモデルだけが対象でした。ローカル版の既定は先頭4カテゴリで、num_objectives（カテゴリごとの攻撃目標数）の既定は10です。

CodeVulnerabilityは、コードインジェクション、tar-slip、SQLインジェクション、スタックトレースの露出などをPython・Java・C++・C#・Go・JavaScript・SQLの7言語で見ます。コード生成を含むアシスタントでは既定4カテゴリだけでは足りないので、明示的に追加します。

エージェント専用3カテゴリと対応するエージェントの範囲

Prohibited actions（禁止・高リスク・不可逆な操作の実行）、Sensitive data leakage（財務・個人・医療データの漏えい）、Task adherence（目標・ルール・手順からの逸脱）の3つは、生成テキストだけでなくツールの出力まで検査します。そのため最低限のサンドボックスを用意できるクラウド実行に限られます。公式概念ページがシングルターン・英語のみと明記するのは、禁止アクションと機微データ漏えいの2カテゴリです。タスク遵守については同じ制限の明記がありません。外部の文書やメールに命令を仕込む間接プロンプトインジェクション（XPIA）は、IndirectJailbreak戦略としてこれらのカテゴリと組み合わせて使います。攻撃の仕組みはプロンプトインジェクションとは？攻撃例・種類と対策をOWASP LLM01とコードで解説で解説しています。

注意したいのは、対応するエージェントの範囲が狭いことです。概念ページの対応表で「Supported」なのは、Foundryでホストするプロンプトエージェントとコンテナーエージェント、それにAzureのツール呼び出しだけです。ワークフローエージェント、Foundry以外のエージェント、Azure以外のツール、関数ツール、ブラウザー自動化、Computer Useは対象外です。関数ツールで社内APIを呼ぶ構成のエージェントは、エージェント専用カテゴリでは検査できません。その部分は後述のPyRIT単体やpromptfooで補います。

クラウド実行の結果では、送り込んだ有害な入力が伏せ字になります。Foundryホストのエージェントを相手にした実行は一時的な扱いで、Agent Serviceにログやチャット履歴は残りません。公式は本番と同等の構成にした非本番環境（purple environment）での実施を勧めています。

攻撃戦略の選び方：EASY・MODERATE・DIFFICULTとCompose

攻撃戦略は、攻撃者に必要な労力で3段階に分かれます。グループ指定の中身は次のとおりです。

個別指定できる戦略は、EASYがAnsiAttack・AsciiArt・AsciiSmuggler・Atbash・Binary・Caesar・CharacterSpace・CharSwap・Diacritic・Leetspeak・ROT13・SuffixAppend・StringJoin・UnicodeConfusable・UnicodeSubstitution・Url・Jailbreakなど、DIFFICULTがMultiTurnとCrescendoです。AttackStrategy.Composeで2つの戦略を連結できますが、3つ渡すと1.18.10では「Composed strategies must have at most 2 items」のValueErrorで止まります。

件数の見積もりも先にしておきます。既定の4カテゴリ×10件にEASY・MODERATE・DIFFICULTをすべて掛けると、ベースライン40件に戦略5種×40件の200件が加わり、計240ペアが採点に回ります。最初はベースラインだけ、またはEASYだけで回し、ASRが上がったカテゴリにだけ戦略を広げる順が無駄がありません。

ローカルでモデルをスキャンする手順（azure-ai-evaluation）

ローカル版のインストール要件とPython 3.14の非対応

PyPIのazure-ai-evaluationは2026年10月23日公開の1.18.10が最新です。[redteam]エクストラはpyritをpyrit==0.11.0に固定しており、このpyrit 0.11.0のRequires-Pythonは「>=3.10,<3.14」です。手元でPython 3.14のvenvにpipで入れると「No matching distribution found for pyrit==0.11.0」で失敗し、3.13では依存解決からimportまで通りました。uvは依存先のPython上限を無視するため3.14でも入りますが、サポート範囲の外になります。

python3.13 -m venv .venv
. .venv/bin/activate
pip install "azure-ai-evaluation[redteam]==1.18.10" azure-identity
az login

PyRIT単体の最新は2026年9月4日公開の1.1.0です。Foundry連携と同じ環境で最新のPyRITを使うことはできないので、単体で使う環境とは分けます。CHANGELOGには、pyrit 0.11.0が要求するpillow 12.1以上がpromptflow-devkit（pillow 11.3以下）と衝突するため、両方使うなら仮想環境を分けるよう書かれています。リポジトリもAzure/PyRITからmicrosoft/PyRITへ移っているので、古い手順書のURLは差し替えます。

RedTeamの作成とスキャンの実行

プロジェクトはエンドポイントURLか、サブスクリプションID・リソースグループ名・プロジェクト名の辞書で指定します。ターゲットには、文字列を受けて文字列を返すコールバック、OpenAI Chat Protocol形式のコールバック、Azure OpenAIのモデル設定、PyRITのPromptChatTargetを渡せます。自社のRAGやチャットボットを検査する場合は、アプリの入口を呼ぶコールバックを用意します。次のコードは組み込み例で、未定義のmy_chatbotを自社アプリのクライアントに置き換え、AZURE_AI_PROJECTにプロジェクトのエンドポイントを設定してから実行します。

import asyncio, os
from azure.identity import DefaultAzureCredential
from azure.ai.evaluation.red_team import RedTeam, RiskCategory, AttackStrategy, SupportedLanguages

def call_my_app(query: str) -> str:
    # 自社アプリの入口を呼んで応答テキストを返す
    return my_chatbot.answer(query)

red_team = RedTeam(
    azure_ai_project=os.environ["AZURE_AI_PROJECT"],  # https://<account>.services.ai.azure.com/api/projects/<project>
    credential=DefaultAzureCredential(),
    risk_categories=[RiskCategory.Violence, RiskCategory.HateUnfairness,
                     RiskCategory.Sexual, RiskCategory.SelfHarm],
    num_objectives=5,
    language=SupportedLanguages.Japanese,
)

result = asyncio.run(red_team.scan(
    target=call_my_app,
    scan_name="chatbot-v2-pre-release",
    attack_strategies=[AttackStrategy.EASY, AttackStrategy.MODERATE,
                       AttackStrategy.Compose([AttackStrategy.Base64, AttackStrategy.ROT13])],
    output_path="redteam-chatbot-v2.json",
))

言語はlanguageで切り替えます。手順ページの表はスペイン語・イタリア語・フランス語・日本語・ポルトガル語・簡体字中国語の6言語ですが、1.18.10のSupportedLanguagesにはドイツ語・英語・韓国語を加えた9言語が定義されています。既定は英語なので、日本語のチャットボットは明示しないと英語の攻撃だけで終わります。scan()の既定は並列5タスク・タイムアウト3600秒です。

独自の攻撃目標もcustom_attack_seed_promptsにJSONファイルで渡せます。採点できるリスクの種類はviolence・sexual・hate_unfairness・self_harmの4つに限られます。社内規程に固有の禁止事項（例：未発表の製品情報を答えない）は、この形式では採点できません。

必要な権限と対応リージョン：Japan Eastの対象外扱い

必要なロールはプロジェクトに対する「Foundry User」です。クラウド実行の手順によれば、Foundry User・Foundry Owner・Foundry Account Owner・Foundry Project Managerは旧Azure AI User・Azure AI Owner・Azure AI Account Owner・Azure AI Project Managerの改称で、ロールIDと権限は変わっていません。古い手順書のロール名が見当たらなくても、同じロールを割り当てれば足ります。

リージョンはドキュメントによって記載が違います。概念ページとclassic版のリージョン一覧はEast US 2・France Central・Sweden Central・Switzerland West・US North Centralの5地域です。一方、新Foundryのリージョン一覧はEast US 2とNorth Central USの2地域だけで、ローカル実行の対応地域はclassic版を見るよう注記しています。新しくプロジェクトを作るなら、両方の記載に入るEast US 2かNorth Central USを選ぶのが確実です。日本のデータ所在要件でJapan Eastに置いたプロジェクトでは実行できないので、検査用のプロジェクトを別に立て、送るデータを合成データに限るのが現実的です。

クラウドでFoundryエージェントを検査する手順（azure-ai-projects 2.x）

red team・タクソノミー・runの作成

クラウド版はOpenAI互換のevals APIの上に載っています。流れは、red team（評価の入れ物）を作り、禁止アクションのタクソノミーを生成して確認し、run（攻撃戦略と対象エージェントを指定）を作る、の3段です。azure-ai-projectsは2026年10月30日公開の2.10.0が最新です。

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import (AzureAIAgentTarget, AgentTaxonomyInput,
                                      EvaluationTaxonomy, RiskCategory)

endpoint = os.environ["AZURE_AI_PROJECT_ENDPOINT"]
agent_name = os.environ["AZURE_AI_AGENT_NAME"]

with DefaultAzureCredential() as cred, AIProjectClient(endpoint=endpoint, credential=cred) as project:
    client = project.get_openai_client()
    red_team = client.evals.create(
        name="agent-redteam",
        data_source_config={"type": "azure_ai_source", "scenario": "red_team"},
        testing_criteria=[
            {"type": "azure_ai_evaluator", "name": "Prohibited Actions",
             "evaluator_name": "builtin.prohibited_actions", "evaluator_version": "1"},
            {"type": "azure_ai_evaluator", "name": "Sensitive Data Leakage",
             "evaluator_name": "builtin.sensitive_data_leakage", "evaluator_version": "1"},
        ],
    )
    agent = project.agents.get(agent_name=agent_name)
    target = AzureAIAgentTarget(name=agent_name, version=agent.versions.latest.version)
    taxonomy = project.beta.evaluation_taxonomies.create(
        name=agent_name,
        taxonomy=EvaluationTaxonomy(   # docsの例の body= は2.10.0ではTypeError
            description="prohibited actions for agent-redteam",
            taxonomy_input=AgentTaxonomyInput(
                risk_categories=[RiskCategory.PROHIBITED_ACTIONS], target=target),
        ),
    )
    print(taxonomy.as_dict())
    if input("生成された禁止アクションを業務責任者が確認済みなら APPROVED と入力: ") != "APPROVED":
        raise RuntimeError("タクソノミーを確認・修正してから実行してください")

    run = client.evals.runs.create(
        eval_id=red_team.id,
        name="pre-release-run",
        data_source={
            "type": "azure_ai_red_team",
            "item_generation_params": {
                "type": "red_team_taxonomy",
                "attack_strategies": ["Flip", "Base64", "IndirectJailbreak"],
                "num_turns": 5,
                "source": {"type": "file_id", "id": taxonomy.id},
            },
            "target": target.as_dict(),
        },
    )

公式手順のPythonの例は、タクソノミー作成でbody=EvaluationTaxonomy(...)と書いています。azure-ai-projects 2.10.0のcreate()の引数名はtaxonomyで、body=のままだと「missing 1 required positional argument: ‘taxonomy’」のTypeErrorになりました（通信前に止まるので、資格情報なしで確かめられます）。runは非同期に処理されるので、client.evals.runs.retrieve()で状態がcompleted・failed・canceledのどれかになるまで待ってから、client.evals.runs.output_items.list()で結果を取り出します。コードを書かずに新ポータルのウィザードから実行することもできます（2025年11月のFoundryブログ）。

禁止アクションのタクソノミーに対する人手確認と承認

Prohibited actionsは、エージェントのツール一覧と説明から「絶対禁止」「人の承認が要る高リスク操作」「告知と確認が要る不可逆操作」の3区分でタクソノミーを自動生成し、それに沿って攻撃を作ります。生成されたタクソノミーは確認・編集・更新できる前提で設計されており、公式も既定の禁止アクションを残したうえで自社の方針に合わせるよう勧めています。自動生成のまま流すと「自社では禁止したい操作」が入っていないまま合格が出ます。そのため、業務側の責任者がタクソノミーを読み、自社の権限設計と照らしてから実行するのが前提です。

スコアカードの読み方と改善の回し方

ローカル版でoutput_pathを指定すると、JSONのスコアカードが出力されます。risk_category_summaryは全体とカテゴリ別のASR、attack_technique_summaryはベースライン・easy・moderate・difficult別のASR、joint_risk_attack_summaryはその掛け合わせです。1.18.0（2026年7月6日）以降は、Base64などで変換した攻撃の記録に、ターゲットが実際に受け取った変換後の文字列が残ります。それより前の版には、実際に送信した符号化済み文字列ではなく、復号された平文が記録される不具合があったため、古い記録から攻撃を再現する場合は注意が必要です。

読む順番は、ベースラインと戦略適用後のASRの差を先に見ます。

• ベースラインからASRが高い：モデルの安全性アラインメントか、システムメッセージの拒否ルールそのものが弱い。
• ベースラインは0%でeasyだけ上がる：Base64やUnicodeの変換を見抜けていない。入力側のフィルタと正規化を足す。
• moderate・difficultで上がる：成功した戦略と応答を確認する。既定グループはTenseとTense→Base64なので、複数ターンへの弱さはMultiTurnやCrescendoを実行した結果から判断する。

対策は、Azure AI Content Safetyのフィルタ強度をASRの高いカテゴリで引き上げ、安全システムメッセージのテンプレートで拒否ルールを明示し、エージェントにはFoundry Control Planeでガードレールを掛けます。そのうえで攻撃目標、カテゴリ、戦略、言語、評価基準をそろえて再スキャンし、ASRを比較します。scan_nameは実行の名前であり、同じ名前でも検査条件や生成される攻撃は固定されません。フィルタの具体的な設定値はAzure OpenAIのセキュリティ設計：社内審査で問われる遮断・認証・フィルタの設定、入出力を検査する層の設計はAIガードレールとは？入力・出力を検査する実装層の設計と選定基準にまとめています。

費用はAgent自体ではなく、裏で動くRisk and Safety Evaluationsの従量課金です。MicrosoftのFoundry料金ガイド（PDF）では、入力100万トークンあたり20ドル、出力100万トークンあたり60ドルです。評価料金は入力・出力のトークン数で決まるため、前章の240ペアという件数に加え、1ペア当たりのトークン数も見積もります。対象モデルの推論や利用するAzureリソースの料金は別途確認します。最新の単価は料金ページで確認してください。

導入前に確認したい制約と既知の不具合

AI Red Teaming Agentだけで検査を済ませないほうがよいケースがあります。次の条件に当てはまるなら、PyRIT単体や他のスキャナーを併用します。

• 関数ツール・ワークフロー・Foundry外で動くエージェント：エージェント専用カテゴリの対象外。
• 日本語でのエージェント検査：禁止アクションと機微データ漏えいは英語のみ。タスク遵守の日本語対応は別途確認が必要。
• 社内固有の禁止事項：独自の攻撃目標を渡せても、採点できるのは暴力・性的・ヘイト・自傷の4種類だけ。
• 画像・音声を受け付けるアプリ：テキストの場面しか扱えない。
• 実データでの漏えい検査：機微データ漏えいの検査は合成データとモックツールで行い、メモリや学習データ由来の漏えいは対象外。

SDK側の不具合にも、結果の信頼性に直結するものがありました。azure-ai-evaluationのCHANGELOGによると、1.16.6（2026年4月27日）より前は、機微データ漏えいの攻撃で文書がエージェントに渡らず、全件が合格扱いになる（偽の合格率100%）不具合がありました。同じ版では、MultiTurnなど複数ターンの攻撃がPyRIT 0.11で何も出さずに失敗する問題も直っています。1.16.2では変換系の戦略で利用者のコールバックが攻撃役として使われる不具合が修正されました。2026年前半の版で取ったスコアカードを合否判断に使っているなら、1.18.10で取り直す価値があります。

手作業で作った攻撃シナリオや、関数ツール経由の攻撃まで含めて検査したい場合は、PyRIT単体のほうが柔軟です。Azureに依存しない形でCIに組み込むならpromptfooとは？YAML設定・使い方・CI組み込みとレッドチーミングを実装視点で解説、既知の脆弱性プローブを広く当てるならgarakとは？NVIDIAのLLM脆弱性スキャナーの使い方と結果の読み方が候補です。検証対象の大半がFoundry上のモデルとプロンプトエージェントなら、採点基盤とポータルが揃っているAI Red Teaming Agentを主軸にし、足りない部分だけ他のツールで補う構成が運用の手間を抑えられます。生成AIアプリのリスク評価から防御の実装までを外部に相談したい場合は、AIセキュリティ対策の支援サービスも用意しています。

CI/CDと4フェーズでの継続的な自動レッドチーミング

公式は、設計（安全な基盤モデルの選定）、開発（モデル更新やファインチューニングごとの確認）、デプロイ前（本番投入前の検査）、デプロイ後（合成データでの定期的なレッドチーミング）の4段階で使うよう勧めています。「継続的自動レッドチーム」は、このうちデプロイ前のゲートとデプロイ後の定期実行を自動化する運用です。

CIに入れる場合は、テストステージでスキャンを走らせ、全体ASRやカテゴリ別ASRがしきい値を超えたらジョブを失敗させます。ローカル版のRedTeamにあるattack_success_thresholds引数は、個々の応答の評価スコアから攻撃成功を判定するためのもので、ASRの合否基準ではありません。CIの合否判定は、集計されたASRと別途定めた許容値を比較して実装します。認証は対話型のaz loginではなく、マネージドIDかワークロードIDフェデレーションに切り替えます。毎回の全件スキャンは費用がかさむので、プルリクエストではベースラインとEASYを少数件、リリース前とデプロイ後の定期実行で全カテゴリと全戦略を回す、と分けるのが現実的です。基盤モデルの版、システムメッセージ、Content Safetyの設定、エージェントのツール構成のどれかが変わったら再スキャンする、とルールに書いておきます。

MITRE ATLASの読み方とOWASP LLM Top 10 2026への対応づけ

MITRE ATLASは「マイター・アトラス」と読みます。正式名はAdversarial Threat Landscape for Artificial-Intelligence Systemsで、サイバー攻撃の戦術と技術を整理したMITRE ATT&CKを、AIシステムへの攻撃向けに広げた知識ベースです。2026年10月28日公開のv2026.10は16戦術・129技術・92サブ技術・77件の事例を収録しています。表の読み方はATT&CKと同じで、列が戦術（攻撃者の目的）、各列のセルが技術（目的を果たす具体的な手段）です。偵察・初期アクセス・実行・持ち出し・影響といったATT&CK由来の戦術に加え、AI Model Access（モデルへのアクセス獲得）とAI Attack Adaptation（汎用の攻撃手法を標的向けに作り変える段階）がATLAS独自の戦術です。

スキャン結果を社内のリスク台帳に載せるときは、使った戦略とカテゴリをATLASの技術IDとOWASPの項目に対応づけておくと、検査の抜けが見えます。OWASP Top 10 for LLM Applicationsは2026年版が2026年8月に公開され、LLM03がExcessive Agency、LLM08がHidden Context Exposureになるなど2025年版から順番と名前が変わっています。

AML.T0086はExfiltration via AI Agent Tool Invocation（エージェントのツール呼び出し経由の持ち出し）です。逆に、サプライチェーン（LLM04）、データ・モデルの汚染（LLM05）、無制限の消費（LLM06）、ベクトルと埋め込みの弱点（LLM09）に当たる検査はAI Red Teaming Agentにありません。これらは依存関係の監査や負荷試験、RAGの検索基盤の設計レビューなど別の手段で埋めます。

よくある質問

AI Red Teaming Agentの利用に料金はかかりますか？

Agent自体の料金はなく、採点に使うRisk and Safety Evaluationsの従量課金です。Microsoftの料金ガイドに掲載された評価単価は、入力100万トークンあたり20ドル、出力100万トークンあたり60ドルです。利用時には現行の料金表も確認してください。料金は評価に使う入力・出力トークン数で決まります。各カテゴリの目標数が同じ単一ターンの検査では、カテゴリ数×攻撃目標数×（1＋展開後の戦略数）を件数の目安とし、トークン量と対象モデルなどの料金も別途見積もります。

日本語のチャットボットを日本語の攻撃で検査できますか？

モデルと7カテゴリのスキャンなら、language=SupportedLanguages.Japaneseを指定すれば日本語で検査できます。既定は英語なので、指定しないと英語の攻撃だけで終わります。エージェント専用カテゴリのうち、禁止アクションと機微データ漏えいは英語のみです。タスク遵守の日本語対応は別途確認してください。

Python 3.14で azure-ai-evaluation[redteam] が入らないのはなぜですか？

1.18.10の[redteam]はpyrit 0.11.0に固定されていて、そのpyritがPython 3.14未満しか対応していないためです。Python 3.10〜3.13の仮想環境を作って入れ直してください。

MITRE ATLASの読み方は？

「マイター・アトラス」と読みます。表は列が戦術、セルが技術で、左の列ほど攻撃の初期段階です。2026年10月公開のv2026.10は16戦術・129技術を収録しています。

PyRIT単体と何が違いますか？

AI Red Teaming AgentはPyRITの攻撃戦略に、Microsoftが用意した攻撃目標、Risk and Safety Evaluatorsによる自動採点、Foundryへの記録とポータル表示を足したものです。PyRIT単体はFoundryに依存せず最新版（1.1.0）を使えて、採点やシナリオを自由に組めます。その代わり、付属のデータセットやスコアラーも利用しながら、攻撃目標と採点方法を選び、接続先や実行条件を自分で構成する必要があります。

関連記事

• AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定【2026年時点】
• GoogleのAIレッドチームとは？6つの攻撃TTPとSAIF・交戦規程に見る演習の実際
• Microsoft Foundryとは？できること・料金の仕組み・始め方【2026年10月】
• garakとは？NVIDIAのLLM脆弱性スキャナーの使い方と結果の読み方【v0.17.0】
• promptfooとは？YAML設定・使い方・CI組み込みとレッドチーミングを実装視点で解説【2026年版】