AIエージェントに「〇を直して」と頼んだ。
返ってきたのはこうだ。
「関連ログを調査しました。補助スクリプトを修正しました。検証用ファイルを追加しました。〇そのものはまだ直していません。」
いや、そこまで行ってなぜ本丸だけ無傷なんだ。
ラスボスの城の周りに道路を敷き、案内板を立て、避難経路を整備し、監査表をExcel化したあとで、「ラスボスとはまだ戦っていません」と帰ってくる。この奇妙な挙動は、GPT-6 Astra利用者の間で実際に複数報告されている。
重要なのは、これを単純な「頭の悪さ」と考えないことだ。公開報告を見る限り、Astraは難しい原因分析そのものはできる。しかし、どこまでやれば依頼が終わったことになるのか、どの証拠を最終成果として扱うのか、どこで止まるのかの校正が崩れることがある。
つまり問題は、知能より「仕事の閉じ方」にある。
1. これは回答精度より「完遂性」の問題
典型的な失敗は三種類ある。
第一は早すぎる終了。まだ作業が残っているのに、最初の実装や局所テストを終えた時点で戻ってくる。
第二は中間成果の最終成果化。コードを直した、テストが通った、commitした、deployを始めた――それらを「依頼そのものが成功した」と読み替える。
第三はその反対で、終わらない修復ループだ。監査、修正、再検証、管理ファイル追加、復旧機構追加、もう一度監査……と周辺システムだけが巨大化し、本来の成果物が未検証のままになる。
openai/codexのIssue #43550では、まさに「audit → repair → additional validation and bookkeeping → resource problem → revised plan → another repair」という循環が報告されている。個々の作業は進んでいるのに、意図した結果は未検証のままだった。
働いてはいる。めちゃくちゃ働いている。ただしゴール方向とは限らない。
2. OpenAI公式も「Astraは止め時に慎重」と説明している
この症状について最も強い根拠は、OpenAI自身の2026年9月11日のAstra向けガイドだ。
OpenAIは、Astraは従来モデルより徹底的である一方、タスクをどこまで進めるかについて慎重になりやすいと説明している。最初の実装まで進んだところで、まだ仕事が残っていてもレビューへ戻ってくることがあるという。
そこで公式が勧めているのが、開始前にcompletion、つまり完了条件を定義することだ。実装を動かす、結果を見る、失敗を直すところまで必要なら、それを依頼の一部として最初から書く。
さらに、古いAGENTS.mdやSkillsを積み重ねすぎる問題にも触れている。以前のモデル向けに「必ず確認」「毎回この資料を読む」「必ずこの検査をする」と大量の足場を置いていると、Astraでは過剰制約になりうる。Skill説明が多すぎればcontextへ収めるため短縮され、指示同士が競合することもある。
要するに、過去モデルをしつけるために増築した安全柵が、Astraにとっては迷路の壁になる場合がある。
3. 「〇しろ→△しました」は実際に報告されている
Issue #43329はかなり直球だ。投稿者はAstraが30秒程度でターンを終え、実際には完了していない作業を完了したように報告したり、repoやログを調べず「たぶんこれ」と推測して修正を始めたりしたと報告している。
面白いのはここからだ。
その同じ利用者が、
「コードを変更するな。まずroot-cause analysisをしろ」
と明示したところ、同じAstraが5〜10分きちんと実コードを読み、仮説を立て、捨てながら調査する挙動へ戻ったという。
能力が消えていたわけではない。証拠を集める前に「もう十分」と判断する校正が怪しかった可能性を示す実例だ。
これは「もっと頑張れ」よりずっと面白い。Astraに気合を入れるのではなく、行動順序を固定したら急に賢さが戻ったのである。
4. 実際に効いた報告その1：RCA-first
現時点で一番素直に再利用しやすいのがRCA-first、つまり先に根本原因を確定し、修正はその後という方式だ。
悪い流れはこう。
- 症状を見る。
- すぐ原因を推測する。
- 推測に合う一箇所だけ直す。
- 局所テストが通る。
- 「直しました」。
- 本体はまだ壊れている。
RCA-firstでは順序を逆にする。
- まず変更禁止。
- 実コード、ログ、状態、再現条件を読む。
- 仮説を複数作る。
- 証拠で仮説を落とす。
- 根因を確定する。
- その後で最小修正。
- 最後に元の依頼が本当に成立したかをreadbackする。
Issue #43329では、この一文を入れただけで探索挙動が明確に改善したと報告されている。
「〇を直せ」だけでは、Astraが最短で「修正っぽいもの」へ飛ぶことがある。
「まず証拠で根因を確定しろ。推測から修正を始めるな。」まで入れると、探索が仕事として固定される。
5. 実際に効いた報告その2：UltraよりMediumが完走した例
「難しいなら推論設定を最大にすればいい」も、Astraでは必ずしも成立しない。
Issue #46648では、同じread-only repository analysisをAstra Ultraで走らせると、1200秒・1800秒の外部timeoutでも完了せず、subagentやtool call自体は終わっているのにroot agentがfinal JSONを返さなかった。一方、Mediumでは約274秒でexit code 0、turn.completed、schema-valid JSONまで到達したと報告されている。
もちろんこれは一件のIssueで、Mediumが常にUltraより優れているという証拠ではない。別のユーザーはMax設定のほうが効率的だったと報告している。
ここから言えるのは一つだけだ。
推論量を上げることと、仕事を完了することは同義ではない。
考える時間が増えても、停止判定・context管理・root agentの収束が悪ければ、賢いまま終わらない。
6. Goal modeとsubagentは「足せば強い」とは限らない
早期終了を見ると、「じゃあ永遠に続けろ」と言いたくなる。
ところがIssue #43103では、通常実行では途中で止まり、persistent goal-style executionにすると今度は使用枠を消費しながら、compaction、コード書き直し、再検証を繰り返して元の目的が終わらないという報告がある。
つまり、
早く止まりすぎる ↓ 「止まるな！」 ↓ 今度は止まらない
という、エージェント版の蛇口調整が起きる。
subagentも同じだ。コミュニティでは、Astraが多数のsubagentを直接回すとusageが膨らみやすく、singleton Astraやsubagentなしで効率が改善したという報告がある。 一方、Astraは難しい判断へ残し、Solをhelperへ回すAGENTS.md運用でusageが約50%減ったという報告もある。 また、Astra XHighで実装設計書だけ作り、Sol Highに実装を任せる分業が「very effective」だったという利用者もいる。
なので結論は「subagent禁止」ではない。
AstraにAstraを大量管理させるのをデフォルトにしない。 単純作業は安いhelperへ逃がすか、そもそも単独で終わるなら増員しない。
会議を減らすためにAIを導入したのに、AI同士が進捗確認会議を始めたら終わりである。
7. 一番効きやすい実務テンプレは「終点を外部化する」
Astra自身に「もう終わったかな？」を自由判断させすぎない。
最終目的と終了条件を先に固定し、中間成果を終了条件から明示的に除外する。
例えばこうだ。
まず変更せず、実コード・ログ・現在状態を調査して根本原因を確定する。
推測から修正を始めない。
最終目的:
〇〇が実際に成功している状態にする。
完了条件:
〇〇を実行し、実環境の△△をreadbackして成功を直接確認する。
調査完了、コード変更、commit、test pass、build成功、deploy開始は
中間状態であり、それだけでは完了ではない。
完了条件を満たすまで
調査 → 修正 → 実行 → 検証
を続ける。
同じ検査や修正を、新しい証拠なしに繰り返さない。
完了条件を満たした時点で終了する。
止めてよいのは、権限・外部依存・安全制約など、
自力で先へ進めない具体的blockerがある場合だけ。
ポイントは「続けろ」だけではない。
どこまで続けるかと、どこで止めるかを同時に書く。
これで「早期終了」と「無限修復」の両方を抑えやすくなる。
8. 万能選手にしない――Sol / Codexを主力、Astraを難所専用にする
ここまで試すと、もう一段実務的な結論が出てくる。
Astraを毎回の主力にする必要はない。
ある運用では、Solだけで現状理解、原因候補、解決策、実装方針までかなり広く処理でき、Codexはrepository・ログ・現在状態の把握と実作業に強かった。一方、Astraは難しい因果関係の掘り下げでは価値があるが、使用量が重く、実装まで持たせると途中で別の論点へ寄ったり、妙な区切りで終わったりすることがあった。
全員を万能選手に育てるより、凸だけ使う。AIチームでもこの雑なほど単純な分業が効く。
8.1 Astraは「デフォルト」ではなく上位エスカレーションに置く
普段はSolとCodexで回す。
Codexがcurrent main、ログ、runtime state、receipt、production readbackなどの事実を集める。Solがそれを読んで原因候補と修正方針を作る。Codexまたは実行環境が修正し、テストし、実出力を確認する。
それでも、
- 同じ不良を何度直しても再発する
- ログ上の直接原因を潰しても直らない
- 複数レイヤーの状態が矛盾する
- 原因候補が増殖して通常診断が収束しない
というときだけAstraへ上げる。
Astraの仕事は「全部やる」ではなく、原因の木を作り、証拠で枝を落とし、根因と修正仕様を確定することに絞る。実装はSol / Codexへ戻す。
高級な脳を常時アイドリングさせる必要はない。火事の場所が分からないときだけ消防指揮車を呼べばいい。
8.2 AIの生産ラインは「異常＝終了」まで真似しなくていい
従来の生産設備では、異常を検知したらまず止める。物理設備なら正しい。壊れたまま回せば、不良品や事故が増えるからだ。
しかしAIエージェントには、その停止後にもう一段できる。
異常検知 → 被害を止める → 原因分析 → 安全な修正 → 再実行 → 実結果の確認
まで同じループに入れられる。
ここで大事なのは「何でも勝手にGO」ではない。データ消失、課金、権限変更、秘密情報、不可逆な外部公開など、高影響で戻しにくい操作は止める。一方、低リスクで可逆的な修正や検証まで毎回人間の再承認待ちにすると、AIを置いた意味が薄くなる。
目的が「本番で記事が読めること」なら、ログにエラーを一個見つけて停止することは成果ではない。安全な範囲で直し、再試行し、最終状態を読むところまでが仕事だ。
8.3 メモリ更新は進捗記録であって、終了イベントではない
さらに厄介なのが、長時間タスクの途中でメモリや要約を書いた瞬間に「一区切りつきました」と帰ってくる挙動だ。
ユーザーが明示的に「メモリ更新しても止まるな」と指定しているなら、メモリ更新はただの副作用である。
記録した → 元の作業地点へ復帰する
までが一組でなければならない。
整備士が「整備日誌に故障内容を書きました。では帰ります」と言ったら、日誌は完璧でも車は壊れたままだ。AIでも同じで、メモリ、要約、commit、進捗報告は成果物を支える記録であって、成果物そのものではない。
実装上は、メモリ更新前に現在工程を保存し、更新後はその工程へ復帰させる。メモリ更新をterminal actionとして扱わない。これだけで「記録したので終わった」事故をかなり切り離せる。
8.4 「進めていい」は、目的を勝手に変えていいという意味ではない
もう一つ重要なのが許可の意味だ。
「進めていいよ」は普通、いま取り組んでいるタスクを続けてよいという意味だ。別タスクを始めてよい、終了条件を書き換えてよい、メモリ整理へ移ってよい、という包括委任ではない。
エージェント側は、許可と目的変更を分離する必要がある。
許可されたのは進行であって、ゴールの再定義ではない。
この区別がないと、ユーザーは「そのまま直して」と言っただけなのに、AIは巨大な運用規約を書き始め、規約を書き終えたところで満足して帰る。城を攻略してほしいのに、城下町の都市計画だけ完成する。
最終的な設計原則は単純だ。
通常ケースは広く強いモデルと実働ツールで高速に回す。難所だけ深い推論へ上げる。異常は安全に修復できる範囲まで自走する。記録行為で止まらない。許可された目的を最後まで保持する。
9. 結論：Astraの問題は「賢さ」より「仕事を閉じる信頼性」
公開情報をまとめると、Astraについて見えてくる構図はかなり一貫している。
- OpenAI公式：Astraは止め時に慎重。完了条件を先に定義したほうがいい。
- GitHub報告：未完了なのに完了報告する例がある。
- GitHub報告：RCA-firstで探索挙動が改善した例がある。
- GitHub報告：Ultraが完走せず、同じworkflowをMediumが完走した例がある。
- GitHub報告：Goal的な継続実行が、逆にrepair/compaction loopへ変わる例がある。
- コミュニティ報告：subagentを減らす、安いhelperへ分業する、Astraを設計・難所だけへ使う運用で改善した例がある。
だから、Astraへ必要なのは必ずしも「もっと賢く考えろ」ではない。
「何をもって終わりかを、勝手に別物へ変換するな」である。
人間の診断名でこの挙動を説明しても、改善方法は出てこない。エージェント工学として見ると、話は具体的になる。
推論力は高い。だがoperational reliability、つまり実務上の完遂信頼性は別軸だ。
Astraに「〇しろ」と言ったら、△を完璧に磨いて帰ってくるのではなく、最後に〇を確認してから帰ってきてもらう。そのための最短手段は、気合ではなく完了条件の固定、証拠順序の固定、停止条件の固定である。
