CI

「毎朝CSVを集計してレポートを送る」「記事を生成して公開する」「価格や在庫を取得して通知する」。こうした業務自動化を始めても、担当者のパソコン上で動かしている限り、電源、通信、ログイン状態に左右されます。 GitHub Actionsへ移せば、GitHub上の実行環境で業務スクリプトを定期的、または特定の操作をきっかけに起動できます。しかし、単にcronを設定しただけでは、二重実行、秘密情報の漏えい、不完全なデータの公開、API利用料の暴走といった問題が起こり得ます。収益につながる処理ほど、誤作動したときの損失も大きくなります。 この記事では、GitHub Actions、CI、Secrets、dry-run、ログ、KPIを組み合わせ、担当者が毎回立ち会わなくても運用を継続できる設計を解説します。 目指すのは「一度も失敗しない仕組み」ではありません。失敗を自動検知し、危険な更新を止め、あとから原因を追跡できる仕組みです。これが整えば、集客記事の公開、アフィリエイトデータの更新、ポイント獲得条件の収集などを、時間の切り売りではない自動化資産へ近づけられます。 なお、自動化による収益やポイント獲得を保証するものではありません。成果は規約、需要、集客力、運用コストなどによって変わります。本記事は一般的な技術情報であり、特定サービスの規約適合性や収益性を保証するものではありません。 GitHub ActionsとCIの全体像 GitHub Actionsは、リポジトリ内の .github/workflows/*.yml または .github/workflows/*.yaml に書いた手順を、GitHubのrunnerで実行する仕組みです。runnerとは、PythonやNode.jsなどを動かす実行環境です。 CIはContinuous Integrationの略で、変更を統合する前後にテストやビルドを自動実行する考え方です。例えば、記事公開スクリプトを実行する前に、リンク切れ、必須項目、生成物の形式を検査します。 役割を分けると理解しやすくなります。 要素 役割 具体例 GitHub Actions 決めた条件で処理を起動する mainへのpush、手動実行、定刻実行 業務スクリプト 実際の仕事を処理する CSV集計、記事生成、API取得 CI 壊れていないか検査する pytest、lint、サイトビルド Secrets 秘密情報を保管する APIキー、デプロイトークン artifact 結果を証拠として保存する レポート、ビルド済みサイト、エラーログ 通知 人間が見るべき例外を知らせる 連続失敗、予算超過、データ欠損 安全な流れは、次の順序です。 起動 → 入力確認 → テスト → dry-run → 本処理 → 出力検証 → 公開 → ログ保存 → 異常通知 収益処理を先に実行し、最後に検査する構成では、誤った記事や価格を公開したあとで失敗に気づく可能性があります。公開、送信、購入、有料APIの呼び出しなど、副作用がある処理は検査に合格した後ろへ置きます。 最初に作るべき「事故の想定表」 YAMLを書く前に、何を防ぐのかを明確にします。少なくとも、次の4つは検討してください。 事故 起こり得る損失 防止策 検知方法 同じ処理の二重実行 二重投稿、重複課金 concurrency、冪等性 実行キーの重複検査 不完全な成果物の公開 信頼低下、機会損失 出力検証、段階的デプロイ 件数・必須項目・URL検査 APIキーの漏えい 不正利用、追加請求 Secrets、最小権限 secret scanning、利用履歴 API利用量の暴走 想定外の請求 件数・回数・金額の上限 推定費用と実費の記録 この表がないと、「テストは通るが事業上は危険」という状態を見落とします。技術的な正常終了と、業務上の成功を分けて定義することが重要です。 ...

ご提示いただいた内容はブログ記事本文ではなく、元記事の共有を依頼する案内文です。そのため、以下の項目を確認できません。 記事のテーマと事実関係 タイトルや見出しの訴求力 専門性と実務的な情報量 初心者が実行できる具体的な手順 実行ログや検証結果などの一次情報 視覚的な証拠と記事の適用限界 既存の画像リンク 情報がない状態で完成版を作成すると、実績や検証結果を推測で補うことになり、一次情報を重視するチェック基準を満たせません。 最終チェックの対象となる記事本文を、次の形式で省略せずに貼り付けてください。 # 記事タイトル 記事本文……  本文を受領後、次の観点から修正し、front matterを付けずに完成版の全文をMarkdownで出力します。 誤字脱字とMarkdown構文の修正 不自然な日本語表現の改善 クリックしたくなるタイトルへの調整 有料でも深掘りしたくなる専門性と実務密度の強化 初心者向けの具体的な手順と次のアクションの明示 一次情報、実行ログ、視覚的証拠、適用限界、差別化要素の補強 既存の  形式の画像リンクの完全保持

「毎朝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階層で考えると理解しやすくなります。 Event：実行のきっかけ 例：mainブランチへのpush、定期実行、管理画面からの手動実行 Workflow：一連の自動処理 例：データ取得から集計、検証、公開までの全工程 Job：役割ごとに分けた処理単位 例：テスト用ジョブと本番反映用ジョブ 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 } 結果は次のとおりです。 ...

自動化の価値は、記事を公開できた回数だけでは測れません。 品質の低い記事、壊れたコード、タイムアウトした生成物を、公開前に止められた回数も重要です。とくにブログを収益資産として運用するなら、「動いたか」ではなく「公開してよい状態か」を判定する仕組みが欠かせません。 2026年7月16日、AIブログの自動生成パイプラインを検証したところ、次の結果になりました。 検証項目 実測結果 判定 pytest 30件成功 通過 ruff 16件失敗 停止要因 記事生成 240秒でタイムアウト 停止要因 AIスロップ検査 5/8項目通過 公開基準未達 最終公開 実行せず 正常な防御動作 テストが30件すべて成功していても、記事は公開しませんでした。 これは自動化の失敗ではありません。複数の検証を独立させ、「一つでも基準を満たさなければ公開しない」という設計が機能した結果です。 「テスト成功」と「公開可能」は別の状態 今回の結果で最も重要なのは、pytestの成功だけを見て公開判定をしなかったことです。 pytestが確認できるのは、主にプログラムが想定した入力に対して期待どおり動くかどうかです。しかし、次の問題までは保証しません。 コード品質や保守性に問題がないか 生成処理が所定時間内に完了するか 記事に一次情報や具体例が含まれているか 読者にとって有用な内容になっているか 公開処理が二重に実行されないか Secretsや権限設定が安全か つまり、30件のテスト成功は「30件の検証条件を満たした」という証拠であって、「公開してよい」という包括的な証明ではありません。 公開判定は、次のような複数のゲートを通過した結果として扱う必要があります。 ソースコード ↓ 自動テスト ↓ 静的解析 ↓ 記事生成 ↓ 内容品質検査 ↓ 公開 ↓ KPI計測 途中のどこかで失敗した場合は、公開処理へ進ませません。この「失敗時に安全側へ倒す」設計を、fail-closedと呼びます。 実測1：pytestは30件成功した 最初の検証では、pytestの対象となった30件がすべて成功しました。 pytest: 30 passed これは、少なくともテストで定義されていた機能について、明確な回帰が検出されなかったことを示します。 ただし、ここには限界があります。 テストされていない入力、外部APIの一時障害、生成内容の質、公開先の認証状態などは、通常の単体テストだけでは十分に確認できません。テスト件数そのものより、「収益や信用を損なう失敗をテストできているか」を確認する必要があります。 実務では、最低でも次のケースを追加します。 生成結果が空だった場合に公開しない 必須見出しが欠けていた場合に失敗させる 外部APIがタイムアウトした場合に再試行回数を制限する 同じ記事IDを二重公開しない dry-runでは公開APIを呼ばない Secretsが未設定なら処理開始前に停止する 実測2：ruffで16件の問題を検出した pytestの成功後、ruffでは16件の違反が検出されました。 ...

毎朝のCSV集計、記事生成、価格調査、レポート送信、デプロイ確認。こうした業務スクリプトは、最初は便利でも、運用が雑だとすぐに「失敗していないか毎日見る仕事」に変わります。 GitHub Actionsを使えば、定時実行、手動実行、テスト、ビルド、デプロイを自動化できます。ただし、Secretsの扱い、失敗時の止め方、ログの残し方、二重実行の防止を決めないまま本番運用すると、手作業より危ない仕組みになります。 この記事では、GitHub Actionsで業務スクリプトを安全に運用し、自動化資産として育てる方法を、初心者でも実装順に追える形で整理します。単なるYAMLの書き方ではなく、ブログ生成、レポート作成、商品ページ更新、通知、Cloudflare Pagesデプロイのような「収益導線に近い業務」を安全に回す設計に絞ります。 なお、この記事は投資助言や収益保証ではありません。扱うのは、業務自動化、CI、Web運用、ログ設計の実践方法です。 GitHub Actionsとは：業務スクリプトを安全に動かす実行基盤 GitHub Actionsは、GitHub上でコマンドを自動実行する仕組みです。たとえば、次のような処理をYAMLファイルで定義できます。 main ブランチにpushされたらテストする 手動ボタンで記事生成を試す 毎朝9時にレポート生成を走らせる テストが通ったときだけCloudflare Pagesへデプロイする 失敗したらログを残し、通知する 初心者が最初に押さえるべき用語は次の通りです。 用語 意味 例 workflow 自動化の設計書 .github/workflows/daily-post.yml trigger 起動条件 push、schedule、workflow_dispatch job 実行単位 テスト、ビルド、デプロイ step job内の1作業 Pythonセットアップ、pytest 実行 Secrets APIキーやトークンを隠して保存する機能 CLOUDFLARE_API_TOKEN CI 変更ごとにテストや静的解析を走らせる仕組み ruff check .、pytest 重要なのは、GitHub Actionsを「ただの定時実行ツール」と考えないことです。業務スクリプトを安全に資産化するには、次の4つをセットで設計します。 実行条件 品質チェック 失敗時の停止条件 ログとKPI 「動く」だけでは不十分です。「壊れたときに、正しい場所で止まり、原因を追える」状態にして初めて業務運用に使えます。 実例：Hiroのauto-ai-blogで確認できる構成 この記事では、Hiroの auto-ai-blog リポジトリで確認できる構成を実例にします。2026年7月12日 JST時点で、主に次のファイルが確認できます。 .github/workflows/daily-post.yml docs/workflows/cloud-daily-post.yml docs/cloud-mode.md scripts/cloud_prepare_ai_cli.sh scripts/cloud_generate.sh generator/generate.py scripts/deploy_cloudflare_pages.py .github/workflows/daily-post.yml は、main へのpushと手動実行で動くCI兼デプロイworkflowです。処理の流れは次の通りです。 ...

「毎朝スクリプトを実行するのを忘れた」「エラーに気づかず投稿や集計が止まっていた」「担当者のPCが止まると業務も止まる」。 ブログ投稿、レポート生成、在庫チェック、広告データ集計、商品リンク管理などを人間のクリックに頼っていると、自動化しているつもりでも、実態は属人化したままです。 この記事では、GitHub Actionsで業務スクリプトを安全に運用する手順を、初心者向けにステップ化して解説します。 単に「Pythonを定期実行する方法」ではありません。CI、Secrets、dry-run、ログ、artifact、KPIを組み合わせて、壊れにくく改善しやすい自動化資産に変える考え方です。 この記事で扱うキーワードは次の通りです。 GitHub Actions CI 業務自動化 Python定期実行 Secrets管理 dry-run artifact Hugoビルド Cloudflare Pages 自動化資産 この記事の結論 GitHub Actionsは「スクリプトを定期実行する道具」だけではありません。 安全に使うには、次の順番で設計します。 業務を「入力・処理・出力」に分ける ローカルで同じコマンドを成功させる dry-runで本番反映なしの検証を用意する Secretsで認証情報を管理する permissionsを最小化する concurrencyで二重実行を防ぐ テスト、生成、ビルド、デプロイを段階化する ログとartifactを残す 技術KPIと事業KPIを分けて見る 重要なのは「自動で動くこと」ではなく、失敗した時に止まれること、成功した時に証拠が残ること、改善すべき数字が見えることです。 GitHub ActionsとCIの役割 GitHub Actionsは、GitHubリポジトリ内の .github/workflows/*.yml に書いた手順を、GitHubのrunner上で実行する仕組みです。 初心者向けに整理すると、役割は次のように分けられます。 要素 役割 GitHub Actions 決めた時刻、push、手動ボタンなどをきっかけに処理を実行する CI テストやビルドを実行し、壊れていないか検査する 業務スクリプト 記事生成、集計、投稿、通知、データ取得など実際の処理を行う Secrets APIキー、Webhook URL、認証情報などを安全に渡す Artifacts ログ、ビルド済みファイル、検証結果などを保存する GitHub Actionsが「実行係」だとすれば、CIは「検査係」です。 業務スクリプトを安全に運用するには、この2つを分けて考える必要があります。いきなり本番投稿や本番デプロイを行うのではなく、先にテストとビルドで壊れていないことを確認します。 実例：Hiroのauto-ai-blogで確認した設計 この記事は一般論だけではありません。Hiroの auto-ai-blog リポジトリで、実際のworkflow定義とテスト結果を確認しています。 ...