社内wikiのおすすめツール比較｜選定軸とSaaS・OSS・自社開発の判断基準

社内wikiのツールを比べ始めると、どの比較記事も同じ顔ぶれが並び、機能欄はほとんど埋まっていて差が読めません。実際に選定で詰まる理由は機能表ではなく、「閲覧だけの社員が何人いるか」「検索に何を期待するか」「基幹システムの数字と結び付けたいか」という3つの前提を先に決めていないところにあります。本記事では、社内wikiとして名前の挙がる7つのツールを料金と無料枠と向く組織条件で並べ、選定軸を5項目に絞り、無料プランとOSSで足りる範囲、そしてSaaSでは届かず自社開発に切り替える条件までを、受託開発会社の目線で整理しました。ナレッジをためる仕組みそのものの考え方はナレッジマネジメントの意味とSECIモデルから導入手順まで整理した記事に譲り、ここではツール選定の判断に絞ります。

まとめ：社内wikiのおすすめは人数と書き手の比率で決まる

• 書き手が5人以下なら、Kibelaのコミュニティプラン（5ユーザーまで無料）かNotionのフリープランで費用をかけずに始められます。
• 閲覧だけの社員が書き手の3倍以上いる組織はNotePMが安く付きます。作成者8人の枠に閲覧者24人が追加費用なしで載る料金設計だからです。
• 書き手が全員エンジニアで、Markdownと日報文化に慣れているならesaが1ユーザー月500円（税込）で軽く回ります。
• 課題管理をJiraで回している開発組織はConfluenceに寄せると導線が短くなります。無料プランは10ユーザーまでです。
• 自前でサーバーを運ぶ担当がいるならGROWIをセルフホストできます。ライセンス費はゼロですが、月あたり数時間の運用工数は必ず発生します。
• ツール選定より先に決めるのは、対象範囲（手順書だけか議事録も入れるか）と書き手の人数です。ここが曖昧なまま比較しても結論は出ません。
• 基幹システムの実データを見ながら書く運用になった時点で、SaaSの社内wikiは限界に達します。ここが自社開発へ切り替える分岐点です。

社内wikiツールを比べる前に決める対象範囲と書き手と検索の期待値

比較表を眺める前に、社内で3つの合意を取っておくと候補が半分に減ります。逆に、この合意がないまま試用を始めると、無料期間の1か月を「誰も書かないまま」使い切ることになります。導入して形骸化した社内wikiの多くは、機能不足ではなく前提の未決着が原因でした。

社内wikiで扱う情報の範囲｜手順書と議事録とFAQを一つに寄せるか

社内wikiに入れる情報は、大きく手順書・議事録・FAQ・仕様書という4種類が中心です。全部を1つのツールに寄せるか、種類ごとに置き場を分けるかで必要な機能が変わります。手順書だけならテンプレート機能と更新履歴で足り、議事録まで入れるなら量が増えるので検索とタグ設計が効いてきます。

顧客対応の想定問答まで含めると、社内wikiではなくFAQ基盤の要件に近づきます。応対品質の担保まで踏み込む場合の設計はコールセンターのナレッジ管理をFAQ集約の観点でまとめた記事で扱いました。社内wikiとFAQ基盤を分けるか統合するかの判断を含め、ナレッジ管理ツール全体の4タイプ分類はナレッジ管理ツールをタイプ別に比較した記事にまとめてあります。

書き手が何人いるかで候補が変わる｜編集者課金と全員課金の料金差

社内wikiの料金体系は、全員を頭数で数える方式と、書く人だけを数える方式の2つに分かれます。100人の会社で書き手が10人しかいない場合、全員課金では10倍の費用がかかる計算になり、この差は年間で数十万円規模になります。

先に社内を「書く人」「読むだけの人」で数えてください。編集者と閲覧者の比が1対3を超えるなら、閲覧者を安く載せられる料金設計のツールが有利に働きます。比率が1対1に近い開発チームのような組織では、1ユーザー単価の安いツールを素直に選んだほうが総額は下がります。

