1. 完了条件を1文書くと、AIは条件を満たすまで自分でターンを回し続ける。
2. customer-portalの4機能を、逐次プロンプトなしで完走させた実体験ベース。
3. 効く条件の核心は「検証結果を会話に出させる」一文。公式情報で裏取り済み。

Claude Codeを毎日触っていて、地味にストレスだったのが「続けて」の連打だ。AIがひと仕事するたびに手を止めて、また同じ指示を打つ。SE歴20年で本業も副業もClaude Code Max 5xで回している筆者でも、この往復は効いた。

/goalコマンドはこの往復を消す。完了条件を1文書くと、AIは条件を満たすまで自分でターンを回し続ける。実際にcustomer-portalの生産パイプラインを設計工程まで広げる4機能を、逐次プロンプトなしで完走させた。この記事は、その実体験で分かった「効く完了条件の書き方」を軸に、Anthropicの公式ドキュメントで裏を取りながらまとめる。

ムラサキ

最初は半信半疑だった。でも一度走らせたら、詰まっても止まらず原因を追い続けるAIを横で見て、考え方が変わった。

/goalとは？「続けて」連打から解放される仕組み

「続けて」を何度も打っていた従来のClaude Code

通常のClaude Codeは1ターンごとに手を止める。テストを書いて、止まる。「続けて」。実行して失敗、止まる。「続けて」。長い作業ほど、この間に人が挟まる回数が増える。

問題は手数だけじゃない。人が間に入るたびに集中が切れ、AIがどこまで進んだかを毎回読み直すことになる。タスクが大きいほど、この「Enterを押す係」の負担が重くなっていく。

/goalの動作フロー：評価器が毎ターン完了判定するループ

/goalは完了条件をひとつ受け取り、その条件を満たすまでターンを自動で回す。Anthropicの/goalコマンド公式ドキュメントによると、各ターンが終わるたびに小さく速い評価モデル（既定はHaiku）が「条件は満たされたか」を判定する。未達ならその理由を次ターンへの指示として渡し、もう一度ターンを始める。条件が満たされた瞬間にゴールは自動で解除され、Claudeは通常モードに戻る。

graph TD
  A["ターン実行"] --> B["評価器が判定"]
  B -->|"未達 理由を渡す"| A
  B -->|"達成"| C["ゴール自動解除"]
  B -->|"打ち切り句"| D["停止"]
  style A fill:#e8eef6,stroke:#9fb3cc
  style C fill:#e8f3ec,stroke:#9ec7ad
  style D fill:#f3ece8,stroke:#c7b09e

筆者の実行では、途中で2回詰まった。1回目は"use server"ファイルでobjectをexportしてアクションが全滅したケース、2回目はagent-browserのclickがServer Actionを発火させなかったケース。どちらも/goalは「未達」と扱って継続させ、原因の特定から修正まで自走でやり切った。止まらず原因追及を続けるこの粘りが、人が「続けて」を打つ運用との一番の差だった。

コスト感覚：自走で消費トークンはどう変わるか

正直に書くと、正確なトークン数は筆者の手元では計測していない。ただ確認手段はある。引数なしで/goalを打てば、その時点のターン数とトークン消費が出る。これが唯一の実測手段だ。

体感はこうだ。「続けて」連打は人が間に入る分、自然にペースが制御される。一方/goalは人の入力なしで連続ターンが走るので、短時間に多くのターンが進み、消費は速い。判定役のHaiku分は、公式も本体ターンに比べて無視できる量だと明記しているので、評価器のコストは気にしなくていい。気をつけるべきは本体ターンの速度のほうだ。トークン単価そのものを詰めたい場合は、Opus・Sonnet・Haikuを役割で分ける3層スタックでコストを半減させる手順が効く。

完了条件の書き方：自走を成功させた実例

効いた条件の4要素

