コラム

Claude Mythosのアーキテクチャを推定する:10兆パラメータの正体

Claude Mythosのアーキテクチャを推定する:10兆パラメータの正体

この記事の結論

Anthropicが極秘開発中のClaude Mythosは10兆パラメータのMoE構造と推定される。アーキテクチャの推定根拠、推論コストの壁、インフラ要件を技術的に読み解く。

「10兆パラメータ」という数字を聞いたとき、多くの開発者は反射的に「凄い」と感じる。ただ私は素直に驚けなかった。

GPT-4が約1.7兆パラメータとされ、Llama 3.1が4050億パラメータ。そこから10兆というジャンプは、線形な進歩ではなく何かが根本的に変わらなければ成立しない。ということはパラメータの「数え方」そのものが変わっているはずだ。

2026年3〜4月に流通したリーク情報と公式発表をもとに、Claude Mythosのアーキテクチャを技術的に推定してみる。確定情報は少ない。だからこそ、推論の過程を明示しながら書く。


なぜMoEなのか — 10兆パラメータは「全部使わない」

Claude Mythosが10兆パラメータを持つとして、それをすべてのトークン処理に使うのは物理的に不可能だ。現在のH100 GPU 1枚のVRAMは80GBで、bfloat16で保存すると1兆パラメータに2TBのメモリが必要になる。10兆なら20TB、つまり250枚以上のH100を1つの推論に割り当てる計算になる。

これは現実的ではない。だからMixture of Experts(MoE)アーキテクチャの採用はほぼ確実だと見ている。

MoEの仕組みはシンプルだ。モデル全体を複数の「専門家(Expert)」に分割し、各トークンの処理時には一部の専門家のみをアクティブにする。Mixtral 8x7Bは総パラメータ46.7Bだが、1トークンあたりのアクティブパラメータは12.9B程度。Qwen 3.5は総計397Bだが、推論時のアクティブ数は約17Bで、実効コストは20B規模のモデルに近い。

では10兆パラメータのMythosはどうか。以下は推定モデルだ。

パラメータ 推定値 根拠
総パラメータ数 〜10兆 リーク文書・複数メディア報道
Expert数 128〜256(推定) スケール比からの類推
アクティブExpert数/トークン 4〜8(推定) 既存MoEモデルの設計比率
実効アクティブパラメータ 300B〜500B程度(推定) 上記比率を適用した試算
必要VRAM(推論時) 6TB〜10TB(アクティブ分) bfloat16換算

ポイントは「10兆パラメータすべてをメモリに展開する必要がある」という点だ。MoEはアクティブパラメータを削減してコンピュートを節約するが、すべての専門家をGPUメモリに常駐させる必要があるため、メモリ使用量は総パラメータ数に比例する。これが10兆の壁だ。

AIエージェントのアーキテクチャ設計全般については、AIエージェント構築完全ガイドでまとめているので参照してほしい。MoEアーキテクチャを採用したモデルのコスト比較については、AIエージェントツール比較ガイドも参考になる。

推論コストの計算 — なぜ「高すぎて出せない」のか

gentic.newsが報じたAnthropicの内部コミュニケーションには、「顧客にとっても我々にとっても非常に高コスト」という記述がある。具体的な数字は出ていないが、逆算は可能だ。

現在Claude Opus 4.6の価格は入力15ドル/100万トークン、出力75ドル/100万トークン程度だ(2026年4月時点)。Anthropicのモデルのアクティブパラメータが仮に200B前後だとすれば、Mythosのアクティブパラメータが500Bに達する場合、コンピュートは単純換算で2.5倍以上になる。

さらに、Mythos独自の「拡張思考モード(Extended Thinking)」が有効になると、出力トークン数が通常より大幅に増える。コスト倍率は容易に5〜10倍以上になりうる。

Anthropicが現時点でMythosを限定プレビューに留めているのは、単なる安全性評価だけでなく「採算が取れるコストで提供できない」という現実的な制約が大きいと筆者は見ている。

