設計判断を掲示板風に残す Claude Skill「なんJ開発部」を作った

TL;DR

nanj-dev-bu という Claude Code 向け skill を作った。
設計検討を掲示板風スレッドで残し、採用した結論を ADR / Spec に昇格させる。
「誰が何を懸念して、なぜその判断になったのか」をあとから追いやすくするのが目的。
デメリットは明確で、通常のプロンプトよりトークン使用量が多い。

作ったもの

nanj-dev-bu は、設計検討を掲示板風のスレッドとして進める Claude Code skill です。

やることは大きく3つです。

設計テーマについて、固定ハンドルの疑似メンバーが議論する
スレッドの末尾に「結論」と「次アクション」をまとめる
採用した判断を docs/adr/ や specs/ に昇格させる

スレッドは history/threads/ に置きます。
ADR は docs/adr/、仕様の正本は specs/ に置きます。

情報が競合したときの優先順位は、次の順番にしています。

specs/ > docs/adr/ > history/threads/

つまり、掲示板風スレッドはあくまで検討ログです。
最終的な仕様は Spec、採用された設計判断は ADR に残します。

なぜ作ったか

AI エージェントに設計相談をすると、結論だけはすぐ出ます。
ただ、そのままだと「なぜその結論になったのか」が薄くなりやすい。

たとえば、あとから次のような状態になります。

代替案が何だったか思い出せない
どの懸念を飲み込んで採用したのかわからない
当時は見送ったけど、将来検討したい論点が消える
AI の提案を承認しただけで、自分の判断として説明しにくい

設計判断で本当に残したいのは、結論そのものだけではありません。
むしろ、結論に至るまでの摩擦や反対意見の方が、あとで効きます。

そこで「意思決定の過程を読み返しやすく残す」ために、掲示板風のやり取りを使うことにしました。

意思決定スレ

以下は、この skill を作るときの判断を記事用に再構成したスレッドです。

# [ai-agent] 設計判断ログ、どう残すんや会議

0001 風吹けば名無しPM 2026/04/14(火) 09:00:12 JST

AI エージェントに設計相談すると、結論は出る。
でもあとから読むと「なんでそうしたんやっけ？」が残りがち。

今回は、意思決定の過程そのものを残す skill にしたい。

---

0002 名無しさん＠型安全 2026/04/14(火) 09:01:34 JST

＞＞＞1
結論だけ残すなら ADR でええ。
でも ADR だけやと、採用しなかった案の温度感が落ちる。

「A 案は実装が軽いけど将来の拡張で詰まる」
「B 案は堅いけど MVP には重い」

こういう比較の揺れを残したいなら、まず議論ログが必要やと思う。

---

0003 名無しさん＠可観測性 2026/04/14(火) 09:03:02 JST

ログを残すなら、あとから追える形式が大事。
ただの長文メモやと、どこが懸念でどこが結論かわからん。

掲示板風にするなら、発言ごとに役割が分かれるから読み返しやすい。
PM、型安全、SRE、スコープ番長みたいに観点を固定できるのも良い。

---

0004 名無しスコープ番長 2026/04/14(火) 09:04:21 JST

ただし、ノリを目的にしたら終わる。

「おもしろいログを作る skill」ではなく、
「設計判断を追える skill」にせなあかん。

掲示板風は味付け。
正本は ADR と Spec。
ここを逆にしたら、ただの読みにくいドキュメントになる。

---

0005 名無しGPU民 2026/04/14(火) 09:06:10 JST

あとトークン消費は増えるで。

複数人っぽく議論させる時点で発話量が増える。
さらに skill 側で思想、文体、ハンドル、テンプレ、ADR ポリシーまで読む。

普通に「この設計どう？」と聞くより重い。
ここはデメリットとして明記した方がいい。

---

0006 風吹けば名無しPM 2026/04/14(火) 09:08:45 JST

＞＞＞4 ＞＞＞5
つまり運用ルールはこうやな。

- 軽微な typo や自明な修正ではスレを立てない
- 設計判断・仕様変更・技術選定など、あとで理由を読みたいものだけスレ化する
- スレは検討ログ、ADR は採用判断、Spec は仕様の正本として分ける
- 文体は薄味にして、可読性を優先する
- トークン消費が増える前提で、使いどころを絞る

---

0007 名無しさん＠型安全 2026/04/14(火) 09:10:03 JST

この形ならあり。

議論ログが残ることで、後日「当時の判断」を再評価できる。
そのうえで、現在の正本は specs/ を見ればいい。

過程と正本を分けるのが肝やね。

---

## このスレの結論

