gstackとは：Y Combinator CEO発のClaude Code専門家チーム化スキル

公開からわずか48時間で10,000スター。 2026年3月現在、GitHub Stars 44,000超。

Y Combinator CEOのガーリー・タン（Garry Tan）氏が公開したClaude Codeスキル「gstack」が、開発者コミュニティを揺るがしています。

Claude Codeを使っていて、こんなもどかしさを感じたことはないでしょうか？

「レビューして」と頼んだら変数名の指摘ばかり返ってきた。

「テストして」と言ったらテストコードは書いてくれたが、実際にブラウザで動かしてはくれなかった。

何でもできるはずなのに、どの仕事も「あと一歩」足りない。

これ、めちゃくちゃイライラしますよね。

汎用AIを使ったことがある人なら、この「惜しい感」に一度はぶつかっているはずです。

gstackは、その「あと一歩」を埋めるために生まれました。

約28個のスラッシュコマンドを追加し、汎用AIアシスタントを「専門家チーム」に変えるオープンソースのスキルセットです。

計画、レビュー、QA、セキュリティ監査、デプロイまで、ソフトウェア開発のあらゆるフェーズを専門家の視点でカバーします。

タン氏自身の言葉がこのツールの本質をよく表しています。

That is not a copilot. That is a team.

「補助ツール」ではなく「チームメンバー」。1人で開発しているのに、まるで専門家チームがいるかのようにClaude Codeを機能させます。

これがgstackの核心です。

作者ガーリー・タンとは

ガーリー・タンは、世界で最も影響力のあるスタートアップアクセラレーター「Y Combinator」のPresident & CEOです。

YCはDropbox、Airbnb、Stripeなど数々のユニコーンを輩出してきた組織で、その現CEOが自ら開発ツールを作って公開したという事実自体が異例です。

タン氏はエンジニア出身で、Palantirの初期社員として勤務した後、ブログプラットフォームPosterousを共同創業（2012年にTwitterが買収）。 Initialized Capitalの共同創業者でもあります。

単なる経営者ではなく、現役で手を動かす技術者でもあります。

ここがポイントです。

gstackは

「エンジニアリングを知らない経営者の理想論」ではなく、

「毎日コードを書いている人間が、自分の痛みを解決するために作ったツール」。

この違いは、使ってみるとすぐにわかります。

gstackが生まれた背景と「60日間60万行」の実績

gstackは「自分がほしかったツール」から生まれました。

GitHub READMEによると、タン氏はYC CEOの業務をこなしながら、60日間で600,000行以上のプロダクションコードをgstackを使って生成したと公表しています。

日あたり10,000〜20,000行というペース。

60日で60万行。

正直、最初にこの数字を見たとき「本当に？」と疑いました。すごすぎです。

一人のエンジニアとしては明らかに桁が違います。

しかしgstackのポイントは「量」だけではないです。

計画段階でスコープを検証し、レビューで本番バグを検出し、QAで実ブラウザテストを行い、デプロイ後の監視まで一貫して行います。

量を出しながら質を落とさない、というやつです。

その仕組みが約28のコマンドに凝縮されています。

つまり、「60万行書けた」ではなく「60万行書いても品質が崩壊しなかった」というのが本当のすごさです。凄まじすぎますね。

なぜGitHub 4.4万スターを突破したのか：gstack爆発的人気の理由

GitHub - garrytan/gstack: Use Garry Tan's exact Claude Code setup: 15 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA · GitHub

github.com

公開48時間で1万スター達成

gstackがGitHubに公開されると、開発者コミュニティは即座に反応しました。

48時間で10,000スターという数字は、オープンソースプロジェクトとしても異例の立ち上がりです。

2026年3月24日時点ではスター数44,200超、フォーク5,500以上に達しています。

この爆発的な反応には、ちゃんと理由があります。

ひとことで言えば、Claude Code自体の普及です。

Anthropicが2025年にリリースしたCLIベースの開発エージェント「Claude Code」は、ターミナルからAIにコードを書かせる新しいワークフローを提示してくれました。

しかし、多くの開発者が同じ壁にぶつかっていたんです。

素のClaude Codeは汎用エージェントで、「何でもできるが、特定の役割に最適化されていない」んです。

レビューを頼めば表面的な指摘が返ってきます。

