【Github】2025/9新機能 CHECK_RUN_IDをAction上で取得する
こんにちは。
2025/9新機能では、Actions上で「check_run_id」を簡単に参照できるようになりました。
「check_run_id」とは、Actions上で構成されるジョブ単位・実行単位の一意キーとなります。
従来「check_run_id」を取得するためには、Gituhb APIを使用する必要がありましたが、2025/9の新機能で、Actions内で簡単に取得できるようになりました。
今回は、「check_run_id」の取得方法や、Actions全体の構成と絡めた概念の復習をしていきます。
2025/9新機能「check_run_id」取得方法
2025/9リリースにより、Actions内にて「job.check_run_id」と参照することで、直接取得できるようになりました。
従来はAPI経由で取得する必要があった「check_run_id」ですが、Actions内で完結できるようになりました。
参考ドキュメント：Identify running jobs with job check run ID in GitHub Actions contexts - Github Docs
ソースコード
Actionsから新規Workflow作成を行い、yamlファイルにサンプルコードを書き込みます。
name: check_run_id-test
on: #Githubにpushされた、または手動で発動する
push:
workflow_dispatch:
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Run tests
run: echo "テストを実行中..."
- name: Show check_run_id
run: |
echo "このジョブの check_run_id は ${{ job.check_run_id }} です"
- name: Send notify
run: |
# ここでは外部通知サービスに check_run_id を送る例を示しています
# 実際の送信先URLはまだ決まっていないためコメントアウトしています
#
# curl -X POST -H "Content-Type: application/json" \
# -d '{"check_run_id": "${{ job.check_run_id }}", "status": "completed"}' \
# https://example.com/notify
#
echo "通知を送信しました（check_run_id=${{ job.check_run_id }}）"
実行結果
Actionsの該当Workflow・Jobを選択し、実行ログを確認します。
実行ログの中に、Echo文で記載された「check_run_id」情報が格納されていることが確認できました。
こちらの「check_run_id」を、運用監視目的で社内システムに送信するのもアリです。
【復習】「check_run_id」とは
「check_run_id」は、Jobの実行ごとに付与される一意の識別子キーとなります。
どのジョブのいつ実行されたログなのかを特定できます。
間違えがちな他ID系との比較
本ブログで紹介している「check_run_id」には、類似したID系の情報があります。
混合防止を兼ねて、いくつか紹介していきます。
| ID | 単位 | 説明 |
|---|---|---|
| check_run_id | Job・実行ごと | 各ジョブ・実行単位ごとの一意のID |
| run_id | Workflow 実行ごと | ワークフロー全体の実行を識別するID |
| job_id | Job ごと（固定） | ジョブ識別ID ※実行ごとの識別には使えない |
参照ドキュメント：コンテキスト リファレンス - Github Docs
Actionsの構造と「check_run_id」との関係
Actionsの構造は以下の通りです。
on（トリガー）で発火し、
→ run（Workflow全体の実行）で起動し、
→ Jobs（Workflow内の複数処理）が進行され、
→ Steps（Job内の細かな処理）が実行される。
Actions構造図は下記のとおりです。
「check_run_id」はJOBに紐づけられます。
Workflow (YAML全体)
├── on: # ★ 実行トリガー定義（push, pull_request, workflow_dispatch など）
│
├── run: # ★ 実行（Run）単位の情報
│ ├── github.run_id # 各Workflow実行ごとの一意ID
│
├── jobs: # ★ ジョブ単位の定義
│ │
│ ├── job_1 # jobのID（YAMLキー名そのもの）
│ │ ├── job.check_run_id # 各ジョブ実行ごとの一意ID
│ │ ├── job.status # 実行結果（success / failure / cancelled）
│ │ └── steps: # ★ ステップ単位の定義
│ │ ├── step_1 # stepのID
│ │ └── step_2 # stepのID
│ │
│ └── job_2 # 別ジョブ
│
└── env: # 任意設定（共通の環境変数など）
おわりに
2025/9新機能「check_run_id」のActions内の取得方法の紹介をしました。
従来のAPI経由での取得方法から、非常に簡略化されました。
また、Actions内のID系データは、いざというときにトラブル原因究明に繋がります。
定期的に社内システム上に保持しておくのもアリかと思います。
それでは。
Tags