Claude Code /goalとultracodeの使い方｜戸野塚蓮さんの解説を、私のループとOpus 5.5で読む

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、戸野塚蓮さんがXに書いた、Claude Codeの/goalとultracodeの使い方の記事を紹介します。

この記事は、私がブックマークに保存していたものです。蓮さんは、AI経営術LIVEで私と一緒に出ているスタメンの仲間です。そのLIVEの仲間が書いた記事を読んで、10月10日に私がベンチマークループで回した型と重なる所が多いと感じました。9月に出たOpus 5.5の発表とも噛み合います。

まず蓮さんの解説を順に追います。次に、私がベンチマークループで実際に回した使い方を書きます。最後に、Opus 5.5の発表と合格条件で回す運用がどこで噛み合うかを読みます。

X記事「【保存版】Opus 5が一発でゲームを作った、その先へ。/goalとultracodeの使い方、全部書きます」（戸野塚 蓮さん（AIVEST CEO・記事の筆者）の記述・冒頭の「316万インプの「ワンショット」と、月曜の朝…」の節）

道具は最先端なのに、働き方は手作業のまま。

蓮さんがこの章で言っているのは、使っている道具は最先端なのに、仕事の進め方は昔の手作業のままだ、ということだ。

2026年7月26日に、海外のあるアカウントが「Claude Opus 5がこのゲームをワンショットで作った」と投稿しました。フォロワーは37万人超です。

投稿は週末のうちに316万インプレッションまで伸び、ブックマークは3,528件つきました。

ワンショットとは、一度の指示だけで完成品を出させることだ。蓮さんは、デモとしての完成度は本物だと認めている。そのうえで、同時に別のことを考えていたと書いている。

蓮さんが記事を書いている日は月曜日です。月曜の朝に目の前にあるのは、ゲームのデモではなく、今週も続く仕事だと言います。

Claude Codeを触っている人の多くが月曜の朝にやっているのは、指示を打つ、出力を見る、直しの指示を打つ、また出力を見る、という往復だ。蓮さんは、これを人間が検品係をやっている状態だと見ている。

AIが作業をして、人間が品質チェックをして、また指示を打つ。道具は最先端でも、働き方は手作業のままです。蓮さんはこれを「高級な手作業」と呼んでいます。

ワンショットのデモは、一発で終わるから美しい。でも実務は、月曜も火曜も水曜も続きます。

蓮さんはそう整理して、実務で効くのは「一発で作らせる」ことではなく、合格条件を渡して達成するまで回し続けさせることだと続けます。

あなたも、Claude Codeの画面の前で、この往復を毎日くり返していませんか。地味ですが、一日の時間を一番食うのはここです。

蓮さんの記事は7月28日に書かれました。Opus 5の時代です。私が読んでいるのは10月で、9月22日にはOpus 5.5が出ています。このことは第7章で書きます。

私の読みです。この記事で持ち帰ってほしいのは、一発で作らせる技ではありません。合格条件を渡して、AIに回し続けさせるという考え方です。次の章で、その中心になる/goalが何をしてくれる機能なのかを見ていきます。

「道具は最先端なのに、働き方は手作業のまま」。AI経営術LIVEで一緒に出ている蓮さんの言葉だと思って読むと、人ごとには聞こえません。

X記事「【保存版】Opus 5が一発でゲームを作った、その先へ。/goalとultracodeの使い方、全部書きます」（戸野塚 蓮さん（AIVEST CEO・記事の筆者）の記述・「ワンショットは指示。/goalは合格条件」の節）

ワンショットは指示。/goalは合格条件。

ワンショットは一往復で終わる指示で、/goalは達成するまで回り続ける合格条件です。蓮さんの整理は、この違いから始まります。

使い方は、/goalに続けて完了条件を1行で渡すだけだ。蓮さんが挙げる公式の例は「全テスト通過とビルド成功」だ。テストは、プログラムが正しく動くかを機械が確認する検査。

ビルドは、プログラムを実行できる形に組み上げる工程のことだ。

裏では、各ターンの終了後に、小型の高速モデルが条件を評価します。未達なら次のターンを自動で始め、達成したら自動で止まります。

