Datadog CI Visibilityとは？対応CI9種の設定手順・料金とCI/CD Optimizationの機能

CI Visibilityは、GitHub ActionsやGitLab、JenkinsなどのCIで動いたパイプラインをDatadogに集め、実行時間・失敗・待ち時間をトレースとして見るための製品です。テスト単位の結果はTest Optimizationという別製品が担当し、料金も別建てです。2026年10月には、この2つを1つの画面にまとめたCI/CD Optimizationが公式ブログで紹介され、設定画面の入口も新しいUIに移りました。この記事では、2026年10月31日時点の公式ドキュメントと料金ページをもとに、どのCIがどの方式でつながるか、GitHub Actionsで何を設定するか、フレーキーテストにどう対処できるか、費用がどう決まるかを順に整理します。

まとめ：CI Visibilityを入れる前に決めること

• パイプラインの可視化（CI Visibility）とテストの可視化（Test Optimization）は別製品です。課金はどちらもアクティブなGitコミッター単位で、年契約の単価は月8ドルと月20ドルです。
• CI/CD Optimizationは2製品を1つの画面にまとめたUIで、別料金の製品ではありません。設定画面はSoftware Delivery配下のCI/CD Optimizationに移っています。
• 標準で連携できるCIは9種類です。GitHub Actionsは、GitHub AppにActions: Read Onlyを付けて有効化するだけで取り込めます。ワークフローの書き換えは要りません。
• Google Cloud Buildのように一覧に無いCIは、公開API（/api/v2/ci/pipeline）に実行結果を自分でPOSTします。
• テストの計装はdd-traceなどの言語ライブラリで行います。後述のJest検証では、APIキーが無効でもテストジョブは成功しました。初回は、ジョブの成否とは別にDatadog側へデータが届いたかを画面で確かめてください。
• フレーキーテストには、失敗の自動再試行（既定5回）、新規テストの反復実行（最大10回）、隔離と無効化、修正確認の4つの対処が用意されています。

CI Visibility・Test Optimization・CI/CD Optimizationの守備範囲

Datadogのソフトウェアデリバリー系の製品は、見る単位ごとに分かれています。ドキュメントはCI Visibilityを「パイプライン起点」、Test Optimizationを「テスト起点」のビューと説明しています。

パイプラインの実行は、APMの分散トレースと同じくトレースとして記録されます。最上位のPipelineの下にStage・Job・Step・Commandの階層が付き、GitHub Actionsならワークフローがパイプラインにあたります。ステージの概念が無いCIでは、この階層が省かれます。

CI/CD Optimizationで1つにまとまった画面

CI/CD Optimizationの公式ドキュメントによると、新しいUIは、CI VisibilityかTest Optimizationのどのページでも上部のTry It Nowを押すと有効になり、Switch Backでいつでも元のUIに戻せます。中身は次の4つです。

• CI/CD Overview：信頼性と所要時間の主要な指標、改善の提案、モニターの状態を1枚のダッシュボードで表示
• 統合エクスプローラー：パイプライン（Pipeline・Stage・Job・Step・Command）とテスト（Session・Module・Suite・Test）を切り替えて検索
• Flaky Management：リポジトリ横断のフレーキーの傾向と優先度の提案
• 連続したセットアップ：CIプロバイダの接続から、そのままテストスイートの設定に進める

料金ページの品目はPipeline VisibilityとTest Optimizationのままで、CI/CD Optimizationという行はありません。新UIにしても請求は変わらず、使っていない側の製品のデータが画面に出てくるわけでもありません。

対応サイトにも注意が要ります。米国政府向けのapp.ddog-gov.comとus2.ddog-gov.comではCI VisibilityもTest Optimizationも提供されていません（CI Visibilityの公式ドキュメント冒頭の注記）。本記事の設定例では、AP1（ap1.datadoghq.com）を使用します。

対応CIプロバイダと連携方式の違い

