社内wikiの作り方｜6ステップの手順とOSS（GROWI v8・Wiki.js）で自作する構築・判断基準

社内wikiの作り方は、目的を決める、作る方式を選ぶ、載せるナレッジを棚卸しする、階層とテンプレートを作る、権限とログイン方法を決める、1部門で試験運用してから広げる、の6ステップです。方式はクラウド型ツールの契約、オープンソース（OSS）の自社構築、スクラッチ開発、既存ツールの流用の4つから選びます。この記事は全体の手順を示したうえで、OSSで自作する場合にGROWI v8とWiki.jsを実際にDocker Composeで起動して測った必要メモリ・初回起動の落とし穴・日本語検索の挙動と、自作を見送るべき条件を扱います。

まとめ：社内wikiの作り方6ステップと方式選定の結論

結論から示します。サーバーを保守できる技術者がいないならクラウド型ツール、Linuxとコンテナを運用できる技術者が2名以上いてデータを自社管理下に置きたいならOSSのセルフホスト、申請・承認や基幹システムとの連携まで要件に入るならスクラッチ開発です。どの方式でも、公開後の定着に向けて、一般的なノウハウを投稿しやすい権限、既存IDで入れるログイン、日本語で探せる検索に加え、文書の更新責任者と見直しの周期を決めます。

OSSなら、2026年10月時点の第一候補はGROWI v8（最新はv8.0.7）です。公式のDocker Compose構成は4コンテナで、起動直後のメモリは合計約1.8GiB、初回は検索エンジンの起動待ちで本体が上がらないことがありました。日本語は分かち書きで検索できますが、「PC」と「パソコン」のような言い換えは拾いません。メモリを抑えたいならWiki.js 2も候補で、検索エンジンを持たない2コンテナ構成ではPostgreSQL込み0.3GiB未満でした（公式要件はLinuxで1GB以上のRAM）。

wikiで何を解決するかの上流の整理はナレッジマネジメントの意味とSECIモデル、属人化を解く導入手順で扱っています。

社内wikiの作り方6ステップ：目的決めから全社展開までの手順

方式がクラウドでもOSSでも、作る順番は同じです。ツールを先に決めると、載せる情報と権限の設計が後追いになります。

ステップ1：導入目的と初期対象業務の選定

「全社の知識を集める」は目的になりません。「新人が同じ質問を先輩に繰り返す」「経費精算の手順が人によって違う」のように、困りごとを1つ選び、その業務で繰り返し参照する手順書を、初期公開するページの中心にします。成果は問い合わせ件数やオンボーディング期間で測り、問い合わせ台帳（Excelで足ります）に受付日・質問分類・対応時間を残して、導入前と試験運用中を同じ長さの期間で比べます。

ステップ2：構築方式とツールの選定

方式は後述の4つから、保守体制、データの配置条件、業務システムとの連携要件で選びます。GROWIのセルフホストを候補にするなら、MongoDBとElasticsearchの更新・復旧を誰が担当するかまで選定表に記入します。クラウド型ツールの料金と無料枠、書き手の人数から候補を絞る比較は社内wikiのおすすめツール比較｜選定軸とSaaS・OSS・自社開発の判断基準にまとめました。

ステップ3：初期移行するナレッジの棚卸し

公開前に、業務マニュアル・就業規則などの社内規程・よくある質問と回答・議事録の4種類を共有フォルダやチャットから集め、ステップ1で選んだ業務の分だけ先に移しておきます。更新が止まった文書は担当者が有効性を確認し、現行資料、参照用アーカイブ、廃棄候補に分けます。移行台帳には元ファイルの場所・文書責任者・最終確認日・移行先ページを記録します。

ステップ4：上位2階層の設計とテンプレートの準備

全社共通で設計する範囲は「部門／目的」の上位2階層とし、3階層目以降は各部門の書き手が整理します。精密な分類木は、書く場所に迷う時間を増やし、管理者の異動で崩れます。浅い階層で置き場所を決め、探すのは検索に任せます。

テンプレートは議事録・手順書・障害対応記録・オンボーディング資料の4種類を最初に用意します。書式が決まっていれば書き手は中身だけ考えればよく、手順書と障害記録は担当者の頭の中にしかない知識を文書に出す装置になります。業務が個人に依存する構造の崩し方は属人化の原因と脱属人化を進める仕組み化・標準化の実務、設計判断の経緯を残す書式はデザインドック（Design Doc）の書き方とテンプレートが参考になります。

ステップ5：閲覧・編集権限とログイン方法（SSO）の設計

