/goal コマンドをどのように構築し、それがどのように役立っているか

私のAIコーディングセッションの多くは、以前はいつも同じように終わっていました。長引くチャット、中途半端な作業、そして何が完了して何が未完了かを思い出そうとする自分。そこで、 /goalというコマンドを作成しました。1つの大きなゴールを与えるだけで、ゴールが完了して検証されるまで、あるいは真のブロッカーに遭遇するまで作業を続けます。

今日は2026年11月9日です。AIアシスタントが大量のコードを素早く書けるようになった今、これは重要です。そして難しい部分は、コードを書くことからそれを信頼することへと移りました。 /goal は、その問題に対する私の答えです。

/goal の実体とは何か

それはプログラムではありません。私が /goal に続けてゴールを入力したときに、アシスタントが従う一連の書かれた指示です。チェックリストがリリースの手順を説明するのと同じように、これらの指示はプロセスを説明しています。

ゴールは1文でも構いません。私の最新の指示は次の通りでした：「ブラウザ拡張機能の v1.1 計画をフェーズごとに完全に実装し、フェーズごとに1回コミットし、私の許可なしにプッシュやデプロイを行わないこと。」その1文が、約25回のコミットに及ぶ全10フェーズの作業をカバーしました。

1行で表すコンセプト

異なる役割には異なるモデルを割り当て、誰も自分の宿題を自分で採点しない。

• 計画 最も強力なプランニングモデルが担当します。プロジェクトを読み込み、保留中のタスクに優先順位を付け、ゴールをフェーズに分割して、トラッカーファイルを作成します。
• 構築 高速で安価なコーディングモデルが担当します。各フェーズはトラッカーから開始する新しいエージェントが担当するため、あるフェーズがそれ以前のフェーズの使い古されたメモリに依存することはありません。
• クリティカルなコード 最も慎重なコーディングモデルが担当します。ユーザーデータの削除、ファイルの上書き、リリーススクリプトなどに関連するタスクは、クリティカルとしてマークします。
• レビュー 独立した読み取り専用のレビュー担当者が担当します。その担当者はコードを書いたことがありません。差分（diff）を読んで問題を報告し、何も編集することはできません。

実行の流れ（ステップ・バイ・ステップ）

ステップ1：プランニングフェーズ

コードを書く前に、プランナーはプロジェクトを確認します：未解決のメモ、未完了の作業、git の状態、ビルドやテストに使用されるコマンドなどです。その後、ゴール、チェックリスト、そして各項目に対してパスしなければならないコマンドなどの実証可能な1行のチェックを含むトラッカーファイルを作成します。各項目にはモデルタグも付与されます。トラッカーは信頼できる唯一の情報源（Single Source of Truth）です。会話が長くなりすぎてアシスタントが忘れてしまっても、トラッカーは依然として把握しています。

また、決定事項も記録します。計画の中に私がまだ回答していない未解決の疑問があった場合、トラッカーはそれぞれについて選択したデフォルト値をリストアップするため、後から無効化して上書きすることができます。

ステップ2：フェーズごとに新しいエージェントを1つ割り当て

各フェーズは新しいエージェントによって構築されます。エージェントはコードを書き、ビルドとテストを実行し、失敗を修正して、わかりやすいメッセージで1回コミットします。トラッカー内の自分の項目にチェックを入れます。その後停止し、次のフェーズは白紙の状態から開始されます。

ステップ3：レビューゲート

フェーズがコミットされると、独立したレビュー担当者がトラッカーのチェック項目に照らし合わせて差分を読み取ります。以下の4点を順番に確認します：コードが本当に受け入れチェックを満たしているか、安全であるか、特殊なエッジケースを処理しているか、ドキュメントがコードの動作と一致しているか。そして、ファイル名、行番号、1文の障害シナリオを含む、順位付けされた問題のリストを返します。

ステップ4：修正と再レビュー

確認された問題は、修正タスクとして新しいエージェントに渡されます。修正後、レビュー担当者が再度確認します。未解決の確認済み問題が残っているフェーズを完了としてマークすることはできず、ゴール全体を完了と見なすこともできません。

ステップ5：実直なレポート

最後に、すべての基準が満たされ、すべてのチェックが合格（グリーン）である場合にのみ COMPLETE と表示されるレポートが届きます。そうでない場合は PARTIAL と表示され、何が不足しているかが正確にリストされます。このレポートが決して過大評価することはありません。

実際のプロジェクトで検出された問題

対象のプロジェクトは、ブラウザタブの音声を録音する個人用のブラウザ拡張機能でした。新しいバージョンでは、録音データをブラウザのプライベートファイルシステムに保存し、名前を指定してフォルダに保存できるようにし、動画ファイルを修復し、ライブラリページを追加しました。

レビュー担当者は、テストでは見つからなかった実際の実装バグを発見しました：

