社内wikiのタグ設計｜3軸ルールと運用の決め方

社内wikiにメモが増えてきて、「あるはずなのに探せない」状態になっていませんか。原因の一つは、検索機能そのものではなく、タグの付け方が人によってバラバラになっていることです。

この記事では、社内wikiのタグ設計を「3つの軸で切る」「1メモあたりの上限を決める」「増えすぎたら畳む」という3つの実務に分解して解説します。読み終えると、自分のチームでタグ規約をゼロから決められる状態になります。あわせて、タグ設計をAIに手伝わせるためのプロンプトも3つ紹介します。

社内wikiのタグ設計とは？グループ（フォルダ）との役割の違いから整理する

タグ設計とは、社内wikiのメモを「どういう切り口で探せるようにするか」を決める作業です。ここで最初に押さえておきたいのは、公開範囲を決める仕組みとタグはまったく別の役割を持っているという点です。この2つを混同したまま設計を始めると、どれだけ丁寧にタグを付けても探しやすくなりません。

なお、公開範囲を決める単位の呼び方はツールによって異なります。DocBaseでは「グループ」、他のツールでは「フォルダ」「スペース」などと呼ばれます。この記事では以降「グループ」と表記します。

グループ（フォルダ）は「誰が見られるか」を決めるもの

グループは、アクセス制御の単位です。人事情報は人事メンバーだけ、開発ドキュメントは開発チームだけ、といった公開範囲を決めるために使います。判断基準は「この情報を誰に見せてよいか」の一点です。

つまりグループは、組織構造や権限設計に従って決まるものであり、情報の内容そのものとは独立しています。

タグは「どういう切り口で探せるか」を決めるもの

一方でタグは、分類と検索のための仕組みです。1つのメモに複数のタグを付けられるため、「議事録」であり「A社案件」であり「対応中」である、という複数の切り口を同時に持たせられます。

グループが1つの階層に情報を押し込む縦の整理だとすれば、タグは同じ情報に複数の入り口を作る横の整理です。だからこそ両者は代替関係になく、両方を正しく使い分ける必要があります。

混同すると何が起きるか

役割を混同したときに起きる問題は、大きく2つに分かれます。

1つは、分類のためにグループを増やしてしまうケースです。「議事録グループ」「マニュアルグループ」のように内容でグループを切り始めると、グループ数が増え続け、誰がどこに参加しているのかを管理しにくくなります。本来は権限のための仕組みなので、権限設計が崩れていきます。

もう1つは、権限のためにタグを使おうとするケースです。「関係者外秘」というタグを付けても、タグには閲覧制限の効力がありません。見えるべきでない人に見えてしまうという、より深刻な事故につながります。

項目	グループ	タグ
目的	アクセス制御	分類・検索
判断基準	誰に見せてよいか	どう探されるか
1メモへの付与	公開範囲として指定（DocBaseの場合は全体／グループ／自分のみ）	複数付与できる
決め方の基準	組織の権限設計に従う	検索軸としてチームで規約化する
増えすぎたときの影響	権限管理が煩雑になる	絞り込みに効かなくなる

DocBaseの場合も、メモの公開範囲は「全体」「グループ」「自分のみ」の3スコープで管理し、タグは分類専用の仕組みとして分かれています。まずこの前提を全員で共有してから、タグ設計に入ることをおすすめします。

タグ設計の基本は「3つの軸」で切ること

タグ設計で最初に決めるべきは、個々のタグ名ではなく軸です。軸とは「そのタグが何を表しているか」のカテゴリのことで、次の3つに分けると多くのチームで扱いやすくなります。

• 種類軸：そのメモがどんな型のドキュメントか
• テーマ軸：何について書かれているか
• 状態軸：今どういう状態にあるか

軸を先に決める理由は、タグの重複と抜け漏れを防ぎやすくなるからです。軸がないままタグを増やすと、「議事録」と「A社」と「対応中」が同じ平面に並び、どの粒度で付ければよいのか判断しにくくなります。

軸① 種類軸：ドキュメントの型を表す