標準の連携先は、AWS CodePipeline・Azure Pipelines・Buildkite・CircleCI・Codefresh・GitHub Actions・GitLab・Jenkins・TeamCityの9種類です（CI Pipeline Visibilityの対応一覧）。連携の仕組みはCIごとに違い、CI側で用意する作業の量もそれに比例します。

GitHub ActionsをGitHub Appで連携する手順

GitHub Actionsの連携は、ワークフローの実行情報をプライベートのGitHub Appが読み取る方式です。手順はGitHub Actions Setup for CI Visibilityに沿うと次のとおりです。

1. DatadogのGitHub連携タイルでCreate GitHub Appを押し、権限の編集でActions: Read Onlyを付けてアプリを作成・インストールする
2. Software Delivery、CI/CD Optimization、Add a Pipeline Providerの順に進み、GitHubを選ぶ（旧UIではSoftware Delivery、CI Visibility、Add a Pipeline Provider）
3. Enable Accountを押し、アカウント全体またはリポジトリ単位でEnable CI Visibilityをオンにする

有効化した直後から、パイプラインが表示され始めます。止めるときは、CI/CD Optimization、Settings、GitHub Actionsの画面でトグルを外します。CI Pipeline Listに表示されるのは各リポジトリのデフォルトブランチだけなので、featureブランチの実行はExecutionsのページで探します。

ジョブのログは2つの設定に分かれています。失敗の原因をLLMで分類するLogs Analysisは既定で有効です。ログ本文をLog Managementに保存するLogs StorageはCI/CDのRepository settingsで別に有効化し、CI Visibilityとは別に課金されます。保存されるログにはdatadog.product:cipipelineとsource:githubのタグが付き、1GiBを超えるログファイルは切り詰められます。ランナーのホストでDatadog Agentを動かせば、ジョブのスパンからそのホストのメトリクスを開けます。Actions Runner Controller以外の構成では、ランナー名とホスト名を一致させる必要があります。

GitLabとJenkinsで確認する最低バージョン

GitLabは、プロジェクト・グループ・インスタンスの設定にあるDatadog連携からAPIキーを登録します。セルフホストは14.1以上が前提です。13.7.0以上14.1未満でもdatadog_ci_integration機能フラグを有効にすれば使えますが、この範囲はGitLab側の不具合でグループ単位・インスタンス単位の有効化ができず、プロジェクトごとの設定になります。GitLab 17.7以降では、連携画面のEnable CI Visibilityにチェックを入れないとトレースが送られません。

Jenkinsは、Agentを経由する場合もAgentを使わない場合も、Datadog Jenkinsプラグイン（v3.1.0以上）が必須です。ジョブとホストのメトリクスを結び付けるにはプラグインv5.0.0以上とAgentが要り、Jenkinsの画面からTest Optimizationを設定するならプラグインv5.6.0以上が必要です。Agentを置かない構成では、プラグインにDatadogサイトとAPIキーを直接設定します。Jenkins自体の構成はJenkinsとは？できること・無料の範囲とインストールから使い方まで【2026年版】で扱っています。

Cloud Buildなど標準連携のないCIからのAPI送信

Google Cloud Buildは標準の連携先に含まれていません。こうしたCIは、ビルドの終了時に実行結果をhttps://api.datadoghq.com/api/v2/ci/pipelineへPOSTします（AP1の場合はホストをapi.ap1.datadoghq.comに読み替えます）。主な項目は、実行ごとに一意なUUID・パイプライン名・リポジトリURL・コミット作成者のメール・コミットSHA・状態・開始時刻と終了時刻（RFC3339）・CI側の画面URLです。

curl -X POST "https://api.ap1.datadoghq.com/api/v2/ci/pipeline" \
  -H "Content-Type: application/json" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -d @payload.json

実行前に、送信先サイトのAPIキーを環境変数DD_API_KEYに設定し、カレントディレクトリにpayload.jsonを作成します。JSONはdata.typeをcipipeline_resource_requestとし、data.attributes.resourceの中にlevel・unique_id・name・url・start・end・statusなどを指定する構造です（カスタムパイプラインの送信手順）。

