GitHub Actions の workflow yml は、見た目は短いですが役割がはっきりしています。
この記事では「いつ動かすか」「どんな環境で動かすか」「Secrets をどう渡すか」「最後に何を実行するか」に分けて見ていきます。
目次
今回見る yml
name: Scheduled Scraper
on:
schedule:
- cron: "0 * * * *"
workflow_dispatch:
jobs:
scrape:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.11"
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run scraper
env:
GOOGLE_CLIENT_ID: ${{ secrets.GOOGLE_CLIENT_ID }}
GOOGLE_CLIENT_SECRET: ${{ secrets.GOOGLE_CLIENT_SECRET }}
GOOGLE_REFRESH_TOKEN: ${{ secrets.GOOGLE_REFRESH_TOKEN }}
GOOGLE_DRIVE_FOLDER_ID: ${{ secrets.GOOGLE_DRIVE_FOLDER_ID }}
run: python main.py
見た目は短いですが、それぞれ意味があります。
on: は実行タイミングを決める
on:
schedule:
- cron: "0 * * * *"
workflow_dispatch:
ここでは、ワークフローを「定期実行」するか、「手動実行」するかを決めています。
schedule: cron 形式で自動実行workflow_dispatch: GitHub の画面から手動実行
最初のうちは workflow_dispatch を入れておくのがおすすめです。
定期実行だけにすると、設定した時間まで実行されずデバッグが遅々として進みません。
runs-on は実行環境を決める
runs-on: ubuntu-latest
これは GitHub が用意している Linux 環境で動かす、という意味です。
Python のスクレイピング用途なら、まずはこれで十分です。
特別な理由がない限り、最初は ubuntu-latest で問題ありません。
actions/checkout はリポジトリを取得する
uses: actions/checkout@v4
これは実行対象のリポジトリをランナー上に展開するステップです。
これがないと、main.py も requirements.txt も見つかりません。
actions/setup-python で Python を入れる
- uses: actions/setup-python@v5
with:
python-version: "3.11"
ここでは Python のバージョンを指定しています。
ローカルと Actions で Python のバージョンがズレると、ライブラリや構文で事故ることがあります。
自分の開発環境とそろえておくのが基本です。
依存ライブラリをインストールする
- name: Install dependencies
run: pip install -r requirements.txt
ここでは requirements.txt に書いたライブラリを一括で入れています。
たとえば今回のような構成なら、次のようなライブラリが入ります。
requestspandaslxmlgoogle-api-python-clientgoogle-auth
このステップがあることで、毎回クリーンな GitHub Actions 環境でも同じ依存関係を再現できます。
GitHubの画面でSecretsを登録する
yml にSecretsの参照を書く前に、GitHub側に値を登録しておきます。ここでは、上のサンプルで使う4つの値を Repository secrets に登録します。
掲載画面は2026年4月に撮影したものです。アカウント名・リポジトリ名・URL・プロフィール画像などが写る範囲は切り取り、認証情報やフォルダIDの実際の値は掲載していません。
1. SettingsからActionsのSecretsを開く
対象リポジトリの Settings を開き、左側の Secrets and variables → Actions を選びます。リポジトリ上部にもActionsタブがありますが、Secretsの登録先はSettings内です。
2. New repository secretを選ぶ
Secrets タブの Repository secrets にある New repository secret を押します。上にあるEnvironment secretsとは登録先が異なるので、今回はRepository secretsを使います。
この画面では、Google認証用の3件がすでに登録されています。続いて GOOGLE_DRIVE_FOLDER_ID を追加する例で説明します。初めて設定する場合は、次の4件を1件ずつ登録します。
| Nameに入れる名前 | Secretに入れる値 |
|---|---|
GOOGLE_CLIENT_ID |
使用するOAuthクライアントのクライアントID |
GOOGLE_CLIENT_SECRET |
そのOAuthクライアントのクライアントシークレット |
GOOGLE_REFRESH_TOKEN |
Googleへの認証で取得したリフレッシュトークン |
GOOGLE_DRIVE_FOLDER_ID |
保存先のGoogle DriveフォルダID |
これらの名前は、この記事のサンプルに合わせたものです。GitHubが自動で値を発行するわけではないので、Google側で準備した値を登録します。
値の取得から始める場合は、Google Drive APIのOAuth設定で、クライアント作成とリフレッシュトークンの準備を説明しています。
3. NameとSecretを入力して保存する
Name は yml から参照するための名前、Secret は保存する実際の値です。たとえばNameに GOOGLE_DRIVE_FOLDER_ID、Secretに保存先のフォルダIDを入力し、Add secret を押します。
画像のSecret欄は未入力です。実際に保存するときは自分の値を入力してください。登録後は一覧に戻り、必要な4つの名前がそろっていることを確認します。
操作の詳細はGitHub公式ドキュメント「GitHub Actionsでのシークレットの使用」でも確認できます。
env: で Secrets を Python に渡す
env:
GOOGLE_CLIENT_ID: ${{ secrets.GOOGLE_CLIENT_ID }}
GOOGLE_CLIENT_SECRET: ${{ secrets.GOOGLE_CLIENT_SECRET }}
GOOGLE_REFRESH_TOKEN: ${{ secrets.GOOGLE_REFRESH_TOKEN }}
GOOGLE_DRIVE_FOLDER_ID: ${{ secrets.GOOGLE_DRIVE_FOLDER_ID }}
ここはかなり大事です。
GitHub Actions では、リポジトリに登録した Secrets を env: 経由で実行プロセスに渡せます。
Python 側では os.environ["..."] で受け取ります。
つまり、yml と Python の役割分担はこうです。
yml: Secrets を安全に渡す- Python: 環境変数として受け取って使う
たとえば GOOGLE_CLIENT_ID の行では、左側がPythonに渡す環境変数名、右側の secrets.GOOGLE_CLIENT_ID がGitHubに登録したSecretの参照です。上で登録したNameと、secrets. の後ろの名前をそろえます。
Secretが未登録だったり、参照する名前を間違えたりすると、その参照は空文字列になります。認証エラーが出たら、まず登録先のリポジトリと名前の対応を確認します。
この構造なら、認証情報の値を yml やPythonのソースコードに直接書かずに済みます。ただし、確認のために print() や echo で値を出力しないようにします。実行ログやスクリーンショットにも認証情報を残さないことが大切です。
最後に python main.py を実行する
run: python main.py
ここでやっと本体を動かします。
大事なのは、workflow yml に細かいロジックを書きすぎないことです。
ロジックは Python 側に寄せて、yml は「どういう環境で」「いつ」「何を実行するか」だけを書くようにした方が管理しやすいです。
yml でやりすぎないほうがいい理由
設定ファイルに分岐や変換ロジックを寄せすぎると、次のような問題が起きやすくなります。
- 動作確認がしづらい
- 途中失敗したときの切り分けがしづらい
- ローカル実行との差分が大きくなる
- 記事化しづらくなる
yml は実行基盤の説明書、Python は処理本体、と役割を切り分けておくと保守しやすくなります。
まとめ
GitHub Actions の workflow yml は、見た目よりずっと役割が明確です。
yml では実行条件と環境づくりに専念して、実際の処理は Python に寄せておくと、壊れにくく読みやすい構成になります。