セキュリティチェックを頼めば偽陽性だらけのレポートが出てきます。

「惜しい。あとちょっとなんだけど......」という声がコミュニティに溢れていました。

gstackは、その声に対する明確な回答です！

「スキル」という拡張機構を使って、Claude Codeに専門家の思考パターンを注入してくれます。

MITライセンスで完全無料という点も、普及を後押ししました。

TechCrunchも報じた賛否両論

gstackの急速な拡散はTechCrunchでも報じられました。

「Why Garry Tan's Claude Code setup has gotten so much love, and hate」

Why Garry Tan's Claude Code setup has gotten so much love, and hate | TechCrunch

techcrunch.com

という記事が公開され、賛否両方の声が紹介されています。

賛成側の声として多いのは「成熟した、意見のあるシステムです。

実際に使い込んでいる人が作ったものだとわかります」という評価です。

確かに、gstackの各コマンドは抽象的なプロンプトの寄せ集めではなく、実際の開発ワークフローに沿った具体的な指示で構成されています。

一方で批判もあります。

「似たようなプロンプトセットは多くの開発者が自作しています」「YC CEOの知名度で過剰に注目されているだけでは？」という声も実はあります。

『それ、自分でもやってるけど？』と思った人もいるかもしれません。

これは一定の真理を含んでいます。

しかし、gstackの価値は個々のプロンプトの新規性にあるのではなく、約28のコマンドが一貫したワークフローとして統合されている点にあります。

料理に例えるなら、個々の食材は手に入るものばかりでも、レシピとして組み立てたときの味が違います。

パーツ単体の新しさではなく、組み合わせたときの体験が違います。

そこが「自作プロンプト集」との決定的な差なんです。

gstackの設計思想：「汎用AIから専門家チームへ」の転換

役割固定がAIの出力精度を上げる仕組み

gstackの設計を理解するうえで、一つ腹落ちしておきたいポイントがあります。ずばり「なぜ役割を固定するとAIの出力が良くなるのか」です。

汎用AIに「コードレビューして」と頼むと、スタイルの些末な指摘からアーキテクチャの問題まで、あらゆることを一度に指摘しようとします。

結果として、どの指摘も浅くなりがちなんですよね。

レビューのたびに「知ってるよ、そういうことじゃなくて......」と思った経験、Claude Codeユーザーなら一度はありますよね？

ここが面白いところで、gstackの/reviewコマンドは「偏執的なスタッフエンジニア」という役割を明確に設定します。

CIでは合格するが本番で問題になるような潜在バグに焦点を当て、スタイルの些末な指摘は意図的にスキップします。

この「やらないことの定義」が、出力の精度を劇的に変えてくれます。

同様に、/csoはセキュリティ専門家の視点に特化しています。

OWASP Top 10やSTRIDE脅威モデリングのフレームワークに沿って分析し、8/10以上の確信度がある問題のみを報告します。

17種類の偽陽性パターンを除外するフィルターも備えており、ノイズの少ない実用的なセキュリティレポートを生成します。

「何を見るか」ではなく「何を見ないか」を定義する。これが専門家の本質です。

いわば、優秀な専門医が「この症状はうちの専門外」と即座に切り分けるのと同じです。

これが専門家と汎用ツールの本質的な違いであり、gstackの各コマンドはこの原則を徹底することで専門家としての精度を実現しています。

では、この専門家たちがどう連携するのか。次のセクションでワークフロー全体を見ていきましょう！

Think → Plan → Build → Review → Test → Ship → Reflectの7ステップ

gstackのもう一つの面白い点は、約28のコマンドがバラバラに存在するのではなく、7つのフェーズに沿って設計されていること。これがめちゃくちゃよくできているんです。

1. Think --- /office-hoursで「この機能は本当に必要か？」を問い直す
2. Plan --- /plan-ceo-review、/plan-eng-reviewで戦略とアーキテクチャを固める
3. Build --- Claude Codeがコードを書く（gstack自体のコマンドではないが、ワークフローの中核）
4. Review --- /reviewで本番バグを検出する
5. Test --- /qaで実際のブラウザを使ってテストする
6. Ship --- /shipでPR作成、/land-and-deployでマージ・デプロイ
7. Reflect --- /retroで振り返りと改善点の抽出