権限は「閲覧も編集も全社員に開け、絞るのは人事・経理などの機密領域だけ」を既定にします。そのうえで、一般的なノウハウは承認なしで投稿でき、社内規程や公式手順のように正確性の確認が要る文書だけ責任者の承認を通す、と文書の役割で分けます。

ログインはwiki専用のIDを発行せず、Microsoft Entra IDやGoogle Workspaceなど既存のID基盤とSAMLやOIDCでつなぎます。退職時はID基盤でアカウントを停止し、wiki側の既存セッションや別の認証経路も無効化できているか確認します。GROWI v8.0.7のソースでは、ローカル認証のほかLDAP・SAML・OIDC・Google・GitHubの各認証方式が実装されています。

ステップ6：1部門での試験運用と全社展開の判断

全社一斉に公開せず、ステップ1の業務を持つ1部門で1か月使います。見るのは閲覧数より「探して見つからなかった語」と「書いた人の数」です。見つからなかった語はMicrosoft Teamsなどの専用チャネルに検索語・探していた情報・検索日を報告してもらい、言い換えの併記かページの新規作成で埋め、書いた人が数人に偏っていればテンプレートと権限を見直してから対象を広げます。運用に入ってから形骸化する要因と立て直し方は社内wikiが失敗する五つの原因とメリットを取り戻す運用設計で扱っています。

社内wikiを作る4つの方式：クラウド・OSS・スクラッチ・既存ツール流用の比較

ステップ2で選ぶ方式の費用と保守の担い手は次のとおりです。費用は契約プラン、利用人数、移行支援の有無、開発・保守の範囲によって異なり、自社の見積もりの代わりにはなりません。

クラウド型はすぐ始められる反面、データの置き場所はベンダーのクラウドに固定され、権限や画面もプランの範囲でしか変えられません。OSSはライセンス費用がかからず、データを自社の管理下に置けますが、表の「保守人件費」が金額に出ない費目です。月2時間の更新確認でも担当者の時間単価を掛ければ年数万円分になり、ソフトウェアが無償でも総コストが安いとは限りません。サーバー代と運用工数を月額に換算した比較は社内wikiを無料で作る三つの型｜SaaS無料枠・OSS自前運用・有料移行の分岐点にあります。

SharePoint・OneNote・Googleサイトで作る場合の限界

Microsoft 365でSharePointを含むプランを契約していればSharePointのページを、OneNoteを利用できる環境なら共有ノートを使えます。Google WorkspaceならGoogleサイトで、追加費用なしに始められます。小さな部署の手順共有なら十分です。SharePointのモダンページには版の履歴と変更箇所の比較もあります（Microsoftサポート）。課題になりやすいのは機能より運用で、ページと共有ファイルが同じ場所に混在して置き場所の決まりが崩れることと、全員が書ける権限を別に設計しなければならないことです。流用する場合も、ステップ4・5の階層と権限の設計は省けません。

OSSによる社内wiki構築：GROWI v8とWiki.jsのDocker Compose起動手順

OSS方式を選んだ場合の構築手順です。2026年10月18日に、macOS（Intel）上のcolima（x86_64の仮想マシン・4CPU・メモリ6GiB）とDocker Engine 29.5.2で、両製品の公式手順どおりに起動して測りました。

GROWI v8の動作要件とv7からの変更点

GROWIは日本で開発されているwiki専用のOSSです。2026年7月27日にv8.0.0が出て、10月7日のv8.0.7が最新です（GitHubのリリース一覧）。開発元のGitHub組織はweseekからgrowilabsに変わりました。旧リポジトリのURLは新しいURLへ転送されますが、Docker Hubの旧イメージ（weseek/growi）は2026年1月の7.4で更新が止まっており、v8はgrowilabs/growiで配布されています。

v8では、MongoDBをレプリカセット構成で動かすことが必須になりました。新機能のGROWI Vault（ページをGitリポジトリとして取得する機能）がMongoDBのchange streamを使うためで、単一ノードのレプリカセットでも動きます。全文検索に使うElasticsearchは8系と9系だけの対応になり、7系のままでは検索の初期化に失敗します（GROWI v8.0.x へのアップグレード）。Dockerを使わずUbuntuへ直接入れる場合の要件は、Node.js 24.x、MongoDB 6.0以上（レプリカセット必須）、任意でElasticsearch 8.xか9.xです。

GROWI v8をDocker Composeで起動する手順と実測値

