こんにちは！アプリケーションサービス部の布施です。
先日うどんばっかり食べている同期からこんなことを言われました。
なんの話かというとGSDというツールです。
やれやれ、うどん食べるのに忙しくて手が空かないから、これは実際に使ってブログにまとめろってことか...
全くしょうがないな...
ということで、本記事ではGSDを使ってみたので、その感触を認めます。
⚠️本ブログを執筆中にgsd2というCLIツールが作成されています⚠️
readmeにはget-shit-doneからgsd2へのmigrationが書かれているので、これらは別ツールと考えていただいて、以降はgsd2から入れると良いかなと思います。
github.com
- What's GSD
- 余談: コンテキストの劣化ってなに？
- 前提
- 既存のプロジェクトの読み取り
- 実装の準備をする〜何を作るのか(what)〜
- 実装の準備をする〜どんな風に作るのか(how)〜
- 実装の準備をする〜終わらない準備、research編〜
- 実装の準備をする〜どんな風に作るのか②〜
- プランの作成と実装〜やあっと実装をするよ〜
- フェーズの中でやるresearchと全体でやるresearchって何が違うの？
- 最終的に出来上がったもの
- まとめ
- おまけ
What's GSD
そもそもGSDなんじゃいという話ですが、これは
- コンテキストの劣化(context rot)を防ぐ
- セッションをまたいで記憶が続く — プロジェクトの状態・決定事項・進捗を自動でファイルに記録するので、明日開いても「続きから」できる
- 並列エージェントを自分で設計しなくていい — リサーチ・計画・実装・検証を勝手に振り分けて動かしてくれる
というメリットがあるフレームワークツールです。 うーんなんだか抽象的だなよくわからない、という人向けには「Claude Code全部やりすぎじゃね？プロジェクトの進め方とか必要な情報はGSDのフレームを使って整理するから、コード良い感じに書いてね〜」というツールですね。 あくまでGSDはツールで、モデルではありません。
余談: コンテキストの劣化ってなに？
そこまで普段実感することがなかったので調べてみましたが、コンテキストの劣化はモデルが読み込むコンテキストの量が多くなると性能が落ちる現象です。
例えばTODOアプリを作るときに
- DBを用意して
- タスク作成のAPIを用意して
- 言語はTypeScriptにして
- バグ出たから修正して
- テストも書いて
- テスト落ちるから修正して
- いや〇〇なケースもテスト書いて
- ...(こんなふうに対話がどんどん進んでいく)...
- タスクを削除するAPIを用意して
という風に会話を重ねたときに、急に既存のコードと関連のないコードを生成し始めるような現象が発生します。 「えっ、TypeScriptって言ったのになんでPHPで書いてるの？」みたいなイメージですね。
個人的にはそこまで劣化を実感する機会はない(Claude Codeの1セッションで上限となるトークン数も増えていますし...)のですが、1, 2年前であれば確かに対話を重ねていくと序盤の内容を覚えていない、ということがあったようななかったような...
前提
本線に戻します。
ちょうど手元ではAWS Lambdaの関数を用意するプロジェクトがありました。 この関数はSecrets Managerから値を取り出して、外部APIに処理を依頼する小さい関数で、すでにうごく"モノ"は出来上がっていました。
ただ、テストは未導入だったので、せっかくなのでGSDを使ってテストコードを用意しようと思います。
GSDそのものはnpx get-shit-done-cc@latestでinstallすることができます。
コマンドを実行すると.claude配下に必要なディレクトリ/ファイルが展開されます。
既存のプロジェクトの読み取り
すでに開発が進められているプロジェクトに導入するには/gsd:codebaseというコマンドを呼び出します。
すると、呼び出し時点でのリポジトリを走査してどのようなプロジェクトであるのかを表現したmdファイルが用意されます。
イメージ的にはClaude Codeの/initに近いです。
ただ、用意されるファイル数は/initよりも多いです。 私の手元では7つのmdファイルが作成されました。
実装の準備をする〜何を作るのか(what)〜
ここからものづくりのフェーズです。
最初は/gsd:new-projectというコマンドを呼び出します。
コマンド実行すると何をしたいのかを聞かれるので、「テストを作りたい」と入力します。
すると以下のような質問が続け様に飛んできました。
| 質問 | 選択肢 | 筆者の回答 |
|---|---|---|
| どのような観点でテストしたいですか？ | ロジック単体テスト / Lambda統合テスト / 両方 | 両方 |
| テストを導入する一番の動機は何ですか？ | デプロイ前の安心感 / リグレッション防止 / ドキュメント代わり | デプロイ前の安心感 |
| CI/CDパイプラインと連携したいですか？ | まずローカルのみ / GitHub Actions連携も必要 | まずローカルのみ |
テストを導入したい目的はそれによって何か出来上がるものが変わるのか...？という感じですが、まあここでは良しとしましょう。
これで他に話しておきたいことある？と聞かれたので 「テストフレームワーク決めてないけどなにを使う予定？」と追加で聞いてみると
どのテストフレームワークを使いますか？
❯ 1. Vitest (Recommended)
TypeScript ネイティブ対応・高速・Jest 互換 API。設定がシンプルで近年の主流
2. Jest
最も実績が多く情報量豊富。ts-jest が必要でやや設定が多め
3. Node.js 組み込み
追加依存なし。機能は最小限で情報も少ない
4. Type something.
────────────────────────
こんな感じで選択肢を出されました。 他に共有したいことある？と聞かれたのですが、なかったので進めてもらうと以下のようなPROJECT.mdが作成されました。
# 週次BoxNote自動作成 Lambda ## What This Is 毎週火曜日に EventBridge で起動し、テンプレート BoxNote をコピーして 課会ノートを自動生成する AWS Lambda 関数。TypeScript 製の単一ファイル構成で、Box JWT 認証情報は AWS Secrets Manager で管理している。 ## Core Value Lambda が実行されたとき、必ず正しい日付のファイル名で BoxNote がコピーされること。 ## Requirements ### Validated - ✓ EventBridge による毎週火曜 15:00 JST のスケジュール実行 — existing - ✓ AWS Secrets Manager から Box JWT 設定を取得して認証 — existing - ✓ `getNextTuesdayJst()` で翌週火曜の日付を YYYYMMDD 形式で算出 — existing - ✓ `client.files.copy()` でテンプレート BoxNote を指定フォルダへコピー — existing - ✓ esbuild でバンドルして `lambda.zip` を生成するビルドフロー — existing ### Active - [ ] Vitest テストフレームワークのセットアップ（`npm test` で実行可能） - [ ] `getNextTuesdayJst()` の単体テスト（日付ロジックの網羅的な検証） - [ ] `handler()` の統合テスト（Box API・Secrets Manager をモックして正常系・異常系を検証） ### Out of Scope - GitHub Actions などの CI 連携 — まずローカル実行のみで十分 - E2E テスト（実際の Box API・Secrets Manager への接続）— 認証情報管理が複雑になるため除外 ## Context - Lambda 本体のロジックはすべて `src/index.ts` の1ファイルに集約されている - テスト対象の主な関数: `getNextTuesdayJst()`（純粋関数）、`handler()`（外部依存あり） - 外部依存のモック対象: `@aws-sdk/client-secrets-manager`、`box-node-sdk` - Lambda は UTC 動作のため、タイムゾーン変換ロジックのテストが重要 ## Constraints - **Tech Stack**: Vitest を採用（TypeScript ネイティブ対応、設定が最小限） - **実行環境**: ローカルのみ（CI 不要） - **スコープ**: テスト導入のみ。本体ロジックの変更は最小限に留める ## Key Decisions | Decision | Rationale | Outcome | |----------|-----------|---------| | Vitest を選択 | TypeScript ネイティブ対応で設定が少ない。Jest 互換 API で学習コストが低い | — Pending | | CI 連携は今回対象外 | まず `npm test` でローカル実行できる状態を優先 | — Pending | | E2E テストは対象外 | 実認証情報の扱いが複雑になるため、モックによる統合テストに留める | — Pending | --- *Last updated: 2026-03-12 after initialization*
それっぽく書かれているので、「お、ようやくここから実装か？」と思ったらそんなことありませんでした。 まだまだ質問攻めに合います。
実装の準備をする〜どんな風に作るのか(how)〜
先ほどは「何を作る？(what)」でしたが、ここでは「どんな風に作る？(how)」の部分を聞かれます。 /gsd:new-projectから始まる対話はwhatのパートで終了せず、連続して以下のようなことを聞かました。
| 質問 | 選択肢 | 選んだ回答 |
|---|---|---|
| Mode | YOLO / Interactive | YOLO |
| Granularity | Coarse / Standard / Fine | Standard |
| Execution | Parallel / Sequential | Sequential |
| Git Tracking | Yes / No | Yes |
| Research | Yes / No | Yes |
| Plan Check | Yes / No | Yes |
| Verifier | Yes / No | Yes |
| AI Models | Quality / Balanced / Budget | Balanced |
| ドメインリサーチ | Research first / Skip | Research first |
これだと何を聞かれているのかわからないのでいくつか例を出すと、
【Granularity】 どのくらい細かく実装をするのかを決めます。 GSDでは実装の単位を「フェーズ」という概念で扱うのですが、Granularityではフェーズをどれだけ細かくするかという決定をします。 フェーズについては後半で詳細に扱うのでここでは「そういう単位があるんだな〜」程度で問題ないです。
例えば今回はテストの導入ですが、
| 粒度 | フェーズ分け例 |
|---|---|
| Coarse（粗い） | フェーズ1: Vitest導入 + 全テスト実装 |
| Standard | フェーズ1: Vitest セットアップ / フェーズ2: 単体テスト / フェーズ3: 統合テスト |
| Fine（細かい） | フェーズ1: 設定 / フェーズ2: getNextTuesdayJst テスト / フェーズ3: handler正常系 / フェーズ4: handler異常系 … |
こんな感じにフェーズを選択できました。
【Execution】 複数のフェーズを並列実行するかどうかを聞かれました 今回は並列にするほどリッチな開発ではないのでSequentialを選択しました。
プランを並列実行しますか？
1. Parallel (Recommended)
独立したプランを同時実行
❯ 2. Sequential
1プランずつ順番に実行
3. Type something.
【Git Tracking】
GSD関連のファイルはプロジェクト内の.plannningディレクトリに全て追加されるのですが、これをgitの管理対象にする？という質問です。 今回はrecommendされているのでYesを選択しました。
プランニングドキュメントを git にコミットしますか？
❯ 1. Yes (Recommended)
.planning/ をバージョン管理する
2. No
.planning/ をローカルのみ（.gitignore に追加）
3. Type something.
と言うイメージで対話形式の質問がいくつ続きました。。
ところで質問の中で、途中でresearchという項目が出てきてだいぶ時間を使いました。 これが結構大事そうです。次の章で取り上げます。
| 質問 | 選択肢 | 選んだ回答 |
|---|---|---|
| Mode | YOLO / Interactive | YOLO |
| Granularity | Coarse / Standard / Fine | Coarse |
| Execution | Parallel / Sequential | Sequential |
| Git Tracking | Yes / No | Yes |
| Research | Yes / No | Yes |
| Plan Check | Yes / No | Yes |
| Verifier | Yes / No | Yes |
| AI Models | Quality / Balanced / Budget | Balanced |
| ドメインリサーチ | Research first / Skip | Research first |
実装の準備をする〜終わらない準備、research編〜
researchは、使う技術のベスプラやよくあるバグを調べてくれる機能です。
公式ドキュメント（README）では、このリサーチファイル群の役割を以下のように定義しています。
Ecosystem knowledge (stack, features, architecture, pitfalls) エコシステムの知識（技術スタック、機能、アーキテクチャ、落とし穴）
具体的には、裏側で4つの並列エージェントが立ち上がり、使おうしている技術のベストプラクティスや、実装時によくハマるエラー（落とし穴）などを徹底的に調査してくれます。その調査結果を、.planning/research/ というディレクトリに出力します。
一例を出すと、以下のようにテストでのタイムゾーンをちゃんとしような、という話が書かれていたりします。 一体どこでこの情報を拾ってきたんだろうか...
### 3. TZ 環境変数を vitest.config.ts で固定しない
**症状:** ローカル（JST環境）では全テストが通るが、UTC環境（CI等）で日付テストが失敗する
**回避策:**
// vitest.config.ts
export default defineConfig({
test: {
env: { TZ: 'Asia/Tokyo' } // これが必須
}
});
テストファイル内で `process.env.TZ = 'Asia/Tokyo'` を設定しても Node.js の制約で確実に反映されない場合がある。
個人的にこれがかなりすごいなと思っていて、コードが生成されてから人間が手直しが必要な箇所を少なくしてくれるんじゃないかなと期待しています。 ちなみに、プロジェクト全体でこのリサーチが必ずしも必要かというと、そうではありません。READMEには以下のように明記されています。
Research — Spawns parallel agents to investigate the domain (optional but recommended) リサーチ — ドメインを調査するために並列エージェントを生成します（任意ですが推奨します）
「任意ですが推奨」なので、個人的には極小プロジェクトや、使用技術が少なくシンプルな場合以外はresearchしてみると良さそうな印象です。
実装の準備をする〜どんな風に作るのか②〜
先ほどresearchまで質問に答えましたが、いくつか質問が残っていました。 researchが完了してそれ以降も質問にも答えていきます。
| 質問 | 選択肢 | 選んだ回答 |
|---|---|---|
| Mode | YOLO / Interactive | YOLO |
| Granularity | Coarse / Standard / Fine | Coarse |
| Execution | Parallel / Sequential | Sequential |
| Git Tracking | Yes / No | Yes |
| Research | Yes / No | Yes |
| Plan Check | Yes / No | Yes |
| Verifier | Yes / No | Yes |
| AI Models | Quality / Balanced / Budget | Balanced |
| ドメインリサーチ | Research first / Skip | Research first |
回答が終わると、
- .planning/ROADMAP.md
- .planning/STATE.md
というファイルが最終的に生成されました。 これらはこの後の実装フェーズに移った後に、どの作業をどこまで起こったのかを決定したり、進行中に発生した意思決定を記録しているファイルになります。
ここで一旦全体の方針決めは完了です。
プランの作成と実装〜やあっと実装をするよ〜
ここからようやく実装に入ります。
実装はGSDが次にこのコマンドを実行する？という提案のまま進めていきました。 具体的には各フェーズごとに以下の計画→実行を繰り返していきます
| ステップ | コマンド | 生成物 |
|---|---|---|
| 計画 | /gsd:plan-phase |
RESEARCH.md → VALIDATION.md → PLAN.md |
| 実行 | /gsd:execute-phase |
コード実装 + コミット群 |
| 完了後 | (自動) | SUMMARY.md・VERIFICATION.md |
ここまで来ると行っていることに馴染みのあるイメージがつく方もいるのではないでしょうか。 GSDでは実装の単位を「フェーズ」という概念で扱うと紹介しましたが、まさに1つのフェーズごとに計画→実行となっています。
ただし、厳密には各フェーズはもっと細かくやれることがありそうです。
公式ドキュメントのreadmeでは以下のようなフローになると書かれています。今回はあくまで体験談なので詳細に中身には触れません(別に書くのが大変だからとかではない)
- Discuss Phase （コマンド: /gsd:discuss-phase 1）
- Plan Phase （コマンド: /gsd:plan-phase 1）
- Execute Phase （コマンド: /gsd:execute-phase 1）
- Verify Work （コマンド: /gsd:verify-work 1）
- Complete Milestone（マイルストーンの完了）
フェーズがたくさん出てきてしまってややこしいのですが、1〜4の処理を1つのフェーズに対して行うことができるわけですね。Discuss Phaseは「議論するフェーズ」でもあるのですが、実装1フェーズの中で議論するパート、になります。
ちなみに今回はDiscuss Phaseを不要と判断して飛ばしてみたのですが、本来Discuss Phaseで行われる各フェーズごとのresearchも行われていました。
...あれ？researchって前半でプロジェクト全体で行いませんでしたっけ？
フェーズの中でやるresearchと全体でやるresearchって何が違うの？
そうです、私も混乱したのですが、researchには
- プロジェクト全体に対して行うresearch
- フェーズごとに行われるresearch
の2つが存在します。
プロジェクト全体のresearchは.plannning/research/に入っており、フェーズごとのresearchは.plannning/phases/<phase番号>-<phase名>/<phase番号>-RESEARCH.mdという完全に別ファイルで存在するのです。
これ、一体何が違うのか調べてみると - プロジェクト全体のresearchは「どんなフェーズに分けるのかを使用される」 - フェーズごとのresearchは「フェーズごとのプランを作成するのに使用される」 らしいのです。
もうちょっと書くと
- プロジェクト全体のリサーチ:
- テストの対象となるコードは読んでいない
- vitestのバージョンが2.1.0と古い状態でresearchをしている
- フェーズごとのresearch:
- テストの対象となるコードを読んでいる
- vitestのバージョンが4.1.0と最新の状態でresearchをしている
このような形で、プロジェクト前半のresearchはだいぶ粗く、あくまでの実装をどのように進めるのかを判断するための材料であることがわかるかなと思います。
最終的に出来上がったもの
実際のコードは良い感じに出来上がりました。 テストもちゃんとパスしていますし、ぱっと見で少なくとも考慮漏れはなさそうなイメージです。
まとめ
つらつらと書いてきましたが、「Claude Code全部やりすぎじゃね？プロジェクトの進め方とか必要な情報はGSDのフレームを使って整理するから、コード良い感じに書いてね〜」ということがわかれば十分で、あとは手を動かしながら細かい概念は理解できると良さそうです。
ちなみにやってみてですが、たかだがLambda関数一つのテストを作成するだけならバイブコーディングをしてしまった方が確実に早いです。 ただ、ある程度大きめの機能開発や複数の機能をまとめて「こんなことを実現したい」という粒度からものづくりを始めていく分には有効なツールかなと思いました。
この記事がGSDについて調べているどなたかの一助になれば幸いです。
おまけ
ちなみにGSDのcore contributerにはClaude Codeがいて「もうそういう時代なんだな...」と思いました。こわひ。
