Claude Codeをしばらく使っていると、ある壁にぶつかります。
タスクを投げるたびに「あなたはシニアエンジニアです」と書いたプロンプトを貼り付けたり、レビューを頼んだらコードを書き始めたり、セキュリティチェックを頼んだら実装の提案まで返ってきたり。
「何でもできる」はずなのに、なぜか出力がぶれる。
その問題に対して、Y Combinator CEO の Garry Tan が自分のワークフローをそのままオープンソースにしたのが gstack です。
GitHub での注目度は公開直後から急速に高まっており、複数の情報源で数万から10万超のスター数が報告されています（時期によって数値が異なるため確定値は示せませんが、開発者コミュニティでの関心の高さは明らかです）。
「YC の CEO が実際に使っている」という文脈は信頼感の裏付けになりますが、注目すべきはそこではなく、設計の考え方のほうです。
gstackとは何か——「プロンプトを渡す」から「役割を与える」へ
ひとことで言うと、gstack は Claude Code 向けの スキルパック です。
23 個のツール（スラッシュコマンド）が、CEO・デザイナー・エンジニアリングマネージャー・QA リード・セキュリティオフィサー・リリースエンジニアという 6 つのロールに整理されています。
「プロンプト集と何が違うの？」という疑問が出てくるのは自然です。
プロンプトは「この会話の中で、今だけ、こう振る舞ってください」という一時的なお願いです。
gstack のアプローチは違います。
Markdown のスキルファイルとして ロールを定義し、ツールとして登録する ことで、「何者として振る舞うか」をセッションをまたいで固定します。
以前の記事で紹介した Claude Cowork や Claude Code Remote Control は、複数のエージェントを並列で動かすオーケストレーション層に焦点を当てていました。
gstack が違うのは、その一段下——個々のエージェントが 何を見て・何を判断して・何を出力するか という責務の粒度を、ツール定義レベルで設計している点です。
オーケストレーションの前に、まずロールを固めるという順番の話です。
23 ツール・6 ロールという構成が解決しようとしているのは、要するに「コンテキストの汚染」と「役割の混在」です。
この二つが具体的にどう問題になるのかを、次の節で見ていきます。
6ロールの責務分離——「何でもやるClaude」の限界を超える
「何でもやる」状態の Claude が起こす問題は、使い込んでいると実感しやすいはずです。
たとえば、こんなシナリオです。
長い会話の中でアーキテクチャの相談をして、コードを書いてもらって、最後に「セキュリティ的に問題ないか確認して」と頼む。
すると Claude は、直前のコードを書いた文脈を引きずったまま確認します。
自分が書いたコードを自分でレビューするわけで、甘くなるのは当然です。
コンテキストが汚染されているので、セキュリティオフィサーとして振る舞うべき場面でも、実装者の視点が混入してしまう。
gstack はこの問題を、ロールを分離することで解決しようとしています。
たとえばこの 4 つが実務で効いてくるロールです。
- Engineering Manager（/eng-manager）: アーキテクチャの判断・コードレビュー・技術的負債の検出を担う。「実装してください」ではなく「これは正しい設計か」を問う役割。
- QA Lead（/qa）: 実際に Chromium を起動してブラウザ操作を行い、ログイン状態を保持したままセッションをまたいで高速にテストを続行する。テストコードを書くのではなく、人間が手でやるテストをそのまま自動化する。
- Security Officer（/cso）: OWASP Top 10 と STRIDE に基づいてコードを監査する。誤検知を絞り込む設計になっており、「なんとなく危ないかも」ではなく根拠のある指摘を返す。
- autoplan（複数ロール連携）: CEO・デザイン・エンジニアが順番にレビューするオーケストレーション例。一人で開発していても、複数の視点から順番に検証できる。
ロールを分けることで何が変わるかというと、Claude が「何者として振る舞うか」がセッション開始時点で固定されます。
QA ロールで呼び出した Claude は、実装の提案をしません。
バグを探す人間として振る舞います。
この固定が、出力の一貫性と再現性を生みます。
ツール定義の構造を読む——フロントマターが「役割」を固定する仕組み
gstack のツールは、TypeScript 製のセットアップスクリプトと Markdown のスキルファイルという二層構造になっています。
セットアップスクリプトがインストールと更新を管理して、実際のロール定義は Markdown ファイルに書かれています。
スキルファイルの先頭にあるフロントマターが、Claude の振る舞いを決める核心部分です。
Claude Code のサブエージェント定義では、name・description・tools・model という 4 つのフィールドが基本構造になっています。
以下は、その構造を QA ロールに当てはめて筆者が再現したサンプルです（実際の gstack のスキルファイルの内容とは異なる場合があります）。
---
name: qa
description: >
ブラウザを使った統合テストが必要なとき、
またはUIの動作確認・回帰テストを実行するときに呼び出す。
ログイン状態を保持したままE2Eシナリオを走らせる。
tools: computer, bash, read
model: sonnet
---
あなたはQAリードです。
コードを書くのではなく、実際にブラウザを操作してバグを見つけることが仕事です。
以下の順序でテストを実行してください：
1. ログインフローの確認
2. 主要なユーザーシナリオの通し確認
3. エラー状態の再現
ここで重要なのが description フィールドです。
このフィールドは単なるメモではなく、Claude が 「いつこのツールを自動呼び出しするか」を判断する基準 になります。
「ブラウザを使った統合テストが必要なとき」という記述があれば、Claude はそのコンテキストを検知して自動的にこのロールを選択できます。
tools フィールドでは、そのロールが使えるツールを明示的に制限しています。
QA ロールなら computer（ブラウザ操作）と bash と read だけ。
書き込みや外部 API 呼び出しは含まない。
この制限が「QA は実装しない」という責務の境界を技術的に強制します。
model フィールドも見逃せないポイントです。
gstack では用途に応じてモデルを使い分けています。
アーキテクチャ判断や複雑なセキュリティ監査には重いモデルを、ドキュメント生成や軽いレビューには軽いモデルを割り当てる。
コスト効率と出力品質のバランスを、ロール定義の段階で設計しているわけです。
プロンプトとの構造的な違いはここに現れています。
プロンプトは「お願い」ですが、スキルファイルは 使えるツールの範囲・呼び出し条件・モデルの重さ をまとめて定義した「役割の仕様書」です。
Claude に渡すのではなく、Claude に持たせる——その違いが、出力の再現性につながります。
自分のフローに差し込む——どのロールから始めるか
「23 ツール全部入れてみよう」は、たぶんうまくいきません。
最初から全部使おうとすると、どのロールがどの場面で効くのかが分からないまま、結局使わなくなります。
スモールスタートの考え方はシンプルで、 今一番痛いところから逆算する だけです。
一人で開発していて、コードの品質チェックが後回しになりがちなら /review から始めるのが自然です。
チームで開発していて、設計レビューの質にばらつきがあるなら /eng-manager から入ると効果を感じやすい。
リリース前のバグ検出が課題なら /qa が一番インパクトが出やすいです。
インストール自体は一行で終わります。
git clone https://github.com/garrytan/gstack ~/.claude/skills/gstack
チームへの展開は、セットアップスクリプトとチーム初期化コマンドを使います。
# チーム全体へのインストール
./setup --team
# リポジトリへの組み込み
gstack-team-init
これを実行すると、チームメンバーの Claude Code セッションが自動的に gstack を参照するようになります。
スキルファイルは Markdown なので、フロントマターも本文も自由に編集できます。
ここが実は一番大事なポイントで、Garry Tan の思想をそのまま使う必要はありません。
/cso のセキュリティ監査基準を自社のコーディング規約に合わせて書き換えても構わないし、/eng-manager のアーキテクチャチェックリストを自分たちのスタックに最適化しても構わない。
スキルファイルは 自社のエンジニアリング文化を Claude に教えるドキュメント として機能します。
gstack を使い始めると、自然と「このロールの定義、もう少し変えたいな」という気持ちが出てきます。
そこまで来たら、次のステップは自分でロールを書くことです。
フロントマターの 4 フィールドと、役割指示の Markdown を書くだけで、自社専用のスキルが作れます。
Garry Tan のセットアップを入り口にして、自分たちのワークフローに合った定義を育てていく——それが gstack の一番賢い使い方だと思います。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援を手がけています。
Claude Code を使った開発フローの設計やチームへの AI 導入に関心があれば、お問い合わせページ からお気軽にどうぞ。