⚡監視係は Luna⚡ Copilot Scheduler で 20 分ごとに確認し、必要なときだけ Opus を起こす🚀

Last updated at 2026-09-30Posted at 2026-09-30

こんにちは、「状態を見るだけなのに、最上位モデルを回すのはもったいない」と思っていたアーキテクトのやまぱん！です 😅

補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

VS Code の GitHub Copilot Chat で、20 分ごとの状態確認を GPT-6 Luna に任せ、必要なときだけ Claude Opus 5.5 の新規セッションを起動する仕組みを、Copilot Scheduler で動かしています。Copilot Scheduler は VS Code の標準機能ではなく、私が作って公開している拡張機能です。この仕組みの味噌は、Copilot Scheduler を GitHub Copilot Chat からツールとして呼び出し、新しいセッションを起動できる点です。この記事の運用は監視側ですが、同じ道具で、Ralph ループのような「同じプロンプトを回し続ける」構成も組めると考えています。判定そのものは Python スクリプトが行い、Luna はその出力 1 行を読んで分岐するだけです。1 回の確認は約 1 credit（約 1.5 円）です。この記事では、構成、最初につまずいた点、実測した費用を書きます。

TL;DR

別のエージェント（Codex）の作業が 15 分以上止まっていないかを、20 分ごとに確認する仕組みです。判定は Python スクリプトが行い、Luna は出力 1 行（READY / WAIT / TAKEOVER / DONE）を読んで分岐するだけです。LLM に判定はさせません
Opus 5.5 は TAKEOVER のときだけ、scheduler_run_task で新しいセッションとして起動します。Opus 5.5 は Copilot Pro では選べず、Pro+ 以上が必要です。Luna 側の確認だけなら Pro でも使えます
Copilot Scheduler は、私が作って Marketplace で公開している拡張機能です（VS Code の標準機能ではありません）。Copilot Chat からツールとして呼び出して新しいセッションを起動できるのが味噌で、スケジュールの登録も自然言語で頼めます（私はもう手動で登録していません）。同じ発想の機能は、GitHub Copilot app（すべてのプランで使えます）と Microsoft Scout（Frontier プレビューで、管理者側の設定が要ります）にもあります
確認 1 回は中央値で約 0.99 credits・約 21 秒・LLM 呼び出し 2 回（24 回の自動実行の実測）。20 分間隔だと月に約 2,100〜2,500 credits で、Pro の付帯枠（基本 1,000 + flex 500 = 1,500）を超えます。間隔を 40 分にすると約 1,070、90 分にすると約 475 credits です
Opus は 1 回約 905 credits（確認 900 回分以上）かかるので、起動は 90 分間隔、8 回までに絞り、進行中は待たせています
最初の自動 15 回は Command produced no output で判定不能のまま止まりました。ファイルの再読とハートビート出力で解消しています
まだ確認していないこと: 再起動・スリープ復帰後の挙動、請求額との対応、権限の技術的な制限

背景: 状態を見るだけに、最上位モデルは要らない

見ているのは、別のエージェント（Codex）が担当している作業が 15 分以上止まっていないか、です。状態を見るだけの判断に最上位モデルを回すのはもったいないので、軽量モデルに任せ、重い判断が要るときだけ上位モデルを使う分け方にしました。

Luna の位置づけは「GitHub Copilot のモデル選び 2026/09 版」に書いています。少し前のフロンティア級モデル（旧 GPT-5.5、旧 Claude Sonnet 5）と同程度の Artificial Analysis Intelligence Index を、1 タスクの実測費用で約 40〜70 分の 1 で出しています（第三者の指標です。7 月の GPT-5.6 Sol や Claude Opus 5 には届きません）。

Copilot Scheduler とは（私が作った拡張機能）

VS Code に標準で入っているものではありません。GitHub Copilot のプロンプトを Cron 式で予約実行する、私の自作拡張機能で、Marketplace（yamapan.copilot-scheduler）で公開しています。この記事の運用では 1.7.5 を使いました。

この仕組みで使う機能は次の 5 つです。

Cron 式でのスケジュール
タスクごとのモデル指定
タスクの有効 / 無効
手動実行（上位モデル側を Luna から起動するのに使います）
GitHub Copilot Chat からのツール呼び出し（scheduler_run_task など）。タスクの作成・更新・削除・有効 / 無効・手動実行・一覧の照会が、ツールとして用意されています

味噌は、最後の 1 つです。ツールとして呼び出せるので、実行中のセッションから別の新しいセッションを起こせます。決まった時刻に処理を起こすほか、必要なときにセッションを増やすこともできます。