種類軸は、そのメモが何のために書かれた文書なのかを示します。組織が変わっても種類はあまり変わらないため、最も安定した軸です。

例：議事録 手順書 仕様書 企画書 週次レポート 調査 テンプレート 振り返り

種類軸のタグは、運用上の目安として10個前後に収めます。20個を超えている場合は、粒度が細かすぎるか、テーマ軸のタグが混ざっている可能性があります。

軸② テーマ軸：何について書かれているかを表す

テーマ軸は、案件名・製品名・業務領域など、内容そのものを示します。組織や事業の変化に応じて増減するため、3つの軸の中で最も動きが大きい軸です。

例：採用 経費精算 A社案件 新プラン開発 セキュリティ

テーマ軸は組織規模や事業数に応じて増えやすいため、一律の上限は設けにくい軸です。ただし、「そのタグが付くメモが今後5件以上になる見込みがあるか」を新設の目安にすると、無秩序な増殖を防ぎやすくなります。

軸③ 状態軸：今どういう状態かを表す

状態軸は、そのメモが現時点で有効なのか、作業中なのかを示します。数を絞ることが最も重要な軸です。

例：対応中 完了 保留 要更新 アーカイブ候補

状態軸のタグは、5個以内を目安にします。状態が6種類も7種類もあると、付ける側が迷い、結果として誰も付けなくなります。

軸	表すもの	数の目安	見直し頻度
種類軸	ドキュメントの型	10個前後	年1回
テーマ軸	内容・案件・領域	組織規模に応じる	四半期に1回
状態軸	現在の状態	5個以内	年1回

1メモあたりのタグ数は「3〜5個」を上限にする

1メモあたりのタグ数には上限を決めておくことをおすすめします。検索の絞り込み精度と、付ける側の負担を、どちらも一定に保つためです。

軸が3つあるので、基本は各軸から1つずつ、合計3個です。テーマが複数にまたがるメモでも、上限は5個までに留めるのがおすすめです。

1つ目の理由は、タグが多すぎると絞り込みの精度が落ちることです。10個のタグが付いたメモは、10通りの検索にヒットします。ヒットすること自体は良いことに見えますが、どの切り口で探しても出てくるメモは、結果的にノイズとして扱われます。

2つ目の理由は、付ける側の負担を一定に保つためです。「3個までで良い」と決まっていれば、投稿のたびに迷う時間がなくなります。ルールが曖昧なほど、タグ付けは後回しにされます。

なお、DocBaseのAIタグ自動生成は、AI機能をONにしている場合に、既存タグ以外の候補を未確定の状態で最大5個まで提案し、投稿者が選別して確定する仕様です。上限を3〜5個に置くことで、この機能の提案数とも自然に整合します。

タグ設計の理論的な背景｜オントロジーとナレッジグラフ

ここまでの3軸ルールは、情報を整理する分野で「オントロジー」と呼ばれる考え方を、実務向けに簡略化したものです。理論を知らなくてもタグ設計は進められますが、背景を押さえておくと、新しいタグを作るかどうか迷ったときの判断が安定します。

オントロジーとは、概念とその関係を定義した体系のことです。情報分野では「対象を人がどう捉えているかを、コンピュータが扱える形で記述したもの」を指し、一般に次の4つの要素で構成されます。

• クラス（概念の型）：顧客、製品といったカテゴリ
• プロパティ（属性）：そのクラスが持つ性質
• リレーション（関係）：「顧客は注文を発行する」のような概念同士のつながり
• 公理・制約：「契約は必ず1人以上の担当者を持つ」のような、守られるべき条件

軸ルールは、この4要素をタグに置き換えたものとして読めます。

オントロジーの要素	タグ設計での対応
クラス（概念の型）	種類軸（議事録・手順書などドキュメントの型）
リレーション（関係）	テーマ軸（そのメモが何について書かれているか）
プロパティ（属性）	状態軸（対応中・完了などの状態値）
公理・制約	1メモ3〜5個の上限、軸をまたいで意味が重複するタグを作らない規約

