社内wikiの作り方：OSS構築の手順と権限・検索設計、スクラッチ開発の判断基準

社内wikiの作り方は、クラウド型ツールを導入する、オープンソース（OSS）を自社サーバーに構築する、業務システムの一部としてスクラッチ開発する、という3つの方式に分かれます。この記事では、構築を担当するエンジニアや情報システム部門の技術選定者に向けて、GROWIやWiki.jsといったOSSの具体的な構築手順、形骸化を防ぐ権限・階層・日本語検索の設計、費用比較と受託開発へ切り替える分岐点までを扱う構成です。そのうえで、自作を採用してよい条件と見送るべき場面を、業務システム開発の現場視点で言い切ります。

まとめ：社内wiki構築は方式選定と権限・検索設計が成否を分ける判断軸

結論から示すと、社内wikiの構築は「書き込む人をどれだけ増やせる設計にするか」で決まります。方式選定の目安は明快です。サーバー保守を担う技術者を確保できないならクラウド型ツール、Linuxサーバーを運用できる技術者がいてデータを自社管理下に置きたいならGROWI 7系（2026年7月時点）などのOSSセルフホスト、申請ワークフローや基幹システム連携まで要件に入るならスクラッチ開発が候補になります。どの方式でも、公開後の定着を左右するのは権限設計（誰でも書ける状態の担保）と日本語検索の精度です。

社内wikiは、組織の知識を蓄積・共有するナレッジマネジメント施策の実行手段のひとつです。wikiで何を解決するのかという上流の整理はナレッジマネジメントの意味とSECIモデル、導入手順を整理した記事が判断ハブとして扱っており、本記事はその「wikiを作る」と決めた後の実装手順に焦点を絞る位置づけです。費用の比較と発注判断の分岐は後半の章で数字とともに示します。

社内wikiを作る3つの方式：クラウドサービス・OSS構築・スクラッチ開発の比較

先に方式を決めないと、構築手順も費用感も定まりません。3方式の技術要件と向き不向きを順に確かめます。

クラウド型社内wikiツールで作る方式の要件と自社管理の限界

もっとも導入が速いのは、NotePM・esa・Confluenceといったクラウド型ツールを契約する方式です。サーバー構築が不要で、アカウント発行から数日で運用を始められます。月額はユーザー数課金が主流で、数十人規模なら月数千円から数万円のレンジ（2026年時点の各社公表プラン）に収まります。技術者が社内にいない組織では、実質この方式が唯一の現実解です。

制約は自社管理の範囲にあります。データの設置場所はベンダーのクラウドに固定され、オンプレミスや自社VPC内に置きたいという要件には応えられません。画面や権限モデルのカスタマイズも提供プランの枠内に限られます。セキュリティポリシー上データを外部に出せない、既存の認証基盤と細かく統合したい、という条件が1つでもあるなら、次のOSS方式以降を検討する段階です。

OSSをセルフホストして作る方式の技術要件と保守運用の前提条件

2つ目は、公開されているOSSのwikiエンジンを自社サーバーやクラウド（VPS・AWSなど）に構築する方式です。ライセンス費用なしで全文検索・権限管理・編集履歴といった専用機能を持て、データの設置場所も自社の管理下に置けます。代表的な選択肢に、日本製のGROWI、海外製のWiki.js・DokuWikiがあり、後の章で構築手順まで具体化します。

前提条件は、LinuxサーバーとDocker・データベースを扱える技術者が社内にいることです。構築そのものは1〜2日で通せますが、公開後のセキュリティ更新・バージョンアップ・障害一次対応を自社で続けられるかが分かれ目になります。ベンダーサポートはなく、頼れるのは公式ドキュメントとコミュニティだけです。この保守体制を用意できないなら、OSS方式は選ばないほうが安全です。

スクラッチ開発で業務要件に合わせ込む方式の工数と適する組織規模

3つ目は、Webアプリケーションとしてwiki機能をゼロから開発する方式です。既製品のwikiは汎用の情報共有に作られているため、承認ワークフロー付きの文書管理、基幹システムのマスタと連動した権限制御、部門固有の帳票と一体になった画面といった要件は満たせません。こうした業務ロジックとの合わせ込みが目的なら、スクラッチが選択肢に入ります。

工数の目安は、ページ作成・編集履歴・全文検索・権限管理という最小構成でも設計・実装・テスト込みで数人月規模、外部委託なら数百万円のレンジが一般的です。純粋な「wikiが欲しい」だけの動機でこの投資は回収できません。スクラッチが正当化されるのは、wikiを既存業務システムの一部として統合する要件があるときに限られます。この損益分岐は後半の判断章で計算します。

OSS社内wikiの選定と構築手順：GROWI・Wiki.jsを軸にした導入の流れ