検索に何を期待するか｜全文検索で足りる範囲とAI回答が要る範囲

記事が300本を超えたあたりから、社内wikiは「探せない置き場」に変わり始めます。全文検索で十分なのは、書き手が用語をそろえて書いている場合だけです。部署ごとに呼び名が違う（受注番号／注文No／オーダーID）状態では、全文検索は空振りします。

AIによる質問応答を各社が載せてきていますが、元の文書が古ければ古い答えが返るだけです。検索体験を先に買うより、棚卸しの運用を先に決めたほうが投資対効果は高くなります。AI回答が要るのは、対象文書が数千本規模で、しかも文書の鮮度を保つ担当が置ける組織だと考えてください。

おすすめ社内wikiツール7選の比較｜料金と無料枠と向く組織規模の違い

社内wikiとして名前の挙がる代表的な7つを、料金の起点と向く条件で並べます。金額は2026年7月31日時点で各社の公式ページに掲載されている内容で、税の扱いは各社の表記に従いました。プラン改定は珍しくないため、最終確認は必ず公式ページで行ってください。

日本語圏の定番3つ｜NotePM・DocBase・esaが向く組織の条件

NotePMは閲覧者の扱いが独特で、作成者8人のプランに閲覧者が24人まで追加費用なしで載ります。初期費用とサポート費用は0円、ストレージは最小プランで80GB、無料トライアルは30日という構成です。営業所や工場を含めて全社に読ませたいが、書くのは本社の数人という会社では、この設計が効きます。

DocBaseは1人550円（税込）のパーソナルから、3人1,320円、10人4,950円、30人11,000円と人数枠で段が上がります。少人数で始めて部署単位に広げる場合、次の段までの費用が読みやすいのが利点です。細かい人数調整はできないため、11人目が入った瞬間に上の段へ移る点は織り込んでおいてください。

esaは1ユーザー月500円（税込）で、書きかけを共有する「WIP」の考え方が仕組みに組み込まれています。完成した文書しか置けない空気になると社内wikiは止まりますから、書きかけを歓迎する文化を作りたい開発チームには合います。試用はチーム作成から2か月後の月末までと長く、定着するかどうかを見極める時間が取れる設計です。

NotionとConfluenceを社内wikiに使うときの得手と不得手

Notionはフリープランが0円、有料のプラスが1ユーザー月1,650円、ビジネスが3,150円（月払い）で、年払いにすると最大20%引きになります。文書とデータベースを同じ画面で持てるため、手順書と案件一覧を1か所に置きたい組織には強い選択肢です。一方で自由度が高いぶん、設計を決めずに配ると各人がページを作り散らかし、半年で迷子になります。

Confluenceは無料プランが10ユーザーまでで、それを超えると人数に応じた課金へ移ります。単価は人数帯によって変わる仕組みのため、見積は公式の料金計算で確認してください。開発課題をJiraで管理している組織なら、課題から仕様書へ一往復で飛べる導線が手に入ります。逆に開発部門以外が主役の社内wikiでは、機能の重さが書き手の負担になりがちです。

GROWIなどOSS系を選ぶ前提｜自前で運ぶ手間と得られる自由度

GROWIはMITライセンスのOSSとしてGitHubで公開されており、Docker Composeを使ったセルフホストに対応しています。ライセンス費用はかからないため、人数が増えても課金は増えません。300人規模で全員に書かせたい組織では、SaaSとの費用差が年間で百万円単位になることもあります。

ただし無償なのはライセンスだけです。サーバー費用、バックアップ、バージョン追随、障害時の一次対応は自社が持ちます。マネージドのGROWI.cloudは最小プランが月額8,000円（30ユーザー・2アプリ）で、自前運用とSaaSの中間に位置します。運用担当を置けないなら、OSSを選んだ結果として更新が止まり、脆弱性を抱えたまま動き続ける事態になりかねません。

