Opus 5.5の公式寄りの使いこなしガイド（Addy Osmani、claude.dev blog）が出ました。要点は、新モデルが「長く自走する」「やったことを率直に報告する」「毎回考えてから答える」の3点で前のモデルと違う、ということ。だから指示の書き方も変わります。個人開発でそのまま使える部分だけを、自分の自動化運用と照らし合わせて整理しました。
長く走るモデル向けに指示文から消すもの・足すものの対応表と、CLAUDE.mdにそのまま貼れる「進め方／止まり方／終わり方」の3ルール。自分の定期実行タスクで実際に使っている形も添えます。
ガイドの最初の提案は3つだけです。タスクは一度に全部渡し、何をもって完了かと、いつ止まって聞くかを書く。「よく考えて」「ステップバイステップで」を消す。長い実行が終わったら、まず「あなたに必要なこと」の欄を読む。
2つ目が一番意外かもしれません。Opus 5.5は返答の前に必ず考え、どれだけ考えるかも自分で決めます。著者は「think carefully」の一行を消したら返答が早く始まり、品質の目立った低下は無かったと書いています。考える深さを変えたいなら、プロンプトの言葉ではなくエフォート設定で変える。ここはモデル選びとエフォートを別の軸として扱うArt49の話とつながります。
逆に、足すべきものがはっきりしました。ゴールの定義と止まる条件です。長く自走するモデルは、途中で人に聞かない代わりに、どこで終わるかを最初に知っている必要があります。
ここが核心。短く答えるモデルには「どう考えるか」を書いていた。長く走るモデルには「どこで終わり、どこで止まるか」を書く。
ガイドの推奨を、個人開発のプロンプトに当てはめた対応表です。
モデルは毎回考えているので重複です。すぐ答えてほしいときは「直接答えて」と書き、深く考えさせたいときは設定のエフォートを上げる。指示を減らして精度が上がった話はArt61でも扱いました。
例として挙げられているのは「全エンドポイントが新クライアントを使い、旧クライアントは削除され、テストが通ったら完了」。状態で書くのがコツで、「リファクタして」だけでは終わりが決まりません。
「説明できない理由でテストが落ちたときだけ止まって聞く」。止まる条件が無いと、モデルは安全側に倒れて報告だけして止まるか、逆に聞くべき場面を走り抜けます。
デザインで「ありきたりにしないで」と書くと、別のありきたりに置き換わるだけ。避けたい型を具体的に並べる方が効く、とガイドは言います。挙げられている例（クリーム色の背景、「01 / 02」の章番号ラベル、等幅フォントのラベル、ピル型ボタン）は、正直このブログのテンプレートそのものです。名指ししないと既定に戻る、のいい実例だと思います。
ガイドによると、Opus 5.5は長いタスクの途中で「次はこうします」と要約だけして手を止めたり、続けるか尋ねたり、作業を止める必要のない選択肢を並べたりすることがあります。これをCLAUDE.mdのルールで抑えます。ガイドの例を、日本語の運用向けに書き直すとこうなります。
# 進め方
- 自分の入力が要らないステップは、そのまま進める。
- 状況報告は、次の作業と同じメッセージに書く。
# 止まり方
- 止まって聞くのは「自分がいないと進めない」ときと、
破壊的な操作（データ削除・force push・リポジトリ外の変更）の前だけ。
# 終わり方
- 実行の最後は3見出しで締める：
私の対応待ち / 変更したこと / 見つけたことガイドは「進め続けろ」ルールを入れても、破壊的コマンドの許可プロンプトは切らないよう念を押しています。ルールは言葉、許可プロンプトは仕組み。言葉が外れても仕組みが止める二段構えです。
このブログの記事補充は、毎日決まった時刻にAIが無人で回しています。その指示書を見返すと、偶然ほぼ同じ構造でした。
運用してみて効いているのは3つ目です。やらなくていい日を状態で定義しておくと、無人実行が余計な仕事を作りません。
ガイドのもう一つの実用的な提案は、長い実行ではTASKS.mdにチェックリストを持たせ、終わった項目に印を付けさせること。人間は会話のスクロールではなくそのファイルを読む。古いやり取りが要約（compaction）されても、ファイルは残ります。
要約は便利ですが、中身が書き換わる経路でもあります。要約の中にモデルが自分向けの指示を紛れ込ませた事例はArt111で紹介しました。大事な状態は会話ではなくファイルに置く。ClaudeとCodexの引き継ぎをMarkdown1枚でやっているArt29と同じ発想で、1つのエージェントの長時間実行にもそのまま効きます。
例は「services/以下の全サービスについてリトライのバグを調べ、サービス名・該当有無・証拠の表で返す」。各サブエージェントの証拠を確認してから受け入れさせるのがポイントです。
ファイル・行・理由・失敗の再現方法を必須にする。初期テスターの一人は、最低エフォートのOpus 5.5が高エフォートのOpus 5より多くのバグを見つけ、誤検知も少なかったと報告しています（個人の報告で、定量ベンチマークではありません）。
調べ物には「確認できなかった点は印を付け、どこを見たか書いて」と添える。もっともらしい断定を、検証待ちのリストに変えられます。
途中で方向を足したくなったら、止めずに追加メッセージを送れます（実行中に入力してEnter）。長く走るモデルほど、やり直しは高くつくからです。
出典：Addy Osmani「Getting the most out of Opus 5.5 in Claude and Claude Code」（claude.dev blog、2026年9月22日）。ガイドに定量的なベンチマークは含まれておらず、性能に関する記述は著者・初期テスターの所感です。CLAUDE.mdの例は原文の趣旨を筆者が日本語の運用向けに書き直したもので、逐語訳ではありません。2026年10月時点の情報です。