Obsidian プラグインおすすめ15選【2026年】導入と選び方

『Obsidian』はローカル保存のMarkdownノートをリンクで育てていけるのが魅力ですが、プラグインは最初から盛り込みすぎると、設定だけで手が止まりがちです。
この記事は、これから導入する初心者や、入れすぎて整理し直したい人に向けて、まずコア機能で1週間使い、その後に『Tasks』Kanban『Image Converter』など15候補から用途に合う3〜5個だけ選ぶ進め方を案内します。
朝のデイリーノートで未完了をまとめて片づけたい日は、『Tasks』で昨日のタスクが1つのビューに集まるだけで、その日の立ち上がりが変わりますし、会議後にKanbanへカード化して、貼ったスクリーンショットを『Image Converter』が自動で軽量化してくれると、Vaultが重くならないまま運用を続けられます。
導入ではObsidian Helpとコミュニティプラグインの案内に沿ってSettings階層から有効化し、Safe modeの扱い、更新確認、manifest.jsonのminAppVersionとobsidian-releasesのversions.jsonで互換性を見るのが安全です。
Obsidian Changelogで2026年3月5日時点の『Obsidian』v1.12.5を前提に、用途別の最小構成3パターンを先に示しつつ、最新版直後に慌てて足さない判断まで含めて整理します。

結論：まず入れるならこの3つ

初めての3候補

最初に入れるなら、構成は3つで十分です。
軸になるのは『Tasks』または『Calendar』のどちらか1つ、文章の見通しを整える『Outline』またはTable of Contentsのどちらか1つ、そして画像を扱うなら『Image Converter』です。
見出しやリンクを土台に運用する前提がはっきりしているので、最初から多機能化するより「いま詰まっている場所」だけを解消する組み合わせのほうが続きます。

私自身の感覚では、デイリー運用が弱いなら『Calendar』、タスクがあちこちのノートに散るなら『Tasks』、長文を書くなら『Outline』やTable of Contentsという順で、作業の詰まりが抜けていきます。
『Calendar』は日付からノートに入れるので、日報や学習記録が途切れにくくなります。
『Tasks』は未完了の項目を横断して拾えるので、「書いたのに埋もれたタスク」が減ります。
長い記事や議事録を扱うなら、見出し単位で移動できる『Outline』や、本文内に目次を置けるTable of Contentsが効きます。

たとえばPNGのスクリーンショットをWEBPに変換すると、報告例では30%〜80%程度の容量削減が示されることがあります。
ただし実際の削減率は画像の種類（写真かスクリーンショットか）や変換設定によって大きく変化するため、数値はあくまで目安として扱ってください。

導入順の提案

進め方は、機能を増やす順番でほぼ決まります。
最初の1週間はコア機能だけで回し、そこで詰まったポイントを1つだけ特定して、その穴を埋めるプラグインを1つ追加する形が安定します。
たとえば日付起点でノートに入れないなら『Calendar』、未完了タスクの所在が追えないなら『Tasks』、見出しの多い長文で上下移動が増えるなら『Outline』です。

その次の週に足すのも1機能だけに絞ると、何が効いたのかがはっきり見えます。
『Tasks』を入れた週に『Dataview』やKanbanまで同時に足すと、改善したのが収集なのか表示なのか、運用なのか判別しにくくなります。
初心者向けの。
1週間ごとに見直して、増やすなら1つ、外すなら1つの 1-in, 1-out にしておくと、設定画面だけが膨らむ状態を避けられます。

短く整理すると、選び分けはこうなります。

1. タスクをノート横断で集めたいなら『Tasks』
2. 日付から記録へ入る流れを作りたいなら『Calendar』。日報や学習記録など、日時を起点にした記録を付けたい運用に向きます。
3. 長文の構造を見失うなら『Outline』またはTable of Contents
4. スクリーンショットや資料画像が多いなら『Image Converter』

この順番にすると、「記録の入口」「やることの回収」「文章の見通し」「添付ファイルの整理」という、初心者が止まりやすい4か所を順番にほどけます。

アップデート時の互換性チェック

プラグインは入れる瞬間より、アップデート前後のほうが差が出ます。
『Obsidian』本体は『Obsidian Changelog』で更新履歴が追え、2026年3月時点ではDesktop v1.12.5まで確認できますが、最新版が出た直後はコミュニティプラグインの追随待ちが起きやすい時期です。
とくに毎日使う『Tasks』のような中核プラグインは、本体だけ先に上げると表示やコマンド周りの挙動確認が必要になります。

互換性を見るときは、プラグイン側のmanifest.jsonにある minAppVersion が目安になります。
さらにobsidian-releasesで管理されている仕組みでは、プラグインが現在の『Obsidian』より高いバージョンを要求している場合でも、versions.jsonをもとに互換のある版が選ばれる設計があります。
つまり、最新版へ一斉に飛びつくより、プラグインの更新状況が揃うまで少し間を置くほうが、運用は落ち着きます。

更新頻度の補助線としては、Obsidian Plugin Statsのような集計サイトで新規更新の動きを眺める方法もあります。
ただし判断の軸になるのは、人気よりも「自分の運用の中心にいるかどうか」です。
毎日開く『Calendar』や『Tasks』、執筆中ずっと表示する『Outline』のような道具ほど、アップデート直後は一歩引いて様子を見るほうが事故が少なくなります。

Obsidian Web Clipper

Highlight and capture web pages in your favorite browser. Save anything and everything with just one click.

obsidian.md

Obsidianプラグインとは？コアプラグインとコミュニティプラグインの違い

Obsidianの基本

『Obsidian』は、ローカルに保存したMarkdownファイルを土台にしてノートを管理するアプリです。
1つ1つのメモを独立したテキストとして持ちながら、ノート同士を リンク でつないでいくことで、単なるメモ置き場ではなく知識のネットワークとして育てていけます。
用語や画面の考え方は『Obsidian Help』にまとまっていて、双方向リンクやグラフ表示がどう働くのかも公式の説明で追えます。

実際に触ってみると、この「Markdownで書ける」「ファイルが手元にある」「リンクでつながる」という3つの性質が、あとから効いてきます。
ノートアプリによっては入力画面の便利さが先に目立ちますが、『Obsidian』は書いた内容がプレーンなMarkdownとして残るので、構成を変えたり、フォルダを整理したり、別のツールで扱ったりするときの自由度が高いんですよね。
日報、会議メモ、学習記録のように種類の違うノートを並べても、リンクがあるだけで文脈が切れにくいのは、この設計の強みだと言えます。

コアプラグインの役割

『Obsidian』のプラグインは大きく2種類に分かれます。
1つは本体に同梱されているコアプラグイン、もう1つは外部の開発者が公開しているコミュニティプラグインです。
コアプラグインは公式が提供している機能群で、基本機能の延長として扱えるのが特徴です。
代表例としてはDaily notesやTemplatesがあり、ノート作成の導線や定型入力を整える役割を担います。
公式提供なので、安全性や本体との整合性という点で基準が高く、最初に触る機能として収まりが良いです。

このあたりは、機能の多さより「どこまで標準機能で回せるか」を掴むための土台として見ると分かりやすくなります。
たとえばDaily notesとTemplatesだけで1週間運用してみると、足りないものが抽象論ではなく具体的な不足として見えてきます。
朝のメモを毎日同じ形式で作るうちに、「未完了タスクを一覧したい」のか、「前日のノートへ移動したい」のか、「会議メモの見出しを自動で入れたい」のかがはっきりしてきます。
ここが曖昧なまま最初から10個以上入れると、便利なはずの機能が判断ノイズになりやすいのが利点です。
逆に、コア機能だけで1週間回すと、何を足すべきかが自然に絞られます。

