AI コーディングエージェントで「ランディングページを作って」くらいなら動く。しかし、複数ファイル・複数サブシステムが絡む本格的なプロジェクトになると、エージェントはコヒーレンスを失い、前に作ったものを忘れ、壊れたコードを量産し始める。GSD はこの問題を構造的に解決するシステムだ。

GSD とは

GSD（Get Stuff Done）は、大規模・マルチセッションのプロジェクトを AI コーディングエージェントで完遂するためのシステムだ。デモ向けのおもちゃではなく、多数のファイルと複数のサブシステムが連携する実務レベルのプロジェクトを対象としている。

GSD が解決する問題は明確だ：

  • エージェントは時間とともにコヒーレンスを失う
  • 3タスク前に作ったものを忘れる
  • ファイルは存在するが実際には動かないコードを生成する
  • 毎ターン、プロジェクト構造の再読み込みにトークンを浪費する
  • 中断後の再開には人間が全てを再説明する必要がある
  • 何かが壊れたとき、クリーンなロールバック手段がない

3層の階層構造：Milestone → Slice → Task

GSD はすべてのスコープを3つのレベルに分解する。

Milestone（マイルストーン）

出荷可能なバージョン。プロジェクトの大きな単位。

Slice（スライス）

独立してデモ可能な垂直的な機能単位。「データベース層を実装する」（水平的）ではなく、「ユーザーがサインアップしてログインできる」（垂直的）という形で切る。

各スライスにはデモ文がある：「これが完了すると、ユーザーは _____ できる」。この空白を人間が観察可能な行動で埋められなければ、スコープの切り方が間違っている。

Task（タスク）

コンテキストウィンドウ1つ分の作業単位。1タスクが1エージェントセッションに収まらなければ、それは2タスクだ。これは鉄則であり、違反するとエージェントがコヒーレンスを失い始める — 長時間の作業で初期の判断がコンパクション（圧縮）され、コンテキストが古いツールコールで汚染され、推論品質が劣化する。

Boundary Maps — 実装前のインターフェース思考

GSD で最もインパクトのある計画機能がこれだ。

マイルストーンの計画時に、各スライスは何を生産し、上流のスライスから何を消費するかを具体的に宣言する。曖昧にではなく、関数名・型名・インターフェース・エンドポイントを名前付きで。

S01 → S02
Produces:
  types.ts → User, Session, AuthToken (interfaces)
  auth.ts  → generateToken(), verifyToken(), refreshToken()
Consumes: nothing (leaf node)

S02 → S03
Produces:
  api/auth/login.ts  → POST handler
  middleware.ts       → authMiddleware()
Consumes from S01:
  auth.ts → generateToken(), verifyToken()

これにより「スライス3が必要とする関数をスライス1がエクスポートしていない」という問題が発生しない。契約が明示的で、検証可能になる。

LLM と決定論的コードの分離

GSD のコアとなるアーキテクチャ原則であり、トークン効率と信頼性の両方を担保する設計だ。

ルール：if-else で毎回正しく処理できるなら、LLM の推論ではなく決定論的コードで処理しなければならない。

決定論的コードが担当するもの

  • すべての git 操作（ブランチ、チェックポイント、コミット、スカッシュマージ、ロールバック）
  • すべての状態遷移（次のタスク、タスク完了、スライス完了、前進）
  • ファイルのパースとフォーマット
  • ディレクトリのスキャフォールディング
  • 状態の導出（ディスク上のファイルから現在位置を再構築）
  • コンテキストの組み立て（要約のロード、トークン予算管理、古いコンテキストの削除）
  • 静的検証（ファイル存在、エクスポート、インポート配線、スタブ検出）

LLM が担当するもの

  • スコープをスライスに分解する（アーキテクチャ判断）
  • スライスをタスクに分解する（スコーピング判断）
  • must-have の記述（観察可能な成果の理解）
  • グレーゾーンについてユーザーと議論する（意図の解釈）
  • コードベースの調査（関連性の判断）
  • 検証失敗の診断（仮説推論）
  • 要約の記述（何が起きたか・なぜ重要かの圧縮）
  • 実際のコード記述

2つのツール — gsd_manage（18アクション）と gsd_verify（4アクション）— が決定論的レイヤー全体を公開する。1回のツールコールが、モデルが推論しなければならない5〜10回の bash/read/edit コールを置き換える。

