注 Actions タブの履歴は反映に数秒〜十数秒かかることがあります。更新直後は少し待ってから確認してください。
この記事でできるようになること
- GitHub Actions が「自動で動くお手伝いロボ」だとイメージできる
- ワークフロー (workflow) / ジョブ (job) / ステップ (step) の意味をざっくり説明できる
- Actions タブを開いて動きを見ることができる
1. そもそも何が困るの？
コードを直したり、追加したりするとき、毎回こんな手作業をしていませんか？
- テストコマンドを打つ
- 変なミスがないかチェック
- 何か終わったらチームに知らせる
人が毎回やると「忘れる」「ミスる」「時間がかかる」が起きがちです。ここを自動でやってくれるのが GitHub Actions です。
2. GitHub Actions はなに？
GitHub が用意している「自動で動く仕組み」です。決まった書き方のファイル (YAMLファイル) をリポジトリの .github/workflows/ フォルダに置くと、
- コードを push したとき
- ボタンを押したとき（手動実行）
- 決まった時間（後の回で学ぶ）
などを合図に、クラウド上のコンテナや仮想マシンでコマンドが動きます。
この設定ファイルを「workflow（ワークフロー：自動の台本）」と呼びます。
| 用語 | 意味 | ひとこと |
|---|---|---|
| workflow | 自動の台本（トリガで動く） | 台本 |
| job | 同一環境で順次動くまとまり | 章 |
| step | 小さな作業単位 | カット |
3. 手作業 vs 自動フロー（イメージ）
ポイント: 自動化で「抜け」「順番ミス」「忘れ」を防ぎ、気持ちをより本質的な作業に向けられるようにする。
図の説明: この図は、手作業の開発フローと GitHub Actions による自動フローを並べて比較しています。左側は人手で「変更→テスト→デプロイ→通知」を進める様子で、ヒューマンエラー（抜け漏れ・順番ミス・通知忘れ）やムラが起きやすい状態を示しています。右側は GitHub Actions での自動化で、トリガ（push / PR / スケジュール）を合図に「自動フロー（workflow→job→steps）」が毎回同じ手順で実行され、最後に通知まで届くイメージです。工程は大きな箱でまとめて表示しており、実際の中身は steps（lint / test / deploy など）としてログに可視化され、再現性と安定性が高まります。
導入の効果（要点）:
- 失敗の早期検知（fail-fast）で無駄な作業を減らす
- 平均リードタイムの短縮（毎回のテスト・デプロイが自動実行）
- ログの可視化と再現性の向上（workflow / job / steps が記録される）
- ヒューマンエラーの低減と通知の確実化（Slack / メール等）
まずは最小で始める指針:
- 最小の workflow（YAML）で「一度きちんと成功」を体験する
- Marketplace のアクションは
@v3/@v4などバージョンを固定 - 機密値は Secrets に置き、
env:へ直書きしない - ステップは lint → test → deploy の順で小さく積む（詳細は本記事後半と次回）
4. Actions 画面を見てみよう
GitHub のリポジトリ上部のタブに「Actions」があります。ここを開くと、過去に動いたワークフローの一覧が並び、緑（成功）や赤（失敗）のバッジが見えます。
[図2 挿入予定]
- Alt: "Actions タブでワークフローの履歴が一覧で表示されている画面"
- キャプション案: 図2: ワークフロー履歴と結果（緑=成功 / 赤=失敗）
5. まず“形”を知る：最小の例
これが、とても小さいワークフローの例です。
# .github/workflows/example.yml
name: example-workflow
on: [push]
jobs:
hello_job:
runs-on: ubuntu-latest
steps:
- run: echo "Hello, GitHub Actions!"意味をざっくり：
- name: 画面での表示名
- on: [push] → コードを push したら動く
- jobs: ここにジョブ（章）を並べる
- hello_job: ジョブの内部名
- runs-on: どの環境（ここでは Ubuntu）で動かすか
- steps: 1行1行がステップ（小さな作業）
- run: 実際に走るコマンド
用語の短い覚え方：
- workflow = 自動の台本
- job = 台本の章（1つの仮想マシンで順に実行）
- step = 小さな作業の行
（用語の詳説は後続回または付録の用語集で扱います）
ヒント Marketplace のアクションは
@v4などバージョンを固定して使うのが無難です。急な破壊的変更の影響を避けられます。
6. ほんの少し先の見通し
このあと：
- 第2回: 最小ワークフローを書いて動かし、ログを読む
- 第3回: テストや “ひみつの値 (secrets)” を使う
- 第4回: 複数バージョンを同時に試す (matrix) / 順番制御 (needs)
- 第5回: 時間で動かす (cron) / 通知 / 権限の安全設定
ここでは “secrets” や “matrix” という言葉をチラ見せだけ。今覚えなくてOKです。
7. ミニ課題（手を動かそう）
ここまでOK チェック:
- リポジトリに
.github/workflows/フォルダを作る（なければ） example.ymlを作り上の内容を貼る- なにか小さい変更を commit & push → Actions タブで実行されたか見る
余裕があれば:
echoのメッセージを別の文に変えて再度 push- Actions タブで新しい実行が追加されたか / 出力が変わったか確認
8. つまづきやすいポイント Q&A
Q. フォルダ名を間違えたら？ → .github/workflows 以外に置くと反応しません。 Q. いつ動いたかわからない → コミット後 数秒～十数秒待つ。履歴は自動反映。 Q. 失敗したらこわい？ → この例は echo だけ。壊れるものはありません。
注意 公開リポジトリで機密値（パスワードや鍵）を
env:直書きしないでください。必要な値は Secrets に登録し、参照で扱いましょう。
9. ちょっとした安全の種あかし（軽く触れる）
次回以降で詳しくやりますが、誰かが作った Action（部品）を使うときは @v3 などバージョンをつけます。これで急な変更の影響を減らせます。今は「固定する」という習慣がある、と覚えておけばOKです。
10. まとめ
- GitHub Actions は “決まった合図で自動で動く台本” を書く仕組み
- まずは形を真似して 1つ成功させるのが最優先
- 小さく動いたら、次は中を増やしていけばよい
次回: 実際にログの読み方や、少し長い例で“失敗” も見てみます。
(終) 第1回
出典
- 公式ドキュメント: https://docs.github.com/actions
- 概要（Understanding GitHub Actions）: https://docs.github.com/actions/learn-github-actions/understanding-github-actions