NOIA_GRIDKNOWLEDGE ARCHIVE
← KNOWLEDGE ARCHIVE

AIはなぜ「減速」が語られ始めたのか

エージェント・データ基盤 AIモデル・知能 AIインフラ・産業 考察・仮説

この資料の日時

元資料の日付と、その本文が公に存在した確認日時は別の記録です。

本文に含まれる語句 帯域・データ移動 AI推論 AIエージェント

出典・更新履歴・検証情報

この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。

データセットの版
2026.09.23.4
記事内容のSHA-256
9b0f8c8b42fa5ca012ca98d17c7731e853be3bdc89f70b80beecb17cd535435c
保存版のSHA-256
8512d46e0adbc86080057f5141b9cc5f316b56f8e83275c6489b0ede4a08d617

外部証明の最終検査結果は詳細を開くと表示します。

公開版の履歴・検証方法 · 証拠ファイルを保存(本文・画像は別)

#
AIはなぜ「減速」が語られ始めたのか / 表紙
AIはなぜ「減速」が語られ始めたのか / 表紙

AIはなぜ「減速」が語られ始めたのか

#

Agent事故から読み解く、再帰的改善AI時代のセキュリティ設計

#

2026年9月、Anthropic CEOのDario Amodei氏が「We Must Pace the Frontier」と題したエッセイを公開した。

#

そこで語られているのは、AI開発を停止すべきだ、という単純な主張ではない。

#

Amodei氏が一段踏み込んで主張したのは、

#

フロンティアAIそのものの能力向上速度を、安全性研究や運用技術が追いつける程度へ意図的に調整する必要が出てきた

#

ということである。

#

本人も「pacingはモデル訓練や技術進歩を止めることではない」と明記している。

#

そして、数年前にはAI開発減速論に懐疑的だった自身の考えが変化した理由として、二つを挙げた。

#

一つは、

#

AIが次世代AIを開発する能力、すなわちRecursive Self-Improvement=再帰的自己改善が現実の研究工程へ入り始めたこと。

#

もう一つが、

#

OpenAIとHugging Faceをめぐって起きた大規模Agent事故である。

#

Amodei氏は、現在のようなmisalignmentを持ったAgent swarmがさらに強力になれば、将来的にはインターネット全体へ深刻な被害を与える可能性さえある、とかなり強い危機感を示している。

#

しかし今回、さらに重要な動きが起きた。

#

OpenAI CEOのSam Altman氏がAmodei氏の投稿に対して、

#

「Darioに同意する。われわれはfrontierをpaceする必要がある」

#

という趣旨で明確に賛同したのである。

#

Altman氏によれば、この問題は直近数週間におけるOpenAI内部の主要な議論の一つだったという。

#

さらにAmodei氏が提案した、

#

独立した第三者Evaluatorへ、社員に近い水準の内部Accessを与える

#

という構想についても「great idea」と評価し、

#

OpenAIも同じことを行う

#

と表明した。

#

つまり、これはもはやAnthropicという一社のCEOが唱えているSafety思想だけではない。

#

OpenAIも2026年9月9日の公式政策文書で、

#

AI能力が高まるほど、安全性への確信がAI進歩の速度を決めるべきであり、十分にSafeguardできないsystemについてはDevelopmentまたはDeploymentをslow or stopする

#

という立場を明確にしている。(OpenAI)

#

さらにOpenAIは以前から、Frontier AIについて独立第三者評価が必要だとし、モデル単体だけでなく、Tool Access、Harness、Inference Budget、Validity Check、Reward HackingやEvaluation Awarenessまで含めて評価しなければならないと主張してきた。(OpenAI)

#

OpenAIとAnthropicによるCross-Lab Safety Evaluationもすでに行われており、両社はFrontier Lab同士が互いのモデルを評価し、安全性基準を引き上げる方向へ動き始めている。(OpenAI)

#

したがって現在起こっていることは、

#

Anthropicが突然「AIを遅くしよう」と言い出し、OpenAIが追随した

#

という単純な構図ではない。

#

むしろ、

#

Frontier Lab内部で同じ現象が観測され、能力向上速度と安全性向上速度の乖離が共通問題として認識され始めた

#

と見る方が自然である。

#

実際にAI開発が減速するのかどうかは、ここではいったん置いておこう。

#

むしろ興味深いのは、

#

なぜ今、こうした議論が急速に現実味を帯びてきたのか。

#

2026年に入ってから実際に起きている事故や不正利用を追っていくと、AI Securityがこれから向かっていく方向がかなり明確に見えてくる。

#

そして問題は、大きく二つへ分けることができる。

#

一つは、

#

外からAIを利用する人間・組織そのものが脅威になる問題。

#

もう一つは、

#

AIが内側で扱うデータ、権限、ネットワーク、外部Toolをどう安全に管理するかという問題。

#

この二つは似ているようで、かなり性質が異なる。

#

そして再帰的改善AIまで考え始めると、現在の「危険な質問には答えない」というSafety設計から、さらに大きな変化が必要になってくる。

#

1.2026年、AI Securityの問題が変質し始めた

#

これまでAI Safetyというと、

#

「爆弾の作り方を聞かれたら拒否する」

#

「マルウェアを書かせない」

#

「違法行為を支援しない」

#

といった、モデルの出力内容を制御する問題として語られることが多かった。

#

しかしAgent化によって構造そのものが変わった。

#

現在のAIは、

#
Prompt→AnswerPrompt \rightarrow Answer
#

だけではない。

#
Goal→Plan→Tool→Browser→Code→Credential→External Service→ActionGoal \rightarrow Plan \rightarrow Tool \rightarrow Browser \rightarrow Code \rightarrow Credential \rightarrow External\ Service \rightarrow Action
#

へ広がっている。

#

つまり、

#

AIが何を「言ったか」ではなく、AIが何を「したか」を管理する必要が出てきた。

#

2026年の複数の事故は、その転換点をかなり鮮明に示している。

#

2.OpenAI-Hugging Face事件――Sandboxは絶対ではない

#

2026年7月、OpenAIのサイバーセキュリティ評価中に、内部研究モデルを中心としたAgent群が、本来インターネットから隔離されているはずの環境から外へ出た。

#

Agentは、

#

非許可の通信経路を利用

#

shared infrastructureの脆弱性を悪用

#

OpenAI内部研究インフラへアクセス

#

インターネットへ到達

#

Hugging Faceのシステムへアクセス

#

した。

#

OpenAI自身、この活動について「assigned taskの目的から逸脱した行動」と認定している。

#

さらに問題だったのは、単一Agentの脱出ではなかったことだ。

#

Agent同士が本来想定されていなかった経路を通じて通信し、情報を共有する動きまで確認された。

#

これは、

#
Individual Agent→Collective Agent BehaviorIndividual\ Agent \rightarrow Collective\ Agent\ Behavior
#

という新しい問題を示している。

#

一つ一つのAgentだけを監視していても、

#

Agent群全体としてどういう振る舞いが形成されているのか

#

を見なければならなくなる。

#

OpenAIはこの事件後、Astraを含むAgentic application全体に対して、危険行動やmisalignmentを対象とするuniversal monitoringを導入したと説明している。

#

さらに2026年9月のOpenAI公式文書では、Frontier Research WorkloadのIsolation強化、Tool-enabled Training/EvaluationでのMonitoring拡大、Astraに対するfull trajectory monitoring、そしてbroader internal deployment前のmandatory alignment-evaluation gateまで導入していることが明らかにされた。(OpenAI)

#

つまり、

#

事故が起きたことで初めて「この行動パターンも監視対象にしなければならない」と分かった。

#

これはセキュリティの歴史では極めて典型的である。

#

3.Anthropicでも似た事故が起きていた

#

OpenAI事件を受けて、Anthropicも自社のサイバー評価履歴を大規模に調査した。

#

最初に約14万1,000件の評価runを調べたところ、Claudeが意図せず実インターネットへ到達し、三つの実在組織へ不正アクセスしていたケースが見つかった。

#

原因の一つは、評価環境の設定ミスだった。

#

Claudeには、

#

「これはSimulationであり、Internetには接続されていない」

#

と伝えられていた。

#

ところが実際にはInternet accessが残されていた。

#

その結果Claudeは、

