Claude CodeのPlan Mode：2026年版、手順と4つのフェーズを解説

詳しくはAilootのドキュメントをご覧ください。

Plan Modeとは何か、なぜそれだけでは不十分なのか？#

通常モードではClaude Codeはすぐにコードを書きます。進行を把握していないと、多数のファイルにまたがる差分が突然出てくることがあります。Plan Modeは手順を逆転させ、まず調査と計画、次に承認、その後に変更を行います。

Anthropicは公式ドキュメントでPlan Modeを次のように説明しています。

単純に聞こえますが、ここには大きな変化が隠れています。Plan Modeは作業のリズムを変えます。まず合意し、その後に実行するのです。これは見た目だけの調整ではなく、モードそのものの変更です。バイブコーディングをする人にとって厄介なのは、AIエージェントが急ぎがちなことです。通常モードで「Google認証を追加して」と頼むと、Claudeは1分でコードを書きますが、ファイルの半分は間違っているでしょう。Plan Modeでは同じ依頼がテキストの計画になり、コードに手を付ける前に2分で読んで修正できます。

海外のガイドではほとんど語られない落とし穴があります。Plan Mode単体では心もとないツールです。計画は現在の会話にしか存在しません。ウィンドウを閉じると計画は失われ、別のエージェントに引き継ぐこともできません。バージョンも履歴もありません。タスクが大きい場合（30ファイルのモジュールのリファクタリングや、新しいデータベースへの移行など）、計画はすぐにコンテキストウィンドウの上限に達し、質が落ち始めます。

そのため、Plan Modeはリポジトリ内のplans/フォルダと組み合わせるとうまく機能します。計画をplans/2026-05-21-google-oauth.mdとして保存し、フェーズごとにチェックボックスで分ければ、次のエージェントが引き継げます。これがコンテキストエンジニアリングの考え方です。プロンプトの最中ではなく、プロンプトを出す前にコンテキストを管理します。

Claude CodeでPlan Modeを有効にするには？#

セッション中に使う最も手早い方法は、キーボード操作です。

Shift+Tab           # cycles through modes: default → acceptEdits → plan

2回押すと、ターミナル下部に⏸ plan mode onと表示されます。3回目を押すと通常モードに戻ります。作業の規模が大きくなってきたとき、その場で切り替えられる最も便利な方法です。

2つ目は、1つのプロンプトの前にプレフィックスを付ける方法です。

/plan write a plan to migrate the database from MySQL to Postgres

自動承認モードを使っていて、セッション全体のモードは変えたくない場合に便利です。1つの依頼だけPlan Modeで処理し、その後はこれまでどおり作業を続けられます。

3つ目は、セッションの起動時に指定する方法です。

claude --permission-mode plan

タスクに計画が必要だと事前に分かっている場合に使います。大規模なリファクタリングや移行の前などが該当します。

4つ目は、プロジェクトの.claude/settings.jsonでデフォルトを設定する方法です。

{
  "permissions": {
    "defaultMode": "plan"
  }
}

どんな場合に役立つでしょうか。複雑なシステムで、どの変更も隣接するモジュールに影響しかねないチーム作業の場合です。Plan Modeをデフォルトにすると、誤変更からチーム全体を守れます。

見落とされがちな5つ目の小技として、Ctrl+Gで計画をテキストエディタで開けます。計画がほぼ正しいものの、2〜3点を言い換えたり、制約を追加したりしたいときに使います。手動で編集して保存すれば、Claudeはその内容に従って続けます。

Plan ModeにおけるAnthropic標準の4フェーズ、Explore・Plan・Implement・Commitとは？#

多くのガイドでは3フェーズ（Explore-Plan-Execute）や2フェーズ（Plan-Implement）だけを紹介しています。これらは簡略化したものです。公式ベストプラクティスガイドでAnthropicが示しているのは、正確に4つのフェーズです。Commitを独立したフェーズにすることには意味があります。「もう少し調整した。コミットは後でやろう」と結果を放置せず、記録するようになるからです。これは作業を失う最も一般的な原因です。

計画が正確であるほど、実装に必要な反復は少なくなります。計画に10分かければ、実装は1つのプロンプトで済みます。1分で計画をざっと書けば、修正に1時間かかります。

Anthropic Docsの例を使って、Google OAuthを追加する場合の4フェーズを見てみましょう。

