「使われる」Notion wikiをつくるDB設計と可視化の工夫
情報を書き込む場所は決まった。でも、それだけで安心してしまうと、半年後には誰も開かないデータベースになっている。そんな話をよく聞きませんか？
- 「1つの巨大なDB」がうまくいかない理由
- 情報を3段階で育てるデータベース設計
- 検索せずにたどり着ける「入口」の作り方
- 顧客の細かい指摘にどう応えたか
なぜ「1つの巨大なDB」ではうまくいかないのか
前回の記事では、複数の生成AIを併用するプロジェクトで、情報格納のハブにNotionを選んだ経緯を紹介しました。ただ、Notionを選んだだけでは終わりません。実際に使い始めてみると、次の壁にすぐぶつかります。
最初に手を動かしたとき、情報を1つのデータベースにひたすら追加していくやり方を試しました。書き込む側は楽です。項目を1つ足すだけで済みます。
あたまところが、行が数百件を超えたあたりから、フィルタと検索を駆使しないと目的の情報にたどり着けなくなりました。これでは、Notionに慣れていない管理者や講師の方には使いこなせません。
検索性の高さそのものは、Notionを選んだ理由の1つでした。それなのに、実際の運用では「検索しないとたどり着けない」ことがそのまま弱点になっていたのです。原因は検索機能ではなく、情報がすべて同じ粒度、同じ扱いで1つの器に入っていたことにありました。
「入りやすさ」と「使いやすさ」はトレードオフになりがちです。入口を1つのDBに絞ると書き込みは楽になりますが、情報が増えるほど、今度は目的の1件を見つけ出すコストが上がっていきます。
情報を3段階で育てるデータベース設計
この問題を解くために、データベースを1つにまとめず、情報が育っていく過程に合わせて3段階に分けました。
| データベース | 役割 |
|---|---|
| Captures | ChatGPT、Claude、人間が最初に書き込む入口。仕分け前の状態 |
| Knowledge Base | 内容を確認し、出典を明記したうえで昇格させた、検証済みの事実や概念 |
| Topics | Knowledge Baseの各行を分野ごとに束ねる、階層構造の目次 |
入口（Captures）は誰でも気軽に書き込める緩い状態にしておき、そこから人間が内容を確認して初めてKnowledge Baseへ昇格させます。**入りやすさと使いやすさを、同じ場所で両立させようとしない**、というのがこの設計の要点です。段階を分けることで、両方を別々に満たせます。
Captures からKnowledge Baseへの昇格には、必ず人間の確認を挟みました。AIが仕分けた内容をそのまま自動で反映するのではなく、ドラフトを提示してから承認を得る、という一手間です。この一手間を省くと、明らかに正しく見える内容までAI任せで通してしまい、小さなズレが少しずつ積み重なっていきます。
検索せずにたどり着ける「入口」の作り方
3段階に分けただけでは、まだ「探しやすさ」の問題は半分しか解決していません。Knowledge Baseの行がいくら整理されていても、そこへ至る道筋が検索しかなければ、結局は最初の悩みに逆戻りします。
そこで作ったのが、検索せずに情報へたどり着けるビューです。トップページから分野別のページへ、分野別のページから具体的な項目へと、階層をたどるだけで目的の情報に行き着くようにしました。
各階層のページには、その配下にある項目の一覧が自動で表示されるビューを埋め込んであります。新しい項目を追加しても、一覧を手作業で更新する必要はありません。
「このテーマを知りたければ、まずこのページを開けば全部たどり着ける」という入口を、分野ごとに用意したイメージです。検索窓に何と打ち込めばいいかわからない人でも、上から順にクリックしていくだけで目的の情報にたどり着けます。
階層は深くしすぎませんでした。最上位の分野を数個に絞り、その下の階層も、項目数が一定のしきい値を超えたときだけ分割する方針にしています。あらかじめ細かい階層を設計してしまうと、実際の使われ方とズレたときに直しにくくなるためです。
顧客の細かい指摘にどう応えたか
データベース構造とビューの骨格ができたあとも、実際の運用が始まると、細かい指摘が次々と挙がってきます。「この項目はもっと上の階層に置きたい」「この資料は毎週内容が変わるので、都度Notionを直すのは負担が大きい」といった声です。
こうした指摘のうち、内容そのものの追加や修正はKnowledge Base側の構造を直せば対応できます。厄介だったのは、講師の方が日常的に手を加える資料まで同じ構造に押し込もうとしたケースでした。ここを無理にNotion側で管理しようとすると、更新のたびに構造を作り直す羽目になります。
あたまそこで、頻繁に更新される元資料そのものは、講師の方が普段から使い慣れているGoogle Drive側に置いたままにしました。Notionは、その資料を指し示すだけの役割に徹しています。
構造化された蓄積庫と、日常的に手を加える資料置き場を分けたことで、細かい指摘のたびにデータベース設計そのものを揺らす必要がなくなりました。この分離の設計思想は、講師の方以外にも生成AI活用に不慣れなメンバーがいるチーム全般に応用できる話なので、続編で詳しく紹介します。
まとめ
情報を書き込む場所を1つに決めても、それだけでは「使われるナレッジベース」にはなりません。入口の緩さと蓄積後の厳密さを両立させるためにデータベースを3段階に分け、検索に頼らずたどり着ける階層のビューを用意し、頻繁に更新される資料は別の場所に逃がす。この3つを組み合わせて、ようやく現場で使い続けられる形になりました。
次回は、この設計を実際に運用する中で見えてきた、より技術的な課題と対策を紹介します。
関連記事
コメント