GSD(Get Shit Done)完全ガイド：AIコーディングの"コンテキスト劣化"を克服し、大規模開発を自動化する

はじめに

海外で急速に人気を集めているこのフレームワークを、本記事で詳しく紹介させていただきます。

GSD (Get Shit Done) — Claude Code / OpenCode / Gemini CLI / Cursor / Codex / Copilot など主要なAIコーディングランタイム向けのコンテキスト・エンジニアリング・フレームワーク

⭐ 51.3k Stars | 🍴 4.3k Forks | 👀 228 Watching（2026年4月時点）

GitHub: https://github.com/gsd-build/get-shit-done

2025年から2026年にかけて、Claude Code、Cursor、Windsurf といったAI駆動開発ツールが急速に普及しています。「自然言語で指示するだけでコードが生成される」という体験は、多くの開発者にとって革命的でした。

しかし、実際に大規模な開発を進めていくと、ある壁にぶつかります。

「最初は完璧だったのに、開発が進むにつれてAIが指示を忘れるようになった」
「途中からコードの品質が明らかに落ちてきた」
「同じ説明を何度もしなければならなくなった」

この現象には名前があります。コンテキスト劣化（Context Rot） です。

本記事では、このコンテキスト劣化問題を根本から解決するフレームワーク 「GSD（Get Shit Done）」 を徹底解説します。GSDの仕組みから実践的な使い方まで、ユースケース別に詳しく見ていきましょう。

---

第1章：GSDとは何か

コンテキスト劣化（Context Rot）問題

Claude CodeなどのAIコーディングツールは、「コンテキストウィンドウ」と呼ばれる記憶領域を持っています。会話の履歴、読み込んだファイル、生成したコード——これらすべてがコンテキストに蓄積されていきます。

問題は、このコンテキストが埋まるにつれて、AIの振る舞いが変化することです。

症状	具体例
指示の忘却	前に決めた設計ルール（「エラーは必ずカスタム例外クラスで」）を無視し始める
品質の低下	コードが簡略化され、エッジケースの処理が省略される
完了モード	深く考えることをやめ、とにかくタスクを終わらせることだけに集中する

これは「AIが悪い」のではなく、アーキテクチャ上の制約 です。コンテキストウィンドウが50%を超えたあたりから、出力品質は顕著に劣化し始めます。

GSDの解決アプローチ

GSD（Get Shit Done）は、この問題を根本から解決するために設計されたフレームワークです。

核心となる考え方は2つです：

1. タスクの極小化 — 大きな仕事を、1つのコンテキストに収まる小さなタスクに分割する
2. クリーンなコンテキストでの実行 — 各タスクを新鮮な（汚染されていない）コンテキストで実行する

具体的には、GSDは「オーケストレーター」として機能し、複数の「サブエージェント」を起動・調整します。各サブエージェントは専用のクリーンなコンテキスト（200kトークン）を持ち、自分の担当タスクに集中します。

この設計により、どれだけ大規模なプロジェクトでも、各タスクは常に最高品質で実行される ことが保証されます。

---

第2章：GSDのアーキテクチャ

コンテキスト・エンジニアリング

GSDの品質維持の秘密は、構造化されたドキュメント群 にあります。各ワークフローステージに必要な情報だけを、最適化されたサイズで供給します。

ファイル	役割	内容
PROJECT.md	ビジョンとスコープ	プロジェクトの目的、制約、成功基準
REQUIREMENTS.md	要件定義	v1/v2で実現する機能一覧
ROADMAP.md	フェーズ分割	実装を段階的に分割した計画
STATE.md	状態管理	決定事項、ブロッカー、セッション記憶
PLAN.md	実行計画	XML構造化されたアトミックタスク
CONTEXT.md	設計ルール	UIの方針、エラー処理等の「絶対ルール」

これらのファイルは、Claudeの品質劣化曲線に最適化されたサイズ制限の下で管理されます。

マルチエージェント・オーケストレーション

GSDのワークフローは4つのステージで構成されます：

1. リサーチステージ
4つの並列リサーチエージェントが、異なる観点から調査を行います：

