社内wikiとは？最初のページの作り方と定着する更新運用

▼ この記事の内容

社内wikiは、繰り返し使う業務の手順、問い合わせ先、確認日を一つのページへ整理し、利用者が別名で探して実行できるようにする仕組みです。最初は一業務を選び、所有者と見直す時期を決めて試用し、見つからない点や古い内容を更新します。

社内wikiは、業務の手順や用語をページとして共有し、担当者が更新しながら使う場所です。最初から全社の知識を集めるのではなく、繰り返し質問される一つの業務から始めると、載せる情報と確認する人を決めやすくなります。

この記事では、社内wikiの役割、最初のページの作り方、利用者に試してもらう方法、更新が続く運用を説明します。貸出PCの返却を題材にした記入例は説明のための架空例であり、実在する会社の手順や導入実績ではありません。

社内wikiでできること

社内wikiは、情報を保管するだけでなく、誰が何を更新するかをページごとに分けて扱うための場所です。業務で使うなら、利用者が探す言葉と、内容を確認する担当者を同時に残します。

社内wikiは業務知識を共同で更新する場所

社内wikiは、チームの手順、用語、よくある質問をページ単位で整理し、関連するページをつなぎながら共同で更新する仕組みです。Notionの会社向けwikiガイドでも、資料を集約し、カテゴリや階層を整える利用例が案内されています。

ただし、これはNotionにおける利用例であり、すべてのwiki製品に同じ機能があるという意味ではありません。自社では、どの情報を正式な手順として扱うかを、業務の責任者と確認して決めます。

参考：How to build a wiki for your company｜Notion

ファイル共有やFAQとの役割の違い

ファイル共有、FAQ、wikiは、同じツール内で併用できることがあります。役割を先に分けると、利用者が探す入口と、更新する対象を決めやすくなります。

扱い方	主な役割
wiki	手順や用語をページ同士で関連付け、更新する
ファイル共有	原本となる資料や添付ファイルを保管する
FAQ	質問と回答の形で、よくある確認を案内する

Atlassianの知識管理ガイドでは、チームspace、グループ権限、ページテンプレート、ラベルを使った整理方法が案内されています。権限をどこまで開くかは、情報区分と社内規程を確認して決めてください。

FAQをどの範囲で独立させるかは、社内FAQとwikiの違いを整理した記事で補足しています。

営業AI・営業DX 社内FAQシステム比較｜4類型の選び方と失敗しない導入判断軸

参考：Knowledge Management Best Practices｜Atlassian

最初に載せる情報を決める

最初のページは、情報量ではなく、利用者が繰り返し尋ねる一つの業務を基準に選びます。質問の入口、正式な手順、問い合わせ先を一つのページで追える範囲に絞ります。

繰り返し聞かれる業務から始める

貸出PCの返却のように、担当者が同じ確認を受ける業務を一つ選びます。最初に集めるのは、実際に聞かれる言い方、現行の手順、判断に迷ったときの窓口です。

「パソコンを返すには」「PC返却」といった別名も、ページ名か検索用の別名として記録します。

正式な手順と下書き・旧版を分ける

正式な手順、検討中の下書き、以前の手順は、同じ閲覧経路に混ざらないように扱います。古い内容を消せない場合でも、現行ページへの案内と状態表示を付ければ、利用者が確認先を選べます。

情報の状態	置き方	利用者への案内
正式な手順	現行ページに根拠と確認日を記載する	このページを実行時の入口にする
下書き	編集者だけが見える場所に分ける	正式な回答としては案内しない
旧版	旧版であることと切替先を示す	現行ページへ移動して確認する

機密情報や個人情報は、ページを作る前に閲覧・編集範囲を確認します。製品の権限機能を利用する場合も、設定の内容が自社の規程に合うかを確認します。

社内wikiの作り方

作成時は、ページを増やす順番ではなく、利用者が見つけて実行する順番で情報を置きます。カテゴリ、ページ名、検索別名、手順、確認日を一緒に決めると、後から見直す箇所も分かります。

カテゴリ・ページ名・検索語をそろえる

カテゴリは、たとえば「テック」→「貸出機器」→「貸出PC」のように、利用者が業務を思い出せる順に置きます。階層を深くしすぎず、ページ名には「貸出PCの返却手順」のように作業を入れます。

検索別名には「パソコン返す」「PC返却」を加え、実際の呼び方で到達できるかを後で試します。カテゴリやラベルを使う方法は製品によって異なるため、この並べ方を全ツールの公式仕様としては扱いません。

手順と更新情報を同じページに記載する

次は、利用者が実行する内容と、内容を確認する人を同じページに記入します。下表は貸出PC返却を題材にした架空の記入例であり、実際の社内ルールや連絡先ではありません。

記入項目	架空の記入例
目的・対象	社内貸出PCを返却する
手順	返却日時を担当へ連絡し、PCと付属品を受付へ渡して受領確認をする
窓口・根拠	情シス窓口／社内貸出ルール
更新情報	更新責任者：情シス担当、最終確認日：2026年9月15日、次回確認：貸出ルール変更時または月次

実際に記入する際は、窓口名、根拠資料、確認日を自社の情報で置き換えます。例に合わせるために、個人の連絡先や確認できないルールを作り足してはいけません。

利用者に探してもらい公開範囲を広げる

公開範囲を広げる前に、利用者が別名で検索し、正しいページに着き、手順を読んで実行できるかを試します。不明点が残った場合に、どこへ連絡すればよいかも確認します。

見つからなければ、まずページを増やす前に、名前、別名、入口のどれが不足しているかを見直します。

更新を続けるための運用を決める

ページを公開した後は、情報を増やす担当と、内容を確認する担当を分けておくと、変更があったときに確認先が分かります。確認日だけではなく、何をきっかけに見直すかも残します。

ページごとに所有者と確認日を残す

ページには、更新する所有者、承認が必要な内容の確認者、最終確認日を記します。Notionの公式ヘルプでは、wikiページの所有者、検証期限、期限切れ時の通知を設定する機能が案内されています。

これはNotionの機能例であり、全wikiで同じ設定ができるとは限りません。機能がない場合も、ページ末尾に担当者と確認予定を記す方法から始められます。

参考：Wikis & verified pages｜Notion

変更・退職・期限切れ時の引き継ぎを決める

業務ルールが変わったら、責任者が内容、根拠、確認日を更新する流れを決めます。担当者の異動や退職時は、後任がページの所有者と未確認の項目を引き継ぐようにします。

確認日を過ぎたページが直ちに誤りとは限りませんが、利用者が判断に迷わないよう「確認中」と窓口を示せます。更新できない内容は、古い手順を残したままにせず、現行の確認先へ誘導します。

利用状況を確かめて改善する

閲覧数だけでは、利用者が目的を果たせたかは分かりません。検索語、到達したページ、理解できなかった箇所を小さく記録すると、次に直すべき内容を選べます。

閲覧数と自己解決を分けて確認する

利用者の試用では、見られた回数と、手順を実行できたかを別に記録します。下表は確認項目の架空例であり、この記録から組織全体の成果や削減率を判断するものではありません。

確認したこと	架空の記録例
質問と検索語	PCを返したい／パソコン返す
到達と理解	返却手順のページには到達できたが、付属品が分からなかった
改善	手順に付属品の確認欄を追加し、再度試用する

このように記録すると、ページが読まれた事実と、作業で迷った事実を混ぜずに扱えます。改善後も同じ業務の利用者に試してもらい、変更した箇所が伝わるかを確かめます。