社内ポータルが部署ごとに散らばったリンク集や、更新の止まったWikiになっていませんか。この記事では、社内ポータルをNext.jsで内製するときに、最初にどう情報設計を組むべきかを整理します。

この記事で分かること

  • 社内ポータルに必要な情報設計の考え方
  • 業務アプリを「束ねるハブ」としての設計パターン
  • 権限管理と検索性をどう両立させるか

複数の社内ツールやExcel管理表が乱立し、どこに何があるか分からないという声が現場から上がっている情シス担当者の方へ向けて書いています。

なぜ今、社内ポータルをNext.jsで作り直すのか

多くの中小企業では、社内ポータルがGoogleサイトや古いWordPress、あるいは共有フォルダのショートカット集で代用されています。これらは手軽に始められる反面、権限管理が甘かったり、検索性が低かったり、業務アプリとの連携ができなかったりという限界を抱えています。

Next.jsでポータルを内製する最大のメリットは、単なる情報掲示板ではなく、社内の業務アプリを束ねる「ハブ」として設計できることです。日報、申請フロー、マニュアル検索といった個別の業務アプリを、同じ認証基盤の上で一元的に導線化できます。

典型的な業務フローをどう分解するか

社内ポータルが担う役割は、大きく分けると次の3つに整理できます。

  • 情報発信：お知らせ、規定変更、部署間の連絡事項
  • 業務導線：各種申請、日報入力、マニュアル検索への入口
  • 検索：過去の議事録やドキュメントへのアクセス

ポータルを作り直す際によくある失敗は、最初から全機能を詰め込もうとすることです。情報発信と業務導線への入口だけを最小構成として先に作り、検索機能や個別業務アプリとの連携は後から拡張する方が、現実的に運用が回りやすいと感じています。

Next.jsでの設計パターン

社内ポータルの最小構成は、次のような設計で組むことができます。

app/
  (portal)/
    layout.tsx        # 共通ナビゲーション・認証ガード
    page.tsx           # トップ：お知らせ一覧+業務導線カード
    announcements/
      page.tsx         # お知らせ一覧
      [id]/page.tsx     # 詳細
    apps/
      page.tsx           # 連携する業務アプリの一覧

Firebase Authenticationでログインを管理し、Firestoreにユーザーの部署・役職情報を持たせることで、表示するお知らせやアプリカードを役職別に出し分けられます。役職に応じたアクセス制御の設計は社内システムの権限設計をNext.js 16でどう実装するかで詳しく扱っています。

拡張フェーズでは、app/apps/配下に個別の業務アプリ（申請フローや日報集計など）をルートとして追加していく形で、ポータル自体を書き換えずに機能を増やせる構造にしておくことがポイントです。

Next.js 16の'use cache'ディレクティブを使えば、頻繁に更新されないお知らせ一覧などのキャッシュ戦略を柔軟に組めます。全体ダッシュボードとしての情報集約については散らばった社内データを1枚のダッシュボードに集約するも参考になります。

検索機能はどのタイミングで組み込むべきか

情報発信と業務導線の最小構成が定着した後、次に検討されることが多いのが検索機能です。社内ポータルに蓄積される情報（お知らせ、議事録、マニュアルへのリンクなど）が増えてくると、単純な一覧表示だけでは目的の情報にたどり着きにくくなります。

検索機能を最初から作り込むのではなく、まずはタイトルと本文の部分一致検索程度のシンプルな実装から始め、利用状況を見ながらベクトル検索などへの拡張を検討する進め方が現実的です。全文検索エンジンやベクトルDBの導入は、情報量がある程度蓄積されてから効果を発揮する機能であり、初期段階から高度な検索基盤を用意する必要はないと考えています。

運用開始後によくあるつまずきとは

社内ポータルは、作った直後は利用されても、更新が止まると徐々に見られなくなる傾向があります。よくあるつまずきは、お知らせの更新権限を情シス担当者だけに絞ってしまい、他部署からの発信が滞ってしまうケースです。

各部署の担当者がお知らせを投稿できる権限設計にしておくと、情報の鮮度が保たれやすくなります。誰が何を投稿できるかという権限設計は、技術的な実装と同じくらい、運用ルールとしての取り決めが重要になります。

AI駆動開発で何が変わるか

社内ポータルのようなCRUD中心の画面は、Claude Codeなどのツールで実装スピードを上げやすい領域です。お知らせ一覧・詳細ページのような定型的な画面はAIに実装の下書きを任せ、権限設計や情報アーキテクチャの判断は人間側が担う、という役割分担が機能しやすいと感じています。

ゼットリンカーでの進め方

私たちが社内ポータルの内製を支援する場合、まず「誰が」「何を」「どのくらいの頻度で」見るのかをヒアリングし、最小構成のトップページとお知らせ機能から数週間の短いサイクルで着手します。全部署の要望を最初から詰め込むのではなく、使われる機能から優先的に形にしていく進め方です。

よくある質問

Q. 社内ポータルとダッシュボードは何が違いますか？ A. ポータルは情報発信と業務導線の「入口」としての役割が中心で、ダッシュボードはデータの可視化に特化した画面です。ポータルの中にダッシュボードへの導線を置く構成もよくあります。

Q. 既存のGoogleサイトから移行する場合、何から始めればいいですか？ A. 現在掲載している情報を「お知らせ」「業務導線」「検索」の3種類に分類することから始めることをおすすめします。分類できれば、最小構成の画面設計に落とし込みやすくなります。

Q. 部署ごとに見せる情報を変えることはできますか？ A. Firebase Authenticationとユーザーの属性情報を組み合わせることで、部署や役職に応じた出し分けが可能です。

Q. 将来的に業務アプリを追加していく場合、作り直しが必要になりますか？ A. 最初から拡張を見据えた構成で作っておけば、既存部分を書き換えずにアプリを追加していける設計が可能です。着手前の情報設計がその後の拡張しやすさを左右します。

まとめ

社内ポータルの内製は、全機能を一度に詰め込むのではなく、情報発信と業務導線の最小構成から始めることが現実的です。役職別の出し分けや業務アプリとの連携は、拡張フェーズで段階的に組み込んでいく設計をおすすめします。情報設計の進め方について相談したい場合は、要件未定の段階でも構わない15分のカジュアル相談をご利用ください。

本記事は Next.js 16.x 時点の情報です。最終更新：2026-08-03