Notionシステム研究所 > Notion Wikiの作り方|ページを増やす前に決める情報設計
2026年6月5日
•約19分で読めます
Notion Wikiの作り方を、ページ作成、カテゴリ設計、Wiki化、ページオーナー、有効期限、権限、最初に作るページ、運用レビューまで実務向けに解説します。
NotionでWikiを作りたいです。まずトップページを作って、ページを増やせばよいですか。
順番が逆じゃ。ページを増やす前に、カテゴリ、ページオーナー、有効期限、権限、更新レビューを決める。そこまで決めてから作ると、1か月後に崩れにくいWikiになる。
NotionでWikiを作ること自体は難しくありません。
ページを作り、サブページを置き、見出しやカラムで整理すれば、Wikiらしいトップページはすぐ作れます。
Notion公式ガイドでも、会社のWikiを作る流れとして、ワークスペースページの作成、Wiki内のサブページ作成、見出しやカラムでの整理、権限設定が紹介されています。
また、Notion公式ヘルプでは、ページをWikiに変換できること、Wikiにはホーム、すべてのページ、自分がオーナーのページといったビューがあること、ページオーナーや有効期限、認証済みページを使えることが説明されています。
ただし、実務で問題になるのは、作り方の操作ではありません。
問題になるのは、作った後です。
Notion Wikiの作り方は、ページを増やす手順ではなく、情報分類、ページ責任、更新期限、権限、レビュー導線を先に決める情報設計として考える のが実務向けです。
この記事では、Notion Wikiを一から作る手順を、カテゴリ、タグ、ページオーナー、有効期限、権限、最初に作るべきページ、運用レビューまで含めて整理します。
Notion Wikiは、次の順番で作ります。
| 順番 | やること | 完了条件 |
|---|---|---|
| 1 | Wikiに置く情報を決める | タスク、議事録、案件情報と混ざらない |
| 2 | カテゴリとタグを決める | 作成者が迷わずページを置ける |
| 3 | トップページと初期ページを作る | 最初に見る入口と基本ページがある |
| 4 | ページをWikiに変換する | ホーム、すべてのページ、自分がオーナーのページを使える |
| 5 | オーナー、有効期限、権限を設定する | 誰が更新するか、誰が見てよいかが分かる |
| 6 | レビュー用ビューを作る | 期限切れ、オーナー未設定、確認待ちを見られる |
最初にやってはいけないのは、思いついたページを次々に作ることです。
ページが10枚程度なら、それでも何とかなります。
しかし、30枚、50枚と増えると、次のような状態になります。
| 起きること | 原因 |
|---|---|
| 同じ内容のページが複数できる | カテゴリと命名ルールがない |
| どれが正しい情報か分からない | 認証状態や有効期限がない |
| 古い手順が残る | ページオーナーがいない |
| 検索しても見つからない | ページ名が「資料」「手順」「メモ」になっている |
| 外部共有が怖くなる | 社内用情報と外部向けページが混ざっている |
Notion Wikiは、きれいなトップページを作るだけでは定着しません。
トップページの前に、情報の分類と更新責任を決めます。
Notion Wikiを作る前に、まずWikiの範囲を決めます。
ここを曖昧にすると、Wikiが何でも置き場になります。
| 決めること | 例 |
|---|---|
| 誰のためのWikiか | 個人、チーム、部署、全社 |
| 何を置くか | ルール、手順、FAQ、オンボーディング、リンク集 |
| 何を置かないか | タスク、議事録全文、案件進捗、顧客の機密情報 |
| 誰が更新するか | ページオーナー、確認者、管理者 |
| いつ見直すか | 月次、四半期、変更時、プロジェクト終了時 |
| 誰が見られるか | 全社、部署内、関係者、外部ゲスト |
個人Wiki、チームWiki、社内Wikiでは、設計が違います。
| 種類 | 向いている情報 | 注意点 |
|---|---|---|
| 個人Wiki | 学習メモ、作業手順、リンク集 | 自分だけの分類になりやすい |
| チームWiki | 部署内手順、FAQ、テンプレート | 他部署から探しにくくなりやすい |
| 社内Wiki | 全社ルール、オンボーディング、業務別手順 | 権限と更新責任が重くなる |
| プロジェクトWiki | 仕様、決定事項、ナレッジ | タスク管理や議事録DBと分ける必要がある |
最初から全社Wikiを完璧に作ろうとすると、設計が重くなります。
小さく始めるなら、次の4カテゴリだけで十分です。
| 初期カテゴリ | 置く情報 |
|---|---|
| 全社共通 | 会社概要、基本ルール、問い合わせ先 |
| 業務手順 | 経費、請求、入社、アカウント、問い合わせ対応 |
| IT・ツール | Google Workspace、Slack、Notion、セキュリティ |
| FAQ | 繰り返し聞かれる質問、例外対応 |
ここに部署別WikiやプロジェクトWikiを足すのは、運用が回り始めてからで構いません。
Notionでは、通常のページでもサブページを作れます。
そのため、最初は普通のページ階層だけでもWikiのように見えます。
しかし、会社やチームで使うなら、普通のページ階層とWiki機能の違いを理解しておきます。
| 通常のページ階層 | Wikiとして使う場合 |
|---|---|
| ページを親子関係で整理する | ページを一覧ビューで管理できる |
| 見出しやリンクで導線を作る | ホーム、すべてのページ、自分がオーナーのページを使える |
| ページ単位で編集する | ページオーナーや有効期限を意識できる |
| 検索はページ名頼み | カテゴリ、タグ、オーナー、状態で整理しやすい |
| 古いページが埋もれやすい | 期限切れページや確認待ちをレビューしやすい |
Notion公式ヘルプでは、Wikiに変換できるのはページであり、データベースをWikiに変換することはできないと説明されています。
つまり、最初に作るのは「Wikiにしたい親ページ」です。
その親ページの中に、サブページやカテゴリを整理してから、必要に応じてWikiに変換します。
実務では、次の判断で使い分けます。
| 状況 | おすすめ |
|---|---|
| 5ページ未満の個人メモ | 通常ページで十分 |
| チームの手順が10ページ以上ある | Wiki化を検討する |
| オーナーや有効期限を管理したい | Wiki化する |
| 議事録やタスクを担当者、期限、状態で管理したい | Wikiではなく専用DBに分ける |
| 顧客別情報や案件情報を管理したい | 案件DB、顧客DB、権限付きスペースに分ける |
Wikiは、すべてのページを入れる場所ではありません。
Wikiは、繰り返し参照する情報を、責任者と鮮度付きで管理する場所です。
Notion Wikiで最初に決めるのは、カテゴリです。
カテゴリは、ページを置く場所であり、読む人が探す入口です。
カテゴリは多すぎると迷います。
最初は5〜7個程度に絞ります。
| カテゴリ | 例 |
|---|---|
| 全社共通 | 会社概要、組織図、基本ルール |
| 人事・労務 | 勤怠、休暇、入退社、福利厚生 |
| 経理・申請 | 経費、請求、稟議、支払 |
| IT・セキュリティ | アカウント、端末、ツール、権限 |
| 営業・顧客対応 | 提案資料、商談手順、問い合わせ対応 |
| 開発・制作 | 開発ルール、レビュー手順、リリース手順 |
| FAQ | よくある質問、例外対応 |
部署名だけでカテゴリを作ると、部署横断の業務が見つかりにくくなります。
たとえば「請求書発行手順」は、営業、管理、経理が関わります。
部署別の「営業Wiki」に置くと、経理側から見つけにくくなります。
このような情報は、部署カテゴリではなく「経理・申請」や「業務手順」に置きます。
タグは、カテゴリを補助する程度で使います。
| タグ種別 | 例 |
|---|---|
| 部署タグ | 営業、管理、開発、採用 |
| 業務タグ | 入社、請求、問い合わせ、障害対応 |
| 情報種別タグ | ルール、手順、FAQ、テンプレート |
タグを増やしすぎると、誰も正しく付けなくなります。
最初は、カテゴリ1つ、タグは最大2つ程度で十分です。
ページ名もルール化します。
| 避けたい名前 | よい名前 |
|---|---|
| 資料 | 営業提案資料テンプレート |
| 手順 | 経費精算の申請手順 |
| アカウント | Google Workspaceアカウント追加手順 |
| 入社 | 入社初日のPCセットアップ |
| FAQ | 勤怠・休暇でよくある質問 |
おすすめは、次の形です。
業務名 + 何をするページか
検索されるWikiは、ページ名だけで内容が分かります。
ここから、Notion Wikiを実際に作る手順です。
操作の細部はNotionの画面変更で変わることがあります。
ただし、作る順番は変わりません。
まず、Wikiの親ページを作ります。
名前は、用途が分かる名前にします。
| 用途 | ページ名の例 |
|---|---|
| 個人用 | 個人Wiki |
| チーム用 | 営業チームWiki |
| 全社用 | 社内Wiki |
| プロジェクト用 | 新規事業プロジェクトWiki |
親ページには、最初から説明文を長く書きすぎない方がよいです。
トップページは、読む場所ではなく探す入口です。
最初は、次のような構成にします。
## はじめて見る人
- よく使うページ
- 問い合わせ先
- Wikiの使い方
## 業務別
- 経費精算
- 請求・入金
- アカウント管理
## 部署別
- 営業
- 管理
- 開発
## 更新が必要なページ
- 期限切れ
- オーナー未設定
- 確認待ち
トップページの目的は、社員が迷わず最初の1クリックを選べることです。
次に、最初に必要なページだけを作ります。
最初から全ページを作ろうとしない方がよいです。
まずは、よく聞かれる情報、入社時に必要な情報、毎月使う手順から作ります。
| 優先度 | ページ例 | 理由 |
|---|---|---|
| 高 | 問い合わせ先一覧 | 誰に聞けばよいかを減らす |
| 高 | 勤怠・休暇のルール | 全員が使う |
| 高 | 経費精算の申請手順 | 差し戻しを減らす |
| 高 | Google Workspaceアカウント追加手順 | 入社、異動で使う |
| 高 | 入社オンボーディング | 新入社員が最初に見る |
| 中 | 営業提案資料テンプレート | 部署横断で使う |
| 中 | 請求書発行前の確認チェックリスト | ミスを減らす |
| 中 | Notion Wikiの運用ルール | 作った後に崩れないようにする |
最初に作るページは、見た目より実用性で選びます。
Slackで何度も聞かれていることから作ると、Wikiを使う理由が生まれます。
初期ページとカテゴリを整理したら、親ページをWikiに変換します。
Notion公式ヘルプでは、ページ上部のメニューから Wikiに変換 を選ぶ方法が説明されています。
注意点は、データベースをWikiに変換するのではなく、ページをWikiに変換することです。
既存のデータベースをそのままWikiにしたい場合は、いったんWiki用の親ページを作り、その中で必要なDBや関連ページへリンクします。
変換後は、次のビューを確認します。
| ビュー | 使い方 |
|---|---|
| ホーム | トップページとして導線を整える |
| すべてのページ | Wiki内のページを一覧で確認する |
| 自分がオーナーのページ | 各担当者が自分の更新責任を見る |
ここまでで、Notion Wikiの形はできます。
ただし、この段階ではまだ「作っただけ」です。
次に、オーナー、有効期限、権限を設定します。
Notion Wikiで一番重要なのは、ページオーナーです。
ページオーナーがない情報は、誰も更新しません。
Notion公式ヘルプでは、Wikiでページを作成したユーザーがデフォルトでページオーナーになること、オーナーは変更できることが説明されています。
実務では、作成者と責任者が違うことがよくあります。
そのため、ページを作ったら、必ずページオーナーを確認します。
| 項目 | 目的 |
|---|---|
| ページオーナー | 内容に責任を持つ人 |
| 確認者 | 正式情報として確認する人 |
| 有効期限 | 次に見直す日 |
| 認証状態 | 下書き、確認待ち、認証済み、期限切れ |
| 公開範囲 | 全社、部署内、関係者、機密 |
| 関連ページ | 手順、FAQ、DB、外部システムへのリンク |
有効期限は、すべて同じにしない方がよいです。
| 情報 | 見直し頻度 |
|---|---|
| 会社概要 | 半年または変更時 |
| 組織図 | 月次または変更時 |
| 勤怠・休暇ルール | 半期または変更時 |
| 経費精算手順 | 四半期 |
| ITアカウント手順 | 四半期 |
| 営業資料 | 月次 |
| FAQ | 月次 |
全ページに厳密な有効期限を入れると、運用が重くなります。
最初は、よく見られる上位20〜30ページだけで十分です。
Notionの認証済みページは、会社として正しい情報を示したいページに使います。
| 認証済みに向くページ | 理由 |
|---|---|
| 勤怠・休暇ルール | 誤った情報が全員に影響する |
| 経費精算手順 | 差し戻しや会計ミスにつながる |
| セキュリティルール | 会社全体のリスクに関わる |
| 顧客対応ルール | 対応品質に影響する |
| 入社オンボーディング | 新入社員が最初に参照する |
逆に、アイデアメモ、作業中の草案、プロジェクト途中の仮説まで認証済みにする必要はありません。
認証済みページは、重要ページに絞ります。
Notion Wikiは共有しやすいので、権限を後回しにしがちです。
しかし、社内Wikiを作るなら、最初に公開範囲を分けます。
| 情報 | 権限の考え方 |
|---|---|
| 会社概要、基本ルール | 全社閲覧 |
| 勤怠、経費、IT手順 | 全社閲覧、一部管理者編集 |
| 部署別マニュアル | 部署編集、全社閲覧または部署内閲覧 |
| 採用評価 | 採用関係者のみ |
| 人事評価、労務相談 | 関係者限定 |
| 経営資料 | 役員、管理者、関係者に限定 |
| 顧客別資料 | 案件関係者に限定 |
権限は、ページ単位で細かく設定しすぎると管理できません。
基本は、チームスペースやカテゴリ単位で整理します。
| スペース | 役割 |
|---|---|
| 全社Wiki | 全員が見る基本情報 |
| 部署Wiki | 部署ごとの業務手順 |
| 管理部Wiki | 人事、労務、経理 |
| 採用Wiki | 採用関係者だけ |
| 経営・法務スペース | 機密情報 |
| 外部共有スペース | 顧客やパートナー向け資料 |
外部ゲストを招待する場合は、社内Wikiとは別の場所にします。
顧客向けの共有ページと、社内メモが同じWikiにあると、共有事故の原因になります。
外部共有が多い会社では、Notion Wikiを社内向けに限定し、顧客向けページは別スペースや別ツールに分けます。
Notion Wikiを作るとき、最初に作るべきなのは、見栄えのよいトップページではありません。
社員がすぐ使うページです。
最初は、次の10ページから始めます。
| No | ページ | 目的 |
|---|---|---|
| 1 | Wikiの使い方 | どこに何を書くかを決める |
| 2 | 問い合わせ先一覧 | 「誰に聞くか」を減らす |
| 3 | 勤怠・休暇のルール | 全員が使う基本情報を集約する |
| 4 | 経費精算の申請手順 | 差し戻しを減らす |
| 5 | 入社オンボーディング | 新入社員が最初に見る導線を作る |
| 6 | アカウント追加・削除手順 | 入社、退職、異動に対応する |
| 7 | よく使う社内ツール一覧 | 外部システムへの入口を作る |
| 8 | 営業提案資料テンプレート | 探す時間を減らす |
| 9 | 請求・入金の確認チェックリスト | 部署横断のミスを減らす |
| 10 | よくある質問 | Slackで繰り返される質問を減らす |
この10ページは、会社によって変えて構いません。
判断基準は、次の3つです。
Notion Wikiの初期ページは、読む人の多さより、業務上の摩擦の大きさで選びます。
Wikiは、公開した日が完成ではありません。
1か月目に必ずレビューします。
見るべきなのは、ページ数ではありません。
| 見るもの | 判断 |
|---|---|
| オーナー未設定ページ | 誰が更新するか決める |
| 有効期限切れページ | 更新する、削除する、認証を外す |
| カテゴリ未設定ページ | 置き場所が曖昧な情報を減らす |
| 下書きのままのページ | 公開するか、削除するか決める |
| Slackで繰り返された質問 | FAQや手順ページにする |
| 検索で見つからなかった言葉 | ページ名やタグを直す |
| 外部共有されたページ | 社内情報が混ざっていないか確認する |
Notion Wikiには、レビュー用ビューを作ります。
| ビュー | 見る人 | 目的 |
|---|---|---|
| 期限切れページ | 管理者、ページオーナー | 古い情報を放置しない |
| 自分がオーナーのページ | 各担当者 | 自分の更新責任を確認する |
| 確認待ちページ | 確認者 | 正式ページにする前に見る |
| カテゴリ未設定 | 管理者 | 情報の迷子を減らす |
| 最近更新されたページ | 全員 | 変更された情報を把握する |
週次で全部を見る必要はありません。
最初は、月1回でよいです。
ただし、Slackで何度も聞かれる質問は、その場でWikiへ反映します。
「それはWikiにあります」と返すだけでは定着しません。
ページが見つからなかった理由を直すことが、Wiki運用です。
Notion Wikiでよくある失敗は、次の通りです。
| 失敗 | 直し方 |
|---|---|
| トップページだけきれいに作る | よく使うページとレビュー用ビューを先に作る |
| 「資料」「手順」など曖昧な名前にする | 業務名を入れたページ名にする |
| 全員が自由に編集できる | 編集者、確認者、閲覧者を分ける |
| ページオーナーを設定しない | 重要ページからオーナーを付ける |
| 全ページを認証済みにする | 会社として正しい情報だけ認証する |
| 議事録やタスクをWikiに混ぜる | 議事録DB、タスクDBへ分ける |
| 部署別カテゴリだけで作る | 業務別カテゴリも作る |
| 公開後にレビューしない | 月次で期限切れと未設定ページを見る |
特に危険なのは、議事録とタスクをWikiに混ぜることです。
議事録は、会議日、参加者、決定事項で管理した方がよいです。
タスクは、担当者、期限、状態で管理した方がよいです。
Wikiには、議事録DBやタスクDBへの入口、運用ルール、重要な決定事項の参照先を置きます。
Notion Wikiは、小さく始める情報共有には向いています。
ただし、すべてをNotion Wikiに入れる必要はありません。
次の条件が強い場合は、専用システムや別ツールへ分けます。
| 条件 | 分ける理由 |
|---|---|
| 承認フローが厳密 | 誰がいつ承認したかの証跡が必要 |
| 規程管理が中心 | 改定履歴、施行日、監査対応が必要 |
| 権限階層が複雑 | 部門、役職、拠点ごとの細かい制御が必要 |
| 外部公開文書が多い | 顧客向けポータルやCMSが向く |
| 個人情報や機密情報が多い | 専用管理や法務確認が必要 |
| 既存の社内検索基盤がある | Notionを入口や補助に留める方がよい |
Notion Wikiは、情報の形を素早く整え、現場で使いながら改善するには強いです。
一方で、厳密な文書統制、監査、承認、複雑な権限が必要な領域は、専用基盤の方が向きます。
Notion Wikiは、社内情報を置く場所ではなく、情報の責任者、鮮度、探し方を見えるようにする仕組み。重い文書統制が必要な領域は、無理にNotionへ寄せない ことが大切です。
Notion Wikiは、ページを作って並べるだけならすぐ始められます。
しかし、実務で使われるWikiにするには、作る前の情報設計が重要です。
Notion Wikiを作るときは、次の順番で進めます。
Notion Wikiの作り方で大切なのは、画面の作り込みではありません。
誰が更新し、いつ見直し、どの情報を信頼してよいかを決めることです。
まずは、全社共通、業務手順、IT・ツール、FAQの4カテゴリで始めます。
そのうえで、よく見られるページにオーナーと有効期限を付けます。
ここまでできると、Notion Wikiは「ページ置き場」ではなく、更新され続けるナレッジ基盤として使いやすくなります。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。