公式のgrowi-docker-composeは、GROWI本体（growilabs/growi:8）、MongoDB 8.2、Elasticsearch 9.3.3、PDF出力用のpdf-converterの4コンテナ構成です。Elasticsearchには日本語形態素解析のanalysis-kuromojiと文字正規化のanalysis-icuが、起動時に自動で入ります。手順は次のとおりです。

git clone https://github.com/growilabs/growi-docker-compose.git growi
cd growi
# docker-compose.yml の app.environment を2か所直す
#   PASSWORD_SEED=changeme      -> 推測されない長い文字列に変える
#   # - FILE_UPLOAD=mongodb     -> 先頭の # を外す（既定は添付ファイルをAWSに置く前提）
docker compose up -d
docker compose ps
# elasticsearch のログを確認し、起動完了後に healthy になってから再実行する
docker compose up -d
# http://localhost:3000 を開くと /installer に転送され、管理者を作成する

実測では、初回の docker compose up -d はエラーで止まりました。Elasticsearchが起動のたびにプラグインを取得するため、コンテナ起動から待ち受け開始まで77秒かかり、composeに書かれたヘルスチェック（10秒間隔で6回）の猶予を超えたためです。GROWI本体はElasticsearchの正常判定を待つ設定なので、作成されたまま起動しません。2回目の実行では本体が29秒で応答し、初期設定画面に転送されました。メモリ不足や設定の誤りでも同じ状態になるので、構築手順書には「docker compose logs elasticsearch で起動の進み具合を確かめ、プラグインの取得待ちなら再実行する」と書いておきます。

Elasticsearchのヒープは既定の256MBのままでも、プロセス全体では1GiB近く使います。この測定はページがほぼ空の状態です。本番容量は、メモリ4GB・ディスク20GBを検討の出発点とし、同時利用者数、添付ファイル量、検索インデックスとバックアップの容量を加味して負荷試験で決めます。pdf-converterを止めてGROWI本体を再起動しても、ページ表示と検索は問題なく動きました。ページの一括エクスポートでPDFを使わないなら、このコンテナを外して約0.4GiB減らせます。公開前には、リバースプロキシでのTLS化と、MongoDBのバックアップを別サーバーへ戻せるかの確認を済ませます（公式のexamplesにHTTPS化とバックアップの構成例があります）。プラグインで機能を足す場合はGROWIプラグインの3種類の違いと導入手順を参照してください。

Wiki.js 2をPostgreSQLと一緒に起動する手順と実測値

Wiki.jsはNode.js製のwikiです。2026年8月に、本番向けの2系は保守用の別リポジトリrequarks/wiki-v2へ移り、最新は10月2日のv2.5.316です。Node.jsは公式要件に記載された22系または24系を使います。元のrequarks/wikiは3.0の開発用になっており、10月16日の3.0.0-beta.672にも「本番利用は不可」と明記されています。旧リポジトリの「最新リリース」は3.0のベータ版を指すので、取り違えに注意してください。

データベースは2系ならPostgreSQL・MySQL・MariaDB・SQL Server・SQLiteに対応しますが、公式の要件文書では3系への移行時にPostgreSQL以外のサポートを終えるとしています。今からPostgreSQLを選べば、3系への移行に伴うデータベース製品の変更を避けられます。ただし、データ移行や設定変更の要否は別途確認が必要です。

GROWIとは別の空のディレクトリを作り、次の内容を compose.yaml として保存します。データベースの準備が終わってからWiki.jsが起動するよう、PostgreSQLにヘルスチェックを付けています。ホスト側のポートはGROWIの3000番と重ならないよう3001番にしました。

services:
  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_USER: wikijs
      POSTGRES_PASSWORD: 長いパスワードに変える
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U wikijs -d wiki"]
      interval: 5s
      timeout: 5s
      retries: 10
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
  wiki:
    image: ghcr.io/requarks/wiki:2
    depends_on:
      db:
        condition: service_healthy
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: 長いパスワードに変える
      DB_NAME: wiki
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3000"
volumes:
  db-data:

この構成を docker compose up -d で起動すると、イメージの取得込みで59秒、取得後7秒でセットアップ画面が応答しました（ヘルスチェック付きの上の構成で作り直した場合は14秒）。初期設定を済ませた後のメモリはWiki.jsが約150〜230MiB、PostgreSQLが約35〜45MiBでした。イメージ容量もWiki.jsが1.03GB、PostgreSQL（alpine版）が424MBに収まります。本番では :2 のような浮動タグでなく版番号を固定し、更新は差分を確かめてから行います。

