Claude Mythos と Fable で開発はどう変わるか — 検証が「正しい実装」から「正しい仕事」へ

Anthropic は 2026 年 6 月 9 日、Claude Mythos クラスと、その系譜の一般提供モデルである Claude Fable 5 を公開した。Fable 5 は「long-horizon agentic work（長期にわたるエージェント作業）」を強みとし、ソフトウェアエンジニアリングや知識作業、視覚タスクで能力が強化されたと説明されている。

この世代のモデルが実務で何を変えるのか——その手がかりが、Claude Code チームの実践だ。同チームのエンジニアは「Fable 5 がチームの日々の働き方を変えた」「以前は Claude が作業を正しくやったかを検証していたが、今はそれが正しい仕事をしているかを検証している」と語る。本記事は、AIコーディングエージェントを日常的に使う開発リードやチーム責任者に向けて、Claude Mythos / Fable 5 が開発の何を変えるのか、そして「丸投げ」に陥らず大きく任せるための設計を、公式情報をもとに整理する。

Claude Mythos は、長期にわたる自律的なエージェント作業を主眼に置いた Claude のモデルクラスであり、Claude Fable 5 はその系譜で一般提供される高性能モデルである。 本記事の主役であるこの2つが何者で、何が強化されたのかを、まず公式情報で押さえておく。

Anthropic は 2026 年 6 月 9 日に Claude Fable 5 と Claude Mythos 5 を提供開始した。公式の位置づけでは、Fable 5 は Mythos クラスに属する一般提供（一般利用向け）の高性能モデルであり、誰もが日常的に使えるモデルとして案内されている。

名前の整理をしておくと、「Mythos」はクラス（系統）を、「Fable 5」はその系統で広く提供される具体的なモデルを指す、と捉えると分かりやすい。本記事では、後述する Claude Code の自律実行を支える基盤としてこの世代を扱うため、以降は主に Fable 5 を指して話を進める。

Fable 5 の強みとして公式が挙げているのは、long-horizon agentic work（長期にわたるエージェント作業）である。あわせて、ソフトウェアエンジニアリング、知識作業、視覚タスクといった領域でも能力が強化されたと説明されている。

「長期にわたるエージェント作業」が効いてくるのは、一度の指示で扱える作業のまとまりが大きくなるからだ。数行のコード補完ではなく、要件の解釈から実装・検証までを含むひと続きの作業を、AIエージェント が自律的に進められる——この性質が、この後で見る検証や働き方の変化を技術的に支えている。

このモデル世代が実務をどう変えるかを端的に示すのが、Claude Code チームの実践談だ。同チームのエンジニア Thariq Shihipar 氏は X（旧 Twitter）で、「Claude Fable 5 changed how we work on the Claude Code team day to day（Fable 5 は Claude Code チームの日々の働き方を変えた）」「We used to verify that Claude did the work right. Now we verify that it's doing the right work.（以前は Claude が作業を正しくやったかを検証していた。今は、それが正しい仕事をしているかを検証している）」と述べている。

Thariq 氏は Anthropic の Claude Code チームのエンジニアとして紹介されている人物だが、これらの投稿は公式ドキュメントではなく、チームメンバーの実践談・宣伝的なポストである点には留意したい。とはいえ、検証の重心が「実装の正しさ」から「仕事の正しさ」へ移りつつあるという実感は、この後の章で見る公式機能の設計とも符合している。

検証の軸が移るとは、「実装の正しさ」を一行ずつ確かめる作業の比重が下がり、「目的に対して正しい仕事をしているか」を確かめる作業の比重が上がることを指す。 どちらの検証もなくなるわけではない。変わるのは、人間が限られた時間をどちらに割くか、その配分である。

従来の検証は、AIが書いたコードの差分を一行ずつ読み、構文・型・ロジック・テストの通過を確かめる作業が中心だった。これは「正しく実装できているか（did it build the thing right）」を見る検証である。ツールがまだ局所的だった時期は、AIの出力はせいぜい数行から一つの関数程度にとどまり、その正しさを人間がレビューで担保するのが現実的だった。

