はじめに：コンテキスト腐敗という課題

最近、AI支援コーディングツールを探っていた際、**GSD（get-shit-done）**という仕様駆動開発システムを知りました。正直、この名前自体が面白い——シンプルで直接的、実務的な雰囲気が伝わります。しかし、本当に私の目を引いたのは、コンテキスト腐敗（context rot）問題への取り組み方でした。

AIコーディングアシスタントを長く使っている方なら、こんな現象に気づいているかもしれません：会話の最初はAIの出力が素晴らしい——正確で的確な回答。しかし会話が進み、コンテキストが蓄積されるにつれて、出力の品質が目に見えて低下してきます。これはモデルの限界ではなく、「コンテキスト腐敗」と呼ばれる現象です。

研究によると、単一セッションのコンテキストがモデル容量の50%程度を超えた時、出力品質が著しく低下します。これは複雑なプロジェクトを扱う開発者が「作業記憶」に過多の情報を詰め込んでいる状態に似て——情報過多になれば判断力と創造性が必然的に影響を受けるのです。

従来のAIコーディングツールは、単一大コンテキスト方式を採用し、すべての要件、設計、コードを一つの長い会話に詰め込んでいます。この手法は複雑なプロジェクトに直面すると、すぐにコンテキストのボトルネックに到達します。GSDは、この問題を解決するために設計されました。

GSDの核心：粒度管理されたワークフロー

バックエンドエンジニアとして、私は常に「粒度」という概念を重視しています。良いシステム設計はモジュラであるべき——各モジュールが明確な責務と境界を持つ。GSDの設計思想はこれと完璧に合致します：小粒度の段階的ワークフローと専門サブエージェントによる実行。

GSDは開発プロセス全体を複数の段階（phase）に分解し、各段階に明確な目標と境界を設定します。各段階は専門サブエージェントが担当し、研究、計画、実行、検証などそれぞれの領域に集中します。

この設計にはいくつかの明確な利点があります：

コンテキストの隔離。 各サブエージェントは自分の段階に関連するコンテキストのみを処理し、他の段階からの情報干渉を回避できます。マイクロサービスアーキテクチャにおけるサービス隔離に似て——各サービスは自分のビジネスロジックに集中します。

責務の明確化。 研究段階の研究者は実行段階の詳細を知る必要がなく、検証段階の審査員も計画段階の決定プロセスを理解する必要がありません。この関心の分離により、各段階で高品質な出力が保証されます。

トレーサビリティ。 各段階は明確な成果物を生成——研究ドキュメント、計画ドキュメント、検証レポートなど。これらは開発プロセスの記録であり、将来の保守とイテレーションのための明確な参照となります。

バックエンド開発思考に慣れた私にとって、この制御可能な粒度は非常に魅力的です。システムを設計するように開発プロセスを「設計」でき、AIのペースに受動的に従うのではなく、主導権を持てるのです。

実践体験：パスワード生成ツールの開発

GSDの基本理念を理解した後、簡単なプロジェクトで試してみようと決めました——パスワード生成ツール。この選択には理由があります：GSDのワークフローを短時間で検証できるほど小さく、同時に各段階がどう協調するかを示す機能が十分ある。

開発はGSDの標準フローに従いました。まず研究段階——研究エージェントがパスワード生成ツールの一般的要件、安全標準、実装アプローチを調査。パスワード強度の定義、UI設計の考慮点など、詳細なドキュメントを生成しました。

次に計画段階。計画エージェントが研究ドキュメントを基に開発計画を策定——プロジェクトを複数段階に分解：UI設計、パスワード生成ロジック、安全性検証など。各段階に明確な入出力と受入基準が定義されました。

実行段階が最も実践的な部分でした。GSDの実行エージェントが計画に従って機能を段階的に実装し、各段階完了後に検証エージェントをトリガーしてチェックを行います。CI/CDパイプラインのような——各段階で自動テストが品質を保証します。

