ローカルにAIチームを作って、サイドプロジェクトが自然消滅するのを防いだ

私のGitHubには墓場があります。

いくつかの個人プロジェクトは、どれも同じライフサイクルをたどります。アイデアを得る、フロントエンドを書く、GitHubにプッシュする、Vercelにデプロイする。すると静的ページが現れる。……そしてそれで終わり。

時間がなくなったからではありません。コードが難しくなったからでもありません。ある日、プロジェクトを開いたときに、本当に次に何をすればいいのか分からないことに気づくからです。どの機能を作るべきか、そもそも作る価値がある機能なのか、30分も自分の判断を疑い続けずにUIの決定をどう下すのか。

私はエディタを見つめてから、閉じます。

この記事は、私がそれをどう直したかについてです。もっと規律を持ったからではありません。足りなかったのは「構造」でした。

実際の問題：役割が消える

プロのチームで仕事をするとき、私は「次に何をすればいいのか」という問題に悩まされることはありません。

どのスプリントも始まる前に、IPM（Iteration Planning Meeting：イテレーション計画会議）を実施します。ストーリーカードをレビューし、見積もりを行い、必須（must-have）とあったらよい（should-have）を分けます。重要な機能が動き出す前にはFeature Kick-off（機能キックオフ）があり、BAが要件を明確にし、QAがテストシナリオを特定し、UXがインタラクションの仕様を固めます。誰かが自分のエディタを開く前に、すべてです。

そして開発の間は、すべてのストーリーカードが複数の観点から突き返されます。開発者として、私は技術的に実現可能か、時間コストはどうか、チームをまたぐ依存関係はあるかを論じます。PMは、その機能がそもそもスプリントに入れるに値するのかを問いかけます。BAは、曖昧な説明を具体的な受け入れ基準に落とし込みます。QAは、他の誰もまだ考えていないようなエッジケースについて、先に質問します。

これらはプレッシャーには感じませんでした。それは、異なる機能的レンズを持つ人たちが同じ問題を見たときに起きる「ただのこと」でした。

ソロのサイドプロジェクトでは、これらのレンズは全部消えます。「今この瞬間に本当に最重要なのはこれか」を誰も聞かない。「ここでユーザーの本当のゴールは何か、あなたのものではなく」を誰も聞かない。「これが失敗したらどうなるのか」を誰も聞かない。

質問が投げられない。プロジェクトは流れていく。やがて止まります。

ある日、私はこう考えるようになりました。もし自分のチームがこのプロジェクトをやっていたら、彼らはどう考えるだろう？ この問いが、今私がやっていることにつながりました。

セットアップ：Gitignoredなチーム

プロジェクトのルートに2つのフォルダを作り、.gitignoreに追加します：

your-project/
├── .gitignore          # includes /team/ and /planning/
├── team/               # role prompt files
│   ├── PM.md
│   ├── BA.md
│   ├── UX.md
│   ├── TL.md
│   └── QA.md
├── planning/           # iteration planning
│   ├── epics.md
│   └── story-cards/
│       ├── epic-1/
│       └── epic-2/
└── src/                # actual code

これらのフォルダはリポジトリに入りません。これはプロジェクトのアウトプット層ではなく思考層です。

各ロールファイルには短い責務の定義があり、時間とともに判断が積み重なっていきます。ロールが狭いままでいるのは意図的です：

この制約が重要です。PMが技術的な意思決定もしてしまうなら、役割はその目的を失います。価値は、すべてをカバーする一つの観点から生まれるのではなく、異なる機能的な観点の間にある摩擦から生まれます。

2つのプロンプトモード：発散してから収束

AIをロールプレイに使うときの最も一般的なミスは、すべてに同じプロンプトを使ってしまうことです。私は2つの明確に分けたモードを維持しています。

ブレインストーミングモード

使うタイミング：方向性がはっきりしないとき。何かを決めてしまう前に、見落としをあぶり出したいとき。

# Brainstorm Session

## Project context
[現在のプロジェクトを説明する1〜2文]

## Current idea / question
[私が検討していること—曖昧でもよい]

## Each role, please respond:

