社内Wiki開発の発注/外注/依頼/委託方法について

社内Wikiの開発を発注・外注するときは、ツールを選ぶ前に目的と対象情報を整理し、SaaS導入・既存基盤活用・受託開発を比較して、運用まで含む要件と費用で委託先を決めることが重要です。

社内の資料が共有フォルダ、Excel、メール、チャット、個人のメモに分散していると、必要な情報を探す時間が増え、同じ質問への回答や新人教育が繰り返されます。この記事では、社内Wikiを発注・外注・委託する際の発注形態の選び方、RFPと要件の整理、契約形態、2026年時点の費用相場、委託先選定と見積比較のポイントを、実際の進め方に沿って解説します。

▼全体ガイドの記事
・社内Wiki開発の完全ガイド

社内Wikiの発注・外注では何を決めますか？

社内Wikiの発注で決める対象は、画面や検索機能だけではありません。どの情報を正本にするか、誰が更新するか、どの社員に何を見せるか、既存資料をどの順番で移すか、導入後の問い合わせや改善を誰が担うかまでを一つの業務基盤として定義します。

社内Wikiは、業務手順、規程、FAQ、議事録、過去案件の知見などをページとして蓄積し、検索・更新・共有できる仕組みです。共有フォルダにファイルを保存するだけの場合と違い、ページ単位で更新履歴、コメント、作成者、レビュー期限、閲覧権限を管理しやすい点が特徴です。発注時は「作れること」よりも、「必要な人が正しい情報を見つけ、現場で使い、担当者が更新できること」を成果として定義します。

「情報共有を改善する」という目的だけでは、提案内容も見積も比較できません。新人が手順を探す時間、同じ問い合わせへの回答件数、検索しても見つからない語句、期限内に更新されたページの割合、月間アクティブ利用者などを候補にします。例えば初期導入から3か月後に、対象部署の主要手順を社内Wikiで完結できる状態にする、検索結果が0件になる代表的な語句を毎月減らす、といった測定可能な条件にします。

社内Wikiの発注形態はどれを選びますか？

発注形態は、専用SaaSを契約して設定を依頼する方法、Microsoft 365やGoogle Workspaceなど既存基盤を活用する方法、パッケージを導入する方法、独自の社内Wikiを受託開発する方法に大きく分かれます。独自機能の多さではなく、業務要件、セキュリティ、導入期限、社内の運用力、将来の保守負担を並べて判断します。

NotePM、DocBase、Confluenceなどの専用SaaSは、ページ作成、全文検索、権限、履歴、通知といった基本機能が整っており、インフラの構築やバージョンアップを自社で抱えにくい選択肢です。発注先には、初期設定、スペースやカテゴリの設計、ユーザー登録、SSO設定、旧資料の移行、管理者研修、運用ルール作成を必要な範囲で依頼します。

ただし、SaaSは標準機能に業務を合わせる必要があります。独自の承認フローや複雑な業務データをページと一体で処理したい場合は、API連携や追加開発の可否を確認します。解約時のエクスポート形式、データ削除の手順、AI機能が参照する範囲も、契約前に確認しておくと移行時のロックインを抑えられます。

すでにMicrosoft 365やGoogle Workspaceを全社で利用している場合は、SharePoint、Sites、Docs、検索、Teams、Google Chatなどを組み合わせる方法があります。既存のアカウント、グループ、ストレージ、監査機能を活用しやすく、社員が新しいログイン方法を覚えずに済むことが利点です。一方で、情報設計や権限モデルの自由度が高いぶん、ページの正本、命名規則、公開範囲、検索対象を発注前に決める必要があります。

Google Workspaceの公式事例では、ソラストが導入決定から利用まで約1年をかけ、基盤構築は開始から約3か月で進めています。既存ツールとの並行利用期間を長く設け、経営から目的を発信し、先行ユーザーを募った点も示されています（出典: Google Workspace公式顧客事例、2025年公開）。ツールの設定期間だけでなく、移行と定着の期間を発注計画に含めることが大切です。

スクラッチ開発や大幅なカスタマイズは、既存サービスでは実現できない業務フロー、厳格なデータ保管、複数会社をまたぐ権限、独自の検索や承認などがある場合に検討します。自由度は高くなりますが、要件定義、画面設計、開発、テスト、インフラ、脆弱性対応、バックアップ、障害対応を長期にわたって管理します。

「社内Wikiだから一から作る」という順番にせず、標準SaaS、既存基盤、ローコード、受託開発の順に不足機能を確認します。独自開発を選ぶ場合は、初期費用だけでなく5年程度の運用費、ベンダー交代時の引き継ぎ、ソースコードやデータの権利、将来のAI検索追加までRFPに含めます。

