AIエージェント時代のイントラネット・社内ポータル構築

社内イントラネット・社内ポータルの領域において、AIエージェントへの期待が高まっています。社内向けWeb戦略の立案、情報設計、デザイン制作、コーディング、CMSとのAPI連携による配信自動化、問い合わせ対応や定期運用業務の自動化まで、社内コミュニケーションと内部情報基盤の現場でAIを活用したいという声は増えています。

ただし、ここで重要なのは、「AIツールを導入すれば社内ポータルが変わる」という単純な話ではないことです。

イントラネットの実務では、AIエージェントが何を参照し、どの社内文書を根拠に回答し、どこまで組織構造やアクセス権の文脈を理解できるかが成果を左右します。

GBSは、AIエージェント時代の社内ポータルやCMSを、単なる社内向けコンテンツの公開システムではなく、AIエージェントが社内業務で活躍するための内部情報基盤として捉えるべきだと考えています。

ページ、文書、コンポーネント、メタデータ、組織区分、アクセス権、版、承認などが整理され、信頼できる情報として管理されていなければ、AIは現場で使える成果を返せません。

反対に、内部情報基盤が整っていれば、AIエージェントは単なる社内チャットツールではなく、情報収集、問い合わせ対応、企画、設計、実装、運用業務の自動化まで、社内業務を前に進める存在になり得ます。

AIエージェントが社内ポータルで注目される背景には、社内情報環境の複雑化があります。

従業員エンゲージメントの向上や意思決定の迅速化が求められる一方で、社内文書は情報共有基盤、チャットツール、各種SaaS、ファイルサーバーなどに分散しています。部門をまたぐ情報調整も増え、ベテラン社員が持つ知識の継承も課題になっています。

これまでのように、人が文書を探し、問い合わせに回答し、構成を考え、デザインやコードを作り、CMSへ入力して公開し、期限切れやリンク切れを点検するだけでは、対応スピードや業務の再現性に限界があります。

そこで期待されているのが、社内の情報源を横断的に検索し、利用者の所属や業務文脈に応じて情報を整理し、次のアクションにつながる形で支援するAIエージェントです。

特に社内ポータルでは、単なるチャット機能ではなく、コンテンツ、組織・アクセス権、問い合わせ履歴、承認ワークフロー、各種業務システムをつなぎながら、現場の判断と作業を支援することが求められます。

AIだけでは社内業務を改善できない理由

GBSは、AI単体では社内業務を改善できないと考えています。AIの性能が高くても、参照する社内情報やデータが整理されていなければ、現場で信頼して使える成果にはならないからです。

例えば、社内ポータルの運用では、次のような確認が日常的に発生します。

• この通達は現在も有効なのか、どの規程に基づいているのか
• この申請や承認フローには、どの部署・役職が関与するのか
• 同じ内容のお知らせが、過去に別の部署から発信されていないか
• このマニュアルの最新版はどれか、旧版との違いは何か
• この情報は全社員向けか、役職者限定か、特定部署限定か
• 問い合わせへの回答根拠として参照すべき文書はどれか

これらに回答するには、AIそのものよりも先に、社内コンテンツの構造、文書同士の関係、版、公開範囲、アクセス権が整理されていなければなりません。

ページ、文書、メタデータ、組織区分、版、承認、公開範囲が分断されたままでは、AIは断片的な情報しか扱えません。設計によっては、利用者に閲覧権限のない文書が回答生成に使われるなど、情報統制上のリスクにもつながります。

生成AIも同様です。生成AIは文章生成、要約、分類などに有力ですが、単体で導入するだけでは社内DXは十分に前進しません。

実務で活用するには、社内CMS、文書管理基盤、情報共有基盤、問い合わせ管理、人事・総務・情報システム部門の各システム、承認ワークフローなどと連携し、必要な文脈と根拠を持たせる必要があります。

つまり、AIエージェント導入の初期段階で問うべきなのは、「どのAI製品を使うか」だけではありません。

AIが利用すべき社内情報とデータが整理されているかを、先に確認する必要があります。

AIエージェントを支える社内ポータル・CMSという考え方

AIエージェント時代には、社内ポータルや社内CMSの役割も変わります。

これまで社内ポータルや社内CMSは、お知らせの配信、社内文書の掲載、申請への誘導、承認、公開といった仕組みとして語られることが一般的でした。これらは今後も重要です。

