Anthropic内部文書リークで見えた「PSM」とClaude Mythos:LLM本番導入の判断ポイント

eyecatch AI関連

結論(導入判断)

  • PSMは「人格/安全性」をプロンプトではなく制御プレーンで統制する方向性を示す(再現性・監査性が上がる)。
  • 一方で、ふるまいのブラックボックス化とベンダーロックインは増える。
  • 評価軸はモデル性能だけでなく、制御/ポリシーの透明性と運用設計(ログ・説明責任・例外運用)まで見る。

想定読者:LLMを本番導入するPM/情シス/セキュリティ/開発リード

あわせて読みたい:Claude 4.6 Sonnetとは?粒子物理・数学・PC操作エージェント“三連発”で見えた導入判断 / Gemini移行支援とは?ChatGPT/Claude→Gemini乗り換えの要点と落とし穴【導入判断】


「LLMにプロダクションの振る舞いを全部任せてるけど、本当にそれでいいのか?」
そんなモヤモヤを抱えたこと、ありませんか。
プロンプトを工夫しても、ある日突然トーンが変わる。安全側に振ったら今度は役に立たない。逆に攻めるとリーガルとセキュリティから怒られる——この綱引きに、私も現場で何度も付き合わされてきました。

そんな中で出てきたのが、Anthropicの内部文書リークと、そこに書かれていた「Claude Mythos」と「Persona Selection Model(PSM)」の話です。
ぶっちゃけ、このリークで見えたのは「モデル企業が何を商品として売ろうとしているのか」が、一段ハッキリしたことだと思っています。


  1. 一言でいうと:LLM界の「DockerからKubernetesへの転換」が始まった
  2. 何が新しい?Persona Selection Model が示す「人格はプロンプトではなくインフラで制御する」という発想
    1. なぜそれが大事か
  3. なぜ業界的に重要か:Anthropic vs OpenAI vs OSS の「思想の差」がはっきりしてきた
    1. Anthropic:規制・企業寄りの「制御プレーン指向」
    2. OpenAI:能力+エコシステム重視の「プラットフォーム指向」
    3. オープンソース陣営:生モデル+自前ガードレール路線
    4. まとめると…
  4. サイバーセキュリティ観の違い:Anthropicは「攻撃のライフサイクル全体」を見ている
    1. ここだけ聞くと素晴らしいが、現実は…
  5. ただ、懸念点もあります…(Gotcha)
    1. ふるまいのブラックボックス化が進む
    2. ベンダーロックインが一段深くなる
    3. 安全性のために「使い物にならない」領域が出てくる
    4. レイテンシとコストの増加
  6. プロダクションで使うか?正直、まだ「選び方」に注意が必要です
    1. こういうチームには、かなり「アリ」
    2. 一方で、こういうチームは慎重に
  7. 最後に:これからの「LLM選び」はモデル性能より「制御アーキテクチャ」を見るべき
  8. FAQ(導入判断のよくある質問)
    1. Q. Persona Selection Model(PSM)とは?
    2. Q. 企業導入で何が一番うれしい?
    3. Q. ロックインを減らすには?
    4. Q. レッドチーム/侵入テスト用途はどう考える?
  9. 関連記事

一言でいうと:LLM界の「DockerからKubernetesへの転換」が始まった

一言でいうと:LLM界の「DockerからKubernetesへの転換」が始まった

リーク内容を一言でまとめると、

「LLMそのもの」ではなく、「LLMをオーケストレーションする制御プレーンを本体にし始めている

という話です。

  • Claudeの次世代基盤とされる “Claude Mythos”
  • その前段に置かれている Persona Selection Model(PSM)
  • どの「人格」「トーン」「安全レベル」で応答するかを選ぶルーター
  • 事実上、安全ポリシーとユーザー体験をコントロールする司令塔

この構造、インフラ屋としては完全に「Docker時代 → Kubernetes時代」の déjà-vu です。

  • 昔:
  • 「コンテナ=プロダクト」
  • 生コンテナに直接 ssh してなんとかする世界
  • その後:
  • 「Kubernetes という制御プレーンが本体」
  • コンテナはスケジュールされる単位に格下げ

今のLLMもほぼ同じ流れになりつつあるように見えます。

  • 昔(GPT-3〜初期Claude):
  • 「モデル=プロダクト」
  • 開発者がプロンプトで性格・安全性を自前で調整
  • これから(Mythos+PSM):
  • 制御プレーン(Mythos+PSM+安全レイヤ)=プロダクト
  • モデルは、その下で動く「コンポーネント」の一つ

