GitHub Actionsで業務スクリプトを安全に無人運用する方法｜二重実行・秘密漏えい・誤配信を防ぐ実践設計

「毎朝CSVを集計している」「定期的に記事を公開している」「ポイントや売上データを手作業で確認している」。こうした業務をPythonなどで自動化しても、自分のパソコン上でしか動かなければ、電源停止や環境差によって簡単に止まります。

そこで役立つのがGitHub Actionsです。決められた時刻やコード更新をきっかけに、業務スクリプトをGitHub側の実行環境で動かせます。たとえば、毎朝9時に売上データを取得し、集計結果を保存して、異常があれば通知する処理を、人間がパソコンを開かずに実行できます。

ただし、スクリプトを定期実行できる状態と、安全に無人運用できる状態は同じではありません。

• 二重実行により同じ顧客へメールを2回送る
• APIキーがログへ出力される
• 空の記事や壊れたCSVが公開される
• タイムアウト後の再実行で売上を重複計上する
• 自動化の利用料が成果額を上回る

こうした事故は、収益につながる自動化資産を一度で壊します。

この記事では、GitHub Actionsを使った業務自動化を、次の状態へ近づける方法を解説します。

• 失敗しても既存データを壊さない
• 同じ処理が重複して実行されない
• 秘密情報をコードやログに残さない
• テストに合格した成果物だけを公開する
• 人間が常時監視しなくても異常を発見できる
• 自動生成した記事や集計結果を収益導線へ継続的につなげる

目指すのは「一度も壊れない魔法の自動化」ではありません。壊れても影響を限定し、自動停止し、原因を追跡して安全に再開できる仕組みです。

GitHub ActionsとCIの全体像

GitHub Actionsは、リポジトリ内のYAMLファイルに実行条件と処理内容を書き、GitHub側の実行環境でワークフローを動かす機能です。

**CI（継続的インテグレーション）**とは、コードを変更するたびにテストやビルドを自動実行し、不具合を早い段階で発見する仕組みです。PythonスクリプトをGitHubへpushした直後に、構文チェック、単体テスト、サイト生成まで確認する流れがCIに当たります。

GitHub Actionsの構造は、次の4階層で考えると理解しやすくなります。

1. Event：実行のきっかけ
   例：mainブランチへのpush、定期実行、管理画面からの手動実行

2. Workflow：一連の自動処理
   例：データ取得から集計、検証、公開までの全工程

3. Job：役割ごとに分けた処理単位
   例：テスト用ジョブと本番反映用ジョブ

4. Step：ジョブ内の個別作業
   例：Pythonの準備、依存関係のインストール、スクリプト実行

収益につながる業務自動化では、処理を次のように分けます。

入力取得
  ↓
入力検証
  ↓
業務スクリプト実行
  ↓
出力検証
  ↓
成果物を一時保存
  ↓
公開・配信・集計先へ反映
  ↓
ログとKPIを記録

途中の検証に失敗した場合は、公開や配信へ進ませません。売上レポートの作成に失敗したのに「完了」と記録したり、内容が空の記事を公開したりする事故を防ぐためです。

実際の運用ログから分かる「無人化の現実」

私が運用しているこのauto-ai-blogでは、記事生成、品質確認、Markdown保存、Notion保存、GitHubへのpushを自動化しています。

2026年7月21日に、次のPowerShellコマンドでリポジトリ内のMarkdownファイル数を確認しました。

$paths = @(
  "sites/ai-tech/content/posts",
  "sites/business/content/posts",
  "sites/real-estate/content/posts"
)

foreach ($path in $paths) {
  $count = (Get-ChildItem -LiteralPath $path -File -Filter "*.md").Count
  "{0}: {1}" -f $path, $count
}

結果は次のとおりです。

この835本は収益額ではなく、自動化によって蓄積されたコンテンツ数のスナップショットです。下書きや検索流入のない記事を含む可能性があるため、記事数だけで事業成果を判断することはできません。

同日のgenerator/logs/generate.logでは、成功だけでなく、次の失敗も確認できました。

18:57:39  対象トピックを選択
19:01:57  記事生成CLIが240秒でタイムアウト
19:01:57  全生成処理が失敗したため記事生成をスキップ