RFPと要件はどこまで整理してから発注しますか？

RFPは、ベンダーに「何を作ってください」と伝える資料であると同時に、社内で発注条件をそろえるための資料です。機能一覧だけでなく、解決したい業務課題、利用者、既存データ、セキュリティ、移行方針、納期、予算、提案してほしい範囲、見積の分け方を記載します。

最初に、情報がどこに散在しているかを棚卸しします。共有フォルダ、既存ポータル、チャット、メール、Excel、紙の手順書、個人が管理する資料を対象に、内容、所有部署、機密度、更新頻度、利用者、移行可否を一覧化します。全社の情報を一度に載せるのではなく、最初は新人教育、情シスFAQ、営業提案、現場手順など、効果を測りやすい1〜2領域に絞ります。

利用者数も「全社員」だけでなく、記事を作成する編集者、閲覧だけの社員、外部協力会社、管理者に分けて記載します。部署や役職、プロジェクトによって閲覧範囲が変わる場合は、具体的な利用シーンを提示します。例えば「退職手続きは全社員が閲覧できるが、人事評価の運用は人事部だけが閲覧する」と書くと、ベンダーが権限設計と費用を見積もりやすくなります。

機能要件は、ページ作成、Markdownやリッチテキスト、画像・動画・添付ファイル、テンプレート、全文検索、タグ、カテゴリ、コメント、メンション、通知、版管理、レビュー期限、承認、エクスポート、API連携などに分けます。各機能を「必須」「できれば必要」「将来検討」に分類し、代替案も示します。検索は、タイトルだけでなく本文、タグ、作成者、更新日で絞れるか、検索候補や関連ページが表示されるかを確認します。

非機能要件では、SSO/SAML、二要素認証、IPアドレス制限、操作ログ、バックアップ、データ保管場所、暗号化、可用性、障害復旧時間、サポート時間、脆弱性対応を確認します。AI検索を利用する場合は、参照権限を越えて回答しないこと、入力データが学習に利用されるか、外部サービスへ送信されるか、プロンプトや回答のログを管理できるかを受入条件に含めます。

既存資料の移行では、ページ数やファイル容量だけでなく、重複、古い版、未承認情報、個人情報、リンク切れ、所有者不明の資料を把握します。すべての資料をそのまま移すと、検索結果に古い手順が残り、社内Wikiが新しい迷子の場所になるためです。移行前に「残す」「統合する」「保管だけにする」「廃棄する」を決め、各ページにオーナーと更新期限を設定します。

RFPには、移行対象の概算ページ数、ファイル数、容量、形式、旧システムのエクスポート可否、変換ルール、画像や添付ファイルの扱い、リンクの書き換え、移行後の確認者を記載します。50〜100ページ程度を対象に2〜4週間のPoCを行い、検索成功率、権限漏れ、編集のしやすさ、スマートフォン利用を確認してから全体移行へ進む方法も有効です。

社内Wikiの契約形態は請負と準委任をどう使い分けますか？

契約形態は、成果物と責任範囲をどこまで確定できるかで選びます。画面、機能、移行範囲、納期、受入条件が固まっている部分は請負契約に向き、要件整理やPoC、運用改善のように作業内容を協議しながら進める部分は準委任契約に向きます。法的な扱いや契約書の確認は、自社の法務担当者や専門家にも相談します。

請負で発注する場合は、納品するシステム、設定内容、移行データ、設計書、操作マニュアル、テスト結果、管理者アカウントの引き渡しを明記します。「使える状態」の意味も、必須機能の動作、権限パターン、検索結果、移行データの件数、バックアップからの復旧確認などに分解します。受入テストの担当部署、判定期限、不具合の修正期限、追加変更の扱いも契約書や仕様書にそろえます。

請負であっても、発注者側の資料提供や判断が遅れると納期や費用に影響します。ベンダー任せにせず、社内の責任者、各部署のレビュー担当、情報セキュリティ担当、法務担当を決めます。仕様変更が起きたときは、無償対応の範囲と、見積を取り直す変更管理の手順を運用します。

準委任契約は、専門家の知見や作業を一定期間確保し、要件定義、製品比較、RFP作成、PoC、情報設計、移行計画、定例会議、運用設計などを段階的に進める場合に適しています。社内Wikiは、実際に現場へ聞くまで必要なカテゴリや権限が固まりにくいため、最初から全機能を固定するより、企画・設計を準委任で進め、確定した開発部分を請負に切り出す構成も考えられます。

