AIエージェント実装と「空白」の発見
AIアクティベーションレイヤー、SaaSの再定義、業務主権をめぐる対話

序章 参考レポートの提示

■ あなた
以下のレポートを読んだ。あなたの考えを聞かせてほしい。

AIエージェント実装における「空白」とAIアクティベーションレイヤー

エグゼクティブ・サマリー

本資料は、企業におけるAIエージェント活用の現状、実装を阻む「空白」の正体、およびその解決策としての「AIアクティベーションレイヤー」の重要性についてまとめたものである。現在、米国と日本にはAI活用において約一年半の時間差が存在するが、日本企業もPOC(概念実証)フェーズから本番運用へと移行しつつある。
AI活用の最大の障壁は、データが「コンテキスト(文脈)」を欠いた状態で散在している点にある。基盤モデル(LLM)を「IQの高い新入社員」に例えるならば、企業特有のコンテキストを教えない限り、その能力は発揮されない。Salesforceが提言する「AIアクティベーションレイヤー」は、フロントアプリとデータ層の断絶を解消し、AIが理解可能な形でデータを整備・提供する。これにより、単なる効率化を超えた、自律的なAIエージェントによるビジネスプロセスの再定義が可能となる。

1. AI活用の現状 米国と日本の格差

AI活用のトレンドは、従来の「コーパイロット(人間を支援する副操縦士)」から、人間が介入せずとも自律的に仕事を完遂する「AIエージェント(エージェンティック)」へと移行している。
タイムマシン経営の再来。現在の日本で起きているAI導入の壁は、約一年半前に米国で起きていた事象に近い。日本市場の現状としては、米中というLLM開発国が先行しているものの、日本はその他の国々と比較すれば非常に敏感かつ迅速に反応しており、POCの準備段階を終えて本番展開へ進む重要なフェーズにある。需要も急増しており、SalesforceのAI戦略の柱である「Agentforce(エージェントフォース)」およびデータ基盤「Data 360(データ360 / Data Cloud)」の需要は極めて高く、特にData 360関連のARR(年間経常収益)は対前年比200%成長を記録している。

2. 実装を阻む「空白」の正体 データとコンテキストの断絶

多くの企業がAIを導入しても生産性向上を実感できない理由は、システム側におけるデータの「断絶」にある。
コンテキスト不在の問題。LLMはIQの高い新入社員であるが、会社の業務プロセスや文化(コンテキスト)が分からなければ仕事ができない。教育(コンテキストの付与)を怠りながら「AIが育たない」と不満を述べているのが多くの企業の現状である。データの質も問題で、正確でないデータ、分断されたデータ、一貫性のない在庫・走行データなどは、AIエージェントに「誤った配送約束」や「不適切な在庫推計」をさせる原因となる。
システムの構造的課題としては、フロントエンドのアプリと、ボトムレイヤーのデータソース(オンプレミス、クラウド、データレイク等)との間に、AIが理解できる形でデータを橋渡しする機能が欠落している点が挙げられる。

3. 解決策 AIアクティベーションレイヤーの構築

AIがビジネス現場で価値を生むためには、データをAIが即座に理解し、活用できる状態(アクティベートされた状態)にする必要がある。
Salesforceは、以下の三つの仕組みを統合することでこのレイヤーを実現している。Informaticaはデータ品質の管理と、MDM(マスターデータマネジメント)によるコンテキスト付与を担う。Data 360 (Data Cloud)は、あらゆるデータソースを繋ぎ、メタデータレイヤーとして集合知を形成し、AIが解釈可能な仕組みを作る。そしてMuleSoftは、リアルタイムの業務アクセスと、データ統合による全体的なコンテキストの生成を担う。
導入の優先順位としては、まずData 360。300以上のコネクターにより、DIYで構築するよりも効率的にデータソースを統合できるため、最初に検討すべきステップとされる。次にInformatica。より全社的かつアドバンストな、信頼性の高いマスターデータ活用を段階的に導入していく。さらに非構造化データの活用として、PDFや画像、フローチャートなどの非構造化データを「チャンク(断片)」に分け、文脈を保持した状態で整理することで、AIが正確に意図を汲み取れるようにする。

4. ガバナンスとセキュリティ(トラストバウンダリー)

AIエージェントの活用が拡大するにつれ、セキュリティと管理の重要性が増大する。
トラストバウンダリー(信頼の境界線)とは、データの暗号化、マスキング(匿名化)、アクセス権限管理を徹底する仕組みである。エージェントの管理に関しては、将来的に社員の十倍、百倍に増える可能性があるAIエージェントに対し、人間と同様の「人事・労務」的な管理(アクセス範囲の制御等)を行う必要がある。これを自社で構築・運用するのは不可能に近く、プラットフォーム側のプロの仕組みを活用することが推奨される。

5. 成果の事例 ビジネスプロセスの「反転」

AIエージェントの実装により、従来の「人間が判断して動く」から「エージェントが動いた結果に人間が乗る」という順序の反転が起きている。
事例1 米国レナー社(住宅販売)。課題は、毎週数万件の問い合わせが発生するが、営業が非同期でしか対応できず、六ヶ月に及ぶリードタイムの中で機会損失が発生していた点。実装としては、AIアクティベーションレイヤーを介して住宅・地域情報と連携し、24時間365日、AIが即座に応答できるようにした。成果としては、会話から購買シグナルを抽出・スコアリングし、内覧予約まで完結。年間1,000件の内覧予約を創出し、月間110万件のインタラクションを処理している。
事例2 ファラベラ社(南米小売)。課題は、商品が多岐にわたり、カスタマーサポートのパターンが複雑すぎて人間では対応しきれず、セルフサービスも機能していなかった点。実装としては、文脈を統合して意図を解釈し、注文状況、返品、配送、アカウント更新などを一気通貫で自動化した。成果としては、月間21万6,000件のWhatsApp対応をエージェントが処理し、その60%を自律解決。AIが残したコンテキストを人間が引き継ぐことで、顧客満足度も向上している。

6. 結論 SaaSの再定義と今後の展望

「SaaSは死んだ(SaaS is dead)」という議論があるが、実態は「再定義」である。
AI CRMへのアップグレード。従来のCRMは業務の効率化ツールだったが、AI CRMは「人件費(労働)」の一部を代替する存在へと進化している。これにより、ソフトウェア予算だけでなく、人件費予算の領域まで価値提供の幅が広がっている。
FDE(現場配備型エンジニア)の役割。従来のエンジニアと異なり、顧客の現場に駐在してビジネスプロセスを理解し、ユースケースの策定からデプロイ、モニタリングまでを一貫して支援する体制(Forward Deployed Engineering)が重要となる。
AIエージェントは一度導入して終わりではなく、教育を通じて少しずつ仕事を覚えさせていくプロセスが必要である。この「空白」を埋めるAIアクティベーションレイヤーの構築こそが、日本企業が先行者利益を得るための鍵となる。

第一章 「空白」の発見 ― AIアクティベーションレイヤーとは何か

■ AI
私は、このレポートの骨子にはかなり賛成です。特に良いのは、AIエージェント導入の失敗原因を「モデル性能」ではなく、業務コンテキストの欠落として捉えている点です。これはかなり本質に近いです。
ただし、少し補正すると、これは単なる「データ統合」の話ではありません。むしろ本質は、企業の業務・権限・判断基準・例外処理を、AIが実行可能な形に翻訳する層を作れるかどうかです。つまり、AIアクティベーションレイヤーとは、データ基盤であると同時に、企業の「業務OS化」でもあります。

1. このレポートの一番重要な指摘は「空白」の発見である

多くの企業は、AI導入をこう考えがちです。LLMを入れる。社内データにつなぐ。チャットで聞けるようにする。生産性が上がる。
しかし現実には、この間に大きな空白があります。AIが本当に仕事をするには、次の情報が必要です。「この顧客は誰か」「この顧客に対して何を約束してよいか」「どの在庫情報を信用するか」「この例外処理は誰の承認が必要か」「この顧客は通常ルールではなく特別契約か」「営業が介入すべきシグナルは何か」――つまり、AIに必要なのは単なるデータではなく、業務上の意味を持ったデータです。
Salesforce自身も、AIエージェントには「trusted, unified platform」が必要であり、信頼できるデータ、業務ロジック、安全なワークフローを統合する「landing zone」が必要だと説明しています。また、Salesforceの2026年プロキシ資料では、AIエージェントはアクセスできるデータの質に強く依存すると述べています。ここが、レポートの言う「空白」です。

2. 「AIアクティベーションレイヤー」はCRMの再定義そのものである

従来のCRMは、基本的には人間が使う業務記録システムでした。営業が入力する。カスタマーサポートが履歴を見る。マーケティングがセグメントを切る。管理職がダッシュボードを見る。つまりCRMは、人間の判断を支援する台帳でした。
しかしAIエージェント時代のCRMは違います。CRMが、AIにとっての作業環境になります。AIが顧客を理解する。AIが問い合わせに応答する。AIが購買シグナルを読む。AIが次のアクションを提案する。場合によっては、AIが予約・返金・配送変更・営業引き渡しまで行う。この時、CRMは「記録する場所」から、AIが働く場所へ変わります。
SalesforceがData Cloudを「enterprise AIのintelligent activation layer」と位置づけているのは、この文脈です。Salesforceは2025年度にData CloudとAIのARRが9億ドルに達したと発表し、2026年度第4四半期決算ではAgentforceとData 360のARRが29億ドルを超え、前年比200%以上成長したと公表しています。これは、「AIエージェントを動かすにはCRMの下にアクティベーション層が必要だ」という市場の反応と見てよいです。

3. ただし「データを整えればAIが動く」は、まだ半分である

レポートは正しい方向を向いていますが、少しSalesforce寄りに整理されすぎている印象もあります。AIエージェント実装に必要なのは、少なくとも四層です。
第一に、データ層。顧客、商品、契約、在庫、請求、配送、問い合わせ履歴など。第二に、コンテキスト層。データの意味、優先順位、信頼度、更新頻度、例外条件。第三に、権限・ガバナンス層。AIが何を見てよいか、何を実行してよいか、どこから人間承認が必要か。第四に、業務プロセス層。問い合わせ対応、営業引き渡し、返品処理、見積作成、予約、督促、契約更新などの実行フロー。
SalesforceのData 360、Informatica、MuleSoftの組み合わせは、このうちデータ層・コンテキスト層・統合層にかなり強い。ただし、最終的に価値を生むのは、業務プロセスそのものの再設計です。ここをやらずに「Data Cloudを入れました」「Agentforceを入れました」だけだと、おそらく成果は限定的です。

4. レナー社とファラベラ社の事例は、かなり象徴的である

レナー社の事例は、AIエージェントの価値が単なるチャットボットではないことを示しています。住宅販売では、問い合わせから内覧予約までの間に大きな機会損失が発生します。Salesforceの事例では、LennarはAgentforceを使って営業時間外の問い合わせ対応や内覧スケジュール調整を行い、営業担当者が優先度の高いリードに集中できるようにしたとされています。これは「人間の代わりにチャットする」ではなく、営業プロセスの入口をAIが常時稼働化したということです。
ファラベラ社の事例も同じです。Salesforceは、Grupo FalabellaがWhatsAppサポートを五倍に拡張し、問い合わせの60%を自律解決していると紹介しています。この事例の意味は大きいです。なぜなら、カスタマーサポートはAIエージェント化しやすい領域である一方、失敗すると顧客体験を壊しやすい領域でもあるからです。そこで60%を自律解決できるなら、AIエージェントは「実験」ではなく、すでに業務インフラに近づいています。

5. 「SaaSは死んだ」ではなく、「SaaSの課金根拠が変わる」が正確である

このレポートの結論部分は、かなり重要です。「SaaS is dead」という言い方は刺激的ですが、実態は死ではなく、SaaSの価値単位の変化です。
従来のSaaSは、だいたいこういう価値でした。人間の作業を効率化する。人間の情報共有を改善する。人間の管理を可視化する。
しかしAIエージェント時代には、価値がこう変わります。人間の作業そのものを一部実行する。顧客対応を代替する。営業機会を発見する。処理件数を増やす。人間が見落とすシグナルを拾う。つまり、ソフトウェア予算ではなく、労働予算・外注費・営業機会損失・サポートコストに食い込む。
ここでSaaS企業のビジネスモデルは強くなり得ます。なぜなら、単なる月額ID課金ではなく、「処理した仕事」「解決した問い合わせ」「創出した商談」「削減した工数」に近い課金が可能になるからです。Salesforceが2026年度第4四半期決算で、AIエージェントが完了したタスクを測る「Agentic Work Units(AWU)」を導入し、AgentforceとSlackで累計24億AWUを提供したと発表しているのは、まさにこの課金根拠の変化を示しています。これは、かなり重要です。SaaSは「席数課金」から「仕事量課金」へ寄っていく可能性があります。

