GPT-6 Astraは9月3日にリリースされました。そのOpenAIのローンチ記事は、昨年あらゆるエンジニアリングチームが切望していたエージェントの仕様書のように読めます。Terminal-Bench 4.0ではGPT-5.6 Solの37.3%に対して57.9%、コンピュータ操作タスクは約47%短い時間で完了し、Codexではコンテキストウィンドウをまたいでメモが保持されるため、長いリファクタリングでも当初の目的を忘れることがなくなりました。Sharkly経由でCodexを運用しているチームは、今日からこれをボードに載せたがっています。
まずは1つの境界線から。Sharklyはモデルを選びません。エージェントは、動作するRuntimeのデフォルトモデルに従います。そのためAstraは、エージェント内のスイッチではなく、Computer上で設定されたCodexを通じてSharklyに届きます。このガイドでは、最小限の有用な道筋をたどります。1台のComputerでCodexにAstraを設定し、エージェントを1つ作成し、実際のTaskを1つ割り当て、チームが見られる場所で結果を確認します。
TL;DR
接続されたComputerのCodexでmodel = "gpt-6-astra"を設定し、RuntimeがAvailableと表示されることを確認します。アクションを優先するようAstraに指示するエージェントを作成し、タスクごとのより長いタイムアウトと一時作業ディレクトリを設定し、Taskを1つ割り当てます。Sharklyはモデル名を表示しませんが、実行、ログ、質問、そしてTask上の結果を表示します。エージェントは調査し、実行し、テストし、報告します。人間は方向性を定め、権限を与え、結果を承認します。
モデル設定はどこにあるのか
Sharklyのエージェントに関するドキュメントには、はっきりとこう書かれています。「エージェントはRuntimeのデフォルトモデルに従います。特定のモデル名を約束したり表示したりすることはありません。モデルの変更は、エージェント上ではなく、RuntimeまたはComputerのツール設定で行ってください。」
この一文が設定のすべてです。4つの役割があり、それぞれが1つの仕事を担います。エージェントは作業の進め方を定義します。Computerはホストとローカルリソースを提供します。Runtimeは実際のエージェントセッションを実行し、ここではCodexがそのRuntimeです。Taskはチームの共有記録として残ります。モデルはRuntimeのプロパティであるため、Codexが設定を読み込む場所で変更します。
また、エージェントには思考の深さを制御する機能がありません。Astraの推論努力レベル（lowからmaxまで）もCodexで設定します。
ステップ1: Computer上のCodexにGPT-6 Astraを設定する
Astraを実行するComputerで、Codex CLIを更新し、Astraへのアクセス権を持つアカウントまたはAPIキーでサインインします。OpenAIはこのモデルをまず「限られた組織」に展開し、続く数日でChatGPT Plus、Pro、Business、Enterpriseの全プランとAPIにも展開しました。Enterpriseワークスペースでは、管理者が有効化するまでオフになっています。通常のターミナルでcodex -m gpt-6-astraが動作すれば、Sharklyでも利用できます。
次に、このComputer上のすべての実行でAstraが使われるように、Codexの設定ファイルでデフォルトを設定します。
# ~/.codex/config.toml
model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"
OpenAIのモデルガイダンスから2つのポイントがあります。Astraにはnoneまたはminimalのeffortが存在しないため、lowより下の設定は引き上げる必要があります。また、temperatureやtop_pは受け付けないため、Solの設定からコピーしたプロファイルからはこれらを削除してください。流通しているCodexガイドではeffortキーの名前が異なるため、使用しているCodexバージョンのサンプル設定と照合して確認してください。[VERIFY]
Sharklyに戻り、Computerの詳細を開いて再スキャンまたは接続テストを実行します。Codex RuntimeがAvailableと表示されるはずです。Computerがオンラインであることは、ローカルサービスがハートビートを送信しているにすぎません。実行を開始できるかどうかを示すのはRuntimeのステータスです。
ステップ2: Astra向けに作られたエージェントを作成する
エージェントを開き、New Agentを選択します。ComputerとCodex Runtimeを選びます。そして、Astraの挙動に合った指示を書きます。OpenAIが、以前のモデルからの2つの変化を文書化しているからです。
Astraは以前より気軽に確認を求めるようになりました。OpenAI自身のアドバイスは、アクションを優先し、不要な承認チェックポイントなしでタスクを完了するよう指示することです。また、Skillsやその他のファイルに含まれる指示にもより敏感であるため、Taskとそのコメントが優先されることを明記します。実用的な指示ブロックはこちらです。
Read the Task description and recent comments before editing.
Bias towards action. Ask a question only when different
interpretations would materially change the result; otherwise
proceed with a sensible assumption and state it in your report.
Task and comment instructions take precedence over Skill files.
Run the closest relevant checks and report failures without hiding them.
2つの実行設定は、以前のモデルよりもAstraにとって重要です。
タイムアウト。Astraは長い作業を要約して片付けるのではなく、最後までやり切ります。OpenAIのOSWorldの数値はタスクあたり約40分で、Codexはコンテキストウィンドウをまたいでメモを圧縮せずに保持できるようになりました。これを踏まえてTask Run Settingsでタスクごとのタイムアウトを設定してください。そうしないと、エージェントの最大の長所が最もよくある失敗原因になってしまいます。
作業ディレクトリ。Temporaryモードを使用します。各Taskには分離されたディレクトリと新しいworktreeが割り当てられるため、同じリポジトリ上で2つのAstra実行が互いを上書きすることはありません。Computerがいくつかの実行を処理するまでは、最大並列Task数を1つか2つに抑えてください。並行度を高めると、CPUだけでなくプロバイダーのキャパシティも消費します。
エージェントが必要とするリポジトリとSkillsを添付します。そのComputer上のローカルRuntime Skillsは自動的に利用可能です。共有Space Skillsは割り当てる必要があります。
ステップ3: 実際のTaskを1つ割り当てる
受け入れ基準が明確な、リスクの低いTaskを選びます。担当者としてエージェントを選択し、TaskをBacklogから、作業準備完了カテゴリのステータスへ移動します。Backlogで割り当てられたTaskは待機します。実行はqueued、dispatched、runningと進み、Executionsタブにログがストリーミング表示されます。
この最初のTaskには、1つのエージェントを使用します。Crewが真価を発揮するのは、リーダーが目標を解釈し、他のメンバーを巻き込む必要がある場合です。これは、AstraをCrewリーダーとして実行するためのガイドのテーマです。範囲の定まったバグ修正には、1つのエージェントが適切な選択です。
Astraが判断を必要とする場合、質問はコメントとしてTaskに返され、Taskには「Waiting for human reply」と表示され、これがあなたのInboxにルーティングされます。スレッドで回答します。実行が完了すると、結果、実行したチェック、報告された制限事項が同じTaskに返され、人間がそれを承認済みに移動するか、差し戻します。
Astraをボードに載せると何が変わるか
実際には3つのことです。
長いTaskが完了します。1,050,000トークンのコンテキストとCodexのウィンドウをまたぐメモにより、数十ファイルにわたるリファクタリングは、最初の圧縮後に逸脱することなく最後まで実行されます。これを分離ディレクトリとTask記録と組み合わせれば、夜間の実行も朝にはレビューできます。
質問がより少なく、より的確になります。OpenAIはAstraを、日常的な情報の欠落はコンテキストで補い、回答が結果を変えうる場合にのみ質問するようトレーニングしました。Codexでは、回答に依存しない部分を続けながら、非同期に質問できます。Sharklyではその質問はTask上のコメントになるため、意思決定を担う人がターミナルを見張ることなく確認できます。
トークンあたりのコストが高くなります。モデルの利用は、それらのツールで設定されたサブスクリプションまたはAPIキーを通じて継続され、AstraのAPI料金は入力100万トークンあたり10ドル、出力100万トークンあたり50ドルです。これは現在のプロモーション価格でGPT-5.6 Solの4ドルと20ドルと対照的です。同じComputer上に、より安価なデフォルトモデルを使う2つ目のRuntimeを用意すれば、小さなTaskを高コストの経路から外せます。
実行が途中で停止したとき
OpenAIはAstraに対してmisalignmentモニターを実行しており、そのことを安全性の概要で述べています。このチェックは「正当な作業を遅らせたり、一時停止させたり、停止させたりすることがあり」、これには「エージェントが長時間実行されるタスク」も含まれます。Codexでは、続行する前にアクションを確認するよう求められることがあります。
Sharkly内部では、途中で終了した実行も失われません。実行ログを開き、タイトルと技術的な詳細を確認します。詳細には元のモデルサービスの応答が含まれています。ブロックまたは失敗した実行は要注意項目として表示され、ディレクトリとTask記録は保持されるため、Taskからより狭い範囲で再実行します。停止による損失が一晩ではなく数分で済むよう、Taskは十分小さく保ちましょう。