**PM**: この状況で解決している「本当のユーザー課題」は何ですか？
今の段階で作る価値はありますか？1つだけ残すなら、それは何ですか？

**BA**: 分解してください—ここにはどんな前提が隠れていますか？
境界はどこにありますか？どんな条件で失敗しますか？

**UX**: このシナリオにおけるユーザーの実際のゴールは何ですか？
提案されているインタラクションは、ユーザーの頭の中のモデルと衝突しませんか？

**TL**: 技術的にどれくらい実現可能ですか？
隠れた複雑さはありませんか？現在のアーキテクチャはそれを支えられますか？

**QA**: 最も壊れやすいポイントはどこですか？
いま解決すべきエッジケースは何ですか？

---
ルール：各ロールは質問をし、リスクだけを提示すること。解決策は出さない。
目的：見落としをあぶり出す。まだ収束しない。

下に書かれたルールは「前提の柱」です。ロールに解決策を出してよいとすると、AIはすべてを1つの統合された回答に押し込めてしまい、複数の観点による摩擦が消えます。

収束モード

使うタイミング：方向性が決まったとき。これ以上の分析ではなく、判断が必要です。

# Convergence Session · [Role Name]

## I need you to reason as [UX / PM / BA / TL / QA]

## What's already decided
[1〜2文—決定済みの方向性]

## The specific question
[質問は1つだけ。2つ以上にしない。]

## Constraints
- [時間／技術／リソースの制限]
- [変更できない意思決定]

## Output format I need
- 明確な推奨（「状況による」なし）
- 理由は1〜2文で
- トレードオフがあるなら、何を諦めて、なぜそうしたのかを名前で示して

「状況によるは禁止」の制約が鍵です。ロールはすでに文脈と制約を持っています。選択肢のメニューを並べるのではなく、判断を出すべきです。

これは実際どんな感じになるのか：デザインシステム

私がこれを最もはっきり感じたのはUXの一貫性の部分です。しかも、AIコーディングが最も静かにダメージを与える場所でもあります。

AIで直接コードを書くと、「このコンポーネントが動くか」をAIは解いてくれます。でも誰も「このコンポーネントが、すでにあるものと整合しているか」を追跡していません。最初のカードはaspect-ratio: 16/9。次のカードは忘れて4:3。ページが揃う頃には見た目の不一致が生まれ、直すにはCSSの値を変えるだけでは済まず、すべてのコンポーネントに触れることになります。

これが私の言う「プロジェクトにおけるAI感覚」です。技術的に間違っているわけではないのに、なぜかうまくまとまらない。デザイン言語がセクションごとに少しずつ違うのは、各セクションが他と参照せずに生成されているからです。

私の解決策は、UX.mdを生きたデザインシステムのドキュメントにすることです。プロジェクトの早い段階で、コアとなる仕様を確立するために収束セッションを実行します：

# UX · Design System

返却形式: {"translated": "翻訳されたHTML"}## 画像
- カードの表紙：aspect-ratio 1:1
  （出典は第三者のアップロードであり、比率は制御されていません — 正方形が最も不具合に強いです）
- 詳細ページのヒーロー：aspect-ratio 16/9

## 間隔
- コンポーネントのパディング：16px（小）/ 20px（標準）/ 32px（大）
- カード間のギャップ：20px

## 色
- プライマリ：#2b6cb0
- テキスト：#1a202c（インク）/ #718096（ミュート）
- 枠線：rgba(0,0,0,0.08)

## モーション
- カードのホバー：translate-y -4px + シャドウ、200ms ease
- トランジション：0.2s ease-out を全体に適用

新しいコンポーネントを書く前に、まずこのファイルの該当箇所を貼り付けて、AIに「この仕様に従って実装して」と伝えます。

何かがおかしいと感じるのに、原因を特定できないときは、Convergence Sessionを開いてUXの役割を呼び出します：

UXの観点でこのコンポーネントを見直してください。デザインシステム上、不整合になっているのはどこですか？

その役割は意思決定者から監査人へと切り替わり、「なんか違う」という曖昧な感覚を、修正すべき具体的なリストに変えてくれます。

