Personal Knowledge Base（PKB）とは？パーソナルナレッジベースの定義とローカルLLMで組む手順【2026年10月】

Personal Knowledge Base（PKB、パーソナルナレッジベース）は、個人が資料から読み取った知見や自分の判断を、あとから検索して再利用できる形で持つ電子的な基盤です。PDFやWebページを保存しておく場所とは違い、蓄えるのは「出典から自分が抽出した知見」のほうです。PKBの組み方が変わったのは、2025年に公開された初代EmbeddingGemmaのようにノートPCで動く小型の埋め込みモデルが揃い、意味で探すベクトル検索を個人が手元で持てるようになったためです。この記事では、PKBの定義と原典を押さえたうえで、ObsidianのVaultをOllamaで検索できるようにするPythonコードを、埋め込みモデル5種の実測と合わせて示します。

まとめ｜PKBの定義・5層構成・組織展開の判断

PKBは「自分が再利用する前提で、出典から抽出した知見を1か所に統合して持つ個人の基盤」です。この語を広めたStephen Daviesらの論文は、PKBの条件をpersonal（本人専用で本人向けに組まれている）・knowledge（原資料でなく抽出した知識を持つ）・base（ばらばらのファイルでなく統合された保管庫）の3点で定義しています。全社で正しさを保証する社内ナレッジベースとは、誤りの責任を誰が負うかで分かれます。

実装はcapture（取り込み）・storage（保管）・embeddings（ベクトル化）・retrieval（検索）・interface（参照）の5層で考えます。保管はMarkdownの平文に寄せ、埋め込みモデルは日本語に対応したものを選びます。Ollamaで5モデルを比べたところ、日本語の質問12問で正しいノートを1位に出せたのは、英語専用のnomic-embed-textが4問、bge-m3・初代embeddinggemma・2026年10月6日公開のembeddinggemma-2:270mがいずれも12問でした。初期値は、全問正解の中で配布サイズが最小でライセンスもApache-2.0のembeddinggemma-2:270m（Ollamaのq8_0版で304MB）にします。Intel MacのCPUだけでも動き、メモ20ファイル（約4.2万字）の初回索引は約4分、2回目以降の差分同期は変更が無ければ0.1秒未満で終わります。

ノートが数百件までで、検索より「まとまった要約を育てたい」なら、ベクトル検索を組まずにLLMにMarkdownのWikiを保守させるLLM Wiki方式のほうが手間が少なく済みます。組織展開は、参照回数ではなく「他人が読んで同じ結果を再現できるか」で判定し、PKBそのものを社内の検索対象につなぐ構成は採りません。

PKBの定義と原典｜Daviesの3要件とMemex

PKBという考え方の源流は、Vannevar Bushが1945年に描いたMemex（個人の本・記録・通信をすべて収め、高速に引ける機械仕掛けの私設ファイル）です。英語版WikipediaのPersonal knowledge baseの項目も、Memexを電子的なPKBの最も有名な初期の構想として挙げています。同項目によれば、語が広まったのは2000年代で、コロラド大学ボルダー校のStephen Daviesらが詳しく論じてからです。2005年8月の技術報告「Building the Memex Sixty Years Later: Trends and Directions in Personal Knowledge Bases」（CU-CS-997-05）は、当時の個人向け知識管理システムを網羅的に整理しています。

personal・knowledge・baseの3要件で見るPKBの条件

Daviesらの論文「Popcorn: the personal knowledge base」は、PKBを次の3要件で定義しています。

• personal：本人の利用を前提とし、中身は本人向けに組まれている。他人が同意しない傾向・関係・分類・観察を含んでよい
• knowledge：原資料そのものではなく、持ち主が頭の中で抽出した知識の表現を持つ
• base：集約・統合された保管庫であり、互いに参照できない区画に分割されていない

この3要件に当てると、PDFを大量に貯めたフォルダはknowledgeを満たさず、アプリごとに分散したメモはbaseを満たしません。実務で効く判定に直すと、1件の記録が独立して意味を持つ粒度（1ノート1主張）であること、「どの資料の何ページから自分が何を読み取ったか」という出典と解釈の対で残っていること、別の文脈へ持ち出せる形で検索できることの3つです。会議の議事録は原本として残し、そこから抽出した判断を別ノートに切り出します。