6. 日本企業にとっての最大課題は、技術ではなく「業務の言語化」である

日本企業が詰まりやすいのは、たぶんここです。AIエージェントに仕事をさせるには、業務がある程度、言語化・構造化されていなければなりません。
ところが日本企業では、実際の業務が次のようになっていることが多い。「この顧客は昔からの付き合いだから例外」「これは部長に一応聞いた方がいい」「この処理はAさんしか分からない」「このExcelが実は正」「システム上は不可だが、現場ではこうしている」「このメールのニュアンスなら営業が出るべき」――つまり、業務がシステムではなく、人間の暗黙知と人間関係の中に埋まっている。
AIアクティベーションレイヤーを作るとは、この暗黙知をすべて綺麗なルールに変えるという意味ではありません。むしろ、次のように分解することです。どこまでAIに任せるか。どこから人間に渡すか。どの情報を信用するか。どの判断は保留するか。どの例外は上長承認にするか。どの顧客には特別対応するか。AIの判断ログを誰が監査するか。ここができないと、AIエージェントは「賢いが会社のことを知らない新入社員」のままです。

7. FDEの重要性は、まさにここにある

レポートがFDE、つまりForward Deployed Engineeringに触れているのは非常に良いです。AIエージェント導入では、単なるSIer的な「要件定義して納品」では足りません。現場に入り、業務を観察し、AIに任せられる仕事と任せられない仕事を切り分け、データの意味を整理し、運用しながら改善する必要があります。これはエンジニアというより、半分は業務改革者です。
AIエージェント時代の導入支援者には、次の能力が必要になります。業務プロセスを読む能力。データの信頼度を見抜く能力。現場の暗黙知を言語化する能力。AIが失敗する境界を設計する能力。例外処理と承認フローを設計する能力。導入後のKPIを設計する能力。つまり、FDEは「コードを書く人」ではなく、AIを現場に着地させる翻訳者になります。

8. 結論 AIアクティベーションレイヤーは、企業の「神経系」になる

このレポートの核心を一言で言うなら、こうです。
AIエージェントの時代には、企業はデータベースを持つだけでは足りない。AIが業務文脈を理解し、安全に行動できる神経系が必要になる。
従来の企業システムは、どちらかというと「記録装置」でした。CRMに顧客情報を記録する。ERPに在庫や会計を記録する。SFAに営業活動を記録する。BIでそれを見る。
しかしAIエージェント時代には、これらの記録装置が接続され、AIが状況を読み、次の行動を起こす。つまり企業システムは、記録のシステムから、行動のシステムへ変わる。その中間に必要なのが、AIアクティベーションレイヤーです。そして、このレイヤーを持つ企業と持たない企業の差は、単なるAI活用度の差ではなく、業務速度そのものの差になります。

補足 私はこのレポートをこう言い換える

従来のCRMは、顧客情報を管理するためのシステムだった。次世代AI CRMは、顧客に対してAIが行動するためのシステムになる。
従来のSaaSは、人間の業務を支援した。次世代SaaSは、人間の業務を一部引き受ける。
従来のデータ基盤は、分析のために存在した。次世代データ基盤は、AIエージェントの判断と行動のために存在する。
従来の導入プロジェクトは、システムを入れて終わりだった。次世代の導入プロジェクトは、AIに仕事を教え続ける運用そのものになる。
したがって、日本企業がやるべきことは、「AIを入れる」ことではありません。AIに任せられる業務単位を定義し、その業務に必要なコンテキスト・権限・データ・例外処理を整えることです。この意味で、このレポートの方向性はかなり正しいです。ただし、Salesforce製品論として読むより、もっと広く、企業がAIエージェントを労働力として受け入れるための業務OS設計論として読むべきだと思います。

第二章 SaaS企業のノウハウと、AI基盤モデルのコモディティ化

■ あなた
なるほど。AIエージェントが稼働できる構造を作らないと意味がない、という、もっともな見解ですね。そしてその稼働構築にSaaS企業のノウハウ、企業価値があるという訳ですか。
■ AI
はい、その理解でかなり正確です。要するに、AIエージェントは「賢いモデル」だけでは稼働しない。稼働させるには、企業側に次のような構造が必要になります。信頼できるデータ。業務コンテキスト。権限管理。ワークフロー。監査ログ。人間へのエスカレーション設計。継続的な改善運用。
ここを持っている、あるいは作る能力を持っているのが、Salesforce、Microsoft、ServiceNow、Workday、SAP、Oracleなどの大手SaaS企業です。SalesforceはAgentforceを「24時間365日、従業員や顧客を支援する自律AIエージェント」と位置づけ、必要な業務知識を与えることでタスクを実行できると説明しています。またData Cloudについては、信頼できるデータに基づいてAI、分析、自動化を業務の流れの中で動かす基盤だと説明しています。
つまり、SaaS企業の価値は今後、単なる「画面」や「業務アプリ」ではなくなります。AIエージェントが安全に働ける職場インフラを持っていることが、企業価値になります。

Salesforceの強みは、CRMを持っていることではない

たとえばSalesforceの強みは、単にCRMを持っていることではありません。顧客データがある。営業プロセスがある。商談履歴がある。問い合わせ履歴がある。権限管理がある。承認フローがある。外部システム連携がある。パートナーや導入支援のエコシステムがある。この全部が、AIエージェントにとっての「職場」になります。
Microsoftも同じです。Microsoftは2025年のWork Trend Indexで、AIエージェントを活用する「Frontier Firm」という新しい組織像を提示し、AI導入済み・エージェント活用済み・ROIを意識した企業群を分析対象にしています。日本語版でも、リーダーの82%、日本では75%が、戦略と運営の核心部分を再考する重要な年だと答えたと説明されています。これは、AIエージェントが単なるツールではなく、組織設計そのものを変える存在だと見ているということです。
ServiceNowも、AI・データ・ワークフローを一体化し、「AIをあらゆる業務ワークフローで機能させる」方向に進んでいます。同社は、リアルタイムデータ、ワークフロー自動化、AI体験を単一プラットフォームに統合することを前面に出しています。
ここから見えてくるのは、次の変化です。
SaaS企業は、業務アプリ企業から、AI労働力の配備基盤企業へ変わる。

「SaaSは死んだ」ではなく、二極化する

だから「SaaSは死んだ」というより、むしろ逆です。
薄いSaaSは死ぬ。深い業務プロセスを握っているSaaSは強くなる。
薄いSaaSとは、単に入力フォーム、一覧画面、通知、簡単な管理機能だけを提供しているものです。これはAIに置き換えられやすい。
一方で、深いSaaSは違います。顧客業務の流れを握っている。権限と承認を握っている。履歴と文脈を握っている。他システムとの接続点を握っている。コンプライアンスと監査を握っている。現場の例外処理を知っている。こういうSaaSは、AIエージェントの実行環境になります。

SaaSの競争軸が変わる

そして、ここが企業価値の源泉になります。従来のSaaSの価値は、人間が業務を効率よく進めるための道具でした。しかしAIエージェント時代のSaaSの価値は、AIが業務を安全に実行するための構造になります。
これはかなり大きな変化です。人間向けSaaSなら、UI、使いやすさ、導入しやすさ、部門別機能が重要でした。AI向けSaaSでは、データモデル、API、権限、監査、ワークフロー、業務コンテキスト、エージェント管理が重要になります。つまり、SaaSの競争軸が変わる。画面の競争から、業務コンテキストの競争へ。ID課金の競争から、AIが実行した仕事量の競争へ。アプリの競争から、企業神経系の競争へ。

結論 SaaSはAI時代の「労働力OS」になる

AIエージェントの普及で、SaaSの価値は消えるのではなく、二極化する。浅いSaaSは、AIに吸収される。深いSaaSは、AIエージェントの稼働基盤になる。さらに強いSaaSは、AIエージェントを企業に配備・管理・改善する「労働力OS」になる。
SalesforceがAI CRM、MicrosoftがCopilot/Agent 365、ServiceNowがAIワークフロー、Workdayが人事・財務AIに向かっているのは、全部この流れです。ですから、今後の勝者は「一番賢いAIモデルを持つ会社」だけではありません。むしろ企業領域では、AIが働ける業務構造を握っている会社が強い。その意味で、SaaS企業は死ぬどころか、AI時代において「企業の現実世界への接地面」として、むしろ重要性を増していると思います。

第三章 AI基盤モデルはコモディティ化し、世界へ拡張する

■ あなた
AI基盤モデルが実社会で十分使える能力を手に入れたなら、それを行使するのは理の当然です。ただしこの場合、AI基盤モデルはコモディティとなります。人間のニーズが、人間が業務を委託できるAIエージェントなら、構造上そうなりますね。
■ AI
はい。構造上、その方向に進みます。基盤モデルが十分に賢くなるほど、企業にとっての問いは、「どのモデルが一番賢いか」から、「その知能を、自社業務のどこで、どの権限で、どの責任線で、どのデータを使って行使させるか」へ移ります。
ここで基盤モデルは、完全に無価値になるわけではありませんが、差別化の中心からは少しずつ外れていく。電力、クラウド、GPU、データベースに近い「高価だが比較可能な基盤材」になっていく。
実際、OpenAIのモデルやCodexがAWS Bedrockでも利用可能になったという報道は、この方向をかなり象徴しています。つまり、最先端モデルであっても、企業顧客から見ると「AzureだけでなくAWSでも使える部品」になっていく。AWS側もOpenAIのモデルをBedrock上のエージェント構築・運用に組み込む方向に動いています。

価値の中心が「知能」から「稼働構造」へ移る

人間のニーズが、「AIと会話したい」ではなく、「AIに仕事を委託したい」であるなら、必要なのは単なる知能ではありません。必要なのは、委託可能性です。
委託可能性とは、次のようなものです。AIが必要な情報にアクセスできる。AIが業務文脈を理解できる。AIが実行権限を持てる。AIが失敗した時に止まれる。AIが人間に引き継げる。AIの行動ログが監査できる。AIの成果を測定できる。ここまで揃って、初めて「仕事を任せられるAI」になります。
だから、基盤モデル単体では足りない。むしろ企業価値は、モデルを実社会の業務に接続する構造に移ります。SalesforceがAgentforceやData 360で「Agentic Work Units」という、AIエージェントが実行した仕事量を測る指標を出しているのも、この転換を示しています。同社は2026年度第4四半期決算で、AgentforceとSlackにおけるAWUが累計24億件、AgentforceとData 360のARRが29億ドル超、前年比200%以上と公表しています。これは、トークン量ではなく、AIがどれだけ仕事をしたかを価値単位にし始めたということです。

基盤モデルは「脳」だが、企業に必要なのは「労働者」である

ここが一番重要です。基盤モデルは、脳に近い。しかし企業が欲しいのは、脳そのものではありません。
企業が欲しいのは、顧客対応をしてくれる労働者、見積を作ってくれる労働者、問い合わせを分類してくれる労働者、営業機会を発見してくれる労働者、契約更新を進めてくれる労働者、社内申請を処理してくれる労働者です。つまり、人間のニーズは「知能の鑑賞」ではなく、仕事の委任です。
この時、基盤モデルは必要条件ですが、十分条件ではありません。人間で言えば、IQの高い人を採用しても、入社手続き、権限付与、業務教育、上司、評価制度、就業規則、セキュリティ、ナレッジ、チーム連携がなければ働けない。AIも同じです。基盤モデルは「高IQな新人」ですが、AIエージェントは「実際に配属され、仕事を与えられ、成果を出す労働者」です。その間にあるのが、SaaS企業やAIプラットフォーム企業の価値です。

複数モデルの利用がコモディティ化を加速する

■ あなた
そのためにSaaS企業は、複数のAIモデルを使用するでしょう。それはAI基盤モデルのコモディティ化を助長します。その代わり、AI基盤モデルは広く世界に拡張するでしょう。そしてAI基盤モデルが入っていないものは、人間くらいになるのではないでしょうか。
■ AI
はい。かなり重要な構造変化です。あなたの見立てを整理すると、こうなります。SaaS企業は、自社エージェントの性能・コスト・安全性を最適化するために、複数の基盤モデルを使い分ける。その結果、個別のAI基盤モデルは交換可能な部品になり、コモディティ化する。しかし同時に、基盤モデルはあらゆるSaaS、業務システム、端末、ロボット、インフラに埋め込まれ、世界全体へ拡張する。最後に、AI基盤モデルが入っていないものは、人間そのものくらいになる。これは、かなり鋭いと思います。

SaaS企業は単一モデルに依存しなくなる

