GPT-6 Astraのコードレビュー評価：改善、プライバシー、コスト

コードレビューで特に難しい仕事の一部は、変更された行の外にあります。変更だけを見れば正しくても、システムの別の場所にあるコードを壊してしまうことがあります。

OpenAIのGPT-6 Astraに関する初期評価がとりわけ興味深いのは、そのためです。今回の評価では、Astraは開発者が対応に移せる指摘を通じて、GPT-5.6 Solより約4%、Opus 5より約22%多く、正解ラベル付きのバグを検出しました。

最も大きな差が表れたのは難しいファイル横断レビューで、Astraの改善幅はSolに対して20%、Opus 5に対して33%に達しました。この能力をお客様向けに広く活用するには、お客様のデータを保護し、モデルの公開API料金を検討することも必要です。

Astraがコードレビューにもたらしたもの

ここでの指標は、対応可能な指摘によるバグ検出率です。これは、開発者が対応できる指摘を通じて、モデルが正解ラベル付きのバグをどれだけ検出したかを表します。

今回の全体評価の指標では、GPT-5.6 Solに対する改善は小幅に見えます。この評価には比較的簡単なレビューも含まれており、より高性能なモデルが差をつける余地は小さいのかもしれません。Astraの優位がより大きく現れたのは、難しいファイル横断レビューでした。これは方向性を示す初期の結果です。

難しいファイル横断レビューの結果は、より期待を持てるものです。Astraの相対的な優位は、Solに対して20%、Opus 5に対して33%に広がりました。変更の意図と、コードベース内の離れた場所に生じる影響を結び付ける能力の価値を示唆しています。

これらの結果が示すのは、レビュー性能の一側面です。レビュー品質の総合順位を決めるものでも、チームの不具合率を予測するものでも、すべてのプルリクエストで同じ改善を約束するものでもありません。

コンテキストを役立てる

大きなコンテキストウィンドウは、多くの情報を入れる余地を作ります。役立つ推論には、その中で重要な情報を見極め、結び付け、根拠のある結論に到達することが必要です。

Astraの最も興味深い進歩は、必要な情報を適切に結び付ける点にあると私たちは考えています。難しいファイル横断レビューで改善幅が大きかったことは、必要な情報が分散している仕事での進歩を示唆します。ただし、この評価だけで進歩の原因を切り分けたり、コンテキストを増やすだけでモデルが良くなると証明したりすることはできません。

OpenAIはAstraを、コード、ブラウザー、業務用ソフトウェアをまたぐ複数段階の仕事に位置付けています。

モデルを組み込むチームにとって重要なのは、追加の推論が、コストに見合うほど結果を変えるのはどこかという問いです。安価なモデルですでに安定してこなせる定型作業よりも、根拠が散在する難しい仕事の方が、試す価値は高いでしょう。だからといって、すべてのセッションをAstraに切り替え、推論量を最大にして、あとは任せきりにすればよいわけではありません。

高度な推論には相応のコストがかかる

Astraの標準API料金は、Astraの公開料金によると、入力100万トークンあたり10米ドル、出力100万トークンあたり50米ドルです。Fable 5.1の基本的な入出力料金も同じですが、キャッシュ料金は異なります。詳しい内訳はAnthropicの料金ドキュメントをご覧ください。

比較のため、キャッシュを使わない入力10万トークンと、推論トークンを含む課金対象の出力1万トークンを使う作業を考えてみます。使用トークン数をそろえると公開料金を比較しやすくなりますが、実際の作業コストは使用量によって変わります。

この固定使用量では、AstraのコストはSolの2.5倍、Terraの約4.7倍、Lunaの約47倍です。無視できない差です。これらは、完了した作業1件あたりのコスト差を予測するものではありません。必要なトークン数や試行回数が少なければ、その差は縮まる可能性があります。

OpenAIは、自社の一部の評価では、Astraのトークン単価が高くても推定作業コストは低くなったと報告しています。だからこそ、トークン単価や能力スコアのどちらかだけで判断せず、自分たちの仕事で成功した結果1件あたりの総コストを測る価値があります。詳しくはOpenAIの効率に関するガイドをご覧ください。

コードレビュー以外に応用できそうなこと

応用の鍵は、別々の情報源の関係を推論することです。今回の結果から、次のような用途を試す価値があると考えています。ただし、これらの仕事でAstraの性能を測ったわけではありません。

• 調査結果の統合： 食い違う報告を整理し、主張を根拠と結び付け、文書を1本ずつ要約するだけでは見落とす欠落を探す。
• 運用上の調査： ログ、インシデント記録、手順書から筋の通った説明を組み立て、観測事実と仮説を分ける。
• 要件や方針の分析： 変更案の影響を仕様書、社内方針、実装計画にわたってたどり、専門家が確認すべき不整合を見つける。
• 文書やスプレッドシートの作業： 報告書と補足資料の間で、前提、数式、文章による結論が一致しているかを確認する。

