gstackとは｜Garry Tan流Claude Codeスキル集『AIソフトウェア工場』の全貌

この記事では Claude Code に特化して解説する。Claude Code 全般は Claude Code完全ガイド2026：インストールから本番運用まで を参照してほしい。

gstack は、Y Combinator の President & CEO である Garry Tan が公開した、Claude Code 向けのスキル集だ。名前が「stack」なので Web アプリのスターターキット（create-next-app のような雛形）を想像しがちだが、それは誤解である。gstack は雛形を生成しない。代わりに、CEO・デザイナー・エンジニアマネージャー・QA・セキュリティ責任者・リリース担当といった役割を Claude Code に演じさせ、1人の開発者を疑似的な開発チームのように動かす——リポジトリ自身の言葉を借りれば「AIソフトウェア工場（AI-Powered Software Factory）」だ。

まず、gstack を入れると Claude Code での開発がどう変わるのかを1枚で示す。個々のスラッシュコマンドが、開発チームの各役割を担う。

この記事では gstack を、当サイトの3つの問い——①結局何ができる／②何を解決する／③何を代替するのか——に沿って、公式リポジトリ（README・ETHOS.md・ARCHITECTURE.md）をベースに整理する。派手な生産性の数字は主張として扱い、確認できる機能・技術構成に軸を置いて解説する。

gstackとは——Garry Tanの「AIソフトウェア工場」の正体

結論から言えば、gstack は「1人の開発者に、開発チームの各役割を”作法”として持たせる」ツールだ。

gstack のパッケージ説明文（package.json の description）は、自らをこう端的に表現する。「Garry’s Stack — Claude Code skills + fast headless browser. One repo, one install, entire AI engineering workflow.（ひとつのリポジトリ、ひとつのインストールで、AIエンジニアリングのワークフロー全体を）」。ここで重要なのは、gstack がClaude Code の”能力”を足すのではなく、”作法”を足すという点だ。コード生成そのものは Claude Code が行い、gstack はその周りに「チームなら当然やる工程」を敷く。

作者の Garry Tan は、Palantir の初期エンジニア/PM/デザイナーを経て、Posterous を共同創業（Twitter に売却）、その後 Y Combinator で Bookface を構築し、現在は YC の President & CEO を務める人物だ。gstack は、その Tan 自身が日々使う Claude Code 構成をそのまま公開したものにあたる。当サイトで解説した Andrej Karpathy 流のスキル/CLAUDE.md 運用 が「ルールの層」だとすれば、gstack はその上に載る「ワークフロー強制の層」だと位置づけられる（README も Karpathy のスキル集を土台として明示的に参照している）。

この「工場」という比喩を、当サイトが繰り返し扱ってきた ハーネスエンジニアリング の言葉に翻訳すると、gstack は「Claude Code というモデルの周りに、役割・ツール・検証・安全機構を敷き詰めたハーネス」だと言える。

gstack の設計思想（ETHOS.md）は「Boil the Ocean（海を沸かす）」という言葉で表現される。普通なら「やりすぎ」とされる網羅的なアプローチ——全工程を役割で埋め、実ブラウザで検証し、セキュリティまで監査する——を、AI支援によって現実的なコストで回せるようになった、という主張だ。ここには「AIで効率が上がる作業と、そうでない作業がある」という冷静な認識も含まれる。ボイラープレートのような定型作業は劇的に圧縮できる一方、アーキテクチャの判断のような本質的な作業は、それほど倍率が伸びない。gstack はこの”効きの差”を前提に、定型作業をAIへ大胆に振り、人間の判断が要る箇所に集中できるよう工程を設計している。

この「効きの差」を数値で主張したのが、前述の圧縮率の図（後段で扱う）だ。定型作業ほど倍率が高く、判断が要る作業ほど倍率が低い——その傾斜自体は、実際にAI支援で開発した経験のある人なら直感的に頷けるだろう。言い換えれば、gstack が売っているのは「速いコード生成」ではなく「抜け落ちない段取り」だ。個人開発でありがちな「実装はしたがテストを書き忘れた」「動いたが本番前のセキュリティ確認を飛ばした」といった漏れを、役割スキルという形で構造的に潰す。ここが、単にプロンプトを工夫するのとは違う、gstack の価値の芯にあたる。

3つの疑問——gstackは何ができ、何を解決し、何を代替するのか

gstack について、当サイトの読者が求める3つの問いに答える。