正直、この方向性は技術的にはかなり合理的です。ただし、開発者と企業にとっては「嬉しいところ」と「かなり厄介なところ」が両方ある、と感じています。


何が新しい?Persona Selection Model が示す「人格はプロンプトではなくインフラで制御する」という発想

リークで特に面白いのが、この Persona Selection Model(PSM) の存在がかなり具体的に書かれていたことです。

ざっくり言うと、PSMはこんな役割を持った「前段モデル」です。

  • ユーザー入力、会話履歴、システム指示、リスク情報などを受け取る
  • それをもとに
  • 「慎重なアシスタント」
  • 「セキュリティ監査モード」
  • 「クリエイティブライター」
  • 「コーディング特化」
    …といったペルソナ(人格プロファイル)を選ぶ or ブレンドする
  • 選ばれたペルソナ情報を、特殊トークンや内部アダプタとして本体モデルに条件づけする

ここで重要なのは、

「人格や安全性をプロンプトの工夫でなんとかする時代から、
前段のルーター+ポリシーモデルで決め打ちする時代にシフトしている

という点です。

なぜそれが大事か

開発者視点でのインパクトはかなり大きいです。

  • 同じモデルでも
  • 「どのペルソナが選ばれたか」で振る舞いが変わる
  • しかもその選択は、ユーザーの一言ではなく
    • 過去の会話
    • 利用プラン(個人 / 企業)
    • リスク判定
      などを含めて決まる
  • 結果として:
  • 「このプロンプトを投げたら必ずこう返る」という単純な対応関係が崩れる
  • 代わりに、「このプロダクト、このユーザー、この文脈では、こう返る」が成立する

正直、「LLMがやたら人間っぽく安定して見える理由」のかなりの部分は、巨大モデルの“自発的な人格”というより、このPSMの設計に寄っていると考えた方が現実的だと思います。


なぜ業界的に重要か:Anthropic vs OpenAI vs OSS の「思想の差」がはっきりしてきた

なぜ業界的に重要か:Anthropic vs OpenAI vs OSS の「思想の差」がはっきりしてきた

リークを読むと、「Anthropicがどこで勝とうとしているか」がだいぶ見えてきます。ざっくり整理するとこんな構図です。

Anthropic:規制・企業寄りの「制御プレーン指向」

  • Persona Selection Model を正式なコンポーネントとして組み込む
  • 安全ポリシーと UX をアーキテクチャの一階部分にしている
  • 「ユーザーは生のモデルに触れず、事前に設計されたペルソナ経由でしかアクセスできない」方向へ

ねらいは分かりやすくて、

  • 企業・政府・規制当局に対して:
  • 「うちは構造的に危険な振る舞いをしにくい設計です」
  • 「ログ、ポリシー、ペルソナの制御で説明責任を果たせます」

というポジションを取りに行っているように見えます。

OpenAI:能力+エコシステム重視の「プラットフォーム指向」

一方、OpenAI(少なくとも公開情報ベース)だと雰囲気はかなり違います。

  • GPT-4.x / o3 などのモデル性能
  • Function calling / Assistants API / GPT Store といったツール・マーケットプレイス

こちらは、

  • 「まずはなんでもできる超強力モデル」+
  • 「それをラップするツールやマーケットを広げる」

という、どちらかというと「App Store+iPhone」型に近い発想です。

安全性はもちろん気にしているものの、

  • 明示的な「ペルソナルーター」というより
  • モデレーションAPIやポリシー、カスタムGPTの制約
    といった「後付けフィルタとルール」としてユーザーに見える構造の方が強い印象です。

オープンソース陣営:生モデル+自前ガードレール路線

さらに、オープンソースのフロンティアモデルを見ていると、

  • 「とりあえず生のモデルを配布」
  • ガードレールやペルソナは
  • 企業ごとに
  • フレームワークごとに
    バラバラに実装

という世界観がまだ主流です。
正直、安全性と一貫性という意味では、一歩も二歩も出遅れているように見えます。

まとめると…

  • Anthropic:
  • 「AI制御プレーン」そのものを商品にしたい会社
  • OpenAI:
  • 「超強力モデル+ツール群」のプラットフォーム
  • OSS:
  • 「生モデル+各社カスタム」の DIY 路線

