---
title: "OpenMythosとは？Claude Mythosの構造を推測したオープンソース実装の仕組みと使い方"
url: "https://www.issoh.co.jp/tech/details/12042/"
published: 2026-05-09
updated: 2026-10-19
categories: ["LLM・RAG"]
publisher: "株式会社一創"
---

# OpenMythosとは？Claude Mythosの構造を推測したオープンソース実装の仕組みと使い方

OpenMythosは、Anthropicのセキュリティ特化モデル「Claude Mythos」の内部構造を、公開論文と推測だけを手がかりに組み直したオープンソース実装です。作者は個人開発者のKye Gomez氏で、2026年4月18日に[GitHubのkyegomez/OpenMythos](https://github.com/kyegomez/OpenMythos)として公開されました。中身はPyTorchで書かれた**学習前のモデル定義**で、学習済みの重みは入っていません。本記事では、Claude Mythosとの違い、反復深度Transformerの仕組み、pipでの使い方を整理し、2026年10月19日に手元でサンプルを実行して分かった「READMEどおりには動かない2か所」と、早期終了（ACT）が実際に何回ループを回すかまで示します。

## まとめ

- **正体**：Claude Mythosの構造を推測で再現した未学習のOSS（MITライセンス）。READMEは「Anthropicとは無関係」と明記し、Claude Mythosがループ型だという前提も「suspected（推測）」と書いています。
- **仕組み**：Prelude、繰り返し通すRecurrent Block、Codaの3段構成。同じ重みのブロックを、既定では最大`max_loop_iters`回、指定時は最大`n_loops`回通して、パラメータを増やさずに計算の深さを稼ぎます。
- **使い方**：`pip install open-mythos`で入りますが、0.3.0以降は`torch==2.11.0`固定です。torch 2.11.0にはIntel Mac向け配布がなく、今回のPython 3.11環境ではpipの依存解決がopen-mythos 0.2.0へ戻りました。
- **READMEの注意**：スペクトル半径を求める行は`RuntimeError`で止まり、`mythos_7b`は存在しません。直し方は本文に載せました。
- **現状（2026年10月）**：PyPIの最新は0.5.0（2026年4月22日）、最後のpushは5月23日、公式の学習済み重みは未公開です。使うには自分で学習させる必要があります。

## OpenMythosとClaude Mythosの違い

名前は似ていますが、開発元も中身も別物です。両者の提供元と公開内容の違いを先に整理します。

### Claude Mythos：Anthropicが審査付きで提供するモデル（2026年10月の状況）

Claude Mythosは、Anthropicが2026年4月7日に公表したサイバーセキュリティ能力の高いモデル系統です。最初の`claude-mythos-preview`は[公式のモデル一覧](https://platform.claude.com/docs/en/about-claude/model-deprecations)で2026年6月9日に非推奨となり（退役日は未定）、現行は`claude-mythos-5`と`claude-mythos-5-1`です。Anthropicは[9月の発表](https://www.anthropic.com/claude-fable-and-mythos-5-1)で、Fable 5.1とMythos 5.1は「同じモデルに異なる水準の安全策をかけたもの」と説明しています。

提供は今も審査制です。[2026年10月6日の発表](https://www.anthropic.com/news/cyber-verification-program)でCyber Verification ProgramがDefense・Red Team・Specializedの3区分に拡充され、Project Glasswingの既存参加組織はSpecializedへ移りました。料金や利用条件は[Claude Mythos 5.1とは：Fable 5.1との違いとCVPでの利用条件【2026年10月】](/tech/details/18215/)、モデル全体像は[Claude Mythosとは？Capybaraティアの正体・性能・料金・一般公開の最新状況【2026年6月】](/tech/details/11584/)で扱っています。Firefoxの脆弱性271件の発見などの実績はClaude Mythos側のもので、内訳は[Claude Mythos 脆弱性1万件超｜提供停止・再開と企業の初動](/tech/details/12254/)にまとめました。

### OpenMythos：公開論文からの推測で組んだ未学習の実装

OpenMythosはClaude Mythosの重みにも内部資料にも触れていません。Anthropicのモデル発表やTransparency Hubには、Mythosがループ型かどうかやパラメータ数の記載が見当たらず、READMEも「Claude Mythos is suspected to be a Recurrent-Depth Transformer」と推測として書いています。つまり、OpenMythosの設計が当たっているかを外から確かめる手段は今のところありません。Firefoxで脆弱性を見つけたのもOpenMythosではありません。

### OpenMythosの開発状況：スター約1.5万・最終公開版0.5.0

GitHub APIで2026年10月19日に確認すると、スター14,908、フォーク3,277、ライセンスはMITです。ただしコードの更新は4月下旬に集中しており、最後のpushは2026年5月23日のREADME修正、[PyPIのopen-mythos](https://pypi.org/project/open-mythos/)は0.5.0（4月22日）が最新で、GitHubのReleasesは空です。作者は4月22日にIssue #8で「we’re training it currently」と答えましたが、学習済みモデルを求めるIssue #83（6月21日）にも作者からの回答はありません。**「いずれ重みが出る」前提で計画を立てない**のが現実的です。

## Recurrent-Depth Transformerの仕組み

OpenMythosの中核は、層を積み増す代わりに同じブロックを繰り返し通すRecurrent-Depth Transformer（Looped Transformerとも呼ばれます）です。以下は`open_mythos/main.py`の実装に沿った説明です。

### Prelude・Recurrent Block・Codaと入力の再注入

入力はまずPreludeを1回通り、その出力`e`を保ったままRecurrent Blockを、既定では最大`max_loop_iters`回、指定時は最大`n_loops`回まわし、最後にCodaを1回通ります。ループ内の更新式は `h_{t+1} = A·h_t + B·e + Transformer(h_t, e)` で、毎回`e`を足し直すことで元の入力から状態が離れていくのを防ぎます。`A`は`exp(-exp(log_dt + log_A))`を基本とする対角成分で、実装では内側の指数の引数をclampしています。線形部分の安定化を狙う設計ですが、浮動小数点演算では0や1になり得るため、非線形項を含むモデル全体の非発散を保証するものではありません。未学習の初期状態では`A`の最大値は0.3679でした。

### ACTの早期終了：act\_threshold=0.99は「停止確率の累積」

Adaptive Computation Time（ACT）は、位置ごとに最終出力への状態の加算を打ち切ります。ただし、停止済みの位置もブロックの演算と隠れ状態の更新は続きます。各ループで小さな線形層が「ここで止まる確率」`p`を出し、その累積が`act_threshold`（既定0.99）に達した位置から、出力への加算が止まります。状態の変化量を見ているわけではありません。全位置が止まるとループを抜けますが、**KVキャッシュを使う生成時は抜けない**実装です（後のステップが全ループ分のキャッシュを必要とするため）。

この挙動は実行すると数字で見えます。今回の設定と乱数seed=0では、全位置が2回目までに停止条件へ達しました。停止までの回数は初期重みや入力に依存し、未学習モデルで常に2回になるわけではありません（seedを0〜4で変えると、2回が3通り、3回が2通りでした）。

| 呼び出し                 | 指定したn\_loops | 実際に回った回数  | 所要時間    |
| -------------------- | ------------ | --------- | ------- |
| forward（2系列×128トークン） | 1            | 1         | 33.9ms  |
| forward（2系列×128トークン） | 4            | 2         | 55.2ms  |
| forward（2系列×128トークン） | 16           | 2         | 46.8ms  |
| generate（8トークン生成）    | 2            | 16（2×8）   | 137.2ms |
| generate（8トークン生成）    | 16           | 128（16×8） | 740.6ms |

MLA・dim=256・max\_seq\_len=256、乱数seed=0、CPUスレッド数4で、Intel Core i9-9880H上で測定した値です。forwardの時間は事前実行後の10回平均、generateの時間は1回の測定値で、統計的な速度比較ではありません。この条件のforwardでは`n_loops`を16にしても実際のループは2回で計算量は変わらず、生成では指定した回数がそのまま時間に効きます。**推論時のループ増加による性能向上は、未学習モデルの実行時間だけでは判断できず、学習済みモデルでの評価が必要**ということです。

### ループ番号の埋め込みと反復ごとのLoRA

同じ重みで毎回同じ計算にならないよう、各ループでは隠れ状態の1/8のチャネルにループ番号の正弦波埋め込みを足し、ブロックの出力にはループごとの倍率を持つ低ランクのLoRA補正を加えます。倍率の表は`max_loop_iters`個しかないため、推論時にそれより多く回すと最後の倍率が使い回されます。

### Chain-of-Thoughtとの違い

Chain-of-Thoughtは途中の考えをトークンとして出力しますが、反復深度方式はループ内の隠れ状態だけで推論を進め、途中経過は外に出ません。深さを層の数ではなくループ回数で変えられる代わりに、推論の過程を読めないという性質があります。

## MoEとMLA/GQAの内部構造

Recurrent Blockのフィードフォワード部は疎なMixture of Experts（MoE）で、Prelude・Codaは通常の密な層です。

### ルーテッドとシェアードを併用するMoE

DeepSeekMoEと同じく、トークンごとに上位`n_experts_per_tok`個を選ぶルーテッドエキスパートと、常に使うシェアードエキスパートを並べます。負荷の偏りは、DeepSeek-V3と同じく補助損失を使わずルーターのロジットにバイアス`router_bias`を足して均す設計です。ただし0.5.0では、このバイアスを更新する処理が本体にも学習スクリプトにも無く、値は0のままです。学習させるなら、エキスパートごとの使用率を見てバイアスを動かす処理を自分で足す必要があります。同系統の設計は[DeepSeek V4とは？Compressed Sparse Attention(CSA)の仕組みとPro/Flashの性能・料金・移行期限](/tech/details/12053/)でも扱っています。

### MLAとGQAの切り替え

注意機構は`attn_type`で`"mla"`（既定）か`"gqa"`を選びます。MLAはDeepSeek-V2由来で、KVを`kv_lora_rank`次元の潜在表現に圧縮してキャッシュを減らします（[DeepSeek-V3.2とは？V3.2-Speciale・DSAの仕組みと性能・使い方・料金を徹底解説](/tech/details/10128/)参照）。GQAはKVヘッドを`n_kv_heads`に減らす方式で、`flash-attn`が入っていればFlash Attention 2を使います。READMEの小さな設定ではMLAが1,538,626パラメータ、GQAが1,771,810パラメータでした。

## 「770Mで1.3B相当」の根拠：Parcae論文の条件

OpenMythosのREADMEが効率の根拠にしているのは、Hayden Prairie氏らの[Parcae: Scaling Laws For Stable Looped Language Models](https://arxiv.org/abs/2604.12946)（arXiv 2604.12946、2026年4月14日投稿）です。論文の表5では、ループ8回の770M Parcaeが評価指標COREで25.07±0.33、1.3Bの固定深度Transformerが25.45±0.08で、論文はこれを「comparable（同程度）」と表現しています。

読むときの注意は2つあります。1つは、これは**Parcae論文の著者が自分たちで学習したモデルの結果**で、OpenMythosを学習して測った数字ではないこと。もう1つは条件で、学習データはFineWeb-Edu、規模ごとの学習トークン数（表21）は770Mが61.6B、1.3Bが104Bです。「この実験条件では、770M Parcaeが1.3B Transformerに近いCOREスコアを示した」という結果であり、Claude Mythosの性能を説明する材料ではありません。

## OpenMythosの使い方：インストールからサンプル実行まで

ここからは2026年10月19日に、Intel Mac・Python 3.11.15・torch 2.2.2で、open-mythos 0.5.0を依存関係の自動導入を省く–no-deps指定でインストールして動かした記録です。パッケージが要求するtorch 2.11.0とは異なる構成での検証で、計算はすべてCPUです。

### pip installとPyTorchの版固定

READMEの手順は`pip install open-mythos`、Flash Attention付きなら`pip install open-mythos[flash]`です。PyPIの依存を版ごとに見ると、0.1.0と0.2.0は`torch`だけでしたが、0.3.0以降は`torch==2.11.0`・`transformers>=4.40.0`・`datasets>=2.18.0`を要求し、Pythonは3.10以上4.0未満です。

torch 2.11.0の配布物はLinux（x86\_64・aarch64）、Windows、Apple Silicon Macの3系統で、Intel Mac向けはありません。そのためIntel Macで普通に入れると、エラーにならずに**open-mythos 0.2.0とtorch 2.2.2が入ります**（pip 24.0とuvの両方で確認）。0.2.0にはプリセット（`mythos_1b`など）が無いので、版を確かめずに進めると後で詰まります。既存のPyTorch環境に入れると版を2.11.0へ入れ替えるため、専用の仮想環境を作るのが安全です。

```
python -m venv .venv && source .venv/bin/activate
pip install open-mythos
python -c "import importlib.metadata as m; print(m.version('open-mythos'), m.version('torch'))"
# Intel Mac で 0.5.0 のコードを読むだけなら（動作保証外）:
# pip install "torch==2.2.2" "numpy<2" "transformers==4.46.3" && pip install open-mythos==0.5.0 --no-deps
```

### READMEのサンプルを動かす：直す必要がある2か所

READMEのUsageはそのまま実行すると最後の行で止まります。`get_A()`が返す`A`は形が`(256,)`の1次元テンソルで、`torch.linalg.eigvals(A)`は「The input tensor A must have at least 2 dimensions」で`RuntimeError`になります。`A`は対角行列の対角成分なので、スペクトル半径は絶対値の最大値です。もう1つ、Model Variantsの例にある`mythos_7b()`は0.5.0に存在せず、`ImportError`になります。用意されているのは`mythos_1b`・`mythos_3b`・`mythos_10b`・`mythos_50b`・`mythos_100b`・`mythos_500b`・`mythos_1t`の7つです。

2か所を直した最小例です（GQAを選ぶ場合は`attn_type="gqa"`と`n_kv_heads=2`に変更します。MLA専用の5項目はGQAでは使われないため削除できます）。

```
import torch
from open_mythos.main import OpenMythos, MythosConfig

cfg = MythosConfig(
    vocab_size=1000, dim=256, n_heads=8, max_seq_len=128,
    max_loop_iters=4, prelude_layers=1, coda_layers=1,
    n_experts=8, n_shared_experts=1, n_experts_per_tok=2,
    expert_dim=64, lora_rank=8, attn_type="mla",
    n_kv_heads=8, kv_lora_rank=32, q_lora_rank=64,
    qk_rope_head_dim=16, qk_nope_head_dim=16, v_head_dim=16,
)
model = OpenMythos(cfg).eval()
print(f"Parameters: {sum(p.numel() for p in model.parameters()):,}")

ids = torch.randint(0, cfg.vocab_size, (2, 16))
with torch.no_grad():
    logits = model(ids, n_loops=4)
print(logits.shape)                       # torch.Size([2, 16, 1000])
out = model.generate(ids, max_new_tokens=8, n_loops=8)
print(out.shape)                          # torch.Size([2, 24])

A = model.recurrent.injection.get_A()     # 1次元（対角成分）
print(f"rho(A) = {A.abs().max().item():.4f}")  # eigvals は使えない
```

実行結果は`Parameters: 1,538,626`、`rho(A) = 0.3679`でした。重みは乱数なので、`generate`が返すのは意味の無いトークン列です。これは不具合ではなく、未学習モデルとして正しい動作です。

### プリセットの規模とMythosConfigの主要項目

プリセットの実際のパラメータ数を、メモリを確保しない`meta`デバイスで数えた結果です。総数のほぼ全部がRecurrent Block（MoE）に入っています。

| プリセット        | 総パラメータ  | うちRecurrent Block | max\_loop\_iters | vocab\_size |
| ------------ | ------- | ----------------- | ---------------- | ----------- |
| mythos\_1b   | 1.06B   | 0.91B             | 16               | 32,000      |
| mythos\_3b   | 3.04B   | 2.73B             | 16               | 32,000      |
| mythos\_10b  | 9.98B   | 9.45B             | 24               | 32,000      |
| mythos\_100b | 99.55B  | 96.16B            | 32               | 32,000      |
| mythos\_1t   | 999.33B | 978.95B           | 64               | 100,000     |

自分で構成するときに効く項目は、規模を決める`dim`と`expert_dim`、既定の反復回数`max_loop_iters`、MoEの`n_experts`・`n_shared_experts`・`n_experts_per_tok`、注意方式の`attn_type`、早期終了の`act_threshold`です。MoEなので、1トークンあたりに使うパラメータは総数よりずっと少なくなります。

### 学習は自前：training/3b\_fine\_web\_edu.pyの中身

同梱の学習スクリプトは`mythos_3b`を土台に、トークナイザーを`openai/gpt-oss-20b`から読み込み、その語彙数でプリセットの32,000を上書きします。系列長2,048、1ステップ256系列（約52万トークン）、学習率3e-4、AdamW、目標は30Bトークンで約5万7千ステップです。データの既定は`HuggingFaceFW/fineweb-edu`の`sample-10BT`です。データを読み終えると先頭から読み直す作りなので、この既定のままでも延べ30Bトークンまで学習は続きます。同じデータの再利用を減らすなら、`sample-100BT`などへの切り替えを検討します。複数GPUでは`torchrun`で起動し、コード上はFSDPで分割します（READMEの表はDDPと書いています）。fused AdamWなどGPU前提の書き方で、個人のPCで回す規模ではありません。

## 第三者によるOpenMythos検証：学習条件別の深さの外挿

READMEは「学習時より多くループを回せば、より難しい問題が解ける」（深さの外挿）を利点に挙げています。根拠の1つの[Loop, Think, & Generalize](https://arxiv.org/abs/2604.07822)（arXiv 2604.07822）は、合成データで学習した反復深度Transformerで推論時の反復を増やすと深い推論へ外挿できたこと、学習時に反復数を動的に変える方式が最も強かったことを報告しています。一方で、反復を増やしすぎると予測が悪くなる「overthinking」も同じ論文が報告しています。

OpenMythosのコードで学習まで行った第三者の報告が[Issue #28](https://github.com/kyegomez/OpenMythos/issues/28)です。117.8Mパラメータのモデルを約4.91億トークンのFineWeb-Eduで学習し、推論時のループ数を変えて評価しています。

| 学習時のループ数     | 最良の評価PPL   | 16ループで推論したPPL |
| ------------ | ---------- | ------------- |
| 1で固定         | 70.0（1ループ） | –             |
| 8で固定         | 57.9（8ループ） | 170.7         |
| 4〜16から毎回ランダム | 65.2       | 65.2          |

8ループ固定で学んだモデルは、学習時と同じ8ループで最も良く、16ループに増やすと約3倍悪化しました。ランダムに学ばせると4〜16ループで横ばいになり、増やしても良くはなりません。小規模な1件の実験なので一般化はできませんが、**少なくともこの実験では、ループを増やすだけで性能が向上するとは限らず、学習時の反復条件によって評価PPLの変化が異なる**ことは読み取れます。投稿者は当初の原因の推測（ループ番号の埋め込みとLoRA）を後の追記で撤回しており、議論は決着していません。

## OpenMythosを使うべき場面・使うべきでない場面

向いているのは、ループ型Transformer、ACT、MoE、MLAを1つのファイルで読み比べたい研究者と実装者です。PyPI版0.5.0の`main.py`は1,074行で、主要クラスには関連論文を挙げた説明があり、教材として読みやすい部類です。MITライセンスなので、自前の実験の土台にもできます。社内で独自モデルの学習を検討しているなら、まず小さな設定でIssue #28のような比較実験を再現し、ループ数の効き方を確かめてから規模を上げるのが手堅い進め方です。モデル開発を外部と組んで進める場合は[生成AI開発・AI受託開発](/service/ai/development/)のような支援も選択肢になります。

使うべきでないのは、すぐに推論させたい場合です。公式の重みが無いので、Ollamaで動かす、GGUFに変換する、といった使い方はできません。Hugging Faceにある`maidacundo/open-mythos-hf`もtransformers形式へ移植したコードだけで、重みファイルはありません。Claude Mythos相当のセキュリティ診断が目的なら、窓口はAnthropicのCyber Verification ProgramやClaude Securityで、OpenMythosはその代わりになりません。同じように「Transformerとは別の構造を試す」研究系の実装としては[BDH（ドラゴン・ハッチリング）とは？Transformerとの違いと実測性能・動かし方](/tech/details/10406/)も比較対象になります。

## よくある質問

### OpenMythosはClaude Mythos本体ですか？

いいえ。Claude MythosはAnthropicが審査付きで提供するモデルで、OpenMythosはその構造を公開論文から推測して組んだ非公式の実装です。Anthropicとの関係は無く、Firefoxの脆弱性発見などの実績もClaude Mythos側のものです。

### pip installすればすぐ使えますか？

モデルの定義は使えますが、学習済みの重みが無いので意味のある文章は出ません。0.3.0以降は`torch==2.11.0`固定のため専用の仮想環境に入れ、Intel Macでは0.2.0に落ちる点に注意してください。

### Hugging FaceやOllamaで動かせますか？

2026年10月時点では、公式の学習済みモデルを取得してすぐ文章生成する使い方はできません。モデル定義の実行や自前学習とは区別が必要です。作者による学習済みチェックポイントの公開が無く、GitHubのReleasesも空です。Hugging Face上の`open-mythos-hf`はコードの移植で、重みは含まれていません。

### 学習にはどれくらいの計算資源が必要ですか？

同梱スクリプトは3Bの設定で30Bトークン、1ステップ約52万トークンを約5万7千ステップ回す想定で、コードはGPUのbfloat16対応を判定し、非対応の場合はfloat16を選択します。必要なGPUメモリや台数は別途検証が必要で、複数GPUのプロセス数は起動時の`torchrun`で指定します。動作確認だけなら、READMEの小さな設定をCPUで動かせます。

### 商用利用や改変はできますか？

できます。ライセンスはMITで、著作権表示とライセンス文を残せば商用利用・改変・再配布が可能です。ただし学習に使うデータセットとトークナイザーには、それぞれ別のライセンスがかかります。

## 関連記事

- [Claude Mythosとは？Capybaraティアの正体・性能・料金・一般公開の最新状況【2026年6月】](/tech/details/11584/)
- [Claude Mythos 5.1とは：Fable 5.1との違いとCVPでの利用条件【2026年10月】](/tech/details/18215/)
- [DeepSeek-V3.2とは？V3.2-Speciale・DSAの仕組みと性能・使い方・料金を徹底解説](/tech/details/10128/)
- [BDH（ドラゴン・ハッチリング）とは？Transformerとの違いと実測性能・動かし方](/tech/details/10406/)

---

出典: [OpenMythosとは？Claude Mythosの構造を推測したオープンソース実装の仕組みと使い方](<https://www.issoh.co.jp/tech/details/12042/>)（株式会社一創）