目次を表示する

AI エージェントを業務に乗せる ─ 技術スタックの地図

常時稼働の駆動 ─ schedule × event × command の 3 軸

常時稼働の駆動 ─ schedule × event × command の 3 軸

ch7 の durable オーケストレーションが「動いている間、壊れない」を担当するなら、Layer 6 は「そもそも動き始めさせる」を担当する。この層を抜くと、エージェントは「ユーザーが対話で起動したセッション」の中だけでしか動けない。

業務に投入するということは、人間が対話で起動するのを待たずに、定刻に・社内イベントで・Slack コマンドで動き出せるということだ。本章では、5 つの軸で常時稼働の駆動を解く。

軸 1：Schedule × Event × Command の 3 軸

業務系の自動化には、必ず次の 3 軸のトリガーが要る。

mindmap
  root((常時稼働の<br/>3 軸トリガー))
    Schedule
      cron / 定刻
      毎日 09:00 のレポート
      週次のレビュー集約
      月次のコスト集計
    Event
      Webhook / 外部イベント
      GitHub PR 作成
      Slack mention
      Linear issue 追加
      Stripe 決済成功
    Command
      ユーザーの明示起動
      Slack slash command
      Claude Code /loop
      手動 dispatch

cron だけでは「ユーザーが今すぐ動かしたい」に応えられず、event だけでは「毎週月曜の朝に状況をまとめる」のような周期業務に応えられない。command だけでは常時稼働にならない。3 軸すべてを備えるのが業務投入の前提だ。

2026-05 時点で 3 軸を揃えている主要プロダクト：

  • Claude Code Routines（schedule + GitHub event + API endpoint）
  • GitHub Agentic Workflows（schedule + issue/PR event + command-driven + manual dispatch）
  • OpenAI Workspace Agents（Slack / Gmail / Notion / Linear / GitHub にまたがるイベント駆動）

軸 2：Claude Code の 3 階層（Cloud / Desktop / /loop）

Claude Code は常時稼働を 3 階層で提供している。これは業務 SOP の設計判断テンプレとしてそのまま使える。

種類実行先マシン要求セッション要求永続化最小間隔
Cloud (Routines)Anthropic 管理不要不要あり1 時間
Desktop scheduled tasks自マシン必要不要あり1 分
/loop自マシン必要必要resume で復帰1 分

選択フロー：

そのタスクは、自分のマシンに依存するか？
  ├── ローカルファイルや個人のIDE環境を必要とする
  │     ↓
  │     現在の対話セッションの延長で続けたい？
  │       ├── Yes → /loop（v2.1.72+）
  │       └── No  → Desktop scheduled tasks
  │
  └── マシン非依存（API + connectors で完結する）
        └── Cloud Routines（Pro 5 / Max 15 / Team・Enterprise 25 routine/日）

Cloud Routines（2026-04-14 公開）

Anthropic クラウドで完全自動実行される。**プロンプト + repos + connectors（Slack / Linear / Drive / GitHub）+ trigger（cron か GitHub event か API endpoint）**を 1 ユニットに保存する。

# Routines のメンタルモデル（実際の YAML は実装による）
name: weekly-pr-review-digest
trigger:
  schedule: "0 9 * * 1"  # 毎週月曜 09:00
prompt: |
  先週の dependabot 以外の PR を全部リストし、
  レビューが必要なものに優先順位を付けて Slack に投稿
connectors:
  - github
  - slack

Desktop scheduled tasks

ローカルマシン上の OS スケジューラ（macOS の launchd / Linux の cron / Windows の Task Scheduler）で起動する。5-field cron が使える。*/15、1-5、1,15,30 など標準的な構文。

/loop

対話セッション内でエージェントが自分自身を繰り返し起動する。これは厳密には「常時稼働」ではなく「半常駐」だが、業務シナリオとしては多い。CronCreate / CronList / CronDelete tool が組み込まれていて、deterministic jitter（同 task ID は常に同じオフセット）、7 日 expiry、最大 50 task/session の制約がある。

dynamic interval：interval を omit すると Claude が観測結果から 1 分〜1 時間で次回を選ぶ。これが 2026 で新登場した自己ペース型のスケジューラだ。

軸 3：GitHub Agentic Workflows ── Markdown で書く workflow

2026-02-13 に technical preview で出た GitHub Agentic Workflows は、エージェント時代の workflow 定義の方向性を象徴している。YAML の代わりに Markdown で書く。

---
name: PR-Reviewer-Agent
on:
  pull_request:
    types: [opened, synchronize]
  schedule:
    - cron: "0 18 * * *"  # 18:00 daily
agent: claude-opus-4-7
permissions:
  contents: read
  pull-requests: write
---

# PR Reviewer Agent

Read the PR diff and check for:

1. Security issues (SQL injection, XSS, command injection)
2. Test coverage gaps for the new code
3. Performance regressions

If issues are found, post comments on the PR with specific line references.
If no issues, post a single approval comment.

特徴：

  • timezone 付き cron：cron: "0 9 * * *" tz: Asia/Tokyo
  • deterministic load distribution：実行時刻にジッタを入れて GitHub Actions の混雑を避ける
  • issue / PR event、schedule、command-driven、manual dispatch すべて対応
  • AI が判断する余地を残しつつ、決定論的な部分は通常の Actions の文法を使える