このとき、開始時刻にはキューで待った時間を含めません。unique_idは再実行や部分的な再実行でも重複させない決まりで、同じ階層の中では一意である必要があります（パイプラインとジョブが同じIDを持つことは許されます）。

パイプラインのボトルネックと失敗原因を見つける機能

クリティカルパスと待ち時間の内訳

クリティカルパスの判定は、9種類の連携先とカスタムパイプラインのすべてで使えます。並列ジョブが多いパイプラインでは、全体の所要時間を決めているのはクリティカルパス上のジョブだけなので、ここを先に絞り込むのが近道です。所要時間は、ジョブが実際に動いていた実行時間（Execution time）、ランナーを待っていたキュー時間（Queue time）、手動承認を待っていた時間（Approval wait time）に分けて表示されます。「ビルドが遅い」の原因がランナー不足なのか処理そのものなのかは、キュー時間を見れば切り分けられます。キュー時間が短いのに実行時間が伸びているジョブは、ランナーを増やしても速くなりません。

Logs Analysisによる失敗の分類

Logs Analysisは、失敗したジョブのログをLLMに渡し、要約したエラーメッセージとドメイン・サブドメインの分類を付けます（Logs Analysisのガイド）。入力に使うのは、過去の成功した実行で収集されたログに現れなかった「関連する」ログ行の最後の100行です。関連する行が無ければ、ログの最後の100行を使います。各行は機密情報を伏せる処理を通してから使われます。

codeは変更した開発者が直すもの、platformはCI基盤を持つチームが直すもの、という切り分けです。@error.domainのファセットで集計すれば、「失敗の何割が基盤側か」をダッシュボードで追えます。対応CIはAzure Pipelines・Buildkite・CircleCI・GitHub Actions・GitLab・TeamCityとカスタムパイプラインで、JenkinsとAWS CodePipeline、Codefreshは一覧にありません。分類はLLMの判断なので、同じCannot connect to docker daemonがnetworkになったりinfrastructureになったりする揺れがあるとドキュメント自身が注記しています。

自動ジョブリトライの前提条件

Automatic job retriesは、Logs Analysisと同じ分類器が一時的な失敗と判定したジョブを、CI側のAPIで再実行する機能です（Automatic job retries）。対象はGitHub ActionsとGitLabだけで、前提は次の4つです。

• 対象リポジトリでLogs Analysisが有効
• ソースコード連携（Source Code Integration）を設定済み
• GitHub Actionsの場合、GitHub AppにActions: Write権限
• 設定する人にDatadogのCI Provider Settings Write権限

再試行の回数はジョブごと・コミットごとに数えられ、上限はDatadogが決めています。GitHub Actionsでは、APIの制約からワークフローが終わるのを待ってから再実行し、失敗したジョブを1回のAPI呼び出しでまとめて再実行します。一時的でないと判定されたジョブも一緒に走り直すため、GitHub Actionsの実行時間が増えることがあります。保護ブランチで再実行させるには、アプリに組織全体のMaintainer相当の権限が要ります。自動リトライはフレーキーなテストやインフラの不調を見えにくくするので、再実行で救われた回数をモニターで追う運用とセットで有効にするべきです。

CIモニターでの通知

モニターはMonitors、New Monitor、CI/CD & Testsの順に作成します（CI/CDとテストのモニター）。パイプライン側は、Executionsのページの検索条件をそのまま件数や所要時間の閾値に使えます。テスト側にはNew Flaky Test・Test Failures・Test Performanceのテンプレートがあります。評価する期間は5分・15分・1時間のほか、1分から2日までの任意の値を選べます。デフォルトブランチのパイプライン失敗率や、クリティカルパス上のジョブのキュー時間に閾値を置いておくと、開発者から「最近CIが遅い」と言われる前に気付けます。障害対応の指標づくりはMTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説【2026年版】も参考になります。

Test Optimizationでテストを計装する手順