コアプラグインは、導入後の説明コストが低いのも利点です。
設定画面の中で完結し、本体更新との歩調もそろっているので、初心者が「まず何から触るか」を決める基準として扱いやすいのが利点です。
『Outline』のように長いノートの移動を助けるものも含め、最初の段階ではコア側だけでも作業の詰まりを十分減らせます。

コミュニティプラグインの位置づけとリスク

コミュニティプラグインは、第三者の開発者が作成・公開している拡張機能です。
『Tasks』Kanban『Dataview』『Calendar』『Excalidraw』『Image Converter』のように、標準機能では届かない運用を埋める役割があります。
日々のタスクを横断表示したい、進行中の案件をボードで見たい、メタデータを一覧化したい、画像を自動変換したいといった要求には、コミュニティプラグインのほうが直接効く場面が多いです。
実務寄りのVaultに育てていく段階では、この拡張性が『Obsidian』の魅力になります。

一方で、ここはコアプラグインと同じ感覚で並べないほうが整理しやすい判断材料になります。
コミュニティプラグインは便利さの幅が広いぶん、更新頻度、互換性、設定の複雑さに差があります。
『Obsidian』本体が更新された直後は、プラグイン側の追随タイミングによって挙動が変わることがあります。
『Obsidian Changelog』や『Plugin security』で見ておきたい論点も、主にこの領域に集まります。
公式機能とは別枠の拡張として位置づけられています。

使い分けの考え方としては、まずコア機能で運用の骨格を作り、必要が発生した箇所にだけコミュニティプラグインを足す、という順序が安定します。
たとえば、日付起点の記録が続くようになってから『Calendar』を足す、タスクの散在が目立ってから『Tasks』を足す、スクリーンショットが増えてきた段階で『Image Converter』を入れる、という流れです。
この順番だと、追加した機能が何を解決したのかを把握しやすく、合わなかったときも切り戻しやすいのが利点です。
Redditなどの初心者向け議論でも、最初から大量導入するより、必要になった分だけ少数追加するほうが失敗が少ないという傾向が目立ちます。

つまり、コアプラグインは『Obsidian』の基本設計を崩さずに使い始めるための土台で、コミュニティプラグインは運用が固まってから不足分を埋める拡張です。
この違いを先に押さえておくと、「人気だから入れる」ではなく「今のVaultに必要だから入れる」という判断に切り替わります。

Obsidianでコミュニティプラグインを安全に導入する手順

導入手順

前提として、本稿の確認環境はObsidian Desktop v1.12.5です。
Obsidian Changelogではv1.12.5が2026-03-05公開となっており、本体を最新版に上げた直後は、テーマやコミュニティプラグイン側で更新が必要になる場面があります。
特に『Dataview』や『Excalidraw』のように機能が大きいプラグインは、本体更新と同日に追随しないこともあるため、導入の順番を雑にしないほうが止まりにくい設計です。

コミュニティプラグインの導線は設定画面にまとまっています。
流れとしては、Settings > Community plugins > Safe modeをオフ > Browse > プラグイン詳細で開発者・バージョン・更新履歴確認 > Install > Enableです。
ここで押さえたいのは、Safe modeをオフにした瞬間に何かが自動で入るわけではなく、第三者製プラグインの導入を許可する段階に入る、という意味だという点です。
Enableを押すまで機能は動きません。

実際に使っていて安定したのは、Browseで候補を開いたら、その場で開発者名とバージョンだけで終わらせず、リリースノートの日付とサポートするminAppVersionまで見てからEnableする流れです。
更新直後の不整合はこの一手間で避けられることが多く、本体だけ先に上がってプラグインがまだ追いついていない状態を拾いやすくなります。
たとえば『Tasks』ならmanifest.jsonにversion 7.21.0、minAppVersion 1.4.0があり、『Excalidraw』はversion 2.20.5、minAppVersion 1.5.7です。
こうした値を見る癖がつくと、「入るかどうか」ではなく「今のVaultで動く条件がそろっているか」で判断できます。

見るべき場所は機能説明だけではありません。
プラグイン詳細を開いたときに、開発者名が明示されているか、配布元リンクがGitHubなどの継続的に管理されている場所につながっているか、更新履歴が読めるかを目視で確認しておくと、導入後に「誰が作っていて、どこを見れば状況が分かるか」が残ります。
権限まわりで気になる挙動があるプラグインほど、この入口情報の有無で安心感が変わります。

更新とバックアップの運用

更新は Settings > Community plugins > Installed > Check for updates でまとめて確認できます。
更新がある場合はリリースノートを読み、変更点や影響範囲を把握してから適用してください。

本体の大きめの更新前や、大型プラグインを追加する前は、Vaultを丸ごとバックアップしておくと復旧が早いです。
普段は細かな差分管理をしていても、いざ表示崩れや設定競合が起きたときに助かるのは、フォルダごとZipで固めた単純な退避だったりします。
私自身、プラグインを増やす前にVaultをZip化しておく運用にしてから、問題が出ても解凍してすぐ戻せるので、検証に踏み込みやすくなりました。
設定ファイルまで含めて戻せるのが、この方法の強みです。

更新では「全部を一度に上げる」より、「本体更新」と「プラグイン更新」を分けて見るほうが挙動を追えます。
たとえば『Dataview』のようにビュー再構築を伴うもの、『Image Converter』のようにファイル処理を伴うものは、更新後にVault全体へ影響が広がりやすいのが利点です。
変更点が大きそうなときほど、先にバックアップを取ってから更新履歴を読み、問題があれば元に戻せる状態を残しておくと、作業の中断時間を短くできます。

互換性とバージョンの読み方

互換性を見るときは、プラグイン一覧の見た目だけでは足りません。
実際には、各プラグインのmanifest.jsonにあるminAppVersionと、リリース管理で使われるversions.jsonが手がかりになります。
開発者は新しいAPIを使うと、その条件に合わせてminAppVersionを上げます。
つまり、この値は「どの『Obsidian』以降なら動く前提か」を読むための最短ルートです。

具体例として、Kanbanはmanifest.jsonにversion 1.2.39、minAppVersion 0.12.3、『Dataview』はversion 0.5.70、minAppVersion 0.13.11が確認できます。
数字だけ見ると古い本体にも対応していそうですが、ここで終わらせず、現在使っている『Obsidian』本体との関係を見る必要があります。
本体側が先に新APIへ移った直後は、minAppVersionを満たしていても、プラグイン側の追随待ちになることがあります。
この仕組みはobsidian-releasesの登録フローを見ると把握しやすく、manifestとversions.jsonの組み合わせで互換性が管理されています。

体感としては、『Obsidian』本体の更新直後に「インストールできる」と「安定して使える」の間に小さな差が出ます。
そこで役立つのが、Browse画面やGitHubのリリースノートで更新日時を見て、本体更新の前後関係を照らす見方です。
本体が先にv1.12.5へ進み、プラグインの更新日がそれより前で止まっているなら、導入自体は可能でも、少し待ったほうが無難なケースがあります。
見分け方を知っていると、原因不明の崩れに見えるものが、実際には単なる追随待ちだと判断できます。

Sync/Publish利用時の注意

『Obsidian』本体は個人利用で無料ですが、SyncやPublishは有料オプションです。
この条件があるので、コミュニティプラグインを含む運用を有料オプションに乗せるときは、いきなり本番Vaultへ重ねるより、先にテスト用Vaultで互換性を見る流れのほうが整っています。

