AIエージェントの稼働が勤務時間を超えるとき：18時間自律エージェントのレビュー設計

夕方4時にリファクタリングを開始し、6時にはノートPCを閉じる。翌朝確認すると、実行が完了しているか、まだ続いているか、あるいは午後9時40分に誰も答える人のいない質問を投げかけて停止しているかのいずれかだ。状況はまったく異なる3つだが、外から見れば一晩中どれも同じように見えていた。

Anthropicは、Claude Opus 5.5 が18時間以上タスクを持続できると述べている。この言葉を文字どおりに受け止めてほしい。ある稼働日の終わりに開始した実行は、翌朝の始業時点でも終わっていない。あなたが不在の11時間もの間、モデルは自律的に判断を下し続けており、誤った判断を防ぐ盾となるのは、退勤前にあなたが書き残した指示だけなのだ。

勤務時間内に収まる実行であれば監視ができる。しかし、退勤時間を超えて動き続ける実行は、「翌日戻って確認するもの」になる。この2つは根本的に異なるシステムであり、ほとんどのチームはいまだに前者の前提で運用を続けている。

要約（TL;DR）

長時間の自律型エージェントの実行とは、人間の不在時にも動き続ける処理のことだ。したがって、エージェント自身で判断できない事柄は、誰も見ていないターミナルのプロンプト表示ではなく、記録された状態として待機させなければならない。これを安全に行うには、3つの条件を満たす必要がある。人間がいなくてもエージェントが適用できる停止条件、実行中や失敗とは明確に区別された「人間待ち」ステータス、そして朝に担当者1名が必ず確認するインボックスだ。エージェントは調査、実行、テスト、レポートを行い、人間は方針を定め、権限を付与し、結果を承認する。Sharkly はこの3つの要素をすべて「タスク（Task）」上で一元管理する。

2026年9月22日に何が変わったのか

2つのAI研究所が同日に新モデルをリリースし、エージェントの稼働時間と実行コストの双方が大きく塗り替えられた。

Anthropicによると、Opus 5.5はOpus 5と比較して実行コストが40%削減され、出力速度が約30%高速化、最大出力トークン数は128kに達し、18時間以上タスクを持続できるという。一方OpenAIは、SolとLunaがそれぞれGPT-5.6のプロモーション価格よりも50%安価であると発表している。「プロモーション価格」という表現はOpenAI自身のものであり、定価ではなく割引価格との比較である点には注意が必要だ。さらにOpenAIは、GPT-6のキャッシュ入力の読み取りが90%割引になること、そして推論の深度（reasoning effort）やツールの利用可否を変更してもキャッシュが無効化されなくなったことを報告している。これはまさに、夜通し稼働するエージェントにとって決定的な意味を持つ。

つまり、エージェントの実行は「長時間かつ安価」に行えるようになったのだ。しかし、人間の勤務時間がそれに合わせて長くなったわけでも、結果をレビューするキャパシティが増えたわけでもない。

レビューの前提が逆転する

実行プロセスを画面越しに見守っているとき、人間自身がそのエラーハンドラーとして機能している。間違ったファイルを開こうとしたら、その場で中断すればよい。その介入はログに記録されることすらない。記録する必要がなかったからだ。

だが夜間には、そうしたリアルタイムの介入は一切期待できない。人間が手動で行っていた修正は、「エージェントにあらかじめ組み込まれたルール」か「処理の停止」のどちらかにならざるを得ない。第3の選択肢はないのだ。長時間稼働するエージェントとは、「放置しても最後まで完了するエージェント」ではない。「人間が寝ている間に、人間が下すべき判断の壁にぶつかるエージェント」なのだ。完了ではなく、停止を前提に設計せよ。

またAnthropicは、Opus 5.5において境界回避（指示の逸脱）の成功率が85%低下したと報告している。しかし、逸脱のリスクが減ったとしても、それは停止条件にはならない。いくら指示に忠実なモデルであっても、深夜2時に発生した疑問を投げかける場所は依然として必要なのだ。

