はじめに

皆さん、Claude Fable使っていますか？
もうすぐサブスクリプションのモデルの中からFableが外れてしまいますね。
そこで今回はFableがサブスクで使えなくなった場合を想定して、OpusとSonnetの自律性を引き上げるTipsについて紹介したいと思います。

といっても、既に知っている人も多くいるかも知れませんが...

本記事の目的

Claude FableはClaudeのモデルの中でも特に自律的にタスクを進めてくれる印象がありますが、実はSonnet 5やOpus 4.8でも、プロンプトとハーネスの設計次第でその自律性をかなり引き出せます。本記事では、Anthropicの公式ドキュメントをベースに、Claude Codeを日常的に使うエンジニア向けに「勝手に最後まで進めてくれる」度合いを上げるための実践的なTipsをまとめました。

筆者はJava+JSP→React+Jakarta EEのマイグレーション案件で、Claude Codeのスキル・コマンドを使ったハーネス設計を主導しています。その過程で得た知見も交えつつ紹介します。

対象読者

Claude Codeを日常的に使っているエンジニア
Claude Fableがもうすぐ使えなくなって寂しい方
「Sonnet 5やOpus 4.8がすぐ確認を求めてくる」「途中で止まる」と感じたことがある方
ハーネス設計・プロンプト設計に興味がある方

動作環境

項目	バージョン
Claude Sonnet 5	claude-sonnet-5
Claude Opus 4.8	claude-opus-4-8
Claude Code	最新版

TL;DR

Tip 1: effort パラメータを上げる（xhighが最重要レバー）
Tip 2: 最初のターンでタスクを完全に定義する（後出し厳禁）
Tip 3: ツール使用と自律継続をプロンプトで明示する
Tip 4: 旧モデル向けの足場（スキャフォールディング）を外す
Tip 5: Opus 4.8は「単一ターン委任型」の方がコスパが良い

Tip 1: `effort` パラメータを上げる

何が問題か

Sonnet 5・Opus 4.8はデフォルト（high）でもある程度自律的に動きますが、最難関のコーディング・エージェントタスクではデフォルトのままだと途中でツール呼び出しを切り上げがちです。特にOpus 4.8はツール呼び出しより推論を優先する傾向があり、この傾向はデフォルト設定のまま気づかれにくい落とし穴になります。

改善案

effort を xhigh まで引き上げると、エージェント検索・コーディングでのツール使用量が大幅に増えます。効果の目安は以下の通りです。

effort	用途の目安
`low`	短く定型的、レイテンシ重視のタスク
`medium`	コスト重視、多少の知能を犠牲にできるタスク
`high`（デフォルト）	ほとんどのユースケースでバランスが良い
`xhigh`	最難関のコーディング・エージェントタスク向け推奨設定
`max`	トークン消費を一切気にしない最大性能

Sonnet 5では、mediumでもSonnet 4.6のhigh相当の知能が出るとされています。モデル移行時はeffortの対応関係も見直す価値があります。

なぜこう設定すべきか

高effort設定では、モデルがツールを使うかどうかの判断がより積極的になる
ツールを使ってほしい場面でモデルが使ってくれない時、プロンプトで「なぜ・どう使うべきか」を明示する方法も併用できる

Tip 2: 最初のターンでタスクを完全に定義する

よくある書き方

このバグを直して

このあと「あ、この制約もあった」「実はこのファイルも見てほしい」と後出しで情報を追加していくパターンは、Sonnet 5・Opus 4.8では相対的にトークン効率も性能も落ちるとされています。

まさかエンジニアの皆さんはこんなプロンプト投げてませんよね？

改善案

以下のバグを修正してください。

- 症状: ログイン後にセッションが5分で切れる
- 影響範囲: src/auth/ 配下のみ（他モジュールは変更しない）
- 制約: 既存のテストスイートを壊さないこと
- 完了条件: `npm test` が全件パスし、手動での再現手順（別途記載）で再発しないこと

なぜこう書くべきか

タスク・意図・関連する制約を最初のヒューマンターンで明確かつ正確に指定することが、自律性と知能を最大化しつつ余計なトークン消費を抑える鍵になります。逆に曖昧な指示を複数ターンに小出しにすると、モデルは何度もやり直しや確認を挟むことになり、結果的に人間の介入回数も増えてしまいます。

この原則はSonnet 5・Opus 4.8共通です。特に自律性が高いモデルほど「最初にどれだけ正確な地図を渡せるか」が成果を左右します。

まあ、ぶっちゃけ、具体的な指示だしするのが面倒くさいので、意思の汲み取り性能の高いFable君は有能なんですが...

パワハラせずに綺麗な指示だしをしていきましょう...