• stack — 技術スタックの選定と落とし穴
• features — 必要な機能群の洗い出し
• architecture — アーキテクチャ設計のパターン
• pitfalls — 実装上の典型的な落とし穴

なお、セキュリティ監査やUI関連のリサーチは別系統のエージェント（gsd-security-auditor、gsd-ui-researcher など）が担当します。

2. プランニングステージ
プランナーエージェントがタスクを作成し、チェッカーエージェントが検証。全てのチェックを通過するまでループします。

3. 実行ステージ
並列実行エージェントが、それぞれ新鮮な約200kトークンのコンテキストで実装を行います（GSD公式ドキュメントが掲げる設計目標値）。

4. 検証ステージ
検証エージェントがコードベース全体を目標と照合。問題があればデバッグエージェントが診断します。

結果： フルフェーズ（リサーチ、プランニング、数千行のコーディング、検証）を実行しても、メインコンテキストは30〜40%程度に維持されるとされています（GSD公式README記載の設計目標）。

XMLによる曖昧さの排除

GSDのプランは、XMLフォーマットで構造化されます。これにより、AIが「なんとなく」解釈する余地を排除します。

<task type="auto">
  <name>ログインエンドポイント作成</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>joseでJWT生成、認証情報を検証し、httpOnlyクッキーを返却</action>
  <verify>curl -X POST localhost:3000/api/auth/login で200+Set-Cookieが返る</verify>
  <done>有効な認証情報でクッキー返却、無効なら401</done>
</task>

各タスクには以下が明確に定義されます：

• name: 何をするか
• files: どのファイルを触るか
• action: 具体的な実装内容
• verify: 完了確認の方法
• done: 完了の定義

アトミック・コミットによる履歴管理

GSDは、完了したタスクごとに自動でGitコミットを行います。

abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
klm012n test(08-02): add auth integration tests

この設計には3つのメリットがあります：

1. デバッグの容易性 — git bisect で問題のあるコミットを特定できる
2. 独立したロールバック — 特定の機能だけを安全に取り消せる
3. 履歴の明確化 — 将来のセッションで「何がいつ実装されたか」が一目瞭然

---

第3章：インストールと初期設定

インストール方法

GSDのインストールは1コマンドで完了します：

npx get-shit-done-cc

インストーラーが以下を対話的に確認します：

選択項目	オプション
ランタイム	Claude Code / OpenCode / Gemini CLI / すべて
スコープ	グローバル / プロジェクトローカル

対応OS: Mac / Windows / Linux

非対話モードでのインストールも可能です：

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

# 全ランタイムにローカルインストール
npx get-shit-done-cc --all --local

初期設定

設定は .planning/config.json で管理されます：

設定項目	選択肢	デフォルト	用途
mode	yolo / interactive	interactive	自動承認 or 都度確認
granularity	coarse / standard / fine	standard	フェーズの粒度（フェーズ × プラン数の細かさ）

運用Tips

1. --dangerously-skip-permissions の活用

頻繁な承認プロンプトをスキップし、AIの自動実行を止めないようにします。信頼できる環境での開発効率が大幅に向上します。

claude --dangerously-skip-permissions

2. /clear の実行

新しいフェーズや実行に入る前にチャット履歴を消去することで、AIの注意力を最大化します。GSDのドキュメント群が文脈を引き継ぐため、情報は失われません。

3. モデルプロファイルの切り替え

/gsd-set-profile budget   # コスト優先（Haiku使用）
/gsd-set-profile balanced # バランス型
/gsd-set-profile quality  # 品質優先（Opus使用）

タスクの重要度に応じてプロファイルを使い分けることで、トークン消費を最適化できます。

---

第4章：主要コマンド一覧

コアワークフロー