特に印象的だったのは、私はほとんど介入しなかったこと。プロジェクト開始時に要件を説明し、GSDが開発プロセス全体を自動的に進行させました。訓練された開発チームを指揮する感覚——目標を説明すれば、チームが残りを完了します。

結果は機能完全なパスワード生成ツール——UIが洗練され、ロジックが明確。しかし結果以上に重要だったのは、GSDのワークフローが曖昧なアイデアを具体的製品に変換する過程を明確に見たことです。

OpenSpecとの比較：仕様策定の繊細さ

GSDを探る過程で、以前触れたOpenSpecについても考えました。両者とも仕様駆動開発の手法ですが、仕様策定の細部と厳格さにおいて、GSDはより深い印象を残しました。

仕様駆動開発に興味がある方は、私の以前の記事OpenSpec in OpenCode体験もご覧ください。

OpenSpecの理念は、開発者が詳細な仕様ドキュメントを書き、AIが仕様に従ってコードを生成すること。これにより仕様書作者が制御権を持てますが、仕様を書くこと自体に多大な時間と専門知識が必要になります。また、仕様に漏れや曖昧さがあれば、生成されたコードに問題が生じる可能性があります。

GSDは異なる戦略を採ります。開発者が事前に完全な仕様を書くことを要求せず、複数の協調エージェントが徐々に包括的な仕様を導出します。研究エージェントが要件と技術背景を収集、計画エージェントが実装方案を策定、実行エージェントが具体的に実装、検証エージェントが品質を保証。各エージェントが自分の作業を完了する同時に、仕様を補充し洗練します。

この手法の利点：仕様は動的に、イテレーティブに生成される。プロジェクト開始時にすべての細部を予見する必要がなく——システムが実行中に自動的に仕様の空白を発見し埋める。アジャイル開発の「創発的設計」に近く、ウォーターフォール開発の「事前設計」とは異なる。

さらに、GSDは仕様検証においてより厳格です。各段階の成果物が後続段階の入力として使用され、自動的な仕様検証機構が形成されます。仕様が不完全または誤りがある場合、後続段階のエージェントが問題に遭遇し、仕様の問題が早期に露出されます。

この繊細さと厳格さは、コード品質を追求するバックエンドエンジニアにとって大きなプラスです。GSDで開発されたプロジェクトは、コード自体が信頼できるだけでなく、開発プロセス全体がトレース可能、検証可能であると確信できます。

まとめ

GSDを初めて試した体験から、AIコーディングの核心的課題に真正面から取り組んでいると確信しました。コンテキスト腐敗は軽視できる小問題ではなく、プロジェクト品質に直接影響します。制御可能な粒度のワークフローと専門サブエージェント機構により、GSDはコンテキスト規模を効果的に管理し、各段階の出力品質を保証します。

バックエンドエンジニアとして、GSDの設計哲学を評価します——ソフトウェアエンジニアリングの古典的原則（モジュラ性、関心の分離、トレーサビリティ）をAI支援開発に適用。この伝統的知見と新技術の融合により、GSDは単なるツールではなく、メソドロジーとなっています。

もちろん、GSDは銀の弾丸ではありません。非常に単純なプロジェクトでは、GSDを使うことは「過剰」に感じるかもしれません。しかし中程度以上の複雑さのプロジェクト——特にチーム協業と長期保守が必要な場合——GSDの価値は明確に現れます。

AI支援開発パラダイムのより多くの議論については、私の記事Vibe Coding: Harness Engineeringパラダイムシフトをご覧ください。

今後、より多くのプロジェクトでGSDを試し、その能力境界をさらに探求する予定です。AI支援コーディングは急速に進化しており、GSDのようなツールは有望な方向を示しています：開発者を置き換えるではなく、AIが開発者の有能な助手となり、より良い仕事を支援する。

GSDまたは他の仕様駆動開発ツールを試した経験はありますか？コメントで共有していただけると嬉しいです。