Microsoft 365 Copilot・Microsoft Cowork を成果につなげるには、ツールの配布だけでなく Microsoft 365 / Azure 上に知識基盤を設計する必要があります。本記事は、大学等高等教育機関がその知識基盤をどう構築すべきかを、経営層・情報システム部門それぞれの視点でまとめたものです。
- 対象読者: 大学等高等教育機関の経営層(学長・理事・CIO/CDO)および情報システム部門・DX推進部門
-
参照元:
projects/ms-iq/microsoft-iq-overview.md(Microsoft IQ 技術解説資料) - 前提: Microsoft Learn 公開情報(2026年10月時点)
- 最終更新: 2026-10-07
第I部 経営層向けサマリー
1. エグゼクティブサマリー
大学における生成 AI 活用は、新しい段階に移行する必要があります。従来は、Copilot や Cowork といったツールを「個人が使う便利な道具」として導入するだけでした。これからは、大学全体の知識を AI が理解できる形で整備し、組織的な成果につなげる段階へと進みます。
Microsoft は、Microsoft IQ(Work IQ / Fabric IQ / Foundry IQ / Web IQ)と Microsoft Agent 365 を提示しています。これらは、「組織の知識基盤」を Microsoft 365 と Microsoft Azure 上に構築するための標準的な部品群です。大学の組織特性は、次の3点に整理できます。第一に、学部・研究科・事務局・付属機関が併存する複雑な組織構造です。第二に、研究データ・学籍データ・個人情報が混在するデータ特性です。第三に、教員の裁量と全学ガバナンスのバランスです。本資料は、これらの特性に Microsoft IQ と Agent 365 を当てはめ、どのような知識基盤を、どの順序で、どのガバナンスの下で構築すべきかを具体的に提示します。
結論を先に述べると、大学が構築すべき知識基盤は以下の4層構造です。
| 層 | 担当する IQ | 大学における役割 | 基盤 |
|---|---|---|---|
| 協働層 | Work IQ | 教職員のメール・会議・ファイル・チャットを横断理解し、日常業務の AI 支援を実現 | Microsoft 365 |
| 意味データ層 | Fabric IQ | 学籍・履修・財務・研究データを「大学の業務語彙」として意味づけ、部局横断の分析・推論を可能にする | Microsoft Fabric(Azure) |
| ナレッジ層 | Foundry IQ | 規程集・シラバス・研究論文・FAQ などの非構造データから、権限に応じた正確な回答を引き出す | Microsoft Foundry(Azure AI Search) |
| 外部知見層 | Web IQ | 他大学動向・最新研究・社会情勢など学外情報で学内回答を補強する | Foundry Agent Service(Bing) |
さらに、学内に増え続ける AI エージェント(全学共通 Copilot、部局独自エージェント、研究室単位のエージェント等)を、横断機能として Microsoft Agent 365 が可視化・統制・保護します。ただし対象となるのは、登録・統合され対応ライセンスが有効化されたエージェントに限られます(未登録エージェントの把握には、申請制度やテナント設定等の補完策を別途組み合わせます。第10章参照)。
本資料は、この4層構造を大学の意思決定層にもわかる形(第I部)と、情報システム部門が実装設計に着手できる形(第II部・第III部)の両方で解説します。
2. なぜ今、大学に知識基盤が必要か
2.1 大学組織特有の課題
一般企業と比較して、大学には生成 AI 活用を難しくする構造的な特徴があります。
| 課題 | 具体例 | 影響 |
|---|---|---|
| 組織の分散性 | 学部・研究科・附属病院・附属学校・事務局が、それぞれ独自の業務慣行・情報システムを持つ | 全学共通の Copilot を入れても、各部局の文脈を理解できず「当たり障りのない回答」しか返せない |
| データの異質性 | 学籍・成績(教務システム)、財務・人事(基幹システム)、研究データ(各研究室・研究科)、診療情報(附属病院)が別々に存在 | データ統合前に AI を使っても、断片的な回答しかできない |
| ガバナンスの二重性 | 教員の学問の自由・裁量と、全学的なコンプライアンス(個人情報保護法、研究倫理、文部科学省への報告義務等)が併存 | 画一的な権限設計ができず、部局ごとに異なるアクセス制御が必要 |
| 規程・ナレッジの属人化 | 奨学金規程、履修要項、研究費執行ルール、留学手続き等が PDF や部局サイトに散在し、全学検索できない | 職員・学生からの問い合わせ対応が属人化し、Copilot 導入だけでは解消しない |
| 個人情報・機微情報の重さ | 学生の成績・健康情報、研究倫理審査情報、治験データ等、取り扱いを誤ると社会的影響が大きい情報を多く扱う | 権限を考慮しない AI 検索は重大なインシデントに直結する |
2.2 「Copilot を配っただけ」で成果が出ない理由
Microsoft 365 Copilot や Cowork をライセンスとして配布しても、それだけでは次のような状態にとどまりがちです。
- 教職員各自が自分のメール・ファイルの範囲でしか AI の恩恵を受けられない(Work IQ が前提とする M365 の情報アーキテクチャ・権限衛生・共有ルールが未整備)
- 「今年度の学部別入学者数の推移」のような全学データに基づく質問に答えられない(Fabric IQ 層が未整備)
- 「奨学金の申請条件は?」のような規程に基づく質問に、古い情報や不正確な回答を返してしまう(Foundry IQ 層が未整備)
- 最新の高等教育政策・他大学動向を踏まえた提案ができない(Web IQ 層が未整備)
- 各部局が独自に作った AI エージェントが乱立し、情報漏洩やなりすましのリスクが可視化されない(Agent 365 が未整備)
知識基盤の整備なしに Copilot ライセンスだけを配布することは、「検索エンジンのない図書館に本を並べる」ことに等しく、投資対効果が限定的になります。
3. 目指す姿: Copilot / Cowork が成果を出す大学の状態
知識基盤が整備された大学では、以下のような状態が実現します。
3.1 教職員にとって
- 新任教員が「本学の科研費申請の学内締切と必要書類は?」と尋ねると、最新の規程・過去の採択実績・担当部署の連絡先が、権限の範囲内で根拠(引用元)付きで提示される(Foundry IQ)。※回答は検索・引用に基づくものであり、最終判断は引用元の原本・担当窓口で確認することが前提
- 学部長が「今期の退学者数と、過去5年の傾向、関連する奨学金利用状況」を自然言語で質問すると、教務データと財務データを横断した分析結果がグラフとともに提示される(Fabric IQ)。
- 教員が会議の議事録・関連メール・共有ファイルを自動的に紐づけた状態で Copilot に相談でき、「あの件、どうなってる?」に即座に答えが返る(Work IQ)。
- 国際連携担当者が「海外大学の最新の単位互換制度トレンド」を質問すると、学内規程と最新の海外動向を踏まえた提案が得られる(Web IQ)。
3.2 学生にとって
- 学生ポータルの AI エージェントが、履修案内・奨学金・ハラスメント相談窓口などの公開・共通の案内を正確に提示する(個人の学籍情報に基づく個別案内は、本人認証・最小権限・最新データ接続を満たした後続フェーズの対象とする。詳細は第14章フェーズ1の留意点)。
- 研究室配属前の学生が、研究科の研究テーマ・教員の業績をオントロジー化されたデータから検索・比較できる。
3.3 経営層・事務局にとって
- 複数の部局エージェントが乱立しても、Agent 365 に登録済みのエージェントは Agent registry / Agent map で全学的に可視化され、リスクの高いエージェントを早期に特定・是正できる(未登録エージェントは別途の申請制・棚卸しで把握する)。
- 文部科学省報告や認証評価に必要なデータ集計が、部局横断のオントロジーにより迅速に行える。
- 個人情報・研究倫理に関わる質問には、対応する ACL 同期・感度ラベル・ユーザー委任実行が確認されたデータソースに限り、権限のない利用者には回答を返さない設計を徹底する。ただし、この統制は層・コネクタ・呼出し方式ごとの検証が前提であり、万能の保証ではない。
4. 投資対効果の考え方
知識基盤投資は、単体の ROI よりも 「どの業務課題に、どの層の整備が効くか」の対応関係で説明すると経営層の納得を得やすくなります。
| 経営課題 | 効く層 | 典型的な効果 |
|---|---|---|
| 教職員の事務作業負担が大きい(働き方改革) | Work IQ | 問い合わせ対応・資料作成・メール対応時間の削減 |
| 部局横断の経営判断に時間がかかる(IR・経営企画) | Fabric IQ | 学内データ集計・分析のリードタイム短縮、属人化の解消 |
| 規程・手続きの問い合わせが窓口に集中する | Foundry IQ | 問い合わせ件数の削減、一次対応の自動化 |
| 他大学・社会動向を踏まえた戦略立案が遅い | Web IQ | 情報収集時間の短縮、提案の質向上 |
| AI エージェントのシャドーIT化・ガバナンス不在 | Agent 365 | インシデント未然防止、監査対応の効率化 |
段階的に投資することで、各層ごとに効果を可視化しながら次の投資判断ができる点が、一括導入よりもリスクを抑えられるポイントです(詳細は第14章)。
4.1 経営層への依頼事項(意思決定サマリー)
本資料を踏まえ、経営層には次の4点の意思決定をお願いします。
| # | 依頼事項 | 判断内容 | 参照 |
|---|---|---|---|
| 1 | フェーズ0(準備)の開始承認 | 情報システム部門による既存環境の棚卸し・PoC対象部局の選定に着手してよいか | 第14章 フェーズ0 |
| 2 | 推進責任者の任命 | DX推進本部長(学長直轄/CIO相当)、および各部局のコンテンツオーナーを指名するか | 第15章 |
| 3 | KPI目標値の設定 | 第18章のKPI項目に、自学として許容できる目標値(例: 窓口問い合わせ件数の削減率)を今設定するか、フェーズ1の実績を見てから設定するか | 第18章 |
| 4 | 予算確保の次ステップ | フェーズ1(Foundry IQ中心)の概算予算化に向け、Microsoft 営業窓口への見積依頼を指示するか | 第16章 |
価格・ライセンス条件は変動するため、本資料は意思決定の「枠組み」を提供するものであり、最終的な予算承認には必ず最新の見積りを取得してください。
第II部 アーキテクチャ設計(IT部門・DX推進部門向け)
5. 全体アーキテクチャ設計方針
5.1 設計原則
大学向け知識基盤の設計にあたり、以下6つの原則を採用します。
- 4層は独立導入可能だが、段階的に積み上げる: Work IQ・Fabric IQ・Foundry IQ はそれぞれ独立したワークロードとして利用でき、Web IQ も単独で利用可能です。ただし大学では、まず問い合わせ対応の負荷が大きい Foundry IQ(規程・ナレッジ)から着手し、次に Work IQ(協働)、Fabric IQ(データ・オントロジー)の順に積み上げることを推奨します(理由は第14章参照)。
- 権限設計をデータ整備より先に固める(層ごとにゲートを分離): 権限制御の仕組みは層によって異なるため、フェーズごとに必要なゲートを分けて定義します。Foundry IQ(フェーズ1)のゲートは「ナレッジソース単位の ACL 同期・Purview 感度ラベル・文書オーナーの確定」、Work IQ(フェーズ2)のゲートは「Work IQ MCP 導入に伴う Rego ポリシー設計」です。Rego ポリシー設計の完了を Foundry IQ 先行着手の前提条件にはしません。
- 部局自治とガバナンスの両立: 全学の情報システム部門が「ガードレール」(アクセス制御方針、Agent 365 登録義務、監査ログ基準)を定め、各部局・研究科が「コンテンツ」(ナレッジソース、オントロジーの業務語彙)を自分たちで整備できる分担モデルを採用します。
- 既存システムを置き換えない: 教務システム・財務会計システム・研究支援システムなどの基幹系は置き換えず、OneLake ショートカット/ミラーリングや Foundry IQ のナレッジソース接続によって「意味の層」を上に重ねます。
- プレビュー機能は PoC から: 参照元によれば Fabric IQ 自体が preview ワークロードです。Ontology・Planning・Graph・Data agent・Operations agent を含む主要コンポーネントが、いずれもプレビュー段階にあります。Foundry IQ も一部機能(利用する Search Service REST API のバージョンに依存)がプレビューです。全学展開前に、採用予定の層・コンポーネント・API バージョン・コネクタ単位で GA/プレビューを棚卸しし、本番利用は GA 機能または承認済み例外に限定します。
- 権限・統制の表現は「保証」ではなく「層ごとの検証結果」として扱う: Entra ID・ACL 同期・Purview ラベル・Rego ポリシーはいずれも、対応するコネクタ・データソース・呼出し方式で機能することが前提です。「個人情報が漏れない」という表現ではなく、「どの層・どのデータソースで、どの統制が検証済みか」を明示します。
5.2 大学向け全体構成図
5.3 導入レイヤーと担当部署の対応
| レイヤー | 主担当 | 連携部署 |
|---|---|---|
| Work IQ | 情報システム部門(基盤) | 全部局(利用) |
| Fabric IQ | IR室・経営企画・情報システム部門 | 教務部、財務部、研究推進部 |
| Foundry IQ | 情報システム部門・各部局の規程所管課 | 総務・人事・学生支援・研究推進・国際連携 |
| Web IQ | 経営企画・広報・研究推進 | 情報システム部門(技術支援) |
| Agent 365 | 情報システム部門(全学ガバナンス) | 情報セキュリティ委員会、個人情報保護担当 |
6. レイヤー1: Work IQ ― 教職員・協働コンテキスト基盤
6.1 大学での位置づけ
Work IQ は Microsoft 365(Outlook / Teams / SharePoint / OneDrive)上の「人・協働・ワークフロー」を理解する層です。大学においては、教職員の日常業務(会議、メール、共有ファイル、委員会活動)を AI が横断的に理解できるようにする基盤として機能します。
6.2 構成要素の大学適用
| 要素 | 大学での適用例 |
|---|---|
| Chat | 学部事務室の AI エージェントが、教務部の専門エージェントに問い合わせを委任(A2A)し、専門的な回答を取得 |
| Context | 教授会・各種委員会の議事録、関連メール、共有ファイルを自動的にグラウンディングし、「前回の教授会で決まったことは?」に即答 |
| Tools | メール・カレンダー・ファイル・人物・チャット・SharePoint サイトへの統一アクセスにより、部局をまたいだ情報集約を実現(例: 入試委員会に関連する全情報の横断取得) |
| Workspaces | 大型の外部資金プロジェクト(科研費・受託研究等)において、複数部局・学外共同研究者が関わる長期ワークフローの中間成果物を SharePoint Embedded 上に永続化 |
6.3 実装上の留意点
- 権限はユーザースコープが原則: 学生の個人情報を含むメール・ファイルは、教職員個人がアクセス権を持つ範囲でのみ AI が参照できます。そのため、既存の SharePoint / Teams の権限設計(学部単位・委員会単位のサイト権限)を事前に棚卸しすることが前提になります。
- 部局間のサイロ解消は段階的に: 全学横断の Context 構築は、まず「全学共通のポータル的業務」(人事異動、全学行事、共通事務手続き)から着手します。学部固有の機密性が高い業務(入試関連等)は、別途アクセス制御を強化した上で対象化します。
- 大学側の作業範囲: Work IQ 自体は Microsoft 365 側が提供する能力であり、大学が「構築」するものではありません。具体的に大学が担うのは、M365 の情報アーキテクチャ(サイト構造・命名規則)の整備、既存権限の衛生状態の改善、共有ルールの明確化、および必要に応じた Work IQ API/MCP の接続設計です。
7. レイヤー2: Fabric IQ ― 大学の構造化データ・オントロジー基盤
7.1 大学での位置づけ
Fabric IQ は、学籍・財務・研究データ等の構造化データを「大学の業務語彙(オントロジー)」に引き上げ、人と AI エージェントの双方が同じ意味で解釈できるようにする層です。IR(Institutional Research)室や経営企画部門による全学データ分析の基盤として特に有効です。
7.2 3層構造の大学適用
| 層 | 大学における対象データ | 実装手段 |
|---|---|---|
| 統合データ | 教務システム(学籍・成績・履修)、財務会計システム、人事システム、研究支援システム(科研費等の外部資金)、施設管理システム | OneLake ショートカット(参照型、原本はシステム側に残す)または ミラーリング(複製・同期)+ OneLake カタログで統合 |
| ビジネスインテリジェンス | 入学者数・就職率・研究費獲得額・学生満足度等の KPI を Power BI セマンティックモデルとして整備(既存の IR ダッシュボードを流用可能) | Power BI セマンティックモデル |
| オペレーショナルインテリジェンス | 「学生」「科目」「教員」「研究課題」「外部資金」「入学者区分」等のエンティティと関係性を定義するオントロジー(プレビュー) | Fabric IQ Ontology |
7.3 大学向けオントロジー設計例
大学の業務語彙は部局を越えて再利用されるため、最小限のコアエンティティから始めることを推奨します。
- ブートストラップ手段: 既存の IR 用 Power BI セマンティックモデル(入学者数・GPA 分布等の KPI)がある場合、そこから DAX メジーをメトリクスとして引き継ぎ、オントロジー構築を迅速化できます。
- クロスドメイン推論の例: 「ある外部資金課題の研究代表者が所属する学部の、過去3年の退職者数」のような、通常は別システムに分断されている質問に、グラフトラバーサルで回答可能になります。
7.4 段階導入の前提
Fabric IQ の活用には、まず OneLake によるデータ基盤整備が前提となります。学内に散在する教務・財務・研究システムのデータを一度に統合するのは避けてください。まず IR 室が既に分析対象としているデータ(KPI ダッシュボード化済みのもの)から着手します。この順序により、投資対効果を早期に示せます。
8. レイヤー3: Foundry IQ ― 規程・シラバス・研究ナレッジ基盤
8.1 大学での位置づけ
Foundry IQ は、権限を考慮した(permission-aware)回答をエージェントに提供する、マルチソースのナレッジベース構築機能です。大学の規程・要項・FAQ・研究論文等、散在する非構造ドキュメントの一元的な知識化に直接対応するため、多くの大学にとって最初に着手すべき層になります。
8.2 大学におけるナレッジソース候補
| カテゴリ | 具体的なドキュメント例 | 想定読者 |
|---|---|---|
| 学則・規則集 | 学則、学位規程、ハラスメント防止規程、研究倫理規程 | 全教職員・学生 |
| 教務関連 | 履修要項、シラバス、単位互換規程、留学手続き | 学生・教員 |
| 人事・労務 | 就業規則、科研費執行ルール、出張旅費規程 | 教職員 |
| 学生支援 | 奨学金案内、就職支援情報、学生相談窓口情報 | 学生 |
| 研究関連 | 研究倫理審査基準、知財規程、研究データ管理方針、学内研究リポジトリ(論文・紀要) | 研究者 |
| 財務・契約 | 契約事務マニュアル、予算執行規程 | 事務局 |
8.3 構成要素の大学適用
| コンポーネント | 大学での役割 |
|---|---|
| Knowledge base | 「学生向け FAQ ナレッジベース」「研究者向け規程ナレッジベース」「事務職員向け業務マニュアルナレッジベース」等、利用者属性ごとに複数構築し、共有エージェントから参照 |
| Knowledge sources | SharePoint 上の規程フォルダ、Azure Blob Storage 上の研究リポジトリ、学内ポータルの公開 Web データ等を接続 |
| Agentic retrieval | 「留学中の学生が休学する場合の手続きと奨学金への影響」のような複合質問を、留学規程・休学規程・奨学金規程のサブクエリに自動分解して横断回答 |
8.4 権限設計の要点
- 学生向け FAQ は原則公開情報が中心ですが、奨学金案内の一部(所得要件に関わる細則等)は学内限定とするなど、ナレッジソース単位でのアクセス制御を設計時に確定させます。
- 研究倫理審査情報や治験関連文書など機微性の高いナレッジソースは、ACL 同期と Microsoft Purview 感度ラベルを必須とし、呼び出し元の Microsoft Entra ID で権限を強制する設計とします。
- Microsoft Copilot Studio エージェントとの接続により、学内ポータル・学生向けチャットボット等、既存のエージェント資産からも Foundry IQ のナレッジベースを再利用できます。
- 回答品質の設計: Foundry IQ は検索・引用に基づく回答を返す仕組みであり、規程の正確性・最新性・条件分岐の完全性を自動保証するものではありません。各ナレッジソースには文書オーナーと有効期限を設定し、規程改定時の再インデックスを義務化します。回答には必ず引用元を提示し、確信度が低い場合や対象外の質問には回答せず、有人窓口へ誘導する設計とします。
- GA/プレビューの確認: Foundry IQ は Knowledge base・Agentic retrieval を含め、利用する Azure AI Search の REST API バージョンによって GA/プレビューの機能が異なります。採用する機能・API バージョン・コネクタ単位で可用性を確認し、本番運用は GA 機能を基本とします。
9. レイヤー4: Web IQ ― 外部知見グラウンディング
9.1 大学での位置づけ
Web IQ は、学内に閉じない「社会・他大学・研究動向」の最新情報を回答に統合する機能です。経営企画・広報・研究推進・国際連携など、外部環境の変化を踏まえた意思決定が必要な部署で特に有効です。
9.2 想定ユースケース
- 中期計画策定時に「国内外の高等教育政策の最新動向」を自動収集
- 研究推進部門が「特定分野の国際的な研究トレンド」を Copilot 経由で把握
- 広報部門が「他大学の入試広報での AI 活用事例」を調査
9.3 ツール選定と留意点
| ツール | 大学での用途 |
|---|---|
| Web Search(推奨・GA) | 一般的な動向調査。ドメイン制限が必要な場合(文部科学省・特定学会サイトに限定する等)は Bing Custom Search リソースの作成が必要 |
| Grounding with Bing Search(GA) | 既存システムからの移行時、詳細なパラメータ制御(freshness・market 等)が必要な場合 |
| Grounding with Bing Custom Search(プレビュー) | 特定の学術データベース・政府系サイトのみに限定した調査が必要な場合 |
重要な留意点: Web グラウンディングツールは First Party Consumption Services であり、データが Azure のコンプライアンス/Geo 境界の外に出ます。附属病院の診療情報や治験データを扱う業務では、Web IQ の利用範囲を一般的な動向調査に限定し、機微データとは明確に切り分けて運用する必要があります。
10. 横断統制レイヤー: Microsoft Agent 365
10.1 大学での必要性
大学では、全学情報システム部門が把握しないまま、学部・研究室・事務局単位で独自の AI エージェント(Power Platform や Copilot Studio で作成された簡易エージェント等)が増殖しやすい環境にあります。Agent 365 は、Agent 365 に登録・統合され、対応ライセンスが有効化されたエージェントを横断的に可視化・統制・保護する基盤です。未登録のエージェントを自動的に発見する機能ではない点に注意が必要です。
10.2 3本柱の大学適用
| 柱 | 大学での適用 |
|---|---|
| Observe | Agent registry により、登録済みのエージェント(学生向けチャットボット、部局 FAQ ボット、研究室独自エージェント等)を一元登録・可視化し、稼働状況・リスクシグナルを早期検知 |
| Govern | 情報システム部門・個人情報保護担当・研究倫理委員会と連携し、エージェントのライフサイクル(作成申請→審査→公開→廃止)を一元管理 |
| Secure | Microsoft Entra のリスクベースアクセス制御、Purview の情報保護・DLP、Defender の脅威検知により、学生の個人情報や研究データを扱うエージェントを継続的に保護 |
10.3 導入の優先順位と未登録エージェント対策
エージェント数が少ないうちに Agent registry / Agent map を先行導入することで、登録済みエージェントについてはガバナンスの後追いを防げます。ただし、Agent 365 の可視化対象は登録済みエージェントに限られます。未登録のシャドー AI 対策には、別途の施策が必要です。具体的には、エージェント作成・調達の事前申請制、Power Platform 等のテナント設定によるガードレール、定期的な部局への利用状況ヒアリング・棚卸しを組み合わせます。知識基盤(Work/Fabric/Foundry/Web IQ)の整備と並行して、早期から Agent 365 の導入と未登録エージェント対策の両方を検討することを推奨します。
11. 大学特有データの分類とマッピング
大学が保有するデータを、どの IQ 層で扱うべきかマッピングした一覧です。導入計画の初期段階で、自学のデータ棚卸しに活用してください。
| データ種別 | 機微度 | 推奨する層 | 備考 |
|---|---|---|---|
| 教職員の業務メール・会議・ファイル | 中 | Work IQ | ユーザースコープでの権限制御が前提 |
| 学籍・成績データ | 高 | Fabric IQ | 個人情報保護法上の「個人情報」として学内最高レベルの保護分類を適用。マイナンバーを含むデータは別途「特定個人情報」として法定の厳格管理(利用目的の限定・安全管理措置等)を適用し、健康情報等は「要配慮個人情報」として区分する。オントロジー化は匿名化・集計レベルから開始 |
| 財務・人事データ | 高 | Fabric IQ | 経営層向け分析のみに利用範囲を限定することを推奨 |
| 研究データ(非公開) | 高〜最高 | Fabric IQ / 個別管理 | 研究倫理審査情報・治験データ等は、全学基盤への統合前に研究倫理委員会の承認プロセスを要する |
| 学則・規程・要項 | 低〜中 | Foundry IQ | 公開情報が中心だが、一部は学内限定 |
| シラバス | 低 | Foundry IQ | 原則公開情報 |
| 研究論文・紀要(学内リポジトリ) | 低〜中 | Foundry IQ | 公開済み論文は低機微度だが、未発表の研究内容は要アクセス制御 |
| 診療情報(附属病院) | 最高 | 対象外(別基盤) | 医療情報システムのガイドラインに従い、本知識基盤とは独立した扱いとすることを強く推奨 |
| 他大学動向・政策情報 | 低(公開情報) | Web IQ | 外部情報のため機密性の懸念は低いが、引用元の信頼性確認が必要 |
12. セキュリティ・ガバナンス・個人情報保護設計
12.1 権限設計の基本方針
| 仕組み | 適用層 | 大学での設計ポイント |
|---|---|---|
| Rego ベースのポリシーエンジン(Work IQ MCP) | Work IQ | リソースパス・メソッド・ユーザー ID・データ内容を考慮した実行時制御。学部単位・委員会単位の既存 SharePoint 権限と整合させる(Work IQ MCP を利用する場合の仕組みであり、A2A/REST は別途各 API の認証・認可要件を確認) |
| ACL 同期 + Microsoft Purview 感度ラベル | Foundry IQ | 規程文書に「全学公開」「教職員限定」「部局限定」等の感度ラベルを付与し、ナレッジソース取り込み前にラベリング体制を整備(対応するデータソースでのみ有効。未対応のコネクタでは別途アクセス制御を設計) |
| Microsoft Entra ID によるユーザースコープでの権限適用 | 層・コネクタごとに検証 | 呼び出し元のユーザー ID に基づき権限を強制する機能だが、対応状況は層・データソース・呼出し方式ごとに異なる。高機微データは、対応する ACL 同期・ラベル・ユーザー委任実行が確認できない限り対象外とし、導入前に受入基準(権限のない利用者に回答・引用が返らないことのテスト)で検証する |
12.2 個人情報保護法・研究倫理への対応
- 学生の成績データ(大学内で最高レベルの保護分類を適用する個人情報)や、健康情報等の要配慮個人情報に相当するデータがあります。これらをオントロジー化・ナレッジベース化する場合は、学内の個人情報保護担当部門・委員会、および必要に応じて研究倫理委員会による事前審査を導入プロセスに組み込みます。両者は法的な分類が異なるため、成績データを要配慮個人情報と同一視せず、それぞれの区分に応じた審査基準を適用してください。国の個人情報保護委員会等、規制当局への相談の要否は、法令または重大な個別事案に応じて判断します。
- 研究データについては、研究データ管理方針(DMP: Data Management Plan)との整合を確認し、本知識基盤への統合可否を研究者自身が判断できる仕組み(オプトイン型のナレッジソース登録)を推奨します。
- 附属病院の診療情報は、医療分野のガイドライン(医療情報システムの安全管理に関するガイドライン等)が優先されるため、本知識基盤とは独立したセキュリティドメインとして扱います。
12.3 監査・ログ
Work IQ のすべてのツール呼び出しはログ記録・評価されるため、情報システム部門はこれを監査証跡として活用し、個人情報保護監査・情報セキュリティ監査への対応に組み込むことを推奨します。
第III部 ユースケースと導入計画
13. 想定ユースケース(部局別)
| 部局 | ユースケース | 主に活用する層 |
|---|---|---|
| 教務部 | 履修相談・単位互換・留学手続きの自動一次対応 | Foundry IQ |
| 学生支援部 | 奨学金・ハラスメント相談窓口の案内、個人の学籍情報に応じた案内 | Foundry IQ + Fabric IQ |
| IR室・経営企画 | 入学者数・就職率・研究費等の部局横断分析、中期計画策定支援 | Fabric IQ + Web IQ |
| 研究推進部 | 科研費申請支援、研究動向調査、研究倫理審査の一次確認 | Foundry IQ + Web IQ |
| 人事部 | 就業規則・福利厚生に関する職員からの問い合わせ対応 | Foundry IQ |
| 国際連携部門 | 海外大学との単位互換制度調査、留学生対応規程案内 | Foundry IQ + Web IQ |
| 広報部 | 他大学の広報・入試戦略動向調査 | Web IQ |
| 情報システム部門 | 全学エージェントの可視化・統制、インシデント対応 | Agent 365 |
| 各学部・研究科事務室 | 教授会・委員会関連情報の横断検索、会議準備の効率化 | Work IQ |
14. 段階的導入ロードマップ
大学という組織特性(意思決定の合議制、予算年度サイクル、部局自治)を踏まえ、以下の4フェーズでの段階導入を推奨します。
フェーズ0: 準備(3〜6ヶ月)
- 情報システム部門主導で、既存の Microsoft 365 / Azure 環境の棚卸し(Entra ID 設計、SharePoint 権限、既存データ基盤の有無)
- 学内の個人情報保護担当部門・委員会、研究倫理委員会との連携体制の確立
- PoC 対象部局の選定(問い合わせ対応負荷が大きい部局を優先)
フェーズ1: Foundry IQ を核としたナレッジ基盤整備(6〜12ヶ月)
- 学則・履修要項・奨学金案内等、公開性の高い規程からナレッジソース化
- 教務部・学生支援部での FAQ 一次対応エージェントの PoC(対象は公開・共通情報への一般的な質問に限定し、個人の学籍・成績情報に基づく個別案内は対象外とする。個別案内は本人認証・最小権限・最新データ接続・有人エスカレーションを満たした上でフェーズ3以降に別ユースケースとして設計する)
- Microsoft Purview 感度ラベリング体制の確立(ナレッジソース単位の ACL・文書オーナーの確定をフェーズ1のゲートとする。Work IQ MCP 向けの Rego ポリシー設計はフェーズ2のゲートであり、本フェーズの前提条件にはしない)
- 採用する Foundry IQ の機能・API バージョン・コネクタについて GA/プレビューの状況を確認し、本番運用は GA 機能を基本とする
- 回答には引用元を必須とし、確信度が低い質問には回答せず有人窓口へ誘導する設計を組み込む
- 本フェーズを最優先するのは、投資対効果が最も見えやすく、部局横断のデータ統合を必要としないため着手が容易だからです。
フェーズ2: Work IQ 関連基盤の拡充(フェーズ1と並行〜12〜18ヶ月)
- 全学共通業務(人事異動、全学行事等)を対象に、M365 の情報アーキテクチャ(サイト構造・命名規則)の整備と既存権限の衛生状態の改善
- 委員会・教授会単位での協働エージェント活用の拡大、および必要な範囲での Work IQ API/MCP 接続(導入する場合は Rego ポリシー設計をこの段階のゲートとする)
- Agent 365 の Observe 機能(Agent registry)を先行導入し、登録済みエージェントについて PoC 段階からガバナンスを組み込む。あわせてエージェント作成・調達の事前申請制等、未登録エージェント対策も着手する
フェーズ3: Fabric IQ によるデータ・オントロジー基盤整備(18〜30ヶ月)
- IR 室の既存 Power BI セマンティックモデルを起点としたオントロジー構築 PoC
- OneLake によるデータ統合(教務・財務の順に、機微度の低いデータから着手)
- 部局横断分析ユースケースでの効果検証
- フェーズ1 の FAQ エージェントを基盤に、本人認証・最小権限・最新データ接続を満たした個人向け個別案内ユースケース(履修・奨学金等)の設計・PoC に着手
フェーズ4: Web IQ 活用拡大と全学ガバナンス確立(30ヶ月以降)
- 経営企画・研究推進・広報での Web IQ 活用拡大
- Agent 365 の Govern / Secure 機能をフル稼働させ、登録済み全学エージェントの審査・監査プロセスを常態化(未登録エージェントの定期棚卸しも継続)
- プレビュー機能について、採用コンポーネント単位で GA 状況を確認し、全学展開の可否を判断する。対象は Fabric IQ の preview ワークロード全体(Ontology・Planning・Graph・Data agent・Operations agent を含む)と、Foundry IQ の一部機能である。
各フェーズの期間は目安であり、大学の規模・既存システムの成熟度に応じて調整してください。重要なのはフェーズ1(Foundry IQ)を先行させ、早期に成果を可視化してから次フェーズへの予算確保につなげるという順序です。
15. 推進体制とガバナンス体制
15.1 推進体制(例)
15.2 役割分担
- 情報システム部門: Work IQ / Fabric IQ / Foundry IQ / Web IQ の技術基盤構築、Agent 365 の全学ガバナンス運用、Entra ID / Purview の権限設計
- 各部局(コンテンツオーナー): 自部局の規程・データをナレッジソース/オントロジーとして提供、精度のレビュー
- 学内の個人情報保護担当部門・委員会・研究倫理委員会: 機微データの知識基盤統合可否の審査
- DX推進本部: 全体の予算配分、フェーズゲートの意思決定、効果測定の統括
16. ライセンス・コストの考え方
| 機能 | ライセンス/課金の考え方 | 大学での留意点 |
|---|---|---|
| Work IQ | Microsoft 365 Copilot ライセンスと独立。Copilot ライセンス保有者は標準の Copilot 体験で利用可だが、カスタム/サードパーティエージェントはライセンス保有者でも従量課金。非保有者は利用量に応じた従量課金 | 教職員全員に Copilot ライセンスを配布するか、一部部局から段階導入するかに加え、部局独自エージェント(カスタム/サードパーティ)の想定稼働量を予算に織り込む |
| Fabric IQ | Microsoft Fabric のキャパシティ/SKU に準ずる | 既に IR 室等で Power BI Premium / Fabric を契約済みの場合、追加投資を抑えられる可能性がある |
| Foundry IQ | Azure AI Search の従量課金 + エージェント型検索のトークン利用量 | PoC は無料枠で開始可能なため、フェーズ1の初期費用は比較的小さい |
| Web IQ | Azure OpenAI 標準料金とは別に Web グラウンディング利用料が発生 | 利用部署を絞ることでコストを抑制できる |
| Agent 365 | ユーザー単位ライセンス(Microsoft E5 推奨) | 全学一律ではなく、エージェント管理責任者等、必要な職員から導入する方法も検討可 |
正確な価格は変動するため、予算策定時には必ず Microsoft Learn および Microsoft 営業窓口から最新情報を確認してください。
17. リスクと対応策
| リスク | 内容 | 対応策 |
|---|---|---|
| 個人情報・研究データの誤統合 | 機微データが権限制御不十分なまま知識基盤に取り込まれる | フェーズ1は公開性の高い規程文書から着手し、機微データは委員会審査を経てから統合 |
| 部局の抵抗・自治意識との衝突 | 「全学で統制される」ことへの学部側の反発 | コンテンツオーナーシップを部局に残し、情報システム部門は基盤提供に徹する分担モデルを採用 |
| シャドー AI エージェントの増殖 | 統制前にエージェントが乱立し、後から収拾がつかなくなる。Agent 365 は登録済みエージェントのみが可視化対象であり、導入だけでは未登録エージェントを捕捉できない | フェーズ2から Agent 365 の Observe 機能を先行導入するとともに、エージェント作成・調達の事前申請制、Power Platform 等のテナント設定によるガードレール、定期的な部局ヒアリング・棚卸しを組み合わせる |
| プレビュー機能の仕様変更 | Fabric IQ は preview ワークロード全体(Ontology・Planning・Graph・Data agent・Operations agent を含む)であり、Foundry IQ の一部機能等とあわせ、機能・名称が変更される可能性 | 採用機能・API バージョン単位で GA 状況を都度確認し、本番運用は GA 機能に限定、プレビューは PoC 止まりの期間を設ける |
| AI 回答への過信による誤案内 | Foundry IQ 等の回答を正式な規程判断として利用し、規程改定の反映漏れや条件分岐の見落としに気づけない | 引用元の明示を必須化し、確信度が低い場合や対象外の質問には回答せず有人窓口へ誘導。文書オーナーによる定期レビューと改定時の再インデックスを義務化 |
| 投資対効果が見えにくく予算が続かない | 大規模統合の効果が出るまで時間がかかる | フェーズ1(Foundry IQ)で早期に問い合わせ対応件数削減等の定量効果を提示し、次フェーズの予算確保につなげる |
18. 効果測定(KPI)
| 層 | KPI例 |
|---|---|
| Foundry IQ | 窓口問い合わせ件数の削減率、FAQ 一次解決率、引用元の提示率、重大誤案内率(抜き取り監査)、規程改定の反映 SLA 遵守率 |
| Work IQ | 会議準備・資料作成にかかる時間の削減、委員会関連の問い合わせ対応時間 |
| Fabric IQ | IR 分析のリードタイム短縮、部局横断レポート作成にかかる人日数の削減 |
| Web IQ | 外部動向調査にかかる時間の削減、一次情報・許可ドメインからの引用率、引用リンクの有効率 |
| Agent 365 | 登録済みエージェント数・登録率、未登録エージェントの棚卸しによる検知件数、インシデント対応時間 |
四半期ごとに DX推進本部がこれらの KPI をレビューし、次フェーズへの投資判断材料とすることを推奨します。
19. まとめ
大学が Copilot や Cowork といった Microsoft の生成 AI ソリューションから最大限の成果を引き出すには、ツールの配布だけでは不十分です。Work IQ・Fabric IQ・Foundry IQ・Web IQ という4層の知識基盤を Microsoft 365 / Azure 上に計画的に構築し、Agent 365 による全学統制を並行させることが不可欠です。
大学には、組織分散性・データの異質性・ガバナンスの二重性という特有の事情があります。これを踏まえると、導入順序は次のとおりとするのが、大学組織において最も現実的かつ効果を示しやすいアプローチです。まず投資対効果が見えやすい Foundry IQ(規程・ナレッジの一元化)から着手し、次に Work IQ(協働基盤)、Fabric IQ(データ・オントロジー)の順に段階的に積み上げ、Agent 365 によるガバナンスを早期から並走させます。
本資料で示したアーキテクチャ・データマッピング・ロードマップを出発点に、各大学の組織構造・既存システム成熟度に応じた詳細設計を進めることを推奨します。
20. 参考リンク
- Microsoft IQ ドキュメントハブ: https://learn.microsoft.com/en-us/microsoft-iq
- Work IQ overview: https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/work-iq
- Fabric IQ overview: https://learn.microsoft.com/en-us/fabric/iq/overview
- Foundry IQ overview: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq
- Web grounding tools overview (Foundry Agent Service): https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/web-overview
- Microsoft Agent 365 overview: https://learn.microsoft.com/en-us/microsoft-agent-365/overview
- 参照元社内資料:
projects/ms-iq/microsoft-iq-overview.md
本資料は Microsoft Learn の公開情報(2026年10月時点)を基に作成しています。Microsoft IQ は発展途上の製品群であり、機能・名称・GA 状況・価格は今後変更される可能性があります。実際の導入検討にあたっては、必ず最新の一次情報(Microsoft Learn)および Microsoft 営業窓口にご確認ください。また、個人情報・研究データ・診療情報等の機微情報の取り扱いについては、本資料の提案内容を基に、自学の学内個人情報保護担当部門・委員会・研究倫理委員会・情報セキュリティ委員会等の審査を必ず経てください。