一方で、AIエージェントを社内業務で活用するには、社内ポータルやCMSを単なる公開システムとしてではなく、AIエージェントが安全かつ実務的に利用できる内部情報基盤として捉える必要があります。

社内ポータルが重要なのは、情報を一か所に集めることだけが理由ではありません。

どの文書が正本なのか、どの版が現在有効なのか、誰が参照できるのか、どの情報がどの組織・役職に公開されるのかといった業務文脈を持って管理できることに、本来の価値があります。

AIエージェントに必要なのは、単に大量の社内データを読み込ませることではありません。文脈が付与され、信頼性が確認され、アクセス権が適切に設定された社内データです。

この意味で、社内ポータルやCMSは「社内情報を掲載するシステム」から「AIエージェントが利用する内部情報基盤」へと、役割を広げつつあります。

• AIが正しい社内コンテンツや正本文書へアクセスできる
• ページ、文書、メタデータ、組織区分が関連付けられている
• 文書の版、改訂履歴、有効期間を追跡できる
• 部署、役職、機密区分などのアクセス権を保ったまま利用できる
• AIが生成した内容を人が確認し、承認できる
• 回答や提案が、どの情報を根拠にしたものか確認できる

こうした状態が整って初めて、AIエージェントは「質問に答えるAI」から「社内業務を前に進めるAI」へ変わります。

イントラネット・社内ポータル市場もAIエージェント前提へ

社内ポータルやエンタープライズ検索の領域では、AIを単独の付加機能としてではなく、構造化された社内コンテンツ、アクセス権、検索基盤、APIを前提に活用する動きが進んでいます。

例えば、Microsoftは、Microsoft 365 CopilotからSharePointページの作成を支援する仕組みを示しています。また、企業内検索においても、利用者の権限に応じて参照可能な文書を制御する考え方が重視されています。

社内ポータルや従業員体験プラットフォームの領域でも、社内問い合わせへの回答、情報検索、パーソナライズされた情報提供、業務タスクの実行などを、AIエージェントから支援する方向が広がっています。

重要なのは、「AI機能を搭載しているか」という機能比較だけではありません。

AIが参照できる情報をどのように整え、利用者の権限をどの段階で確認し、回答や処理の根拠をどのように残すかが、社内利用では特に重要になります。

社内ポータルにおけるAIエージェントの活用例

社内向けWeb戦略・利用状況分析

AIエージェントは、社内ポータルの利用状況を集計するだけでなく、課題を発見し、次の施策を提示するところまで支援する可能性があります。

部署別・ページ別の閲覧データや社内検索データを分析し、情報が届いていない部門、更新されていないトピック、問い合わせが集中している領域などを抽出する活用が考えられます。

さらに、分析結果を基に、お知らせの配信方法、ナビゲーション、コンテンツの統合、FAQの追加といった改善案を提示することも可能になります。

ただし、その前提として、ページ、対象者、部署、検索語、エンゲージメント指標などの計測設計が整っている必要があります。データの定義が曖昧なままでは、AIが数字を整理しても、具体的な改善判断には結び付きません。

情報設計・社内コンテンツの棚卸し

社内ポータルの情報設計は、AIエージェントを活用しやすい領域です。

既存コンテンツの棚卸し、サイトマップの再構成、部署・業務・対象者による分類の見直し、類似ページや重複文書の抽出、社内検索の導線改善などを支援できます。

一方で、社内コンテンツがページ単位やフォルダー単位でしか管理されておらず、対象部署、対象者、文書種別、版、有効期間などが定義されていない場合、AIは表面的な分類案しか出せません。

組織ごとの配信や、複数ページでの情報再利用まで見据える場合は、コンテンツモデルとメタデータの設計が必要です。

社内ポータルのデザイン制作

デザイン制作では、AIを活用して、ブランドガイドラインに沿った画面案、ページのバリエーション、画像編集、コンポーネント設計などを支援できます。

社内ポータルは、多数の部門が継続的にページを更新するため、デザインシステムや共通コンポーネントを整備する効果が大きい領域です。

ただし、カラー、タイポグラフィ、レイアウト、コンポーネント、文章のトーンなどが明文化されていなければ、AIが生成するデザインやコンテンツにもばらつきが生じます。

AI活用と併せて、社内ポータルのデザインルールを再利用可能な形で整える必要があります。

コーディング・コンポーネント実装

AIコーディングエージェントは、コンポーネントの実装、テストコードの作成、リファクタリング、障害調査などを支援できます。