テスト側の計装には言語別のライブラリを使います。現行ドキュメントの対応表に載っている言語は.NET・Java・JavaScript・Python・Ruby・Swift・Goで、それ以外の言語はJUnit XMLで取り込みます。料金ページのFAQではGoが抜けて6言語と書かれているので、Goで使うときはドキュメント側の設定手順を正としてください。テストはCI Visibilityの連携先に関係なく、どのCIで動かしても送れます。JUnit XMLをdatadog-ci junit uploadで送る手順はdatadog-ciの導入と使い分け｜3つの配布形態とプラグイン方式・CI連携コマンドにまとめています。

GitHub ActionsでJestを計装するワークフロー例

この例は、dd-traceを追加したpackage.jsonとpackage-lock.jsonをコミットし、GitHub ActionsのシークレットDD_API_KEYを登録したリポジトリ向けです。フォークからのpull_requestでは通常このシークレットが渡らないため、同じ設定でDatadogへの送信はできません。

JavaScriptでは、dd-traceを開発依存に入れ、NODE_OPTIONSに-r dd-trace/ci/initを渡してからテストを実行します。Agentを置かないAgentlessモードでは、DD_CIVISIBILITY_AGENTLESS_ENABLED=trueの指定が必要です。DD_API_KEYを渡しただけではAgentlessモードにならない、とJavaScriptのセットアップ手順に明記されています。dd-trace v6はNode.js 22以上が前提で、対応する最低バージョンはJest 28.0.0・Vitest 1.6.0・Playwright 1.38.0です。

name: test
on: [push, pull_request]
jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - run: npm ci
      - run: npm test
        env:
          NODE_OPTIONS: -r dd-trace/ci/init
          DD_CIVISIBILITY_AGENTLESS_ENABLED: "true"
          DD_API_KEY: ${{ secrets.DD_API_KEY }}
          DD_SITE: ap1.datadoghq.com
          DD_TEST_SESSION_NAME: unit-tests

package.jsonのtestスクリプトでNODE_OPTIONSを上書きしていると、計装が外れます。メモリ上限などを足したいときは、${NODE_OPTIONS:-}を残して追記してください。Vitestの場合は--import dd-trace/register.js -r dd-trace/ci/initを指定します。Pythonはpip install -U ddtraceのあとpytest --ddtraceで実行します。

無効なAPIキーでのJest実行結果と送信エラー

上の設定を、dd-trace 6.23.0（2026年10月31日時点のnpmのlatest）・Jest 30.5.2・Node.js v26.5.0の手元環境で、無効なAPIキーのまま実行しました。テストは1 passedで終了コード0になり、通常のログには送信エラーが1行も出ません。DD_TRACE_DEBUG=trueを付けて同じ実行をすると、送信先のcitestcycle-intake.ap1.datadoghq.comが403 Forbidden（API key is missing or invalid）を返していたことがわかります。設定APIも401 Unauthorizedを返すため、Test Impact AnalysisやEarly Flake Detectionの設定も読み込まれず、テストは全件実行されます。10月3日にdd-trace 6.19.0で試したときも同じ結果でした。

つまり、CIが緑でもDatadogにデータが届いている保証はありません。導入した日に、Test Optimizationの画面に該当のテストセッションが出ているかを必ず確認してください。キーのローテーション後に送信だけが止まっていた、という事故も同じ仕組みで起こります。定期的にテストが実行される環境では、通常の実行間隔より長い評価期間を設定し、CIモニターで「テストイベントが0件」を監視すると送信停止の検知に役立ちます。コミット時だけ実行する環境では、テスト自体が実行されなかった場合との区別が必要です。

フレーキーテストへの4つの対処

Datadogは、同じコミットで成功と失敗の両方が出たテストをフレーキーと判定します。初めて検出されたものにはis_new_flaky、既知のものが失敗したときはis_known_flakyのタグが付きます。デフォルトブランチの一覧には、マージ済みfeatureブランチで出たフレーキーも含まれ、直近5,000コミットの履歴から拾われます。ただし、squashやforce pushで履歴を書き換えたブランチの検出分は追えません。

Auto Test RetriesとEarly Flake Detectionの目的と再試行回数