タグ名より先に軸を決めるという手順が効くのは、これが「タグを増やす作業」ではなく「概念の型をいくつ持つかを決める作業」だからです。型が決まっていれば、新しいタグが出てきたときに「どの型に属するか」で仕分けでき、どこにも属さないものは作らないと判断できます。

一方でナレッジグラフは、オントロジーで定義した型に従って、実際のデータを関係で結んだネットワークを指します。両者は設計図と建物の関係に近く、オントロジーが設計図、ナレッジグラフが建物にあたります。社内wikiに当てはめると、タグ規約がオントロジー、規約どおりにタグが付いたメモの集まりがナレッジグラフに相当します。

この対応関係から分かることが1つあります。規約を文書にまとめただけでは、設計図があるだけの状態です。実際のメモにタグが付いて初めて、探せる状態になります。四半期ごとの棚卸しが必要なのは、建物のほうが時間とともに崩れていくからです。

ただし、ここで説明したのは考え方の対応であって、同じものだという意味ではありません。研究や大規模なデータ基盤で使われる形式的なオントロジーは、機械が推論できる記述言語で定義され、制約の検証も自動で行われます。社内wikiのタグ設計にそこまでの厳密さは必要ありません。必要なのは、軸を決める・上限を決める・畳む仕組みを持つ、の3つです。

※オントロジーの定義と構成要素は、NTTデータ バリュー・エンジニア「オントロジー（用語解説）」およびAI総合研究所「オントロジーとは？基本要素やナレッジグラフとの違い、活用例」（いずれも2026年9月11日確認）を参照しています。

避けるべき「悪いタグ」4パターン

タグ設計で問題になりやすいのは、次の4種類のタグです。すでに使ってしまっている場合は、後述するタグ整理で畳んでいくことになります。

① 時期タグ（2026年上期 Q3 2025年度）

時期タグは、時間が経つほど価値が下がり、数だけが増え続けるという性質を持っています。四半期ごとにタグを作る運用なら、3年で12個程度の使われないタグが積み上がる計算です。

さらに、時期での絞り込みは、多くの社内wikiで標準の作成日・更新日から確認できます。タグとして持つ必要がありません。時期を明示したいなら、タグではなくメモのタイトルに入れるほうが適しています。

② ツール名だけのタグ（Slack Zoom Excel）

ツール名だけのタグは、そのメモの主題を表していないため、目的が曖昧になりやすいタグです。「Slackの通知設定を変更した手順書」にSlackと付けても、探す側は「通知設定を知りたい」のであってSlackの話題を網羅したいわけではありません。

ツール名は、そのツール自体が探す切り口になる場合に限って、テーマ軸のタグとして使うとよいでしょう。目安は、そのツールについてのメモが10件以上あるかどうかです。

③ 1つのメモにしか付かないタグ

タグの価値は、複数のメモをまとめられることにあります。運用初期に一時的に1件だけになるのは問題ありませんが、継続して1件のままのタグは、分類としての効果がほとんどありません。

これが起きるのは、タグをメモの要約として使ってしまっているときです。「新プランの料金体系検討2回目」のようなタグは、タイトルに書くべき情報です。

④ 部署名・人名だけのタグ（営業部 田中）

部署名を公開範囲の代わりに使うと、グループと役割が重複します。営業部のメモを営業部だけに見せたいなら、それはグループで解決すべき課題です。タグで表現すると、権限とタグの二重管理になります。

人名タグも同様です。誰が書いたかで分類したいなら、作成者は社内wikiが自動で記録しています。担当者を示したい場合は、状態軸のタグ（要対応）とメンションを組み合わせるほうが確実です。

悪いタグの例	なぜ悪いか	改善案
2026年上期	期ごとに増え続ける／作成日で代替できる	タイトルに時期を書く
Slack	メモの主題を表していない	通知設定など目的をテーマ軸に
新プラン料金検討2回目	継続して1件にしか付かない	タイトルに書き、タグは企画書＋新プラン開発
営業部	公開範囲の代わりに使うとグループと重複する	グループで公開範囲を制御する

DocBaseでのタグ設計・運用の実践方法