今回確認した標準設定の制約は、本文中の語が検索結果に出ない点です。標準の検索エンジン（Database - Basic）のまま、タイトル「経費精算の手順」・本文「PCや備品の立替精算は、月末までに申請します。」のページを作って検索したところ、タイトルにある「精算」「経費精算」はヒットし、本文にしかない「立替」「PC」「申請」は0件でした。管理画面でPostgreSQLの検索へ切り替える場合は、既存のPostgreSQLを使い、pg_trgm拡張の有効化とインデックスの再構築を確認します。Elasticsearchへ切り替える場合は、別途検索サーバーの構築・保守が必要です。日本語の全文検索を最初から重視するならGROWI、メモリを抑えて小さく始めたいならWiki.js、という分け方になります。

DokuWiki・MediaWikiなど他のOSS候補を選ぶ4つの観点

DokuWikiはPHP製で、データベースを使わずページをテキストファイルで持つため、共用サーバーでも動きます。最新安定版は2026年7月14日公開の「Mort」系で、9月2日の修正版2026-07-14cが出ています（GitHubのリリース一覧）。この版はPHP 8.2以上が必要です。Wikipediaと同じMediaWikiは長期サポート版の1.43系が2027年12月まで保守され、大規模運用の実績もありますが、独自の記法と管理画面の癖があり、IT部門以外も書く社内wikiでは勧めにくい選択です。候補は次の4点で絞ります。

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

開発チームのドキュメントなら、構成・API仕様のようにコードに由来する知識はGitHubのコードをローカルでWiki化するDeepWiki-Openのような自動生成に寄せ、決定の経緯や障害対応記録のようにコードに書かれない知識だけを手書きのwikiに残す二本立てが、更新を止めにくい分け方です。

日本語検索の設計：GROWIの分かち書きと同義語の実測

探しても見つからないwikiは使われなくなります。GROWI v8が作る検索インデックスを確かめたところ、本文には日本語用の解析器（文字の正規化にicu_normalizer、分割にkuromoji_tokenizer）が設定されていました。実際にElasticsearchへ問い合わせた結果は次のとおりです。

docker compose exec elasticsearch curl -s -H 'Content-Type: application/json' \
  'localhost:9200/growi/_analyze' -d '{"field":"body.ja","text":"経費精算の手順書"}'
# 結果のトークン: 経費 / 精算 / の / 手順 / 書
# 「ＰＣの貸与申請」 -> pc / の / 貸与 / 申請（全角英字は半角小文字にそろう）
# 「ｹｲﾋｾｲｻﾝ」       -> ケイヒセイサン（半角カナは全角にそろう）

次に「PCや備品の立替精算は、月末までに申請します。」という1行を含むページを作って検索すると、「精算」「経費精算」「立替」「ＰＣ」はヒットし、「パソコン」は0件でした。全角・半角のゆれは吸収されますが、言い換えは拾いません。既定の検索インデックスには同義語の設定が入っていないためです。

そこで運用で埋めます。利用者から「見つからなかった語」を集めて月に1回見直し、「PC／パソコン／端末」「経費精算／立替精算」のような自社の言い換えを、該当ページの本文やタグに併記します。Elasticsearchに同義語辞書を足す方法もありますが、GROWIの更新でインデックスを作り直すたびに設定が残るか確かめる手間が増えるので、まずはページ側の併記から始めます。

スクラッチ開発・業務アプリ統合へ切り替える判断と費用の分岐点

wikiをゼロから開発する場合は、ページ作成・編集履歴・全文検索・権限管理に加え、認証、移行、テストの範囲を定めて開発工数を見積もります。月額3万円が5年間変わらない仮定では、利用料の合計は180万円です。自社開発と比べる際は、双方の導入・移行・保守費も加えます。汎用のwikiが欲しいだけなら既製品にある機能を一から作り直すことになるので、まずクラウド型かOSSで要件を満たせないかを確かめます。

分岐点が動くのは、wikiが業務アプリの一部になるときです。ナレッジの蓄積に加えて、申請・承認のワークフロー、案件情報や顧客マスタとの連動、現場からのスマホ入力までを1つの画面で扱うなら、複数のSaaSを連携させるより統合した業務アプリを開発するほうが、総コストと運用の複雑さを抑えられる場合があります。前提は、連携対象・権限モデル・データの流れを文書に書けるところまで要件を具体化することです。「将来つなぐかもしれない」段階ならクラウド型で始めます。要件が固まっているなら、業務用・Webアプリ開発でナレッジ共有を含む業務アプリの要件定義から運用まで相談できます。社内の入口側の構築は社内ポータルサイトの機能・作り方・要件定義と内製外注の判断基準で扱っています。