インストールと設定は、Marketplace のページからできます。ここでは、この仕組みに必要な部分だけを扱います。

もう 1 つのいいところは、設定を自然言語で頼めることです。Copilot Chat に「こういうタスクを、この時間に、このモデルで動かして」と伝えれば、タスクを作れます。私は、スケジュールをもう手動で登録していません。作成のときに指定できるのは、プロンプト、Cron 式か 1 回だけ実行する日時、モデルと reasoning effort、チャットセッション（新規か継続か）、実行してよい時間帯、1 日の実行回数の上限などです。1 回だけ実行するタスクは、実行後に無効化するか削除するかも選べます。画面で Cron 式を組む必要はありません。呼び出されたエージェントが状況を見て、次のタスクを 1 回だけ動かす使い方も、Cron 式で回すスケジュールも、同じ仕組みで扱えます。

全体像

図: 筆者作成。

ポーリング側のタスクは Luna（reasoning effort は low）で、cron は */20 * * * *、有効にしています
上位側のタスクは Opus 5.5（reasoning effort は high）で、無効のままです。Luna からの起動専用になっています
モデルの指定はタスク定義側に持たせています。プロンプトの frontmatter には model を書いていません
引き継ぎは会話ではなく、固定プロンプトと handoff 文書などのファイルで行います

Scheduler が起動するのは Copilot のプロンプトなので、スクリプトを実行して結果で分岐できる程度のモデルが要ります。それを、安い Luna に任せています。

実装

ポーリング側（Luna）

現行版は、スクリプトの出力をファイルに書いて読み直し、run_id を付け、実行中はハートビート（動いていることを示す短い出力）を出します。この形は、後ろの「つまずき」への対処です。

Luna が実際に呼んだのは、スクリプトの実行、ファイルの読み取り、scheduler_run_task の 1 回だけでした。

判定スクリプト

判定は Luna ではなく、Python スクリプトが行います。出力は 1 行で、READY / WAIT / TAKEOVER / DONE のいずれかです。現行版は、担当の作業が 15 分以上止まったかを見ます。起動を控える条件（WAIT になる場合）は、次の「起動の抑止」で書きます。

上位モデル側（Opus）

無効にしておいたタスクを、Luna が scheduler_run_task で 1 回だけ起動します。Opus は新しいセッションで始まり、会話は引き継ぎません。必要な状況は、固定プロンプトと handoff 文書で足りています。

起動の抑止

Opus は 1 回で確認 900 回分以上かかるので、起こす回数の管理が費用に直結します。起動の状態は、ゲートの JSON で管理しています。

前回の起動から 90 分未満は WAIT
起動は 8 回まで
進行中のレビューがあれば WAIT

自動で TAKEOVER になった中に、不要な起動（空振り）は確認できた範囲で 0 件でした。検知漏れは、正解のデータがないので判定できません。

つまずき: 最初の 15 回は判定不能だった

運用を始めた最初の自動 15 回は、ターミナルが Command produced no output を返し、READY か WAIT かを判定できないまま止まりました。

対処は、実装の節に書いた、出力のファイルへの書き出しと再読、ハートビートの出力です。

コストの見方

24 回の自動実行の実測は、中央値が約 0.99 credits（最小 0.95、最大 1.92）、約 20.7 秒、LLM 呼び出し 2 回でした。1 credit = $0.01、1 ドル = 150 円とすると、約 1.5 円です。

間隔ごとの月間の目安です。中央値 0.99 credits、1 か月 = 30 日で計算しました。

ポーリング間隔	月間の回数	月間の credits	月間の金額
90 分	480 回	約 475	約 710 円
60 分	720 回	約 710	約 1,070 円
40 分	1,080 回	約 1,070	約 1,600 円
30 分	1,440 回	約 1,430	約 2,140 円
20 分	2,160 回	約 2,140	約 3,210 円
15 分	2,880 回	約 2,850	約 4,280 円

20 分間隔の実測ベースの推定は、最大値が混ざる場合を含めて約 2,100〜2,500 credits です
Opus の TAKEOVER は 1 回約 905 credits（約 1,360 円）です。同じ単価で 8 回起動した場合の目安は約 7,240 credits（約 10,860 円）で、消費 credits の上限を保証する値ではありません

費用は「確認 1 回の単価 × 回数」に、「Opus を起こす回数 × その単価」を足して見積もります。

プランごとの月間の付帯 AI credits（2026/09/30 時点）

