1章. Tanium Client の構成 — 本体と Client Extensions
Tanium Client は単一のインストーラで導入できますが、エンドポイント上で動作する Tanium 関連のソフトウェアは本体バイナリだけではありません。本体に Client Extension が組み合わさり、各ソリューションの機能が提供される構造になっています。本章では Tanium Client の構成要素、インストール後のツール配布の流れ、エンドポイント上のプロセス構造、Shared Process Mode について解説します。
Tanium Client の構成と配布の流れ 構成要素
Tanium Client を構成する要素は次のとおりです。
Tanium Client（本体バイナリ） : 通信、ピアリング、Sensor 実行、Action 実行といった基本機能を担う本体。インストーラで配布されるのはこの部分ですCore CX（core-cx） : 他のすべての Client Extension (CX) に対する管理フレームワークを提供する Client Extension。各ソリューションの CX はこの core-cx を介して機能しますEndpoint Configuration Tool（cx-config） : Client Extension や Endpoint Tool のインストール・設定・更新を担う Client Extension。ソリューション固有のツールはこの cx-config を経由してエンドポイントへ配布されますソリューション固有 Client Extension : 各 Tanium ソリューションの機能を提供する CX。例: comply-cx（Comply）、dec-cx（Direct Connect）、enforce-cx（Enforce）、performance-cx（Performance）、integrity-monitor-cx（Integrity Monitor）などEndpoint Tools : CX とは別系統の補助ツール群（Nmap、Driver 等）。やはり cx-config 経由で配布されます
Tanium Client 本体は通信・ピアリング・Sensor 実行・Action 実行といったコア機能を担当し、機能の追加配布は Core CX と Endpoint Configuration Tool（cx-config）が担当する、という役割分担になっています。
Client Extensions（CX） は、Tanium Client の機能を拡張するツールとプロセスの拡張可能なフレームワークです。複数のモジュール・ソリューション間でのコード重複を最小化することを目的としており、必要に応じて各 Tanium ソリューションで再利用されます。
Tanium Client のインストールとツール配布
Tanium Client は単一のインストーラで提供されます。インストール直後の状態では、コア機能（Tanium Client 本体）だけが動作している状態です。
Tanium Client 本体は Tanium Server と通信して登録（Registration）を済ませると、まず Core CX（core-cx） と Endpoint Configuration Tool（cx-config） が Tanium Server から配布されます。これらが揃った段階で、各ソリューションが必要とする Client Extensions（CX） や Endpoint Tools が cx-config 経由で自動的に配布・有効化されていきます。
また、新しいソリューションを利用したいときは、機能を有効化すれば cx-config が対応するツールを自動でエンドポイントへ配布し、CX が起動します。Tanium Client 本体・Core CX・cx-config を差し替える必要はありません。
Tanium が提供している Client Extension と Endpoint Tool の一覧、およびそれぞれがどのソリューションで使われるかの対応関係は、Tanium Client Management User Guide: Reference - Client Extensions and endpoint tools used for Tanium solutions で確認できます。実際にエンドポイントへ配布される範囲は、組織が契約している Tanium ソリューションのライセンスや各ソリューションの Action Group によって決まります。
Tanium Client のプロセス構造
エンドポイント上で実際に動く Tanium 関連のプロセスは、おおまかに次の3種類に分かれます。
Tanium Client 本体プロセス (TaniumClient.exe): 通信、ピアリング、Sensor 実行、Action 実行などコア機能を担うプロセス。独立した1つのプロセスとして常に動作しますClient Extension プロセス（TaniumCX.exe / TaniumCX） : Client Extension を動かすためのプロセス。後述の Shared Process Mode の設定によって、1つに統合するか Extension ごとに分けるかが変わりますEndpoint Tool プロセス : Nmap や Driver など、CX とは別系統の補助ツールが動作するプロセス。それぞれ独立して動きます
Shared Process Mode — Client Extension プロセスの統合設定
Shared Process Mode は、上記のうち Client Extension プロセスの動かし方を制御する設定です。有効にすると、複数の Client Extension が単一の TaniumCX.exe（Windows）/ TaniumCX（非 Windows）プロセス内にまとめて動作するようになります。エンドポイント上で動作する Tanium 関連プロセスの数とメモリ消費を抑える効果があります。
Shared Process Mode が有効な状態でのプロセスの見え方 無効化すると、Client Extension それぞれが独立した TaniumCX.exe / TaniumCX プロセスとして動作します。特定の Extension の CPU・メモリ使用量を切り分けてトラブルシュートしたい場合に有効です。
Tanium Client 本体プロセスと Endpoint Tool プロセスは、Shared Process Mode の設定に関わらず常に独立して動作します。Shared Process Mode の有効・無効は Interact の Action で切り替えられます。
2章. Registration と Computer ID
Tanium Client インストール後、端末は Tanium Server に接続して Registration を行い、Computer ID が割り当てられます。本章では Registration の2種類（Initial / Normal）の動作と、Computer ID の管理について解説します。
Registration と Computer ID — 生成・登録・通常登録のタイミング 初回接続
Tanium Client がインストールされた端末は、起動時に Tanium Server への初回接続を行います。これはインストール後に1回だけ発生する、Server との最初のセッション確立手続きです。接続先 Tanium Server の FQDN リストは、Client 設定の ServerNameList に保持されています。インストール時には、インストールパッケージに同梱される tanium-init.dat から ServerNameList、ServerPort、LogLevel、その他 Client Deployment Template で設定された Client 設定とタグが Client へ読み込まれます。Client は ServerNameList から FQDN を選択して Server に接続します。tanium-init.dat が無い、もしくは内容が不正な場合、Client は Server に接続できません。
Initial Registration
Initial Registration は、Client が Tanium Server から包括的な情報を受け取る Registration の種類です。初回接続時にも実行され、その後も 2〜6時間ごとのランダム間隔でリセットされて再実行されます。
Initial Registration では Tanium Client が Tanium Server から次の4点を受け取ります。
最新の Tanium Client 設定
近隣ピアのリスト（Peer List）
Sensor 定義
現在出ている Question と Scheduled Action の一覧
定期的に Initial Registration を実行する理由は、Tanium Client 設定を最新化することと、その時点のネットワーク状況に合わせて最適なピアを選び直すことにあります。
Normal Registration
Tanium Client は Initial Registration とは別に、Normal Registration を数分ごとのランダム間隔で行います。Tanium Client は現状（Question・Action・設定の状態）を Tanium Server に報告し、Tanium Server は新しい Question・Action・設定を返します。
Question・Action・設定はリニアチェーン経由でも Tanium Client に伝播しますが、端末数の多い大規模環境では、Normal Registration が新しい Question・Action・設定を受け取る主経路となります。
Computer ID の付与
Initial Registration 時に、Tanium Client は Computer ID を生成し、Registration のなかで Tanium Server に ComputerID と RegistrationCount（Client が完了した Registration 回数のカウンタ）を提示します。Tanium Server も同じ Client の RegistrationCount を自身で保持しており、Client が報告した値と突き合わせて重複を検出します。一致していれば重複なしと判定してそのまま利用を許可します。重複していた場合、Tanium Server は Client に Computer ID の再生成を指示し、Client は新しい一意の Computer ID を生成して再度 Registration を行います。
Computer ID は Tanium Server 上で各端末を一意に識別するための内部キーで、ホスト名・IP アドレス・MAC アドレス・OS GUID といった他の識別子が変わっても、この Computer ID で同じ端末を追跡し続けることができます。
OS イメージから端末を量産すると、イメージに含まれる ComputerID 設定がそのまま複製され、Computer ID が重複した状態で配備されることがあります。Tanium Server は Registration 時に重複を検出して再採番しますが、重複検出処理自体の発生を抑えるために、OS イメージ準備時に Tanium Client の ComputerID 設定を事前に削除しておくことが推奨されます。これにより、配備後の各端末が新規に Computer ID を生成して Registration するようにします。
Computer ID が変更される条件
Computer ID は端末ごとに固定されているように見えますが、実際には次のような条件で再採番されます。
Tanium Client から ComputerID 設定が削除された場合（再インストール時等）
Tanium Server が Registration 時に重複を検知した場合（別端末との ComputerID 重複、バックアップからのリストア、VDI でのリセット等）
Computer ID が変更された場合の影響
Computer ID が再採番されると、運用上の主な影響は次の通りです。
ライセンスカウントが実態より多く見える : Tanium Server は Computer ID を用いて一意な Tanium Client を識別して、ライセンス対象台数として計上します。一度登録された Computer ID は、最後の Registration から 30 日間ライセンス対象台数として残り続けます。Computer ID が再採番されると新しい Tanium Client として扱われるため、実際の物理台数（VDI 環境では VDI インスタンス数）よりライセンス消費が多く見えることがあります外部システム連携で識別が分断される : 外部システムに Tanium の情報を連携しており Computer ID をキーとして突合している場合、再採番後は別端末として扱われ、それまでの履歴と紐付かなくなります
キッティング工程に Tanium Client の ComputerID 設定の削除を組み込むことで、配備後の意図しない再採番を抑制できます。
3章. リニアチェーンの形成と再形成
リニアチェーン （Linear chain）は、各 Tanium Client が Tanium Server と直接通信するのではなく、Tanium Client 同士で通信を中継し合う構造です。Tanium が大規模環境でエンドポイント管理を行う際の主要な仕組みであり、本章ではその形成条件・形成タイミング・再形成・サブネット境界の制御について解説します。
リニアチェーン基本概念（Backward Leader / Forward Leader / 中継ピア） ピア検出
Tanium Client は他の Client と長期間維持されるピア接続を確立します。リニアチェーン上の Tanium のメッセージやファイルは、この接続上を流れます。
Registration 時に Tanium Server から渡される Peer List を元に、各 Tanium Client がピア接続先を選定します。Peer List は Tanium Server が管理する情報であり、Tanium Client が独自にネットワーク探索（ブロードキャストやスキャン）を行うわけではありません。
リニアチェーンを組む基本条件
同じリニアチェーンに所属できる Tanium Client 同士は、デフォルトでは次の2つの条件を両方満たしている必要があります。
NAT IP アドレス（Tanium Server から見える送信元 IP アドレス）が同一であること :Local IP アドレス（端末に振られている IP アドレス）が同一サブネットであること :
NAT IP は Tanium Server 側でのグループ分けの基準として、Local IP はそのグループ内での順序付けに使われます。上記2つは基本条件であり、後述の Peering Settings で境界をチューニングすることができます。
リニアチェーンの構造
同一サブネット内の Tanium Client は、IP アドレスの昇順に1本のリニアチェーンを形成し、各 Tanium Client は前後のピアと接続します。チェーンの両端には2種類のリーダーが存在します。
Backward Leader : 最も低い IP アドレスの Tanium Client。チェーンの先頭Forward Leader : 最も高い IP アドレスの Tanium Client。チェーンの末尾
基本のリニアチェーン動作では、Registration 時を除けば Tanium Server と直接通信するのはこのリーダーだけです。チェーンの中間にいる Tanium Client は隣接ピアとだけ通信するため、WAN 帯域の消費を抑えられます。
Tanium Client 7.6 以降では、この前提に対する例外が追加されています。リニアチェーン上の Chunk 取得がタイムアウトした場合に Non-Leader Client が Tanium Server に直接 Chunk を要求する動作や、CDN Downloads により各 Tanium Client が個別に CDN へリクエストする動作などです（詳細は6章）。
リニアチェーンの形成タイミング
Initial Registration 直後、各 Tanium Client は受け取った Peer List を元に前後のピアを選定し、前述の境界条件（基本条件 + Peering Settings の補正）に従ってリニアチェーンを形成します。追加設定なしでも自動的に構成される動作で、運用者がチェーンを明示的に組む必要はありません。
リニアチェーンの再形成
リニアチェーンは静的に固定されたものではなく、動的に再構築されます。
端末追加 : 新しい Tanium Client が登録されると、Peer List が更新され、IP 順に応じた位置にチェーンへ挿入される端末離脱 : シャットダウンやスリープを隣接ピアが断として検知し、後続ピアと接続し直してチェーンを再構築する
Peering Settings — リニアチェーン境界のチューニング
Peering の境界はサブネット設定で柔軟にコントロールできます。ネットワーク構成や運用要件に応じて、4種類の設定を使い分けます。
たとえば Intentional Subnets を設定すると、異なる NAT IP の Tanium Client 同士でも同一サイトとしてピアリング可能になります。Separated Subnets を設定すると、Address Mask（/24）の内側でさらに細かい境界（/26 など）を定義できます。
ピア設定 - 4種類の境界制御 設定種別 用途 Default Peering /24 サブネット単位でチェーンを区切る既定動作 Separated Subnets デフォルトより細かい境界を引く（例: 同一 /24 の中で更に切り出す） Intentional Subnets 同一サイト内で複数の NAT IP（パブリック IP）が存在する環境で、異なる NAT IP の Tanium Client 同士を同一サイトとしてピアリング可能にする Isolated Subnets ピアリングを完全に無効化する。VPN クライアント・VDI などの高密度環境向け
4章. Sensor / Question / Answer / String
本章では Sensor / Question / Answer / String の役割と、エンドポイント側・Server 側の2層のキャッシュ機構を解説します。リニアチェーン上の Forward 方向への順送り伝播とこれらのキャッシュにより、数万台規模のエンドポイントから短時間で応答を集約できる動作モデルが成立します。
Question・Answer・String・Hash の関係性 Question がチェーン全体に伝播する流れ
Tanium Server から Tanium Client へ Question が届く経路は2系統あります。一つは Backward Leader からリニアチェーン上を順送りで伝播する経路、もう一つは各 Tanium Client が数分ごとに行う Normal Registration の応答として受け取る経路です。2章で述べたとおり、端末数の多い大規模環境では Normal Registration が主経路となります。本章では、リニアチェーン経由の伝播動作を解説します。
リニアチェーン経由では、Tanium Server が発行した Question はまず Backward Leader に渡されます。各 Tanium Client は受け取った Question を Forward 方向の隣のピアへ渡します。この時、 Question に含まれる Sensor を実行し、Answer も Forward 方向のピアへ渡します。Action と Action Status についても同様に Backward Leader から Forward Leader に向かってチェーン上を流れ、最終的に Forward Leader から Tanium Server に Answer と Action Status が返されます。
Tanium Client 7.6 以降では、Sensitive Data Flag を持つ Sensor の Direct Reporting が実装されており、Forward Leader を経由せず Tanium Client が Tanium Server へ直接結果を返す経路もあります（Release Notes 7.6.1.6334 ）。
Sensor の実行モデル
Sensor は OS の各種情報源（WMI、レジストリ、ファイルシステム、コマンド出力など）にアクセスして値を取得するスクリプトで、Question はこの Sensor を組み合わせて構成されます。
Sensor 定義（スクリプト本体を含む）は Registration 時に Tanium Server から各 Tanium Client へ配布されており、Question を受領した Tanium Client は手元に持っている Sensor 定義を実行して結果を Answer として生成します。Question 受信のタイミングでスクリプトが配布されるのではなく、事前配布済みの Sensor が即座に実行されるモデルです。Sensor 定義が変更された場合、Tanium Client は次の Registration 間隔の後に新しい定義を受け取り、それ以降の Question から更新後の定義で応答します。
Answer String とハッシュ化
Question に対する回答である Answer は、必ず String （文字列）の形で処理されます。数値であれ日時であれ、最終的には String に整形されます。
Tanium Client は Answer の String をハッシュ化して扱います。長い String を毎回そのまま送るのではなく、ハッシュ化することでネットワーク転送量を抑えるための仕組みです。ただし、String がハッシュ値より短い場合は、そのままの String が送られます。
String とハッシュのマッピング
Tanium Server は String とハッシュのマッピング情報を Tanium Client から別途受け取り、保持します。Question の集計や型解釈の際には、このマッピングを使ってハッシュから元の String へ解決します。
Sensor Result Cache と String Cache
同じ Sensor を同じ端末で連続実行するとエンドポイントの CPU を消費するため、Tanium はキャッシュ機構で再実行を抑制します。Tanium には置き場所も役割も異なる2つのキャッシュがあり、別々のパラメータで制御されます。
Sensor Result Cache と String Cache キャッシュ 場所 制御パラメータ 役割 Sensor Result Cache 各 Tanium Client（エンドポイント側） Max Sensor Age同じ Sensor を短時間で再実行しないことで、エンドポイントの CPU 負荷を抑制 String Cache Tanium Server 側 Max String Age / Max Strings同一 Answer の String を保管・再利用する。後続の Question で同じ String が必要になったとき、キャッシュから引き出すだけで済み、Tanium Client へ Question を再発行して同じ String を作り直す必要がなくなる
Max Sensor Age — Tanium Client 側キャッシュ
Max Sensor Age は Sensor 単位の設定で、キャッシュ済みの Answer を再利用してよい時間を指定します。Tanium Client は Question を受け取ったとき、Max Sensor Age 内であればキャッシュ値を返し、超過していれば Sensor を再実行して新しい Answer を生成します。
Max Sensor Age の値は Sensor の性質によって、5 分・15 分・1 時間など実態に合った値が設定されています。たとえば 15 分に設定された Sensor の場合、Client が一度 Sensor を実行して Answer を得ると、その後 15 分間は同じ Sensor を含む別の Question が届いても再実行されず、キャッシュ済みの Answer がそのまま返ります。15 分を超えてから要求があった時点で初めて Sensor が再実行され、Answer がキャッシュごと新しい値に置き換わります。
Question を短時間に何度発行しても、Max Sensor Age の範囲内では結果は変わりません。Sensor は再実行されず、Client は同じキャッシュ済み Answer を返し続けるため、画面を何度更新しても同じ値が表示されます。
Max Sensor Age を短く設定すると Answer の鮮度が上がる代わりにエンドポイント CPU 負荷が増し、長く設定すると CPU 負荷を抑えられる代わりに変更の反映が遅れる、というトレードオフがあります。
String Cache — Tanium Server 側キャッシュ
Tanium Server に集約された Answer String は、Tanium Server のメモリ上に String Cache として保管されます。Sensor 単位で Max String Age（保管期間）と Max Strings（保管件数の上限）の2つを制御できます。
String Cache が果たす役割は、Tanium Server のメモリ管理だけではありません。同じ String が後続の Question で再び必要になったとき、Tanium Server はキャッシュから引き出すだけで済み、Tanium Client に対して Question を再発行して同じ String を作り直す必要がなくなります。Tanium Server のメモリ消費の抑制に加えて、Tanium Client 側の処理負荷とネットワーク上の再送信を減らすという、両面のメリットがある仕組みです。
Detect Primary Alerts のようなユニークな String が大量発生する Sensor では、Max String Age を短く設定することで Tanium Server のメモリ肥大化を抑えられます。一方で短くしすぎるとキャッシュからの再利用が効かなくなり、Tanium Client への Question 再発行が増えるため、Sensor の性質と更新頻度に応じた設定が必要です。
Tanium が提供する Sensor には、Max Sensor Age などのデフォルト値が性質に応じて事前設定されています。公式は Max Sensor Age のデフォルト値を引き下げないことを強く推奨しています（Tanium Console User Guide ）。基本的には組み込み Sensor のデフォルト値をそのまま運用し、必要に応じて Question 側で maxAge= を指定する方針が安全です。
明示的に最新値を取りたい場合の対処
Sensor の値を変更したのに Question 結果に反映されない、と感じるケースの大半は、Max Sensor Age による Tanium Client 側キャッシュが効いている状態です。Question を何度発行しても Max Sensor Age の範囲内なら同じキャッシュ値が返るため、Sensor 自体の出力が変わっても結果は更新されません。
明示的に最新値を取得したいときは、Question 側で maxAge=60（60 秒で再評価を強制）のように短い Max Sensor Age を指定することで、Tanium Client に Sensor の再実行を要求できます。Sensor のロジックを変更した直後の検証や、特定の更新を確実に拾いたい場合に使用します。
Answer の集約
Question の種類によって集約の挙動とネットワーク負荷が異なります。Tanium では公式に次の2種類の Question が区別されています。
Question 種別 get 句の構成 集約の挙動 ネットワーク負荷 Counting Question （カウンティング）単一 Sensor（デフォルト） 同じ値を返した端末ごとに重複排除し、値とその端末数だけを返す 小さい Non-Counting Question （非カウンティング）複数 Sensor を指定、または ?forceComputerIdFlag=1 で Computer ID を付与 端末ごとに1行の結果を返す（重複排除なし） 大きい
10,000 台のエンドポイントから OS 種別を取得する場合の挙動を比較します。
Get Operating System from all machines（Counting）Get?forceComputerIdFlag=1 Operating System from all machines（Non-Counting）
Question の記述方法によって集約挙動が切り替わるため、求める結果の粒度（集約値か、端末ごとのインベントリか）に応じて Question を組むことで、リニアチェーンの転送量と Tanium Server の処理量に差が生じます。
5章. Action の指示伝達
Action（端末で実行する指令）の伝達経路、指示内容、対象判定の動作モデルを解説します。
Action の伝播と実行対象判定 Action の指示は Sensor と同じ経路
Action の配信は、Question と同じ経路をたどります。Tanium Server → Backward Leader → リニアチェーン伝播 → Forward Leader、という流れで、リニアチェーン上のすべての Tanium Client が Action 指示を受け取ります。
指示そのものは軽量
Action 指示に含まれるのは、おおまかに次のような情報です。
実行対象の Package を識別する情報（URL や ID）
実行スケジュール・対象判定などのメタデータ
ファイル本体は Action 指示には含まれず、Package のファイル配信は別経路で行われます（6章で詳述）。
Targeting Question による対象評価
Action 指示は対象を絞らずにリニアチェーン上のオンラインの全 Tanium Client に流れ、各 Tanium Client は Action 指示と一緒に受け取る Targeting Question （対象判定の条件式）を実行して自分自身で評価します。条件にマッチした端末だけが Action の実行に進み、マッチしない端末は何もしません。
この設計には次のような特性があります。
対象判定が分散実行される : 数万台の対象判定を Tanium Server がまとめて行うのではなく、各エンドポイントが自分の判定だけを行うため、Server 側に負荷が集中しない動的な対象判定ができる : Computer Group の条件は実行時に各端末で評価される。最新のホスト状態（OS バージョン、インストール済みソフト、特定のレジストリ値など）に基づいて対象判定が行われる
6章. Package ファイル配信
Action 指示そのものにはファイル本体は含まれません。Action が参照する Package にファイルが含まれる場合、ファイル配信は別の仕組みで行われます。Tanium のファイル配信はリニアチェーン経由のピア間配信をベースとし、Tanium Client 7.8 以降は CDN Downloads が追加経路として併用されます。CDN Downloads が利用できない場合は、リニアチェーン経由配信にシームレスにフォールバックします。
リニアチェーン経由のピア間配信
Package ファイル配信 - リニアチェーン経由（WAN転送・LAN内中継・チャンク分散キャッシュ） ピア間配信の仕組みは、WAN 帯域を節約するために設計されています。Tanium Server は Package ファイルをすべての端末に直接送るのではなく、各リニアチェーンの Backward Leader 1台だけに送信します。WAN 帯域を消費するのは Server → Backward Leader の1本だけ、ということです。
Backward Leader が受け取ったファイルは、その後 LAN の高速接続を使って隣の Forward Peer に渡され、さらに次の Forward Peer へと中継されていきます。最終的に Forward Leader まで届くと、リニアチェーン全体にファイルが行き渡ったことになります。WAN 経由のファイル転送は Tanium Server から Backward Leader への1回だけで、それ以降の中継はすべて LAN 内で完結します。
Chunk Caching（チャンクキャッシュ）
リニアチェーン経由のピア間配信では、リニアチェーン全体が分散キャッシュとして機能します。
Package ファイルは一括ではなく、小さなチャンク（Chunk）に分割して配信されます。各 Tanium Client は受け取ったチャンクをローカルにキャッシュします。Tanium Client が新しくチャンクを必要としたときは、Tanium Server にリクエストする前に、リニアチェーン上の他の Tanium Client に該当チャンクがキャッシュされていないかを確認します。
チェーン上にキャッシュがあった場合 : リニアチェーン経由でそのチャンクを受け取る。Tanium Server へのリクエストは発生しないチェーン上のどこにもなかった場合 : リーダー経由で Tanium Server に配信をリクエストする。Tanium Server から配信されたチャンクは、リニアチェーンを通って要求元の Tanium Client まで届く
Tanium Client 7.6 以降では、リニアチェーン上の ChunkRequest が PeerChunkRequestTimeout を超えて応答されない場合、Non-Leader Client も Tanium Server に直接 Chunk Download をリクエストできます。リーダー経由のチェーン伝播がタイムアウトした際のフォールバック経路です（Release Notes Tanium Server and Tanium Client 7.6.1.6334 ）。
CDN Downloads — Tanium Client 7.8 以降で追加された経路
CDN Downloads - 並列取得とフォールバック（Tanium CDN PoP 経由 / リニアチェーンへの自動切替） 各 Tanium Client が個別に Tanium CDN へリクエスト
Tanium Client 7.8 以降は、ファイル配信に Tanium CDN （Content Distribution Network）を併用するようになりました。
CDN Downloads では各 Tanium Client が個別に最寄りの Tanium CDN PoP へリクエストします（PoP = Point of Presence）。物理的に近い PoP から並列でファイルを取得できるため、配信が高速化します。Tanium Client から CDN への接続は、PoP のうち最も短く効率的なルートに自動でルーティングされます。
Package ファイルの暗号化と復号
CDN Downloads では、Package ファイルが暗号化された状態で CDN 上に置かれます。Tanium Server は Package ファイルごとに共通鍵を生成し、ファイルを暗号化したうえで CDN へアップロードします。Action 実行スケジュール到達時、Tanium Server は対象の Tanium Client へ Tanium Protocol 経由で Action メッセージを送り、メッセージに CDN 上のファイル URL と 共通鍵 を含めます。Tanium Client は CDN から暗号化済みファイルを取得し、Action メッセージに含まれる共通鍵で復号してから Action を実行します。
CDN Downloads の対象ファイル
CDN 経由で配信されるファイルは、おおまかに次の4種類です。
Action パッケージ（手動作成・モジュール作成の両方。Tanium Client Upgrades、Endpoint Configuration Toolset Upgrades、Tanium Patch Deployments を含む）
Action に同梱されるファイル
Action 実行時に追加でダウンロードされるファイル
Client Extension が Tanium Client にダウンロードを指示するファイル
CDN 利用不可時のフォールバック
ネットワーク制限などで CDN にアクセスできない場合、Tanium Client は自動的にリニアチェーン経由のピア間配信（Tanium Server からのダウンロード）にフォールバックします。切り替えは Tanium Client 側で自動的に行われるため、ユーザー側の追加設定は不要です。
まとめ
冒頭の10の疑問に、各章が用意した答えを並べます。
疑問 答え 1. Tanium Client って中身はどうなってるの？モジュール追加で入れ替えは必要？ 本体をインストールすれば、必要な追加機能は cx-config が自動で配布する。新機能を使うときに本体を入れ替える必要はない（1章） 2. どうやって端末を識別しているのか Tanium Client が生成する Computer ID で識別する。ホスト名・IP・MAC が変わっても同じ端末を追跡できる（2章） 3. リニアチェーンって何？ 同一サブネット内の Tanium Client が IP の昇順に並んで1本のリニアチェーンを形成し、前後のピアと中継し合う構造（3章） 4. リーダーって何？ チェーン両端の Tanium Client（Backward Leader = 最低 IP、Forward Leader = 最高 IP）。Tanium Server との直接通信の窓口役を担う（3章） 5. どうやってリニアチェーンって組まれるの。何か設定が必要？ Tanium Server が Registration 時に近隣ピアのリストを各端末に渡し、端末側で前後ピアを自動的に選んでチェーンを組む。デフォルトでは同一サブネット内で形成され、追加設定なしで動作する。必要に応じて境界の調整も可能（3章） 6. リーダーになったら負荷が高かったりしない？ リーダーは Tanium Server 側の窓口を担うだけで、仕組み上、リーダーだから処理量が増える構造にはなっていない（3章・4章・5章・6章） 7. リーダーしか Tanium Server と通信しないの？ 全 Tanium Client が Registration やファイルダウンロード等で Tanium Server と直接通信する（2章・3章・4章・6章） 8. Question をたくさん投げると負荷が高くならないの？ Question はチェーン上を Forward 方向に順送りで伝播し、各端末が手元の Sensor 定義を実行する。端末側・サーバ側の2層キャッシュ（Sensor Result Cache / String Cache）で同じ実行や同じ収集の繰り返しを抑える（4章） 9. Action って指定した端末にだけ届くの？ Action 指示はオンラインの全 Tanium Client に流れ、各端末が「自分が対象か」を自分で判定する（5章） 10. 「配信効率がいい」とは具体的にどういうこと？ リニアチェーン経由のピア間配信と分散キャッシュにより、Tanium Server から WAN 経由で配布するファイル量を抑える（6章）
本記事では Tanium Client のアーキテクチャを、構成・端末識別・リニアチェーン・Question / Sensor・Action・ファイル配信の観点から解説しました。詳細や最新の挙動は公式ドキュメントを参照してください。
関連記事
