01 / THE IDEA必要な時間だけ借りる、作業用のコンピューター
たとえば「毎朝6時にニュースを集め、AIで要約し、見出し画像を作る」という仕事を考えます。VPSなら、自分用のサーバーを契約して、その上にPythonや予約実行の設定を置きます。
Cloud Run Jobsでは、実行に必要な道具をまとめたプログラムを登録しておきます。起動の依頼が来るとGoogle側で実行環境が用意され、収集や生成が進みます。結果を保存し、プログラムが終了すると、その実行のコンピューターも停止します。
Cloud Run Jobsは、終わりのあるプログラムを動かす場所です。「いつ起動するか」「結果をどこに保存するか」「失敗にどう気づくか」は、組み合わせる仕組みやプログラムで用意します。
Googleが実行基盤を管理する方式を「サーバーレス」と呼びます。サーバーそのものが消える意味ではありません。利用者がOSの更新や故障したマシンの交換を直接担当する範囲が小さくなる、という意味です。
公式資料：Cloud Runの概要02 / VPS TO JOBSVPSが持っていた役割を、分けて引き継ぐ
VPSは「一部屋を借りて、道具も時計も棚もそこに置く」方式に近いです。Cloud Run Jobsへの移行では、実行する場所・予約する時計・保存する棚を分けます。これにより管理は減りますが、最初に役割を整理する必要があります。
| 役割 | VPSでの例 | Google Cloudでの例 |
|---|---|---|
| 処理の実行 | Python・シェル・Docker | Cloud Run Jobs |
| 毎朝の予約 | cron・systemd timer | Cloud Scheduler |
| ファイル保存 | サーバー内のフォルダー | Cloud Storage |
| 配信の履歴 | JSON・SQLiteなど | Firestoreなどの永続DB |
| 認証情報 | 環境変数・秘密ファイル | Secret Managerなど |
| ログ・失敗通知 | ログファイル・監視cron | Cloud Logging・監視と通知の設定 |
| Webhook受付 | 常駐Webサーバー | Cloud Run Serviceなど |
これは構成案です。すべてのサービスを一度に採用する必要はありません。最初は「Jobを1つ、結果の保存先を1つ」から試し、必要な部分を追加します。
VPSを解約する前に、そこで動いているcronや常駐処理をすべて洗い出します。手元の設定ファイルや過去のメモだけでは、現在の稼働状況はわかりません。サーバー上で実際の予約一覧と動いている処理を確かめてから判断します。
生成AIは、コードの作成、設定案の整理、調査、障害の分析を手伝えます。ただし毎朝確実に起動する実行基盤は、別に必要です。手元のパソコンはスリープ・電源・ネットワークの状態に左右されるため、それだけで24時間の定期実行を保証することはできません。
03 / THREE WORDSJob・Execution・Taskを、朝の仕事で考える
「朝のニュースを作る」というレシピ
どのプログラムを使うか、CPUやメモリをいくつ使うか、失敗時に何回やり直すかなどを保存した設定です。Jobを作成しただけでは、毎朝自動で動きません。
「10月6日分を作る」という、その日の作業
Jobを起動すると、1つのExecutionが作られます。同じJobを翌日も起動すると、別のExecutionになります。それぞれ成功・失敗・所要時間・ログを確認できます。
その作業を担当する、1つの実行枠
最初は1つのExecutionに1つのTaskで十分です。大量の画像などを複数のTaskに分担させることもできますが、「どのTaskがどのデータを処理するか」はプログラム側で決めます。Taskの数を増やすだけでは、同じニュースの重複処理になることがあります。
失敗したTaskをやり直すことを「再試行（retry）」と呼びます。既定の最大再試行回数は3回なので、初回1回＋再試行最大3回＝最大4回の試行です。毎回4回走るという意味ではありません。
公式資料：Jobの実行公式資料：最大再試行回数04 / SERVICE OR JOB?同じCloud Runでも、Serviceとは使い方が違う
アクセスに応答する窓口
WebサイトやAPI、Webhookなど、HTTPリクエストを受けて応答する用途です。公開URLまたは認証付きの窓口を持ちます。
例：LINEから届くWebhookを受け取る。
作業を終える実行係
指定した処理を実行し、成功または失敗を返して終了する用途です。JobそのものをWebサイトの窓口にはしません。
例：RSSを集めて記事とPNGを保存する。
「毎朝生成する」はJobs、「外からの通知を受け取る」はService、という分け方が基本です。両方が必要なら、窓口がJobの起動を依頼する構成にすることもできます。
公式資料：コンテナの動作要件05 / THE WHOLE PICTUREMacで作り、Google側で動かす
まず「準備」と「毎日の運用」を分けると、仕組みが見やすくなります。Macは開発する場所です。毎日の処理がGoogle側に移った後は、実行時にMacを起動しておく必要はありません。ただし、Macで行う投稿や同期が残れば、その部分は引き続きMacに依存します。
A. 準備する流れ — コードを変更したとき
B. 毎日動く流れ — 予約した時間が来たとき
サービスアカウントは、プログラムがGoogle Cloud上で使う身分証のようなものです。「このJobはこの保存先に書き込める」という権限を付けます。予約起動を依頼する側にも必要な権限があり、用途に合わせて区別します。
リージョンは、実行する地域です。東京や大阪などから選びます。保存先や利用するサービスの地域も合わせて検討すると、通信の遅延や費用を整理しやすくなります。
コンテナ化は、Macの中身を丸ごとコピーすること？
必要なPython、ライブラリ、フォント、ブラウザなどをまとめる作業です。個人のMac全体や秘密情報を梱包する意味ではありません。Cloud Runに対応したLinux用イメージを作ります。Apple SiliconのMacで作った環境を、そのまま使えるとは限りません。
ローカルのコードを渡してGoogle側でビルドする方法もあります。コンテナを作る工程や保存先がなくなるわけではありません。
06 / LIFECYCLE起動・実行・成功・失敗は、どう進む？
Jobの処理には「始まり」と「終わり」を作ります。データを集め、必要な成果物を保存し、プログラムが終了すれば1回の作業が終わります。いつまでも待ち続けるWebサーバーを、そのままJobsに入れる用途ではありません。
長い処理には、時間の上限を合わせる
通常の非GPU Taskのタイムアウトは既定10分、最大168時間（7日）です。これはTaskの各試行の上限で、Execution全体を一律7日で終了する意味ではありません。このガイドでは、GPUを使わない処理を前提にしています。
たとえば30分かかる処理を、既定の10分のまま登録すると途中で打ち切られます。実測時間に余裕を加えつつ、際限なく待ち続けない上限を決めます。既存のアプリ内の再試行とCloud Runの再試行が重なると、予想以上に長く動くこともあります。
Taskの失敗による再試行に加え、Schedulerはまれに同じ予定時刻の起動を複数回依頼することがあります。同じ日・同じ配信先への二重投稿を避ける仕組みを、永続保存先とプログラム側で用意します。
Taskを1つにすれば、同時実行は起きない？
1つのExecution内でTaskを1つにすることと、別のExecutionが重ならないことは別です。予約や手動操作でJobを再度起動すれば、前のExecutionと重なる可能性があります。必要なら、永続DB上で処理枠を確保するなどの仕組みを設計します。
07 / SAVE THE RESULTS実行環境が止まるので、結果は外に置く
VPSでは「昨日作ったファイルが同じフォルダーにある」のが自然です。Cloud Runの通常のコンテナ内に書いたファイルは、そのインスタンスが停止すると残りません。次の実行で、昨日のファイルがそこにあることを前提にしない設計にします。
記事・画像・収集データ
Markdown、PNG、収集したJSONなどを、日付や種類で整理して保存する候補です。保存期間、削除ルール、閲覧する人の権限を決めます。
送ったか・処理中か
配信済みの記録、重複防止の処理状態、処理対象の一覧などを保存する候補です。既存のSQLiteを、そのまま置けば共有DBになるわけではありません。
コンテナ内の一時ファイルは、作業中の下書きや画像合成に使えます。ただし通常の書込み領域はメモリを消費します。大きな画像、ブラウザ、ダウンロードしたデータの分も含め、メモリに余裕が必要です。
ブラウザのログイン状態も、別に考える
PlaywrightやChromiumをコンテナに入れて、ページを開く処理は可能です。一方、今使っているブラウザのプロファイルを移すだけで、外部サイトへのログインが継続する保証はありません。再ログイン・二段階認証・Cookieの有効期限・サイトの自動操作条件を確認します。
Cookieや認証状態ファイルには本人として操作できる情報が含まれます。公開コードや成果物へ入れず、適切な秘密情報の保存先と権限を用意します。Secret Managerも候補ですが、大きなプロファイルや更新する状態の保管方法は別途設計します。
公式資料：コンテナ内のファイル保存公式資料：ブラウザ自動化公式資料：Playwrightの認証状態08 / TYPICAL WORKLOADSよくある定期処理に当てはめると
以下は、個人や小さなチームでよくある定期処理を例にした移行の考え方です。実際の所要時間や費用は、Google Cloud上で試験実行して測ります。
長めの定期バッチを、1回の仕事にする
RSSを取得し、AIでまとめ、記事を保存する流れはJobsに向いています。手元で20〜30分かかる処理でも、クラウド上の所要時間が同じになるとは限りません。RSSの取得待ち・AI APIの応答待ち・再試行も含めて実測します。
種類の違うレポートを複数作る場合は、1つのJobにまとめるか、種類ごとにJobを分けるかを先に決めます。分けると失敗の影響範囲が小さくなり、まとめると管理するJobの数が減ります。
収集・要約・画像生成をまとめる
Python、AI API、HTML整形用の外部コマンド、Pillow（Pythonの画像処理ライブラリ）、フォントなどをコンテナへ入れる構成が考えられます。記事と画像は外部の保存先に出します。Mac固有のフォントやファイルの場所は、Linuxで使えるものに置き換えます。
GitHub Actionsで日次実行している処理も、Jobs＋Schedulerへ移せる候補です。GitHubをコードの保管や公開配布に残す選択もできますが、日々の実行にGitHub Actionsを使う必要はありません。手元のコードから直接Google側に登録する方法もあります。
移す前に、ログインと利用条件を確かめる
PlaywrightやChromeで、ログインした状態のWebサイトを操作する処理は、移行の難所です。Jobsでブラウザを動かすこと自体は可能ですが、認証状態の維持に加えて、相手サイトの利用規約や自動操作の制限を先に確認します。最初の試験対象には、ログイン不要の公開RSSの収集が扱いやすいでしょう。
記事の生成と、SNSやブログへの公開は別の工程です。手元のパソコンのブラウザで行っている投稿や、パソコンへファイルを取り込む仕組みが残る場合、その依存も別途整理します。生成だけ移しても、全工程がクラウドで完結したことにはなりません。
CloudflareのWorkersやWorkflowsなどは別の選択肢です。Python・画像処理・ブラウザ・長めの処理を含む定期バッチには、コンテナの実行環境を持つCloud Run Jobsが検討しやすい選択肢です。すべてを同じ基盤に統一する必要はありません。
09 / COST「何分動いたか」と「どれだけ借りたか」で考える
Jobsの主な計算費用は、CPUとメモリを使った時間です。CPUが計算している時間だけではなく、起動した各インスタンスの開始から終了までが対象です。RSS取得待ちやAI APIの応答待ち、プログラム内の待機も含まれます。各インスタンスには最低1分の課金時間があります。
CPUの数 × 実行時間 × CPU単価
＋ メモリの量 × 実行時間 × メモリ単価
複数Task・実際の再試行・月の実行回数の分を足します。
下の計算は、標準JobsのTier 1・通常料金のUSD単価を使う例です。CPUは$0.000018 / vCPU秒、メモリは$0.000002 / GiB秒。東京・大阪はTier 1に含まれます。料金や地域分類は変更される可能性があるため、契約前に公式表を再確認します。
月の計算費用を、条件を変えて見る
単一コンテナ構成で、各Task・各試行に同じ時間と資源量を使う仮定です。無料枠・割引・税・ほかのサービス料金を差し引き／加算しません。実際の再試行は失敗までの時間が異なりうるため、これは概算です。
1 vCPU・1 GiB・27分・月30回・1 Task・平均1試行。合計48,600インスタンス秒。
CPU US$0.8748 ＋ メモリ US$0.0972。保存・AI API・通信などの費用は含みません。
この入力欄は料金計算用であり、設定の有効性を確認するツールではありません。実際にはCPUとメモリの組み合わせなどの条件も確認します。最低1分は各試行に適用し、請求単位の100ミリ秒に切り上げて計算します。
計算機の初期値（1 vCPU・1 GiB・27分・月30回）は、収集と記事生成を1本だけ動かす仮定の例です。複数の処理、保存、通知、AI APIの費用は含みません。VPSの月額と比べる前に、自分の処理をGoogle Cloudで試験実行し、実際の所要時間を測ります。
別に数える費用
- Cloud Scheduler：予約する時計。請求アカウント全体で3ジョブ／月まで無料、超過分は1ジョブにつきUS$0.10／31日で日割りです。実行回数ではなく登録ジョブの数で数え、停止中も対象です。
- ビルドとイメージ保存：Cloud BuildやArtifact Registryなど。コードの変更頻度と保存する量が関係します。
- ファイル・DB・ログ：保存量、操作回数、保存期間などが関係します。
- 通信と外部API：外部への転送、GeminiなどのAI API、投稿先APIなど。Cloud RunのCPU・メモリ料金とは別です。
無料枠があるなら、無料で動かせる？
Cloud Runの無料枠は請求アカウント内で共有されます。複数プロジェクトで使っても、Jobごとに同じ無料枠を重ねて使えるわけではありません。JobsのCPU・メモリには月ごとの無料枠があり、料金表ではus-central1の価格基準で説明されています。
ほかの利用状況、地域、追加サービスの費用によって請求は変わります。そのため、この計算機は無料枠を引かずに表示します。「毎月必ず無料」とは約束できません。
円ではいくら？ 予算を設定すれば自動で止まる？
ここではUSDで示しています。請求通貨やSKUの価格、税などがあるため、固定の為替換算で円の請求額を保証しません。
通知だけの予算（alerts-only）は、支出に気づく仕組みで、自動停止する上限ではありません。別機能のSpend cap budgetsにはCloud Runも含まれ、対象サービスの新しい利用を停止する機能があります。ただし停止は即時ではなく、超過額も請求されるため、請求額を厳密に保証する上限ではありません。
小規模な試験、実行回数と再試行の上限、不要な成果物の削除ルール、請求確認を組み合わせます。
10 / MOVE SAFELY移行は、小さく試して、結果を比べる
最初からVPSを止める必要はありません。1つの収集・生成処理を試し、保存結果と運用を確かめてから、担当を移していきます。
- 現在の仕事を確定する。実際のcron・timer・常駐処理、保存先、配信先、依存を確認します。記録が古いこともあるので、サーバー上の実際の予約一覧で確かめます。
- ログイン不要の収集から試す。公開RSSの収集など、ログイン不要の処理を候補にし、入力と出力を限定した1 Taskを作ります。
- 本番への送信を止めた試験を行う。新しい環境では別の試験用フォルダーへ保存し、既存の結果と記事数・内容・文字化け・画像を比較します。
- 保存と失敗通知を確かめる。処理が失敗したとき、やり直したとき、途中で止まったとき、結果と状態がどう残るか確認します。
- 予約起動を試す。日本時間の設定と、複数日・週次の動きを確認します。Scheduler受付、Execution成功、成果物保存、配信成功をそれぞれ確認します。
- 配信担当を1つに切り替える。VPSとクラウドの両方から同じ本番通知を送らないようにします。元の環境を復元できる状態で、新側だけを配信担当にします。
- 運用実績と請求を見て判断する。必要な日次・週次の処理を一通り通し、漏れた役割がないことを確認してから、VPS解約を検討します。
元の設定・実行に必要なソース・保存データ・復旧手順を確保します。問題が起きたら新側の配信を止め、未送信と結果不明を照合してから旧側に戻します。両方を起動すれば戻る、という運用にはしません。
GitHubは残しても外しても構いません。残すなら、コードの保管・レビュー・公開配布の役割を選べます。日次起動をJobsに移した後も、Gitへの書込みだけで「配信したか」を判定する設計が残っていれば、その依存は別途整理します。
11 / BEFORE THE FIRST RUN始めるときに決めること
実際に始める際は、Google Cloudのプロジェクトと請求設定を用意し、必要なサービスを有効にして、権限を設定する工程があります。このガイドでは、その操作手順は扱いません。
- 最初に移す1つの処理と、成功の条件が決まっている。
- 実行に必要なPython・外部コマンド・フォントを把握している。
- 記事・画像・配信状態・認証情報の保存先を分けて決めている。
- CPU・メモリ・タイムアウト・再試行の初期値を決めている。
- 実行地域と予約のタイムゾーンを決めている。
- JobとSchedulerに必要な権限だけを用意する方針がある。
- 試験中の通知先と、本番への二重送信を避ける方法がある。
- ログの確認方法、失敗通知、料金の確認方法が決まっている。
- VPSの現在の全処理を確認し、復旧できる準備がある。
最初の目標は、「1つの記事と画像を、クラウドで生成して外部保存できる」です。その後に予約・通知・障害対応を足していくと、どこに問題があるか見つけやすくなります。
12 / FAQよくある疑問
Googleのサービスなら、Geminiを使う必要がある？
Cloud Run Jobsはプログラムを動かす基盤です。AIモデルを含め、呼び出すAPIはコードで選びます。使うAPIの料金、認証、利用条件はそれぞれ別です。
毎朝パソコンを起動しておく必要はある？
クラウド側での予約起動・実行・保存・通知まで移した部分は、パソコンが停止していても動く構成にできます。手元のパソコンでの投稿やノートアプリへの取込みを残す場合は、その工程が動く時点でパソコンが必要です。
GitHub Actionsをやめても動く？
動く構成にできます。JobをGoogle側に登録し、Schedulerで起動します。ローカルソースから登録する方法もあるので、GitHubを必須の入口にする必要はありません。コードの保管先と日々の実行場所は、別に選べます。
スマートフォンから結果を見られる？
保存先と閲覧の仕組みを用意すれば可能です。Cloud Storageへ保存しただけで、読みやすいWebサイトやスマートフォン向け画面が自動で完成するわけではありません。公開範囲や通知先も決めます。
Jobが失敗したら、Googleが内容まで直してくれる？
基盤の管理や設定された再試行はGoogle側が行います。プログラムの不具合、外部サイトの変更、認証の失効、配信内容の誤りなどは、ログを見て修正する運用が必要です。調査や修正は、生成AIに手伝わせることもできます。
VPSの中身を全部そのまま移せる？
既存のOS・DB・ファイル・常駐サービスを丸ごと同じ形で引き継ぐ仕組みではありません。終わりのある処理をJobsへ切り出し、保存や受付の役割を別の仕組みに移します。常駐が必要なものは、Serviceやほかの実行基盤も含めて検討します。
13 / GLOSSARY用語を、ここで引き直す
- Cloud Run Jobs
- 処理を実行して終了するプログラムを、Google側の環境で動かすサービス。
- Job
- 実行するイメージやCPU・メモリなどを保存した仕事の設定。
- Execution
- Jobを起動するたびに作られる、1回分の実行。
- Task
- Executionの中で動く処理単位。最初は1つを使う。
- コンテナ
- プログラムと必要な道具をまとめた環境を起動したもの。
- イメージ
- コンテナを起動するために保存する、実行環境のひな型。
- Artifact Registry
- イメージなどを保存しておくGoogle Cloudの倉庫。
- Cloud Build
- ソースなどからイメージを組み立てるサービス。
- Cloud Scheduler
- 指定した時刻に起動の依頼などを送る、予約の時計。
- Cloud Storage
- 記事や画像などのファイルを永続保存するサービス。
- Firestore
- 処理状態や記録などのデータを保存するDBサービス。
- サービスアカウント
- プログラムに使わせる身分証。できる操作を権限で決める。
- リージョン
- コンピューターやデータを置く地域。東京・大阪など。
- Secret Manager
- APIキーなどの秘密情報を、権限を付けて管理するサービス。
- 冪等性（べきとうせい）
- 同じ処理を繰り返しても、二重投稿などの余分な結果を増やさない性質。
- デプロイ
- 用意したプログラムや設定を、実行基盤で使える状態に登録すること。Jobsでは登録と実行は別に扱える。
- vCPU / GiB
- 借りるCPUの処理能力とメモリ容量の単位。料金計算にも使う。
14 / REFERENCES確認に使った公式資料
確認日：2026年10月6日。サービス仕様と料金は、実際の契約・移行前にも確認してください。
- Google Cloud：What is Cloud Runサービスとジョブの用途。
- Google Cloud：Create jobs / Execute jobsJob設定とExecution・Task。
- Google Cloud：Task timeout / Maximum retries / Parallelism時間上限、再試行、実行内の並列度。
- Google Cloud：Container runtime contractLinux用イメージ、終了条件、一時ファイル。
- Google Cloud：Execute jobs on a schedule / Cloud Scheduler overview予約起動と重複しうる配信。
- Google Cloud：Service identity for jobsプログラムが使う権限。
- Google Cloud：gcloud run jobs deployGitHubを必須にしない、ローカルソースの登録方法。
- Google Cloud：Browser automation / Playwright：Authenticationブラウザ実行と認証状態の注意。
- Google Cloud：Cloud Run pricing / Cloud Scheduler pricing単価、無料枠、課金時間、予約ジョブの料金。
- Google Cloud：Budgets and alerts予算アラートと支出制御の違い。
ニュース処理の例と移行順序は、一般的な定期処理を想定した提案です。サービスの仕様と料金は上の公式資料で確認し、自分の処理の所要時間と費用は試験実行で測ってください。