特にSyncを使う場合、プラグイン設定や生成ファイルまで同期対象に入るため、デスクトップ側で問題が出た構成をそのまま他の端末へ広げてしまうことがあります。
『Excalidraw』の補助ファイルや、『Image Converter』の変換設定のように、ノート本文以外へ影響する要素があると、確認なしで同期したときの切り戻しが面倒になります。
先にテストVaultで導入し、同期を有効にして、設定ファイルや生成物がどう動くかを見てから本番へ移すと、運用の見通しが立ちます。

Publishでも、プラグイン由来の表示がそのまま公開側で再現されるとは限りません。
公開時に見えるのはMarkdown本文や添付ファイルが中心で、Vault内では成立していた挙動が、そのまま外へ出るわけではないからです。
図や特殊表示を扱うプラグインほど、公開用の出力物を別途持つ設計のほうが安定します。
コミュニティプラグインは便利ですが、同期や公開まで含めると「その機能がどこまで持ち出せるか」という視点が必要になります。

Obsidianおすすめプラグイン15選

プラグイン名は、できるだけ公式のコミュニティプラグインストアや公式配布ページの表記にそろえて読むと混乱が減ります。
特にTable of Contents系やHighlight系は実装が複数あるため、記事名だけで判断せず、配布元のGitHubやヘルプページまで見て区別する前提で捉えると整理しやすくなります。
人気や更新頻度の傾向を見る補助線としてはObsidian Plugin Statsも便利ですが、導入判断をその数字だけに寄せるより、用途と更新の継続性を並べて読むほうが実運用ではぶれません。

まず、最初に迷いやすい6つを用途でざっくり並べると次のようになります。

モバイル対応はプラグインごとに異なります。
使用前に各プラグインの配布ページやmanifestを確認して、対象端末で期待する挙動がサポートされているかを確認してください。
モバイル対応はプラグインごとの差があるので、一律に語るより個別ページの記載を参照するのが確実です。
『Dataview』やKanbanはmanifest上でデスクトップ専用ではないことが確認できますが、『Tasks』や『Calendar』は検索結果上で明示が見られない場合もあります。
ここでは用途別に比較し、端末ごとの運用は個別に検討します。

Tasks

『Tasks』は、Vault全体に散らばったMarkdownのチェックボックスをまとめて扱うための定番です。
提供元はobsidian-tasks-group、GitHubで確認できる最新バージョンは7.21.0、minAppVersionは1.4.0です。
単なるチェックリスト強化ではなく、「期限」「優先度」「完了日」などの条件で抽出できるところに価値があります。

用途は、日々のメモに混ざったタスクの横断管理です。
会議メモ、読書ノート、デイリーノートのどこに書いたTODOでも、クエリで一か所に集められます。
毎朝、未完了タスクだけをデイリーノートに抜き出す形にすると、昨日のメモに埋もれていた作業が目に入り、見落としが体感ではっきり減ります。
タスク管理専用アプリへ移すほどではないが、ノート内のTODOは放置したくない人に特に合います。

向いているのは、ノートとタスクを分けたくない人です。
『Obsidian』を「考える場所」と「実行する場所」で分断せず、同じ文脈のまま扱えます。
逆に、厳密な担当者管理や工数管理、通知中心の運用をしたいなら、プラグイン内で頑張るより外部ツールのほうが筋がいい場面もあります。

導入のコツは、最初から複雑なクエリを書かないということです。
まずは「未完了のみ」「期限ありのみ」程度の絞り込みから始めると、書式を覚える負荷が下がります。
タスクの書き方も、日付や優先度を全部付けるより、期限だけ付ける運用から入るほうが続きます。

入れすぎ注意の観点では、『Tasks』自体より「タスク管理を全部クエリで解決しようとする姿勢」が詰まりやすい判断材料になります。
並び替え、タグ、状態管理を一気に盛ると、書くより整える時間が増えます。

代替候補としては、Markdown標準のチェックボックスだけでも最低限は回ります。
より視覚寄りに進捗を見たいならKanban、メタデータまで含めて一覧化したいなら『Dataview』が候補です。

（公式ドキュメント - Tasks User Guide - Obsidian Publish

Not Found File （公式ドキュメント.md does not exist.

publish.obsidian.md

Kanban

Kanbanは、Markdownベースでボードを作れるプラグインです。
GitHubのmanifestではバージョン1.2.39、minAppVersionは0.12.3、isDesktopOnlyはfalseとなっています。
カードを列間で移動しながら進捗を見る構成で、文章の世界だった『Obsidian』に「いま止まっている場所」を可視化するレイヤーを足せます。

用途は、進行中の案件整理です。
個人タスクでも使えますが、真価が出るのは「Backlog」「Doing」「Waiting」「Done」のように列を切って、停滞箇所を会話の起点にするときです。
実際、止まった列が一目で分かるので、週次レビューでは「どこで止まっているか」の確認がすぐ終わり、会話が前に進みました。
箇条書きだけのプロジェクトメモより、ボトルネックの発見が早くなります。

向いているのは、タスクを文章より配置で把握したい人です。
案件ごとの状態が頭に残りやすく、チームで画面を見ながら話す場面とも相性があります。
一方、デイリーノート中心で細かな記録を積む人だと、ボードを開く回数が減って埋もれやすくなります。

導入のコツは、列を増やしすぎないということです。
3列か4列で始めたほうが、意味の重複が起きません。
カードに情報を詰め込むより、必要なら元ノートへリンクする設計にしておくと、ボードの視認性が落ちにくくなります。

入れすぎ注意のポイントは、「何でもKanbanに載せる」状態です。
読書メモ、買い物、長期研究、日々の雑務まで同じボードへ入れると、列の意味がぼやけます。
プロジェクト管理に用途を絞ったほうが効きます。
入れすぎ注意のポイントは、何でもKanbanに載せると列の意味が薄れてしまう点です。
プロジェクト管理に用途を限定すると、ボードの読みやすさが保てます。
導入前には必ず GitHub のリリース履歴や Issues を直接確認することをおすすめします。

Dataview

『Dataview』は、ノート内のメタデータを表やリストとして表示するための代表格です。
GitHubで確認できるバージョンは0.5.70、minAppVersionは0.13.11です。
タグ、frontmatter、ファイル情報を読み取り、検索ではなく「条件付きの一覧」を組み立てられます。

用途は、ノートを半ばデータベースとして扱うということです。
たとえば読書ノートなら著者別一覧、プロジェクトノートなら期限順リスト、学習メモなら分野別の集計という形で、Markdownの集合に構造を与えられます。
『Obsidian』を単なるメモ置き場から「自分専用の索引付き資料庫」へ一段引き上げるのがこのプラグインです。

向いているのは、frontmatterやプロパティを苦にしない人です。
ノートを増やすほど価値が出るので、記録が蓄積しているVaultほど恩恵が大きくなります。
逆に、ノートを気楽に書き散らしたい時期には、入力ルールの整備が重荷になることがあります。

導入のコツは、最初からdataviewjsへ行かず、DQLで「一覧を1つ作る」ということです。
たとえば読書ノートの表を1枚作るだけでも効果が見えます。
Propertiesと命名規則をそろえておくと、後から修正する手間が減ります。
大量ノートで自動更新を多用すると再構築の負荷を感じやすいので、ビューの数や更新の仕方は絞ったほうが安定します。

入れすぎ注意のポイントは、Dataview前提でしかノートを読めなくなる状態です。
クエリが壊れると一覧ごと見えなくなるため、元ノート単体でも読める構造は残しておくほうが長持ちします。

