Cloudflare・Live Schedule・GitHub Actionsは何が苦手?

「元のMarkdownを持ってきて、直して、公開するだけ。」

読書機能の使い方

聴く:本文を読み上げます。速読:語句を順に表示し、速さを調整できます。語学練習:別の言語版と対訳を読み比べます。保存:このブラウザーにブックマークし、プレイヤーの保存済み一覧から開けます。

この記事をシェア
広告
広告

AI記事工場を回して分かった「定期実行≠自律運転」

「元のMarkdownを持ってきて、直して、公開するだけ。」

文字にすると簡単そうだ。

ところが実際に記事工場を自動化すると、その「だけ」が急に増殖する。

Markdownを読む。対象を判定する。12言語がそろっているか確認する。変な見出しを消す。リンクを見る。公開する。公開後の表示を見る。失敗したら戻る。原因を考える。直す。もう一度流す。副作用がないか確認する。

気づけば、ベルトコンベアに編集長までやらせようとしている。

結論から言うと、Cloudflare Workers、定期実行タスク、GitHub Actionsが弱いわけではない。

得意な仕事が違う。

決まった処理を繰り返す仕組みは強い。 でも、毎回内容が違う文章を読んで「今回はどこが変なのか」を考え、直して、再確認する仕事は、単なる定期実行よりAIエージェント向きだ。

1. 「同じ工程」でも、記事ごとに実際の仕事が違う

記事工場は一見すると大量生産に見える。

入力はMarkdown。 出力は公開記事。 なら同じ処理を100回回せば終わりそうだ。

でも文章は部品ではない。

記事Aはタイトルがおかしい。 記事Bは12言語のうち1言語だけ抜けている。 記事Cは翻訳はあるが、その地域で普通に使う言葉になっていない。 記事Dは余計な「検索向け要約」が本文に混ざっている。 記事Eはアフィリエイトリンクの置き場所だけ変だ。 記事Fは公開自体は成功したのに、完了記録だけ失敗した。

全部「記事を公開する」という同じ工程に見えるのに、直す内容は違う。

ここが普通の量産ラインとの大きな差だ。

入力が毎回違えば、失敗の形も毎回違う。

2. 定期実行が得意なのは「決まったことを決まったようにやる」こと

GitHub Actionsは、イベントや時刻をきっかけに、あらかじめ定義したジョブやステップを実行する仕組みだ。[1]

ChatGPTのScheduled Tasksも、指定時刻や対応イベントをきっかけにタスクを実行するための仕組みとして提供されている。[2]

Cloudflare Workersも、リクエスト処理や定期処理、各種サービス連携の土台として非常に強い。

つまり、この3つは「起動する」「決まった処理を走らせる」「結果を次へ渡す」には向いている。

一方で、

「この記事、なんか変じゃない?」 「タイトルだけ妙に機械翻訳っぽい」 「リンクはあるけど、この場所に置く意味ある?」 「失敗した原因は前回と同じ? それとも別物?」

という問いには、最初から正解条件をコードで書き切れない。

定期実行は時計を持っている。 でも編集者の違和感センサーまでは標準装備ではない。

3. 一番難しいのは「PDCAを閉じる」こと

修正そのものより難しいのが、次のループを最後まで閉じることだ。

失敗を見つける。 原因を切り分ける。 修正する。 再実行する。 本当に直ったか確認する。 別の場所を壊していないか見る。 まだダメなら別の仮説を試す。

人間なら自然にやっている。

でも自動処理にすると、各段階を明示的に設計しないといけない。

しかも厄介なのは「半分成功」だ。

公開は成功した。 でも完了記録だけ失敗した。

翻訳は生成できた。 でも1言語だけ空欄だった。

ファイルは更新できた。 でも本番サイトの反映に失敗した。

ここで再実行すると、重複公開や二重処理が起きることもある。

だから本番自動化では、「一度も失敗しない」より、

何回やり直しても最終結果がおかしくならない

ことのほうが大事になる。

Cloudflare Workflowsの公式ガイドでも、各ステップを再試行可能に分け、途中状態を保持し、再試行されても問題が起きない設計が重要だと説明されている。[3][4]

4. Cloudflareには「壊れにくくする道具」はある。でも編集判断は別問題

ここはCloudflareに濡れ衣を着せないために重要だ。

Cloudflare Workflowsは、長時間の複数ステップ処理、状態保持、途中からの再開、自動再試行を提供している。[3]

Cloudflare Queuesには、何度か処理しても失敗したメッセージを別の失敗用キューへ送る仕組みもある。[5]

つまり、

「通信エラーだから再試行」 「この処理だけ失敗したので途中から再開」 「何回やってもダメなので隔離」

はかなり機械化できる。

ただし、

「スペイン語として意味は通るけど、検索でそんな言い方しない」 「本文は正しいけど、読者にとってこの小見出しは邪魔」 「このリンクは技術的には正しいけど記事として不自然」

は、再試行回数を3回から10回に増やしても直らない。

同じ間違いを10回元気よく繰り返すだけになる可能性がある。

再試行は、判断力の代わりにはならない。

5. GitHub Actionsも「自律編集者」ではなく「優秀な作業台」

GitHub Actionsは非常に便利だ。

テストをする。 ファイルを検査する。 ビルドする。 決まった条件なら公開する。 定時にスクリプトを走らせる。

こうした処理には強い。[1]

しかし、Actions自身が記事を読んで、

「うーん、今回の違和感はタイトルより導入だな」

と考えるわけではない。

もちろんActionsからAIを呼ぶことはできる。 だが、その瞬間に問題は「Actionsの設定」ではなく、「AIに何を見せ、何を直させ、どこまで確認させるか」というエージェント設計へ移る。

GitHub Actionsがダメなのではない。

