はじめに
Claude Code では、/goal コマンドを使えます。
/goal は、ざっくり言うと、Claude に「どこまで到達したら作業完了か」を伝えるためのコマンドです。
通常のプロンプトでは、ユーザーが毎回、次のように指示する必要があります。
次はこのファイルを見て
次はこのテストを直して
次はビルドエラーを確認して
次は不要なコードを削除して
一方で /goal を使うと、最初に「完了条件」を設定できます。
例えば、以下のような形です。
/goal "すべてのテストが通るまで、UserProfileViewModel のリファクタリングを完了する"
この場合、Claude は単に1回だけコードを修正するのではなく、指定された完了条件に向かって作業を続けます。
本記事では、Claude Code の /goal コマンドについて、電子書籍アプリのような大規模 iOS アプリ開発を例にして整理します。
公式ドキュメント
まず、公式ドキュメントはこちらです。
- Claude をゴールに向かって動作させ続ける - Claude Code Docs
- コマンド - Claude Code Docs
- Claude Code の概要 - Claude Code Docs
公式ドキュメントでは、/goal はコンプリーション条件を設定する機能として説明されています。
/goal を使うと、Claude は各ステップごとにユーザーの追加指示を待つのではなく、設定された条件が満たされるまでターンをまたいで作業を続けます。
つまり、/goal は単なる TODO メモではありません。
重要なのは、「何をしてほしいか」だけではなく、「どこまで到達したら完了か」を Claude に渡す点です。
/goal の基本構文
基本的な使い方はシンプルです。
/goal <完了条件>
例です。
/goal "認証まわりのテストがすべて通り、lint も成功する状態にする"
現在のゴールを確認する場合は、引数なしで実行します。
/goal
アクティブなゴールを削除する場合は、以下のように実行します。
/goal clear
公式ドキュメントでは、clear 以外にも、stop、off、reset、none、cancel がアクティブなゴール削除のエイリアスとして説明されています。
/goal で何が変わるのか
通常の Claude Code 利用では、ユーザーが作業単位ごとに指示を出します。
例えば、リファクタリング作業であれば、以下のような流れになりがちです。
この ViewController を見て
責務を分けて
ビルドして
エラーを直して
テストを実行して
不要になったコードを削除して
この方法でも作業はできます。
ただし、複数ファイルにまたがる作業では、指示が細かくなりやすく、人間側が進行管理をする必要があります。
/goal を使うと、最初に終了条件を渡せます。
/goal "SearchViewController を責務分離し、検索条件管理を SearchState に移動して、既存テストとビルドが通る状態にする"
このように指定すると、Claude は単に「リファクタリングする」だけでなく、「ビルドとテストが通る状態」までを目指して作業します。
ここが大きな違いです。
/goal は「作業内容」ではなく「完了条件」を渡すコマンド
/goal を使うときに重要なのは、作業内容だけを書かないことです。
悪い例です。
/goal "Reader をいい感じに改善する"
この指定では、何をもって完了とするのか判断できません。
「いい感じ」は人間にとっても曖昧ですし、AIにとっても曖昧です。
良い例です。
/goal "Reader 画面の画像キャッシュ処理を見直し、メモリ警告時に不要キャッシュを解放する実装を追加し、ビルドが通る状態にする"
こちらは完了条件が明確です。
少なくとも、以下が読み取れます。
- 対象は Reader 画面
- 作業内容は画像キャッシュ処理の見直し
- 追加する実装はメモリ警告時の不要キャッシュ解放
- 完了条件はビルドが通る状態
/goal は、AIに「何となく改善して」と頼むためのコマンドではありません。
「この状態になったら完了」と判断できる条件を渡すためのコマンドです。
なぜ電子書籍アプリ開発と相性が良いのか
電子書籍アプリは、一般的な CRUD アプリよりも状態管理が複雑になりがちです。
例えば、以下のような要素があります。
- Reader
- 書籍ダウンロード
- オフライン閲覧
- 画像キャッシュ
- ページ位置復元
- 購入状態
- 同期処理
- 会員状態
- 端末間同期
- メモリ管理
- 古い OS や古い端末への対応
特に Reader 周辺は、単純な画面表示では終わりません。
EPUB、PDF、画像、キャッシュ、ページング、メモリ警告、バックグラウンド復帰など、複数の状態が絡みます。
そのため、開発作業も1回の指示では終わりにくいです。
例えば、Reader のクラッシュ改善をする場合、以下のような作業が発生します。
クラッシュログを読む
再現条件を推測する
該当コードを探す
メモリ保持箇所を確認する
修正する
ビルドする
テストする
副作用がないか確認する
このような作業は、Claude Code に対して単発で「直して」と依頼するよりも、/goal で完了条件を渡した方が扱いやすくなります。
電子書籍アプリでの /goal 利用例
ここからは、電子書籍アプリ開発で使えそうな /goal の例を挙げます。
特定企業や特定サービスに依存しない、一般的な電子書籍アプリ開発の例として読んでください。
例1：Reader 画面のメモリ改善
/goal "Reader 画面の画像キャッシュ処理を調査し、メモリ警告時に不要なキャッシュを解放する実装を追加して、ビルドが通る状態にする"
Reader 画面は、電子書籍アプリの中でもメモリ使用量が大きくなりやすい領域です。
ページ画像、サムネイル、先読みデータ、表示中ページ、前後ページなどを保持するため、実装によってはメモリが膨らみます。
このような改善は、単純な1ファイル修正では終わらないことがあります。
キャッシュ管理、ライフサイクル、メモリ警告、ページ遷移、バックグラウンド復帰などを確認する必要があるからです。
/goal を使う場合は、「メモリをいい感じに改善する」ではなく、「メモリ警告時に不要キャッシュを解放する」「ビルドが通る」など、完了条件を明確にします。
例2：起動速度改善
/goal "アプリ起動時の初期化処理を調査し、本棚初期表示に不要な同期処理や重い初期化を遅延実行へ移動して、既存挙動を維持したままビルドが通る状態にする"
電子書籍アプリでは、起動時に多くの処理が走りがちです。
例えば、ログイン状態の確認、本棚データの読み込み、購入済み書籍の同期、ダウンロード状態の確認、Reader 設定の読み込み、分析 SDK の初期化、Feature Flag の取得などです。
これらをすべて起動直後に実行すると、初回表示までの時間が長くなります。
特に電子書籍アプリでは、ユーザーは「すぐに本棚を開きたい」「すぐに続きを読みたい」という期待を持っています。
そのため、起動速度の悪化は体験品質に直結します。
起動速度改善では、以下のような観点を確認します。
AppDelegate / SceneDelegate で重い処理をしていないか
初期表示前に不要な API 通信をしていないか
同期処理を起動直後にまとめて実行していないか
SDK 初期化がメインスレッドをブロックしていないか
本棚表示に不要なデータまで先読みしていないか
Reader 用の重い設定読み込みを起動時に行っていないか
このような作業は、単純な1箇所修正では終わりません。
調査、計測、初期化順序の見直し、遅延実行、ビルド確認、動作確認が必要になります。
そのため、/goal と相性が良いです。
より具体的には、以下のように書くこともできます。
/goal "アプリ起動時の処理を調査し、初期表示前に不要な API 通信と同期処理を遅延実行へ移動して、起動時のメインスレッドブロックを減らし、ビルドが通る状態にする"
起動速度改善で重要なのは、「速くする」とだけ書かないことです。
悪い例です。
/goal "アプリの起動を速くする"
これだと、何をもって完了とするのか曖昧です。
良い例です。
/goal "アプリ起動時に本棚初期表示へ不要な同期処理を遅延実行へ移動し、初期表示までに必要な処理だけを残して、ビルドが通る状態にする"
このように、対象、作業内容、完了条件を明確にすると、Claude が進めやすくなります。
例3：本棚画面の責務分離
/goal "BookshelfViewController を責務ごとに分割し、表示ロジックとデータ取得ロジックを分離して、既存の挙動を維持したままビルドが通る状態にする"
電子書籍アプリの本棚画面は、機能が増えやすい画面です。
例えば、以下のような責務が集まりがちです。
- 書籍一覧表示
- 並び替え
- 絞り込み
- ダウンロード状態表示
- 未読・既読管理
- 購入済み判定
- 同期状態表示
- エラー表示
- 空状態表示
長期運用されたアプリでは、ViewController が肥大化しやすい領域です。
このようなリファクタリングでは、単にファイルを分けるだけでは不十分です。
既存の挙動を壊さないことが重要です。
そのため、/goal では「既存の挙動を維持したまま」「ビルドが通る状態にする」のような条件を入れると実務向きになります。
例4：旧 APIClient から新 APIClient への移行
/goal "BookDownload API の旧メソッドを新 APIClient に移行し、すべての call site を更新して、ビルドが通る状態にする"
長期運用のアプリでは、古い APIClient が残りやすいです。
例えば、以下のような状態です。
旧 APIClient
新 APIClient
一部だけ async/await 対応
一部だけ callback ベース
一部だけ Combine
この状態が続くと、実装方針が分散します。
新規開発時にどの API を使えばよいか分かりづらくなり、保守性も下がります。
/goal を使う場合は、対象 API を絞り、call site の更新まで含めると実用的です。
/goal "BookDownload API の旧 callback ベース実装を async/await ベースの新 APIClient に移行し、すべての call site を更新して、関連テストが通る状態にする"
このように、移行対象、移行先、完了条件を明確にします。
例5：購入履歴画面の SwiftUI 化
/goal "購入履歴画面を SwiftUI 化し、既存の UIKit 画面と同等の表示・遷移・エラー表示を維持して、ビルドが通る状態にする"
UIKit から SwiftUI への移行も、/goal と相性が良い作業です。
理由は、一気に完了しにくいからです。
SwiftUI 移行では、以下のような確認が必要になります。
- 既存の表示と差分がないか
- Navigation が壊れていないか
- ローディング表示が維持されているか
- エラー表示が維持されているか
- 空状態が維持されているか
- 既存の UIKit 画面との接続が壊れていないか
そのため、/goal には「SwiftUI 化する」だけでなく、「既存の表示・遷移・エラー表示を維持する」という条件を入れるのが重要です。
例6：Feature Flag の整理
/goal "恒久的に ON になっている Feature Flag を調査し、不要な分岐を削除して、ビルドと関連テストが通る状態にする"
長期運用のアプリでは、Feature Flag が残り続けることがあります。
リリース当初は必要だった分岐も、時間が経つと以下のような状態になります。
常に ON の Feature Flag
常に OFF の Feature Flag
実験終了後も残っている分岐
削除タイミングを逃した A/B テストコード
このような分岐は、コードの見通しを悪くします。
ただし、Feature Flag の削除は慎重に行う必要があります。
削除してよいフラグなのか、まだ利用されているのか、サーバー側設定と関係があるのかを確認する必要があるからです。
そのため、/goal では「不要な分岐を削除する」だけでなく、「ビルドと関連テストが通る状態にする」まで含めると安全です。
例7：巨大ファイルの分割
/goal "ReaderViewController を責務ごとに分割し、各ファイルを 500 行以下に整理して、既存挙動を維持したままビルドが通る状態にする"
電子書籍アプリでは、Reader や本棚のような中核画面が巨大化しやすいです。
ファイル分割では、以下のような観点が必要になります。
- 表示責務
- 状態管理
- API 通信
- イベントハンドリング
- エラー表示
- 画面遷移
- キャッシュ制御
ただファイルを分けるだけでは、保守性は上がりません。
責務ごとに分ける必要があります。
/goal では、「各ファイルを 500 行以下にする」「既存挙動を維持する」「ビルドが通る」など、判断しやすい条件を入れると効果的です。
例8：ダウンロード処理の安定化
/goal "BookDownloadManager のダウンロード状態管理を見直し、失敗時のリトライとキャンセル処理を整理して、既存のダウンロード挙動を維持したまま関連テストが通る状態にする"
電子書籍アプリでは、書籍ダウンロード処理も複雑になりがちです。
例えば、以下のような状態を扱います。
未ダウンロード
ダウンロード中
一時停止
失敗
リトライ待ち
完了
削除済み
端末容量不足
通信エラー
さらに、バックグラウンド移行、通信断、アプリ再起動、同時ダウンロード数制限なども絡みます。
このような処理は、単純に「ダウンロード処理を直す」では範囲が広すぎます。
/goal では、対象を絞るのが重要です。
/goal "BookDownloadManager の失敗時リトライ処理を整理し、通信エラー時に再試行可能な状態へ戻ることを確認して、関連テストが通る状態にする"
このように、どの状態を直すのか、何をもって完了とするのかを明確にすると進めやすくなります。
良い /goal の書き方
実務では、以下の形で書くと使いやすいです。
/goal "<対象> を <作業内容> し、<検証可能な完了条件> まで進める"
例です。
/goal "SearchViewController を責務分離し、検索条件管理を SearchState に移動して、既存テストとビルドが通る状態にする"
/goal "BookDownloadManager の非同期処理を async/await に移行し、既存のダウンロード挙動を維持して、関連テストが通る状態にする"
/goal "ReaderSettings 画面の重複 UI 実装を共通コンポーネント化し、既存画面の表示差分が出ない状態にする"
ポイントは、最後に検証可能な条件を入れることです。
例えば、以下のような条件です。
ビルドが通る
テストが通る
lint が通る
既存挙動を維持する
すべての call site を更新する
ファイルサイズを指定行数以下にする
git status がクリーンになる
悪い /goal の書き方
逆に、以下のような書き方は弱いです。
/goal "コードをきれいにする"
/goal "Reader を改善する"
/goal "本棚画面をいい感じにする"
これらは、完了条件が曖昧です。
Claude がどこまで進めればよいのか判断しづらくなります。
/goal を使うときは、「何をやるか」よりも「何をもって完了とするか」を明確にする方が重要です。
/goal に向いている作業
/goal は、短い質問や単純な修正よりも、複数ステップに分かれる作業に向いています。
例えば、以下のような作業です。
複数ファイルにまたがるリファクタリング
古い API から新 API への移行
テストが通るまでの修正
ビルドエラーの連続解消
巨大ファイルの分割
設計ドキュメントに沿った実装
バックログの一括処理
起動速度改善
メモリ改善
ダウンロード処理の安定化
特に、大規模 iOS アプリでは「調査して、修正して、ビルドして、テストして、さらに直す」という流れがよくあります。
このような作業は /goal と相性が良いです。
/goal に向いていない作業
一方で、以下のような作業にはあまり向いていません。
単純な質問
1ファイルだけの軽微な修正
仕様相談だけ
設計方針の壁打ち
人間の判断が必要な意思決定
完了条件が曖昧な調査
例えば、以下のような指定は弱いです。
/goal "この設計を良くする"
この場合は、まず通常のプロンプトで設計方針を固めた方が良いです。
そのうえで、実装段階に入ってから /goal を使う方が自然です。
/goal を使うときの注意点
公式ドキュメントによると、/goal の評価器は独立してコマンドを実行したり、ファイルを読み取ったりするわけではありません。
評価器は、会話上に表示された内容をもとに条件が満たされたかを判断します。
そのため、完了条件には「Claude が会話上で証明できる条件」を含める必要があります。
例えば、以下のような条件です。
npm test が 0 で終了する
xcodebuild が成功する
関連テストが成功する
git status が clean である
対象ファイルが 500 行以下になっている
iOS 開発であれば、例えば以下のような書き方が考えられます。
/goal "BookDownloadManager を async/await に移行し、xcodebuild が成功し、関連する Unit Test が通る状態にする"
また、長く走りすぎることを避けたい場合は、条件に上限を入れるのも有効です。
/goal "ReaderViewController の責務分離を進め、ビルドが通る状態にする。ただし最大10ターンで停止する"
/goal は便利ですが、無制限に任せるよりも、検証可能な条件と停止条件を明確にした方が安全です。
/goal と通常プロンプトの使い分け
通常プロンプトは、短い作業に向いています。
この関数の責務を説明して
このエラーの原因を教えて
このテスト名を改善して
この差分をレビューして
一方で /goal は、完了条件まで進めたい作業に向いています。
/goal "Reader 画面の画像キャッシュまわりのクラッシュ原因を調査し、不要な強参照を解消して、ビルドと関連テストが通る状態にする"
この違いを意識すると、Claude Code の使い方が変わります。
AI に「回答してもらう」のか。
AI に「完了条件まで作業してもらう」のか。
/goal は後者に近い使い方です。
まとめ
Claude Code の /goal コマンドは、AI に「完了条件」まで作業を進めてもらうための機能です。
特に、電子書籍アプリのような大規模 iOS アプリでは、以下のような作業が多く発生します。
Reader のメモリ改善
起動速度改善
本棚画面の責務分離
旧 APIClient から新 APIClient への移行
UIKit から SwiftUI への段階移行
Feature Flag の整理
巨大ファイルの分割
ダウンロード処理の安定化
これらは、1回のコード生成で終わる作業ではありません。
調査、修正、ビルド、テスト、追加修正が必要になります。
そのため、/goal のように「どこまで到達したら完了か」を先に渡す考え方と相性が良いです。
重要なのは、曖昧な依頼にしないことです。
/goal "Reader をいい感じに改善する"
ではなく、
/goal "Reader 画面の画像キャッシュ処理を見直し、メモリ警告時に不要キャッシュを解放する実装を追加し、ビルドが通る状態にする"
のように書く。
/goal は、AI に「何をしてほしいか」ではなく、「どこまで到達したら完了か」を伝えるためのコマンドです。
この考え方に慣れると、Claude Code は単なるコード生成ツールではなく、長めの開発タスクを進めるための実行エージェントとして使いやすくなります。