コマンド	内容
/gsd-new-project	プロジェクトの新規立ち上げ。ヒアリング→リサーチ→要件定義→ロードマップ生成
/gsd-discuss-phase [N]	フェーズNの実装方針を対話で確定（CONTEXT.md生成）
/gsd-plan-phase [N]	フェーズNの設計とリサーチ、アトミックなプラン作成
/gsd-execute-phase <N>	フェーズNのコード自動生成と並列実行（内部で検証エージェントが VERIFICATION.md を生成し、ゴールバックワード検証も実施）
/gsd-verify-work [N]	実装後の対話型ユーザー受け入れテスト（UAT）。手順をガイドし結果を UAT.md に記録

既存コード対応

コマンド	内容
/gsd-map-codebase	既存コードの解析（技術スタック、アーキテクチャ、規約を理解）
/gsd-new-milestone	新しい開発目標の設定（機能追加等）
/gsd-audit-milestone	マイルストーン完了前の達成度確認
/gsd-complete-milestone	マイルストーンのアーカイブとタグ付け

ユーティリティ

コマンド	内容
/gsd-quick	軽量版GSD。planner と executor で計画を作りつつ、研究や追加検証を省略
/gsd-fast <text>	計画プロセスを完全にスキップし、些末なタスクを即座に実行
/gsd-debug [説明]	体系的なデバッグセッション開始
/gsd-progress	現在の進捗状況を表示
/gsd-pause-work	作業の中断（引き継ぎ書を自動作成）
/gsd-resume-work	中断した作業の再開

フェーズ管理

コマンド	内容
/gsd-add-phase	ロードマップ末尾にフェーズ追加
/gsd-insert-phase	既存フェーズ間に緊急作業を挿入（例: 72.1）
/gsd-remove-phase	フェーズを削除し後続を再番号付け

---

第5章：ユースケース別 実践ガイド

5-1. 新規Webサービスの立ち上げ

シナリオ: SaaS型のタスク管理アプリを一人で開発する

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

/gsd-new-project

GSDがあなたのアイデアを深掘りする質問を繰り返します：

「ターゲットユーザーは誰ですか？」
「競合との差別化ポイントは？」
「初期リリースに必須の機能は？」

アイデアが具体化されると、4つの並列リサーチエージェントが起動します：

• stack — 技術スタックの選定と落とし穴調査
• features — 必要な機能群の整理
• architecture — アーキテクチャパターンの分析
• pitfalls — 実装時に陥りがちな罠の洗い出し

調査結果を基に、ROADMAP.md にフェーズ分割された実装計画が生成されます。

Step 2: コンテキスト・エンジニアリング

/gsd-discuss-phase 1

最初のフェーズ（例：認証基盤とUI骨格）について、AIが確認を求めてきます：

「UIの密度は高め？それともゆとりのあるデザイン？」
「エラーメッセージは技術的？それともユーザーフレンドリー？」
「ダークモードは初期対応する？」

ここでの決定は CONTEXT.md に記録され、後続のすべての工程で「絶対ルール」として機能します。AIが勝手に判断を変えることはありません。

Step 3: 原子的プランニング

/gsd-plan-phase 1

GSDは「50%ルール」を適用します——コンテキスト使用量が50%を超えないよう、1つのフェーズをさらに小さなプランに分割します。

各プランの依存関係を解析し、並列実行可能なウェーブを構築します：

Step 4: 並列実行

/gsd-execute-phase 1

実行モードを選択します：

• Sequential（順次実行）: 1つずつ確実に。途中で止まっても成果は保存される
• Parallel（並列実行）: 依存関係のないタスクを同時実行。スピード優先

各プランは新鮮な約200kトークンのコンテキストで実行されます（GSD公式の設計目標値）。タスクが完了するたびに自動でGitコミットが行われ、クリーンな開発履歴が残ります。

なお、/gsd-execute-phase の内部では検証エージェントが VERIFICATION.md を生成し、コードレベルでゴールバックワード検証も行われます。

Step 5: ユーザー受け入れテスト（UAT）

/gsd-verify-work

/gsd-verify-work は対話型のユーザー受け入れテスト（UAT）を担当するコマンドです。実際に動かして確認するための手順をAIがガイドし、結果は UAT.md に記録されます。

ポイント: 「曖昧なアイデア → 動くプロダクト」までの一気通貫フローが完成します。

