シリーズ: Gstack (2/7)
AI アシスタントに「ロール切り替え」が必要な理由：Gstack のコアロジック
こんなシナリオに心当たりがあるかもしれません：
Claude に「このコードをレビューして」と頼みます。長い返答が返ってきて、よく網羅されているように見えます——アーキテクチャの提案、命名規則、いくつかの小さなバグ。その通りに修正してコミットし、2 日後に production で問題が発生。1 時間追いかけてやっと見つけたのは race condition——それが「レビュー済み」のコードの中にありました。
Claude が賢くないわけではありません。あなたが「汎用アシスタント」の頭脳に「偏執的なシニアエンジニア」の仕事をさせていたのです。
この 2 つは、全然違います。
1 つの会話で全部やろうとするコスト
ほとんどの人が Claude Code を使う方法は、すべての問題を同じコンテキストに投げ込むことです：
「この機能のアーキテクチャを設計して。」
「よし、今度は実装を書いて。」
「書き終わった、レビューして。」
「レビューが終わったら PR を開いて。」
すべてのステップが同じ会話の中で行われ、AI はすべてのステップで同じ「モード」で応答します。表面上はスムーズに見えますが、実際には——
アーキテクチャ設計の時、「この機能は本当に作る価値があるか」を十分に問いません。
コードレビューの時、構文やスタイルを見ているのであって、production レベルの failure mode を見ているわけではありません。
PR を開く時、テストが走ったかどうか、メインブランチが sync されているかどうかを確認しません。
各ステップを実行はしましたが、各ステップは 70% しか実行されていません。
Gstack のコア思考：認知モードは切り替え可能
Garry Tan が Gstack を設計した時、彼が問いかけたのはとても根本的な問いでした：
「もし今日、本物の開発チームがいたら、各ロールは何を考えているか？」
CEO が考えているのは：この機能は作る価値があるか？ユーザーの本当の問題は何か？10 倍の効果をもたらすより良い解決策はないか？
Engineering Manager が考えているのは：このアーキテクチャに隠れた failure mode はないか？非同期の境界はどこか？テストカバレッジは十分か？
シニアエンジニアが PR をレビューする時に考えているのは：N+1 クエリ、race condition、trust boundary violation——CI を通過しても production でクラッシュするような問題。
Release Engineer が考えているのは：ブランチは main と sync されているか？テストはすべて通っているか？PR の説明は完全か？
これらのロールは、考える「周波数」がまったく異なります——1 つの汎用プロンプトですべてを呼び出そうとしても、薄まったバージョンしか得られません。
Gstack がやっていることはシンプルです：これらの認知モードを、それぞれ 1 つの skill としてパッケージ化し、slash command で明示的に切り替える。
9 つの Skill、9 つの認知モード
Gstack は現在 9 つのコア skill を提供しています：
| Slash Command | ロール | 問いかけていること |
|---|---|---|
/plan-ceo-review |
Founder / CEO | この機能は作る価値があるか？より良い解決策はないか？ |
/plan-eng-review |
Engineering Manager | アーキテクチャ、データフロー、エッジケース、テストカバレッジ |
/review |
偏執的シニアエンジニア | CI は通るが production でクラッシュする問題 |
/ship |
Release Engineer | Sync、test、push、PR 一気通貫 |
/browse |
QA エンジニア（目あり版） | 本物のブラウザでアプリをクリックし、スクリーンショットで検証 |
/qa |
QA リード + バグ修正 | 問題を見つけ、修正し、検証し、ヘルススコアを出力 |
/qa-only |
QA レポーター | 報告するだけで、コードには手を加えない |
/setup-browser-cookies |
セッションマネージャー | 本物の cookies を headless セッションにインポート |
/retro |
Engineering Manager（振り返り版） | コミット履歴、出荷速度、PR サイズを分析 |
各 skill の背後には、丁寧に設計されたシステムプロンプトがあり、AI がその認知モードで、問いかける質問、チェックする観点、出力のフォーマット——すべてがそのロールにふさわしいものになっています。
なぜ「1 つの超強力プロンプト」ではダメなのか
これは最もよくある質問です：「system prompt に『あなたは CEO、エンジニア、QA、Release Engineer を兼任している』と伝えればいいのでは？」
ダメです。理由は具体的です：ロール間に認知的衝突があり、混ぜると互いに薄め合ってしまうからです。
CEO 思考は「大胆に仮定し、最良の解決策に向かう」；偏執的エンジニア思考は「すべてが失敗すると仮定し、最悪のケースを探す」。この 2 つのモードを同時に開いていると、十分に大胆でも十分に偏執でもない妥協バージョンが得られます——あなたの役に立ちません。
同じ人に同じ会議で、投資家へのピッチと法的リスク審査を同時に担当させないのと同じです——これら 2 つは必要とする思考が根本的に異なり、分けてこそ品質が出ます。
Gstack と通常のプロンプトの違い
直接的な比較で：
通常のやり方：「このコードをレビューしてバグがないか確認して。」
→ Claude が汎用アシスタントモードで一通りスキャンし、いくつかの明白な問題を見つけますが、race condition や N+1 クエリは見逃すかもしれません。
Gstack /review：
→ AI が「偏執的シニアエンジニア」モードに切り替わり、体系的にチェックします：N+1 クエリ、race condition、trust boundary violation、missing index、broken retry logic、stale read——チェックリストがあり、項目ごとに確認し、漏れがありません。
違いは AI の賢さではなく、問いかける質問が違うことです。良い認知モードとは、正しい質問をする能力のことです。
Gstack は万能薬ではない
ここまで言っておいて、Gstack が解決できないことも明確にしておく必要があります：
- 何のプロダクトを作るかを決めてくれるわけではない——あなたはまだ自分が何の問題を解決しているかを知っている必要があります
- プログラミング能力の代替にはならない——あなたはまだ AI が与えるアドバイスを理解できる必要があります
- すべて使うとトークン消費がかなり多い——各ロールに独自のコンテキストがあり、複雑なタスクは素早く燃え尽きます
Gstack に適したユースケース：すでに Claude Code で本番コードを書いていて、より安定した品質保証が欲しい——AI 支援開発に初めて触れる人向けではありません。
メンタルモデルができました。次のステップ：これらの 9 つの skill を実際に動かす。
→ Gstack インストールとクイックスタート：10 分で 9 つの skill をセットアップ
シリーズ総覧に戻る
この記事は Gstack シリーズの第 1 回で、「なぜロール切り替えが必要か」というコアコンセプトの構築を担当しています。完全な読書ルートと他の記事のトピックは Gstack 入門コース に戻って確認してください。