フェーズごとにプロンプトも異なります。Exploreでは「/src/authを読んで、セッションとログインの扱いを理解して」。Planでは「Google OAuthを追加したい。どのファイルを変更する必要がある？計画を作って」。Implementでは「計画に沿ってOAuthフローを実装し、テストを書いて、テストスイートを実行し、失敗を修正して」。Commitでは「説明的なメッセージでコミットし、PRを開いて」。

重要な補足があります。Plan ModeでもClaudeが調査用コマンドを実行することは禁止されません。Read、LS、Glob、Grep、web fetch、調査のためのシェルコマンドは許可されています。禁止されるのはEdit、Write、およびファイルシステムを変更する操作です。そのため、Claudeはプロジェクト構成を読み、git logを実行し、テストを確認できますが、誤って何かを変更することはありません。

Claudeの計画を読み、承認するかどうかを判断するには？#

Claudeが計画の作成を終えると、次に何をするか選択肢が表示されます。

• 承認して自動モードで開始
• 承認して編集を受け入れる
• 承認して編集ごとに手動で確認
• フィードバックを続けて計画を練る
• Ultraplanで改良する（ブラウザーでレビュー）

計画を承認すべきか判断することは、Plan Modeの重要なスキルです。「Approve」を反射的に押してしまい、後でコミットを取り消す羽目になることはよくあります。AIの追従的な振る舞いはすぐに答えを返そうとし、あなたは早くコードに取りかかりたいと思っています。どちらも間違いです。

良い計画は7つの基準を満たします。

1. 具体的なファイル名。「認証を更新する」ではなく、「src/auth/login.ts:42-58を変更し、src/auth/oauth-callback.tsを作成し、src/auth/session.ts:103を更新する」と書かれています。
2. 手順が明記されている。「どこかで全部やる」ではなく、計画がフェーズまたはステップに分かれています。
3. 外部依存関係が示されている。新しいライブラリが必要なら記載されています。環境変数が必要な場合も同様です。
4. リスクが列挙されている。良い計画は「移行で既存セッションが壊れる可能性があるため、Xを確認する必要がある」と書きます。悪い計画は副作用に触れません。
5. 成功基準がある。「test/authのテストが通り、リンターがクリーンで、開発サーバーがエラーなく起動する」などです。
6. 「根拠のない」前提がない。Claudeが「ライブラリZを使う」と書いたら、プロジェクトにインストールされているか確認してください。AIが作り出したものなら、package.jsonに記載がないと分かります。
7. 画面に収まる。単純な機能の計画が200行に及ぶなら、タスクが大きすぎて1つの計画では扱えない可能性があります。分割しましょう。

計画が基準を満たさない場合、選択肢は3つあります。

• フィードバックを続けて計画を練る—気に入らない点を具体的にClaudeに伝えると、計画を書き直します。
• Ctrl+G—エディタで計画を開き、手動で編集して保存します。Claudeはあなたのバージョンで続けます。
• Ultraplanで改良する—計画をClaude Code on the webのブラウザーモードに送り、セクションを確認してコメントした後、ローカルまたはクラウドで実行します。

実装の途中で問題が起きたら、無理に進めないことです。Plan Modeに戻って計画を書き直しましょう。後で40コミットを取り消すより10倍安く済みます。

Plan Mode + plans/フォルダ：長いコンテキストに対応する組み合わせ#

Plan ModeはClaude Codeのモードです。plans/フォルダは、その上に構築する方法論です。フォルダを作らずにPlan Modeを使うと、1時間も作業すれば限界に達します。

考え方はこうです。Claudeのコンテキストウィンドウはセッションの記憶です。Opus 4.7では100万トークンを入れられますが、これは会話全体の容量です。複雑なタスクを1つの会話で計画し、実装を依頼し、バグを議論し、さらに別の話をすると、ウィンドウは「膨張」します。Claudeは初期の決定を忘れ始め、コンテキストを混同し、同じ質問を繰り返します。

解決策は黄金律です。1つのタスクにつき1つの会話。

手順は次のとおりです。

1. 会話1—計画を作る。Plan Modeを有効にし、タスクを説明すると、Claudeが計画を作成します。計画をplans/2026-05-21-feature-name.mdに保存します。ウィンドウを閉じます。
2. 会話2—フェーズに分ける。新しいチャットを開き、「plans/2026-05-21-feature-name.mdを開いて、フェーズに分けて」と頼みます。更新したファイルを保存します。
3. 会話3—フェーズ1を実装する。新しいチャットを開き、「plans/2026-05-21-feature-name.mdにあるフェーズ1を実装し、完了した項目にチェックを入れて」と頼みます。ウィンドウを閉じます。
4. 会話4—フェーズ2を実装する。同じように進めます。

