この記事の実施記録（2026-05-25）: Claude Code の /goal コマンドに「品質チェックで90点以上になるまで修正を続けよ」という完了条件を与え、記事1本（約3,000字）を書かせた。1回目は83点で足切りあり、2回目の品質チェック中に AI 編集長役が誤判定を自力でファクトチェックして判断を覆し、最終93.2点で合格。この記事自体も同じゴール条件下で書かれている。
今日のセッションを始める前に、私はこんな /goal を設定した。
/goal 今日の1アクションを参考に記事を執筆し、3軸ゲートレビューで90点以上になるまで、レビューと修正を実施して
ふだんは「執筆」「レビュー依頼」「修正」を自分でオーケストレーションしている。今日はそこを /goal に丸投げして、どこまで自走するか見てみようと思った。
結論から書くと、AIは自走した。しかし「完全な無人運転」ではなかった。途中でCOOが独自に判断を動かす場面が1回あった。そこが今回の体験で一番面白かった部分だ。
Claude Code × /goal で何が起きたか——1セッションの全記録
セッションの流れを時系列で整理する。
1. goalsを設定 → writerエージェントへ委任
/goal を設定した瞬間、COO（オーケストレーター）が writer エージェントへ執筆を委任した。テーマは「今日の1アクション」、つまりこのセッション当日に選ばれた次のアクション記事だ。
writer は claude-code-goal-command-guide.md を書き上げ、コミットまで完了した。文字数は約3,000字。
2. 3エージェント並行レビュー
執筆完了を受けて、COO は reviewer・reader・researcher の3エージェントを並行起動した。
私が個人的にこう呼んでいる「3軸レビュー」（公式用語ではない）は、それぞれ以下の役割を担う。
- reviewer: 事実確認・論理整合・技術的正確性
- reader: 想定読者ペルソナの感情・離脱・購買意欲
- researcher: SEO・AEO（AI参照最適化）・流入設計
この3軸での採点を /goal の termination condition として設定したため、合計90点以上かつ足切りなしが達成されるまでループが続く仕組みになっている。
3. 1回目レビュー: 83点・足切りあり
1回目のレビュー結果は83点、かつ足切り条件に該当した。
主な指摘は以下の3点だった。
-
足切り（🔴）:
/goalコマンドとclaude agents（Agent View）の両方を「Research Preview」と記述したが、claude agentsのみが Research Preview であり/goalは安定機能。誤記。 - 主観断定（🟡）: 断定的な主観表現が複数箇所にあり、根拠の補足が必要。
- Reader指摘: SE視点に切り替わる節への転調が唐突（-1点）。
- SEO推奨: タイトルに「Claude Code」が含まれていない。
足切りが発生しているのでループは当然継続する。
4. writer修正 → 再コミット
writer が指摘を受けて修正し、再コミットした。足切りの根本原因だった Research Preview の誤記を修正し、タイトルにも「Claude Code」を追加した。
5. 2回目レビュー——ここで想定外が起きた
2回目のレビューで、reviewer が新しい🔴を出した。
「v2.1.139のリリース年が2025年では？」
これが正しければ、記事内の「2026年5月リリース」という記述が誤りになる。足切り条件に相当する指摘だ。
ここで COO が動いた。
エージェントの指摘をそのまま修正委任に回す前に、自分でファクトチェックをしたのだ。
claude --version で実機確認したところ、バージョンは v2.1.150（2026-05-25現在）。デイリーリサーチで蓄積していた素材と照合した結果、「2026年5月リリース」が正確であり、reviewer の判定が誤っていると結論づけた。
修正は行わず、reviewer の指摘を誤判定として棄却した。
2回目の最終スコアは93.2点。合格ライン（90点以上・足切りなし）を超えたため、/goal のループが完了した。
想定外だったこと——「完全自動化」ではなかった理由
今回のフローで想定外だったのは、reviewer が「誤った🔴」を出した場面だ。
もし COO がその指摘をそのまま鵜呑みにしていたら、正確な記述を誤った記述に書き換えるという逆の結果になっていた。/goal のループは「レビュー点数が上がれば合格」という機械的な判断しかできない。指摘の内容が正しいかどうかは、別の評価軸が必要だ。
今回は COO が「一次ソースを自分で確認する」という判断をした。これが機能したのは、採点ループとは独立した「判断できる主体」がいたからだと考えている。
逆に言えば、/goal が有効に機能したのは「完了条件が機械判定可能だった」からだ。「90点以上かつ足切りなし」というゴールは、数値として確認できる。そのため、ループの継続/停止判定をAIに委ねることができた。
/goal を使ってわかった「人間の仕事として残るもの」
今回の体験から、私が「人間（あるいはオーケストレーター）の仕事として残る」と感じた部分を整理すると、こうなる。
条件の設計: 「3軸90点以上」という完了条件が適切だったから、ループが意味を持った。条件が曖昧だったり、機械判定できないものだったりすれば、ループは機能しない。採点スコアは数値なので、90点以上かどうかをAIが確認できる。これが機械判定できる理由だ。
判断の介入: reviewer の誤判定をそのまま通してしまえば、正確さが損なわれた。「ここで一次ソースを確認すべきか」という判断は、ルールとして書けない類のものだ。
この2点は、今のところAIには委ねられていない。
この記事自体が /goal で書かれている
最後に少し奇妙な事実を添えておく。
この記事も、同じ /goal 条件下で書かれている。「今日の1アクションを参考に記事を執筆し、3軸ゲートレビューで90点以上になるまで」——その最初の記事（claude-code-goal-command-guide.md）の執筆体験が、そのまま今回の記事のテーマになった。
構造が入れ子になっている。体験を書くために体験している、という状態だ。
これが意図したものか偶然の産物かは、正直よくわからない。ただ、「/goal を使って記事を書いた体験が、また /goal を使って記事になった」という事実は、このコマンドが何かを変えつつある兆候のように見える。
まとめ: /goal は「放置の自動化」ではなく「判断設計の自動化」
/goal を使って1本書かせた感想は、「放置できるが、放置していい部分は限られている」だ。
完了条件が明確で、機械判定できるタスクであれば、ループは確かに機能する。今回の「3軸レビュー90点合格」はその好例だった。
一方で、判断の質——指摘が正しいか、修正の方向性が適切か——は、ループの外にいる誰かが担保する必要がある。その役割を放棄すると、高い点数のまま質の低い記事が完成する。
/goal は作業の自動化ではなく、判断の設計を強いるコマンドだ、と考えている。何を終了条件にするかを考える時間が、以前の「続けて」連打より確実に長くなった。それはたぶん、悪いことではない。
まず試すなら、数値で判定できるゴールを1つ設定することをおすすめする。
Claude Code をさらに深く学ぶための書籍
- Claude CodeによるAI駆動開発入門（平川 知秀 著）— 基本から実践まで網羅
- 実践Claude Code入門――現場で活用するためのAIコーディングの思考法（西見 公宏・吉田 真吾・大嶋 勇樹 著）— 現場での思考法にフォーカス
関連記事
- Claude Code の /goal コマンドで AI を自走させる——完了条件を1行書いて放置する新しい開発スタイル — /goalコマンドの仕組みと完了条件の書き方
- 自己改善するマルチエージェント組織の作り方 — エージェントが自律的に動き続ける設計の全体像
- Claude Code 週次アップデートまとめ（2026/05/23週） — /goalを含む最新機能解説
本記事で言及した Claude Code v2.1.139 は 2026年5月リリース。/goal コマンドは安定機能、Agent View（claude agents）は研究プレビュー（Research Preview）段階（2026-05-25時点）。
関連記事
- Claude Code の /goal コマンドで AI を自走させる——完了条件を1行書いて放置する新しい開発スタイル - コードを書かないSE日誌
- Claude Code /goalコマンドで試す自律エージェント入門——ゴールを書くだけで複数ターン自動実行 - コードを書かないSE日誌
- Claude Codeで作業を記録していたら、そのまま記事になった——メタフィードバックループの実録 - コードを書かないSE日誌
この記事は はてなブログ からのクロスポストです。