---

5-2. 既存コードへの機能追加（Brownfield）

シナリオ: Next.js + Prisma で構築済みのECサイトに通知機能を追加する

Step 1: 既存コードの解析

/gsd-map-codebase

GSD mapperが並列で複数のエージェントを起動し、既存プロジェクトを徹底分析します：

• 技術スタック: Next.js 14, Prisma, PostgreSQL, Tailwind CSS...
• アーキテクチャ: App Router, Server Actions, レイヤード構造...
• コーディング規約: 命名規則、ディレクトリ構成、エラーハンドリングパターン...
• 懸念事項: 古い依存関係、潜在的なセキュリティリスク...

分析結果は .planning/codebase/ フォルダに構造化ドキュメントとして保存されます。これにより、AIは「このプロジェクトのルール」を理解した状態で作業を開始できます。

Step 2: 新しい開発目標の設定

/gsd-new-milestone

「通知機能を追加する」という目標を定義します。GSDは既存アーキテクチャとの整合性を考慮しながら、ロードマップを生成します：

## Milestone: 通知機能の追加

### Phase 1: 通知基盤
- 通知テーブルのスキーマ設計
- 通知サービスの実装

### Phase 2: リアルタイム配信
- WebSocket接続の実装
- プッシュ通知の統合

### Phase 3: UI/UX
- 通知ベルアイコン
- 通知一覧ドロワー
- 既読管理

Step 3: 計画→実行→検証のサイクル

通常のワークフロー（discuss → plan → execute → verify）を各フェーズで繰り返します。

重要なのは、すべてのプランが既存のコード規約に従って作成されることです。例えば：

• 既存の命名規則（camelCase vs snake_case）を遵守
• 既存のエラーハンドリングパターンを踏襲
• 既存のディレクトリ構成に従った配置

ポイント: 「既存コードを壊さない」ための事前マッピングが、一貫性のある機能追加を可能にします。

---

5-3. 管理画面の自動構築（デモ再現）

シナリオ: 解説動画で紹介された管理ダッシュボードを構築する

完成する機能群

このデモでは、以下の機能を備えた管理画面がほぼ全自動で構築されます：

機能	詳細
ユーザー管理	検索、ティア（無料/有料）によるフィルタリング
クレジット管理	特定ユーザーのクレジットを直接調整し、理由をログに残す
監査ログ（Audit Logs）	誰がいつ何を変更したかをすべて記録
アナリティクス	ユーザー数やクレジット使用状況の統計を可視化

GSDが自動で行ったこと

1. 多角的リサーチ

「管理画面を作りたい」というラフな指示から、サブエージェントが以下を同時に調査：

• 技術スタックと既存実装のパターン（stack）
• 必要な機能要件（features）
• アーキテクチャ上の整合性（architecture）
• 実装時のリスクや欠落（pitfalls）

セキュリティ監査やUI設計レビューが必要な場合は、gsd-security-auditor や gsd-ui-researcher などの専門エージェントが別途呼び出されます。

2. ギャップの自動発見

リサーチの結果、元の指示にはなかった技術的欠陥が発見されました：

• 「管理者用ミドルウェアがない」
• 「クッキーの設定が不足している」
• 「監査ログ用のテーブルがない」

これらは自動で修正プランに組み込まれます。

3. 状態管理の自動実装

ページをリロードせずにクレジット調整をUIに即座に反映させるため、Zustandを用いた状態管理も自動で実装されました。開発者が指示していない実装詳細を、AIが適切に判断しています。

4. アトミックコミット

各機能は独立したコミットとして記録されます：

feat(admin): add user search and filtering
feat(admin): implement credit adjustment with audit log
feat(admin): add analytics dashboard

ポイント: 「ラフな指示」から「技術的欠陥の自動発見・修正」まで、AIがリードエンジニアのように自律的に開発を進めます。

---

5-4. 難解なバグの解決（Debug Mode）

シナリオ: 「APIが時々500エラーを返す」という再現困難なバグ

Step 1: デバッグセッション開始

