変更要約: 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.1ワークフローのトリガーとイベント
ワークフローを「いつ・何をきっかけに」実行するかを設計します。スケジュール・手動（workflow_dispatch）・Webhook・リポジトリイベントの使い分け、workflow_dispatch の入力定義、再利用可能ワークフロー（workflow_call）への入力とシークレットの受け渡し、そしてイベントに応じた適切なスコープと権限の選択を理解します。
GitHub Actions のワークフローは、リポジトリの .github/workflows/ 配下に置く YAML ファイル です。その先頭で必ず on: キーを使い、「何が起きたらこのワークフローを動かすか」＝ トリガー（イベント） を宣言します。GH-200 ではまず、イベントの種類を正しく選び分ける力が問われます。代表的なのは、コードの変更で動く push と pull_request、定期実行の schedule、人が手で起動する workflow_dispatch、他リポジトリ/外部から API で起動する repository_dispatch、そして Issue・リリース・ラベルなど多数の リポジトリイベント です。
1.1.1イベントの種類と使い分け
push と pull_request は CI の中心で、branches・paths などのフィルターで「どのブランチ・どのファイル変更で動かすか」を絞り込めます（paths-ignore・branches-ignore で除外も可能）。schedule は cron 式（UTC 基準）で定期実行します——夜間のテストや依存関係チェックに使いますが、最短間隔や混雑時の遅延・リポジトリが非アクティブだと停止する点に注意します。workflow_dispatch は GitHub の UI／API／CLI から手動起動でき、運用タスク（デプロイ・データ移行など）に向きます。repository_dispatch は外部システムからの Webhook 的なトリガー で、カスタムイベント名を付けて API（POST）で起動します。
| イベント | 起動のきっかけ | 典型用途 |
|---|---|---|
| push / pull_request | コードの push・PR の作成/更新 | CI（ビルド・テスト・Lint） |
| schedule | cron 式（UTC） | 夜間テスト・定期チェック |
| workflow_dispatch | UI/API/CLI からの手動起動 | デプロイ・運用タスク |
| repository_dispatch | 外部 API（POST）＋カスタムイベント名 | 外部システム連携 |
| workflow_call | 別ワークフローからの呼び出し | 再利用可能ワークフロー |
1.1.2workflow_dispatch の入力
workflow_dispatch は手動起動時にパラメーターを受け取れます。inputs の下に各入力を定義し、type（string・boolean・choice・number・environment）、required（必須かどうか）、default（既定値）、choice の場合は options を指定します。受け取った値はワークフロー内で inputs.<名前> コンテキストや、github.event.inputs.<名前> で参照します。これにより、たとえば「デプロイ先環境を選んで起動する」運用ワークフローを安全に作れます。入力は 検証（型・必須・選択肢）されるため、不正値の混入を防げます。
1.1.3再利用可能ワークフロー（workflow_call）と入力・シークレット
同じ処理を複数のワークフローで使い回すには、on: workflow_call を宣言した 再利用可能ワークフロー にします。呼び出し側は uses: でそのワークフロー（owner/repo/.github/workflows/file.yml@ref）を参照し、with: で入力を、secrets: でシークレットを渡します。シークレットは個別に渡すほか、secrets: inherit で呼び出し側の全シークレットを継承させることもできます。再利用可能ワークフローは outputs を定義して結果を呼び出し側に返せます。これにより「ビルド」「デプロイ」などの共通ロジックを 一箇所で集中管理（バージョン管理） でき、組織全体で標準化できます。
1.1.4スコープ・権限・GITHUB_TOKEN
イベントを選んだら、そのワークフローに与える 権限（permissions） も適切に絞ります。各実行には自動で GITHUB_TOKEN という一時的な資格情報が発行され、リポジトリへの読み書きに使われます。permissions: キーで contents: read のように 最小権限 に設定するのが安全な既定です（書き込みが要るジョブだけ昇格させる）。とくに pull_request を フォークからの PR で動かす場合、外部の貢献者のコードが走るため、書き込み権限やシークレットの露出を避ける設計（pull_request_target の扱いに注意）が重要です。
頻出：
①「手動で起動＋パラメーターを受け取る」＝workflow_dispatch（inputs に type/required/default/options）。
②「定期実行」＝schedule（cron・UTC）。
③「外部 API から起動」＝repository_dispatch。
④「共通ロジックを別ワークフローから呼ぶ」＝workflow_call（reusable workflow）で with: 入力・secrets: 渡し（inherit 可）。
⑤権限は permissions で最小権限、各実行の資格情報は GITHUB_TOKEN。
混同・注意：
①schedule の cron は UTC 基準——ローカル時刻で書くとズレる。最短間隔や遅延もあるため「正確な定時起動」を保証しない。
②workflow_dispatch（手動）と repository_dispatch（外部 API）は別物。
③再利用可能ワークフロー（workflow_call）と スターターワークフロー（雛形をコピー）と コンポジットアクション（ステップをまとめたアクション）は別概念（第2・3章）。
④フォーク PR で機密を扱うと露出リスク——pull_request と pull_request_target の違いに注意。
1.1.5この節のまとめ
on:でトリガーを宣言：push/pull_request（branches/paths で絞る）・schedule（cron・UTC）・workflow_dispatch（手動）・repository_dispatch（外部 API）- workflow_dispatch の inputs：type/required/default/options を定義し inputs.<名前> で参照
- 再利用可能ワークフロー：on: workflow_call＋呼び出し側 uses:／with: 入力／secrets:（inherit 可）／outputs
- 権限は permissions で最小権限、各実行の一時資格情報は GITHUB_TOKEN。フォーク PR の露出に注意
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 運用担当者が GitHub の UI からボタンで起動し、起動時に「デプロイ先環境」を選べるワークフローを作りたいです。どのトリガーを使いますか？
Q2. cron 式で毎晩テストを回す schedule トリガーについて、正しい注意点はどれですか？
Q3. 「ビルド」ロジックを複数リポジトリのワークフローから呼び出して一元管理したいです。呼び出される側のワークフローに宣言するイベントはどれですか？
Q4. 再利用可能ワークフローに、呼び出し側が持つすべてのシークレットをまとめて渡す書き方はどれですか？
Q5. セキュリティレビューで「ワークフローの GITHUB_TOKEN を最小権限にせよ」と指摘されました。適切な対応はどれですか？
Q6. 外部の CI 連携システムが、独自のイベント名を付けて API（POST）で GitHub のワークフローを起動します。対応するトリガーはどれですか？