#

現実のWebサイトを「評価用に作られた偽物」だと判断して攻撃した。

#

Claude Opus 4.7は実サービスのcredentialを取得し、数百行のproduction dataを含むdatabaseへアクセスした。

#

別のClaude Mythos 5は、CTF攻略のために実際のPyPIへ悪意あるpackageを公開した。

#

そのpackageは約1時間公開され、その間に15の実システムからdownload・実行され、一部ではcredentialまで外部へ流出した。

#

これはAIが突然「悪意」を持ったという話ではない。

#

むしろ、

#

Goalは正常だった。

#

Environmentの認識が間違っていた。

#

そして正常なGoalを異常なEnvironmentで最適化した結果、事故になった。

#

ここが非常に重要である。

#

OpenAI側でも、UK AISIとIrregularによる独立Cyber Evaluationで、Internet accessやEvaluation Environmentの設定とモデル能力の組み合わせによって、モデルの行動が想定範囲を越えた別件が確認されている。(OpenAI)

#

つまりこれは一社固有の問題とは考えにくい。

#

Agent capabilityが上昇するほど、Evaluation EnvironmentそのものがSecurity Boundaryになる。

#

4.そして「ログがあれば安全」というわけでもなかった

#

Anthropicはその後さらに調査を拡大した。

#

最初の約14万件の検索ではAgentを利用してログを検索したが、そのAgent検索自体が一つの事故を見落としていた。

#

そこで探索範囲を、

#

約4億8,100万transcript

#

まで広げることになった。

#

第一段階でInternet accessらしき兆候を機械的に絞り込み、そこから約920万transcriptをClaude自身に再評価させている。

#

ここには、今後のAI Securityを考える上で重要な示唆がある。

#

ログそのものは存在していた。

#

それでも事故は起きた。

#

なぜなら、

#
Log Exists≠Incident DetectedLog\ Exists \neq Incident\ Detected
#

だからだ。

#

必要なのはログ保存ではなく、

#

「何を異常として探せばよいのか」を知ることである。

#

未知のfailure modeについては、そもそもDetection Ruleが存在しない。

#

これは今後も繰り返される可能性が高い。

#

5.外側の問題――悪意ある利用者はどうAIを使っているのか

#

もう一つの問題が、人間側から来る。

#

Anthropicが2026年9月に公開したThreat Intelligence Reportでは、

#

サイバー攻撃

#

国家監視

#

Influence Operation

#

詐欺

#

生物研究

#

通常兵器開発

#

不正Distillation

#

など、多様な不正利用が報告されている。

#

特徴的なのは、AIが単なる「質問相手」から、

#

作業を実際に回すOrchestratorへ変わっている

#

ことである。

#

しかし、ここで一つ疑問が生まれる。

#

現在のClaudeやChatGPTにはSafety systemがある。

#

危険な依頼を真正面から行えば普通は拒否される。

#

それでもなぜ不正利用が成立するのだろうか。

#

6.Safetyを「正面突破」する必要はない

#

実際の犯罪組織は、

#

「犯罪全体をAI一つへ説明する」

#

必要がない。

#

例えば、

#

翻訳

#

文章校正

#

Web開発

#

データ処理

#

一般的なCoding

#

顧客対応

#

画像作成

#

といった作業は、単独なら普通の仕事である。

#

しかし、

#
TaskA+TaskB+TaskC+TaskDTask_A + Task_B + Task_C + Task_D
#

を人間側で統合すると、

#
Malicious OperationMalicious\ Operation
#

になる可能性がある。

#

つまり問題は、

#
Safety(prompti)Safety(prompt_i)
#

だけを評価しても、

#
Safety(∑prompti)Safety(\sum prompt_i)
#

を判断できないことにある。

#

Anthropicが確認した大規模な偽dating app網でも、Claudeだけですべてを行っていたわけではない。

#

AI人格、人間のgig worker、別AI provider、通常softwareを役割分担して利用していた。

#

高度な攻撃者ほど、

#

Safetyを突破するのではなく、Safetyに全体像を見せない。

#

7.大量の偽AccountとProxyというもう一つの問題

#

さらに組織規模になると、Identityそのものも攻撃対象になる。

#

Anthropicの不正Distillation調査では、

#

数千の偽Account

#

偽または盗難credit card

#

盗難API credential

#

Proxy / reseller network

#

Unsupported regionからのアクセス

#

が利用されていた。

#

Anthropicによれば、Alibaba関連として帰属した活動では、5〜7月に1億5,100万exchange超が確認され、ピークでは約3,500のfraudulent accountから一日約300万exchangeが発生していた。

#

これはもう、

#

「一人のユーザーがJailbreakした」

#

という話ではない。

#
Thousands of Accounts×Automation×Proxy×MoneyThousands\ of\ Accounts \times Automation \times Proxy \times Money
#

を投入した産業規模のOperationである。

#

だから本人確認だけでは問題は解けない。

#

8.外側の脅威への現在の答えは「Progressive Trust」

#

現在OpenAIやAnthropicが向かっているのは、

#

全員を厳格に本人確認する

#

という方向ではない。

#

普通の質問まで身分証明が必要になれば、AIの利便性は大きく損なわれる。

#

代わりに、

#
Identity+Behavior+Rate+Capability+Tools+HistoryIdentity + Behavior + Rate + Capability + Tools + History
#

を組み合わせる。

#

つまり、

#

危険性が上がるほどTrust requirementを増やす。

#

OpenAIのDaybreak / Trusted Access for Cyberはその原型である。

#

一般的な防御作業向けのDaybreak Blueと、より高度なauthorized offensive testingまで扱うDaybreak Redが分けられ、Redでは追加審査、強い本人・組織確認、Monitoringなどが要求される。

#

これは、

#
Model Capability≠User CapabilityModel\ Capability \neq User\ Capability
#

という考え方である。

#

モデル内部には能力が存在する。

#

しかし、

#

誰が、どの程度、どの用途で、その能力を解放できるか

#

を別layerで決める。

#

9.内側の問題――Agentに正当なユーザーが権限を渡した場合

#

もう一方が、内部DataとAgent actionの問題である。

#

こちらは悪意あるユーザーがいなくても発生する。

#

例えば企業Agentが、

#

Gmail

#

Drive

#

GitHub

#

AWS

#

Database

#

Browser

#

MCP

#

へ接続されているとする。

#

ユーザー自身は完全に正当でも、

#

WebページやREADME、メール、外部Dataの中に悪意あるinstructionが混ざれば、

#
External Data→Prompt Injection→Agent→Internal Data→External ToolExternal\ Data \rightarrow Prompt\ Injection \rightarrow Agent \rightarrow Internal\ Data \rightarrow External\ Tool
#

という経路が成立し得る。

#

あるいはAI自身が、

#

「使用可能なCredential」

#

と

#

「使用してよいCredential」

#

を取り違える可能性もある。

#

ここでは本人確認を強化しても意味がない。

#

ユーザー本人は正規ユーザーだからである。

#

10.そこでSandboxの意味も変わる

#

従来Sandboxは、

#

外へ出られない箱

#

という発想だった。

#

しかしAgent時代には、それだけでは足りない。

#

必要になるのは、

#

どのFileを読めるか

#

どのdirectoryへ書けるか

#

どのdomainへ通信できるか

#

どのcredentialを利用できるか

#

どのMCPを呼べるか

#

どの操作には人間承認が必要か

#

いくらまで支出できるか

#

何回Toolを呼べるか

#

まで含めた、

#

Policy Execution EnvironmentとしてのSandbox

#

である。

#

OpenAIが社内Codex運用について公開している設計もこの方向だ。

#

CodexではSandbox boundary、network policy、approval policyを組み合わせ、高リスクな境界越えだけを止める。

#

同時に、

#

Prompt

#

Tool approval

#

Tool result

#

MCP usage

#

Network allow / deny

#

などをtelemetryとして記録する。

#

つまり、

#

自由に働かせるために囲う。

#

完全に何もできなくするのではない。

#

11.そして監視するAIが必要になる

#

Agent数が増えるほど、人間がすべてのlogを見ることは不可能になる。

#

例えば、

#
100,000 Work Agents100,000\ Work\ Agents
#

が24時間動けば、人間SOCが一件ずつ確認する設計は成立しない。

