PR：本記事にはアフィリエイト広告（プロモーション）を含みます。
AIエージェントのデータ基盤とは、エージェントが読めるデータ、エージェント自身の権限、エージェントの行動の記録という3つの層のことです。エージェントは委譲された権限で複数の業務システムに触れて行動するため、データを整えるだけでは動きません。3層のうち最も抜けやすいのは記録です。
整える順番は、記録を先に薄く敷き、次に権限を絞り、データの範囲を最後に広げます。最初の1体で必要なのは、読み取り専用のID、取得方式を書いた台帳1枚、ツール実行まで残るログの3つです。
- データ層：全社文書を整えるのではなく、どの領域をどの方式で取りにいくかを1枚の台帳に書く
- 権限層：エージェントごとに専用のIDを持たせ、担当業務の範囲にだけ権限を絞る
- 記録層：回答だけでなく、どのツールをどの権限で呼んだかまで残す
AIエージェントを動かすのに、なぜ専用のデータ基盤が要るのか？
エージェントは委譲された権限を持ち、複数の業務システムに同時に触れて行動するためです。Microsoftは、この性質が従来のアプリケーションとは異なる組織的なリスクを生むとし、すべてのエージェントが動き出す前に満たすべき最低要件を、ガバナンスとセキュリティの基準線として定めるべきだとしています。
Microsoftは企業向けガイダンス「Govern and secure AI agents across the organization」で、AIエージェントを、データにアクセスし、意思決定を行い、業務システムをまたいで行動できるソフトウェアシステムだと定義しています。
Microsoftは、エージェントが委譲された権限で動作して複数のシステムに同時に影響を与えうる点を、従来のアプリケーションとは異なる組織的リスクの源として挙げています。
データ側の依存関係も明示されています。Microsoftは「Data architecture for AI agents across your organization」で、エージェントは情報を作るのではなく統合するため、その精度は元となる情報源の品質とアクセス可能性に完全に依存すると述べています。
Microsoftは同じデータアーキテクチャのガイダンスで、分断された、あるいは統治されていないデータが、誤解を招く結果とセキュリティリスクの両方につながるとしています。
3層の分け方は次のとおりです。
| 層 | 答えるべき問い | 整っていないと起きること |
|---|---|---|
| データ | エージェントが読める形になっているか | それらしいが根拠のない回答が返る |
| 権限 | 誰の権限で、どこまで動けるか | 見せてはいけない情報に届く／止められない |
| 記録 | 何をしたかが残っているか | 原因を特定できず、改善も評価もできない |
Microsoftは、エージェントのガバナンスで方針を決めるべき領域を、コントロールプレーン、データガバナンスとコンプライアンス、セキュリティ、開発標準の4つとして整理しています。コントロールプレーンには、所有者、ID、ライフサイクル管理、そして可観測性が含まれます。本記事の3層は、Microsoftの4領域を、意思決定する側から見て「何を用意すれば動かし始められるか」の単位に畳み直したものです。
RAGの構築は、3層のうち第1層の一部にすぎません。この仕組みから考えると、エージェントは読むだけでなく書き込む・実行するため、検索基盤を作っただけでは第2層と第3層が空のまま残ります。委譲された権限で行動するという性質が、権限と記録を新しく必要にしています。
AIエージェントで業務を自動化するとなると、AI用のデータ基盤をうまく設計する必要が出てきます。データ基盤を設計するというのは、私の言い方をすればAIに仕事を教えることです。
エージェントとワークフローの違い、どんな業務なら使うべきかという判断はAIエージェントとは？ワークフローとの違いと実務で使う条件で解説しています。本記事は、使うと決めた後に自社で何を用意するかに限定します。
エージェントに渡すデータは、どこまで整っていればよいのか？
文書をきれいにするより先に、どのデータをどの方式で取りにいくかを1枚の表に書き出すところまでです。Microsoftは、業務領域ごとに取得方式を検索・API・その両方に分類して記録し、どのデータ源が認定済みか、どのAPIが認証を要するか、どの権限が適用されるかまで書くべきだとしています。
Microsoftは「Data architecture for AI agents across your organization」で、データ計画は技術的な実装で終わりではなく、AIエージェントがどう情報にアクセスするのかを文書化する責任が経営側にあると述べています。
Microsoftは同じデータアーキテクチャのガイダンスで、文書化がないと、どのシステムをエージェントが使い、それらがどう相互作用するのかについてチームが曖昧さを抱えることになるとしています。
書き出し方も具体的に示されています。Microsoftは、エージェントが支える主要なデータ領域を列挙し、領域ごとに取得方式を検索・API・その両方という明確な分類で記録することを出発点に置いています。同ガイダンスが挙げる例は次の3行です。
- 製品のFAQ：ナレッジインデックスを使った検索
- 注文の追跡：受注管理システムへのAPI呼び出し
- 返品ラベルの発行：配送システムへのAPI呼び出し
台帳は、データ整備の終わりを定義する装置です。「全社の文書を整える」という目標には終わりがありませんが、「台帳に載っている領域だけ整える」なら終了条件が決まります。Microsoftが分類を出発点に置いているのは、範囲を先に閉じるためだと読めます。
台帳には統制の情報も同じ場所に書きます。Microsoftは、どのデータ源が認定済みか、どのAPIが認証を要するか、どの権限が適用されるかを明記するよう求めています。この時点で台帳は、データの一覧であると同時に第2層（権限）の入力になります。
読み取り専用で足りるのか、作成・更新まで要るのかも早い段階で決めます。Microsoftは、照会のために読み取り専用のアクセスで足りるシステムと、レコードの作成・更新のために読み書きが要るシステムがあり、この区別がセキュリティ統制とコンプライアンス要件を左右するため、役割を早期に定義して不必要なリスクを避けるべきだとしています。
なお、静的な文書は検索、リアルタイムの照会はAPIというように取得方式が混在する場合、Microsoftはどの領域にどちらを当てるのかとその理由を台帳に書き添えることを勧めています。
例えば、社内の問い合わせ対応を担当するエージェントを1体作る場合に、規程類は検索、在庫の残数はAPIというように領域を4〜5行だけ書き出して着手する、という進め方が考えられます。想定例であり、何行から始めるかは対象業務の広さで変わります。
フォルダを直接読みに行かせる構成は、それだけで良い結果になることが中々ありません。フォルダ直読みにはコンテキスト汚染のおそれもあるため、手前でデータを整備する必要が出てきます。データ基盤という言葉で私が指しているのは、この整備の部分です。
ファイルがいくつかあって、どれが最新版なのかが人が見ても分からないケースがあります。最新版がどれなのかを管理する仕組みが要り、私の実務ではしっかりとタグをつけるといった手当てがここに入ります。
固有名詞のように、その企業でしか通じない独特の言葉を扱う場面でも、データの整備は避けられません。辞書のようなものを用意しておく必要があり、私はこれもAI用のデータ基盤の構成要素として扱っています。
文書を機械が読める形に整える具体的なやり方（メタデータの持たせ方、非テキスト情報の扱い、チャンキング）はRAGにおけるデータクレンジングの重要性で扱っています。
検索の仕組みを1本作る手順そのものはRAG導入の手順は？社内データで失敗しない進め方で解説しています。第1層で本記事が担当するのは、どの領域をどの方式で取るかという台帳の設計だけです。
エージェントは誰の権限で動くべきか？
エージェントごとに専用のIDを持たせ、担当する業務の範囲にだけ権限を絞るのが原則です。Microsoftは、エージェントの行動は一意のIDに帰属し追跡できなければならないとし、IDと権限の範囲、使えるツール、監査可能性の4つを、自律性を広げる前に決めておくべき設計要件としています。
Microsoftはゼロトラストの設計パターン「Least privilege for AI agents」で、エージェントを導入するとセキュリティの問いが変わると述べています。タスクを完了できるかどうかではなく、どのリソースに対して、誰の権限のもとで、その操作を許してよいのかを一つひとつ問うことになる、というのが同パターンの整理です。
ID自体の要件も明確です。Microsoftは企業向けガイダンスで、すべてのエージェントに単一のIDを要求し、エージェントの行動が一意のIDに帰属して強制可能でなければならないとしています。人のアカウントを借りて動かしている状態は、この要件を満たしません。
エージェント専用のIDと、利用者の権限を借りる方式のどちらを選ぶのか？
Microsoftは、共有シークレット、サービスプリンシパル、「利用者の代理」モードが混在すると、どの主体がその行動に責任を負うのかが不明確になることを、IDの曖昧さという課題として挙げています。混在そのものが問題であり、どちらの方式にも寄せていない状態が最も追跡しづらくなります。
権限の継承についても指針があります。Microsoftは、エージェントが利用者に代わってデータへアクセスする場合は、その利用者の権限を継承させ、問い合わせの際に利用者のIDやトークンを安全に引き渡すべきだとしています。
専用IDと権限の継承のどちらを選ぶかは、扱うデータの見え方で決まります。人ごとに見える範囲が違うデータを扱うなら利用者の権限を継承させ、決まった範囲を機械的に処理するならエージェント専用のIDを立てる、という分け方です。どちらを選んでも、行動が一意のIDに帰属するという要件は変わりません。
権限はどうやって絞るのか？
Microsoftは、エージェントにはその機能に必要な特定のデータ源だけへのアクセスを与え、組織の全データへの広いアクセスを与えてはならないとしています。同社は、文書を横断して要約するエージェントの例で、対象のワークスペースに範囲を限定した読み取り専用のロールを示しています。
読む権限と書く権限は分けます。Microsoftは、チケットを作成・更新するエージェントの例で、証拠を集める読み取りロールと、チケットを作成する書き込みロールを分離し、作成・更新の操作だけを許可リストに載せて削除と管理操作を遮断し、一括更新には人の承認を要求する構成を示しています。
権限を最初に決める理由は、後から狭める機会がほぼ来ないためです。Microsoftは、チームがパイロットを止めないために広いロールを与え、業務が安定した後もスコープを狭めないまま放置するという権限の肥大化を、典型的な課題として挙げています。この構造から考えると、最初の1体で決めておくほうが安くつきます。
権限の強さは時間で絞る方法もあります。Microsoftは、ライフサイクル管理された安定したIDは維持したまま、一時的なロールの有効化・短命なトークン・承認といった仕組みで権限を時間限定にし、高い権限が特定の業務の実行中だけ存在するようにする形を推奨しています。
望ましいのは、AIエージェントの権限を利用者本人の権限と紐づけて管理する形です。社内のID基盤と紐づけて権限を渡すところまでやるべきだ、というのが私の立場です。
AIエージェントを入れると見てはいけない情報が見えてしまう、という話にもなりがちです。ただし私の見立てでは、それはそもそもの権限管理・情報管理の問題でしかありません。
エンタープライズでAIエージェントを実用するとなると、権限まわりの安全性の担保は慎重に行わざるを得ない、というのが私の実感です。
個人でチャットツールを使うのと、企業がエージェントを業務システムにつなぐのとでは、決めることの数が変わります。両者の距離は生成AIの企業活用と個人活用は何が違うのかで整理しています。本節が扱うのは、組織としてIDと権限の範囲をどう決めるかです。
エージェントが何をしたかは、どう残せばよいのか？
最終的な回答だけでなく、どのツールをどの権限で呼んだかまで残します。Microsoftは、ログが会話の応答しか記録しておらず、その裏で実行されたツールの操作や権限の範囲、下流の認可の判断が残っていないことを、エージェント運用で弱くなりがちな監査証跡として挙げています。
Microsoftは「Least privilege for AI agents」で、フォレンジックや規制当局の照会に必要となるのは、相関IDを伴ったツールの操作・スコープ・認可の判断であり、ログはしばしばチャットの応答しか捉えていないと指摘しています。会話ログは残っているのに調査ができない、という状態がここで生まれます。
残す項目も列挙されています。Microsoftが挙げるのは、エージェントのID、ロール、実効的な権限の範囲、操作、対象リソース、相関ID、そして該当する場合は「誰の代理か」の7項目です。7項目はそのまま第3層の設計仕様として使えます。
組織として何を把握すべきかも同じ方向を向いています。Microsoftは企業向けガイダンスで、すべてのエージェントは可観測で、統治され、セキュアでなければならないとし、経営側はどのエージェントが存在し、誰が所有し、何にアクセスでき、方針から外れた挙動のときにどう介入するかを把握していなければならないとしています。
記録が無いと、具体的に何ができなくなるのか？
3つのことができなくなります。失敗の切り分け、渡した権限が適正だったかの事後検証、そして評価の3つです。記録が無い期間の挙動は、後からログを足しても復元できません。
- 失敗の原因が回答の生成にあるのか、検索にあるのか、ツールの実行にあるのかを切り分けられない
- 渡した権限が広すぎたのか適正だったのかを、事後に検証できない
- 評価しようにも、評価する対象の記録が存在しない
エージェントの評価方法そのものは別の主題です。本記事が言えるのは、評価は記録の層の上に載るということまでで、経路やツール呼び出しをどう採点するかには踏み込みません。
検索と生成のどちらを疑うかという切り分けはRAGの精度が上がらない原因は？検索・データ・生成で切り分けるで解説しています。切り分けの手順が使えるのは、切り分けるための記録が残っている場合だけです。
コストも第3層に載ります。Microsoftは、AIエージェントが計算能力・トークン・API呼び出しといった資源を消費し、可視性がないとコストが急速に膨らむとしています。同社は、部門やプロジェクト単位で利用とコストを一元的に見る仕組みを作り、予算の閾値に近づいた時点で通知するアラートを設定することを勧めています。
記録の型は、Microsoft以外でも整備が進んでいます。OpenTelemetryは生成AI向けのセマンティック規約として、エージェントの呼び出しやツールの実行を単位に、どのエージェントが、どのモデルで、どれだけのトークンを使い、どう失敗したかを共通の形式で残す取り決めを策定しています。
記録の項目が標準化されつつあるという事実自体が、自前で項目を決め切る必要はないという判断材料になります。ただしOpenTelemetryの生成AI向け規約は、リポジトリ上でスキーマのURLが未確定のまま公開されており、2026年8月時点では策定途上です。
3層はどの順で整えればよいのか？
記録を先に薄く敷き、次に権限を絞り、データの範囲は最後に広げます。Microsoftは、最初から厳格な統制を課すと開発を止めて革新を妨げるとして、まず監査に基づくモデルで挙動を観察してパターンを特定し、必要に応じて段階的に統制を強めることを勧めています。
Microsoftは、ガバナンスは統制と機動力のバランスを取る必要があるとし、いきなり制限をかけるのではなく監視から始めるアプローチを業務チームと一緒に定義することを勧めています。段階を踏むこの進め方は、ガードレールを時間をかけて磨きながら、混乱を最小限に抑えるためのものだと同社は説明しています。
観察の前提として、台帳がもう1つ要ります。Microsoftは、エージェントのレジストリを維持し、所有者・目的・稼働する基盤・アクセス範囲を記録することを求めています。追跡されていない「シャドー」の配備はセキュリティとコストの両方のリスクになり、存在を知らないエージェントは統治できない、というのが同社の言い方です。
配布と利用促進は成果が目に見えるため進みますが、基盤は成果が見えないため後回しになります。この非対称から考えると、順番を先に決めておくこと自体が対策になります。監査から始めよという一次資料の推奨は、裏側を薄くでも先に立てておく指示として読めます。
先に作ることのコストも併記します。Microsoftは、最小権限の設計には4つのトレードオフがあるとしています。設計の初期工数が増えること、ライフサイクル管理の運用が複雑になること、影響の大きい操作に摩擦が生まれること、そして下流のシステムが正しく認可を再検証することに依存することの4つです。
止め方も順序に含めます。Microsoftは、不具合や被害が出たときにどうやって素早くエージェントを止めるかをあらかじめ決め、フォレンジックのためにログを保全する手順を計画に含めるよう求めています。同社は、トークンが残る、鍵が共有されている、下流のシステムが認可を再確認しないといった理由で停止が不完全になると、インシデント対応が遅れるとも指摘しています。
なお、1体のエージェントを作る順序と、組織で複数体を動かす基盤を整える順序は別の話です。1体を作る順序はAIエージェントとは？ワークフローとの違いと実務で使う条件で扱っています。本節が示したのは、複数体が増えていく前提での基盤側の順序です。
小さく始める場合、どこまで作らなくてよいのか？
最初の1体では、読み取り専用のID、取得方式を書いた台帳1枚、ツール実行まで残るログの3つで足ります。Microsoftも、エージェントの利用が限定的なら既存のガバナンスの場で足りる場合があるとし、環境が小さければ初期の導入では手作業の管理でも十分な場合があるとしています。
Microsoftの記述で重要なのは、統制の仕組みを新設するかどうかを利用の広がりで判断している点です。同社は、複数の事業部門をまたいでエージェントが使われる段階になったらガバナンスを見直し、権限を伴う形で責任を明文化するよう求めています。逆に言えば、1体しか動いていない段階で組織を作る必要はありません。
最小セットの3つは、後から足すと作り直しになるものだけで構成しています。読み取り専用で始めれば書き込み権限の設計は後回しにできますが、記録は事情が違います。ログを後から足しても、それ以前の期間に何が起きていたかは永遠に復元できません。
台帳を1枚に留める理由も同じです。Microsoftが求めているのは領域と取得方式の分類であって、全社のデータカタログではありません。この構造から考えると、1体目の台帳は数行で足り、エージェントが増えるたびに行を足していく形が自然です。
例えば、社内規程を検索して答えるだけのエージェントを1体目に置き、読み取り専用のIDを1つ発行し、台帳を3行書き、ツール実行のログを取り始める、という始め方が考えられます。想定例であり、書き込みを伴う業務を1体目に選ぶなら、権限の分離と承認の設計を先に足すことになります。
よくある質問
AIエージェントのデータ基盤は誰の仕事ですか？
層ごとに担当が分かれます。第1層のデータは対象領域を業務側が決めて取得方式と品質をデータ側が持ち、第2層の権限はIDの発行と範囲の設定を情報システム・セキュリティ側が持ち、第3層の記録は何を残すかを開発側が実装します。この分け方から考えると、3層をまとめて1部門に投げた場合、どの層も中途半端なまま止まります。
AIエージェントを入れると、既存のアクセス権限の設計は作り直しになりますか？
作り直しにはなりません。Microsoftは、利用者に代わってデータへアクセスする場合はその利用者の権限を継承させ、エージェント自身が動く場合は一意のIDに紐づけるという2つの型を示しており、既存の権限設計を組み替えるのではなくエージェントという新しい主体を足すのが基本形です。作り直しが要るのは、そもそも人の権限が業務単位で分かれていない場合です。
エージェントのログはどれくらい残せばよいですか？
保持期間は、規制と社内方針から逆算して決めます。Microsoftは、ログ・メモリ・学習データに保持期間を定め、機能に必要な文脈だけを残すよう自動的な削除や匿名化の処理を実装することを求めていますが、具体的な月数は公開ガイダンスに示されていないため自社の規程に合わせます。保持期間を決めていないログは、増え続けるコストと消せない個人データという2つの負債になります。
AIエージェントの基盤づくりは何から学べばよいですか？
3層のうち、自社に無い層から学びます。台帳が無いなら取得方式の分類から、権限が人のアカウントの流用で回っているならIDと権限の設計から、ログが会話の記録だけなら観測の設計からで、3層とも空なら記録から着手すると後戻りが最も小さくなります。手を動かしながら体系的に学び直すならキカガクの生成AI講座のような社会人向けのコースも選択肢になります。
まとめ
AIエージェントのデータ基盤は、エージェントが読めるデータ、エージェント自身の権限、行動の記録の3層です。データを整えるだけでは動かず、最も抜けやすいのは記録です。整える順番は、記録を薄く敷き、権限を絞り、データの範囲を最後に広げます。
最初の1体に要るのは、読み取り専用のID、取得方式を書いた台帳1枚、ツール実行まで残るログの3つです。
PR
3層のうち、自社に無い層から埋める
権限の設計や記録の項目は、公式ガイダンスを読むだけでは自社の構成に落ちません。手を動かしながら学ぶなら、AI・データサイエンスに特化した社会人向けオンラインスクールのキカガクが、生成AIを業務で使うためのコースを提供しています。講座の選び方そのものは生成AI講座の選び方｜社会人が失敗しない4つの基準で整理しています。
※ 説明会の参加は無料です。受講費用、開講日程、カリキュラムの詳細は公式サイトで最新情報を確認してください。
データの整備からIDと権限の設計まで担える人がどんな条件で求められているかは、機械学習・データサイエンス領域の案件条件を見ると具体的に分かります。転職や独立の予定がなくても、相場と要件を把握しておく価値はあります。
にほんブログ村
