Notionシステム研究所 > Notion Wikiの作り方|ページを増やす前に決める情報設計

Notion Wikiの作り方|ページを増やす前に決める情報設計

2026年6月5日

19分で読めます

Notion Wikiの作り方を、ページ作成、カテゴリ設計、Wiki化、ページオーナー、有効期限、権限、最初に作るページ、運用レビューまで実務向けに解説します。

Notion
Wiki
作り方
社内ナレッジ
情報設計
業務DB
助手
助手

NotionでWikiを作りたいです。まずトップページを作って、ページを増やせばよいですか。

博士
博士

順番が逆じゃ。ページを増やす前に、カテゴリ、ページオーナー、有効期限、権限、更新レビューを決める。そこまで決めてから作ると、1か月後に崩れにくいWikiになる。

NotionでWikiを作ること自体は難しくありません。

ページを作り、サブページを置き、見出しやカラムで整理すれば、Wikiらしいトップページはすぐ作れます。

Notion公式ガイドでも、会社のWikiを作る流れとして、ワークスペースページの作成、Wiki内のサブページ作成、見出しやカラムでの整理、権限設定が紹介されています。

Notion公式ガイド:社内Wikiの作り方

また、Notion公式ヘルプでは、ページをWikiに変換できること、Wikiにはホーム、すべてのページ、自分がオーナーのページといったビューがあること、ページオーナーや有効期限、認証済みページを使えることが説明されています。

Notion公式ヘルプ:Wikiとページの有効期限

ただし、実務で問題になるのは、作り方の操作ではありません。

問題になるのは、作った後です。

  • ページ名が曖昧で検索できない
  • 部署名だけで分けたため、横断業務が見つからない
  • ページオーナーがなく、誰も更新しない
  • 有効期限がなく、古い手順が残る
  • 議事録、タスク、マニュアル、FAQが同じ階層に混ざる
  • 重要ページと下書きページの違いが分からない
  • 外部ゲストや部署別権限を後から直せない

Notion Wikiの作り方は、ページを増やす手順ではなく、情報分類、ページ責任、更新期限、権限、レビュー導線を先に決める情報設計として考える のが実務向けです。

この記事では、Notion Wikiを一から作る手順を、カテゴリ、タグ、ページオーナー、有効期限、権限、最初に作るべきページ、運用レビューまで含めて整理します。

Notion Wiki機能の全体設計はこちら

Notion Wiki作成を、情報分類、カテゴリ設計、ページ作成、Wiki化、オーナー設定、運用レビューへ並べる構成図

先に結論:Wikiはこの順番で作る

Notion Wikiは、次の順番で作ります。

順番 やること 完了条件
1 Wikiに置く情報を決める タスク、議事録、案件情報と混ざらない
2 カテゴリとタグを決める 作成者が迷わずページを置ける
3 トップページと初期ページを作る 最初に見る入口と基本ページがある
4 ページをWikiに変換する ホーム、すべてのページ、自分がオーナーのページを使える
5 オーナー、有効期限、権限を設定する 誰が更新するか、誰が見てよいかが分かる
6 レビュー用ビューを作る 期限切れ、オーナー未設定、確認待ちを見られる

最初にやってはいけないのは、思いついたページを次々に作ることです。

ページが10枚程度なら、それでも何とかなります。

しかし、30枚、50枚と増えると、次のような状態になります。

起きること 原因
同じ内容のページが複数できる カテゴリと命名ルールがない
どれが正しい情報か分からない 認証状態や有効期限がない
古い手順が残る ページオーナーがいない
検索しても見つからない ページ名が「資料」「手順」「メモ」になっている
外部共有が怖くなる 社内用情報と外部向けページが混ざっている

Notion Wikiは、きれいなトップページを作るだけでは定着しません。

トップページの前に、情報の分類と更新責任を決めます。

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を足すのは、運用が回り始めてからで構いません。

ページ階層と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を実際に作る手順です。

操作の細部はNotionの画面変更で変わることがあります。

ただし、作る順番は変わりません。

1. 親ページを作る

まず、Wikiの親ページを作ります。

名前は、用途が分かる名前にします。

