AI時代の競争力は「モデル選び」ではない、サティアナデラ氏の「学習ループ所有」論を読み解く

Shinji Saito
Shinji Saito

代表取締役社長 / 文部科学省 最高情報セキュリティアドバイザー

シンジです。Microsoft CEOのサティア・ナデラ氏が、AI時代における企業のあり方を論じた長文をXに投稿し、国内外の複数のメディアが取り上げました。論調は「人的資本とトークン資本」「学習ループの所有」という経営・AI戦略の言葉で語られています。

この投稿の中身は実のところ情シス・セキュリティの所掌そのものです。「自社の知識・判断・評価・ログをどこに置き、誰がアクセスでき、どう監査するか」という問いは、AI戦略の皮をかぶったデータガバナンスとアクセス制御の問題です。そして、その土台にあるのは、多くの企業がまだ整理しきれていないSaaS・IDガバナンスの足元です。この記事では、ナデラ氏の主張を実務の設計問題に翻訳し、特に「学習ループを所有する前に整えるべき足元」に踏み込みます。

※本記事が参照するナデラ氏の投稿は米国時間2026年6月14日(日)になされたと報じられています(投稿原文上の日付は日本時間で午前0:33、2026年6月15日)。本文の主張は公開情報と一般化した実務論点に基づきます。

エグゼクティブサマリー

  • ナデラ氏は2026年6月、AI時代の企業は「最良のモデルを選ぶこと」ではなく「モデルの上に乗る学習ループを所有すること」で差がつくと主張した。鍵となる概念は「人的資本(Human Capital)」と「トークン資本(Token Capital)」である。
  • この主張はMicrosoftのポジショントーク(自社AI基盤の販売)でもある。それを差し引いても、情シス・セキュリティにとって本質的な論点が残る。
  • 本質とは「AIを使うほど、ナレッジ・プロンプト・評価・ログといった知的資産がベンダー側のツールに蓄積され、自社に残りにくくなる」構造であり、これは生産性の話ではなく、権限・分類・監査・退職者対応・DLPの設計問題である。
  • 学習ループは砂上に建てられない。 ユーザー軸の権限可視化、自動デプロビジョニング、棚卸し、台帳と実態の一致といったSaaS・IDガバナンスの足元が崩れたままAI検索・AIエージェントを乗せると、既存の不備がそのまま増幅される。
  • AIエージェントは新種のNHI(非人間ID)である。 棚卸しされず、オーナー不在で、半永久的に権限が付いたまま放置されたサービスアカウントやAPIキーは、AIエージェント時代に見落とされやすい攻撃面になる。
  • ベンダーロックインはゼロにできない。目標は「ゼロ化」ではなく「管理可能化」。便利なAIツールは使い倒しつつ、会社の中核資産(ナレッジ・プロンプト・評価基準・ポリシー・ログ)は自社側にも保持する。

NHIについては別の記事で詳しく解説しています。

何が起きているのか

米国時間2026年6月14日(日)、Microsoft会長兼CEOのサティア・ナデラ氏が、AI時代における企業のあり方を論じた長文をXに投稿しました。投稿の表題は「A frontier without an ecosystem is not stable(エコシステムのないフロンティアは安定しない)」です。報道各社の引用と投稿原文を突き合わせると、主張の骨子は次のとおりです。

  • 今回のAIへの移行は過去のどのプラットフォーム転換とも異なり、人間とデジタルシステムの間に「本物の認知ループ(a real cognitive loop)」を生み出す。
  • 企業は「人的資本(Human Capital)」と「トークン資本(Token Capital)」の双方を育てる必要がある。前者は従業員の知識・判断・関係性・創造性・パターン認識、後者は企業が構築し所有するAIの能力である。
  • トークン資本が増えても人的資本の価値は下がらず、むしろ上がる。「人間の方向づけがなければ、計算資源はただ空回りする」。
  • 真の機会は「最強のモデルを選ぶこと」にはなく、「モデルの上に学習ループを構築し、人的資本とトークン資本を複利で増やすこと」にある。「タスクや仕事は外注できても、学習だけは外注できない」。
  • 少数のAIモデルが全産業の価値を吸収する未来は、社会的にも政治経済的にも持続しない。だからこそ「フロンティアモデル」ではなく「フロンティア・エコシステム」が必要だ。

ここで一歩引いておきます。