社内ポータルでも、ページや機能がコンポーネント単位で整理され、デザインシステムとCMSの構造が対応していれば、実装や改修を効率化しやすくなります。

一方で、画面上の部品とCMS上のコンテンツ構造が一致していない場合、AIがコードを生成しても、CMSへの組み込みや入力設計で手戻りが発生します。

AIによる実装効率化を目指す場合も、コード、デザイン、CMSの各コンポーネントを対応させることが重要です。

社内CMS・情報共有基盤とのAPI連携

API連携は、AIエージェントを「回答するだけの仕組み」から「社内業務を実行する仕組み」へ広げるための鍵になります。

例えば、AIが社内コンテンツを検索して回答するだけでなく、更新案を作成し、承認申請を行い、人の確認を経て公開するといった流れが考えられます。

問い合わせ内容から必要な申請フォームを案内する、期限切れの文書を担当者へ通知する、更新が必要なページの一覧を作るといった処理も、各システムとのAPI連携によって実現しやすくなります。

ただし、CMSや文書管理基盤に十分なAPIがない場合、AIが情報を読むことはできても、安全に更新したり、承認フローへ接続したりすることが難しくなります。

問い合わせ対応と定期運用業務の自動化

問い合わせ対応と定期点検は、社内ポータルでAIエージェントの効果が期待される領域です。

人事、総務、情報システム部門などへの問い合わせの一次対応、申請手続きの案内、期限切れ文書の確認、リンク切れの点検、公開範囲の棚卸し、定例のお知らせ原稿の作成などを支援できます。

ただし、問い合わせ履歴、回答根拠、申請フロー、文書の有効期限、公開範囲などが構造化されていることが前提です。

根拠文書との関連付けがないままAIに回答を任せると、自然な回答は生成できても、内容が正しいかを確認できず、かえって二次対応が増える可能性があります。

AIエージェント時代の社内ポータル構築で考える7つのポイント

AIエージェントを前提にイントラネットや社内ポータルを構築する場合、現在必要な機能や製品の比較だけでは不十分です。

重要なのは、将来、AIが安全に利用できる内部情報基盤になっているかという視点です。

1. 社内情報の正本をどこに置くか

お知らせ、規程、マニュアル、申請書、議事録、画像などの正本管理が曖昧なままAIを導入しても、回答や提案の信頼性は上がりません。

まず、どのシステムや保管場所にある情報を正本とするのかを定義する必要があります。

複数の情報共有基盤、チャット、ファイルサーバー、業務システムに同じ文書が存在する場合は、AIがどの情報を優先すべきか判断できるように、正本とコピーの関係も整理します。

2. 構造化情報と非構造化情報を分断しないか

AIエージェントは、コンテンツモデルやデータベースのような構造化情報だけでなく、PDF、Word、画像、議事録、通達などの非構造化情報も横断して利用します。

社内では非構造化文書の割合が大きいため、両者を分断せず、文書種別、対象者、関連業務、版、有効期間などを通じて関連付けられる設計が重要です。

3. アクセス権と公開範囲をAIが守れるか

社内ポータルでAIを活用する場合、特に重要になるのがアクセス権です。

役員限定、特定部署限定、プロジェクト限定、個人情報を含む文書など、社内情報には複雑な公開範囲があります。

AIが回答を生成した後で表示を制限するのではなく、検索・取得する段階で、利用者が参照できる情報だけを対象とする設計が必要です。

AIエージェントが利用する検索基盤、文書管理基盤、APIのそれぞれで、利用者の所属や権限が正しく引き継がれるかを確認する必要があります。

4. 版管理・承認・トレーサビリティを保てるか

社内ポータルのAI活用では、利便性以上に統制が重要です。

AIがどの版の文書を根拠にしたのか、生成された更新案がどの情報に基づくのか、誰が確認・承認したのかを追跡できる必要があります。

AIが生成した内容を無条件に公開するのではなく、情報の重要度や公開範囲に応じて、人による確認と承認を組み込む設計が求められます。

5. 社内の各業務システムとつながるか

AIエージェントは、社内ポータルやCMSの中だけで完結するよりも、人事、総務、情報システム、申請・承認、文書管理、問い合わせ管理などのシステムとつながったときに、より大きな価値を発揮します。

社内ポータルを情報の入り口として、各業務システムを検索・参照・実行できるアーキテクチャを検討することが重要です。

6. API連携や将来のAI拡張が可能か

AIエージェント、エンタープライズ検索、RAG、デザインツール、コーディング支援などを組み合わせるには、API、webhook、検索インデックスなどの接続性が必要になります。