各コマンドが前のフェーズの出力をコンテキストとして引き継ぐため、フェーズ間の情報のロスが少ないです。

計画段階で検討したエッジケースが、レビュー段階で自動的にチェック項目に反映されます。フェーズをまたいでも文脈が途切れません。

この連携感が、個別にプロンプトを打つのとは決定的に違う体験を生み出してくれます。

gstack全コマンド解説：約28の専門家スキルの中身

gstackの約28コマンドをフェーズごとに整理して解説していきます！

計画フェーズ（/office-hours, /plan-ceo-review, /plan-eng-review, /plan-design-review）

特に注目してほしいのが、/office-hoursです。

多くの開発者って、「何を作るか」を決めた後にすぐコーディングに取り掛かりますよね。その衝動、痛いほどわかります。

しかしgstackは、その前に「本当にそれを作るべきか？」を突きつけてきます。YCの投資判断で鍛えられたタン氏ならではの設計ですよね。

開発者にとって、「作らない判断」って最も難しい判断の一つじゃないですか？

/office-hoursはその判断をAIとの対話で構造化してくれます。

つまり、「思いつきで作り始めて3日後に捨てる」という、あの虚しい体験を未然に防いでくれるわけです！

/autoplanは、個別のレビューを手動で回す手間を省いてくれる便利なコマンドです。

CEO→デザイン→エンジニアリングの順にレビューが自動実行され、すべてのフェーズを通過した計画だけが実装に進みます。

開発・レビューフェーズ（/review, /investigate, /design-review）

/reviewは、gstackの中でも特に評価の高いコマンドです。

一般的なAIコードレビューが「変数名が長い」「コメントがない」といった表面的な指摘に終始しがちなのは、多くの開発者が身をもって知っているはずです。

gstackの/reviewはそうした指摘を意図的にスキップします。

代わりに、レースコンディション、エッジケースの未処理、セキュリティ上の見落としなど、本番環境で実害が出る問題にフォーカスします。

「スタイルガイド警察」ではなく「本番障害を未然に防ぐスタッフエンジニア」。

この役割の違いが、レビュー体験をまるで別物に変えてくれます。

正直、この違いを体験すると「今まで何を見てもらってたんだ」って思いますよ。

テスト・QA・セキュリティフェーズ（/qa, /browse, /cso, /benchmark）

/qaと/browseは、正直に言ってかなり衝撃的です。

Claude Codeの「MCP（Model Context Protocol）」を活用して実際のブラウザを操作します。

AIがコードを読むだけでなく、実際にアプリケーションを開き、ボタンをクリックし、フォームに入力し、スクリーンショットを撮ります。

「コードを読んでレビューする」から「実際に動かして確認する」へ。

これは従来のAIコードレビューにはなかった次元の機能です！

「え、AIがブラウザ操作までしてくれるの？」と思うかもしれませんが、本当にやってくれます。しかも~100ms/コマンドという速さで！

/csoの偽陽性除外も、実用上の大きなポイントです。

セキュリティスキャンを回したことがある人なら激しく共感してもらえると思いますが、最も困るのは大量の偽陽性に埋もれて本当の問題を見逃すことですよね。

gstackは17種類の一般的な偽陽性パターンを事前に除外し、8/10以上の確信度がある指摘のみを報告します。

「ノイズだらけで結局読まなくなる」という落とし穴を、設計レベルで回避しています。

では、ここまでの開発・テストを経たコードをどうリリースするのか。ここからいよいよ本番です！

リリース・デプロイフェーズ（/ship, /land-and-deploy, /canary, /retro）

/shipから/land-and-deploy、/canaryの流れは、「コードを書いたら終わり」ではなく「本番で正常に動いていることを確認するまでが開発」という思想を体現しています。

デプロイ後に/canaryでエラーを監視し、問題がなければ/retroで振り返ります。

ここが地味にすごいんですよ。この一連のフローが1つのスキルセットに統合されています。

個別にプロンプトを書いて同じことをやろうとすると、フェーズ間のコンテキストが途切れてしまいます。

「さっきのレビューで指摘した項目、デプロイ前に全部直ったっけ？」がわからなくなりますよね。

あの「あれ、どこまでやったんだっけ」問題です。gstackはその断絶を、ワークフロー統合という設計で解消しています。

ユーティリティ・安全装置（/careful, /freeze, /guard, /codex）