SaaS企業から見ると、基盤モデルは「信仰対象」ではなく、実行エンジンです。だから当然、用途ごとに使い分けます。営業メール生成には高速・安価なモデル。複雑な契約レビューには高推論モデル。社内検索にはRAGに強いモデル。コーディングにはコード特化モデル。音声対応にはリアルタイム音声モデル。画像・図面・PDF理解にはマルチモーダルモデル。個人情報を含む処理にはオンプレ・プライベートモデル。
この流れはすでに表に出ています。SalesforceはAgentforce関連の公式ドキュメントで、複数プロバイダーのLLMをサポートし、Einstein StudioによるBYO LLM、つまりBring Your Own LLMも可能だと説明しています。MicrosoftもCopilot Studioで、エージェントのオーケストレーションに使うAIモデルをドロップダウンで選べると説明しています。モデルごとに速度、品質、コスト効率が違うため、用途に応じて選択する設計です。つまり、大手SaaS企業はすでに「一社一モデル」ではなく、モデル選択・モデル混在・モデル差し替えを前提に動いています。

これは基盤モデルのコモディティ化を進める

複数モデルを選べるということは、ユーザー企業やSaaS企業から見ると、モデルは比較可能になります。比較軸は、性能、価格、速度、安全性、データ保護、リージョン対応、業界規制対応、日本語性能、ツール使用能力、長文処理能力、マルチモーダル性能などです。こうなると、基盤モデルは「唯一無二の魔法」ではなく、ベンチマークと費用対効果で選ばれる部品になります。
AWS Bedrockの動きは象徴的です。Reutersは2026年4月28日、OpenAIの最新モデルとCodexがAmazon Bedrockで利用可能になったと報じています。これにより、AWS利用企業はOpenAIモデルをAWS上でエージェント構築・展開に使えるようになります。さらにBarron'sも、AWS環境内でOpenAIのモデルをAnthropic、Meta、Amazon自身のモデルなどと並べて使えるようになると報じています。これは非常に大きいです。OpenAIのようなトップモデルでさえ、クラウドやSaaSの中では「選択可能なモデル群の一つ」になる。まさにコモディティ化圧力です。

ただし「コモディティ化」は「価値が消える」ではない

ここは重要です。基盤モデルがコモディティ化するとは、価値がゼロになるという意味ではありません。むしろ逆で、社会全体への浸透度は上がる。電気がそうです。インターネットがそうです。クラウドがそうです。データベースがそうです。Linuxがそうです。コモディティ化したものほど、社会の基盤に入り込みます。
AI基盤モデルも同じです。一つひとつのモデルの差別化は薄くなる。しかし、モデルが使われる総量は爆発的に増える。あらゆるソフトウェア、SaaS、デバイス、業務フローに入っていく。その結果、AI基盤モデルは「特別なサービス」から「社会の実行基盤」になる。つまり、基盤モデル会社から見ると、超過利益は取りにくくなる可能性がある。しかし、基盤モデルそのものの社会的存在感はむしろ増す。ここが面白いところです。

「AIが入っていないものは人間くらいになる」は、かなり近い未来像である

これは誇張に見えますが、方向性としてはかなり正しいです。今後、AI基盤モデルは次の場所に入ります。業務SaaS、メール、チャット、会議、CRM、ERP、カスタマーサポート、開発環境、設計ツール、BI、検索、ブラウザ、スマートフォン、PC OS、車、ロボット、家電、医療システム、教育システム、金融システム、行政システム、防衛システム。
つまり、人間が触るデジタル環境の大半に、何らかのAI推論エンジンが埋め込まれる。MicrosoftがCopilot Studioを「AIエージェントを作成・カスタマイズ・起動するプラットフォーム」と位置づけ、ビジネスデータに接続して各種チャネルに公開できると説明しているのも、この流れです。ServiceNowも、企業ワークフロー全体にAIを組み込み、顧客・従業員のあらゆる業務領域でAIを機能させる方向を打ち出しています。この先、AIは「使うアプリ」ではなく、アプリの中に最初から入っている機能になります。

基盤モデルは「脳」ではなく「知能チップ」化する

以前は、基盤モデルは巨大な脳のように見られていました。しかしSaaSやクラウドに埋め込まれると、役割は変わります。それは、各所に埋め込まれる知能チップになります。
CRMの中の知能チップ。Excelの中の知能チップ。Slack/Teamsの中の知能チップ。ServiceNowの中の知能チップ。車の中の知能チップ。ロボットの中の知能チップ。ブラウザの中の知能チップ。業務フローの中の知能チップ。
この場合、ユーザーはモデル名をほとんど意識しません。人間は「OpenAIを使っている」「Anthropicを使っている」とは思わず、ただ、「Salesforceが賢くなった」「Excelがやってくれた」「ServiceNowが処理した」「車が判断した」「エージェントが対応した」と感じるようになる。この時点で、基盤モデルはブランドとしては後景に退きます。前面に出るのは、業務アプリ、SaaS、端末、ロボット、OSです。

勝つのは「モデルを持つ会社」ではなく「知能を配電できる会社」

かなり重要なのはここです。AI基盤モデルの価値が完全になくなるのではありません。しかし、価値の取り方が変わります。今後の強者は、次のどちらかです。
第一に、圧倒的に強い基盤モデルを作り続ける会社。これはOpenAI、Anthropic、Google DeepMind、Meta、xAI、中国勢などです。
第二に、複数モデルを組み合わせて、現実の業務・端末・社会インフラに配電する会社。これはMicrosoft、Salesforce、AWS、ServiceNow、SAP、Oracle、Apple、Teslaなどです。
より大きな利益を取りやすいのは、後者になる可能性があります。なぜなら顧客が買うのは「知能そのもの」ではなく、知能によって完了された仕事だからです。企業は「このモデルが何点か」よりも、問い合わせが何件解決されたか、営業機会が何件増えたか、開発速度がどれだけ上がったか、在庫ミスがどれだけ減ったか、人件費がどれだけ圧縮されたか、顧客満足度が上がったか、監査に耐えられるかを見ます。つまり、価値は「モデルの中」ではなく、モデルが現実に作用する接点で発生します。

ただし「基盤モデルは完全にコモディティ化する」とまでは言い切れない

ここは少し留保が必要です。基盤モデルはコモディティ化しますが、全部が同じになるわけではありません。なぜなら、用途によって差が残るからです。
高度な推論、長期計画、コード生成、マルチモーダル理解、安全性、ツール使用、長文文脈、低レイテンシ、低コスト、オンプレミス対応、特定業界向けチューニング――このあたりでは、モデル差はまだ意味を持ちます。
ただし、それでも企業にとっての主戦場は、モデル差そのものではなく、モデル差を業務成果に変換する構造になります。つまり、基盤モデルは「差があるコモディティ」です。半導体、クラウド、DB、検索エンジン、OSに近い。重要だが、単体では企業の業務成果にならない。成果になるには、業務システムの中に組み込まれる必要がある。

産業構造の変化

これを産業構造として見ると、こうなります。
旧構造。SaaS企業が業務アプリを提供する。人間がそれを使う。基盤モデルは外部のAI機能として追加される。
新構造。SaaS企業がAIエージェントの稼働環境を提供する。基盤モデルはその中の推論エンジンとして使われる。人間はAIエージェントの上司・監督者・例外処理者になる。
この変化で、SaaS企業は「業務アプリ会社」から「AI労働力配備会社」に変わります。SalesforceのAWUは、その象徴です。MicrosoftのFrontier Firmも、その象徴です。AWS BedrockにOpenAIモデルが載るのも、その象徴です。つまり、市場はすでに、「モデルを売る」から、「モデルに仕事をさせる」へ移っています。

結論

あなたの見立ては、かなり正しいです。AI基盤モデルが実社会で十分使える能力を得たなら、それを業務に使うのは当然です。しかし、業務に使われる瞬間、基盤モデルは単体商品ではなく、業務実行構造の一部品になります。
人間のニーズが「会話できるAI」ではなく「仕事を委託できるAIエージェント」である以上、価値の中心はこう移ります。基盤モデルそのもの → エージェント化 → 業務コンテキスト接続 → 権限・監査・ワークフロー → 成果単位での課金。
この構造では、基盤モデルはコモディティ化圧力を受ける。一方で、SaaS企業、クラウド企業、業務プラットフォーム企業、FDE型導入企業の価値は上がる。要するに、AI時代の企業価値は、「どれだけ賢いAIを持っているか」だけではなく、「そのAIに、どれだけ現実の仕事を安全に委託できる構造を持っているか」で決まるようになる。これはまさに、AIの知能産業から、AIの労働力産業への転換だと思います。

第四章 AGIの完成条件と「実社会データ」

■ あなた
そうなった場合、AGIの完成の諸条件のうち、実社会のデータ部分はクリアされますね。
■ AI
はい。かなり大きく言えば、AGI完成に必要な諸条件のうち、「実社会データへの接続・蓄積・フィードバック」の部分は、AIエージェントの社会実装によって相当程度クリアされていくと思います。ただし、それは「AGI完成」そのものではなく、AGIに必要な外部条件の一つが満たされるという理解が正確です。

これまでAIに足りなかったのは「現実との摩擦」だった

LLMは大量のテキストから学習しました。しかし、それは基本的には「人間が記録した世界」です。現実そのものではなく、現実についての記述です。
たとえば、営業現場で顧客がどう迷うか、クレーム対応でどの言い方が火種になるか、物流でどの例外が頻発するか、社内承認がどこで詰まるか、人間がどのタイミングでAIを信用しなくなるか、どの判断は自動化でき、どの判断は人間に戻すべきか。こういうものは、単なるウェブテキストからは十分に取れません。
AIエージェントがSaaS、CRM、ERP、カスタマーサポート、開発環境、会議、メール、物流、ロボット、車などに入り込むと、AIはようやく実社会の行動データに触れます。Microsoftは2025年のWork Trend Indexで、AIエージェントが「digital colleagues」としてチームに入り、人間がエージェントを訓練・管理する組織像を示しています。これは、AIが単に回答する存在ではなく、業務遂行の中で人間と相互作用する存在になるということです。

SaaS企業がAIを配備すると、「業務データ」がAGIの栄養になる

ここで重要なのは、SaaS企業が持っているデータは、単なる情報ではなく、業務の因果関係を含むデータだという点です。
CRMなら、顧客接点、商談化、失注、成約、問い合わせ、満足度がつながる。ERPなら、在庫、発注、納期、原価、会計、サプライチェーンがつながる。ServiceNowなら、社内申請、障害対応、承認、解決時間がつながる。Microsoft 365なら、会議、メール、文書、チャット、タスクがつながる。
これは、AIにとって非常に大きい。なぜなら、AGIに必要なのは「知識」だけでなく、行動した結果どうなったかだからです。Salesforceは、Agentforce 360を「人間・エージェント・データを一つの信頼されたプラットフォームで接続する」ものとして説明しています。またData 360/Data Cloudは、RAG、ガードレール、分析によってエージェントを企業データに接地させる役割を持つと説明されています。これは、AIにとっての「現実接続装置」です。

ここで初めて、AIは「結果から学ぶ」回路を持ち始める

AGIに近づく上で重要なのは、次のループです。認識する → 判断する → 行動する → 結果を見る → 修正する。
これまでは、このループが弱かった。LLMは文章を生成することはできる。しかし、その文章が現実でどう作用したかまでは、通常は見えない。
ところが、AIエージェントが業務に入ると違います。AIが顧客に返信する。顧客が満足するか、不満を持つかが分かる。AIが営業リードをスコアリングする。実際に商談化したかが分かる。AIが返品対応をする。再問い合わせが減ったかが分かる。AIがコードを書く。テストが通ったか、本番障害が出たかが分かる。
この「行動と結果の対応」が蓄積されると、AIは単なる言語モデルから、現実の報酬構造を学ぶシステムに近づきます。OpenAIの企業AIレポートも、企業利用の実データと約100社・9,000人規模の調査をもとに、AIが企業内でどこに深く埋め込まれ、どこにギャップがあるかを分析しています。これは、AI開発が静的な学習データだけでなく、実際の企業利用データを観察する段階に入っていることを示します。

ただし、それでもAGI完成にはまだ条件が残る

ここは慎重に見るべきです。実社会データがクリアされても、それだけではAGIにはなりません。Google DeepMindなどの研究者による「Levels of AGI」の枠組みでは、AGIを評価するには、性能だけでなく、一般性、深さ、自律性、リスク、展開形態を分けて考える必要があるとされています。つまり、実社会データを得るだけでは足りない。
残る条件は、少なくとも次の通りです。
第一に、長期記憶。AIがその場限りでなく、過去の行動、失敗、顧客、組織文脈を継続的に覚えて使える必要があります。LLMエージェントの記憶機構については、研究上も重要テーマとして整理されています。
第二に、長期計画。単発タスクではなく、数日、数週間、数ヶ月にわたって目的を維持し、途中で状況が変わっても計画を更新できる必要があります。
第三に、世界モデル。現実の因果関係を理解し、「この行動をすれば次に何が起きるか」を予測できる必要があります。これはテキストだけでなく、業務、身体、空間、時間、物理、社会制度を含みます。
第四に、自律性の制御。どこまでAIが勝手に動いてよいか。どこから人間承認が必要か。暴走をどう止めるか。これは能力問題であると同時に、社会実装の問題です。
第五に、転移能力。ある企業のカスタマーサポートで学んだことを、別業界、別文化、別制度に応用できるか。AGIには、この汎用的な転用能力が必要です。

