Notionシステム研究所 > NotionでページをWikiに変換する方法|有効期限とオーナーで情報を保つ

NotionでページをWikiに変換する方法|有効期限とオーナーで情報を保つ

2026年6月5日

16分で読めます

NotionでページをWikiに変換する方法を、変換できるもの・できないもの、変換前チェックリスト、3つのデフォルトビュー、オーナー、有効期限、権限、元に戻す判断まで解説します。

Notion
Wiki
社内ナレッジ
有効期限
ページオーナー
権限設計
助手
助手

Notionの既存ページをWikiに変換したいです。ボタンを押せば、そのまま社内Wikiとして使えますか。

博士
博士

変換操作だけなら簡単じゃ。ただし、既存ページをそのままWiki化すると、古いページ、曖昧なページ名、権限の混在まで一緒にWiki化してしまう。変換前の棚卸しが先じゃ。

Notionでは、既存のページをWikiに変換できます。

Notion公式ヘルプでは、ページ上部の ••• から Wikiに変換 を選ぶ手順、Wikiに変換できるのはページのみでデータベースはWikiに変換できないこと、Wikiに3つのデフォルトビューがあることが説明されています。

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

同じヘルプでは、Wikiを元に戻す操作、ページオーナー、認証済みページ、有効期限、期限切れ時の通知についても説明されています。

つまり、NotionのWiki化は、単なる表示切り替えではありません。

ページを、情報の責任者と鮮度を管理する場所へ変える操作です。

ただし、実務で危ないのは、変換ボタンそのものではありません。

次の状態のままWikiに変換すると、問題もそのまま引き継ぎます。

  • ページ名が「資料」「手順」「メモ」になっている
  • 部署別ページと業務別ページが混ざっている
  • 古いページと最新ページの区別がない
  • ページオーナーが分からない
  • 顧客向け共有ページと社内メモが同じ階層にある
  • 議事録、タスク、マニュアルが同じページ階層に混ざっている
  • 外部ゲストが見てよいページと社内限定ページが分かれていない

NotionでページをWikiに変換する前にやるべきことは、操作確認ではなく、既存ページの棚卸し、残すページの選定、オーナー、有効期限、権限、戻す判断を決めること です。

この記事では、NotionでページをWikiに変換する方法を、変換できるもの・できないもの、変換前チェックリスト、3つのビュー、オーナーと有効期限、既存ページ階層の整理、Wikiを元に戻す判断まで含めて整理します。

Notion Wiki全体の設計はこちら

Notionの通常ページをWikiに変換し、デフォルトビュー、オーナー、有効期限、戻す判断へつなぐ構成図

先に結論:変換前に既存ページを棚卸しする

NotionのページをWikiに変換する流れは、次の順番で進めます。

順番 やること 目的
1 既存ページを棚卸しする 古いページや重複ページを混ぜない
2 Wikiに入れる情報を決める タスク、議事録、案件情報と分ける
3 ページ名とカテゴリを整える 検索しやすくする
4 権限と外部共有を確認する 共有事故を防ぐ
5 ページをWikiに変換する Wikiの3つのビューを使えるようにする
6 オーナーと有効期限を設定する 情報が古くなるのを防ぐ
7 戻す判断を決める Wiki化が合わない場合に迷わない

変換操作は最後の方です。

先に押してしまうと、今あるページ階層の問題が見えにくくなります。

特に、社内WikiやチームWikiを作る場合は、既存ページをそのままWikiにしない方がよいです。

Wiki化する前に、次の3つに分けます。

分類 置き場所
Wikiに残す 社内ルール、マニュアル、FAQ、オンボーディング Wiki
別DBへ分ける 議事録、タスク、案件、顧客情報 議事録DB、タスクDB、案件DB
削除・統合する 古い資料、重複ページ、使われていないメモ 削除、アーカイブ、統合

Notion Wikiは、後から何度も参照するストック情報に向いています。

進行中のタスクや会議記録は、Wikiではなくデータベースで管理した方が崩れにくいです。

Wikiに変換できるもの・できないもの

Notion公式ヘルプでは、Wikiに変換できるのはページのみで、データベースはWikiに変換できないと説明されています。

この違いは重要です。