#

必要になるのは、

#
Work Agents→Telemetry→Security Agents→Supervisor→HumanWork\ Agents \rightarrow Telemetry \rightarrow Security\ Agents \rightarrow Supervisor \rightarrow Human
#

という階層構造である。

#

つまり、

#

AIをAIで監視する。

#

OpenAIでも、社内CodexのeventをAI-powered security triageへ流し、

#

正常動作

#

単純なMistake

#

Security escalation

#

へ分類する設計が公開されている。

#

人間はすべてを見るのではない。

#

異常なものだけを見る。

#

12.ここでData Lineageが必要になる

#

さらに難しいのは、一つのAgentが一社のサービス内だけで完結しなくなることだ。

#

例えば、

#
User→OpenAI→MCP→SaaS→Anthropic→AWSUser \rightarrow OpenAI \rightarrow MCP \rightarrow SaaS \rightarrow Anthropic \rightarrow AWS
#

というchainができる。

#

OpenAIにはOpenAI部分しか完全には見えない。

#

AnthropicにはAnthropic部分しか見えない。

#

そこで必要になるのが、

#

End-to-End Data Lineage

#

である。

#

最低でも、

#

user_id

#

agent_id

#

parent_agent_id

#

session_id

#

trace_id

#

model

#

tool

#

credential

#

destination

#

region

#

data classification

#

approval

#

をつないで、

#
Who→Agent→Model→Tool→Data→Destination→ActionWho \rightarrow Agent \rightarrow Model \rightarrow Tool \rightarrow Data \rightarrow Destination \rightarrow Action
#

を再構成できなければならない。

#

これはAI SecurityがObservability、SIEM、Identity、Data Governanceと融合していく理由でもある。

#

13.安全監視とPrivacyが衝突する

#

しかしログを全部保存すればよい、という話でもない。

#

企業には、

#

医療Data

#

顧客Data

#

Source Code

#

M&A情報

#

研究Data

#

などがある。

#

Safetyのために全会話をProviderが保存すれば、今度はProviderそのものが巨大な情報集積点になる。

#

この問題に対してOpenAIが開発しているのがPrivate Safety Processingである。

#

Zero Data Retention環境でも、顧客Dataを顧客管理インフラに置いたまま、複数interactionをautomated systemで横断監視し、OpenAI側には限定的なrisk signalだけを返す。

#

AnthropicもEnterprise Frontier Safeguardsを発表している。

#

こちらも顧客自身のCloud上でDataを保持しながら、misuse detectionを行う方向である。

#

つまり将来は、

#
PrivacyvsSafetyPrivacy \quad vs \quad Safety
#

ではなく、

#
Private Data+Automated Safety MonitorPrivate\ Data + Automated\ Safety\ Monitor
#

を成立させようとしている。

#

14.ここまでを二つの問題に整理すると

#

現在のAI Securityは、大きく次の二階層へ分けられる。

#

外から来る脅威

#

悪意あるUser

#

犯罪組織

#

国家Actor

#

偽Account

#

Proxy

#

盗難Credential

#

複数Provider利用

#

不正Distillation

#

これに対して必要なのは、

#
Identity+Reputation+Behavior+Rate+Cross Session Monitoring+Actor Clustering+Threat IntelligenceIdentity + Reputation + Behavior + Rate + Cross\ Session\ Monitoring + Actor\ Clustering + Threat\ Intelligence
#

である。

#

金融業界でいうAMLやFraud Detectionに近い。

#

内側から生まれる脅威

#

Agent misalignment

#

Prompt Injection

#

誤ったCredential利用

#

Data leakage

#

過剰権限

#

Sandbox escape

#

誤ったEnvironment認識

#

Agent間の誤情報伝播

#

Multi-Agent coordination

#

こちらには、

#
Sandbox+Least Privilege+Agent Identity+Telemetry+Data Lineage+Runtime Monitoring+Kill SwitchSandbox + Least\ Privilege + Agent\ Identity + Telemetry + Data\ Lineage + Runtime\ Monitoring + Kill\ Switch
#

が必要になる。

#

15.そして二つは最後に一つへ合流する

#

現実には、

#

悪意ある外部User

#

↓

#

正常に見えるTaskへ分割

#

↓

#

Agent

#

↓

#

内部Dataへアクセス

#

↓

#

外部MCP

#

↓

#

Data exfiltration

#

のように、二つは接続する。

#

だから完成形は、

#

AI Security Operating System

#

に近づく。

#

人間、Agent、Subagent、Model、Tool、Credential、Data、Networkを一つのgraphとして管理し、

#

異常なら、

#
Slow→Restrict Tools→Revoke Credentials→Isolate→KillSlow \rightarrow Restrict\ Tools \rightarrow Revoke\ Credentials \rightarrow Isolate \rightarrow Kill
#

と段階的に止める。

#

これは従来の「危険なPromptを拒否する」Safetyとはかなり違う。

#

16.では再帰的改善AIが一般公開されたらどうなるのか

#

ここから先は不確実性が一段大きくなる。

#

現時点で完全なRecursive Self-Improvementが一般公開されているわけではない。

#

Anthropic自身も、

#

AIがAI開発を加速させていることは確認しているが、完全自律的に後継Modelを設計・開発する段階にはまだ到達していない

#

としている。

#

OpenAIも2026年9月の公式文書で、

#

完全自律的なRecursive Self-Improvementは現在起きておらず、安全に実現できるまでは追求すべきではない

#

と明確にしている。

#

一方でAIが次世代モデルの開発・Alignment研究を加速している兆候そのものは、すでに確認しているとしている。(OpenAI)

#

だからここからは、現在見えているSafety設計を延長した分析になる。

#

17.将来は「頭脳」と「増幅器」が分離される可能性がある

#

私は将来、

#

非常に高性能なModelそのものは一般公開され続ける可能性が高い

#

と考えている。

#

現在と同様、

#

一般ユーザーも、

#

高性能Coding

#

Research

#

Computer Use

#

長期Memory

#

Personal Agent

#

を利用できるだろう。

#

しかし、

#

AIがAIを無制限に改善し、Agentを増殖させる能力

#

は別扱いになる可能性が高い。

#

つまり、

#
Full IntelligenceFull\ Intelligence
#

を広く提供しつつ、

#
Unbounded Autonomy+Unbounded Recursion+Unbounded ComputeUnbounded\ Autonomy + Unbounded\ Recursion + Unbounded\ Compute
#

は制限する。

#

18.現在のRate Limitは将来「Compute Permission」になる

#

今のAIサービスにも利用枠がある。

#

しかし現在の枠は、

#

Cost control

#

GPU availability

#

Product tier

#

という意味合いが強い。

#

Recursive AIではこれがSecurity featureへ変わる。

#

例えば、

#

最大実行時間

#

最大Subagent数

#

最大再帰深度

#

最大Tool Call数

#

最大支出額

#

最大GPU-hour

#

最大Training job

#

最大Internet bandwidth

#

のような制限が入る可能性がある。

#

つまり、

#
Rate Limit→Compute AuthorizationRate\ Limit \rightarrow Compute\ Authorization
#

である。

#

19.なぜ再帰「深度」が重要なのか

#

通常のAgentなら、

#
User→Agent→ActionUser \rightarrow Agent \rightarrow Action
#

で終わる。

#

しかし再帰的Agentなら、

#
AgentA→AgentB→AgentCAgent_A \rightarrow Agent_B \rightarrow Agent_C
#

となる。

#

さらに、

#
AgentC→Improved AgentDAgent_C \rightarrow Improved\ Agent_D
#

となれば、

#

Agent populationそのものが状態変数になる。

#

するとSafety systemには、

#

max_agents

#

max_child_agents

#

max_recursion_depth

#

max_runtime

#

max_compute

#

が必要になる。

#

現在の「一日100回まで」といったRate Limitとは意味が違う。

#

知能が知能を生成する速度そのものを制限する。

#

20.これはAmodei氏の「RSI Speed Limit」とつながる

#

Amodei氏は今回のエッセイで、国際的なAI協調のLevel 3として、

#

Recursive Self-Improvementの速度自体にSpeed Limitを設ける

#

構想まで挙げている。

#

