1. はじめに
Confluenceに毎日の作業メモページを作る、という定期タスクを動かしています。
平日の朝7時に走って、翌営業日分のページをテンプレートから1枚作っておく、それだけの仕事です。ローカルで動かしていたものを、PCを開いていなくても走るようにクラウド(Claude Cowork)のスケジュールタスクへ移しました。
そこから毎朝止まるようになりました。
しかも止まり方が「エラーで落ちる」ではなく、同じツールを延々と呼び続けて進まないという形です。手で止めると、その先は普通に進みます。
結局4回対処することになったのですが、1〜3回目の対処は全部見当違いでした。最後に分かってみれば原因はひとつで、しかも4回とも同じものでした。
同じところで転ぶ人がいそうなので、遠回りした過程ごと書いておきます。
なお、タスクのプロンプトを書いたのも、途中の調査をしたのもAIです。自分はやりたいことを伝えて、止まるたびに「止まったので原因を調査して修正して」と報告していただけです。
2. 作っていたもの
やっていることは単純です。
- 今日の日付から次の平日を「対象日」とする(月〜木なら翌日、金なら次の月曜)
- 対象日が祝日、または自分が休みならスキップ
- Confluenceの「YYYY年」→「YYYY年M月」フォルダを探す
- 同じ日付のページが既にあればスキップ
- 無ければ、テンプレートから
YYYYMMDDというタイトルのページを作る
このために、Googleカレンダー(祝日と不在の確認)とConfluence(検索とページ作成)のMCPツールを呼んでいます。
ローカルで動かしていたときは、これで普通に動いていました。だから「処理内容そのものには問題がない」ことは分かっている状態でのスタートです。
3. 原因と対策
先に結論を書いておきます。
3.1. 原因
事前承認されていないMCPツールを呼ぶと、承認待ちで止まる。
スケジュールタスクの設定には、tool_policy_overrides という「このツールは常に許可」のリストがあります。自分のタスクに入っていたのは2つだけでした。
-
searchConfluenceUsingCql(Confluenceの検索) -
createConfluencePage(ページ作成)
ここに入っていないツールを呼ぶと、承認待ちの状態になります。定期実行なので、人はそこにいません。誰も承認しないまま、リトライを繰り返して時間が過ぎていきます。
外から見ると「同じツールを何度も呼んで無限ループしている」ように見えるのですが、実際には承認されるのを待っていただけでした。
3.2. 対策
呼ぶツールを、事前承認済みの2つだけに絞りました。
具体的には、フォルダを探すのに使っていた getConfluencePageDescendants(未承認)をやめて、searchConfluenceUsingCql(承認済み)に置き換えました。ついでに重複チェックと同じ1回の検索にまとめられたので、呼び出し回数も減りました。
カレンダー側は、後述する承認モードの設定を入れることで解決しています。この承認モードの設定についてが今回の失敗の原因ですべてです。(が、全部の過程を書いておきます)
4. 4回止まるまでの経緯
原因が分かるまでに、4回対処して3回外しました。
4.1. 1回目: カレンダーで無限ループ → ツールの癖を疑った
AIが同じパラメータで list_events を実際に叩いて再現を試みたところ、カレンダーMCP側に2つの罠が見つかりました。
罠1: 該当0件のとき events フィールド自体が返ってこない
{"accessRole":"reader","description":"日本の祝日と行事","summary":"日本の祝日","timeZone":"Asia/Tokyo","updated":"..."}
events というキーがどこにもありません。これを見て「取得に失敗した」と判断すると、パラメータを変えながら延々と呼び直すことになります。0件は0件で正常なんですよね。
罠2: 1日分の検索でも nextPageToken が返ってくる
さらに eventType でフィルタすると、フィルタ後が空でもトークン付きのページが返ってきます。素直にページングを追うと終わりません。
いかにも無限ループの原因っぽいです。というわけで、プロンプトの冒頭に「実行ルール」を足しました。
- 各ツールは1回だけ
-
nextPageTokenは絶対に追わない - 空レスポンスは0件で正常なのでリトライ禁止
- エラー時のリトライは最大1回
- 合計ツール呼び出しは10回以内
これで直ったはず、と思っていました。
4.2. 2回目: またカレンダー → 今度はツール名を疑った
同じ場所です。
AIが次に疑ったのは、ツール名でした。このタスクをクラウドに移すとき、指定されていたツール名がUUID形式(mcp__<uuid>__list_events のような形)だったのを、mcp__Google_Calendar__list_events という表示名の形に書き換えていたのです。
セッションによってどちらの形式で公開されるか変わるのだとしたら、存在しない名前を呼び続けているのかもしれない。そう考えました。
そこで「推測で呼ばず、最初にToolSearchで実際のツール名を確認してから使う」という手順を足しました。両方の命名形式を候補として明記もしました。
これも外れでした。
4.3. 3回目: またカレンダー → 連携ごと外した
3回連続、同じ場所です。
リトライ禁止も、呼び出し回数の上限も、ツール名の事前解決も、全部入れた上での再発でした。ここで「指示文では直せない問題だ」と判断して、カレンダー連携そのものを外すことにしました。
- 祝日判定 → 日本の祝日を2027年末まで書き出したリストをプロンプトに埋め込む
- 不在判定 → やめる。休む日は自分でページを消す運用にする
かなり後ろ向きな判断ですが、毎朝止まるよりはマシです。実際、静的なリストで済むものをツール呼び出しでやる必要はないので、これ自体は今も悪くない判断だったと思っています。
4.4. 4回目: Confluenceで止まった → ここでやっと気づいた
カレンダーを外したのに、今度はConfluence側で止まりました。
さすがにおかしいので、止まった場所を並べてみました。
| 回 | 止まった場所 | 事前承認済みか |
|---|---|---|
| 1〜3回目 | Googleカレンダー list_events
|
✗ |
| 4回目 | Confluence getConfluencePageDescendants
|
✗ |
全部、事前承認されていないツールでした。
逆に、searchConfluenceUsingCql と createConfluencePage は一度も止まっていません。この2つだけが「常に許可」に入っていたツールです。
つまりカレンダーは悪くありませんでした。承認されていないツールを最初に呼ぶ場所がカレンダーだった、というだけです。それを外したので、次に承認されていないツールを呼ぶ場所であるConfluenceが露出した、と。
ここまで来てようやく、同じツールを何度も呼んでいるように見えていたのは、承認を待っていただけだと分かりました。
5. ついでに分かったこと
原因とは別に、遠回りの途中で分かったことも書いておきます。
5.1. CQLはフォルダも返してくれる
Confluenceのフォルダを探すのに getConfluencePageDescendants を使っていたのですが、これは事前承認されていませんでした。
代わりに searchConfluenceUsingCql を試したところ、フォルダも type: "folder" として返ってくることが分かりました。
そうなると、重複チェック(対象日のページがあるか)とフォルダ探し(月フォルダのidが欲しい)を、1回のクエリにまとめられます。
(title = "20260806" OR title = "2026年8月") AND space = "<スペースキー>"
これ1回で、「対象日のページが既にあるか」と「月フォルダのid」の両方が分かります。あとはページを作るだけです。
承認の問題を避けるために仕方なく変えた形だったのですが、結果的にツール呼び出しが減って速くなりました。
5.2. 静的なデータはツールで取りに行かない
祝日の判定は、当初カレンダーAPIで日本の祝日カレンダーを見に行っていました。
これも罠があって、日本の祝日カレンダーには「祭日」や「行事」も混ざっています。description がちょうど "祝日" のものだけを祝日とみなす、という判定が必要でした。
いまはプロンプトに祝日の一覧を直接書いています。2年ぶんで24行くらいなので、大した量ではありません。
2026-08-11 山の日 / 2026-09-21 敬老の日 / 2026-09-22 国民の休日 / ...
ツールを1つ減らせて、判定の癖にも悩まされなくなりました。年に1回、リストを差し替える手間だけです(その代わり、対象日が2028年以降になったら「リストの更新が必要」と報告に添えるよう書いてあります)。
6. もうひとつの罠: 承認モードは翌日に戻る
原因が分かったので、承認の設定を変えて解決しよう、という話になりました。
Coworkには承認モードという設定があります。
| モード | 挙動 |
|---|---|
| 自動承認 | 各アクションの安全性を確認した上で実行し、危険と判断したものだけブロック |
| すべての承認をスキップ | 事前チェックなしで実行 |
| 手動で承認 | 1アクションごとに承認が必要 |
これを自動承認にすれば、承認待ちで止まることはなくなります。実際、切り替えてから手動でテスト実行したところ、カレンダーもConfluenceも問題なく通りました。
ところが翌日、また止まりました。
原因は単純で、自動承認に切り替えたのがチャット入力欄のモードセレクターだったからです。
ここの設定はそのセッション限りのものです。スケジュールタスクは発火のたびに新しいセッションを開始するので、翌日の実行は既定のモード(手動で承認)で立ち上がります。「戻っている」のではなく、そもそも引き継がれていなかったわけですね。
正しい設定場所は、タスク自体の編集画面でした。
- 左サイドバーの「スケジュール済みタスク」から該当タスクを開く
- 鉛筆アイコンで編集モーダルを開く
- プロンプト入力欄の下にある承認モードのセレクターを「自動承認」にする
- 保存する
ここで設定するとタスクの設定として保存されるので、毎回の実行に効きます。保存後はタスクの詳細画面にも「常に許可 / 自動承認」と表示されるようになるので、効いているかどうかはそこで確認できます。
こちらに切り替えてからは、毎朝ちゃんと動くようになりました。
紛らわしいのは、チャット入力欄のセレクターと編集モーダルのセレクターが、見た目も選択肢もほぼ同じことです。自分は最初、実行中のセッションのチャット欄で切り替えて「設定した」つもりになっていました。タスクに効くのは編集モーダルの方だけです。
なお、API経由で作ったタスクだと tool_policy_overrides(個別ツールの「常に許可」)は空のままになります。確認のために一時的なタスクをAPIから作って中身を見たところ、実際に空でした(確認後すぐ消しました)。いま動いているタスクに2つだけ入っているのは、移行元のローカル版から引き継がれたもののようです。
ただ、承認モードを自動承認にしてしまえば、この一覧に入っていないツールでも止まりません。作り直す必要はありませんでした。
7. まとめ
- 定期タスクが「無限ループしている」ように見えたら、まず承認待ちを疑う。 人がいないので、承認されないまま延々と待つことになる
- 承認モードはタスクの編集モーダルで設定する。チャット入力欄のセレクターはセッション限りの設定で、スケジュールタスクは毎回新しいセッションなので引き継がれない
- 個別の事前承認(常に許可)は
tool_policy_overridesに入っているものだけ。API経由で作ったタスクだとここは空になる。ただし承認モードを自動承認にすれば、そこに無いツールでも止まらない - とはいえ、承認済みのツールだけで完結する設計にしておくと、承認モードに依存せずに済む
- Googleカレンダーは0件のとき
eventsフィールド自体を返さない。1日分の検索でもnextPageTokenが返ることがある。どちらも異常ではない - ConfluenceのCQLはフォルダも返すので、ページ検索とフォルダ検索を1回にまとめられる
- 祝日リストのような静的データは、ツールで取りに行くよりプロンプトに書いた方が確実
8. 最後に
4回のうち3回、見当違いの対処をしていました。自分でもある程度頭を働かせていれば、もっと早く気づいたような気がします。
しかし、承認モードはだいぶ罠でしたね。チャット欄のところの認証モードを切り替えてぬか喜びしてしまいました。
とはいえ、原因が判明したので良かったです。ローカルで自動実行しているとPCが起動していないときは発火しないので、クラウドで自動実行できるようになったことは喜ばしいです。
この記事が同じように、Claude Coworkで定期実行タスクを設定しようとしている方の助けとなれば幸いです。
株式会社シンシア
株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
弊社には年間100人程度の実務未経験の方に応募いただき、技術面接を実施しております。
この記事が少しでも学びになったという方は、ぜひ wantedly のストーリーもご覧いただけるととても嬉しいです！