別の実行では、レビュー処理に失敗したためドラフトを採用した記録があり、正常な回では次の段階まで完了していました。

記事をMarkdownとして保存
Notionへの保存に成功
origin/mainへのpushに成功

このログから分かるのは、完全自動化で重要なのが成功ルートの長さではなく、失敗時の採用条件と停止条件だということです。

• 生成に失敗したら空ファイルを公開しない
• レビューに失敗した場合、ドラフトを採用できる条件を決める
• タイムアウト後に中途半端な成果物を残さない
• 保存、外部連携、pushのどこまで完了したかを記録する

835本という蓄積を守っているのは、生成能力だけではありません。失敗した成果物を採用しない設計です。

なお、ここで示した件数とログは2026年7月21日時点のローカルリポジトリに基づく一次情報であり、将来の稼働率や収益を保証するものではありません。

ステップ・バイ・ステップ：安全な業務自動化を作る手順

1. 業務を「入力・処理・出力」に分解する

最初に、自動化する業務を一文で説明できる形へ分解します。

入力：前日分の注文CSV
処理：商品別の売上と紹介報酬を集計
出力：日次レポートCSVと処理ログ

「売上業務を自動化する」のような広い定義では、失敗箇所も再実行範囲も判断できません。取得、計算、保存、通知を分ければ、障害時に必要な部分だけを再実行できます。

外部サービスへの送信、決済、削除など、元に戻しにくい処理は別のジョブへ分離してください。

2. 成功条件を機械判定できるようにする

GitHub Actionsは、コマンドの終了コードで成功と失敗を判断します。基本的には終了コード0が成功、0以外が失敗です。

Pythonでは例外を握りつぶさず、必要な成果物まで検証します。

from pathlib import Path

output = Path("output/daily_report.csv")

run_business_process()

if not output.exists():
    raise RuntimeError("日次レポートが生成されていません")

if output.stat().st_size == 0:
    raise RuntimeError("日次レポートが空です")

さらに実務では、ファイルの存在だけでなく、次の条件も確認します。

• 必須列がそろっている
• 行数が想定範囲内である
• 売上金額が負数になっていない
• 対象日が処理日と一致している
• 前回より件数が急減していない

ログへ「エラー」と書くだけで終了コード0を返す設計では、GitHub Actions側が成功と誤認します。

3. 最小権限のワークフローを作る

.github/workflows/business-automation.ymlを作成し、最初は読み取り権限で動かします。

以下は理解しやすさを優先した学習用の例です。本番では後述するコミットSHA固定も検討してください。

name: Business Automation

on:
  workflow_dispatch:
  schedule:
    - cron: "17 0 * * *"

permissions:
  contents: read

concurrency:
  group: business-automation
  cancel-in-progress: false

jobs:
  run:
    runs-on: ubuntu-latest
    timeout-minutes: 20

    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: pip

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest

      - name: Execute business script
        run: python scripts/run_business_process.py

permissions: contents: readは、GITHUB_TOKENへ不要な書き込み権限を与えないための指定です。GitHubも、ワークフローの権限を必要最小限にする運用を推奨しています。GitHub公式の安全な利用ガイド

cronの時刻はUTCです。17 0 * * *は、日本時間では通常9時17分に相当します。GitHub Actionsの定期実行は厳密な時刻を保証するものではなく、高負荷時には遅延し、状況によってはキューに入った処理が破棄される可能性もあります。また、定期実行されるのはデフォルトブランチ上のワークフローです。GitHub公式のトラブルシューティング

決済や法定期限のある処理など、指定時刻の実行保証が必要な用途では、GitHub Actionsだけに依存しない設計が必要です。

4. 二重実行を二段階で防ぐ

GitHub Actionsでは、同じワークフローが並行して実行される可能性があります。前回の処理中に次回が始まると、二重投稿や重複集計が起こります。

concurrency:
  group: business-automation
  cancel-in-progress: false

ただし、cancel-in-progress: falseは「すべての実行を順番どおり無制限に待たせる」という意味ではありません。同じconcurrency groupでは、原則として実行中の1件と待機中の1件が管理され、新しい実行によって既存の待機実行が置き換えられる場合があります。GitHub公式のConcurrency解説

さらに、concurrencyだけでは外部APIへの重複送信を完全には防げません。ワークフローがタイムアウトしても、外部サービス側では送信が完了している可能性があるためです。

