Datadog と JP1 の比較 - 統合運用管理と SaaS 監視の思想の違い

結論 - 守備範囲が非対称だから「何を移すか」を先に分ける

JP1 は日立の「統合システム運用管理」製品群で、公式サイトはオンプレミス / マルチクラウド / ハイブリッドを対象に、統合管理とシステム監視だけでなく、業務連携と自動化、エンドポイント管理、バックアップ、セキュリティまでを実現するソリューションとして掲げています (2026 年 9 月時点・出典: 統合システム運用管理 JP1)。Datadog はメトリクス / ログ / トレースを 1 つのデータ基盤に集めるオブザーバビリティの SaaS で、ジョブの実行管理や端末の資産管理は守備範囲に含みません。両者は同じ土俵で優劣を競う製品ではなく、重なる部分 (監視と通報) と重ならない部分 (ジョブ / 資産 / 配布 / バックアップ) を持ちます。検討の最初の問いは「JP1 を Datadog に置き換えられるか」ではなく「JP1 が担う仕事のうち、どれを Datadog 側に移し、どれを残すか」です。以下ではその切り分けに使う軸を 3 つ立てます。

JP1 の製品群はどう並んでいるか

公式サイトの製品一覧は、機能分類ごとに製品名が並ぶ形です (2026 年 9 月時点・出典: 統合システム運用管理 JP1)。Datadog と重なる「監視」に当たるのは統合管理とパフォーマンス管理、ネットワーク管理、通報管理の分類で、それ以外の分類は Datadog に対応する製品がありません。

販売地域についても 1 点あります。製品&サービスのページは、JP1 製品の一部が日本限定販売であること、JP1 Cloud Service と IT 運用最適化サービスは日本でのみ販売していることを明記しています (出典: 製品&サービス)。海外拠点のシステムまで同じ基盤で見たい場合は、この点を最初に確認する必要があります。

軸 1: 運用の中心に置くものは何か

1 つ目の軸は、運用の中心に何を置くかです。JP1 の一覧を見ると、ジョブ管理 (JP1/Automatic Job Management System 3) や運用自動化、IT 資産管理といった「業務を回す」製品が監視と並んで置かれています。夜間バッチの実行順序、端末の配布、バックアップの成否まで含めて 1 つの運用基盤で管理する設計です。Datadog の中心はシステムの内部状態の観測で、インフラ監視のメトリクス、ログ、トレースを同じタグで結び、「どこで何が起きたか」を調査するための基盤です。この違いは、監視で見つけた異常の「その後」に現れます。

したがって「バッチの成否や端末の管理を含めた業務運用の統合」が中心なら JP1 の領分が広く、「クラウド上で増減するサービスの内部状態を調べる」が中心なら Datadog の領分が広くなります。どちらが優れているかではなく、自分の運用の中心がどちらに近いかで読みます。

軸 2: 監視対象と設定はどれくらいの頻度で変わるか

2 つ目の軸は変更の頻度です。変更には 3 種類あり、それぞれで両者の設計が違います。

JP1 は公式サイトで「運用 as Code」と「運用統合」を掲げ、SaaS 提供の JP1 Cloud Service も並べているため、変更の多い環境への対応を打ち出していること自体は確認できます (2026 年 9 月時点・出典: 統合システム運用管理 JP1)。判断が分かれるのは、変更を「誰が」行うかです。運用部門が窓口となり手順書に沿って計画的に反映する体制なら、統合運用管理の体系に沿った運用が組みやすく、開発チームが自分のサービスの監視を自分で足して週に何度も変える体制なら、設定を各チームに委ねやすい SaaS 型の方が摩擦は小さくなります。組織の体制と製品の設計が合っているかを見る軸です。

軸 3: 費用はどう決まるか (単位が違うので数字は比べない)

3 つ目の軸は費用の決まり方で、単位が違うため数字は比べません。日立は「価格と構成例」のページで JP1 標準価格一覧 (Excel 形式) と分類ごとの構成例と概算価格 (PDF 形式) を公開し、掲載のない製品は問い合わせとしています (2026 年 9 月時点・出典: 価格と構成例)。費用は「どの製品を、どの構成で、何ライセンス」で決まる製品ライセンス型です。Datadog は SKU ごとの使用量単価を公開し、たとえばインフラ監視はホスト 1 台あたりの月額 (年契約 / 月契約 / オンデマンドの 3 単価) で、対象が増減した分だけ請求が動きます (2026 年 8 月時点・出典: Datadog Pricing)。

決めるべきは、構成を固定して年度予算を確定させたいか、対象の増減に合わせて使った分だけ払いたいか、のどちらに近いかです。積み上げの数え方は料金体系の読み解きで扱っています。本記事は課金の仕組みを解説するものです。具体的な単価や料金は各社の料金ページで確認してください。

JP1 が向く条件と Datadog が向く条件

3 つの軸を条件の形に直すと、次のように対置できます。冒頭で述べた守備範囲の非対称も同じ表の上 4 行に並べました。どちらの列も「向く」条件であり、もう一方ではできないという意味ではありません。

向く条件の 4 行で 3 つ以上が片側に寄るなら、その側を中心に据えて設計を始めるのが順当です。左右に割れる場合は「置き換え」ではなく次の節の併存が現実的な形になります。Datadog を選ぶ場合の具体的な損得の見極め (規模帯別の月額、要件別の判定) は導入判断チェックリストが扱っており、本記事はそこへ進む前の「比べる相手なのか」を整理する位置にあります。

併存の形と移行前に確かめる 3 つのこと

併存の基本形は「業務運用と統合的な通報は JP1 に残し、クラウド上のサービスの観測は Datadog に寄せ、異常検知を JP1 側へ流す」です。日立の公式サイトはシステム運用ハックとして、オブザーバビリティの『メールで通知される大量アラートも JP1 でまとめて管理する方法』を掲載しており、観測ツールのアラートを JP1 側で集約する使い方を日立自身が示しています (2026 年 9 月時点・出典: 統合システム運用管理 JP1)。Datadog 側の出口はモニターの通知で、メールや Webhook で外部に渡せます。JP1 の公式ページに Datadog との連携の記載は無いため、どの経路 (メール / Webhook / イベントの取り込み) で受けられるかは JP1 側の製品仕様で個別に確認してください。移行を決める前に確かめることは 3 つです。

JP1 と比べる作業は優劣を決める作業ではなく、運用の地図を描き直す作業だと捉えると判断が早く進みます。