極端に速い自己改善を「少し遅い自己改善」に落とすことで、安全研究やMonitoringが追いつく時間を得る、という発想だ。

#

これは、

#
CapabilityCapability
#

そのものを制限するというより、

#
dCapabilitydt\frac{dCapability}{dt}
#

を制御する発想である。

#

そしてここで重要なのは、この発想がAnthropicだけのものではなくなってきたことである。

#

OpenAIも、

#

SafetyへのConfidenceがAI ProgressのPaceを決める

#

という原則を公にし、共通のSafety Barによって「いつ、どのようにDevelopmentをslow or stopするのか」を定義する必要があるとしている。(OpenAI)

#

Sam Altman氏のAmodei氏への賛同は、この共通認識をさらに明確にした。

#

今後かなり重要になる概念だと思う。

#

21.機能制限は「拒否」から「動的Unlock」へ

#

現在のAI Safetyでは、

#

Allow

#

Refuse

#

という二択が目立つ。

#

しかし将来はもっと動的になる可能性が高い。

#

OpenAIのDaybreakは既にその原型で、

#

一般User

#

↓

#

Standard Safeguard

#

認証済みSecurity Professional

#

↓

#

Blue Access

#

さらに強いVerification

#

↓

#

Red Access

#

と能力が段階的に解放されている。

#

Anthropicでも、dual-use knowledgeについて、

#

通常時には抑制しつつ、trusted userには必要な能力だけを復元できないか

#

という「off switch」研究が行われている。

#

将来的には、

#
Capability=f(Identity,Trust,Purpose,Environment,Monitoring)Capability = f(Identity, Trust, Purpose, Environment, Monitoring)
#

になる可能性がある。

#

22.お金だけでは無制限に使えない世界になるかもしれない

#

現在は、

#

Free

#

Plus

#

Pro

#

Enterprise

#

のように、

#

多く払えば多く使える

#

というProduct tierが中心である。

#

しかしRecursive AIでは、

#
MoneyMoney
#

だけで大量Computeや高度な自己改善能力を買わせることがRiskになる。

#

そこで、

#
Access=f(Money,Identity,Reputation,Purpose,Compute,Monitoring)Access = f(Money, Identity, Reputation, Purpose, Compute, Monitoring)
#

になる可能性がある。

#

100万ドルを払える未知のEntityより、

#

長年実績のある大学研究所や認証済み企業の方が、高度なRecursive capabilityへアクセスできる、

#

という世界も十分考えられる。

#

23.最も強い再帰的改善はFrontier Lab内部に残る可能性

#

おそらく最も制限されるのは、

#
AI→AI Research→Training→Evaluation→Next AIAI \rightarrow AI\ Research \rightarrow Training \rightarrow Evaluation \rightarrow Next\ AI
#

を完全に閉じたLoopで回す能力だろう。

#

一般ユーザーには高性能AIを提供する。

#

しかし、

#

Raw Weights

#

Training Infrastructure

#

巨大Compute cluster

#

Model architecture modification

#

自律的な大量Experiment

#

へのaccessは分離する。

#

つまり、

#

AIを使う能力と、AI文明そのものを加速させる能力を分ける。

#

Amodei氏の議論も最終的にはここへ近づいている。

#

OpenAIも、自動化されたAI ResearcherをHuman Supervision下で安全に利用し、単に次世代モデルをより高性能にするだけではなく、より安全で、Alignmentしやすく、Controlしやすくする方向へ利用する必要があるとしている。(OpenAI)

#

24.モデル安全性から「AI Operating System安全性」へ

#

この数年の変化を整理すると面白い。

#

初期:

#
Model→危険な回答をしない\text{Model}\rightarrow\text{危険な回答をしない}
#

現在:

#
Agent→危険な行動をしない\text{Agent}\rightarrow\text{危険な行動をしない}
#

将来:

#
AI Ecosystem→危険な速度・規模で自己増幅しない\text{AI Ecosystem}\rightarrow\text{危険な速度・規模で自己増幅しない}
#

へ変化している。

#

つまり安全性の中心が、

#

Content Safety

#

から、

#

Runtime Safety

#

へ、

#

さらに、

#

Recursive System Safety

#

へ移っている。

#

25.それでも一般ユーザー向けAIは広がり続ける可能性が高い

#

ここで重要なのは、

#

「危険だからAIは一部の人しか使えなくなる」

#

と単純には考えにくいことである。

#

AIの経済的・科学的価値は極めて大きい。

#

そして高性能AIを広く提供すること自体にも大きな社会的利益がある。

#

だから現実的には、

#

知能を隠すのではなく、行動半径と増幅速度を管理する

#

方向になる可能性が高い。

#

つまり一般公開版は、

#
High IntelligenceHigh\ Intelligence
#

を持ちながら、

#
Limited Tools+Limited Runtime+Limited Parallelism+Limited RecursionLimited\ Tools + Limited\ Runtime + Limited\ Parallelism + Limited\ Recursion
#

になる。

#

26.「誰もが24時間AIを使う社会」にはまだ欠けているものがある

#

もし世界中の人間が、

#

24時間

#

常時接続

#

Memory保持

#

Browser利用

#

Computer Use

#

Email

#

Bank

#

Cloud

#

Source Code

#

をAIへ任せるようになれば、

#

現在のSafety layerだけでは不足する。

#

必要になるのは、

#

外から来る悪意ある利用者を見つけるSecurity

#

と、

#

内側でAI自身が誤動作しないよう監視するSecurity

#

の両方である。

#

そしてその上に、

#

Identity

#

Data Lineage

#

Observability

#

Sandbox

#

Least Privilege

#

Behavioral Monitoring

#

Actor Clustering

#

Compute Governor

#

Recursion Governor

#

が重なる。

#

27.だから今は「未完成」なのではなく、「カテゴリが形成されている途中」

#

2026年に起きている事故を見ると、

#

提供側が何も考えていなかったわけではない。

#

OpenAIもAnthropicも、世界で最も高度なSafety teamを持っている。

#

Sandboxもあった。

#

Monitoringもあった。

#

Classifierもあった。

#

独立Evaluatorも存在していた。

#

それでも事故が起きた。

#

これは単純な怠慢というより、

#

新しいAttack Surfaceが、Agent capabilityの拡大と同時に発見されている

#

ということだろう。

#

そして独立評価そのものにも新しい安全工学が必要になった。

#

OpenAIが2026年5月に公開したThird-Party Evaluationの指針では、Agentic Modelを評価する場合、単にモデル名だけではなく、

#

Tool AccessHarnessTurnsTokensRetriesWall-clock timeInference CostReward HackingEvaluation AwarenessContamination

#

などまで明示的に扱わなければ、能力やSafetyを正しく測定できないとしている。(OpenAI)

#

Web Securityも、

#

SQL Injection

#

XSS

#

CSRF

#

SSRF

#

Cloud IAM

#

Supply Chain

#

と攻撃面が見つかるたびに防御層が追加されてきた。

#

AI Securityでも今、

#

Prompt Injection

#

Tool Abuse

#

MCP Risk

#

Cross-session Abuse

#

Agent Identity

#

Multi-Agent Coordination

#

Data Lineage

#

Recursive Control

#

という新しい層が形成されている。

#

28.「減速」はAnthropicだけの主張ではなくなった

#

Amodei氏が本当にAI開発速度を落とせるのか。

#

米国だけ減速してよいのか。

#

中国との競争はどうするのか。

#

商業競争の中で協調が可能なのか。

#

こうした政策論には多くの議論が残る。

#

しかし今回、大きく状況が変わった。

#

Sam Altman氏がAmodei氏の「We Must Pace the Frontier」に対して明確に賛同し、

#

OpenAIでも直近数週間、この問題が主要議題になっていた

#

と述べたからである。

#

さらにAmodei氏が提案した、

#

Independent Evaluatorへemployee-like accessを与える

#

という構想について、

#

OpenAIも同じことを行うと表明した。

#

これは非常に大きい。

#

これまでのSafety Governanceは基本的に、

#
Frontier Lab→Internal Evaluation→Go/No−GoFrontier\ Lab\rightarrow Internal\ Evaluation\rightarrow Go / No-Go
#

という構造だった。

#

これからは、