この段階では、レビュアーの負担の多くは「AIが書いたものを完全には信用しきれない」ことに由来していた。実際、Claude Code と Codex の比較記事でも、エージェントの出力をレビューせず本番投入することは典型的な失敗として挙げられている。差分の精読は、出力が小さいうちは有効な品質保証の手段だった。

もう一方は「そもそも正しい仕事をしているか（is it doing the right work）」を見る検証である。コードとして破綻していなくても、作っているものが目的や制約と食い違っていれば、その実装は「正しく」ても「正しい仕事」ではない。要件の解釈、設計判断、優先順位づけといった上流の妥当性を問う検証だ。

冒頭で引用した Claude Code チームの「今は、それが正しい仕事をしているかを検証している」という実感は、まさにこの上流の検証を指している。Fable 5 のようにまとまった作業を任せられるようになるほど、コードの正誤を一行ずつ追うよりも、作っているものの方向そのものを問う検証の比重が増す——この実感は公式ドキュメントの記述ではなく実践談だが、後続の章で見る公式機能の設計とも整合している。

この2つの検証はトレードオフではなく、層が異なる。「実装の正しさ」は、型チェック・自動テスト・CI、そして後述するエージェント同士の相互検証によって、以前より機械的に担保しやすくなった。だからこそ、人間の負担が軽くなるのは主に前者の「実装の正しさ」の側である。

一方で「正しい仕事か」は、目的・背景・制約を理解している人間にしか最終的には判断できない。これはなくなるのではなく、人間が集中すべき検証として残る。なお、ミスを「構造」で未然に防ぐ仕組み（CLAUDE.md やルール、CI ガードの作り込み）は検証とは別の論点であり、ハーネスエンジニアリングで詳しく扱っている。

この変化を後押ししているのは、AIが「一度の指示で大きなまとまりの作業を、検証まで含めて」進められるようになった3つの仕組みだ。 ゴール駆動の実行、サブエージェントによる相互検証、そして長期作業に強いモデルである。順に公式情報をもとに見ていく。

/goal は、完了条件を設定すると、毎ステップ指示しなくても Claude がその条件に向かって作業を続ける Claude Code のコマンドである。公式ドキュメント（code.claude.com/docs/en/goal）は「完了条件を設定し、Claude が一手ごとの指示なしにそこへ向かって作業を続ける」と説明している。利用には Claude Code v2.1.139 以降が必要だ。

意味するところは単純で、「次はこれ、その次はこれ」と逐次指示する代わりに、満たすべき条件を先に与えるという発想の転換である。ここで成果を左右するのは、完了条件をどれだけ的確に書けるかだ。条件が曖昧なら、いくらモデルが優秀でも「正しい仕事」にはたどり着かない。検証の重心が「条件の設計」へ移る、最初の入り口がこのコマンドだといえる。

Dynamic workflows は、Claude が JavaScript のスクリプトを書き、そのスクリプトが多数のサブエージェントを大規模に編成・実行する Claude Code の機能である。公式ドキュメント（code.claude.com/docs/en/workflows）は、コードベース横断のバグ掃討、500 ファイル規模の移行、ソースを相互チェックするリサーチといった用途を挙げている。

注目すべきは、検証が仕組みに組み込まれている点だ。独立したエージェントが互いの findings を批判的にレビューしてから報告する「adversarial verification（敵対的検証）」が設計に含まれている。ただし本機能はリサーチプレビューであり、利用には Claude Code v2.1.154 以降と有料プランが必要で、Pro では /config から有効化する。「誰でも今すぐ丸投げできる」機能ではなく、前提条件のある先進機能だという点は押さえておきたい。関連する設計思想は エージェントオーケストレーション や マルチエージェントシステム も参照。

これらの機能を実際に動かしているのが、Fable 5 をはじめとする長期作業に強いモデルだ。前章で見たとおり Fable 5 は long-horizon agentic work を強みとし、一度に扱える作業のまとまりを押し広げている。だからこそ /goal のゴール駆動や Dynamic workflows のような「まとめて任せる」機能が現実的に機能する。

さらに Claude Opus 4.8 の発表では、Dynamic workflows について「Claude が作業を計画し、単一セッションの中で数百の並列サブエージェントを実行し（Opus 4.8 ではエージェントがより長く動ける）、出力を検証してからユーザーに報告する」と説明されている。エージェントが一度に扱える作業が大きくなり、かつ自前で検証してから返してくるようになったこと——これが「検証の軸が移る」現象を支える、Mythos / Fable 世代の技術的な背景である。