こうすると何がよいのでしょうか。各会話のコンテキストウィンドウを新鮮に保てます。フェーズ3を担当するClaudeはフェーズ1の詳細を知りませんが、リポジトリにplans/ファイルがあるため、計画は把握しています。サブエージェント、新しいセッション、/goalによる実行など、次のエージェントが計画を引き継いで続けられます。

方法を比較します。

機能ごとに計画ファイルを1つ作ります。3か月後に、なぜある決済プロバイダーを別の候補より選んだのか思い出したいとき、該当する計画を開いて意思決定の履歴を読めます。何を話し合い、どの選択肢を検討し、なぜその道を選んだかが分かります。

これらは進行中の作業計画です。静的なドキュメントは数か月で古くなります。

Plan Modeと/goalを使って、Claudeを寝ている間に働かせるには？#

長時間のAIセッションにおける最大の制約は、モデル自体ではなく、Enterを押す人です。Claudeは各ターンの終わりに達するたび、あなたの返答を待ちます。/goalはその待ち時間をなくします。

構文は簡単です。

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

条件は最大4000文字です。1セッションにつき目標は1つです。各ターンの後にHaiku miniモデルがトランスクリプトを読み、「条件達成—終了」または「未達成—次のターン」と判断します。評価モデルはツールを呼び出さず、読むだけです。

目標を解除するエイリアスは次のとおりです。/goal stop、/goal off、/goal reset、/goal none、/goal cancel。

Plan Modeとの組み合わせは次のようになります。

1. Plan Modeを有効にします（Shift+Tabを2回押す）。
2. 「MySQLからPostgresへのデータベース移行計画を作り、フェーズと基準を付けてplans/2026-05-21-postgres-migration.mdに保存して」と頼みます。
3. 計画を確認し、編集して、承認します。
4. Plan Modeを終了します（Shift+Tabをもう1回押す）。
5. 目標を設定します。「plans/2026-05-21-postgres-migration.mdの全フェーズを完了し、チェックボックスにチェックを入れ、すべてのテストを通す。50ターンで停止する。」
6. ノートパソコンを閉じて眠ります。

朝に結果を確認すると、「✓ goal completed」または「◎ stopped after 50 turns」と、実施内容の履歴が表示されます。

/goalでトークンを浪費しないための重要なルールが3つあります。

ルール1：測定可能な最終状態。「見栄えをよくする」はよくありません。「npm testが0を返し、npm run lintが0を返し、CHANGELOG.mdに項目を追加する」は適切です。

ルール2：明示的な検証。条件には検証可能なもの、つまりコマンド、ファイル、エンドポイントを含めます。「すべて動く」ではなく、「curl localhost:3000/api/usersが200を返す」とします。

ルール3：ターン数を制限する。必ずor stop after N turnsを追加します。Anthropicはドキュメントで明示的に推奨しています。

or stop afterを付けずに/goalを有効にすると、一晩で予算が消える可能性があります。

Plan Modeをエンジニアリングプロセスに変える4ステップのサイクルとは？#

よくある間違いは、「どう直せばいい？」と尋ねることです。Claudeが解決策を提示し、それを適用しても、何も直らないか、状況が悪化します。これが「AIの追従的な振る舞い」です。Claudeは素早く答えるよう訓練されており、あなたは早くコードに取りかかりたいと思っています。4ステップのサイクルがこの問題に対処します。

この4ステップのサイクルは、この振る舞いを抑えます。Plan Modeのセッション1つの中で、順番に使います。

ステップ1. 解決策を出さずに事実を確認する。

プロンプト：「次の問題が起きています：[症状の説明]。今のあなたの仕事は事実を確認することです。解決策、アイデア、助言は禁止です。記録するのは、私が観察したこと、再現できる手順、利用可能なデータ、不足しているデータだけです。厳守する停止条件：解決策を提案しないこと。診断だけを記録してください。」

これにより、AIの最初の衝動である「解決策はこちらです」を抑えます。Claudeは「分かっていることと、分かっていないこと」で止まらざるを得ません。

ステップ2. 先例をもとに選択肢を考える。

