GSD (Get Shit Done) 徹底解説

はじめに

Ralph Wiggum 徹底解説では、ある核心的な問題を探りました：Context Rot — 会話が長くなるにつれて、Claude のコンテキストウィンドウが失敗したコード、古くなった議論、無関係な情報で埋まり、出力品質が着実に低下していく現象です。

Ralph の解決策は「すべてをリスタートする」というものでした：bash の無限ループで毎回新しい Claude インスタンスを起動し、ファイルシステムを通じて状態を受け渡します。シンプルで効果的ですが、明確な限界もあります — それは単なる手法であり、プロジェクトの理解もフェーズ計画も品質検証もありません。スペックは自分で書き、タスクは自分で編成し、「完了したかどうか」も自分で判断する必要があります。

Chase AI が動画で的確にまとめたように：Ralph Loop は極めて強力な武器ですが、ほとんどの人に必要なのは一つの武器ではなく、武器庫全体です。 Ralph ループは完全に事前準備に依存しています：PRD は十分に良いですか？機能定義は十分にタイトですか？「完了」がどのようなものか分かっていますか？これらの質問への回答が正確でなければ、ループを何回実行しても、garbage in, garbage out になるだけです。

もし、Claude を単にループさせるのではなく、あなたのプロジェクトを本当に理解し、確実にコードを届けてくれるシステムがあったら？

それが GSD (Get Shit Done) の目指すところです。

GSD とは

GSD の作成者は TÂCHES（GitHub: glittercowboy）という独立開発者です。彼のモチベーションは非常にシンプルでした：

「私は50人規模のソフトウェア会社ではない。エンタープライズシアターをやりたくない。ただクールなものを作りたいクリエイターなんだ。」

ライブ配信で、TÂCHES は衝撃的な事実を実演しました：彼は一切コードを手書きしません。GSD を使って、4時間でゼロから完全な macOS ネイティブ AI 音楽生成アプリ（Sample Digger）を構築しました — 手書きコードはゼロです。彼は自分をプログラマーではなく「ハイレベルなプロジェクトマネージャー」と位置づけています — ビジョンを描き、重要な判断を下し、結果を検証する。GSD がこのような働き方を可能にしています。

"This has like 100x'd my ability to make cool shit with Claude Code because it's just created this systematization."

—— TÂCHES

他のスペック駆動開発ツール — BMAD、SpecKit — にはそれぞれの価値がありますが、複雑なエンタープライズワークフローを導入しがちです：スプリントセレモニー、ストーリーポイント、ステークホルダーシンク。ソロ開発者や小規模チームにとって、これらのプロセス自体が負担になります。Chase AI が述べたように：「It's not enterprise theater. We understand that you're just one person, you just want some sort of scaffolding around Claude Code to make sure it executes the tasks it says it's going to execute in an effective way.」

GSD の設計哲学は複雑性をシステムの中に隠すことです。ユーザーは数個のシンプルなコマンドだけで、システムが裏側でコンテキスト管理、タスクオーケストレーション、品質検証のすべてを処理します。リリースから1ヶ月以内に、プロジェクトは約3,000の GitHub スターと14,000の npm インストールを獲得し、TÂCHES はほぼ毎日15〜20回のアップデートをプッシュしています。

ツールエコシステムにおける GSD の位置づけ

この表は重要なトレードオフを示しています：Ralph は最小限のシステム複雑性と引き換えに最大の実行自律性を得ています — 起動したら寝てしまえます。一方、GSD は高いシステム複雑性と引き換えに計画品質と人間による監督を得ています — 各ステージで介入する機会があります。SpecKit と BMAD はその中間に位置し、計画能力を提供しますが、GSD のコンテキストエンジニアリングと Ralph の自律実行の両方が欠けています。

GSD と Ralph は矛盾するものではありません。GSD は Ralph の核心原則 — 新鮮なコンテキスト、ファイルを信頼の源泉とすること — を継承しつつ、その上に完全なプロジェクト理解と実行フレームワークを構築しています。Ralph が「AI にタスクを与えて繰り返し試行させる」ものだとすれば、GSD は「あなたが何を望んでいるかを理解し、どう実現するかを調査し、ステップを計画し、実行し、検証する」ものです。

Chase AI の要約が非常に的確です：Ralph ループは完成された設計図を持ってくることを前提としています — GSD はその設計図を構築する手助けをします。 GSD はあなたの半ば形になったアイデアを受け取り、深い質問をし、代わりに調査を行い、完全な PRD を生成し、それをアトミックなタスクに分解し、プロジェクトをエンドツーエンドで届けます。そしてコード実行時には、Ralph ループを強力にしているのと同じ基本原則を使用します：サブエージェントの新鮮なコンテキストと、可能な限り小さく正確なタスクです。

コアワークフロー

