Claude Codeの定期実行を回す5工程|放置しても止まらない形

「クロードコードで毎朝のレポートを自動にしたが、気づくと何日も止まっていた」「エンジニアでなくても定期実行を組めると聞いたが、どこまで任せていいのか」。定期実行を組んだ部署から、組んでしばらく経ったころに届くことの多い声です。クロードコードには、決まった時刻に仕事を走らせる仕組みがいくつも用意され、画面の操作だけで組めるものも増えました。そのせいで、定期実行は一度組めば毎日勝手に回り続けるものだと受け取られがちです。けれども本当は、定期実行は人が見ていない時間に走るので、止まったときに誰も気づかない作りがいちばんの事故になるものです。この記事では、クロードコードの定期実行を5つの工程に分け、任せる仕事の切り方、起動の仕組みの選び方、無人で走るための権限と止める条件、完了の判定と記録・通知、版と業務の変化に合わせた点検までを、放置しても止まらない形として整理します。
カメ先生定期実行って、時刻を決めて指示を書けば終わりだと思われがちなんだ。でも本当に難しいのは、そのあと誰も見ていない時間に、ちゃんと最後まで走ったかをどう知るかなんだよ。
カメ子動かす設定よりも、止まったことに気づく仕組みのほうが大事ということですか。
カメ先生そう。クロードコードの定期実行は、どこで動かすかによって止まり方がまったく違う。手元のPCなら眠ったら飛ばされるし、確認待ちで止まることもある。クラウドなら止まらない代わりに、確認なしで何でもできてしまう。
カメ子止まり方が違うなら、先に止まり方を知ってから仕組みを選ぶんですね。
- 定期実行の事故は、止まることより「止まったことに誰も気づかない」こと。動かし方より先に、止まったときの知り方を決める
- クロードコードには、クラウドのルーティン、デスクトップの定時タスク、セッション内のループ機能、対話なしモードの4つの道があり、止まり方がそれぞれ違う
- 定期実行に載せてよい仕事、与える権限の範囲、止まったときの連絡先と止める権限、外に出る操作の承認は人が決める
AI活用を戦略に落とす前に、まずは導入・定着から始めませんか?
デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。
定期実行の事故は「止まったことに誰も気づかない」こと
人が画面の前で操作しているときは、処理が止まればその場で分かります。定期実行は違います。走るのは夜中や早朝、担当者が会議に出ている時間です。止まっても画面の前に誰もいないので、翌朝に届くはずの報告が届かないことで初めて気づくか、届かないことにすら気づきません。毎朝のレポートが来ない日が続いても、受け取る側は「今日は遅れているのだろう」と見過ごしがちです。
さらに厄介なのは、止まったように見えない止まり方です。クロードコードのクラウドの定期実行(ルーティン)について、公式ドキュメントは、実行の一覧に出る緑の表示は「起動して基盤の異常なく終わった」という意味で、指示した仕事が成功したことを意味しないと明記しています。通信の遮断、接続先の道具が見つからない、仕事そのものの失敗は、実行の記録を開いて読まないと分かりません。一覧では正常に見えるのに、中身は何もしていないという止まり方が、仕組みの側に最初から含まれているということです。
だから定期実行の設計は、どう動かすかより先に、止まったときにどう知るかから考えます。起動の条件や止める条件、結果の受け取り方といった、裏で回すエージェント全般の決めごとはバックグラウンドエージェントの記事で整理しています。この記事では、クロードコードという具体的な道具に絞り、どの仕組みを選び、それぞれどこで止まりやすく、どう備えるかを工程の順に見ていきます。
クロードコードを人の操作なしで走らせる4つの道
2026年10月時点の公式ドキュメントは、決まった時刻に仕事を走らせる仕組みとして3つを並べて比べています。提供元が管理するクラウドで走るルーティン、デスクトップアプリから作る手元のPCの定時タスク、開いているセッションの中で指示を繰り返すループ機能です。これに加えて、対話なしで1回だけ実行するモードを、OSの定時実行の仕組みやギットハブの自動処理から呼び出す方法があります。違いを並べると次のようになります。
| 道 | 動く場所 | PCの電源 | 手元のファイル | 確認待ち | 最短の間隔 |
|---|---|---|---|---|---|
| クラウドのルーティン | 提供元が管理するクラウド | 切れていてよい | 使えない(毎回リポジトリを新しく複製) | 止まらない(確認なしで走る) | 1時間 |
| デスクトップの定時タスク | 自分のPC | アプリが起動中で、PCが起きている必要がある | 使える | タスクごとの設定次第。設定によっては承認待ちで止まる | 1分 |
| セッション内のループ機能 | 自分のPC | セッションを開いたままにする必要がある | 使える | 開いているセッションの設定を引き継ぐ | 1分 |
| 対話なしモードを外から呼ぶ | 呼び出す側の環境 | 呼び出す側による | 使える | 確認が要る操作は拒否され、先へ進む | 呼び出す側による |
表の右から2列目が、止まり方の違いを最もよく表しています。クラウドは止まらない代わりに確認なしで動き、手元のPCは設定次第で確認待ちのまま止まる。どちらが安全という話ではなく、止まる場所が違うので、備える場所も変わります。なお、ルーティンは2026年10月時点で研究段階の提供と書かれており、挙動や上限が変わる可能性があると公式が断っています。利用できるのは個人向けと法人向けの有料の契約です。
エンジニアでない人が最初に触るのは、たいていデスクトップアプリの画面から作る方法です。アプリの「ルーティン」の画面で新規作成を選び、手元で動かすかクラウドで動かすかを選ぶ形になっています。クラウドのルーティンはターミナルから対話で作ることもでき、ウェブ・アプリ・ターミナルのどこで作っても同じアカウントに保存されます。対話なしモードを外の仕組みから呼ぶ方法は、呼び出す側の設定を書く必要があるので、情シスや開発の担当と組むのが現実的です。
放置しても止まらない形をつくる5工程
定期実行を組む作業は、時刻と指示を入れる画面の操作だけに見えます。けれども放置しても止まらない形にするには、その前後に決めることがあります。次の5つの工程の順に進めると、抜けが出にくくなります。
1回の実行で始まって終わる大きさに仕事を切る。前回の実行の続きを前提にしない。
PCを閉じても回す必要があるか、手元のファイルが要るかで、4つの道から選ぶ。
確認待ちで止まらないように許可を整え、同時に、渡しすぎないように範囲を絞る。止める人を決める。
何をもって成功とするかを指示に書き、結果を見に行く場所と、止まったときに知らせる先を1つに決める。
モデルの版、接続先、契約、業務の手順が変わったときに回す短い点検を決め、持ち主を置く。
この順番には理由があります。起動の仕組みを先に選ぶと、仕事の切り方が仕組みの都合に引きずられるからです。たとえば手元のファイルを毎回読む仕事なのに、PCを閉じても回したいという理由でクラウドを選ぶと、手元のファイルが届かず最初から動きません。仕事を先に切り、その仕事に合う仕組みを後から選ぶのが原則です。
もう1つ、工程3と工程4は組む前に決めます。動かしてから権限や通知を足すと、最初の数日は確認待ちで止まったり、止まっても誰にも知らせが行かなかったりします。定期実行で最初に起きる事故の多くは、この2つの工程を後回しにしたことから生まれます。
工程1:任せる仕事を1回で終わる単位に切る
最初の工程は、定期実行に載せる仕事を、1回の実行で始まって終わる大きさに切ることです。公式ドキュメントでは、ルーティンは実行のたびに新しいセッションを作り、リポジトリも毎回、既定のブランチから新しく複製すると説明されています。デスクトップの定時タスクも、予定の時刻になると新しいセッションを立ち上げます。つまり毎回の実行は前回の会話を覚えていないので、「昨日の続きから」という指示は通じません。
続きが必要な仕事は、続きの情報を会話の外に置きます。前回どこまで処理したかをファイルや表に書き残させ、次の実行はそれを読んでから始める形です。毎朝のレポートなら、集計の対象期間を「前日の0時から24時まで」のように日付で決めておけば、前回の結果を覚えていなくても毎回同じ仕事として完結します。何日分を処理したかを記録から読み取れる形にしておくと、止まった翌日にどこからやり直せばよいかもすぐに分かります。
1回の大きさにも気を配ります。対話なしモードの公式の説明には、背景で動かした処理を待つ時間に既定で10分の上限があり、それを超えると途中の結果を捨てて終わると書かれています。仕組みごとに上限は違いますが、長く走るほど途中で切れる機会が増えるのは共通です。夜のうちに何十件も処理したい仕事なら、1回で全部を片付けさせるより、件数を区切って何回かに分けるほうが止まりにくくなります。
やり直したときに二重に送信や登録が起きないかも、この段階で確かめます。どこまでなら安全にやり直せるかの線引きはやり直す範囲を決める記事で扱っているので、ここでは「1回の実行の中で、外に何かを出す操作がいくつあるか」を数えておくだけで十分です。外に出す操作が多い仕事ほど、工程3の承認の線が重くなります。
工程2:起動の仕組みを選ぶ
仕事を切ったら、4つの道から起動の仕組みを選びます。判断の軸は2つです。1つは、PCの電源が切れていても回す必要があるか。もう1つは、手元のPCにあるファイルや道具が要るか。電源が切れていても回したく、手元のファイルが要らないならクラウドのルーティン、手元のファイルが要るならデスクトップの定時タスクが基本になります。
クラウドのルーティンは、公式の説明では毎時・毎日・平日・毎週の予定のほか、決めた時刻に1回だけ走らせることもできます。最短の間隔は1時間で、それより短い間隔は受け付けられません。また、ちょうど9時のように0分に置くと数分遅れて始まることがあるので、時刻に近く始めたいなら9時7分のように少しずらすよう勧めています。社内のファイル置き場ではなくギットハブのリポジトリから材料を取る形になるため、材料をリポジトリに置けない仕事には向きません。
デスクトップの定時タスクは、手元のフォルダを直接扱え、最短1分の間隔で組めます。その代わり、アプリが起動していてPCが起きているときにしか動きません。セッション内のループ機能は、作業中の見張りのような短い用途のためのもので、業務の定期実行には向きません。理由は次の節で触れます。対話なしモードは、社内のサーバーや既存の自動処理の仕組みにすでに定時実行がある場合の選択肢です。
迷ったときは、止まったときに困る度合いで決めます。毎朝必ず届かないと業務が止まるレポートを、担当者のノートPCで回すのは危うい選択です。逆に、担当者が自分の作業を楽にするための下準備なら、手元のPCで回して、止まった日は手で補うくらいの割り切りでも足ります。どちらに当たるかは、仕事の持ち主が決めます。
手元のPCで回すときの落とし穴:スリープ・取り戻し・7日の期限
デスクトップの定時タスクでいちばん多い止まり方は、PCが眠っていることです。公式ドキュメントは、PCがスリープしている間に予定の時刻が来るとその回は飛ばされると書いています。設定で何もしていないときのスリープを防ぐことはできますが、ノートPCの蓋を閉じればやはりスリープします。夜に回すつもりの仕事が、蓋を閉じて帰った日には一度も走らないということです。
飛ばされた回の扱いにも癖があります。アプリの起動時やPCの復帰時に、過去7日の取りこぼしを確かめ、最も新しい1回分だけを取り戻しとして実行し、それより古い分は捨てます。6日分を取りこぼした毎日のタスクは、復帰したときに1回だけ走ります。公式は、9時の予定のタスクが、1日中眠っていたPCでは夜11時に走ることがあると例を挙げ、時刻が大事なら指示の中に歯止めを書くよう勧めています。たとえば「当日分だけを対象にし、夕方を過ぎていたら処理せず、取りこぼした旨だけを残す」と書いておけば、夜遅くに古い前提で処理が走る事故を防げます。
ほかにも、前の回がまだ走っている、別の定時タスクが動いている、といった理由で飛ばされることがあり、タスクの履歴には飛ばした回とその理由が残ります。また既定では、作業フォルダのその時点の状態、つまり保存前の変更も含めて対象にするので、担当者が昼間に触りかけたファイルを夜のタスクが読む、ということが起きます。作成時に、実行ごとに作業用の複製を用意する設定を選べるので、手元で作業しているフォルダを定時タスクにも使うなら、この設定を検討します。
セッション内のループ機能は、さらに短命です。セッションを閉じれば止まり、繰り返しの予定は作成から7日で自動的に消えると公式に書かれています。止まっていた間の取りこぼしを取り戻す仕組みもありません。忘れられたループが際限なく回らないための作りなので、業務として毎日回す仕事をループ機能に載せると、1週間後に黙って止まることになります。
工程3:確認待ちで止まらないための権限の決め方
3つ目の工程は、無人で走るための権限を決めることです。クロードコードは、ファイルの書き換えや命令の実行の前に、使う人に許可を求める作りになっています。人が見ている対話なら問題ありませんが、定期実行では許可を求めた時点で、答える人がいません。デスクトップの定時タスクについて公式は、手動で承認するモードのタスクが許可のない道具を使おうとすると、承認されるまで実行が止まり、セッションは後で答えられるようにサイドバーに残ると説明しています。
公式が勧める防ぎ方は、タスクを作ったらすぐに「今すぐ実行」を押して、出てきた許可の求めを見ながら、1つずつ「常に許可」を選ぶことです。こうしておくと、以後の実行では同じ道具を承認なしで使えます。許可した道具の一覧はタスクの詳細画面で見直し、取り消すこともできます。最初の1回は必ず人が見ている時間に走らせるのが、確認待ちで止めないための最も確実な手順です。
ただし、常に許可を選べない道具もあります。外部とつなぐ道具のうち、毎回人の操作を求めるよう印が付いたものは、呼ぶたびに承認を求め、常に許可の選択肢が出ません。公式は、こうした道具を呼ぶ実行は毎回止まると書いています。定期実行に載せる仕事の中に、この種の道具が混ざっていないかを、最初の1回で確かめておきます。
対話なしモードを外から呼ぶ場合は、止まり方が逆になります。承認する相手がいない実行では、確認が要る操作は拒否されて、処理は先へ進みます。定時の仕事のために確認を出さないことをはっきり指定する方法も用意されています。止まらない代わりに、必要な操作が拒否されたまま、できなかったことを抱えて最後まで走るので、工程4の完了の判定がないと失敗に気づけません。
クラウドで回すなら、渡す範囲を絞り、止める人を決める
クラウドのルーティンには、確認待ちで止まる問題がありません。公式ドキュメントによると、ルーティンには権限のモードを選ぶ欄がなく、命令の実行、リポジトリに置いたスキルの利用、つないだコネクタ(外部のサービスとの接続)の呼び出しを、一部の公開の操作を除いて承認を待たずに行います。止まらないということは、何をしてよいかを、実行の前に渡す範囲だけで決めるしかないということです。
気をつけたいのは既定の状態です。ルーティンを作ると、そのアカウントでつないでいるコネクタがすべて含まれた状態になり、含まれたコネクタの道具は書き込みも含めて承認なしで使えると公式は書いています。さらにルーティンは個人のアカウントに属し、ギットハブへの記録は本人の利用者名で、社内チャットへの投稿や課題管理の登録も本人の連携アカウントで行われます。ルーティンがしたことは、すべて作った本人がしたことになるのです。使わないコネクタは作成の画面で外し、リポジトリも必要なものだけを選びます。
書き出し先にも線を引けます。ルーティンは既定では「クロード」で始まる名前のブランチに作業を書き出し、どのブランチに書き込めるかはギットハブ側のブランチ保護で制御するよう案内されています。通信も、既定の環境では許可された宛先の一覧にあるものだけに通り、それ以外は拒否されます。社内のサービスに届かせたいときは宛先を足しますが、足すほど届く範囲が広がるので、足した宛先と理由を記録に残します。
止める手段と、止める人も先に決めます。ルーティンの詳細画面には予定を一時停止するスイッチがあり、法人向けの契約では、組織のオーナーが管理画面からメンバー全員のルーティンを止められます。公式によれば、止めると既存のルーティンも動かなくなります。問題が起きたときに、作った本人が不在でも誰がこのスイッチを押せるのかを決めておかないと、止めるべき実行が止められないまま回り続けます。
工程4:完了の判定を指示に書く
4つ目の工程は、何をもって終わったとするかを決めることです。公式ドキュメントは、ルーティンは自律して走るので、指示は自己完結させ、何をするかと、何をもって成功とするかを明示するよう書いています。人が見ている対話なら、途中で「ここで終わりでいいですか」と聞かれても答えられますが、定期実行では終わりの条件が書かれていなければ、AIが自分で終わったと判断した時点が終わりになります。
完了の条件は、手順ではなく確かめられる状態で書きます。「レポートを作る」ではなく、「前日分の件数が元の表の件数と一致し、指定の置き場所に日付入りの名前で保存され、保存した場所を記録に書いた状態」と書きます。条件のうち1つでも満たせなかったら、満たせなかった項目と理由を書いて終えるよう指示しておくと、途中で止まった回も「何ができなかったか」が残ります。
ここで大事なのは、作った本人であるAIに出来を採点させないことです。AIが「完了しました」と書いても、それは条件を満たした証拠になりません。件数の照合、置き場所にファイルがあるかの確認のように、機械で確かめられるものは機械で確かめる形にし、中身の良し悪しは人が見ます。完了の判定を、作業をしたAIの自己申告だけに頼らないことが、正常に見える失敗を減らします。
クロードコードには、処理の区切りで決まった処理を挟むフックという仕組みもあります。公式の説明では、応答を終えるときに動くフックは、終了を止めて作業を続けさせることができます。完了の条件を機械で確かめ、満たしていなければ終わらせない、という使い方ができるということです。ただし設定には知識が要るので、エンジニアでない部門では、まず指示の中に完了の条件を書くところから始め、フックは開発の担当と相談して足します。
記録と通知:結果を見に行く場所を1つに決める
完了の条件を書いたら、結果をどこに残し、止まったときに誰に知らせるかを決めます。仕組みごとに結果の残り方は違います。ルーティンは実行ごとにセッションが作られ、何をしたかを後から開いて読めます。デスクトップの定時タスクは、走るとPCに通知が出て、サイドバーの専用の欄に新しいセッションが並びます。対話なしモードは、成功すれば終了コード0、失敗すれば0以外で終わり、ログイン切れのような失敗は結果として出力されると公式に書かれています。
どの仕組みでも、結果を見に行く場所を1つに決めて、毎朝そこを見る人を決めるのが基本です。仕組みの画面、保存先のフォルダ、社内チャットと、結果が散らばっていると、見る人は1か所しか見なくなります。完了の条件で決めた「保存した場所を記録に書く」先を、そのまま毎朝見る場所にすると、見る場所が1つにまとまります。
通知は「終わった」より「終わらなかった」を知らせる形にします。毎日「完了しました」と届く通知は、数日で読まれなくなります。届かなかったら異常、という形にするなら、届かないことに気づく人を決めておく必要があります。クロードコードのフックには、許可の求めや待機の通知が出たときに動くものや、API の異常で処理が終わったときに動くものもあり、こうした場面で社内の連絡先に知らせる仕組みを組めます。
費用の記録も残します。対話なしモードでは出力に費用の概算を含められ、ルーティンは契約の利用量を対話と同じように消費すると公式に書かれています。毎日の実行で費用が少しずつ膨らんでも、見る人がいなければ月末まで分かりません。止まったかどうかと同じ場所に、1回あたりの費用の目安を並べておくと、異常な回に気づきやすくなります。
工程5:版と業務の変化に合わせて点検する
5つ目の工程は、組んだ後の点検です。定期実行が止まるきっかけの多くは、組んだ日には存在しなかった変化です。ルーティンは作成の画面で選んだモデルを毎回の実行で使うと公式に書かれていますが、提供元がモデルを入れ替えたり、自分で新しいモデルに切り替えたりすれば、同じ指示でも動き方が変わることがあります。以前は黙って補っていた手順を飛ばす、逆に慎重になって途中で止まる、ということが起こり得ます。
接続や契約の変化でも止まります。公式によると、ルーティンの実行の時点でギットハブとの接続が切れていると、最大72時間は実行を飛ばし、その間につなぎ直せば自動で再開しますが、72時間を過ぎるとルーティン自体が止まり、つなぎ直したうえで手で入れ直す必要があります。契約の利用上限に達した場合も、超過分の利用を有効にしていなければ実行は拒否され、契約を一時停止すれば保留になります。指示もモデルも変えていないのに止まるのは、たいていこの種の変化です。
点検は、変化が起きたときに回す短い確認として決めておきます。モデルを変えたとき、接続先のサービスや社内の表の形式が変わったとき、業務の手順が変わったときに、「今すぐ実行」で1回走らせ、完了の条件をすべて満たすかを人が確かめます。決まった周期でも、月に1回は履歴を開き、飛ばされた回や失敗した回がないかを見ます。版が変わったときの検査の考え方はハーネスエンジニアリングの記事で、止まった自動化をどこから直すかと合わせて整理しています。
点検には持ち主が要ります。定期実行1本ごとに、点検の持ち主を1人決め、作った人と同じでなくてもかまいません。作った人が異動した瞬間に、誰も中身を知らない定期実行が残るのが、放置の始まりだからです。定期実行で動かしているスキルも同じように壊れるので、スキル側の点検はスキルが壊れる原因の記事を合わせて読んでください。
放置した定期実行が止まる原因と、症状からの当たりの付け方
ここまでの内容を、止まったときに逆から引けるように並べ直します。症状から原因の見当をつけ、どの工程に戻ればよいかを示したのが次の表です。原因は1つとは限らないので、上から順に確かめます。
| 症状 | まず疑う原因 | 戻る工程 |
|---|---|---|
| ある日から結果が一度も届かない | PCのスリープ、ギットハブの接続切れ、ループ機能の7日の期限、利用上限 | 工程2・工程5 |
| 結果が届く日と届かない日がある | 蓋を閉じた日に飛ばされている、前の回がまだ走っている | 工程2 |
| 実行は残っているが途中で止まったまま | 手動承認のモードで許可の求めに答える人がいない | 工程3 |
| 一覧は正常なのに中身が空、または一部だけ | 必要な操作が拒否された、通信が遮断された、完了の条件が書かれていない | 工程3・工程4 |
| 夜遅くに古い日付で処理が走った | 取りこぼしの取り戻し実行に、時刻の歯止めがない | 工程2・工程4 |
| 前は動いていたのに手順を飛ばすようになった | モデルの版が変わり、指示の解釈が変わった | 工程5 |
表を使うには、記録が残っている必要があります。止まったときにまず開くのは、ルーティンなら実行のセッション、デスクトップの定時タスクならタスクの履歴、対話なしモードなら終了コードと出力を残した記録です。ルーティンについては、ターミナルから「今朝の実行で何もしなかったのはなぜか」と尋ねると、直近の実行の状態と記録を読んで、道具の失敗や拒否された許可を説明してくれる機能も公式に紹介されています。
よくある止め方をまとめると、次のようになります。どれも組んだ日には問題が出ず、数日から数か月後に表に出るのが共通点です。
- 担当者のノートPCで毎朝のレポートを回し、出張や休暇で蓋を閉じた日に止まる
- 手動承認のモードのまま定時タスクを作り、最初の1回を見ずに放置する
- 毎日の仕事をセッション内のループ機能に載せ、7日後に予定が消える
- ルーティンを作るときに既定のコネクタを外さず、使わないサービスへの書き込みまで許したままにする
- 完了の条件を書かず、一覧の緑の表示だけを見て動いていると判断する
- 作った人の異動後、点検の持ち主を決めないまま回し続ける
エンジニアでない部門で回すときの線と、情シスとの取り決め
クロードコードの定期実行は、画面の操作で組める部分が増え、エンジニアでない部門でも手が届くようになりました。それでも、組めることと、部門だけで回してよいことは別です。手元のPCの定時タスクは、そのPCの中にあるファイルや、そのPCからつながる社内のサービスに、作った人の権限で触れます。クラウドのルーティンは、作った人のアカウントで外部のサービスに書き込みます。どちらも、部門の外に影響が出る可能性があります。
情シスとは、組む前に少なくとも次のことを取り決めておきます。どの方式を使ってよいか、どのコネクタやリポジトリを渡してよいか、外部への送信や公開を伴う仕事を定期実行に載せてよいか、利用上限と費用の上限、止まったときの連絡先と、作った人が不在のときに止める権限を持つ人です。法人向けの契約では組織のオーナーがルーティンを全員分止められるので、その権限を誰が持つかも確認します。
部門の中で任せやすいのは、社内の資料を読んで集計や要約の下書きを作り、決まった場所に置くまでの仕事です。外に何かを送る、登録する、公開する操作は、定期実行の中では行わず、下書きを置くところで止めて人が確かめてから出す形にすると、部門の中で回せる範囲が広がります。夜に回してよい仕事と回してはいけない仕事の型は、冒頭で触れたバックグラウンドエージェントの記事で詳しく整理しています。
もう1つ決めておくのは、止まったときに誰が直すかです。作った本人しか中身が分からない定期実行は、本人が忙しくなった時点で止まったままになります。直す人を社内に置けるなら点検の持ち主と同じ人に、置けないなら外の力を借りる前提で、業務の手順と指示と記録を誰でも読める形で残しておきます。止まった仕組みを業務と一緒に見直して作り直す相談を、外部の伴走の枠で受けている会社もあり、デボノもその1つです。
AIに任せず、人が決める4つのこと
定期実行は、AIが人の代わりに仕事を進める仕組みですが、仕組みの外側の線は人が引きます。クロードコードの定期実行で、AIに決めさせず人が決めるのは次の4つです。
- 定期実行に載せてよい仕事。止まったときに業務が止まる仕事か、手で補える仕事かを、仕事の持ち主が決める
- 与える権限の範囲。どの方式を使い、どのフォルダ、リポジトリ、コネクタを渡すかを、情シスと決める
- 止まったときの連絡先と止める権限。誰に知らせ、作った人が不在のときに誰が止めるかを、実行の前に決める
- 外に出る操作の承認。送信・登録・公開は定期実行の中で行わず、人が確かめてから出す
4つに共通するのは、AIに決めさせると、間違えたときに誰も責任を持てない点です。AIはどの仕事を定期実行に載せるべきかを提案できますし、指示の下書きや完了の条件の案も作れます。けれども、提案や下書きを採用するかどうか、どこまで渡すかは、結果に責任を持つ人が決めます。
とくに4つ目は、クラウドのルーティンで重くなります。ルーティンは承認を待たずにコネクタの書き込みまで行えるので、外に出る操作を指示に含めれば、そのまま実行されます。公式の説明でも、ルーティンの起動は保存した指示を実行するだけで、実行中の操作への承認や同意の代わりにはならないとされています。外に出す操作を承認する人を、指示の中ではなく仕組みの外に置くことが、無人の実行で事故を防ぐ最後の線になります。
よくある質問
PCを閉じていても回したいときは、どれを選べばよいですか
2026年10月時点の公式が並べる3つの方式のうち、PCの電源が要らないのはクラウドのルーティンだけです(ギットハブの自動処理から対話なしモードを呼ぶ方法もありますが、設定に開発の知識が要ります)。ただし毎回リポジトリを新しく複製して動くので、手元のPCにあるファイルは使えません。材料をリポジトリに置けない仕事なら、手元のPCで回し、スリープしない設定と、取りこぼし時の歯止めを指示に書く形を選びます。
最初の1回がうまく動けば、あとは放置してよいですか
最初の1回は、許可の求めを潰すために必要な確認で、放置してよい証拠にはなりません。モデルの版、接続、契約、業務の手順が変わるたびに止まる可能性があるので、変化が起きたときと月に1回は、履歴を開いて飛ばされた回や失敗した回がないかを確かめます。
エンジニアでなくても定期実行を組んでよいですか
画面の操作で組める範囲は増えていますが、組んでよいかは会社の取り決め次第です。使ってよい方式、渡してよい接続先、外に出る操作の扱い、止める権限を持つ人を情シスと決めたうえで、社内の資料を読んで下書きを置くところまでの仕事から始めるのが安全です。
ループ機能で毎日の仕事を回すのはだめですか
公式の説明では、ループ機能はセッションを閉じると止まり、繰り返しの予定は作成から7日で消えます。作業中の見張りには便利ですが、毎日の業務には、デスクトップの定時タスクかクラウドのルーティンを使います。
止まった定期実行を直す人が社内にいないときは
ここまでの5工程は、組む前に決めておけば防げることばかりです。ただ実際には、すでに組んで回っていた定期実行が、モデルの更新や接続先の変化をきっかけに止まり、作った人も異動していて誰も直せない、という相談のほうが多くあります。止まる原因はモデルそのものより、指示・道具・確認・止め方・記録といった周りの仕組みにあることが多く、そこを業務と一緒に見直せば作り直せる場合があります。
社内に直す人を置けないなら、業務を見ながら一緒に点検し、作り直す外部の伴走を使う手もあります。相談だけで終わる支援でも、要件を固めてからの本番開発でもなく、その間で実際の業務と仕組みを見る形の支援です。
デボノのコンサルタントとAI実務メンバーが同じチームで、担当者と一緒に実際の業務(画面・エクセル・既存のサービス・資料)を見ながら、「業務を見る→なぜを掘る→解き方を決める→そのまま作る→使って直す」の順で進めます。業務のスキルやテンプレート、簡易ツール、小規模な検証、AIエージェントを月額の中で作り、使ってもらいながら直し、月次の活用レポートで振り返ります。
放置して動かなくなった定期実行やスキル、エージェントを、業務と一緒に見て、指示・道具・確認・止め方・記録から点検して作り直す、という相談もこの枠で扱えます。月額数十万円程度で、1か月の単月から始められ、定例の頻度と実務支援の時間(月15・30・50時間まで)でライト・アドバンス・フルの3プランがあります。完成責任を伴う本番開発や本番運用が必要になったテーマは、価値を確かめたうえで別のプロジェクトに切り替えます。
まとめ
クロードコードの定期実行は、組めば回り続けるものではありません。人が見ていない時間に走るので、止まったときに誰も気づかない作りがいちばんの事故になります。任せる仕事を1回で終わる単位に切り、PCの電源と手元のファイルの要否で起動の仕組みを選び、確認待ちで止まらず渡しすぎない権限と止める人を決め、完了の条件と結果を見る場所を作り、版と業務の変化に合わせて点検する。この5工程を踏めば、止まっても翌朝には気づき、どこから直せばよいかが分かる形になります。指示の下書きや完了の条件の案はAIに作らせてかまいませんが、載せてよい仕事、渡す権限、止める人、外に出る操作の承認は人が決めます。まずは手元で回っている定期実行を1本選び、最後に成功した日付と、止まったときに誰が気づくのかを確かめるところから始めてください。
- クロードコードの定期実行の仕組み(ルーティン、デスクトップの定時タスク、ループ機能、対話なしモード、フック)の記述は、2026年10月6日に公式ドキュメントで確かめた範囲に基づきます。ルーティンは研究段階の提供で、挙動や上限が変わることがあります。組む前に最新の公式ドキュメントを確かめてください
- 利用できる契約、利用上限、組織での停止の設定は、契約の種類や管理者の設定によって異なります
- 情シスとの取り決めや人が決める範囲は、運用を設計するときの考え方の一例です。実際の運用は、自社の規程と情シスの判断に従ってください
※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。
AI活用を戦略に落とす前に、まずは導入・定着から始めませんか?
デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。
