AIコーディングあるあるの「次」の話

Claude CodeやCursorでコードを書かせていると、最初はよく動く。ところがしばらくすると、同じ指示を何度も貼り直している自分に気づく。AIが自信満々に嘘をつく。バグを直したら別のバグが生える。レビューすると「そこじゃない」となる。そして、一度うまくいった方法が次回に再現されない。

ここで多くの人は「もっといいプロンプト」を探し始める。これが罠だ。

Qiitaに投稿された樋口悟氏の記事「AIコーディングの本質は『プロンプト』ではなく『仮想開発組織』を作ることだった」は、この罠に対してひとつの明確な答えを出している。AIをひとりの万能アシスタントとして使うのをやめ、役割分担された仮想開発組織として運用せよ、というものだ。

「仮想開発組織」という発想の出どころ

このアプローチの中心にあるのが、Y CombinatorのGarry Tan氏が公開している gstack と、そこで語られる Tokenmaxxing という考え方だ。

gstackは、Claude Code上で /office-hours、/plan-ceo-review、/plan-eng-review、/review、/qa、/ship、/cso、/investigate などの役割別Skillを用意し、AIコーディングを「設計 → 実装 → レビュー → QA → リリース → 学習」という流れに押し込む仕組みだ。GitHub READMEでは、CEO・Designer・Eng Manager・Release Manager・Doc Engineer・QAなどの役割を持つ 23のツール群 と説明されている。

TokenmaxxingはYC公式記事「Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers」でも紹介されている概念で、要は「重要な仕事にはAIのトークンをケチらず大量投入する——ただしコード生成だけでなく、調査・設計・反証・テスト・レビュー・QAにも使う」というものだ。

大事な補足がある。「とにかく全部丸投げ」はTokenmaxxingではない。仕様が曖昧なまま実装させる、テストなしで進める、生成結果をレビューしない——これは記事の言葉を借りれば「ただの暴走」だ。トークンは「コードを書くため」だけでなく、「間違ったコードを書かないために」燃やす。ここが核心になる。

仕組みの核心：SkillとCLAUDE.mdで「プロセス資産」を作る

具体的には、リポジトリに以下の構成を置くことから始まる。

  • CLAUDE.md：AIが常時読む「プロジェクト憲法」。実装前に既存コードを必ず読む、計画外の変更をしない、セキュリティ・課金・計算ロジックは人間確認を求める——といった恒久ルールを書く
  • .claude/skills/*/SKILL.md：/office-hours-ja、/plan-eng-review-ja、/qa-ja など、役割ごとの再利用可能な手順書
  • docs/ 以下：プロダクトビジョン、アーキテクチャ設計、テスト戦略、意思決定ログ（ADR）、振り返り記録

Anthropicの公式ドキュメントでも、Skillは「同じチェックリストや複数ステップ手順を何度も貼るならSkill化せよ」という思想で設計されていると明記されている。常時コンテキストに入れるのではなく、必要なときだけ呼び出す構造だ。

1機能を作るときの標準フローはこうなる。

Issue → /office-hours-ja（課題再定義）
      → /tokenmax-research-ja（事実確認・反証）
      → /plan-eng-review-ja（設計・テスト計画）
      → Implementation
      → /review-ja（スタッフエンジニアレビュー）
      → /qa-ja（ブラウザQA・Playwright）
      → /ship-ja（PR・リリース）
      → /retro-ja（学習・Skill更新）

「AIを実装から始めない」というのが、このワークフローの根幹にある。

ここからは見方の話：これはプロンプト進化ではなく「開発プロセスのSOP化」だ

率直に言うと、この記事が整理していることは「AIを使ったプロンプト術の洗練」ではない。AI時代の標準作業手順書（SOP）をどう作るかという話だ。

人間の開発組織を思い返すと当然のことがある。新人に毎回口頭でルールを説明していたら破綻する。だからオンボーディング資料があり、コーディング規約があり、レビューフローがある。AIも同じで、毎回同じことをプロンプトで説明するのは「組織にSOPがない状態」とほぼ同じだ。

記事が提示する3段階の進化図（Chat型 → Agent型 → Virtual Engineering Org型）は、実務感覚でもしっくりくる。Agent型はかなり便利だが危険、という指摘は正しい。AIは「作ること」に最適化されがちで、品質チェックや設計の問い直しを自発的にはしない。それを構造で強制するのがLevel 3の発想だ。

ただし、留保も必要だ。このアプローチが最も効くのは「繰り返しの多い開発タスク」がある場合だ。プロトタイプ段階で毎回仕様が変わるような環境では、Skill化のコストが回収できない可能性もある。gstackが23ツールを持つGarry Tan氏レベルの運用になるには、それ相応の初期投資が要る。

実務での判断軸と今後の論点

「この記事、自分に関係あるか?」を判断する軸はシンプルだ。同じ指示を3回以上AIに貼ったことがあるなら、関係がある。

まず試せる最小ステップは、CLAUDE.md を1枚書くことだ。プロダクトの目的、触ってはいけい領域（セキュリティ・課金・認可）、テストのルール——これだけでも、AIの出力の安定度が変わる。Skillの整備はその後でいい。

次に問題になるのはコストと知識の非対称性だろう。トークンを「設計・反証・QAにも燃やす」スタイルは、API料金が直接かかる個人開発者には痛い場面もある。また、/plan-eng-review でアーキテクチャを問い直せるのは、そもそも「良い設計と悪い設計の違いを判断できる人間」がレビューに回れる前提がある。AIが出した設計を、AIで承認するだけでは品質は上がらない。

もうひとつ、長い目で見ると、こうしたSKILL.mdやCLAUDE.mdの「工程資産」は、プロジェクトの知的財産になっていく。コードより長持ちするかもしれない。その管理・更新・チーム共有をどうするか——これが次のフェーズで問われる論点になると思っている。

「魔法のプロンプトを探す」のをやめて、「AIが動くプロセスを設計する」に発想を切り替える。それだけで、AI開発の使い方の見え方がだいぶ変わる。

参考元: AIコーディングの本質は「プロンプト」ではなく「仮想開発組織」を作ることだった —— Tokenmaxxing / gstack / Claude Code Skills 実践入門