SB C&Sの最新技術情報 発信サイト

C&S ENGINEER VOICE

SB C&S

【Tanium】【AI】【Tanium Atlas】活用のススメ③

セキュリティ
2026.07.02

■はじめに

Tanium Atlasについて、どんな使い方ができるか。
という活用案を考える記事になります。

参考までにご覧ください。

※あくまで弊社の環境で検証した際の結果ですので、実際の仕様とは異なる場合がございます。
 その点ご留意いただけますと幸いです。
 また、動作の内容がプロンプトの内容に大きく左右される機能の特性上、再現性やその結果生じたトラブルにおいては弊社やTanium社では責任を負いかねますことご留意ください。

Atlas関連の過去の記事になります。
ご参考までにどうぞ。

【Tanium】【AI】Tanium Atlasとは。Taniumを進化させるAI新機能。

【Tanium】【AI】【Tanium Atlas】活用のススメ①

【Tanium】【AI】【Tanium Atlas】活用のススメ②

=======================
もくじ
■しばらくAtlasを触ってみて
■Atlasの画面説明
■追加情報
=======================


■しばらくAtlasを触ってみて

Atlasの検証をしばらく実施してきました。
良いところ、少し使い方にコツを要するところなど様々見つかりましたが
まずAtlasのすごい所は、シンプルに言えばこれにつきるかなと。

目的を渡せば、TANIUMモジュールやスクリプトを駆使して達成まで思考と試行を繰り返し完遂してくれる。

 例えば複数端末への作業の一括実行スキームや、特定の端末の調査分析を指示すれば
 目標達成までに必要なモジュールでの設定登録やモジュールで利用するスクリプトの作成などを
 ユーザーの代わりにやってくれます。
 周期実行なども併せて指示すれば、運用の手間は劇的に削減できます。
 「なんでもできる」と言われていたTANIUMの特性とシナジーが強く、他の製品にatlasを積んでも
 同じ効果を持たせるのは難しいのではないかと思います。

バッググラウンドエージェントにポーリングや定期実行させることで、自由な条件で動作のトリガーを指定できる。
「毎回状態を確認してこれがこうなったらメールで通知して!」が可能。

 セキュリティ的な使い方をするのであれば、
 「連続してアラートを上げている端末があったら、アラート内容を相関しインシデントか判定して」
 と指示すれば定期的にアラートの状態を確認して問題があれば教えてくれます。
 ※相関の精度はプロンプト次第なのでそこはご留意ください。

 運用向きの使い方であれば、
「登録済みのパッチリストを日次で取得して、リニアチェーンの状態を加味してパッチのダウンロード量
 をマークダウンに出して」と指示すれば、
 リスト名 / 単体でダウンロードした場合の総量 / リニアチェーンで削減した後の総量 / 削減率 / パッチ数 を計算して適宜更新してくれます。
 ここに社内NWの帯域や端末の設置情報も渡せば、作業時の帯域不可も加味したパッチ適用を計画できますね。
スクリーンショット 2026-06-30 21.52.30.png
※チェーン考慮の値 = 各パッチをインターネットから1回だけ取得する際の合計量
 Tanium のリニアチェーンでは、1台目がインターネット(または上位リレー)からダウンロードし
 残りの端末からはそこからP2Pで受け取る。
 なので「チェーン考慮 = フリート全体でインターネット向きに流れる実トラフィック量」
 と考えると歴然ですね。
 ワースト=1台1台が内外の通信でフルにダウンロードしてきた場合。


■Atlasの画面説明

今更ですが、最近アップデートも入ったので改めてAtlasの画面をご説明します。

AtlasはTaniumのホーム画面のこのアイコンで開けます。
スクリーンショット 2026-06-30 22.19.04.png

今回は新規のページを表示していますが、通常最初に表示されるのは最新のチャット履歴です。
試しにデモをしたい旨を伝えてみます。
スクリーンショット 2026-06-30 22.20.47.png
スクリーンショット 2026-06-30 22.23.05.png

コンポーネントが追加された場合は、チャット画面が右に寄せられます。
真ん中のエリアがコンポーネント画面です。
円グラフはないみたいですね。
代わりにドーナツチャートで出してくれました。
スクリーンショット 2026-06-30 22.25.12.png
スクリーンショット 2026-06-30 22.25.26.png
ちなみに真ん中のコンポーネント画面に表示されるチャートやマークダウンには動的/静的な
違いもあるようです。
スクリーンショット 2026-06-30 23.05.52.png
スクリーンショット 2026-06-30 23.09.39.png

この違いを利用することで、トークンを節約できそうですね。


■追加情報

最後にatlasで見えてきた仕様部分の追加情報です。