Auto Test Retriesは、失敗したテストケースを成功するまで、または回数の上限まで再試行します。既定の上限は5回で、DD_CIVISIBILITY_FLAKY_RETRY_COUNTで変えられます。DD_CIVISIBILITY_FLAKY_RETRY_ONLY_KNOWN_FLAKES=trueにすると、既知のフレーキーだけを再試行します（Auto Test Retries）。設定はCI/CD Optimizationの設定画面で、組織・リポジトリ・テストサービスの単位で切り替えます。

Early Flake Detectionは、Datadogが知らない新しいテストを最大10回再試行し、失敗を検出するとフレーキーの印を付けます。ただし、実行に5分を超えるテストは対象外です。また、14日を超えて実行されていないテストが新規と再判定される場合があります。マージ前にフレーキーを見つけるための機能で、PR GatesのNew Flaky Tests条件と組み合わせると、新しいフレーキーをデフォルトブランチに入れずに済みます。

Auto Test Retriesは今のビルドを落とさないための対処で、フレーキーそのものは残ります。再試行で通ったテストは、次の隔離と修正確認まで続けて扱ってください。

隔離と無効化の4状態とポリシー

Flaky Tests Managementでは、テストごとにActive・Quarantined・Disabled・Fixedの状態を切り替えられます。Quarantinedは実行を続けたまま失敗をCIの結果に反映させない状態で、Disabledは実行そのものを止めます。ポリシーでは、経過日数・発生したブランチ・直近7日の失敗率の3つを条件に、自動で隔離や無効化ができます。30日間フレークしなかったテストは原則として自動でFixedに移ります（この挙動は変更不可）。ただし、直近7日間の実行がすべて失敗しているBroken testは、自動移行の対象外です。Disabledのテストも実行されないため、自動ではFixedになりません。

隔離や無効化をテスト実行に反映するには、ネイティブ計装が必要で、JUnit XMLのアップロードだけでは利用できません。最低バージョンはJavaScriptのdd-traceで5.44.0以上、Pythonのddtraceで3.3.0以上、Javaで1.47.0以上です（Flaky Tests Management）。テストの層ごとの配分はテストピラミッドとは？単体・結合・E2Eの配分と実装者向けテスト戦略設計を参照してください。

Attempt to fixで修正を確かめる流れ

フレーキーを直したつもりでも、本当に直ったかは1回の成功ではわかりません。Attempt to fixは、画面のLink commit to Flaky Test fixで表示されるキー（例：DD_ABC123）をコミットメッセージに含めると、そのテストを20回（ポリシーで変更可）再実行して確かめる仕組みです。Disabledのテストも実行されます。

全回成功すると「修正中」として扱われ、修正ブランチがデフォルトブランチにマージされた時点でFixedに移ります。修正前のブランチでフレークが出続けて誤検知にならないよう、成功から14日間の猶予期間が設けられています。マージの検知にはGitHub・GitLab・Azure DevOpsのソースコード連携が必要です。対応するライブラリはJavaScriptで5.59.0以上、Pythonで3.8.0以上と、隔離より新しい版が求められます。

Test Impact AnalysisとTest Parallelizationによるテスト時間の短縮

Test Impact Analysisが検知できない変更

Test Impact Analysis（旧称Intelligent Test Runner）は、テストごとのカバレッジと変更ファイルを突き合わせ、影響の無いテストを飛ばす機能です。標準設定では、ライブラリ依存・コンパイラオプション・外部サービス・データ駆動テストのデータファイルの変更を検知できず、本来実行すべきテストまで飛ばすことがあります。Dockerfileやロックファイルを追跡対象（tracked files）に登録しておくと、それらが変わったときは全テストを実行します。外部システムに依存するテストには、スキップ不可（unskippable）の印を付けます。

変更の大きいコミットで全テストを走らせたいときは、コミットメッセージにITR:NoSkipと書きます。GitHubでは、プルリクエストにITR:NoSkipラベルを付けても同じ効果があります。ただしGitHub Appで「Software Delivery: Collect Pull Request Information」を有効にする必要があり、pull_requestイベントで起動したGitHub Actionsのテストには効きません。1コミットで5,000ファイルを超える変更があった場合や、1つのテストが16,000ファイルを超えて網羅している場合は、そもそもスキップの対象になりません。制限の一覧はTest Impact Analysisの公式ドキュメントにあります。Agent経由でデータを送るなら、Agent 6.40または7.40以上が必要です。

