2.1実行結果の解釈とトラブルシュート

ワークフローを「消費する」側——つまり既存のパイプラインを使い、結果を読み、失敗を直す——のも GH-200 の重要な領域です。実行（run）ページでは、その実行を起こした トリガー（イベント）、コミット/PR、対象ブランチ、各ジョブとステップの 状態（成功/失敗/スキップ/キャンセル） が確認できます。トラブルシュートの第一歩は、「設定（YAML）が何を意図し、ログで実際に何が起きたか」を突き合わせることです。

2.1.1失敗の診断 — ログと実行履歴

失敗したジョブは、実行ページで該当ステップを展開するとログを確認できます。エラーは アノテーション として要約表示され、行レベルで原因へジャンプできます。実行履歴 を見ると「同じワークフローが以前は成功していたか／いつから失敗し始めたか」が分かり、原因（コード変更・依存更新・ランナーイメージの更新など）の切り分けに役立ちます。詳細が足りない場合は、リポジトリ/組織のシークレットに ACTIONS_STEP_DEBUG を設定して デバッグログ を有効化します。ログは保持期間内であれば後から参照・ダウンロードできます。

2.1.2YAML アンカー/エイリアスの展開

他人が書いたワークフローを読むと、アンカー（&）とエイリアス（*）、マージキー（<<）で断片を再利用していることがあります。これらは YAML パーサーが展開してから評価されるため、解析時には「アンカーで定義された値がどこに展開されるか」を頭の中で（または整形ツールで）展開して読む必要があります。アンカー/エイリアスは 単一ファイル内の再利用 であり、別ファイルのワークフローには波及しない点を踏まえて読み解きます。

2.1.3matrix 展開の読み取りと個別再実行

matrix を使うジョブは、組み合わせごとに job (ubuntu-latest, 20) のような名前で並列に現れます。失敗時は、どの 軸（OS・バージョン等） の組み合わせで落ちたかをジョブ名から特定し、ログで原因を見ます。すべて再実行する必要はなく、失敗したジョブだけを再実行（Re-run failed jobs） できます——逆に全体を Re-run all jobs すると同じ GITHUB_RUN_ATTEMPT のもとで再試行されます。「特定バリアントだけ落ちる」場合は、その環境固有の問題（依存・パス・OS 差）を疑います。

2.1.4ログとアーティファクトの取得（UI と API）

ログとアーティファクトは、実行ページの UI から直接ダウンロードできるほか、REST API（や gh CLI）からも一覧・取得・削除できます。CI/CD の自動化や監査では、API で「ある実行のログを取得」「アーティファクトを一覧して取得」「不要な成果物を削除」といった操作をスクリプト化します。アーティファクトは 保持期間 を過ぎると消えるため、長期保管が必要なら期限内に取得して外部へ退避します。

2.1.5この節のまとめ

• 実行ページでトリガー・状態を確認し、ステップログ＋アノテーション＋実行履歴で失敗を診断（詳細は ACTIONS_STEP_DEBUG）
• YAML アンカー/エイリアスは展開してから読む（単一ファイル内の再利用）
• matrix 失敗はジョブ名（軸）で特定し、Re-run failed jobs で個別再実行
• ログ/アーティファクトは UI と REST API/gh CLI で取得・削除、retention 後は消える