現在の運用課題だけで製品や構成を決めるのではなく、将来的にAIが情報を読み取り、処理を実行し、結果を書き戻せるかという観点で設計する必要があります。

7. Fit to Standardだけで終わらないか

標準機能に業務を合わせるFit to Standardは、引き続き重要です。

ただしAIエージェント時代には、標準化された業務や情報が、AIにとって「読める」「つながる」「権限を守れる」「再利用できる」状態になっているかまで確認する必要があります。

これからの社内ポータル構築では、Fit to Standardに加えて、Fit to AIという視点が求められます。

GBSがご支援できること

GBSは、イントラネットや社内ポータルの構築を、単なるシステム移行ではなく、社内DXとAI活用を支える内部情報基盤づくりとしてご支援します。

AIエージェントを導入すること自体を目的とせず、AIエージェントが社内業務で機能するためのコンテンツ設計、情報設計、アクセス権設計、API設計、運用設計までを一体として検討します。

社内ポータル・CMS基盤の構築、再構築、移行支援

• 既存コンテンツや社内文書の棚卸し
• サイト構造、ナビゲーション、検索導線の設計
• コンテンツモデルとメタデータの設計
• 版管理、承認、公開範囲、有効期間の設計
• 既存環境から新しい社内情報基盤への移行計画

アクセス権・ガバナンス設計支援

• 組織、部署、役職、プロジェクト、機密区分を踏まえた権限モデルの設計
• 検索・取得段階でアクセス権を反映する仕組みの検討
• AIが参照できる情報範囲と利用ルールの整理
• AI生成コンテンツの確認・承認ワークフロー設計
• 回答根拠や変更履歴を確認できる運用設計

API連携・業務自動化支援

• 社内CMSと文書管理基盤、情報共有基盤の連携
• 人事、総務、情報システム、問い合わせ管理などの業務システム連携
• API、webhook、検索基盤を活用した連携方式の設計
• 問い合わせ対応、承認、定期点検、更新通知の自動化
• 人の確認を含めた安全な自動化フローの設計

AIエージェントを見据えた社内情報設計

• 社内コンテンツの構造化と正本管理の整理
• 文書種別、対象者、組織、業務、有効期間などのメタデータ設計
• 社内検索性と情報再利用性の向上
• FAQと根拠文書の関連付け
• AI活用を見据えたデータ整備と業務プロセス設計

重要なのは、特定のAIツールを最初に決めることではありません。

まず、自社の社内コンテンツ、文書、アクセス権、版、承認、API、業務プロセスが、AIエージェントにとって利用可能な状態になっているかを確認することが重要です。

同時に、それらの情報をどのAI環境から、誰が、どの権限で利用できるようにするかも設計する必要があります。

GBSが考えるこれからの社内ポータルは、社内向けコンテンツを公開するためだけのものではありません。

AIエージェントが、情報収集、企画、設計、問い合わせ対応、申請案内、コンテンツ更新、定期運用など、複数の社内業務を支援するための基盤です。

Fit to Standardから、Fit to AIへ。

この視点で社内ポータルやCMSを見直すことが、AIエージェントを一時的な実証実験で終わらせず、社内業務へ定着させる第一歩になります。

一方で、社内情報基盤をAIエージェントから安全に利用できる状態へ整えるだけでは、AIガバナンスとして十分とは限りません。

社員が個人契約の生成AIを業務に持ち込んだり、会社が把握していないAIサービスへ社内情報を入力したりすれば、せっかくアクセス権や情報管理を整備しても、企業の管理外に業務情報や仕事の文脈が蓄積される可能性があります。

AIエージェント時代の社内情報基盤では、「どの情報をAIに使わせるか」だけでなく、「どのAI環境から利用させるか」まで含めて設計することが重要です。

FAQ

Q1. AIエージェントがあれば、社内ポータルやCMSは不要になりますか？

A. いいえ。むしろ、AIエージェントを実務で活用するほど、信頼できる社内情報基盤が重要になります。

社内ポータルやCMSは、AIが参照する情報の正本、版、関係性、対象者、アクセス権を管理する役割を担います。これらが整理されていなければ、AIが自然な回答を生成できても、その内容を社内業務で信頼して利用することは難しくなります。

Q2. 生成AIやAIアシスタントを導入すれば、社内ポータルはすぐに効率化できますか？

A. 単体導入だけでは、活用範囲が限定される可能性があります。

