Taniumでエンドポイントに変更を加えたいとき、Deployモジュールを使うべきか、InteractからCustom Packageを実行すべきか。ソフトウェア配信はもちろん、レジストリ変更やスクリプト実行など、さまざまな場面で「どっちでもできるけど、どっちが正解？」と迷った経験はありませんか。
実は、この迷いを持つこと自体が健全です。両方の手段を知っているからこそ生まれる悩みです。この記事では、まず「明確にこっち」という場面を整理し、その上で「どちらも使える」ときの判断ポイントを解説します。
「DeployとCustom Packageの使い分け、考えたことはありますか？」――こう聞くと、多くのTanium管理者が「言われてみれば、特にルールは決めていない」と答えます。
Deployに慣れていること自体は悪いことではありません。ただ、Custom Packageの方がより適切な場面でも、慣れているからという理由でDeployを使ってしまっているケースは少なくありません。逆に、Custom Packageで済むシンプルな作業にも関わらず、わざわざソフトウェアパッケージを作成して配信していることもあります。
深刻なトラブルが起きるわけではありません。しかし、「もっと早く終わったのに」「もっとシンプルにできたのに」という場面が積み重なると、運用全体の効率に少しずつ影響してきます。
チーム内で使い分けのルールが共有されていないと、担当者ごとにやり方が異なることにもつながります。同じ作業なのに人によってDeployだったりCustom Packageだったりすると、引き継ぎ時にも混乱の原因になりかねません。
この記事では、「明確にこっち」という場面を先に整理し、その上で迷うケースの判断ポイントを提示します。
Deployモジュールは、アプリケーションの配信・インストールのためのツールです。これがDeployの本来の用途であり、この領域ではCustom Packageよりも明確に優れた機能を持っています。
以下のような場面では、迷わずDeployを選んでください。
ブラウザの更新、Web会議ツールの展開、セキュリティソフトの配信など、アプリケーションのライフサイクル管理はDeployの最も得意とする領域です。Predefined Galleryに用意されているソフトウェアであれば、パッケージを一から作る手間もありません。
Deployには、インストール前後のエンドユーザーへの通知機能や、再起動のコントロール機能が備わっています。「今からアップデートが始まります」という事前通知や、「再起動が必要です」という案内をエンドユーザーに表示できるため、業務時間中の作業でもユーザー体験を損ないにくい設計になっています。
Self Service Clientを使えば、アプリケーションストアのように、エンドユーザーが自分のタイミングでアプリケーションを選んでインストールできます。管理者が全端末に一斉配信するのではなく、ユーザーの意思で導入できるため、展開のストレスを軽減できます。
「あるアプリをアンインストールしてから別のアプリをインストールする」「前提条件を満たしてから本体を配信する」など、複数のステップを特定の順序で実行する必要がある場合もDeployが適しています。バンドル機能を使えば、こうした複数ステップの処理をローコードで定義できます。Custom Packageで同じことをやろうとすると、すべてをスクリプトで制御する必要があり、開発・保守の負担が大きくなります。
一方、Custom Packageが明確に合理的な場面もあります。シンプルな処理を素早く実行するというシナリオでは、Deployよりも効率的です。
レジストリを1つ変更する、設定ファイルの値を書き換える、特定のサービスを再起動する――こうしたコマンド1つで完結する作業にDeployを使うのは、過剰な手段です。ソフトウェアパッケージの作成、インストール条件や完了条件の定義といった手間をかけるよりも、Custom Packageを作成してすぐ実行する方がはるかに早く終わります。
特にレジストリの変更などでは、Taniumが公式に提供しているパッケージがすでに存在するケースもあります。公式パッケージを活用すれば、自分でスクリプトを書く必要すらありません。
Custom Packageの大きな強みは、Questionで対象端末を柔軟に絞り込み、そのまま即座にアクションを実行できる点です。「このSensorの値がこの条件に合致する端末」を特定し、その場でアクションを打てます。
たとえば、特定のレジストリ値を持つ端末をQuestionで見つけて、その場ですぐにレジストリ値を修正したい、といった場面ではCustom Packageの即時性が活きます。
Deployでソフトウェアパッケージを配信するには、インストール条件（どの端末に適用するか）と完了条件（インストールが成功したとみなす条件）を定義する必要があります。アプリケーションのインストールであればこれらの条件は明確ですが、単純なスクリプト実行やレジストリ変更のようなケースでは、これらの条件を適切に定義すること自体が難しい場合があります。
条件定義に無理にこだわるよりも、Custom Packageで実行し、Actionの結果で成否を確認する方がシンプルで実用的です。
ここまでで「明確にこっち」という場面を整理しました。しかし実際の運用では、「どちらでもできるが、どっちがいいのだろう」と迷うケースも少なくありません。複数のレジストリ値をまとめて変更したい場合、設定ファイルの配布と適用を行いたい場合など、DeployでもCustom Packageでも実現可能なシナリオです。
そうした場面で使える判断ポイントを整理します。
| 判断ポイント | Deploy寄り | Custom Package寄り |
|---|---|---|
| 処理のステップ数・前後関係 | 複数ステップ、順序制御が必要 | 単純な1ステップ |
| 配信・実行タイミングの制御 | メンテナンスウィンドウ、スケジュール指定 | — |
| 処理実行の即時性 | — | 今すぐ実行したい |
| インストール条件・完了条件 | 事前条件・成功判定を厳密に定義したい | Action結果の確認で十分 |
| ユーザー通知・再起動 | 通知や再起動制御が必要 | — |
| ユーザーコンテキスト実行 | ユーザー権限での実行が必要 | — |
| セルフサービス | ユーザーが自分で選んで適用 | — |
以下、それぞれのポイントを詳しく見ていきます。
今すぐ実行したい場合はCustom Packageで決まりです。
Custom Packageは、InteractからQuestionで対象端末を絞り込み、その場でアクションを実行できます。「今すぐこの端末に対してこの処理を適用したい」という場面では、Custom Packageを使います。
一方、Deployでは対象端末を指定しても、まずSoftware Package Applicability Scanが実行されます。これはエンドポイントがソフトウェアパッケージの要件を満たしているかを評価するスキャンで、端末が「Install Eligible（インストール可能）」と判定されて初めてデプロイメントが実行される仕組みです。このスキャンはデフォルトで24時間間隔のスケジュール実行のほか、カタログ更新時などにも実行されますが、いずれにしてもスキャンでInstall Eligibleと判定されるまで処理は始まりません。計画的な展開であれば問題ありませんが、「今すぐ」が求められる場面ではこの仕組みが制約になります。
処理が複数のステップで構成され、特定の順序で実行する必要がある場合はDeploy寄りです。バンドル機能で順序制御がローコードで実現できます。単純な1ステップの処理であれば、Custom Packageの方がシンプルです。
配信タイミングをきめ細かくコントロールしたい場合はDeploy寄りです。Custom Packageでも周期的な実行（Scheduled Action）は可能ですが、「この時間帯・この曜日は配信しない」といったメンテナンスウィンドウの制御はDeployの機能です。タイミング制御が不要であれば、どちらでも対応できます。
エンドユーザーに事前通知を出す、再起動のタイミングを制御するといった要件がある場合はDeployで決まりです。こうした機能はCustom Packageにはありません。通知や再起動制御が不要であれば、どちらでも対応できます。
事前条件のチェックや成功判定を厳密に定義したい場合はDeployの条件定義機能が有効です。一方で、条件を明確に定義しづらい場合はCustom Packageの方が適しています。Actionの結果で成否を確認するシンプルな運用で十分なケースも多いでしょう。
ユーザー権限での実行が必要な場合、DeployではRun Commandの設定でActive Userを選択できます。Custom Packageでも RunAsUser を利用すればユーザーコンテキストでの実行は可能ですが、Deployの方がGUI上でシンプルに設定できます。
エンドユーザーが自分で選んで適用する形式であれば、Deployで決まりです。Self Service ClientはDeployの機能であり、Custom Packageでは実現できません。セルフサービスが不要であれば、どちらでも対応できます。
実際には、これらの判断ポイントのいずれかによってどちらを使うかが決まるケースがほとんどです。すべてのポイントを総合的に評価するというよりも、「即時性が求められるからCustom Package」「セルフサービスで配りたいからDeploy」のように、ユースケースに応じて自然と選択が決まることが多いでしょう。
大事なのは、どちらかに統一することではなく、両方の特性を理解した上で、その場面に適した手段を選べることです。
Deployはアプリケーション配信・ライフサイクル管理を中心に、通知・再起動制御・セルフサービス・複数ステップの順序制御といった機能が充実しています。Custom Packageはシンプルな処理の即時実行、Questionによる柔軟なターゲティング、公式パッケージの活用に強みがあります。
どちらかに詳しくなること自体は悪いことではありません。ただ、「慣れているからこっち」という選び方は、必ずしもベストとは言えません。判断ポイントを知っていれば、「なんとなく」ではなく、そのユースケースに適した手段を根拠を持って選べるようになります。
ザッツイットの運用支援サービスでは、使い分け方も含め、DeployとCustom Packageそれぞれを上手に活用するための支援も行っています。お気軽にお問い合わせください。