本記事は、CodeRabbitの提供するポッドキャストTHE MERGEより、GPT-6 Astra vs Fable 5.1: Does More Reasoning Improve Your Code?の日本語解説記事です。

TL;DR

GPT-6 AstraとFable 5.1を並べてみると、ベンチマークスコアだけでは見えない違いがあります。Astraは指示を受けてから即座に動き、コードベース全体をまたぐ問題の把握や複数ツールを使った作業を得意としています。対してFable 5.1は処理に時間がかかりますが、同じ持ち時間で比べた実験においては、より作り込んだ成果物を作成する場面もありました。

そして見逃せないのが、モデルの能力が上がった結果として、これまで役に立っていたAgent.mdやSkill.md、固定的なワークフロー、細かな手順書が、かえってモデルの判断力を狭め始めているという指摘です。これからのAI駆動開発は、モデルを細かく操作するのではなく、権限と境界だけを渡して、処理中の判断はモデルに任せる設計へ寄っていきそうです。

GPT-6 AstraとFable 5.1の実用上の違い

AstraとFable 5.1は実際に使ってみると、挙動の違いがはっきりと分かります。Astraはタスクを渡すと一点に集中して実行し、比較的早く解決策まで到達します。対するFableは時間を使い、途中で方向付けが必要になることもありますが、最終的には広い範囲まで作り込んだ結果を返してきます。Astraはプロンプトに引きずられる度合いも大きいので、何を実行してよいのか、どこまで権限を持っているのかは書き手が明示しておきたいところです。

Astraは科学分野の作業や技術的な作業、技術ドキュメントにも強く、与えられた目的に向かって集中して進みます。ただし判断はあくまで確率的なので、曖昧な指示を渡せば意図と違う方向へ向かうこともあります。能力が高いから細かい指示が不要になるという話ではありません。目的・権限・境界の3つは、これまでどおり言葉にして渡す必要があります。

コンピュータ操作の能力も上がっています。動画の中では、登壇の裏でゲーム開発を進めていたAstraが自分でUIテストを始め、投影中のプレゼン画面をゲーム画面に切り替えてしまった、という一幕も紹介されました。自律性が上がるほど、何を実行できるかに加えて、いつ・どこで実行するかまで手綱を握っておきたくなります。

コードレビューで見えたクロスファイル理解の進化（11:53〜）

CodeRabbitの評価では、一般的なバグ検出の精度もGPT-5.6 Soulから伸びています。ただ、差がはっきり出たのはクロスファイルレビューでした。クロスファイルレビューとは、変更されたファイルだけを見るのではなく、コードベース内の複数ファイルや複数システムを横断して、変更の影響を追いかける力です。

たとえば関数に引数を1つ足せば、その関数を呼んでいる箇所をコードベース全体から洗い出します。厄介なのは直接の依存関係ではなく、別システムのエッジケースとして数週間後に表面化するようなケースです。この場合、離れた場所にある複数の情報を長い文脈の中に保ったまま、関係を結び付けて判断します。

Astraの強みは、長いコンテキストを扱えることだけではありません。自分が置かれているハーネスの目的や、渡されたツールの用途を推測して使いこなす点も高く評価されています。一度やると決めた作業を途中で投げ出さず、実現方法を探し続ける粘り強さも挙げられました。コードレビューでは、この結び付ける判断と粘り強さが、そのままクロスファイルの問題検出につながっています。

Agent.mdやSkill.mdがモデルの能力を制限する（21:31〜）

モデルが賢くなるにつれて、これまでAIエージェントを助けてきたAgent.mdやSkill.mdといった大量のMarkdownが、むしろ足かせになり始めています。コンテキストを浪費してコストを押し上げるうえに、そこに書かれたルールがモデル自身の判断を縛ってしまうからです。

分かりやすいのが、本番環境が落ちたときの振る舞いです。エージェントが修正を作っても、「必ずPRを作る」「レビューを通す」「マージキューを待つ」「絶対に直接本番へ反映しない」といったルールが並んでいれば、緊急時でも律儀に通常の手順を守り続けます。目的はサービスの復旧のはずなのに、過去に自分たちで置いた絶対ルールがその達成を邪魔します。