社内CMS、文書管理基盤、情報共有基盤、問い合わせ管理、各種業務システムと連携し、社内コンテンツの構造とアクセス権を整えることで、検索や要約だけでなく、問い合わせ対応や業務処理まで支援できるようになります。

Q3. なぜアクセス権設計がAI活用の鍵になるのですか？

A. 社内情報には、部署、役職、プロジェクト、機密区分などによって異なる公開範囲が設定されているためです。

AIが利用者に閲覧権限のない文書を参照すると、情報漏えいにつながる可能性があります。そのため、回答を表示する段階ではなく、検索・取得する段階で利用者の権限を反映する設計が必要です。

Q4. 社内文書やPDFが大量にあります。それでもAIを活用できますか？

A. 活用可能ですが、文書の整理が前提になります。

正本、版、有効期間、文書種別、対象者、公開範囲、関連業務などを整理し、検索や関連付けができる状態にする必要があります。文書が複数の場所へ分散したままでは、AIが情報を発見できても、どれが正しい情報か判断できない可能性があります。

Q5. AIエージェントと生成AIは同じものですか？

A. 厳密には異なります。

生成AIは、文章、画像、要約などを生成するモデルや機能を指すことが一般的です。AIエージェントは、生成AIに加えて、情報検索、ツールの実行、システム連携、判断、業務フローの遂行などを組み合わせた実行主体を指します。

Q6. 先にAIツールを導入し、後から社内ポータルを整備してもよいですか？

A. 小規模な検証であれば可能ですが、本番活用では限界が生じやすくなります。

情報基盤が未整備のままでは、回答根拠、更新への追従、アクセス権、版管理、トレーサビリティなどの課題が残ります。本格導入を見据える場合は、AIの検証と並行して、社内情報の正本やアクセス権を整理することが重要です。

Q7. AIエージェント時代の社内ポータル構築には、どの部門が関与すべきですか？

A. 社内広報や情報システム部門だけでなく、人事、総務、法務、セキュリティ、各業務部門などを含む横断的な体制が望まれます。

AI活用は、単なるシステム導入ではなく、社内情報の管理方法、業務プロセス、権限、責任範囲を見直すテーマだからです。

Q8. 対外WebサイトのCMS基盤と、社内ポータルの基盤は何が違いますか？

A. コンテンツを構造化し、版や承認を管理する基本的な考え方には共通点があります。

一方、社内ポータルでは、部署や役職によるアクセス権、機密区分、個人情報、問い合わせ、申請・承認など、社内業務との連携がより重要になります。対外Webのコンテンツ基盤に、権限統制と社内業務連携の層が加わると考えることができます。

Q9. 社内問い合わせの自動化で、特に注意すべきことは何ですか？

A. 問い合わせ履歴と回答根拠が関連付けられていない状態で、AIへ回答を任せないことです。

回答の根拠が確認できなければ、担当者による再確認が必要になり、二次対応が増える可能性があります。まずはFAQ、根拠文書、担当部門、更新日、有効期間などを構造化することが重要です。

Q10. AI活用を前提にすると、社内ポータル構築が難しくなりませんか？

A. 難しくなるというより、社内ポータルを整備する目的が明確になります。

単なる情報掲載や公開作業の効率化ではなく、「AIが社内業務で機能するための内部情報基盤をつくる」という目的が加わることで、正本管理、メタデータ、権限、承認、APIを整備する意義を社内で共有しやすくなります。

AIエージェント時代のイントラネット・社内ポータル構築をご検討中の方へ

AIエージェントを社内ポータルで活用するには、AIそのものだけでなく、社内コンテンツ、文書、版、メタデータ、アクセス権、承認、APIなどを整理した内部情報基盤が重要です。

GBSでは、イントラネット・社内ポータルの構築や移行、アクセス権・ガバナンス設計、API連携、運用自動化、AIエージェントを見据えた情報設計・業務設計についてご相談いただけます。

関連ページもご覧ください

参考情報

• Microsoft｜SharePoint page creation in Microsoft 365 Copilot
• Microsoft｜Entra-based document-level security in Azure AI Search
• Simpplr｜AI Agent Platform for Employee Support
• Staffbase｜AI-powered intranet platforms
• LumApps｜Employee Experience Platform
• ServiceNow｜Completes acquisition of Moveworks
• OpenAI｜API Platform
• GBS｜AIエージェント時代のPLM
• GBS｜AIエージェント時代の大規模Webサイト・CMS基盤整備