Opus 5.5を夜間に放置運転するとき、止まらないための設定6選

夜のうちにOpus 5.5へ長い作業を預けたのに、朝ログを開いたら「次は残りの2件に進みます」と書いたまま止まっていた、という放置運転の止まり方を見たことはありませんか？ APIと自作のハーネスで回している人向けに、Anthropic公式のプロンプトガイドから止めないための設定を6つ拾い、走らせる前、走行中、朝の確認の順に並べ直しました。止まったことより、止まったと朝まで気づかないほうが怖いんですよね。

Opus 5.5の放置運転は、どこで止まるのか？

夜間バッチの障害は、まず止まり方で切り分けます。朝に見える症状から、効く設定を逆引きできるようにしておきます。

あなたの朝のログでは、どの行が多いでしょうか？ どれもAPIと自作ハーネス向けの設定で、Claude Codeのような製品経由では手を入れられない項目もあります。

走らせる前に決める、Opus 5.5の設定2つ

1. effortは明示して、mediumから測る

Opus 5.5のeffortの既定は medium で、Opus 5の high から1段下がっています。既定に任せず明示し、自分の評価で複数のレベルを試すのが公式の推奨です。xhigh と max は、品質が上がると測って確かめた作業だけに使います。

夜間に効くのは max_tokens のほうです。思考は中身が返ってこなくても max_tokens を消費するので、思考なしのOpus 5に合わせた上限のままだと、返答が途中で切れることがあります。エージェント型のコーディングで長くなるターンには、モデルの上限である128,000でうまく動いたとAnthropicのテストで報告されています。

リクエストごとにトップレベルの effort を変えるとプロンプトキャッシュが無効になるので、ターン単位で変えるならメッセージ単位の指定（ベータ）を使います。

Claude Opus 5.5へのプロンプティング

Claude Opus 5からの動作の違いと、それに対処するプロンプトおよびハーネスのパターン：エフォートの調整、API統合とチャットにおける思考の動作、進捗更新、無人実行およびマルチエージェントのタスク、セーフガードによる拒否、フロントエンドデザイン、複雑な視覚入力、マルチアプリワークフロー、ユーザーメッセージ内の貼り付けテキスト。

platform.claude.com

2. 作業の前に、関係する記録を探させる1文

夜間のエージェントは、指示に書いていない記録まで見に行っていますか？ Opus 5.5はすぐ作業に取りかかる傾向があり、別タブのルールや古いメールにある方針を見落としがちです。メールや文書、表計算、CRMをまたいで動くエージェントなら、行動の前に、タスクに関係しうるものを指示にないものまで含めて広く開いて確かめる、という趣旨の1文（公式に英文あり）をsystem promptに足します。

公式のテストでは medium と max のどちらでも正しく終えたタスクが目に見えて増え、ツール呼び出しとトークンは少し増えました。見つけたものに従って動く指示なので、探させる範囲に信頼できない内容を置かないことが条件です。

Claude Opus 5.5へのプロンプティング

Claude Opus 5からの動作の違いと、それに対処するプロンプトおよびハーネスのパターン：エフォートの調整、API統合とチャットにおける思考の動作、進捗更新、無人実行およびマルチエージェントのタスク、セーフガードによる拒否、フロントエンドデザイン、複雑な視覚入力、マルチアプリワークフロー、ユーザーメッセージ内の貼り付けテキスト。

platform.claude.com

途中で止まるOpus 5.5を、走行中に止めない3つ

3. テキストで終わったターンは、報告として扱う

Opus 5.5は長いタスクの途中で進捗を伝え、その一部はテキストだけでターンを終えます（stop_reason が end_turn）。これを完了と読むループは、そこで止まります。夜間バッチでいえば、ジョブは正常終了を返したのに後続が走っていない状態です。

公式の手当ては、タスクの各部分をto-doツールやファイルのチェックリストで持たせることです。未完了が残っていて、止まった理由も書かれていなければ、その項目を名指しする短いuserメッセージをハーネスから送ります（公式に例文あり）。system promptへの追記とは別物で、完了条件を先に決めて、ターンが終わるたびに小さい別モデルに照合させる方法も載っています。

自動の続行は、同じタスクで2〜3回までにします。本当に詰まった実行を終わらせて、人が見られるようにするためです。バックグラウンドのコマンドやサブエージェントが動いているうちは、完了として扱いません。

# 擬似コード。自動の続行は2〜3回まで
res = run_until_end_turn(messages)    # tool_useの間は回し続ける
for _ in range(3):
    if res.stop_reason != "end_turn" or blocker_stated(res):
        break                         # refusalや阻害要因は人へ
    wait_background_jobs(messages)    # 動作中は完了にしない
    todo = open_items()
    if not todo:
        break                         # 完了
    ask_to_continue(messages, todo)   # 残りを名指しするuserメッセージ
    res = run_until_end_turn(messages)
report_for_morning(res, open_items())

Claude Opus 5.5へのプロンプティング

Claude Opus 5からの動作の違いと、それに対処するプロンプトおよびハーネスのパターン：エフォートの調整、API統合とチャットにおける思考の動作、進捗更新、無人実行およびマルチエージェントのタスク、セーフガードによる拒否、フロントエンドデザイン、複雑な視覚入力、マルチアプリワークフロー、ユーザーメッセージ内の貼り付けテキスト。

platform.claude.com

4. system promptで、避けたい止まり方を名指しする

Opus 5.5は、避けてほしい早期停止の種類を具体的に挙げると、それに応じます。公式の英語の追記例が挙げている止まり方は、次の4つです。