公式ドキュメントは、長いターン数を越えても崩れない条件の要素を挙げている。測定可能な終了状態、それをどう証明するかの手段、途中で壊してはいけない制約だ。筆者が実際に走らせて完走した条件は、これに打ち切り句を足した形だった。

/goal customer-portalの生産パイプラインを設計工程まで拡張する。
レビュー収束性・承認フロー・改訂自由指示・設計工程の横展開の4機能を実装し、
npx tsc --noEmit がエラー0で、各機能を実際にsupabaseで確認した結果を会話に示し、
既存機能を壊さないこと。 or stop after 60 turns

要素を分解すると、こうなる。

条件は最長4,000文字まで書ける。短くまとめる必要はないので、終了状態・証明手段・制約を遠慮なく詰め込んでいい。

最重要は「検証結果を会話に出させる」一文

4要素のなかで決定的だったのは、「supabaseで確認した結果を会話に示す」の一文だ。評価器は会話に出た内容しか見ない。コマンドを自分で叩いたりファイルを読んだりはしない。公式も評価器について、Claudeが会話で表に出したものしか判定できないと明記している。

つまり「検証結果を会話に出させる」と書くことで、AI自身が検証ログを吐くよう仕向けられる。この一文がないと、AIは内部で「できたつもり」になっても、評価器にはそれが見えず判定が進まない。逆にこの一文があると、AIは証拠を会話に残しながら進むので、判定がきれいに通る。

ムラサキ

「会話に出させる」を入れるか入れないかで、自走の安定感がまるで違った。評価器の目線で条件を書く、という発想が要る。

主観条件が引き起こす「止まれないループ」

逆に入れてはいけないのが主観条件だ。筆者は「UXを良くする」のような条件は最初から外した。評価器が良し悪しを測れないからだ。

公式が挙げる典型的な失敗例も「本番運用に耐える品質（production-ready）」型の条件で、検証可能な出力を生まないため達成判定が出ない。条件が甘すぎれば早すぎる解除、達成不能なら打ち切り句に当たるまで回り続ける。会話に証拠が出る客観条件だけが機能する–これは実際に走らせて骨身にしみた。

「指示を出す人」から「仕事を設計する人」へ

曖昧な指示はAIにも人にも通じない

完了条件を書く作業は、要するに「終わりの定義」を言語化する作業だ。これはAI特有の話じゃない。曖昧な指示は人間の部下にも通じない。「いい感じにして」で動ける人はいない。

AIの場合、曖昧さは別の形でも牙をむく。指示が緩いと、存在しない仕様を勝手に埋めてくることがある。プロンプトが育ちすぎて888行プロンプトで起きた破綻を一度経験すると、客観的に検証できる指示だけが効くという感覚が身につく。/goalの完了条件は、その感覚を毎回強制してくる。

完了条件を書く訓練が仕事の解像度を上げる

「会話に証拠が出る客観条件だけが効く」という制約は、副業開発でそのまま武器になる。何をもって完了とするかを1文で書けるなら、その仕事は設計できている。書けないなら、まだ自分の中でゴールが曖昧だということだ。

筆者がCLAUDE.mdとBUGS.mdを使い分ける運用に行き着いた経緯は個人サービスを作った正直な話に書いたが、結局どれも同じ方向を向いている。AIを動かすほど、自分の指示の甘さが可視化される。/goalはその最先端で、「指示を出す人」を「仕事の終わりを定義する人」に変えていく。

Agent View・/loopと組み合わせる（公式情報・筆者未検証）

claude agentsで並列セッションを一望する

複数のセッションを並列で回すと、ターミナルのタブが増えて、どれが終わったか分からなくなる。AnthropicはAgent Viewの公式発表で、claude agentsコマンド（またはセッション内で左矢印）から全セッションを1画面に並べる仕組みを示している。各行に「どれが入力待ちか・作業中か・完了したか」が出る研究プレビュー機能だ。

