多リポ Issue を 1 リポに集約する「ideation-hub パターン」
困りごと: 多リポ管理の Issue 散在
サービスを 3〜5 個のリポジトリで構成しているとよくある問題:
- バックエンドリポに Issue
- 管理画面リポに Issue
- 顧客向け Web リポに Issue
- モバイルアプリリポに Issue
- 共通ドキュメントリポに Issue
これだと:
- 全体の進捗が見えない（どのリポに何があるか把握できない）
- 重複 Issue が立つ（複数リポにまたがる機能を別々に立ててしまう）
- AI も把握できない（Claude Code が複数リポの Issue を横断調査するのが面倒）
- 優先順位が付けにくい（リポ毎の優先度しか見えない）
解決策: ideation-hub リポジトリ
全リポの Issue を集約する専用リポを作る、という運用パターンです。命名は何でも良いですが、本記事では ideation-hub と呼びます。
「企画リポ」と「実装リポ」を分離し、企画は ideation-hub に集約、実装は各リポで行う、という構成です。
例え話: 図書館の検索カウンター
複数の書庫（リポジトリ）に本（コード）が分散していても、検索カウンター（ideation-hub） が 1 箇所にあれば、利用者は迷わず本を探せます。
書庫を直接彷徨い歩かせるより、カウンターで案内してもらう方が効率的、という考え方です。
仕組み
1. Issue は ideation-hub にだけ立てる
機能・バグ・改善などすべての Issue を ideation-hub リポに集約します。実装リポでは Issue 機能を使わない（または使うとしても内部技術タスクのみ）。
2. PR から Issue を参照する
実装リポの PR で、ideation-hub の Issue をクロスリポ参照で紐付けます。
# backend-repo のコミットメッセージ or PR 本文
Closes <org>/ideation-hub#42
# または
Refs <org>/ideation-hub#42
GitHub は別リポへの参照もリンクとして扱ってくれるので、ideation-hub 側の Issue から関連 PR が一覧で見えるようになります。
3. 命名規則: 略称 + 番号
実装リポの PR タイトルや commit メッセージには ideation-hub の Issue 番号を入れる規約を作ると、後で追跡しやすい。
feat(notify): プッシュ通知を家族へ送信 (ih#42)
fix(api): バリデーションエラーの修正 (ih#58)
ih#42 のように略称を決めると、行末でも視認性が高い。
「現場の声 → プロダクト化」の動線を作る
ideation-hub の真価は、事業側・CS の現場で拾った声を、開発の意思決定の場に最短経路で届けることにあります。
Claude を「現場の通訳」にする
CS や営業の現場では「お客様に〇〇を言われた」という生の声があります。これを Claude（co-work モード等のチャット環境） で要約・整理し、/customer-voice のような skill で ideation-hub の Issue に変換するフローです。
[顧客の声] [Claude で整理] [ideation-hub]
"アプリが重い" ───► 再現条件を抽出 ───► Issue: "起動時パフォーマンス改善"
"〇〇が分かりにくい" ──► 類似要望を集約 ───► Issue: "オンボーディング UX 改善"
"△△機能が欲しい" ──► 類似 Issue 検索 + マージ ───► Issue 既存に投票追加
ポイントは:
- CS/営業は「テキストで投げる」だけで済む（GitHub の使い方を覚えなくて良い）
- Claude が要件の言語化・重複排除・既存 Issue との突合を引き受ける
- ideation-hub に積まれる時点でプロダクトのバックログとして整備された状態
意思決定の場が ideation-hub になる
集約された Issue を見て、PO/PdM と開発リーダーが意思決定します。
| ロール | やること |
|---|---|
| PO/PdM | 顧客価値・優先度・スコープ判断（Go/No-Go） |
| 開発リーダー / CTO | 技術的実現可能性・コスト評価 |
| CS/営業 | 顧客文脈の補足・現場の温度感 |
| AI（subagents） | 多角レビュー・既存実装との整合性チェック |
/idea-review や /prioritize で、Issue ごとに AI が技術評価コメントを残し、人間がそれを踏まえて判断する、という流れになります。
CS が言葉で投げてから 数分で「優先度判定可能な Issue」になる — これが現場感を失わずにプロダクト化できる仕組みです。
「実務」と「意思決定」の役割分担
この運用に切り替えると、人間と AI の役割が明確になります。
作る判断・止める判断・優先順位付けといった「意思決定」だけが人間の仕事として残り、その重要度は相対的に上がります。
「AI が代替するのは作業、人間が担うのは判断」という整理が、ideation-hub の運用を通じて自然に実現されます。
利点
A. 全体俯瞰
ideation-hub の Issue 一覧 = プロダクトのバックログになります。経営者・PdM・開発者が同じ画面を見て話せる。
B. AI が把握しやすい
Claude Code に「現在のバックログから優先順位の高い順に 5 件出して」と聞けば、ideation-hub だけ見れば済みます。
/prioritize /feature-idea /idea-review のような skill は、集約リポでの実行を前提に設計できます。
# Claude Code で実行
/prioritize # ideation-hub の全 Issue を優先度評価
/feature-idea ... # ideation-hub に Issue を立てる
/idea-review #42 # ideation-hub の Issue #42 を Go/No-Go 判定
C. 複数リポにまたがる機能を 1 つの Issue で扱える
「通知機能を追加したい」という 1 つの目的で、BE と FE 両方の作業が必要なケース:
ih#42 通知機能の追加
├─ PR <org>/backend-repo#150 (API + DB マイグレーション)
└─ PR <org>/admin-web#88 (設定画面)
両 PR が Closes <org>/ideation-hub#42 で紐付くので、Issue クローズと共に両方が完了したと分かります。
D. PR レビューが軽くなる
実装 PR は技術的な内容に集中できます（要件は ideation-hub に書いてある）。PR 本文は「Closes ih#42」とだけ書いて、レビュアーは Issue で要件を確認する流れ。
ディレクトリ構成例
ideation-hub/
├── README.md ← 運用ルールを書く
├── CLAUDE.md ← Claude Code 用のプロジェクト指示
├── SERVICE.md ← サービス全体像（ドメイン用語・主要フロー）
├── DESIGN.md ← デザインガイド
├── docs/ ← 営業資料・既存ドキュメント
│ ├── product-intro.md
│ └── sales-deck.md
├── specs/ ← 機能仕様
│ └── notification-spec.md
├── decisions/ ← 設計判断の記録（ADR）
│ └── 0001-notification-arch.md
├── mocks/ ← UI モック（GitHub Pages で公開）
│ └── notification-settings.html
├── scripts/ ← Bot コメント等の共通スクリプト
│ └── gh-bot-comment.py
└── .claude/
├── agents/ ← 役割特化エージェント
│ ├── pm.md
│ ├── cto.md
│ └── ...
└── skills/ ← custom skill
├── feature-idea/
├── develop-issue/
├── close-issue/
├── prioritize/
└── ...
ポイント:
- CLAUDE.md で Claude Code に関連リポのパス・規約を伝える
- mocks/ を GitHub Pages で公開すれば Issue から URL 参照可能
- scripts/ に Bot コメント投稿等を置けば、複数 skill から再利用
CLAUDE.md の例
## 関連リポジトリ
本リポジトリと同じ親ディレクトリ（`../`）に配置。
| リポジトリ | ローカルパス | 用途 |
|-----------|-------------|------|
| backend-repo | `../backend-repo/` | バックエンド（Go / PostgreSQL） |
| admin-web | `../admin-web/` | 管理画面（Next.js） |
| customer-web | `../customer-web/` | 顧客向け Web（Next.js） |
| mobile-app | `../mobile-app/` | モバイル（Flutter） |
## 関連リポジトリ調査前の準備
各リポを最新化:
```bash
git pull origin main
for repo in backend-repo admin-web customer-web mobile-app; do
(cd "../$repo" && git checkout main && git pull origin main)
done
Issue 管理
全リポジトリの Issue は <org>/ideation-hub に集約する。
各リポの PR からは Closes <org>/ideation-hub#<番号> で紐付ける。
## Bot コメントによる役割演出
ideation-hub の Issue にエージェント別のコメントをつける際、**GitHub App の Bot 経由**で投稿すると視覚的に分かりやすくなります。
```python
# scripts/gh-bot-comment.py
# 引数: Issue 番号
# 標準入力: コメント本文
# → GitHub App として投稿（個人アカウントではなく）
skill から Bot コメントを投げる際のフォーマット:
<img src="https://api.dicebear.com/9.x/personas/svg?seed=<Seed>" width="24"> **<名前>（<役割>）**
<コメント本文>
| エージェント | Seed | 名前 | 役割 |
|---|---|---|---|
| pm | Yuki | 結城 はるか | PM |
| cto | Takeshi | 堺 剛志 | CTO |
| uiux-designer | Miku | 水瀬 みく | UI/UX Designer |
| be-engineer | Kenta | 黒田 健太 | Backend Engineer |
| fe-engineer | Riku | 藤原 りく | Frontend Engineer |
| qa-engineer | Haruto | 森 はると | QA Engineer |
アバター付きでコメントが並ぶと、Issue が「会議録」のように見えて、関係者全員が状況を把握しやすくなります。
運用ルール
実際に運用する際の Tips:
マイルストーン = スプリント
2 週間スプリントなら、Sprint-2026-04-1 Sprint-2026-04-2 のようなマイルストーンを作って、Issue を割り当てます。
ラベルで属性管理
| ラベル | 用途 |
|---|---|
idea |
アイデア段階。技術評価が必要 |
feature |
機能追加 |
bug |
バグ修正 |
refactor |
リファクタリング |
priority:high |
優先度高 |
affects:backend affects:admin
|
影響範囲 |
優先度評価の自動化
/prioritize skill で全 Issue を一気に優先度評価できます:
/prioritize
→ 全 Issue を取得
→ 各 Issue を ICE スコア（Impact × Confidence × Ease）で評価
→ スコア順にソート
→ 上位を Bot コメントで通知
注意点
過度な集約は逆効果
「実装リポでも内部 Issue を立てたい」という需要は残ります（リファクタリング・技術的負債管理など）。機能・要件レベルの Issue だけ集約し、純粋な技術タスクはそれぞれのリポに残す、という線引きが必要です。
Issue 番号の重複
各リポでも Issue 機能を有効にしている場合、#42 がリポ毎に存在します。クロスリポ参照では必ず <org>/<repo>#<num> のフルパスで書く運用にしましょう。
Bot コメントの認証
GitHub App の Private Key 管理が必要です。~/Downloads/<app-name>.private-key.pem のようにローカルに置き、scripts/gh-bot-comment.py で読み込む形が一般的。
まとめ
- 多リポを跨ぐ Issue は ideation-hub という集約リポにまとめる
- 実装リポの PR は
Closes <org>/ideation-hub#<num>で紐付け - ideation-hub の CLAUDE.md / SERVICE.md / DESIGN.md が AI の知識源
- skill と subagent はこの集約リポで定義 → 全リポを横断調査可能に
- Bot コメントで Issue が「会議録」のように見える
次回（#5）はIssue 駆動開発を Claude Code で完全自動化するで、ideation-hub から実装 PR まで全自動で進めるフローを解説します。
Discussion