Context Pruning — タスクごとにクリーンなウィンドウ

マルチタスクの信頼性を根本的に変える仕組みだ。

各タスクは会話に不可視のアンカーメッセージが挿入される。LLM コールの前に、コンテキストフックがメッセージ履歴を現在のタスクのアンカーまで刈り込む。

タスク5はタスク1〜4の40回のツールコールを見ない。失敗した試み、中間の読み取り、過去のデバッグを見ない。クリーンなコンテキストウィンドウに、タスク計画と関連する上流の要約だけが入る。

なぜこれが重要か — コンテキスト腐敗

これがなければコンテキスト腐敗（context rot）が起きる。タスク3〜4あたりで、コンテキストウィンドウは以前のタスクからの陳腐なツール出力で飽和する：

  • 4タスク前に読んだが、その後リファクタリングされたファイル内容
  • すでに修正された問題のデバッグトレース
  • もはや関連しないビルド・テストの出力

モデルは何が最新で何が陳腐かを区別できない。リネームされた変数を参照し、再構築されたコードのパターンに従い、もはや当てはまらない理由で以前試したアプローチを避ける。

アンカープルーニングはコンテキスト腐敗を完全に排除する。 タスク7はタスク1と同じコンテキスト品質で実行される。

Context Injection — ゼロディスカバリーコール

タスク開始前に、システムがエージェントに必要なすべてを事前組み立てする：

  • タスク計画（目標、ステップ、must-have）
  • 依存スライスの圧縮要約
  • マイルストーンレベルのコンテキストと意思決定
  • 中断作業の再開データ

エージェントは grep でプロジェクト構造を探したり、状態ファイルを read して現在位置を把握したりする必要がない。もしそうしているなら、コンテキスト組み立てが壊れている — それはバグだ。

Fractal Summaries — スケールする記憶

タスク完了時にエージェントが構造化された要約を書く。スライス完了時にタスク要約がスライス要約に圧縮される。さらにマイルストーン要約へと圧縮される。

スライス6を計画するとき、スライス1〜5の15個のタスク要約は読み込まない。1つのマイルストーン要約 — おそらく200行 — が、何が構築され、何が利用可能で、どのパターンに従うべきかの本質的な情報を含む。

重要なルール：要約の要約は作らない。 各レベルの要約は、下位レベルの要約＋実際のコード状態から再生成する。圧縮されたテキストをさらに圧縮すると情報が累積的に失われるためだ。

Verification — ゴールから逆算する検証

「全ステップ完了」は検証ではない。実際の成果を確認することが検証だ。

各タスクは must-have を定義する：

  • Truths（真実）: 真でなければならない振る舞い — 「ユーザーがメールとパスワードでサインアップできる」
  • Artifacts（成果物）: 実装を伴って存在しなければならないファイル — src/lib/auth.ts、最低30行、generateToken と verifyToken をエクスポート
  • Key Links（接続）: 成果物間の配線 — login/route.ts が auth.ts から generateToken をインポートしている

静的検証はこれらを決定論的にチェックする。スタブ検出器は TODO コメント、FIXME マーカー、return null、return {}、console.log プレースホルダーを検出する。

さらに4段階の検証ラダーがある：

  1. Static — ファイル存在、エクスポート、配線、スタブなし
  2. Command — テスト合格、ビルド成功、lint クリーン
  3. Behavioral — ブラウザフロー、API レスポンスが正しい
  4. Human — エージェントが自分で検証できない場合のみ

Discuss Phase — 実行前のアラインメント

ほとんどの AI コーディングエージェントの問題：「認証を作って」と言うと即座にコーディングを始め、最初の5分で30の意思決定をする。セッションストレージ vs JWT、メール認証の有無、OAuth vs パスワード、リダイレクト動作… 完成結果を見るまで、どの選択がなされたか分からない。

GSD は議論をファーストクラスのフェーズにする。計画開始前に、エージェントがスコープを読み、グレーゾーン（複数の合理的なアプローチが存在し、ユーザーの好みが重要な箇所）を特定し、具体的な質問を投げかける。

出力は context.md ファイル — すべての意思決定とその理由の構造化された記録。このファイルはすべての下流作業（計画、実行、検証）に注入される。10分の会話でアラインメントを前倒しすれば、それ以降のすべてのタスクがその意思決定を自動的に継承する。

Git 戦略 — スライスごとのブランチとスカッシュマージ