作業を中断しても、resume（中断した作業を再開する機能）で条件は引き継がれます。蓮さんによると、v2.1.139以降で使えます。

蓮さんは、これを経営者の言葉に直しています。「作業を頼む」から「検収条件を渡す」への切り替えです。優秀な外注先に仕事を出す時、手順書を渡す人は少ないですよね。「この状態になったら納品」を渡して、過程は任せます。

Claude Codeの公式ドキュメントによると、判定役はコマンドを実行せず、会話に出た結果だけを見ます。だから条件には、会話の中に結果が出る検証、たとえばテスト通過を含めます。ここは地味ですが、大事な点です。

同じく公式ドキュメントによると、条件は、終わりの状態を1つ、確かめ方、制約で書き、4,000字以内です。「20ターンで止まる」のような上限の一文も足せます。

中断してもresumeで目標が引き継がれ、-p（非対話実行）でも使えます。

AI氣道『AIに12時間放り投げて成果物が出てくる人と、3時間で見に行っちゃう人の違いは「終了条件」だった』より

「すごいのは「時間」じゃない。「終了条件が第三者にある」設計だった」

この向きを、私は『AIに12時間放り投げて成果物が出てくる人と、3時間で見に行っちゃう人の違いは「終了条件」だった』で書いています。

私の読みです。/goalの判定役は、作業しているAIとは別にいます。作った側に「終わった」を言わせず、終わりの判定を別の役が持つ。これが「終了条件が第三者にある」設計と同じ形だと、私は読みました。

つまり、AIを使う私たちが渡すのは、作業の手順ではなく、終わった状態の定義です。判定が作業とは別の所にあるから、途中の出来が悪くても、AIは自分でやり直せます。

検品係が人間からAIに移る、という蓮さんの言い方は、この構造を指しているんですよね。

X記事「【保存版】Opus 5が一発でゲームを作った、その先へ。/goalとultracodeの使い方、全部書きます」（戸野塚 蓮さん（AIVEST CEO・記事の筆者）の記述・「種明かし。「ワンショット」の指示文には、ループが書いてあった」の節）

一発芸に見えたものの裏側は、合格条件と審査役と反復を1枚に書き切る、ループの設計だった。

蓮さんが言っているのは、一発芸に見えたものの裏側が、合格条件と審査役と反復を1枚に書き切る、ループの設計だったということだ。

蓮さんは、ワンショット投稿の主が引用ツリーで公開した指示文を解剖している。冒頭に付いているのは/goalだ。人間の入力が1回だった、というだけで、中身はワンショットの対極だと蓮さんは見ている。

分解すると、4つの部品が入っています。1つ目は担当の分解で、項目ごとにサブエージェントを1体ずつ割り当てます。サブエージェントとは、本体から分かれて働く小さなAIの働き手のことです。

2つ目は独立した審査役です。作る側とは別のAIを辛口の批評家として立て、自己採点をさせません。3つ目は外に置いた物差しで、本物のCall of Dutyと、どちらが作った側か伏せて並べる比較です。

4つ目は反復の明示で、各項目を/loopで、審査役が唸るまで回します。

蓮さんは、この4つが自分の「ゴール設計」の部品とほぼ同じだと書いている。

AI氣道『AIが作った物の確認を、npakaさんが解説。Anthropicの7段階レビューと、人に残る5つの判断』より

「作った本人に「終わった」を言わせない点は、同じです。」

この点を、私は『AIが作った物の確認を、npakaさんが解説。Anthropicの7段階レビューと、人に残る5つの判断』で書いています。

私も、同じ型を回しています。ベンチマークループというスキルを持っていて、作った物を、手本と同じ物差しで、作者を伏せて審査し、負けた軸を直して回します。

10月10日、自分で作ったループ画面を、既存のループ管理の道具RisingLOOPと比べた。作る側はClaude Sonnet 5.5、審査はCodex（別会社のAI）だ。

目的と期待結果は、作る前に書いて封印した。審査は順番を入れ替えて2回だ。

機械の検査4件（テスト・実行・HTTP・ファイル）は全部通過しました。途中で基準を変えたことは0回です。11軸のうち9軸で私の版が上、2軸は同じ、負けは0で、2回とも同じ結果でした。