/goalを背景で走らせ、その進捗をAgent Viewで眺める、という組み合わせが想定できる。並列実行やHooksの基礎をまず固めたい場合は、/powerupで隠れ機能を体系的に学ぶ手順から入ると地続きで理解しやすい。

/loopとの違い：時間駆動 vs 完了駆動

/goalと混同しやすいのが/loopだ。公式の比較によれば、/goalは「前のターンが終わったら次が始まり、条件を満たすと止まる」完了駆動。/loopは「一定間隔で同じプロンプトを再実行する」時間駆動で、夜間テストや朝の定期チェックに向く。終わりが条件で決まる作業は/goal、決まった間隔で回したい作業は/loop、という切り分けになる。

朝に仕込んで夕方確認するハーフオート運用

公式は、開いたセッションとは独立に夜間テストや朝の仕分けを走らせるスケジューリングにも触れている。背景セッションとAgent View、あるいは/loopを組み合わせれば、朝に仕込んで夕方に結果だけ見る運用が描ける。ただし筆者の今回の実行はインタラクティブな単一セッションで、ここまで完走させたところまでだ。背景＋並列の本格運用は未検証なので、組み合わせる際は小さく試してから広げてほしい。

/goalが動かないときの前提条件

信頼ダイアログとフックシステム

/goalの実体は、セッション単位のStopフックのラッパーだ。だから公式のフックガイドが示すフックシステムが動く環境が前提になる。具体的には、信頼ダイアログを承認したワークスペースでないと/goalは動かない。承認していない場合、コマンドが理由を表示してくれるので、無反応で悩むことはない。

法人・チームのポリシーで無効化される

会社のmanaged policy設定でdisableAllHooksが有効になっていると、フックごと無効になり/goalも使えなくなる。チームや法人のClaude Codeで「コマンドが反応しない」場合は、まずこの管理ポリシーを疑うといい。これも公式のRequirementsに明記されている挙動だ。

バージョン確認とアップデート

/goalもAgent Viewも比較的新しい機能で、Agent Viewの研究プレビューはv2.1.139以降が要件とされている。claude --versionで確認し、古ければnpmで更新しておく。完了判定の精度はバージョンが上がるほど改善されているので、新しめに保つのが無難だ。

今日から始める/goal活用ステップ

副業開発で試すなら、いきなり大物に当てず、小さく回して感覚を掴むのが近道だ。

よくある質問

まとめ

/goalを実際に使って分かったのは、3つだ。

ひとつ、完了条件を1文書くだけで、AIは詰まっても止まらず条件を満たすまで自走する。ふたつ、効く条件の核心は「検証結果を会話に出させる」一文で、評価器は会話しか見ないからここが決定的。みっつ、客観的に検証できる終了状態だけが機能し、主観条件は止まれないループを生む。

まず手元で「続けて」を連打しているタスクを1つ選び、終わりを1文で書いてみる。それが書けたなら、その仕事はもうAIに渡せる。書けないなら、自分の中でゴールがまだ曖昧だというサインだ。/goalは、その曖昧さを毎回突きつけてくる道具でもある。

ムラサキ

「Enterを押す係」から卒業すると、空いた時間で次の設計を考えられる。副業の時間は有限だから、この差は大きい。

結論：プロンプトは問題発生のたびにルールを追加する運用では必ず肥大化する。2026年4月時点の筆者のプロンプトは888行・22セクション・65チェック項目で、AIが全体を一貫して追従できる限界に近い。モデルのバージョンを上げても解決しない。対策は「プロンプトの改修」だけでなく「AIに任せる範囲を狭める」方向に踏み込む必要がある。

ムラサキ

この記事は、その壊れたAI応答を目撃した直後に書き始めました。リアルタイムの事例として残します。

プロンプトが育ちすぎて何が起きたか

今回発生した事象を具体的に記録する。同じパターンに気づいていないだけで、他の利用者にも起きているはずだ。

発生した具体事象①｜存在しない成果物番号を創作

