変更要約: GH-200 第1章を新規作成（トリガーとイベント＝push/pull_request/schedule/workflow_dispatch/repository_dispatch/workflow_call・inputs/secrets、ワークフロー構造＝jobs/steps/needs/if・env/$GITHUB_ENV・サービスコンテナ・strategy.matrix・コンテキスト/${{ }}式・YAMLアンカー、実行管理＝アーティファクト/$GITHUB_OUTPUT/キャッシュ/$GITHUB_STEP_SUMMARY/バッジ/環境保護/retention REST API）
1.3実行結果の管理 — キャッシュ・アーティファクト・出力・ジョブサマリー
ジョブ間・ステップ間でデータを受け渡す方法（アーティファクト、$GITHUB_OUTPUT、$GITHUB_ENV、再利用可能ワークフローの outputs）、依存のキャッシュ、$GITHUB_STEP_SUMMARY による Markdown のジョブサマリー、ステータスバッジ、環境（environment）の保護、そして REST API によるログ・アーティファクト・実行の保持（retention）管理を理解します。
第2節で見たとおりジョブは独立環境で動くため、結果を明示的に受け渡す仕組みが要ります。GH-200 では、用途に応じて 3 つの経路を使い分けます——ファイル/成果物を渡す アーティファクト、短い値をステップ/ジョブ間で渡す $GITHUB_OUTPUT（と環境変数の $GITHUB_ENV）、そして再利用可能ワークフローが呼び出し側へ返す outputs です。さらに、ビルドを速くする キャッシュ、結果を見やすく示す ジョブサマリー、状態を可視化する ステータスバッジ を組み合わせます。
1.3.1アーティファクト — ファイル/成果物の受け渡し
ビルド成果物・テストレポート・ログなどファイルを後続ジョブや実行後のダウンロードに残すには、actions/upload-artifact でアップロードし、actions/download-artifact で取得します。アーティファクトは実行（run）に紐づいて保存され、既定の 保持期間（retention） を過ぎると自動削除されます（リポジトリ/組織の設定や upload 時の retention-days で調整）。ジョブ間でファイルを渡す典型手段がこれで、後続ジョブは依存（needs）の後でダウンロードして使います。
1.3.2値の受け渡し — $GITHUB_OUTPUT とジョブ outputs
短い値（バージョン番号・判定結果など）を渡すには、ステップで echo "name=value" >> "$GITHUB_OUTPUT" と書いて ステップ出力 を作り、同じジョブ内では steps.<id>.outputs.<name> で参照します。別ジョブへ渡すには、ジョブの outputs: マップにステップ出力を割り当て、後続ジョブが needs.<job>.outputs.<name> で読みます。アーティファクトが「ファイル向け」なのに対し、こちらは「小さな値向け」と覚えると選択を誤りません。再利用可能ワークフローも同様に outputs を定義して呼び出し側へ結果を返します。
| 渡したいもの | 手段 | 参照方法 |
|---|---|---|
| ファイル/成果物 | アーティファクト（upload/download） | download-artifact（needs 後） |
| 短い値（同一ジョブ内） | $GITHUB_OUTPUT | steps.<id>.outputs.<name> |
| 短い値（別ジョブへ） | ジョブ outputs | needs.<job>.outputs.<name> |
| 環境変数（後続ステップ） | $GITHUB_ENV | env.<NAME> / $NAME |
1.3.3キャッシュで高速化
依存パッケージ（npm・pip・Maven など）の再ダウンロードは時間とコストの無駄です。actions/cache は、ロックファイルのハッシュなどから作った キー で依存ディレクトリを保存・復元し、次回以降のジョブを高速化します。完全一致がなくても restore-keys で部分一致の古いキャッシュを復元できます。キャッシュ（再現できる中間生成物）とアーティファクト（残したい成果物）は目的が違う点に注意——キャッシュはあくまで高速化のためで、消えても再生成できるものに使います。
1.3.4ジョブサマリーとステータスバッジ
実行結果を分かりやすく見せるには、$GITHUB_STEP_SUMMARY に Markdown を追記します——テスト結果の表・カバレッジ・関連リンクなどを書くと、実行ページに リッチなジョブサマリー として表示されます。リポジトリ全体の状態は ステータスバッジ（README に貼る SVG バッジ）で可視化でき、特定ブランチ/イベントの最新結果（成功/失敗）を一目で示せます。
1.3.5環境（environment）の保護と保持期間（retention）
デプロイ先などを表す 環境（environment） には 保護ルール を設定できます——必須レビュアー（required reviewers） による承認待ち、待機タイマー、デプロイを許可する ブランチの制限、そして環境スコープのシークレット/変数です。これにより「本番デプロイは承認後のみ」を強制できます。運用面では、ログ・アーティファクト・ワークフロー実行の 保持期間（retention） をリポジトリ/組織レベルで設定し、不要になった古いデータを自動削除します。これらの保持設定や成果物の取得・削除は REST API からも操作でき、棚卸しやコンプライアンス対応を自動化できます。
頻出：
①ファイルをジョブ間で渡す＝アーティファクト（upload/download-artifact）。
②短い値＝$GITHUB_OUTPUT→steps/needs.<job>.outputs。
③環境変数を後続へ＝$GITHUB_ENV。
④依存の高速化＝actions/cache（key＋restore-keys）。
⑤リッチな実行サマリー＝$GITHUB_STEP_SUMMARY（Markdown）。
⑥本番デプロイを承認制に＝environment の required reviewers／wait timer／branch 制限。
⑦保持期間（retention）と成果物は REST API で管理可能。
混同・注意：
①アーティファクト（残す成果物）とキャッシュ（高速化用の再生成可能データ）は別物——テストレポートはアーティファクト、node_modules はキャッシュ。
②$GITHUB_OUTPUT（値）と upload-artifact（ファイル）を取り違えない。
③環境（environment）の保護とブランチ保護ルールは別レイヤー。
④保持期間を過ぎたアーティファクトは消える——長期保管が要るものは外部ストレージへ。
⑤set-output 等の古いコマンドは非推奨——$GITHUB_OUTPUT を使う。
1.3.6この節のまとめ
- ファイルはアーティファクト（upload/download-artifact）、短い値は $GITHUB_OUTPUT→steps/needs.<job>.outputs、環境変数は $GITHUB_ENV
- actions/cache（key＋restore-keys）で依存を高速化。キャッシュ≠アーティファクト
- $GITHUB_STEP_SUMMARY で Markdown のジョブサマリー、README にステータスバッジ
- environment の保護（必須レビュアー/待機/ブランチ制限）で承認制デプロイ。retention と成果物は REST API で管理
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ビルドジョブが生成した実行ファイルを、後続のデプロイジョブで使いたいです。ジョブ間でファイルを渡す標準的な方法はどれですか？
Q2. あるジョブで計算したバージョン文字列を、別のジョブで参照したいです。最も適した方法はどれですか？
Q3. 毎回 npm の依存を再ダウンロードしてビルドが遅いです。再現可能な依存を保存・復元して高速化する仕組みはどれですか？
Q4. 本番（production）環境へのデプロイを、特定の担当者の承認後にだけ実行するよう強制したいです。どこで設定しますか？
Q5. テスト結果の表とカバレッジを、実行ページに見やすく表示したいです。どこに書き込みますか？
Q6. 古いアーティファクトやログを自動削除し、棚卸しを自動化したいです。これらの保持期間（retention）や成果物の管理に使えるのはどれですか？