はじめに 📝
2026年9月22日、claude.dev ブログに 「Getting the most out of Opus 5.5 in Claude and Claude Code」（著者: Addy Osmani 氏）が公開されました。
Opus 5.5 はこれまでの Claude の使い方でそのままよく動きますが、次の3点で振る舞いが変わっています。
- 🏃 自律的に長く作業する
- 🗣️ 何をしたかを平易に報告する
- 🧠 毎回の返答の前に必ず考える
本記事では、この公式ガイドの内容を日本語で要約します。プロンプトの書き方、長時間タスクの舵取り、結果の確認方法を押さえておけば、Opus 5.5 の力をしっかり引き出せます。
たとえば Claude Code では、次のように 「タスク全体」「完了の定義」「止まるべき条件」 を1つのメッセージで渡すのが基本形です。
支払いエンドポイントを
旧クライアントから新クライアントへ移行してください。
完了の定義:
- すべてのエンドポイントが新クライアントを使う
- 旧クライアントが削除されている
- テストスイートが通る
説明のつかない理由でテストが失敗したときだけ、
止まって確認してください。
3行まとめ ✨
- 🎯 タスクは丸ごと渡し、「完了」の定義と止まる条件を伝えたら任せる
- 🧹 「think carefully」系の指示は削除する（Opus 5.5 は常に考えてから返答する）
- 📋 長時間の実行が終わったら、まず「あなたに求めていること」から読む
1. 依頼の仕方 💬
「完了」の形を伝えて、あとは任せる
- やること: タスク全体を1つのメッセージで渡し、「テストが通る」「全エンドポイントが移行済み」のようにゴールを明示する
- 理由: Opus 5.5 は Opus 5 よりも長く複数段階にわたる作業を粘り強く続けられます。特に、大規模リポジトリで変更をテストが通るまでやり切るような多段階タスクで大きく伸びています。初期テスターは、ほとんど監視なしで何時間もコーディングタスクを走らせていたそうです。ゴールが明確なら、モデル自身が「終わった」と判断できます。
「よく考えて」と言うのをやめる
- やること: 「think carefully」「think step by step」などの指示を、プロンプトや保存済みの指示から削除する
- 理由: Opus 5.5 は常に返答前に考え、どれだけ考えるかも自分で決めます。Anthropic のテストでは、チャット製品で「think carefully」を消すと応答の開始が早くなり、品質の明確な低下は見られませんでした。
-
ポイント:
- 簡単な質問に素早く答えてほしいときは「直接答えて」と伝える
- Claude Code で思考量を調整したいときは effort を変更する
実行中のタスクに追加指示する
- 実行時間が長くなった分、やり直しのコストも大きくなっています
- Claude Code では、Claude が作業中でもメッセージを入力して Enter で送れます
- 例: 「旧エンドポイント名もエイリアスとして残して」
デザイン系の依頼では「使ってほしくないスタイル」を列挙する 🎨
デザインの指示がないと、Opus 5.5 はいくつかの定番スタイルに寄りがちです。「ありきたりな見た目は避けて」のような抽象的な指示では、別の定番に置き換わるだけです。具体的なパターンを列挙するほうがずっと効果的です。
仮のコンテンツで個人サイトを作ってください。
次のデザインは使わないでください:
- クリーム色やオフホワイトの背景
- 見出し内のイタリックの強調語
- 「01 / 02 / 03」形式の番号付きセクションラベル
- 等幅フォントのラベル
- ピル型のボタン
出てきた結果も気に入らなければ、それもリストに追加してもう一度頼みましょう。
2. Claude Code で長時間タスクを舵取りする 🛠️
どこで止まってほしいかを CLAUDE.md に書く
Opus 5.5 は作業中こまめに状況を報告します。そのため長いタスクの途中で、次のように「報告のために止まる」ことがあります。
- 次の手順を書いただけで実行しない要約
- 「続けましょうか？」という提案
- 作業をブロックしない選択肢の列挙
こうした止まり方を名指しした指示には従うので、CLAUDE.md にルールを書いておきます。
私の入力が不要なステップでは、
そのまま作業を続けてください。
状況報告は、次のアクションと
同じメッセージに含めてください。
止まって確認するのは、次の場合だけにしてください:
- 私なしでは続行できないとき
- 破壊的な操作の前
（データの削除、force push、このリポジトリ外への変更）
⚠️ 注意点
- 「続けましょうか？」で止まったら「続けて」と返せばOK。頻発するなら上のルールが効きます
- 「続けて」ルールは止まる回数を減らすので、リスクがある操作や元に戻しにくい操作の前のチェックは残すこと（上のルールの最終行がそれにあたります）
- 破壊的なコマンドに対する パーミッションプロンプトもオンのまま にしておきましょう
- ペアプログラミング的に進めたい場合は逆に「開始前に1行の計画、終了時に短い振り返り」と書けば、Opus 5.5 はそちらにも従います
大きな作業はサブエージェントに分割させる 🤖
コードベース全体の監査・移行・レビューでは、サブエージェントに分担させ、それぞれの結果を検証させましょう。初期テスターは、長時間の監査や移行で Opus 5.5 に並列サブエージェントを、ほぼ監視なしで統括させていました。
services/ 配下のすべてのサービスについて、
リンク先の issue にあるリトライのバグが
ないか監査してください。
サービスごとに別のサブエージェントに担当させてください。
サブエージェントから報告が来たら、
根拠を確認してから受け入れてください。
最後に「サービス / 影響の有無 / 根拠」の表を
1つにまとめてください。
タスクリストはファイルで管理する 📂
長い実行ではコンテキストウィンドウが埋まり、Claude Code は古いターンを要約します。ファイルに書いたリストはこの要約の影響を受けません。何が終わって何が残っているかも一目で分かります。
TASKS.md にチェックリストを置いてください。
項目が終わるたびにチェックを付け、
新しく見つかったことも追加してください。
スクロールバックではなく、このファイルを見て進捗を確認しましょう。
3. 結果を確認する ✅
まず「あなたに求めていること」を読む
長い実行が終わったら、未決の判断や承認待ちの変更など、Claude があなたを待っている事項を最初に確認し、そのあとで要約の残りを読みます。Opus 5.5 は Opus 5 より報告が明確で、何をしたか・何を見つけたか・何が必要かを平易な言葉で伝えてくれます。
要約のフォーマットを変えたいときは CLAUDE.md に書きます。
毎回の実行の最後は、次の3つの見出しでまとめてください:
- 私の対応待ち
- 変更したこと
- 見つけたこと
コードレビューを任せる 🔍
人間がレビューする前に、diff や PR を Opus 5.5 にレビューさせましょう。ある初期テスターによると、最低 effort の Opus 5.5 が、high effort の Opus 5 より多くのバグを見つけ、誤検知も少なかったそうです。変更内容の説明も平易なので、PR の説明文もレビューしやすくなります。
このブランチの main との差分をレビューしてください。
マージを止めるべき問題だけを挙げてください。
それぞれについて、次の内容を書いてください:
- ファイルと行
- なぜ間違っているか
- どうすれば失敗を再現できるか
確認できなかったことを明示させる
調査や分析では「見つからなかったこと」「確認できなかったこと」を書かせましょう。「見つからなかった」という情報にも価値があり、明示させれば見落としません。
確認できなかったことには印を付け、
どこを調べたかも書いてください。
Claude のリサーチレポートでも Claude Code でも使えます。
4. Claude アプリでの使い方 📱
まず、モデルピッカーが Opus 5.5 になっているか を確認しましょう。
| やること | 理由・効果 | 例 |
|---|---|---|
| 🖼️ グラフやスクショは画像のまま添付（数値を打ち直さない） | 図表・スクショの読み取りが Opus 5 より正確で、追加の手順も不要。矢印がどの箱をつなぐか、図の2版間の差分、カレンダーの予定の開始・終了など、位置に依存する意味の理解も向上 | 「これらのサービスのうち、billing API を直接呼んでいるのはどれ？」 |
| 📄 長い文書のミスチェックを頼む | 細部への注意力が向上。長い計画スレッドで曜日が合わない日付や、資料内で数値と合わないグラフを検出した例あり | 「この資料の数値・日付・名前の矛盾を、該当箇所を引用して場所とともに挙げて」 |
| 📊 完成したファイルを頼む（アウトラインではなく） | Opus 5.5 が作るスプレッドシートや文書は、共有前の手直しが Opus 5 より少なくて済む | 「ベンダーごとに1行、コスト・契約終了日・担当者の列で共有用スプレッドシートにして」 |
プロジェクトでは「回答済み事項は確定」と伝える
長いチャットでは、短い追加質問に対しても過去の回答を見直してしまい、返答が遅くなることがあります。その場合はプロジェクトの指示に次を追加します。
一度答えたことは、確定したものとして扱ってください。
今の質問に集中してください。
私が尋ねたり問題を指摘したりしない限り、
以前の回答を見直さないでください。
ただし、後のステップで前のミスが判明しうる長い分析系のプロジェクトでは入れないほうがよい、とされています。
5. メッセージがフラグされたとき 🚩
Opus 5.5 は、Fable 相当のバイオ・サイバー安全対策を搭載してリリースされた初の Opus モデルです。Claude アプリや Claude Code では、フラグされたメッセージの多くは旧モデルに切り替わって作業が続きます。
- ソースコードの脆弱性探しは許可されています
- 日常的な健康や教育に関する質問も引き続き使えます
- 正当な作業が誤ってフラグされることもあり、誤検知を減らすよう調整が続けられています
Claude アプリの場合
- 表示: 「Switched to」で始まり、旧モデル名が入った通知。以降そのチャットは旧モデルで続きます
-
対処:
- モデルピッカーで Opus 5.5 を選び直す（問題のメッセージがチャットに残っていると再度フラグされる可能性があるため、新しいチャットを始めるのが確実）
- 事前に確認してほしい場合は Settings → Capabilities で「Switch models when a message is flagged」をオフにする（「paused」カードで選択肢が表示されます）
- チェックはファイルや検索結果を含む会話全体が対象です。直前のメッセージではなく、それ以前の内容が原因でフラグされることもあります
Claude Code の場合
- 表示: 旧モデル名を示す通知が出て、セッションはそのモデルで続きます
- 対処:
| 操作 | 内容 |
|---|---|
/model |
Opus 5.5 に戻す |
Esc を2回 |
直前のメッセージを編集して再試行 |
/config |
「Switch models when a message is flagged」の設定を変更 |
/feedback |
誤ったフラグを報告 |
推論過程を返答に出させない
内部の推論を返答内に再現させる依頼は拒否されることがあり、フラグのカテゴリの1つでもあります。代わりに、必要なことを直接頼みましょう。
このアプローチを選んだ理由を3文で説明してください。
6. スピード ⚡
Claude Code で、1回ずつ返答を読んでから次を送るような往復作業では fast mode が便利です。
- Opus 5.5 ではリリース時点から リサーチプレビュー として利用可能
- モデルは同じで、テキストが早く届く
- extra usage の有効化が必要で、トークン単価は標準モードより高い
/fast
Opus 5.5 チェックリスト ☑️
次の長いタスクの前に確認しましょう。
依頼
- タスクに「完了」の定義が書かれている
- プロンプトや保存済み指示に「think hard」系の文言がない
- デザイン依頼で、避けたいスタイルを列挙している
- グラフやスクショは打ち直さずに添付している
Claude Code での長時間タスク
- CLAUDE.md に「いつ止まり、いつ続けるか」「破壊的操作の前は止まる」が書かれている
- 破壊的コマンドのパーミッションプロンプトはオンのまま
- 大規模な監査・移行はサブエージェントに分割している
- タスクリストをファイルで管理している
確認
- レポートの「あなたに求めていること」を最初に読む
- 人間のレビュー前に、Claude のレビューを通している
- リサーチ結果で、確認できなかった点が明示されている
フラグ
-
戻し方（モデルピッカー、または
/model）を知っている - 「Switch models when a message is flagged」を好みどおりに設定している
まとめ 🎉
Opus 5.5 は、長く自律的に動き、明確に報告し、常に考えてから答えるモデルです。そのため、使い方のポイントも次のように変わります。
- 細かく指示するより、ゴールと止まる条件を伝えて任せる
- 「よく考えて」のような不要になった指示は削る
- 長時間実行は CLAUDE.md・サブエージェント・タスクファイル で舵取りする
- 結果は 「自分に求められていること」から読む
まずは手元の CLAUDE.md から「think carefully」を消し、「止まる条件」のルールを追加するところから始めてみてください 💪