この記事の要点（2026-05-22 実施）: /goal コマンド（研究プレビュー）を記事制作の品質ゲートに当てはめ、どのスコープで使えてどこが使えないかを分析した。品質ゲートフローには「ユーザー事実確認」「ユーザー中間通読」「ユーザー取捨選択」という必須の人間介入ポイントが3つある。フロー全体への /goal 適用は構造的に難しいが、「最終レビュー→指摘ゼロまでの修正ループ」に限定すれば有効に機能する。
「/goal に完了条件を書いたら、あとは Claude が自律継続する」——その仕組みを聞いて、記事制作の品質ゲート全体に適用できないかと考えた。2026-05-22 のセッションで分析した結果、使えるスコープと使えないスコープが明確に分かれることがわかった。
本記事では、その分析過程と実装パターンを整理する。なお /goal は現時点で 研究プレビュー（Research Preview） だ。仕様変更・不安定な挙動が起きうる前提で読んでほしい。
/goal とは何か
/goal は Claude Code v2.1.139（2026年5月リリース）で追加されたコマンドだ。自然言語で完了条件を書くと、Claude がその条件を満たすまで複数ターンにわたって自律的に作業を継続する。
基本的な使い方はこうだ。
/goal テストが全件グリーンになること
/goal READMEにインストール手順が追記され、動作確認済みであること
Claude は各ターンの終わりに「条件を満たしたか」を自己評価し、満たしていなければ次のターンへ進む。この判定をデフォルトで担うのは Haiku（軽量モデル）で、「会話に現れたテキスト」を見て条件達成の有無を判断する（設定で変更可能）。
/loop との違いを一言で: /loop は設定した時間間隔で繰り返す定期実行型、/goal は条件達成で終了する完了駆動実行型だ。「一定間隔で回す」が /loop、「指摘ゼロになるまで繰り返す」が /goal のユースケースに対応する。
品質ゲートに /goal を当てはめてみる
品質ゲートフローの全体像
私が運用している記事制作の品質ゲートは、おおむね以下のフローで動く。
ユーザー指示 ↓ 企画（構成・疑いリスト設計） ↓ 【ユーザー事実確認】← 人間介入ポイント① ↓ 執筆（章ごとに reviewer + reader レビューサイクル） ↓ 【ユーザー中間通読】← 人間介入ポイント② ↓ 全章レビュー → 批判的レビュー ↓ 【ユーザー取捨選択 → 最終修正】← 人間介入ポイント③ ↓ 最終レビュー（指摘ゼロまで繰り返し） ↓ 3軸スコアリング → 公開
このフローに /goal をそのまま当てはめると問題が発生する。なお「reviewer / reader / researcher」は私の運用上の呼称で、あなたの環境ではそれぞれ「コードレビュアー役エージェント」「読者視点チェックエージェント」「リサーチエージェント」に相当する。
フロー全体への適用が難しい理由
品質ゲートには3つの 必須人間介入ポイント がある。
- ユーザー事実確認: 「この記事の前提認識は正しいか」をユーザーが判断する工程。AIの解釈違いで記事の方向性が丸ごとずれるリスクをここで止める
- ユーザー中間通読: 執筆が半分進んだ時点で、用語・トーン・方針レベルの問題を発見する。後半の章に最初からフィードバックを反映するための工程
- ユーザー取捨選択: reviewer/reader の指摘は相反することもある。「どちらの指摘を採用するか」はユーザーが判断する必要がある
/goal のループはこれらの介入ポイントを「そのまま通過」してしまう可能性がある。「品質ゲートを全部通過していること」という条件を書いても、Haiku の判定は「会話に現れたテキスト」のみが頼りだ。ユーザーが実際に読んで承認したかどうかを、外部から検証する手段を持たない。
さらに、品質ゲートの最終段階には「3軸スコアリング」がある。reviewer / reader / researcher の3エージェントが並列に採点し、COOが集計して90点以上かどうかを判定する構造だ。外部エージェント3体の採点結果をまとめて評価する仕組みと、Haiku の「会話テキスト判定」は噛み合わない。
使えるスコープ: 最終レビューの修正ループ
フロー全体は難しいが、1つのフェーズには有効に使える。
「最終レビュー → 指摘ゼロまでの修正ループ」 だ。
これはフローの中でユーザーが取捨選択を完了した後の工程で、条件がシンプルだ。「reviewer の指摘ゼロ、かつ reader の指摘ゼロ」という状態を目指して、writer が修正 → 再レビュー → 修正を繰り返す。
この工程は:
- 達成条件が明確（指摘ゼロ）
- ユーザーの判断を挟む必要がない（判断は取捨選択フェーズで完了済み）
- 繰り返しの回数が事前にわからない（だから /goal が適している）
実装パターン: reviewer/reader をループに組み込む
完了条件の書き方
/goal の完了条件は、Haiku が会話テキストから読み取れる形で書く必要がある。曖昧な条件では判定がブレる。
実際に使える完了条件の例を示す。
/goal 以下の両方が会話に明示された状態になること: - reviewer が「指摘なし」または「修正不要」と回答した - reader が「指摘なし」または「離脱リスクなし」と回答した 最大 5 ターンで打ち切ること
ポイントは2つだ。
「会話に明示された状態」と書く: Haiku は会話のテキストを評価する。reviewer/reader が出力した結果テキストが会話に流れていれば、Haiku がそれを読んで判定できる。「ファイルに保存された」状態は読めない。
最大ターン数を設定する: 収束しないケースでの無限ループを防ぐために必須だ。後述する目安を参照してほしい。
サブエージェントの結果を会話に出力するパターン
ここでは reviewer/reader を例に書くが、構造は汎用だ。チームのコードレビュアー役エージェント・テスト実行エージェント・ドキュメントチェックエージェントなど、「何かを評価してOK/NGを返すエージェント」であれば同じパターンが使える。
reviewer/reader はサブエージェントとして呼び出すが、その結果を会話に出力させることが /goal との連携の核心だ。サブエージェントの出力がファイルにだけ書かれて会話に流れてこないと、Haiku が読めない。
writer に以下を依頼する: 1. 最新の原稿 (content/writing/articles/<slug>.md) を reviewer に渡し、 ファクトチェック結果を会話に出力させる 2. 同じ原稿を reader に渡し、 感情レビュー結果を会話に出力させる 3. 両エージェントから指摘がなければ作業完了と宣言する 4. 指摘があれば修正して最初から繰り返す
「会話に出力させる」という一言を委任プロンプトに含めるだけで、Haiku が読める形で結果が流れる。
「Haiku が会話テキストを見るだけで本当に正確に判定できるの？」という疑問は正直なところで、完璧ではない。「指摘なし」という文字列が会話に現れても、それが本当に指摘ゼロなのか、あるいは「特に大きな指摘なし（細かい点は……）」なのかを Haiku が取り違えるケースはある。完了条件を「指摘なし」より具体的に書くほど誤判定は減るが、ゼロにはならない。これが現時点の限界だ。
最大ターン数の目安
最大ターン数は以下の目安で設定する。
| ループの内容 | 目安ターン数 | 理由 |
|---|---|---|
| reviewer + reader の並列レビュー1回 | 約2ターン | 各エージェント呼び出しで1ターン |
| 修正作業 | 約1〜2ターン | 変更量による |
| 余裕分 | 1ターン | エラー・再確認 |
1サイクル（レビュー→修正→再レビュー）で約5〜6ターンかかる。最大2サイクルを想定するなら stop after 12 turns が現実的な上限だ。多すぎると費用が増え、少なすぎると途中で打ち切られる。
注意点・現時点の限界
3軸スコアリングには使えない
reviewer/reader/researcher の並列採点 → COO集計という構造は、/goal の「会話テキスト判定」と根本的に噛み合わない。3エージェントの採点結果を集計して90点以上かどうかを判定するには、数値集計のロジックが必要で、Haiku のテキスト判定では処理できない。3軸スコアリングは引き続き COO が手動で集計する工程として残す。
研究プレビューの不安定さ
/goal は現時点（2026-05-22）で研究プレビューだ。v2.1.139 導入直後に、disableAllHooks または allowManagedHooksOnly が設定されている環境でハングする問題が発生し v2.1.140 で修正された経緯がある（出典: github.com/anthropics/claude-code/blob/main/CHANGELOG.md）。条件達成の判定精度・途中停止の頻度・長時間セッションでのコンテキスト管理、いずれも安定版とは言えない状態だ。
実用にあたっては「止まっていたら手動で再開する」ハーフオート運用が現実的だ。「設定したら完全放置でいい」というレベルには至っていない。
ユーザー介入ポイントは飛ばせない
繰り返しになるが、品質ゲートフローの3つの介入ポイント（事実確認・中間通読・取捨選択）は /goal のループで代替できない。「/goal を設定すれば品質ゲート全体を自動化できる」という解釈は間違いだ。現時点では「取捨選択が完了した後の修正ループ」にだけ適用できると理解しておくことが重要だ。
まとめ: 今使えるユースケース vs まだ早いユースケース
分析の結果を1枚の表にまとめる。
| ユースケース | /goal 適用 | 理由 |
|---|---|---|
| 最終レビュー → 指摘ゼロまでの修正ループ | 今使える | 達成条件が明確・ユーザー判断不要 |
| テスト全件グリーンになるまでのデバッグ | 今使える | 達成条件が機械的に判定可能 |
| コードレビューの指摘対応ループ | 今使える | 「レビュアー承認」を会話に明示させれば機能する |
| 品質ゲートフロー全体の自動化 | まだ早い | 必須の人間介入ポイント3つを飛ばすリスク |
| 3軸スコアリング（並列採点→集計） | まだ早い | 数値集計と会話テキスト判定が噛み合わない |
| ユーザー承認を要する意思決定のループ | まだ早い | ユーザーの判断を Haiku では代替できない |
「/goal が使えるのは、達成条件が会話テキストで明確に判定できて、かつ人間の判断を挟まなくていいスコープだけ」——これが今回の分析で得た結論だ。
逆に言うと、そのスコープに絞れば 今すぐ使える。reviewer/reader のレビューを受けて修正を繰り返す工程は、まさにその条件に合致する。設定コストは完了条件を1〜2文書くだけで、繰り返し回数が読めないループ作業の自動化として十分に機能する。
研究プレビューの不安定さを受け入れつつ、使えるスコープを見極めて使い始めるのが現時点での現実的な選択だ。
この記事でカバーしきれなかった設計・運用の全体像は、Zenn Books にまとめている。序章・第1部は無料で読める。
- コードを書けない私がClaude Codeで「AIチーム」を作るまで（¥900 / 序章・第1部無料）
- コードを書けない私がClaude Codeで「AIチーム」を回すまで（¥900 / 序章無料）
Claude Code の仕組みをもっと体系的に学びたい場合は、以下の書籍も参考になる。
- Claude CodeによるAI駆動開発入門（Kindle版）（平川知秀著）— Claude Code の基本から実践的な開発フローまでカバーした入門書。
- 実践Claude Code入門 エンジニア選書（Kindle版）（西見公宏・吉田真吾・大嶋勇樹著）— 現場で活用するための思考法と実践パターンを扱った一冊。
関連記事
- AIにAIの書いた文章を批評させたら60点だった話——reviewer/reader エージェントを品質管理に使う方法
- Claude Code のスケジュール枠は3つだけ——/loop・Remote Trigger・スケジューラの使い分け
- Claude Code の trigger リストを11日間育てた記録——8件の事故とAIガバナンスの実証
参考リンク
- Claude Code 公式 changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
