はじめに
Claude Code では、/goal コマンドを使えます。
/goal は、ざっくり言うと、Claude に「どこまで到達したら作業完了か」を伝えるためのコマンドです。
通常のプロンプトでは、ユーザーが毎回、次のように指示する必要があります。
次はこのファイルを見て
次はこのエラーを直して
次はテストを実行して
次はビルドエラーを確認して
次は不要なコードを削除して
一方で /goal を使うと、最初に「完了条件」を設定できます。
例えば、以下のような形です。
/goal "商品詳細ページの価格表示ロジックを整理し、既存テストとビルドが通る状態にする"
この場合、Claude は単に1回だけコードを修正するのではなく、指定された完了条件に向かって作業を続けます。
本記事では、Claude Code の /goal コマンドについて、電子書籍ストアWeb開発を例にして整理します。
公式ドキュメント
まず、公式ドキュメントはこちらです。
- Claude をゴールに向かって動作させ続ける - Claude Code Docs
- コマンド - Claude Code Docs
- Claude Code の概要 - Claude Code Docs
公式ドキュメントでは、/goal はコンプリーション条件を設定する機能として説明されています。
/goal を使うと、Claude は各ステップごとにユーザーの追加指示を待つのではなく、設定された条件が満たされるまでターンをまたいで作業を続けます。
つまり、/goal は単なる TODO メモではありません。
重要なのは、「何をしてほしいか」だけではなく、「どこまで到達したら完了か」を Claude に渡す点です。
/goal の基本構文
基本的な使い方はシンプルです。
/goal <完了条件>
例です。
/goal "検索結果ページの表示崩れを修正し、既存のE2Eテストとビルドが通る状態にする"
現在のゴールを確認する場合は、引数なしで実行します。
/goal
アクティブなゴールを削除する場合は、以下のように実行します。
/goal clear
公式ドキュメントでは、clear 以外にも、stop、off、reset、none、cancel がアクティブなゴール削除のエイリアスとして説明されています。
/goal で何が変わるのか
通常の Claude Code 利用では、ユーザーが作業単位ごとに指示を出します。
例えば、電子書籍ストアWebの検索画面を改善する場合、以下のような流れになりがちです。
検索結果ページの実装を見て
検索条件の状態管理を確認して
APIレスポンスの型を確認して
表示崩れを直して
テストを修正して
ビルドして
エラーが出たら直して
この方法でも作業はできます。
ただし、複数ファイルにまたがる作業では、指示が細かくなりやすく、人間側が進行管理をする必要があります。
/goal を使うと、最初に終了条件を渡せます。
/goal "検索結果ページのフィルタ条件管理を整理し、URLクエリと画面状態が同期され、既存テストとビルドが通る状態にする"
このように指定すると、Claude は単に「コードを修正する」だけでなく、「URLクエリと画面状態が同期され、テストとビルドが通る状態」までを目指して作業します。
ここが大きな違いです。
/goal は「作業内容」ではなく「完了条件」を渡すコマンド
/goal を使うときに重要なのは、作業内容だけを書かないことです。
悪い例です。
/goal "検索画面をいい感じに改善する"
この指定では、何をもって完了とするのか判断できません。
「いい感じ」は人間にとっても曖昧ですし、AIにとっても曖昧です。
良い例です。
/goal "検索結果ページの並び替え条件をURLクエリと同期し、リロード後も同じ検索条件が復元され、既存テストとビルドが通る状態にする"
こちらは完了条件が明確です。
少なくとも、以下が読み取れます。
対象は検索結果ページ
作業内容は並び替え条件とURLクエリの同期
期待する挙動はリロード後も同じ検索条件が復元されること
完了条件は既存テストとビルドが通る状態
/goal は、AIに「何となく改善して」と頼むためのコマンドではありません。
「この状態になったら完了」と判断できる条件を渡すためのコマンドです。
なぜ電子書籍ストアWeb開発と相性が良いのか
電子書籍ストアWebは、一般的なコーポレートサイトよりも状態管理と導線設計が複雑になりがちです。
例えば、以下のような要素があります。
検索
ジャンル一覧
商品詳細
無料作品
セール
クーポン
カート
会員ログイン
購入導線
決済
閲覧導線
レコメンド
ランキング
SEO
構造化データ
表示速度
A/Bテスト
Feature Flag
アクセス解析イベント
特にストアWebでは、単純にページが表示されればよいわけではありません。
検索できること、商品詳細が分かりやすいこと、購入導線が壊れていないこと、SEOに必要な情報が出ていること、表示速度が悪化していないことが重要です。
そのため、開発作業も1回の指示では終わりにくいです。
例えば、商品詳細ページを改善する場合、以下のような作業が発生します。
APIレスポンスを確認する
価格表示ロジックを確認する
セール価格と通常価格の出し分けを見る
クーポン表示条件を確認する
ログイン状態ごとの表示差分を見る
構造化データを確認する
テストを修正する
ビルドする
表示崩れがないか確認する
このような作業は、Claude Code に対して単発で「直して」と依頼するよりも、/goal で完了条件を渡した方が扱いやすくなります。
電子書籍ストアWebでの /goal 利用例
ここからは、電子書籍ストアWeb開発で使えそうな /goal の例を挙げます。
特定企業や特定サービスに依存しない、一般的な電子書籍ストアWeb開発の例として読んでください。
例1：検索結果ページの状態管理改善
/goal "検索結果ページの検索条件、並び替え、ページ番号をURLクエリと同期し、リロード後も同じ状態が復元され、既存テストとビルドが通る状態にする"
電子書籍ストアWebでは、検索結果ページの状態管理が複雑になりがちです。
例えば、以下のような条件があります。
キーワード
ジャンル
著者名
出版社
価格帯
無料作品
セール対象
完結済み
並び替え
ページ番号
表示件数
これらの状態がURLクエリと同期されていないと、ユーザーがページをリロードしたときに条件が消えます。
また、検索結果を共有したときに、相手側で同じ条件が再現されません。
検索画面の改善では、単にUIを直すだけでは不十分です。
URL、状態管理、APIリクエスト、ページング、テストまで確認する必要があります。
そのため、/goal では以下のように完了条件を明確にします。
/goal "検索結果ページのフィルタ条件をURLクエリから復元できるようにし、条件変更時にURLが更新され、既存テストとビルドが通る状態にする"
例2：日本語検索と英語検索のパフォーマンス差の調査
/goal "作品検索で日本語クエリと英語クエリの検索レスポンス差を調査し、正規化、検索条件生成、API呼び出し、検索結果描画のどこで差が出ているかを整理して、改善方針を提示する"
電子書籍ストアWebでは、作品検索が中核機能になります。
作品名、著者名、出版社名、シリーズ名、ジャンルなど、検索対象が多く、さらに日本語と英語では検索処理の性質が変わります。
例えば、英語検索では空白区切りの単語を前提にしやすい一方、日本語検索では単語の境界が明確ではありません。
そのため、検索実装によっては、日本語クエリと英語クエリで検索レスポンスに差が出ることがあります。
このような問題では、単に「検索を速くする」と書くと範囲が広すぎます。
悪い例です。
/goal "作品検索を速くする"
これでは、何を調査し、どこまで改善すれば完了なのかが曖昧です。
良い例です。
/goal "作品検索で日本語クエリと英語クエリの検索レスポンス時間を比較し、検索条件生成、APIレスポンス、フロント側描画のどこがボトルネックかを特定して、改善方針を整理する"
さらに、実装まで進める場合は以下のように書けます。
/goal "作品検索で日本語クエリ時に遅くなる処理を調査し、不要な再検索、重複API呼び出し、検索結果描画の再レンダリングを削減して、既存テストとビルドが通る状態にする"
検索パフォーマンスを見る場合は、以下の観点を分けて確認すると進めやすくなります。
検索条件生成に時間がかかっているのか
APIレスポンス自体が遅いのか
検索結果件数が多すぎるのか
フロント側の描画が重いのか
入力中の再検索が多すぎるのか
日本語クエリだけ正規化処理が重いのか
検索結果のハイライト処理が重いのか
検索結果コンポーネントの再レンダリングが多すぎるのか
特にストアWebでは、検索欄に入力するたびに検索処理が走る実装になっている場合、debounce の設定や不要な再検索の抑制も重要になります。
/goal "作品検索の入力中検索処理を見直し、不要な連続API呼び出しを抑制して、日本語入力中でも検索結果画面の操作性が悪化しない状態にする"
日本語入力では、IME変換中の入力状態も考慮が必要です。
変換中の文字列に対して毎回検索を実行すると、不要なAPI呼び出しや再レンダリングが増える可能性があります。
そのため、IME変換中は検索を抑制し、確定後に検索するような制御も検討対象になります。
/goal "作品検索でIME変換中の不要な検索実行を抑制し、入力確定後に検索されるようにして、既存の検索挙動を維持したままビルドが通る状態にする"
このように、作品検索のパフォーマンス改善では、「検索を速くする」ではなく、どの言語のクエリで、どの処理が、どの条件で遅くなるのかを分解することが重要です。
/goal を使うことで、調査、原因特定、修正、ビルド、テストまでを一連の作業として進めやすくなります。
例3：商品詳細ページの価格表示整理
/goal "商品詳細ページの価格表示ロジックを整理し、通常価格、セール価格、無料、クーポン適用可能状態を正しく出し分け、既存テストとビルドが通る状態にする"
電子書籍ストアWebの商品詳細ページでは、価格表示が複雑になりがちです。
例えば、以下のような表示条件があります。
通常価格
セール価格
無料
期間限定無料
クーポン対象
ポイント還元
購入済み
予約商品
販売終了
ログイン前
ログイン後
このような条件がコンポーネント内に直接書かれていると、表示ロジックが読みにくくなります。
また、条件追加のたびにバグが入りやすくなります。
/goal を使う場合は、単に「価格表示を直す」ではなく、どの状態を正しく出し分けるのかを明確にします。
/goal "商品詳細ページの価格表示ロジックをPriceDisplayコンポーネントに分離し、通常価格、セール価格、無料、購入済みの表示パターンをテストで確認できる状態にする"
このように、対象、分離方針、表示パターン、テスト条件まで書くと実務向きです。
例4：購入導線のリファクタリング
/goal "商品詳細ページから購入完了までの購入導線を調査し、カート投入、ログイン誘導、購入確認への遷移条件を整理して、既存のE2Eテストが通る状態にする"
電子書籍ストアWebでは、購入導線が非常に重要です。
購入導線には、以下のような分岐が発生します。
未ログイン
ログイン済み
購入済み
未購入
カート投入済み
無料作品
予約商品
販売終了
決済エラー
年齢確認が必要な商品
このような導線は、単純な画面遷移ではありません。
状態によって、表示するボタン、遷移先、エラーメッセージ、確認画面が変わります。
そのため、/goal では「購入導線を改善する」ではなく、どの状態を整理するのかを明確にします。
/goal "商品詳細ページの購入ボタン表示条件を整理し、未ログイン、購入済み、未購入、無料作品、販売終了の各状態で期待するCTAが表示され、関連テストが通る状態にする"
購入導線は売上に直結するため、/goal の完了条件にE2Eテストを入れると安全です。
/goal "未ログイン状態の商品詳細ページからログイン後に購入確認画面へ戻る導線を修正し、該当E2Eテストが通る状態にする"
例5：表示速度改善
/goal "ストアトップページの初期表示処理を調査し、ファーストビューに不要なAPI通信と重いコンポーネント読み込みを遅延実行へ移動して、ビルドが通る状態にする"
電子書籍ストアWebでは、表示速度がユーザー体験に直結します。
特にストアトップ、検索結果、商品詳細ページは、ユーザーの離脱に影響しやすい領域です。
ストアWebでは、初期表示時に以下のような処理が走りがちです。
ランキング取得
レコメンド取得
バナー取得
セール情報取得
ログイン状態確認
クーポン情報取得
閲覧履歴取得
Feature Flag取得
A/Bテスト設定取得
アクセス解析SDK初期化
これらをすべて初期表示前に実行すると、ページ表示が遅くなります。
/goal を使う場合は、単に「速くする」ではなく、何を遅延実行に移すのかを明確にします。
悪い例です。
/goal "トップページを速くする"
良い例です。
/goal "ストアトップページの初期表示前に実行されているAPI通信を調査し、ファーストビュー表示に不要なランキング、レコメンド、バナー取得を遅延実行へ移動して、ビルドが通る状態にする"
さらに計測条件まで入れるなら、以下のようにします。
/goal "商品詳細ページの初期表示を調査し、画像とおすすめ作品エリアを遅延読み込みに変更して、LighthouseのPerformanceスコアが悪化しない状態にする"
表示速度改善は、調査、計測、修正、ビルド、再計測が必要になります。
そのため、/goal と相性が良い作業です。
例6：SEOと構造化データの改善
/goal "商品詳細ページのSEO関連実装を調査し、title、description、canonical、構造化データを整理して、既存テストとビルドが通る状態にする"
電子書籍ストアWebでは、SEOも重要です。
商品詳細ページ、著者ページ、ジャンルページ、ランキングページ、セールページなどは、検索流入の入口になりやすいからです。
例えば、商品詳細ページでは以下のような情報が必要になります。
作品名
著者名
出版社
巻数
価格
説明文
サムネイル
canonical
noindex制御
構造化データ
SEO改善では、見た目のUIだけでなく、headタグや構造化データも確認する必要があります。
/goal を使う場合は、対象ページと確認項目を明確にします。
/goal "商品詳細ページのmeta情報生成ロジックを整理し、作品名、著者名、巻数をtitleとdescriptionに反映し、canonicalが正しく出力される状態にする"
構造化データも含める場合は、以下のようにします。
/goal "商品詳細ページの構造化データ生成処理を整理し、作品名、著者名、出版社、価格がJSON-LDに出力され、既存テストとビルドが通る状態にする"
SEOは「いい感じにする」だと曖昧です。
/goal では、どのページの、どのタグや構造化データを、どういう状態にするかまで書くのが重要です。
例7：ログイン状態による表示分岐の整理
/goal "商品詳細ページのログイン状態による表示分岐を整理し、未ログイン、ログイン済み、購入済みの各状態で期待するCTAが表示され、関連テストが通る状態にする"
電子書籍ストアWebでは、ログイン状態によって表示が大きく変わります。
例えば、商品詳細ページでは以下のような分岐があります。
未ログインならログイン導線を表示
ログイン済み未購入なら購入ボタンを表示
購入済みなら読むボタンを表示
無料作品なら無料で読むボタンを表示
販売終了なら購入不可表示
予約商品なら予約ボタンを表示
このような条件が複数コンポーネントに散らばると、バグが入りやすくなります。
/goal を使う場合は、表示状態を明確に列挙すると進めやすくなります。
/goal "商品詳細ページのCTA表示条件をProductCTAコンポーネントに集約し、未ログイン、未購入、購入済み、無料作品、販売終了の表示パターンをテストで確認できる状態にする"
このように書くと、Claude は単に表示を修正するだけでなく、コンポーネント分離とテスト追加まで進めやすくなります。
例8：カート画面の状態管理改善
/goal "カート画面の状態管理を整理し、購入不可商品、販売終了商品、クーポン適用対象外商品を正しく表示して、既存テストとビルドが通る状態にする"
電子書籍ストアWebのカート画面では、複数の状態を扱います。
通常商品
無料商品
販売終了商品
購入済み商品
クーポン対象商品
クーポン対象外商品
価格変更商品
決済不可商品
カート画面では、表示だけでなく、購入可能かどうかの判定も重要です。
表示上は問題なく見えていても、購入確認画面でエラーになると、ユーザー体験が悪くなります。
/goal では、カート内商品の状態と完了条件を明確にします。
/goal "カート画面の商品状態判定を整理し、販売終了商品と購入済み商品は購入不可として表示し、購入確認へ進めないことをテストで確認できる状態にする"
例9：レコメンド枠の遅延読み込み
/goal "商品詳細ページのレコメンド枠を遅延読み込みに変更し、メインの商品情報表示をブロックせず、既存の表示崩れがない状態にする"
電子書籍ストアWebでは、レコメンド枠が多くなりがちです。
例えば、以下のような枠があります。
この作品を読んだ人におすすめ
同じ著者の作品
同じジャンルの人気作品
最近チェックした作品
セール中の関連作品
これらは回遊には有効ですが、初期表示を重くする原因にもなります。
特に商品詳細ページでは、まず作品名、著者、価格、購入ボタンなどの主要情報を素早く表示することが重要です。
そのため、レコメンド枠は初期表示後に遅延取得する設計が有効です。
/goal を使う場合は、以下のように書けます。
/goal "商品詳細ページのレコメンドAPI呼び出しを初期表示後の遅延実行に変更し、作品名、価格、CTAの表示をブロックしない状態にする"
表示速度改善と購入導線の安定性を両立したい場合に使いやすい /goal です。
例10：Feature Flag の整理
/goal "恒久的にONになっているFeature Flagを調査し、不要な分岐を削除して、既存テストとビルドが通る状態にする"
長期運用のストアWebでは、Feature Flag が残り続けることがあります。
例えば、以下のような状態です。
常にONのFeature Flag
常にOFFのFeature Flag
A/Bテスト終了後も残っている分岐
一部ページだけに残っている旧導線
削除タイミングを逃したキャンペーン分岐
このような分岐は、コードの見通しを悪くします。
ただし、Feature Flag の削除は慎重に行う必要があります。
削除してよいフラグなのか、まだ利用されているのか、管理画面やサーバー側設定と関係があるのかを確認する必要があるからです。
/goal では、対象フラグと完了条件を明確にします。
/goal "旧購入導線用のFeature Flagを調査し、参照箇所を削除して新購入導線に一本化し、関連テストとビルドが通る状態にする"
例11：アクセス解析イベントの整理
/goal "商品詳細ページのアクセス解析イベントを整理し、商品表示、購入ボタン押下、カート追加、読むボタン押下のイベントが重複送信されない状態にする"
ストアWebでは、アクセス解析イベントも重要です。
特に電子書籍ストアでは、以下のようなイベントを計測することがあります。
商品詳細表示
検索結果表示
商品クリック
購入ボタン押下
カート追加
ログイン誘導クリック
購入完了
無料作品閲覧
レコメンドクリック
ただし、イベント送信処理がコンポーネント内に散らばると、重複送信や送信漏れが起きやすくなります。
/goal を使う場合は、どのイベントを、どの条件で、どういう状態にするかを明確にします。
/goal "商品詳細ページの計測イベント送信処理を整理し、初回表示時の商品表示イベントが1回だけ送信されることをテストで確認できる状態にする"
このように、計測イベントは「送る」だけでなく、「重複しない」「条件どおり送る」まで完了条件に含めるとよいです。
例12：エラー表示の共通化
/goal "検索結果、商品詳細、カート画面のAPIエラー表示を共通コンポーネント化し、既存の表示文言と導線を維持したままビルドが通る状態にする"
ストアWebでは、APIエラー表示が複数画面に散らばりがちです。
例えば、以下のようなエラーがあります。
検索結果取得失敗
商品詳細取得失敗
カート取得失敗
購入処理失敗
ログイン状態取得失敗
クーポン取得失敗
レコメンド取得失敗
これらを各画面で個別に実装すると、文言や再試行導線がばらつきます。
/goal では、共通化する対象と、維持すべき既存挙動を明確にします。
/goal "APIエラー表示をErrorStateコンポーネントに共通化し、検索結果、商品詳細、カート画面で既存文言と再試行導線を維持して、関連テストが通る状態にする"
共通化は影響範囲が広くなりやすいため、/goal と相性が良いです。
例13：アクセシビリティ改善
/goal "商品詳細ページの主要CTAと価格表示のアクセシビリティ属性を整理し、スクリーンリーダーで作品名、価格、購入状態が理解できる状態にする"
電子書籍ストアWebでは、アクセシビリティも重要です。
特に商品詳細ページや購入導線では、ユーザーが以下を正しく理解できる必要があります。
作品名
著者名
価格
セール状態
購入済みかどうか
購入ボタン
無料で読むボタン
カート追加ボタン
エラーメッセージ
アクセシビリティ改善は、見た目の変更だけではありません。
ラベル、フォーカス順、キーボード操作、エラー通知なども確認する必要があります。
/goal を使う場合は、対象と確認条件を明確にします。
/goal "商品詳細ページのCTAボタンに適切なaria-labelを設定し、キーボード操作で購入ボタンまで到達でき、既存テストとビルドが通る状態にする"
良い /goal の書き方
実務では、以下の形で書くと使いやすいです。
/goal "<対象> を <作業内容> し、<検証可能な完了条件> まで進める"
例です。
/goal "検索結果ページのフィルタ状態をURLクエリと同期し、リロード後も条件が復元され、既存テストとビルドが通る状態にする"
/goal "作品検索で日本語クエリ時に遅くなる処理を調査し、不要な再検索、重複API呼び出し、検索結果描画の再レンダリングを削減して、既存テストとビルドが通る状態にする"
/goal "商品詳細ページの価格表示ロジックをPriceDisplayコンポーネントに分離し、通常価格、セール価格、無料、購入済みの表示パターンをテストで確認できる状態にする"
/goal "購入ボタンの表示条件を整理し、未ログイン、購入済み、未購入、無料作品、販売終了の各状態で期待するCTAが表示される状態にする"
ポイントは、最後に検証可能な条件を入れることです。
例えば、以下のような条件です。
ビルドが通る
テストが通る
lint が通る
E2Eテストが通る
既存挙動を維持する
URLクエリと状態が同期される
対象イベントが重複送信されない
特定ページのmeta情報が出力される
検索レスポンス差のボトルネックが整理されている
git status がクリーンになる
悪い /goal の書き方
逆に、以下のような書き方は弱いです。
/goal "検索を良くする"
/goal "商品詳細ページを改善する"
/goal "購入導線をいい感じにする"
/goal "SEOを強くする"
/goal "日本語検索を速くする"
これらは、完了条件が曖昧です。
Claude がどこまで進めればよいのか判断しづらくなります。
/goal を使うときは、「何をやるか」よりも「何をもって完了とするか」を明確にする方が重要です。
/goal に向いている作業
/goal は、短い質問や単純な修正よりも、複数ステップに分かれる作業に向いています。
例えば、以下のような作業です。
検索結果ページの状態管理整理
日本語検索と英語検索のパフォーマンス差調査
商品詳細ページの価格表示整理
購入導線のリファクタリング
表示速度改善
SEOと構造化データの改善
ログイン状態による表示分岐整理
カート画面の状態管理改善
レコメンド枠の遅延読み込み
Feature Flag の削除
アクセス解析イベントの整理
APIエラー表示の共通化
アクセシビリティ改善
特に、ストアWebでは「調査して、修正して、ビルドして、テストして、さらに直す」という流れがよくあります。
このような作業は /goal と相性が良いです。
/goal に向いていない作業
一方で、以下のような作業にはあまり向いていません。
単純な質問
1ファイルだけの軽微な修正
仕様相談だけ
デザイン方針の壁打ち
人間の判断が必要な意思決定
完了条件が曖昧な調査
例えば、以下のような指定は弱いです。
/goal "この購入導線を良くする"
この場合は、まず通常のプロンプトで設計方針を固めた方が良いです。
そのうえで、実装段階に入ってから /goal を使う方が自然です。
/goal を使うときの注意点
公式ドキュメントによると、/goal の評価器は独立してコマンドを実行したり、ファイルを読み取ったりするわけではありません。
評価器は、会話上に表示された内容をもとに条件が満たされたかを判断します。
そのため、完了条件には「Claude が会話上で証明できる条件」を含める必要があります。
例えば、以下のような条件です。
npm test が 0 で終了する
npm run build が成功する
npm run lint が成功する
E2Eテストが成功する
git status が clean である
対象コンポーネントのテストが追加されている
検索レスポンス差の計測結果が会話上に表示されている
フロントエンド開発であれば、例えば以下のような書き方が考えられます。
/goal "商品詳細ページの価格表示ロジックをPriceDisplayに分離し、npm test と npm run build が成功する状態にする"
作品検索の調査であれば、以下のような書き方もできます。
/goal "作品検索で日本語クエリと英語クエリのレスポンス差を計測し、APIレスポンス、検索条件生成、描画処理のどこが主因かを会話上に整理する"
また、長く走りすぎることを避けたい場合は、条件に上限を入れるのも有効です。
/goal "検索結果ページのフィルタ状態管理を整理し、ビルドが通る状態にする。ただし最大10ターンで停止する"
/goal は便利ですが、無制限に任せるよりも、検証可能な条件と停止条件を明確にした方が安全です。
/goal と通常プロンプトの使い分け
通常プロンプトは、短い作業に向いています。
この関数の責務を説明して
このエラーの原因を教えて
このテスト名を改善して
この差分をレビューして
このコンポーネントの責務を整理して
一方で /goal は、完了条件まで進めたい作業に向いています。
/goal "商品詳細ページの購入ボタン表示条件を整理し、未ログイン、購入済み、未購入、無料作品、販売終了の各状態で期待するCTAが表示され、関連テストが通る状態にする"
検索パフォーマンスのような調査系タスクでも、完了条件を明確にすれば使いやすくなります。
/goal "作品検索で日本語クエリと英語クエリのレスポンス差を調査し、API、正規化、描画、再検索制御のどこにボトルネックがあるかを整理して、改善方針を提示する"
この違いを意識すると、Claude Code の使い方が変わります。
AI に「回答してもらう」のか。
AI に「完了条件まで作業してもらう」のか。
/goal は後者に近い使い方です。
まとめ
Claude Code の /goal コマンドは、AI に「完了条件」まで作業を進めてもらうための機能です。
特に、電子書籍ストアWebのような開発では、以下のような作業が多く発生します。
検索結果ページの状態管理整理
日本語検索と英語検索のパフォーマンス差調査
商品詳細ページの価格表示整理
購入導線のリファクタリング
表示速度改善
SEOと構造化データの改善
ログイン状態による表示分岐整理
カート画面の状態管理改善
レコメンド枠の遅延読み込み
Feature Flag の削除
アクセス解析イベントの整理
APIエラー表示の共通化
アクセシビリティ改善
これらは、1回のコード生成で終わる作業ではありません。
調査、修正、ビルド、テスト、追加修正が必要になります。
そのため、/goal のように「どこまで到達したら完了か」を先に渡す考え方と相性が良いです。
重要なのは、曖昧な依頼にしないことです。
/goal "商品詳細ページをいい感じに改善する"
ではなく、
/goal "商品詳細ページの価格表示ロジックを整理し、通常価格、セール価格、無料、購入済みの表示パターンをテストで確認でき、ビルドが通る状態にする"
と書く。
検索パフォーマンスであれば、
/goal "作品検索で日本語クエリと英語クエリの検索レスポンス差を調査し、正規化、API呼び出し、描画処理、IME入力制御のどこにボトルネックがあるかを整理して、改善方針を提示する"
と書く。
/goal は、AI に「何をしてほしいか」ではなく、「どこまで到達したら完了か」を伝えるためのコマンドです。
この考え方に慣れると、Claude Code は単なるコード生成ツールではなく、長めの開発タスクを進めるための実行エージェントとして使いやすくなります。