20 分間隔は、Pro の付帯枠（月 1,500 credits）を超えます。他のプランではどれだけあるかを、GitHub Docs の値で並べます。

Copilot Pro: 1,500（基本 1,000 + flex 500）。Opus 5.5 は選べません
Copilot Pro+: 7,000（基本 3,900 + flex 3,100）。Opus 5.5 は選べます
Copilot Max: 20,000（基本 10,000 + flex 10,000）。Opus 5.5 は選べます
Copilot Business: シートあたり 1,900（課金単位でプール）。Opus 5.5 は、組織のモデルポリシーで許可されていれば選べます
Copilot Enterprise: シートあたり 3,900（課金単位でプール）。Opus 5.5 は、企業のモデルポリシーで許可されていれば選べます
個人プラン（Pro / Pro+ / Max）は、基本の部分がサブスクリプションの価格と一致し、変わりません。flex は、モデルの価格や効率の変化に合わせて変わり得る部分です（個人向けの課金）
Business / Enterprise は、シートごとの額を課金単位でプールします。100 シートの Business なら、190,000 credits の共有プールです。個人のプランのように「自分のシートの分」だけを使うわけではありません（組織と企業の課金）
どのプランも、未使用分は翌月に繰り越されません。リセットは毎月 1 日の 00:00 UTC です
比べると、この記事の 20 分間隔（約 2,140 credits）は Pro+ の約 3 割、Enterprise のシートあたり額の半分強にあたります（実際の枠は共有プールです）。Opus の TAKEOVER 1 回（約 905 credits）は、Pro の枠の約 6 割です
Opus 5.5 を選べるかは、自記事に書いた確認のとおりです。Free / Student はモデルを手動で選べず、Auto のみのため外しました

間隔と時間帯を見直す

今回は 20 分おきですが、確認 1 回の単価は一定なので、月間の費用は回数にほぼ比例します。間隔を 40 分にすると約 1,070 credits、90 分にすると約 475 credits で、どちらも Pro の付帯枠（1,500）に収まります。

時間帯を絞る方法もあります。Cron 式の時間や曜日の欄のほか、タスクの設定にも、実行してよい時間帯（開始と終了の時刻）と 1 日の実行回数の上限があります。例えば 1 日 12 時間だけを 20 分おきに確認すると、月 1,080 回、約 1,070 credits です（1 日 24 時間の 20 分おきの半分）。この記事の運用では、間隔も時間帯も絞っていません。表とこの見積もりは、中央値 0.99 credits を掛けた計算です。

間隔を長くするほど、作業が止まっていることへの気づきは遅れます。監視対象の性質しだいで、どこまで遅れてよいかを決めてください。

今回の仕組みは Ralph ループに近いのか

「ループ」を使う関連の 2 つを短く整理し、今回の仕組みがどちらに近いかを書きます。

Ralph ループ（英語ページのみ）は、Geoffrey Huntley が 2025/07/14 のブログ「Ralph Wiggum as a "software engineer"」で紹介した手法です。最も素朴な形は、同じプロンプトファイルをエージェント CLI に繰り返し渡す Bash のループ（while :; do cat PROMPT.md | claude-code ; done）です
同じページが示す運用の要点は、1 ループで 1 つのことだけをやる（進行に合わせて緩めてよいとも書かれています）、毎回、計画と仕様のファイルを読み込ませる、テストや型チェックで不正なコードを弾く、の 3 つです。壊れたときは、git reset --hard でやり直すか、プロンプトを直すかを人間が判断するとあります。適用範囲は、筆者自身は既存のコードベースには使わないとしており、新規の立ち上げ向けで 9 割程度までを想定していると書かれています
Loop Engineering（私の記事）は、エージェントに指示する側を卒業し、代わりに指示する仕組みを設計する、という考え方です。Addy Osmani（英語ページのみ）が 2026/06/07 に記事で整理しました

今回の仕組みは、Ralph ループそのものではなく、Loop Engineering の側に近いと考えています。Ralph は作業を進めるループで、次にやることも LLM に選ばせ、前の周回が終わり次第、続けて回ります。今回は作業を進めません。時刻で起動して状態を見て、必要なときだけ上位モデルを起動する、見張りと起動の側です。共通点は、会話ではなくファイルに状態と手順を置き、毎回会話の履歴に頼らずに引き継ぐことです。