• フォルダ保存機能は、毎回暗黙的に古い「名前を付けて保存」ダイアログにフォールバックしていました。保存処理が実行されるバックグラウンドページは拡張機能の設定を読み取ることができないため、コードは何も言わずにデフォルトを選択していたのです。テストがパスしたのは、擬似的な設定ストアを使用していたためでした。
• 修復ステップによって独自のチェックをパスする短縮されたファイルが生成され、それが元のファイルを置き換えてしまう可能性がありました。
• 修復されたファイルには新しい更新日時が付与されるため、復元された録音のファイル名に含まれる長さが誤ったものになっていました。
• 書き込みが失敗した場合、録音の残りの部分が警告なしに破棄される可能性がありました。

これらはいずれも特殊なバグではありません。どれも数週間後に、録音が見つからない、途中で切れている、あるいは名前が間違っているといった形で顕在化していたはずのものです。

そこに組み込んだルール

• 質問するために立ち止まらないこと。決断し、その決定事項をトラッカーに記録し、続行すること。
• 例外となるのは、対外的なアクションや破壊的なアクションです：プッシュ、デプロイ、メッセージの送信、データの削除、あるいは私のパスワードが必要なあらゆる操作です。これらは、私が実行すべき正確なコマンドとともにブロック項目となります。
• 失敗しているチェックをパスさせるために無効化してはならない。また、失敗しているテストを削除してはならない。
• 無関係なクリーンアップは行わないこと。目標に資するコードのみを記述すること。
• 私がフラグを渡すか指示を出さない限り、決してプッシュやリリースを行わないこと。

まとめ

/goal が私にとってうまく機能しているのは、曖昧な願望を追跡可能で検証可能なステップのリストに変えてくれるからであり、ある部分を構築した人がそれを承認する人になることが決してないからです。これはアシスタントをより賢くするわけではありません。結果の信頼性を高め、自分自身の注意を払う必要性を減らしてくれるのです。

メリット

• 1文の入力で、大規模で複数フェーズに及ぶ作業を推進できる。
• トラッカーは長いセッションやコンテキストの喪失にも耐えうる。
• 独立したレビューにより、作成者自身のテストが見逃したバグを発見できる。
• 各フェーズが1つの小さなコミットになるため、履歴が読みやすく、元に戻すのも容易である。
• 最終レポートは、何が検証され、何が検証されなかったのかについて実直である。
• プッシュやデプロイなどのリスクの高いアクションは、自分の管理下に留まる。

デメリット

• 処理が遅い。すべてのフェーズにビルド、レビュー、修正のループが存在するため、このプロジェクトには何時間もかかりました。
• 複数のエージェントが同じコードを読むため、大量のトークンを消費する。
• レビュー担当者は無数の細かいエッジケースを見つけ出す可能性があるため、レビューラウンド数に上限を設ける必要がある。
• 擬似環境で実行されるテストでは、実機での動作を証明できない。一部のチェックには依然として人間の確認が必要である。
• 不十分なゴール設定からは不十分な計画しか生まれない。このコマンドは、不明瞭なゴールを修正することはできない。

注意事項

この記事は教育目的であり、私自身のセットアップを説明するものです。名前、パス、プロジェクトの詳細は一般化されており、自身のコマンド内のプレースホルダー値は各自のものに置き換える必要があります。モデル名やツールの動作は頻繁に変更されるため、重要な作業で依存する前に、すべての主張を検証し、リスクの低い小規模なプロジェクトでプロセスをテストしてください。

よくある質問（FAQ）

• /goal コマンドとは何ですか？ — AIコーディングアシスタントに1つの大きなゴールを計画、構築、レビュー、検証させ、その結果を実直に報告させるための一連の保存された指示です。
• プログラムやプラグインですか？ — いいえ。アシスタントが従うコマンドファイルに書かれたプロセスであるため、通常のテキストドキュメントと同じように編集できます。
• なぜ役割ごとに異なるモデルを使用するのですか？ — 計画、日常的なコーディング、慎重なレビューにはそれぞれ異なる強みが必要であり、それぞれに適したモデルを使用することでコストを削減し、品質を向上させることができます。
• なぜフェーズごとに新しいエージェントを使うのですか？ — 新しいエージェントは、長くて部分的に忘れ去られた会話からではなく、トラッカーから作業を開始するため、方針のブレや古い前提知識への依存を防ぐことができます。
• なぜレビュー担当者は作成者と分ける必要があるのですか？ — 作成者は自分の作業を過信しがちであるため、コードを書いていない第三者の読み手の方が、作成者が見落とした問題を発見しやすくなります。
• 単独でコードをプッシュしたりデプロイしたりしますか？ — いいえ。プッシュ、リリース、デプロイには私の明示的な承認が必要であり、このコマンドはそれらを代わりにブロックされたステップとして一覧表示します。
• 何かを完了できない場合、どのように処理しますか？ — その項目をブロック済みとしてマークし、正確なエラー内容とブロックを解除するための条件を記録した上で、独立した他の作業に進みます。
• 余分な時間をかける価値はありますか？ — 大規模な変更やリスクの高い変更であれば、レビューラウンドによってバグを早期に発見できるため、その価値があります。小規模な修正であれば、通常のチャットの方が高速です。

タグ

#ClaudeCode #AICoding #DeveloperWorkflow #CodeReview #Automation #SoftwareEngineering #AIAgents #Productivity #DevTools #BuildInPublic