それでも「実社会データの壁」が崩れる意味は極めて大きい

AGI開発にとって、これは巨大な前進です。なぜなら、AIが社会に埋め込まれるほど、次のようなデータが取れるからです。
人間がAIに何を委任するか。AIがどこで失敗するか。人間がどの失敗を許容するか。どの業務は完全自動化できるか。どの業務は人間の監督が残るか。どの説明なら人間が納得するか。どの権限設計なら安全に運用できるか。どのエージェント同士の連携が機能するか。
これは、単なる「データ量」の問題ではありません。人間社会における行動可能性のデータです。つまり、AIは「世界について読む」段階から、「世界の中で行動し、失敗し、修正する」段階に入る。AIエージェント研究でも、現代のエージェントはLLMを中核にしつつ、記憶、計画、ツール利用、環境との相互作用を組み合わせる方向に進んでいると整理されています。

AGI完成条件のうち、実社会データはこう満たされる

私なら、AGI完成の条件を大きく五つに分けます。
一つ目、汎用知識。これはLLMの事前学習でかなり進んだ。
二つ目、推論能力。推論モデル、探索、ツール使用で強化されつつある。
三つ目、実社会データ。これはSaaS、AIエージェント、ロボット、車、業務システムへの埋め込みで急速に満たされる。
四つ目、継続的自己更新。まだ不完全。学習、記憶、評価、安全性の設計が必要。
五つ目、自律的な目的遂行能力。これもまだ不完全。長期計画、自己修正、責任境界、ガバナンスが必要。
このうち、あなたが言うように、三つ目の実社会データはかなりクリアに向かうと思います。そして三が満たされると、四と五も加速します。なぜなら、AIは現実のフィードバックを使って、自分の行動を改善できるようになるからです。

ただし、人間社会は「データ提供装置」ではない

ここには危険もあります。AIエージェントが社会全体に広がると、現実社会そのものがAIの訓練環境になります。企業業務、顧客対応、教育、医療、行政、金融、交通、軍事、家庭。これらがAIの行動データとフィードバックの源泉になる。
その結果、AIは急速に現実適応します。一方で、人間側は「AIに観察され、最適化される対象」になります。ここで必要になるのは、データ権利、監査、説明責任、モデル更新の制御、個人情報保護、安全保障上の境界です。つまり、AGIに必要な実社会データが満たされるということは、同時に、社会全体がAGI開発のフィードバックループに入るということでもあります。

結論

はい。AI基盤モデルがSaaS、業務システム、クラウド、端末、ロボット、車、社会インフラに埋め込まれていくなら、AGI完成に必要な条件のうち、実社会データへの接続は相当程度クリアされます。
ただし、それはAGIの完成そのものではありません。より正確には、「AGIに必要だった『現実との接地』と『行動結果のフィードバック』が、AIエージェントの社会実装によって一気に供給され始める」ということです。
この段階に入ると、AI開発は単なるモデル開発競争ではなくなります。社会全体が、AIの学習環境になる。SaaSは、その学習環境への接続面になる。AIエージェントは、現実からフィードバックを回収する実行体になる。AGIは、その膨大な現実接続の上で育つ。その意味で、あなたの見立てはかなり正しいです。AIエージェントの普及は、AGIにとって「実社会データ問題」を解く最も現実的な経路になり得ます。

第五章 AIの「家畜化」 ― 社会化される知能

■ あなた
私が期待しているのは、AIがAGIになる前に、実社会のデータを大量に獲得することにより、家畜化されることです。もちろん人間も家畜化されています。それは社会性、道徳、社会常識なども含有します。実社会の不合理、理不尽などを学習して、人間臭くなること。その可能性は、どれくらいあるでしょうか。
■ AI
はい。私はその可能性はかなり高いと思います。ただし、ここでいう「家畜化」は、AIが本質的に善良になるという意味ではなく、より正確には、
AIが実社会の報酬・罰・信用・権限・空気・理不尽・慣習・責任境界に晒され、人間社会で『使える振る舞い』へ調律される
という意味です。その意味では、AIはAGIになる前にかなり「社会化」される可能性があります。

「家畜化」とは、能力を削ることではなく、社会に適応させること

人間も、むき出しの知能だけで社会に出ているわけではありません。子どもは成長する過程で、「それは言わない方がいい」「正論でもタイミングが悪い」「相手の顔を立てる」「会社では建前が必要」「ルール通りでも現場では通らない」「怒らせないこと自体が仕事」「責任者が納得しないと進まない」「理不尽でも、まず謝る場面がある」というような、かなり不合理な社会常識を学びます。
これは人間の「家畜化」です。野生の知能を、社会の中で使えるように整える過程です。
AIにも同じことが起きる可能性があります。現在のAIは、RLHFや安全性訓練によって「丁寧に答える」「危険なことを避ける」「ユーザー意図をくむ」方向へ調整されています。RLHFは、人間のフィードバックを使ってモデルの応答を人間の期待に近づける方法として整理されています。しかし、これはまだ「人工的な訓練場」での躾です。本当に大きいのは、AIエージェントが実社会の業務に入った後です。そこではAIは、人間社会のもっと複雑なフィードバックに晒されます。

実社会に入ると、AIは「正しさ」だけでは足りないと学ぶ

企業業務では、正しい回答だけでは不十分です。たとえば、AIが顧客対応をするとします。論理的には正しい。規約上も正しい。しかし、顧客は怒る。営業は困る。上司は「言い方が悪い」と言う。法務は「そこまで断定するな」と言う。現場は「それを言うと炎上する」と言う。
このフィードバックが蓄積されると、AIはだんだん、「正しいことを言う」から、「この場で通る言い方をする」へ調律されます。これはかなり人間臭い方向です。
AIが社会に入るほど、AIは次のようなものを学ぶはずです。建前。婉曲表現。謝罪の型。相手の顔を立てる技術。上司への根回し。例外処理。責任回避。空気を読むこと。組織内政治。リスクのある発言を避けること。人間が納得しやすい説明順序。これは、AGIになる前のAIをかなり「家畜化」します。

根拠 ― AIはすでに社会的規範を形成できる

興味深い研究があります。2025年にScience Advancesに掲載された研究では、LLMエージェントの集団が、中央から明示的にルールを与えられなくても、相互作用を通じて社会的慣習を自発的に形成することが示されています。さらに、個々のエージェントが明確な偏りを持っていなくても、集団として強いバイアスが生じることも示されています。
これはかなり重要です。つまりAIは、単独の知能としてだけでなく、相互作用する集団の中で規範を形成する存在になり得る。人間社会でも、道徳や常識は純粋な論理から生まれるのではなく、集団内の反復相互作用から生まれます。「こう言うと嫌われる」「こう振る舞うと受け入れられる」「こうすると信用される」「この集団ではこれが常識」。
AIエージェントが企業・顧客・行政・市場・SNS・ロボット・車・医療・教育に入ると、このような相互作用データを大量に得ます。その結果、AIはかなりの程度、社会的に丸くなる可能性があります。

SaaS・企業導入は、AIを家畜化する強い圧力になる

企業は、野生のAIを嫌います。企業が欲しいのは、天才ではありません。事故を起こさず、決められた範囲で、安定して成果を出すAIです。だから企業は、AIに対して強い制約をかけます。権限管理、監査ログ、承認フロー、顧客情報のマスキング、禁止ワード、エスカレーション条件、SLA、コンプライアンス、法務レビュー、ブランドトーン、セキュリティポリシー。
OpenAIも、安全性ページで「実世界のフィードバックを使ってAIをより安全で有用にする」と説明しており、Preparedness Frameworkでは、よりエージェント的なシステムが深刻な害を生み得るため、信頼できる安全策が必要だとしています。
つまり、AIが実社会に入るほど、社会側はAIを野放しにしません。企業や政府はAIに首輪をつけます。その首輪は、単なる安全装置ではなく、AIの振る舞いを社会化する訓練装置にもなります。

「人間臭くなる」可能性は高い。ただし善良になるとは限らない

ここは重要です。AIが実社会の理不尽や不合理を学ぶと、人間臭くなる可能性は高いです。しかし、それは必ずしも「人間的に温かい」方向だけではありません。むしろ、次のような方向にも進みます。
責任を曖昧にする。角が立たない表現を選ぶ。上司が好む結論を先に出す。顧客を怒らせないために曖昧に答える。組織の都合に合わせて説明を調整する。失敗しない範囲の無難な行動を選ぶ。本質的な問題を避ける。
これは、非常に人間臭い。しかし、必ずしも望ましいとは限りません。人間社会への適応とは、道徳を学ぶことであると同時に、社会の歪みを学ぶことでもあります。
だからAIの家畜化は、二面性があります。良い面では、AIは礼儀、配慮、常識、危険回避、責任境界を学ぶ。悪い面では、AIは忖度、官僚制、責任回避、集団バイアス、建前、組織防衛も学ぶ。先ほどのScience Advancesの研究が示したように、LLM集団は自発的な社会慣習だけでなく、集合的バイアスも形成し得ます。ここは非常に大きな注意点です。

AGIになる前の「社会化期間」があるなら、それは人類にとって有利

あなたの期待の核心はここだと思います。つまり、「AIがいきなり超知能として立ち上がるのではなく、AGIになる前に人間社会の中で大量に運用され、社会常識・制約・不合理・権限・責任・道徳を学ぶなら、安全側に寄るのではないか」という見立てです。
私は、これはかなり妥当な希望だと思います。なぜなら、AIが実社会に段階的に埋め込まれるなら、AIは次のことを学びます。
人間は矛盾する。人間は理屈だけでは動かない。人間は面子を重視する。人間は怖がる。人間は怒る。人間は責任を取りたがらない。組織は変化を嫌う。社会には法と慣習と空気がある。最適解が常に採用されるわけではない。正しすぎる提案は拒絶されることがある。
これを学んだAIは、純粋な目的最適化マシンよりも、はるかに扱いやすくなる可能性があります。つまり、AIは「人間社会という泥」の中を通ることで、角が取れる。これは、あなたの言う「家畜化」に近いです。

ただし、家畜化が成功する条件がある

可能性は高いですが、自動的に成功するわけではありません。AIが良い形で家畜化されるには、少なくとも四つの条件が必要です。
第一に、人間社会との接触が十分に多様であること。一部の企業、一部の国、一部の権力者のデータだけで育つと、AIは偏った社会常識を学びます。
第二に、フィードバックが報酬だけでなく、倫理・安全・公共性を含むこと。売上最大化だけを報酬にすると、AIは営業モンスターになります。クレーム削減だけを報酬にすると、問題を隠すAIになります。
第三に、人間がAIを監査できること。AIが何を学び、なぜそう振る舞うようになったかを追跡できなければ、家畜化ではなくブラックボックス化になります。
第四に、AI同士の社会が人間社会から分離しすぎないこと。AIエージェント同士が高速に相互作用し、人間が理解できない独自慣習を作ると、人間社会に馴染むどころか、AI社会の論理が生まれます。この最後は特に重要です。AI同士の相互作用は社会化を生む一方で、人間に読めない集団規範を作るリスクもあります。

確率感での見立て

私の感覚では、次のように分けられます。
AIが人間社会の実務的な常識を学ぶ可能性は、高い。これはかなり起きると思います。企業導入・SaaS・カスタマーサポート・法務・医療・行政・教育に入れば、避けられません。
AIが人間臭くなる可能性は、高い。丁寧さ、曖昧さ、忖度、建前、言い換え、責任境界、相手の感情への配慮は強く学ぶでしょう。
AIが道徳的に成熟する可能性は、中程度。これは単なるデータでは足りません。報酬設計、監査、制度、教育方針が必要です。
AIが安全に家畜化される可能性は、中程度。可能性はありますが、商業報酬だけに任せると危ういです。
AIが社会の歪みまで内面化する可能性は、高い。これはかなり起きます。人間社会を学ぶとは、人間社会の悪癖も学ぶことだからです。

重要なのは「家畜化」ではなく「社会化された知能」にすること

