🪄
Opus 4.5のよしな力に立ち向かう

2025/12/05に公開
こんにちは、かがわ（@shinpr_p）です。
Claude Code × Opus 4.5を使った開発もようやく安定してきた今日この頃、みなさんはどんなAI開発ライフをお過ごしでしょうか？

この記事では、Opus 4.5を使いこなすために試行錯誤した対策を2つ紹介します。

 前提：Opus 4.5の設計思想を理解する私が一番頭を悩ませたのが、作業の過程をスキップされることが増えたという事実です。

調べてもらったのですが、スキップは意図的な設計変更だそうです。
公式ドキュメントにこんな記載があります。
Claude 4.5 models tend toward efficiency and may skip verbose summaries after tool calls, jumping directly to the next action.
つまり「効率化のためにサマリーをスキップしてワークフローの勢いを維持する」という設計です。

私はフローをガチガチにして自律的な実装をLLMに行ってもらうアプローチを取っているので、この設計思想の悪い側面にクリティカルヒットしてしまいました。
色々試行錯誤していく中で、この振る舞いをある程度制御できるいいtipsを見つけました。

 対策1：TodoWriteでステップを明示するたとえば「テスト項目を列挙して、評価して、絞り込む作業」をお願いすると、Opus 4.5は「よしなに」判断して絞り込みを飛ばすことがあります。以前のモデルなら全ステップを踏んでくれたものが、効率化された結果としてスキップされるケースが増えました。
これに対しては、TodoWrite（Claude Codeが使うToolsの一つ）で作業ステップを明示的にタスクとして登録することで対策できました。
私のプロジェクトの実例ですが、サブエージェントの冒頭の定義を以下のように変更しました。
これまで
## 初回必須タスク

作業開始前に以下のルールファイルを必ず読み込み、厳守してください：

- **@docs/rules/typescript-testing.md** - テスト設計の基準（品質要件、テスト構造、命名規則）
...
## 4フェーズ生成プロセス
### Phase 1: AC検証（振る舞い優先フィルタリング）
### Phase 2: 候補列挙（2段階 #1）
### Phase 3: ROIベース選択（2段階 #2）
### Phase 4: 過剰生成制限
...
変更後
## 初回必須タスク

**TodoWrite登録**: 作業開始前に以下の作業ステップをTodoWriteで登録し、各完了時に更新すること。

作業開始前に以下のルールファイルを必ず読み込み、厳守してください：

- **@docs/rules/typescript-testing.md** - テスト設計の基準（品質要件、テスト構造、命名規則）
...
## 4フェーズ生成プロセス
### Phase 1: AC検証（振る舞い優先フィルタリング）
### Phase 2: 候補列挙（2段階 #1）
### Phase 3: ROIベース選択（2段階 #2）
### Phase 4: 過剰生成制限
...
こうすることで、Claude CodeのTODO管理機構にステップが組み込まれ、スキップされることがなくなります。
ただ、注意点も同時に見つかっています。ステップが多すぎると途中の作業をまとめて実行（バッチ処理）してしまいます。10ステップを一度にお願いすると中盤以降の3〜4ステップを「効率的に進めるため、まとめて実行します」と言われまとめられてしまうことが体感として多いです。そのため、一度にお願いするタスク量は3〜5ステップ程度に抑えて、細かく区切って依頼するのが良さそうです。
タスク量が多くてもスキップされない対策を知っている方が居ましたら教えてください。泣いて喜びます。

 対策2：生成より検証で精度を担保するLLMの生成を完全に制御することは不可能です。どんなに詳細なプロンプトを書いても、原則を定義してコンテキストとして与えても、思った通りの出力にならないことがあります。
生成に対して過度に対策してもROIが見合わないと気づき、私は生成物のレビューを作業の1ステップに組み込むことで精度を担保する方針に切り替えました。LLMの特性として、「生成」より「検証・確認」タスクの方が精度が出やすいです。そして、これはモデル性能向上の恩恵を受けやすい部分でもあります。
私のプロジェクトでは、最近テストコードの改善に向き合っていて、レビュー機構を作って精度を担保しようとしています（近日自作のOSSに適用できる予定です）。
実際のオーケストレーターのステップ定義はこんな感じです。
**各ステップの実行内容**:
- task-executor実行: サブエージェント呼び出し
- エスカレーション判定・フォローアップ:
  - `status: escalation_needed/blocked` → ユーザーにエスカレーション
  - `testsAdded`に`*.int.test.ts`/`*.e2e.test.ts` → integration-test-reviewer実行
- quality-fixer実行: サブエージェント呼び出し
- git commit: Bashツールでコミット実行
Design Docからテストスケルトンを生成し実装のステップの中でテスト実装も行うというアプローチをとっているのですが、意図を汲んでいなかったり、そもそも実装をしてくれていないなど、課題が山積みでした。

そこで、テストをレビューするサブエージェントを作り、フィードバックで軌道修正するアプローチに変えたところ、期待した精度のテストが作られるようになってきました。ポイントは、生成とレビューで共通して守るべき原則を定義しておくことです。そうしないとレビューの意味もないですし、差異が大き過ぎると見落としも増えてしまうので、プロジェクトで守りたい水準を言語化しておくと良い結果につながります。
チェックリスト形式にしておくとLLMがチェック観点として使いやすいので、おすすめです。
## レビュー基準

### スケルトンと実装の整合性

| チェック | 不合格条件 |
|---------|-----------|
| Property検証 | Property注釈があるのにfast-check未使用 |
| 振る舞い検証 | 「観測可能な結果」に対応するexpectがない |
| 検証項目網羅 | 列挙された検証項目がexpectに含まれていない |
| モック境界 | 統合テストで内部コンポーネントをモック化 |

### 実装品質

| チェック | 不合格条件 |
|---------|-----------|
| AAA構造 | Arrange/Act/Assertの区切りが不明確 |
| 独立性 | テスト間で状態共有、実行順序依存 |
| 再現性 | 日時・乱数に依存し結果が変動 |
| 可読性 | テスト名と検証内容が一致しない |
ここで追加のtipsとしては、レビューを生成とは異なるコンテキストで行うと良いです。同じセッションで生成→レビューすると、自分が生成したものを自分でレビューすることになり、生成時に利用したコンテキストが悪さをし、適切なレビューを行えないことがあります。別セッションを起動してレビューをさせる、サブエージェントを呼び出してレビューをさせるなど異なるコンテキストでレビューを行うことで、より客観的なレビューがなされ、精度が向上しやすいです。

 おわりにOpus 4.5は確かに賢くなりました。そしてよしな力のおかげで、完遂スピードは確かに上がっています。が、「よしなに」が過ぎる場面があるのも事実です。効率化されたモデルに対しては、特に精度を担保したい領域には明示的なガードレールを設けることがこれまで以上に求められそうです。TodoWriteでのステップ明示と、別コンテキストでのレビューで少なくともOpus 4.5の速度の恩恵を受けつつこれまでと同等の結果を得られているので、もし「よしな力」に悩まされている方が居たら試してみてください。
前提：Opus 4.5の設計思想を理解する

対策1：TodoWriteでステップを明示する

対策2：生成より検証で精度を担保する

おわりに

Discussion