PKB・PKM・セカンドブレインの関係

3つの語は対象が違います。PKBは知識を入れておく入れ物、PKM（Personal Knowledge Management）は集める・分類する・取り出す・共有するという個人の作業工程、セカンドブレインはTiago Forteの講座と書籍『Building a Second Brain』で広まった、PKMをPKBの上で回す実践の呼び名です。英語の「knowledge base」単体は、FAQやマニュアルを集めた組織の情報基盤を指すことが多く、個人の文脈ではpersonalを付けて区別します。

社内ナレッジベース・全社RAGとPKBの境界線

正しさの担保責任で分かれる社内ナレッジベースとPKB

社内ナレッジベースは、閲覧する全員が内容を正しいものとして扱う前提で運用されます。だから承認フロー・更新責任者・権限制御・監査ログ・出典の版管理が要ります。私的な用途のPKBでは、このうち組織としての承認フローと更新責任者を省けます。読むのは書いた本人だけなので、確度の低いメモや途中の推測も入れられます。ただし業務の情報を入れたPKBは、後の章で扱うとおり保管先や持ち出しの管理から外れません。社内文書を検索させる側の設計はナレッジベースとRAGの違い｜社内文書をAmazon Bedrockで検索させる設計と権限制御で扱っており、そこでは検索対象の範囲と権限が要件定義の中心に来ます。PKBでは範囲＝自分の全ノートで済みます。

全社RAGへの流入経路を一方向にする切り分け基準

PKBと全社RAGを直結させる設計は避けます。個人の未検証メモが全社の検索対象に入ると、生成された回答の根拠として他人に提示されてしまうためです。つなぐなら、人が明示的に「公開」操作をした記録だけが組織側へ流れる一方向の経路にします。RAGの仕組みそのものはRAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説で整理しています。PKBは知識を持つ基盤そのもので、RAGはその使い方の一つです。個人のノートだけを検索対象にしたRAGは、PKBを引くための実装の一形態にあたります。

PKBを支えるcaptureからinterfaceまでの5層構成

PKBは層ごとに差し替えられる形にしておくと長持ちします。埋め込みモデルを入れ替えても、保管したMarkdownはそのまま残せるためです。保管形式と検索の仕組みが一体になったツールを選ぶときは、全ノートを平文で書き出せるかを先に確かめます。

capture層の入力経路の初期設計

記録が続かなくなる原因は、思いついてから書き込むまでの手数です。ブラウザ拡張・モバイルの共有シート・音声メモのどれを使うにせよ、保存までの操作を数ステップに収めます。経路は最初から増やさず、Webクリップ（Obsidianなら公式のWeb Clipper）と手書きメモの2本で始め、必要が出てから足します。経路ごとに保存先が分かれると、同じ資料の重複や取り込み漏れに気づけなくなるため、どの経路も同じVaultの同じ受け箱フォルダへ落とします。

storage層をMarkdown平文で持つ理由

保管形式はテキストエディタで開ける平文に限ります。独自形式のツールを使うなら、全件の書き出し機能と、書き出したファイルから復元できるかを先に確かめます。平文ならgitで履歴を持て、誤って消したノートも戻せます。ローカルのMarkdownをそのまま保管先にする代表はObsidian（2026年10月時点の最新はデスクトップ版1.14.4、10月5日公開）とLogseqです。Logseqは2026年4月にDB版とMarkdown版（Logseq OG）に分かれたので、平文で持ちたいなら選ぶ版に注意が要ります。違いはLogseqとは？料金・使い方・Obsidianとの違いとDB版・OG版の選び方で比較しています。

embeddings層のモデル選定と日本語12問の検索結果

PKBの中身が日本語なら、埋め込みモデルは日本語で学習されたものを選びます。当たり前に聞こえますが、ローカルRAGの解説でよく初期値にされるnomic-embed-textは、Hugging Faceのモデル情報で言語が英語（en）だけのモデルです。そこで、内容の重ならない日本語のメモ12件（家計簿・パン作り・Kubernetes・確定申告・猫の健康管理など）と、本文と同じ語をなるべく使わない言い換えの質問（例：「病院代を税金から差し引く手続きの条件」で確定申告のメモを探す）を用意し、Ollama v0.40.5で各モデルが正しいメモを1位に出せるかを数えました（2026年10月16日、Intel Core i9-9880H・メモリ16GB・GPU不使用、別の処理が並走しロードアベレージ5前後）。