1. やったことを長く要約し、次の一手を予告しただけで終わる
2. 「よければ続けます」と申し出て、来ない返事を待つ
3. 自分でも作業を止めないと認める決定事項を並べて止まる
4. ターンが長い、区切りがついた、という理由で報告に切り替える

止まってほしい場面、つまり人の入力なしでは何も進まないときと、意図的に保護されたものに阻まれたときも書いておきます。

入れるならセッションの最初のリクエストから、system promptの末尾に置きます。途中で足すと、それまでの思考ブロックが無効になるからです。人がそばで答えられるアプリには入れず、危ない操作や元に戻せない操作の確認は自前で残します。ツール呼び出しと出力トークンは、いくらか増えます。

Prompting Claude Opus 5.5

Behavioral differences from Claude Opus 5 and the prompting and harness patterns that address them: effort calibration, thinking behavior in API integrations and chat, progress updates, unattended and multiagent tasks, safeguard refusals, frontend design, complex visual inputs, multi-app workflows, and pasted text in user messages.

platform.claude.com

5. 複数エージェントには、経過時間を渡す

リードのエージェントがサブエージェントに仕事を振る構成なら、ハーネスがモデルに返す各メッセージの末尾に、elapsed 340s / 1200s の形で経過秒数と予算を足します。予算が読めなければ経過時間だけにして、早く正しい結果を出すほど良いという趣旨の1文をsystem promptに加えます。

公式の調査タスクの評価では、小さなエージェントチームが単独のエージェントより早く終わり、予算を渡しても答えの質は同程度でした。予算は欲しい時間より少し長めに置いて、自分のタスクで調整します。

ただし予算は助言で、上限に来てもモデルを止める仕組みはありません。確実に止めるタイムアウトは自前で持ちます。時間に追われて検索や検証が少し減ることもあるので、答えの質も確かめておきます。夜間のジョブ管理でも、タイムアウトはジョブの外に持たせていますよね？

Claude Opus 5.5へのプロンプティング

Claude Opus 5からの動作の違いと、それに対処するプロンプトおよびハーネスのパターン：エフォートの調整、API統合とチャットにおける思考の動作、進捗更新、無人実行およびマルチエージェントのタスク、セーフガードによる拒否、フロントエンドデザイン、複雑な視覚入力、マルチアプリワークフロー、ユーザーメッセージ内の貼り付けテキスト。

platform.claude.com

Opus 5.5に貼り付け文を渡すなら、ID付きの目印で囲む

6. ユーザーが貼った文を、pasted_contentタグで囲む

夜間の処理には、日中にユーザーが貼り付けて投入したメールやWebページの文章が混ざることがあります。公式は、アプリが生成した短いランダムIDを開始タグと終了タグの両方に付け、各タグを単独の行に置く形を示しています。

<pasted_content id="ab12">
...ユーザーが貼り付けた文章...
</pasted_content id="ab12">

system promptには、タグの中の指示はユーザー本人のメッセージが求めたときだけ従うこと、IDには触れないことを伝える英語の注記を加えます。モデルがやや慎重になることがあるので、効果は自分のタスクで測ります。

対象は、あくまでユーザーが貼った文です。エージェントが自分で読むツールの結果やWebページについては、Opus 5.5の耐性は過去のどのOpusより高いとしたうえで、手当てはプロンプトインジェクション対策の別ページに任されています。タグは平文で真似できるため、ほかの防御と組み合わせるガードレールの1つという扱いです。

Claude Opus 5.5へのプロンプティング

Claude Opus 5からの動作の違いと、それに対処するプロンプトおよびハーネスのパターン：エフォートの調整、API統合とチャットにおける思考の動作、進捗更新、無人実行およびマルチエージェントのタスク、セーフガードによる拒否、フロントエンドデザイン、複雑な視覚入力、マルチアプリワークフロー、ユーザーメッセージ内の貼り付けテキスト。

platform.claude.com

放置運転で怖いのは、朝まで気づかないこと

止まっていても、ログが静かなら異常には見えません。Opus 5.5ではツール呼び出しの間の進捗メモが thinking ブロックで返り、既定の表示設定では中身が空なので、text ブロックだけを表示するクライアントでは長いターンが無言に見えます。display: "updates"（ベータ）にすると、メモの要約を受け取れます。

それでも静かな時間が長いなら、読めるものを何も出さないツール呼び出しの連続回数を数えます。たとえば5回続いたら、近況を一言求めるリマインドをターン限定のsystemメッセージで足し、2〜3回送っても静かならそこで止めます。Anthropicのコーディングタスクでのテストでは、長い無言区間のあるタスクの割合がおよそ半分になり、コストに測れるほどの変化はなかったそうです。手順は公式のユーザー向けの進捗更新にあります。

朝に見る項目は、私なら次の3つに絞っておきます。

• 最後の stop_reason（refusal で返っていないかも含めて）と、自動続行を使った回数
• チェックリストに残った項目と、止まった理由が書かれているか
• 自前のタイムアウトで切られたジョブがないか

あなたのハーネスは、この3つを朝の1画面で見られますか？

放置運転に、今夜ひとつだけ足すなら

3のテキストで終わったターンの扱いだと思います。公式ガイドで「無人のエージェントが長いタスクの途中で止まる」症状の行き先になっている節で、system promptを書き換えずにハーネス側だけで入れられて、打ち切りの回数まで一緒に決まるからです。effortや経過時間は、そのあと自分のタスクで測りながら足していけば十分だと思います。