準委任では、成果物の完成を一方的に保証する契約とは限らないため、稼働時間だけで判断しないことが重要です。月ごとの成果物、会議体、課題一覧、意思決定ログ、次月の作業計画、担当者のスキル、報告頻度を合意します。契約終了後に社内だけで運用できるよう、設計資料とナレッジの引き継ぎも作業範囲に含めます。

社内Wikiには社内規程、顧客情報、従業員情報、開発ノウハウが混在する可能性があります。契約書では、秘密保持、再委託先、データの保管場所、アクセス権限、ログの保存、事故時の報告、脆弱性対応、バックアップ、データ返却・削除、解約時のエクスポート、知的財産権を確認します。個人情報を扱う場合は委託先の監督や安全管理措置も論点になり、個人情報保護委員会のガイドラインでは委託先の監督が整理されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年6月一部改正）とされています。

AI機能を使う場合は、AI提供会社がデータを学習に利用するか、国外のサーバーへ送信されるか、管理者が機能を無効化できるか、参照元ページと権限を追跡できるかを確認します。便利な要約が出ても、権限の誤設定や古いページが残れば誤回答につながるため、AI機能はナレッジの品質管理とセットで発注します。

社内Wikiの費用相場はいくらですか？

社内Wikiの費用は、ライセンス、初期設定、データ移行、連携、研修、運用保守に分けて考えます。公開料金から見ると、小規模なSaaSは月額数千円から3万円程度、中規模は月額3万円から30万円程度、大規模は月額30万円から180万円以上が一つの目安です。ただし、これは各社の公開料金と一般的な導入支援作業をもとにした整理であり、社内Wiki全体に共通する公的な統計相場ではありません。

公開料金の例では、NotePMは編集ユーザー8名と閲覧ユーザーを含むプランが月額4,800円、編集25名を含むプランが月額15,000円、編集100名を含むプランが月額60,000円です。DocBaseは1人月額550円、10人月額4,950円、30人月額11,000円などの料金を掲載し、追加ストレージは10GBあたり月額500円です（出典: NotePM公式料金ページ、DocBase公式サイト、いずれも2026年8月確認）。契約前は税表示、請求単位、ストレージ、SSOやIP制限などの有料オプションを再確認します。

ライセンス費を比較するときは、社員数だけでなく編集者数と閲覧者数を分けます。例えば、全社員が見るが記事を書くのは各部署の代表だけなら、閲覧専用ユーザーの扱いが総額を左右します。Confluenceのようにドル建てでプランが分かれるサービスでは、為替、税、年払い・月払い、AI機能、監査や高度な権限の追加料金を含めて年間費用を算出します。

初期設定だけを自社で行うなら、初期費用は0円から30万円程度に収まるケースがあります。権限設計、テンプレート作成、データクレンジング、旧資料の移行、SSO設定、操作研修、運用ルール作成を外注する場合は、導入支援費として30万円から150万円程度を見て、作業量に応じて見積もります。これらは個別案件の推定レンジであり、ページ数、ファイル容量、移行元の状態、連携数で大きく変わります。

受託開発を選ぶ場合の費用も、社内Wikiだけの横断的な公表統計は少ないため、業務ポータルや文書管理システムに近い開発規模から推定します。ローコードや既存基盤を使う小規模構築は100万円から500万円程度、SaaS選定から移行・連携までの支援は50万円から300万円程度、中規模の独自開発は500万円から2,000万円程度、大規模・規制対応・複数拠点を含む開発は2,000万円から5,000万円以上になる可能性があります。期間の目安も順に1〜3か月、1〜3か月、3〜9か月、6〜12か月以上と幅を持たせます。

発注時には、初年度だけでなく2年目以降の費用を分けて提示してもらいます。ライセンス、ストレージ、SSO、IP制限、監査ログ、AI機能、クラウド利用料、監視、バックアップ、脆弱性対応、問い合わせ、コンテンツ更新、追加開発、データ移行のやり直しを含めます。自社担当者が毎月何時間を運用に使うかも、見えないコストとして整理します。

安価なサービスでも、閲覧ユーザーが有料、検索や監査が上位プラン、外部連携が別料金であれば、想定より年間費用が上がります。反対に、受託開発は初期費用が大きくても、既存ライセンスの重複や手作業を減らせる場合があります。価格だけでなく、5年間で誰が何を管理するかを同じ前提にそろえて比較します。

社内Wikiの委託先はどのように選びますか？

委託先は、知名度や提示価格だけでなく、社内Wikiの導入を業務改善として扱えるかで選びます。製品提供会社、SaaSの導入支援会社、MicrosoftやGoogleの基盤に強いSIer、独自開発会社では得意領域が異なります。候補を3〜5社程度にそろえ、同じRFPと同じ評価項目で提案と見積を比較します。

