AIエージェントに毎回「続けて」と打たなくてよくする方法

Codex や Claude Code を使っていると、能力不足ではなく、妙に行儀よく止まることがあります。進捗報告はきれいなのに、こちらが毎回 続けて と打たないと先に進まない、という状態です。

今回、自分の過去セッションログを実際に集計して、この問題を運用側から直しました。結論から言うと、原因の多くは AI が詰まっていること ではなく、きれいな報告のたびに止まる stop policy にありました。

結論: 問題は「能力」より「止まり方」にある

ログを見て分かったのは、続けて が必要になる場面の多くが、実ブロックではなく final_answer の直後だったことです。

つまり、AI エージェントは考えられないから止まっていたのではなく、報告としては区切りが良いが、作業としてはまだ続けられる地点 で止まりすぎていました。

この問題に対して効いたのは、モデルを変えることより、次の 2 つです。

過去ログを見て、どこで止まっているかを数で把握する
report and continue を既定にする repo-local ルールを入れる

最初にやったこと: 「続けて」がどこで発生しているかを集計した

最初にやったのは感覚論ではなく、過去セッションログの集計です。自分の環境では Codex の JSONL ログが残っていたので、ユーザー入力が完全一致で 続けて の行だけを抽出しました。

その結果はかなりはっきりしていました。

完全一致の 続けて は 345 回あった
そのうち 341 回は assistant の final_answer の直後だった
承認待ちや本当の判断待ちより、進捗の良い区切りで止まるパターンが圧倒的に多かった

ここで重要なのは、「ユーザーが曖昧だから止まっている」のではなかった という点です。多くは「もう 1 ステップ進めるのに、礼儀正しく止まっていた」だけでした。

ログを見る前の仮説は、だいたい外れる

この手の問題は、つい「もっと強いモデルにすればよい」「プロンプトが甘い」と考えがちです。ただ実際には、それだけでは解決しないことがあります。

今回のケースでは、止まる理由は次のように分かれていました。

止まり方	意味	対応
`final_answer` 直後	区切りが良いだけで、実作業はまだ続けられる	自動継続に寄せる
承認待ち	外部副作用や権限昇格がある	止まるべき
選択肢提示	複数案に明確なトレードオフがある	止まるべき
破壊的変更前	失敗時のコストが高い	止まるべき
closeout 前	終了処理や知見保存に入る	止まるべき

つまり、止まり方を全部消すのではなく、止まるべき所だけ止める のが正解でした。

改善したルール: 「report and continue」を既定にする

方針としては単純です。次の一手が 1 つで、低リスクで、承認も追加選択も不要なら、短く進捗を共有してそのまま続けるようにしました。

逆に、止まる条件は明文化しました。

承認が必要
複数案に明確なトレードオフがある
破壊的変更がある
投稿、送信、本番反映などの外部副作用がある
/end のような締め処理に入る

ここを曖昧にしたままだと、毎回「ここで止めるのが安全なのか」「止めない方が自然なのか」がぶれます。repo-local に書いてしまう方が速いです。

実際に入れたもの

今回は、単に口約束にせず、運用ファイル側まで反映しました。

ログ集計用の analyze_continue_logs.py を追加
AGENTS.md に stop / continue の条件を追記
codex-operator-guide.md に 「続けて」を待たない ルールを追加
session-autocontinue という skill を追加
README、handoff、learned lessons にも残して次回以降に効くようにした

ポイントは、その場の prompt だけで直さないこと です。README、AGENTS、handoff、lessons にまで落としておくと、次のセッションでも再発しにくくなります。

skill 化すると何がいいのか

今回追加した session-autocontinue は大きい仕組みではありません。ただ、続けて、keep going、stop only when blocked を 1 つの再利用可能なフローにまとめられます。

この形にしておくと、毎回長く指示しなくても、次のような一文でかなり自然に動きます。

前回の続き。止まる理由が出るまでそのまま進めて。

逆に、これを skill 化していないと、エージェントは毎回その場で空気を読み直す必要があり、結果として行儀よく止まりやすくなります。

このやり方が向いているケース

AI エージェントを日常的に使っている
毎回 続けて と打つのが面倒になっている
repo-local の運用ファイルを持っている
会話ログや handoff を残す運用がある

逆に、単発の相談だけならここまでやる必要はありません。継続運用の文脈がある時に効きます。

注意点

自動継続を強くしすぎると危ない のも事実です。外部副作用や破壊的変更まで無条件で突っ込ませるのは違います。

自分が残したルールは、あくまで「低リスクで明確な次の一手までは進める」です。ここを越えるところは、むしろ強く止めた方がよいです。

つまり目指すべき状態は、どこまでも自律すること ではなく、止まらなくてよい所では止まらず、止まるべき所だけ止まること です。

まとめ

AI エージェントが毎回止まる問題は、モデルの能力より、運用側の stop policy が原因になっていることがあります。今回のように、過去ログを見て 続けて の発生地点を集計すると、かなり具体的に直せます。

効いたのは、強いモデルへの乗り換えより、report and continue の既定化と、止まる条件の明文化でした。継続運用するなら、この手の改善は prompt より repo-local policy に落とした方が強いです。

次にやるなら

同じ問題があるなら、まずは自分のセッションログで 続けて や keep going がどこで出ているかを見てください。その上で、README、AGENTS、handoff、lessons のどこに stop policy を書くか決めるのが自然です。

AI エージェントの運用をもっと詰めたいなら、次は closeout と knowledge retention を分ける設計も一緒に見るとつながりやすいです。

AI を実務の運用フローにどう組み込むかは、Codex と wp-cli でブログ運用を自動化する考え方が近いです。どの AI ツールに課金するかを整理したいなら、エンジニア向け AI ツール比較もつながります。運用全体でどこにお金をかけるかを見直したいなら、ブログ運用を効率化する有料ツールまとめも合わせて読むと流れが見えやすいです。

AIエージェントに毎回『続けて』と打たなくてよくする方法