--- title: "TAXIIとは？TAXII 2.1の仕組みとSTIX連携・実装判断【2026年時点】" url: "https://www.issoh.co.jp/tech/details/5145/" published: 2025-02-03 updated: 2026-07-27 categories: ["セキュリティ"] publisher: "株式会社一創" --- # TAXIIとは？TAXII 2.1の仕組みとSTIX連携・実装判断【2026年時点】 TAXII（タクシー）は、STIXで記述したサイバー脅威情報を組織間でやり取りするためのHTTPSベースのプロトコルです。脅威情報の「書き方」を決めるSTIXに対して、TAXIIは「運び方」だけを決めます。最新版はOASIS標準のTAXII 2.1で、実装前に押さえておくべき点がひとつあります。多くの日本語解説が並べる「プル型とプッシュ型」のうち、2.1で実際に動くのはプル型だけです。この記事では、TAXII 2.1のエンドポイント構成、1.xとの非互換、Microsoft Sentinelなどへの接続要件、そして自前でTAXIIサーバーを立てるべきかの判断基準を一次情報で整理します。 ## まとめ：TAXIIの要点 - TAXIIはSTIXコンテンツを運ぶアプリケーション層プロトコル。データ構造そのものはSTIX側の規格で、TAXIIは転送インターフェースだけを定義する。 - 最新はTAXII 2.1（OASIS標準として2021年6月10日承認）。2026年7月時点でOASISの標準一覧にTAXII 2.2は存在しない。 - 2.1で動作するのはコレクションからのプル（ポーリング）のみ。Channelsによるプッシュ配信はキーワードが予約されただけで、サービス仕様が未定義。 - 1.xと2.xは正式名称からメッセージ形式まで異なり、仕様上の互換性がない。1.xは「Indicator Information」、2.xは「Intelligence Information」。 - 接続に必要な最小情報はAPIルートURLとコレクションID。導入はTIP／SIEM側の既存コネクタに寄せるのが現実的で、OASIS参照実装は本番利用を想定していないと明記されている。 以下、エンドポイント構成から順に一次情報で確認します。 ## TAXIIとは何か：STIXを運ぶための交換プロトコル TAXIIは、脅威インテリジェンスを保有する組織がサーバーを立て、受け取る側がクライアントとしてHTTPSで取得する形の交換手順です。IPAは日本語名として「検知指標情報自動交換手順」を用いています。仕様が扱うのはURLの構造、リクエストパラメータ、レスポンスのラッパー、認証と暗号化の要件であり、脅威情報の中身の表現には踏み込みません。 ### 版で変わる正式名称と読み方 同じ「TAXII」でも、頭字語の展開が版で違います。IPAが解説するTAXII 1.1は「Trusted Automated eXchange of **Indicator** Information」で、指標（Indicator）の交換を名前に掲げていました。OASIS標準のTAXII 2.1では「Trusted Automated Exchange of **Intelligence** Information」に変わり、扱う対象が指標からインテリジェンス全般へ広がったことが名称に表れています。古い資料の名称をそのまま引用すると版のズレが生じるため、2.x前提の文書では後者を使います。 読みは日本語の解説では「タクシー」が使われますが、仕様書に発音の規定はありません。 ### STIXとの役割分担 STIXは脅威情報をJSONオブジェクトとして表現する形式、TAXIIはそのオブジェクトを転送するプロトコルです。TAXII 2.1はSTIX 2.1を前提に設計され、OASISの解説ではSTIX 2.1コンテンツの交換対応が実装必須と説明されています。仕様本文は他のコンテンツ形式の運搬を禁じてはいませんが、要件はSTIXを前提に書かれています。 調べたい対象がオブジェクトの種類やプロパティ設計なら、参照すべきはTAXIIではなくSTIX側です。データモデルの詳細は[STIXとは？脅威インテリジェンス標準をSTIX 2.1・TAXII連携まで実装視点で解説【2026年時点】](/tech/details/5127/)で扱っています。STIXの前身にあたる観測記述形式については[CybOXとは？サイバー攻撃観測記述形式の基礎とSTIX統合後の現在地](/tech/details/5121/)を参照してください。 ## TAXII 2.1のサーバー構成とエンドポイント ### Discoveryからオブジェクト取得までの階層 TAXII 2.1のサーバーは、ディスカバリ→APIルート→コレクション→オブジェクトという入れ子で公開されます。仕様が固定しているのはディスカバリの`/taxii2/`だけで、APIルートのURL自体はサーバー側が決めます（仕様は`https://example.com/api1/`のような例を挙げています）。固定されているのはAPIルート配下の相対パス構成です。接続時にAPIルートURLの入力が必要になるのはこのためです。 | エンドポイント | パス | 役割 | | ---------------------- | ------------------------------------------------------------ | --------------------- | | Server Discovery | `/taxii2/` | サーバー情報と利用可能なAPIルートの一覧 | | API Root Information | `/{api-root}/` | 対応バージョン、最大コンテンツ長 | | Get Collections | `/{api-root}/collections/` | コレクション一覧（IDと読み書き可否） | | Get a Collection | `/{api-root}/collections/{id}/` | 単一コレクションのメタ情報 | | Get Object Manifests | `/{api-root}/collections/{id}/manifest/` | 本体を落とさずに存在確認・更新確認 | | Get / Add Objects | `/{api-root}/collections/{id}/objects/` | GETで取得、POSTで投入 | | Get / Delete an Object | `/{api-root}/collections/{id}/objects/{object-id}/` | 個別オブジェクトの取得と削除 | | Get Object Versions | `/{api-root}/collections/{id}/objects/{object-id}/versions/` | 同一IDの版一覧 | | Get Status | `/{api-root}/status/{status-id}/` | POST投入の非同期処理結果 | プロバイダがディスカバリURLだけを公開しているケースもあります。その場合はディスカバリを叩いてAPIルートを取得してから接続します。 ``` curl -H "Accept: application/taxii+json;version=2.1" \ -u "$TAXII_USER:$TAXII_PASS" \ https://example.com/taxii2/ ``` ### 取得範囲を絞るパラメータ オブジェクト取得は`limit`（1回の最大件数）、`next`（サーバーが返す継続トークン）、`added_after`（この時刻以降に追加されたものだけ）、そして`match[id]`・`match[type]`・`match[version]`・`match[spec_version]`で絞り込みます。`match`のカンマ区切りはOR条件です。応答のエンベロープに`more`がtrueで返れば続きがあり、`next`を付けて再取得します。 差分同期の軸になるのは`added_after`です。これを使わない実装は毎回コレクション全件を引くことになり、ポーリング間隔を詰めるほどサーバー側のレート制限に当たりやすくなります。前回取得時刻を保存して差分だけを引く形にしてください。本体が不要な更新確認だけならマニフェストで済みます。 ### HTTPS必須と認証方式の混在（Basic認証はSHOULD止まり） 通信はHTTPS（HTTP over TLS）が必須です。証明書検証の要件は非対称で、クライアントはサーバー証明書を検証しなければならない一方、クライアント証明書の検証はサーバー側の任意機能に位置づけられています。相互TLS前提で設計すると、対応しないサーバーに接続できません。 TAXII応答のメディアタイプは`application/taxii+json;version=2.1`です。STIXの`application/stix+json;version=2.1`は応答ヘッダに現れる値ではなく、コレクションリソースの`media_types`プロパティで「このコレクションが扱えるオブジェクト形式」として宣言されます。 認証はHTTP Basic認証が推奨（suggested）とされ、サーバー側の実装はSHOULD止まりです。全サーバーが同じ認証方式で繋がる保証はなく、実際にはBasic認証とAPIキーが混在します。複数プロバイダから購読する構成では、認証方式ごとの設定項目を先に洗い出しておくと接続作業が短くなります。 ## Channels未定義によるプッシュ配信不可という実態 TAXII 2.1仕様は、Channelsについて「このバージョンはChannelsに必要なキーワードを予約するが、Channelサービスは規定しない。Channelsとそのサービスは後続バージョンで定義する」と明記しています。publish-subscribeモデルの概念定義は存在するものの、実装できる形の仕様がないという状態です。 したがって、2.1準拠サーバーに対して購読側ができるのはコレクションのポーリングだけです。「TAXIIにはプル型とプッシュ型の2方式がある」と書く解説も残っていますが、これはInbox Serviceでプッシュ配信を持っていた1.x時代の説明で、2.1で実装できる機能とは一致しません。 設計上の帰結はひとつです。TAXIIで配信の即時性は作れません。反映の速さはポーリング間隔で決まり、間隔を詰めればサーバー側の負荷とレート制限に当たります。秒単位で伝播させたい要件があるなら、TAXIIの外側にWebhookやメッセージキューを置く前提で設計してください。TAXIIに期待する役割は「標準化された定期取り込み」に限定して設計します。 ## TAXII 1.xと2.xの非互換 1.xと2.xは同じ名前を共有しているだけで、実装としては別のプロトコルです。1.0が2013年4月、1.1のサービス仕様が2014年1月13日公開で、2.1は2021年6月10日承認と7年以上の隔たりがあります。 | 項目 | TAXII 1.x | TAXII 2.1 | | ------- | --------------------------------------------------- | ------------------------------------------------------ | | 正式名称 | Trusted Automated eXchange of Indicator Information | Trusted Automated Exchange of Intelligence Information | | メッセージ形式 | XMLメッセージバインディング | JSON over HTTPS（REST） | | 共有方式 | Poll（プル）＋Inbox（プッシュ） | コレクション（プル）のみ | | 交換形態 | ハブ＆スポーク、ピアツーピア等を明示 | APIルートとコレクションの構成で表現 | | 運搬対象 | STIX 1.x | STIX 2.1 | 2.0から2.1への変更も接続に効きます。ディスカバリURLが`/taxii/`から`/taxii2/`へ、DNS SRVレコードの名前も`taxii`から`taxii2`へ変わり、メディアタイプも書き換えられました。件数ベースのページング（Rangeヘッダ方式）は2.1で削除され、`limit`と`next`に置き換わっています。2.0と2.1のサーバーが混在する環境では、クライアント側でディスカバリのパスとページング方式を版ごとに分岐させる必要があります。新規に組むなら2.1で揃えてください。 ## TIP／SIEMへの接続：Microsoft Sentinelの場合 ### 用途で分かれる2つのコネクタ 購読側の実装は、TIPやSIEMのコネクタを使うのが最短です。Microsoft Sentinelは用途別に2つのコネクタを持ちます。「脅威インテリジェンス – TAXII」データコネクタはTAXII 2.0または2.1サーバーからインジケーターを取り込み、「脅威インテリジェンス – TAXII Export」コネクタはTAXII 2.1プラットフォームへ書き出します（認証は基本認証かAPIキー）。 ### 設定に必要な値 入力するのは、フレンドリ名、APIルートURL、コレクションID、必要な場合のユーザー名とパスワード、取り込むインジケーターの種別、そしてポーリング頻度です。ここでも即時配信ではなくポーリングであることが設定項目に表れています。 ### 運用で先に潰しておく3点 ひとつはIP許可リストです。FS-ISACのような一部のTAXIIサーバーはSentinelのTAXIIクライアント側IPアドレスの登録を求めます（大半のサーバーでは不要）。エクスポート側にも別のIP群が案内されているため、双方向で使うなら両方を申請します。 次にコネクタの変更手順です。既存のTAXIIエクスポートコネクタは編集がサポートされておらず、サーバーやルールの構成を変えるには再インストールが必要になります。設定値は初回に確定させてください。 最後に提供基盤の移行です。2027年3月31日以降、Microsoft SentinelはAzureポータルでは提供されずMicrosoft Defenderポータルのみとなります（Microsoft Learn、2026年6月15日更新）。これから構築するならDefenderポータル前提で手順書を作るほうが手戻りがありません。 取り込み後の相関や運用体制については、[Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合を実装者目線で解説](/tech/details/15647/)で解説しています。監視体制の内製とアウトソースの判断は[SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】](/tech/details/13310/)を参照してください。 ## 自前実装を避ける判断とTAXII採用の基準 ### 参照実装の更新停止と本番不採用の判断 TAXIIサーバーの自社構築は、OASISの参照実装を使う限り勧められません。TAXII 2.1サーバー実装のmedallionは、PyPIの説明文に「medallion was designed as a prototype and reference implementation of TAXII 2.1, and is not intended for production use（本番利用を想定していない）」と明記されています。 更新も止まっています。medallionのPyPI最新は3.0.0で2020年7月7日公開、クライアントライブラリのtaxii2-clientは2.3.0で2021年3月12日公開です。前者は6年、後者は5年以上リリースが動いていません（GitHubリポジトリはいずれもアーカイブされておらず、最終pushは2024年4月15日）。配信側に立つ必要があるなら、参照実装ではなく商用TIPやクラウドサービスのTAXIIエクスポート機能を使う判断になります。 接続先として公開サーバーを探す場合、MITRE ATT&CKはTAXII 2.1サーバーの実装（attack-workbench-taxii-server）を公開しています。接続先URLとレート制限は提供元のリポジトリ案内で確認してください。 ### TAXIIを採用しない3条件 - **取り込み先のTIP／SIEMが決まっていない**：受け取ったSTIXオブジェクトを検知ロジックや相関に流す先がないと、JSONがストレージに溜まるだけで終わります。先に整えるのは受け皿側です。 - **共有相手が数社かつ更新が月次程度**：TLS証明書の管理、認証情報の配布、可用性の確保というサーバー運用コストに対して、得られる自動化の効果が釣り合いません。この規模ならファイル受け渡しのほうが総コストで勝ちます。 - **秒単位の伝播が要件**：前述のとおり2.1はポーリング前提です。要件を満たせません。 実務で最も多いのは1つ目です。逆に、購読（消費）側だけで足りる組織にとってTAXIIは扱いやすい標準です。自社サーバーは不要で、プロバイダのAPIルートとコレクションIDをコネクタに登録すれば取り込みが始まります。攻撃手口そのものの分類と対策は[サイバー攻撃の手口と対策とは？侵入経路の分類と実装者向けの防御策を解説【2026年時点】](/tech/details/13363/)で扱っています。 ## よくある質問 ### TAXIIは何と読みますか？ 日本語の解説では英語のtaxiと同じ「タクシー」が使われます。仕様書に発音の規定はありません。日本語の正式名称はIPAの表記で「検知指標情報自動交換手順」です。なお頭字語の展開は版で違い、1.xは「Trusted Automated eXchange of Indicator Information」、2.xは「Trusted Automated Exchange of Intelligence Information」です。古い資料を引用するときは版を確認してください。 ### TAXIIサーバとは何ですか？ 脅威情報のコレクションを公開し、クライアントからのHTTPSリクエストに応答するサーバーです。APIルートという単位でコレクション群をまとめ、`/taxii2/`のディスカバリエンドポイントで自身の構成を通知します。1台のサーバーに複数のAPIルートを置けるため、購読側が受け取るべき情報はサーバーのホスト名ではなくAPIルートURLとコレクションIDです。オブジェクトの投入を受け付けるかどうかはコレクション単位の設定で決まります。 ### STIXとはどのような形式ですか？ 脅威情報をJSONオブジェクトとして表現するデータ形式で、攻撃者・マルウェア・指標などをオブジェクトと関係性で記述します。TAXIIが運ぶ中身がSTIXです。オブジェクト種別やプロパティは[STIXとは？脅威インテリジェンス標準をSTIX 2.1・TAXII連携まで実装視点で解説【2026年時点】](/tech/details/5127/)で解説しています。 ### TAXII 2.1と2.0のどちらで実装すべきですか？ 新規実装は2.1です。2.0はディスカバリURLが`/taxii/`、ページングがRangeヘッダ方式で、2.1とはクライアント側の分岐が必要になります。既存プロバイダが2.0のみ対応の場合はコネクタ側（Sentinelは2.0／2.1両対応）で吸収し、自社が配信側になる部分は2.1で揃えるのが手戻りの少ない構成です。2026年7月時点でOASISの標準一覧にTAXII 2.2はなく、2.1が最新版です。 ### 脅威インテリジェンスの購読にTAXIIサーバーの自社構築は必要ですか？ 不要です。購読だけならクライアント側の設定で完結し、必要な情報はAPIルートURLとコレクションID、認証情報です。自社サーバーが必要になるのは、自組織が生成した脅威情報を外部へ配信する場合に限られます。その場合もOASIS参照実装は本番利用を想定していないため、商用TIPやSIEMのエクスポート機能を使う構成が現実的です。 ## 関連記事 - [STIXとは？脅威インテリジェンス標準をSTIX 2.1・TAXII連携まで実装視点で解説【2026年時点】](/tech/details/5127/) - [Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合を実装者目線で解説](/tech/details/15647/) - [SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】](/tech/details/13310/) - [CybOXとは？サイバー攻撃観測記述形式の基礎とSTIX統合後の現在地](/tech/details/5121/) - [サイバー攻撃の手口と対策とは？侵入経路の分類と実装者向けの防御策を解説【2026年時点】](/tech/details/13363/) --- 出典: [TAXIIとは？TAXII 2.1の仕組みとSTIX連携・実装判断【2026年時点】]()（株式会社一創）