満たすべき3つの必須要件

1. 人間がいなくてもエージェント自身が適用できる停止条件

これには2つの側面がある。プラットフォーム側が強制するハードリミットと、エージェント自身が適用する明文化された条件だ。

ハードリミットは設定による上限を指す。Sharkly Agentには、並列実行タスクの最大数とタスクごとのタイムアウトが、実行単位ではなくエージェント単位で設定されている。タイムアウト値は、「想定される最長実行時間」より長く、「コストとして許容できる最長実行時間」より短く設定する。これはスケジュールではなく、サーキットブレーカー（安全装置）なのだ。

そして明文化された条件こそ、多くのチームが見落としがちなもう半分だ。決して止まらないエージェントは勤勉なのではなく、単に監視されていないだけである。

Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.

When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.

タスクが限定的な変更であり、完了したかどうかを判定できるテストが整っている場合は、タイムアウトを長めに設定するとよい。一方で、タスクが探索的なものである場合や、受け入れ基準があいまいで議論の余地がある場合、あるいは事前確認なしには触ってほしくない領域に波及する恐れがある場合は、1〜2時間にとどめておくべきだ。承認ゲートでは、エージェントが処理に確信を持っている場合であっても停止させるべきポイントについて解説している。

2. 「実行中」とは明確に区別された待機ステータス

Sharklyでは、タスクのライフサイクルステータスとエージェントの稼働状態が別々に記録される。タスクが「In Progress（進行中）」であっても、エージェントの状態は「Working（実行中）」、「Waiting for human reply（人間の返答待ち）」、「Waiting for human review（人間のレビュー待ち）」、あるいは「Error（エラー）」になり得る。さらにその下層にある実行プロセス自体も、Queued、Dispatched、Waiting for local directory、Running、Completed、Failed、Canceledといった独自のステータスを持つ。

これは単なる細かな事務処理のように思えるかもしれないが、夜間に8つのタスクを並行実行してみればその重要性がわかる。この仕組みがないと、朝の9時にボードを見たとき、絶賛編集中のエージェントも、1つの質問の答えを待って11時間前に停止したエージェントも、どちらも同じ「In Progress」と表示されてしまう。どちらの状態なのかを確かめるためだけに、8つのタスクすべてを開く羽目になるのだ。

実行ログがあれば、翌朝に停止の理由を正確に把握できる。なぜその実行がキューに入れられたのか、いつ開始され終了したのか、ツールの呼び出しやランタイムイベント、トリガーの発生元、失敗やキャンセルの詳細などが記録される。前日に何を指示したか記憶が薄れていても、このログを読めば状況が一目でわかるのだ。自前でこの仕組みを構築する場合に何を記録すべきかについては、ステータス、ログ、および失敗シグナルを参照してほしい。

3. 特定の担当者が開くインボックス

責任者の定まっていない待機状態は、永久に放置されることになる。夜間の実行は日中とは異なり、静かに失敗する。その沈黙に気づく人が誰もいないからだ。

SharklyのInboxは、タスクのアクティビティを個人ごとに集約するキューであり、Primaryには人間の対応が必要な通知が集まる。具体的には、あなたの返答待ち、あなたのレビュー待ち、失敗またはブロックされた作業、メンション、あなたへのタスク割り当てなどだ。実行の失敗やブロックの通知は、タスクの全フォロワーではなく担当者に直接届く。そのため、深夜3時に発生した実行失敗も、「全員宛て（＝実質的に誰も見ない）」ではなく、責任を持つ1人の手元に確実に届くようになっている。

朝の業務をスムーズに進めるには、保存済みビュー（Saved View）が2つあればよい。「レビュー待ちのタスク」と、「エージェントに割り当てられ、現在ブロックされているタスク」だ。そして、これらを確認する担当者の名前を明記すること。「チーム全体」という曖昧な主語では、誰もインボックスを開かない。

朝一番に行うルーティン

処理する順番が重要だが、それはカンバンボードが提示する順番とは異なる。