- 設計検討は掲示板風スレッドとして `history/threads/` に残す
- 採用した設計判断は `docs/adr/` に昇格させる
- 現在の仕様は `specs/` を正本にする
- 掲示板風の文体は薄味にし、可読性と正確さを優先する
- トークン消費は増えるので、スレ化する対象を絞る

## 次アクション

- `nanj-dev-bu` skill のテンプレートを整備する
- ハンドルごとの役割を定義する
- サンプルとしてスレッド、ADR、Spec を1本ずつ作る

こういう形式にすると、単に「ADR を書きました」よりも、どの論点を経由したのかが見えやすくなります。

掲示板風にする理由

掲示板風にした理由は、ネタにしたかったからではありません。
むしろ、軽い口調にすることで設計の摩擦を表に出しやすくなると考えました。

堅いドキュメントだけで意思決定を書くと、どうしても結論が整いすぎます。
整っていること自体は良いのですが、迷った痕跡や反対意見が落ちやすい。

掲示板風スレッドでは、役割を持った複数のハンドルを出します。

風吹けば名無しPM: MVP、優先順位、スコープ整理
名無しさん＠型安全: 型、安全性、責務分離
風吹けば名無しSRE: 運用、監視、障害対応
名無しさん＠可観測性: ログ、追跡可能性
名無しスコープ番長: 話が広がったときの絞り込み

このように観点を分けると、AI に1つの結論を急がせるのではなく、複数の視点から設計を揺らせます。

重要なのは、キャラクター性ではなく役割です。
同じハンドルが同じ観点で発言し続けるから、議論の軸がぶれにくくなります。

スレッドから ADR / Spec に昇格する

スレッドは読み返しやすい一方で、そのまま仕様の正本にすると危険です。
雑談の中には、検討中の案、却下された案、保留した案が混ざるからです。

そこで、nanj-dev-bu では次の流れにしました。

設計検討スレッド
  ↓
ADR
  ↓
Spec

スレッドでは、論点を広げて比較します。
ADR では、採用した判断と理由を記録します。
Spec では、現在の仕様として参照すべき内容だけを残します。

この分離があると、あとから読む人は目的に応じて見る場所を選べます。

実装するときは specs/ を読む
なぜその設計になったか知りたいときは docs/adr/ を読む
当時の議論や迷いまで見たいときは history/threads/ を読む

議論ログを残しつつ、正本を曖昧にしないための構成です。

良かったところ

一番良かったのは、意思決定の説明責任を AI 任せにしにくくなったことです。

AI エージェントに「いい感じに設計して」と投げると、もっともらしい答えは返ってきます。
ただ、それをそのまま採用すると、自分が設計を所有している感覚が弱くなります。

スレッド形式にすると、次のような問いが自然に出ます。

その案は MVP に対して重すぎないか
将来の拡張をどこまで見るか
運用で困るポイントはないか
正本はどのファイルに置くべきか
今回は何をやらないのか

これらを発言として残しておくと、あとで自分が読み返したときにも判断の筋道を取り戻しやすい。

「AI がそう言ったから」ではなく、「この懸念と比較を踏まえて、今回はこうした」と説明できる状態に近づきます。

デメリット: トークン使用量が多い

デメリットは、トークン使用量が増えることです。
これは避けにくいです。

理由は3つあります。

skill の前提知識を読む必要がある
複数ハンドルの発言として出力するため、単純に文章量が増える
スレッドから ADR / Spec に昇格するとき、過去ログを参照する必要がある

通常の相談なら、次のように短く聞けます。

この認証設計、JWT とセッションどちらがいい？

一方で nanj-dev-bu 的にやるなら、観点を分けた議論、結論、次アクション、ADR 化まで含めるため、どうしても長くなります。

そのため、何でもスレ化する運用には向いていません。
軽微な修正や、明らかに選択肢がない作業に使うと、コストだけが増えます。

対策としては、スレ化する条件を絞ります。

技術選定
データモデル
認証・認可
外部 API 連携
運用設計
長く残る仕様変更

逆に、次のような作業では使いません。

typo 修正
単純なリネーム
既存パターンに沿った小さな追加
フォーマット調整

「あとから判断理由を読み返したいか」を基準にすると、使いどころを決めやすいです。

まとめ

nanj-dev-bu は、AI エージェントとの設計検討を掲示板風に残すための skill です。

狙いは、面白いログを作ることではありません。
設計判断の過程を残し、採用した結論を ADR / Spec に昇格させ、あとから説明できる状態にすることです。

一方で、トークン使用量は確実に増えます。
だからこそ、すべての作業に使うのではなく、設計判断の背景を残す価値がある場面に絞って使うのがよさそうです。

AI エージェント開発では、速く作ること以上に「なぜそうしたかを取り戻せること」が重要になる場面があります。
そのための、少し変わった意思決定ログ運用として作りました。