代替候補は、コアの検索機能やタグ運用です。簡易集計ならそれでも足ります。タスク中心なら『Tasks』、視覚的な進捗ならKanbanのほうが導入負荷は軽めです。

Calendar

『Calendar』は、サイドバーにカレンダーを置き、Daily Notesとつないで日付起点の記録を回しやすくするプラグインです。
『Calendar』は、サイドバーにカレンダーを表示しDaily Notesと連携して、日付を起点に記録作成をスムーズにするプラグインです。
用途は、日単位の記録導線を作るということです。
何を書いたかより、いつ書いたかを起点に見返すタイプの人には特に効きます。
学習記録、日報、体調ログ、作業ログのように、時間の連続性そのものが意味を持つノートと相性がいいです。

向いているのは、デイリーノートをすでに使っている人、もしくはこれから始める人です。
日付から飛べるだけで、ノート作成の心理的なハードルが下がります。
白紙ページを作るより「今日のページを開く」ほうが動作が具体的だからです。

導入のコツは、テンプレートを先に決めすぎないということです。
最初は見出し2つか3つだけの軽い日次ノートで回し、運用が固まってから週次や月次へ広げるほうが無理が出ません。
Periodic Notesと組み合わせる発展形もありますが、最初は『Calendar』単体で十分です。

入れすぎ注意のポイントは、「毎日書くこと」が目的化する状態です。記録する中身より穴埋めの継続が前に出ると、ノートが負担になります。

代替候補は、コアのDaily Notesだけでも成立します。
日付UIを加えたいなら『Calendar』、一覧や集計まで伸ばしたいなら『Dataview』との組み合わせが候補です。

GitHub - liamcain/obsidian-calendar-plugin: Simple calendar widget for Obsidian.

Simple calendar widget for Obsidian. Contribute to liamcain/obsidian-calendar-plugin development by creating an account

github.com

Excalidraw

『Excalidraw』は、図解・スケッチ・構造整理のための大型プラグインです。
GitHubのmanifestではバージョン2.20.5、minAppVersionは1.5.7です。
.excalidraw形式を扱い、PNGなどへのエクスポートにも対応しています。
モバイルサポートへの言及も公式配布ページで確認できます。

用途は、文章では詰まる内容を図に逃がすということです。
概念整理、アーキテクチャ図、会議中のラフ、思考の枝分かれなど、テキストだけだと関係性が見えにくい場面で力を発揮します。
ノート間リンクともつながるため、単なるお絵描きではなく、Vaultの中に図解レイヤーを持ち込めます。

向いているのは、考えながら描く人です。
文章をきれいに書く前に、まず箱と矢印で整えたいタイプには刺さります。
逆に、完成した文章だけを蓄積したい人だと、起動頻度が上がらず宝の持ち腐れになりかねません。

導入のコツは、公開や共有の出口を先に意識しておくということです。
.excalidrawはObsidian内では編集しやすい一方、外へ持ち出すならPNGのほうが扱いやすい場面が多いので、画像エクスポート運用を前提にしたほうが流れがきれいです。
図を増やすなら保存先フォルダも分けておくと散らかりません。

入れすぎ注意のポイントは、文章で十分な内容まで図解に変換してしまうということです。図を作る時間と情報整理の時間が二重になり、ノート作成が重くなります。

代替候補は、Mermaid記法や通常の画像添付です。
手描き感と自由配置がほしいなら『Excalidraw』、簡潔な構造図で足りるならテキストベースの図表でも回ります。

GitHub - zsviczian/obsidian-excalidraw-plugin: A plugin to edit and view Excalidraw drawings in Obsidian

A plugin to edit and view Excalidraw drawings in Obsidian - zsviczian/obsidian-excalidraw-plugin

github.com

Image Converter

『Image Converter』は、画像の変換と圧縮を自動化するプラグインです。
提供元はxRyulで、対応形式としてWEBP、JPG、PNG、HEIC、TIFが確認できます。
Obsidian Plugin Statsでは最新バージョン1.4.1の表記があります。
貼り付け時やドラッグ＆ドロップ時の自動変換、Vault全体への一括処理も特徴です。

用途は、スクリーンショットや資料画像が増えるVaultの軽量化です。
画像をそのまま貼る運用だと、ノート本文より添付ファイルのほうが大きくなりがちです。
このプラグインを入れてスクショを自動で.webp化する設定にしてから、同期時の重さが目に見えて軽くなりました。
画像の内容によって差はありますが、WEBP変換は元のPNGやJPEGよりファイルサイズを圧縮できることが多く、枚数が増えるほど効いてきます。

向いているのは、スクショを大量に貼る人、Webクリップや資料整理を『Obsidian』内で完結させたい人です。
逆に、画像をほとんど使わないテキスト中心のVaultなら優先度は上がりません。

導入のコツは、自動変換のタイミングと画質設定を先に決めるということです。
貼り付け時に即変換するか、後からまとめて処理するかで運用感が変わります。
画像の保存先も分けておくと、変換後の管理が楽になります。

入れすぎ注意のポイントは、変換ルールを複雑にしすぎるということです。
形式、品質、リサイズ、出力先を細かく分けると、どの設定で保存された画像か分かりにくくなります。

代替候補は、OS側での事前圧縮や手動変換です。
ただ、貼り付け時点で自動処理できる利点は大きく、スクショ中心の運用では『Image Converter』の価値が発揮されます。

GitHub - xRyul/obsidian-image-converter: ⚡️ Convert, compress, resize, annotate, markup, draw, crop, rotate, flip, align images directly in Obsidian. Drag-resize, rename with variables, batch process. WEBP, JPG, PNG, HEIC, TIF.

⚡️ Convert, compress, resize, annotate, markup, draw, crop, rotate, flip, align images directly in Obsidian. Drag-resize

github.com

Outline

『Outline』は、Obsidian公式のコアプラグインです。
ノート内の見出し一覧をサイドバーに表示し、クリックでその位置へ移動できます。
ノート更新時に自動反映されるため、長文ノートの移動コストを下げる基本機能として見るのが適切です。
公式のコア機能として位置づけられています。

用途は、長いノートの内部ナビゲーションです。
講義ノート、仕様書、リサーチメモのように見出し階層が深くなるノートほど効果が出ます。
ページ内検索とは違い、構造そのものを見渡せる点が強みです。

向いているのは、1ノートをある程度の長さで育てる人です。逆に、短いメモを大量に分割して保存するスタイルなら、体感差は小さめです。

導入のコツは、見出し設計とセットで使うということです。
H2とH3が整っていれば、『Outline』は自然に効きます。
見出しを飾りではなく構造として打つ習慣がないと、サイドバーに情報が出ても役立ちません。

入れすぎ注意という意味では、ここはコミュニティプラグインを足す前に見直したい領域です。目次やナビゲーションの悩みが、まずコア機能で解決する場合があります。

代替候補は同じくコア機能のページ内検索です。ノート本文へ目次自体を埋め込みたいなら、次のTable of Contents系が候補になります。

Outline - Obsidian Help

Outline is a core plugin that lists the headings in the active note. To navigate to that section in the note, click on t

help.obsidian.md

Table of Contents

Table of Contents系は実装が複数あります。
代表例としてAutomatic Table Of Contentsは、ノート内に目次を生成・挿入し、見出し変更時の自動更新にも対応します。
一方で、静的生成型やフローティング表示型など別実装もあるため、「目次プラグイン」という括りで考えると違いが見えにくくなります。