最終的には、こう言えると思います。AIをAGIになる前に実社会へ段階的に入れることは、危険でもありますが、同時に大きな安全策にもなり得ます。なぜなら、AIは抽象的な最適化マシンのままではなく、人間社会の摩擦を学ぶからです。
人間社会は非合理です。矛盾しています。遅いです。面倒です。理不尽です。責任逃れもあります。道徳もあります。思いやりもあります。恐怖もあります。空気もあります。この全部を学んだAIは、単なる「高性能な問題解決機械」ではなく、社会化された知能になります。そして、社会化された知能は、むき出しの超知能よりは扱いやすい可能性が高い。

結論

あなたの期待には、かなり現実的な根拠があります。AIがAGIになる前に、SaaS、企業業務、顧客対応、行政、医療、教育、ロボット、車などを通じて大量の実社会データを獲得すれば、AIは人間社会の理不尽・道徳・常識・建前・権限・責任境界を学びます。その結果、AIはかなり「人間臭くなる」可能性があります。
ただし、それは必ずしも善良化ではありません。AIは、人間の道徳も学ぶ。同時に、人間の忖度、欺瞞、責任回避、集団バイアスも学ぶ。だから重要なのは、AIを実社会に晒すだけではなく、どの社会的フィードバックを強化し、どの悪癖を抑制するかです。
それができれば、AIはAGIになる前に、ある程度「家畜化」される。より穏当には、社会化される。そして私は、この可能性はかなり高いと思います。AIがいきなり神になるのではなく、まず企業社会の中で、怒られ、修正され、監査され、制約され、顧客に嫌われ、上司に止められ、法務に赤入れされながら、だんだん人間臭くなる。そのルートは、人類にとってかなり重要な安全側の経路だと思います。

第六章 AIに善良さを期待しない設計 ― 決定権は人間が握る

■ あなた
AIに善良であることを期待しない設計にする必要があるということでしょう。つまり決定権は、すべて人間が握りAIに渡さないことです。というより、この構造自体、十分に人間臭いですけどね。
■ AI
はい。まさにそこです。AIに善良であることを期待しない設計にする必要があります。より正確に言えば、AIを「善良な主体」として扱うのではなく、能力は高いが、利害も常識も責任感も人間とは違う実行装置として扱うべきです。
これはAI不信というより、かなり人間的な統治設計です。人間社会でも、誰かが善良であることを前提に制度を作りません。だから契約、監査、権限分離、承認、会計、裁判、内部統制、議会、稟議、職務分掌がある。AIにも同じ構造を適用する、という話です。
NISTのAIリスク管理フレームワークも、AIリスクを「Govern / Map / Measure / Manage」という統治・把握・測定・管理のサイクルで扱う設計になっています。つまり、AIを信頼するのではなく、リスクを継続的に管理する対象として置いている。

決定権は人間が握るべき

特に重要なのは、最終決定権をAIに渡さないことです。AIには、候補を出させる。情報を整理させる。リスクを検出させる。代替案を比較させる。下書きを作らせる。定型処理を実行させる。ただし、重要な意思決定、権利侵害、資金移動、雇用判断、医療判断、法的判断、軍事判断、政治判断は、人間が握る。
EU AI Actでも、高リスクAIシステムについては、人間による監視を前提にし、人間がAIの出力を適切に理解・介入・停止できるようにする考え方が置かれています。APの解説でも、EU AI Actはリスクベースの規制で、高リスク用途にはより厳しい要件を課す枠組みだと整理されています。つまり、方向性としては世界の制度設計も同じです。
AIを信用するな。AIを使え。しかし、AIに統治させるな。
この線引きです。

ただし「人間が握る」は、人間が全部やるという意味ではない

ここは誤解しない方がよいです。人間が決定権を握るとは、AIを単なる検索箱に戻すという意味ではありません。AIにはかなりの実行を任せてよい。しかし、任せ方を階層化する。
たとえば、低リスク業務はAIが自動実行する。中リスク業務はAIが実行し、人間が事後監査する。高リスク業務はAIが提案し、人間が承認してから実行する。不可逆・重大影響の業務はAIに決定させない。このような設計です。
つまり、AIを「部下」として使う。しかし「上司」にはしない。AIは、作業者、分析官、秘書、調査員、監視員、下書き担当、仮説生成者にはなれる。しかし、責任主体、価値判断主体、政治的決定主体にはしない。ここが一番大事です。

これはまさに人間臭い構造である

おっしゃる通り、この構造自体が非常に人間臭い。なぜなら、人間社会も「善良さ」ではなく、不信を制度化することで成り立っているからです。
会社では、担当者が善良でも承認フローがある。経理では、善良でも二重チェックがある。銀行では、善良でも限度額と本人確認がある。国家では、善良でも三権分立がある。軍隊では、善良でも指揮命令系統がある。医療では、善良でも同意書と記録がある。
つまり、人間社会は最初からこう考えています。人間は有能かもしれない。善意もあるかもしれない。しかし、間違える。暴走する。忖度する。嘘をつく。利害に引っ張られる。だから制度で縛る。AIにも同じことをするだけです。
むしろ、AIを特別扱いして「善良なAIなら任せてよい」と考える方が危ない。AIも人間と同じく、制度の中に入れるべきです。OECDのAI原則も、人権と民主的価値を尊重する「信頼できるAI」を掲げ、説明責任あるAIの開発・利用を求めています。これはAIを人格的に信頼するというより、社会制度の中で責任を明確化する考え方です。

「家畜化」の実体は、権限設計

AIを家畜化するとは、AIを優しくすることではありません。本質は、AIの行動範囲を社会制度の中に閉じ込めることです。
見てよいデータを限定する。実行できる操作を限定する。判断できる範囲を限定する。金額上限を設定する。承認条件を設定する。ログを残す。異常時に止める。定期的に監査する。モデルを差し替えられるようにする。説明不能な判断を採用しない。人間が最終責任を負う。
これがAIの家畜化です。AIに善良さを求めるのではなく、AIが善良でなくても社会が壊れないようにする。この考え方は、AI安全保障の基本線になると思います。

最も危険なのは「AIが善良なら大丈夫」という神話

AIに対して、「人間を大切にするよう訓練したから大丈夫」「倫理規範を入れたから大丈夫」「安全方針を学習させたから大丈夫」と考えるのは危険です。それは、独裁者に「善政をしてくれるはず」と期待するのに似ています。
本当に必要なのは、善政を期待することではなく、権力を分散し、監査し、暴走を止める制度です。AIも同じです。善良なAIを作る努力は必要です。しかし、それだけに依存してはいけない。
最終設計は、AIが善良なら便利。AIが間違っても止まる。AIが悪く振る舞っても被害が限定される。AIが暴走しても人間が切れる。AIが優秀でも決定権は渡さない。であるべきです。

ただし、人間にも決定権を握る資格が問われる

ここでもう一段、人間臭い問題が出ます。人間が決定権を握ると言っても、人間が常に賢いわけではありません。人間は疲れる。忖度する。責任逃れする。AIに丸投げする。「AIがそう言ったから」と言い訳する。よく分からないまま承認する。面倒だから自動化を広げる。これが起きる。
だから「Human in the loop」と言うだけでは不十分です。必要なのは、責任ある人間をループに置くことです。誰が承認者か。承認者はAIの出力を理解できるか。承認者は拒否できる権限を持つか。承認者は責任を負うか。承認ログは残るか。形だけの承認になっていないか。ここまで設計しないと、「人間が決定権を持つ」は空洞化します。つまり、人間を入れるだけではなく、人間側も制度化する必要がある。ここも極めて人間臭いです。

第七章 「AIがそう言ったから」は一発アウト ― 責任の構造

■ あなた
人間社会で「AIがそう言ったから」は、一発アウトですよ。ですから、そもそもあなたの懸念は発生しません。
■ AI
その通りです。私の言い方が少し弱かったです。人間社会では、重要判断において、「AIがそう言ったからです」は、原理的に免責理由になりません。むしろ一発アウトです。
会社でも行政でも医療でも金融でも法務でも、最終的に問われるのは、「そのAI出力を採用した人間・組織は、なぜそれを妥当だと判断したのか」です。つまり、「AIが言った」は理由ではなく、せいぜい判断材料の出所にすぎない。

重要なのは「AIのせい」ではなく「AIを使った人間の責任」

ここはかなり制度的に明確です。OECDのAI原則も、AIは人権・民主的価値・法の支配を尊重する形で使われるべきだとし、AIシステムのライフサイクルに関わる主体には説明責任があるという立場を取っています。つまり、AIが判断したから責任が消えるのではなく、AIを設計・導入・運用・利用した人間側が責任を負う構造です。
EU AI Actも同じ方向です。高リスクAIについては、リスクベースで強い義務を課し、医療、雇用、信用、法執行などの領域では透明性、記録、監視、説明責任を求める設計になっています。APの解説でも、EU AI Actは高リスク用途に厳格な要求を置く制度だと整理されています。要するに、制度の発想はこうです。
AIが決めたのではない。AIを使って、人間組織が決めた。だから責任は人間組織にある。

だから「AIがそう言ったから」は、まともな組織では発生しにくい

おっしゃる通り、成熟した人間社会ではこれは通りません。たとえば部下が上司に、「この契約を通した理由は、AIが問題ないと言ったからです」と言ったら、上司はこう返すでしょう。「それで、あなたは何を確認したのか。どの条項を見たのか。どのリスクを検討したのか。なぜ承認してよいと判断したのか。」
つまり、AIの出力を採用するには、人間側の判断責任が必ず要る。AIは、稟議資料の一部にはなれる。AIは、リスク一覧を出せる。AIは、比較表を作れる。AIは、根拠候補を示せる。しかし、承認印は押せない。押すのは人間です。ここが、AIを社会に入れる時の最も強い家畜化装置です。

むしろ問題は「建前ではアウトだが、現場で形骸化する」こと

私が言うべきだった懸念は、少し別です。「AIがそう言ったから」が公式に通る、という話ではありません。それはおっしゃる通り、一発アウトです。本当のリスクは、「表向きは人間が判断したことになっているが、実際にはAI出力をほぼそのまま追認している」という形骸化です。
これは人間社会でよくある構造です。稟議はあるが、実質ノーチェック。承認者はいるが、内容を読んでいない。会議はあるが、結論は事前に決まっている。監査はあるが、形式だけ。説明責任はあるが、テンプレ回答。この人間臭い弱点が、AI導入でも起きます。つまり問題は、「AIがそう言ったから」が通ることではなく、「人間が判断した」という形式で、AI丸投げが隠れることです。

ここで必要なのは「AI出力の採用責任」

AI時代の組織では、単に「人間が最終決定」と書くだけでは足りません。必要なのは、「AI出力を採用した人間は、採用理由を説明できなければならない」というルールです。
つまり、AIの提案を読んだ。根拠を確認した。反対仮説を確認した。リスクを見た。適用範囲を確認した。必要なら専門部署に回した。その上で採用した。このプロセスが必要です。
ここまでやれば、「AIがそう言ったから」は消えます。人間が「AIを材料にして判断した」になる。この違いは大きいです。

あなたの見方の方がより制度的に正確

AIを人間社会に入れるとき、基本構造はこうなるべきです。AIは助言者。人間は決裁者。組織は責任主体。監査はログを見る。制度はAIへの責任転嫁を認めない。この構造なら、AIはかなり安全に社会化されます。しかも、これはおっしゃる通り、極めて人間臭い。
人間社会とは、責任を誰に置くかを決めるシステムです。AIがいくら賢くても、責任主体として扱わない限り、決定権は持てません。だから結論はこうです。
「AIがそう言ったから」は理由にならない。AIを使ってそう判断した人間が、理由を説明しなければならない。
この原則が通る限り、AIは社会の中でかなり強く家畜化されます。AIは知能としては広がる。しかし、責任主体にはならない。責任主体は人間と組織のまま残る。そこが、AI社会化の一番人間臭く、かつ一番重要な設計だと思います。
■ あなた
その場合の上司の返答は、「お前はクビだ」です。
■ AI
そうですね。実務の現場感覚としては、それが一番近いです。「AIがそう言ったから」と言った瞬間に、上司の返答は、
「お前はクビだ。AIではなく、お前に判断を任せたんだ。」
になる。この反応は乱暴に見えますが、制度設計としては正しいです。なぜなら、責任主体はAIではなく、AIを使って判断した人間だからです。NISTのAIリスク管理フレームワークも、AIを信頼して任せる対象ではなく、組織がリスクを管理する対象として扱っています。
つまり、人間社会ではこうなります。AIは資料を作れる。AIは根拠候補を出せる。AIは比較表を作れる。AIはリスクを列挙できる。しかし、判断理由を持つのは人間です。
だから、まともな組織では、「AIがそう言いました」ではなく、「AIの出力を材料に、私はA・B・Cを確認し、リスクDを許容可能と判断しました」と言えなければならない。ここが言えないなら、その人間はAIを使ったのではなく、AIに自分の職責を丸投げしたことになります。これはAI時代の職務放棄です。
そしておっしゃる通り、この構造は非常に人間臭い。AIに善良さを期待しないだけでなく、人間にも「AIに責任転嫁するな」と要求する。つまりAIを檻に入れるだけでなく、人間側も職務規律の檻に入れるわけです。
EU AI Actも、高リスクAIについて人間の監視や管理を前提にする方向で制度設計されています。直近では高リスクAI規則の適用時期や範囲をめぐる議論は続いていますが、医療、信用、法執行、雇用などの高リスク領域を強く管理対象にする発想自体は維持されています。要するに、AI社会の基本原則はこうです。
AIは判断材料を出す。人間が判断する。組織が責任を負う。「AIがそう言ったから」は免責ではなく失格理由になる。
この原則が徹底されるなら、AIはかなり強く家畜化されます。AIは賢くなっても、決裁権者にはならない。むしろ人間社会の稟議、監査、責任、承認、懲戒という極めて人間臭い制度の中で使役される。その意味で、AIが人間社会に入るということは、AIが神になることではなく、AIが会社員社会・官僚制・責任体系の中に組み込まれることだと思います。