この投稿は純粋な思想であると同時に、Microsoftのビジネス文脈とも切り離せません。報道では、Copilotのサブスクリプション収益やクラウドAI収益が巨額のデータセンター投資に見合うのかという疑問が市場にある、という背景が指摘されています。「自社の知識をベンダーに吸い取られず、自社で学習ループを持て」というメッセージは、裏を返せば「そのための基盤を提供できるのは自社だ」という売り込みにもなり得ます。

したがってシンジの立場は、この投稿を礼賛も否定もせず、「ベンダーのポジショントークを差し引いても残る本質」だけを抽出して実務に使う、というものです。そして差し引いても残る本質は、まさに情シス・セキュリティ担当者が向き合うべき設計問題です。

なぜ情報システム・セキュリティ担当者に関係するのか

「学習ループを所有する」を分解すると、次の問いになります。

  • どの社内知識をAIに使わせるのか(データ分類)
  • その知識に誰がアクセスできるのか(権限・最小権限)
  • AIが誰の権限で、どの情報を、どう使ったのかが追えるか(監査ログ)
  • 入力・出力はベンダー側にどれだけ残り、学習に使われるのか(保持・学習オプトアウト)
  • プロンプト・評価基準・ログを後から取り出せるのか(エクスポート可搬性)
  • 退職者や委託先のアクセスは、AIアクセスと連動して止まるのか(オフボーディング)

これらはすべて情シス・セキュリティの所掌です。つまり「学習ループの所有」は、突き詰めるとデータガバナンスとアクセス制御の設計に帰着します。そして、その手前にもっと地味で、もっと根深い問題があります。多くの企業では、AIを乗せる前のSaaS・ID基盤の段階で、すでに可視化と統制が追いついていないのです。

なお、ここで二つのリスクを分けておきます。

ひとつは「入力データがベンダーのモデル学習に使われる」リスク、もうひとつは「ナレッジ・評価・ログが自社に残らない」ロックインのリスクです。前者について、法人向けの主要なAIサービスは学習にテナントデータを使わない設定・契約が一般的で、たとえばMicrosoft 365 Copilotは「プロンプト・応答・Microsoft Graph経由のデータを基盤LLMの学習に使用しない」と公式に明記しています。したがって学習利用そのものは主に個人契約や未統制プランで問題化しやすく、法人利用で本質的に効いてくるのは後者のロックイン・可搬性・監査の設計問題です(保持・学習設定はプランや契約で異なるため、後述の確認ポイントで実機確認します)。

よくある誤解

誤解1:最強のモデルを選べば勝てる

モデルは今後も入れ替わり続けます。差がつくのは、使うたびに自社の判断基準やナレッジが改善されていく仕組みの有無です。

誤解2:ロックインはゼロにできる、ゼロにすべきだ

完全なノーロックインは幻想です。現実的な目標は「ゼロ化」ではなく「管理可能化」です。

誤解3:AI活用とは便利ツールの導入である

出力を一度使って終わりなら、それは消費です。出力の良し悪しの理由が評価データやプロンプトに戻って初めて、投資になります。

誤解4:学習ループは生産性の話で、セキュリティとは別である

同じものです。学習ループの設計は、そのまま「どの情報を、誰の権限で、どう蓄積・再利用するか」という権限・分類・監査の設計です。

誤解5:社内データを全部AI検索の対象にすれば賢くなる

最も危険な誤解です。権限設計のない全文インデックスは、これまで人間が偶然見つけにくかった機密情報を、AIが自然言語で簡単に掘り出す仕組みになります。賢くなる前に漏れます。

誤解6:AIを入れれば、ぐちゃぐちゃのSaaS環境も整理される

逆です。AIは既存の状態を増幅します。権限がSaaSごとにバラバラで、休眠アカウントや過剰権限が放置された環境にAIを乗せると、その混乱の上で回答が生成され、漏れも誤りも拡大します。

実務で問題になりやすいポイント(SaaS・IDガバナンスの足元)