ddtestによるテストファイルのCIノードへの分割

Test Parallelizationは、Test Optimizationに蓄積した所要時間をもとに、残ったテストファイルをCIノードへ均等に割り振る機能です。Test Impact Analysisと併用すると、スキップされなかったテストを含むファイルだけが分割対象になります。件数ではなく想定時間で割るため、長いテストを抱えた1台だけが最後まで残る偏りを避けられ、必要なノード数もddtestが見積もります（Test Parallelization）。

bin/ddtest plan \
  --platform javascript \
  --framework jest \
  --min-parallelism 1 \
  --max-parallelism 8

bin/ddtest run --platform javascript --framework jest --ci-node "${CI_NODE_INDEX}"

ddtest planはテストを実行せず、分割の計画を.testoptimization/ディレクトリに書き出します。各CIジョブにこのディレクトリを渡し、CIのマトリクスなどで割り当てたノード番号を付けてddtest runを実行します。GitHub Actionsのアーティファクトで渡す場合は、include-hidden-files: trueを指定しないと隠しディレクトリが転送から漏れることがあります。ddtestはGitHub Releasesでバイナリが配布されており、2026年10月28日（UTC）にv1.14.0が公開されています。対応はRuby（RSpec・Minitest）、Python（pytest）、JavaScript（Jest・Mocha・Playwright・Vitest・Cypress・Cucumber.js）で、JavaScriptはdd-trace v6なら6.0.0以上で使えます。公式の手順は、まずplanだけを追加して既存のテストコマンドを残し、計画を確かめてからddtest runに置き換える順番を勧めています。

PR GatesとDORA Metricsへの接続

PR Gatesは、条件を満たさないプルリクエストのマージを止める機能です。条件にできるのは、Static Code Analysis（SAST）・Software Composition Analysis・Code Coverage・IaC Scanning・Secret Scanning・New Flaky Testsの6種類です。CI Visibilityのパイプライン所要時間や失敗率は含まれていません。判定結果はGitHub・GitLab・Azure DevOps・Bitbucket Cloudのソースコード連携を通じてチェックとして返ります。実際にマージを止めるには、GitHub・Azure DevOps・Bitbucket Cloudではそのチェックを必須に設定し、GitLabではDatadogのサービスアカウントをマージリクエストの必須承認者にします（PR Gatesの公式ドキュメント）。フォークから元リポジトリへのプルリクエストでは動かず、マージキューを使うGitHubリポジトリでは必須チェックにも設定できません。SASTやSCAの中身はDatadog Code Securityの記事で扱っています。

DORA Metrics（デプロイ頻度・変更のリードタイム・変更失敗率・デプロイ失敗からの復旧時間）は、デプロイイベントから計算される別の製品です。CI Visibilityを有効にしただけでは数値は出ないので、デプロイイベントのデータソースを別に設定します。DevOpsの指標全体での位置づけはDevOpsとは？アジャイル・CI/CDとの違いとDORA 5指標での成果の測り方にまとめています。

料金とコストの決まり方

課金の単位は、月に3回以上コミットしたGit作成者メールの数（アクティブコミッター）です。以下は米国サイトの定価を2026年10月31日に確認した値で、10月3日の確認時から変わっていません。コミッターの数え方はCI Visibility Billingに、最新の金額はDatadogの料金一覧で確認してください。

Pipeline Visibilityでは、パイプライン・ステージ・ジョブの1つずつが1スパン、Test Optimizationではテストの1回の実行が1スパンと数えられます。検証済みのBotによるコミットと、GitHubのUI上で直接行った操作のコミットは課金されません。同じ人が複数のメールアドレスで3回以上ずつコミットすると別人として数えられますが、GitHubのリポジトリに限り、Contents: Read付きのGitHub Appを入れておけば1人にまとめてもらえます。特定の人やパイプラインを取り込み対象から外すには、Ingestion Controlの除外フィルタを使います。

