scheduled-automation

Claudeと複数の人が関わるワークフローの中で、各段階で「今これは誰の責任か」を明確にすること。ツールが問題を見つけ、誰かがそれを判断し、誰も応答しなければ別の誰かが引き継ぐ。これにより、後で何がうまくいかなかったかを遡って調べるとき、対応する段階を特定でき、全員が「他の誰かがやっていると思っていた」と言う事態を避けられる。

<a href="https://claude-me.com/ja/glossary/ai-agents/agentic-loop/" target="_blank">エージェントループ</a>とは、<a href="https://claude-me.com/ja/glossary/core-concepts/ai-agent/" target="_blank">AIエージェント</a>（Agent）がタスクを実行する基本的な動作サイクルです：現在の状態を感知→次のアクションを計画→アクションを実行→結果を観察→再び計画、タスクが完了するまでこれを繰り返します。これによりClaudeは「一つの質問に答える」から「複数ステップのタスクを自律的に完成させる」へと進化できます。

同じ性質を持つタスクの集まり（例えば20件の文書をすべて要約する、50件のデータをすべて分類するなど）を一括でまとめて送信し、一つずつ手作業でClaudeに貼り付けて尋ねるのではなく、Claudeが同じ指示をバッチ全体に適用できるようにすること。人は一度ルールを設定するだけで済み、同じ指示を20回繰り返す必要がない。

あるデータが最後に本当に更新されてからどれだけ時間が経ったかを測る指標で、そのデータを今も信頼してよいかを判断するために使う。データが存在することは、データが最新であることを意味しない。データはそこにあり続け完全に見えても、何日も前の古いバージョンのままかもしれない。

スケジュールされたタスクを通常どおりの流れで一度最後まで走らせるが、実際にメールを送信したり、データベースに書き込んだり、下流の動作をトリガーしたりはしない。「本当に実行したら何が起こるか」を一覧にして事前に見せてくれるだけだ。台本を先に読んでから舞台に立つようなもので、観客の前でぶっつけ本番にするのとは違う。

スケジュールされたタスクが本当に問題を起こしたとき、誰に通知するか、どの方法で通知するか、最初の担当者が応答しなければどれだけ待って次の人へ切り替えるかを定めること。単に「問題が起きたら通知する」という単純な話ではなく、順序と時間制限のある<a href="/ja/glossary/scheduled-automation/accountability-chain/">責任の連鎖</a>である。

再試行ポリシーが尽きたとき、あるいはそもそも再試行すべきでないと最初から判定されたときに、システムがどう締めくくるべきかを定めること。バックアップのデータソースに切り替える、不完全とマークした部分的な結果を出す、あるいは単純に止まって人を待つ、いずれの場合も重要なのはこの締めくくりが誰かの目に見える形になっていることであり、誰にも気づかれず静かに止まったままではいけない。

何回実行しても、一回だけ実行したときと最終的な結果が同じになるようにタスクを設計すること。これは retry policy（再試行ポリシー）を安全に使うための前提条件である。タスクが冪等でなければ、再試行するたびに新しい結果が積み重なり、再試行回数が増えるほど誤りはむしろ深刻になる。

スケジュールされたタスクが失敗したとき、何回再試行するか、間隔をどれだけ空けるか、その間隔をどう増やしていくかを定めたルール。失敗するたびに際限なく再試行するのでもなく、一回失敗しただけですぐに人を呼ぶのでもなく、その間に有限でリズムのある境界線を引く。

<a href="https://claude-me.com/ja/glossary/scheduled-automation/scheduled-task/" target="_blank" rel="noopener">スケジュールタスク</a>（Scheduled Tasks）はClaude.aiの機能で、指定した時間に特定のプロンプトやタスクをClaudeが自動実行するよう設定できます——例えば毎朝8時に今日の業務ブリーフィングを自動生成したり、毎週月曜に先週のメールサマリーを自動整理したりします。Claudeを「聞いたときだけ答える」から「時間が来たら自動的に知らせる」積極的なモードに変えます。

<a href="https://claude-me.com/ja/glossary/scheduled-automation/scheduled-task/" target="_blank" rel="noopener">スケジュールタスク</a>が実際には正常に動作しなくなり、データの更新も止まっているのに、システムは表面上まったく普段どおりに見える状態。エラーは表示されず、スケジュールは時刻どおりにトリガーされるが、その裏では実際には何も達成されていない。この種の失敗は誰かに発見されるものではなく、誰かがたまたま照合して初めて明るみに出る。

スケジュールされたタスクがどんな状況で起動すべきかを決めるロジック。単純な固定時刻（毎朝9時）はその最も単純な形にすぎない。より完全なトリガー条件は「時刻になったとき、処理すべきデータは本当に準備できているか」も問う。時刻が合っていることは、始めてよいことを意味しない。

一件のデータを一緒になって正確に表せるいくつかの項目を組み合わせ、固定の印にすること。同じ元データは何回処理されても、生成される印がまったく同じになる。この印を使って「これは既に処理済みか」を照合できる。これは<a href="/ja/glossary/scheduled-automation/idempotent-task-design/">冪等タスク設計</a>を実際に成り立たせる具体的な技術手段である。

本来は人が手動でリレーしながら完成させていた一連の手順（データの読み込み、判断、出力の生成、通知）を、自動的に実行される一つの流れへとつなぎ合わせること。人は重要な節目での確認や例外処理のときだけ関わればよく、すべての段階に自ら手を下す必要はない。これは上位概念であり、実際の実装はスケジュールタスクの場合もあれば、録画済みのスキルの場合、両者を組み合わせる場合もある。