作業がまとまりで進むようになると、開発者の時間は「実装をどう書くか」を逐一指示することから、「何を・どんな制約で・どこまで・どう確かめるか」を設計することへ移る。 指示者から、共同開発者の設計者へ、という変化だ。

かつては、実装の各ステップをこちらが考え、エージェントに指示し、返ってきた差分をレビューする、という往復が中心だった。今は、完了条件と制約を渡せば、まとまった範囲をエージェントが自分で進める。逐次の指示出しに費やしていた時間が、目に見えて減っていく。

当社の開発現場でも、レビューの重心は「差分を一行ずつ追う」ことから、「受け入れ条件と設計意図に照らして、この変更は妥当か」を見ることへ移りつつある。差分そのものより、それが要件に対して正しい方向を向いているかを問う比重が増えた、という肌感がある。逐次指示が減ったぶん、何を確かめるべきかを考える余地が生まれている。

逐次指示から浮いた時間は、上流の設計に回る。具体的には、目的・背景・制約・完了条件、そして検証方法をどう与えるかという設計だ。エージェントに渡す文脈の質が成果を決めるという点で、これは プロンプトエンジニアリング から コンテキストエンジニアリング への流れと地続きである。

個人の働き方だけでなく、チームとしてこの設計を標準化する動きも重要になる。完了条件の書き方や検証の型を属人化させず、CLAUDE.md・Skills・Hooks といった仕組みで共有する進め方は、Claude Code チーム導入ガイドで扱っている。設計に時間を移すというのは、各自が場当たりに頑張ることではなく、任せ方と確かめ方をチームの資産にすることでもある。

「Fable 5 なら丸投げで正しくやってくれる」というのは、危険な誤読である。 モデルの能力が上がったのは事実だが、それは「無監督でよい」を意味しない。むしろ公式の設計では、人間の監督が中心に据えられている。

SNS で見かける「もう細かい指示はいらない」「任せておけばいい」といった強い要約は、宣伝的な実践談として読むのが安全だ。能力の向上が実際に意味するのは、「無監督でよい」ではなく、「目的設計と検証設計の重要性がいっそう増す」ということである。

理由は単純で、間違った目的を与えれば、優秀なエージェントほど速く、確信を持って、間違った方向へ進むからだ。手作業なら途中で違和感に気づけたかもしれない逸脱も、まとまりで自律的に進む分だけ、気づいたときには広範囲に及んでいる。能力が上がるほど、入口の目的と出口の検証——人間が設計すべき両端——が効いてくる。

この前提は、開発者の主観ではなく公式の設計に裏づけられている。Anthropic の Claude Code 紹介ページ（anthropic.com/product/claude-code）は「Human oversight remains central（人間の監督が中心であり続ける）」と明記し、システムはファイルの変更やコマンドの実行の前に許可を求め、何をコミットするかは開発者が完全に制御する、と説明している。

つまり、エージェントがどれだけ自律的に動こうと、変更を加える瞬間には人間の承認が挟まり、最終的に何を出荷するかは人間が決める設計になっている。「正しい仕事をしているか」の検証と最終判断を人間が握ることは、運用上の心がけである以前に、ツールが前提としている使い方なのである。

実務では「大きく任せる」と「確実に検証する」を両立させる設計が要る。 その核心は、入力の設計・検証の設計・出荷判断という3つを、作業を始める前に決めておくことだ。順に、具体的な渡し方を示す。

第一に、入力の設計である。エージェントには、目的・背景・制約・完了条件をひとそろいにして渡す。バラバラの単発指示ではなく、「何のために」「どんな前提で」「何を守りながら」「どこまでできたら完了か」を一度に与えるイメージだ。

たとえば /goal を使うなら、次のような渡し方になる。「この仕様を実装し、すべての受け入れ条件を満たすまで作業を継続してください。ただし既存 API の互換性を壊さず、DB スキーマ変更が必要な場合は事前に提案してください」。ここで「既存 API を壊さない」「スキーマ変更は事前提案」が制約であり、「受け入れ条件を満たすまで」が完了条件にあたる。制約と完了条件を最初に固定しておくほど、まとまりで任せても逸脱が起きにくくなる。