蓮さんの4部品に当てると、担当の分解は作る側と審査を分けること、独立した審査役は別会社のAI、外に置いた物差しは手本のRisingLOOPと作る前に封印した期待結果、反復は負けた軸を直して回すことです。

「完璧になるまで」ではなく、軸ごとのラウンド上限で回す点は、第5章で書きます。

X記事「【保存版】Opus 5が一発でゲームを作った、その先へ。/goalとultracodeの使い方、全部書きます」（戸野塚 蓮さん（AIVEST CEO・記事の筆者）の記述・「合格条件の書き方、最小手順【コピペ用】」の節）

感想ではなく、機械が数えられる条件。

合格条件は、感想ではなく、機械が数えられる形で書く。蓮さんが一番細かく書いているのは、ここだ。

蓮さんの最小手順を順に書きます。1つ目は、終わった状態を1行で書くこと。やり方は書きません。2つ目は、機械が合否を判定できる検証を条件に含めること。

全テスト通過、ビルド成功、E2Eテスト通過のいずれかです。3つ目は、足りなければresumeで条件を継ぎ足すこと。一発で完璧な条件を書こうとしません。

雛形は「/goal 作りたいもの・終わった状態を1行。全テスト通過とビルド成功。」です。作りたいものを自分の業務名に書き換えれば使えます。

「いい感じにして」は、合否の判定が人間の感想になるので、合格条件になりません。

開発以外の例も出ている。請求書と入金記録の突合表なら、全件一致し、不一致は理由つきの一覧になっていること。競合10社の比較表なら、10社全てに出典URLがつき、リンク切れがゼロであること。

週次レポートなら、数字の欠損がゼロで、全項目に前週比が入っていることだ。

どれも、条件の後半が「数える・照合する」形です。件数の一致と欠損ゼロ、それにリンク切れゼロ。この形なら、開発以外の仕事でも書けます。

蓮さん自身の実例が、quiz-trainerというWebアプリだ。最初の発注は曖昧な1行だった。

E2Eテスト（利用者の操作を最初から最後まで通しで確認する自動テスト）の3ファイル・6件は、走らせたあとのやり取りで後から締めたものだ。

蓮さんによると、Anthropic公式の「Getting started with loops」の投稿も同じ向きだ。

605万インプレッション、ブックマーク38,807件で、最も単純な解から始めること、検査が定量的なほどClaudeは自己検証しやすいことが書かれている。

私の読みです。10月10日の回で、私が作る前に書いて封印したのは、期待結果6件でした。

例えば「打ち手の依頼ボタンを押すと、その内容を持つCockpitのタスクが作成され、画面から依頼先のタスクを確認できる」です。人が画面で確かめられる文にして、作る前に決めました。

機械が数えられる検査（テスト・実行・HTTP・ファイルの4件）は、別に置きました。合格条件は、数える部分と、人が試して確かめる部分の2本立てにできる、と私は読んでいます。

私なら、数える部分をAIに任せて、試して確かめる部分を自分で持ちます。

X記事「【保存版】Opus 5が一発でゲームを作った、その先へ。/goalとultracodeの使い方、全部書きます」（戸野塚 蓮さん（AIVEST CEO・記事の筆者）の記述・「種明かし。「ワンショット」の指示文には、ループが書いてあった」の節）（同じ節のもう1つの発言）

合格条件とセットで必ず「達成、または上限」を書きます。

蓮さんが言っているのは、合格条件を渡す時は、必ず「達成、または上限」の2つを書く、ということだ。

蓮さんは、ワンショット投稿の指示文の停止条件が「完璧になるまで止まるな」しかない点を指摘している。デモならそれでいい。でも実務でこれをやると、止まる保証のないループを回し続けることになる、という見方だ。

もうひとつ、蓮さんは書いています。「唸るまで」「どちらが良いか」は、審査役の感想です。見た目が命のゲームなら正解ですが、書類仕事なら、機械が数えられる条件まで落とせます。

Claude Codeの公式ドキュメントによると、/goalの条件には「20ターンで止まる」のような一文を足せます。上限は、機能として最初から用意されているんですよね。

