Opus 5.5をClaude Codeで使いこなす — 長時間タスクの渡し方と止まり方

Opus 5.5を使い始めて最初に変わるのは、プロンプトの書き方よりも「いつまで任せるか」の決め方です。開発者ブログのプレイブック「Getting the most out of Opus 5.5 in Claude and Claude Code」(著者はAddy Osmani、2026年9月22日公開)は、Opus 5.5が長く自走し、何をしたかを平易に報告し、返信の前に必ず考える、という3点を前提に置いています。本稿はこのうちClaude Codeで長いタスクを回す部分を軸に、既存の個別記事との対応と、運用に落とすときの注意をたどります。Claude CodeでOpus 5.5を使うには、v2.1.280以上が必要です。

背景:これまでの使い方で変わる3点

従来の使い方はOpus 5.5でもそのまま通用します。変わるのは次の3点です。

モデルの料金や破壊的変更などの全体像はClaude Opus 5.5とはにあります。

長いタスクを任せる前に、最初の1通に書く3つの部品

タスク全体を1通のメッセージで渡し、完了の定義と、止まって聞く条件を書きます。指示例は次のとおりです。

Migrate the payment endpoints from the old client to the new one.
Done means: every endpoint uses the new client, the old client is
deleted, and the test suite passes. Stop and ask me only if a test
fails for a reason you can't explain.

構造は3つの部品でできています。対象(何を移すか)、完了条件(どうなれば終わりか)、例外の停止条件(何があれば聞くか)です。完了条件に「テストが通る」「全エンドポイントが移行済み」のような検査可能な状態を置くと、モデルは自分で終わりを判断できます。終着点が明確なら、終わるタイミングも分かるからです。

進行中に思い出したことがあれば、Claudeが作業している間にメッセージを入力してEnterを押せば追加できます。長い実行ほどやり直しのコストが高いため、この追加入力の価値も上がります。

「よく考えて」の行を消す

プロンプトと保存済みの指示から「think carefully」「think step by step」の類は削れます。Opus 5.5は返信前に必ず考えるためです。チャット製品でのテストでは、この行を外すと返信が早く始まり、品質の明確な低下は出ませんでした。簡単な質問で即答がほしいときは「Answer directly」と書きます。Claude Codeで考える量を変えたいときに触るのは、文言ではなくeffortです。セッション中は/effortでlow、medium、high、xhigh、maxから選び、起動時ならclaude --effort highのように指定します。Opus 5.5の既定はmediumです。

チャットでの検証はOpus 5.5のチャットで「think carefully」を外す理由が詳しく、ここはその実務側にあたります。

デザイン依頼は避けたい型を名指しする

ページやアプリ、アーティファクトを頼むとき、方向性の指定がなければ、Opus 5.5は少数の既定スタイルに寄ります。「ありがちな見た目を避けて」と書いても、既定が別の既定に入れ替わるだけです。効くのは具体的なパターンの列挙で、例としてクリーム色の背景、見出しのイタリック強調語、「01 / 02 / 03」の番号ラベル、等幅ラベル、丸薬型ボタンが挙がっています。出てきた結果が気に入らなければ、リストに足してもう一度頼みます。詳細はClaude Opus 5.5でAIっぽいフロントエンドを避ける書き方にまとめています。

途中で止まりすぎる・進みすぎるをCLAUDE.mdと権限で分ける

Opus 5.5は「報告のために止まる」ことがある

Opus 5.5は作業の状況をこまめに知らせます。その結果、長いタスクの途中で続きを進めずに止まって報告することがあります。次の手順を述べるだけで実行しない要約、続けてよいかの確認、作業を妨げない選択肢の提示、がその例です。止まる場所を名指しした指示には従うので、望む止まり方を書いておくのが対策になります。

止まり方を指定するCLAUDE.mdの規則は次のとおりです。

When a step doesn't need my input, keep going. Put status notes in
the same message as your next action. Stop and ask only when you
can't continue without me, or before anything destructive: deleting
data, force-pushing, or changing anything outside this repository.

前半の2文は止まりすぎを抑え、後半の1文は進みすぎの歯止めです。2つの目的が組になっているので、片方だけ写すと意図どおりに働きません。止まったときに「continue」と返す手もありますが、頻発するならこの規則を足すのが筋です。

ペアプログラミングのように反対の運用を望む場合は、作業前に1行の計画、最後に短い振り返り、をCLAUDE.mdに書けば、Opus 5.5はそれにも従います。

「止まらない」と「確認を外す」は別の話

「続けて」と書いたからといって、権限の確認まで外してよいわけではありません。取り消しにくい操作の確認は自分の側に残し、破壊的なコマンドの権限プロンプトもオンのままにします。

CLAUDE.mdの文章はモデルへの依頼で、権限はClaude Codeの仕組みです。両方を重ねておけば、規則が守られなかったときも確認が残ります。権限側の書き方は、ask規則が一例です。askに入れたツールの使用は毎回確認になり、評価順はdeny、ask、allowです。

{
  "permissions": {
    "ask": ["Bash(git push *)"]
  }
}

Bash(git push *)のように内容で絞ったask規則は、allow規則による自動許可やサンドボックス内の自動許可、autoモードの下でも確認を強制します。上の例はgit push …の形で書かれたpush(force-pushを含む)を確認に回す最小の形です。git -C . pushのような別の書き方には一致しないため、コマンド文字列に依らない制限にはサンドボックスやPreToolUseフックを組み合わせます。削除やリポジトリ外への変更は、ここに規則を追加して広げます。

監査や移行を数時間回すときの分担とタスクファイル

サブエージェントに分担させ、証拠を検査させる