対象 Wikiに変換できるか 補足
通常ページ できる 親ページをWiki化できる
サブページを持つページ できる 配下のページをWiki内のページとして扱いやすくなる
フルページデータベース できない Wiki用の親ページを別に作る
インラインデータベースを含むページ ページ自体はできる DBはWikiそのものにはならない
タスクDB Wiki化しない方がよい 担当者、期限、状態で管理する
議事録DB Wiki化しない方がよい 会議日、参加者、決定事項で管理する

既存のデータベースをWikiのように見せたい場合でも、データベースを直接Wiki化するのではありません。

Wiki用の親ページを作り、その中から必要なデータベースへリンクします。

たとえば、社内Wikiのトップページには次のように置きます。

## 業務ルール
- 勤怠・休暇
- 経費精算
- 契約レビュー

## 関連DB
- 議事録DB
- タスクDB
- マニュアルDB
- 案件DB

Wikiは情報の入口です。

タスクや議事録の実行管理までWikiに入れると、ページ数が増え、後から探しにくくなります。

変換前チェックリスト

既存ページをWikiに変換する前に、次のチェックを行います。

チェック 見ること 対応
ページ名 内容が分かる名前か 業務名を入れて直す
重複 同じ内容のページがないか 1つに統合する
鮮度 最終更新日が古すぎないか 更新、削除、アーカイブ
オーナー 誰が内容に責任を持つか ページオーナーを決める
公開範囲 誰が見てよいか 全社、部署内、関係者、機密に分ける
外部共有 顧客やパートナーに共有されていないか 社内Wikiから分離する
情報種別 ルール、手順、FAQ、議事録、タスクが混ざっていないか DBやカテゴリへ分ける

ページ名は、検索される名前に直します。

直す前 直した後
資料 営業提案資料テンプレート
手順 経費精算の申請手順
アカウント Google Workspaceアカウント追加手順
メモ 問い合わせ一次対応メモ
FAQ 勤怠・休暇でよくある質問

重複ページも、Wiki化前に整理します。

Wiki化後に重複を直すこともできますが、変換前に減らした方が、最初のビューがきれいになります。

削除に迷うページは、すぐ消さずにアーカイブ用ページへ移します。

1か月見られなければ削除、という運用でも十分です。

Wikiに変換する手順

Notion公式ヘルプでは、ページをWikiに変換する手順として、ページ上部の ••• を選び、Wikiに変換 をクリックすると説明されています。

実務では、次の順番で進めます。

手順 やること
1 Wiki化したい親ページを開く
2 配下のページ名とカテゴリを確認する
3 外部共有や機密ページが混ざっていないか確認する
4 ページ上部の ••• を開く
5 Wikiに変換 を選ぶ
6 ホーム、すべてのページ、自分がオーナーのページを確認する
7 オーナー、有効期限、認証状態を設定する

変換する親ページは、できるだけ明確な名前にします。

用途 親ページ名
全社向け 社内Wiki
部署向け 営業チームWiki
業務向け 経理・申請Wiki
プロジェクト向け 新規事業プロジェクトWiki

親ページ名が曖昧だと、社員がどこに何を書くべきか迷います。

「共有」「メモ」「資料」ではなく、「社内Wiki」「営業チームWiki」「IT・セキュリティWiki」のように目的を入れます。

変換直後は、見た目を整えるより、ビューとプロパティを確認します。

3つのデフォルトビュー

Notion公式ヘルプでは、Wikiに変換すると、次の3つのデフォルトビューがあると説明されています。

ビュー 役割 実務での使い方
ホーム Wikiの入口 よく使うページ、カテゴリ、問い合わせ先を置く
すべてのページ Wiki内ページの一覧 カテゴリ、オーナー、有効期限で棚卸しする
自分がオーナーのページ 自分が持つページの一覧 各担当者が更新責任を確認する

ホームは、きれいな表紙ではありません。

社員が最初に見る導線です。

たとえば、次のように作ります。

## よく使うページ
- 勤怠・休暇
- 経費精算
- アカウント申請

## 業務別
- 入社対応
- 請求・入金
- 問い合わせ対応

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

すべてのページビューは、管理者向けです。

ページ数、カテゴリ、オーナー、有効期限、確認状態を一覧で見ます。

自分がオーナーのページは、各担当者が見るビューです。