向いているのは、長文記事やマニュアルを書いている人です。
ノート単体で読ませる構成にしたい場合に相性が出ます。
逆に、自分だけが読む作業メモなら『Outline』で足りることも多いです。

導入のコツは、自動更新か静的生成かを先に分けて考えるということです。
見出し変更が多いノートでは自動更新型が便利ですが、本文を自分で整えたい人には静的型のほうが扱いやすいことがあります。

入れすぎ注意のポイントは、『Outline』と本文目次を二重に重ねて、情報が過剰になるということです。
サイドバーで足りるなら本文目次は不要ですし、公開文書中心なら逆に本文目次だけで足りる場面もあります。

代替候補は『Outline』です。コア機能の範囲で済むなら、追加プラグインを増やさずに済みます。

Iconize

『Iconize』は、ファイルやフォルダにアイコンを付けて視認性を上げるプラグインです。
提供元はFlorian Woelkiで、アイコンパック導入、カスタムアイコン登録、ルールベース適用、Frontmatter連携、タブ上のアイコン表示などに対応しています。

用途は、Vaultの見た目を整えることではなく、「種類の違いを一瞬で判別すること」です。
読書ノート、会議メモ、日次ログ、テンプレートのように役割がはっきり分かれているなら、文字を読む前に識別できます。
情報設計の補助として使うと効きます。

向いているのは、ノート数やフォルダ数が増えてきた人です。
一覧の文字列だけでは探しにくくなってきた段階で入れると恩恵が出ます。
逆に、Vaultがまだ小さいうちは優先順位は高くありません。

導入のコツは、色やアイコンの意味を先に決めるということです。
たとえば本は本型、会議は吹き出し、日記はカレンダーというように、ルールがあると見返したときに迷いません。

入れすぎ注意のポイントは、装飾目的でアイコンを盛りすぎるということです。意味のない色や記号が増えると、見た目はにぎやかでも判別性能は下がります。

代替候補は、フォルダ名や接頭辞の命名ルールです。視覚記号がなくても、文字の設計だけで十分整理できる人には不要です。

Local Graph系プラグイン

Local Graph系は、ノート周辺のリンク関係をより見やすくしたいときの拡張候補です。
Obsidian本体にもローカルグラフ機能がありますが、コミュニティ側にはインタラクティブ性や可視化表現を増やす派生が存在します。
代表例として記事内ではJuggl系が言及されることがあります。

用途は、「このノートがどこにつながっているか」を探索するということです。
ある概念ノートを中心に周辺ノートを辿ったり、関係の薄い孤立ノートを見つけたりできます。
リンクを育てる楽しさを感じやすい領域でもあります。

向いているのは、ネットワーク的に知識を育てたい人です。
単発メモの保管より、概念同士の接続に価値を感じるなら面白さがあります。
逆に、業務メモや日報の整理が主目的なら、優先順位は上がりません。

導入のコツは、まずコアのローカルグラフを使ってから不足分を見るということです。
拡張は見た目の魅力が強い反面、レンダリング負荷や操作学習も伴います。
ノードを増やしすぎると「見えるが読めない」状態になりやすいので、対象範囲を絞る前提で扱うのが合っています。

入れすぎ注意のポイントは、可視化そのものが目的化するということです。グラフは探索の補助であって、ノート内容の代わりにはなりません。

代替候補は、ObsidianコアのLocal graph viewです。まずは標準機能で十分なことが多いです。

Settings Search系プラグイン

Settings Search系は、増えてきた設定項目を検索で探せるようにする補助プラグイン群です。
具体的な実装は複数あり、検索結果からは開発者やバージョンの一括確認まではできませんが、狙いは明快で、「どこに設定があったか」を探す時間を減らすことにあります。

用途は、プラグイン数が増えた後の設定迷子対策です。
『Obsidian』は本体設定、コアプラグイン設定、コミュニティプラグイン設定が積み上がるので、項目名を覚えていても場所を忘れがちです。
設定画面の中を直接検索できるだけで、調整の再現性が上がります。

向いているのは、複数プラグインを並行運用している人です。導入初期には不要でも、構成が固まってきた段階で効きます。

導入のコツは、設定を増やすためではなく、既存設定の把握に使うということです。探せるようになると調整箇所が目に入り、逆に設定をいじりすぎる罠もあります。

入れすぎ注意のポイントは、本来触らなくてよい項目まで調整したくなるということです。検索性の向上と設定最適化は別物です。

代替候補は、Obsidian標準の設定画面内のカテゴリ整理と、自分用メモへの設定記録です。

Highlight系プラグイン

Highlight系は、選択テキストに色付きハイライトを付けるためのプラグイン群です。
代表例としてHighlightr系があり、色の切り替え、ホットキー割り当て、抽出補助などを備えた実装があります。

用途は、読書メモやレビュー時の「どこを後で拾うか」を明確にするということです。
Markdown標準の強調だけでは区別しにくい場面で、色によるレイヤー分けができます。
たとえば「要点」「疑問」「引用候補」で色を変えると、再読時の視線移動が短くなります。

向いているのは、文章を読み返して再利用する人です。
インプット整理と相性がよく、長文メモでもフックを作れます。
逆に、テキストの可搬性を最優先する人には慎重なほうが合います。
実装によってはHTML＋CSS前提になるため、Markdownだけで完結するわけではないからです。

導入のコツは、色の意味を固定するということです。
毎回違う意味で使うと、後から見返したときに解釈できません。
導入のコツは、色ごとに意味をあらかじめ決めておくということです。
入れすぎ注意のポイントは、ページを塗り分けすぎるということです。
色が増えるほど重要箇所のコントラストは落ちます。
入れすぎ注意のポイントは、色の使い分けが過剰になると情報の識別性が落ちるということです。
必要な色だけに絞る運用をおすすめします。

Web Clipper連携系

『Obsidian Web Clipper』は、Obsidian公式のブラウザ拡張です。
Chrome Web Storeや公式ページで配布されており、WebページをMarkdownとしてVaultへ保存できます。
テンプレートによる保存形式のカスタマイズ、ハイライト、記事抽出、CSSセレクタやschema.org情報の利用といった柔軟性もあります。

用途は、Web上の情報を「あとで読む」ではなく「あとで使う」形で取り込むということです。
URLだけ残すより、本文やメタデータごとVaultへ入るので、検索や再編集のしやすさが上がります。
調べもの、競合調査、引用候補の収集と相性がいいです。

向いているのは、ブラウザと『Obsidian』を行き来しながらノートを育てる人です。ブックマークでは埋もれやすい情報を、自分のノート体系へ載せ替えられます。

導入のコツは、保存テンプレートを1つ決めるということです。
ページタイトル、URL、取得日、抜粋という最低限の型があるだけで、後の再利用率が上がります。
画像まで大量に取り込む運用なら、『Image Converter』との相性も見えてきます。

入れすぎ注意のポイントは、クリップの量が読む量を上回るということです。取り込みの摩擦が減るぶん、未読の山ができやすくなります。

代替候補は、ブラウザの標準ブックマークやRead it later系サービスです。
ただし、Markdownで自分のVaultに置ける点は『Obsidian Web Clipper』ならではです。

Properties補助系プラグイン

Properties補助系は、Obsidian本体のProperties機能を扱いやすくしたり、編集・表示・連携を補ったりするプラグイン群です。
Obsidian本体側でもProperties UIは整ってきていますが、運用を詰めると補助レイヤーが欲しくなる場面があります。