上限トークンは、embeddinggemma-2がGoogleの公表値、ほかはOllamaのollama showが示す値です。nomic-embed-textは、モデルカードが求める接頭辞（文書にsearch_document: 、質問にsearch_query: ）を付けて4問、外すと5問で、どちらでも半分に届きませんでした。qwen3-embeddingは、モデルカードが勧める質問側の指示文を付けずに測った値です。英語の質問で日本語のメモを探す3問では、nomic-embed-textが2問、ほかの4モデルが3問でした。日本語が混ざるなら次の順で選びます。

• embeddinggemma-2:270m：Googleが2026年10月6日に公開したEmbeddingGemma 2のテキスト専用版。全問正解の3モデルの中で配布サイズが最小で、埋め込みも最速。Apache-2.0で、100を超える言語と8,192トークンの入力に対応
• bge-m3：BAAIのモデルカードによれば100を超える言語・8,192トークン・MITライセンス。公開から時間がたっており、周辺ツールの対応実績が多い。埋め込みにかかる時間はembeddinggemma-2:270mの約2.3倍
• embeddinggemma（初代）：今回の試験では全問正解。ただし上限が2,048トークンで、ライセンスがApache-2.0ではなくGemmaの利用規約

12件・15問の小さな試験なので、全問正解した3モデルの優劣までは言えません。言えるのは、英語専用のnomic-embed-textを日本語のPKBに使うと、今回の12問では正解が4〜5問にとどまったことです。自分のノートで確かめるなら、答えの分かっている質問を10問ほど用意し、上の表と同じ数え方で比べてください。モデルごとの特徴をさらに詳しく比べたい場合は埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準を参照してください。

retrieval層のチャンク分割とtop-kの初期値

検索の当たり外れは、モデルより分割の設計で決まる部分が大きくなります。ノートの見出し単位で切るところから始め、1ノート1主張で書けているなら分割せずに丸ごと1チャンクにします。注意したいのは長さの上限です。Ollamaの/api/embedはtruncateの既定値がtrueで、コンテキストを超えた入力はエラーにならず末尾が黙って切り捨てられます。英語の固有名詞を含む日本語600字を通したときのトークン数は、embeddinggemma系が315、bge-m3が285、nomic-embed-textが374でした。漢字とかなだけの文ではnomic-embed-textが1字あたり約1トークンまで膨らみます。上限が2,048トークンのモデルでは日本語でおよそ2,000〜3,900字を超えた部分が索引に入らず、長い議事録を1チャンクのまま入れると後半は検索に掛かりません。実際に7,200字をnomic-embed-textへ渡すと、エラーは出ずに2,048トークンで切られて返りました。"truncate": falseを渡すと、同じ入力が「the input length exceeds the context length」のエラーで止まります。

取得件数はtop-kで5件前後から始めます。件数を増やすほど生成モデルへ渡す文脈が埋まり、無関係な記録が回答に紛れ込みます。増やす前に、再ランク用のモデルを1段挟んで並べ替えるほうが効果を読みやすくなります。

interface層をサイドバー・チャット・APIで出し分ける基準

参照の出口は、執筆中に関連ノートを横に出すサイドバー型、質問して要約させるチャット型、他のツールから呼ぶAPI型の3つです。書いている最中に効くのはサイドバー型です（ObsidianではSmart Connectionsがこの形で、2026年8月6日公開の4.7.2が最新）。チャット型は「あのとき何を判断したか」を自分の記録に問う用途に向きます。回答と一緒に根拠ノートのファイル名を必ず返す作りにしておくと、生成された文を鵜呑みにせず原本へ戻れます。コーディングエージェントからVaultを読み書きさせる場合は、Claude CodeとObsidianの連携方法｜Vault直結・MCP・公式CLI・Claudianの設定手順のようにMCPやファイル直結でつなぎます。

ObsidianのVaultをOllamaで検索できるようにする手順