※あくまで弊社の環境で検証した際の結果ですので、実際の仕様とは異なる場合がございます。
 その点ご留意いただけますと幸いです。

メール送信

単純に「こういう条件でメール通知して」だと少し悩みます。
connectで接続という手順もありますが、atlasはapiでメール送信の実行が可能です。
そのためメールサーバーの登録さえすればconnectを使わずにメールを送ることが可能。
今のところ弊社実績だとMSのgraphQLでの送信が可能であり安定。
メール送信を頼む時は、
「メールサーバー登録プロファイルの〇〇(graphQLプロファイル)で送信して」と
指示しましょう。

また、メール送れた!やったー!
で完結してしまいがちですが、フォーマットを指定しないと割とコロコロデザインが変わります。
しっかりと最低限の体裁は指定しておきましょう。

他チャットとの連携

他チャットの情報を今使ってるチャットで引用したい。
というときは、バックグラウンドエージェント経由なら可能な場合もあります。
また、チャット内での情報は記憶領域で他チャットにも共有されるものもあります。

例えば別のチャットで「語尾を"にゃん"にしてみて」と指示すると、
新しいセッションで新しいチャットを開始した時にはそのチャットでも「にゃん」となっています。
※ちなみに共有はセッションの終了をトリガーに行われるようです。

上記はあくまで冗談ですが、例えばこんな部分で注意が必要です。
===========
チャットAでは大事な作業を行うから特定の動作の前に承認を求めてほしい。
チャットBでは検証で承認が面倒だからいちいち聞かないでほしい。
===========
こういった形で利用するつもりで、チャットBで「以降はこの操作に承認を求めないで」
と伝えてしまうと
チャットAでも思わぬところで承認がスルーされ更新や削除が実施されてしまう。
という事もあり得ます。

実際私はそれで他のチャットのエージェントが消えてしまいました。
幸いなことに、「戻して!」と言ったら復元してくれましたが。

また、コンポーネントIDを指定すれば別チャットのコンポーネントに書き込みが可能なようです。
※これも少しテクが必要なので変更されるかもしれませんが。
分析系のチャットが作業系のチャットでエンドポイントにした操作を誤検出しないように
変更履歴コンポーネントのチャット間共有という手も使えます。

他チャットとの連携(注意書き)

他チャットで作成したエージェントに対し、別のチャットから再作成を依頼すると
今のチャットに紐づいたエージェントが作成されてしまいます。
弊害としては、本来別チャット上でエージェントが通知を出す仕様にしてたのに、
再作成を指示したチャットで通知してきたりしてしまいます。

エージェントのプロンプト上限

単一のエージェントでは恐らく8000文字が限界です。
上限ギリギリまで使うと、後々の修正に手間取ります。
とはいえ複数機能は統合させた方がトークンの消費を抑えられるかもしれません。
プロンプトの文字数を考慮してバランスをみるのが良いかと。

また、上限を超えてプロンプトを追加しようとすると、
Atlasが自ずからプロンプトを削除してスペースを確保しようとします。
確認無しに実行するときもあるので、
油断して詰め込みすぎると動作に影響のある情報を削除することもあります。
普段からプロンプトの使用量はウォッチしましょう。

また、パッケージやapiでの情報送信など様々な部分で8000あたりで処理が失敗する気がします。

エージェントの動作とプラットフォームの負荷

同じ時間にエージェントを複数動作させると、プラットフォーム側が対応出来ずに処理が失敗します。
当たり前ですが、物理的に不可能なものは不可です。
間隔実行とcron実行を組み合わせ、実行時間を分散させましょう。

エージェントのトークン消費について

Atlasに確認した情報ですと、
=======
エージェントごとに時間当たりのトークン消費量の上限
エージェント全体で時間当たりのトークン消費量の上限
=======
が存在するようです。
超過した場合は、それぞれ母数の範囲のエージェントが一定時間停止します。
また、リミットのシステム設定値の表記[atlas_ambient_tokens_per_hour_limit]なので
1時間当たりなのは確実そうですが、
固定リセット型(例:1:59に停止したら2:00にリセットされる。毎時:00リセット)
なのか
スライドウィンドウ型(例:停止タイミングから1時間)
なのかは検証中です。
※あくまで弊社の環境で検証した際の結果ですので、実際の仕様とは異なる場合がございます。
 その点ご留意いただけますと幸いです。

■最後に

まだ新しい機能のため、検証結果を適宜したためている状態です。
誤った情報を記載している可能性もあるためお気を付けいただけますと幸いです。


※本ブログの内容は投稿時点での情報となります。今後アップデートが重なるにつれ
 正確性、最新性、完全性は保証できませんのでご了承ください。

他のオススメ記事はこちら

著者紹介

SB C&S株式会社
技術本部 技術統括部 第4技術部 1課
宮澤 建人