③の注意点を改めて強調しておく。gstack は T3 スタックや create-next-app の代わりではない。これらはアプリの初期コードを生成する道具で、gstack は開発の”進め方”を強制する道具だ。カテゴリが違う。比較するなら、Karpathy のスキル集や、Peter Steinberger の OpenClaw といった Claude Code のスキル/エージェント系プロジェクトが相手になる。

この「カテゴリの取り違え」は、gstack を検索する人が最も陥りやすい誤解だ。名前の “stack” は、技術スタック（フレームワーク＋DB＋認証……の組み合わせ）ではなく、Garry Tan 個人の”作業スタック（一式の道具）”を指している。だから gstack を入れても、Next.js のプロジェクトが生成されるわけでも、DB がセットアップされるわけでもない。代わりに、あなたの Claude Code に「CEO なら計画をこう問い直す」「QA なら実ブラウザでこう検証する」という役割ごとの作法がインストールされる。この一点を理解しておくと、gstack への期待値がずれない。

②の「ブランクのプロンプト問題」も、経験のある人ほど腑に落ちるはずだ。真っ白な指示欄に「このアプリを作って」と書くと、AIは一見それらしい成果物を返すが、テストが抜けていたり、エッジケースを踏み外していたり、セキュリティ確認を飛ばしていたりする。gstack は、その”抜け”を人間が毎回思い出す代わりに、役割スキルという仕組みで機械的に埋める。規律を記憶に頼らない——これが gstack の解決策の本質だ。

役割ベースのスキル群——CEOからQA・CSOまでチームを演じる

gstack の中身は、23以上の役割特化スキルと、8つの「パワーツール」で構成される。すべてスラッシュコマンドとして呼び出す。開発の1スプリントを、役割のリレーとして回すのが基本形だ。ポイントは、これらの役割が「別々のAI」ではなく、同じ Claude Code に異なる帽子をかぶらせているという点にある。CEO の帽子をかぶれば戦略を問い、QA の帽子をかぶれば粗探しをする——1つのモデルを、役割ごとに違う視点へ切り替えて使う。人間のチームが会議で役割分担するのを、1人＋AIで再現しているわけだ。

それぞれの役割を、READMEの記述に沿って整理する。

このうち gstack を最も特徴づけるのが /qa だ。多くのAIコーディングツールが「コードを書く」で止まるのに対し、gstack は実際のブラウザを立ち上げて動作を確認し、見つけたバグを直し、二度と再発しないよう回帰テストまで書く。この「検証が通るまで閉じない」ループは、当サイトが ループエンジニアリング で説いてきた「証拠で完了を確かめる」設計そのものだ。単なるスキル集ではなく、検証設備を備えた”工場”を名乗る理由がここにある。

設計・デザインの自動化——/design-shotgun と /design-html

gstack はコードだけでなく、デザインの工程にも役割を用意している。/design-shotgun は、GPT-Image でUIのモック案を複数（4〜6案）生成し、比較ボードに並べて選べるようにする。選んだ案は /design-html が本番相当のHTMLへ落とし込む。ここでも「1人でデザイナーの叩き台づくりからレビューまでを回す」という、役割の肩代わりの発想が貫かれている。生成した好みの傾向は”テイストメモリ”として蓄積され、回を重ねるほど自分の好みに寄っていく設計だ。

並列スプリントと second opinion——Conductor と /codex

さらに規模を上げたいときのために、gstack は複数スプリントを同時に走らせる Conductor（10〜15並列）を持つ。1人で複数の機能開発を並行させ、それぞれを役割リレーで進められる。加えて /codex は、Claude の /review とは別に OpenAI Codex による”第二の意見”を取り、両者の指摘の重なりと差分を突き合わせる。単一モデルの盲点を、別モデルのレビューで補う——という多モデル運用の発想は、当サイトの ハーネス設計 の文脈とも重なる。

こうした機能は魅力的だが、裏を返せば gstack の全体像はかなり大きい。23以上のスキルと8つのパワーツールをいきなり全部使いこなす必要はなく、まずは基本のスプリントを回しながら、必要になった役割だけを足していくのが現実的な付き合い方だ。

実ブラウザQAとセキュリティ——単なるスキル集ではない「工場」の設備

gstack が「スキル集」以上のものである最大の理由が、ヘッドレスブラウザの常駐デーモンと、セキュリティ・安全機構という2つの”設備”だ。

技術構成を見ると、gstack はランタイムに Bun を採用し、bun build --compile で単一バイナリの CLI を作る。ブラウザ層は Playwright と puppeteer-core が駆動する常駐ヘッドレス Chromium デーモンで、localhost 経由の HTTP と CDP でやり取りする。初回のコールドスタート後は1コマンドあたり100〜200ミリ秒程度で応答し、/qa の実ブラウザ検証を高速に回せる設計だ（詳細は ARCHITECTURE.md）。