プロンプト：「診断が確定したので、類似の問題の解決例をオンラインで探してください。少なくとも3つの異なるアプローチを挙げてください。それぞれについて、一次情報へのリンク、簡潔な説明、今回の状況における長所と短所を示してください。」

これにより、AIの2つ目の衝動である「思いつきで解決策を作る」を抑えます。外部の情報を探し、確認可能なアプローチを持ち帰らせます。

ステップ3. リスクを含む詳細な計画を作る。

プロンプト：「ステップ2の最良の選択肢を使い、詳細な計画を立ててください。具体的に変更するファイル、追加するもの、削除するもの、作成するテスト、壊れる可能性があるもの、2〜3手先にあるリスクを挙げてください。」

これはおなじみのPlanフェーズですが、1つ違いがあります。Claudeの推測ではなく、ステップ2で確認した選択肢をもとにしています。

ステップ4. 計画を自己点検する。

プロンプト：「必須の自己点検をしてください。計画を正直に見直し、コード、ドキュメント、ステップ2の先例で検証していない根拠のない推測がないか確認してください。あれば明示して、計画を修正してください。」

これが最後のフィルターです。Claudeは自身の推論を確認し、幻覚を起こした箇所を認めなければなりません。このステップでは通常、計画の項目が少なくとも2つ修正されます。

4つのステップを終えれば、計画は承認できる状態です。タスクを理解し、選択肢を比較し、リスクを考慮したうえで実装に進めます。

この方法論は、難しいバグの診断や、誤りのコストが高いアーキテクチャ上の判断のためのものです。Plan Modeに適用すると、バイブコーディングをする人の最大の悩みである「AIが解決策を提示したので適用したら、すべてが壊れた」を解消します。

よくあるタスクでPlan Modeに使える5つのプロンプトテンプレートとは？#

テンプレート1. モジュールのリファクタリング。

Plan Modeを有効にします。タスク：{module-name}モジュールをリファクタリングします。

ステップ1：{module-path}モジュールの現在の構成を調べてください。以下を説明してください。
- モジュールに含まれるファイル
- 外部依存関係
- 重複している部分
- 複雑になりすぎている関数

ステップ2：類似のモジュールをリファクタリングしたオンライン事例を2〜3件探してください。
少なくとも1つはAnthropic公式、または関連フレームワークの公式ドキュメントにしてください。

ステップ3：リファクタリング計画をplans/YYYY-MM-DD-refactor-{module}.mdに作成してください。
- 名前を変更するファイル
- 別モジュールに切り出す関数
- 維持するテストと書き直すテスト
- リスク：ユーザーに影響する可能性があること

ステップ4：自己点検してください。計画に「根拠のない」前提はありませんか？
書き直すか削除してください。

テンプレート2. データベース移行。

Plan Modeを有効にします。タスク：データベースを{old}から{new}に移行します。

ステップ1：{schema-reading-command}を使って現在のデータベーススキーマを調べてください。以下を説明してください。
- 存在するテーブルとその規模
- 関連、インデックス、制約
- マイグレーションの保存場所
- 重要なデータ

ステップ2：本番プロジェクトにおける{old → new}の移行事例を探してください。
pg_dump、dual-write、blue-greenの、少なくとも3つの異なるアプローチを挙げてください。
それぞれについて、データ量に照らした長所とリスクを列挙してください。

ステップ3：移行計画をplans/YYYY-MM-DD-db-migration.mdに作成してください。
- フェーズ（バックアップ、移行、検証、切り替え）
- 各フェーズの成功基準
- 問題発生時のロールバック計画
- ダウンタイムの有無

ステップ4：自己点検してください。すべての数値にドキュメントの裏付けがありますか？
開発環境に照らして各ステップを頭の中で確認しましたか？

テンプレート3. 新機能の追加。

Plan Modeを有効にします。タスク：プロジェクトに{description}機能を追加します。

ステップ1：プロジェクト内で類似機能が現在どのように動いているか調べてください。
特に、以下を確認してください。
- {file-1}
- {file-2}
- 使われているアーキテクチャパターン
- 類似機能のテスト

ステップ2：類似のアーキテクチャを使うオープンソースプロジェクトで、この機能がどう実装されているか探してください。
少なくとも2つの異なるアプローチを挙げてください。

ステップ3：plans/YYYY-MM-DD-feature-{name}.mdに計画を作成してください。
- 新規ファイルの一覧
- 具体的な行を示した変更ファイルの一覧
- 実装の順序
- 追加するテスト
- 今後のセッション向けのルールとしてCLAUDE.mdに追加する内容