部門ごとの費用を出したいときは、CI/CD OptimizationのBilling & Committers画面でBilling enrichmentを有効にします。コミッターのメールアドレスをキーにしたリファレンステーブルを用意すると、課金メトリクスにvp_nameのような組織のタグが付き、事業部やチームごとに按分できます。Datadog全体の課金単位はDatadogの料金体系と費用が膨らむ課金単位｜抑制策を実装目線で整理で比較しています。

導入を見送るべき場面と判断基準

課金がコミッター単位なので、たとえば月に3回以上コミットする人が40人いれば、Pipeline Visibilityだけで年契約でも月320ドルかかります。Test Optimizationも入れれば、さらに月800ドルが加わります。これはコミッター分の基本料金で、実行回数やジョブ数が増えて付属スパン枠を超えると、追加スパン料金が発生します。基本料金がパイプラインの数ではなく人数で決まるため、開発者が多い割にCIが単純な組織や、CIの不調がそもそも議論になっていない組織では、費用に見合いにくくなります。GitHub Actionsだけで運用していて、知りたいのがワークフローの所要時間の推移くらいなら、まずはGitHub側の実行履歴とAPIで足りるかを試すべきです。

逆に、導入する価値が高いのは次のような組織です。複数のCIが混在していて横断的に比較したい場合、ランナーの待ち時間とジョブの処理時間を分けて見たい場合、フレーキーテストの再実行で毎週まとまった時間を失っている場合などです。最初はCI Visibilityだけを有効にして、クリティカルパスとキュー時間、Logs Analysisのplatform比率を見ます。テストが遅延や失敗の主因だとわかってから、Test Optimizationを追加し、Auto Test RetriesとTest Impact Analysisを順に有効にすると無駄がありません。CIツール自体の選び方はCI/CDツール比較｜主要11製品の無料枠・料金と選び方【2026年10月】で比較しています。パイプラインの設計やテスト自動化の進め方から相談したい場合は、DevOps・CI/CD導入支援で承っています。

よくある質問

Datadog CI Visibilityとは何ですか？

CIパイプラインの実行結果・所要時間・失敗をトレースとしてDatadogに集め、ダッシュボードやモニターで扱えるようにする製品です。テスト単位の分析はTest Optimizationが別に担当します。

CI/CD OptimizationとCI Visibilityは何が違いますか？

CI/CD Optimizationは、CI VisibilityとTest Optimizationの画面を1つにまとめた新しいUIです。料金は従来どおりPipeline VisibilityとTest Optimizationの単位で発生し、Switch Backで旧UIに戻せます。

GitHub Actionsのワークフローファイルを書き換える必要はありますか？

パイプラインの可視化だけなら不要です。GitHub AppにActions: Read Onlyを付け、Datadog側でリポジトリを有効化すれば取り込まれます。テストまで見る場合は、テストを実行するステップに言語ライブラリの環境変数を追加します。

Datadog Agentは必須ですか？

必須ではありません。GitHub ActionsとGitLabはSaaS間の連携で動き、JenkinsとTest OptimizationにはAgentを使わないモードがあります。ジョブとホストのメトリクスを結び付けたい場合は、ランナーのホストにAgentが要ります。

Google Cloud Buildに対応していますか？

標準の連携先には含まれていません。ビルドの終了時に実行結果を公開API（/api/v2/ci/pipeline）へ送る、カスタムパイプラインとして取り込みます。

関連記事

• Datadogとは？何ができるか・仕組み・料金とCloudWatch/Zabbixとの違い
• datadog-ciの導入と使い分け｜3つの配布形態とプラグイン方式・CI連携コマンド
• Datadogの料金体系と費用が膨らむ課金単位｜抑制策を実装目線で整理
• CI/CDツール比較｜主要11製品の無料枠・料金と選び方【2026年10月】
• DevOpsとは？アジャイル・CI/CDとの違いとDORA 5指標での成果の測り方