ここからが、この記事で最も伝えたい部分です。AI活用の前提となるSaaS・IDガバナンスでは、企業の規模や業種を問わず、次の課題が繰り返し立ち上がります。いずれも導入時より運用開始後に表面化しやすく、監査や経営説明の場で問われやすいものです。

  • ユーザー軸の可視化ができない:SaaSごとに権限管理が分かれており、「この人が、どのSaaSの、どの情報にアクセスできるか」を横断で説明できない。サービス単位では見えても、人単位で束ねた像が作れない。
  • 権限付与・剥奪が手作業:申請・承認のあとに管理者が各SaaSを手で操作するため、付与漏れ・剥奪漏れ・タイムラグが慢性的に発生する。
  • 退職・異動のデプロビジョニング遅延:人事イベントとアカウント停止が連動せず、退職後もログインできる、異動後も旧権限が残る、といった状態が放置される。
  • 台帳と実態の乖離:申請→付与→台帳更新が連動しておらず、台帳が現実を反映していない。監査のたびに棚卸しを手作業でやり直し、毎回指摘される。
  • 申請入り口の乱立:SaaSごとに申請フォームや申請ルートが異なり、利用者は何をどこに申請すればよいか分からない。結果として「とりあえず広めに付与」が常態化する。
  • 休眠・過剰権限・広範な外部共有・MFA未適用:使われていないアカウント、必要以上に広い権限、意図せず外部公開されたままのリンク、多要素認証が掛かっていないアカウントが、棚卸しのたびに大量に見つかる。
  • 第三者SaaS連携(OAuthアプリ)の過剰スコープ:利用者が個別に許可したOAuth連携アプリが、広い読み取り・書き込み権限を持ったまま放置される。管理者の視界の外で、データへの常時アクセス経路が増えていく。

これらは、特定の誰かの怠慢ではなく、SaaSが部門ごと・用途ごとに増えていく中で構造的に生まれる「よくある状態」です。重要なのは、この足元が崩れたままAI検索やAIエージェントを乗せると、不備がそのまま増幅されるという点です。過剰権限のアカウントに紐づくAIは過剰な範囲を参照し、棚卸しされていない連携は監査の外で動き続けます。

「学習ループ」を回す前に確認すべき足元

ナデラ氏は「学習ループを所有せよ」と説きます。しかし学習ループは、整ったSaaS・ID基盤の上でしか安全に回りません。AIを乗せる前に、最低限ここを確認しておくべきです。

  • ユーザー軸の権限可視化:人単位で「どのSaaSの、どの権限を持つか」を一覧できるか。これがないと、AIの参照範囲も統制できない。
  • ロールベースの権限設計(RBAC):役割に基づいて権限が定義され、個別付与の積み重ねになっていないか。
  • 自動プロビジョニング/デプロビジョニング:人事イベント(入社・異動・退職)を起点に、SaaSのアカウントと権限が自動で変更・停止されるか。SCIM等でアカウント・属性・グループの連携が対象SaaSに行き渡っているか(細粒度の権限は各SaaS/IGA側で補う)。
  • 棚卸しの自動化と台帳の単一情報源化:手作業の棚卸しに依存せず、実態がそのまま台帳になっている状態か。
  • 申請ポータルの一本化:申請・承認・付与が一つの導線に集約され、記録が残るか。

これらは、IGA(Identity Governance and Administration)やIDライフサイクル自動化の領域そのものです。AI活用の前に足元を固めるという順序を踏むと、後段のAIガバナンスが一気に楽になります。逆に、足元を飛ばしてAIだけ先行させると、AIが既存の混乱を可視化・増幅し、収拾がつかなくなります。

AIエージェントは新種のNHIである

もう一つ、AI時代に避けて通れないのがNHI(Non-Human Identity/非人間ID)の問題です。NHIとは、人間ではなくアプリケーション・自動化プロセス・エージェントがシステム間で認証・認可を受けるためのデジタルアイデンティティの総称で、サービスアカウント、APIキー、OAuthトークン、シークレット(秘密鍵・証明書)などを含みます。

実務でよく見られるのは、次のような状態です。

  • いつ、誰が、何のために作ったのか分からないサービスアカウントが残っている。
  • そのアカウントにオーナー(責任者)が紐づいておらず、扱いを誰も決められない。
  • 「消す理由が見つからないから」という理由で、半永久的に権限が付いたまま放置されている。
  • MFAが掛からず、24時間365日稼働し、往々にして過剰な権限を持っている。

AIエージェントは、まさにこのNHIを使って動きます。エージェントはAPIキーやサービスアカウント、OAuthトークンを介してSaaSやデータにアクセスするからです。つまり、AIエージェントの導入は新しいNHIを大量に増やす行為であり、既存のNHIガバナンスが甘いまま進めると、攻撃面と過剰権限の問題が一気に膨らみます。

ナデラ氏の言う「トークン資本」を安全に積み上げるには、その前提としてNHIガバナンス(発見・オーナー紐付け・最小権限・短命化/ローテーション・ライフサイクル管理・異常検知)が必須です。AIエージェントに与える権限も、人間と同じく最小権限・時限付与・多段階の人間承認・監査可能の原則で扱うべきです。エージェントに「とりあえず管理者権限」を渡すのは、半永久付与のサービスアカウントを増やすのと同じ過ちです。