AIにコードを大量に書かせるとき、正直ちょっと怖くないですか？

「意図しないファイルを消されたらどうしよう」「うっかりforce-pushされたら......」。この不安、AIエージェントを本格運用している人ほど強いはずです。

/guard（/careful + /freeze）は、そのための安全ネットです。

意図しないファイルの削除やforce-pushを防ぎ、編集範囲を指定ディレクトリに制限できます。AIの自律性を高めつつ、致命的なミスを防いでくれます。

いわば、車のアクセルとブレーキを同時に装備する発想です。

/codexも意外で面白い。

ClaudeのレビューをOpenAIのCodexで二重チェックするという、AIベンダーをまたいだクロスレビューです。

「1社のAIを信じすぎない」という実践的な知恵が、コマンドとして組み込まれています。この割り切りの良さが、いかにも現場で手を動かしている人の発想だと思いませんか。

gstackのインストール方法：30秒セットアップ手順

前提条件（Claude Code、Git、Bun v1.0+）

gstackのインストールには以下が必要です。

• Claude Code --- Anthropicが提供するCLI開発エージェント（有料プラン必要）
• Git --- バージョン管理ツール
• Bun v1.0以上 --- JavaScript/TypeScriptランタイム（Windowsの場合はNode.jsでも可）

Claude Codeがまだインストールされていない場合は、先にAnthropicのサイトからセットアップを済ませておきましょう。

グローバルインストールとプロジェクト別インストール

インストールは拍子抜けするほど簡単です。ターミナルで以下の1行を実行するだけです。

グローバルインストール（全プロジェクト共通）:

git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

これだけで、すべてのプロジェクトでgstackのコマンドが使えるようになります。所要時間は約30秒。30秒で「専門家チーム」が手に入ります。試さない理由が見当たりません！

プロジェクト別インストール（特定のプロジェクトのみ）:

cp -Rf ~/.claude/skills/gstack .claude/skills/gstack && rm -rf .claude/skills/gstack/.git && cd .claude/skills/gstack && ./setup

プロジェクト別にインストールすると、プロジェクトごとにgstackの設定をカスタマイズできます。チームで共有する場合はこちらが推奨されます。

Codex・Cursor等の他ホストへの対応

gstackはClaude Code以外の環境にも対応しています。

# OpenAI Codex CLI対応
./setup --host codex

# Cursor/Gemini CLI対応（自動検出）
./setup --host auto

--host autoを使えば、使用中のエディタやCLIツールを自動検出して適切な設定を行ってくれます。

gstackの実践ワークフロー：機能開発を一気通貫で回す例

gstackの真価は個々のコマンドではなく、それらを連携させたワークフローにあります。さて、ここからが一番ワクワクするパートです！

公式READMEに記載されている実践例をもとに、典型的な開発フローを見ていきましょう。

/office-hours → /plan-ceo-review → /plan-eng-review で計画を固める

たとえば「日次ブリーフィングアプリを作りたい」とClaude Codeに伝えるところから始まるケースがあります。

まず/office-hoursを実行すると、Claude Codeは複数の質問を投げかけてきます。

「誰がこのアプリを使うのか」「既存の代替手段は何か」「最もリスクの高い仮定は何か」といった、YCのオフィスアワーで実際に聞かれるような質問です。

この事例では、Claudeが「日次ブリーフィングアプリ」を「パーソナルチーフオブスタッフAI」に再構成し、見落とされていた5つの機能を抽出、4つの前提に挑戦しました。「自分では気づかなかった視点」がAIとの対話から出てきます。

コーディングを始める前に、作るべきものの解像度が格段に上がる瞬間です。この「あ、そっちのほうがいいじゃん」という体験は、一人で考え込んでいても起きません。

次に/plan-ceo-reviewでスコープを検証します。

拡大モードと縮小モードの2つがあり、「ビジョンを広げるべきか、絞り込むべきか」を判断できます。

最後に/plan-eng-reviewでアーキテクチャ、データフロー、エッジケース、テスト計画をロックインします。ここで固まった計画が、以降のすべてのフェーズのベースラインになります。

コーディング → /review → /qa でレビュー・テスト

計画が固まったら、Claude Codeにコードを書かせます。

公式READMEの事例によると、約8分で11ファイル・2,400行のコードが生成されました。