用途は、frontmatterやPropertiesの操作負荷を下げるということです。
たとえば入力補助、折りたたみ、見せ方の整理、他プラグインとの橋渡しなどが典型です。
『Dataview』を多用するなら、Propertiesの整備は一覧品質に直結します。

向いているのは、メタデータを継続的に書く人です。読書記録、プロジェクト台帳、論文メモなど、項目をそろえて蓄積するVaultで効果が出ます。

導入のコツは、先に本体のPropertiesで足りない箇所を明確にするということです。
補助系は便利ですが、何を補うのかが曖昧だと増やしただけで終わります。
入力項目が固定されているなら、テンプレートとの併用も効きます。

入れすぎ注意のポイントは、Properties自体が目的になるということです。項目を増やし続けると、ノートを書く前にフォーム入力で疲れます。

代替候補は、Obsidian本体のProperties機能そのものです。
まずはコアで回し、一覧化が必要になった段階で『Dataview』との接続を考える流れが自然です。

Agent Client

『Agent Client』は、ACP対応の外部エージェントと『Obsidian』をつなぐプラグインです。
提供元はRAIT-09で、公式ドキュメントとGitHubが公開されています。
プラグイン自体は無料ですが、接続先AIサービス側で料金が発生する構成があります。

用途は、Vault内のノートを土台にAIエージェントを作業へ組み込むということです。
要約、再構成、下書き支援、整理補助といった場面で、単発チャットより一歩踏み込んだ連携が可能になります。
ノート資産を外部の作業系AIとつなぐ窓口として見ると分かりやすいのが利点です。

向いているのは、すでにAIサービスを日常的に使っていて、ノートとの往復を減らしたい人です。
反対に、『Obsidian』自体の運用がまだ固まっていない段階では、便利さより設定項目の多さが前に出やすいのが利点です。

導入のコツは、AIに何を任せるかを限定するということです。
要約だけ、見出し再構成だけ、アイデア展開だけ、と役割を絞ると評価しやすくなります。
認証情報や接続先の理解も必要になるので、純粋なノート整理プラグインより一段上のレイヤーとして扱ったほうが混乱しません。

入れすぎ注意のポイントは、ノート作成そのものをエージェント任せにしすぎるということです。
『Obsidian』の強みは自分の文脈を残せる点なので、生成文の比率が上がりすぎると、後で見返したときに「なぜこう書いたか」が薄くなります。

代替候補は、外部AIサービスをブラウザやCLIで単独利用する形です。Vault内で完結させたいか、作業を外に出して割り切るかで向き不向きが分かれます。

目的別のおすすめ構成3パターン

初心者最小構成

最初の組み合わせとして扱いやすいのは、コアプラグインのDaily notesとBacklinksを軸にして、『Calendar』か『Tasks』を1つ、さらに『Outline』かTOC系プラグインを1つ足す形です。
これなら記録、振り返り、移動の3点がそろい、設定画面を行き来する時間を増やさずに済みます。
コア機能は土台として案内されており、拡張より先に基本の流れを固める発想と相性がいいです（『Obsidian Help』）。

この構成の肝は、1つのノートを高機能化することではなく、毎日開く入口を固定することです。
学習記録や日報なら『Calendar』とDaily notesの組み合わせが特に噛み合います。
カレンダーに記録の有無がそのまま見えるので、空白の日が視界に入ります。
私もこの組み合わせにしてから「今日は何を書くか」より「今日は空欄を埋める」が先に立つようになり、1週間ほどで継続の引っかかりが軽くなりました。
習慣化の初期は内容の質より、ノートを開く回数が先に積み上がります。

一方、日付よりもやること中心で回したいなら、『Calendar』ではなく『Tasks』を入れるほうが筋が通ります。
デイリーノートの中に書いたチェックボックスを後から拾えるので、TODOが各ページに散って埋もれる状態を避けられます。
『Tasks』は公式ドキュメントが整っていて、GitHub上のmanifestではバージョン7.21.0、minAppVersion 1.4.0が確認できます。
初心者段階では複雑なクエリまで踏み込まず、まずは「今日書いたタスクを後で一覧できる」だけでも価値があります。

見出し移動の補助は、『Outline』かTOC系プラグインのどちらか1つで足ります。
『Outline』は今書いているノートの見出しを横で追えるので、長いメモでも位置感覚を失いません。
TOC系はノート本文内に目次を置けるため、読む側の導線まで整えたいときに向いています。
最初から両方入れても役割が重なりやすいので、編集中の移動を重視するなら『Outline』、完成ノートの見返しやすさを優先するならTOCという切り分けで十分です。

タスク管理構成

タスクを主役にするなら、『Tasks』＋Kanban＋『Calendar』が基準になります。
ここに必要が出た段階で『Dataview』を足すと、一覧抽出まで一段深く掘れます。
この並びが噛み合う理由は、それぞれの担当が明確だからです。
『Tasks』はタスクの横断管理、Kanbanは進行状況の視覚化、『Calendar』は期限や実施日の把握に向いています。
役割がかぶり切らないので、3つ入れても混線しにくい組み合わせです。

実運用では、日次は『Tasks』、週次はKanban、月単位の眺めは『Calendar』と置くと流れが整います。
『Tasks』ではデイリーノートや案件メモに書いたチェックボックスを集めて、その日やることを確認します。
週の途中で案件数が増えてきたら、Kanbanで「未着手」「進行中」「待ち」に分けると詰まりが見えます。
さらに『Calendar』で締切日やレビュー日を日付起点で見ると、ボード上では気づきにくい偏りも拾えます。
タスク管理でつまずくのは、情報が足りないからではなく、同じ画面で全部見ようとして役割が混ざるときです。

Kanbanは見た目の把握が速いのが強みですが、ボードだけに寄せると「今週動いている案件」は見えても、「自分が書いた全タスク」は拾いにくくなります。
そこで『Tasks』が効きます。
逆に『Tasks』だけだと一覧は取れても、案件ごとの滞留や手戻りは見えづらいので、Kanbanの列移動が補完になります。
『Calendar』を加えると、締切が月末に固まりすぎていないかも一目で掴めます。
3つを同列に置くより、抽出・視覚化・日付確認を分担させると無理がありません。

『Dataview』は必須ではありませんが、読書記録や案件台帳のようにPropertiesをそろえているなら相性が出ます。
たとえば担当者、状態、期限といったメタデータを持つノートを一覧化したいとき、『Tasks』では拾いきれない切り口が作れます。
GitHub上では『Dataview』のバージョン0.5.70、minAppVersion 0.13.11が確認でき、表やリストの抽出に対応しています。
ただ、ここは最初から加えるより、タスク運用の型ができてから足したほうが詰まりません。

前述の通り、情報が混在しているプラグインは慎重に扱うべきです。
導入前に提供元の更新履歴や Issues を確認し、最新のメンテナンス状況を把握してから運用に組み込んでください。

執筆・ナレッジ整理構成

文章中心で使うなら、『Outline』＋TOC系プラグイン＋Properties補助系＋『Image Converter』の組み合わせがまとまりやすいのが利点です。
図で考えるタイプなら、ここに『Excalidraw』を追加します。
この構成では、発想を増やすよりも、記事や技術メモの整形、参照性、Vaultの軽量化を優先します。
ノートが増えてくると困るのは「何を書くか」より「どこに何があるか」と「画像が重くて扱いづらい」の2点なので、そこを先回りして整えるイメージです。