各スライスは独自の git ブランチを持つ。ブランチ上で各タスクがチェックポイントコミットを得て、検証後に正式コミットされる。スライス完了時にスカッシュマージで main に1つのクリーンなコミットとして統合される。

feat(M001/S06): verification + summarization + UAT
feat(M001/S05): task execution + context pruning
feat(M001/S04): milestone and slice planning commands
feat(M001/S03): extension scaffold and command routing
feat(M001/S02): state machine + deterministic operations
feat(M001/S01): types + file I/O + git operations

ロールバックは単純明快：

  • 悪いタスク → ブランチ上のチェックポイントに git reset
  • 悪いスライス → main 上の1つのスカッシュコミットをリバート
  • マージ後の UAT 失敗 → -fix ブランチで修正タスク

Continue-Here — 中断の生存

コンテキストウィンドウは終わる。セッションはタイムアウトする。ユーザーは Ctrl+C を押す。GSD はすべて処理する。

タスクが中断されると、continue ファイルが書き出される：

  • 完了済みの内容
  • 残作業
  • タスク中に行われた意思決定（次のセッションで再議論しないため）
  • 何が厄介で、何に注意すべきか
  • 再開時の最初のアクション

新しいセッションがこのファイルを読み、タスク計画をロードし、中断箇所からピックアップする。

UAT — 自動的な受け入れテストドキュメント

スライス完了時に、GSD はユーザー受け入れテストスクリプトを自動生成する。実装の詳細ではなく、人間が観察できる内容：

Test: Sign up flow
Do:
  Open http://localhost:3000/signup
  Enter "test@example.com" in the Email field
  Enter "password123" in the Password field
  Click "Sign Up"
Expected:
  Page redirects to http://localhost:3000/dashboard
  Header shows "Welcome, test@example.com"
  Refreshing the page keeps you logged in

すべてのステップがコピー＆ペースト可能なコマンドまたは具体的な UI アクション。すべての期待結果が具体的なテキスト、URL、振る舞いを記述する。

UAT はノンブロッキング — エージェントはテストスクリプトを書いたら即座に次のスライスに進む。テストはいつでも都合の良いタイミングで実行できる。

なぜ GSD は機能するのか

根本的な洞察：AI コーディングエージェントの信頼性を損なうのは、モデルのコード生成ではなく、その周辺のすべてだ。状態管理、コンテキスト汚染、継続性の喪失、git 操作の機械的エラー、プロセスではなく成果をチェックしない検証、圧縮を重ねて情報を失う要約。

GSD はこれらすべてを決定論的にする。モデルはコードを書き、判断を下す。それ以外 — 状態遷移、ファイル管理、git 操作、コンテキスト組み立て、静的検証 — は正しく動くかクリアなエラーを投げる TypeScript が処理する。

すべてはディスク上のマークダウンファイルで管理される。データベースなし。外部サービスなし。ファイルと git だけだ。

Claude Code での実践的な使い方

GSD は Claude Code のスラッシュコマンド拡張として提供されており、npx 一発でインストールできる。

インストール

1
2
3
4
5
6
7
8

# インタラクティブインストール（推奨）
npx get-shit-done-cc@latest

# Claude Code グローバルインストール
npx get-shit-done-cc --claude --global

# プロジェクト単位のインストール
npx get-shit-done-cc --claude --local

インストール後、/gsd:help でコマンド一覧を確認できる。

推奨設定

GSD はサブエージェントの自動起動やgit操作を多用するため、パーミッション確認を省略するモードが推奨されている：

1

claude --dangerously-skip-permissions

毎回確認ダイアログを承認する手間を省くための設定だ。細かく制御したい場合は .claude/settings.json で個別のコマンドを許可リストに追加することもできる。

基本ワークフロー：5つのステップ

GSD の実際の使い方は、以下の5ステップのループだ：

Step 1: プロジェクト初期化

/gsd:new-project

システムが対話形式で質問し、以下のファイルを生成する：

  • PROJECT.md — プロジェクトのビジョン（常にコンテキストにロードされる）
  • REQUIREMENTS.md — v1/v2/スコープ外に分類された要件
  • ROADMAP.md — フェーズに分割されたロードマップ
  • STATE.md — 意思決定・ブロッカー・進捗状態（セッション間の記憶）
  • .planning/research/ — ドメイン調査結果

