Claude Codeに「ultracode」が来た。指示しなくてもAIが勝手に並列で考え始める時代の話
公開日:2026年05月30日

代表取締役
貝出康

実はこれ、2026年5月28日、つまり一昨日リリースされたばかりの新機能なんですよ。
Claude Codeに「ultracode(ウルトラコード)」という設定が増えました。名前だけ見ると「なんか強そうなモード」くらいの印象じゃないですか。私も最初はそう思いました。でも中身を調べてみたら、これ、AIに仕事を頼むときの前提がひとつ変わるレベルの話だったんです。
ひとことで言うと、ultracodeをオンにすると、Claude Codeは「いちいち指示されなくても、自分で深く考えて、必要なら何十体ものAIを並列で動かして、答えを検証してから返してくる」ようになります。
「いやそれ前からできたでしょ」と思うかもしれません。でも、ポイントは「指示しなくても」のところなんです。今日はこの話を、できるだけ正確に、でも分かりやすく書いていきます。私は株式会社カンマンでAI活用やWebマーケティングの仕事をしているので、最後に「中小企業の現場でこれどう使えるの?」という視点も入れますね。
ultracodeって、結局なんなの?
先に結論を言います。ultracodeは「effortレベル」ではありません。ここ、間違えてる人がめちゃくちゃ多くなると思うので最初に潰しておきます。
Claude Codeの公式ドキュメントには、こう書いてあります。
Ultracode is a Claude Code setting rather than a model effort level: it sends
xhighto the model and additionally has Claude orchestrate dynamic workflows for substantive tasks.
(ultracodeはモデルのeffortレベルではなく、Claude Codeの設定である。xhighをモデルに送り、加えて実質的なタスクに対して動的ワークフローを編成させる)
― Claude Code公式ドキュメント「Model configuration」より
つまりultracodeは、2つの要素の組み合わせなんですね。
ひとつ目が「xhigh」。これはAIにどれだけ深く考えさせるか(=どれだけトークンを使ってもいいか)を決める設定で、これは後で詳しく説明します。
ふたつ目が「動的ワークフロー(Dynamic Workflows)の自動編成」。これがultracodeの本体と言ってもいいです。実質的な作業だと判断したら、Claudeが勝手に複数のAIエージェントを段取りして動かす。これを「指示されなくても」やるようになる。それがultracodeです。
公式の「Dynamic workflows」のページにも、ほぼ同じことが書いてあります。
Ultracode is a Claude Code setting that combines
xhighreasoning effort with automatic workflow orchestration. With it on, Claude plans a workflow for each substantive task instead of waiting for you to ask.
(ultracodeはxhighの推論努力と自動ワークフロー編成を組み合わせたClaude Codeの設定。オンにすると、こちらが頼むのを待たずに、実質的なタスクごとにワークフローを計画する)
「待たずに」。ここが効いてるんですよ。
なぜこれが「事件」なのか
今までのClaude Codeって、基本は「1人のAIと1対1で会話する」感じだったんです。こちらが「これやって」と言う、AIが考えて手を動かす、結果が返ってくる。その繰り返し。
もちろん前から、サブエージェント(補助のAI)を呼んだり、ワークフローを組んだりはできました。でもそれは、こちらが「並列でやって」「ワークフローにして」と明示的にお願いするか、Claudeがその場の判断で「ちょっとこれは手分けしよう」と決めるか、どちらかだったんですね。
ultracodeは、その判断そのものをAIに常時まかせる設定なんです。
公式ドキュメントの表現を借りると、こうなります。
With ultracode on, Claude decides when a task warrants a workflow. A single request can turn into several workflows in a row: one to understand the code, one to make the change, and one to verify it.
(ultracodeがオンだと、Claudeはどのタスクがワークフローに値するかを自分で判断する。1つの依頼が、連続した複数のワークフローに化けることもある。コードを理解するためのもの、変更を加えるためのもの、検証するためのもの、という具合に)
1つの「これ直して」が、「理解する → 変更する → 検証する」の3つの並列処理プロジェクトに化ける。しかも各プロジェクトの中で何体ものAIが同時に動く。これ、人間のチームで言うと、ひとこと頼んだだけで勝手にプロジェクトチームが立ち上がって、レビュー担当まで付けて返してくる感じなんですよ。
ちょっとすごくないですか。
ultracodeの正体を分解してみる
「xhigh」と「動的ワークフロー」。この2つをもう少し丁寧に見ていきます。ここを理解すると、ultracodeの使いどころが一気に見えてきます。
まず「effort(エフォート)」の話
Claude Codeには「effortレベル」という設定があります。これは、AIがどれくらいトークンを使って(=どれくらい時間とコストをかけて)考えるかを調整するツマミです。
公式ドキュメントによると、effortレベルはモデルによって使えるものが違います。
- Opus 4.8 と Opus 4.7:
low/medium/high/xhigh/max - Opus 4.6 と Sonnet 4.6:
low/medium/high/max(xhighは無し)
lowに近いほど速くて安い、maxに近いほど深く考えるけど高くつく。そういうツマミです。デフォルトはOpus 4.8でhighになっています。
ここで出てくる「xhigh」が、ultracodeがモデルに送る値です。xhighについて、Claude APIのドキュメントはこう説明しています。
Long-running agentic and coding tasks (over 30 minutes) with token budgets in the millions.
(30分を超えるような長時間のエージェント作業・コーディング作業。トークン予算が数百万規模になるもの向け)
そして「Expect meaningfully higher token usage than high.(highよりも明らかにトークン消費が増えると思っておけ)」とも書いてあります。つまりxhighは「ガッツリ考えるモード」なんですね。ultracodeはこのxhighを土台にしています。
ちなみに、よく混同されるんですが「ultrathink」という別の機能もあります。これはプロンプトの中にultrathinkと書くと、その1回だけ深く考えてくれるというもの。effort設定そのものは変えません。ultracodeとは別物なので、ここも覚えておくといいです。
次に「動的ワークフロー(Dynamic Workflows)」
これがultracodeの主役です。
公式の定義はこうです。
A dynamic workflow is a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task you describe, and a runtime executes it in the background while your session stays responsive.
(動的ワークフローとは、サブエージェントを大規模に編成するJavaScriptのスクリプト。あなたが説明したタスクに対してClaudeがスクリプトを書き、ランタイムがバックグラウンドで実行する。その間もあなたのセッションは反応し続ける)
ポイントが3つあります。
1つ目、Claudeが「スクリプト(コード)」を書いて段取りを決めるということ。今までは「Claudeがその場のノリで次の一手を決める」感じでしたが、ワークフローでは「プランがコードに焼き込まれる」。だから読めるし、何度でも同じ手順で再実行できます。
2つ目、バックグラウンドで動くということ。何十体ものAIが裏で並列に働いている間、こちらのチャット画面は固まらない。/workflowsというコマンドで進捗を覗けます。
3つ目、品質を上げる仕組みが組み込めるということ。これが地味に効きます。公式はこう書いています。
It can have independent agents adversarially review each other’s findings before they’re reported, or draft a plan from several angles and weigh them against each other.
(独立したエージェント同士が、報告前にお互いの発見を敵対的にレビューし合ったり、複数の角度からプランを起こして比較検討したりできる)
要するに「1人で1回考えて終わり」じゃなくて、「複数のAIが互いの答えにツッコミを入れてから出す」。だから、単に速いだけじゃなく、答えの信頼性も上がりやすいんですね。
ちなみに、この動的ワークフローは公式に「research preview(リサーチプレビュー)」という位置づけです。出たてホヤホヤ、まだ実験的な段階だということは押さえておいてください。動かすにはClaude Codeのバージョン2.1.154以降が必要で、有料プラン全部+API+Bedrock/Vertex/Foundryで使えます。Proプランの人は/configから手動でオンにする必要があります。
サブエージェント、スキル、ワークフロー。何が違うの?
ここで一回、似た言葉を整理させてください。Claude Codeには「サブエージェント」「スキル」「ワークフロー」という、どれも「複数ステップの作業をこなす」仕組みがあります。混乱しますよね。私も最初ごっちゃになりました。
公式ドキュメントは、この3つの違いを「誰がプランを持っているか」で説明しています。これがいちばん腹落ちする切り口でした。
サブエージェントは、Claudeがその場で生み出す「働き手」です。次に何をやらせるかは、Claudeが一手ごとに判断します。スキルは、Claudeが従う「指示書」です。やることは指示書に沿って、やっぱりClaudeがその場で決める。どちらも、途中の結果は全部Claudeの頭(コンテキスト)に乗っかってきます。
ワークフローはここが違うんですよ。プランがスクリプト(コード)の側にある。ループも分岐も途中の計算結果も、スクリプトが抱えてくれる。だからClaudeの頭には「最終的な答え」だけが返ってくる。公式の言葉だと「A workflow moves the plan into code.(ワークフローはプランをコードに移す)」です。
規模感もぜんぜん違います。サブエージェントやスキルが「1ターンで数体に振る」くらいなのに対して、ワークフローは「1回の実行で数十から数百体」を動かせる。ultracodeが裏で使っているのは、この一番スケールする仕組みなんですね。
実際にどう動くのか
まずは、実際にClaude Codeで動的ワークフローが立ち上がる瞬間を見てください。私のターミナルで撮った、10秒ほどの様子です。
「Running workflow…」と出て、裏でエージェントたちが段取りされていくのが分かると思います。これがバックグラウンドで走っている間も、こちらの操作は止まりません。では、イメージしやすいように、公式が挙げている「ワークフローが向いている仕事」を紹介します。
- コードベース全体を横断する「バグの一斉点検」
- 500ファイル規模の大移行(マイグレーション)
- 複数のソースを互いに突き合わせて検証する調査
- 本番に決める前に、いくつかの独立した角度からプランを起こしておきたいとき
どれも共通しているのは「1人のAIが1回の会話で抱えるには大きすぎる仕事」だということです。
Claude Codeには、この動的ワークフローを使った/deep-researchという標準コマンドが用意されています(Web検索が使えることが前提で、これも前述のリサーチプレビューの一部です)。質問を投げると、いろんな角度からWeb検索を並列で走らせて、見つけたソースを互いに照合して、各主張に投票して、「照合を通らなかった主張は除外したうえで」引用付きのレポートを返してくる。これ、まさに「複数のAIで事実確認してから出す」の実装なんですよ。
ちなみにこの記事自体、ultracodeをオンにした状態で、まさにその仕組みを使いながら書いています。私が「ultracodeについて書いて」と頼んだら、AIが勝手に公式ドキュメントを何ページも取りに行って、書いた原稿の事実を1つずつ照合して……という工程を、裏で並列に回してくれました。この記事の数字や引用は、全部その「複数のAIによる突き合わせ」を通したものです。
「ワークフローを使う」のに、ultracodeは必須じゃない
ここ、勘違いしやすいので補足します。「並列でガッと処理してほしい」だけなら、実はultracodeをオンにしなくてもいいんです。
公式によると、ワークフローを動かす入り口は3つあります。
ひとつ目は、プロンプトの中に「workflow」という単語を入れること。たとえば「Run a workflow to …(〜のワークフローを走らせて)」と書くと、その1回だけワークフロー化してくれます。セッションのeffortは変えずに、ピンポイントで使える方法ですね。
ふたつ目が、今日の主役のultracodeです。これは「毎回、自動で判断してワークフロー化」。常時オンの全自動モードだと思ってください。
みっつ目が、すでにあるワークフローコマンドを実行すること。さっき紹介した/deep-researchがこれですし、自分がよく使う段取りを保存して「自分専用コマンド」にすることもできます(/workflowsでrunを選んでsキーで保存するだけ)。
つまり、「たまにガッツリやってほしい」なら単語ひとつで呼べばいいし、「この作業中はずっと全力でいてほしい」ならultracode、という使い分けができるわけです。
どんなときに使う? どんなときに使わない?
ここ、大事です。「最強モードなんだから常にオンにしとけばいいじゃん」とはならないんです。
公式ドキュメントは、ultracodeについてこう注意しています。
This applies to every task in the session, so each request uses more tokens and takes longer than at lower effort levels.
(これはセッション内のすべてのタスクに適用されるので、各リクエストは低いeffortレベルよりも多くのトークンを使い、時間がかかる)
そう、全部のタスクに適用されちゃうんですよ。「おはよう」みたいな軽い会話にまでフルパワーで考え始めたら、時間もコストも無駄じゃないですか。だから公式も「routine work(日常的な作業)に戻るときは/effort highで落とせ」と書いています。
整理すると、こんな感じで使い分けるといいと思います。
ultracodeが向いているのは、腰を据えた大仕事です。大規模なリファクタリング、コードベース全体の監査、念入りな調査、設計の意思決定。逆に向いていないのは、ちょっとした修正や、対話しながら詰めていきたい作業。ワークフローは走り出すと途中でこちらが口を挟めない(公式いわく「No mid-run user input」)ので、こまめにキャッチボールしたい作業とは相性が悪いんです。
コストの話は、正直にしておきます
ここはごまかさずに書きます。ultracodeは、お金(トークン消費)がかかります。
公式の警告がこれです。
A workflow spawns many agents, so a single run can use meaningfully more tokens than working through the same task in conversation.
(ワークフローは多数のエージェントを生成するので、1回の実行で、同じタスクを会話でこなすよりも明らかに多くのトークンを消費しうる)
1回のワークフローで最大16体のエージェントが同時に動き、1回の実行でのべ1000体まで動く設計になっています。これだけ並列で働けば、当然そのぶん消費は増えます。
実際、この記事を書いたら「これだけ」溶けました
ここでひとつ、生々しい1次情報をお見せします。きれいごとじゃなくて、私が実際にやらかした記録です。
正直に白状すると、この記事を1本書いただけで、トークンを盛大に溶かしました。これがその証拠。記事を書いていたときのClaude Codeの使用状況です。