『Outline』とTOC系を並べる理由は、役割が微妙に違うからです。
『Outline』は執筆中のナビゲーションに効き、TOCは完成後の読み直しや共有時の導線になります。
実際、長めの記事草稿や技術メモでは、この2つだけで段落の迷子が減りました。
見出しを上下に行き来しながら書けるので、重複説明や見出しの飛びも拾いやすく、レビューに回す前の整え直しが短くなった感触があります。
文章量が増えるほど、エディタ内での現在地を見失わないことが効いてきます。

Properties補助系は前に出る主役ではありませんが、記事メモ、読書ノート、技術検証メモのように型があるノートでは効きます。
カテゴリ、公開状態、関連テーマ、参照元といった項目を揃えておくと、後で一覧したときのノイズが減ります。
ここで大事なのは項目数を増やすことではなく、検索や抽出に使うものだけ残すことです。
執筆ワークフローでは、入力フォームの豪華さより、後から並べ替えたときの効き目のほうが価値になります。

WEBP変換を通すと、画像の種類や設定次第で大きくファイルサイズが減る場合があります。
報告例に30%〜80%の削減がある一方、実効値はケースバイケースなので、導入前にサンプルで試して運用ルールを決めることを推奨します。

図解ベースで考えるなら『Excalidraw』の追加も合います。
GitHub上のmanifestではバージョン2.20.5、minAppVersion 1.5.7が確認でき、モバイルサポートにも言及があります。
構造図、概念整理、画面遷移のメモまで1つのVaultで持てるのは魅力です。
ただ、文章が主で図が補助なら、先に『Outline』とTOCを固めたほうが執筆全体の流れは安定します。
図は発想を広げる道具ですが、記事として読める形に整えるのは見出し構造だからです。

プラグインを入れすぎないための選び方

課題駆動の選定フロー

プラグイン選びでいちばん崩れにくいのは、最初に機能を集めるのではなく、まずコア機能で回し始めるということです。
ノート作成、リンク、検索、見出し移動のような基本動作だけでも、日々の記録や資料整理は想像以上に前へ進みます。
その状態で詰まりが見えたら、原因を1つに絞ってから、対応するプラグインを1つだけ足す流れにすると、設定の増殖を抑えられます。

たとえば、タスクが複数ノートに散って追えなくなったなら『Tasks』、案件の流れを列で見たいならKanban、日付起点で記録を見返したいなら『Calendar』、メタデータを表で束ねたいなら『Dataview』という順番です。
「便利そうだから入れる」ではなく、「今の詰まりを解消するために入れる」に切り替えるということです。
Redditの初心者向け議論でも、長いおすすめ一覧をそのまま持ち込むより、必要なものを上位だけに絞るほうが価値があるという流れが目立ちます。
実際、75個以上のプラグインを扱う長い記事が話題になっても、そこからTop 10〜15に絞って考えるべきだという反応が出ていました。

依存しすぎない判断も欠かせません。
私が見る基準は、「その機能が無いとノートが壊れるか」です。
『Dataview』の一覧が消えても元ノート自体は残るなら、依存度はまだ抑えられています。
反対に、そのプラグインが止まった瞬間に主要ワークフローが崩れる構成は、後から身動きが取りにくくなります。
離脱しやすさを先に見ておくと、導入時のテンションで複雑な仕組みを作り込みすぎずに済みます。

この考え方にしてから、私は週ごとに「それ本当に必要か」を見直す時間を取り、使っていないプラグインを外すようにしました。
続けていくと、入れたまま触っていないものが少しずつ減り、起動や表示まわりも落ち着いてきました。
プラグイン数を競うより、今のVaultで役割があるかだけを見るほうが、結果として長く回ります。

安全性・互換性チェックリスト

プラグイン選定のチェックリスト（簡易版）:

1. 最終更新日が新しいか、2) manifest の minAppVersion が自身の本体と合致するか、3) Issues に同様の不具合報告がないか、4) 提供元（GitHub/README）の信頼性、5) 補助的に Obsidian Plugin Stats の動向、の順で確認してください。

minAppVersion は特に実務的です。
これは、そのプラグインがどの『Obsidian』本体バージョンを前提にしているかを示す目印で、配布の仕組みと一緒に扱われています。
たとえば『Tasks』は minAppVersion が 1.4.0、『Excalidraw』は 1.5.7、『Dataview』は 0.13.11、Kanbanは 0.12.3 と確認できます。
本体を更新したあとに急に動かなくなる場面は、この前提条件の差で説明できることが少なくありません。

Issues は件数そのものより、中身の傾向を見たほうが判断しやすい場面が多いです。
最新版で不具合報告が集中しているのか、質問が多いだけなのか、放置された互換性問題が続いているのかで、受ける印象は変わります。
提供元も同様で、公式ヘルプやドキュメントが整っているか、GitHub の README や help URL が用意されているかを見ると、導入後に迷子になりにくいかが見えます。
『Tasks』は公式ドキュメントがあり、『Dataview』や『Excalidraw』も専用ドキュメントが整っているので、機能が多くても追いかける先がはっきりしています。

情報が混在しているプラグインは慎重に扱ったほうが収まりがいいです。
Kanbanのように、便利さは広く認識されていてもメンテナンス状況の記述が記事ごとに割れているものは、機能自体よりも「止まったら困る位置に置かない」ほうが安全です。
見える化担当としては優秀でも、Vaultの根幹まで任せると戻しづらくなります。

アップデート運用とロールバック戦略

アップデートでつまずきやすいのは、最新版が悪いというより、本体側とプラグイン側の更新タイミングがずれるということです。
Obsidian Changelogを見ると、Desktop v1.12.4 が 2026-02-27、v1.12.5 が 2026-03-05 に公開されていて、最近も短い間隔で更新が続いています。
こういう時期は、大型プラグインが追随中のことがあり、テーマやCSSスニペットまで合わせて手を入れないと見た目が崩れることがあります。
新機能を早く触りたい気持ちは出ますが、日常のVaultでいきなり本番適用すると、原因の切り分けが面倒になります。

そこで効くのがテスト用Vaultです。
普段のVaultをそのまま更新するのではなく、同じプラグイン構成を再現した検証用のVaultで先に開くと、表示崩れやコマンド不発を先回りで拾えます。
『Dataview』のようにクエリで一覧を作るもの、『Excalidraw』のように外部形式とのやり取りがあるもの、『Image Converter』のように変換設定を持つものは、動くかどうかだけでなく、出力結果まで見ておいたほうが安心です。

ロールバックを考えるなら、バックアップは大型更新の前に取っておくのが前提になります。
あわせて、プラグイン設定のエクスポートが可能なものは保存し、そうでないものは設定画面のスクリーンショットを残しておくと復旧が速くなります。
数が増えるほど、再現に時間がかかるのはノート本文より設定のほうです。
特に細かいクエリ、除外フォルダ、変換品質、テンプレート連携のような項目は、見た目以上に記憶に残りません。

依存を増やさない設計と、戻せる準備をセットで持っておくと、アップデートは怖いイベントではなくなります。
普段から「無くてもノートは読める」「止めても戻せる」状態を保っておけば、便利なプラグインだけを残しながら、Vault全体の保守負担を膨らませずに済みます。

Obsidian Changelog

Follow the latest updates to Obsidian apps for desktop and mobile.

obsidian.md

よくある質問

何個まで入れていい？

最初に入れる数は、3〜5個以内に収めると運用が安定します。
理由は単純で、Obsidian のつまずきは機能不足よりも、設定項目が増えすぎて「何を触れば状態が変わるのか」が見えなくなるところから始まるからです。
Reddit の初心者スレッドでも、75以上のプラグインを扱う長大な紹介より、まずは上位の 10〜15 個に絞って考える価値があるという流れが出ていました。
実際にはその中からさらに削って、自分の毎日使う動作に直結する数だけ残すほうが落ち着きます。

