「なぜこうしたの？」が永遠に残る——LLM-Wikiがデザインシステムの属人化を終わらせる

「あのとき、なぜこうしたんだっけ？」——デザインチームの集合記憶が消えていく問題

デザインシステムをチームで育てていると、こんな場面に必ずぶつかります。「このボタンの色、なんで Primary-600 なの？」——答えを知っているのは、もう退職したメンバーだけ。あるいは Slack の数百件のスレッドのどこかに埋もれている。そんな「なぜ」の喪失が、デザインシステムの使われなさに直結しているとしたら？ AI 時代のデザインシステムは、コンポーネントの整理だけでなく「意思決定の記憶」をどう残すかが次の課題になっています。

そもそもどういうこと？

デザインシステムとは、ボタンや色・フォントなどの部品（コンポーネント）と、それを使うルールをまとめた「チームの共通言語」のことです。大規模なプロダクト開発では、このルールが整っていないと、ページごとにデザインがバラバラになったり、同じ問題を何度も議論したりする無駄が生まれます。

ところが現実には、デザインの議論は Slack・GitHub・Confluence・Figma のコメントと、あちこちに散らばってしまいます。「なぜこのルールになったのか」という文脈が、ドキュメントではなく個人の記憶に依存している状態——これを「属人化」と呼びます。サイボウズの kintone Design System チームも、過去の意思決定を探す作業がメンバーの記憶頼みになっていたことを課題として挙げています。これはどのチームでも起きる、構造的な問題です。

ここに登場するのが LLM-Wiki という考え方です。LLM（大規模言語モデル、つまり ChatGPT のような AI）を使って、散らばった議論を自動的に「百科事典」のようにまとめ直す仕組みのことです。

散らばったSlack・GitHub・Confluenceの議論が、AIによって一つのWiki知識ベースに整理・統合されていくイメージ

なぜ注目されているのか / 何がすごいのか

「探すたびに本棚を漁る」から「まとめた辞書を引く」へ

AIを使った情報検索の手法として、これまで主流だったのは RAG（検索拡張生成）と呼ばれる方式です。これは「質問が来るたびに、大量のドキュメントから関連する断片を引っ張ってきて AI に渡す」仕組みで、図書館で毎回本棚を漁るようなイメージです。

LLM-Wiki はこれとは発想が逆です。ドキュメントを取り込む段階（※インジェスト時）に AI が文書を読んで要点を整理し、クロスリンク型（※）の知識ページとして書き出しておくのです。百科事典を毎回一から書き直すのではなく、読んだそばから更新していく編集者が常駐しているイメージに近いでしょう。

※インジェスト時：外部ドキュメントを知識ベースに「取り込むタイミング」のこと。

※クロスリンク型：複数の知識ページが互いに参照し合う、百科事典の「関連項目」のような構造のこと。

この方式を2026年に提唱したのは AI 研究者の Andrej Karpathy で、現在はいくつかのオープンソースプロジェクトとして実装が進んでいます。

デザインシステムとの相性が抜群な理由

LLM-Wiki がデザインシステムに特に向いているのには、明確な理由があります。

理由	具体的な場面
「なぜ」を問う場面が多い	仕様よりも意思決定の根拠が問われる
議論が長期間有効	2年前の GitHub のやり取りが今も判断材料になる
言葉と名前が混在する	「ボタン」「button」「BTN」など表記ゆれが多い

特に表記ゆれの問題は、ハイブリッド検索（※）との組み合わせで解決できます。

※ハイブリッド検索（密ベクター探索＋キーワードマッチング）：「意味で探す」と「言葉で探す」を同時に走らせる手法。「なぜこのルールか」という意味的な問いと「Button v2.3」のような固有名称の検索を一度に両立できる。

「ドキュメントを作る」から「議論がドキュメントになる」へ

従来、デザインシステムのドキュメントは誰かが意識的に書かなければ生まれませんでした。LLM-Wiki では、Slack の会話や GitHub の議論が自動的に知識ページに変換されていくため、「ドキュメントを書く」という作業のコストが大幅に下がる可能性があります。業界調査（Design Systems Report 2026）でも、AIへの期待として「ドキュメント生成」を挙げるチームが60%に上っています。

わたしたちにどう関係する？

デザイナーやエンジニアでなくても、「過去の議論が記録されず、同じ話し合いを何度も繰り返す」という問題は、どんな職場にも存在します。LLM-Wiki はデザインシステムの文脈で生まれた概念ですが、その本質は 「チームの議論を、検索できる知識に変える」 ことです。

たとえばこんな使い方が考えられます：

●「このコンポーネントを廃止した理由は？」 → 2年前の GitHub Issue の議論を要約して即答
●「アクセシビリティ方針はいつ変わった？」 → 変更の経緯と担当者の発言を時系列で提示
●「新しいアイコンを追加していい？」 → 過去の類似議論と当時の結論を判断材料として提示

AI がやることは「検索」ではなく、チームの「集合記憶」を代わりに持っておくこと ——そう考えると、自分の職場にも応用できる発想だと感じるのではないでしょうか。

気をつけたい点

夢物語のように聞こえるかもしれませんが、正直に限界もお伝えします。

古い情報が混じるリスク：取り込みの頻度を設計しないと、「廃止になったルール」と「現在のルール」が混在して回答される恐れがあります。「週次で #design-system チャンネルを自動取り込み」のようなルール設計が必要です。

「検討中」と「決定済み」の区別：没になったアイデアも議論ログとして残るため、そのまま取り込むと「正式な方針」として誤って回答されるリスクがあります。「これは決定事項」「これは検討中」というメタ情報を付与する工夫が欠かせません。

まだ発展途上の技術：Design Systems Report 2026 によると、AI をデザインシステムのプロセスに取り込めているチームはわずか 10% にとどまり、44% が「実験中」という状況です。LLM-Wiki はまだ黎明期の技術であり、「効果がある」と「安定して運用できる」の間にはまだ距離があります。「まず小さく実験する」姿勢が現実的です。