まず押さえたい「ポータルサイトとディレクトリ」の本質的な違いと関係
社内ポータルを作ろうとして、気付けば「フォルダ名会議」に数週間…という相談が後を絶ちません。実は、そのモヤモヤの8割は、ポータルとディレクトリの役割を混同していることが原因です。ここを整理すると、設計の迷いが一気にほどけます。
ポータルサイトとは何か？総合型や専門型や社内ポータルのざっくり地図
ポータルはひとことで言うと、情報への入口をまとめたホームベースです。外部向けか社内向けかで性格が変わります。
| 種類 | 主な目的 | ユーザーが最初にしたいこと |
|---|---|---|
| 総合型ポータル | ニュースや検索をまとめて提供 | 世の中の情報をざっと把握 |
| 専門型ポータル | 業界特化の情報やサービスを提供 | 特定テーマを深掘り |
| 社内ポータル | 社内の業務情報やツールに誘導 | 今日の仕事にすぐ着手 |
社内ポータルでは、ログイン後最初の1クリックをどこに向かわせるかが勝負どころです。ここを外すと、社員がブックマーク直行になり、ポータルそのものが素通りされてしまいます。
ディレクトリとは何ですか？リンク集から社内情報基盤へ進化した意外な役割
ディレクトリは、ざっくり言えば情報をしまう棚と住所のルールです。昔はリンク集型サイトのカテゴリ分けというイメージが強かったですが、今は役割が大きく変わっています。
-
Webサイトの階層構造とURLのルール
-
社内ポータルのコンテンツ配置
-
ファイルサーバやクラウドストレージのフォルダ構成
私の視点で言いますと、部署別フォルダと年度別フォルダだけで組まれた構造は、3年目以降ほぼ確実に行き止まりファイルの山になります。検索に引っかからない情報が増え、探す時間だけが膨らんでいきます。
ポータルサイトとディレクトリ構造が“入口と骨組み”になる納得の理由
ポータルとディレクトリの関係は、駅前の案内板と街そのものに近いイメージです。
-
ポータルが示すのは「どこに行けばいいか」という最短ルート
-
ディレクトリが定めるのは「街全体の区画と住所」のルール
この2つがバラバラだと、次のような事態が起こります。
-
トップページはそれらしく整っているのに、3クリック目から迷子になる
-
社内検索でヒットするのに、開くと別部署フォルダに埋まっていて権限エラー
-
同じマニュアルが部署ごとにコピーされ、どれが最新か誰も自信が持てない
逆に、ポータルのメニューとディレクトリの骨組みをセットで設計すると、社員の探し方のクセと情報の置き場がぴたりと噛み合います。
社内検索ログを見ると、多くの職場で検索語の上位は「部署名」「人名」「取引先名」「業務名」に集中します。この4つを軸にポータルの入口とディレクトリの棚をそろえることが、使われる社内ポータルへの最初の一手と言えます。
社内ポータルサイトの目的と機能を整理する ― 失敗プロジェクトの共通点から逆算する
「社内ポータルを入れたのに、誰もログインしてくれない」
この状態から抜け出す鍵は、機能を盛ることではなく、目的を細かく分解してから設計することです。
社内ポータルサイトとは？業務効率やナレッジやコミュニケーションをつなぐ「デジタルワークプレイス」
社内ポータルは、社員が毎日アクセスする「社内のスタートページ」です。単なるリンク集ではなく、次の3つを一枚の画面でつなぐデジタルワークプレイスとして設計する必要があります。
-
業務効率の向上（申請やマニュアルへ最短で到達させる）
-
ナレッジ共有（属人化した知識を引き出しやすい形で蓄積）
-
コミュニケーション促進（全社ニュースや部門のお知らせを一元表示）
私の視点で言いますと、トップページのファーストビューで「最新ニュース」「よく使う業務フローへのショートカット」「よく閲覧されるマニュアル」の3つが揃っているかどうかで、定着率が目に見えて変わります。ここが欠けると、社員はすぐにファイル共有ツールや個別ブックマークに逃げてしまいます。
よくある失敗パターン3選 ― 「なんとなく部署別フォルダ」で始めるとハマる落とし穴
社内ポータルが使われなくなるプロジェクトには、共通の“型”があります。代表的な3つを整理します。
-
なんとなく部署別フォルダ構成
- 組織図そのままの階層で作る
- 異動や組織変更のたびにリンク切れとURL崩壊が発生
- 「この資料は前の部門名のまま」の行き止まりファイルが増殖
-
年度別フォルダ地獄
- 「2022」「2023」のように年度で最上位を切る
- 3年目以降、どの年度のどのパスに最新版があるか誰も分からない
- 社内検索にも引っかかりにくく、重複コンテンツが量産される
-
目的不明の機能てんこ盛り
- 掲示板、チャット、ワークフロー、ファイル共有を全部詰め込む
- 更新フローや権限設計が追いつかず、誰もメンテナンスしなくなる
- 「どこに何を書けばいいか分からない」と現場から不満が出る
共通しているのは、社員の探し方（検索行動）を無視した構造になっていることです。実際の社内検索ログを見ると、多いのは「部署名」「人名」「取引先名」「業務名」の4パターンで、これに沿わないラベリングはまず使われません。
目的別に見る必要な機能やページ（ニュースやFAQやマニュアルやワークフローやナレッジマネジメントツールなど）
「目的 → 機能 → ページ」の順に落とし込むと、必要なコンテンツが整理されます。
下の表は、中小企業で最低限押さえたい目的とページ構成の例です。
| 目的 | コア機能・ページ | ポイント |
|---|---|---|
| 全社への情報共有 | トップニュース / お知らせ一覧 | 掲載ルールと掲載期限を決めて鮮度を維持する |
| 業務効率アップ | 業務別ショートカット集 / 申請フォーム一覧 | 申請システムや外部ツールへの入口を一画面に集約 |
| 問い合わせ削減 | FAQ / トラブルシューティングガイド | 問い合わせ窓口ごとに「よくある質問」を紐づける |
| マニュアル・規程の一本化 | マニュアル集 / 規程集 / テンプレート置き場 | 「業務名」「部署名」「文書種別」でフィルタできる設計 |
| ナレッジ共有・学習促進 | 事例共有ページ / ベストプラクティス集 | コメント機能や評価機能で“使われている知識”を浮かび上がらせる |
| 社内コミュニケーション活性化 | 部門ブログ / 社員紹介 / サークル活動の紹介ページ | 業務と雑談を混ぜず、タブやセクションで明確に分ける |
| ガバナンス・コンプライアンス徹底 | 規程改定のお知らせ / 研修動画 / テストフォーム | いつ誰が見たかアクセスログで追える仕組みを用意する |
この表をそのままテンプレートにし、まずは「必ず毎日見てほしいページ」だけを先に作るのが現実的な進め方です。
機能を選ぶ際のチェックポイントを挙げます。
-
社員が1日に何回アクセスするのかを想像し、3クリック以内で主要業務に到達できるか
-
ページごとに「誰が更新するか」「いつまでに更新するか」が決まっているか
-
FAQやマニュアルに対し、検索キーワードを意識したタイトルと見出しを付けているか
-
ワークフローや申請フォームは、既存システムと二重管理にならないよう連携方針を決めているか
この段階で目的と機能を言語化できていると、次のディレクトリ設計やレイアウト設計で迷走しません。逆にここを曖昧にしたまま進めると、「それっぽいトップページ」だけが完成し、半年後には誰も更新しない置物ポータルが出来上がってしまいます。
サイトのディレクトリ構造をどう設計するか ― 情報設計とURL設計のリアルな勘どころ
「どこに何があるか分からない社内サイト」が一気に「迷わない情報の地図」へ化けるかどうかは、ディレクトリ構造でほぼ決まります。見た目より“骨組み”が勝負どころです。
ウェブサイトのディレクトリ構造とは？階層やパンくずやカテゴリの基本をさくっと整理
ディレクトリ構造は、Web上のフォルダ階層とURL設計のことです。
-
階層：/intranet/manual/expense/ のようなフォルダの深さ
-
パンくず：トップ ＞ マニュアル ＞ 経費精算 のような「いまどこ」表示
-
カテゴリ：経費・人事・営業支援など、横串となる分類
ポイントは、URL・パンくず・画面上のカテゴリ名を必ず揃えることです。名前がズレると、ユーザーも検索エンジンも迷子になります。
社内向けでも、外部公開サイトと同じく「3クリック以内で目的情報に届く」イメージで階層を設計すると、業務のストレスが一気に下がります。
「部署別」「業務別」「プロセス別」どれで分ける？社内ポータルディレクトリの設計パターン集
社内ポータルの骨組みでよく使われるのは、この3パターンです。
| パターン | メリット | 失敗しやすいポイント |
|---|---|---|
| 部署別 | 管理者を決めやすい | 異動・組織変更でURL崩壊しやすい |
| 業務別 | 社員の検索行動に近い | 部署ごとの例外対応を書きがち |
| プロセス別 | ワークフローと相性が良い | 専門用語が多いと新人が迷う |
私の視点で言いますと、軸を1つに決めるのではなく「業務別＋部署別タグ」のハイブリッド構造が現場では一番長持ちします。
例として、URLは /task/expense/ に統一し、部署ごとの差分はタグや本文で表現する形です。
深すぎる階層や年度フォルダ地獄や重複コンテンツ…現場で本当に起きるディレクトリのトラブル事例
現場でよく見る“地雷パターン”を整理します。
-
部署別フォルダだけにした結果
- 組織変更で部署名が変わるたびにURL変更・リンク切れが多発
-
年度別フォルダ地獄
- /2022/マニュアル、/2023/マニュアル…と増えていき、検索で古い版ばかりヒット
-
深すぎる階層
- /本社/管理本部/総務部/庶務課/マニュアル/… といった5階層以上で、スマホからのアクセスが激減
-
重複コンテンツ
- 同じ経費規程が「総務フォルダ」「経理フォルダ」「全社マニュアル」に3コピーされ、どれが最新か誰も分からない
回避のコツは、「場所で管理する」のではなく「1つの正本に集約し、リンクで飛ばす」発想に切り替えることです。正本だけを更新すれば、古い情報が社内に残りにくくなります。
検索で見つかるディレクトリ設計 ― 社内検索とSEOをどっちも外さないコツ
社内検索ログを分析すると、多くの組織で次の4パターンが突出します。
-
部署名（総務、営業、コールセンターなど）
-
人名（担当者名、上長名）
-
取引先名（顧客名、仕入先名）
-
業務名（経費精算、勤怠、見積作成など）
この4つを無視して、「経営理念ベースの抽象的なカテゴリ」だけでディレクトリを組むと、まず使われません。
検索で見つかる構造にするためのポイントは次の通りです。
-
URL・タイトル・見出しに「業務名」を必ず入れる
-
部署名・取引先名・人名はタグやメタ情報として付与する
-
年度はフォルダ名ではなく、更新日とバージョン管理で表現する
-
よく使うページはトップから2クリック以内にショートカットを置く
外部向けサイトのSEOと同じで、「社員がどんな言葉で探すか」を起点にディレクトリを組み立てると、社内ポータルの利用率と業務効率が目に見えて変わってきます。
社内ポータルサイトのレイアウトとデザイン ― 見やすさが業務効率をガラッと変える
「中身は良いのに、誰も使わない」。社内ポータルが失敗するとき、多くは中身ではなくレイアウト設計でつまずいています。画面の並べ方1つで、社員の1日が“迷子タイム”になるか“時短タイム”になるかが決まります。
私の視点で言いますと、トップページは「情報のショーケース」であり、ディレクトリ構造は「倉庫の棚番号」です。この2つを噛み合わせると、使われる社内システムに一気に変わります。
ファーストビューに何を置くべきか ― ニュースや業務ショートカットやダッシュボードの黄金バランス
ファーストビューは、社員が毎朝必ず通る「玄関ホール」です。ここに置く要素は3つに絞り込むと機能します。
-
最新ニュース（会社からの一方通行通知）
-
業務ショートカット（よく使う申請やシステムへの入口）
-
ダッシュボード（自分に関係するタスクや期限のサマリ）
現場のログを見ると、これらが欠けているポータルでは、1カ月以内に多くの社員が申請フォームやファイル共有ツールを直接ブックマークしてしまい、ポータルを素通りしがちです。逆に、この3要素をトップの“上から順”に並べると、アクセスが自然に集まり、情報共有と業務効率が同時に回り始めます。
ポイントは、部署別のメニューより「よく使う業務別」のショートカットを優先して配置することです。検索ログを分析すると、「経費精算」「勤怠」「取引先名」など“やりたい作業名”で探していることが多く、ここに合わせると迷子が一気に減ります。
1カラムや2カラムやダッシュボード型…レイアウト例と会社規模ごとの向き不向き
レイアウトは「見た目の好み」ではなく、規模と運用体制で選ぶと失敗しません。
| レイアウト | 向いている規模・状況 | 特徴とメリット |
|---|---|---|
| 1カラム | 〜50人の中小企業や立ち上げ期 | 迷いゼロ。重要情報を縦1本に集中 |
| 2カラム | 50〜300人の成長期企業 | 左にナビ、右にニュースやショートカット |
| ダッシュボード型 | 300人超や部署が多い企業 | ロール別にカード表示で個別最適化 |
1カラムは「今日何を見るべきか」をシンプルに伝えられるため、最初の社内ポータルや無料ツールでの自作に向いています。2カラムは、左に固定メニュー、右に更新情報や掲示板を置く定番構成で、SharePointやWordPressでも実装しやすい形です。
ダッシュボード型は、部門ごとにカードやウィジェットを出し分けられる環境が前提になります。権限設定や運用ルールが整っていない段階で採用すると、「誰がどのカードを管理するのか」があいまいになり、数カ月で情報が腐りやすい点には注意が必要です。
カラーやフォントや余白やアイコン…「おしゃれ」よりも迷わないUIやUXをつくるポイント
デザインで優先すべきは、ブランド感よりも「一目でわかる道しるべ」です。特に次の4点を押さえておくと、社員が迷いにくい画面になります。
-
カラー
- 情報の種類ごとに色を固定（例:申請関連は青、ナレッジは緑、ニュースはオレンジ）
- 背景は白や薄いグレーに抑え、アクセントカラーは2色までにする
-
フォント
- Web標準の読みやすい文字を使い、見出しと本文でサイズ差をはっきりつける
- 半角英数字と日本語が混ざるページは、行間をやや広めにとる
-
余白
- 「情報量が多い企業ほど余白を削る」傾向がありますが、これは逆効果です
- クリックできる要素同士の間隔を十分に取り、スマホでも押し間違えを防ぐ
-
アイコン
- 申し込み、閲覧、編集など、アクションの種類ごとにアイコンを統一
- 似た意味のアイコンを乱発すると、社員は結局文字を読まないと判断できなくなります
業界人の目線で見ると、デザインで迷走しているポータルほど、ディレクトリ構造や権限設計も複雑になりがちです。情報設計がシンプルであれば、レイアウトも自然と整理されます。逆に、部署名や年度単位でメニューを増やし続けると、どれだけ美しい色やフォントを使っても、「どこに何があるのか分からない」というクレームは止まりません。
レイアウトとデザインは、社員にとっての「情報の地図」です。地図が読みやすければ、多少倉庫が散らかっていても業務は回ります。逆に、どれだけ立派なコンテンツを詰め込んでも、地図が読みにくければ使われません。ここを押さえておくと、社内ポータルのプロジェクト全体が驚くほどスムーズになります。
ポータルサイトとディレクトリを「どう作るか」 ― ツール別の選択肢と現実的な構築STEP
「社内ポータルを作ろう」と言った瞬間から、情シスと総務の頭の中にはSharePointやGoogleサイトやWordPressのロゴがぐるぐる回り始めます。ただ、ツール選びの前に“骨組み”の描き方を決めたチームだけが、3年後も使われ続けるポータルを手に入れています。
SharePointやGoogleサイトやWordPressや専用CMS…社内ポータル作り方と選択肢を一気見比較
現場でよく比較される構築手段を、ディレクトリ設計との相性という視点で整理します。
| ツール | 強み | 弱み・ハマりどころ | 向いている企業像 |
|---|---|---|---|
| SharePoint | Microsoft365との連携が強く、権限管理が細かい | 部署別フォルダ前提で構築しがちで、3年後に行き止まりページが増えやすい | 部門数が多く、Office中心で業務を回している会社 |
| Googleサイト | 無料で始めやすく、レイアウト変更が簡単 | ワークフローや高度なアクセス制御には別ツール連携が必須 | 100人前後でまず入口を整えたい会社 |
| WordPress | テーマとプラグインが豊富で拡張しやすい | 更新権限とセキュリティ設計を誤ると「誰も触れない」状態になりやすい | Web担当がいて、外部アクセスも視野に入れる会社 |
| 専用CMS | 業務に合わせたUIやワークフローを組み込みやすい | 初期費用とベンダーロックインのリスクが高い | 長期でインターナルコミュニケーションを強化したい会社 |
ディレクトリ構造を何度も組み替える前提であれば、SharePointとGoogleサイトは試行錯誤がしやすい一方で、専用CMSは最初の要件定義を外すと痛みが大きいという感覚があります。
社内ポータルサイト自作と制作会社依頼はどこで線を引く？費用や工数や失敗リスクのリアル
自作か外注かで迷うときは、デザインよりも「情報設計を誰がやるか」で判断するとぶれません。
-
自作に向くケース
- 社員数が50〜150人程度で、担当者が週数時間は確保できる
- 既存のファイルサーバーやTeamsのチャンネル構造を把握している
- 最初はニュース、社内リンク集、主要マニュアルだけに絞る
-
外注に向くケース
- 部署数が多く、既にフォルダ構造が迷路化している
- 組織変更やM&Aが多く、URL設計のやり直しが頻発している
- 検索ログやアクセスログを読み解く知見が社内にない
費用感だけを見て「テンプレートで安く作れます」という会社を選ぶと、1年後にディレクトリ構造の再設計費用が本体より高くつくパターンが少なくありません。私の視点で言いますと、要件定義とディレクトリ設計フェーズにきちんと時間を割いてくれる制作会社だけが、長期的には安くつきます。
構築方法の7STEP ― 要件定義からテストやリリースや運用体制づくりまでを滑らかに進める流れ
現場で失速しないプロジェクトは、次の7STEPを外していません。
-
目的と言葉合わせ
- 「業務効率」「ナレッジ共有」「コミュニケーション」のどれを最優先にするかを役員と合意します。ここが曖昧だと、部署別フォルダの貼り合わせポータルになります。
-
検索ログと問い合わせ分析
- メール件名、チャット履歴、既存社内検索のキーワードを集計し、「部署名」「人名」「取引先名」「業務名」のどれが多いかを確認します。これがディレクトリの軸候補です。
-
ディレクトリとメニュー案の作成
- 部署別だけでなく、「業務プロセス別」「よく使う手続き別」の2層目を必ず用意します。年度別フォルダを最上位に置かないことが、3年目以降の崩壊防止になります。
-
ツール選定と試作
- 上記の構造案をもとに、SharePoint版とGoogleサイト版など、最低2パターンでワイヤーフレームを作り、10人前後の社員に触ってもらいます。ここで「迷子になるポイント」を洗い出します。
-
テンプレート化と権限設計
- ニュース、マニュアル、FAQ、プロジェクトページなど、コンテンツ種別ごとにテンプレートと更新ルールを決めます。権限は「書く人」と「承認する人」を分けすぎないことが継続のコツです。
-
パイロット運用とログ確認
- 全社公開前に、1部署や1拠点に限定して1〜2カ月運用します。アクセス数よりも、「直ブックマークされているURLがどこか」を見ると、入口の設計ミスを早期に発見できます。
-
全社展開と改善サイクルの固定化
- リリース時に終わりではなく、「検索ログを毎月見る会」「不要ページを四半期ごとに棚卸しする会」をカレンダーに固定します。ここまでが構築です。
この流れを守ると、ツール変更があってもディレクトリ構造の思想だけは資産として残るため、数年単位で見たときのコストと手間が大きく変わってきます。
現場で本当にあったや起きうる「つまずき」と解決策 ― プロが見る危険サインと処方箋
「ページはあるのに、誰もたどり着けない。」
社内の情報基盤がこうなった瞬間、ポータルは“便利な玄関”から“迷路の入口”に変わります。ここでは、現場で繰り返し見てきたつまずきと、その処方箋をまとめます。
最初は順調だったのに誰も更新しなくなるポータルの原因と、その前に打てる予防策
立ち上げ直後はアクセスも多く、各部門も張り切って記事を投稿するのに、半年後には「最後の更新が3カ月前」という状態になりがちです。主な原因は次の3つです。
-
更新権限が一部の担当者に集中し、依頼と承認に時間がかかる
-
「誰が・どの頻度で・何を更新するか」が決まっていない
-
更新しても評価されず、業務として認められていない
予防策として、最初から更新の“仕組み”を設計することが重要です。
-
各部門に1人「編集担当」を任命し、直接更新できる権限を付与
-
月1回の必須更新枠（ニュース、マニュアル更新情報など）を決める
-
評価制度や目標に「ナレッジ共有への貢献」を組み込む
私の視点で言いますと、導入フェーズで「デザインレビューより先に、更新フローのレビュー」をしている企業ほど、3年後もポータルが生きています。
「どこに何があるか分からない」クレームが続出したディレクトリ構造やり直しケースの舞台裏
ありがちな構造が「部署別フォルダ＋年度別フォルダ」です。一見きれいですが、3年目から急激に詰み始めます。
-
部署異動や組織変更で、どの年度のどのフォルダが正か分からない
-
同じマニュアルが複数年度にコピペされ、どれが最新版か不明
-
社内検索で古いファイルが大量にヒットし、社員が混乱
よくある失敗例を整理すると、次のようになります。
| NGパターン | 起きる問題 | 再設計のポイント |
|---|---|---|
| 部署別×年度別だけで分類 | 異動・組織改編のたびにリンク切れが多発 | 年度はメタデータにし、URLから切り離す |
| プロジェクト名でのみ分類 | 人が変わるとプロジェクト名が通じなくなる | 業務プロセスや業務名での横串カテゴリを用意 |
| 経営理念ベースの階層名 | 検索ログと一致せず、社員の探し方とズレる | 部署名、人名、取引先名、業務名を軸にする |
やり直しの際は、社内検索ログを必ず見てから構造を決めることが肝心です。多くの組織で、検索キーワードは「部署名・人名・取引先名・業務名」に集中します。この4軸に沿ったディレクトリにすると、劇的に“迷子”が減ります。
セキュリティと利便性のバランス ― 権限を絞りすぎて逆に業務が止まったパターンから学ぶ
情報セキュリティを意識するあまり、「閲覧権限は極力絞る」が合言葉になるケースがあります。結果としてよく起きるのが、次のような事態です。
-
必要なマニュアルが見られず、結局メールでPDFを個別送付
-
承認フローが複雑で、ポータルよりチャットや口頭が優先される
-
新人が「どこまで見ていいか分からない」と萎縮し、自己学習が進まない
権限設計で意識したいのは、“標準公開”と“要制限”を先に線引きすることです。
-
全社員が見ても問題ない情報（総務手続き、業務フロー、社内ルール）
-
部門限定にすべき情報（部署別の数値、取引条件など）
-
ごく一部の役職限定情報（人事評価、M&A関連など）
この3レベルに分けたうえで、「原則は公開、例外を制限」にすると、セキュリティと利便性のバランスが取りやすくなります。
ログやアンケートで“使われていないページ”をあぶり出し、スリムに整理していく実践テクニック
作ったページを増やし続けるだけでは、どんなに美しいディレクトリでも、確実に“ゴミ屋敷化”します。重要なのは、使われていないコンテンツを定期的に捨てる習慣です。
実務で効果が高かったのは、次の組み合わせです。
-
アクセスログで「直近90日間の閲覧0回ページ」を抽出
-
社内検索ログで「よく探されているのにヒットしていないキーワード」を抽出
-
年2回の簡易アンケートで「役に立つページ」「不要に感じるページ」を聞く
抽出したページは、次のように仕分けします。
-
今後も使うが場所が悪い → ディレクトリの上位に移動、リンクを追加
-
内容が古いが軸は必要 → 更新担当を決めてリライト
-
役割が重複している → 1ページに統合し、旧ページはリダイレクトまたは削除
この「棚卸し」を四半期に1回でも回せると、ポータルは“太り続けるサイト”から“筋肉質な情報基盤”へと変わっていきます。社員が迷わない環境をつくる最大の近道は、「増やすこと」ではなく「要らないものをやめること」です。
SEOやMEOやAIOと社内ポータルをつなぐ ― 情報が「見つかる」組織になる設計思想
外部向けポータルサイトと社内ポータルサイトのディレクトリをどう切り分けると迷子が減るか
外部向けと社内向けを同じ発想で設計すると、必ずどちらかが迷路になります。ポイントは「誰が、どこから入ってくるか」で役割を分けることです。
外部向けは検索エンジンやSNSからの新規ユーザー、社内ポータルはログイン済みの社員という前提で、ディレクトリの軸を切り替えます。
外部向けの軸は、SEOやMEOを踏まえた「サービスカテゴリ」と「地域」です。一方、社内向けは「業務」と「担当者」が探しやすいことが最優先になります。
代表的な切り分けパターンを整理すると、設計方針がぶれにくくなります。
| 種類 | 主な入口 | ディレクトリの軸 | 代表的なトップ階層 |
|---|---|---|---|
| 外部向けWebサイト | 検索結果・広告 | サービスカテゴリ・地域 | service、case、area、blog |
| 社内ポータル | 社員ログイン | 業務・部門・社内制度 | task、workflow、manual、hr、sales |
外部向けでやりがちなのが、「会社概要」「事業紹介」「製品名」の社内ロジックだけで階層を作るケースです。これをそのまま社内に持ち込むと、社員は「経営企画の配下にある人事制度のマニュアル」など、現実の動線からズレた場所を延々と探すことになります。
社内向けでは、次の3地点を最優先でディレクトリ直下に置くと迷子が激減します。
-
毎日見る業務ショートカット（勤怠、経費精算、各種申請）
-
よく参照されるマニュアルとテンプレート
-
全社ニュースと重要なお知らせ
この3つがトップ階層に見えているかどうかで、ブックマーク直打ちかポータル経由かがはっきり分かれます。
Google検索やGoogleビジネスプロフィールや社内検索…すべてに共通する「探し方」のクセを読む
社員も顧客も、人が情報を探すときのクセは驚くほど共通しています。私の視点で言いますと、大量の検索ログを分析すると、次の4パターンが圧倒的に多くなります。
-
部署名・店舗名で探す
-
人名で探す
-
取引先名・ブランド名で探す
-
業務名・目的で探す（「請求書」「見積」「休暇申請」など）
外部向けでは、この4パターンをページタイトルやパンくず、ローカル検索用の店舗情報に反映させます。社内向けでは、同じ発想をディレクトリと検索インデックスの両方に埋め込みます。
具体的には次のような設計が有効です。
-
ディレクトリ名に「業務名」を必ず含める
例: /workflow/keihi、/manual/keiyaku
-
社内検索の対象に、部署名・人名・取引先名のタグを含める
-
店舗や拠点を扱う企業なら、外部の店舗ページと社内の店舗情報ページで、同じ名称ルールを採用する
この「名称ルールの一貫性」があるだけで、SEO、MEO、社内検索のどれでも同じ感覚で探せるようになり、問い合わせ件数や「どこにありますか」というチャットが目に見えて減ります。
AI時代のポータルサイトディレクトリ設計 ― LLMベース検索を前提にしたナレッジ構造のつくり方
AIを前提にした検索では、「どこに置くか」より「どう意味づけしておくか」が効きます。ディレクトリは、AIにとっての「意味のまとまり」を示すサインだと捉えると設計が変わります。
LLMベースの検索に強いナレッジ構造を作るポイントは次の3つです。
-
1階層目は“テーマ”、2階層目は“プロセス”、3階層目は“ケース”にそろえる
例: /sales/estimate/template、/sales/estimate/rules のように、「営業」「見積」「テンプレ・ルール」と粒度をそろえると、AIが関連文書を束ねやすくなります。
-
同じ内容を別ディレクトリに重複させない
見かけをそろえたコピーではなく、1つを正本として、他はリンクで参照する構造にしないと、AIが古い情報を学習してしまいます。
-
メタ情報を“AI向けの見出し”として仕込む
ページの先頭に「対象者」「いつ使うか」「関連文書」などを簡潔に書き、同じフォーマットで統一しておくと、AIは文脈を取り違えにくくなります。
AIOの観点では、「AIに学ばせたいナレッジ」と「学ばせたくない一時的なメモ」をディレクトリで分けることも重要です。
-
/knowledge/ 以下は長期保存される正式ナレッジ
-
/memo/ 以下は個人メモや検討用資料で検索対象から除外
-
/archive/ 以下は過去版としてAIの学習対象外にする
このように、SEOやMEOの発想に社内ポータルのディレクトリを接続しつつ、AIが誤学習しないための「意味の境界線」を明確に引いておくと、組織全体が「聞けばすぐ答えが返ってくる」状態に近づきます。社員の頭の中だけにあった知識が、ちゃんと資産としてまわり始める瞬間です。
中小企業の社内ポータル成功パターン ― 無料や自作からでも始められるリアルロードマップ
「お金も人も時間もない。でも“使われるポータル”は作りたい。」中小企業でよく聞く声です。ポイントは、最初から完璧を狙わず、ミニマム構造→段階拡張→3カ月改善の3ステップで進めることです。
社員数50人規模までの「ミニマム社内ポータル」ディレクトリ構造お手本パターン
社員50人前後なら、最初はこの4ブロックに絞ると迷走しません。
| 階層レベル | ディレクトリ名例 | 主なコンテンツ | 現場メリット |
|---|---|---|---|
| 第1階層 | news | お知らせ、人事情報 | メール探しを削減 |
| 第1階層 | workflow | 申請フォーム、手順 | 申請ミスと質問減少 |
| 第1階層 | manuals | 業務マニュアル、FAQ | 教えてコールを削る |
| 第1階層 | members | 社員名簿、組織図 | 「誰に聞くか」が秒で分かる |
この4つの下で、部署別ではなく「業務名」「目的」ベースで第2階層を切るのがコツです。
例）
-
manuals/請求業務
-
manuals/採用業務
-
workflow/経費精算
-
workflow/入社手続き
部署名や年度で切ると、3年目から行き止まりファイルだらけになります。業務名で切れば組織変更があっても崩れにくく、検索にも強くなります。
無料ツールと既存ITツールを組み合わせて、ムダなく段階的に拡張するスマート戦略
ゼロから高機能CMSを入れるより、今あるツールを組み合わせるほうがコストパフォーマンスは高いです。
-
Webポータル: GoogleサイトやSharePoint
-
ファイル管理: OneDriveやGoogleドライブ
-
コミュニケーション: チャットツールや掲示板機能
私の視点で言いますと、「いきなり万能ツール1本勝負」より「軽い組み合わせ＋運用ルール」のほうが定着率が高いケースが多いです。
段階拡張のイメージは次の通りです。
- 月1日で作るトップページ＋上記4ディレクトリ
- よく使う申請とマニュアルだけを先に移行
- 検索機能とアクセス権限を簡易設定
- 社内アンケートで「次に欲しい機能」を1つだけ決める
常に「次の一手は1つだけ」に絞ると、情報過多にならず社員もついてきます。
社内ポータル導入後3カ月でやるべきこと ― アクセス測定や検索ログ分析や改善のサイクル
導入後3カ月は、数字で“使われ方”を観察する期間です。最低限、次の3つを見ます。
-
アクセス数が多いページ
-
直帰率が高いページ
-
社内検索のキーワードログ
ここから拾える改善は、とても実務的です。
-
検索キーワードに「人名」「取引先名」「業務名」が多い
→ membersやmanuals配下に、その名前を含むタイトルを付け直す
-
直帰率が高いマニュアル
→ ファイルではなくWebページ化して、画像や手順番号を追加
-
アクセスがほぼゼロのページ
→ メニューから外すか、別ページに統合してスリム化
3カ月ごとにこのサイクルを回すと、「どこに何があるか分からない」という不満は確実に減ります。
中小企業の社内ポータルは、豪華さより骨組みのシンプルさと、3カ月単位の地味な改善が勝負どころです。ここを押さえれば、無料や自作スタートでも十分“使われる入口”になります。
ポータルサイトとディレクトリ設計を任せる相手をどう選ぶか ― プロの見分け方とアシストのスタンス
社内ポータルやディレクトリ構造は、一度失敗すると「誰も使わない社内システム」を量産してしまいます。最後に、“任せていい相手”を見抜く視点を整理します。
制作会社やコンサル会社を選定するチェックリスト（提案力やヒアリング力や運用サポート体制）
選定時は、見積金額より質問の質を見た方が安全です。最低限、次の観点をチェックしてみてください。
1 提案力・情報設計力
-
目的を聞いたうえで、ディレクトリ構造やトップページの配置案まで話せるか
-
組織変更や人事異動があった時のURL維持・権限変更の方針を持っているか
-
社内検索ログを前提にした構造案を出せるか
2 ヒアリング力
-
「部署別」「業務別」「プロセス別」のうち、どれで分けるべきかを一緒に整理してくれるか
-
既存のファイルサーバーやTeams、SharePointとの連携状況まで踏み込んで聞いてくるか
3 運用サポート体制
-
リリース後3〜6カ月のアクセス解析や検索ログ分析を前提にしたプランがあるか
-
更新担当者向けの運用マニュアルやレクチャーまでセットになっているか
次のように「できる会社」と「危ない会社」は初回打ち合わせから差が出ます。
| 観点 | 任せて安心な会社 | 危険信号が出ている会社 |
|---|---|---|
| ヒアリング | 業務プロセス・検索ログ・権限まで聞く | 「デザインテイストは？」だけで終わる |
| 提案内容 | ディレクトリ・レイアウト・検索設計がセット | 「トップはお知らせとバナー」程度 |
| 運用 | ログを見た改善サイクルを提案 | 納品して終わりの前提 |
「デザインだけ」「システムだけ」で終わらないパートナーを見極めるための具体質問リスト
面談では、次の質問をそのまま投げてみてください。回答の深さが、そのまま経験値です。
-
社内検索で多いキーワードに合わせて、ディレクトリ名やカテゴリをどう決めますか
-
部署別フォルダと年度フォルダだけで構成した場合、3年後にどんな問題が起きますか
-
トップページのファーストビューに必ず置くべきコンテンツは何だと考えますか
-
組織変更で部署名が変わったとき、URLやリンク切れをどう防ぎますか
-
「誰も更新しなくなったポータル」を立て直した経験があれば、原因と対策を教えてください
ここで即答できない会社は、情報設計よりも見た目やシステム構築に偏っている可能性が高いです。
80,000社以上のサイト構築とSEOやMEO支援で見えてきた「失敗しない情報設計」の共通ルール
多くの企業を支援してきた立場の私の視点で言いますと、長く使われる社内ポータルには、次の共通ルールがあります。
-
組織図だけで階層を作らない
異動や再編のたびにURL崩壊が起きるため、「業務名」「手続き名」「よくある目的（入社・異動・申請など）」を入口に混ぜることが必須です。
-
トップページは“今日使う3つ”に振り切る
最新ニュース、よく使う業務フロー、閲覧数の多いマニュアル。この3つをファーストビューに置いた会社ほど、ブックマーク直行やファイル共有ツール直行が減ります。
-
検索ログを情報設計の“答え合わせ”に使う
| ログで多い検索軸 | ディレクトリ・メニューへの反映例 |
|---|---|
| 部署名 | 部署別ページ+部署横断の共通業務カテゴリ |
| 人名 | 社員名鑑・組織図・連絡先検索 |
| 取引先名 | 顧客・パートナー一覧、案件ナレッジ |
| 業務名 | 「経費精算」「稟議」など手続き別カテゴリ |
-
更新フローと権限をシンプルに保つ
承認プロセスを重くし過ぎると、誰も更新しなくなります。現場担当がその場で直せる領域と、承認が必要な領域を明確に分けることがポイントです。
この視点を持っているパートナーかどうかを見極められれば、単なるサイト制作ではなく、業務とコミュニケーションを底上げする「働くインフラ」としての社内ポータルに近づいていきます。
執筆者紹介
この記事を書いた理由
著者 -
社内ポータルの相談を受けると、「誰も見ていない」「結局ファイルサーバに直行している」という声を何度も聞きます。画面はきれいなのに、ポータルとディレクトリの設計がちぐはぐなせいで、更新する側も探す側も疲弊している様子は、打ち合わせの空気で伝わってきます。私自身、最初に関わった社内ポータル案件で、部署ごとの声を十分に聞かないまま画面優先で形にしてしまい、リリース後に「どこに何があるか分からない」と全面的なディレクトリのやり直しに追い込まれました。あのとき、担当者が夜遅くまで自分のメモや過去メールをたどりながらリンクを貼り直していた姿が忘れられません。また、自分のパソコンの中でも年度フォルダや案件フォルダが増えすぎて迷子になり、必要な資料を見つけられず商談の直前まで焦った経験があります。会社のポータルで起きていることは、あの混乱を大きくしたものにすぎません。だからこの記事では、ツールの名前より前に、「入口」と「骨組み」をどう整えるかだけに焦点を当てました。読み終えたときに、明日から社内の誰かと具体的なディレクトリ案を前に話し合えるようになってほしい、その思いで書いています。
取材申込み