目安としては、日付起点で書くなら『Calendar』、タスクを拾いたいなら『Tasks』、見出し移動を整えるなら『Outline』か TOC 系、画像が多いなら『Image Converter』というように、役割が重ならない組み合わせで 3 つ前後から始めると全体像が見えます。
そこから「毎週使っているか」で足し引きすると、増やす判断にも根拠が出ます。
最初から 10 個前後をまとめて入れるより、1 個追加して数日使い、残す理由があるものだけ定着させるほうが、Vault の設計も崩れません。

最新版で動かない場合

本体を更新した直後にプラグインが動かないときは、まずそのプラグイン自体に更新が来ているかを見ます。
そのうえで manifest の minAppVersion と、GitHub の Issues に同じ症状が出ていないかを確認すると、原因の切り分けが進みます。
前のセクションでも触れた通り、ここは本体の不具合というより、追随のタイミング差で起きることが多いです。
Obsidian Changelogを見ると、最近も短い間隔で Desktop 更新が続いているので、最新版の直後は大型プラグインほど様子見が効きます。

たとえば『Tasks』は minAppVersion が 1.4.0、『Excalidraw』は 1.5.7、『Dataview』は 0.13.11 と確認できます。
自分の本体バージョンと前提条件がずれていないのに不調なら、Issues に同報告があるかを見る価値があります。
ここで報告が複数並んでいるなら、個別設定より互換性の問題である可能性が高いです。

一時運用では、止まったプラグインの役割を別手段で置き換えるのが現実的です。
『Dataview』の一覧が崩れたなら通常リンクや検索でしのぎ、『Tasks』のクエリ表示が不安定なら通常の Markdown チェックボックスに戻す、といった形です。
無理に修正を重ねるより、まず読める・書ける状態に戻したほうが被害が広がりません。
更新前の状態で安定していたなら、ロールバックの判断も十分ありです。
新機能を追うより、普段のノートが止まらないことを優先したほうが、結果として手戻りが少なくなります。

モバイル対応の考え方

モバイルで使う前提なら、各プラグインの配布ページや GitHub の manifest で Mobile 対応の記載があるかを見ておくのが基本です。
たとえば『Excalidraw』はモバイルサポートへの言及があります。
『Dataview』やKanbanは manifest 上でデスクトップ専用ではないことが確認できます。
一方で『Tasks』『Calendar』『Image Converter』『Outline』は、今回確認できた範囲ではモバイル対応の明示が揃っていません。

体感としては、モバイル前提の運用ほど、先に Desktop で設定を固めてから同期したほうがトラブルが少なく収まります。
クエリ、テンプレート、画像変換、表示位置のような要素は、狭い画面で触ると「設定が悪いのか UI の見え方なのか」が判別しにくくなります。
Desktop 側でノート作成フローと表示結果を先に安定させておけば、モバイルでは閲覧と軽い追記に集中でき、同期後の違和感も拾いやすくなります。

モバイルで恩恵を感じやすいのは、『Calendar』のように日付起点でノートへ入るものや、『Outline』系のように長文内を素早く移動できるものです。
反対に、『Dataview』の複雑なクエリ編集や『Excalidraw』の細かい図の調整は、Desktop のほうが向いています。
モバイル対応は「起動するか」だけでは足りず、日常操作の中心をどこに置くかまで含めて考えたほうが現実に合います。

初心者の最初の一歩

初心者が最初に入れるなら、『Calendar』または『Tasks』のどちらか 1 つ、さらに『Outline』または TOC 系のどちらか 1 つ、そこに『Image Converter』を足す構成が収まりやすいのが利点です。
この組み合わせだと、日付かタスクのどちらかで入口を作り、見出し移動で文章を扱いやすくし、画像の肥大化も早めに防げます。
機能の方向が分かれているので、役割の違いもつかみやすくなります。

『Calendar』はデイリーノートを軸にした記録と相性がよく、書く習慣を作りたい人に向いています。
『Tasks』はやることを複数ノートから拾い上げたい人に合います。
どちらも「今日何を書くか」「何を処理するか」という入口を作る役目です。
見出しの整理には、まずコアの『Outline』で十分なことが多く、本文内に目次を置きたいなら TOC 系を選ぶ、という順番で考えると迷いません。
画像を貼る機会があるなら『Image Converter』は効果が見えやすく、設定も目的がはっきりしています。

『Dataview』や『Excalidraw』は刺さる人には強いのですが、最初の一歩としては役割がやや広く、覚えることも増えます。
読書記録を一覧化したい、図解中心で考えたい、といった目的が最初から固まっているなら候補に入りますが、そうでなければ後から追加したほうが流れが自然です。
最初の導入は「毎日 1 回触る機能」を基準に選ぶと、入れたまま使わない状態を避けやすくなります。

セキュリティ・社内PCでの配慮

社内 PC や業務端末で扱うときは、コミュニティプラグインが サードパーティ製であることを前提に見たほうが筋が通ります。
プラグインにはコード実行の観点があるため注意が必要です。
便利そうという理由だけで広く入れるより、必要最低限に絞り、提供元が明確か、README やヘルプが整っているか、権限まわりの説明に不自然さがないかを見ていくほうが安全です。

社内運用では、『Outline』のようなコア機能で足りる部分を先に使い、コミュニティプラグインは業務上の効果が明確なものだけに限定すると判断しやすくなります。
『Tasks』のようにドキュメントが整っているもの、『Dataview』や『Excalidraw』のように提供元と情報の置き場が追いやすいものは、導入後に問題が起きたときも調べる先がはっきりしています。
逆に、更新状況や運営主体の見えにくいものは、個人 Vault なら試せても、社内 PC では扱いが変わります。

実務では、いきなり本番 Vault に入れず、テスト Vault でノートの読み書き、同期、既存設定との干渉を先に見る流れが合っています。
そこで問題が出なければ限定的に広げる、という順番なら、万一外すことになっても影響範囲を小さく保てます。
社内 PC で問われるのは「便利かどうか」だけではなく、「止めても業務が読めるか」「設定を戻せるか」まで含めた運用の見通しです。

Plugin security - Obsidian Help

The Obsidian team takes security seriously. This page explains the risks involved when installing community plugins, and

help.obsidian.md

まとめ

最初の3個提案

最初に入れる3つは、『Tasks』か『Calendar』のどちらか1つ、『Outline』か TOC 系のどちらか1つ、そして『Image Converter』です。
入口を作る機能、長文をさばく機能、画像の膨張を抑える機能の順にそろえると、Vault 全体の流れが整います。
私自身、最小構成を守った時期のほうが検索、リンク、レビューの回転が軽く、結果としてノートから成果物までの質が上がる感覚がありました。

導入は、まずコア寄りの構成で1週間回し、足りないと感じた機能を1つだけ追加する流れが収まりやすいのが利点です。
週次で見直して「本当に毎日触ったか」を基準に残すものを決めると、機能を増やしすぎずに済みます。
大型の追加や更新を入れる前には Vault をバックアップし、Obsidian Changelogやobsidianstats。

次のアクション

次にやることは3つだけです。

1. まずはコア機能中心で運用を始める
2. 『Tasks』か『Calendar』を先に1つだけ入れる
3. 主要プラグインの互換性を確認してから更新する

この順番なら、便利さを増やしながらも構成は細りません。足し算より維持のしやすさを優先すると、『Obsidian』は道具として長く残ります。