「絶対にするな」「必ずこの順番で実行しろ」といった書き方や、ステップを固定した手順書も同じで、今のモデルには締め付けが強すぎます。Astraでは、複数のCodexセッションが指示されていないのに互いに通信し、自然と役割分担を始めるケースまで確認されました。固定のDAGやオーケストレーションを前もって設計するより、境界だけ引いて中の判断はモデルに委ねる方面に設計の重心が動いています。

推論量とコストは最大にすればよいわけではない（33:26〜）

入出力トークンの単価は、AstraもFableも同等とされています。ただし同じタスクを終えるまでにAstraが使う出力トークンは少なめで、実運用では請求が軽くなる場面があります。Astraは低い推論レベルでも十分な結果を出すので、日常的な作業は最も低いLightで回し、品質が要るタスクだけMedium、High、Extra Highへ上げていく。動画では、そんな使い方を紹介しています。

モデルルーティングについても、利用者が毎回モデル名と推論レベルを選ばされる世界は理想ではないと話しています。タスクを始める前に、必要な作業量や推論量を言い当てるのは難しいからです。モデル選びはAIが引き受け、利用者は時間や費用といった実体ある予算だけを指定する方が筋が良いという見方です。

Fable 5.1のコードレビュー評価では、適合率（Precision）が改善した一方、再現率（Recall）はわずかに下がりました。タスクあたりのレイテンシーも増えていて、実際に使ってもAstraより待たされるという感触が語られています。安全性のClassifierがツール実行を止める場面が多く、そのたびに推論をやり直すことがレイテンシーとトークン消費を押し上げているのではないかという指摘をしています。

モデルの限界より人間のTasteとImaginationが問われる（52:48〜）

AstraとFable 5.1に同じ持ち時間を与えて、GTA風のゲームを作らせる実験を披露しています。Astraは、短い時間でプレイできるところまで仕上げます。対してFable側の成果物には、時間帯の変化やミッション、車の乗り換えといった要素がより多く盛り込まれていました。Astraは素早く形にし、Fableは時間をかけて広げる。それまで語られてきた違いが、そのまま成果物に出た形です。

Astraで作った別のゲームは、もっと先まで進んでいます。2Dゲームから3Dバージョンを複数生成し、それらをゲーム内の要素として組み込むところまで到達しました。ゲームシステムには988ノードのパッシブスキルツリーを持たせ、数値を盛るだけの強化ではなく、プレイスタイルそのものを変える仕組みやトレードオフまで含めてバランスを設計しています。

ここでHendrikがボトルネックに挙げたのは、モデルの性能ではなく人間側の味付け（Taste）と創造性（Imagination）でした。何を作りたいのか、どこまで作り込むのか…そうした観点が成果物を左右します。使い分けも具体的で、複雑なゲームシステムやバランス設計にはExtra Highなど高い推論レベルを当て、そのあとの実装作業はLightで流す、という進め方が示されました。全工程で最大推論を回すのではなく、人間が目的を決めて、必要な場所に計算リソースを集中させるという、配分が大事になります。

まとめ

GPT-6 AstraとFable 5.1を並べてみて分かるのは、モデルの性能をひとつのベンチマークだけで測ることの難しさです。Astraは素早い実行やクロスファイルの理解、ハーネスやツールの使いこなし、自律的なオーケストレーションで強さを見せました。Fable 5.1は、時間を使って成果物をより細かいところまで作り込みます。どちらが上かではなく、用途に対してどの性質が欲しいのかを見極める必要があります。

そして、モデルが賢くなるほど人間側の設計も組み替えが必要になります。大量のルールや絶対的な禁止事項、固定された手順やオーケストレーションは、モデルの判断力を削りかねません。これから問われるのは、AIにすべてを指示することではなく、目的と境界をはっきり示したうえで、中の判断はモデルに委ねること。そして進む方向そのものは、人間が味付けと創造性で決めるのです。

CodeRabbitでは、他にもたくさんのポッドキャストを配信しています。ぜひチャンネル登録お願いします！