これは「人間が定義する自動化からエージェントが文脈を読む自動化への移行**」を象徴する重要な変化だ。

軸 4：Event-driven agent architecture

cron / scheduler は「定刻に起こす」ための仕組みだが、業務は不定期な event に駆動されることが多い。Polling から event-driven に移行することで latency が 70-90% 削減できる、という主張は Confluent などイベント基盤側のベンダから繰り返し出ている。

基本構成：

graph LR
    P[Event Producer<br/>GitHub / Slack / Stripe]
    B[Event Bus<br/>NATS / Kafka / Pub-Sub]
    A1[Agent 1<br/>research]
    A2[Agent 2<br/>writing]
    A3[Agent 3<br/>review]

    P --> B
    B --> A1
    A1 -->|emit research.complete| B
    B --> A2
    A2 -->|emit draft.complete| B
    B --> A3

これは Event Chaining と呼ばれるパターンだ。「リサーチ完了」イベントを受けて執筆エージェントが起動、「ドラフト完了」イベントを受けてレビューエージェントが起動、とエージェントの間を非同期にイベントで繋ぐ。

AWS Prescriptive Guidance は「event-driven は serverless AI のバックボーン」とエクスプリシットに位置づけている。

軸 5：NATS vs Kafka の選択軸

イベント基盤側の選択肢は無数にあるが、業務系エージェントで実用的なのは NATS と Kafka の 2 強だ。

項目NATSKafka
Latencysub-millisecond2-5ms (2026 ベンチ)
Throughput中〜高~10M msg/sec
Retention短〜中（JetStream で長期も可）長期（前提）
用途real-time agent 通信データ集約・長期 retention
運用コスト軽い重い

選択基準は単純だ。

  • low-latency real-time → NATS：「3 秒以内に応答してほしい」「agent 間で短く頻繁に talk する」
  • high-throughput + retention → Kafka：「1 ヶ月分のイベント履歴を保持」「大量のログを集約」

両者を併用する設計もある（NATS で agent 間通信、Kafka で audit log 保管）。Synadia のような商用サポートもあるので、エンプラで NATS を採用する事例も増えている。

OpenAI Workspace Agents との接続

2026-04 に OpenAI が Workspace Agents をローンチした。ChatGPT Business / Enterprise / Edu 向けで、Slack / Gmail / Notion / Linear / GitHub にまたがるエージェントだ。

業務投入の観点では、これは「connectors を SaaS 側で運用してくれる」という意味で重要だ。自前で Slack bot / Gmail OAuth / Linear webhook を組むと、その維持コストはエージェント本体の維持コストを超えることがある。Workspace Agents 系を起点にすると、connectors の運用負荷を SaaS 側に押し付けつつ、自前のエージェントロジックだけ持ち込む設計が可能だ。

ただし、ベンダロックインのリスクもある。社内データの所有権、SOC2 / GDPR 対応、退出戦略を最初に決めてから採用する。

❌ アンチパターン：cron だけで全部やる

症状
─────────
- 「今すぐ動いて」に応えられない
- イベント発生から実行まで最悪 60 分のラグが発生
- 失敗時のリトライが cron 次回まで遅れる

根本原因
─────────
- 3 軸（Schedule × Event × Command）の Event と Command を実装していない
- イベント基盤（NATS / Kafka / EventBridge）を入れていない
- ユーザーが手動起動する経路がない

脱出法
─────────
1. Event 駆動の経路を追加：GitHub Webhook / Slack event / Stripe event
2. Command 駆動の経路を追加：Slack slash command / API endpoint
3. cron は「最後の防衛線」として残す（イベントを取りこぼした場合の補完）
4. NATS or Kafka で event chaining を組む（複数 agent 間の連携）

業務投入の観点で重要な 3 点

  1. 3 軸（Schedule × Event × Command）を全部備える：cron だけ・event だけは業務側の現実に合わない。Claude Code Routines / GitHub Agentic Workflows / OpenAI Workspace Agents が全部 3 軸対応に収束している事実は、業務側のニーズを反映している
  2. dynamic interval（自己ペース型）が新登場：Claude Code /loop で interval を omit すると Claude が次回を決める。「観測してから動く」という発想が scheduling のレベルで実装され始めた
  3. イベント基盤は NATS / Kafka の 2 強で OK：選択軸は latency vs throughput。両者を併用する設計も自然

次章への接続

ここまでで「動き始めて、壊れずに動き続ける」エージェントが組めるようになった。最後の壁は「動いていることを、外から見える状態に保つ」だ。失敗原因を特定し、コストを可視化し、ガードレールで暴走を防ぎ、監査ログで責任を追えるようにする。次の ch9 で観測とガバナンス層を扱う。

この章のまとめ

  • 常時稼働は Schedule × Event × Command の 3 軸：cron だけは業務側の現実に合わない
  • **Claude Code の 3 階層（Cloud / Desktop / /loop）**は業務 SOP の設計テンプレとして使える
  • GitHub Agentic Workflows は Markdown で workflow 定義：「人間が定義する自動化」から「エージェントが文脈を読む自動化」への移行を象徴
  • Event-driven で latency 70-90% 削減：Event Chaining で agent 同士を非同期に繋ぐ
  • **NATS（real-time）vs Kafka（throughput + retention）**の使い分け
  • OpenAI Workspace Agents で connectors を SaaS に押し付ける設計も検討に値する（ロックインリスクは要評価）