SharklyでGPT-6.1 Solエージェントを実行する方法

OpenAIは9月29日のDevDayでGPT-6.1 Solをリリースしました。定価はGPT-6 Solと同じく入力100万トークンあたり2ドル、出力100万トークンあたり10ドルですが、キャッシュされた入力は半額の0.10ドルに引き下げられています。しかし、複数のCodexエージェントを運用しているチームにとって最も重要なのは、より目立たない点にあります。Codex CLIドキュメントの起動画面には、現在gpt-6.1-sol mediumと表示されています。モデルを固定（ピン留め）していないComputerでは、チームが決定したタイミングではなく、誰かがそのComputer上のCodexをアップデートした時点で、エージェントが使用するモデルが自動的に切り替わってしまいます。

Sharkly上ではこの変化が表示されません。AgentはRuntimeのデフォルトモデルに従い、モデル名を表示しないため、今週以降、まったく同じ指示を与えた2つのAgentが2台のComputer上でそれぞれ異なるモデルを実行していても、ボード上では同じTaskに見えてしまう可能性があります。どのエージェントがどのモデルで動作し、どの成果物がどちらによるものかを、記憶だけに頼って把握しなければならなくなります。本ガイドでは、前回のGPT-6 Solガイドからの差分のみを解説します。新しいデフォルトがどこから適用されるのか、いつ固定すべきか、変更された2つの設定項目、そして中間モデルが最上位モデルに迫る性能を持つようになった今、Crewがどのように作業をルーティングすべきかについて説明します。

TL;DR

GPT-6.1 SolはComputer上のCodex Runtime経由でSharklyに反映されますが、Sharkly側では何も変わりません。各Computerで実行されているCodexのビルドと、~/.codex/config.tomlでモデルが固定されているかを確認してください。固定されていないComputerはCLIのデフォルトに従い、ドキュメントの記載通りmediumエフォートのgpt-6.1-solになります。前回のガイドに従ってセットアップしたComputerは、設定ファイルの1行を書き換えるまでgpt-6-solのまま維持されます。推論エフォートにnoneを指定している場合はlowに変更してください。また、キャッシュの半額化はプランログインではなくAPIキーを使用するComputerに反映される点に注意し、後述のルーティング表は確定事項ではなく、ご自身のTaskで検証するための目安としてご活用ください。

Codex Runtimeの内部で何が変わったのか

Agentのドキュメントには、この記事がAgentではなくComputerに焦点を当てている理由が次のように説明されています。「AgentはRuntimeのデフォルトモデルに従います。特定のモデル名を保証または表示することはありません。モデルの変更はAgent上ではなく、RuntimeまたはComputerツールの設定で行ってください。」今回のアップグレードはRuntime側の事象です。Crewが影響を受ける差分は以下の通りです。

アップデートされたCodex CLIには、音声入力、/agentsビュー、プロンプト編集、再開（resume）機能、そしてすべてのプランでのworktree対応も追加されました。ターミナルから手動でCodexを操作する際には、ぜひ活用したい機能です。しかし、作業がチーム全体のものになると、Taskが共有レコードとなります。Temporaryモードでは、Sharklyは各Taskに専用のディレクトリを割り当て、リポジトリ作業用にはクリーンなworktreeを用意できます。また、実行ステータス、ログ、質問、実行結果がTaskに集約されるため、次の担当者が迷わず引き継ぐことができます。

モデルを固定するか、Computerごとにデフォルトに従わせるか

まずは現状のインベントリ（一覧）を確認することから始めましょう。対応はComputerごとに異なる可能性があるためです。sharkly computer listを実行すると組織に登録されているComputerが一覧表示され、sharkly computer show <computer-id>で特定のComputerと関連付けられたRuntimeを確認できます。Computer本体でcodexを起動すると、ビルドとモデルが表示されます。Codex変更履歴によると、バージョン0.159.1（9月29日リリース）でGPT-6.1 Solがデフォルトになり、公式ドキュメントのサンプルセッションにもmodel: gpt-6.1-sol mediumと記載されています。