コードが書けたら/reviewを実行します。

スタッフエンジニアの視点で本番バグを検出し、明らかな問題は自動で修正してくれます。

続いて/qa https://staging.myapp.comでステージング環境に対して実ブラウザテストを行います。

実際にChromiumが起動し、画面をクリックし、フォームに入力し、スクリーンショットを撮影します。AIが「コードを読む」だけでなく「実際に動かして確認する」ステップです。ここまでやってくれるAIツールは、現時点ではかなり限られています。

/ship → /land-and-deploy → /retro でリリース・振り返り

テストが通ったら/shipでPRを作成します。

メインブランチとの同期、テストの再実行、プッシュ、PR作成までを一括で行います。

/land-and-deployでマージからデプロイ、本番環境の健全性確認までを一気通貫で実行します。デプロイ後は/canaryで監視し、問題がないことを確認します。

最後に/retroで振り返りを行います。このコマンドは単なるサマリーではなく、貢献者一人ひとりへの称賛を含む「チームを意識した振り返り」を生成してくれます。

ソロ開発でも、AIとの協働を振り返ることで次のスプリントに改善を反映できます。

計画からデプロイ、振り返りまで。

従来なら数時間から数日かかっていた一連の作業が、一握りのコマンドで完結します。この体験を一度味わうと、素のClaude Codeには戻れなくなるかもしれません。

gstackの評価：メリット・デメリットと向いている開発スタイル

メリット（精度向上、思考の強制切り替え、ワークフロー統一）

AIの出力精度が上がる。

役割を固定することで、各コマンドが「やるべきこと」と「やらないこと」を明確に定義しています。

汎用プロンプトで起きがちな「広く浅い出力」を回避できます。

言い換えれば、「何でも70点」だったAIが「特定分野で90点」を出せるようになります。

この差は、実際の開発では天と地ほど違います。

思考の強制切り替えが起きます。

/office-hoursで「本当に必要か？」を問い、/plan-ceo-reviewで「スコープは適切か？」を検証し、/reviewで「本番で壊れないか？」をチェックします。

開発者自身の思考が、各フェーズで異なる視点に強制的に切り替わります。

一人で開発していると視野が狭くなりがちですが、gstackはその視野を意図的に広げてくれます。これは、いわば一人でブレインストーミングをやれる仕組みです。

ワークフローが統一されます。

個人のプロンプトスキルに依存せず、チームで一貫した開発フローを実現できます。

新しいメンバーがチームに加わっても、gstackのコマンドに沿えば同じ品質のプロセスを踏めます。

安全装置が組み込まれています。

/careful、/freeze、/guardといった安全コマンドにより、AIに大きな権限を渡しても致命的なミスを防げる設計になっています。

デメリット（トークン消費、学習コスト）

トークン消費が増える。

gstackの各コマンドは詳細なシステムプロンプトを含むため、1回の実行あたりのトークン消費量は素のClaude Codeより多くなります。

特に/autoplanのようなパイプラインコマンドは、複数のレビューを連続実行するため消費が大きくなります。

ただし、「本番障害を1件防げたら元が取れる」と考えれば、このコストは保険料のようなものです。

コマンドの学習コストがあります。

約28個のコマンド名と用途を一度に覚える必要はない。

日常的に使うコマンドは/review、/qa、/shipあたりに集約されるため、まずはこの3つから始めれば十分です。

『え、それだけでいいの？』と思うかもしれませんが、本当にそれだけで効果を実感できます。

Claude Codeの有料プランが前提。

gstack自体はMITライセンスで無料ですが、Claude Code自体の利用にはAnthropicの有料プランが必要です。

向いているケース・向いていないケース

向いているケース:

• ソロ開発者や少人数チームで、レビュアーやQA担当がいない環境
• MVPの高速開発で、計画からデプロイまでを一人で回す場面
• Claude Codeを日常的に使っていて、ワークフローを体系化したい開発者
• セキュリティやパフォーマンスの見落としを減らしたいプロジェクト

向いていないケース:

• Claude Codeをまだ使っていない（まずClaude Code自体の習熟が先）
• 大規模チームで既にCI/CDパイプラインとレビュー体制が確立されている（gstackが代替するものではなく、補完するもの）
• トークンコストを極力抑えたい場合