大規模なコードベースの監査や移行、レビューでは、作業をサブエージェントに分けさせ、各結果を確認させます。初期のテスターは、長い監査と移行でOpus 5.5に並列のサブエージェントを調整させていました。指示例は次のとおりです。

Audit every service in services/ for the retry bug in the linked
issue. Give each service to its own subagent. When a subagent
reports back, check its evidence before you accept it. Finish with
one table: service, affected yes or no, and the evidence.

効くのは「証拠を確認してから受け入れる」の1文です。分担すると速くなりますが、サブエージェントの報告を鵜呑みにすると誤りが集計に混ざります。最終出力を「サービス、該当の有無、証拠」の表に固定すれば、人が読むときの検算も楽になります。

タスク一覧はファイルに置く

数時間の実行では、コンテキストウィンドウが埋まり、Claude Codeが古いターンを要約します。タスクの一覧をファイルに持たせておくと、この要約を越えて残ります。依頼の例は「TASKS.mdにチェックリストを作り、終えたら印を付け、新しく見つけたものを足す」で、進捗はスクロールバックではなくそのファイルを読めば分かります。Agent SDK側の同種の設計はClaudeの長時間タスクをtests.jsonとprogress.txtで管理するにあります。

終わった実行を読む順番と、レビューの頼み方

実行が終わったとき、最初に読むのはサマリー全体ではなく、Claudeが人に求めていることです。決定が保留されていないか、承認を待つ変更がないか、を先に見ます。そのあとで残りを読みます。報告の形を変えたければ、CLAUDE.mdに「毎回の終わりに、Blocked on me、Changed、Foundの3見出しで書く」のように指定します。

レビューは人に回す前にOpus 5.5に頼みます。ある初期テスターは、最も低いeffortのOpus 5.5が、highのOpus 5より多くのバグを、誤検知を減らして見つけたと述べています。この比較は1人のテスターの所感で、一般的な数値ではありません。プロンプト例は、ブランチとmainの差分を見て、マージを止めるべき問題だけを、ファイルと行、理由、失敗を示す方法つきで挙げさせるものです。

調査や分析では、確認できなかったことと探した場所を書かせます。「確認できなかったものに印を付け、どこを探したか書いて」と1行足すだけで、Claudeの調査レポートでもClaude Codeでも使えます。頼めば「見つからなかった」ことも報告の目立つ位置に書かれ、調べ漏れを見分けられます。

フラグで古いモデルに移ったときの戻し方

メッセージがフラグされると、作業が古いモデルで続くことがあります。Opus 5.5はFable水準のバイオとサイバーの安全策を備えて出た最初のOpusで、フラグされたメッセージの多くは古いモデルに移り、作業はそこで続きます。Claude Codeでは、バイオ分野のフラグはOpus 5で、サイバーセキュリティ分野のフラグはOpus 4.8で再実行されます。ソースコードの脆弱性探索は許可されており、日常の健康や教育の質問も使える想定です。ただし正当な作業がフラグされることもあり、誤検知を減らす調整が進められています。

Claude Codeではeffortも維持されます。既定のmediumで動いていたOpus 5.5のセッションがOpus 4.8にフォールバックしても、mediumのままです。

Claude Codeでの見え方と対処は次のとおりです。

Claudeアプリでの切り替え手順はClaude Opus 5のモデル切り替えにあります。

内部の推論を返信に再現させない

関連する注意点が1つあります。内部の推論を返信にそのまま再現させる依頼は、断られることがあり、フラグの分類の1つでもあります。プロンプトと保存済みの指示から、その種の依頼を外すのが対策です。この断りの仕組みはOpus 5.5の推論抽出フォールバックで扱っています。代わりに必要なものを頼みます。たとえば「この方式を選んだ理由を3文で説明して」と書けば、判断の根拠は読めます。

fast modeは待ち時間が支配的な作業に

返信を1つずつ読んで次を送る往復型の作業では、fast modeが効きます。Opus 5.5ではfast modeがリサーチプレビューとして最初から使えます。モデルは同じで、テキストが早く届きます。追加の使用量(extra usage)をオンにする必要があり、トークンあたりの単価は標準より高くなります。Claude Codeでは/fastと入力して切り替えます。

倍率や単価の数値は、プレイブックには書かれていません。API側の価格や対応環境はClaude Opus 5.5とはに載っています。

CLAUDE.mdに寄せた設計は、止まり方を後から検証できない

並べて読むと、プレイブックが制御を置く場所がはっきりします。途中で止まるのを防ぐ設定をはじめ、Opus 5.5を扱う個別記事の多くは、API呼び出しとハーネスの側でend_turnを完了と取り違えない実装を扱います。プレイブックは同じ現象を、人が書く規則の側から解いています。「続けて」「止まるのはここ」の2行をCLAUDE.mdに置けば、会話のたびに打ち直さずに済みます。

この設計は便利ですが、偏りもあります。止まり方の規則をモデルの従順さに預けると、守られたかどうかを後から検証する手段がありません。規則が破られたと分かるのは、たいてい何かが起きた後です。

もう1つ、プレイブックにはeffortの具体的な推奨値がありません。考える量はOpus 5.5が決めるので、変えたいときは/effortなどでeffortを動かす、という整理に留まります。水準ごとの目安はモデル設定のページにあり、mediumは範囲が明確な日常の実装、highは検証が要る作業やバグ修正向けです。この目安を出発点に、各チームの実測で詰めることになります。水準の違いはClaude Codeのeffortレベルの使い分けにまとめています。

まとめ

CLAUDE.mdの規則は守られたかを後から確かめられないので、ask規則で確認を残す範囲を先に決めてから、止まり方の規則を緩めていく順番が扱いやすい構成です。最初はgit pushだけをaskに置き、運用しながら範囲を広げられます。