実績確認では、単に「社内Wikiを導入した会社がある」と聞くだけでは不十分です。自社と近い社員数、拠点数、情報の機密度、既存ツール、移行データ量、編集者数を持つ事例を確認します。導入前の課題、対象ページ数、期間、移行の方法、利用率や問い合わせ削減などの効果、導入後の運用体制まで聞けると、提案の再現性を判断しやすくなります。

NotePMが公開する導入事例では、パソナ日本総務部が社員1,700人規模で社内Wikiを活用し、業務効率や従業員満足度の向上を紹介しています（出典: NotePM公式導入事例、2026年8月確認）。ベンダー事例の数値は自社にそのまま再現するとは限らないため、効果が出た運用ルール、更新責任者、利用促進の方法まで質問します。

セキュリティは「対応しています」という表現で終わらせず、SSOの方式、退職者のアカウント停止、部署異動時の権限変更、ゲスト管理、IP制限、操作ログの保存期間、バックアップの頻度、復旧テスト、脆弱性の報告と修正期限を確認します。顧客情報や従業員情報を扱うなら、データの保管場所、再委託、事故発生時の連絡経路を情報セキュリティ担当と確認します。

導入後は、ページを作る担当者が変わり、部署が増え、検索語も変化します。月次の利用分析、検索0件語の改善、更新期限の確認、管理者研修、問い合わせ窓口、追加設定の単価、障害時の対応時間を提案書で確認します。初期構築だけを安くする会社より、社内担当者が自走できるまで資料と研修を残す会社の方が、長期的な定着につながりやすいです。

社内Wikiの見積はどこを比較すべきですか？

見積比較では、合計金額の安さよりも、同じ作業が同じ項目に入っているかを確認します。ライセンス、初期設定、要件定義、情報設計、移行、連携、テスト、研修、マニュアル、プロジェクト管理、保守を分けてもらい、数量、単価、工数、前提条件、除外事項、追加料金の条件を並べます。

例えば「データ移行一式」とだけ書かれている場合は、対象ページ数、添付ファイル数、旧形式からの変換、重複整理、権限設定、リンク修正、移行後の目視確認が含まれるかを質問します。「連携対応」も、APIの設計だけなのか、実装・テスト・運用監視まで含むのかで費用が変わります。見積の前提をRFPと照合し、会社ごとの解釈を減らします。

安い見積に含まれていない作業は、発注後に追加費用として現れます。反対に、過剰な機能や全資料の一括移行が含まれている場合は、段階導入に分けられないか相談します。必須機能の初期フェーズと、AI検索や高度な分析など将来フェーズを分けると、予算と効果を確認しながら拡張できます。

提案書では、トップ画面のデザインだけでなく、ページテンプレート、カテゴリ構成、ページオーナー、更新期限、レビュー方法、古い情報の廃止、問い合わせの導線、利用促進の方法を見ます。社内Wikiは公開初日に完成するものではなく、更新される情報の仕組みを作って初めて価値が続くためです。

評価表は、要件適合度、移行方法、検索品質、権限と監査、AIの安全性、導入期間、実績、担当者の経験、保守体制、総額、引き継ぎやすさに分けます。価格だけで決めず、各項目に重みを付けます。例えば機密情報が多い会社はセキュリティと権限を重くし、短期間の部門導入なら移行と現場支援を重くする方法があります。

リスクとして、既存資料の所有者が不明、権限グループが整理されていない、移行元からデータを出せない、社員が新しい場所を使わない、AIが古いページを参照する、担当ベンダーが退職する、運用費が想定を超えるといった事態を挙げます。それぞれに、事前棚卸し、PoC、段階移行、先行ユーザー、ページオーナー、契約上の引き継ぎ、年間予算の上限を対策として置きます。

発注前の最終確認では、候補会社に同じ質問をします。「失敗しやすい点は何ですか」「移行しない方がよいデータは何ですか」「運用開始後に発注者が毎月行う作業は何ですか」「担当者が変わったとき、どの資料で引き継げますか」「解約するとき、どの形式でデータを返せますか」と質問すると、提案の現実性と責任範囲が見えやすくなります。

発注後の社内Wiki開発と運用はどう進めますか？

発注後は、要件確認、情報設計、環境設定または開発、PoC、移行、受入テスト、教育、段階公開、効果測定の順に進めます。全社公開を急ぐより、対象部署と代表的な業務を決め、現場が実際に検索・投稿・更新できることを確認してから範囲を広げます。