Tip 3: ツール使用と自律継続をプロンプトで明示する

何が問題か

Sonnet 5は思考（thinking）が無効な状態だと、ツールに手を伸ばしたり検索を検討したりする頻度が下がります。また、長時間タスクではコンテキスト上限が近づくにつれ、モデルが自然にタスクを早めに切り上げようとすることがあります。

改善案

CLAUDE.mdやシステムプロンプトに、以下のような一文を入れておきます。

CLAUDE.md

あなたのコンテキストウィンドウは上限に近づくと自動的に圧縮され、
中断した箇所から作業を継続できます。
そのため、トークン予算を理由にタスクを早期に切り上げないでください。
予算の限界が近づいた場合は、現在の進捗をメモリ（ファイル等）に保存してから続行してください。
常に可能な限り持続的かつ自律的に行動し、タスクを完全に完了させてください。
残りコンテキストに関わらず、タスクを人為的に途中で止めないでください。

ツール使用を積極化させたい場合は、併せてツールの使いどころを具体的に説明します。

CLAUDE.md

Webサーチツールが利用可能です。マイグレーション対象のライブラリのバージョン差分や
非推奨APIについて確信が持てない場合は、必ずWebサーチで一次情報を確認してから
実装してください。

なぜこう書くべきか

Sonnet 5・Opus 4.8はいずれも、コンテキスト圧縮を前提としたハーネス（Claude Codeなど）で使う場合、この情報をプロンプト側で伝えておかないと「なんとなく早めに切り上げる」挙動が出ることが公式に指摘されています。逆に言えば、この一文を足すだけで自律継続の挙動がかなり改善します。

Tip 4: 旧モデル向けのスキャフォールディングを外す

よくある書き方（旧モデル向け）

3回ツールを呼び出すごとに、これまでの進捗を要約して報告してください。

昔、この書き方流行りましたよね。
昔と言っても1年程度ですが...

なぜ見直すべきか

Sonnet 5・Opus 4.8は、長い自律実行トレースの中でもユーザーへの進捗報告を自発的に、かつ高品質に行うようになっています。そのため、旧モデル向けに組み込んだ「N回ごとに報告させる」ような足場は、むしろ自然な報告のリズムを崩し、冗長化させる要因になり得ます。

逆に、報告の長さや内容が自分の用途に合わない場合は、削除するのではなく「どんな更新をしてほしいか」を具体的に記述する方向で調整するのが推奨されています。

改善案

- 3回ツールを呼び出すごとに、これまでの進捗を要約して報告してください。
+ 大きなマイルストーン（設計方針の決定、実装完了、テスト結果）ごとに、
+ 何を判断しどう対処したかが分かる形で報告してください。

ハーネス（カスタムコマンドやスキル）を作り込んでいるプロジェクトほど、モデル更新のタイミングでこの手の「足場の棚卸し」をする価値があります。

Tip 5: Opus 4.8は「単一ターン委任型」の方がコスパが良い

何が問題か

Opus 4.8は、対話的（インタラクティブ）に複数ターンでやり取りするセッションでは、ユーザーの発言後により多く推論する傾向があり、トークン消費が増えます。これは長く対話的なコーディングセッションでの一貫性・指示追従・コーディング能力の向上に寄与する一方、コストは増加します。

改善案

自律性・コスト効率を重視するなら、以下のように「最初に必要な情報を全部渡して、あとは任せる」形にするのが向いています。

以下のタスクをまとめて委任します。途中経過の確認は不要です。
完了したら結果だけ報告してください。

[タスクの詳細・制約・完了条件をすべて記載]

逆に、設計方針を一緒に詰めていきたいような場面では、対話的な使い方の方が向いています。用途に応じて使い分けるのがポイントです。

まとめ

Sonnet 5・Opus 4.8の自律性を最大限引き出すには、次の4点が特に重要です。

effort を xhigh に上げてツール使用と自律深度を引き上げる
最初のターンでタスク・制約・完了条件を完全に定義する
ツール使用・自律継続の指示をCLAUDE.md等に明示する
旧モデル向けの中間報告強制などのスキャフォールディングを見直す

「Fableだから自律的」なのではなく、モデルの特性に合わせてハーネス側を調整することで、Sonnet 5やOpus 4.8でも十分に自律的な実行を引き出せます。マイグレーション案件のようにレビュー指摘を減らし工期を短縮したい場面では、こうしたハーネス設計の積み重ねが効いてきます。

私自身、最近のLLMモデルの性能の高さにかまけて、曖昧な指示出しをするパワハラ上司になっていたので、気を付けていきます。

皆さんもともに気を付けていきましょう。

Have a good AI

参考資料