今回のAI応答には、article_prompt.mdに存在しない成果物番号が6つ出力された。正解は「成果物2：アイキャッチ画像テキストデータ」「成果物3：記事データ」「成果物4：既存記事対応リスト」の3つだ。AIが生成したのは次の通り。

特に深刻なのは「成果物3：スプレッドシート行（タブ区切り）」だ。これはMake経由でスプレッドシートにAI出力を流し込んでいた時代の古い仕様で、現行のAPIパイプライン移行後は廃止されている。AIはプロンプト本文の現行仕様ではなく、過去の痕跡か自己の学習データから古い形式を再構成した。

発生した具体事象②｜Cocoonブロックのテンプレ逸脱

事象はこれだけでは終わらなかった。同じAIが本文HTMLを出力した際、Cocoon独自ブロックのテンプレートを9箇所全てで逸脱していた。最も分かりやすい例が吹き出しブロックだ。

プロンプトの吹き出しテンプレートでは、JSON属性のキー名としてname・icon・iconid・id・indexの5つを明示している。またサイト別のアイコンURLも具体的に記載されている。にもかかわらずAIが出力したHTMLは次のようだった。

JSON属性のキー名は完全に創作されている。プロンプトにはiconImageやiconNameという文字列は出現しない。AIが自己の学習データから別形式のCocoon記述を想起し、プロンプト内の正規テンプレートより優先して出力した。

timeline・faq・icon-boxでも同じパターンの逸脱が起きた。特にfaqは5問分全てがプロンプトの正規テンプレートと構造が異なり、WordPress投稿後にバリデーションエラーが出た。

過去にも起きていたブロック構造崩れ・登録漏れ

プロンプト肥大化による破綻は、実は以前から別の形で起きていた。Cocoon独自ブロック（FAQ・timeline・icon-box等）のclass名や属性を守れず、WordPress投稿後にブロックが崩れるケースが多発していた。

また、記事更新時の変更履歴登録漏れも繰り返し発生した。本文中に「更新履歴を必ず追加する」と記載していても、AIが見落とす。問題が起きるたびにプロンプトへチェック項目や禁止パターンを追加してきた結果、現在は65項目まで膨らんだ。

問題発生は「AI側の劣化」ではなく「プロンプト側の設計限界」

今回の事象は2026年4月16日にClaude Opus 4.7がリリースされた翌日に発生した。「4.7が4.6より指示を取りこぼしやすい」という解釈も成り立つが、1サンプルでモデル傾向を断定するのは早計だ。

本質的な原因はプロンプト側にある。どれだけモデルが賢くなっても、888行の指示を完全に追従できる保証はない。問題発生のたびにルールを追加する運用を続ける限り、いずれ破綻する。プロンプト設計そのものを見直す必要がある。

肥大化の軌跡｜0項目から70項目超までの成長曲線

65チェック項目に至るまでの経緯を整理する。同じ道を避けるための参考になるだろう。

問題発生のたびにルール追加で膨らんでいく構造

最初はチェック項目ゼロから始まった。AIに記事を書かせ、出力に問題が出るたびに「次回から○○しないこと」というルールを1行追加する。この運用で最終的に70項目を超える規模まで膨らんだ。

各項目は「発生実績のある問題への対策」なので削りづらい。削った瞬間に同じ問題が再発する恐怖がある。加算のみで減算がない運用になってしまう。

運用基盤の変更（スプレッドシート→パイプライン）で一気に不要化

転機は運用基盤の変更だった。以前はAI出力をスプレッドシートに貼り付け、Makeで自動投稿する構成だった。タブ区切り形式・文字数制限・Make連携専用のルールが多数存在していた。

WordPress REST APIへ直接投稿するパイプラインに移行した際、Make連携前提のルール群が不要になった。この棚卸しでチェック項目は2〜3割削減できた。重要なのは「不要ルールが2〜3割も残っていた」という事実だ。

現状の規模と「AIが読める限界」の体感値