技術的・運用的な確認ポイント

ナデラ氏の言う「プライベートな評価(private evals)」「ナレッジベース」「学習ループ」を、自社で所有・統制可能な資産として設計するための確認観点です。SaaS・IDガバナンスの足元と一体で点検します。

1. 権限モデル(最小権限・権限継承)

AI検索・エージェントのインデックスが、元SaaSのACL(アクセス制御リスト)を正確に継承しているか。継承が日次バッチ等で遅延する場合、権限変更後のラグでの露出を許容できるか評価します。「全社員が見られる」前提のインデックスを安易に作らないことが原則です。

2. ユーザー軸の可視化

AIに紐づくアカウント(人間・NHI双方)が、どのSaaSのどの権限を持つかを横断で把握できるか。これが見えなければ、AIの参照範囲も統制できません。

3. データ分類

顧客情報・個人情報・経営情報・公開可能情報を分け、分類ごとにAI利用可否を定義します。分類のないままインデックス化すると、後から「この情報はAIに使わせてよかったのか」を遡及判定できなくなります。

4. 監査ログと出典表示

AIの回答に根拠の出典が表示されるか。誰がどの情報をAI経由で参照したかを後から追えるか。出典表示は精度向上だけでなく、機密情報の混入検知にも効きます。

5. データ保持とモデル学習オプトアウト

入力・出力がベンダー側にどの期間保持されるか。入力データがベンダーのモデル学習に使われない契約・設定になっているか。法人向けプランでも設定やプランで挙動が異なる場合があるため、契約条項と管理コンソールを実機で確認します。

6. NHIのライフサイクル

サービスアカウント・APIキー・OAuthトークンに、発見・オーナー紐付け・最小権限・ローテーション・廃止のサイクルがあるか。AIエージェントが使う認証情報も同じ統制下に置けるか。

7. IdP連動とオフボーディング

退職・異動・契約終了時、IdPの無効化に連動してSaaSとAIツールのアクセス・キャッシュが失効するか。SCIM等の自動デプロビジョニングの対象にAIツールが含まれているか。

8. エクスポート可搬性

プロンプト、評価データ、ポリシー、ログを取り出せるか。取り出せない資産は「自社所有」とは言えません。

9. 中間レイヤー(正規化・メタデータ・ACL付与)

原本は各SaaSに置いたまま、AIが使う形に正規化し、権限とメタデータを付けた中間レイヤーを持つ構成が現実的です。将来別のAIからも、各ツールのネイティブな権限継承または中間レイヤー側の認可のもとで、同じ知識を使えます。

SmartHR等の人事マスター(入社・異動・退職イベント)

IdP / IGA(ユーザー軸の権限を一元管理・自動プロビジョニング)

Notion / Drive / Slack / Box / GitHub(原本はそのまま)
        ↓ コネクタで取得
Markdown化・メタデータ化・分類・権限情報の付与(中間レイヤー)

Glean / Copilot / Claude / 社内エージェント から権限制御つきで利用

対応方針の比較表

「学習ループ」を構成する資産を、どこに置くかという観点での比較です。

方針概要メリットリスク・注意点向いている組織
ベンダー完結型ナレッジ・プロンプト・評価・ログを各AIツール内に置く導入が速い/運用負荷が低いベンダー閉じ込め/監査・エクスポートが弱い/乗り換えで学習が消えるまず小さく始めたい段階
中間レイヤー併用型原本はSaaSに、AI利用向け資産は自社の中間レイヤーにも保持ロックインを管理可能化/複数AIへ横展開/権限・監査を自社で握れる中間レイヤーの構築・運用が必要/正規化の設計コスト複数AIを使い分ける中堅〜大企業
フル内製型モデル・検索・評価基盤まで自社運用主権を最大化/要件に完全適合構築・運用負荷が大きい/人材要件が高い高い機密要件・専門人材を持つ組織

多くの企業にとって現実解は「中間レイヤー併用型」です。便利なAIツールのUI・検索・生成能力には依存しても、会社の中核資産は自社側にも残すという考え方です。

一方で、クラウドネイティブが支援した「世田谷区役所様のAI基盤」はAzureを利用した内製型でしたが、これは住民サービスという機微な情報を取り扱うためです。