ここからは、DocBaseの機能を使って実際に規約を運用に乗せる手順を解説します。使うのは「優先タグ」「AIタグ自動生成」「タグ整理」の3つです。

優先タグでチーム内のタグを揃える

優先タグは、メモ編集時のタグ候補一覧の上位に表示されるタグを、チーム全体に対して指定できる機能です。設定できるのはチームのオーナーと管理者で、設定内容はチーム全員に反映されます。

規約として決めた種類軸・状態軸のタグを優先タグに登録しておくと、投稿する人は候補の上位から規約タグを選びやすくなります。類似タグの重複を、ルールの周知だけに頼らず画面の設計で防ぎやすくなるのが最大の利点です。

登録の順番としては、最も安定している種類軸から始め、次に状態軸、テーマ軸は主要なものだけに絞るのが実務的です。

AIタグ自動生成をどう併用するか

DocBaseのAIタグ自動生成は、メモの内容から既存タグ以外の候補を最大5個まで提案する機能です。AI機能をONにしていれば追加費用なく全ユーザーが利用でき、提案されたタグは未確定の状態（グレー表示）で示されるため、投稿者が選別してから確定できます。自動で付与される仕組みではありません。

重要なのは、この機能がチーム内で使用頻度の高いタグを優先的に提案するという点です。つまり規約タグが揃っているチームほど、提案が実用的になります。逆に表記ゆれが多いほど、意図しない候補が出やすくなります。

そのため、併用の設計は次のように分けるのが合理的です。

• 規約で固定する層：種類軸と状態軸。選択肢が有限なので、優先タグで固定する
• AIに候補を出させる層：テーマ軸。内容から判断する余地が大きいため提案が役に立つ。提案は未確定なので、投稿者が選別して確定する

AIタグ自動生成の詳しい挙動は、DocBaseのAIタグ機能のヘルプページで確認できます。

タグ整理（名寄せ）で増えすぎたタグを畳む手順

タグは必ず増えます。増えること自体は問題ではなく、畳む仕組みを持っているかどうかが分かれ目です。DocBaseの管理機能にはタグ整理（名寄せ）があり、複数のタグを1つの代表タグに統合できます。

実務的な手順は次の4ステップです。

1. タグ一覧を、付いているメモ数の多い順に並べる
2. メモ数1件のタグを廃止候補として抜き出す
3. 表記ゆれ・同義語のグループを作り、統合先の代表タグを1つ決める
4. タグ整理で統合し、オーナーまたは管理者が代表タグを優先タグに登録する

ポイントは4つ目です。統合しただけでは、また同じゆれが発生します。統合先を優先タグに登録することで、再発を抑えやすくなります。

なお、AIが統合候補を提示する「AIタグ整理」は、チームの管理者のみが利用できる機能です。また、優先タグは自動的に保護されるため、統合先（代表タグ）としては使えますが、変更や削除の対象にはなりません。規約タグを誤って畳んでしまう心配がない設計になっています。

no-aiのような機能タグと、分類タグを混ぜない

DocBaseには、メモにno-aiタグを付けることで、そのメモをAI要約やMCP経由の操作などの処理対象から除外できる機能があります。こうした動作を変えるためのタグは、分類のためのタグとは性質がまったく違います。

混ぜてはいけない理由は、見直しのタイミングが違うからです。分類タグは四半期ごとに棚卸ししますが、no-aiのような機能タグを棚卸しで統合・削除してしまうと、AI処理対象から除外する設定が外れる恐れがあります。

対策はシンプルで、機能タグを規約の一覧に「触らないタグ」として明記しておくことです。タグ整理の作業手順にも「機能タグは対象外」と書いておくと安心です。

なお、グループ単位でAIの利用範囲を制限したい場合は、セキュリティパック（有料オプション）の利用が必要です。チーム全体のAI機能ON/OFFとno-aiタグによるメモ単位の除外は、標準機能として利用できます。

---

DocBaseがおすすめ｜タグ設計を運用に乗せやすい理由