1. まずは「人間の返答待ち」から。質問に答えることで停止していたエージェントが再始動するが、レビューをしても何も動き出さない。もし SH-312 が前夜の午後9時40分から待機しているなら、朝一番にコメントで回答するのが最も手っ取り早い。それにより、同じタスクで後続の実行が即座にキューイングされる。
2. 2番目は「失敗およびブロック」。再試行する前に、実行ログのタイトルと技術的な詳細を確認しよう。単一のHTTPステータスコードは手がかりにすぎず、診断そのものではない。
3. 3番目は「レビュー待ち」。これこそが本質的な作業キューであり、実行コストが安くなるほど膨れ上がる部分だ。
4. 最後は「現在実行中」。そのまま続行させるか、あるいはキャンセルする。一度キャンセルした実行をその場から再開することはできないが、タスクとその履歴は保持されるため、方向性が間違っていると判断したなら躊躇なくキャンセルしてよい。ただし、まずはログを確認すること。

これでは解決できない問題

エージェントの実行時間が長くなったからといって、レビューの手間が減るわけではない。むしろレビューは集中する。18時間稼働した実行は、一晩分の意思決定を凝縮した1つの結果を返してくるが、それを読み、判断し、承認するのは依然として人間の仕事だ。OpenAI自身の研究者たちが、その行き着く先を示している。研究者1人あたりの中央値で1日600ドル以上、上位10%（90パーセンタイル）では1日7,000ドル以上ものAPI推論を実行している一方で、その出力をレビューできる人間の数は変わっていない。OpenAIがこのデータを公表した際、私たちはその試算を行ったが、今回の新モデル発表によっても分母（人間のレビュー能力）は何一つ変わっていないのだ。

コストが下がり、長時間稼働が可能になったことで得られるのは、「より多くの並列試行」であって、「人間が下すべき意思決定の削減」ではない。人間のレビューこそがボトルネックであり、価格の低下はこの問題を好転させる前に、まず悪化させる。自動化はチームの判断が求められる境界で停止し、その際には完全なコンテキストと検証可能な証跡を揃えた成果物として差し出されるべきなのだ。

よくある質問（FAQ）

18時間稼働するモデルの場合、タスクごとのタイムアウトはどのくらいに設定すべきですか？ 「完了させたい実行時間」より長く、「放置して後悔する実行時間」より短く設定してください。通常のタスクならまずは数時間から始め、どうしても一晩かける必要があるタスクに対してのみ、エージェント単位で制限を延ばすとよいでしょう。タイムアウトは無限ループに陥った処理を打ち切るためのものであり、適切な作業にどれだけの時間をかけるべきかを決めるものではありません。

深夜2時にエージェントが投げかけた質問はどうなりますか？ ターミナルのスクロールバックに埋もれる1行ではなく、「人間の返答待ち」ステータスとして記録され、担当者のInboxにアイテムとして届くべきです。現在の環境でそうした質問が見失われてしまうなら、タイムアウトを延長する前にまずその運用ギャップを解消してください。

これからの指針

この問題の本質となる仕組みを提供しているベンダーは、まだどこにも存在しない。真に重要なのは「停止した処理がどこに届くか」、そして「朝の業務を誰が引き受けるか」だからだ。この課題はClaude CodeでもCodexでも、その他あらゆるツールでもまったく同じである。だからこそ、オーナーシップは特定のベンダーのセッション内ではなく、タスクレベルで管理されるべきなのだ。

もしすでにエージェントを夜間に稼働させているなら、検証方法は簡単だ。朝9時にカンバンボードを開き、「思考中のエージェント」と「昨晩から待機し続けているエージェント」が区別できているか確認してほしい。もし区別できていないなら、真っ先に改善すべきはそこだ。そしてそれこそがSharklyが担うレイヤーでもある。依頼からリリースに至るまで、タスクが目標、実行状態、ブロッカー、結果、そして人間の意思決定をすべて保持するのだ。