私のベンチマークループにも、同じ考えが仕組みとして入っています。使う量の上限（トークン、エージェントの呼び出し回数、同時に動かす数）を、回す前に決めます。軸ごとのラウンド上限は5です。

超えたらループを止めて、状況を添えて人に判断を返します。選べるのは、続行、軸を緩める、中止です。

10月10日の回も、回す前に上限を決めました。トークンは160万、エージェントの呼び出しは40回、同時に動かす数は2です。終わってから実績を測ると、呼び出しは18回、同時は2でした。

トークンは、測れた分で約164万。上限をわずかに超えていました。1回分は数字が取れず、合計に入れていません。上限は、書いておくだけでは守れたか分かりません。測って、はじめて確かめられる線です。

AI氣道『Claude Code /goalなら毎週同じ指示を打ち直さずに済む、飯塚浩也さんの解説』より

「停止条件は、止める上限と、返すものの2行で一組。」

この考えは、私の過去記事では『Claude Code /goalなら毎週同じ指示を打ち直さずに済む、飯塚浩也さんの解説』で書いています。

止まった時に何を返すかは、回し始める前にしか決められません。

その記事に書いたとおり、2026年9月22日20時42分に、有効な自動実行126本のうち13本が、私への確認の問いを出さないまま待ちで止まっていました。

止まったことより、止まった理由が私に届かなかったことが問題でした。

私なら、止める上限と一緒に、止まった時に返すものを先に書きます。進んだ所と、私が決めること。この2つです。上限は暴走を防ぐ線で、返すものは、止まったあとの月曜の朝を楽にする線だと、私は読んでいます。

X記事「【保存版】Opus 5が一発でゲームを作った、その先へ。/goalとultracodeの使い方、全部書きます」（戸野塚 蓮さん（AIVEST CEO・記事の筆者）の記述・「ultracodeの正体。1体との会話が、編成の総力戦に変わる」の節）

合格条件で終わりを定義し、ultracodeで体制を定義する。

合格条件は終わりを決めるもので、ultracodeは働く体制を決めるもの。蓮さんは、この2つを分けて説明している。

蓮さんによると、ultracodeはClaude Code v2.1.203以降で入った総力戦モードです。

使い方は2つで、プロンプトに「ultracode」と書くか、/effort ultracodeを指定します。

裏では、まず推論が最も深いレベルに切り替わります。次に、そのタスク専用のワークフロー（作業手順のプログラム）が自動で生成されます。

そのプログラムが、最大16並行、合計1000体を上限とするサブエージェントの編成を組みます。途中経過はプログラム側に蓄積され、画面には最終回答だけが返ります。

蓮さんは、これを機能の追加ではなく働き方の変更だと言います。1体のAIと会話する働き方から、数十体の編成を采配する働き方へ。プレイヤーの道具ではなく、監督業の道具、という表現です。

/goalと組み合わせる時は、1行に同居させます。蓮さんの例が次の1行です。

X記事「【保存版】Opus 5が一発でゲームを作った、その先へ。/goalとultracodeの使い方、全部書きます」（戸野塚 蓮さん（AIVEST CEO・記事の筆者）の記述・「ultracodeの正体。1体との会話が、編成の総力戦に変わる」の節）（同じ節のもう1つの発言）

/goal 記録アプリを公開する。全テスト通過とビルド成功とE2Eテスト通過。 ultracode

前半が検証までを含めた合格条件、末尾のultracodeが総力戦の指定です。

使いどころは、網羅が要る仕事（全件レビュー・監査・移行）や、独立に並列できる案件だ。会話で詰めたい相談や、小さな修正1件には向かないと蓮さんは書いている。

蓮さんは、普段は/goal単体、総力戦に値する案件だけ末尾に一語、と使い分けている。

Claude Codeの公式ドキュメントによると、キーワードのultracodeは、対話中のプロンプトでだけ効きます。-p（非対話実行）、定期実行、Webhookでは効きません。

同時に動くエージェントは既定で最大16、1回の実行で上限1,000です。使うトークンも時間も増え、利用上限に早く届きます。