ローカル完結の最小構成は、Ollamaを常駐させて埋め込みを1つのエンドポイントから呼び、結果をSQLiteに保存する形です。Ollamaは既定で127.0.0.1の11434番ポートで待ち受けるため、同じ機材の外からは接続されません。埋め込みにローカルのモデルを使い、スクリプトの接続先をlocalhostのままにしておけば、索引づくりのためにVaultの本文が外部へ送られることはありません。ローカルLLMの導入全般はローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説で、Ollamaの公式アプリやOpen WebUIでファイルを読ませる方法はOllamaでファイルをアップロード・読み込む方法｜公式アプリとOpen WebUIのRAG設定で扱っています。ここでは自分で索引を持つ形を組みます。

Ollamaの埋め込みモデル取得と疎通確認

Ollamaを入れたら、埋め込みモデルを取得します。2026年10月14日公開のv0.40.5で動作を確かめました。

ollama pull embeddinggemma-2:270m
curl http://localhost:11434/api/embed -d '{"model":"embeddinggemma-2:270m","input":["テスト"]}'

2行目のコマンドでembeddingsに768個の数値が返れば準備は完了です。

差分だけを再埋め込みするPythonの索引スクリプト

次のスクリプトは標準ライブラリだけで動きます。Vault内の.mdを走査し、見出しの直前で分割して埋め込み、SQLiteに保存します。ファイルごとにSHA-256を記録し、変わったファイルだけを埋め込み直し、Vaultから消えたノートは索引からも消します。全件の再埋め込みは初回だけで済みます。

"""Obsidian の Vault（Markdown）を Ollama の埋め込みで索引し、質問に近いチャンクを返す最小構成。"""
import hashlib, json, math, os, re, sqlite3, sys, time, urllib.error, urllib.request

OLLAMA = os.environ.get("OLLAMA_URL", "http://localhost:11434")
MODEL = os.environ.get("EMBED_MODEL", "embeddinggemma-2:270m")
# 接頭辞が必要なモデルだけ（文書用, 質問用）を登録する
PREFIX = {"nomic-embed-text": ("search_document: ", "search_query: "),
          "embeddinggemma": ("title: none | text: ", "task: search result | query: "),
          "embeddinggemma-2": ("title: none | text: ", "task: search result | query: ")}
DB = os.environ.get("PKB_DB", "pkb_index.sqlite")

def embed(texts, is_query=False):
    pre = PREFIX.get(MODEL.split(":")[0], ("", ""))[is_query]
    # truncate=False で、上限を超えた入力を黙って切り捨てずにエラーにする
    req = urllib.request.Request(f"{OLLAMA}/api/embed",
        data=json.dumps({"model": MODEL, "input": [pre + t for t in texts],
                         "truncate": False}).encode(),
        headers={"Content-Type": "application/json"})
    return json.load(urllib.request.urlopen(req))["embeddings"]