Copilot Scheduler なら、Ralph 型のループも組めると考えています。組み方は 2 通りです。1 つは、同じプロンプトを決めた間隔で起動し、計画のファイルを毎回読ませる形です。もう 1 つは、実行中のエージェントが、終わる前に次のタスクを起動する（scheduler_run_task や新しいセッションの起動）つなぎ方で、こちらなら Ralph のように、終わり次第すぐ次へ進めます。ただし Ralph は、外側の Bash ループがエージェントの成否に関わらず次を回すので、セッションが途中で壊れても止まりません。エージェントが次を起動するつなぎ方は、次を呼ぶ前にセッションが壊れると、そこで止まります。そのため、時刻で起動する見張り役（今回の Luna の監視）を外側に置いて、止まっていたら起動し直す構成が要ると考えています。また、実装を回すなら、Ralph の元記事が挙げるテストや型チェックと、実行回数の上限（タスクの 1 日の上限など）が欠かせません。この記事では、Ralph 型のループはまだ試していません。

似た機能との比較: Microsoft Scout と GitHub Copilot app

Microsoft Scout

Microsoft Scout にも、同じ発想の Automations があります。スケジュール実行と条件実行に対応し、一度だけ動かす設定（one-shot）や、reasoning effort とコンテキストサイズの指定もできます（Use Microsoft Scout）。

ただし Scout は Frontier プレビューの機能で、管理者側の設定が必要です。Microsoft 365 管理センターでの Frontier の有効化、Intune ポリシー、管理者の attestation の 3 つに加えて、GitHub Copilot のライセンス（Business か Enterprise）と、GitHub 側で Copilot app のポリシーが有効なことも要ります。アプリを入れただけでは、サインインできません（Admin access overview、いずれもプレリリースのドキュメントで 2026/09/30 時点）。導入のハードルは、Copilot Scheduler より高くなります。VS Code の GitHub Copilot をすでに使っていれば、拡張機能を入れるだけで同じ発想を試せるのが、Copilot Scheduler のいいところです。

GitHub Copilot app

GitHub Copilot app にも自動化（Automations）があり、定期的なエージェントのタスクを保存して、スケジュールまたはオンデマンドで実行できます。アプリはすべての Copilot プランで使えます（Business / Enterprise は、組織側のポリシーが有効であることが前提です）。エージェントが create_session ツールでローカルやクラウドの新しいセッションを作れることも、changelog に書かれています。この点で、Copilot Scheduler と近い使い方ができると考えています。Copilot Scheduler は VS Code の GitHub Copilot Chat 上で動くので、VS Code で運用している人向けです。

2026/09/30 に自分の環境で試すと、create_session でモデルと reasoning effort（GPT-5 mini の low）を指定して、子セッションを作れました。親のターンを終えた後も子は動き続け、終わると完了の通知が親に届いて、親が再開しました（notify_on_idle を once にして作成。子は親から切り離されていませんでした）。

自動化（Automations）についても試しました。自動化の実行の中から create_session を呼んで、子セッションを作れました。自動化の実行が終わった後も子は最後まで動き、完了の通知が自動化の実行セッションに届いて、実行セッションが再開しました。ただし、再開したエージェントは、子の返信本文を取得できませんでした。カスタムエージェントの指定と、自動化へのモデル・reasoning effort の指定もできました。一方、1 回だけ実行する日時の指定は、Automations では使えず、対象は手動、定期実行、5 フィールドの Cron でした。別機能の「セッション自動化」では、1 回だけ実行（once）を指定できました。

注意点とまだ確認していないこと

運用開始は 2026-09-29 16:18Z（JST で 2026/09/30 01:18 頃）で、運用期間は 1 日に満たない短期の結果です
書き込みや git 操作の禁止は、プロンプト上の規定だけです。技術的な制限は確認できていません
再起動やスリープ復帰の後に、ポーリングがどう動くかは確認していません
credits の換算は、1 セッションだけ利用状況のログの copilotCredits と一致を確かめました。請求額との対応は未確認です
プロンプトに秘密情報は入れていません。ログや handoff 文書に載せる情報も、同じ基準で見てください

今後の展望

ここから先は私の見通しです。次の 1 つ目を除いて、まだ試していません。

1 つ目は、新しいセッションの起動です。いまのセッションのコンテキストが増えてきたら、新しいセッションを起動して、続きをそのまま実行させられます。この使い方は、私はすでに実際に使っています。

2 つ目は、Ralph 型のループを Copilot Scheduler で組み、ウォッチャーを付ける形です。Ralph のようなループが動いているかを、Luna のウォッチャータスクに見張らせ、止まっていたら新しいセッションで起動し直す。今回の「Luna が状況を見て、必要なときだけ起動する」を、そのまま Ralph 型のループの監視に使う考えです。