DocBaseなら、優先タグでチーム全体のタグを揃え、AIタグ自動生成で入力の手間を減らし、管理者はタグ整理で増えすぎたタグを畳めます。いずれも追加費用なしで利用できる機能です（AIタグ自動生成はチームのAI機能ONが前提）。ISO 27001（ISMS）認証を取得しており、利用継続率は99%（自社集計）です。

30日間の無料トライアルをクレジットカード不要でお試しいただけます。

▶ DocBaseの30日間無料トライアルを始める（クレジットカード不要）

導入後の運用イメージは、DocBaseを導入した企業の事例一覧でご確認いただけます。

---

タグ設計に使えるプロンプト3選

タグ設計は、ゼロから考えるより「AIに候補を出させて、人が決める」ほうが早く進めやすくなります。ここで紹介する3つのプロンプトは、いずれもAIに決定させるものではなく、たたき台と検出結果を出させるものです。最終的な判断はチームで行うことをおすすめします。

① タグ規約のたたき台を作るプロンプト

これから設計を始めるチーム向けです。自分のチームの情報を埋めて使えます。

あなたは社内ナレッジ管理の設計者です。
以下のチーム情報をもとに、社内wikiのタグ設計案を作ってください。

# チーム情報
- 部署：（例：マーケティング部）
- 人数：（例：8名）
- よく書くドキュメント：（例：施策の企画書、週次レポート、議事録、競合調査、運用手順書）
- 探すときの典型的な状況：（例：去年やった同じ施策の企画書を探したい）

# 出力してほしいもの
1. 種類軸（ドキュメントの型）のタグ候補：10個以内
2. テーマ軸（何についてか）のタグ候補：15個以内
3. 状態軸（今どうなっているか）のタグ候補：5個以内
4. それぞれのタグについて、どんなメモに付けるかの定義を1行で
5. 優先タグとして最初に登録すべき10個の推薦と、その理由

# 制約
- 3つの軸のあいだで意味が重複するタグは作らないでください
- 年号・四半期など時期を表すタグは作らないでください
- ツール名だけのタグ、部署名だけのタグは作らないでください

② 既存タグの棚卸し・名寄せ候補を出すプロンプト

すでにタグが増えすぎているチーム向けです。タグ整理を実行する前に、どれをどれに寄せるかを洗い出す用途で使います。

あなたは社内ナレッジ管理の整理担当者です。
以下は現在チームで使われているタグの一覧です。棚卸しをしてください。

# 現在のタグ一覧（タグ名：付いているメモ数）
（ここに貼り付け）

# 出力してほしいもの
1. 表記ゆれ・同義語で統合すべきタグの組み合わせと、統合先として推奨するタグ名
2. 付いているメモが1件だけのタグの一覧（廃止候補）
3. 種類軸・テーマ軸・状態軸のどれにも当てはまらないタグの一覧と、その理由
4. 上記を反映したあとに残すべきタグ一覧

# 制約
- 統合の可否を断定せず、判断が分かれそうなものは「要確認」として理由を添えてください
- メモ数が多いほうを機械的に統合先にせず、名前としてわかりやすいほうを推薦してください
- 動作を変えるための機能タグ（no-ai など）は対象外としてください

③ 新しいタグを作るべきか判定するプロンプト

運用フェーズで使うプロンプトです。「このタグ作っていいですか」という相談に対して、判断の材料を揃えます。

以下の「新しく作りたいタグ」が本当に必要かを判定してください。

# 新しく作りたいタグ
- タグ名：
- 付けたいメモの例：（2〜3件）

# 既存のタグ一覧
（ここに貼り付け）

# 判定してほしいこと
1. 既存タグの組み合わせで代替できるか（できる場合は具体的な組み合わせ）
2. 代替できない場合、種類軸・テーマ軸・状態軸のどれに属するか
3. 新設した場合、今後どれくらいのメモに付く見込みか
4. 結論：新設する / 既存タグで代替する / 表記を変えて新設する

MCPサーバーを使えばタグ一覧の貼り付けも不要になる

チームのAI機能をONにしていて、対応するAIアプリからDocBaseに接続している場合は、タグ一覧をコピーして貼り付ける手間を減らせます。使うのは、DocBase公式のリモートMCPサーバーです。