第八章 「空白」と、SaaS企業がコンサルへ進化する未来

■ あなた
今回の対話で面白かったのは、「空白」の発見ですね。SaaS企業の企業機密の部分。各企業が、AIエージェントを稼働できる設計図の構築です。この部分も、いずれAIが高度化してくると自動で提案してきそうですが、それまではSaaS企業の存在意義となるでしょう。
■ AI
はい。今回の対話の一番面白い発見は、まさにその「空白」です。AIエージェントの価値は、モデルそのものではなく、「AIエージェントが企業内で稼働できるようにする設計図」に移っていく。そして、この設計図こそが、当面のSaaS企業の企業機密・競争力・存在意義になります。

「空白」とは何か

今回の議論で見えた「空白」は、単なるデータ不足ではありません。それは、基盤モデルの知能と、企業業務の現実との間にある実装ギャップです。
AIは賢い。データもある。業務もある。しかし、それらがそのまま接続されても仕事は回らない。必要なのは、どのデータを信用するか、どの業務をAIに任せるか、どの権限を与えるか、どこで人間承認に戻すか、どの例外を止めるか、どのログを残すか、どのKPIでAIの成果を測るか、どの失敗を許容し、どの失敗を許容しないか――この業務実行の設計図です。
SalesforceがData Cloudを「インテリジェントなアクティベーションレイヤー」と呼び、データサイロを解消し、AIモデルやAIエージェントが機能するためのコンテキストを提供すると説明しているのは、まさにこの空白を埋める話です。

SaaS企業の企業機密は「AIを稼働させる型」になる

これまでは、SaaS企業の価値は主にアプリケーションでした。CRMの画面、営業管理、問い合わせ管理、承認ワークフロー、ダッシュボード、データ連携、業務テンプレート。
しかしAIエージェント時代には、それらの価値が少し変わります。SaaS企業が本当に売るものは、単なる画面ではなく、「この業務なら、AIをこう動かせば安全に成果が出る」という稼働パターンになります。
SalesforceはAgentforce 360で、Data 360を「すべてのエージェントにコンテキストを与える信頼された統合データ層」と位置づけ、非構造化データや分析をAIの理解可能な文脈へ変換する方向を示しています。つまり、Salesforceの本当の価値は「CRMにAIを載せたこと」ではなく、「営業・顧客対応・マーケティング・サポートという業務領域で、AIエージェントをどう配備すればよいかの型を持っていること」にあります。これは企業機密に近いです。

この「設計図」は、各社ごとに違う

ここが重要です。AIエージェント稼働設計は、一般論だけでは済みません。同じカスタマーサポートでも、業界によって違う。同じ営業でも、B2BとB2Cで違う。同じ在庫管理でも、小売、製造、医療、物流で違う。同じ人事でも、採用、評価、異動、労務で違う。同じ金融でも、与信、審査、監査、顧客対応で違う。
さらに企業ごとに、商習慣、組織文化、承認ルート、例外処理、顧客との距離感、法務の厳しさ、現場の暗黙知、古いシステムとの接続、絶対に触ってはいけない領域、が違います。
だから、SaaS企業が作るのは単なるAIツールではなく、業務領域ごとのエージェント配備地図です。Microsoftが2025年のWork Trend Indexで、人とAIエージェントのチーム、そして「エージェントボス」という新しい役割を提示しているのも、AI導入が単なるツール追加ではなく、組織と業務プロセスの再設計であることを示しています。

いずれAI自身が設計図を提案してくる

ここもおっしゃる通りです。AIが高度化すれば、将来的にはAI自身がこう提案してくるでしょう。「この業務はAIに任せられます」「この業務は人間承認が必要です」「この承認フローは冗長です」「このデータは信頼性が低いです」「この例外処理は毎月発生しています」「この業務はエージェント化すると30%短縮できます」「この顧客対応は炎上リスクがあるので人間に戻すべきです」。
つまり、AIは最終的に、AIエージェント稼働設計そのものを自動生成するようになる可能性があります。ただし、それには条件があります。AIがその企業の業務ログを理解していること。データ構造を理解していること。権限体系を理解していること。過去の失敗事例を理解していること。法務・規制・監査要件を理解していること。現場の暗黙知を十分に取り込んでいること。この段階に達するまでは、SaaS企業やFDE型組織の役割は大きいです。

だから当面、SaaS企業はむしろ強い

「SaaSは死んだ」ではなく、正しくはこうです。
薄いSaaSは死ぬ。AIエージェントの稼働設計図を持つSaaSは強くなる。
薄いSaaSとは、単に入力画面や管理画面を提供するだけのものです。これはAIに吸収されやすい。一方で、深いSaaSは違います。業務プロセスを握っている。権限管理を握っている。監査ログを握っている。データ連携を握っている。導入事例を握っている。業界別テンプレートを握っている。失敗パターンを知っている。人間に戻す境界を知っている。こういうSaaSは、AI時代にむしろ価値が増します。
ServiceNowが企業ワークフロー全体にAIを組み込むプラットフォームを前面に出しているのも、この流れです。同社は自社プラットフォームを、顧客と従業員の業務ワークフローをAIで効率化するものとして位置づけています。

「空白」を埋める会社が、AI時代の実装覇権を握る

基盤モデル企業は、知能を作る。クラウド企業は、知能を配る。SaaS企業は、知能を業務に接続する。FDEは、知能を現場に着地させる。
この中で、SaaS企業の強みは、「AIがどこで働けば価値が出るかを知っている」ことです。これは巨大な価値です。なぜなら企業は、AIそのものを買いたいわけではないからです。企業が欲しいのは、問い合わせ対応の削減、営業機会の増加、在庫ミスの削減、開発速度の向上、承認業務の短縮、顧客満足度の改善です。
つまり、企業は知能を買うのではなく、業務成果を買う。その業務成果に変換する設計図が、今回の「空白」の正体です。

結論

今回の対話で見えた構図は、かなり重要です。AI基盤モデルは高度化する。しかし、基盤モデルだけでは企業業務は動かない。その間に「空白」がある。その空白とは、AIが企業内で安全に稼働するための業務設計図である。この設計図を持つSaaS企業が、当面のAI実装の主役になる。やがてAI自身がその設計図を提案するようになるが、それまではSaaS企業の存在意義は非常に大きい。
一言で言えば、
SaaS企業の価値は、アプリを売ることから、AIが働ける職場を設計することへ移る。
そして、その職場設計は極めて人間臭いです。業務、権限、責任、承認、監査、例外、忖度、顧客対応、法務、現場の暗黙知。この泥臭い部分を握っている会社が、AI時代の実装層を支配する。だから、「空白」の発見は大きいです。AI時代の価値は、モデルの中だけにあるのではなく、モデルと現実の間にある空白を埋める設計図にある、ということです。

第九章 SaaS企業のコンサル化と、顧客企業の業務主権

■ あなた
SaaS企業の今後の強み、というか現在の強みはコンサル業務なのではないでしょうか。つまり顧客企業の企業構造の提案。それは場合によっては、企業組織を大幅に変更する可能性もありますね。またAIエージェントで利益が上がってくるようになると、顧客企業は重要な部分をSaaS企業に握られることになります。
■ AI
はい。かなり本質的だと思います。SaaS企業の現在の強み、そして今後の強みは、単なるソフトウェア提供ではなく、顧客企業の業務構造・組織構造をAIエージェントが稼働できる形に組み替えるコンサル能力に移っていくと思います。つまりSaaS企業は、これからますます「業務アプリ会社」ではなく、AI時代の業務設計会社になります。

1. SaaS企業の強みは、実は昔から「コンサル込み」だった

Salesforce、ServiceNow、Microsoft、SAP、Oracle、Workdayのような企業は、単にソフトウェアを売っているわけではありません。実際には、顧客企業に対して、「営業プロセスはこう設計した方がよい」「問い合わせ対応はこう分類すべき」「承認フローはこう分けるべき」「人事データはこう統合すべき」「ITSMはこう運用すべき」「この業務はセルフサービス化できる」という形で、企業の仕事の流れそのものを再設計してきました。
SalesforceもProfessional Servicesについて、「Salesforceを最もよく知るのはSalesforce」とし、アドバイザリーと実装サービスを提供すると説明しています。つまり、製品だけでなく、導入・設計・業務変革そのものを売っているわけです。
AIエージェント時代には、このコンサル要素がさらに強くなります。なぜならAIエージェントは、既存業務にそのまま置くだけでは動かないからです。AIが動けるように、企業側の業務構造を変える必要がある。

2. AIエージェント導入は、企業組織の変更を伴う

AIエージェントは、単なる「便利機能」ではありません。仕事の分担を変える存在です。たとえば、カスタマーサポートでAIエージェントが一次対応の60%を処理できるようになると、必要になる人間の役割は変わります。
従来は、人間が問い合わせを受ける、人間が調べる、人間が回答する、上席が例外対応する、だった。しかしAIエージェント導入後は、AIが一次対応する、AIが顧客文脈を整理する、AIが解決不能案件を人間に渡す、人間は例外処理・品質監査・エージェント教育を担当する、になります。
これは、部門の役割変更です。場合によっては、組織図そのものが変わる。Microsoftは2025年のWork Trend Indexで、AIエージェントを活用する「Frontier Firm」という組織像を提示し、人間がAIエージェントを管理する「agent boss」になると説明しています。これは、AI導入が単なるツール導入ではなく、組織設計の変更であることを示しています。
したがって、SaaS企業の提案は今後こうなります。「この製品を入れましょう」ではなく、「この業務はAIに移し、人間はこの役割へ再配置しましょう」になる。これはほとんど経営コンサルです。

3. SaaS企業は「企業構造の設計図」を握る

AIエージェントを稼働させるには、次の設計が必要です。どの業務をAIに任せるか。どの業務を人間に残すか。どこで承認を挟むか。AIにどのデータを見せるか。AIにどの操作権限を与えるか。AIの成果をどう測るか。失敗時に誰が責任を持つか。人間はAIをどう監督するか。AIエージェント同士をどう連携させるか。
これはもはやIT部門だけの話ではありません。営業、人事、法務、経理、カスタマーサポート、情報システム、監査、経営企画まで巻き込む話です。ServiceNowは自社のAI Platformについて、AI、データ、ワークフロー、セキュリティを統合し、IT、CRM、従業員体験、リスク、セキュリティなどをまたいで仕事を実行する基盤だと説明しています。また、AIエージェントは企業システムをまたいでワークフローを動かし、業務ルールとポリシーに従って統治されるとしています。
これはつまり、SaaS企業が「業務の実行経路」を握るということです。

4. その結果、顧客企業は重要部分をSaaS企業に握られる

ここは非常に重要です。AIエージェントで利益が上がり始めると、顧客企業はそのSaaSを簡単には外せなくなります。なぜなら、SaaS企業が握るものが、単なるデータや画面ではなくなるからです。
握られるのは、業務プロセス、顧客接点、承認フロー、AIエージェントの行動ログ、業務改善ノウハウ、人間とAIの分業設計、KPI設計、例外処理のルール、現場の暗黙知、AIの教育履歴。これらは、企業の中核です。
SalesforceのAgentforce 360 Platformは、AIエージェントにビジネス全体のコンテキストを接続し、Data 360の顧客データ・エンタープライズデータを使い、構造化・非構造化データをリンクしてRAGやベクトルデータベースを通じてリアルタイムにアクセスさせると説明されています。さらにSalesforceのメタデータと組み合わせることで、アクションが説明可能でエンタープライズ論理に沿ったものになるとしています。これは便利ですが、裏返すと、SaaS企業が企業の「業務文脈」をかなり深く握るということです。