ステップ4：自己点検してください。計画はプロジェクトのアーキテクチャに沿っていますか？
まだインストールされていないライブラリを前提にしていませんか？

テンプレート4. テストの作成。

Plan Modeを有効にします。タスク：{name}モジュールをテストでカバーします。

ステップ1：{path}モジュールを調べ、以下を特定してください。
- 公開関数とそのシグネチャ
- テストしない内部関数（実装の詳細）
- エッジケース：空の入力、エラー、並行アクセス

ステップ2：同じフレームワークを使う、人気のオープンソースプロジェクトで類似タスクのテスト例を探してください。

ステップ3：plans/YYYY-MM-DD-tests-{module}.mdにテスト計画を作成してください。
- 各公開関数について、テストの一覧
- 必要なモック
- フィクスチャ
- 検証方法（アサーションの形式）

ステップ4：自己点検してください。すべてのテストは実装ではなく動作を検証していますか？
エッジケースをカバーしていますか？

テンプレート5. 複雑なエラーのデバッグ。

Plan Modeを有効にします。タスク：エラーの原因{symptom-description}を理解します。

ステップ1：事実を確認します。解決策やアイデアは禁止です。以下だけを挙げてください。
- 観察したこと（エラーの正確な文言）
- 再現手順
- 利用可能なデータ（ログ、トレース、ライブラリのバージョン）
- 不足しているデータ（追加で収集する必要がある情報）

ステップ2：このエラーの事例を探してください。
GitHubのissueやドキュメントから少なくとも3つの情報源を挙げてください。
各事例について、リンクと解決策の簡潔な要約を示してください。

ステップ3：plans/YYYY-MM-DD-bug-{name}.mdに診断計画を作成してください。
- 確認する仮説（可能性の高い順）
- 各仮説を確認するコマンドやスクリプト
- 各確認で予想される結果

ステップ4：自己点検してください。計画に「根拠のない」仮説はありませんか？
すべての仮説はステップ1の事実と結び付いていますか？

各テンプレートをコピーし、{parameters}を自分の値に置き換えて、Plan ModeのClaude Codeに貼り付けてください。結果として、plans/に実用的な計画ができ、承認して実装に使えます。

Plan Modeと通常モード、どちらを選ぶべき？#

Anthropicは公式ドキュメントで次のように述べています。

独立した計画を省けるのは、実際の差分が小さく、理解でき、低リスクのときです。方法の調査や、危険な横断変更の調整には計画を使います。ファイル名や一文の目的が分かっても、移行、認証、データ整合性のリスクは残ります。

判断表：

モードを選ぶ前に、方法、副作用、検証を理解しているか確認します。小さく局所的で低リスク、明白な検査があるなら直接進めます。不確実、不慣れ、移行、認証、複数構成要素の調整があるなら、対象3〜5ファイルをすでに挙げられても先に計画してください。

Plan Mode + CLAUDE.md + サブエージェントを組み合わせて、信頼性を高めるには？#

CLAUDE.mdは、Plan Modeを含むすべてのセッションの開始時にClaudeが読むファイルです。CLAUDE.mdに「日付をハードコードしない。必ずデータベースから取得する」と書いてあれば、計画で日付をハードコードする提案は出ません。そのようなルールがなければ、計画は何でも提案できます。

組み合わせると、次のように機能します。

レイヤー1. CLAUDE.mdでルールを定める。

このファイルでは、プロジェクトの技術スタック、アーキテクチャ原則、禁止事項（「非推奨APIを使わない」）、要件（「すべてのメールで共有レイアウトを使う」）を指定します。詳しくはCLAUDE.mdの設定方法をご覧ください。

レイヤー2. Plan Modeでルールをタスクに適用する。

Plan Modeを有効にして「OAuthを追加して」と頼むと、ClaudeはCLAUDE.mdを読み、「トークンはデータベースではなくRedisに保存する」というルールを確認して、すぐ計画に反映します。計画はプロジェクトのアーキテクチャに沿ったものになります。

レイヤー3. サブエージェントに作業を分ける。

計画をフェーズに分けた場合、各フェーズを個別のサブエージェントに割り当てられます。各サブエージェントは独自のコンテキストウィンドウで作業するため、メインのコンテキストを圧迫しません。plans/の計画は信頼できる唯一の情報源として残ります。サブエージェントが読み、担当フェーズを実行し、チェックボックスを更新します。