導入・見直し時のチェックリスト

足元(SaaS・IDガバナンス)とAI活用を一体で点検します。

SaaS・IDガバナンスの足元

  • 人単位で「どのSaaSのどの権限を持つか」を横断で可視化できる
  • ロールベースで権限が定義され、個別付与の積み重ねになっていない
  • 人事イベントに連動して権限の付与・変更・停止が自動化されている
  • 棚卸しが自動化され、台帳が実態と一致している(単一情報源)
  • 申請・承認・付与が一本の導線に集約され、記録が残る
  • 休眠アカウント・過剰権限・広範な外部共有・MFA未適用を定期検出している
  • 第三者SaaS連携(OAuthアプリ)のスコープを棚卸し・統制している
  • サービスアカウント・APIキー等のNHIに、オーナーとライフサイクルがある

AI活用に乗せるとき

  • AIに使わせる社内知識を棚卸しし、分類(公開可能/社内/機密)を付けた
  • AI検索・エージェントのインデックスが元SaaSの権限を継承している
  • 「全社員可視」の前提でインデックスを作っていない
  • AI回答に出典が表示され、参照ログを後から追える
  • 入力データがベンダーのモデル学習に使われない設定・契約になっている
  • プロンプト・評価データ・ポリシー・ログをエクスポートできる
  • IdPでのアカウント無効化とAIツールのアクセス失効が連動している
  • AIエージェントに渡す権限を最小権限・時限付与・多段階の人間承認で扱っている
  • シャドーAI(個人契約AIへの情報流出)を可視化・統制する仕組みがある
  • 出力の修正理由を評価データとして残し、次回に反映する運用がある

経営層・監査部門への説明ポイント

  • 投資と消費の違い:AIの利用結果がナレッジ・評価・プロセスに戻れば投資、使い捨てなら消費。同じAI費用でも数年後の差が大きい。
  • 足元への投資効果:ユーザー軸の可視化、自動デプロビジョニング、棚卸しの自動化は、AIガバナンスの前提であると同時に、監査準備の負荷削減・退職者リスクの低減という形で単独でも効果が出る。
  • 主権(ベンダー非依存):汎用モデルを入れ替えても、自社固有の知識と判断が失われない状態を「主権」と定義し、その達成度を経営指標として示す。
  • 二重のリスク:無設計のAI活用は、知的資産のベンダー閉じ込め(事業リスク)と権限超過の情報露出(セキュリティリスク)を同時に生む。
  • 監査可能性:誰がどのAIで何を使ったかを追える状態は、インシデント対応・内部統制・規制対応の前提になる。
  • 段階導入:全社一括ではなく、リスクが低く成果が見えやすい領域から始める方針であることを明示し、過剰投資への懸念を払拭する。

実務担当者が次に取るべき対応ステップ(優先順位つき)

  1. 足元の現状把握:ユーザー軸の権限可視化、退職者・休眠・過剰権限・OAuth連携・NHIの棚卸し状況を、実機で確認する。
  2. ナレッジ棚卸しと分類:どこにどの知識があり、どの分類かを整理する。すべてをAI化する必要はない。
  3. 権限継承の検証:AI検索・エージェントの権限継承の実態を実機で確認する。
  4. 対象を3領域に絞る:価値が高く機密を管理しやすい領域(例:公開コンテンツ作成、提案・顧客回答、製品比較・技術検証)から始める。
  5. 資産を自社側にも置く:プロンプト・評価データ・ポリシーを自社管理し、複数AIへ横展開できる形にする。
  6. NHIとシャドーAIの統制:AIエージェントの認証情報を最小権限・時限で管理し、個人契約AIへの流出を可視化する。
  7. 学習ループを回す:出力→修正→修正理由の記録→評価データ化→次回反映、の循環を運用に定着させる。

まとめ(次に取るべき行動)

ナデラ氏の投稿が投げかける問いは、結局のところ次の一文に集約されます。

あなたの会社は、AIを使っているだけなのか。それとも、AIを使うたびに自社の知識と判断を蓄積しているのか。

この問いに「蓄積している」と答えるための条件は、生産性ツールの選定ではなく、権限・分類・監査・保持・可搬性というガバナンスの設計です。そして、その設計はSaaS・IDガバナンスの足元の上にしか成り立ちません。ユーザー軸で権限が見え、人事イベントに連動して権限が止まり、棚卸しが自動で回り、NHIにオーナーとライフサイクルがある、その土台があって初めて、AIの学習ループは安全に複利で回り始めます。

