SWE-Bench Verified 93.9%という数字を見て、何を感じただろうか。GitHub上のリアルなバグを自律的に修正する能力を測るこのベンチマークで、前モデルの Opus 4.6（80.8%）を大きく超えてきた。
しかし Claude Mythos は今、招待制の Project Glasswing を通じた限定公開であり、個人開発者が明日から使えるわけではありません。それでもこの数字を無視することができないのは、Mythos が示している「AIコーディング支援の次の地平」が、近い将来のすべての開発者に影響を与えるからです。
93.9% は何を意味するのか——実際の修正タスクで何が起きているか
SWE-Bench Verified は「実際の OSS プロジェクト（Django、Pytest、scikit-learn など）から収集したバグチケットを、コードを読んで自律的に修正できるか」を測定します。ランダムな質問ではなく、実際のリポジトリにあった本物のバグです。
93.9% は、渡された100件のバグチケットのうち93件以上を、人間の追加指示なしに修正できることを意味します。Opus 4.6 の80.8%でも十分すごいと思っていたが、その差は13ポイントあります。
より重要なのは質的な違いです。Opus 4.6 が得意とするのは比較的単純な修正（1ファイル以内、明確な原因）だが、Mythos はマルチファイルにまたがる複雑なバグ、依存関係の変化による副作用、型推論のエッジケースなど、熟練開発者でも手こずるケースに対応できます。
また Mythos は 1M トークンのコンテキスト窓を持ちます。中規模の React Native アプリのコードベース全体（src/ 以下など）が一度に収まるため、「このバグはどこが原因か」という問いに対して、ファイル間の依存関係を踏まえた上で回答できます。
Rork + AIコーディングの組み合わせがどう変わるか
Rork でビジュアルにアプリを設計した後、コードの調整・機能追加・バグ修正に AIコーディングツールを使うワークフローは、すでに多くの個人開発者が実践しています。
Mythos レベルの能力が一般開発者に届いたとき、このワークフローはどう変わるか。現時点での推測だが、3つの変化が想定できます。
1. 「なんとなく動くコード」から卒業できる
AIが生成したコードをコピーしてとりあえず動かす、という段階から、「本番環境で壊れないコード」を最初から生成できるようになります。テスト網羅率の低いコードや型定義のあいまいなコードが減り、後からのデバッグ工数が下がる。
2. リファクタリングの敷居が下がる
「このコードは動いているが、構造が汚い」と分かっていても手をつけない、という状況がなくなります。コードベース全体を把握した上でリファクタリングを提案・実行できるAIが使えるなら、技術的負債の解消が現実的な日常業務になります。
3. 開発の「詰まり」が減る
個人開発者が開発を止める最大の理由の一つは「解決策が分からない問題にぶつかること」です。93.9%のバグ修正能力があるということは、多くの「詰まり」を自律的に解消できることを意味します。これはリリースまでのタイムラインに直接影響します。
今、Opus 4.6 で最大限近づくための実装パターン
Mythos はまだ使えありません。しかし、その方向性を見据えながら Opus 4.6 の使い方を最適化することはできます。
パターン1: コンテキストを最大限活かす
Opus 4.6 のコンテキスト窓は20万トークンです。Rork プロジェクトの重要なファイル（コンポーネント、API連携、型定義）をまとめてコンテキストに渡してから質問することで、的外れな回答が減る。
# 効果的なコンテキスト提供の例
以下のファイル群を前提に、[具体的な問題]を解決するコードを書いてください:
[src/screens/HomeScreen.tsx の内容]
[src/hooks/useUserData.ts の内容]
[src/types/index.ts の内容]
[src/api/userApi.ts の内容]
パターン2: バグを「原因の説明」と一緒に渡す
「このコードが動かない」だけでなく、「エラーメッセージはXXXで、Yというケースで発生する」という情報を添えると、AI の修正提案の精度が上がる。エラーログをそのまま貼るのが効果的です。
以下のエラーが発生しています:
TypeError: Cannot read properties of undefined (reading 'map')
at HomeScreen.tsx:42
このエラーはアプリ起動直後（データ取得前）にのみ発生します。
以下のコードを修正してください: [コード]
パターン3: テストコードと一緒に生成依頼する
「動くコード」と「壊れにくいコード」の違いは、多くの場合テストの有無です。機能実装と同時にテストコードも生成依頼することで、後から発見されるバグが減る。
以下の機能を実装してください。
- Jest + React Native Testing Library でのユニットテストも合わせて書いてください
- エッジケース（空のレスポンス、ネットワークエラー）のテストを含めてください
個人開発者が今準備すべきこと
Claude Mythos が一般開発者に届く日は、まだ分からありません。しかし、AIコーディング支援が「ほぼ人間並みのバグ修正能力」を持つ方向に進んでいることは確かです。
今すぐできる準備は、AIとの協働ワークフローを整えることです。Rork でアプリのビジュアルを設計し、Opus 4.6（あるいは Claude Sonnet）でコードを生成・改善する流れを日常にすること。コンテキストをどう渡すか、バグをどう説明するか、テストをどう組み込むか——このスキルは、Mythos が使えるようになっても変わらず必要になります。
AIが強くなればなるほど、AIへの指示の質が結果を決める。その準備は今日から始められます。