「社内のADRや仕様書、議事録をGitで管理しているけど、AIに参照させようとするとクラウドに上げるしかなくて困っている」という状況、わりと多いんじゃないでしょうか。
Notionに置けば検索は楽になるけど、センシティブなドキュメントをクラウドに預けるのは気が引ける。
ObsidianにAI検索プラグインを入れようとしたら設定が複雑で途中で諦めた、という経験がある人もいるかもしれません。
そこで試してほしいのが Tolaria です。
ローカルのMarkdownファイルをそのまま開いて、ローカルLLMと連携してAI検索できるデスクトップアプリ。
アカウント不要・サブスクなし・OSSで、Gitリポジトリとして管理しているドキュメントとの相性が特によいです。
Tolariaが何者でどう動くのかを正確に把握したうえで、ObsidianやNotionとの使い分けを整理します。
セットアップからGit連携の実運用、Obsidianからの移行コストまで、実際に手を動かせる粒度で書いていきます。
Tolariaとは何か――「ファイルが主役」のMarkdownナレッジアプリ
TolariaはElectron製のデスクトップアプリで、macOS（Apple Silicon・Intel）、Windows x64、Linux x64に対応しています。
AGPL-3.0ライセンスのOSSで、tolaria.md またはGitHubから無料でダウンロードできます。
アカウント登録もサブスクリプションも不要です。
設計思想のキーワードは 「files-first」 です。
Obsidianの「Vault」のような独自の管理概念を持たず、既存のディレクトリをそのまま開くだけで使えます。
Gitで管理しているリポジトリをそのまま開けるのは、この思想があってこそです。
AI機能については、ローカルLLMとの接続を想定した設計になっています。
Tolariaを紹介するRefactoring.fmのブログ記事では、ADRのコレクションやビジョンドキュメントをAIが参照することで、新機能のスペック作成や技術的な意思決定の精度が大きく上がると紹介されています。
クラウドにドキュメントを預けずにAI活用したい、という要件にフィットするアーキテクチャを志向していると見てよいでしょう。
開発はrefactoringhq（Luca Rossi氏）が主導しており、リポジトリにはAGENTS.md・CLAUDE.md・GEMINI.mdといったファイルが並んでいます。
AIエージェントがコードベースを理解するためのコンテキストファイルを丁寧に整備している点からも、「AIと一緒に使う」ことを本気で想定しているプロジェクトだとわかります。
ObsidianでもNotionでもない理由――Tolariaが刺さる場面
Tolariaを「Obsidianの競合」として見ると、機能の少なさが気になるかもしれません。
でも、そもそも狙っている用途が違います。
NotionとObsidianを使い分けている人は多いと思いますが、どちらも「Gitで管理しているチームドキュメントをローカルAIで検索する」という用途には素直にフィットしません。
Notionはデータがクラウドに置かれる前提なので、機密性の高いドキュメントを扱う場面では選択肢から外れます。
Obsidianはローカルファーストで強力ですが、チーム共有をObsidian Gitプラグインで実現しようとすると、プラグインの設定・自動コミットの挙動・競合解消の手順など、Gitの上にObsidianの操作レイヤーが乗っかる分だけ複雑さが増します。
AI検索を追加しようとすると、さらにプラグインを重ねることになります。
Tolariaが刺さるのは、こういう状況です。
すでにGitでドキュメントを管理していて、そのリポジトリをそのままAI検索の対象にしたい。
プラグインの設定コストをかけずに、ローカル完結でAIに参照させたい。
そういう要件を持つエンジニアやチームにとって、Tolariaは現状ほぼ唯一に近いポジションにいます。
3ツールの「これに使う」シーンを簡潔に整理するとこうなります。
- Notion：チームのタスク管理・DB的な情報整理・外部共有が必要なドキュメント。クラウド管理が前提なので、機密ドキュメントの置き場としては要検討。
- Obsidian：個人の深いPKM・Zettelkastenの実践・双方向リンクやグラフビューを活かした知識の網目作り。チーム共有やAI検索を追加するには設定コストがかかる。
- Tolaria：Gitリポジトリとして管理するチームドキュメントのAI検索・閲覧。編集の豊かさよりGit親和性とローカルAI検索を優先した設計。
逆に、リッチな編集体験や双方向リンクのグラフビュー、プラグインによる拡張性を求めるなら、Obsidianのほうが向いています。
Tolariaは「書く」ためのツールというより「参照する・AIに渡す」ためのツールだと理解しておくと、期待値のズレが起きません。
セットアップとフォルダ構成――インストールから最初のディレクトリを開くまで
tolaria.md/releases にアクセスすると、macOS Silicon・Intel用のDMG、Windows用のEXE、Linux用のAppImageとdebパッケージが並んでいます。
使っているOSに合ったファイルをダウンロードして、通常のアプリと同じようにインストールするだけです。
ビルド環境は不要で、アプリを起動したら既存のMarkdownディレクトリを開くだけで即使えます。
社内ドキュメントを想定したディレクトリ構成の例はこんな感じです。
docs/
├── adr/ # Architecture Decision Records
│ ├── 0001-use-postgresql.md
│ └── 0002-adopt-openapi.md
├── specs/ # 機能仕様・設計ドキュメント
│ ├── auth-flow.md
│ └── notification-system.md
├── meetings/ # 議事録
│ ├── 2026-05-01-sprint-review.md
│ └── 2026-05-08-architecture-review.md
└── knowledge/ # チームの知見・ノウハウ集
├── onboarding.md
└── deployment-runbook.md
この構成にはGit運用とAI検索の両方に効く理由があります。
ファイルの粒度を細かく保つことで、Gitのdiffが読みやすくなり、コンフリクトの影響範囲も小さくなります。
AI検索の観点でも、1ファイルに詰め込みすぎると検索精度が落ちやすいので、トピックごとにファイルを分けておくほうが結果がよくなります。
Tolaria固有の設定ファイルやキャッシュがドキュメントフォルダ内に生成されるかどうかは、現時点でREADMEに明示的な記載を確認できていません。
files-firstという設計思想からすると余分なファイルを生成しない方向性だと推測できますが、念のためOS固有のファイルは.gitignoreで除外しておくのが無難です。
# .gitignore
.DS_Store
Thumbs.db
*.swp
Git連携の実運用――いつcommitして、チームでどう回すか
TolariaはGit操作を内包しません。
ビューア兼エディタとしてTolariaを使い、Git操作はターミナルかGitクライアントで行うという役割分担が前提です。
これはObsidian Gitプラグインの設計とは対照的です。
Obsidian Gitは「GitをObsidianの上に乗せる」アプローチで、アプリ内から自動コミットやプッシュができます。
一方Tolariaは「Gitと並走する」思想で、Git操作はGitの道具でやるという割り切りがあります。
慣れたGitクライアントをそのまま使えるので、Gitに慣れているエンジニアには逆に扱いやすいはずです。
チームでの運用で意識したいのは pull-before-edit の習慣です。
編集を始める前に必ずリモートから最新を取得する。
これを徹底するだけで、コンフリクトの大半は防げます。
典型的な作業フローはこんな形になります。
# 作業開始前に最新を取得
git pull origin main
# Tolariaでドキュメントを閲覧・編集（別ウィンドウ）
# 変更をコミット
git add docs/adr/0003-adopt-redis.md
git commit -m "docs(adr): Redis採用の意思決定を記録"
# リモートに反映
git push origin main
コミットのタイミングは「ドキュメントの意味のある更新ごとに1コミット」が読みやすいです。
作業終了時にまとめてコミットする運用でも問題はありませんが、議事録を追加したのかADRを更新したのかが混ざると、あとでgit logを追うときに辛くなります。
コンフリクトが起きやすいのは、複数人が同一ファイルを同時に編集するパターンです。
前述のディレクトリ構成のようにファイルを細かく分けておくと、同じファイルを触る確率が下がるので、コンフリクトのリスクを構造的に下げられます。
議事録は日付をファイル名に含めて1回の会議ごとに1ファイルにする、ADRは番号付きで1決定1ファイルにする、といった運用がそのまま衝突回避策になります。
ObsidianからTolariaへ――移行コストの正直な見積もり
ObsidianユーザーがTolariaを試すときの最初の疑問は「今のVaultがそのまま使えるか」だと思います。
.mdファイルはMarkdown形式のテキストファイルなので、基本的な閲覧はできるはずです。
ただし、Tolariaが各Markdown機能をどこまでサポートしているかはREADMEに網羅的な記載がなく、実際に開いて確認するのが一番確実です。
互換性の見通しを整理するとこうなります。
- おそらく問題ないもの：通常のMarkdownファイル（見出し・リスト・コードブロック・標準リンク等）。ただし実際に開いて表示を確認することを推奨。
- 要確認のもの：wikilinkの扱い（[[ノート名]]形式）。TolariaがどこまでwikilinkをサポートしているかはREADMEに明示的な記述が確認できていないため、実際に開いて表示を確認するのが確実。YAMLフロントマターも同様に、読み込み挙動は試して確かめてほしい。
- Tolariaでは機能しないもの：Obsidianプラグイン依存のカスタムブロック、DataviewクエリによるDB的なビュー、Canvasファイル（.canvas）、テンプレートプラグインの動的展開。
Dataviewを多用している場合は注意が必要です。
Dataviewのクエリ記法はObsidian固有の機能なので、Tolariaで開いてもただのコードブロックとして表示されます。
Canvasファイルも同様で、.canvasはObsidian独自の形式なので開けません。
現実的な落とし所として、 「編集はObsidian、チーム共有・AI検索はTolaria」という併用パターン がおすすめです。
個人のPKMや深いノート作成はObsidianで続けて、チームに共有するADR・仕様書・議事録だけをGit管理のdocsリポジトリに置き、そこをTolariaで開く。
この分け方なら、Obsidianの資産を捨てる必要もなく、Tolariaの強みだけを活かせます。
Obsidianを捨てる移行ではなく、役割を分担させるイメージです。
Tolariaはまだ比較的新しいプロジェクトで、機能は今も活発に追加されています。
リリースページを見ると2026年5月だけで複数のバージョンが出ており、開発ペースは速いです。
wikilink対応やfrontmatterの扱いなど「今は未確認」な部分が、数ヶ月後には明確になっている可能性も十分あります。
今の段階では「まず開いてみて、動作を自分で確かめる」というスタンスが一番合っています。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援・DX推進に取り組んでいます。
TolariaのようなローカルAIツールの導入支援や、社内ドキュメントのGit管理体制の整備についてもご相談を受け付けています。
興味があればお気軽に お問い合わせページ からどうぞ。