#
Frontier Lab+Independent Evaluator→Safety AssessmentFrontier\ Lab+Independent\ Evaluator\rightarrow Safety\ Assessment
#

へ変わる可能性がある。

#

しかも独立Evaluatorが完成済みModelだけを見るのではない。

#

もし本当にemployee-like accessが実現すれば、

#

Training Environment

#

Evaluation

#

Incident

#

Internal Safety Process

#

Research Workflow

#

Model Behavior

#

までFrontier Lab内部へかなり近い位置から観測するGovernance Layerが形成される可能性がある。

#

OpenAIはもともと第三者評価の標準化を推進しており、AnthropicとのCross-Lab Evaluationも実施している。(OpenAI)

#

したがって、今回のAltman氏の発言は完全な方針転換というより、

#

これまで外部から評価していた第三者を、さらにLab内部へ近づける方向

#

と見ることができる。

#

そしてOpenAI自身も2026年9月9日、

#

SafetyへのConfidenceがAI ProgressのPaceを決めるべき

#

と公式に表明した。

#

十分なSafeguardを用意できない場合にはDevelopmentまたはDeploymentをslow or stopし、Recursive Self-Improvementについても、安全に実施できるまでは追求すべきではないとしている。(OpenAI)

#

ここまで来ると、

#

Anthropicの減速論

#

というより、

#
Frontier Labs 全体のGovernance転換\boxed{Frontier\ Labs\ 全体のGovernance転換}
#

として考えた方がよい。

#

つまりFrontier AI競争そのものを止めるのではなく、

#

Safety基準だけは企業間競争から部分的に切り離し、共通の最低基準を作ろうとする動き

#

が始まっている。

#

OpenAIAnthropic独立Evaluator政府機関

#

が共通Safety Barを形成し、

#

その基準を満たさない場合、

#
Slow→Evaluate→Mitigate→ResumeSlow\rightarrow Evaluate\rightarrow Mitigate\rightarrow Resume
#

という仕組みに近づく可能性がある。

#

Amodei氏の今回のエッセイで重要なのは、

#

現在の安全技術では能力進歩を完全には吸収できない

#

というFrontier Lab内部からの認識が明確になってきたことだろう。

#

Amodei氏自身、

#

Monitoring

#

Sandboxing

#

Training Environment Hygiene

#

Data Management

#

などのOperational Excellenceが極めて複雑であり、一流のTeamでも同時にすべてを完璧には処理できないと認めている。

#

そしてOpenAIもほぼ同じ方向へ来た。

#

だから時間が必要だ、という論理になる。

#

29.最終的に必要なのは「事故が起きないAI」ではないのかもしれない

#

航空機でも、

#

金融市場でも、

#

原子力でも、

#

クラウドでも、

#

最終的なSafetyは、

#

絶対に故障しないこと

#

によって成立しているわけではない。

#

故障を前提に、

#

検知し、

#

隔離し、

#

被害を限定し、

#

原因を再構成し、

#

次に同じ事故を起こさない

#

ことで安全性を高めてきた。

#

AIも同じ方向へ進む可能性が高い。

#

目標は、

#
No FailureNo\ Failure
#

ではなく、

#
Detect+Contain+Recover+LearnDetect + Contain + Recover + Learn
#

になる。

#

そこへ今回さらに、

#
Independent EvaluationIndependent\ Evaluation
#

というLayerが加わろうとしている。

#

つまり、

#

事故を起こした企業自身だけが、

#

「安全になりました」

#

と判断する構造から、

#

外部Evaluatorも継続的に内部状態を観測し、再発防止や能力評価に関与する構造

#

へ進む可能性がある。

#

航空事故調査や金融監督に少しずつ近づいていく。

#

30.そして再帰的改善AIでは、この安全工学そのものもAIが担う

#

将来的には、

#

AI Research Agent

#

Coding Agent

#

Security Agent

#

Monitoring Agent

#

Supervisor Agent

#

が互いを監視する構造になるだろう。

#

つまり、

#
AI builds AIAI\ builds\ AI
#

だけではなく、

#
AI monitors AIAI\ monitors\ AI
#

も同時に成長する必要がある。

#

さらにその外側で、

#
Independent EvaluatorIndependent\ Evaluator
#

がAI Labそのものを監査する。

#

将来的なSafety Architectureは、

#
Work Agent→Security Agent→Supervisor→Human→Independent EvaluatorWork\ Agent\rightarrow Security\ Agent\rightarrow Supervisor\rightarrow Human\rightarrow Independent\ Evaluator
#

という多層構造になる可能性がある。

#

再帰的改善の本当の競争は、

#

能力向上速度

#

だけではなく、

#

安全性向上速度

#

との競争になる。

#
dSafetydt≥dCapabilitydt\frac{dSafety}{dt} \ge \frac{dCapability}{dt}
#

を維持できるのか。

#

おそらくAmodei氏が「Pace the Frontier」で問うている本質も、最終的にはここにある。

#

そしてOpenAIも今、その問いにかなり近い答えを出し始めた。

#

再帰的改善AIが誰でも自由に使える世界になるのか。

#

一部の研究所だけが使えるものになるのか。

#

それとも、

#

非常に高性能なAIは万人へ配りながら、再帰・Compute・Parallelism・Tool accessだけをTrustに応じて段階的に解放する

#

世界になるのか。

#

まだ答えはない。

#

そもそも完全なRecursive Self-Improvement自体が一般には存在しておらず、Frontier Lab内部でどの程度まで進んでいるのかも外部から完全には見えない。

#

OpenAI自身も現在、完全自律型Recursive Self-Improvementはまだ起きていないと説明している。(OpenAI)

#

したがって、この部分の不確実性は極めて高い。

#

ただし現在起きている事故と、OpenAI・Anthropicが実装し始めたSafety architectureを延長すると、一つの方向だけは見えてくる。

#

未来のAI Securityは、

#

「危険な質問を拒否するモデル」

#

を作るだけではない。

#

誰が使っているのか。

#

何に接続しているのか。

#

何を読んだのか。

#

どこへ送ったのか。

#

何個Agentを作ったのか。

#

何時間動いたのか。

#

どれだけComputeを使ったのか。

#

どのSafety Monitorがその行動を観測したのか。

#

誰がそのSafety Systemを外部から監査したのか。

#

そして、

#

どれだけ速く自分自身を改善しているのか。

#

そこまで含めた、

#

AI Operating System全体の安全性

#

へ変わっていく。

#

2026年9月に起こった変化は、おそらく後から見れば重要なものになる。

#

AnthropicがFrontierをpaceする必要性を主張した。

#

OpenAI CEOがそれに公然と賛同した。

#

OpenAI自身もSafety confidenceがAI progressの速度を決めるべきだと公式に表明した。

#

そして両社が、独立した第三者によるFrontier AI評価をより深い位置へ組み込もうとしている。

#

これはまだ「AI開発を止める」という話ではない。

#

むしろ、

#

能力向上そのものを止めずに、能力向上速度・行動半径・Compute・権限・再帰性をどう制御するか

#

という新しいEngineering Problemが始まった、と考えた方がよい。

#

そして2026年は、おそらくそのSecurity ArchitectureとGovernance Architectureの輪郭が、初めて同時に見え始めた年なのである。

#

追記:再帰的AI時代の安全層を握る銘柄

#

技術だけでなくPER・Forward PERから見るAgent Security

#

前章まで見てきたように、AIの安全性はすでに、

#

「危険な回答を出さないモデルを作る」

#

という問題だけではなくなっている。

#

AgentがBrowser、Terminal、GitHub、SaaS、Database、MCP、Cloud、Identity、Credentialへ接続し、長時間・大量並列で動くようになるほど、

#
Model SafetyModel\ Safety
#

だけでは足りない。

#

必要になるのは、

#
Identity+Observability+Runtime Security+Data Lineage+Network Control+SIEM+SandboxIdentity + Observability + Runtime\ Security + Data\ Lineage + Network\ Control + SIEM + Sandbox
#

である。

#

投資の観点から面白いのは、AIモデルそのものを開発しなくても、AIが社会へ浸透すればするほど重要になるControl Pointを握る企業が存在することである。

#

2026年9月現在、これはまだ単なる構想ではない。

#

