Claude CodeのultracodeとOpus 4.8の設定手順なら検索すれば出てくる。けれど、実際に動かしてどんな作業が変わり、どこで限界が来て、コストはいくらかかるのか──その「設定の先」を知りたい人に向けて、ファイル数50超えのリファクタリングタスクをultracodeに丸ごと委任した事例を通して見せる。
図解:ultracodeが動く仕組みとeffortレベル比較
flowchart TD
A["ユーザーが\n/effort ultracode を入力"] --> B["オーケストレーター\n(Opus 4.8 × xhigh推論)"]
B --> C["タスク分解\n全体計画立案"]
C --> D["サブエージェント群\n並列起動"]
D --> E1["SA-1\nファイル群A担当"]
D --> E2["SA-2\nファイル群B担当"]
D --> E3["SA-3\nファイル群C担当"]
D --> E4["SA-N\n..."]
E1 --> F["結果集約"]
E2 --> F
E3 --> F
E4 --> F
F --> G["オーケストレーターが\n統合・最終レビュー"]
G --> H["ユーザーへ返答"]
style B fill:#f5a623,color:#000
style D fill:#4a90d9,color:#fff
style G fill:#7ed321,color:#000
effortレベル比較(公式ドキュメントをもとに整理)
| effortレベル | 推論深度 | Dynamic Workflows | 向いているタスク | コスト感 |
|---|---|---|---|---|
| low | 最小 | なし | 簡単な質問・単語置換 | 最小 |
| medium | 標準 | なし | 通常の開発補助 | 標準 |
| high | 高い | なし | 中規模の実装・レビュー | 中 |
| xhigh | 最高 | なし | 複雑な設計・難題 | 高い |
| ultracode | 最高(xhigh) | 自動起動 | 大規模コードベース全体 | 最大 |
※ 各レベルの定義は公式ドキュメント(code.claude.com/docs/en/workflows)で随時更新されるため、最新情報は公式で確認してください。
ultracodeとは:effortの5段階とDynamic Workflowsの位置付け
Claude Codeには「どれだけ深く考えさせるか」を制御する effortレベル がある。low → medium → high → xhigh → ultracode という5段階(現時点の公式ドキュメントによる)で、数字が上がるほどモデルの内部思考ステップが増え、処理も重くなる。
ultracodeがほかと決定的に違うのは、単なる「推論強化」にとどまらず、Dynamic Workflows という機能が自動的に有効になる点だ。
Dynamic Workflowsとは、単一エージェントでは手に余る大量の作業を「オーケストレーター(指揮者)+複数のサブエージェント(実作業担当)」に自動分割し、並列実行するしくみ。公式ドキュメントでは「数百のサブエージェント」が起動しうると説明されているが、実際の並列数はタスクの性質とリソース状況によって変わる。
現時点の公式ドキュメントによると、ultracodeはAnthropicの最上位モデルである Opus 4.8 を使用する設定になっている。Opus 4.8は推論速度より品質を最優先したモデルであり、xhigh推論と組み合わせることで複雑な文脈判断が求められる大規模タスクに対応する。
【設定】Claude CodeでOpus 4.8 × ultracodeを動かす3ステップ
設定そのものはシンプルだ。
ステップ1:Dynamic Workflowsをオンにする
Claude Codeの設定画面(または .claude/settings.json)でDynamic Workflowsが有効になっていることを確認する。デフォルトでオフになっているバージョンもあるため、まずここを確認する。設定方法は公式ドキュメント(code.claude.com/docs/en/workflows)に記載がある。
ステップ2:モデルをOpus 4.8に指定する
Claude Codeのモデル選択でOpus 4.8を選ぶ。設定ファイルで指定する場合は claude-opus-4-8 のモデルIDを使う。ultracodeはOpus 4.8と組み合わせて真価を発揮する設計になっているため、ここは省略しない。
ステップ3:ultracodeを起動する
2つの方法がある。
# 方法A:スラッシュコマンドで起動
/effort ultracode
# 方法B:プロンプトに「ultracode」と書く
ultracode でこのプロジェクト全体をリファクタリングしてください
方法Bは、依頼文の中に「ultracode」というキーワードを含めるだけで自動的にultracodeモードが発動する。設定を忘れがちな場合はプロンプトに書き込むほうが確実だ。
【ケース】今回委任したタスク:50ファイル超えのリファクタリング、どう準備したか
実際に試したのは、TypeScriptで書かれたWebアプリのリファクタリングだ。構成は次のような規模感だった。
- ファイル数:約55〜60(コンポーネント・フック・ユーティリティ・型定義ファイルを含む)
- 主な作業内容:コンポーネント粒度の見直し、importパスの整理、型定義の共通化、unused exportの除去
- 手動でやると見積もっていた時間:半日〜1日
ultracodeに丸投げする前に、2つの準備をした。
準備1:CLAUDE.mdにプロジェクト構成を書く
Claude Codeはプロジェクトルートに CLAUDE.md ファイルがあれば最初に読む。ここにディレクトリ構成・命名規則・使用しているライブラリバージョン・やってはいけないこと(例:サードパーティへのリクエストを勝手に追加しない)を箇条書きで書いておいた。
# CLAUDE.md
## ディレクトリ構成
- src/components/ : UIコンポーネント(Atomic Designベース)
- src/hooks/ : カスタムフック
- src/types/ : 型定義(index.tsで集約する方針)
## 命名規則
- コンポーネント: PascalCase
- カスタムフック: use〇〇
## 禁止事項
- 外部APIへの新規リクエスト追加
- pnpm以外のパッケージマネージャー使用
準備2:タスク分解の指示をプロンプトに入れる
「全部よろしく」だけでは結果がばらつく。「まず計画を立てて確認してから作業を始めてほしい」と一言加えた。これにより、オーケストレーターが全体計画を提示し、承認してから実作業に入るフローになった。
【動作ログ】並列エージェントはこう動く:タイムラインで見た実際の挙動
ultracodeを起動した後の流れは、これまでのClaude Code体験とは明らかに違った。
フェーズ1(最初の数分):オーケストレーターが全体計画を立案
まずOpus 4.8のオーケストレーターがプロジェクト全体を走査し、「どのファイルをどの順番でどのサブエージェントに割り当てるか」という計画を出力した。コンポーネントを依存関係でグループ分けし、干渉しないファイル群を並列作業できるよう整理していた。ここで計画を確認・修正できるのがポイントだ。
フェーズ2(メインの処理):サブエージェントが並列で動く
/workflows コマンドを使うと進捗ツリーが表示され、どのサブエージェントがどのファイルを処理中かが見えた。複数のファイルが同時進行しているのが確認でき、「待っている感」がなかった。ただし、処理中はCPUとネットワーク使用量が上がる点は把握しておく必要がある。
フェーズ3(集約・統合):オーケストレーターが結果をまとめる
各サブエージェントの作業結果をオーケストレーターが統合し、import整合性のチェックや型エラーの有無を確認して最終アウトプットをまとめた。
「委任できた作業」と「うまくいかなかった作業」の境界線
うまくいったのは、ルールが明確なリファクタリングだ。「型定義をこのファイルに集約する」「importパスをこの形式に統一する」のように判断基準が一意に決まる作業は、精度が高かった。
一方で、ビジネスロジックの意図を読み解く必要がある箇所(「このコンポーネントは本当に2つに分割すべきか?」という設計判断)は、確認を求めてくるか、判断が保守的になる傾向があった。「なぜそうなっているか」の背景がCLAUDE.mdに書かれていないものは精度が落ちる、という感触だった。
【比較】ultracode vs xhigh:コスト・品質・待ち時間で判断する使い分け基準
「ultracodeでなくxhighでいいのでは?」という判断は重要だ。使い分けの目安を整理する。
xhighで十分なケース
- ファイル数が10〜20程度
- 作業が1つのモジュールやコンポーネント内で完結する
- 「この関数のロジックを改善してほしい」レベルの深い思考が必要なタスク
- 複雑なバグの原因調査(ただしファイル横断でない場合)
ultracodeが真価を発揮するケース
- ファイル数が30を超えてくる大規模リファクタリング
- コードベース全体のセキュリティ監査
- 複数ファイルにまたがるバグの根本原因調査
- アーキテクチャレベルの変更(依存関係を多数更新する必要がある)
判断の実感として、「1人のエンジニアが一度に頭に入れておく量を超えるタスク」がultracodeの出番だと感じた。それ未満はxhighで十分で、むしろそのほうがコストを抑えつつ早く完了する。
【コスト】1タスクで消費したトークン量と費用の現実
正直に言うと、想定より消費トークンが多かった。
ultracodeはオーケストレーター+多数のサブエージェントが全員Opus 4.8を使うため、入力・出力トークンの合計が単独エージェントより大幅に増える。50ファイル超えのリファクタリングでは、全体の文脈把握のために各エージェントが同じプロジェクト情報を読み込む「オーバーヘッド」が発生する。
具体的な金額は公式料金ページの最新情報をもとに試算する必要があるため、ここでは断定しない。ただ、体感として「中規模のxhighタスクの数倍」というオーダーは覚悟しておいたほうがいい。Anthropicの公式料金ページ(anthropic.com/pricing)でOpus 4.8の入出力トークン単価を確認し、タスク規模から逆算することを強く推奨する。
コストを抑えるコツとして試してみた方法:
- CLAUDE.mdに詳細を書いておくことで、サブエージェントが探索に使うトークンを削減できた
- タスクを「型定義の集約のみ」「importパスの整理のみ」と分けて複数回に分けることで、1回あたりの消費を抑えられた
注意点:使う前に知っておきたい3つのこと
コストに注意する
ultracodeは通常のモード比でトークン消費が大きく増える。業務で使う場合は事前に上限設定を確認し、予想外の請求が来ないようにする。
単一ファイル編集には使わない
「このファイルのこの関数を直してほしい」というタスクにultracodeは過剰だ。単一ファイルの作業にはhighかxhighで十分。ultracodeはあくまでも「コードベース全体」を扱うためのモードだ。
CLAUDE.mdへのプロジェクト情報記載を強く推奨する
公式ドキュメントでも推奨されているが、サブエージェントはそれぞれが独立して動くため、プロジェクトの背景情報をCLAUDE.mdに書いておかないと同じ情報を何度も探索するコストが発生する。最低でも「ディレクトリ構成」「命名規則」「禁止事項」の3点は書いておく。
まとめ:ultracodeが向く仕事・向かない仕事・始め方の推奨ルート
向いている人・プロジェクト
- ファイル数30以上のプロジェクトを抱えている個人開発者・副業エンジニア
- コードベース全体のリファクタリング・監査を一気に進めたい人
- 「とにかく大量のファイルを一貫したルールで処理したい」タスクを持つ人
向いていない人・プロジェクト
- 小規模スクリプト・単発ファイルの編集が中心の人
- トークンコストをできるだけ抑えたい人(まずxhighから始めるほうがいい)
- Dynamic Workflowsの挙動確認・検証をまだしていない人
推奨する始め方
いきなりultracodeで大規模タスクを投げるより、まず小さなプロジェクト(ファイル数10〜20程度)でxhighとultracodeの両方を試して、動作の違いとコスト感を体感してから本番に移行するのがリスクが低い。
公式ドキュメントは随時更新されているため、実際に使用する際は最新情報を確認してほしい。
- 公式ドキュメント(Workflows): code.claude.com/docs/en/workflows
- Anthropic料金ページ: anthropic.com/pricing