GSD のワークフローは議論 → 計画 → 実行 → 検証のループであり、各ステージに明確な入力と出力があります。

1. プロジェクトの初期化

/gsd:new-project

1つのコマンドでプロセス全体が始まります。システムは以下を行います：

1. 質問 — あなたのアイデアを完全に理解するまで掘り下げて質問します（目標、制約、技術的好み、エッジケース）
2. 調査 — 関連領域を調査するために並列エージェントを派遣します（任意ですが推奨）
3. 要件抽出 — v1、v2、スコープ外の内容を区別します
4. ロードマップ — 要件に対応したフェーズ計画を作成します

ロードマップを承認したら、構築を開始します。TÂCHES の経験では：最初に提供する説明が詳細であるほどシステムの追加質問は少なくなり、曖昧であるほど質問が増えます。開始前に大まかなビジョンドキュメントを準備することを推奨しています — 技術スタックや実装の詳細を知る必要はなく、何が欲しいかを記述するだけで十分です。

出力ファイル: PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md

既存のコードベースがある場合は、まず /gsd:map-codebase を実行してください。システムが並列エージェントを派遣し、技術スタック、アーキテクチャ、規約、潜在的な問題を分析します。その後、/gsd:new-project が既存のコードベースに基づいて計画を立てられるようになります。

2. 議論フェーズ

/gsd:discuss-phase 1

ロードマップの各フェーズには1〜2文の説明しかありません — これだけでは望むものを構築するには不十分です。議論フェーズの役割は、調査と計画の前にあなたの実装に関する好みを捉えることです。

システムは現在のフェーズを分析し、「グレーゾーン」— 複数の合理的な実装アプローチが存在する判断ポイント — を特定します：

• ビジュアル機能 → レイアウト、インタラクション、空の状態の処理
• API/CLI → レスポンスフォーマット、エラーハンドリング、冗長性
• コンテンツシステム → 構造、トーン、深さ、フロー

ここでの各判断は、その後の調査と計画の品質に直接影響します。このステップをスキップしても構いません（システムは合理的なデフォルト値を使用します）が、深い議論を行うことで、システムがあなたの期待により近いものを構築できるようになります。

出力ファイル: {phase}-CONTEXT.md

3. 計画フェーズ

/gsd:plan-phase 1

システムは以下を行います：

1. 調査 — 議論フェーズでの決定をガイドとして、現在のフェーズの実装方法を調査します
2. 計画 — XML 構造化フォーマットで2〜3個のアトミックタスク計画を作成します
3. 検証 — 計画が要件を満たしているか確認し、合格するまで反復します

重要な設計理念は Goal-Backward Planning（目標逆算計画）です。「何を構築すべきか？」から始めるのではなく、「目標を達成するためにどのような条件が成立していなければならないか？」と問い、そこから逆算して計画とタスクを導き出します。TÂCHES はこのアプローチが「出力品質を大幅に向上させた」と述べています。各タスクが他のタスクとの関係を理解しており、単なる ToDo リストの項目ではないからです。

各計画は、1つの新しいコンテキストウィンドウ内で実行できるほど小さく設計されています。これが重要です — 品質の劣化は起こりません。

出力ファイル: {phase}-RESEARCH.md、{phase}-{N}-PLAN.md

4. 実行フェーズ

/gsd:execute-phase 1

システムは以下を行います：

1. ウェーブ実行 — 独立したタスクは並列実行、依存関係のあるタスクは順次実行
2. 新鮮なコンテキスト — 各計画は全く新しい 200k トークンのコンテキストで実行され、蓄積されたゴミはゼロ
3. アトミックコミット — 各タスクが独立した git commit になる
4. 目標検証 — コードベースがフェーズで約束された機能を実現しているか確認

TÂCHES のライブ配信デモでは、3つの完全なフェーズの開発を完了し、メインコンテキストウィンドウは常に24%に留まっていました。GSD Executor サブエージェントは、1つの完全なフェーズを完了するのに1,000行未満のコンテキストをロードするだけで済みます — 10個の計画を連続実行しても、コンテキストは50%未満に留まります。これは Claude Code で直接作業する場合とはまったく異なる体験です：「コンテキストウィンドウの壁にいつぶつかるか賭けるロシアンルーレット」はもうありません。

出力ファイル: {phase}-{N}-SUMMARY.md、{phase}-VERIFICATION.md

5. 検証フェーズ

/gsd:verify-work 1

自動検証はコードが存在するか、テストが通るかを確認できます。しかし、機能が期待通りに動作するかどうかは、あなた自身の確認が必要です。

システムは以下を行います：

1. テスト可能な成果物の抽出 — あなたが今できるはずのことをリストアップ
2. 一つずつ検証をガイド — 「メールでログインできますか？」はい/いいえ、または問題を記述
3. 失敗の自動診断 — デバッグエージェントを派遣して根本原因を特定
4. 修正計画の作成 — 直接実行可能な修正方案