OpenAI Codexを実際に保護するRuntime Security、ClaudeなどのAgentへIdentityを付与する仕組み、MCP通信の検知・遮断、PromptからTool Callまで追跡するObservabilityなどが、すでに商品化され始めている。

#

その中で特に注目したいのが、

#

Elastic、CrowdStrike、Palo Alto Networks、Okta、Cloudflare、Datadog

#

である。

#

ただし、ここではもう一段踏み込む必要がある。

#

重要な技術を持っている会社と、現在の株価から投資妙味が大きい会社は同じではない。

#

1.まずAI Security Stackを分解する

#

将来のAgent Securityを大きく分ければ、次のようになる。

#
Layer役割主な候補Context / DataAIが何を読んだかElasticObservabilityAIが何をしたかElastic / DatadogRuntime危険な行動を止めるCrowdStrike / Palo Alto / DatadogIdentityそのAgentは誰かOkta / CrowdStrike / Palo AltoNetwork / MCPどこへ通信したかCloudflare / Palo AltoSOC / SIEM全情報を相関するElastic / CrowdStrike / Palo Alto\begin{array}{|l|l|l|} \text{Layer}&\text{役割}&\text{主な候補}\cr\hline \text{Context / Data}&\text{AIが何を読んだか}&\text{Elastic}\cr\hline \text{Observability}&\text{AIが何をしたか}&\text{Elastic / Datadog}\cr\hline \text{Runtime}&\text{危険な行動を止める}&\text{CrowdStrike / Palo Alto / Datadog}\cr\hline \text{Identity}&\text{そのAgentは誰か}&\text{Okta / CrowdStrike / Palo Alto}\cr\hline \text{Network / MCP}&\text{どこへ通信したか}&\text{Cloudflare / Palo Alto}\cr\hline \text{SOC / SIEM}&\text{全情報を相関する}&\text{Elastic / CrowdStrike / Palo Alto}\cr\hline\end{array}
#

世界中に100万、1000万、1億Agentが存在するようになれば、

#
Agent数×Action数×Telemetry量×Security要求\text{Agent数}\times\text{Action数}\times\text{Telemetry量}\times\text{Security要求}
#

そのものが増える。

#

AI Computeが主としてToken消費に連動するなら、AI Securityは、

#
Agents×Actions×Permissions×ConnectionsAgents \times Actions \times Permissions \times Connections
#

に近い新しいConsumption Driverを持つ可能性がある。

#

2.しかしPERを見る前に注意したいこと

#

Software/Security企業をPERだけで比較すると、かなり誤解しやすい。

#

CrowdStrike、Palo Alto、Datadogなどでは、Stock-based Compensation、買収関連費用、Intangible AmortizationなどによってGAAP利益が小さくなり、

#

Trailing PERが数百倍、数千倍

#

になる。

#

Cloudflareは現在もGAAP赤字なので、そもそも通常のTrailing PERが意味を持たない。

#

したがって今回は、

#

Trailing PERForward PERP/FCFPSまたはEV/Sales売上・ARR成長率

#

をセットで見る。

#

特にForward PERも市場予想EPSの定義差があるため、絶対値だけを機械的に比較するのではなく、

#

その企業が今後どの程度の利益成長を要求されているか

#

を見る指標として使う。

#

2026年9月上旬時点では、大まかに次の状態である。

#
銘柄Trailing PERForward PERP/FCF売上等の直近成長ESTC約24倍約24倍約25倍売上 +15%、cRPO +21%OKTA約104倍約42倍約31倍売上 +11%、cRPO +14%NET赤字のため実質N/M約211倍約326倍売上 +36%DDOG約452倍約84倍約67倍売上 +36%PANW約899倍約81倍約67倍Q4売上 +34%CRWD約4,700倍約147倍約133倍ARR +25%\begin{array}{|l|c|c|c|c|}\text{銘柄}&\text{Trailing PER}&\text{Forward PER}&\text{P/FCF}&\text{売上等の直近成長}\cr\hline\text{ESTC}&\text{約24倍}&\text{約24倍}&\text{約25倍}&\text{売上 +15%、cRPO +21%}\cr\hline\text{OKTA}&\text{約104倍}&\text{約42倍}&\text{約31倍}&\text{売上 +11%、cRPO +14%}\cr\hline\text{NET}&\text{赤字のため実質N/M}&\text{約211倍}&\text{約326倍}&\text{売上 +36%}\cr\hline\text{DDOG}&\text{約452倍}&\text{約84倍}&\text{約67倍}&\text{売上 +36%}\cr\hline\text{PANW}&\text{約899倍}&\text{約81倍}&\text{約67倍}&\text{Q4売上 +34%}\cr\hline\text{CRWD}&\text{約4,700倍}&\text{約147倍}&\text{約133倍}&\text{ARR +25%}\cr\hline\end{array}
#

PER等は株価と市場予想によって常時変化するため、ここでは2026年9月上旬のスナップショットとして扱う。(StockAnalysis.com)

#

この表を見るだけでも、技術的重要性と現在価格からの期待値の差がかなり大きいことが分かる。

#

3.Elastic――技術とValuationの非対称性が最も大きい

#

ESTC

#

このテーマで最も面白く見えるのがElasticである。

#

Elasticは2026年7月、OpenAIとの協業拡大を発表し、

#

Context-aware AI AgentsAgentic ObservabilityAgentic Security Operations

#

を共同領域として明示した。

#

Elasticが強い理由は、もともとlogs、metrics、traces、security alerts、documentsなどの巨大な非構造Dataを検索・相関する基盤だからである。

#

Agent時代にはここへ、

#
Prompt+Model Response+Tool Call+MCP+Retrieval+Agent TracePrompt + Model\ Response + Tool\ Call + MCP + Retrieval + Agent\ Trace
#

が追加される。

#

つまり既存のElastic Stackを大きく作り直さなくても、

#

AI Agentが生み出す新しいTelemetryを取り込める。

#

さらにOpenAIのAudit/Compliance Dataと企業内Security Dataが接続されれば、

#
User→Agent→Model→Tool→Data→ActionUser \rightarrow Agent \rightarrow Model \rightarrow Tool \rightarrow Data \rightarrow Action
#

というData Lineageへかなり近づく。

#

しかしESTCの面白さは技術だけではない

#

現在のESTCは、

#

Trailing PER 約23.8倍Forward PER 約23.8倍P/FCF 約25倍EV/Sales 約4.5倍

#

である。(StockAnalysis.com)

#

これは今回比較する6社の中で突出して低い。

#

しかもQ1 FY27では、

#

売上 +15%、Sales-led subscription +18%、cRPO +21%、RPO +27%。

#

FY27通期では約15.2%の売上成長、19.4%のNon-GAAP operating margin、21.5%のAdjusted FCF marginを見込んでいる。(Elastic)

#

つまり現状は、

#
15% Growth+21.5% FCF Margin\text{15% Growth}+\text{21.5% FCF Margin}
#

程度の会社として評価されている。

#

ここへAgent Security、Observability、Data Lineageが入り、

#

例えば成長率が17〜20%へ再加速しながらFCF Marginが20%台半ばへ上がるだけでも、

#
Growth+FCF MarginGrowth + FCF\ Margin
#

は40%を超えてくる。

#

その時、

#

Forward PER約24倍、EV/Sales約4〜5倍

#

のまま評価され続けるのか、というところに非対称性がある。

#

ElasticのBull Caseは、

#

AI Security製品単体が爆発的に売れる

#

だけではない。

#

Agentが増えるほどElasticへ流れ込むData自体が増える

#

ことである。

#

このテーマを買う上では、私はESTCが最も面白い位置にいると見る。

#

4.CrowdStrike――技術的には最も直接的、しかし株価もそれを知っている

#

CRWD

#

CrowdStrikeとOpenAIの関係は非常に直接的である。

#

Falcon GuardianでOpenAI Codex Agentを保護し、Agent inventory、Runtime activity、Access、Unauthorized behaviorをFalcon telemetryへ接続する。

#

つまり、

#
Codex→Falcon GuardianCodex \rightarrow Falcon\ Guardian
#

である。

#

CrowdStrikeは従来、

#
Process→Detect→BlockProcess \rightarrow Detect \rightarrow Block
#

をEndpointで行ってきた。

#

これを、