第二に、検証の設計である。受け入れ条件と、報告してほしいレポートの形式を、作業を始める前に決めておく。たとえば「実装後に、変更ファイル・実装内容・未対応点・テスト結果・仕様との差分をレポートしてください」と指定しておけば、出力を「正しい仕事か」の観点でレビューしやすくなる。

Dynamic workflows のように、エージェント同士が相互に findings をレビューする仕組みは、この検証を一次フィルタとして機械化してくれる。ただしそれは人間の検証の代わりではなく、人間が最終確認に集中できるよう前段を整えるものだ。何をもって「正しい仕事」とするかの基準そのものは、依然として人間が定義する必要がある。

第三に、出荷判断である。エージェントが返してきた差分・テスト結果・仕様との差分・未対応点を人間が確認し、出荷するかどうかを決める。前述のとおり、何をコミットするかを開発者が制御する設計になっているので、この最終ゲートは飛ばさない。

とりわけ、認証・権限・テナント分離・課金など、間違うと影響が大きい領域に触れる変更は、まとまりで任せたものほど慎重に確認したい。「テストが通っている」は「実装が正しい」ことの証拠にはなっても、「正しい仕事をしている」ことの証明にはならない。受け入れ条件と照らし、残課題を把握したうえで、出すか戻すかを人間が判断する——ここが任せ方の設計の締めくくりになる。

ここからは、現場でよく出る3つの疑問に、要点を絞って答える。

結論から言えば、可能であり、むしろ少人数ほど効果が出やすい。レビュー要員が限られるチームでは、実装の細部を全部追うより、完了条件を的確に設計し、検証と最終判断に人手を集中させるほうが現実的だからだ。

ただし機能には前提がある。/goal は Claude Code v2.1.139 以降、Dynamic workflows は v2.1.154 以降かつ有料プラン（Pro では /config から有効化）で、後者はリサーチプレビューの段階だ。まずは /goal で完了条件を渡す働き方から慣らし、必要に応じて Dynamic workflows へ広げるのが無理のない順序である。

基本は許可制と権限設計で担保する。Claude Code はデフォルトで、ファイル変更やコマンド実行の前に承認を求める設計になっており、何をコミットするかは開発者が制御する。自律性が上がっても、変更を加える瞬間のゲートは残る。

加えて、人間が毎回見張る代わりに、ミスを「構造」で防ぐ作り込み——許可ルール、CI ガード、リポジトリ規約——を整えておくと安定する。この構造的なガードレールの設計は、ハーネスエンジニアリングで具体的に解説している。

完了条件を明確に書けて、かつ失敗したときの影響が限定的なタスクから始めるのが安全だ。たとえばテストの拡充、定型的なリファクタリングや移行、横断的な調査などは、受け入れ条件を定義しやすく、まとまりで任せる練習に向いている。

逆に、要件の解釈が割れる、あるいは本番の重要経路に直接触れるタスクは、任せ方が成熟してから広げたい。どのツールにどの粒度のタスクを割り当てるかという判断軸は、Claude Code と Codex の比較記事の実測データも参考になる。

Anthropic が公開した Claude Mythos クラスと Fable 5 は、長期にわたるエージェント作業を強みとし、開発の進め方を着実に変えつつある。人間の検証の重心は「正しく実装できているか」から「そもそも正しい仕事をしているか」へ移り、/goal による完了条件の駆動、Dynamic workflows によるサブエージェントの相互検証、そして Opus 4.8 を含む長期作業に強いモデルが、この変化を技術的に後押ししている。

ただし、能力の向上は「丸投げでよい」を意味しない。公式の設計でも人間の監督が中心に据えられ、何を出荷するかは人間が決める。だからこそ実務では、目的・制約・完了条件・検証方法を設計して大きく任せ、受け入れ条件に照らして最終判断を握る——この両立が要になる。

当社は、こうした AIエージェントを前提とした開発・業務プロセスの設計と、現場への定着を支援している。「どのタスクから、どんな完了条件で任せるか」を一緒に設計したい方は、AIエージェント の基礎とあわせてお気軽にご相談いただきたい。