PoCでは、代表的な手順を実際の言葉で検索し、目的のページにたどり着けるかを確認します。タイトルの付け方が部署ごとに違う場合、同義語や略称で検索できるか、検索結果が多すぎないか、古いページが上位に出ないかを見ます。権限テストでは、一般社員、管理者、異動者、退職者、外部協力会社などのアカウントを用意し、見えてはいけないページが見えないことを確認します。

各ページには、内容を正しい状態に保つオーナー、レビュー担当、更新期限、廃止条件を設定します。総務の規程、人事の手続き、情シスのアカウント申請、営業の提案資料、開発の障害対応など、内容を最もよく知る部署が更新責任を持ち、情シスは仕組みと権限を管理します。全ページを一人の管理者に任せると更新が止まりやすいため、分担を明確にします。

月次では、閲覧数、検索0件の語句、検索後に離脱した語句、期限切れページ、ページ更新率、問い合わせ件数、月間利用者を確認します。ページ数を増やすだけでは価値を測れません。検索できたか、業務が止まらなかったか、新人が独力で手順を完了できたかを見て、不要なページを減らし、よく使われるページを改善します。

受入テストでは、要件一覧を一つずつ確認し、必須機能、主要な検索語、権限パターン、スマートフォン表示、通知、エクスポート、バックアップと復旧、AI回答の参照元を試します。不具合は重要度、再現条件、対応期限、回避策を記録します。公開後に見つかった追加要望は、瑕疵修正なのか仕様変更なのかを分けて管理します。

ベンダーからは、システム構成、権限一覧、運用手順、障害時の連絡先、バックアップ、データエクスポート、管理者向け研修資料を受け取ります。担当者が異動しても運用できる状態を検収条件に加えると、導入直後だけ手厚く、その後に何も分からない状態を防げます。

社内Wikiの発注・外注でよくある質問

社内Wikiの発注では、費用だけでなく、どの方法が自社に合うか、どこまで外注すべきか、導入後に誰が更新するかがよく問題になります。ここでは、発注前に特に確認されやすい質問へ直接回答します。

独自の保管要件や業務フローが明確でない場合は、まず専用SaaSや既存クラウド基盤を比較する方法が現実的です。標準機能で不足する部分だけを連携やカスタマイズで補い、独自開発は差別化要件と長期保守費を確認してから選びます。

ライセンス、初期設定、移行、連携、研修、保守を分け、社員数ではなく編集者数・閲覧者数・データ量・権限パターンで見積もります。SaaSの月額は小規模で月額5,000円から3万円程度が一つの目安ですが、導入支援やオプションを加えると変わります。受託開発の金額は要件で大きく変わるため、公開統計ではなく推定レンジとして扱い、複数社から同じ前提で提案を取ります。

データ移行は外注できますが、残す資料と廃棄する資料の判断は社内の各部署が担います。外注先には、重複整理、形式変換、添付ファイル移行、権限設定、リンク修正、移行後の確認を依頼し、対象ページ数と品質基準をRFPに書きます。全資料を一括移行せず、まず代表的なページで試すと、古い情報を持ち込むリスクを下げられます。

AI検索の回答範囲が、利用者の閲覧権限と一致することを最優先で確認します。データの学習利用、外部送信、保存期間、回答ログ、参照元表示、管理者による無効化、誤回答の報告方法を確認し、機密情報を載せる領域では段階導入します。AIは古いページや曖昧な権限を自動で正しくできないため、ページオーナーと更新期限の運用も同時に整えます。

まとめ

社内Wikiの発注・外注では、機能を多く作ることより、必要な情報を正しく探せて、現場が更新し続けられる仕組みを作ることが成果になります。SaaS、既存クラウド基盤、パッケージ、スクラッチ開発を比較し、対象業務と利用者を絞ってからRFPを作成します。

最初に、解決する業務、対象部署、初期ページ数、編集者と閲覧者、機密情報の範囲、成功指標、公開時期、予算上限を決めます。次に、既存資料と権限を棚卸しし、必須機能と将来機能を分けます。見積は初期費用だけでなく、ライセンス、移行、連携、研修、保守、5年間の運用負担を同じ条件で比較します。

委託先には、導入実績だけでなく、移行、権限、AIの安全性、受入テスト、導入後の伴走、データ返却まで質問します。50〜100ページ程度のPoCで検索と権限を試し、ページオーナーと更新期限を置いてから段階的に公開すると、導入後に使われない社内Wikiになりにくいです。社内の責任者と各部署の更新担当を決め、毎月の検索・利用・更新データを見ながら改善します。

▼全体ガイドの記事
・社内Wiki開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。