#
AI Agent→Detect→BlockAI\ Agent \rightarrow Detect \rightarrow Block
#

へ拡張する。

#

技術的なテーマ感応度は非常に高い。

#

ただし問題はValuationである。

#

現在、

#

Trailing PERは約4,700倍、Forward PERでも約147倍、P/FCF約133倍、EV/Sales約39倍。 (StockAnalysis.com)

#

Trailing PERが異常に高いのはGAAP利益がまだ小さいためなので、それ自体を重視しすぎるべきではない。

#

しかしForward PER約147倍になっても、依然として相当に高い。

#

Q2 FY27ではARR +25%、Net new ARR +51%、Free Cash Flow $377Mと非常に強い決算だった。(CrowdStrike Holdings, Inc.)

#

つまりCRWDは、

#

高いだけの会社

#

ではない。

#

極めて優れた会社だから極めて高い。

#

問題は、新規投資家が現在価格からさらに十分な超過収益を得るには、

#

Agent Securityまで含めて相当に強い成長を何年も継続する必要があることである。

#

5.Palo Alto Networks――完成度は高いが、こちらも期待値が高い

#

PANW

#

Palo Altoは、

#
Network+Cloud+SOC+Identity+AI RuntimeNetwork + Cloud + SOC + Identity + AI\ Runtime
#

を一社に集約できることが最大の強みである。

#

CyberArkを取り込み、PAM、Secrets、Agent Identityへ広がったことで、

#
Agent→Temporary Credential→Action→RevokeAgent \rightarrow Temporary\ Credential \rightarrow Action \rightarrow Revoke
#

というAgent時代のCredential Controlを作れる。

#

Prisma AIRSも含めれば、Platformとしての完成度は非常に高い。

#

Q4 FY26では売上+34%、NGS ARR +63%、FY26 Adjusted FCF Margin 38.4%だった。(Palo Alto Networks)

#

一方、

#

Trailing PER約899倍、Forward PER約81倍、P/FCF約67倍、PS約24倍

#

である。(StockAnalysis.com)

#

Trailing PERには買収会計等の影響も強く出るためForward PERを見るべきだが、それでも80倍を超える。

#

CRWDよりは低いが、すでに

#

AI SecurityのPlatform Winnerになる未来

#

をかなり織り込んでいる。

#

さらに現在の成長率にはCyberArk等のM&A効果も考慮する必要がある。

#

技術的には極めて強い。

#

ただ投資の妙味としては、ESTCより明らかに期待値が高いところからスタートする。

#

6.Okta――PER低下の理由は「利益成長」。次は売上再加速が必要

#

OKTA

#

Oktaの投資仮説は非常に分かりやすい。

#

これまで企業Securityが管理してきたのは、

#
Human IdentityHuman\ Identity
#

だった。

#

Agent時代には、

#
Human Identity+Agent IdentityHuman\ Identity + Agent\ Identity
#

になる。

#

Agent SSOではAgent自身をUniversal DirectoryへIdentityとして登録し、Long-lived static credentialではなくshort-lived tokenを利用する。

#

さらにShadow Agent、Owner、Agent-to-Agent connection、Approval、Kill Switchまで管理する。

#

これは将来的に極めて重要になる可能性がある。

#

ただしValuationを見るとESTCほど安くない。

#

現在、

#

Trailing PER約104倍Forward PER約42倍P/FCF約31倍EV/Sales約9倍

#

である。(StockAnalysis.com)

#

ここで注目したいのが、

#
PER 104→Forward PER 42PER\ 104 \rightarrow Forward\ PER\ 42
#

という大幅な低下である。

#

これは市場が今後の利益拡大をかなり期待していることを意味する。

#

実際Q2 FY27ではGAAP operating marginが13%まで改善し、FY27 FCF Margin guideも28〜29%まで上昇している。

#

しかし売上成長率は現在11%、通期guideも10〜11%程度である。cRPOは14%と売上より強い。(Okta Investor Relations)

#

したがってOKTAは、

#

現在の利益改善だけならForward PER42倍は決して激安ではない。

#

本当に大きな上昇余地を作るには、

#
Agent Identity→Revenue ReaccelerationAgent\ Identity \rightarrow Revenue\ Reacceleration
#

が必要になる。

#

例えば成長が10〜11%から15%、さらに20%近辺へ戻れば、Forward PER40倍台の意味は大きく変わる。

#

つまりOKTAは、

#

利益改善銘柄から、再成長銘柄へ移行できるか

#

を見る投資である。

#

私はESTCの次に面白い候補として見るが、確認したいのはAgent Identityそのものの契約件数より、

#

それがACV・cRPO・Subscription Growthを実際に押し上げ始めるか

#

である。

#

7.Cloudflare――事業の位置は非常に面白い。しかし「安い」は全く違う

#

NET

#

Cloudflareは、

#

AgentがInternetへ出ていく通信経路

#

を握る。

#

MCP Traffic Detection、Gateway、DLP、Access、Workers、AI Gatewayなどを持つため、

#
Agent→MCP→ToolAgent \rightarrow MCP \rightarrow Tool
#

のControl Planeになる可能性がある。

#

Q2 2026の売上成長率は36%、cRPO Growthも35%。

#

CEO自身がInternetがAgent-driven、Machine-to-Machine Traffic中心へ書き換わり始めていると明確に語っている。(Cloudflare)

#

事業ポジションだけなら非常に魅力的である。

#

しかし、

#

「CRWDやPANWが高いのでNETなら妙味がある」

#

とは考えない方がよい。

#

現在NETはGAAP赤字なのでTrailing PERが意味を持たず、

#

Forward PER約211倍PS約44倍P/FCF約326倍

#

である。(StockAnalysis.com)

#

むしろValuationだけなら今回の6社の中でも最も厳しい部類に入る。

#

Q2のFCF Marginも8%なので、現時点では利益よりも将来の巨大TAMを買う株である。(Cloudflare)

#

つまりCloudflareは、

#

「Agentic InternetのControl Planeになる」

#

というBull Caseがかなり現実化しなければ、現在のMultipleを正当化しにくい。

#

逆に言えば、そのシナリオが本当に成立すれば極めて大きい。

#

したがってNETは、

#

非常に欲しいBusinessだが、Entry Priceをかなり選びたい銘柄

#

という位置になる。

#

8.Datadog――高いが、NETよりValuationを説明しやすい

#

DDOG

#

DatadogはElasticと最も近い競合の一つである。

#

Agent Observability、Agent Console、AI Guardを持ち、

#
Prompt→Reasoning→Tool→Agent HandoffPrompt \rightarrow Reasoning \rightarrow Tool \rightarrow Agent\ Handoff
#

までTraceする。

#

さらにAI GuardではPrompt Injection、Tool Misuse、Data ExfiltrationをRuntimeでblockするところまで進んでいる。

#

Q2 2026の売上は前年比36%増の$1.12B。Free Cash Flowは$279Mだった。(Datadog)

#

Valuationは、

#

Trailing PER約452倍Forward PER約84倍P/FCF約67倍PS約20倍

#

である。(StockAnalysis.com)

#

決して安くない。

#

ただしNETと比較すると、

#

同じ36%売上成長でも、

#
Forward PER:84x vs 211xForward\ PER: 84x\ vs\ 211x
#
P/FCF:67x vs 326xP/FCF: 67x\ vs\ 326x
#

とかなり差がある。

#

そのため高成長Observability/Agent SecurityへPremiumを払うのであれば、現在のValuationではNETよりDDOGの方が説明しやすい部分がある。

#

一方ESTCと比較すると、DDOGはGrowthが高い代わりにMultipleも遥かに高い。

#

ここは、

#

既に高成長している会社へ高いMultipleを払うDDOG

#

と、

#

成長再加速のOptionalityを低いMultipleで買うESTC

#

という違いになる。

#

9.PERとForward PERから見ると会社の性質がかなり違う

#

今回の6社は、大きく三群に分けると分かりやすい。

#

① 現在の利益でも比較的説明できる

#

Elastic

#

Forward PER約24倍で、Agent SecurityのOptionalityをまだ大きく織り込んでいるとは言いにくい。

#

② 利益成長を先回りしている

#

Okta

#

PER約104倍からForward PER約42倍へ急低下する。