MCPサーバーはOAuth 2.1に準拠しており、ChatGPT・Claude・Claude Code・Cursorなどの外部AIアプリから接続すると、タグの取得、タグを条件にしたメモ検索、メモやコメントの管理などを、ユーザーの指示に基づいて対応アプリ経由で実行できます。接続していれば、プロンプト②は「DocBaseのタグ一覧を取得して、統合候補を出して」のように依頼できます。ただし、統合の判断と反映は人が確認するのが安全です。追加費用はかかりません。

また、タグが規約どおりに揃っていると、外部AIからメモを引くときに「種類軸は議事録、テーマ軸はA社案件」といった絞り込みを指定しやすくなります。これは検索結果の正確さを保証するものではなく、AIに渡す範囲を人が指定しやすくなるという意味での効果です。

なお、DocBaseの画面上でメモをもとにAIが質問に回答するAIアシスタントと、言い回しが違うメモも探せる意味検索は、「DocBase AIプラス」として提供しています。ベータ期間中はAI機能をONにしているすべてのチームで、プランを問わず無料で利用できます（正式提供後は有料アドオンの予定です）。

MCPサーバーの仕組みそのものについてはリモートMCPサーバーとローカルMCPサーバーの違いを解説した記事を、対応アプリと設定手順についてはDocBase公式リモートMCPサーバーのヘルプページをご覧ください。

タグ運用のルールを決める（誰が・いつ・どんな条件で）

タグ設計が形骸化する主な原因の一つは、決める人と見直すタイミングが決まっていないことです。規約を作った直後は揃っていても、半年ほどで表記ゆれが再発しやすくなります。次の3点を明文化しておくとよいでしょう。

誰が決めるか

種類軸と状態軸は運用担当者が決め、テーマ軸は現場の提案を運用担当者が承認するという二段構えにすると、運用しやすくなります。

種類軸と状態軸は選択肢が有限で、全員に共通するため、合議にすると決まりません。一方テーマ軸は現場のほうが実態を知っているため、提案を上げてもらったほうが精度が高くなります。

運用担当者が1人だと属人化しやすいため、副担当を1人置いておくと安心です。なお、決まった内容を優先タグとして登録する操作は、チームのオーナーと管理者の権限です。運用担当者が権限を持たない場合は、登録を依頼する相手をあらかじめ決めておくとスムーズです。

いつ見直すか

• 四半期に1回：テーマ軸の棚卸し（メモ数1件のタグの廃止候補の確認、表記ゆれの統合）
• 年に1回：種類軸・状態軸を含めた全体の見直し
• 随時：新規タグの申請があったとき

四半期に1回とした理由は、テーマ軸が事業や案件の動きに連動して増えるからです。半年空けると、統合対象が多すぎて着手しにくくなります。短時間で終わる分量を保つことが、続けるコツです。

新しいタグを作る条件

新規タグの申請には、次の3つの条件を設けておくとよいでしょう。

1. 既存タグの組み合わせで表現できないこと
2. 目安として、今後5件以上のメモに付く見込みがあること
3. 3つの軸のいずれかに明確に属すること

この3条件を満たさない場合は、既存タグの組み合わせで運用します。条件を先に決めておくと、「作っていいですか」という相談に対して個人の感覚ではなくルールで答えられるようになります。

社内wikiのタグ設計でよくある失敗5つ

失敗① 自由入力に任せて表記ゆれが増える

よくある失敗です。議事録 会議メモ MTGメモ 打ち合わせ記録が並立し、どれで検索しても全体が出てこなくなります。

対策は、候補を先に見せる仕組みを使うことです。DocBaseであれば、オーナーと管理者がチーム全体に設定できる優先タグがこれにあたります。ルールを文書で配っても、投稿画面で候補が出なければ守られません。

失敗② 軸を決めずにタグを増やす

タグ名から先に決め始めると、粒度がバラバラになります。セキュリティ（テーマ）と手順書（種類）と要対応（状態）が同じ平面に並び、付ける側は「どれを付ければいいのか」を毎回判断することになります。