リークで見えてきたのは、Anthropicがこの三者の中で一番はっきりと、

モデルよりも制御の方に差別化の軸を置く

と腹をくくっている、ということです。


サイバーセキュリティ観の違い:Anthropicは「攻撃のライフサイクル全体」を見ている

もう一つ、リークで興味深かったのがサイバー攻撃リスクの扱い方です。

多くの議論はどうしても

  • 「危険なコード片を出すな」
  • 「爆弾の作り方を教えるな」

という“単発のアウトプット”の話に収まりがちですが、
Anthropicの内部資料はかなり具体的に攻撃ライフサイクル全体を見ているのが分かります。

  • 偵察(OSINT・スキャン結果の解釈)
  • 既存CVEの悪用コードの改変
  • 権限昇格・ラテラルムーブのパス設計
  • データ持ち出しとログの隠蔽
  • そして、LLM+ツールの反復ループでの最適化

正直、「ここまで攻撃者目線で整理している安全チーム」は、普通のSaaS企業だとまだ少数派です。

ここだけ聞くと素晴らしいが、現実は…

ただし、ここには典型的なジレンマがあります。

  • Anthropicがどれだけガードを固めても
  • 攻撃者はオープンソースモデルを自前で fine-tune すれば回避できる
  • 結果として
  • 一番強く制限されるのは、真面目にSaaSを構築している企業側ユーザー

という構図になりやすい。

正直、「ベンダー側が安全側に振るほど、攻撃者は他の手段に流れ、まじめなユーザーだけが不便になる」という構造は、セキュリティ屋として何度も見てきました。

とはいえ、「だから何もしない」は論外なので、

  • 攻撃ライフサイクルレベルでのモデル制御
  • ログと監査の強化

を本気でやっているベンダーが出てきたこと自体は、大きな意味があると思っています。


ただ、懸念点もあります…(Gotcha)

ただ、懸念点もあります…(Gotcha)

ここからは、現場エンジニアとして「正直ここは困る」というポイントです。

ふるまいのブラックボックス化が進む

PSM+安全レイヤ+ツールオーケストレーションが前段に入ると、

「なぜこの応答になったのか」が、開発者から見てさらに分かりにくくなる

という問題が出てきます。

  • ある日突然、
  • 同じAPI
  • 同じプロンプト
  • 同じユーザー
    なのに、モデルのトーンが変わる
  • 実は裏側で
  • Personaの定義が変わった
  • リスク判定ロジックが変わった
  • 新しい安全ポリシーがロールアウトされた

でも、開発者には何も知らされない
これ、Kubernetesでも散々見ました。「デプロイしてないのに挙動だけ変わる」やつです。

正直、「PSMでどのペルソナが選ばれたか」「なぜブロックされたか」を最低限ログやレスポンスメタデータで見せてくれないと、プロダクションでのデバッグはかなりつらくなります。

ベンダーロックインが一段深くなる

もし将来こんなAPIが出てきたら、どうでしょう。

{
  "model": "claude-mythos",
  "personas": ["assistant.default", "domain.security", "style.terse"],
  "messages": [...]
}

便利そうですよね。
でも、これに依存し始めると、

  • その「assistant.default」「domain.security」が
  • どういう安全ポリシーか
  • どの程度の情報開示を許すのか
  • を Anthropic の仕様に完全に委ねることになります。

別ベンダーや OSS に乗り換えるとき、

  • これらのペルソナを自分で再実装しないといけない
  • しかも完全な互換性はほぼ無理

という意味で、アプリのコアロジックがベンダー固有抽象に強く結びつくリスクがあります。

ぶっちゃけ、「プロンプトエンジニアリング地獄」からは解放されるかもしれませんが、代わりに「ペルソナ仕様ロックイン地獄」が来る可能性はあります。

安全性のために「使い物にならない」領域が出てくる

サイバーセキュリティの話にも繋がりますが、

  • 本気で攻撃ライフサイクルを抑止しようとすると
  • レッドチーム
  • 侵入テスト
  • マルウェア解析
    といった正当な用途まで巻き込んで制限してしまう危険があります。

現実には、

  • Anthropic的な厳格モデルを
  • 「ユーザー向け本番プロダクト」
  • 多少攻めたモデルやOSSを
  • 「社内レッドチーム・検証用」

二重構成で使い分けるようなアーキテクチャになる企業が増えるかもしれません。
これはこれで運用コストが増えます。

レイテンシとコストの増加