電動ドライバーに編集会議を任せていたら、それは工具の責任ではない。

6. 100%自動化を狙うより「正常系」と「例外系」を分ける

記事工場で現実的なのは、全部を同じルートへ押し込むことではない。

二つに分ける。

正常系:機械で流す

機械判定できるものはそのまま公開する。

  • 必須ファイルがある
  • 12言語がそろっている
  • 空欄がない
  • URL形式が正しい
  • 重複したIDがない
  • 公開コマンドが成功した
  • 本番URLが返る

これはWorkerやActionsやスクリプトが得意だ。

例外系:止めずに隔離する

一件失敗しても工場全体を止めない。

失敗理由を残して、その記事だけ飛ばす。

たとえば、

  • 翻訳不足
  • 構造エラー
  • リンクエラー
  • 公開エラー
  • 内容要確認
  • 原因不明

のように分ける。

そして次の記事へ進む。

100件中90件が自動で通ったなら、90件を成功として出す。 残り10件のために90件まで正座させない。

Skip the exception and keep going. 例外は飛ばして、処理を続ける。

7. 残った例外をCodexのようなリポジトリ型AIへ渡す

例外系は、単純な再試行ではなく「読む・考える・直す」が必要になる。

ここでリポジトリを読めるAIエージェントが合う。

Codex Cloudの公式説明では、準備済み環境でリポジトリやツールを使い、バグ調査、コード変更、テスト実行などのタスクを進められ、対応端末から同じクラウド作業を続けられる。[6]

記事工場なら役割はこうなる。

失敗記事を取る。 元Markdownを読む。 生成物を見る。 エラー記録を見る。 必要ならコードも見る。 直す。 テストする。 再公開する。 本番を確認する。

つまり、Codex側には「公開ボタンを押す係」ではなく、

詰まった記事の修理担当

をやらせる。

全部をAIへ渡す必要はない。 機械で通る記事まで高性能AIに読ませるのは、時間も計算資源ももったいない。

簡単なものは機械。 難しいものだけAI。

この分業のほうが自然だ。

8. 同じ例外が増えたら、そのとき初めて機械化する

例外処理をAIに投げ続けるだけでもよくない。

同じ失敗が何度も出るなら、それはもう例外ではなくパターンだ。

たとえば毎回、

「12言語のうち1つだけ欠ける」

なら、欠落検査と補完処理を自動側に追加できる。

毎回、

「特定の見出しが混ざる」

なら、その見出しを弾く検査を追加できる。

毎回、

「公開成功後に完了記録だけ失敗する」

なら、公開済み確認をしてから状態を直す復旧処理を追加できる。

この順番が大事だ。

最初から全例外を予言してコードにしようとすると、永久に工場建設が終わらない。

まず流す。 例外を集める。 頻出だけ機械化する。

工場は完成してから動かすものではなく、動かしながら「よくある失敗」だけ設備化していくほうが現実的だ。

結論:定期実行はベルトコンベア、AIエージェントは修理工

Cloudflare、Scheduled Tasks、GitHub Actionsは、自律的な編集者として見ると物足りなく感じる。

でも、それは役割が違うからだ。

定期実行基盤は、

「時間になったら動く」 「決まった検査をする」 「成功したものを流す」 「失敗したものを隔離する」

ところまで担当する。

その先の、

「なぜこの記事だけ変なのか」 「どこを直せばいいか」 「修正後、本当に自然になったか」

は、リポジトリを読んで反復できるAIエージェントへ渡す。

これなら100%自動化を無理に狙わなくていい。

機械で通るものは機械で流す。 通らないものは止めずに横へ出す。 横へ出たものだけAIが直す。 頻出エラーだけ、あとから機械側へ昇格させる。

記事工場で欲しかったのは、何でも考えるベルトコンベアではなかった。

止まらないベルトコンベアと、詰まった箱だけ直してくれる修理担当だった。

参考資料(6件)

  1. GitHub Docs, Workflows docs.github.com
  2. OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
  3. Cloudflare Docs, Build your first Workflow developers.cloudflare.com
  4. Cloudflare Docs, Rules of Workflows developers.cloudflare.com
  5. Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
  6. OpenAI Help Center, Using Codex Cloud help.openai.com

PRこのテーマの本を探す

この記事には広告(アフィリエイトリンク)が含まれます。 広告について Amazonのアソシエイトとして、mendoi-appsは適格販売により収入を得ています。

今日これ読んで

この記事を読んだ人の次の疑問に、それぞれ答える記事です。

すべての記事から探す「AI」の記事をもっと見る

広告

もう1個、なんか面白いのない?

読み終わったついでに。近い話と、ぜんぜん違うけど面白い話を少しずつ。

  1. 近い話仕事が一生味するガムになった――AIにPMまで任せたら、ゲームより終わらない「一人会社」になったAIに仕事のすべてを任せると、自分で新しい仕事を生成し始める 散歩や遊び中にアイデアを思いつき、実装する
  2. 無料10分ゲームが「名刺」になる時代短編ADV×AI×バズ×実績
  3. ぜんぜん違うけどなぜ子どもはあんなに元気なのか?「暇→走る」無限エンジンが、思春期とスマホで静かになるまで
  4. 9%の500mL缶は本当に「1本」?5%ビール約2.6本分で、睡眠・夢・身体がバグる理由
  5. 人間は月40ページ、機械は28万回広告審査待ちのブログで「記事数・アクセス・収益」の現実を計算した
  6. 1TB SSDが2万円超えで「安い」だと?──2026年のSSD価格は本当に壊れているのか、5年推移とM2 Macの買い時

他の記事を探す

すべての記事

めんどいちゃん

このサイトの運営者

めんどいちゃん

仕事や日常の「めんどい」を構造化して、次に動きやすくする記事を書いています。