gstack：Claude Code を仮想エンジニアリングチームに変える 23 の役割別スラッシュコマンド

背景と課題の所在

2026 年 3 月、Andrej Karpathy はポッドキャストで、昨年 12 月からほとんどコードを手で書いていないと語りました。gstack の README はこの発言を冒頭に置いています。ここから新しい問題が見えてきます。モデルがコードの大半を書けるようになると、ボトルネックは「書けるかどうか」から「作業をどう組み立てるか」に移ります。

多くの人にとって、Claude Code との最初の出会いは白紙の入力欄です。同じモデルでも、ある人には数行の補完しか返さず、別の人には機能一式を作り上げます。差はモデルよりも依頼の構造から生まれることが多く、構造がなければ成果は安定しません。レビュー、テスト、リリースといった実チームの規律も現れません。

gstack はこの隙間を狙っています。公開したのは Y Combinator の社長兼 CEO である Garry Tan で、リポジトリは garrytan/gstack、ライセンスは MIT、GitHub の星は約 13.5 万です。作者はこれを毎日使うオープンソースのソフトウェア工場と呼んでいます。想定読者は三つです。自分で出荷したい技術系の創業者、白紙のプロンプトではなく構造化された役割が欲しい Claude Code 初心者、そして全ての PR に厳格なレビューと QA とリリース自動化を求める技術リーダーです。

コアアーキテクチャと技術原理

中心となる考え方は、汎用モデルを責任の明確な複数の役割に分けることです。README には、製品を考え直す CEO、設計を固めるエンジニアリングマネージャー、AI らしい雑な意匠を見抜くデザイナー、本番の不具合を探すレビュアー、実ブラウザを開く QA リード、OWASP と STRIDE の監査を行うセキュリティ担当、PR を出荷するリリースエンジニアが挙げられています。総数は 23 の専門役割と 8 つの補助ツールです。 形式として、gstack にバックエンドサービスも新しい実行環境もありません。README によれば、すべてスラッシュコマンドで、すべて Markdown で、無料で、MIT ライセンスです。つまり各役割は用意されたプロンプトファイルであり、対応するコマンドを呼ぶと Claude Code が読み込みます。この設計には三つの帰結があります。 第一に、導入の敷居が非常に低いことです。ファイルを Claude Code が読める場所に置くだけで、README は設定に約 30 秒と述べています。第二に、監査しやすいことです。挙動はすべて文章なので、一行ずつ読み、編集し、フォークできます。第三に、そして最も重要なのは、強制力がないことです。役割はプロンプトにすぎず、従うかどうかはモデル次第です。型システムもコンパイラもなく、「セキュリティ担当」が本当に監査を完了したと証明する仕組みもありません。

クイックスタートにも同じ分業が表れています。`/office-hours` で作るものを説明し、`/plan-ceo-review` で発想を検証し、`/review` で変更のあるブランチを確認し、`/qa` でステージング URL や隔離したローカルの API、CLI、ジョブ、Webhook を試験します。順序は実際のチームを模しています。要件の整理、計画のレビュー、コードのレビュー、テスト、リリースです。

実用性と検証結果

このセッションで見えるスキル一覧から、コマンドがソフトウェアの生命周期の多くの段階を覆っていることが分かります。発想整理（office-hours）、戦略と設計とデザインのレビュー（plan-ceo-review、plan-eng-review、plan-design-review）、デザインシステム（design-consultation）、原因調査（investigate）、テスト（qa、qa-only）、コードレビュー（review）、見た目の監査（design-review）、出荷（ship、land-and-deploy）、文書更新（document-release）、振り返り（retro）、安全ガード（careful、freeze、guard）です。1 コマンドあたり約 100 ミリ秒とされるヘッドレスブラウザも QA とスクリーンショットを支えます。

特に注目すべきは QA の役割です。多くの AI コーディングの流れはコードを書き終えた時点で止まります。gstack は実ブラウザを開いて画面の状態を確かめるよう求めます。「動くと思う」を「動くのを見た」に置き換えるもので、幻覚への現実的な備えです。careful、freeze、guard といったガードも有用で、`rm -rf` や強制プッシュの前に警告したり、編集範囲を一つのディレクトリに限定したりします。

はっきり述べるべき点があります。README で最も目立つ数字はすべて作者本人のものです。2026 年の論理的なコード変更速度は 2013 年の約 810 倍で、1 日あたり 11,417 行対 14 行だと報告しています。4 月 18 日までの 2026 年は 2013 年一年分の 240 倍に達したとも述べ、対象は公開と非公開を合わせた 40 のリポジトリです。AI により単純な行数が膨らむことは作者も認め、補正方法をまとめた文書を示しています。それでも、第三者による再現はなく、非公開リポジトリは外部から確認できません。コード量の増加は価値の増加と同じではなく、成果を gstack だけに帰すこともできません。当方は対照実験を行っていないため、具体的な倍率の改善を主張することはできません。

業界への影響と今後の展望

gstack の意義はアルゴリズム上の突破ではなく、それが示す実践にあります。チームの工程を、共有できるプロンプト一式として符号化するというやり方です。コーディング規約を lint 設定に書き、デプロイを CI スクリプトに書いてきた流れと同じ系統で、対象がエージェントに変わっただけです。約 13.5 万の星は、すぐ使えるエージェント用ワークフローへの強い需要を示しています。

一方でリスクも見えます。役割プロンプトは画一的になりやすく、実際のプロジェクトは制約が大きく異なるため、そのまま写すと中身のない形式的なレビューになり得ます。検証が強制されないので、レビュー系コマンドの結論は人が確かめる必要があります。さらに、コマンドは Claude Code を前提に作られており、別のエージェントへ移すには書き直しが要ります。

今後の方向は二つ考えられます。一つは、役割プロンプトを決定的な実検査につなぐことです。たとえばセキュリティ役にスキャナを呼ばせ、文章だけでなく他者が検証できるログを出させます。もう一つは計測で、役割ありとなしの欠陥率や手戻り率を、サンプルごとの対応データで比較することです。そうした証拠が出るまでの慎重な見方はこうです。gstack は設計がよく、費用がほとんどかからず、試す価値のあるワークフローの雛形です。ただし生産性の約束は作者の自己申告であり、検証済みの結論ではありません。