社内wikiの選定軸5項目｜検索・権限・エディタ・連携・移行のしやすさ

機能表の項目をすべて比べても差は出ません。実際に運用が割れるのは次の5つです。試用期間には、この5点だけを自社の実データで試してください。

検索精度と情報設計の軸｜階層フォルダとタグのどちらで迷子を防ぐか

情報の整理方式は、階層フォルダ型とタグ型に分かれます。階層型は「部署→業務→手順」のように物理的な置き場が決まるので、書く側は迷いません。ただし部署をまたぐ手順書の置き場でもめます。タグ型は横断で拾えますが、タグ命名の統制が効かないと似たタグが増えて機能しなくなります。

選定の見極め方は単純で、自社の既存文書を30本ほど試用環境に入れ、他部署の社員に「有給の申請方法」のような曖昧な言葉で探させてみることです。3クリック以内に届かなければ、その情報設計は自社に合っていません。

権限設計とエディタの軸｜見せない範囲の作り方と書く負荷の下げ方

権限で確認するのは、閲覧・編集・管理の3階層をグループ単位で切れるかどうかです。人事情報や役員議事録を同じツールに置くなら、記事単位ではなくグループ単位で閉じられる設計が要ります。記事ごとに権限を付ける運用は、設定漏れが必ず起きるため避けてください。

エディタは、書き手の職種で選び分けるのが基本です。エンジニア主体ならMarkdown対応が書く速度を上げ、営業や管理部門が主体ならリッチテキストと表の貼り付けやすさが効きます。書く負荷が高いツールは、どれだけ機能が揃っていても更新されなくなります。

外部連携と移行のしやすさ｜Markdown書き出しの有無を先に見る

外部連携は、まずチャットへの通知を見てください。新しい記事や更新がSlackやTeamsに流れないと、書いても読まれない状態になります。次にシングルサインオン（SAML／OIDC）の対応です。100人を超える組織で個別IDを配ると、退職時の権限剥がしが漏れます。

そして見落とされがちなのが、出ていくときの手段です。全記事をMarkdownやHTMLで一括書き出しできるかを、契約前に必ず確かめてください。書き出せないツールに5年ぶんの手順書を貯めると、乗り換えの費用が非現実的な水準まで膨らみます。移行のしやすさは、入るときにしか確認できない項目です。

無料プランとOSSで始める選択肢と、有料へ切り替える判断の分岐点

費用ゼロで始める道は2つあります。SaaSの無料プランを使う道と、OSSを自前で運ぶ道です。どちらも一定規模までは十分に回りますが、割れ方は違います。

無料プランで回せる規模の目安｜5〜10人までなら費用ゼロで足りる

Kibelaのコミュニティプランは5ユーザーまで無料、Confluenceの無料プランは10ユーザーまで、Notionのフリープランは人数の上限なく個人利用の範囲で使えます。10人以下のチームで手順書を数十本ためるだけなら、無料プランで実務は回ります。

無料で始める場合も、情報設計とテンプレートは有料と同じ密度で作ってください。無料だから雑に始めてよいわけではなく、後から構造を直す手間のほうが高く付きます。半年運用して定着したら有料へ移す、という段取りが現実的です。

OSSをセルフホストする実費｜サーバー代と運用工数を月額換算する

GROWIのようなOSSを自前で運ぶ場合、クラウドの小型インスタンスとデータベースで月数千円から1万円台、これにバックアップ領域が乗ります。見落とされるのは人件費のほうで、バージョン追随と障害対応に月2〜4時間を見ておくと、人月単価から逆算した実費はSaaSと大差ない水準に着地します。

それでもOSSを選ぶ理由になるのは、人数が多い場合と、社外に出せない情報を扱う場合です。構築手順と権限・検索の設計、そしてスクラッチ開発との分かれ目は社内wikiの作り方をOSS構築の手順から解説した記事で実装者向けにまとめました。手を動かす前に、運用の担当者を1人決めておいてください。

