注意
※本記事は執筆時点の情報に基づきます。New Relic Fleet Control の Linux/Windows ホスト対応は Public Preview 段階であり、GA（正式提供）に向けて仕様が変わる可能性があります。GA 時期・料金など未確定の内容は「見込み」として記載しています。（執筆日：2026年8月31日）
はじめに
株式会社ＮＴＴデータ九州 ビジネス共創部 デジタルビジネス推進室の濱崎です。
普段はクラウドに関するプロジェクトに携わっております。
今回は、アプリ、サーバー、ログを一元監視するSaaSプラットフォームであるNew Relicをテーマに執筆しております。
参画中のプロジェクトにおいて、複数の Linux/Windows ホストに New Relic Infrastructure Agent を導入して運用していましたが、バージョン管理や設定変更を継続的に実施する仕組みまでは整備できていませんでした。この運用を改善するにあたり、New Relic が提供する Fleet Control（Agent Control） の導入を検討しています。
本記事は、実際の運用環境での検討内容を基に、環境固有の情報を一般化して整理したものです。
本記事は「導入してみた結果」ではなく、導入の是非を判断するための PoC（検証）計画をどう設計したかという検討プロセスをまとめたものです。同じように「Agent の運用をどう仕組み化するか」で悩んでいる方の参考になれば幸いです。
1. Fleet Control とは
本題に入る前に、New Relic の Fleet Control がどういうものかを整理しておきます。
Fleet Control は、New Relic が提供するエージェントのライフサイクル管理の仕組みです。多数のホストに入れた監視エージェントの面倒を1台ずつ手作業で見るのではなく、管理画面からまとめて管理することを目的としています。
次の3つの登場人物で構成されていると考えると分かりやすいです。
| 登場人物 | 役割 |
|---|---|
| Fleet Control | New Relic の管理画面（SaaS）側の司令塔。フリート（ホストのグループ）単位で、エージェントのバージョン更新・設定変更・ログ転送設定などを指示する |
| Agent Control | 各ホストに常駐する監督役（スーパーバイザ）。Fleet Control からの指示を受け、ホスト上でエージェントの導入・設定・更新を実行する |
| Infrastructure Agent | 実際にメトリクスやログを収集する本体。Agent Control 経由で導入・管理される |
整理すると、「Fleet Control（管理画面）で指示を出す → 各ホストの Agent Control が受け取る → Infrastructure Agent に反映する」という流れです。従来はホストごとに SSH でログインして設定ファイルを編集していた作業を、管理画面からの操作に置き換えられるのがポイントです。
なお、Fleet Control の Kubernetes 向けは正式提供（GA）済みですが、本記事で扱う Linux/Windows ホスト向けは Public Preview 段階です。
2. 背景と課題
Infrastructure Agent は監視を始めるうえでは手軽ですが、運用フェーズに入ると次のような課題が出てきました。
- バージョン管理の仕組みがない：導入時のまま放置され、いつ・どのバージョンが入っているか把握しづらい
- 設定変更が属人的・手作業：ホストごとに SSH でログインして設定ファイルを編集する必要がある
- 設定のばらつき：ホストが増えるほど設定の一貫性を保つのが難しい
要するに「入れたはいいが、その後の面倒を見る仕組みがない」状態です。まずはバージョン更新の運用を整えたい、というのが検討の出発点でした。
3. 選択肢の整理 ── 既存の構成管理ツールでの対応と Fleet Control の比較
更新運用を仕組み化する方法として、大きく2つを比較しました。
| 観点 | 既存の構成管理・デプロイ運用で対応 | Fleet Control を導入 |
|---|---|---|
| バージョン更新 | 自前で定期実行の仕組みを構築 | 管理画面からフリート単位で一括指示 |
| ロールバック | バージョン指定で再適用 | 管理画面から即時実行 |
| 設定変更・ログ転送設定 | ホストごとに配布設計が必要 | 管理画面から一括で遠隔適用 |
| バージョン可視化 | 別途整備が必要 | 管理画面で一覧表示 |
| 追加で管理するもの | なし | Agent Control（常駐プロセス）が増える |
当初は「バージョン更新の効率化」だけを目的として見ていたため、Fleet Control は「Agent Control という管理対象が増えるだけでは?」という印象もありました。
しかし調べていくうちに、設定変更やログ転送設定を管理画面から一括で遠隔適用できるという、バージョン更新以外の価値が見えてきました。
4. 検討して見えてきた「効果」と「懸念」
期待できる効果
- 設定変更・ログ転送設定の一括遠隔適用：ホストに個別ログインしたり別途構成管理ツールを回したりせず、管理画面から設定変更を一括で反映できる
- メトリクスもログも1つのエージェントで：Infrastructure Agent は、CPU・メモリなどのメトリクスに加え、内蔵のログ転送機能（Fluent Bit）でログ転送も担える。その両方の設定を遠隔管理できる
- 段階的な展開：検証用フリートに先に適用して問題がないことを確認してから、同じ設定構成を本番フリートに紐付け直して横展開できる
- 可視化：全ホストのバージョン・稼働状況を一覧で確認できる
【補足】ベンダーに確認して分かったこと①：バージョン更新以外のメリット
ここは公式ドキュメントだけでは判断しづらかったため、New Relic の担当者にも確認しました。回答としても、Infrastructure Agent の設定・ログ転送設定を遠隔制御でき、サーバーへの一括設定適用が管理画面で完結する点が導入を後押しする、という整理でした。
ログ転送の対象としては、ファイル出力された OS ログ・ミドルウェアログ・アプリログ、Windows Event Log、Syslog など多様なログを想定しているとのことです。
見えてきた懸念
一方で、導入前に押さえておくべき懸念もありました。
-
既存 Agent はそのまま管理下に入らない（後述。最重要ポイント）
-
移行時に監視データの欠損が発生する（後述）
-
Agent Control という管理対象が増える：常駐プロセスであり、そのライフサイクル管理が新たに必要になる
【補足】ベンダーに確認して分かったこと②：GA・料金に関する情報
- ホスト向け Fleet Control は執筆時点で Public Preview 段階
- GA 時期については、正式な日程は公開されていない
- ホスト向けの正式な料金体系についても未公表
- 将来的な機能拡張については継続的に改善が進められているとの説明を受けた
※正式な仕様・料金・提供時期については最新の公式情報をご確認ください。
5. 導入前に必ず知っておきたい制約
検討の中で最も重要だと感じたのが、既存の Infrastructure Agent の扱いです。
既存 Agent は「後付けの管理下」には入らない
当初は「既存の Infrastructure Agent はそのまま残す」構成を想定していました。後から Agent Control を追加インストールすれば、既存 Agent のバージョンアップや設定変更ができるようになる、という理解です。
しかし調査の結果、これは誤りでした。Agent Control が管理できるのは、Agent Control 自身が配布したエージェントだけです。手動でインストール済みの既存 Agent は、種類が同じ Infrastructure Agent であっても管理対象外となり、設定変更・バージョン更新・ロールバックのいずれも遠隔からは行えません。
この点は公式ドキュメント「Manage existing instrumentation with Agent Control」にも記載があります。Linux/Windows ホストでは既存 Agent の自動移行に非対応であり、導入前の手動アンインストールが必要と明記されています。
したがって、本番移行は「入れ替え」になる
既存 Agent を管理下に置くには、次の手順が必要です。
- 既存の設定を退避
- 既存の Infrastructure Agent をアンインストール
- Agent Control をインストール
- Fleet Control 経由で Infrastructure Agent を再デプロイ（退避した設定を再現）
つまり「追加」ではなく「入れ替え」です。この構造上、アンインストールから再デプロイ完了までの間、監視データの欠損（監視断）が発生します。
補足しておくと、これはサーバー本体や業務サービスの停止ではありません。あくまで New Relic へ送られる監視データが一時的に途切れるだけで、Web サーバーやデータベースなどの業務サービスの停止や、OS 本体の再起動は伴いません。同じアカウント・同じホスト名を使えば同一ホストとして扱われるため、ダッシュボードやアラートを作り直す必要はありません（欠損した区間のデータそのものは復元されません）。
APM エージェントは対象外＝そのまま共存できる
なお、アプリケーション監視の APM エージェントは Agent Control の管理対象外です。Agent Control を導入しても APM に手を加える必要はなく、そのまま共存できます。影響を受けるのは Infrastructure Agent 側だけ、という切り分けになります。
監視断はどう扱うか（他社の対応傾向）
「監視断が確実に起きる」なら、本番でどう扱うかが論点になります。他社での対応傾向をベンダーに確認したところ、次のようなパターンがあるとのことでした（特定の事例が識別されない範囲での一般的な傾向として）。
- データ欠損をそのまま許容する運用：短時間の欠損を割り切る
- メンテナンスウィンドウの活用：計画メンテナンスの時間帯に作業し、欠損によるアラートを事前に抑止する
- ステージング/開発環境で先に適用し、問題ないことを確認してから本番に適用する
これらはそのまま、自分たちの移行計画の選択肢です。
6. PoC で検証する項目
ここまで整理した「課題」と「懸念」を、そのままにせず
「検証可能な問い」に落とし込むのが PoC の役割だと考えました。
課題の解決を検証する項目
| 検証したいこと | 検証したい問い |
|---|---|
| バージョン更新の運用改善 | フリート単位で指定したバージョンへ更新できるか |
| バージョン更新の運用改善 | 問題発生時にロールバックできるか |
| バージョンの可視化 | 管理画面から導入済みバージョンを一覧で把握できるか |
| 設定変更の効率化 | Agent Control 導入 → Infrastructure Agent デプロイ → 設定変更が管理画面から完結するか |
| 設定の標準化 | フリート内の全ホストに一括反映されるか、反映時間は許容範囲か |
| ログ転送設定の運用改善 | 転送していない状態から、管理画面の設定追加で転送が始まるか |
導入コスト・懸念事項を検証する項目
| 検証したいこと | 検証したい問い |
|---|---|
| 監視断の影響 | 既存 Agent の入れ替えで、送信停止から再開まで実際に何分かかるか |
| Agent Control の負荷 | 導入前後で CPU・メモリ・ディスクがどれだけ増えるか |
特に負荷への影響は、調べても公開された数値が見つかりませんでした。ベンダーに確認しても「案内できる公開数値はない」との回答で、既に導入している他社の環境で負荷やディスクの問題は起きていない、という定性的な情報にとどまりました。だからこそ、自分たちの環境で実測することに PoC の価値がある、と判断しました。
7. まとめ
公式ドキュメントで確認できる情報に加え、
ベンダーへの確認で初めて分かった情報が
検討を大きく前進させました。
具体的には、負荷に関する公開数値がないこと、
ログ転送設定の運用イメージ、
移行時の一般的な対応傾向などです。
Public Preview 段階の製品では、
こうした確認プロセス自体が検討の一部になります。
参考
- Getting started with New Relic Control
- Set up Fleet Control
- Set up and install Agent Control
- Managing configurations
- Manage existing instrumentation with Agent Control
※本記事中の「ベンダー担当者への確認結果」は、執筆時点での一般的な説明や見解として共有いただいた内容を整理したものです。正式な製品仕様、サポート方針、料金体系、リリース計画を保証するものではなく、今後変更される可能性があります。最終的な判断にあたっては、最新の公式ドキュメントおよび New Relic 社の正式な案内をご参照ください。