/gsd-debug "APIが時々500エラーを返す"

専門のデバッグエージェントが起動します。通常のチャットと異なり、状態が永続化されるため、コンテキストリセット後も調査を継続できます。

Step 2: 自律的な調査プロセス

デバッグエージェントは科学的手法でバグに向き合います：

観察フェーズ

• エラーログの収集と分析
• 発生パターンの特定（時間帯、リクエスト種別、ユーザー属性）

仮説構築フェーズ

• 「データベース接続プールの枯渇」
• 「特定の入力値による未処理例外」
• 「並行リクエストによる競合状態」

検証フェーズ

• 各仮説を検証するためのログ追加やテストコードを提案
• 再現手順の特定

根本原因の特定

• 検証結果を基に、真の原因を特定

Step 3: 修正プランの作成と実行

原因が特定されると、修正プランが自動生成されます。アトミックコミットで修正が適用され、同じバグの再発を防ぐためのテストも追加されます。

ポイント: 「なんとなく直った」ではなく、根本原因を特定し、再発を防ぐ体系的アプローチ。

---

5-5. ちょっとした修正（Quick / Fast Mode）

シナリオ: 「ボタンの色をすべてブランドカラーに変えて」

フルワークフロー（discuss → plan → execute → verify）が不要な小規模修正には、軽量モードを使います：

/gsd-quick "全てのボタンをブランドカラー #3B82F6 に統一"

/gsd-quick の特徴：

• planner と executor を使い、PLAN.md と SUMMARY.md を生成する軽量版GSD
• リサーチ・plan-checker・verifier はデフォルトで省略
• --full で全工程有効化、--validate で plan-checker と verifier を追加
• GSDのアトミックコミットルールは適用される

さらに軽量に、計画自体も省いて即座に実行したい場合は /gsd-fast を使います：

/gsd-fast "ヘッダーのロゴを差し替える"

適したケース：

• CSSの調整
• テキストの修正
• 単純なバグ修正
• 小さなリファクタリング

ポイント: フルワークフローのオーバーヘッドなしに、GSDの品質保証を受けられる軽量オプション。

---

第6章：なぜGSDは機能するのか

従来のSDDとの違い

「Spec-Driven Development（仕様駆動開発）」フレームワークは以前から存在していました。BMAメソッド、SpecKitsなどがその例です。

しかし、これらには共通の限界がありました：

1. すべての作業を1つのコンテキストで行おうとする — 計画、実装、検証を同一セッション内で実行するため、コンテキストが肥大化していく
2. 手動でのコンテキスト管理が必要 — /compact や /clear コマンドで定期的にコンテキストを整理しないと品質が維持できない。しかし、いつ実行すべきか、何を残すべきかの判断は開発者に委ねられていた

結果として、トークン消費が増えるほどAIの精度が低下する「コンテキストスワンプ（泥沼）」現象が発生していました。あるいは、手動でコンテキストを整理する作業に時間を取られ、開発のリズムが崩れるという問題もありました。

GSDの革新は、コンテキスト管理をアーキテクチャレベルで解決したことです：

従来のSDD	GSD
1つの巨大コンテキスト	タスクごとの新鮮なコンテキスト
計画・実装・検証を同一セッション	各ステージを専門エージェントに分離
コンテキストが汚染されていく	常にクリーンな状態を維持

品質維持のメカニズム

GSDが一貫した品質を維持できる理由は、以下の3つのメカニズムにあります：

1. ドキュメント・ファースト

決定は実装前に捕捉されます。CONTEXT.md に記録されたルールは、どのサブエージェントからも参照され、「AIが勝手に判断を変える」ことを防ぎます。

2. リサーチ→プランニング→実行の分離

リサーチ結果はプランニングに流れ込み、プランは実行に渡されます。各ステージは前のステージの成果物を「入力」として受け取るため、情報の欠落がありません。

3. プランの原子性と検証可能性

各プランは十分に小さく、完了条件が明確に定義されています。曖昧さがないため、AIは「なんとなく」ではなく「確実に」タスクを完了できます。