有料へ切り替える三つの兆候｜検索・権限・監査で無料枠が割れる

無料から有料へ移る合図は3つあります。1つ目は検索で、記事が200〜300本を超えると絞り込み条件の弱さが表面化します。2つ目は権限で、閲覧範囲を分けたい部署が出てきた時点で無料枠の設計では足りません。

3つ目は監査で、誰がいつ何を見たかの記録を求められる段階に入ると、上位プランの機能が必要になります。ISMSやPマークの更新審査で指摘を受けてから慌てて移行する例が多いため、審査の予定がある会社は先に有料プランの機能一覧を確認しておくと安全です。

SaaSで足りない社内wikiを自社開発に切り替える条件と見送る場面

ここが本記事でいちばん言い切っておきたい部分です。社内wikiは基本的にSaaSで足ります。それでも自社開発が正解になる場面は確かにあり、その線引きは「文書を貯めるだけか、業務データと結び付くか」の一点で決まります。

自社開発を選ぶ条件｜基幹データと結び付けて初めて読まれる場合

自社開発に踏み込む価値があるのは、社内wikiの記事が単体では意味を持たず、基幹システムの実データと並んで初めて機能する場合です。たとえば製品ごとの作業手順に、その製品の在庫状況や過去の不具合履歴が同じ画面に出る形。あるいは顧客ごとの対応方針に、その顧客の契約情報と請求状況が連動する形。SaaSの社内wikiで同じことをやろうとすると、担当者が2つの画面を行き来して転記する運用になり、結局は転記漏れで信用を失います。

もう1つの条件は、既存の業務システムに検索窓を1つ増やすだけで済む場合です。現場が毎日開く画面の中に手順書が出るなら、社内wikiを別に立てるより定着します。この形の実装は業務用・Webアプリ開発の範囲で、既存システムの認証と権限をそのまま引き継げるのが強みです。逆に言えば、この2つの条件に当てはまらないなら自社開発は見送るべきです。

自社開発を見送る場面｜文書を貯めるだけならSaaSが安く速い

手順書と議事録を貯めて検索できればよい、という要件で自社開発を検討するのは筋が悪い判断です。SaaSが月数千円から提供している機能を作ると、初期で数百万円、加えて保守が毎年乗ります。エディタ、検索、権限、通知、バージョン管理を自前で作り切るのは、見た目より重い仕事です。

「既存ツールに欲しい機能が1つ足りない」という理由も、自社開発の根拠としては弱いところがあります。その1機能のために、他の20機能を自分で保守する取引になるからです。要望を要件表に書き出し、SaaSで満たせない項目が全体の2割を超えるかどうかを数えてから判断してください。

折衷案としての連携開発｜SaaSを残して不足分だけ自前で作る

実務でよく落ち着くのは中間の形です。文書の置き場と編集はSaaSに任せ、APIで記事を引き出して基幹システムの画面に埋め込む。あるいは基幹システム側の変更を検知して、該当する手順書に更新の合図を立てる。作るのは連携部分だけなので、初期費用は全面開発の数分の一に収まります。

この形を取る場合、選定の段階でAPIの有無と取得できる範囲を確認しておく必要があります。記事本文と更新日時とタグを外から取れるかどうかは、ツールによって差があります。将来の連携を見込むなら、比較表の機能欄よりAPIドキュメントを先に読んでください。

導入後に更新が止まらない運用設計｜書き手・レビュー・棚卸しの回し方

社内wikiが失敗する原因は、ほぼ運用側にあります。ツールを入れた月がいちばん記事数が伸び、3か月後に更新が止まる。この曲線を折るための仕掛けは、導入前に決めておくものです。

書き手を絞って型を配る運用｜テンプレートで書く負荷を先に下げる

全社員に「書いてください」と号令をかけると、誰も書きません。最初は部署ごとに書き手を1〜2人指名し、その人の評価項目に含めるところまでやります。書く人が決まったら、次はテンプレートです。目的・対象者・手順・注意点・更新日という枠を先に配るだけで、白紙から書く負荷は大きく下がります。