OSS方式を選んだ場合の具体的な選定と構築の流れです。候補は多くありますが、日本語環境で実用に耐えるものは限られます。

GROWI 7系の機能と動作要件・Dockerを使った構築手順の要点

GROWIは日本で開発が続くwiki専用OSSで、2026年7月時点の安定版は7系です。Node.jsとMongoDBで動作し、公式がDocker Compose構成を提供しているため、コンテナが動くサーバーなら短時間で立ち上がります。Markdown編集・同時多人数編集・階層ページ・グループ権限を標準で備え、LDAPやSAML・OIDCによるシングルサインオン連携にも対応します。構築の流れは次のとおりです。

1. サーバー（VPS・クラウドの仮想マシン）にDockerとDocker Composeを導入する
2. 公式のgrowi-docker-composeリポジトリを取得し、環境変数（サイトURL・シークレット）を設定して起動する
3. 初回アクセスで管理者を作成し、認証方式（ローカル・LDAP・SAMLなど）と新規登録の許可範囲を決める
4. Elasticsearchコンテナを有効にして日本語全文検索を組み込む（標準構成に含まれる）
5. リバースプロキシでTLS化し、MongoDBのバックアップとリストア手順を確かめてから全社公開する

手順自体は難所が少ない一方、実工数は次章以降の権限・階層・検索の設計に集中します。サーバーを立てた時点では、まだ「作り方」の半分です。

Wiki.js・DokuWikiなど他のOSS候補と選定の比較観点

GROWI以外の候補では、Wiki.jsとDokuWikiが現実的です。Wiki.jsはNode.js製で、2026年5月リリースの2.5.314など2.5系の更新が続いており、PostgreSQLを推奨データベースとし、50種類を超える認証方式との連携を売りにします。DokuWikiはPHP製でデータベース不要のフラットファイル構成のため、低スペックの共用サーバーでも動きます。Wikipediaと同じMediaWikiもありますが、独自記法の習得コストと管理画面の癖から、社内用途では前の2つに比べて勧めにくい選択です。選定では次の観点を確かめます。

• 直近1年以内にセキュリティ修正を含むリリースがあるか（GitHubのreleasesで実測する）
• 日本語の全文検索を標準または公式手順で組み込めるか（多言語UIの有無とは別の問題）
• 自社の認証基盤（LDAP・SAML・OIDC）に公式対応しているか
• ページの編集履歴と差分表示、グループ単位の閲覧・編集権限を備えるか

この4点で絞ると、日本語の社内ナレッジ用途ではGROWIを第一候補、既存インフラがNode.js＋PostgreSQLで揃うならWiki.js、サーバー資源が極端に限られるならDokuWiki、という切り分けになります。

エンジニア組織の開発ドキュメントに特化したWiki構築の選択肢

全社ナレッジとは別に、開発チームのドキュメントだけをWiki化したい場合は、汎用wikiより特化型のほうが速いことがあります。ソースコードの理解が目的なら、GitHubリポジトリを解析してWikiを自動生成するOSSという選択肢があり、GitHubのコードをローカルでWiki化する無料OSS「DeepWiki-Open」の導入と使い方で構築手順を扱っています。コードから生成されるドキュメントは実装と乖離しにくく、手書きの設計書を書き起こす工数を削れる点も利点です。

使い分けの線引きは知識の出どころです。コードに由来する知識（構成・API仕様・依存関係）は自動生成に寄せ、コードに書かれない知識（決定の経緯・運用手順・障害対応記録）はGROWIなどの手書きwikiに蓄積する、という二本立てにすると、どちらのwikiも更新が止まりにくくなります。

形骸化を防ぐ社内wikiの情報設計：権限・階層・日本語検索の作り込み

社内wikiの失敗は、サーバー構築ではなく情報設計で起きます。書き込みの摩擦・迷子ページ・検索の空振りという3つの穴を、構築段階で塞ぎます。

閲覧・編集権限とSSO連携の設計で決まる書き込みやすさの確保

権限設計の原則は「閲覧も編集も既定で全開放し、絞るのは機密だけ」です。承認を経ないと書けないwikiは、書き手が数人に固定され、その数人が忙しくなった時点で更新が止まります。GROWIならユーザーグループ機能で人事・経理など機密領域のページツリーだけを限定公開にし、それ以外は全社員が編集できる状態を既定にします。

入り口の摩擦も定着に直結します。wiki専用のIDとパスワードを別に発行する運用では、ログインの一手間だけで閲覧数が落ちます。SAMLやOIDCで既存のID基盤（Microsoft Entra IDやGoogle Workspaceなど）と連携し、社内ポータルや業務システムと同じ認証で入れる状態にしてから全社公開してください。退職者のアカウント停止がID基盤側の操作だけで完結する点でも、SSO連携は運用の穴を減らします。