確認すべき点は2つあります。1つ目は、どのバイナリが実行されているかです。macOSでは、スタンドアロンのCodexをインストールしていないComputerの場合、ChatGPTデスクトップアプリに同梱されているCodex CLIがRuntimeとして登録されることがあります。しかしSharklyのドキュメントでは、個別にインストールしてPATHを通したCodexを使用することを推奨しています。2つ目は、どの設定レイヤーでモデルが指定されているかです。Codex設定の基本では、個人のデフォルト設定は~/.codex/config.tomlに記述し、リポジトリ独自の.codex/config.toml（信頼されたプロジェクトでのみ読み込み）で上書きでき、さらにコマンドラインの-mまたは--modelオプションがその両方より優先されます。

判断の基準は次の2通りです。1人で専有し、週に数件のTaskしか実行せず、設定ファイルを保守するよりもOpenAIの推奨モデルに追従したいComputerであれば、デフォルトのまま任せても問題ありません。一方、複数人がそのComputer上のAgentに作業を割り当てる場合や、Crewが複数のComputerにまたがる場合、あるいはスプリントの最中である場合は、モデルを固定すべきです。気づかないうちにモデルが変わってしまうと、火曜日の成果と木曜日の成果の前提が異なっているにもかかわらず、Task上では同じように見えてしまうためです。

モデルを固定するには、Codex Runtimeを実行しているComputer上のユーザー設定を編集します。

# ~/.codex/config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

どちらのキーもCodexの設定ドキュメントにこれらの値で記載されています。当社のGPT-6 Solガイドに沿って設定済みであれば、該当ファイルにはすでにmodel = "gpt-6-sol"と記述されているため、アップデートしてもそのComputerのモデルは勝手に変わりません。移行の準備が整うまでは、その行を変更しないでください。

Codexをアップデートするには、ドキュメントに記載されている新規インストールと更新兼用のインストーラーを実行するか、Sharkly CLIから特定のRuntimeに対するCLIアップデートを要求します。

curl -fsSL https://chatgpt.com/codex/install.sh | sh
# or, from anywhere with the Sharkly CLI:
sharkly computer update <computer-id> <runtime-id>

その後、Computer詳細画面で再スキャンまたは接続テストを実行し、Codex Runtimeが「Available（利用可能）」になっていることを確認してください。最後に、固定したモデル名をAgentの説明欄に記載しておきましょう。差分をレビューする人が、どのモデルがコードを書いたかを確かめるためだけにComputerでシェルを開くような事態は避けるべきです。

変更された2つの設定：推論エフォートとキャッシュ

noneは廃止されました。GPT-6.1 Solが受け付けるのはlow、medium、high、xhigh、maxであり、noneやminimalには対応していません。GPT-6 Solで高速処理用の「ファストレーン」として当然の選択肢だったnoneを設定しているComputerは、移行前にlowへ変更する必要があり、生成結果も再確認する価値があります。lowでも推論処理が行われるためです。古い設定のままで実行が失敗した場合でも、実行ログにはタイトルとモデルサービスからの元のレスポンスが保持されます。サポートされていないオプションに対するSharklyのトラブルシューティング方針は、やみくもに再試行するのではなく、モデルとリクエストのオプションを確認することです。

目立たないながらも大きなメリットとなるのがキャッシュです。OpenAIはキャッシュされた入力の価格を100万トークンあたり0.10ドルに設定しており、これは「標準の入力価格より95%安く、GPT-6 Solのキャッシュ入力価格よりも50%安い」価格です。この恩恵が最も現れるのは、長時間稼働するAgentです。1つのリポジトリで1時間作業を続ける実行では同じコンテキストの大部分が繰り返し送信され、同じリポジトリ構成、ルール、テストコマンドから作業を開始するCrewメンバーは、1日を通じて同一のプレフィックスを再利用することになります。