そこで、アプリケーション側でも**冪等性（べきとうせい）**を持たせます。

def send_order(order_id: str) -> None:
    if already_processed(order_id):
        return

    send_to_external_service(order_id)
    record_as_processed(order_id)

実務では、次のようなキーを保存します。

処理種別 + 対象日 + 顧客ID + 注文ID

たとえば、daily-mail:2026-07-21:customer-123がすでに存在する場合は、再送をスキップします。

重要な処理では、送信後に記録するだけでなく、データベースの一意制約、外部APIのidempotency key、トランザクションなども利用してください。

5. Secretsへ秘密情報を分離する

APIキーやパスワードをYAMLやPythonへ直接書いてはいけません。GitHubのRepository SecretsまたはEnvironment Secretsへ登録します。

- name: Execute business script
  env:
    SERVICE_API_TOKEN: ${{ secrets.SERVICE_API_TOKEN }}
  run: python scripts/run_business_process.py

Python側では環境変数として受け取ります。

import os

token = os.environ["SERVICE_API_TOKEN"]

次のようなログ出力は避けてください。

print(os.environ)
print(request_headers)
print(api_response.text)

GitHubには秘密情報をマスクする仕組みがありますが、値を分割・変形した場合や、GitHubが秘密情報として認識していない値まで必ず隠せるわけではありません。GitHub公式のSecretsリファレンス

秘密情報を守る基本は、「マスクされることを期待する」よりも、最初からログへ渡さないことです。

6. テストと公開を別ジョブにする

テストジョブと本番反映ジョブを分離し、前者が成功した場合だけ後者を動かします。

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - run: pip install -r requirements.txt
      - run: pytest
      - run: python scripts/build_output.py

      - name: Upload validated output
        uses: actions/upload-artifact@v4
        with:
          name: validated-output
          path: output/

  publish:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: write
    environment: production

    steps:
      - name: Download validated output
        uses: actions/download-artifact@v4
        with:
          name: validated-output
          path: output/

      - name: Publish
        run: python scripts/publish.py

needs: testにより、テストジョブが失敗した場合は公開ジョブへ進みません。

environment: productionには、対象ブランチの制限、Environment Secrets、承認ルールなどを設定できます。ただし、Required reviewersやEnvironment Secretsの利用条件は、リポジトリの公開範囲やGitHubプランによって異なります。導入前に現在の条件を確認してください。GitHub公式のEnvironments解説

毎回の人間承認は完全無人化と相反しますが、次の処理では承認を残す価値があります。

• 決済や返金
• 顧客への一斉送信
• 本番データの大量削除
• 法務・医療・金融に関する公開
• 一度公開すると回収が難しい情報

まずは、元に戻せる記事生成や社内集計から無人化し、不可逆な処理は段階的に移行します。

7. 一時保存してから正式版へ切り替える

成果物を最初から公開先へ書き込むと、途中で失敗した場合に不完全なファイルが残ります。

安全性を高めるには、次の順序にします。

一時ファイルへ保存
  ↓
内容を検証
  ↓
正式ファイルへ置換
  ↓
公開処理を実行

Pythonでは、同じファイルシステム上で一時ファイルを正式名へ置き換える方法が使えます。

from pathlib import Path

temporary = Path("output/daily_report.csv.tmp")
final = Path("output/daily_report.csv")

build_report(temporary)
validate_report(temporary)
temporary.replace(final)

ただし、ファイルの置換が安全でも、外部APIへの送信まで原子的に取り消せるわけではありません。外部送信には、別途冪等性キーや送信履歴が必要です。

8. 成果物と調査可能なログを残す

実行結果を画面表示だけで終わらせず、CSV、テスト結果、スクリーンショットなどをArtifactとして保存します。

- name: Upload result
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: business-result
    path: |
      output/
      logs/
    retention-days: 14

Artifactは実行後に確認するための成果物、Cacheは依存関係などを再利用して処理を高速化する仕組みです。役割を混同しないようにします。GitHub公式のWorkflow artifacts解説

ログには最低限、次の情報を残します。

run_id
開始・終了時刻
入力データの対象日と件数
処理段階
採用した成果物
検証結果
外部送信の結果
公開・pushの結果
終了コード