ターゲットユーザー像

GSDは以下のような開発者のために設計されています：

「50人のエンジニア組織のふりをせずに、やりたいことを説明して正しく作ってほしい」

• ソロ開発者、個人開発者
• 小規模チーム（1-5人）
• サイドプロジェクトを効率的に進めたいエンジニア
• AIコーディングの可能性を最大限に引き出したい開発者

---

第7章：GSD vs Superpowers — 2つのフレームワークの比較

AIコーディングの品質を高めるフレームワークとして、GSDの他に Superpowers も注目を集めています。両者は異なるアプローチで同じ課題に取り組んでおり、理解しておくと選択の助けになります。

比較表

観点	GSD	Superpowers
主な焦点	コンテキスト劣化の防止、大規模開発の自動化	開発方法論の徹底とサブエージェント駆動の実装
アプローチ	タスクを極小化し、サブエージェントに分散	スキルベースのワークフロー誘導 + サブエージェント実行
アーキテクチャ	オーケストレーター + 専門エージェント群	モジュラーなスキルシステム（TDD、並列エージェント、git worktree など）
強み	プロジェクト全体のオーケストレーション、並列実行	TDD、コードレビュー、サブエージェント駆動開発、worktree運用
ドキュメント	PROJECT.md, ROADMAP.md, PLAN.md, CONTEXT.md	仕様、設計ドキュメント、実装計画
哲学	「AIをリードエンジニアに」	「方法論を徹底してAIの品質を上げる」
インストール	npx get-shit-done-cc	プラットフォームごとに異なる（Claude公式マーケットプレイス、Cursor、Codex、OpenCode、Copilot、Gemini など）

それぞれの得意領域

GSDが得意なこと：

• ゼロからの大規模プロジェクト立ち上げ
• 長時間にわたる開発セッション
• 複数フェーズに分割された計画的な開発
• 既存コードベースへの機能追加

Superpowersが得意なこと：

• テスト駆動開発（RED-GREEN-REFACTOR）の徹底
• サブエージェント駆動開発と並列エージェントのディスパッチ
• git worktree を使った安全な並行作業
• コードレビューワークフローと設計段階のブレインストーミング

連携の可能性

両者は補完関係にあります：

• GSD = 「何を・どう分割するか」のオーケストレーション層
• Superpowers = 「どう作るか」の方法論・品質層

理論的には、GSDでプロジェクト全体を管理しつつ、各タスクの実行時にSuperpowersのTDDスキルを活用する、という併用が可能です。

併用の例：

1. /gsd-new-project でプロジェクトを初期化し、ロードマップを作成
2. /gsd-plan-phase 1 で最初のフェーズを計画
3. 各タスクの実装時に、Superpowersのtest-driven-developmentスキルを適用
4. /gsd-verify-work で全体の検証

両方をインストールしている環境では、GSDの大局的な管理とSuperpowersの方法論的な厳密さを組み合わせることで、より高品質な開発が期待できます。

---

第8章：まとめ

GSDが実現すること

GSDは、AIを「単なるコード書き」から**「仕様を理解し、問題を自ら発見し、整合性を保ちながら自律的に開発を進めるリードエンジニア」**に変えるフレームワークです。

解決する課題：

• コンテキスト劣化による品質低下
• 長時間セッションでの指示忘れ
• 大規模開発での一貫性維持

実現するワークフロー：

• 曖昧なアイデアから動くプロダクトへ
• 既存コードを壊さない機能追加
• 体系的なデバッグと品質保証

今日から始める

npx get-shit-done-cc

このコマンド1つで、あなたのAI駆動開発は次のレベルへ進みます。

---

参考リンク

• GitHub: https://github.com/gsd-build/get-shit-done
• 解説動画: https://www.youtube.com/watch?v=l94A53kIUB0
• Superpowers: https://github.com/obra/superpowers

---

著者注: 本記事は2026年1月時点の情報に基づいています。GSDは活発に開発が進んでいるプロジェクトのため、最新の機能やコマンドについては公式リポジトリをご確認ください。