ここで言いたいのは、AIがデザインをやっているということではありません。重要なのは、AIに任せて毎回の新機能のたびにデザインが流されていくのではなく、デザイン方針に対する自分の主導権を維持するためにAIを使っている、という点です。

計画：ブレインストーミングからエピックへ

計画フォルダがプロジェクトにリズムを与えてくれます。

epics.md は事前に定義されているわけではありません。Brainstormを実行し、その後Convergenceを行った結果の出力です。流れは次のとおりです：

Brainstorm Session（全役割）
    → 方針の候補、リスク、未検討の観点を浮かび上がらせる
    → 候補となる方向性を集める

Convergence Session · PM
    → 制約（時間、体力、ターゲットユーザー）を前提に
    → 各方向性を判断：今やる価値がある／後で／やらない
    → 出力：明確なゴールを持つエピック

エピックを手に入れたら、各エピックは対応するフォルダ内でストーリーカードに分解します。新しいスプリントを始める前に、PMの役割でIPM相当のことを実行します — ストーリーカード一覧を貼り付けて優先順位の判断をもらい、入れるものを決めてコミットします。

重要な機能を始める前は必ず、キックオフ相当のことを実行します：要件はBAセッション、インタラクション仕様はUXセッション、エッジケースはQAセッション。エディタが開くより前に全部やります。

# エピック

## エピック1 · ホームページ & プロジェクト紹介
ゴール：訪問者が30秒以内に、私が誰で何を作ってきたかを理解すること

## エピック2 · プレイグラウンドページ  
ゴール：すべてのカードで一貫したビジュアル言語を備えた、完全なプロジェクトグリッド

## エピック3 · 多言語対応
ゴール：EN/ZHの切り替えと、ロケールに対応したルーティング

これがあることで、プロジェクトを開くたびに、何をやるべきか、そしてなぜそれをやるのかがはっきり分かります。「エディタを開く→見つめる→閉じる」のループが消えます — モチベーションが上がったからではなく、構造が問題になる前に質問に答えてくれるからです。

実際に何が変わったのか

ツールはひとつの要素です。より面白いのは、プロジェクトの捉え方が変わったことです。

チームで働くと、こうした視点は自然に身につきます。PMからは優先順位について突っ込まれ、BAからは要件について詰められ、UXからはユーザーのゴールについて求められます。そうしたレンズを、時間をかけて吸収していきます。

一人の場合は、それらを意図的に作らなければなりません。私が見つけたのは、十分にBrainstormとConvergenceセッションを回したあと、質問が自然に湧いてくるようになる、ということです。コンポーネントを書く前に、UX.mdを開かなくても「これはデザインシステムに合っているか？」と自分で考えるようになります。機能をコミットする前に、PMセッションを始めなくても「いま本当に最重要なのはこれか？」と問いかけるようになります。

役割の持ち方が、あなたのプロジェクトの見え方を変えます。単に実装する人でなくなり、「何を実装するのか、なぜそれを実装するのか」を決める人になっていきます。

これは置き換えられないもの

正直な限界：

• 実ユーザーのフィードバック：UXの役割はユーザー視点をシミュレートしますが、実際のユーザーの代わりにはなりません
• チームの暗黙知：ドメイン経験5年のBAは、どんなプロンプトにも再現できない文脈を持っています
• 本当に厳しく問われること：AIの役割はリスクを浮かび上がらせて難しい質問をしてくれますが、あなたのアイデア全体が間違っていると言い切ることはありません

このアプローチが最もうまく機能するのは、すでにある程度「方向性」が見えていて、実行のための構造が必要なときです。解くべき問題を探している段階ではありません。

このプロセスが何を生み出したのかを見たいなら、yukiuix.com が私が実際にこの方法で運用しているプロジェクトです。

まだ完全には解けていない部分があります：AIの役割に、すでに自分で決めてしまったときでも、より強く反論させるにはどうすればいいのか。AIは、自分が考えていなかったことを掘り起こすのは得意ですが、自分がコミットしている方向性そのものを本質的に厳しく挑戦するのは得意ではありません。もしそこまでできるようになったなら、ぜひどうやったのか教えてほしいです。