2026年4月時点のarticle_prompt.mdの規模。

• 全888行・約72,000文字（およそ2.5万〜3万トークン）
• 22セクション
• 65項目のセルフチェック
• バージョンv4.3（複数回のリファクタリングを経由）

Claudeのコンテキストウィンドウ1Mトークンに対しては微々たる量だが、「指示を正確に追従できる規模」という観点ではすでに限界付近だ。プロンプト側の複雑度が高ければ取りこぼしが発生する。

AIが落ちるパターンの分類

運用で観測したAI応答の破綻パターンは3つに分類できる。タイプごとに原因と対策が異なる。

AIモデル側だけでなく、Claude Codeのクライアント側に起因する詰みもあります。代表例として画像貼付で発生する400エラーの構造を別記事で扱っています。

取りこぼし｜指示が効かなくなる

プロンプトに書かれた指示が出力に反映されないパターンだ。長文インプットでは指示の一部が漏れやすい。プロンプト規模が大きいほどリスクは高まる。

対策は「重要なルールを冒頭と末尾に配置する」こと。ただし重複するとプロンプト自体が肥大化するため、本当に重要な項目だけ冒頭に再掲する運用が現実的だ。

創作｜存在しない仕様を自己生成する

プロンプトに明記されていない仕様を、AIが学習データやプロンプト内の曖昧な表現から再構成して出力する。厄介なのは創作内容がそれらしい形式を保つため、検知が難しいことだ。

対策は「成果物の番号・名称・数をプロンプト冒頭で明示する」こと。article_prompt.mdでは1行目に「3つの成果物を出力してください」と書かれていたが、AIは最終的に6つ出力した。冒頭の明示だけでは足りず、出力テンプレート自体に「成果物2」「成果物3」「成果物4」の見出しを固定する対応が必要だ。

構造崩れ｜テンプレ厳守の指示でも出力がズレる

Cocoon独自ブロックのclass名・属性・ネスト構造が1バイトでも違うと、WordPress投稿後にブロックが崩れる。「テンプレートを1文字も変えずにコピーする」と指示しても、AIが微妙に変形させる事象が繰り返し発生した。

プロンプト内にテンプレート全文とサイト別アイコンURLが具体的に明記されているのに、AIはJSON属性キー名を別の単語に創作し、img srcを空文字で出力した。これは「指示を見落とした」のではなく「プロンプトより自己の学習データを優先した」結果だ。

対策は「禁止パターン例をプロンプトに明記する」こと。「×こう書くのは間違い／◯こう書くのが正解」という具体例を並べるとAIの独自解釈を抑制できる。ただし例を増やすほどプロンプトが肥大化するトレードオフがある。この矛盾こそが、「AIに任せる範囲を狭める」改善へつながる。

壊さないための設計原則

運用の中で身につく、プロンプトを壊さない設計原則をまとめた。当たり前に見えることばかりだが、実際には実行できていない部分が多い。

この「検証可能な指示だけが効く」原則を、完了条件として毎回強制する仕組みが/goalだ。評価器に証拠を出させる完了条件の書き方に、実際に効いた条件の4要素をまとめている。

セルフチェックの現実的な運用

現状の65項目のセルフチェックは、AIに全項目チェックさせる前提で設計されている。だがこの前提自体が限界に近い。

AIに65項目を全部チェックさせることの限界

今回の事象がそれを示している。AIは「成果物数は3つ」というプロンプト冒頭の前提すら守れず、Cocoonブロックテンプレートも9箇所全て逸脱させた。この状態で65項目のセルフチェックが機能していると考えるのは無理がある。

実際にはAIが「セルフチェック済み」と主張しながら、一部項目しか確認していない可能性が高い。そうなると、65項目の存在意義そのものが成り立たない。

加算ではなく減算を前提にする発想の転換

チェック項目を減らすことを運用の中心に据え直す必要がある。これまでは「問題発生→対策ルール追加」という加算型で動いており、削除の機会がなかった。加算を続ければいずれプロンプトは破綻する。