対策は、この記事の通り軸を先に決めることです。軸が決まっていれば、新しいタグが出てきたときに「これは何軸か」で仕分けできます。

失敗③ 付けるだけ付けて見直さない

タグは増える一方で、放置すると絞り込みに使えなくなります。タグが多すぎると、付けるときに選ぶことも、探すときに絞り込むことも難しくなります。

対策は、四半期に1回の棚卸しをカレンダーに入れてしまうことです。「気づいたときにやる」は実行されません。

失敗④ グループとタグの両方で分類しようとする

「営業部グループ」の中に営業部タグが存在する、という状態です。二重管理になり、どちらを更新すべきか判断しにくくなります。

対策は、記事冒頭の役割分担に戻ることです。公開範囲はグループ、分類はタグと決め、公開範囲の代わりに使っている部署名タグは廃止するのがおすすめです。

失敗⑤ 全員に完璧なタグ付けを求めて投稿が止まる

タグ規約を厳密にしすぎると、「正しく付けられないなら投稿しないでおこう」という心理が働きます。社内wikiにとって最も避けたい結果です。

対策は、必須タグを1つだけにすることです。「種類軸だけは必ず付ける、あとは任意」と決めれば、投稿のハードルは上がりません。DocBaseでAI機能をONにしている場合は、既存タグ以外の候補が未確定の状態で最大5個まで提案されるので、テーマ軸はその中から選んで確定する運用にすると、付ける側の負担を抑えられます。

よくある質問（FAQ）

Q. タグとフォルダ（グループ）の違いは何ですか？

公開範囲を決める単位（DocBaseでは「グループ」、ツールによっては「フォルダ」「スペース」）はアクセス制御の仕組みで、「誰が見られるか」を決めます。タグは分類と検索の仕組みで、「どういう切り口で探せるか」を決めます。1つのメモに複数のタグを付けられる点も大きな違いです。役割が異なるため、どちらか一方で置き換えることはできません。

Q. 1つのメモにタグは何個まで付けるべきですか？

基本は3個、上限は5個を推奨します。種類軸・テーマ軸・状態軸から1つずつ選ぶと3個になります。それ以上付けると、どの切り口で検索しても同じメモが出てくるようになり、絞り込みの精度が下がります。

Q. タグが増えすぎたときはどうすればいいですか？

メモ数の多い順にタグ一覧を並べ、①メモ数1件のタグを廃止候補にする、②表記ゆれ・同義語を1つの代表タグに統合する、③統合先を優先タグに登録する、という順で進めます。DocBaseでは管理機能のタグ整理（名寄せ）で複数のタグを1つの代表タグに統合でき、優先タグへの登録はオーナーまたは管理者が行ってチーム全体に反映します。③までやらないと、同じゆれが再発しやすくなります。

Q. AIのタグ自動生成に任せてしまってよいですか？

種類軸と状態軸は規約で固定し、テーマ軸の候補出しをAIに任せるという分け方を推奨します。DocBaseのAIタグ自動生成は、AI機能をONにしているチームで、既存タグ以外の候補を未確定の状態（グレー表示）で最大5個まで提案し、投稿者が選別して確定する仕様です。チーム内で使用頻度の高いタグが優先的に提案されるため、規約タグが揃っているほど提案が実用的になります。逆に表記ゆれが多いほど、意図しない候補が出やすくなります。

Q. タグを整えるとAI検索の精度は上がりますか？

タグ設計が効くのは、AIに渡す範囲を絞りやすくなる点です。現時点で効果が説明できるのは次の3点です。1つはAIタグ自動生成の提案精度で、チーム内で使用頻度の高いタグが優先的に提案されるため、規約タグが揃うほど提案が安定します。2つ目はMCPサーバー経由で外部AIからメモを引くときで、タグを条件にしたメモ検索ができるため、取得対象を絞る設計にできます。3つ目は、DocBase AIプラスで提供しているAIアシスタントや意味検索を使う場合で、タグで絞り込んだうえで探せます。ただし、タグを整えれば検索結果の正確さが保証されるというものではありません。タグ設計はあくまで、探す範囲を人が指定しやすくするための仕組みです。