すべて合格すれば、次のフェーズに進みます。問題があれば、再度 /gsd:execute-phase を実行して修正計画を実行します。

これが GSD と Ralph ループの最大の思想的な違いです：Ralph はハンズオフ — 起動したらそのまま走らせる。GSD は各フェーズの終わりに人間による検証ステップがあります。 Chase AI が指摘しているように、Ralph ループは「征服しに行く」スタイル — 振り返らずに自力で動き続けます。GSD は各重要なチェックポイントで軌道修正できることを保証し、監視なしでエラーが積み重なることを防ぎます。

さらに、GSD は専用のデバッグワークフローも提供しています。検証で問題が見つかった場合、/gsd:debug は隔離されたデバッグサブエージェントを起動します。このエージェントは独自の仮説-証拠-解決ワークフローを持ち、調査プロセス全体を追跡する独立したデバッグドキュメントを作成し、メインコンテキストを汚染しません。

出力ファイル: {phase}-UAT.md

サイクルの繰り返し

/gsd:discuss-phase 2 → /gsd:plan-phase 2 → /gsd:execute-phase 2 → /gsd:verify-work 2
...
/gsd:complete-milestone → /gsd:new-milestone

各フェーズが完全な議論 → 計画 → 実行 → 検証サイクルを経ます。コンテキストは新鮮なまま、品質は一貫して保たれます。

すべてのフェーズが完了したら、/gsd:complete-milestone でマイルストーンをアーカイブしてバージョンをタグ付けします。その後、/gsd:new-milestone で次のバージョンの構築を開始します。

なぜ効果的なのか：技術的原理

GSD の信頼性は偶然ではありません — 4つの重要な技術的柱が支えています。

Context Engineering

Claude Code は正しいコンテキストが与えられると非常に強力です。ほとんどの人は正しいコンテキストの与え方を知りません。GSD がこれを代わりに処理します。

各ファイルには、Claude の品質劣化閾値に基づいたサイズ制限があります。制限内に収めれば、一貫した高品質の出力が得られます。メインコンテキストウィンドウは30〜40%に保たれ、実際の作業はサブエージェントの新しい 200k コンテキストで行われます。

Chase AI は Context Rot について直感的な説明をしています：コンテキストウィンドウがどれだけ大きくても — Sonnet、Opus、100万トークンのウィンドウでさえ — 前半のトークンは後半よりも効果的です。 これはバグではなく、LLM 固有の特性です。Claude Code に組み込まれた autocompact は部分的にしか緩和できません。GSD のアプローチはより徹底的です：すべてのアトミックタスクが新しいサブエージェントで実行され、各タスクが Claude の最高のパフォーマンスを引き出せることを保証します。

TÂCHES 自身のデータがこれを裏付けています：月額 $200 の Max プランで、毎月約 $30,000 相当の Opus トークンを消費しています。多く聞こえるかもしれませんが、各タスクが新鮮なコンテキストで実行されるため、やり直しは最小限であり、実際の効率は劣化したコンテキストで繰り返しパッチを当てるよりもはるかに高いのです。

XML Prompt Formatting

すべての計画は Claude 向けに最適化された構造化 XML です：

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

正確な指示、推測は不要、検証が各タスクに組み込まれています。

Multi-Agent Orchestration

各ステージは同じパターンを使用します：薄いオーケストレーターが専門化されたエージェントを派遣し、結果を収集し、次のステップにルーティングします。

オーケストレーターは重い作業を一切しません。エージェントを派遣し、待機し、結果を統合します。その結果：1つのフェーズ全体を実行できます — 深い調査、複数の計画作成と検証、数千行のコードの並列記述、自動検証 — メインコンテキストウィンドウは30〜40%に留まったままです。

Atomic Git Commits

各タスクは完了後すぐに独立してコミットされます：

abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpoint

利点：git bisect で具体的な失敗タスクを特定でき、各タスクを独立してロールバックでき、クリーンな履歴が将来のセッションで Claude がコードの進化を理解する助けになります。

GSD の限界

GSD は強力ですが、できないことを理解することも同様に重要です。

GSD は人間がガイドするワークフローであり、自律エージェントではない

GSD は持続的に実行することができません。各ステージの境界 — discuss から plan、execute、verify まで — で手動でコマンドを入力する必要があります。「アプリを作って」と言って寝に行くことはできません。

これは Ralph の AFK モードとは対照的です。Ralph は「起動して寝に行く」ために設計されています — bash の無限ループがタスクの完了または失敗まで実行し続けます。GSD はあなたが各重要なチェックポイントにいることを要求します：ロードマップの承認、議論の質問への回答、計画のトリガー、実行の開始、検証結果の確認。