用途 ページ名の例
個人用 個人Wiki
チーム用 営業チームWiki
全社用 社内Wiki
プロジェクト用 新規事業プロジェクトWiki

親ページには、最初から説明文を長く書きすぎない方がよいです。

トップページは、読む場所ではなく探す入口です。

最初は、次のような構成にします。

## はじめて見る人
- よく使うページ
- 問い合わせ先
- Wikiの使い方

## 業務別
- 経費精算
- 請求・入金
- アカウント管理

## 部署別
- 営業
- 管理
- 開発

## 更新が必要なページ
- 期限切れ
- オーナー未設定
- 確認待ち

トップページの目的は、社員が迷わず最初の1クリックを選べることです。

2. 初期ページを作る

次に、最初に必要なページだけを作ります。

最初から全ページを作ろうとしない方がよいです。

まずは、よく聞かれる情報、入社時に必要な情報、毎月使う手順から作ります。

優先度 ページ例 理由
問い合わせ先一覧 誰に聞けばよいかを減らす
勤怠・休暇のルール 全員が使う
経費精算の申請手順 差し戻しを減らす
Google Workspaceアカウント追加手順 入社、異動で使う
入社オンボーディング 新入社員が最初に見る
営業提案資料テンプレート 部署横断で使う
請求書発行前の確認チェックリスト ミスを減らす
Notion Wikiの運用ルール 作った後に崩れないようにする

最初に作るページは、見た目より実用性で選びます。

Slackで何度も聞かれていることから作ると、Wikiを使う理由が生まれます。

3. ページを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を社内向けに限定し、顧客向けページは別スペースや別ツールに分けます。

最初に作るべき10ページ

Notion Wikiを作るとき、最初に作るべきなのは、見栄えのよいトップページではありません。

社員がすぐ使うページです。

最初は、次の10ページから始めます。

No ページ 目的
1 Wikiの使い方 どこに何を書くかを決める
2 問い合わせ先一覧 「誰に聞くか」を減らす
3 勤怠・休暇のルール 全員が使う基本情報を集約する
4 経費精算の申請手順 差し戻しを減らす
5 入社オンボーディング 新入社員が最初に見る導線を作る
6 アカウント追加・削除手順 入社、退職、異動に対応する
7 よく使う社内ツール一覧 外部システムへの入口を作る
8 営業提案資料テンプレート 探す時間を減らす
9 請求・入金の確認チェックリスト 部署横断のミスを減らす
10 よくある質問 Slackで繰り返される質問を減らす

この10ページは、会社によって変えて構いません。

判断基準は、次の3つです。

  • Slackや口頭で何度も聞かれる
  • 入社や異動のたびに説明している
  • ミスや差し戻しが発生しやすい

Notion Wikiの初期ページは、読む人の多さより、業務上の摩擦の大きさで選びます。

1か月目の運用レビュー

Wikiは、公開した日が完成ではありません。

1か月目に必ずレビューします。

見るべきなのは、ページ数ではありません。

見るもの 判断
オーナー未設定ページ 誰が更新するか決める
有効期限切れページ 更新する、削除する、認証を外す
カテゴリ未設定ページ 置き場所が曖昧な情報を減らす
下書きのままのページ 公開するか、削除するか決める
Slackで繰り返された質問 FAQや手順ページにする
検索で見つからなかった言葉 ページ名やタグを直す
外部共有されたページ 社内情報が混ざっていないか確認する

Notion Wikiには、レビュー用ビューを作ります。

ビュー 見る人 目的
期限切れページ 管理者、ページオーナー 古い情報を放置しない
自分がオーナーのページ 各担当者 自分の更新責任を確認する
確認待ちページ 確認者 正式ページにする前に見る
カテゴリ未設定 管理者 情報の迷子を減らす
最近更新されたページ 全員 変更された情報を把握する

週次で全部を見る必要はありません。

最初は、月1回でよいです。

ただし、Slackで何度も聞かれる質問は、その場でWikiへ反映します。

「それはWikiにあります」と返すだけでは定着しません。

ページが見つからなかった理由を直すことが、Wiki運用です。

