定期実行でLLMに『やる/やらない』を判断させる — 量産型自動化からの脱却

これは16媒体に自動配信するコンテンツ基盤の全体アーキテクチャの深掘りシリーズの1本です。前提となる全体像はそちらを参照してください。今回は、その中でも一番効いている設計判断 —— AIエージェントを「決まった処理を流す実行者」ではなく「今やるべきかを決める判断者」として起動する —— を掘り下げます。

量産型の自動化はコンテンツで破綻する

「毎日1本、記事や動画を自動生成する」をcronで組むのは簡単です。しかしコンテンツ生成でこれをやると、すぐに質が落ちます。

• ネタが尽きても機械は止まらないので、薄い内容や過去記事の焼き直しを量産する
• 「今日は書くことがない」という正常な状態を表現できず、無理やり何かを出力する
• 出力が積み上がるほど、平均品質が下がっていく

自動化の目的が「作業の代行」なら固定処理でいいのですが、目的が「良いコンテンツを出すこと」だと、"何を作るか・そもそも作るべきか"の判断こそが本体です。そこを固定ロジックに任せた瞬間に破綻します。

スケジューラは「起動」だけ、判断はLLMに委ねる

そこで、役割をこう分けました。

• スケジューラ（cron / Task Scheduler）: 決まった時刻に「起動」するだけ。何をするかは指示しない。
• AIエージェント（CLI headless）: 起動されたら状況を読み、「価値ある仕事があるか」を自分で判断し、あれば1件だけ実行し、なければ何もしない。

ポイントは、スケジューラがエージェントに渡すのが「これを実行しろ」という命令ではなく、「判断しろ」という指示であることです。

判断プロンプトの設計で外せない3点

この仕組みの品質は、起動時に渡すプロンプトでほぼ決まります。実際に運用して効いた要点は3つです。

1. 判断基準を具体的に明示する

「良い記事を書いて」では曖昧すぎて、エージェントは無難で薄いものを出します。「他の開発者にとって学びになる、汎用的な技術的知見に一般化できる出来事があったか。バグの発見と修正、APIの落とし穴、設計判断など。単なる機能追加やコンテンツ更新は対象外」のように、採否のラインを言語化します。

2.「やらない」を正当な結論として許可する

これが最重要です。LLMは放っておくと「とりあえず何か出力する」方向にバイアスします。プロンプトで明示的に、**「良い題材が無ければ、何もせず終了してよい。無理に書かないことが最優先」**と許可を与えないと、SKIP判断が生まれません。実際、この一文の有無で薄い記事の量産が止まりました。

3. 出力を機械可読にして後続を分岐させる

エージェントの結論を自由文で受け取ると、後続処理（通知・記録）が判定できません。最後に必ず定型トークンで結論を出させます。

- 記事を書いた場合:  "WROTE: <slug>"
- 書かなかった場合:  "SKIPPED: <理由>"

呼び出し側はこの1行を正規表現で拾い、通知の出し分けや履歴記録に使います。

呼び出し側の骨格

スケジューラから起動されるラッパーは、驚くほど薄くて済みます。判断の中身はすべてエージェント側にあるからです。

# 1. 判断材料を集める (直近の作業ログ・既存成果物の一覧など)
$recentLog     = git log --oneline --since="7 days ago"
$existingSlugs = Get-ChildItem $ArticleDir -Filter *.md | ForEach-Object BaseName

# 2. 「判断しろ」というプロンプトを組み立てて headless 起動
$prompt = @"
直近の作業ログ:
$recentLog

既存の記事slug (重複禁止):
$($existingSlugs -join ', ')

学びになる題材があれば1本だけ書け。無ければ何もするな (SKIP)。
最後に必ず "WROTE: <slug>" か "SKIPPED: <理由>" を出力すること。
"@
$out = $prompt | & claude -p --output-format text

# 3. 結論トークンで分岐
if     ($out -match "WROTE: (.+)")   { Notify "書いた: $($Matches[1])" }
elseif ($out -match "SKIPPED: (.+)") { Notify "今週はスキップ: $($Matches[1])" }

「重複禁止」のために既存成果物の一覧を毎回渡しているのがミソです。コンテキストが毎回リセットされるエージェントに、過去の状態を思い出させる仕組みは別途必要で、これは知識・記憶層の話につながります。

ハマりどころ

• 「書く」方向へのバイアス: 前述のとおり、SKIPを明示的に許可しないと薄い量産に戻る。判断基準は「厳しめ」に振るくらいでちょうどいい。
• 判断がブラックボックスになる: エージェントが「なぜ書いた/書かなかった」を検証できないと、暴走に気づけない。結論トークンと通知は、その最低限の可観測性を担保するための仕掛けでもある。出力の有無と結果は機械的に監視する（「静かな失敗」対策として別記事で扱います）。
• べき等性: 同じ起動が二重に走っても重複生成しないよう、既存成果物リストと履歴で防ぐ。

まとめ

コンテンツ系の自動化で品質を保つ鍵は、「実行」ではなく「判断」をエージェントに委ねることでした。

• スケジューラは起動するだけ。何を・やるべきかはLLMが決める
• 「やらない」を正当な結論として明示的に許可する（無理に作らないが最優先）
• 結論を機械可読トークンで出させ、後続処理と可観測性につなぐ

この記事自体、「直近の作業で他人の学びになる題材があったか」をエージェントに判断させる、まさにその仕組みから生まれています。次回は、コンテキストが毎回リセットされるエージェントに一貫性を持たせる「知識・記憶層」を掘り下げます。

---

📩 LINE で深掘り配信中

AI / マーケ / 楽天モバの限定情報を 週1〜2回 お届け（無料）

興味のあるテーマだけ選んで受け取れます

友だち追加する 👉

AIエージェント運用 / MMM / 楽天モバ紹介 の3テーマから選べます