既存のコードベースがある場合は、先に /gsd:map-codebase を実行すると、スタック・アーキテクチャ・規約を自動分析してくれる。

Step 2: フェーズの議論

/gsd:discuss-phase 1

ロードマップの1〜2行の説明だけでは、ユーザーが何を求めているか分からない。このステップでグレーゾーンを洗い出す：

  • 視覚的な機能 → レイアウト、密度、インタラクション、空状態
  • API/CLI → レスポンス形式、フラグ、エラーハンドリング
  • コンテンツ系 → 構造、トーン、深さ、フロー

出力される CONTEXT.md が、以降のリサーチと計画に反映される。ここを丁寧にやるほど、実装が自分のビジョンに近づく。

Step 3: フェーズの計画

/gsd:plan-phase 1

システムが以下を自動実行する：

  1. リサーチ — CONTEXT.md の決定を踏まえて実装方法を調査
  2. 計画 — 2〜3個のアトミックなタスク計画を XML 構造で作成
  3. 検証 — 計画が要件を満たしているかチェックし、不合格なら修正ループ

各計画はフレッシュなコンテキストウィンドウで実行できるサイズに制限される。

Step 4: フェーズの実行

/gsd:execute-phase 1

ここが GSD の真骨頂だ：

  • Wave 実行 — 依存関係のない計画はパラレルに、依存するものはシーケンシャルに実行
  • フレッシュコンテキスト — 各計画が200Kトークンの新しいコンテキストウィンドウで実行される
  • アトミックコミット — タスクごとに独立したgitコミットが作られる
  • 自動検証 — フェーズが約束した成果物が実際に存在するかチェック

メインのコンテキストウィンドウは30〜40%に留まり、セッションは快適なまま。

Step 5: 検証

/gsd:verify-work 1

自動検証とは別に、人間が実際に触って確認するステップ：

  • テスト可能な成果物を1つずつ提示される
  • 「ログインできる？」→ Yes/No、または問題を説明
  • 失敗した場合はデバッグエージェントが自動で原因を調査
  • 修正計画が生成され、/gsd:execute-phase で再実行するだけ

フェーズを繰り返してマイルストーンを完了

/gsd:discuss-phase 2
/gsd:plan-phase 2
/gsd:execute-phase 2
/gsd:verify-work 2
...
/gsd:complete-milestone    # マイルストーン完了、リリースタグ作成
/gsd:new-milestone         # 次のバージョンへ

便利なコマンド

コマンド用途
/gsd:quickバグ修正や小さな機能追加など、フル計画が不要なタスク
/gsd:progress現在の進捗と次のアクションを確認
/gsd:pause-work作業中断時にハンドオフ情報を保存
/gsd:resume-work前回のセッションから復帰
/gsd:add-phaseロードマップにフェーズを追加
/gsd:insert-phase N緊急の作業をフェーズ間に挿入
/gsd:debug永続的な状態を持つ体系的デバッグ
/gsd:add-todoアイデアを後で対応するメモとして記録

モデルプロファイル

エージェントごとに使用するモデルを切り替えて、品質とコストのバランスを調整できる：

プロファイル計画実行検証
qualityOpusOpusSonnet
balanced（デフォルト）OpusSonnetSonnet
budgetSonnetSonnetHaiku
/gsd:set-profile budget

GSD が向いているケース・向いていないケース

向いている：

  • 複数セッションにまたがる大きなプロジェクト（認証システム、管理画面、API一式など）
  • 1回のコンテキストウィンドウで収まらないスコープ
  • 中断・再開が頻繁に発生する開発

向いていない：

  • 単発のバグ修正（/gsd:quick で対応可能）
  • 1セッションで完結する小さなタスク
  • GSD のオーバーヘッド（ファイル生成、サブエージェント起動）が見合わない場合

まとめ

GSD は、AI コーディングエージェントの「コンテキストウィンドウの壁」を構造的に突破するシステムだ。3層の階層分解、インターフェース契約の事前宣言、LLM と決定論的コードの明確な分離、タスクごとのコンテキストプルーニング、フラクタル要約、ゴール逆算型の検証 — これらの仕組みが組み合わさることで、タスク7もタスク1と同じ品質で実行される。

Claude Code ユーザーなら npx get-shit-done-cc@latest でインストールし、/gsd:new-project から始められる。「AI にコードを書かせる」フェーズから「AI でプロジェクトを完遂する」フェーズへの移行を考えるなら、試す価値がある。