ここが「常駐デーモン」であることには理由がある。毎回ブラウザを起動し直すと、コールドスタートに数秒かかり、検証のたびに待たされる。gstack は一度立ち上げたブラウザを約30分のアイドルタイムアウトまで生かし続け、以降のコマンドはそこへ接続するだけにする。結果、AIエージェントが「クリックして→スクショを撮って→次を確認して」と細かく往復しても、体感の待ち時間が小さい。gstack が MCP 経由のブラウザツール（Claude-in-Chrome など）ではなく、独自の /browse コマンド群を勧めるのも、この速度と、後述するセキュリティ制御を両立させるためだ。地味だが、実ブラウザQAを”実用速度”で回すための重要な作り込みである。

とりわけ安全機構は、AIエージェントを本番に近づける現場で効いてくる。/careful・/freeze・/guard は、rm -rf や DROP TABLE、force-push といった破壊的操作をブロックし、編集を特定ディレクトリに固定する。AIが暴走して意図しない領域を書き換える——という事故を、コマンドで縛れる。

GBrain——セッションをまたぐ永続メモリ

もうひとつの重要な設備が、永続メモリの GBrain だ。Claude Code は基本的に会話（セッション）が終わると文脈を失うが、GBrain は Postgres（Supabase）またはローカルの PGLite を MCP サーバとして登録し、プロジェクトの知識をセッションをまたいで保持する。リポジトリごとに read-write / read-only / deny の信頼レベルを設定でき、どのプロジェクトにどこまでメモリを開くかを制御できる。

これは、当サイトが ループエンジニアリング で「ループが1つのコンテキストウィンドウより長く回ると、信頼性はメモリの問題になる」と整理した論点への、gstack なりの回答だ。役割リレーを何スプリントも回すほど、「前に何を決めたか」を憶えている外部メモリの価値が効いてくる。gstack が /learn で学びを蓄積し、ドメイン特化スキルを回を追うごとに育てていくのも、同じ「記憶を資産にする」思想の表れである。

さらに gstack は、iOS 実機QA（USB/Tailscale 経由）や、複数ベンダーで1つのブラウザを共有する /pair-agent といった機能も備える。まさに「工場」の名にふさわしい設備群だが、その分だけ全体像は大きく、最初から全部を使う必要はない。まずは /office-hours→/review→/qa→/ship の基本ラインから始めるのがよい。

導入と使い方——git clone から /office-hours まで

導入は、リポジトリを Claude Code のスキルディレクトリへ直接クローンし、セットアップを走らせる方式だ。読者が実際に実行する手順として、公式READMEのコマンドを引く。

# Claude Code へ導入（スキルディレクトリへクローン＋セットアップ）
git clone --single-branch --depth 1 \
  https://github.com/garrytan/gstack.git ~/.claude/skills/gstack \
  && cd ~/.claude/skills/gstack && ./setup

./setup は依存関係のインストール、ブラウザバイナリの構築、各機能の初期化を自動で行う。Playwright のブラウザをダウンロードするため、初回はネットワーク次第で数分かかる点は覚えておきたい。前提として Bun v1.0 以上（Windows のみ Node.js も併せて）が必要で、これらが未導入だとセットアップの途中で止まる。

チームで使う場合は、リポジトリ側に gstack の利用を必須化する設定も用意されている。

# チームモード：リポジトリで gstack 利用を必須化
(cd ~/.claude/skills/gstack && ./setup --team) \
  && ~/.claude/skills/gstack/bin/gstack-team-init required \
  && git add .claude/ CLAUDE.md \
  && git commit -m "require gstack for AI-assisted work"

導入後の基本的な使い方は、スプリントの型に沿ってスラッシュコマンドを順に呼ぶだけだ。

/office-hours          # プロダクトのアイデアを問い直す
/plan-ceo-review       # 戦略的な観点で計画をレビュー
/review                # コードレビュー＋自動修正
/qa https://staging    # 実ブラウザでテスト
/ship                  # テスト・監査・PR

Claude Code 以外のエージェントを対象にする場合は ./setup --host codex（opencode・cursor・factory 等も指定可）で切り替えられる。gstack は Claude Code を主対象としつつ、10種類ほどのエージェントに対応しており、hosts/ 配下に各エージェント向けの型付き設定を持つ。つまり「Claude Code 専用ツール」ではなく、手元のエージェントに合わせて同じワークフローを載せられる設計だ。不要になれば ~/.claude/skills/gstack/bin/gstack-uninstall で取り外せる。