「86% 使用済み」。チームプランの1セッション枠を、ほぼ使い切っています。「1時間12分後にリセット」という表示も、地味に効いてきますよね。
何にそんなに使ったのか。いちばん効いたのは、さっき触れた「複数AIで事実確認してから出す」、つまりこの記事にかけたファクトチェックの工程です。記事の中の事実の主張を細かく分解して、それぞれを複数の独立した角度から、別々のAIに検証させました。このファクトチェックのワークフロー1回だけで、64体のAIが約37分動き、消費したトークンはおよそ525万(5.25M)でした。記事の本文を書く作業や、公式ドキュメントを何ページも取りに行く工程は、この上にさらに積み重なっています。
念のため、数字は正直に分けて書いておきます。「5.25M」はあくまでファクトチェック工程だけのトークン数。いっぽう「86%」は、このセッション全体でチームの枠をどれだけ使ったかの割合で、トークンの実数とは別物です。この2つを混ぜて「1記事で○○トークン!」と盛るのは簡単なんですが、それをやったら、この記事で散々書いてきた「AIの誇張を一次情報で潰す」という話と矛盾しちゃいますからね。分けたまま、正確にお伝えします。
笑い話のようですが、これがultracodeのリアルです。深く考えて、手分けして、検証してから返す——その「ちゃんとやる」を全部本気でやると、ここまでいく。裏を返せば、速さと信頼性には、ちゃんと代金がかかる、ということです。
なので公式も「大きく回す前に/usageで使用量を確認しろ」「最初は範囲を絞ったタスクから始めろ」と言っています。私もまったく同感で、いきなり全社のコードベースに対してフルスロットルで回すより、まずは1つの機能、1つの調査から試すのが正解だと思います。
使い方(コマンドだけまとめておきます)
難しくないです。セッション中に、こう打つだけ。
/effort ultracode
これでそのセッションはultracodeになります。注意点は「セッション限定」だということ。Claude Codeを再起動すると元に戻ります。設定ファイルに保存して常時オンにする、ということはできません(effortLevelという設定項目には書けない仕様になっています)。
日常作業に戻りたくなったら/effort high。ワークフロー機能まるごと切りたいなら/configのトグルか、CLAUDE_CODE_DISABLE_WORKFLOWS=1という環境変数でオフにできます。
「勝手に何十体も動き出すって、ちょっとこわくない?」と思った方、ご安心を。権限モードにもよりますが、通常モードなら、ワークフローが実際に走り出す前に「この段取りで実行していい?」という確認と、計画されたフェーズの一覧が表示されます。中身を読んでから「Yes」を押せる。いきなり暴走することはない設計になっています。
ここ、カンマンの見解です
さて、ここからは私個人の読み筋です。事実というより「中小企業のAI活用支援をやっている立場から見て、これどう捉えるべき?」という話だと思って読んでください。
私がultracodeで一番おもしろいと思ったのは、「AIに毎回こと細かく指示しなくてよくなる方向」に進んでいる点なんです。
これまでのAI活用って、結局「どれだけうまく指示できるか(プロンプトの腕)」がモノを言いました。でもultracodeは、「深く考えて、手分けして、検証してから出す」という段取りそのものをAI側に持たせにきている。使う側に求められるのが「細かい指示」から「何をやってほしいかを正しく伝えること」と「どこまでコストをかけるかの判断」にシフトしていくんですね。
これ、中小企業にとってはむしろ追い風だと私は思っています。なぜなら、専任のエンジニアやプロンプトの達人が社内にいなくても、「ちゃんと考えて、ちゃんと裏取りしてから返してくれる」AIに近づくからです。リソースが限られている会社ほど、「指示の手間」が減るのはありがたいじゃないですか。
ただし、コストの話とセットで考えないといけません。ultracodeは賢いぶん高くつく。だから現実的には、「普段はhighで軽快に、ここぞの大仕事だけultracodeに上げる」というメリハリが正解だと思います。研修の現場でも、私はこの「使い分け」をいちばん丁寧に伝えるようにしています。最強の道具を持つことより、いつ最強モードを使うかを判断できることのほうが、ずっと実務的な価値があるからです。
そしてもうひとつ。動的ワークフローの「複数AIで互いに検証してから出す」という発想は、AIの一番こわいところ――それっぽいウソ(ハルシネーション)――への、現時点でかなり真っ当な対抗策だと思います。1人のAIに1回聞くより、複数のAIに突き合わせさせるほうが、間違いは確実に減る。これはAIを業務に組み込むときの安心材料になります。
まとめ
長くなったので、ぎゅっとまとめます。
ultracodeは、2026年5月28日、Claude Opus 4.8や動的ワークフローと一緒に登場したClaude Codeの設定で、「xhighの深い思考」と「動的ワークフローの自動編成」を組み合わせたものです。オンにすると、こちらが頼まなくても、AIが実質的なタスクごとに複数のエージェントを並列で動かし、互いに検証してから答えを返してくれます。effortレベルではなく、セッション限定の設定。土台の動的ワークフローはまだresearch preview段階です。
向いているのは大仕事、向いていないのは日常の小さな作業。賢いぶんトークン消費は増えるので、/usageで確認しながら、/effort ultracodeと/effort highを行き来して使い分けるのがおすすめです。
正直、AIにどこまで任せるか、というラインはこれからどんどん上がっていくと思います。ultracodeはその一里塚みたいな機能です。出たてなので荒削りな部分もあると思いますが、まずは小さく試してみてください。触ってみると「あ、もう自分で全部段取りしなくていいんだ」という感覚が、きっと掴めるはずです。
カンマンでは、こういう新しいAIの使いどころを、中小企業の現場で本当に役立つ形に翻訳してお伝えする仕事をしています。「うちの業務だとどう使えばいい?」と気になった方は、ぜひ一緒に考えましょう。

代表取締役
貝出康
1963年徳島市生まれ。 1999年に楽天の三木谷社長の講演を聴き、イン ターネット時代の到来を悟る。翌年、ホームペ ージ制作会社カンマン設立に参画し、これまで のキャリアで培った営業や人事のスキルを活か しての顧客開拓や社内・労務管理を実践。2019 年〜代表取締役。