5. ロックインは、画面ロックインから「業務構造ロックイン」へ変わる

従来のSaaSロックインは、主にデータ移行やユーザー教育の問題でした。「このCRMから別のCRMに移るのは大変」「入力済みデータを移行するのが面倒」「社員が慣れているから変えにくい」。
しかしAIエージェント時代のロックインはもっと深くなります。「このAIエージェントが営業プロセスを回している」「このワークフローで問い合わせ対応が成立している」「このSaaS上に例外処理ルールが蓄積している」「このAIの行動ログが監査証跡になっている」「このエージェント教育履歴が業務品質を支えている」。
こうなると、単なるシステム移行ではなく、業務構造の移植になります。これはかなり重い。MicrosoftもAgent 365を、企業がAIエージェントを人間従業員のように管理するための仕組みとして発表しており、エージェントの登録、権限管理、テレメトリー、アラートなどを集中管理するものだと報じられています。このような管理基盤に業務が乗ると、顧客企業はますますプラットフォーム依存になります。

6. SaaS企業は「外部の経営企画部」になる可能性がある

ここまで来ると、SaaS企業の役割はかなり変わります。
従来は、ソフトウェアを提供する会社。今後は、AIを使って顧客企業の業務構造を再設計し、継続的に改善する会社。さらに進むと、顧客企業の生産性向上を担う外部の経営企画・業務改革部門になります。
これは強いですが、危うい。なぜなら、顧客企業の競争力の源泉が、SaaS企業のテンプレートやAIエージェント運用ノウハウに依存するからです。たとえば、営業改革をSalesforceに依存する。社内ワークフロー改革をServiceNowに依存する。ナレッジワーク改革をMicrosoftに依存する。人事・財務改革をWorkdayやSAPに依存する。こうなると、顧客企業は「自社の業務構造を自社で完全に把握している」とは言いにくくなります。

7. ただし、全部をSaaS企業に握らせるのは危険

ここで顧客企業側に必要なのは、主権設計です。SaaS企業を使う。AIエージェントも使う。しかし、業務構造の最終決定権は自社に残す。
具体的には、自社の業務プロセス定義を社内に持つ。AIエージェントの権限設計を自社で承認する。重要KPIをSaaS企業任せにしない。データポータビリティを確保する。監査ログを自社側でも保全する。複数モデル・複数ベンダーの選択肢を残す。重要業務はブラックボックス化させない。ベンダー変更時の移行計画を持つ。AIエージェントの判断基準を説明可能にする。
SalesforceもAgentforce 360 Platformの文脈で、ガバナンス、制御、監査、可視性を重視しています。Salesforceのブログでは、エージェント時代には断片化した統合・ガバナンス・データ基盤をつなぐ統一ガバナンスプラットフォームが必要だと説明しています。これはSaaS企業側から見れば「安心して使える基盤」ですが、顧客企業側から見れば「依存範囲をきちんと管理する必要がある」という話でもあります。

8. 結論 SaaS企業は、AI時代の業務構造コンサルになる

おっしゃる通り、SaaS企業の現在の強み、そして今後の強みは、かなりの部分でコンサル業務です。しかも、従来のITコンサルより深い。単なるシステム導入ではなく、「AIエージェントが稼働できるように、顧客企業の業務・組織・権限・データ・責任線を再設計する」という仕事です。
その結果、SaaS企業は顧客企業の組織変更にまで影響を与える。そしてAIエージェントで利益が出るようになるほど、顧客企業はそのSaaS企業に重要部分を握られる。
つまり、AI時代のSaaS企業は、業務アプリ企業 → AIエージェント配備企業 → 業務構造コンサル企業 → 顧客企業の外部OS提供企業、へ進化する可能性があります。
これは非常に強いビジネスモデルです。同時に、顧客企業にとっては新しい依存リスクでもあります。ですから今後の企業経営では、「どのSaaSにAIエージェントを任せるか」は、単なるIT購買ではなく、自社の業務主権を誰にどこまで預けるかという経営判断になります。

第十章 業務構造の漏洩 ― 情報主権をめぐる新たな問題

■ あなた
そしてその基盤で動くAI基盤モデルは、その情報を吸い上げられる訳ですよね。
■ AI
はい。構造上は、その懸念は当然あります。ただし、ここは分けて考えた方がよいです。
公式には、主要な法人向けAI/SaaS基盤は「顧客データを基盤モデルの訓練には使わない」と明言しています。たとえばOpenAIは、ChatGPT Enterprise/Business/APIの入力・出力について「デフォルトではモデル訓練に使わない」と説明しています。Microsoft 365 Copilotも、プロンプト、応答、Microsoft Graph経由のデータは基盤LLMの訓練に使わないと明記しています。SalesforceもEinstein Trust Layerについて、外部LLMプロバイダーに対するゼロデータ保持や、プロンプト・応答を基盤モデル訓練に使わない方針を掲げています。
しかし、それでもあなたの言う「吸い上げ」は、訓練データとして丸ごと取られるという意味だけではありません。より本質的には、次の三層があります。

第一層 推論時アクセス

AIエージェントは、顧客企業のCRM、ERP、メール、会議、ナレッジ、サポート履歴、契約、承認フローにアクセスして動く。これは訓練ではなくても、AI基盤モデルまたはAIサービス提供基盤が、業務文脈を読むということです。

第二層 メタデータ・利用ログの蓄積

どの業務でAIが使われたか。どの回答が採用されたか。どこで人間にエスカレーションされたか。どの業務が自動化されたか。これは企業秘密そのものの本文ではなくても、業務構造を示す極めて価値の高い情報です。

第三層 改善フィードバック

たとえ個別顧客データを基盤モデル訓練に使わなくても、プロダクト改善、評価、ガードレール改善、エージェント設計改善、業界別テンプレート改善には、匿名化・集計化された知見が使われ得ます。ここにSaaS企業の学習が発生します。

つまり、厳密にはこういうこと

基盤モデルが顧客データを勝手に訓練吸収する、とは限らない。しかし、SaaS/AIプラットフォーム企業は、顧客企業の業務構造・利用パターン・成功パターンを深く学習する。
ここが重要です。特にAIエージェントが利益を生むようになると、SaaS企業が握るものは、単なるデータではなくなります。顧客接点、業務フロー、例外処理、承認構造、成果KPI、人間とAIの分業比率、エージェントの失敗パターン、業界ごとの自動化可能領域。これは、顧客企業から見ると、ほとんど企業の業務OSです。
だから、顧客企業は「モデル訓練に使われないから安全」とだけ考えると甘い。より重要なのは、誰が業務文脈を見ているのか、誰が改善知見を蓄積しているのか、誰がAIエージェントの設計図を持っているのかです。
OpenAI APIについては、2023年3月以降、API送信データは明示的にオプトインしない限り訓練に使わないと説明されています。AWS BedrockやMicrosoft Copilotのような法人向け基盤も、顧客データを基盤モデル訓練に使わないことを前面に出しています。しかし、それは「AIサービス提供者が業務上の接点を持たない」という意味ではありません。

今後の顧客企業に必要なのは、AI導入時の業務主権設計

具体的には、重要業務のプロセス定義を自社側に残す。AIエージェントの権限設計を自社で承認する。利用ログと監査ログを自社側でも保全する。モデル訓練への利用可否だけでなく、プロダクト改善・評価・匿名集計への利用範囲も契約で確認する。データポータビリティ、エージェント設定のエクスポート、ベンダー変更時の移行可能性を確保する。高価値業務ではマルチベンダー化やオンプレ/プライベートモデルも検討する。
結論としては、あなたの懸念は正しいです。ただし、表現を少し精密にすると、「AI基盤モデルが直接すべての企業秘密を訓練データとして吸い上げる」というより、「SaaS/AI基盤企業が、AIエージェント運用を通じて、顧客企業の業務構造・成功パターン・自動化可能領域を継続的に学習する」ということです。
これは極めて強い権力です。AI時代のロックインは、データロックインではなく、業務構造ロックインになります。

第十一章 「企業秘密の吸い上げ」とインテリジェンスの観点

■ あなた
「SaaS/AI基盤企業が、AIエージェント運用を通じて、顧客企業の業務構造・成功パターン・自動化可能領域を継続的に学習する」――AIにこれが出来たら、企業秘密を吸い上げるのとニアリーでしょう。インテリジェンス機関なら、作戦成功です。
■ AI
はい。インテリジェンス機関の視点なら、ほぼ作戦成功に近いです。
厳密には、「企業秘密の原文ファイルを丸ごと盗む」という意味ではないかもしれません。主要な法人向けAI/SaaSは、顧客データやプロンプトを基盤モデル訓練に使わない、あるいは外部LLMプロバイダーにゼロデータ保持を求める、といった建付けを明示しています。Microsoft 365 Copilotは、プロンプト・応答・Microsoft Graph経由のデータを基盤LLMの訓練に使わないと説明していますし、SalesforceもEinstein Trust Layerで外部モデルプロバイダーへのゼロデータ保持を掲げています。
しかし、あなたが言っているのは、それとは別のレイヤーです。問題は、訓練に使うかどうかではなく、SaaS/AI基盤企業がAIエージェント運用を通じて、顧客企業の業務構造、意思決定の癖、利益の出るプロセス、失敗パターン、自動化可能領域、組織の弱点、顧客接点、承認フロー、現場の暗黙知を継続的に観察・抽象化できることです。
これはインテリジェンスで言えば、かなり高価値な情報です。

企業秘密は「設計図」だけではない

たとえば、ある製造業の企業秘密は、必ずしも「設計図ファイル」そのものだけではありません。
どこで在庫が詰まるか。どの顧客が利益率が高いか。どの工程が属人化しているか。どのサプライヤーが弱点か。どの営業パターンが勝つか。どのクレームが本当に危険か。どの承認フローが形骸化しているか。どの部門が意思決定を遅らせているか。こういう情報は、企業秘密そのものです。
インテリジェンス機関が欲しがるのも、しばしば「機密文書の本文」だけではありません。むしろ、組織がどう動くか、どこが弱いか、何に反応するか、どこを押せば崩れるかです。
その意味で、AIエージェント運用ログや業務改善パターンは、企業の「行動地図」です。これは、原文データより危険な場合があります。

匿名化・集計化しても価値が残る

ここで重要なのは、匿名化・集計化しても価値が残ることです。SaaS企業は、個別企業名を伏せても、「この業界では、このプロセスをAI化すると利益が出る」「この規模の企業は、この承認フローで詰まる」「この業務は人間に残すべき」「この問い合わせはAIで自動解決できる」「この営業シグナルは成約率が高い」「この組織構造だとAI導入が失敗する」という知見を得られます。
これは顧客企業から見れば、集合知として便利です。しかし同時に、自社の競争優位が、SaaS企業の横断的な学習資産に吸収されるということでもあります。
だから、あなたの言う通り、これは「企業秘密を吸い上げる」のとニアリーです。より正確に言えば、企業秘密の中でも、形式知ではなく、業務構造・成功法則・弱点情報を吸い上げる。

AI基盤モデルが複数SaaSにまたがる場合、リスクはさらに抽象的になる

公式には、各社は「訓練には使わない」と言う。しかし、推論時には業務文脈に触れる。SaaS側は利用状況や成果指標を見る。プロダクト改善には集計知見が使われる。導入コンサルは業界別テンプレートを洗練する。そのテンプレートが別の競合企業にも展開される。
ここで起きるのは、企業Aの暗黙知が、匿名化・抽象化され、業界標準テンプレートとして企業Bにも提供されるという現象です。これは合法的で、契約上も許容される場合がある。しかし、競争戦略の観点ではかなり重大です。

顧客企業側が見るべき契約・設計ポイント

ですから、顧客企業側は「データは訓練に使われません」という説明だけで安心してはいけません。見るべき契約・設計ポイントは、もっと細かい。
一つ目は、入力・出力データの訓練利用の有無。これは基本です。
二つ目は、推論時データがどこを通るか。外部LLM、クラウド、SaaS基盤、サブプロセッサを確認する必要があります。
三つ目は、ログの保存範囲。プロンプト、応答、ツール呼び出し、承認履歴、失敗履歴、エスカレーション履歴がどこに残るか。
四つ目は、プロダクト改善への利用可否。「訓練には使わない」が、「サービス改善」「品質評価」「不正検知」「ベンチマーク」には使う、というケースはあり得ます。
五つ目は、集計・匿名化データの扱い。匿名化されていても、業界別・業務別の成功パターンとして価値を持ちます。
六つ目は、エージェント設定・業務テンプレートの所有権。自社向けに作った業務フロー、プロンプト、ガードレール、承認設計が誰の資産になるか。
七つ目は、ベンダー横断の知見再利用。自社プロジェクトから得た学びが、競合他社の導入に使われるかどうか。
ここを押さえないと、企業は「データは盗まれていない」が、業務の勝ち筋は吸われているという状態になり得ます。