共通しているのは、根拠が散在し、それぞれが依存し合っていることです。まずは、答えを確認できる範囲の仕事から始めましょう。Astraが自分たちのワークフローや製品に合うかを試す最も簡単な方法は、現在のモデルと同じ仕事をさせ、回答の質、確認にかかる時間、総コストを比較することです。

NIGHTSHIFTの制作とバランス調整

私たちはAstraを使って、ゲームを丸ごと1本作りました。NIGHTSHIFTは、GodotとGDScriptで作られたアクションRPGです。最も難しかったのは、各システムの相互作用を調整し、ゲームが変わるたびにそのバランスを見直すことでした。

対象は、7つのキャラクタークラス、名高いPath of Exileのパッシブノードツリーに着想を得た988ノードのパッシブスキルツリー、アクティブスキル、ルーンとソケットに装着する強化要素、スキルの進化、協力プレイにまで及びます。10幕にわたる40のゾーンでは、敵の群れや組み合わせが次第に複雑になります。一つのクラスを変えると、どの強化が有効か、スキルがどう発展するか、パーティーがどこまで戦えるかにも影響します。

開発中には中核となるシステムを根本から変更し、その影響を整理してバランスを調整し直すようAstraに求めました。このようなゲームで魅力的なプレイ体験を作るうえで、最も難しい創造的な課題は「バランス」です。大幅な変更や、まったく新しいシステムや仕組みを取り入れながら、成長、戦闘、難易度の整合性をどう保てばよいのでしょうか。

私たちがさらに目指したのは、クラス、ステータス、アイテム、パッシブ、アクティブスキルの巧みな組み合わせから、プレイヤー自身がエンドゲームで圧倒的な強さを発揮するビルドを発見できるゲームでした。中盤にたどり着ける保証さえない一方で、工夫や試行錯誤が大きな成果につながる成長の流れを作ることが課題でした。その組み合わせを見つけ、ビルドを育てた先には、敵の群れを気持ちよく溶かすような強さが待っていました。

ほかの仕事の合間にもゲームに戻り、Astraにフィードバックを伝え、バランスの改善はAstra自身の判断に任せました。AstraはPS5とXboxのコントローラーへのネイティブ対応、macOSのネイティブビルド、Web版、Linux版、協力プレイも実装しました。特に興味深かったのは、同じコンピューターでもLAN経由でも遊べる協力プレイです。macOSを使う同僚に配布するために、新しいXcodeプロジェクト、App Store Connectのアカウント、複数の証明書やエンタイトルメント、公証への対応も必要になりました。

Astraは、まだ持っていない権限や許可を時々求める以外は、これらを自律的に進めました。さらに、エージェント自身もプレイヤーになれるようゲームを設計したため、Astraをチームメイトにしてリアルタイムで協力プレイをする、不思議な体験もできました。なかなかやめられなくなったメンバーもいます。上司が通りかかったとき、画面にゲームが映っていても「モデルの評価中です」と説明できるのは、何かと便利でした。

このゲーム制作は、コードレビューで際立っていた能力を、創作の場で探る機会になりました。Astraには、一つひとつの変更がシステムのほかの部分にどう影響するかを考え抜くことが求められました。

次に期待する進歩

次に期待したいのは、この深さの推論を、もっと頻繁に使えるほど確かなものにする進歩です。難しい仕事での一貫した改善、人が検証できる結論、そして成功した結果を得るための総コストの低下です。

そのためには、必要なコンテキストをより適切に選び、根拠を明確にし、不要な手順を減らすことが求められます。お客様への実際の約束を守りながら高度な機能を使える、プライバシーを保護する導入方法も欠かせません。

Astraの結果は、ファイル横断の推論に期待を持たせてくれます。実用上の機会は、その能力を、より役に立ち、より信頼しやすい仕事へとつなげることです。CodeRabbitで新しいモデルを導入する際と同じく、評価はその判断の一部です。

お客様のデータを守る

CodeRabbitもモデル提供会社も、CodeRabbitのお客様の非公開コードや、非公開コードのレビュー中に収集した個人情報をAIモデルの学習に使用しません。詳しくはプライバシーポリシーをご覧ください。

OpenAIとAnthropicでは、データ保持に関する方針が異なります。

• OpenAI： GPT-6 Astraは、対象となるAPI利用企業のゼロデータ保持（ZDR）に対応しています。OpenAIのAPIデータ管理ドキュメントには、ZDRの対象資格と対応機能が記載されています。Astraの発表、OpenAIのデータ管理。
• Anthropic： Fableは通常、安全性監視のために30日間の保持を必要としますが、Enterprise Frontier Safeguards（EFS）の導入期間中、対象顧客はFable 5と5.1をZDRで利用できます。他の企業に提供する製品でこの選択肢を使う場合は、Anthropicと合意した条件が必要です。EFSは、保持する利用状況データを顧客が管理するインフラ内に置けるよう設計されています。対象モデルのデータ保持方針、Enterprise Frontier Safeguards、対象資格の詳細。

お客様のレビューに使うモデルは、いずれも私たちのデータ保護要件を満たす必要があります。