誇張を避けるため、3つの注意点も挙げておきます。まず、トークン単位のコスト削減効果が現れるのは、CodexがAPIキーで課金されているComputerのみです。ChatGPTプランでサインインしているComputerでは代わりにプランの使用枠が消費されます（これについては姉妹記事であるAPIキーなしでのGPT-6.1 Solの運用で解説しています）。次に、定価自体は変わっていないため、キャッシュされない処理のコストは先週と変わりません。そして最後に、長いコンテキストには追加料金（サーチャージ）が発生します。OpenAIは入力トークン数が272Kを超えるプロンプトに対して、入力およびキャッシュ料金を2倍、リクエスト全体の出力料金を1.5倍に設定しています。そのため、ターンごとに巨大なコンテキストを引きずるAgentに対しては、予算を増やす前に、コンテキストのプレフィックスを小さく安定させる工夫をすべきです。

Crewのルーティング戦略：Astra、6.1 Sol、Luna、またはClaude Runtimeの使い分け

OpenAIが掲げる6.1 Solの強みは、コストを大幅に抑えながらAstraに迫るパフォーマンスを発揮する点であり、その根拠となる数値はすべてOpenAI自身のベンチマーク実行に基づいています。DeepSWE v1.1において、OpenAIは6.1 Solがおよそ5分の1のコストでAstraに匹敵し、より低いエフォート設定でもGPT-6 Solの最高スコアを6.4ポイント上回ったとしています。コンピューター操作ベンチマークであるOSWorld 2.0では、maxエフォート時にAstraとわずか2.1ポイント差にとどまり、タスクあたりのコストは約7分の1に抑えられています。同時にOpenAIは限界についても明確に述べており、Terminal-Bench Scienceでは依然としてAstraが最高の68.1%を記録しているため、最も難易度の高い科学系タスクにはAstraを使用するよう推奨しています。

OpenAIのモデル選定ガイドでも同様の分類がなされています。曖昧な課題にはAstra、時間とコストが重視される複雑なタスクには6.1 Sol、スコープが明確なタスクやトリアージにはLunaを割り当てており、この指針自体もあくまで出発点として位置付けられています。モデルの設定はRuntime側に存在するため、Sharklyにおけるルーティングルールとは実質的にComputerに関するルールを意味します。つまり、CodexのデフォルトがAstraに設定されているComputerにバインドされたAgentは、Astraを実行します。テスト運用の目安となる初期ルールは以下の通りです。

最後の行はベンチマークの主張ではなく、特定ベンダーに依存しない方針を明文化したものです。Claude Sonnet 5.5は6.1 Solの前日に同じく2ドル／10ドルでリリースされましたが、OpenAIの発表記事では6.1 SolをOpus 5.5やFable 5.1と比較しているものの、Sonnet 5.5との直接比較は行っていません。いずれのベンダーもその直接対決の結果を公開していないため、真に意味のある比較はご自身のTaskで実際に検証したものだけです。手動エスカレーション経路を組み込んだ明文化ルールの詳細については、Crewのためのモデルルーティングを参照してください。

とはいえ、作業プロセスの最終着地点が変わるわけではありません。Astraに迫る結果がより低コストで得られるということは、1日に完了する実行数が増えることを意味しますが、そのすべては最終的に差分を確認する「人間」の手に行き着きます。Agentが調査、実行、テスト、レポートを行い、人間が方針を定め、権限を付与し、結果を承認します。今週取り組むべき実用的な作業は、どのComputerがどのモデルを実行したのか、何が完了し、何が古いエフォート設定で失敗し、何がレビュー待ちなのかを、カンバンボード上で正確に把握できるようにすることです。いまだに複数のCodexターミナルを手動で切り替えながら操作している場合は、まずは複数のCodexエージェントを見失わずに管理する方法で手動運用の手順をご確認ください。

この運用はworktreeを使って手動で構築することもできますし、Sharklyを使ってワークフロー全体を管理することも可能です。