PSM → 安全フィルタ → コアモデル → ツール呼び出し → 再度PSM判断…
みたいな多段構成になればなるほど、

  • レイテンシは伸びる
  • 料金も上がりがち
  • 障害ポイントも増える

リアルタイム性が要求されるUX(音声アシスタントや対話エージェント)だと、
「安全で一貫したふるまい」と「スナッピーな応答」のトレードオフがかなりシビアになってきます。


プロダクションで使うか?正直、まだ「選び方」に注意が必要です

では、このAnthropicの方向性をどう評価すべきか。
エンジニア兼プロダクト側の立場からの結論はこうです。

こういうチームには、かなり「アリ」

  • 規制・コンプラ・安全性が最優先:
  • 金融
  • ヘルスケア
  • 公共・政府系
  • 「とにかく変なことを言わないモデル」が欲しいチーム
  • LLMの専門家を社内に多数抱えられない中堅〜大企業

こういう組織にとっては、

  • Personaレイヤ+安全アーキテクチャ込みで
  • ある程度ふるまいが読めるSaaS

を提供してくれるベンダーは、相性が良いと思います。

一方で、こういうチームは慎重に

  • レッドチーミングや攻撃的セキュリティを本業にしている
  • とにかく「生の能力」を最大限引き出したい研究寄り組織
  • OSSモデルを自前で安全設計したいスタートアップ

このあたりのチームにとっては、

  • Anthropic的な厳格アーキテクチャは
  • 頼れるが窮屈なガードレール
  • どうしても、
  • 「ユーザー向けはAnthropic」
  • 「研究・検証用はOSS or 他社フロンティア」
    というマルチベンダー構成になる可能性が高いと感じます。

最後に:これからの「LLM選び」はモデル性能より「制御アーキテクチャ」を見るべき

最後に:これからの「LLM選び」はモデル性能より「制御アーキテクチャ」を見るべき

今回のリークで一番示唆的だったのは、

これからは「どのモデルが一番賢いか」より、
「どのベンダーの制御プレーンと安全アーキテクチャに乗るか」の方が重要になる

ということだと思います。

正直、Mythosが何パラメータで、どのベンチマークが何点か、という話は時間が経てば陳腐化します。
でも、

  • Persona Selection Model という前段ルーター
  • サイバー攻撃ライフサイクルを前提にした安全設計
  • 「生モデルに直接触らせない」哲学

こうしたアーキテクチャと思想の差は、数年スパンで効いてきます。

プロダクション導入を検討する立場としては、

  • ベンダー選定のチェックリストに
  • 「ペルソナ/ポリシーの制御方法」
  • 「安全レイヤの構造と透明性」
  • 「ログや説明責任の仕組み」
  • そしてなにより
  • 「ロックインをどう緩和するか(抽象レイヤをどこに置くか)」

を加えるべきタイミングに来た、と感じています。

プロダクションでAnthropicを全面採用するか?
正直、まだ「全てを預ける」のは様子見です。

ただし、

  • モデル能力だけを比べる時代は終わりつつあり、
  • 「AI制御プレーン」としてのAnthropicは
  • 少なくともエンタープライズ領域では無視できない選択肢になった

というのが、今回のリークを見ての率直な印象です。

今後ベンダー各社が「自分たちの制御プレーン」をどう設計し、公言していくか。
そこを見比べるのが、これから数年のAIエンジニアの新しい「目利きポイント」になっていくはずです。


FAQ(導入判断のよくある質問)

Q. Persona Selection Model(PSM)とは?

ユーザー入力やリスク情報をもとに、応答の「人格/トーン/安全レベル」を選ぶ前段ルーター(ポリシーモデル)です。プロンプトよりインフラ側で統制するのがポイントです。

Q. 企業導入で何が一番うれしい?

「同じ条件なら同じ挙動」を作りやすく、監査・ガバナンス要求に答えやすい点です(ただし透明性が不足すると逆に運用がつらくなります)。

Q. ロックインを減らすには?

ペルソナ/ポリシーをAPI固有仕様に直結させず、社内の抽象レイヤ(ガードレール、ログ、評価)を先に設計しておくのが現実解です。

Q. レッドチーム/侵入テスト用途はどう考える?

「ユーザー向け本番」は制御強め、「社内検証」は別ベンダー/OSSなど、用途別に二重化する設計が現実的です。


関連記事

コメント

タイトルとURLをコピーしました