階層設計とテンプレートの整備で迷子ページを防ぐ情報構造の実務

ページ階層は「部門／目的」の2階層を上限に設計し、3階層以下は書き手の自由に任せるのが実務的です。最初から精密な分類木を作り込むと、どこに書けばよいか迷う時間が投稿のハードルになり、分類の管理者が異動した時点で構造が崩れます。浅い階層＋検索で探す前提に振り切るほうが、後述の検索設計と噛み合います。

テンプレートは、議事録・手順書・障害対応記録・オンボーディング資料の4種類を初期整備すると効きます。書式が決まっていれば「何を書くか」だけ考えればよく、書き慣れない人の投稿ハードルが下がる効果が大きい部分です。とくに手順書と障害記録は、特定の担当者の頭の中にしかない知識を文書化する装置として機能します。業務が個人に依存する構造の崩し方は属人化の原因と脱属人化を進める仕組み化・標準化の実務を解説した記事で扱っており、wikiのテンプレート整備はその実行手段にあたります。

Elasticsearch連携と同義語辞書による日本語検索の精度設計

検索の空振りは、社内wikiが使われなくなる技術要因の筆頭です。海外製OSSの標準検索は空白区切りの言語を前提にした実装が中心で、日本語の複合語を適切に分割できないことがあります。GROWIの場合、公式Docker構成に含まれるElasticsearchと日本語形態素解析プラグイン（kuromoji）の組み合わせで全文検索を有効にするのが標準手順で、ここを省略した構築は日本語運用では実用になりません。

次の一手が同義語辞書です。「経費精算／立替精算」「PC／パソコン／端末」のような自社の語彙対応表を検索エンジンの同義語設定に登録し、表記ゆれをエンジン側で吸収します。辞書の種は検索ログから拾います。何が検索されて0件だったかを月次で確かめ、同義語の追加かページの新規作成かを判断する運用を、構築時に決めておいてください。エンジンの選定よりこの辞書を育てる仕組みのほうが、検索の体感品質に効きます。

社内wikiの内製とスクラッチ開発・SaaSの費用比較と発注判断の分岐点

方式を費用と工数で並べ、どこで採算が分かれるかを数字で確かめます。

初期費用・継続費用・保守の担い手で見る4方式の比較表と読み方

既存ツールの流用も含めた4方式の費用と特性は次のように整理できます。クラウド型の金額は2026年時点の各社公表レンジ、開発系は受託開発での一般的な規模感です。

表の読み方には注意が要ります。OSSセルフホストの継続費用欄にある保守人件費が、金額欄に出ない最大の費目です。月2時間の更新確認とセキュリティ適用でも、担当者の時間単価を掛ければ年間数万円台の実費に相当し、脆弱性対応が重なる年はさらに膨らみます。ソフトウェアが無償である事実と、総コストが安い事実は別物として見積もってください。

受託開発へ切り替える損益分岐の目安と業務アプリ統合という発展形

スクラッチ開発の採算は、クラウド型の費用との比較で概算できます。仮に月額3万円のプランを5年使うと総額180万円です。同等機能をゼロから開発すれば開発費だけでこれを超えるため、「wikiを作ること」自体を目的にしたスクラッチは成立しません。分岐点が動くのは、wikiが業務アプリの一部になるときです。ナレッジ蓄積に加えて、申請・承認ワークフロー、案件情報や顧客マスタとの連動、現場からのモバイル入力までを一体の画面で扱う要件なら、複数のSaaSを契約して連携を作り込むより、統合した業務アプリを開発するほうが総コストと運用の複雑さを抑えられる局面があります。

その見極めには、連携仕様を書ける程度まで要件を具体化することが先決です。「将来つなぐかもしれない」段階ならクラウド型で始めるべきで、連携対象・権限モデル・データの流れが文書化できて初めて開発が正当化されます。要件が固まっているなら、業務用・Webアプリ開発のサービスで、ナレッジ共有を含む業務アプリの要件定義から設計・開発・運用までを相談できます。

社内wiki自作を採用する条件と見送るべき場面：構築前の判断ライン

ここが実装者としての結論です。自作（OSSセルフホスト・スクラッチ）の採否は、着手前に次のラインで判断してください。

OSSでの社内wiki構築を採用してよい条件と異動リスクの見極め

OSSセルフホストを採用してよいのは、次の条件がすべて揃う場合です。

• Docker・Linuxサーバーの保守（月次のバージョン確認・セキュリティ適用・障害一次対応）を担える技術者が2名以上いる
• データを自社管理下（オンプレ・自社契約のクラウド）に置く要件が明文化されている
• Elasticsearch連携までを構築スコープに含める前提で工数を見積もっている（検索なしのwikiを作らない）
• バックアップとリストアの手順を全社公開前に実測で確かめる計画がある