「失敗した」という一行だけでは、再実行してよいか判断できません。どこまで成功し、何を保存・送信しなかったかが分かる形式にしてください。

9. 1週間は手動実行で観察してから定期化する

最初からcronで無人運用せず、workflow_dispatchによる手動実行で確認します。

最初に試すべきテストケースは次のとおりです。

安定後にscheduleを追加します。

今日すぐできる行動は、既存スクリプトへworkflow_dispatchだけを設定し、正常入力・入力なし・異常入力の3パターンを実行することです。

専門家目線のチェックポイント

外部Actionは完全長のコミットSHAへ固定する

actions/checkout@v4のようなタグ指定は読みやすい一方、タグの参照先が変更される余地があります。

高い安全性が必要な業務では、検証済みの完全長コミットSHAへ固定します。

- uses: actions/checkout@検証済みの完全長コミットSHA

GitHub公式は、完全長のコミットSHAを、Actionを不変のリリースとして参照する最も安全な方法としています。固定後はDependabotなどで更新候補を受け取り、テストしてから差し替えます。GitHub公式のSecure use reference

ただし、SHAを固定するとセキュリティ修正も自動では取り込まれません。「固定して終わり」ではなく、更新を定期的に確認する運用が必要です。

pull_request_targetを安易に使わない

外部から変更を受け付けるリポジトリで、信頼できないPull RequestのコードへSecretsや書き込み権限を渡すと危険です。

特に、pull_request_targetで起動した権限付きジョブから、Pull Request側のコードをcheckoutして実行する構成は避けてください。

テスト用ワークフローと権限付き処理を分離し、外部コードを実行するジョブにはSecretsを渡さないことが基本です。

リトライ対象を限定する

すべての失敗を自動リトライすると、障害を悪化させる場合があります。

指数バックオフを使う場合も、最大回数と最大待機時間を決めます。無限リトライは、API費用と障害時間を増やすだけです。

タイムアウト後の状態を定義する

実際の運用ログでは、CLIが240秒でタイムアウトした回に記事生成をスキップしていました。タイムアウトを設定するだけでは不十分です。

• 一時ファイルを公開先へ移動していないか
• 外部APIへの送信が完了した可能性はないか
• 再実行時に同じ処理を重複させないか
• 子プロセスが残っていないか
• ロックや一時ファイルを次回まで残していないか

この5点まで設計します。

self-hosted runnerの限界を理解する

社内ネットワークや専用ソフトが必要な場合はself-hosted runnerが便利ですが、GitHub-hosted runnerのような使い捨て環境ではありません。

• 前回のファイルが残る
• 認証情報が端末内に残る
• 信頼できないコードが社内ネットワークへ到達する
• OSやライブラリの更新を自分で管理する
• 実行ユーザーの権限が過大になりやすい

一般的なPython処理で完結する業務なら、まずは管理負担の少ないGitHub-hosted runnerを検討します。

概念図と実ログを混同しない

上の画像は、安全な運用画面を説明するための概念図であり、実際のGitHub Actions画面や稼働実績を示す証拠ではありません。

実行結果を確認するときは、緑色の成功表示だけでなく、次の情報を見ます。

• 失敗したStep名
• 終了コード
• 実行時間
• 公開ジョブがSkippedになっていること
• Artifactにログが残っていること
• 外部送信の有無
• 再実行しても重複しないこと

実画面のスクリーンショットを掲載する場合は、リポジトリ名、ユーザー名、顧客情報、APIレスポンス、Secretsの一部が写っていないか確認してください。

よくある失敗と対策

失敗1：ローカルでは動くのにActionsで失敗する

原因：OS、Python、文字コード、作業ディレクトリ、環境変数の差です。

対策：Pythonと依存関係のバージョンを固定し、相対パスの起点を明示します。Windows専用ソフトへ依存する処理は、Ubuntu runnerへそのまま移せません。

失敗2：定期実行が重なって二重投稿する

原因：並行実行と、外部送信処理の非冪等性です。

対策：concurrencyを設定し、投稿IDや処理日を保存して重複判定します。重要な処理では、データベースの一意制約や外部APIのidempotency keyも使用します。

失敗3：失敗したのにワークフローが成功になる