スキルの実体は、プロジェクトの .claude/skills/（または各エージェントの対応ディレクトリ）に配置される Markdown の SKILL.md 群だ。既存プロジェクトに組み込むときは、このディレクトリを取り込み、プロジェクト固有の CLAUDE.md に役割ごとの権限と対応範囲を書いておくと、各コマンドの回答精度が上がる。コマンド体系をさらに深掘りしたい場合は、Claude Code スラッシュコマンド完全ガイド も合わせて参照するとよい。

gstack の主張をどう読むか——生産性の数字と誇張の切り分け

ここは、gstack を誠実に紹介するうえで最も大切な節だ。gstack の README と ETHOS.md には、目を引く生産性の数字が並ぶ。だが、それらは確認できる事実と、本人の主張とを分けて読む必要がある。

上の図は、gstack の ETHOS.md が掲げる「作業ごとに AI 支援でどれだけ圧縮できるか」の倍率だ。ボイラープレートは約100倍、テストは約50倍、機能実装は約30倍……といった具合に、作業の性質によって効きが違うと主張する。この「作業種別で倍率が変わる」という整理自体は示唆に富むが、数値そのものは gstack の自己申告である点を忘れてはいけない。

誤解のないように言えば、これは gstack を貶めるための注意ではない。Garry Tan は実在の YC CEO であり、gstack は実際に高機能なプロジェクトだ。ただ、当サイトの方針として「誇張・煽りはしない・事実は一次ソースで裏取りする」を貫くため、検証できない生産性の数字を事実として垂れ流さないというだけのことだ。ツールの価値は、他人の生産性倍率ではなく、あなたのプロジェクトでどう効くかで決まる。

では、自分にとっての価値をどう測るか。おすすめは、いきなり全機能を導入するのではなく、手元の小さなタスクで /qa を一度だけ回してみることだ。実ブラウザが立ち上がり、バグを見つけて直し、回帰テストを書くまでを目の前で見れば、README の数字よりよほど確かな判断材料になる。そこで「これは自分の開発フローに効く」と感じたら、/review や /cso、安全機構へと広げていけばいい。逆に、/qa の一巡が自分のプロジェクトにハマらなければ、それ以上深入りする必要はない。

もうひとつ、README には OpenClaw のスター数や、著名エンジニアの引用など、権威づけに使われる数字・逸話も並ぶ。これらも「そう書かれている」という事実と、「それが正しい」という判断は分けて扱うのが安全だ。ツール選びで大事なのは、他人の実績の大きさではなく、自分の課題との相性である。gstack は、その相性を /qa の一巡で手早く確かめられる点で、試すハードルが低いツールだと言える。

まとめ——gstack は誰のためのものか

gstack は、「1人の開発者を、疑似的な開発チームに変える」という明確な野心を持ったツールだ。

向いているのは、Claude Code を既に使っていて「1人でも、チームがやるようなレビュー・QA・出荷の工程をきちんと踏みたい」という開発者だ。ソロの開発者やスモールチームが、人員を増やさずにリリースの質を上げたい——そんな場面で、役割スキルと実ブラウザQAは素直に効く。逆に、まだ Claude Code に慣れていない段階でいきなり全機能を使おうとすると、設備の多さに圧倒される。まずは基本のスプリント（/office-hours→/review→/qa→/ship）から始め、必要に応じて /cso や安全機構を足していくのがよい。

gstack が投げかけているのは、「AIコーディングの次の差は、モデルの賢さではなく”段取り”で決まるのではないか」という問いだ。同じ Claude Code を使っても、工程を役割で構造化する人と、真っ白なプロンプトに向かう人とでは、抜け漏れの量が変わる。モデルの性能がどれだけ上がっても、「何を確認すべきか」を思い出すのは結局は人間の仕事だった——gstack は、その”思い出す”すら仕組みに肩代わりさせようとする。派手な生産性の数字ではなく、/qa が実ブラウザで本当にバグを見つけて直すその地味な瞬間にこそ、gstack の値打ちは表れる。数字に煽られず、まず一巡させてみる——それが、この「AIソフトウェア工場」との正しい付き合い方だ。

参照ソース

・garrytan/gstack（GitHub・MIT）
・gstack ETHOS.md（設計思想・生産性倍率の主張）
・gstack ARCHITECTURE.md（ヘッドレスブラウザ設計）
・Andrej Karpathy 流スキル/CLAUDE.md 運用（gstackが土台に参照）
・Claude Code 完全ガイド2026