4時間のライブ配信中、TÂCHES はコマンドを打ち続けていました：new-project、discuss-phase 1、plan-phase 1、execute-phase 1、verify-work 1、discuss-phase 2……各遷移で彼がエンターキーを押す必要がありました。これは偶然ではありません — 意図的な設計上の選択です。

意図的な設計上のトレードオフ

Ralph は計画能力を犠牲にして実行の自律性を得ました。GSD は実行の自律性を犠牲にして計画品質と人間による監督を得ました。これは設計上のトレードオフであり、欠陥ではありません。

• Ralph の強み：寝ている間に機能を一つ完成させることができます。ただし、スペックが十分でなければ、間違った方向に全速力で突き進みます。
• GSD の強み：各フェーズの後に軌道修正できます。ただし、全プロセスを通じて立ち会う必要があり、離れることはできません。

理想はどのようなものでしょうか？GSD の議論、計画、実行、検証を自動ループに繋げられたら — Ralph の bash loop のようでありながら、GSD の構造化された計画と品質検証を備えている — それが両方の世界のベストです。しかし、そのようなツールはまだ存在しません。おそらく、これが次に探求すべき方向性でしょう。

動画リソース

以下の動画は、GSD の使い方と効果をより直感的に理解する助けになります。

I Created GSD For Claude Code. This Is How I Use It.

GSD 作者 TÂCHES の4時間ライブ配信。ゼロから macOS ネイティブ AI 音楽生成アプリ Sample Digger を構築、手書きコードはゼロ。GSD Executor サブエージェント、目標逆算計画、デバッグワークフロー、マルチモデル切り替え、10フェーズ後もメインコンテキストが24%に留まる様子を実演。YouTube

The New Claude Code Meta

Chase AI がソロ開発者にとって GSD が新しいメタである理由を解説。Context Rot のメカニズム、サブエージェント実行がどのように出力品質を保証するか、GSD の3つのコアドキュメント（Project/Roadmap/State）、そして GSD で My Fitness Pal クローンを構築した実体験を深掘り。YouTube

Stop Using Ralph Loops (Use This Instead)

Chase AI が Ralph ループユーザーの視点から GSD を評価。核心的な主張：Ralph ループは強力な武器だが、GSD は武器庫全体。Ralph のハンズオフモード vs GSD の human-in-the-loop 検証を比較し、完全なインストールと実行フローを実演、トークンコストのトレードオフを議論。YouTube

おわりに

GSD は AI コーディングツールの進化における一つの方向性を示しています：「AI にコードを書かせる」から「AI に確実にプロジェクトを届けさせる」へ。

Ralph Wiggum は重要な洞察を証明しました — 新鮮なコンテキストは蓄積されたコンテキストよりも価値がある。GSD はこの基盤の上に、プロジェクト理解（new-project）、意思決定の記録（discuss）、構造化された計画（plan）、並列実行（execute）、品質検証（verify）を加え、完全な閉ループを形成しています。

ソロ開発者や小規模チームにとって、GSD の価値は複雑なエンジニアリングプラクティスを数個のシンプルなコマンドにパッケージ化していることにあります。サブエージェントオーケストレーションや XML プロンプトエンジニアリングを理解する必要はありません — 何が欲しいかを記述して、システムにやらせるだけです。

Chase AI はうまく表現しています：GSD は「技術的なバックグラウンドがないが、それでも Claude Code で持続可能かつ再現可能な方法でプロジェクトをエンドツーエンドで構築したい」人のためのものです。そして TÂCHES のライブ配信がそれを証明しました — 「おそらく自分では Hello World の HTML ページしか書けない」と自称する人が、GSD で完全なネイティブデスクトップアプリケーションを構築したのです。

これは魔法ではありません。正しい複雑性を正しい場所に置くこと — システムがオーケストレーションの複雑性を担い、人間はクリエイティビティと意思決定に集中する。そしてその限界も同様に尊重すべきです：GSD が人間を常に立ち会わせる選択をしていることは、制約であると同時に、その信頼性の源泉でもあります。

実践に進みたい方は、GSD 実践ガイドをお読みください — 完全なコマンドリファレンス、設定の詳細、実践ワークフローのウォークスルー、FAQ を網羅しています。

関連記事：

• Ralph Wiggum 徹底解説 — Context Rot の問題と Ralph 手法の完全な解析
• スペック駆動開発とは — Vibe Coding からスペック駆動開発へのパラダイムシフト
• Claude Subagent 完全ガイド — コンテキストをクリーンに保つもう一つのアプローチ
• Claude システムアーキテクチャ全解説 — Hooks、Subagent などのコンポーネントの全体アーキテクチャ
• 私の Claude Code ベストプラクティス — Claude Code の日常的な使い方のコツ