便利なAIは使い倒す。ただし会社の脳みそはベンダーの中に置かない。そして、その脳みそを支える足元を、ゼロトラストと最小権限の原則で固める。これがAI時代の「学習ループ所有」の実装です。

FAQ

Q1. ナデラ氏の言う「学習ループ」とは何ですか。

業務の発生→AIによる下書き・判断補助→人間のレビュー→修正・採用・却下の理由の記録→ナレッジ・プロンプト・評価基準への反映→次回出力の改善、という循環です。この循環を自社で所有できるかが競争力になる、という主張です。

Q2. 「トークン資本」と「人的資本」の違いは何ですか。

人的資本は従業員の知識・判断・関係性・創造性・パターン認識です。トークン資本は企業が構築し所有するAIの能力(システムやモデル、蓄積した評価・改善履歴)です。ナデラ氏は、トークン資本が増えても人的資本の価値は下がるどころか、むしろ価値が上がると述べています。

Q3. AIを入れる前に、なぜSaaS・IDガバナンスが先なのですか。

AIは既存の状態を増幅するからです。権限がバラバラで休眠・過剰権限が放置された環境にAIを乗せると、その混乱の上で回答が生成され、漏れも誤りも拡大します。ユーザー軸の可視化や自動デプロビジョニングといった足元が、AIガバナンスの前提になります。

Q4. AIエージェントとNHIはどう関係しますか。

AIエージェントはAPIキー・サービスアカウント・OAuthトークンといった非人間ID(NHI)を使って動きます。エージェント導入はNHIを増やす行為であり、既存のNHIガバナンス(発見・オーナー紐付け・最小権限・ローテーション)が甘いまま進めると、過剰権限と攻撃面が一気に膨らみます。

Q5. 社内データを全部AI検索の対象にすれば便利になりますか。

権限設計がないまま全文インデックス化すると、本来アクセスできない機密情報をAIが回答に混ぜるリスクがあります。便利さの前に、元SaaSの権限継承と機密分類の設計が必要です。

Q6. シャドーAIとは何が問題ですか。

会社が統制していない個人契約のAIサービスに社内情報が貼り付けられ、可視化も監査もされないまま、ベンダーの学習に使われる可能性があることです。情報漏えいと統制不能の二重リスクになります。

Q7. ベンダーロックインは避けるべきですか。

完全に避けるのは現実的ではありません。目標は「ゼロ化」ではなく「管理可能化」です。AIツールの利便性には依存しても、ナレッジ・プロンプト・評価・ログという中核資産は自社側にも保持し、乗り換え可能な状態を保つことが現実解です。

Q8. 最初に何から始めるべきですか。

足元の現状把握(ユーザー軸の権限可視化、休眠・過剰権限・OAuth連携・NHIの棚卸し)から始め、その上でナレッジ棚卸しと分類、価値が高く機密を管理しやすい3領域に絞った試行へ進むのが無難です。全社一括導入は避けます。

CTA

自社のAI活用が「消費」で終わっていないか、知的資産がベンダー側に閉じ込められていないか、そして何より、AIを乗せる前のSaaS・IDガバナンスの足元が整っているか。この点検は、ゼロトラスト・IDガバナンス・SaaSセキュリティ・監査ログの設計と一体で進めると効果的です。

クラウドネイティブでは、ユーザー軸の権限可視化とIDライフサイクル自動化、休眠・過剰権限・OAuth連携・NHIの棚卸し、AI検索・AIエージェント導入時の権限継承と機密分類の設計、シャドーAIの可視化、IdPと連動したアクセス統制、AI利用ポリシーと監査・DLPの整備といった観点から、現状整理と設計・運用の見直しをご一緒できます。「便利なAIは使い倒しつつ、会社の中核資産は自社に残す」状態をどう作るか、まずは自社状況の整理からご相談ください。

社内データを全てAI用のインデックスにするサービス

宣伝ですが、クラウドネイティブでは社内情報を個人の権限を引き継ぎながら、丸ごとインデックス化してAIに食わせるサービスとして、現時点で史上最強の「Glean」を活用しています。Gleanは、中堅・エンタープライズ向けに設計されたSaaSで、オンプレミスのデータのインデックス化や、完全な自社ホストでの構築展開などが可能な特徴を持っています。AIを活用したエンタープライズサーチとしても機能します。ご興味ある方はこちらもお問い合わせいただければ詳細にご案内いたします。

参考情報

この記事をシェア