実際、gentic.newsの記事では「Spud」と呼ばれる中規模モデルが先にリリースされる可能性が示唆されている。Mythosの技術を蒸留・最適化した派生モデルを先行させて収益基盤を作り、段階的にMythosの推論コストを下げていく戦略だ。GPT-4→GPT-4o→GPT-4o-miniというOpenAIの戦略と同じ構図だ。

アーキテクチャ推定の裏付けになる3つの事実

Anthropicはアーキテクチャの詳細を開示していない。ただ間接的な証拠がいくつかある。

証拠1: Claude Opus 4.6のアーキテクチャ傾向

データサイエンスコミュニティの分析によれば、Claude Opus 4.6はすでに推定5兆パラメータ規模のMoEアーキテクチャを採用している可能性がある。Anthropicの3.xシリーズから4.xシリーズへの性能ジャンプは、単純な密度増加では説明しにくいスケールに達していた。Mythosが10兆であれば、Opus 4.6の延長線上にある自然な進化だ。

証拠2: SWE-bench Proで77.8%のインプリケーション

コーディングタスクでの高性能を実現するには、コードの「意味」を理解する専門家群と、「構文」「テスト」「デバッグ」を担う専門家群を分離して学習させるアーキテクチャが有利だ。MoEはまさにこの用途に向いている。93.9%というSWE-bench Verifiedスコアは、MoEによるタスク特化型ルーティングなしには説明が難しい。

証拠3: Project Glasswingのパートナー構成

Anthropicが限定アクセスを与えた組織はAWS、Apple、Cisco、Google、NVIDIA、CrowdStrikeなど、インフラと安全性評価の両面で高い能力を持つ企業群だ。これは「大規模インフラを持っているパートナーにしか運用できないモデル」という現実を示唆している。クラウドプロバイダー3社(AWS、Google、おそらくAzure)が含まれているのは偶然ではない。

インフラ要件 — どれだけのGPUが必要か

技術的な見積もりを試みる。ただしこれはあくまで推定であり、Anthropicが確認した数字ではない。

以下のコードで大まかな計算ができる。

# 注意: 以下はあくまで公開情報からの推定計算です
# 本番環境での参考にはなりません

total_params = 10e12  # 10兆パラメータ(推定)
bytes_per_param = 2   # bfloat16

# メモリ計算
total_memory_bytes = total_params * bytes_per_param
total_memory_tb = total_memory_bytes / (1024**4)
print(f"総パラメータのメモリ: {total_memory_tb:.1f} TB")
# → 20.0 TB

# H100 SXM5 (80GB VRAM) での必要枚数
vram_per_h100_gb = 80
h100_count = (total_memory_tb * 1024) / vram_per_h100_gb
print(f"必要H100枚数(メモリ基準): {h100_count:.0f} 枚")
# → 250 枚

# 実際のクラスター規模(冗長性・通信オーバーヘッド含む)
# 推定: 500〜1000 H100 / 推論インスタンス

この計算は粗い。実際には量子化(INT4やFP8)によってメモリを削減できるし、テンソル並列化とパイプライン並列化を組み合わせた最適化もある。AnthropicがAWSのTrainium、Google TPU、NVIDIAのGPUを混在させているのも、単一ハードウェアへの依存リスクを避けつつ最適コストを探るためだろう。

2026年、AnthropicはGoogleとBroadcomとの間で「複数ギガワット規模のTPUキャパシティ」を確保する契約を結んでいる。2027年以降に本格稼働するこのインフラが整って初めて、Mythosを採算ラインで提供できるようになる可能性が高い。

開発者として今知っておくべき現実

正直にお伝えすると、Claude Mythosはまだ「手が届かない存在」だ。Project Glasswingの参加企業でなければアクセスできないし、APIが公開されても当初のコストは現在のOpus 4.6の数倍になるだろう。

ただし、開発者が準備できることはある。

# Anthropic Claude SDK — Mythosが公開された際の想定コード構造
# 動作環境: Python 3.11+, anthropic>=0.30.0
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください

import anthropic