情報を出す側にとっての利点を作る設計は、社内wikiに限らず共通します。組織として仕組み化する進め方は情報共有がうまくいかない原因と仕組み化を整理した記事にまとめました。書き手が「聞かれる回数が減った」と実感できるまでが最初の山です。

レビューと棚卸しの回し方｜古い記事を落として検索の精度を保つ

記事は増えるほど価値が下がる時期が来ます。古い手順書が検索の上位に出て、新人がその通りに作業して事故る。これを防ぐには、半年ごとの棚卸しを回すしかありません。更新日が半年を超えた記事に自動で印を付け、担当者が「現行」「改訂」「廃止」の3つに仕分けます。

廃止した記事は削除ではなくアーカイブに移し、検索対象から外す扱いが安全です。過去の判断根拠として参照したい場面があるからで、消してしまうと同じ議論を最初からやり直すことになります。

定着したかを測る指標の置き方｜検索件数と問い合わせ件数で見る

記事数を目標にすると、中身の薄い記事が量産されます。見るべきは2つで、1つは検索が実行された回数、もう1つは同じ内容の問い合わせが減ったかどうかです。社内チャットで「これどうやるんでしたっけ」が飛ぶ回数を月次で数えるだけでも、傾向はつかめます。

検索されたのに結果が0件だった語も記録してください。そこに書かれていない情報の需要が現れます。0件の語を毎月3つ拾って記事にする運用を1年回すと、社内wikiは「聞くより探したほうが速い」場所に変わります。

よくある質問

社内wikiとナレッジ管理ツールは何が違いますか？

社内wikiは社員が自分で書いて編集する文書の置き場を指し、ナレッジ管理ツールはFAQ型や文書管理型を含む上位の分類です。社内wikiは4タイプのうちの1つと考えてください。顧客対応の想定問答が中心ならFAQ型、契約書や図面の版管理が中心なら文書管理型のほうが要件に合います。

無料の社内wikiツールだけで運用を続けられますか？

10人以下で、権限を分ける必要がなく、記事が200本程度までなら運用を続けられる範囲です。それを超えると検索の弱さと権限設計で行き詰まります。OSSをセルフホストする道もありますが、サーバー費用と月2〜4時間の運用工数が発生するため、実費はSaaSの有料プランと大きく変わらない水準に落ち着きます。

社内wikiを入れたのに誰も書かない状態はどう直しますか？

原因は書く負荷か、書く動機のどちらかです。負荷側はテンプレートの配布と書きかけの公開を許す運用で下げます。動機側は、書き手を部署ごとに指名して評価に含めるのが確実です。全社に号令をかける方式は、ほぼ機能しません。

NotionとNotePMはどちらを選ぶべきですか？

読むだけの社員が多い会社ならNotePMが安く付きます。作成者8人のプランに閲覧者24人が追加費用なしで載る設計だからです。逆に、文書と案件一覧やタスク管理を同じ場所で持ちたい、書き手と読み手の比率が近い、という組織ならNotionが向きます。

社内wikiを自社開発すべきかはどう判断しますか？

基幹システムの実データと同じ画面で読ませる必要があるか、既存の業務システムに検索窓を足すだけで済むか。この2つのどちらかに当てはまるなら自社開発の検討に値します。文書を貯めて検索するだけの要件であれば、SaaSのほうが安く速く確実です。

関連記事

• ナレッジマネジメントとは？意味とSECIモデル、属人化を解く導入手順を解説
• ナレッジ管理ツールの比較と選び方｜タイプ別の特徴・選定基準と自社開発の判断
• 社内wikiの作り方：OSS構築の手順と権限・検索設計、スクラッチ開発の判断基準
• 情報共有とは？目的とメリット、うまくいかない原因と仕組み化の進め方を解説
• コールセンターのナレッジ管理とは？属人化と離職を防ぐFAQ集約と応対品質の高め方