月次レビューでは、このビューを使って自分の担当ページを確認します。

追加で作るなら、次のビューが実務向けです。

ビュー 条件 目的
期限切れページ 有効期限が今日以前 古い情報を放置しない
確認待ちページ 認証状態が確認待ち 正式情報にする前に見る
オーナー未設定 オーナーが空 更新責任を決める
外部共有注意 公開範囲が外部 共有事故を防ぐ
最近更新されたページ 最終更新日が直近 変更された情報を知らせる

Wiki化したら、ページを増やす前にレビュー用ビューを作ります。

レビュー用ビューがないWikiは、すぐ古くなります。

オーナーと有効期限を設定する

Wiki化した後は、ページオーナーと有効期限を設定します。

Notion公式ヘルプでは、Wiki内でページを作成したユーザーが初期状態のページオーナーになること、ページオーナーは変更できることが説明されています。

しかし、実務では作成者と責任者が違うことがよくあります。

たとえば、管理部の手順を別部署のメンバーが下書きすることがあります。

その場合、作成者をオーナーのままにせず、内容に責任を持つ人へ変更します。

項目 目的
ページオーナー 内容の責任者を明確にする
確認者 会社として正しい情報か確認する
有効期限 次に見直す日を決める
認証状態 下書き、確認待ち、認証済み、期限切れを分ける
公開範囲 全社、部署内、関係者、機密を分ける
関連DB 議事録、タスク、マニュアル、申請先につなぐ

有効期限は、情報ごとに変えます。

情報 見直し頻度
会社概要 半年または変更時
組織図 月次または変更時
勤怠・休暇ルール 半期または変更時
経費精算手順 四半期
ITアカウント手順 四半期
営業資料 月次
FAQ 月次

すべてのページに厳密な期限を入れる必要はありません。

最初は、よく見られる上位20〜30ページだけで十分です。

Notion公式ヘルプでは、認証済みページの有効期限が切れると、ページオーナーにNotionの受信トレイとメールで通知されると説明されています。

この仕組みは便利ですが、通知だけに頼ると運用は止まります。

月次で期限切れビューを見る運用も作ります。

既存ページ階層の整理

既存ページをWikiに変換するとき、最も崩れやすいのはページ階層です。

ページ階層は、作った人の都合で増えがちです。

Wiki化する前に、読む人の探し方に合わせて整理します。

よくある階層 問題 直し方
部署別だけで分ける 横断業務が見つからない 業務別カテゴリも作る
プロジェクト別だけで分ける 終了後に情報が埋もれる 汎用ナレッジをWikiへ移す
年度別で分ける 最新手順が分からない 現行版と過去版を分ける
人名で分ける 退職や異動で責任が曖昧になる ページオーナーで管理する
顧客別で分ける 権限と機密性が重い 顧客DBや案件スペースに分ける

おすすめは、トップページで次の入口を分けることです。

## 全社共通
- 会社情報
- 勤怠・休暇
- 経費・申請

## 業務別
- 入社対応
- 請求・入金
- 問い合わせ対応

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

## 関連DB
- 議事録DB
- タスクDB
- マニュアルDB

Wikiにすべてを入れるのではなく、正しい場所へ案内します。

ページ階層を整理するときは、既存リンクが切れないよう注意します。

重要ページを移す場合は、移動後にトップページや関連ページからリンクし直します。

Wikiを元に戻す判断

Notion公式ヘルプでは、Wikiとして使わなくなったページは、ページ上部の ••• から Wikiを元に戻す を選べると説明されています。

Wikiを元に戻すことは失敗ではありません。

用途に合わないWikiを無理に続ける方が問題です。

次の状態なら、Wikiを元に戻す、または別の構成にする判断をします。

状態 判断
ページ数が少ない 通常ページで十分
個人メモ中心 Wiki化せずページ階層でよい
タスク管理が中心 タスクDBへ分ける
議事録が中心 議事録DBへ分ける
顧客別情報が中心 案件DBや顧客DBへ分ける
承認履歴や監査が重要 専用文書管理へ分ける
権限が複雑すぎる チームスペースや専用ツールへ分ける

特に、議事録とタスクが中心のページは、Wiki化よりDB化が向きます。

議事録は、会議日、参加者、決定事項、関連タスクで管理します。

