社内ポータルやナレッジ共有ツールは、作った直後は使われても、半年もすると古い情報が残り、誰も更新せず、必要な情報が見つからない場所になりがちです。使われ続ける社内ポータルの条件は、デザインや機能の多さではありません。「探している情報に早くたどり着ける」「情報が古くなっていない」「見てよい人だけが見られる」の三つが守られていることです。そして、この三つを支えるのは、システムの機能よりも、情報ごとに更新の責任者を決める運用の設計です。
結論として、社内ポータルを作るときは、まず社員が日常的に何を探しているかを調べ、その情報への入口を最優先で設計します。次に、情報の種類ごとに置き場所と更新の担当を決め、古くなった情報を見つける仕組みを組み込みます。そのうえで、既製のグループウェアやナレッジ共有ツールで足りるのか、社内の業務システムやデータと結びつけるために個別開発が必要なのかを判断します。
この記事は、社内ポータルの立ち上げや作り直しを任された総務・情報システム・広報の担当者や、社内の情報共有に課題を感じている経営者に向けています。使われなくなる原因、設計の手順、情報の探しやすさ、更新の責任、権限、検索、構築方法の選び方、よくある失敗を整理します。
社内ポータルが使われなくなる原因
使われなくなった社内ポータルには、共通するパターンがあります。
情報が古く、信用されない
一度古い情報に当たった社員は、ポータルの情報を信用しなくなり、詳しい人に直接聞くようになります。規程の旧版が残っている、退職者が担当者として載っている、終わったキャンペーンのお知らせがトップに残っている、といった状態です。
探している情報にたどり着けない
ポータルの構成が組織図どおりになっていて、社員は「どの部署の担当か」を知らないと情報を探せない。検索しても関係のない古い文書ばかりがヒットする。こうした状態では、社員は探すのをあきらめます。
情報の置き場所が分散している
ポータル、ファイルサーバー、チャットツール、各部署の共有フォルダ、個人のメールに情報が分散し、どこに何があるか誰も把握していない状態です。ポータルが「置き場所の一つ」にすぎず、入口として機能していません。
更新の担当が決まっていない
ポータルを立ち上げた担当者が更新を一人で抱え、異動や多忙で更新が止まる。各部署に更新を任せたが、誰が担当か決まっておらず、誰も更新しない。社内の情報共有が進まない原因は、社内のナレッジ共有が進まない原因でも詳しく解説しています。
社内ポータルに載せる情報を整理する
設計の最初の作業は、載せる情報の整理です。情報の種類によって、更新の頻度、責任者、閲覧範囲、適した形式が異なります。
| 情報の種類 | 例 | 更新頻度 | 適した形式 |
|---|---|---|---|
| お知らせ | 全社連絡、行事、システム停止の案内 | 随時 | 日付付きの投稿、期限で自動的に非表示 |
| 規程・手続き | 就業規則、経費精算の方法、各種申請の手順 | 改定時 | 版の管理ができるページ、改定履歴 |
| よくある質問 | 総務・人事・情報システムへの問い合わせ | 問い合わせの傾向に応じて | 質問と回答の形式、カテゴリとタグ |
| 業務ナレッジ | 業務手順、トラブル対応、提案資料の型 | 業務の変更時 | 手順書、テンプレート、事例のページ |
| 人・組織 | 社員名簿、組織図、担当者一覧 | 異動・入退社のたび | 人事データとの連携で自動更新 |
| 業務システムへの入口 | 勤怠、経費、顧客管理などへのリンク | システム変更時 | リンク集、シングルサインオン |
この表を自社の情報で埋めてみると、「人・組織」の情報は人事データと連携しなければすぐに古くなる、「お知らせ」は掲載期限を設けないとトップが埋まる、といった設計上の要件が見えてきます。
探しやすさの設計
社員が探しているものから入口を作る
社員が日常的に探している情報は、実はそれほど多くありません。総務や人事、情報システム部門への問い合わせ、社内チャットでの質問を一か月ほど集めると、よく探されている情報が見えてきます。その上位の情報への入口を、トップページの目立つ場所に置きます。
組織ではなく目的で分類する
「総務部」「人事部」のような組織別の分類は、情報を作る側には分かりやすいものの、探す側には不便です。「入社・退社」「休暇・勤怠」「経費・購買」「PC・アカウント」のように、社員の目的や場面で分類すると、担当部署を知らなくても探せます。
検索を使えるものにする
情報が増えるほど、分類よりも検索が重要になります。検索結果に古い文書が上位に出ないよう、掲載期限の過ぎた情報を検索対象から外す、正式な文書を優先して表示する、といった工夫が必要です。同じ意味の言葉（「有給」と「年次休暇」など）でも検索できるように、同義語を登録しておくのも効果的です。
生成AIによる検索と回答
近年は、社内の文書をもとに質問に答えるAIの仕組みを、社内ポータルに組み込む例も増えています。社員が自然な言葉で質問すると、関連する規程や手順書を探して回答し、根拠となる文書へのリンクを示す、という使い方です。ただし、AIの回答の質は、元になる文書の質と鮮度に左右されます。古い文書が残っていれば、AIは古い情報で答えます。AIを入れる前に、情報の整理と更新の仕組みを整えることが先決です。規程に関する問い合わせへの応用は社内ヘルプデスクをAIチャットボット化するで詳しく解説しています。
更新の責任をどう設計するか
情報ごとにオーナーを決める
ページや文書ごとに、内容に責任を持つオーナーを決め、ページ上に表示します。オーナーは個人名よりも役割（たとえば「人事部 労務担当」）で指定すると、異動の際に引き継ぎやすくなります。オーナーが表示されていれば、読む側も誰に問い合わせればよいかが分かります。
鮮度を見える化する
各ページに最終更新日を表示し、一定期間更新されていないページをオーナーに通知して、内容の確認を求めます。確認して変更がなければ「確認日」を更新するだけでもかまいません。これにより、「古いかどうか分からない」状態を防げます。
掲載期限を設ける
お知らせやキャンペーンの情報には掲載期限を設定し、期限が過ぎたら自動的にトップから外れ、検索対象からも除外されるようにします。期限のない情報が増え続けることが、ポータルが散らかる最大の原因です。
更新のしやすさを確保する
更新の手間が大きいと、オーナーは更新を後回しにします。専門知識がなくても編集できる画面、テンプレート、下書きと公開の分離、変更点の差分表示など、更新する側の使いやすさにも配慮します。ウェブページを専門知識なしで編集できる仕組みはCMSとも呼ばれ、社内ポータルでも同じ考え方が使えます。
権限とアクセスの設計
社内ポータルには、全社員向けの情報だけでなく、管理職向け、特定の部署向けの情報も載ります。閲覧範囲の設計を誤ると、見せてはいけない情報が全社に公開される事故につながります。
- 閲覧範囲の単位を決める：全社、部署、役職、プロジェクトなど、閲覧範囲をどの単位で設定するかを決めます。人事データの組織情報と連動させると、異動のたびに手作業で設定を変える必要がなくなります。
- 編集権限を絞る：編集できる人を、ページのオーナーと補助者に限定します。誰でも編集できる状態は、更新が進むように見えて、責任の所在を曖昧にします。
- ログインを一本化する：社内の他のシステムと同じアカウントでログインできるようにすると、利用者の負担が減り、退職者のアカウント停止も一元化できます。この仕組みはSSO（シングルサインオン）と呼ばれます。
- 社外からのアクセス：在宅勤務や外出先から使う場合、どの情報を社外のネットワークから見られるようにするか、端末の条件をどうするかを決めます。
構築方法の選び方
社内ポータルの構築方法は、大きく三つに分かれます。
| 観点 | グループウェアのポータル機能 | ナレッジ共有ツール・社内wiki | 個別開発 |
|---|---|---|---|
| 導入の速さ | 速い（既存契約で使える場合も） | 速い | 設計と開発の期間が必要 |
| 文書の作成・更新 | 製品の編集機能の範囲 | 編集しやすさに優れる製品が多い | 必要な形で設計 |
| 検索 | 製品の検索機能の範囲 | 製品によって差がある | 業務に合わせて設計できる |
| 業務システムとの連携 | 同じ製品群なら容易 | 連携機能の範囲 | 必要な連携を設計できる |
| 独自の画面・データ表示 | 製品の範囲内 | 製品の範囲内 | 自由に設計できる |
多くの場合、まずはすでに使っているグループウェアや、ナレッジ共有ツールで始めるのが合理的です。個別開発が向くのは、社内の業務システムのデータ（たとえば各部署の実績、顧客の状況、在庫や予約の状況）を一画面にまとめて表示したい、人事データや業務データと深く連動させたい、AIによる検索を社内の複数のシステムにまたがって行いたい、といった場合です。また、既製のツールを基盤にして、必要な部分だけを個別に作る組み合わせも可能です。
個別開発を選ぶ場合に決めておくこと
個別開発で作る場合は、既製ツールなら製品が用意してくれる部分も自分たちで決める必要があります。少なくとも次の点は、開発を依頼する前に整理しておきましょう。
- 文書の編集をどこで行うか：ポータルの中に編集機能を作るのか、既存の文書管理ツールやCMSで編集した内容を表示するのか。編集機能を一から作ると、開発の範囲が大きく広がります。
- 連携するデータの正本：人事データ、組織情報、業務システムの実績などを表示する場合、それぞれのデータの正本がどのシステムにあり、どの頻度で反映するかを決めます。
- 検索の範囲：ポータル内の文書だけを検索するのか、ファイルサーバーや他のツールの文書も対象にするのか。対象を広げるほど、権限に応じて検索結果を出し分ける設計が重要になります。
- 運用後の改修体制：入口の並び替えや分類の追加など、頻繁に変える部分を管理画面から変更できるようにするか、開発に依頼するかを決めます。
特に検索の範囲は、AIによる回答を組み込む場合に重要です。権限のない社員に、見てはいけない文書の内容が回答として表示されないよう、文書ごとの閲覧範囲を検索や回答の段階でも守る設計が必要になります。
社内ポータル構築の手順
- 現状を調べる：社員が日常的に探している情報、問い合わせの多い内容、現在の情報の置き場所を調べます。
- 目的と対象を決める：ポータルで何を解決したいのか（問い合わせの削減、手続きの迷いの解消、ナレッジの共有など）を決め、最初に載せる情報の範囲を決めます。
- 情報の分類と入口を設計する：社員の目的に沿った分類と、トップページに置く入口を決めます。
- オーナーと更新ルールを決める：情報の種類ごとにオーナー、更新の頻度、確認のルール、掲載期限を決めます。
- 権限を設計する：閲覧範囲と編集権限の単位を決め、人事データとの連携を検討します。
- 構築方法を選び、作る：既製ツールで足りるか、個別開発が必要かを判断し、構築します。
- 既存の情報を移す：既存の文書を、そのまま全部移すのではなく、最新かどうかを確認し、不要なものは移さずに整理します。
- 公開と周知：公開後しばらくは、問い合わせに対してポータルのページを案内する運用を徹底し、ポータルを入口として定着させます。
- 利用状況を見て改善する：よく見られるページ、検索されても見つからなかった言葉、更新されていないページを定期的に確認し、改善します。
具体的な場面で考える：拠点の多い会社のポータル
架空の例として、全国に営業所を持つ会社が、社内ポータルを作り直す場面を考えます。既存のポータルはお知らせの掲示板として使われていましたが、規程や手続きの文書はファイルサーバーに、業務の手順は各営業所のフォルダに散らばっていました。本社の総務には、営業所から「この申請はどうすればよいか」「この書式はどこにあるか」という問い合わせが毎日のように届いていました。
まず、総務への問い合わせを一か月分集めて分類したところ、申請手続き、備品やPCのトラブル、休暇の扱いが大半を占めていました。そこで、ポータルのトップに「申請・手続き」「PC・アカウント」「休暇・勤怠」の三つの入口を置き、それぞれの手順をよくある質問の形式で整理しました。各ページには担当部署の役割をオーナーとして表示し、最終更新日から一定期間が過ぎたらオーナーに確認の通知が届くようにしました。
営業所ごとの業務手順は、全社共通のものと営業所固有のものに分け、共通のものは本社の担当がオーナーとなって標準の手順として整備しました。公開後、総務は問い合わせに対してポータルのページを案内する運用を続け、回答のたびに、ページの説明で分かりにくかった点を修正していきました。このように、問い合わせとポータルの改善を結びつけると、ポータルは使われるたびに良くなっていきます。
よくある失敗と避け方
既存の文書をすべて移す
古い文書をまとめて移すと、新しいポータルも最初から古い情報だらけになります。移す前に最新かどうかを確認し、オーナーが決まらない文書は移さない、という基準で整理しましょう。
デザインと機能に時間をかけすぎる
見た目や機能の作り込みに時間をかけても、載っている情報が古ければ使われません。最初は情報の整理と更新の仕組みに力を注ぎ、デザインは使われ方を見ながら改善します。
公開して終わりにする
公開した時点がスタートです。利用状況を確認し、見つからなかった検索語を拾い、更新の滞っているページに手を入れる担当と時間を確保しておきます。
情報を集めることだけを目的にする
ナレッジを集めること自体が目的になると、誰も読まない文書が増えるだけです。社員がどんな場面で何を探しているのかを起点に、必要な情報から整えます。
社内ポータル構築のチェックリスト
- 社員が日常的に探している情報を調べたか
- ポータルで解決したい課題を決めたか
- 情報を組織ではなく目的や場面で分類したか
- トップページに置く入口を、よく探される情報から決めたか
- 情報ごとにオーナーを役割で決め、ページに表示したか
- 最終更新日の表示と、確認を促す仕組みを用意したか
- お知らせに掲載期限を設けたか
- 閲覧範囲と編集権限の単位を決めたか
- ログインを社内の他システムと一本化できるか確認したか
- 既存文書を移す基準を決めたか
- 公開後の利用状況の確認と改善の担当を決めたか
よくある質問
Q. 社内ポータルとナレッジベースはどう違いますか？
社内ポータルは、お知らせ、規程、手続き、業務システムへの入口などをまとめた社内の玄関口です。ナレッジベースは、業務の知識や質問への回答を整理して蓄積したものを指します。社内ポータルの中にナレッジベースを置く、という関係になることが多いでしょう。
Q. 社員に情報を書いてもらうにはどうすればよいですか？
書く手間を減らし、書いたことが役に立っていると分かる仕組みを作ることが基本です。テンプレートを用意する、チャットでの回答をそのままナレッジとして登録できるようにする、よく見られたページを書いた人に知らせる、といった工夫が有効です。
Q. 社内ポータルが使われているかどうかは、何で判断すればよいですか？
閲覧数だけでは判断しきれません。よく見られているページ、検索されたのに結果が見つからなかった言葉、問い合わせの件数と内容の変化を組み合わせて確認します。特に、ポータルに答えが載っている内容の問い合わせが減っているかどうかは、ポータルが入口として機能しているかの分かりやすい目安になります。
Q. 小さな会社でも社内ポータルは必要ですか？
社員が少なく、誰に聞けばよいかが分かっている規模なら、本格的なポータルは不要なことも多いでしょう。ただし、規程や手続きの最新版をどこか一か所にまとめておくだけでも、問い合わせや間違いは減ります。共有フォルダの整理と、一枚の案内ページから始めても十分です。
Otsumuに相談できること
社内ポータルの課題が、情報の整理や更新の担当が決まっていないことにあるなら、まずは既存のグループウェアやナレッジ共有ツールを使い、この記事の手順に沿って情報の分類とオーナーの設定から始めるのが最善です。この段階では、新しいシステムを作る必要はありません。
一方で、人事データや業務システムのデータと連動した表示が必要な場合、拠点や部署ごとに細かな閲覧範囲の制御が必要な場合、社内の複数のシステムにまたがる文書をAIで検索できるようにしたい場合は、既製ツールの設定だけでは対応が難しくなります。どこまでを既製ツールで賄い、どこを個別に作るかの判断も、外部の視点があると整理しやすくなります。
Otsumuでは、社内ツール開発として、社員が探している情報の調査から、分類と入口の設計、更新の仕組みづくり、権限設計、業務システムとの連携、AIによる検索の組み込みまでを一貫して支援しています。目的から逆算して必要な機能に絞り、AIを活用した開発で少人数・短期間で進めるため、まず問い合わせの多い領域だけを整えるといった小さな始め方も可能です。
社内の情報共有をどこから整えるか迷っている段階でもかまいません。30分の無料相談で、現在の情報の置き場所と困りごとをお聞きし、進め方を一緒に整理します。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01