社内wikiを自作してよい条件と見送るべき場面

OSSで自作してよい4つの条件

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

• Linuxとコンテナの保守（月1回の版の確認・セキュリティ更新・障害の一次対応）を担える技術者が2名以上いる
• データを自社管理下（オンプレミスや自社契約のクラウド）に置く要件が文書になっている
• GROWIならElasticsearchまで含めて構築する前提で工数を見積もっている（検索なしのwikiを作らない）
• バックアップを別環境に戻す手順を、全社公開の前に実際に試す計画がある

技術者を2名以上とするのは、担当者の異動・退職時にも保守を引き継げる体制を勧めるためです。1人しか触れないサーバーは、その人がいなくなると「誰も更新できないが止められない」資産に変わります。GROWI v8のようにメジャー版でMongoDBの構成変更が必須になる更新も来るので、構築手順そのものをwikiの最初のページとして書き、もう1人がそれだけを見て再構築できるかを試してください。

自作を見送るべき3つの場面

第一に、保守の担当と引き継ぎ体制を決められない場合です。更新や障害対応の責任が曖昧になるため、自作は見送ります。第二に、「まず情報共有の効果を確かめたい」段階の場合です。既にSharePointを契約しているなら、対象業務の手順ページを作って1〜2か月試し、検索で解決できた質問と追加が必要だった文書を記録します。新規契約する場合は、無料枠や試用期間が試験計画に合うかを確認します。第三に、費用削減だけが動機の場合です。構築・保守の人件費を含む総コストをクラウド型の利用料と比べ、削減額が運用負担に見合わなければ見送ります。どの方式でも、浮いた費用はテンプレートの整備、見つからなかった語の拾い上げ、更新が止まった領域の担当者の割り当て直しに回します。

よくある質問

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

ソフトウェアの費用だけならゼロにできます。GROWI・Wiki.js・DokuWikiはライセンス費用なしで使え、人数制限付きの無料プランを持つクラウド型ツールもあります。ただしOSSはサーバー費と、構築・保守にあたる担当者の人件費が必ずかかります。GROWIの公式構成は起動直後で約1.8GiBのメモリを使ったため、メモリ1GB程度の最小プランのサーバーでは足りません。

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

作れます。既存の契約にSharePointが含まれていればページを、OneNoteを利用できる環境なら共有ノートを使って始められ、小さな部署の手順共有には十分です。ExcelはOneDriveやSharePointに保存し、対応する形式とアプリを使えば共同編集できます。ただし、複数ブックに分散した知識の整理や検索は別途設計が必要で、全社のナレッジ基盤に育てるならwiki専用の仕組みが向きます。

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

社内wikiは全員が書き込んで知識をためる場、社内ポータルは会社からの通知や各システムへの入口を集める場です。SharePointの社内ポータルからGROWIの手順書へリンクする形なら、入口の集約と知識の共同編集を役割分担でき、両者は併用できます。

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

今回の検証では、Docker環境を用意した後の起動と初期設定は当日中に終わり、画面が開くまではGROWIが2回目の起動から29秒、Wiki.jsが掲載した構成で14秒でした。本番では認証連携・公開設定・復旧確認の時間が別に要ります。期間を決めるのは設計と移行で、階層・テンプレート・権限の設計に1〜2週間、ナレッジの棚卸しと初期移行に数週間、1部門での試験運用に1か月を見込みます。

自分用の個人wikiを作ることはできますか？

できます。Wiki.jsは自分のパソコン上のDockerでも動き、今回の検証ではPostgreSQL込みで0.3GiB未満でした（公式要件はLinuxで1GB以上のRAM）。ただし個人用ならサーバーを立てるより、Markdownファイルをフォルダで管理してエディタで開くほうが手間がかかりません。チームで共有し始めた段階で、権限と検索のあるwikiへ移すのが無駄のない順番です。

関連記事

• ナレッジマネジメントとは？意味とSECIモデル、属人化を解く導入手順を解説
• 社内wikiのおすすめツール比較｜選定軸とSaaS・OSS・自社開発の判断基準
• 社内wikiを無料で作る三つの型｜SaaS無料枠・OSS自前運用・有料移行の分岐点
• 社内wikiが失敗する五つの原因とメリットを取り戻す運用設計｜形骸化からの立て直し基準
• 社内ポータルサイトとは？機能・作り方・要件定義と内製外注の判断基準