原因：例外を握りつぶす、またはエラー後も終了コード0で処理を終える設計です。

対策：異常時は終了コードを0以外にし、出力ファイルの存在、件数、必須列、内容まで検証します。

失敗4：Secretsへ登録したので安全だと思い込む

原因：依存Actionやスクリプトに秘密情報を渡しすぎています。

対策：ジョブ単位で権限を分け、必要なStepにだけ環境変数を渡します。外部Actionは提供元を確認し、重要な業務では完全長SHAへ固定します。

失敗5：Artifactへ機密情報を保存する

原因：デバッグ用ファイルやAPIレスポンスを無条件にアップロードしています。

対策：Artifactへ含めるファイルを明示し、顧客情報やトークンを除外します。if: always()を使う場合は、失敗時に生成されるデバッグファイルまで保存対象にならないか確認してください。

失敗6：自動化した処理が赤字でも動き続ける

原因：稼働率だけを見て、API費用や収益への貢献を測っていません。

対策：月次コスト上限、成果1件当たりの処理費用、収益導線への到達数を記録します。自動運用は利益を保証するものではなく、価値の低い処理を高速で繰り返す可能性もあります。

成果を測るKPI

835記事という数字も、単独では事業成果を表しません。検索流入、商品ページへの遷移、成約件数、運用費を組み合わせて、初めて自動化資産の価値を判断できます。

障害時の簡易ランブック

無人運用を始める前に、障害時の手順を短く残しておきます。

1. 失敗したrun_idとStepを確認する
2. 外部送信が完了しているか確認する
3. Artifactとログを退避する
4. 入力データに問題がないか確認する
5. 冪等性キーまたは処理履歴を確認する
6. 再実行可能な段階を判断する
7. 修正後はworkflow_dispatchで実行する
8. 正常化した時刻と原因を記録する

最も危険なのは、「失敗したから、とりあえずワークフロー全体を再実行する」ことです。外部送信を伴う処理では、再実行前に送信済みかどうかを必ず確認します。

GitHub Actionsが向かないケース

GitHub Actionsは、次の用途に適さない場合があります。

• 秒単位のリアルタイム処理
• 長時間常駐するサーバー
• 厳密な実行時刻が必要な処理
• デスクトップ画面操作が中心の業務
• 強い個人情報を扱う閉域処理
• 実行状態を長期間保持する必要がある処理
• 外部サービスの規約で自動アクセスが禁止されている処理

また、無人化によって利益やポイント獲得が保証されるわけではありません。サービス規約に反する自動アクセス、広告の不正クリック、複数アカウントによる不正なポイント取得などは行ってはいけません。

この記事はシステム運用に関する一般的な情報であり、投資判断や収益保証を行うものではありません。

まとめ：最初の一歩は「安全に失敗する手動実行」

GitHub Actionsによる業務自動化は、定期実行のYAMLを書いた時点では完成していません。

まずは次の5項目を実行してください。

1. 自動化したい業務を入力・処理・出力に分ける
2. 異常時に終了コード0以外を返す
3. permissions、concurrency、timeout-minutesを設定する
4. テスト成功後にだけ公開処理を動かす
5. workflow_dispatchで正常系と異常系を検証する

そのうえで、外部送信を伴う処理には冪等性キーを設け、一時保存、出力検証、Artifact、障害時ランブックを追加します。

売上集計、記事公開、アフィリエイト導線の更新などをこの構造へ載せれば、自分が毎日同じ操作をしなくても成果物を蓄積できます。

収益性は別途検証が必要ですが、再利用できるコード、テスト、ログ、公開経路、復旧手順の組み合わせは、時間を生み出す自動化資産になります。

本気で自動化・不労所得を構築したい方へ

GitHub Actionsの仕組みを理解しても、「何を自動化すれば収益につながるのか」「どこまで無人化してよいのか」「商品・記事・集客導線をどう接続するのか」で止まる方は少なくありません。

試行錯誤を毎回ゼロから始めると、節約したいはずの時間を設定作業で消耗します。

収益導線を持つテーマ選定、AIによるコンテンツ生成、定期実行、品質チェック、公開後の改善まで、一つの運用システムとして組み立てたい方は、実践マニュアルを確認してください。

▶ 本気で自動化・不労所得を構築したい方向けの実践マニュアルを見る