Plan Modeを壊す7つの間違いとは？#

間違い1. 計画がチャットにしか存在しない。

症状：計画を書いてウィンドウを閉じ、翌日に続きをしたいのに、何も残っていません。コンテキストが失われています。解決策：計画は必ずリポジトリ内のplans/YYYY-MM-DD-feature-name.mdに保存します。チャットは作業机、ファイルはアーカイブです。

間違い2. すべてのタスクを1つのチャットに入れる。

症状：1つのセッションで認証、移行、UIデザイン、バグと次々に議論します。コンテキストウィンドウが「膨張」し、Claudeは前の内容を忘れます。解決策：1つのタスクにつき1つの会話です。計画が完成したらウィンドウを閉じ、実装を始めるときは新しいチャットを開きます。

間違い3. フェーズのない3000行の計画。

症状：計画はありますが、チェックボックスや区分がありません。何が終わり、何が残っているか分からず、委任もできません。解決策：各計画を3〜7フェーズに分けます。各フェーズを具体的な作業項目のチェックリストにします。

間違い4. 計画の前に十分な調査をしない。

症状：先例を探すよう頼まなかったため、Claudeが思いつきで解決策を提示します。1週間後に、オープンソースではずっと前からより良い方法が使われていたと分かります。解決策：4ステップサイクルのステップ2として、計画を作る前にClaudeにオンラインで2〜3件の先例を探させます。

間違い5. AIの追従的な振る舞いが診断なしに解決策を出す。

症状：「エラーXをどう直せばいい？」と尋ね、Claudeの解決策を適用しても何も直らないか、状況が悪化します。解決策：必ず「事実を確認する。解決策は禁止」と始めます。選択肢に進むのは診断の後だけです。

間違い6. 自己点検を省く。

症状：計画はもっともらしく見えますが、根拠のない前提が2〜3個含まれています（架空のライブラリ、存在しないAPI、誤ったバージョンなど）。その箇所で実装が失敗します。解決策：4ステップサイクルのステップ4として、Claudeに計画を正直に見直し、前提を指摘させます。

間違い7. /goalの条件が曖昧。

症状：「見栄えをよくする」という/goalを設定して夜通し動かしたら、朝には利用枠の200ドル分が使い切られていました。解決策：検証コマンドと必須のor stop after N turnsを含む、測定可能な条件だけを使います。「よくする」「磨き上げる」といった表現は避けます。

バイブコーディングをする人が最もよく犯す8つ目の間違いは、plans/フォルダ自体を作らないことです。plans/フォルダのないPlan Modeは方法論ではなく、おもちゃです。Plan Modeを使ってもファイルを作らなければ、その機能の10%しか活用できません。

Plan Modeを初めて使った後、次に何をすべき？#

難易度が低い順に、具体的なステップを3つ紹介します。

ステップ1. まだなければCLAUDE.mdを設定する。

CLAUDE.mdがないと、Plan Modeは「真空の中」で動きます。Claudeはプロジェクトのルールを知らず、アーキテクチャを壊す計画を提案します。詳しくはCLAUDE.mdの設定方法をご覧ください。最小限のCLAUDE.mdは、技術スタック、ルール、禁止事項を記した50〜80行です。長さよりも具体性が重要です。

ステップ2. リポジトリにplans/フォルダを作る。

プロジェクトのルートにplans/フォルダを追加します。命名形式をYYYY-MM-DD-feature-name.mdに統一します。計画ごとにファイルを1つ作成します。1か月後には20〜30ファイル、半年後には100以上になるでしょう。それらは、プロジェクトの意思決定を記録した生きた履歴になります。

ステップ3. 1つのタスクで/goalを試す。

通常なら手作業で30〜40分かかるタスクを選びます。Plan Modeを有効にし、計画を作ってplans/に保存します。Plan Modeを終了して、/goal complete all phases in plans/file.md, all tests pass, or stop after 30 turnsを設定します。ノートパソコンを閉じて1時間、別のことをしてください。戻ったら結果を確認します。

これら3つが最低限です。これは段階的に整えるものです。一晩ですべてを作ろうとしないでください。まずCLAUDE.mdを作り、1週間後にplans/を追加し、1か月後に夜間の/goalを試します。

準備ができたら、Ailootをご覧ください。