gstackと他のClaude Codeスキルの比較

Claude Code向けのスキルセット・プロンプト拡張は、gstack以外にも存在します。代表的なものとの違いを整理しておきましょう。

gstack vs. SuperClaude

SuperClaudeはgstackと同様にClaude Codeにスラッシュコマンドを追加するプロジェクトですが、設計思想が異なります。

gstackは「開発フロー全体をカバーする垂直統合」、SuperClaudeは「多様なタスクへの水平拡張」と理解するとわかりやすいです。開発者がClaude Codeをメインの開発ツールとして使うなら、gstackの方が実務に直結した機能を提供してくれます。

gstack vs. 自作プロンプト

「自分でCLAUDE.mdにプロンプトを書けばいいのでは」という意見もあります。実際、そのアプローチは有効です。しかし以下の点でgstackに利点があります。

• 統合されたワークフロー: 個別のプロンプトは各フェーズを孤立して扱いがちですが、gstackは各コマンドが前後のフェーズを意識して設計されています
• メンテナンス: gstackは/gstack-upgradeで最新版に追従できます。自作プロンプトは自分で更新する必要があります
• 実績ベース: 60日間・60万行の実開発で磨かれたプロンプトは、理論上の設計とは異なる実用上のノウハウを含む

もちろん、gstackをそのまま使いつつ、プロジェクト固有の要件はCLAUDE.mdで追記する、というハイブリッドが現実的な運用です。「gstackでベースを固め、自分のプロジェクトに合わせてカスタマイズする」が最も実践的なアプローチだと思います。

よくある質問（FAQ）

gstackは無料で使えますか？

gstack自体はMITライセンスのオープンソースで完全無料です。GitHubからクローンしてセットアップするだけで使い始められます。ただし、gstackを実行するためにClaude Codeが必要で、Claude Code自体はAnthropicの有料プランが前提となります。

Claude Codeなしでgstackを使えますか？

./setup --host codexでOpenAI Codex CLIに、./setup --host autoでCursor等に対応できます。ただし、gstackの各コマンドはClaude Codeとの連携を前提に設計されており、他のホストでは一部機能が制限される可能性があります。まずClaude Code環境での利用が推奨されます。

gstackは日本語に対応していますか？

gstackのコマンド自体は英語で記述されていますが、Claude Codeへの指示（プロンプト）に日本語を混在させることは可能です。ただし、gstackの出力（レビューコメント、計画文書等）は基本的に英語で生成されます。日本語出力が必要な場合はCLAUDE.mdに「レスポンスは日本語で」という指示を追加することで対応できます。

gstackのコマンドはどこで確認できますか？

GitHubリポジトリ（https://github.com/garrytan/gstack）のREADMEに全コマンドの一覧と説明が記載されています。インストール後は~/.claude/skills/gstack/ディレクトリ以下の各.mdファイルを参照すると、各コマンドの詳細なプロンプト内容を確認できます。

gstackの/reviewと通常のAIコードレビューは何が違いますか？

通常のAIコードレビューは「コメントがない」「変数名が長い」といったスタイル上の指摘が多くなりがちです。gstackの/reviewはそうした指摘を意図的にスキップし、レースコンディション、エッジケースの未処理、セキュリティ上の見落とし等、本番環境で実害が出る問題のみにフォーカスします。「偏執的なスタッフエンジニア」という役割設定がノイズを排除し、本質的な問題だけを浮かび上がらせます。

まとめ：gstackが示すAI開発の新しい形

gstackは単なるプロンプト集ではありません。「AIを汎用ツールとして使う」から「専門家チームとして使う」へのパラダイムシフトを、約28のスラッシュコマンドという具体的な形で実装したものです。

Y Combinator CEOという立場のガーリー・タン氏が、自ら60日間・60万行のコードを書く中で磨き上げたワークフローが、MITライセンスで誰でも無料で使えます。GitHub 44,000スターという数字は、開発者コミュニティがこのアプローチに強い共感を示した証拠です。

gstackを試すのに必要な時間は30秒のインストールだけです。Claude Codeを使っているなら、まずは/office-hoursか/reviewから始めてみてください。汎用AIが「チーム」に変わる感覚を、きっと実感できるはずです！

gstackのGitHubリポジトリはこちら: https://github.com/garrytan/gstack