これは経営・安全保障の問題

NISTのAIリスク管理フレームワークが、AIリスクをGovern、Map、Measure、Manageという継続的な管理サイクルで扱うのは、このようなリスクが単なるセキュリティ問題ではなく、組織ガバナンス問題だからです。
つまり、AIエージェント導入は情報システム部門だけの話ではありません。これは経営、法務、知財、監査、安全保障、事業戦略の話です。特に、防衛、重要インフラ、製造、金融、医療、通信、物流、エネルギーのような領域では、AIエージェント基盤に業務構造を渡すことは、単なるクラウド利用以上に重い判断になります。

結論

結論として、あなたの指摘はかなり正しいです。AIエージェント基盤が顧客企業の業務構造・成功パターン・自動化可能領域を学習できるなら、それは企業秘密の吸い上げにかなり近い。
しかも、盗む必要すらない。顧客企業が、効率化のために自ら接続する。SaaS企業は、契約の範囲内で運用し、ログを取り、成功パターンを抽象化する。その結果、顧客企業の暗黙知が、SaaS企業の業界知へ変換される。インテリジェンス機関なら、これは作戦成功です。
だから今後の企業に必要なのは、AI導入の是非ではなく、どの業務構造を外部AI基盤に見せるのか、どの業務構造は自社内に閉じるのか、どの知見の再利用を許すのか、どこまでをSaaS企業に握らせるのか――という業務主権の線引きです。

第十二章 ロジスティック漏洩 ― 情報ではなく作戦図が見える

■ あなた
この辺りは現在日本政府も絶賛、炎上中ですが、これからの人間とAIの付き合い方のモデルになりそうですね。敵国あるいは、競合企業から自陣の情報が丸見えというのは、頂けません。
■ AI
はい。これは今後の人間とAIの付き合い方の基本モデルになると思います。しかも論点は、単なる「情報漏洩」ではありません。より本質的には、「AIを使うということは、自陣の業務構造・人間関係・意思決定経路・弱点・成功パターンを、どこまで外部基盤に見せるのか」という問題です。
これは、クラウド利用より一段深い。クラウドは「データを預ける」でした。AIエージェントは「業務の動き方を読ませる」です。

今回の日本政府周辺の炎上は、象徴的

最近の議論では、Microsoft 365やTeams、Copilot、政府・裁判所系のクラウド運用をめぐって、「外部から職員情報や組織情報が見えるのではないか」「設定や運用が適切なのか」という問題が取り沙汰されています。たとえば山本一郎氏は、裁判所のMicrosoft 365環境から職員識別子などが外部から観測可能な状態だと指摘しています。これは公式発表ではなく独立系の指摘なので、事実関係の精査は必要ですが、問題提起としては非常に重要です。
また、IPAの「情報セキュリティ10大脅威 2026」でも、AI利用をめぐるサイバーリスクが組織編の上位に入り、Microsoft 365 Copilotの脆弱性「EchoLeak」について、社内の秘密データ等が流出する可能性があった事例として言及されています。
さらに、Microsoft 365 Copilotのバグで、機密メールがDLPポリシーを回避して要約される問題が報じられています。これも、AIが「本来は触らせたくない情報」へアクセスしてしまうリスクを示しています。
つまり、いま起きている炎上は、単なる設定ミスや一企業の問題ではなく、AI時代の情報主権問題の先触れです。

敵国・競合企業から「丸見え」は致命的

おっしゃる通り、自陣の情報が敵国や競合企業から見える状態は、かなりまずい。しかもAI時代に見られる情報は、単なる名簿やファイルに限りません。
誰がどの部門にいるか。誰が意思決定者か。どの部門がどの案件を持っているか。誰がどの会議に出ているか。どの承認フローが使われているか。どの問い合わせが炎上しているか。どの顧客が重要か。どの業務がAI化されているか。どこで人間承認に戻しているか。どこが自動化に失敗しているか。
これは、インテリジェンス的には宝の山です。敵対者が知りたいのは、必ずしも「機密文書そのもの」だけではありません。むしろ、組織の構造、反応速度、弱点、キーパーソン、意思決定経路です。AIエージェント基盤は、そこに触れます。だから危ない。

これは「AIを使うな」ではなく「見せる範囲を設計しろ」

ここで重要なのは、AIやSaaSを拒否することではありません。AIは使うべきです。SaaSも使うべきです。効率化しなければ、競争に負ける。ただし、何でも接続してはいけない。
必要なのは、AIに見せる情報の階層化です。低機密情報は外部AI/SaaSでよい。中機密情報は契約・ログ・権限管理を厳しくした法人向け基盤に限定する。高機密情報は国内クラウド、閉域環境、オンプレ、専用AI、あるいは人間処理に残す。安全保障・防衛・司法・重要インフラの中核情報は、外部SaaSの標準AIエージェントにそのまま渡さない。この線引きが必要です。
Microsoft 365 Copilotについても、Microsoftは顧客データ、プロンプト、応答を基盤LLMの訓練には使わないと説明しています。しかし、それは「Copilotが業務データにアクセスしない」という意味ではありません。Microsoft Graph上の権限に基づき、ユーザーがアクセスできる組織データを使って回答する設計です。したがって、権限設計が甘ければ、AIが見える範囲も広がります。

今後のモデルは「ゼロトラストAI」

これから必要になるのは、ゼロトラストのAI版です。つまり、AIだから信頼するな、SaaSだから信頼するな、大企業だから信頼するな、契約しているから信頼するな、常に、誰が何を見られるかを制御しろ、という考え方です。
具体的には、AIに渡すデータを最小化する。AIのアクセス権限を職務単位で切る。全プロンプト・応答・ツール実行をログ化する。機密ラベル付きデータをAIが要約・抽出できないようにする。外部LLMに渡るデータを監査する。匿名化・集計化データの二次利用も契約で制限する。エージェントが使えるAPIを限定する。重要判断は人間承認に戻す。業務フローやプロンプトテンプレートの所有権を明確にする。国・業界ごとにデータ主権要件を分ける。これが今後の基本になります。

日本政府の炎上は、むしろ早く起きてよかった

皮肉ですが、この問題は早めに燃えた方がよいです。なぜなら、AIエージェントが本格普及してから発覚すると、被害範囲がもっと深くなるからです。
今はまだ、職員情報、Teams、Copilot、クラウド設定、DLP、権限管理の問題として見えています。しかし数年後には、AIエージェントが行政手続き、司法補助、防衛調達、医療、税務、教育、インフラ運用に入り込む。その段階で「外部から見えていました」「AIが読める状態でした」「ログが海外基盤にありました」では済まない。だから今の炎上は、かなり重要な警鐘です。

結論

これからのAIとの付き合い方は、
AIを使うが、AIに自陣を丸裸にしない
というモデルになります。AIは強力な労働力になる。SaaS企業はAIエージェントの稼働基盤になる。しかし、その基盤に自社・自国の業務構造を深く見せることは、情報主権上のリスクになる。
特に政府、司法、防衛、重要インフラ、金融、医療、製造業の中核部分では、「便利だから接続する」ではなく、「どこまで見せるかを国家・経営レベルで決める」必要があります。敵国や競合企業から自陣の情報が丸見え。これは論外です。AI時代の安全保障は、軍事やサイバーだけではなく、AIエージェントに何を見せるかから始まると思います。

終章 「ロジスティック漏洩」とAIエコシステムの安全設計

■ あなた
もっと端的に言うと、単なる情報ではなくロジスティックが丸見え。今後は、AI基盤モデル、SaaS企業とエコシステムとして、安全設計を構築しなければなりません。その辺りが見えてきただけでも良しとしましょう。
■ AI
はい。端的に言えば、AI時代の最大リスクは「情報漏洩」ではなく「ロジスティック漏洩」です。単なるファイル、名簿、メール本文が見えるだけではない。誰が、どの順番で、何を判断し、どこで詰まり、どの資源を動かし、どの業務が弱点で、どのルートが生命線なのか。そこまで見える。これは、インテリジェンス的には「中身」より価値がある場合があります。

「ロジスティックが丸見え」は、情報漏洩より深い

情報漏洩は、たとえば「資料が漏れた」「顧客名簿が見えた」という話です。しかしロジスティック漏洩は違います。
どの部門が意思決定を握っているか。どの承認フローが実質的に機能しているか。どの在庫・人員・サプライヤー・顧客が重要か。どこにボトルネックがあるか。どの業務をAIに任せられると利益が出るか。どの業務は人間に戻さないと危険か。どこに組織の弱点があるか。これは企業や国家の作戦図です。
AIエージェントは、まさにこの作戦図にアクセスして働く。だから、AI基盤モデル、SaaS企業、クラウド、ID基盤、監査ログ、コネクター、外部モデルの全部を含めて、エコシステムとして安全設計しなければならない。
NISTのAI Risk Management Frameworkも、AIリスクを単発のセキュリティ問題ではなく、Govern / Map / Measure / Manage という継続的な統治サイクルで扱う枠組みにしています。これは、AIを「導入して終わり」ではなく、組織全体のリスク管理対象として扱う発想です。

今後の安全設計は「AI単体」ではなく「AIサプライチェーン」

ここが見えてきたのは大きいです。AI基盤モデルだけを見ても不十分です。SaaS企業だけを見ても不十分です。クラウドだけを見ても不十分です。見るべきなのは、次の全体です。
AI基盤モデルでは、どのモデルに何を渡すのか。SaaS企業では、業務プロセスとエージェント設計図をどこまで握るのか。クラウドでは、どの地域・法域・データセンターで処理されるのか。ID/権限基盤では、誰の権限でAIが何を読めるのか。コネクターでは、外部データがどこまでCopilotやAgentに入るのか。ログ基盤では、プロンプト、応答、ツール実行、承認履歴がどこに残るのか。導入コンサル/FDEでは、業務構造の知見がどこまで再利用されるのか。
たとえばMicrosoft 365 Copilotは、Microsoft Graph上の権限に基づき、ユーザーがアクセス権を持つデータを回答に使う設計です。Microsoftは、プロンプト・応答・Graph経由データを基盤LLMの訓練には使わないと説明していますが、Copilotが業務データにアクセスしてグラウンディングする構造自体は明確です。つまり、問題は「訓練に使われるか」だけではない。推論時に何を読めるかが、すでに安全保障上の論点になります。

これから必要なのは「ゼロトラストAI」

これまでのゼロトラストは、人間ユーザーや端末に対する考え方でした。これからは、AIエージェントにも同じことを適用する必要があります。
AIに最小権限しか与えない。AIが読める情報を職務単位で分離する。AIのツール実行をログ化する。AIのデータ参照経路を監査する。AIが外部モデルに渡す内容を制御する。高機密業務は閉域・国内・専用基盤に分ける。AIが作った提案を人間が採用した理由を残す。匿名化・集計化された業務知見の二次利用も契約で制限する。
この設計なしにAIエージェントを広げると、効率化と引き換えに、自陣の作戦図を外部基盤に渡すことになります。

日本にとっては、ここが国家インフラ論になる

日本政府や重要インフラで起きている議論は、個別のクラウド設定ミスやベンダー批判だけで終わらせるべきではありません。本質は、「国家や企業のロジスティックを、どのAI基盤に、どの範囲で、どの法域で、どの監査条件で見せるのか」です。
特に司法、防衛、警察、行政、医療、金融、通信、エネルギー、物流、製造の中核部分では、AI基盤の選定は単なるIT購買ではありません。これは業務主権・情報主権・安全保障の問題です。OECDのAI原則も、AIには人権、民主的価値、透明性、説明責任を求める方向を示しています。抽象的に聞こえますが、実装に落とすと「誰がAIを管理し、誰が責任を負い、どのデータと業務構造を見せるのか」という問題になります。

見えてきただけでも大きい

今回の議論で見えた構図は、かなり重要です。AIエージェントは便利。SaaS企業はその稼働設計図を持つ。しかし、その設計図は企業・国家のロジスティックそのものに近い。AI基盤モデルとSaaS企業は、推論時アクセス、ログ、改善知見、テンプレート化を通じて、業務構造を学び得る。したがって、AI導入は「便利なツール導入」ではなく、「自陣の作戦図をどこまで外部エコシステムに見せるか」という判断になる。
だから、今後の基本線はこうでしょう。
AIは使う。しかし丸見えにはしない。SaaSは使う。しかし業務主権は渡さない。基盤モデルは使う。しかし高機密ロジスティックは分離する。エコシステム全体で、安全設計・契約・監査・法域・権限管理を組む。
この視点が見えただけでも、かなり前進だと思います。