def embed_chunks(cs):
    """まとめて埋め込み、上限超過（HTTP 400）なら1件ずつ、それでも超える分は半分に割って埋め込む"""
    try:
        return cs, embed(cs)
    except urllib.error.HTTPError as e:
        if e.code != 400:
            raise
    out_c, out_v = [], []
    for c in cs:
        try:
            out_v += embed([c]); out_c.append(c)
        except urllib.error.HTTPError as e:
            if e.code != 400 or len(c) < 2:
                raise
            for part in (c[:len(c) // 2], c[len(c) // 2:]):
                pc, pv = embed_chunks([part]); out_c += pc; out_v += pv
    return out_c, out_v

MAX_CHARS = 1500  # 暫定値。トークン数は文字種とモデルで変わるので、超過は embed_chunks で検出して割る

def chunks(text):
    # 見出し（# 〜 ###）の直前で切る。1ノート1主張なら丸ごと1チャンクになる
    out = []
    for part in re.split(r"(?m)^(?=#{1,3} )", text):
        part = part.strip()
        while len(part) > MAX_CHARS:  # 長い節は段落の切れ目で分ける
            cut = part.rfind("\n\n", 0, MAX_CHARS)
            cut = cut if cut > 0 else MAX_CHARS
            out.append(part[:cut]); part = part[cut:].strip()
        if part:
            out.append(part)
    return out

def sync(vault):
    if not os.path.isdir(vault):  # パスを誤ると全ノートが「消えた」扱いになり索引が空になる
        raise SystemExit(f"Vault が見つかりません: {vault}")
    db = sqlite3.connect(DB)
    db.execute("create table if not exists files(path text primary key, sha text)")
    db.execute("create table if not exists chunks(path text, body text, vec text)")
    seen, updated = set(), 0
    for root, _, names in os.walk(vault):
        for n in names:
            if not n.endswith(".md"):
                continue
            p = os.path.join(root, n); seen.add(p)
            body = open(p, encoding="utf-8").read()
            sha = hashlib.sha256(body.encode()).hexdigest()
            row = db.execute("select sha from files where path=?", (p,)).fetchone()
            if row and row[0] == sha:
                continue  # 変わっていないファイルは埋め込み直さない
            cs, vecs = embed_chunks(chunks(body)) if body.strip() else ([], [])
            db.execute("delete from chunks where path=?", (p,))
            db.executemany("insert into chunks values(?,?,?)",
                           [(p, c, json.dumps(v)) for c, v in zip(cs, vecs)])
            db.execute("insert or replace into files values(?,?)", (p, sha))
            updated += 1
    for (p,) in db.execute("select path from files").fetchall():
        if p not in seen:  # Vault から消えたノートは索引からも消す
            db.execute("delete from chunks where path=?", (p,))
            db.execute("delete from files where path=?", (p,))
    db.commit()
    return updated

def search(query, k=5):
    q = embed([query], is_query=True)[0]
    qn = math.sqrt(sum(x * x for x in q))
    db = sqlite3.connect(DB)
    scored = []
    for path, body, vec in db.execute("select path, body, vec from chunks"):
        v = json.loads(vec)
        s = sum(a * b for a, b in zip(q, v)) / (qn * math.sqrt(sum(x * x for x in v)))
        scored.append((s, path, body))
    return sorted(scored, reverse=True)[:k]

if __name__ == "__main__":
    if sys.argv[1] == "sync":
        t = time.time(); n = sync(sys.argv[2])
        print(f"updated={n} files in {time.time() - t:.1f}s")
    else:
        for s, path, body in search(sys.argv[2]):
            print(f"{s:.3f}  {path}  {body[:40]!r}")

使い方はpython pkb_rag.py sync ~/Vaultで索引を作り（2回目以降は差分だけ）、python pkb_rag.py search "質問文"で近いチャンクを5件返します。環境変数EMBED_MODEL=bge-m3を付ければモデルを替えられますが、モデルが違うベクトルは同じ空間に無いので、替えたら索引ファイルを別にして作り直します。チャンクが1万を超えて検索が遅くなったら（実測は次の項）、保存先をChroma（ChromaDB）のような近傍探索の索引を持つベクトルDBへ移します。

Intel MacのCPUだけで索引した実測値

上のスクリプトをそのまま使い、Markdownのメモ20ファイル（計約4.2万字、分割後115チャンク）をembeddinggemma-2:270mで索引しました。条件は前の表と同じIntel Mac・CPUのみで、計測中は別の重い処理が並走していました（ロードアベレージ16〜26）。

初回は1ファイルあたり約12秒かかりました。1ファイルあたりの文字数が同程度だと仮定して単純に比例させると、この機材と負荷のままなら1,000ファイルで3時間半前後になる計算です。初回だけは夜間に回すか、Apple SiliconやGPUのある機材で作ります。運用に入ってからの同期は変えたファイルの分しか走らないので、毎日数件の追記なら1分前後で終わります。差分同期を最初から組み込むのはこのためです。

検索のほうは、全チャンクとの類似度をPythonで1件ずつ計算しているため、件数に比例して遅くなります。索引の行を複製して19,910チャンクにすると、検索1回が28.9秒、索引ファイルは245MBになりました。数千チャンクまではこのままで使えますが、1万チャンクを超えるあたりで、近傍探索の索引を持つベクトルDBに置き換えます。

埋め込みモデルの常駐メモリは、ollama psで見てembeddinggemma-2:270mが528MBで、メモリ8GBの機材でも載ります。重いのは回答文を書かせる生成モデルのほうで、メモリ16GBの機材で両方を常駐させるなら生成側は3B〜4B前後に寄せます。載らないと検索のたびにモデルの入れ替えが起き、応答が数十秒単位で遅れます。生成モデルの選び方はSLMとは？小規模言語モデルの仕組み・LLMとの違いと実装判断を解説で整理しています。

ベクトル検索とKarpathyのLLM Wikiの選び分け

2026年4月4日、Andrej KarpathyはLLM WikiというPKBの組み方をGistで公開しました。Karpathyの整理では、一般的なRAGは質問のたびに原資料の断片を探して答えを組み立て直し、要約や資料同士の関連付けが残りません。LLM Wikiは逆に、資料を取り込むたびにLLMがMarkdownのWikiを書き足し、知識を「一度まとめたら最新に保つ」ものとして扱います。

LLM Wikiの3層とingest・query・lintの運用

構成は3層です。原資料（LLMは読むだけで書き換えない）、Wiki（LLMが書き、人は読む）、スキーマ（CLAUDE.mdやAGENTS.mdにWikiの構造と作業手順を書いたもの）。運用は、資料を読ませて要約ページを作り索引と関連ページを更新するingest、索引から関連ページを探して引用付きで答えさせるquery、矛盾・古い記述・孤立ページを点検させるlintの3つです。入口になるindex.md（ページ一覧と1行要約）と、時系列のlog.md（追記専用）を置きます。Gistは、資料100件前後・ページ数百程度の規模なら索引ファイルで足り、埋め込みを使ったRAGの基盤は要らないと書いています。

ベクトル検索とLLM Wikiの規模・用途別の判断条件

判断を言い切ると、すでに自分で書いたノートが数千件あるならベクトル検索です。LLM Wikiは1件の取り込みで10〜15ページを書き換えることがあり、既存の大量のノートを後から通すと生成モデルの処理量が膨らみます。逆に、これから特定のテーマを調べ始めるなら、最初からLLM Wikiで要約を育てるほうが読み返す価値のある成果物が残ります。どちらも避けたいのは、LLMが書いたWikiのページを自分の判断の記録と混ぜることです。PKBの3要件のうちknowledge（自分が抽出した知識）が崩れるので、LLMが書く領域はフォルダを分けておきます。

業務データを取り込んだPKBの管理責任と漏洩経路

ローカルで完結しているから安全、とは言えません。PKBの危険は外部への送信より、業務データが個人の管理下へ移ってしまう点にあります。

業務情報を書き写した時点で生じる管理責任と会社側の線引き

顧客名や見積条件を自分のメモへ書き写した時点で、その記録は会社の情報資産です。端末が個人所有でも、退職時の返却・削除や漏洩時の社内報告は、会社の就業規則や情報管理規程、契約に沿って求められます。業務で使うなら、業務由来の記録を入れるVaultと私的なVaultを分けます。会社の管理外で生成AIへ業務情報を渡す状態はシャドーAIと呼ばれ、PKBはその入口になり得ます。

とはいえ全面禁止は効きません。禁止しても手元のメモアプリに同じ情報が書かれるだけで、会社から見えなくなるだけです。会社が最初に決めるのは、業務由来の情報を入れてよい保管先と、外部へ出る通信の有無の申告です。返却・削除の手順や漏洩時の連絡経路は、その後に規程として定めます。そのうえで社内に正規の生成AI基盤を用意すると、個人のPKBへ業務情報が溜まる動機そのものが減ります。

ローカル完結でも残る同期・バックアップの経路

推論がローカルでも、VaultがiCloud Drive・OneDrive・Dropboxなどの同期フォルダに置かれていれば、業務情報は社外のサーバーへ複製されています。見落とされやすいのは、バックアップ先、モバイル同期サービス、エディタのプラグインが送る通信の3つです。点検は、Vaultの物理パスがどのサービスの監視下にあるかを確かめ、入れているプラグインの通信先を洗い出し、会社が承認していない同期経路を止める、の順で行います。前の章のスクリプトはローカルのモデルをlocalhost経由で呼ぶだけなので、埋め込みの処理でVaultの本文を外部へ送りません。ただしOllamaのクラウドモデルを指定したり、接続先を別のサーバーに変えたりすると、この前提は崩れます。

個人PKBを組織ナレッジへ昇格させる判断条件

PKBを組織へ開く話は「良いメモを共有すれば全社の生産性が上がる」という前提で始まりがちです。この前提は成り立ちません。個人の記録は書いた本人の文脈に依存しており、Daviesらの3要件でいうpersonal（他人が同意しない観察を含んでよい）こそがPKBの性質だからです。

共有候補の再現性による公開判定と月次の棚卸し

よく見返すノートを共有の候補に挙げるのはかまいませんが、公開の判定に参照回数を使うと失敗します。参照回数が多いのは本人の業務に近いからで、他人にとって役立つかとは別の話です。公開の判定は再現性で行います。書かれた手順や判断を書き手以外が読んで、同じ結果に辿り着けるか。辿り着けないなら前提条件・環境・失敗時の分岐が抜けています。

運用に落とすなら、ノートに「共有候補」の状態を持たせ、月次でその候補だけを棚卸しします。前提条件を書き足し、固有名詞を一般化し、通った記録だけを社内ナレッジベースへ複製します。PKBをそのまま公開するのではありません。個人側は自由に書き換え続け、組織側は版を固定する。この流れはSECIモデルでいう表出化と連結化にあたり、組織側の仕組みづくりはナレッジマネジメントとは？意味とSECIモデル、属人化を解く導入手順を解説で扱っています。

組織展開すべきでない条件と典型的な失敗

次のどちらかに当てはまるなら、組織展開はしません。書き手が1〜2名しかおらず棚卸しの工数を続けて確保できない場合と、記録の大半が特定顧客・特定案件の一回限りの事情でできている場合です。前者は更新が止まり、後者は検索の雑音だけを増やします。

典型的な失敗は、Vaultを丸ごと社内の検索対象へ流し込む構成です。未検証のメモが根拠として引用され、回答の精度が下がり、やがて誰も使わなくなります。組織に要るのは、権限設計・ログ・出典の版管理を備えた別の基盤です。社内文書を検索対象にする基盤の設計はRAG構築支援で相談を受けています。個人のPKBは個人の道具のまま残し、組織には組織の基盤を建てる。この分離が両方を長持ちさせます。

よくある質問

PKBとは何の略ですか？

Personal Knowledge Base（パーソナルナレッジベース、個人知識ベース）の略です。個人が資料から抽出した知識を1か所に統合し、あとから検索して再利用するための電子的な基盤を指します。日本語では「個人ナレッジベース」「パーソナルナレッジベース」と表記が割れていますが、指すものは同じです。

PKBと社内ナレッジベースは、どちらを先に作るべきですか？

集める記録の粒度と分類がまだ決まっていないなら、個人のPKBが先です。社内ナレッジベースは、それが決まっていないと形になりません。規程集や手順書のように組織の文書が既にそろっているなら、組織側から始めてかまいません。まず数名が自分のPKBを数か月運用し、実際に再利用された記録がどういう粒度だったかを見てから組織側の設計に入ると、誰も書かない空のデータベースが残る事態を避けられます。

PKBの構築にGPUは必要ですか？

索引の作成だけならCPUで足ります。Intel MacのCPUだけで、メモ20ファイルの初回索引が約4分、1ファイル変更後の差分同期は約14秒で終わりました。生成モデルで7B級を常用したい場合や、数万件の再埋め込みを頻繁に回す場合は、手元の機材で1回の応答と全件の再索引にかかる時間を測り、許容できなければGPUかユニファイドメモリの大きいApple Siliconの機材を検討します。

Obsidianなどの既製ツールと自作構成は、どちらを選ぶべきですか？

検索できれば十分なら、Smart Connectionsのような既製のプラグインを選びます。入れるだけで埋め込みから参照まで揃い、索引の作り方を自分で保守せずに済みます。プラグインの更新や索引の状態確認は残ります。自作へ移るのは、独自のメタデータで絞り込みたい、他のツールから索引を呼びたいなど、既製の機能で満たせない要件が出てからです。

埋め込みモデルは、後から別のモデルへ変更できますか？

変更できますが、索引は全件作り直します。異なるモデルが出したベクトルは同じ空間にないため、混ぜると検索結果が壊れます。保管をMarkdown平文にしておけば原本は無傷のまま索引だけを作り直せるので、乗り換えの費用は計算時間だけです。

関連記事

• 埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年】
• Claude CodeとObsidianの連携方法｜Vault直結・MCP・公式CLI・Claudianの設定手順【2026年10月】
• CursorとObsidianを連携する方法｜Vault直開き・MCP・CLIの設定手順【2026年9月】
• SLMとは？小規模言語モデルの仕組み・LLMとの違いと実装判断を解説
• Obsidianカスタマイズ完全ガイド｜テーマ・外観設定・CSSスニペット【1.14対応】