こんにちは！日々のデプロイやCI/CDのメンテ、本当にお疲れ様です。
「テストが落ちた原因が、ローカルでは再現しない……」
「水曜日のデプロイ以降、なんだか本番のレイテンシーが悪化している気がするけど、どのPRが原因なんだ？」
こんなモヤモヤを抱えた経験、ありませんか？
こんにちは、オブザーバビリティ・アーキテクトの先輩です。今日は、開発チームの命綱である GitHub Actions と、我らが最強の監視プラットフォーム Datadog を美しく連携させ、CI/CDの健康状態を完全に可視化する方法を伝授します。
これをマスターすれば、「ビルドが遅い原因」も「障害の真犯人であるプルリクエスト」も、一撃で特定できるようになりますよ。毎日の作業が劇的に楽になる世界へ、一緒に一歩を踏み出しましょう！
—
1. なぜ、GitHub ActionsとDatadogを連携させるのか？
まずは「なぜこの連携が必要なのか」という設計思想のお話をさせてください。
多くのチームは、GitHub Actionsの画面（緑や赤のチェックマーク）だけで満足しています。「あ、今日のビルドは成功したな」と。
しかし、プロダクトの規模が大きくなると、これだけでは不十分になります。
- 「なんとなくビルドが遅くなった」を数値化したい（メトリクス収集）
- 「どのデプロイが、どのバグを生んだか」をタイムラインで紐付けたい（デプロイ追跡）
Datadogと連携させることで、「コードが書かれてから（Commit）、テストされ（CI）、本番にリリースされ（CD）、ユーザーに届くまで（APM）」の全行程を一本のストーリーとして繋ぐことができるのです。これがオブザーバビリティの醍醐味です。
—
2. 基礎セットアップ：世界一シンプルな連携の第一歩
それでは、実際に手を動かしていきましょう。
今回は、最も簡単かつ強力な2つのアプローチを実装します。
1. Datadog公式のGitHub Actions（CIメトリクス収集）
2. Datadog Events APIへのデプロイ通知
ステップ 1：Datadog側でAPIキーを用意する
まずはDatadogにログインし、APIキーを取得します。
1. Datadogの画面左下のアイコン ＞ Organization Settings ＞ API Keys に移動。
2. キーを作成し、安全な場所にコピーしておきます。
ステップ 2：GitHubのSecretsに登録する
リポジトリのセキュリティを守るため、APIキーは必ずGitHubのシークレットに保存します。
1. GitHubの対象リポジトリを開く。
2. Settings ＞ Secrets and variables ＞ Actions に移動。
3. `New repository secret` をクリックし、以下を登録します。
- Name: `DATADOG_API_KEY`
- Secret: （先ほどコピーしたAPIキー）
—
3. 「HelloWorld」：CIメトリクスを収集するワークフローの作成
ここからが本番です。GitHub Actionsが実行されるたびに、その結果（成功・失敗・実行時間）をDatadogに自動送信するワークフローを作りましょう。
プロジェクトの `.github/workflows/ci.yml` を以下のように記述してください。
name: CI with Datadog Metrics
on:
push:
branches: [ “main” ]
pull_request:
branches: [ “main” ]
jobs:
build-and-test:
name: Build and Test
runs-on: ubuntu-latest
steps:
# 1. リポジトリのコードをチェックアウト
- name: Checkout Code
uses: actions/checkout@v4
# 2. ダミーのビルド・テスト工程（ここに実際の処理が入ります）
- name: Run Tests
run: |
echo “Running unit tests…”
sleep 3 # テストのつもり
# 3. 【核心】DatadogへCIパイプラインのメトリクスを送信
- name: Send Pipeline Metrics to Datadog
uses: DataDog/datadog-ci-actions@v2
with:
command: pipeline
# どの環境か、どのサービスかをタグで明確にするのがプロの技です
service: my-awesome-web-app
env: production
env:
DATADOG_API_KEY: ${{ secrets.DATADOG_API_KEY }}
# USリージョン以外の人は datadoghq.eu などに適宜変更してください
DD_SITE: “datadoghq.com”
ここがポイント：
公式のアクション `DataDog/datadog-ci-actions@v2` を使うことで、面倒なAPIリクエストの自作をしなくても、ジョブの成功/失敗や実行時間が自動的にDatadogのメトリクス（例: `ci.provider.pipeline.duration` など）として蓄積されます。
—
4. 障害切り分けの武器：「デプロイイベント」の通知
メトリクスが取れるようになったら、次は「デプロイ追跡（Deployment Tracking）」です。
「何時何分に、どのコミットが本番環境にデプロイされたか」をDatadogのタイムライン上にイベントとして記録します。これがあると、APM（アプリケーション監視）でエラーレートが跳ね上がった瞬間、「あ、3分前のあのデプロイが原因だ！」と秒速で特定できるようになります。
以下のステップを追加して、デプロイメントの足跡を残しましょう。
# 4. デプロイ成功時にDatadogへデプロイメントイベントを通知
- name: Notify Datadog of Deployment
if: success() && github.ref == ‘refs/heads/main’
uses: DataDog/datadog-ci-actions@v2
with:
command: tag
service: my-awesome-web-app
env: production
env:
DATADOG_API_KEY: ${{ secrets.DATADOG_API_KEY }}
DD_SITE: “datadoghq.com”
# コミットハッシュやバージョンを紐付けることでDatadog上でコードと完全一致させます
DD_VERSION: ${{ github.sha }}
これで、GitHub Actionsが`main`ブランチへのマージを検知してデプロイを完了した瞬間、DatadogのインフラストラクチャーやAPMのダッシュボード上に「青い縦線（デプロイマーカー）」が出現するようになります。
—
5. 動作確認：ダッシュボードを覗いてみよう！
設定が終わったら、実際に `main` ブランチへ空コミットをプッシュするか、PRを作成してGitHub Actionsを走らせてみてください。
ビルドが緑になったら、Datadogの画面を開きます。
1. CI Visibility または Events > Stream に移動します。
2. 自分が走らせたワークフローの実行時間や、成功のステータスが綺麗にグラフ化されているのを確認してください。
3. APMの画面を開けば、デプロイマーカーを起点として「デプロイ前後のエラーの増減」が一目でわかるようになっています。
この瞬間、あなたの開発パイプラインはただの「自動化スクリプト」から、「完全に見える化された信頼性の高いシステム」へと生まれ変わりました。
—
おわりに
今回は、GitHub ActionsとDatadogを連携させ、CIメトリクスの収集とデプロイ追跡の基礎をセットアップしました。
「監視は、障害が起きてから慌てて見るものじゃない。開発のプロセスそのものに組み込むものだ」
これが、現場を渡り歩いてきた私の確信です。
この連携を導入したその日から、チームの心理的安全性はグッと上がります。「何が起きているか分からない」という恐怖から解放されるからです。
まずは小さなリポジトリからでも構いません。ぜひ今日、あなたのパイプラインにこの魔法をかけてみてください。あなたのエンジニアリングライフが、より快適でエキサイティングなものになることを心から応援しています！