私は、9月23日の登壇スライドを、UltraCodeのワークフロー（10エージェント）で新規55枚作らせました。指示は「UltraCodeでやって最速で最高品質の内容にして」です。

本番はその55枚で確定しました。同じ記録には、日本語の文字化けなど、あとで直した失敗も残っています。

私の読みです。私は決まった時刻に動く自動実行を多く持っています。そこではキーワードが効かないので、キーワードに頼らず、合格条件と上限を書く側に寄せます。

ultracodeは、私が画面の前にいる、網羅が要る日のための一語です。

X記事「【保存版】Opus 5が一発でゲームを作った、その先へ。/goalとultracodeの使い方、全部書きます」（戸野塚 蓮さん（AIVEST CEO・記事の筆者）の記述・「一発で作るのは芸。毎日回るのは仕組み」の節）（同じ節のもう1つの発言）

一発で作らせる人で終わるな。合格条件を設計する側へ。

蓮さんの結びは、一発で作らせる人で終わらず、合格条件を設計する側に回ろう、でした。この章では、その先を公式の発表と重ねます。

蓮さんの記事は7月28日で、Opus 5の時代に書かれた。Anthropicの発表によると、Claude Opus 5.5は2026年9月22日に公開されている。

発表のTerminal-Bench 4.0では、Opus 5.5が66.4%だ。

Opus 5は52.3%、Fable 5.1は55.8%、GPT-6 Astraは57.9%で、Opus 5.5が最も高い数字だ。

Opus 5.5の結果はxhigh effortでの測定だと注記されている。出力はOpus 5より30%以上速い、とも書かれている。

顧客の声も載っています。Clioのショーン・ハインツさんは、18時間以上、同じ作業に集中し続けたと話しています。別の声では、サブエージェントへの振り分けがずっと上手で、自分の仕事を工夫して確かめる、とあります。

安全面では、取り返しのつかない操作をする可能性が最近のモデルよりずっと低いと書かれている。境界をすり抜けようとする頻度は、Opus 5より約85%少ない、という数字も出ている。

私の読みです。合格条件で回す運用は、長い作業で脱線しないこと、サブエージェントへの振り分けが上手なこと、止まる所で止まること、の条件が揃うほど効きます。

第2章の/goal、第3章の担当の分解、第5章の上限は、この条件とそのまま噛み合います。

だから私は、Opus 5.5なら合格条件で回す運用は一段効く、と読んでいます。ここは、あなたの仕事でも当てはまるところかな、と思います。

ただし線引きがあります。この数字はAnthropic自身の測定で、設定（xhigh）も注記されています。私の10月10日の回は、作る側がSonnet 5.5でした。Opus 5.5での実測は、まだありません。

次にやることは決めています。作る側だけをOpus 5.5に替えて、同じ目的の封印、同じ別会社の審査、同じ上限で回し、11軸の結果を比べます。

モデルが替わっても、書くのは終わった状態と、止める上限です。ここは変わらないと、私は思っています。

蓮さんとは朝LIVEを2人で始めた仲間で、今はAI経営術LIVEにも一緒に出ています。Opus 5.5をこの物差しで比べる時は、同じLIVEの場で蓮さんと話してみたい題材だと思っています。

戸野塚蓮さんの記事の中心は、ワンショットは指示、/goalは合格条件、という整理でした。指示は一往復で終わり、合格条件は達成まで回り続けます。

一発に見えたゲームの指示文にも、担当の分解、独立した審査役、外に置いた物差し、反復の4部品がありました。私が10月10日に回したベンチマークループも、同じ型です。11軸のうち9軸で私の版が上、負けは0でした。

合格条件は、終わった状態を1行で書き、機械が数えられる検証を含めます。そこに、止める上限と、止まった時に返すものをセットで書きます。ultracodeは、網羅が要る案件の体制を決める一語です。

Opus 5.5の発表は、長い作業での集中、サブエージェントへの振り分け、境界を守る点で、この運用と噛み合うと私は読んでいます。私のOpus 5.5での実測はまだないので、作る側だけを替えて同じ物差しで比べます。

まずは今日の業務のどれか1つを、指示ではなく合格条件で発注してみてください。あなたの検品係の時間が、少しずつAI側に移っていきます。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！