Umbrella issue という well-known な 1 単語を覚えただけで、1 日 20 PR がリアルになった

CARTA fluct エンジニアのなっかー @konsent_nakka です。

最近 Umbrella issue という言葉に出会って、頭の中がすごい勢いで整理されています。社内でも AI コーディングをガンガン回している人がよく口にしている言葉でした。

軽く書きます。

tl;dr

1 日 20 PR は LLM の精度ではなく、構造化の問題だった
Umbrella issue は「複数 PR をまとめる運用」を 1 単語に圧縮している
一度立てておけば、自分にも AI エージェントにも「同じ参照点」を渡せる
実例

1 日 20 PR の壁は LLM ではなくコンテキストの供給だった

AI コーディングをやり込むほど、ボトルネックは LLM 側ではなく自分側にあると気づきます。

個別タスクのたびにプロンプトへ具体のタスク指示を書き、1 タスクごとに壁打ちしながら進めているうちは、結局スケールしません。「まずこのツールを入れてね」「その次はツールを使う実装をしてね」を毎回書いているのは、全てのタスクを分割して他の人に仕事を"依頼"している構造と変わらないわけです。

裏返すと、先に高品質なコンテキストを入力し自律的に進められる環境ができれば、後続の指示はものすごく薄くて済みます。1 日 20 PR がリアルかどうかは、ここの設計が効くかどうかで決まる、と最近は思っています。

well-known な 1 単語は、長い前提説明を肩代わりする

ある運用パターンに共有された名前がついていると、その 1 単語を投げるだけで前提説明をまるごと省けます。

たとえば「依存構造を持つ複数の issue / PR をまとめて、親 issue から checklist で潰していく運用」をゼロから説明すると、それだけで数百 token は持っていかれます。これに well-known な名札がついていれば、その 1 単語に同じ構造が圧縮されていて、長文プロンプトを書く代わりにキーワードを 1 個渡すだけで済みます。

人相手には共通言語として、LLM 相手には token 節約として、自分相手には頭の整理として効いてくる。使える語彙を増やすこと自体が、AI コーディングのスループットを押し上げる行為になっている、という感覚が最近強いです。

その分かりやすい具体例が、「Umbrella issue」でした。

Umbrella issue は「複数 PR をまとめる運用」を 1 単語に圧縮している

Umbrella issue とは、ざっくり言えば「ある領域に対する Day 0 triage の結果と、複数 PR で潰していく checklist を 1 枚にまとめた親 issue」のことです。

有名どころだと OSS でいくつか実例が見つかります。

自分のところでは、あるリポジトリの frontend を対象に、Scorecard（lockfile / TS strict / Biome / coverage / E2E / CI 中央値 / TODO 真数…）と、その上で潰すべきタスクの checklist を並べました。各 task は独立した PR で出し、PR 説明に親 issue への Refs を書いて、マージ時に該当 checkbox が閉じていく流れです。

ただの parent issue ではありません。Day 0 triage（領域の現状を一気にスキャンして scorecard 化する）→ checklist 化 → 独立 PR で潰す、という運用パターンの全体に「Umbrella issue」という名札がついている、というのが大事なところだと思います。

圧縮された言葉は、人にも AI にも効く

この言葉が圧縮しているのはタスク管理ではなく、コンテキスト供給そのものです。

自分の頭の中: タスクの依存・順序・残量が 1 枚に集約される。「次どれやる？」が 5 秒で決まる
AI への指示: 「Umbrella issue をできるところまで全て並列でやって」で済む。背景・Scorecard・関連 PR の文脈はその場で参照される
PR 説明: 親 issue への Refs 1 行で必要な背景が貼り付く。冗長な説明文がいらない

長文プロンプトを毎回書いていた頃と比べて、指示そのものが短くなるし、そもそも指示がいらないんですよね。

言葉を 1 つ手に入れただけで、世界が一歩近づく

「1 日 20 PR」という数字を聞いても、しばらく前までは正直、現実感がありませんでした。

でも Umbrella issue という運用に名札がついた瞬間に、「あ、これは再現可能なやつだ」という感覚に変わりました。コンテキストの供給コストを構造で下げる、という落としどころが見えたからだと思います。今は私が開発しているものだけでも、複数のリポジトリで並列にそれぞれ 10 〜 20 PR が動こうとしています。

言葉を 1 つ手に入れただけで、世界の見え方がここまで変わるのは結構面白い体験でした。明日、自分の担当領域で Umbrella を 1 本書いてみる、くらいから始めてみるのおすすめです。

Umbrella issue という言葉だけが大事なわけではない

根本的には Claude Code が常時アクセスできて、セッションを跨いで利用できるチェックリストが必要という話ではあります。しかし、 Umbrella issue という言葉を使うと、タスクを進めるためのフェーズ分けやTODOの洗い出し精度が今までと明らかに違う感覚がありました。今まで頑張ってTODOを精査していたつらみが一気に無くなりました。

あとがき

この記事を書く動機をくれた rinchan へ感謝。