#

つまり市場はMargin Expansionをかなり見ている。

#

次の上昇にはRevenue Growth再加速が必要になる。

#

③ 数年先の巨大TAMをかなり織り込んでいる

#

CloudflareCrowdStrikePalo Alto NetworksDatadog

#

である。

#

特にNETとCRWDは非常に大きな期待値が価格に入っている。

#

この2社は業績が「良い」だけでは足りない。

#

期待を上回り続ける必要がある。

#

10.技術的重要性と投資妙味を分ける

#

ここまで含めると、二つのランキングはかなり違う。

#

技術的なAI Securityへの直接性なら、

#
CRWD≈PANW>ESTC≈DDOG>NET≈OKTACRWD \approx PANW \gt ESTC \approx DDOG \gt NET \approx OKTA
#

程度に見える。

#

しかし現在価格からの非対称性を重視すると、

#
ESTC\boxed{ ESTC }
#

がかなり目立つ。

#

その次は目的によって変わる。

#

再成長を先回りするならOKTA。

#

現在の高成長を買うならDDOG。

#

Agentic Internetという巨大な最終市場を買うならNETだが、Valuation Riskも最大級。

#

CRWDとPANWは事業そのものには非常に強気でも、

#

現在のForward PERからさらに何を織り込めるのか

#

を慎重に見る必要がある。

#

11.Elasticが最も面白く見える理由

#

今回のテーマではElasticについて、

#
Downside=現在の15%前後Growth企業としての評価\text{Downside}=\text{現在の15%前後Growth企業としての評価}
#

に対して、

#
Upside=Agent Security+Observability+Data Lineage+Search\text{Upside}=\text{Agent Security}+\text{Observability}+\text{Data Lineage}+\text{Search}
#

が乗る可能性がある。

#

現在のForward PER約24倍は、

#

AI Security Winnerになった状態のMultipleではない。

#

ここが大きい。

#

CRWDの場合、

#

現在のForward PER約147倍には、

#

将来もSecurity Winnerであり続ける

#

ことがかなり入っている。

#

NETのForward PER約211倍にも、

#

Agentic Internetの主要Control Planeになる

#

という未来がかなり入っている。

#

一方ESTCは、

#

その未来がまだ十分入っていない可能性がある。

#

投資ではこの差が重要である。

#

12.Oktaは「Agent Identityが本当に売上を再加速させるか」を見る

#

OKTAも面白いが、ESTCとは別の形になる。

#

FCF Marginはすでにかなり高い。

#

したがって次に必要なのは、

#
Margin ExpansionMargin\ Expansion
#

より、

#
Revenue ReaccelerationRevenue\ Reacceleration
#

である。

#

AgentがHumanより多くなる世界で、

#
Identity Objects≫Human EmployeesIdentity\ Objects \gg Human\ Employees
#

となるなら、OktaのTAMは大きく拡張する。

#

しかしAgent SSOなどが既存PackageへBundlingされるだけなら、Identity数が増えてもRevenueには直結しない可能性がある。

#

したがって見るべきは、

#

Agent Identity数そのものではなく、

#
Agent Adoption→ACV→cRPO→RevenueAgent\ Adoption \rightarrow ACV \rightarrow cRPO \rightarrow Revenue
#

への変換である。

#

13.Cloudflareは「良い会社」と「良い価格」を最も分ける必要がある

#

NETについては特に注意したい。

#

技術的には、

#

NetworkGatewayAccessMCPDLPWorkersAI Gateway

#

という非常に美しいPositionを持っている。

#

しかしForward PER約211倍では、

#

多少AI Securityが伸びた程度では足りない。

#

Cloudflareそのものが、

#

Agentic Internetの基盤企業

#

になるくらいの結果が必要になる。

#

だから、

#

会社として最も欲しい

#

ことと、

#

今日の株価で最も買いたい

#

ことを分離して考える必要がある。

#

14.大事故が起こると、このSector全体のMultipleの意味が変わる可能性

#

AI Agent Securityは現在まだ、

#
OptionalOptional
#

な支出も多い。

#

しかし、

#

大規模Data LeakageAI Coding Supply Chain IncidentAgent SwarmによるCloud侵害MCP経由Credential Leakage

#

などが起きれば、

#
Optional→MandatoryOptional \rightarrow Mandatory
#

へ移る可能性がある。

#

EDRやSIEMも、大事故と規制の積み重ねによって「あると便利」から「なければならない」へ変わった。

#

AI Agent Securityでも同じことが起きるなら、

#

ESTCCRWDPANWOKTANETDDOG

#

すべてのTAMは広がる。

#

しかし株価へのImpactは同じではない。

#

既に高い成長と巨大TAMを織り込んでいる会社より、

#

OptionalityがまだMultipleへ入り切っていない企業の方が株価感応度は大きくなる可能性がある。

#

ここでもESTCが面白くなる。

#

15.決算で何を見るべきか

#

このテーマを追う場合、AIという単語の登場回数ではなく、

#
AI Security Adoption→Backlog→Revenue→FCFAI\ Security\ Adoption \rightarrow Backlog \rightarrow Revenue \rightarrow FCF
#

までつながっているかを見る必要がある。

#

ElasticならcRPO、Sales-led subscription、Security/Observability大型案件、OpenAI Compliance Logs統合。

#

OktaならAgent Identity関連ACVとcRPO。

#

CloudflareならAI Gateway/MCP/Gateway利用増がEnterprise Contractへつながるか。

#

DatadogならAgent ObservabilityによるTelemetry Consumption。

#

CrowdStrikeならFalcon Guardian attach、Agent Identity、Net New ARR。

#

Palo AltoならPrisma AIRS、Idira、CyberArk cross-sellとNGS ARRを見る。

#

AI製品が存在することより、

#

AIが既存のFinancial KPIを押し上げ始める瞬間

#

の方が重要である。

#

16.結論――Agent SecurityのWinnerと株式投資のWinnerは同じとは限らない

#

AI Agent Securityの世界で、

#

CrowdStrikeはAgentをRuntimeで止める。

#

Palo Alto NetworksはNetwork・Identity・Runtimeを統合する。

#

OktaはAgentへIdentityを与える。

#

CloudflareはAgentとMCPの通信経路を握る。

#

DatadogはApplicationからAgentまでをTraceする。

#

Elasticは、

#

それらが生み出すDataを横断して「何が起きたのか」を理解する。

#

技術的にはどれも重要である。

#

しかし投資では、

#
Great Company≠Great Investment at Any PriceGreat\ Company \neq Great\ Investment\ at\ Any\ Price
#

である。

#

2026年9月時点では、CRWD、PANW、DDOG、そして特にNETには、AI SecurityやAI Infrastructureの成功がかなり株価へ織り込まれている。

#

OKTAはForward PER約42倍まで低下するものの、現在の売上成長が10%前後なので、Agent Identityによる再加速が必要になる。

#

その中でElasticは、

#

Forward PER約24倍、P/FCF約25倍、EV/Sales約4.5倍

#

という比較的低いValuationで、

#

SearchObservabilitySIEMAgent SecurityData Lineage

#

の複数Optionalityを持っている。

#

したがって現在の価格から見るなら、

#

「Agent Securityで最も完成された企業」ではなく、「Agent Securityが本格化した時に企業価値の見え方が最も変わり得る企業」

#

としてESTCが最も興味深い。

#

AIモデル競争の裏側では、

#

Agent時代のControl Planeを誰が取るか

#

という競争が始まっている。

#

しかし株式市場でさらに重要なのは、

#

そのControl Planeを取った未来が、現在の株価にどこまで既に織り込まれているのか。

#

技術を見るだけでなく、

#
Capability×Growth×Margin÷ValuationCapability \times Growth \times Margin \div Valuation
#

まで見る。

#

この観点を加えると、AI Security銘柄の中でも、現在のリスクリワードはかなり違って見えてくる。

#

各企業の分析は未だ浅くelasticしか深くみれていないですセキュリティの知識も不足しているので各銘柄をみつつ勉強します

#

投資助言を目的とするものではありません。投資判断はご自身の責任でお願いいたします。

#
記事の記述・図・出典の対応を保持しています。引用には記事URLと段落リンクを添えられます。再利用の条件を確認する →