技術者の人数を2名以上としたのは、担当者の異動・退職が社内wiki放置の最多パターンだからです。1人しか触れないサーバーは、その1人の離任と同時に「誰も更新できないが止められない」資産に変わります。構築ドキュメント自体をそのwikiの最初のコンテンツとして書き、もう1名がそれだけを見て再構築できるかを試すのが、属人化の実効性テストになります。

社内wiki自作を見送るべき失敗パターンと定着運用へ投資する判断

逆に、次の場面では自作を見送るべきです。第一に、保守要員を固定できない場合。前述のとおり、これは数年後の放置がほぼ確定します。第二に、目的が「まず情報共有の効果を確かめたい」検証段階の場合。無料プランのあるクラウド型ツールで1〜2か月試すほうが、構築に費やす時間ごと節約できます。第三に、コスト削減だけが動機の場合。保守人件費を含めた総コストでクラウド型を下回る自作はまれで、費用比較の章で示したとおり金額目的の内製は計算が合いません。

方式がどれであっても、浮いた費用は定着運用に回すべきです。テンプレートの整備、検索ログの月次確認、更新が止まった領域のオーナー再割り当てという地味な運用が、ツールの選定差よりも定着率を左右します。構築して終わりにしない体制まで含めて、社内wikiの「作り方」です。

よくある質問

社内wikiの構築を検討する実装者・情報システム担当者からよく挙がる質問に答えます。

社内wikiを無料で作ることはできますか？

ソフトウェア費用だけならゼロにできます。GROWI・Wiki.js・DokuWikiなどのOSSはライセンス費用なしで利用でき、人数制限付きの無料プランを持つクラウド型ツールも選択肢です。ただしOSSの場合はサーバー費（VPSで月数百円〜数千円規模）と、構築・保守に充てる担当者の人件費が必ず発生します。「無料」はソフトウェアの取得費に限った話で、総コストでは保守の工数が最大の費目になります。

社内wikiはExcelやSharePointでも作れますか？

作れますが、規模の上限が早く来ます。既存のMicrosoft 365環境があるなら、SharePointのページ機能やOneNoteで追加費用なしに始められ、小さな部署の手順共有には十分です。限界は検索と構造にあります。ファイル単位の管理では表記ゆれを吸収する全文検索が働かず、編集履歴の差分も追えません。全社のナレッジ基盤に育てる前提なら、最初からwiki専用の仕組みを選ぶほうが移行の手戻りを避けられます。

社内wikiと社内ポータルサイトの違いは何ですか？

役割が違います。社内wikiは全員が書き込んで知識を蓄積する場、社内ポータルは会社からの通知や各システムへの入口を集約する場です。ポータルの中の1機能としてwikiを置く構成もあり、両者は排他ではありません。ポータル側の機能や作り方、内製と外注の判断は社内ポータルサイトの機能・作り方・内製と外注の判断基準を解説した記事で整理しています。

社内wikiの構築にはどれくらいの期間がかかりますか？

OSSセルフホストの場合、サーバー構築そのものはDocker Compose利用で1〜2日が目安です。実際の期間を決めるのは設計と移行で、権限・階層・テンプレートの設計に1〜2週間、既存の共有フォルダや個人メモからの初期コンテンツ移行に数週間を見込みます。全社一斉ではなく1部門で1か月試験運用してから広げると、設計の手戻りを小さくできます。

社内wikiが更新されず形骸化するのを防ぐには？

投稿のハードルを下げる設計と、更新を確かめる運用の両方が必要です。設計面では、承認なしで誰でも編集できる権限、SSOでログインの手間をなくすこと、書式に迷わないテンプレートの3点が効きます。運用面の柱は、検索ログの月次確認で0件検索を拾ってページを足すことと、更新が止まった領域のオーナー再割り当ての2つです。ツール選定よりこの2つの積み重ねが定着率を分けます。

関連記事

• ナレッジマネジメントとは？意味とSECIモデル、属人化を解く導入手順を解説：本記事の主ハブ。社内wikiで何を解決するかという上流の整理を扱います。
• 属人化とは？原因・リスクと脱属人化を進める仕組み化・標準化の実務：wikiのテンプレート整備が実行手段となる、業務の個人依存を崩す方法論です。
• 社内ポータルサイトとは？機能・作り方・内製と外注の判断基準まで解説：wikiと役割分担する社内の入口側の構築を扱う対の記事です。
• DeepWiki-Openとは？GitHubのコードをローカルでWiki化する無料OSS：開発ドキュメントに特化したWiki自動生成の具体例です。