タスクは、担当者、期限、状態、優先度で管理します。

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

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

Wikiは、これらのDBへ案内する入口にします。

社内Wiki化の注意点

既存ページを社内Wikiに変換する場合は、個人用Wikiより慎重に進めます。

社内Wikiは、全員が参照する情報基盤になるからです。

注意点は次の通りです。

注意点 理由
人事、労務、評価情報を混ぜない 閲覧範囲が限定される
顧客別情報を通常Wikiに置かない 機密性と外部共有のリスクがある
下書きと正式情報を分ける どれを信じてよいか分からなくなる
オーナー未設定を放置しない 古い情報が残る
外部共有ページを分離する ゲスト招待時の事故を防ぐ
Wiki運用ルールを1ページ作る 誰が何を更新するかを示す

社内Wikiでは、次のページを最初に作ります。

ページ 目的
Wikiの使い方 ページ作成、命名、カテゴリのルール
問い合わせ先一覧 誰に聞くかを減らす
更新ルール オーナー、有効期限、認証の使い方
外部共有ルール 顧客、パートナー、ゲスト招待の基準
関連DB一覧 議事録、タスク、マニュアル、案件への入口

社内Wikiにすると、ページを作る人が増えます。

だからこそ、作り方のルールを最初に置きます。

ルールがないWikiは、作成者ごとにページ名、カテゴリ、タグがばらばらになります。

Notion Wiki化に向かない領域

Notion Wikiは、情報共有やナレッジ管理を小さく始めるには便利です。

ただし、すべての情報をWiki化する必要はありません。

次の領域は、別ツールや専用DBを検討します。

領域 理由
厳密な規程管理 改定履歴、施行日、承認履歴が重要
契約書管理 権限、版管理、法務確認が必要
人事評価 機密性とアクセス制御が重い
顧客情報 個人情報、案件権限、監査が関わる
タスク管理 担当者、期限、状態、通知が必要
議事録管理 会議日、参加者、決定事項、タスク連携が必要

Notionを使わないという意味ではありません。

Notion Wikiは、これらの専用DBや外部システムへの入口として使えます。

たとえば、契約書の実体はクラウドサインやDriveで管理し、Notion Wikiには「契約レビュー依頼の手順」を置きます。

会計処理はfreeeや会計システムで行い、Notion Wikiには「経費精算の申請手順」を置きます。

Notion Wikiに変換する目的は、すべてをNotionに閉じ込めることではなく、正しい情報と正しい業務DBへ迷わず到達できる入口を作ること です。

まとめ

Notionでは、ページ上部の ••• からページをWikiに変換できます。

ただし、実務では変換ボタンを押す前の準備が重要です。

NotionでページをWikiに変換するときは、次の順番で進めます。

  • Wikiに変換できるのはページであり、データベースではないと理解する
  • 既存ページを棚卸しし、古いページ、重複ページ、機密ページを整理する
  • Wikiに残す情報、別DBへ分ける情報、削除・統合する情報を決める
  • ページ名を「業務名 + 何をするページか」に直す
  • 親ページを開き、••• から Wikiに変換 を選ぶ
  • ホーム、すべてのページ、自分がオーナーのページを確認する
  • ページオーナー、有効期限、認証状態、公開範囲を設定する
  • 期限切れ、確認待ち、オーナー未設定のビューを作る
  • 用途に合わなければ、Wikiを元に戻す、またはDBへ分ける
  • 社内Wiki化する場合は、外部共有、人事労務、顧客情報を分離する

Notion Wikiは、既存ページをきれいに見せるための機能ではありません。

社内情報を、誰が持ち、いつ見直し、どの情報を信頼してよいかを見えるようにする仕組みです。

まずは、既存ページをそのまま変換せず、残すページ、分けるページ、消すページを整理します。

そのうえで、Wiki化したページにオーナーと有効期限を設定します。

ここまでできると、NotionのWiki化は、単なるページ整理ではなく、古くならない社内ナレッジ基盤の入口になります。

Notionシステム設計支援

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

既存ページの整理から、社内Wiki、マニュアル、議事録、タスクDB、外部共有の分離まで、実務に合わせて構築します。

著者
守高 成悟
守高 成悟

代表取締役 CEO

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

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

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

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

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

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

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