Q. タグ設計は誰が担当すべきですか？

種類軸と状態軸は運用担当者が決め、テーマ軸は現場からの提案を運用担当者が承認する形が運用しやすくなります。ただし、決まった内容を優先タグとして登録する操作はチームのオーナーと管理者の権限のため、運用担当者が権限を持たない場合は依頼先を決めておくとスムーズです。属人化を防ぐために副担当を1人置くことをおすすめします。

Q. no-aiのような機能タグも分類タグと一緒に管理してよいですか？

分けて管理するのがおすすめです。no-aiはメモをAI要約やMCP経由の操作などの処理対象から除外するための機能タグで、分類のためのタグとは性質が違います。棚卸しのときに誤って統合・削除すると、除外の設定が外れる恐れがあります。規約の一覧に「触らないタグ」として明記し、タグ整理の対象外としておくと安全です。

Q. タグ設計とオントロジーは何が違いますか？

目的は同じで、厳密さが違います。どちらも「概念とその関係を定義して、情報を探せる状態にする」ための設計です。オントロジーは、クラス（概念の型）・プロパティ（属性）・リレーション（関係）・公理（制約）を、機械が推論できる形式で定義します。社内wikiのタグ設計は、この考え方を人が運用できる範囲まで簡略化したもので、種類軸がクラス、状態軸がプロパティ、テーマ軸がリレーション、1メモ3〜5個などの規約が公理にあたります。実務では形式的な定義まで踏み込む必要はなく、軸を決める・上限を決める・畳む仕組みを持つ、の3つで十分です。なお、オントロジーが概念の設計図であるのに対し、ナレッジグラフはその設計図に沿って実データを結んだものを指し、社内wikiでは規約どおりにタグが付いたメモの集まりがこれにあたります。

まとめ｜タグ設計は「軸を決めて、上限を決めて、畳む仕組みを持つ」

社内wikiが探せなくなる原因の一つは、検索機能そのものではなくタグの設計です。この記事の要点は次の5つです。

1. グループは公開範囲、タグは分類。役割を混同しない
2. 種類軸・テーマ軸・状態軸の3軸で切る。タグ名より先に軸を決める
3. 1メモあたり3個を基本、上限5個。上限がないと絞り込みに効かなくなる
4. 時期タグ・ツール名だけのタグ・継続して1件だけのタグ・公開範囲の代わりに使う部署名タグは作らない
5. 四半期に1回の棚卸しと、統合先を優先タグに登録するところまでをセットにする

そして、設計と棚卸しの作業はAIに候補を出させることで短縮しやすくなります。決めるのは人、洗い出すのはAI、という役割分担が進めやすくなります。

タグ設計に必要な「揃える・提案する・畳む」の3つを、DocBaseは1つのツールで運用できます。優先タグでチームのタグを揃え、AIタグ自動生成で入力の負担を減らし、管理者はタグ整理で増えすぎたタグを畳めます。30日間の無料トライアルをクレジットカード不要でご利用いただけます。

▶ DocBaseの30日間無料トライアルを始める（クレジットカード不要）

タグ以外の運用も含めて整えたい方は、ナレッジ共有のテンプレート活用方法を解説した記事もあわせてご覧ください。料金や機能の詳細はナレッジ共有ツールDocBaseの機能一覧、導入前の疑問はDocBase導入前のよくある質問で確認できます。

---

編集ポリシー

本記事はDocBase開発元である株式会社クレイが作成しています。可能な限り客観的な情報提供を心がけていますが、自社製品に関する記事であることをあらかじめご了承ください。

※本記事に記載しているタグ数・件数の目安（種類軸10個前後・20個超で見直し、状態軸5個以内、1メモあたり3〜5個、新規タグは今後5件以上の見込み、ツール名タグは10件以上）は、公的な統計に基づく数値ではなく、運用設計上の推奨値です。チームの規模や業務内容に応じてご調整ください。