社内向けデザインガイドラインは本文にルール、脚注に「決めた理由」を残し、パターン追加は人とAIで役割分担する

どんな問題を解決するか / いつ使うか

社内業務システムなど、利用者が決まっている画面をAIエージェントが量産するとき。「好き嫌い」の議論が繰り返されるとき。AI向けデザインシステムはコードを正にし、FigmaはMCPで作る「鏡」にするや歴史ある大きなプロダクトでは、まずDESIGN.mdに仮置きし、次にStorybookを「唯一の正」にしてAIに部品を選ばせるの前段として、判断の文章側を整えたいとき。

具体手順

1. 考えること／考えないことを分ける

社内システムでは一般向けの物差しをそのまま当てない。例：毎日の業務を早く正確に終えることは考える。今の利用者に場面がないダークモード等は、求められてから足す——ただし考えない理由も書いておく。

2. 本文と脚注の役割を分ける（DDRを脚注に組み込む）

• 本文：今どうするか、の1行ルールだけ
• 脚注：次の4問のうち中身があるものに答える
  1. 何で決めたか
  2. 何を諦めたか
  3. 何を選ばなかったか
  4. どうなったら決め直すか
• 履歴の「以前は〜」は書かず、gitに任せる。人もAIも「今の決まり＋理由」を一度に読めるようにする。

3. 根拠の順番を固定する

候補を並べてから、上にある根拠で選ぶ（先に見つけた弱い案が残らないようにする）。

1. 客観的な根拠（規格・実装の事実・利用実態・利用者の声）
2. 既存パターン・既存画面
3. 使っているUIライブラリの既定
4. 主観（好み・印象・他サービスで見かけた）

一次資料の例：WCAG、MDN／HTML仕様、HIG／Material、デジタル庁・SmartHR・GOV.UK 等のDS、NN/g・Baymard。ルールを書く前に調べる（書いたあとに出典を探すと都合の良い資料だけ拾う）。AIに調べさせるときはURLの実在と該当記述を確かめる。

判断は保留にしない。見直したいならいったん決め、脚注に「見直すきっかけ」を書く。

4. 置き場所

• docs/design/README.md：共通原則・根拠の順番・書き方
• docs/design/patterns/*.md：場面ごと1ファイル1パターン（ボタン、エラー、空状態など）

5. パターンを増やすスキル（人＝判断、AI＝調査）

新しいUIでパターンが無いとき、AIスキルで次を回す（完了条件つき）。

1. 題材と論点を仮置き（既存コードから実例）
2. 決めた一次資料のすべてに当たり、無ければ「無し」と残す
3. 論点を1つずつ人に聞く（資料が揃う／割れる／無い、の型で進め方を変える）
4. パターンを書く
5. 実装との食い違いを並べ、チケットにするか今のままかを人に聞く
6. 人がOKしたら終了

人が「再提案しない」と言った案も脚注に残し、同じ案の再提案を止める。

6. 実装エージェントへの接続

AGENTS.md 等に「UIを作る・変えるときは docs/design/README.md と当てはまるパターンを開いてから着手。無ければ先にパターンを作る。見た目を変えるPRではパターンも同じPRで直す」と書く。

注意点

• 1パターン決めるのに時間がかかる。最初は共通原則と根拠の順番だけ決め、迷った場面から足す。
• 見せ方の判断はデザインガイドライン、コードの書き方は開発ガイドライン、と分ける。

出典

• @kgsi · 2026-11-06 （紹介）
• ytakagi（GENDA）「社内システムのデザインガイドラインを、根拠つきで AI と作る」