client = anthropic.Anthropic(api_key="your-api-key")

# 将来的にMythosが公開された場合、モデル名を差し替えるだけで移行できるよう設計
MODEL_NAME = "claude-opus-4-6"  # → 将来: "claude-mythos-..." に切り替え

response = client.messages.create(
    model=MODEL_NAME,
    max_tokens=8192,
    messages=[
        {"role": "user", "content": "セキュリティ診断を開始してください"}
    ]
)

print(response.content[0].text)

MoEアーキテクチャを活かしたモデルを使いこなすには、「どのExpertが活性化するか」を意識したプロンプト設計が将来的に重要になる可能性がある。コーディングタスク、セキュリティ分析、数学的推論といったタスクを明確に分離してプロンプトを設計することで、適切なExpertが優先的にアクティブになる可能性が高い。

# MoEモデルへのタスク特化プロンプトの例(推奨設計パターン)
# 動作環境: Python 3.11+
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください

def create_specialized_prompt(task_type: str, content: str) -> str:
    """
    タスクタイプを明示してMoEモデルの専門家ルーティングを最適化する
    task_type: 'coding' | 'security' | 'math' | 'analysis'
    """
    prefixes = {
        "coding": "以下はPythonコードのレビューです。バグと最適化機会を特定してください。",
        "security": "以下はセキュリティ診断タスクです。CVSSスコア基準で脆弱性を評価してください。",
        "math": "以下は数学的推論タスクです。ステップバイステップで解いてください。",
        "analysis": "以下はデータ分析タスクです。仮説と検証方法を提示してください。"
    }
    return f"{prefixes.get(task_type, '')}nn{content}"

# 使用例
prompt = create_specialized_prompt("security", "このコードにSQLインジェクションのリスクはありますか?")

【要注意】よくある誤解と正しい理解

誤解1:10兆パラメータ = 10兆の計算をすべてのトークンで実行する

❌ 「10兆パラメータなら推論が10倍遅い」

⭕ MoEでは1トークンあたりのアクティブパラメータは総数の数〜数十%程度。計算量は総パラメータ数に比例しない。ただしメモリ搭載量(VRAM)は総数分が必要になる。

なぜ重要か: この違いを理解しないと、Mythosが「高コストな理由」を誤解する。コストの主因はコンピュートよりメモリ帯域幅とVRAM確保コストだ。

誤解2:Mythosは今すぐAPIで試せる

❌ 「APIを叩けばMythosが使える」

⭕ 2026年4月時点でMythosはProject Glasswingの選定パートナー企業のみが限定プレビューで使用できる。一般APIは未公開。

誤解3:パラメータ数が多いほど必ず賢い

❌ 「10兆 > 1兆 だから常に優れている」

⭕ 同じ問題を解かせた場合、適切に学習・最適化された1兆パラメータモデルが10兆MoEモデルを上回ることはある。重要なのはタスクとアーキテクチャの整合性だ。

私の見立て — Mythosが変えるもの、変えないもの

筆者の判断を明確に書いておく。

Mythosが変えるのは「AIが自律的に実行できるタスクの難易度の天井」だ。SWE-bench Pro 77.8%が示すのは、実際の本番コードへのバグ修正をほぼ自律的に実行できるレベルに達しているということだ。これはコーディングエージェントの実用性が質的に変わることを意味する。

変わらないのは「コストの壁」と「組織的な信頼構築の必要性」だ。MoEで効率化しても、10兆パラメータをホストするインフラコストは当面、一部の大企業と研究機関にしか手が届かない。民主化されるとすれば、Mythosの能力を蒸留した中規模モデル(「Spud」的なもの)経由になるだろう。

2027年にGoogleとBroadcomのTPUインフラが本格稼働すれば、Anthropicの推論コストは大幅に下がる可能性がある。そのタイミングがMythosの一般公開と重なるかもしれない。それまでは、Opus 4.6でエージェントを磨く時間だ。

参考・出典


この記事はAIgent Lab編集部がお届けしました。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年4月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事