逆の発想を導入する。新しいルールを追加するときは、不要になったルールを同時に1つ削る。追加と削除をセットで回せば、ルール総量の肥大化を防げる。筆者自身も完全には実行できていないが、今回の事象を機に減算の仕組み化を進める必要がある。

今後のプロンプト運用ロードマップ

今回の事象を受けて、筆者がこれから試す運用改善は4つ。そのうち1つは、AIの構造崩れ問題を根本から解決する可能性がある。

コンテキストを肥大化させないという方向では、外部ナレッジベース側で知識を分離する構成も同じ思想で動いている。プロンプト側を軽くする発想と対になる設計として参考になる。

プロンプト本体とチェックリストを物理的に分離する

現状はarticle_prompt.md一本にプロンプト本体と65項目のチェックリストを同居させている。この肥大化が取りこぼしを招いている。

検討中の案は、本体プロンプト（出力仕様・執筆ルール）とチェックリスト（出力後の自己検証項目）を別ファイルに分離し、AIに2段階で読み込ませる構成だ。本体を短く保ちながら、チェックは別リソースとして明示的に実行させる。

チェック項目の定期棚卸しワークフロー

発生実績のないチェック項目を削除する。記事投稿時にAIがチェック結果を記録し、月次で「引っかかった項目」と「引っかからなかった項目」を集計する。データで削減判断できる状態にする。

小規模プロンプト×複数回呼び出しへの分割構想

1本の巨大プロンプトで全工程を指示するのではなく、フェーズごとに小規模プロンプトを連鎖させる方式も検討している。「構成案生成」「本文執筆」「内部リンク設計」「セルフチェック」を別プロンプトで実行し、前段の出力を次段に渡す。

欠点は情報伝達ロスと実装コスト。シンプルさを失う代わりに各フェーズでの指示追従性が上がる。Claude CodeでのCLAUDE.md＋BUGS.md運用の実例で似た分割構造を試しているので、その知見を横展開できる。

プロンプトを安定させることはキャッシュヒット率にも直結します。書き換えのたびにキャッシュが壊れる仕組みはPrompt Cacheでトークンを10倍安くする方法で詳しく整理しました。

Markdown＋ルールベース変換方式への移行

今回の構造崩れ問題への最も本質的な対策はAIに任せる範囲を狭めることだ。AIには標準Markdown＋カスタムコンテナ記法で書かせ、Python側のルールベース変換器でCocoon HTMLに変換する。

この方式のMarkdown記法はZennやQiitaが採用しているものと同じ考え方だ。吹き出しブロックは次のように書く。

:::balloon name=ムラサキ

この記事はその壊れたAI応答を目撃した直後に書き始めました。

:::

この3行をPython側の変換器が受け取り、サイト別の正規Cocoonテンプレートに機械的に展開する。アイコンURL・iconid・divクラス・JSON属性キーなど、AIが間違えやすい要素を変換器が自動で埋める。

実装の主要部分はPython製Markdownパーサー（markdown-it-py）の拡張機能で実現できる。工数見積は約3日（22時間程度）。現在使用中の9種のCocoon独自ブロックはすべてこの方式でカバー可能だ。wp:columnsやwp:groupのような利用頻度ゼロのブロックは当面対応せず、必要になったときに追加する。

ムラサキ

この記事自体は現行ルール（Cocoon HTMLベタ書き）で出力しています。Markdown＋ルールベース変換方式は次のステップで実装予定です。

よくある質問

まとめ

プロンプトが888行を超えたら、モデルのバージョンアップを待つより設計を見直すべき。長大なプロンプトは破綻する。

今回の問題は、プロンプト運用の限界を示している。AIに複雑な構造ルールを守らせるより、Markdown＋ルールベース変換をPython側で機械的に処理する方が確実だ。次の記事では実装結果を公開する。