重要なポイント
- ゼロから設計するのではなく3つの参照アーキテクチャのいずれかを選択してください。 Obsidian中心型 (ノート優先、~50Kアイテム)、AnythingLLM中心型 (ドキュメント優先、~100Kアイテム)、カスタムPython + ChromaDBスタック (エンジニア向け、1M+アイテム)。アーキテクチャを混ぜることはまれにしか割に合いません — 統合コストが支配的になります。
- ローカルAI PKBは5つのレイヤーから成ります: キャプチャ、ストレージ、Embedding、検索、インターフェース。 初心者の失敗の多くはLLMレイヤーではなくキャプチャレイヤーで起こります。アイテムがモバイルとメールからシステムに流入しない場合、巧妙な検索もビルドを救えません。
- ハードウェア最低要件: 16 GB RAM。 これ未満では、Embeddingモデルとチャットモデルのどちらか一方しか実行できません — 両方は無理です。16 GBではLlama 3.2 3B + nomic-embed-textを並列実行できます。32 GBではQwen3 7Bにアップグレードしたり、複数チャットセッションを実行できます。100,000アイテム以上ではEmbeddingをホームサーバーに移してください。
- 2026年の推奨モデル: チャット — Llama 3.2 3B (デフォルト)、Phi-4 Mini (8 GBシステム)、Qwen3 7B (32 GB+の品質); Embedding — nomic-embed-text (768次元、高速)、mxbai-embed-large (1024次元、より精密)、bge-m3 (多言語)。
- キャプチャがスケーリングのボトルネックで、検索ではありません。 ほとんどの知識アイテムはモバイルで到着します (Webクリッピング、スクリーンショット、音声メモ、転送メール)。LLMをチューニングする前に、モバイル共有シート → vaultのパスを設計してください。iOS Shortcuts → Obsidian / Working Copy / a-Shellが3つの実用的なiOSパスです。
- 同期方法がモバイルで何が動くかを決定します。 Obsidian Syncはバイナリ Embeddingインデックスをきれいに処理します; iCloud Driveはプラットフォーム間で破損させます; Gitは.gitignore規律とデバイスごとの再インデックスを必要とします。同期を先に選択し、プラグインを後にしてください。
- バックアップは必須です。 3つのレイヤー: vaultスナップショット (Time Machine、Backblaze、restic)、平文コンテンツのGit履歴、Embedding + メタデータの四半期エクスポートをクリーンな再構築パスとして。Embeddingは再生成可能ですが高価です — 10,000アイテム以上ではこれもバックアップしてください。
クイックファクト
- カバーするアーキテクチャ: Obsidian中心型、AnythingLLM中心型、カスタムPython + ChromaDBスタック。
- LLMバックエンド: Ollama (推奨) — チャットモデルとEmbeddingモデルを1つのローカルエンドポイント
http://localhost:11434の背後で実行。 - 2026年の推奨チャットモデル: Llama 3.2 3B (16 GBシステム)、Phi-4 Mini (8 GB)、Qwen3 7B (32 GB+)。
- 2026年の推奨Embeddingモデル: nomic-embed-text (768次元、高速)、mxbai-embed-large (1024次元、精密)、bge-m3 (多言語)。
- アイテム数の目標: Obsidian約50,000ノート、AnythingLLM約100,000ドキュメント、カスタムPython + ChromaDBスタック1M+。
- ハードウェア最低要件: 16 GB RAMノートPC。10,000アイテム以上: 32 GB推奨。100,000アイテム以上: 64 GBホームサーバー。
- モバイルキャプチャパス (iOS): Shortcuts → Obsidian、Shortcuts → Working Copy (Git)、Shortcuts → a-Shell。Android: TaskerまたはHTTP Shortcuts。
どのアーキテクチャを構築すべきか?
最も強力に聞こえるアーキテクチャではなく、知識がすでに到着している方法に合うアーキテクチャを選択してください。 すでに毎日ノートを書いているなら、Obsidian中心型を構築します。知識の大半がドキュメント (PDF、エクスポート、Webクリッピング) であれば、AnythingLLM中心型を構築します。100,000+アイテムやマルチユーザーアクセスが本当に必要な場合のみ、カスタムPython + ChromaDBスタックを構築してください — メンテナンスコストは現実で、その閾値以下では正当化されにくいです。
📍 一文で説明
ノート優先のワークフローはObsidian + Smart Connections + Copilot + Ollamaを選び; ドキュメント中心のアーカイブはAnythingLLM + Ollamaを選び; 100K+アイテムのエンジニアはカスタムPython + ChromaDBスタックを選びます。
💬 簡潔に説明
このセクションでは、3つの道、1つの目的地という考え方で説明します。すでにノートアプリで生活しているなら、Obsidianが既存の習慣にAI機能をかぶせます。主にPDFとWebページを集めているなら、AnythingLLMが取り込み、インデックス化、チャットを1つのアプリで行います。コードを書き、完全な制御を望むなら、Python + ChromaDBで欲しいものを正確に構築できます — ただしメンテナンスは自分でします。既存のワークフローに合う道を選んでください; アーキテクチャに合わせて習慣を変えないでください。
判断: どのPKBアーキテクチャ?
Use a local LLM if:
- •すでにObsidianを使っている、またはMarkdownファイルでノート優先のワークフローを望む → Obsidian中心型
- •知識の大半がPDF、エクスポート、Webクリッピング、メールアーカイブ → AnythingLLM中心型
- •100,000+アイテム、カスタムスキーマ要件、またはマルチユーザーアクセスが必要 → カスタムPython + ChromaDBスタック
- •キャプチャ、ストレージ、RAG、チャットを1つのアプリでカバーしたい → AnythingLLM中心型
- •チャンキング、検索、再ランク付けを完全にコントロールしたい → カスタムPython + ChromaDBスタック
Use a cloud model if:
- •すべてのクエリでGPT-4oクラスの推論が必要で、アーカイブが小さい → Notion AIまたはChatGPT with Custom GPTs (ローカルスタックは合成で約70%の能力)
- •16 GB+ RAMのマシンもホームサーバーもない → クラウドSaaS PKB (Mem、Reflect)
- •チームに同時マルチユーザーアクセスが必要で、サービスをホストしたくない → クラウド相当
Quick decision:
- →ノート優先ユーザーのデフォルト: Obsidian + Smart Connections + Copilot + Ollama
- →ドキュメント中心ユーザーのデフォルト: AnythingLLM + Ollama
- →100K+アイテムのエンジニア: カスタムPython + ChromaDB + Llama 3.2 3Bスタック
💡Tip: より強力に聞こえるという理由だけでカスタムPythonスタックから始めないでください。まずObsidian中心型またはAnythingLLM中心型を構築し、2か月運用し、ワークフローに合わないレイヤーを特定してから、そのレイヤーだけをカスタムコンポーネントに置き換えてください。「Pythonでゼロから」始めて6か月以上稼働したPKBプロジェクトはすべて、結局ObsidianまたはAnythingLLMの形に収束しました。
アーキテクチャ比較表
3つの参照アーキテクチャは、ほとんどのビルダーに重要な5つの軸で異なります: セットアップの複雑さ、アイテム数の上限、モバイル同期、キャプチャの柔軟性、メンテナンスの負担。 セットアップの複雑さはコントロールにほぼ比例して増加します — そしてメンテナンスコストも同様です。
📍 一文で説明
Obsidianは~50Kアイテムで中程度の複雑さ、AnythingLLMは~100Kアイテムで低複雑さ、カスタムPython + ChromaDBスタックは高複雑さですが100万アイテム以上に拡張します。
💬 簡潔に説明
AnythingLLMはセットアップが最も簡単で、2つの「すぐに使える」オプションの中で最も拡張します — ただしドキュメントの整理方法に強い意見を持ちます。Obsidianは最も表現力豊かなノートレイヤーとアクティブなプラグインエコシステムを提供しますが、セットアップ作業がやや増えます。カスタムPythonは無制限ですが、すべてを自分でメンテナンスします: チャンキング、再ランク付け、重複排除、同期、バックアップ。アイテム数だけでなく、メンテナンスへの忍耐力で選択してください。
| アーキテクチャ | セットアップ複雑さ | 最大アイテム数 | モバイル同期 | 最適な用途 |
|---|---|---|---|---|
| Obsidian中心型 | 中 | ~50,000 | はい (Obsidian Sync; iCloud / Gitは制限あり) | 日常的な執筆習慣を持つノート優先のパワーユーザー |
| AnythingLLM中心型 | 低 | ~100,000 | 限定的 (LAN / Tailscale経由でモバイルからWeb UI) | ドキュメント中心のPKB (PDF、エクスポート、Webクリッピング) |
| カスタムPython + ChromaDB | 高 | 1M+ | 手動 (独自API + モバイルクライアントを構築) | 完全な制御 + マルチユーザーを望むエンジニア |
💡Tip: モバイル同期は最も過小評価されている比較軸です。AnythingLLMはObsidianより技術的にセットアップが簡単ですが、モバイルでは「SafariでLAN Web UIを開く」ことを意味します — ネイティブな体験ではありません。Obsidian Mobileは、Obsidian Syncと組み合わせると、オフライン読み込みのできるほぼネイティブなiOS / Androidアプリを提供します。モバイルでのキャプチャと読み込みが重要なら、表が示唆するよりObsidianを高く評価してください。
ローカルAI PKBの5つのレイヤー
すべてのローカルAI PKBは、アーキテクチャに関係なく同じ5つのレイヤーを持ちます: キャプチャ、ストレージ、Embedding、検索、インターフェース。 失敗は通常、1つのレイヤーが他とミスマッチしているために起こります — 最も多いのは、誰も使わない壊れたキャプチャパイプラインと組み合わされた高度な検索レイヤーです。
- 1キャプチャ
Why it matters: アイテムがシステムに入る方法。Web Clipper、メール転送、モバイル共有シート、音声メモ、手動貼り付け。初心者ビルドで最もスキップされるレイヤー — そしてシステムが日常使用に耐えるかを決定するレイヤー。モバイルでキャプチャに5秒以上かかる場合、システムは放置されます。 - 2ストレージ
Why it matters: アイテムがディスク上に存在する場所。Markdown vault (Obsidian、Logseq)、ドキュメントフォルダ + データベース (AnythingLLM)、またはファイルシステム + マニフェスト (カスタムPython)。ツール変更を生き延びる保存形式を選択してください — 平文Markdownが最も移植可能; バイナリデータベースは最も移植不可。 - 3Embedding
Why it matters: セマンティック検索に使用されるアイテムのベクトル表現。ローカルモデル (Ollama経由のnomic-embed-textまたはmxbai-embed-large) で生成。Embeddingモデルは後で変更可能ですが、移行コストは「すべて再Embedding」です — 一度選んで貫いてください。 - 4検索
Why it matters: クエリ時にアイテムを見つける方法。Top-kベクトル検索、オプションの再ランク付け、オプションのメタデータフィルター (タグ、日付、ソース)。素朴なtop-5とチューニングされたtop-20-with-rerankerの品質差は「便利」と「魔法」の差です。 - 5インターフェース
Why it matters: クエリと閲覧の方法。サイドバー (Smart Connections)、チャット (Copilot、AnythingLLM)、CLI (カスタムPython)、またはAPI。ほとんどのユーザーはデフォルトでチャットに頼りますが — 「関連ノート」サイドバーは、何を尋ねるべきかわからない忘れた素材を浮上させます。
⚠️Warning: 失敗するよくあるビルドパターン: 最も強力な検索 (再ランク付き独自ハイブリッド検索)、最も賢いチャットモデル (Qwen3 7B)、そしてキャプチャを無視。3週間後、vaultには47アイテムしかありません — モバイルから何も流入していないからです。修正は常に同じ: 検索を簡素化、チャットを簡素化、キャプチャを修正、そして価値の80%はアイテムがシステムに存在することから来ると受け入れる。
アーキテクチャA: Obsidian中心型
Obsidian + Smart Connections + Copilot for Obsidian + Ollamaは、2026年のノート優先ワークフローのデフォルトアーキテクチャです。 16 GB Mac M3 ProまたはPCで約50,000ノートまで安定して拡張し、Obsidian Mobile経由でモバイル読み込みをサポートし、すべてを将来のどのツールにも持ち運べる平文Markdownで保持します。
- ストレージ: フォルダ (「vault」) 内のMarkdownファイル。平文、シンプルなフォルダ、データベースなし。ツール移行に耐えます。
- キャプチャ: Obsidian Web Clipper (ブラウザ拡張)、Obsidian Mobile共有シート (iOS / Android)、Mailspike経由またはカスタムIFTTTレシピでのObsidianへのメール転送、手動貼り付け。
- Embedding: Smart Connectionsプラグイン →
http://localhost:11434/api/embeddingsのOllama → nomic-embed-text (デフォルト) またはmxbai-embed-large (より精密)。インデックスはvault内の.smart-env/に存在します。 - 検索: Smart Connectionsサイドバー (関連ノートビュー) + Copilot for Obsidian Vault QAモード (チャットクエリ用のvault上のRAG)。両方ともEmbeddingインデックスを使用します。
- インターフェース: Smart Connectionsサイドバー (受動的発見) + Copilotチャットパネル (能動的クエリ) + Text Generatorテンプレート (日次サマリーなど反復可能なワークフロー)。
- セットアップ時間: ~30分 (Ollamaインストール、モデルプル、3つのプラグインインストール、エンドポイント設定、初期インデックス構築)。
- ハードウェア: 16 GB RAM最低 (Llama 3.2 3B + nomic-embed-text並列)。10,000ノート以上で32 GB推奨。SSD強く推奨 — インデックス再構築はHDDではI/O律速。
- アイテム数の上限: ~50,000ノート実用; 20,000まで秒未満の増分再インデックスでテスト済み。50K+ノートで初期インデックスが4〜8時間かかり、サブvaultを検討すべきです。
- 最適な用途: 日常的な執筆習慣、Markdown優先の好み、忘れたノートを浮上させる「思考パートナー」サイドバーへの欲求を持つユーザー。
- 不向き: 知識の大半がPDFとWebクリッピングのユーザー (AnythingLLM中心型を選択); 1つのオールインワンアプリを望むユーザー (Obsidian中心型は「Obsidian + 3プラグイン + Ollama」)。
💡Tip: このアーキテクチャのプラグインレイヤーの詳細 (どの5つのプラグイン、設定手順、vault規模の数値) については、Obsidian + ローカルLLMプラグインガイド を参照してください。このページはアーキテクチャをカバーし、プラグインガイドは設定をカバーします。
アーキテクチャB: AnythingLLM中心型
AnythingLLM + Ollamaはオールインワンオプションです: キャプチャ、ストレージ、RAG、チャットが1つのデスクトップまたはセルフホスト型アプリにバンドルされています。 約100,000ドキュメント (PDF、Webクリッピング、エクスポートの混合) まで拡張し、知識がノートではなく主にドキュメントとして到着する場合の正しい選択です。
- ストレージ: AnythingLLM内部データベース (デフォルトSQLite; マルチユーザーセルフホスト用にPostgres)。ドキュメントはUI経由で取り込まれます; 元ファイルはミラーリングするフォルダに残せます。
- キャプチャ: アプリ内アップロード (PDF / ファイルをワークスペースにドラッグ)、Webページ用ブラウザ拡張、プログラム取り込み用パブリックAPI (
POST /api/v1/document/upload)、公式統合またはカスタムリレー経由のメール転送。 - Embedding: AnythingLLMは設定したEmbeddingプロバイダーを使用 — 「Ollama」を選択 → エンドポイント
http://localhost:11434→ モデルnomic-embed-text。Embeddingは内蔵ベクトルストア (デフォルトLanceDB; ChromaDB / Pineconeオプション) に保存されます。 - 検索: ワークスペース上のRAG。設定可能なチャンクサイズ、top-k検索、オプションの再ランク付け。複数のワークスペースでトピック (「仕事」、「読書」、「プロジェクト」など) ごとに分割可能。
- インターフェース: AnythingLLM Web UI (デスクトップとモバイルブラウザで動作)、カスタムフロントエンド用パブリックAPI、他のツールをPKBに接続するOpenAI互換エンドポイント。
- セットアップ時間: ~15分 (AnythingLLM DesktopまたはDockerをインストール、Ollamaを指定、ドキュメントをドラッグ)。
- ハードウェア: 16 GB RAM最低。10,000ドキュメント以上で32 GB推奨。AnythingLLMは同じアイテム数でObsidian + プラグインよりメモリ効率が良く、プロセスが2つではなく1つだからです。
- アイテム数の上限: 1つのワークスペースで~100,000ドキュメント; 50K以上で複数のワークスペースに分割し、検索レイテンシを~1秒未満に保ちます。
- 最適な用途: PDF中心のアーカイブ、Webクリッピング中心のキャプチャ、プラグインのスタックよりも1つのアプリを好むユーザー。共有PKBをセルフホストする小規模チームにも正しい選択。
- 不向き: ノート優先の執筆面を望むユーザー (Obsidian); 平文Markdownでストレージを所有したいユーザー (AnythingLLMのベクトルストアは内部)。
💡Tip: ここで使用されるRAGレイヤーの段階的セットアップ (Ollama + AnythingLLM、取り込み、チャンク調整) については、30分でのローカルRAG (Ollama + AnythingLLM) チュートリアルを参照してください。RAGをおもちゃの例を超えて1,000+ PDFに拡張するには、1000+ PDFをローカルでチャット を参照してください。
アーキテクチャC: カスタムPython + ChromaDB
カスタムPython + ChromaDB + Ollamaスタックは、本当に100,000+アイテム、マルチユーザーニーズ、または既製ツールでモデル化できない特定のスキーマ要件がある場合のみ正しい選択です。 メンテナンスコストは現実です: チャンキング、重複排除、再ランク付け、同期、バックアップ — すべて自分で所有します。
ChromaDB取り込み (Pythonスケッチ)
“import chromadb, ollama, pathlib client = chromadb.PersistentClient(path="./chroma") coll = client.get_or_create_collection("kb") for p in pathlib.Path("vault").rglob("*.md"): text = p.read_text() emb = ollama.embeddings(model="nomic-embed-text", prompt=text)["embedding"] coll.upsert(ids=[str(p)], embeddings=[emb], documents=[text], metadatas=[{"source": str(p)}])”
再ランク付きクエリ (スケッチ)
“q = "What did I write about local RAG sync?" q_emb = ollama.embeddings(model="nomic-embed-text", prompt=q)["embedding"] hits = coll.query(query_embeddings=[q_emb], n_results=20) # pass hits["documents"] through a re-ranker, keep top 5 # send top 5 + question to Llama 3.2 3B via Ollama chat endpoint”
- ストレージ: ファイルシステム (ソースごとに1フォルダ:
notes/、pdfs/、web/、email/) + メタデータマニフェスト (SQLiteまたはJSONL)。ソースファイルは平文形式のままで、再取り込みなしで検索レイヤーを交換できます。 - キャプチャ: Webhookでトリガーされるスクリプト (Web Clipper → HTTPエンドポイント → ファイル書き込み)、メール転送 → IMAPポーラー → ファイル書き込み、モバイル共有シート → Tailscaleエンドポイント → ファイル書き込み。各キャプチャパスは小さなPythonサービス。
- Embedding: ChromaDB (ローカルモード、ディスクに永続化) + OpenAI互換エンドポイント経由のOllama Embedding。watchdogプロセス経由でファイル変更時に再Embedding。ChromaDBはHNSWインデックスで単一マシンで数百万ベクトルまで拡張。
- 検索: ChromaDB top-k類似度 + 再ランカー (BGE Re-rankerまたはローカルCohere相当) + メタデータフィルター (日付範囲、タグ、ソース)。正確な単語マッチング用にチャンク上のBM25とのオプションのハイブリッド検索。
- インターフェース: 任意の組み合わせ: OpenAI互換
/v1/chat/completionsエンドポイントを公開する小さなFastAPIサービス、Streamlit / Gradio UI、CLI、または3つすべて。Open WebUIをフロントに置くと、UIコードを書かずに洗練されたチャット体験が得られます。 - セットアップ時間: 動作するv1まで~1日; チャンキング、検索品質、データに合わせたキャプチャパイプラインの調整に~2週間の反復。
- ハードウェア: 開発用の32 GB RAMノートPC; Embeddingサービスがノートと競合しないよう100,000アイテム以上ではホームサーバー64 GB RAM。チャットスループット用に500K+アイテムで専用GPU (RTX 4060以上) を検討。
- アイテム数の上限: HNSW + シャーディングで1M+アイテム実用; ボトルネックは検索からキャプチャパイプラインの信頼性とスキーマ変更時の再Embeddingコストへ移ります。
- 最適な用途: スタックを所有したいエンジニア、カスタムスキーマを持つチーム (例: 「すべてのアイテムには信頼度スコア、ソース、著者がある」)、またはObsidianまたはAnythingLLMの硬い限界 (それぞれ50K / 100K) に達したユーザー。
- 不向き: 非エンジニア; メンテナンスコストを過小評価する人; 既製オプションでユースケースがすでにカバーされているユーザー。
⚠️Warning: カスタムビルドで最もよくある失敗パターン: スキーマが安定していないため、コード変更のたびにアーカイブ全体を再Embedding。~5,000アイテムを取り込む前に、Embeddingモデル + チャンクサイズをロックしてください。100Kアイテムでnomic-embed-text 768次元からmxbai-embed-large 1024次元への移行は数時間の計算コストがかかり、ChromaDBコレクションを破壊します — 次元を混ぜることはできません。
キャプチャパイプライン: Web、メール、モバイル、音声
キャプチャレイヤーがPKBが日常使用に耐えるかを決定します。ほとんどの知識はデスクトップの外で到着します — モバイル、メール、音声メモで — そして最初にデスクトップアプリを開く必要があるキャプチャパイプラインは、迂回されるパイプラインです。 4つの主要な流入用に構築し、80%のアイテムがモバイルで到着することを受け入れてください。
- Web Clipper (デスクトップ + モバイル): Obsidian Web Clipper、AnythingLLMブラウザ拡張、または現在のページをキャプチャエンドポイントにPOSTするカスタムbookmarklet。モバイル共有シート → Web Clipper拡張 → vault。
- メール転送: 専用アドレス (例:
kb@yourdomain.com) + IMAPポーラー → ファイル書き込み。保存したいメールを転送; ポーラーが取り込みを処理。検索でソースごとにフィルターできるよう、ファイル名にソースごとのプレフィックスを使用してください。 - モバイル共有シート: 最も使用されるキャプチャパス。iOS Share → Obsidian (Markdownファイルを書く)、iOS Share → Working Copy (Gitにコミット)、iOS Share → カスタムShortcut (キャプチャAPIにPOST)。Android: HTTP ShortcutsまたはTasker。
- 音声メモ: AudioPenスタイルのキャプチャは2026年に普及しています。電話で録音 → Whisper.cppでローカル転写またはセルフホストWhisperサービス経由 → 転写をMarkdownファイルとして書く → Embedding。
- 手動貼り付け: フォールバック。常に動作、決して拡張しません。ロングテールに使用。
- スクリーンショットOCR: スクリーンショットは損失のあるキャプチャ形式。iOSではApple Live Textを使用するか、ローカルOCRパイプライン (Tesseract、Apple Vision、EasyOCR) を使用してテキストを抽出 + 画像とOCRテキストの両方を含むMarkdownファイルを書きます。
💡Tip: パイプラインを設計する前に、既存のキャプチャ習慣を監査してください。すでに保存しているものを見てください: ブラウザブックマーク、スクリーンショット、転送メール、音声メモ。PKBキャプチャレイヤーはこれらの既存の流入を反映すべきです — すでに常にスクリーンショットを撮っているなら、OCRパスを構築; すでに自分にメールを転送しているなら、メール転送を構築。新しい習慣を追加する (「これからは各記事を手動でKBにコピー貼り付けする」) ことは決して機能しません。
モバイルキャプチャ: iOS Shortcuts、Working Copy、a-Shell
iOSは2026年にローカルAI PKBへの3つの実用的なキャプチャパスを持ちます: Shortcuts → Obsidian、Shortcuts → Working Copy (Git)、またはShortcuts → a-Shell (スクリプト駆動)。 各パスは3つの参照アーキテクチャの1つに自然にペアリングします。同期モデルが全体的なアーキテクチャに合うパスを選択してください。
- Shortcuts → Obsidian (Obsidian中心型): Obsidianの「ノートに追加」Shortcutがキャプチャしたコンテンツを直接vaultに書き込みます。Obsidian Sync (有料、推奨) またはiCloud Drive (無料、制限あり) 経由で同期。ノート優先のワークフローに最適。
- Shortcuts → Working Copy (Git): キャプチャしたコンテンツがiPhone上のWorking Copyリポジトリに書き込まれ、自動コミットとプッシュ。デスクトップがプル。無料、堅牢、どのMarkdown vaultでも動作。注: Working Copyは有料 (一括約¥3,000)。Git同期vaultに最適。
- Shortcuts → a-Shell: a-Shellはスクリプトを実行する無料のiOSターミナル。キャプチャしたテキストをa-Shellスクリプトに渡すShortcutを構築し、ファイルを書いて
gitでコミット、Tailscale経由でrsync同期、または独自キャプチャエンドポイントにアップロードします。エンジニアが構築するカスタムアーキテクチャに最適。 - Android相当: iOS Working CopyパスのペアとしてTasker + Termux + Git。カスタムエンドポイントパス用にHTTP Shortcuts。Obsidianパス用にObsidian Mobile共有シート。
- レイテンシ予算: モバイルキャプチャはエンドツーエンドで5秒未満で完了すべきです (共有シート → ファイル書き込み / コミット / アップロード)。それより遅いとユーザーは1度だけアプリを開いて二度と開きません。
- オフラインキャプチャ: 3つすべてのiOSパスはオフラインでキューイングします (Shortcutsはキューイング、Working Copyはコミットをキューイング、a-Shellスクリプトはローカルに書いて後で同期可能)。フライト、交通機関、地方でのキャプチャに不可欠。
⚠️Warning: デスクトップがオンラインであることを必要とするモバイルキャプチャパス (例: ノートPCが起動している間だけ到達可能なTailscale保護エンドポイントへのPOST) を構築しないでください。仕事の会議中、ノートPCのスリープモード中、夜間にキャプチャを失います。キャプチャエンドポイントを常時稼働のホームサーバー / NASで実行するか、オフラインでバッファする最終的整合性ストア (Obsidian Sync、Git、iCloud) に書き込んでください。
スケーリング: 1K、10K、100Kアイテム
ローカルAI PKBのスケーリングには3つの体制があります: 1,000アイテム未満では、すべてが現代のノートPCで高速; 1,000〜10,000アイテムでは、Embeddingインデックスが管理が必要な実物のアーティファクトになる; 10,000アイテム以上では、ハードウェアがボトルネックになり、キャプチャパイプラインの信頼性が結果を支配します。 以下の現実的な数値は、Mac M3 Pro / RTX 4060 PCでnomic-embed-textとLlama 3.2 3Bを想定しています。
| アイテム数 | 推奨アーキテクチャ | 初期Embedding時間 | ハードウェア | メモ |
|---|---|---|---|---|
| 1,000アイテム | 3つのいずれか | ~2分 | 16 GB RAMノートPC | すべてが瞬時に感じられます。アーキテクチャ選択は純粋にワークフローの適合性によります。 |
| 10,000アイテム | ObsidianまたはAnythingLLM | ~25分 | 16 GB RAMノートPC (32 GB推奨) | Embeddingインデックス~150〜250 MB。編集時の再Embedding時間は秒未満。ほとんどのナレッジワーカーのスイートスポット。 |
| 50,000アイテム | AnythingLLMまたはカスタムPython | ~3時間 | 32 GB RAMノートPCまたはホームサーバー | 初期インデックスは夜間実行。この点を超えるとサブvault / ワークスペースを計画。Embedding用ディスク使用量~1.5〜2 GB。 |
| 100,000アイテム | AnythingLLM (マルチワークスペース) またはカスタムPython | 6〜8時間 | 32 GB RAM最低; ホームサーバー優先 | Embeddingを専用ホームサーバーに移動。キャプチャパイプラインの信頼性が主な失敗モードに、検索ではない。 |
| 500,000+アイテム | カスタムPython + ChromaDB | 24+時間 | 64 GB RAMホームサーバー + 専用GPU | シャーディング、重複排除、増分再Embeddingパイプラインが必要に。既製ツールはもはや適合しません。 |
💡Tip: 初期Embeddingコストは1回限りの請求書です。最初のインデックスの後、変更されたアイテムのみが再Embeddingされます — 100Kアイテムでも通常save毎に1秒未満。最初の遅さは現実ですが繰り返しません。電源接続マシンで初期インデックスを夜間実行し、忘れてください。
バックアップ、バージョン管理、マルチデバイス同期
ローカルAI PKBには3つのバックアップレイヤーが必要です: vaultスナップショット (Time Machine、Backblaze、restic)、平文コンテンツのGit履歴、クリーンな再構築パスとしてのEmbeddingとメタデータの四半期エクスポート。 Embeddingは技術的には再生成可能ですが、100K+アイテムでは再生成コストは数時間 — これもバックアップしてください。
- vaultスナップショット (ファイルシステムレベル): 24時間ごとのTime Machine (macOS) またはrestic (Linux)。オフサイトにBackblazeまたはrsync.net。Embeddingを含むすべてをキャプチャ。
- Git履歴 (コンテンツのみ): Gitリポジトリ (ローカル + GitHub / Gitea private) にコミットされた平文Markdownファイル。
.smart-env/、vector_store/、その他のバイナリインデックスフォルダを.gitignoreに追加。Gitはノート毎のバージョン履歴を提供; vaultスナップショットはシステム全体のロールバックを提供。 - Embeddingエクスポート (四半期): ベクトルストアを移植可能形式にエクスポート (ChromaDB → parquet、Smart Connections → JSONダンプ、AnythingLLM → 内蔵エクスポート)。最新2つのエクスポートをオフサイトに保管。vaultスナップショットが失敗するかEmbeddingインデックスが破損した場合、これが高速再構築パス。
- マルチデバイス同期 — Obsidian中心型: Obsidian Syncは平文 + バイナリインデックスをきれいに処理 (E2E暗号化)。iCloud Driveは平文には機能しますが、プラットフォーム間でバイナリインデックスを破損させます。Working Copy / Termux経由のGitは平文のみ機能 — デバイスごとに再インデックス。
- マルチデバイス同期 — AnythingLLM中心型: AnythingLLMをホームサーバーのセルフホストDockerコンテナとして実行。すべてのデバイスがLANまたはTailscale経由で同じインスタンスに接続。クライアント側同期不要。
- マルチデバイス同期 — カスタムPython: 構築するアーキテクチャがこれを決定。ほとんどのビルドは中央APIサービス (ホームサーバーのFastAPI) + キャプチャをPOSTしクエリをGETするクライアントを使用。Tailscaleがネットワークレイヤーを提供。
- 新しいコンピューターへの移行: vaultスナップショット復元 → Gitリポジトリ復元 → Ollama再起動 → Embeddingインデクサー再起動。Embeddingエクスポート手順をスキップした場合、Embedding再生成は自動; バックアップしたが形式がプラットフォーム固有の場合は手動再インデックス。
- 選択的共有: vaultの一部 (例: 共同研究プロジェクト) を共有するには、サブvaultまたはタグエクスポートスクリプトを使用。vault全体を共有しないでください — ほとんどのローカルAI PKBはローカルスタックを離れるべきでない機密アイテム (医療、財務、個人) を蓄積します。
💡Tip: 四半期に一度復元をテストしてください。ほとんどの「バックアップがあります」という主張は願望です — テストは「新しいノートPCで2時間以内にvaultを復元できますか?」 そのテストを実行してください。最初に行うとき、3つのレイヤー (スナップショット、Git、Embeddingエクスポート) のうち1つが過去6か月間誤設定だったことが判明します。
よくある間違い
- キャプチャレイヤーの前に検索レイヤーを設計する。 47アイテムのvaultでは再ランク付き独自ハイブリッド検索は無駄です。最初にキャプチャを構築し、素朴なtop-5検索を受け入れ、vaultが1,000+アイテムを持ち、実際のクエリで検索品質を測定できるようになってから検索を最適化してください。
- アーキテクチャを混ぜる。 「ノート用Obsidian + PDF用AnythingLLM + メール用カスタムPython」はクリーンに聞こえますが、統合コストが支配的になります。1つのアーキテクチャを選択し、限界を受け入れ、絶対に必要な場合のみ単一のコネクタを追加してください (例: Obsidian vaultフォルダを読み取り専用で取り込むAnythingLLM)。
- アーカイブを再Embeddingせずにモデルを切り替える。 同じストアでnomic-embed-text 768次元とmxbai-embed-large 1024次元のベクトルを混ぜると、検索が静かに壊れます。Embeddingモデル + 次元を1つ選択し、ロックし、アーカイブの完全な再Embeddingでのみ切り替えてください。
- 10,000アイテム以上でEmbeddingインデックスのバックアップを無視する。 「再生成できる」は本当ですが、再生成は数時間かかります。10Kアイテム以上でEmbeddingストアをバックアップ戦略に追加してください。
- キャプチャの80%がモバイルで起こるのにデスクトップ専用に設計する。 モバイルキャプチャパスのないPKBは放置されます。1日目にモバイルキャプチャフローをテスト — 共有シートからvaultへは5秒未満で完了すべきです。
- バイナリEmbeddingインデックスにiCloud Driveを依存する。 iCloudは平文をきれいに処理; バイナリインデックス (Smart Connections
.smart-env/、AnythingLLMベクトルストア) はプラットフォーム間で破損。Obsidian Sync、セルフホストインスタンスを使用するか、デバイスごとの再インデックスを受け入れてください。 - 100Kアイテムで分割しない。 100K+アイテムの単一ワークスペース / vaultは検索レイテンシが秒オーダーになります。トピックごと (仕事、読書、プロジェクト) に複数のワークスペースまたはサブvaultに分割; それぞれ別々にまたはルーター経由でクエリしてください。
- コンプライアンスリスクを過小評価する。 個人ナレッジベースは必然的に機密データ (顧客、患者、同僚からのメール、財務・医療メモ) を蓄積します。経済産業省の「AI事業者ガイドライン (2024)」は、個人情報を扱う企業展開において、ローカル推論によるデータ最小化と説明責任を推奨しています — クラウドエグレスがないため、第三者処理者契約 (Art. 28相当) が不要になります。
出典
- Obsidian — obsidian.md と help.obsidian.md (vault構造、モバイル同期アーキテクチャ、プラグインドキュメント)。
- AnythingLLM — github.com/Mintplex-Labs/anything-llm (オープンソースのセルフホスト型RAGアプリケーション)。
- Ollama — ollama.com と github.com/ollama/ollama (ローカルLLMランタイム; チャット + Embeddingエンドポイント)。
- ChromaDB — trychroma.com と github.com/chroma-core/chroma (オープンソースのローカルベクトルデータベース)。
- Working Copy — workingcopy.app (モバイルキャプチャパイプライン用のiOS Gitクライアント)。
- a-Shell — holzschu.github.io/a-Shell_iOS/ (スクリプト駆動モバイルキャプチャ用の無料iOSターミナル)。
FAQ
Webページをナレッジベースにキャプチャするには?
摩擦順に3つのオプション。(1) ブラウザ拡張Web Clipper — Obsidian Web ClipperまたはAnythingLLMブラウザ拡張が現在のページを直接vault / ワークスペースに書き込みます。(2) モバイル共有シート — Safari / Chrome共有 → Obsidian (Markdownファイルを書く)、または → Working Copy (Gitにコミット)、または → カスタムShortcut (キャプチャAPIにPOST)。(3) Bookmarklet — 拡張のないブラウザ向け; 現在のURL + 選択をキャプチャエンドポイントにPOST。実際にはモバイル共有シートが最も使用されるパス — 最初に設計してください。
メールをシステムに転送できますか?
はい。専用アドレスを設定し (例: Fastmail / Migaduエイリアス kb@yourdomain.com)、ホームサーバーまたはノートPCで新しいメールをダウンロードしてvaultに1メールにつき1Markdownファイルを書くIMAPポーラーを実行します。検索でsenderごとにフィルターできるよう、ファイル名にfromアドレスプレフィックスを使用してください。AnythingLLMはファーストパーティのメール統合を持ちます; ObsidianユーザーはIMAPポーラーを自分で構築するか、IFTTT / Zapier代替のn8nなどを使用するのが一般的です。
デスクトップとモバイルを同期するには?
アーキテクチャ依存。Obsidian中心型: Obsidian Sync (有料、バイナリインデックスをきれいに処理)、iCloud Drive (無料、平文のみ — デバイスごとに再インデックス)、Working Copy経由のGit (無料 + Working Copy一括料金、平文のみ — デバイスごとに再インデックス)。AnythingLLM中心型: AnythingLLMをホームサーバーでDockerで実行、すべてのデバイスがLANまたはTailscale経由で接続 — クライアント側同期不要。カスタムPython: ホームサーバーに中央APIサービスを構築; クライアントがキャプチャをPOSTしクエリをGET。
1つの大きなvaultを使うべきか、トピックで分割すべきか?
~50,000アイテムまでは1つのvault。50K以上ではトピック (仕事、読書、プロジェクト、個人) で分割、2つの理由から: 検索レイテンシが~1秒未満を維持し、コンテキスト間の意図しないクロスリーク (例: 個人ノートが仕事クエリに表示) が大規模で可能になります。50Kより早く分割するのは時期尚早 — PKBの主な価値である偶発的なクロスドメイン接続を失います。
精度のためにどのくらいの頻度で再Embeddingすべきか?
「精度ドリフト」のために再Embeddingしないでください — Embeddingは劣化しません。Embeddingモデルを変更するときのみ再Embedding (例: 技術コンテンツのより良い検索のためにnomic-embed-textからmxbai-embed-largeへのアップグレード)。3つすべてのアーキテクチャがファイル変更時の増分再Embeddingを自動的に処理します; スケジュールしません。例外はインデクサーを制御するカスタムPythonスタック — そこではwatchdog駆動の保存時増分再Embeddingが標準です。
ナレッジベースをバージョン管理できますか?
平文コンテンツについてははい (Markdown vault → Gitリポジトリ、ローカル + GitHub / Gitea private)。バイナリインデックスフォルダ (.smart-env/、vector_store/、ChromaDB永続化ディレクトリ) を .gitignore に追加 — それらは履歴を膨張させ、マージコンフリクトを引き起こします。Gitはノート毎のバージョン履歴を提供; vaultスナップショット (Time Machine、restic) はシステム全体のロールバックを提供。両方のレイヤーで、どちらか一方ではない。
このシステムでPDFを処理するには?
Obsidian中心型: PDFをMarkdownノートと並べて保存; Smart ConnectionsはPDFコンテンツを直接Embeddingしない — まずテキストを抽出 (例: PDF++プラグイン経由または各PDFと並んでMarkdownサマリーを書く前処理スクリプト)。AnythingLLM中心型: PDFを直接ワークスペースにドラッグ; AnythingLLMがPDFパースとチャンキングを自動的に処理。カスタムPython: 取り込みパイプラインで pypdf または pdfplumber を使用してテキストを抽出し、抽出したテキストをEmbedding。AnythingLLMがPDF中心のアーカイブで最も摩擦の少ないオプションです。
KBの一部を選択的に共有できますか?
はい、ただし1日目から設計してください。サブvault (Obsidian) またはワークスペース (AnythingLLM) を使用して、「共有可能」と「プライベート」コンテンツを別々のストアに保ちます。1回限りの共有には、タグ (例: #shareable) でアイテムを引っ張る移植可能Markdownバンドルへのタグエクスポートスクリプトを構築。vault全体を共有しないでください — ほとんどのローカルAI PKBはローカルスタックを離れるべきでない機密アイテム (医療、財務、個人通信) を蓄積します。
最良のバックアップ戦略は?
3つのレイヤー: (1) 24時間ごとのファイルシステムスナップショット (Time Machine / restic) とオフサイトコピー (Backblaze / rsync.net); (2) ノート毎のバージョン回復のための平文コンテンツのGit履歴; (3) 高速再構築パスとしてのEmbedding + メタデータの四半期エクスポート。四半期に一度復元をテスト — 「新しいノートPCで2時間以内にvaultを再構築できますか?」 最初の復元テストは通常、3つのレイヤーのうち1つが誤設定だったことを明らかにします。
新しいコンピューターに移行するには?
vaultスナップショットを復元 → Ollamaをインストールして同じモデルをプル → Obsidian / AnythingLLM / カスタムPythonスタックをインストール → Embeddingインデクサーを再起動。Obsidian Syncまたはセルフホスト型AnythingLLMでは、移行は「クライアントをインストールしてログイン」 — 手動復元不要。それらなしでは、10Kアイテムvaultで~30分、50Kで~2時間、Embeddingエクスポート手順をスキップした場合は100K以上で夜間を見込んでください。