「Mac の電源を切ったら自動投稿が止まる」「GitHub Actions の scheduled cron が時々発火しない」。中小企業の AI 実装で誰もがぶつかる2つの壁を、月¥60-100で解決した実装記録です。
この記事を読み終えると、AWS EventBridge + Lambda + GitHub Actions を組み合わせて、Mac 不要・99.99% SLA の自動化基盤を作る具体的な手順が分かります。
書き手は、複数の事業会社で経営と業務自動化を進める立場から、5月の実装で実際に動いている構成を、隠さず生のまま書きます。「実装系の記事は専門外なので難しそう」と感じている方もご安心ください。コードを書けなくても、構成図と判断基準は理解できる内容にしています。
この記事の流れ
1.なぜ Mac launchd と GitHub Actions だけでは不十分か
中小企業で AI を業務自動化に組み込み始めると、必ず2つの壁にぶつかります。
1つ目は 「Mac の電源依存」です。Mac launchd は便利ですが、Mac の電源を切ったら止まります。出張・休日・Mac 故障時に自動化が完全に止まる前提では、業務には組み込めません。
2つ目は 「GitHub Actions の scheduled cron 不安定問題」です。GitHub Actions の scheduled cron は無料で便利ですが、混雑時間帯にドロップ(発火しない)します。5月11-12日に2日連続で不発火を実測しました。SLA(発火保証)はゼロです。
有料の cron-as-a-service を使えば解決しますが、月数千円〜数万円のコストが発生します。中小企業の業務自動化で「月¥3万のcron サービス」を払うのは現実的ではありません。
解決策が、AWS EventBridge Scheduler + AWS Lambda の組み合わせでした。SLA 99.99% を保証しつつ、月¥60-100に収まります。
2.構成の全体像:発火と実行を分離する
核心は「発火(起動の引き金)」と「実行(中身の処理)」を分離することです。
具体的な流れは以下です。
- AWS EventBridge Scheduler が指定時刻(JST 07:00など)に発火
- AWS Lambda 関数が呼ばれ、Secrets Manager から GitHub PAT を取得
- Lambda が GitHub API(workflow_dispatch)を叩いて GitHub Actions を起動
- GitHub Actions ワークフローが既存の Python スクリプトを実行
- Outlook メール送信・Sheets 更新・X 投稿などの最終出力
「発火」だけを AWS に移し、実行コンテナとして GitHub Actions を残す構成です。これにより、既存スクリプト資産(50本以上)を一切変更せずに、cron の安定性だけを大幅に上げられます。
3.構築の3ステップ
実装に必要な作業は、大きく3ステップです。
3-1.① IAM Role と Secrets Manager の準備
AWS Console の IAM で2つの Role を作ります。
- Lambda 実行用 Role:Secrets Manager 読み取り + CloudWatch Logs 書き込み権限
- EventBridge → Lambda 呼び出し用 Role:Lambda Invoke 権限のみ
次に Secrets Manager で GitHub PAT を保管します。Personal Access Token に必要な権限は workflow スコープのみです。
3-2.② Lambda 関数の実装
Lambda 関数(Python 3.12)を1つ作ります。コードは40行程度で完結します。
GITHUB_REPO = "your-org/your-repo"
SECRET_NAME = "github/pat"
_sm = boto3.client("secretsmanager")
_token = None
def get_token():
global _token
if _token is None:
_token = _sm.get_secret_value(SecretId=SECRET_NAME)["SecretString"]
return _token
def lambda_handler(event, context):
workflow_id = event["workflow_id"]
inputs = event.get("inputs", {})
url = f"https://api.github.com/repos/{GITHUB_REPO}/actions/workflows/{workflow_id}/dispatches"
req = urllib.request.Request(
url, data=json.dumps({"ref": "main", "inputs": inputs}).encode(),
headers={"Authorization": f"token {get_token()}",
"Accept": "application/vnd.github+json",
"Content-Type": "application/json"}, method="POST")
with urllib.request.urlopen(req, timeout=30) as r:
return {"statusCode": r.status, "workflow_id": workflow_id}
たったこれだけです。GitHub Actions が動かしたい workflow_id を引数として受け取り、API を叩くだけのシンプルな構造です。
3-3.③ EventBridge Schedule の作成
AWS Console の EventBridge Scheduler で、必要な数だけスケジュールを作ります。私の構成では7本作りました。
- JST 07:00 daily Lien KPI 取得
- JST 07:05 daily Lumiere KPI 取得
- JST 07:10 daily Personal KPI 取得
- JST 07:15 daily Lien Sales 取得
- JST 08:35 / 12:35 / 21:07 X 自動投稿(朝・昼・夜)
各 Schedule の Target を上記 Lambda 関数に設定し、Input として workflow_id と inputs を JSON で渡します。これで構築完了です。
4.実装後の検証結果
2026年5月16日深夜に構築完了、5月17日朝から本番運用を開始しました。
5月17日朝の発火実績(CloudWatch Logs で実測):
- JST 07:00:27 Lien Meta daily 発火 ✅ Duration 1.81秒
- JST 07:05:19 Lumiere KPI daily 発火 ✅ Duration 1.34秒
- JST 07:10:10 Personal KPI daily 発火 ✅ Duration 1.28秒
- JST 07:15:24 Lien Sales daily 発火 ✅ Duration 1.18秒
- JST 08:35:11 X morning 発火 ✅ Duration 1.76秒
5本すべて秒単位の精度で発火、Lambda Errors=0。GitHub Actions の scheduled cron 不発火問題は、構成移行で完全に解決しました。
5.月額コストとリスク
運用コストを正確に分解しておきます。
| サービス | 使用量 | 月額 |
|---|---|---|
| EventBridge Scheduler | 7 schedules × 30日 = 210 invocations | ¥0(無料枠14M/月) |
| Lambda 実行 | 210回 × 約2秒 | ¥0(無料枠100万回/月) |
| Secrets Manager | 1 secret | $0.40 ≒ ¥60 |
| CloudWatch Logs | 約100MB | ¥0(無料枠5GB/月) |
| 合計 | – | 月 ¥60-100 |
固定費は Secrets Manager の月¥60のみ。これで SLA 99.99% を保証する自動化基盤が手に入ります。
残るリスクは1つ。WordPress の予約投稿(Missed Schedule)です。5月19日に予約時刻通り発火しない事象が発生しました。原因は WP-Cron がサイト訪問者依存である構造的な問題です。対策として、AWS EventBridge から wp-cron.php を定期的に叩く Lambda を追加実装中(本記事を書いている時点で進行中)です。
6.中小経営者への示唆
この構成の最大の意味は、「Mac の電源依存からの脱却」です。
業務自動化を Mac launchd で動かしている経営者は多いと思います。便利ですが、Mac が止まれば自動化も止まる前提では、業務には組み込めません。「自動化したつもりが、結局Mac の前にいる」状態が続きます。
AWS EventBridge に移すと、以下が変わります。
- 出張・休日でも自動化が動き続ける
- Mac 故障・OS アップデート・再起動の影響を受けない
- 複数Macで二重実行する事故が起きない
- 会社規模が大きくなっても同じ構成で対応できる
パナソニックの創業者 松下幸之助さんは、次のように語りました。
「便利だからやるのではない。やるべきことをやるための便利な道具を選ぶのだ」
Mac launchd は「便利な道具」でしたが、業務組み込みには Inadequate な前提を抱えていました。AWS EventBridge は「やるべきこと(24h365d 安定稼働)」のための道具です。月¥60-100で、その境界線を超えられます。
7.まとめ
AWS EventBridge × Lambda × GitHub Actions の組み合わせは、中小企業の業務自動化を「実験」から「本番運用」のフェーズに進める鍵でした。
構築に必要な作業は3ステップ、コードは40行程度、月額¥60-100。これで、SLA 99.99% を保証する自動化基盤が手に入ります。
そして、これは AI 実装の最初の一歩でしかありません。次のステップは「Phase B Lambda 化」、つまり毎日18時に最新情報リサーチ→記事執筆→画像生成→WP予約投稿までを完全自動化する構成です。本シリーズで継続的に記録していきます。
あなたの業務で、「Mac の電源依存」になっている自動化はありますか? 同じ視点で実装している方、いらっしゃれば教えてください。
FAQよくある質問
なぜ GitHub Actions の scheduled cron だけでは不十分なのですか?
GitHub Actions の scheduled cron はピーク時間帯にドロップする問題があります。実測で5/11-5/12に連続不発火を観測しました。AWS EventBridge Scheduler は SLA 99.99% を保証しており、cron 主軸を完全に置き換えるのが現実解です。
AWS と GitHub Actions の併用は冗長ではないですか?
発火源(cron)だけを AWS に移し、実行コンテナとして GitHub Actions を残す構成にしました。Lambda の中で全処理を書く必要がなく、既存スクリプト資産(50本以上)を変更不要で動かせる利点があります。「起動」と「実行」を分離するアーキテクチャです。
月¥60-100 で本当に動くのですか?
EventBridge Scheduler 7本(月210回発火)は AWS の無料枠 14M/月の内側、Lambda 実行も無料枠 100万回/月の内側に収まります。発生する固定費は Secrets Manager $0.40/月 = 約¥60のみ。CloudWatch Logs も無料枠 5GB/月の内側です。
Missed Schedule(予約投稿失敗)はどう対応していますか?
5/19 に WP の予約投稿が時刻通り発火しない事象が発生しました。WP-Cron がサイト訪問者依存である本質的な問題です。対策として AWS EventBridge から定期的に wp-cron.php を叩く Lambda を追加実装中です。
中小企業の現場でこの構成を導入するメリットは何ですか?
「Mac の電源依存から解放される」ことが最大のメリットです。Mac launchd や個人のスケジュール起動に依存していた業務自動化が、24時間365日 AWS で動き続けます。出張中・休日・Mac 故障時でも止まりません。月¥60-100 でこの安定性が手に入るのは破壊的です。
「AI実装ノート」シリーズ一覧
- 📍 #001 AWS EventBridge × GitHub Actions 自動化基盤(本記事)
- → #002 以降 週1-2本のペースで公開予定
※本記事は実装の参考情報です。AWS の料金は変動する可能性があるため、最新の公式情報を確認してください。本記事の構成は2026年5月21日時点で稼働中のものです。