3 つ目は、ゴールを決めたループです。ゴールを設定し、できているかを Luna などで判定し、できていなければ GPT-6.1 Sol や Opus 5.5 を呼んで、もう一度実装させる。達成するまで回し続けるループも組めると考えています。この組み合わせは、まだ試していません。ゴールまで回す考え方は、goal-loop の記事に書いています。

今回は GitHub Copilot 上で動かしましたが、同じ形は他のハーネスや、スクラッチで作ったエージェントにも入れられると考えています。入れるものは 3 つです。① 時刻で起動する仕組み、② 判定を行う決定論的なスクリプト（ルールベースの処理）、③ 判定の出力だけを読んで分岐し、必要なときだけ上位のエージェントを呼ぶ軽量モデル。Copilot Scheduler が担っているのは、①と、③のうち上位を起動する部分です。他のハーネスを選ぶときは、タスクの有効 / 無効や手動起動に当たる機能があるかを、そのハーネスで確認してください。

日常の運用業務を安い軽量モデルで見張り、条件に合ったときだけ上位のモデルが手順書（インストラクション）を読んで対応する。今回の引き継ぎが、会話ではなく固定プロンプトとファイルだったことは、この形に向いています。15 分おきに確認しても、確認だけなら月 4,280 円ほど（前の表）で、上位モデルは必要なときだけ、1 回約 1,360 円で起動します。ただし、今回測ったのは確認 1 回が約 1 credit、Opus 1 回が約 905 credits という差だけです。他のハーネスでの費用は、まだ測っていません。

例として、アラートの一次切り分けや、PR・デプロイ・ログ・拡張機能の更新確認のような定期チェックが考えられます。夜間の監視だけを AI エージェントに一時的に任せる使い方もあります。夜間の時間帯だけ軽量モデルで見張り、エスカレーションが必要なときだけ、そのための別のプロンプトと別のモデルを呼んで、エスカレーションの流れを回す形です。

まとめ

味噌は、Copilot Chat からツールとして Copilot Scheduler を呼び出せ、新しいセッションを起動できることです
設定も自然言語で頼めます。同じ発想の Microsoft Scout より、導入のハードルは低いです
判定はスクリプト、Luna は分岐と起動、Opus は必要なときだけ起動します
費用は「確認 1 回の単価 × 回数」に、「Opus を起こす回数 × その単価」を足して見積もります
Opus は 1 回で確認 900 回分以上かかるので、起動の間隔と回数（90 分間隔、8 回まで）を絞っています。消費 credits を制限する仕組みではないので、見積もりは単価 × 回数で立てます

参考・出典

GitHub Copilot のモデル選び 2026/09 版（Luna・Sonnet 5.5・GPT-6.1 Sol）（Luna の水準と料金の見方）
Copilot Scheduler を作った記事（拡張機能の概要）
Copilot Scheduler（VS Code Marketplace）
GitHub Docs: GitHub Copilot アプリについて（自動化と、すべてのプランで使えること）
github/app: changelog（create_session ツールなど、英語）
Microsoft Learn: Microsoft Scout (Frontier) overview（プレリリースのドキュメント。日本語ページでも本文は英語）
Microsoft Learn: Use Microsoft Scout（Automations）
Microsoft Learn: Admin access overview for Microsoft Scout（管理者側の 2 つのゲート）
AI エージェントを「最後までやり切らせる」 goal-loop という Agent Skill を作った話（私の記事）
TypeSafe AI: Jev（System One）（判断用のモデルの説明、英語ページ。日本語版は未確認）
GitHub Docs: Models and pricing for GitHub Copilot（1 credit = $0.01、モデル別単価）
GitHub Docs: Usage-based billing for individuals（Pro / Pro+ / Max の月間枠）
GitHub Docs: 組織と企業の使用量ベースの課金（Business / Enterprise のシートあたりの額とプール）
GitHub Docs: Copilot のプラン（Pro / Pro+ の違い）
OpenAI: GPT-6 Sol と Luna のご紹介（OpenAI 自身の評価。DeepSWE などでのコスト比較）
Artificial Analysis: LLM Leaderboard（Luna の Intelligence Index と、旧世代モデルとの実測費用の比較）
Anthropic: Claude Opus 5.5（英語ページのみ）
Geoffrey Huntley: Ralph Wiggum as a "software engineer"（2025/07/14、英語ページのみ。Ralph ループの定義と適用範囲）
Addy Osmani: Loop Engineering（2026/06/07、英語ページのみ）
Loop Engineering とは？（私の記事）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up