運用が止まる失敗例

Notion Wikiでよくある失敗は、次の通りです。

失敗 直し方
トップページだけきれいに作る よく使うページとレビュー用ビューを先に作る
「資料」「手順」など曖昧な名前にする 業務名を入れたページ名にする
全員が自由に編集できる 編集者、確認者、閲覧者を分ける
ページオーナーを設定しない 重要ページからオーナーを付ける
全ページを認証済みにする 会社として正しい情報だけ認証する
議事録やタスクをWikiに混ぜる 議事録DB、タスクDBへ分ける
部署別カテゴリだけで作る 業務別カテゴリも作る
公開後にレビューしない 月次で期限切れと未設定ページを見る

特に危険なのは、議事録とタスクをWikiに混ぜることです。

議事録は、会議日、参加者、決定事項で管理した方がよいです。

タスクは、担当者、期限、状態で管理した方がよいです。

Wikiには、議事録DBやタスクDBへの入口、運用ルール、重要な決定事項の参照先を置きます。

Notion議事録DBの設計はこちら

Notionタスク管理の設計はこちら

Notion Wikiに向かない領域

Notion Wikiは、小さく始める情報共有には向いています。

ただし、すべてをNotion Wikiに入れる必要はありません。

次の条件が強い場合は、専用システムや別ツールへ分けます。

条件 分ける理由
承認フローが厳密 誰がいつ承認したかの証跡が必要
規程管理が中心 改定履歴、施行日、監査対応が必要
権限階層が複雑 部門、役職、拠点ごとの細かい制御が必要
外部公開文書が多い 顧客向けポータルやCMSが向く
個人情報や機密情報が多い 専用管理や法務確認が必要
既存の社内検索基盤がある Notionを入口や補助に留める方がよい

Notion Wikiは、情報の形を素早く整え、現場で使いながら改善するには強いです。

一方で、厳密な文書統制、監査、承認、複雑な権限が必要な領域は、専用基盤の方が向きます。

Notion Wikiは、社内情報を置く場所ではなく、情報の責任者、鮮度、探し方を見えるようにする仕組み。重い文書統制が必要な領域は、無理にNotionへ寄せない ことが大切です。

まとめ

Notion Wikiは、ページを作って並べるだけならすぐ始められます。

しかし、実務で使われるWikiにするには、作る前の情報設計が重要です。

Notion Wikiを作るときは、次の順番で進めます。

  • Wikiに置く情報と置かない情報を決める
  • カテゴリを5〜7個程度に絞る
  • タグは部署、業務、情報種別に分けすぎず使う
  • ページ名は「業務名 + 何をするページか」にする
  • 親ページを作り、初期ページを置いてからWiki化する
  • ページオーナー、有効期限、認証状態を設定する
  • 権限はページ単位ではなく、カテゴリやスペース単位で整理する
  • 最初はよく聞かれる10ページから作る
  • 1か月目に、期限切れ、オーナー未設定、カテゴリ未設定をレビューする
  • 議事録、タスク、案件、顧客情報は必要に応じて別DBへ分ける

Notion Wikiの作り方で大切なのは、画面の作り込みではありません。

誰が更新し、いつ見直し、どの情報を信頼してよいかを決めることです。

まずは、全社共通、業務手順、IT・ツール、FAQの4カテゴリで始めます。

そのうえで、よく見られるページにオーナーと有効期限を付けます。

ここまでできると、Notion Wikiは「ページ置き場」ではなく、更新され続けるナレッジ基盤として使いやすくなります。

Notionシステム設計支援

Notion Wikiを業務ナレッジ基盤として設計します

社内Wiki、マニュアル、議事録、タスクDB、外部ツールの分け方まで、現場の運用に合わせて構築します。

著者
守高 成悟
守高 成悟

代表取締役 CEO

千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。

運営会社
株式会社ビットライト
株式会社ビットライト

顧客が本当に必要だった価値を、実装する。

現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援しています。

コーポレートサイトを見る
Notion設計相談

議事録・タスク・ナレッジの運用設計を相談できます

Notionで始める範囲、権限、通知、別システムへ切り出す条件まで整理します。