コーディングエージェントGooseが、実行ループを「巻き戻せるステートマシン」に作り替えている（実験段階）

3行まとめ

• Block社発のオープンソースAIエージェント「Goose」がv1.46.0（2026年8月12日公開）で、実行ループをコルーチンからPR #9574「再入可能なステートマシン」に作り替えた。まだGOOSE_STATE_MACHINEフラグの裏にある実験的実装
• PR #9574は2026年8月6日にマージキュー経由でマージ。自動レビューbot（Codex）が少なくとも5件の具体的な不整合（バグ）を指摘し、いずれも追加コミットで修正されている
• PR本文の説明によれば、この作り替えは副産物として既存バグも修正しており、たとえば「プロアクティブな要約（compaction）が実は一度も発火していなかった」問題が新実装で直った、と明記されている

Block社（旧Square）が開発するオープンソースのAIコーディングエージェント「Goose」のv1.46.0（2026年8月12日公開）のリリースノートには、「Unrolled agent loop」という項目が1行だけ挙げられている。それ以上の説明は本文には無く、名前だけが先に公開された形だ。だが実装したマージ済みPR #9574の本文を読むと、内部アーキテクチャのかなり大きな作り替えだと分かった。

コルーチンの状態を持たない「再入可能なステートマシン」

PR本文の説明はこうだ。

Unrolls the agent loop into a re-entrant state machine. Each call runs from the persisted conversation to the next applied step or client yield; no coroutine state is held between steps.

The new path remains behind GOOSE_STATE_MACHINE while it establishes parity with the legacy reply loop.

（エージェントループを再入可能なステートマシンへと「巻き戻す（unroll）」。各呼び出しは、永続化された会話から、次に適用されるステップまたはクライアントへのyieldまでを実行する。ステップとステップの間でコルーチンの状態は一切保持されない。この新しい経路は、従来の応答ループとの動作の一致を確立するまでの間、GOOSE_STATE_MACHINEというフラグの裏に留め置かれる）

従来の実装がおそらく「関数呼び出しの途中経過をメモリ上のコルーチンとして保持し続ける」設計だったのに対し、新しい実装は「永続化された会話そのものが実行状態」という前提に切り替えている。呼び出しのたびに会話の続きから次の一歩を計算するだけなので、プロセスが落ちても、永続化された会話さえ残っていれば同じ場所から再開できる、という設計に読める。

「Operation」という共通の単位でパイプラインを組む

PR本文の「Design」欄には、この設計の骨格がもう少し詳しく書かれている。

• StateMachine::step evaluates ordered steps until one returns Applied; NotApplicable passes control onward.
• StepResult contains explicit effects. StateMachine::apply persists them through SessionManager, while StateMachine::run is the convenience method that drives both until a yield.
• Operation is the common protocol for commands, tools, context management, hooks, and inference. Operations can also contribute tools, prompt parts, and MOIM parts to inference.
• The conversation is execution state. Operation notes are stored on messages under the operation name, so a pipeline can be discarded and rebuilt after any applied step.

（StateMachine::stepは、いずれかがAppliedを返すまで順序付けられたステップを評価する。NotApplicableは制御を次へ渡す。StepResultは明示的な効果を含む。StateMachine::applyはそれをSessionManagerを通じて永続化し、StateMachine::runは両方をyieldまで実行し続ける便利メソッドだ。Operationは、コマンド・ツール・コンテキスト管理・フック・推論に共通するプロトコルである。Operationは推論に対して、ツール・プロンプトの断片・MOIMの断片を提供することもできる。会話そのものが実行状態であり、Operationのメモはメッセージ上にOperation名で保存されるため、パイプラインはどの適用済みステップの後でも破棄して作り直すことができる）

コマンド実行・ツール呼び出し・コンテキスト管理・フック・推論といった異なる種類の処理を、すべて「Operation」という共通のインターフェースで扱う設計だ。Gooseは標準のパイプラインをAgent::replyと並べて構築しており、呼び出し側はAgentに依存しない別の順序のステップ集合を組み立てることもできる、とも書かれている。

テストで「本当に永続化状態から動いているか」を確認している

PR本文のテスト欄には、興味深い検証方法が書かれている。

Reconstruction tests discard and rebuild the pipeline after each applied step, proving that progress comes from persisted state rather than operation instances.

（再構築テストは、各適用済みステップの後にパイプラインを破棄して作り直し、進捗がOperationのインスタンスではなく永続化された状態から来ていることを証明する）

パイプラインのオブジェクト自体を毎回作り直しても同じ場所から再開できることを、意図的にテストで確認している。この設計思想（実行状態＝永続化された会話）が実際に守られているかを、テストという形で担保しようとしている、と読み取れる。

副産物として直った既存バグもある

PR本文の「What changed」欄には、単なる作り替えではなく、旧ループが抱えていた具体的な不具合が新設計で解消された、という記述もある。

The compaction op records its summarization usage with the compaction flag, which resets the session total to the summary size; the machine no longer clears totals on ReplaceConversation. This is what makes proactive compaction actually fire: the total was previously never written, so the threshold check could never trigger outside tests.

Stale orphaned tool requests. A crash mid-execution leaves an unanswered request in the conversation; it used to be silently re-executed on the next user prompt (unannotated requests default to executable). Approval and execution now only consider requests from the current request [...]

（要約使用量はcompactionフラグ付きで記録され、セッション合計を要約サイズにリセットする。新しいステートマシンはReplaceConversation時に合計をクリアしなくなった。これにより「プロアクティブな要約」が実際に発火するようになった――従来はこの合計値がそもそも書き込まれておらず、閾値チェックがテスト以外では発火し得なかった。／実行途中でクラッシュすると、未応答のツールリクエストが会話に残る。従来はこれが次のユーザー入力時に黙って再実行されていた（注釈のないリクエストは実行可能扱いがデフォルトのため）。新しい承認・実行フローは、現在のリクエストに属するものだけを対象とする）

つまり、この作り替えは新機能の追加ではなく「以前から存在していたが発火していなかった省コスト機能を、実際に動くようにした」バグ修正という側面も持っている。

マージキュー経由でマージ、自動レビューboが5件以上の不整合を指摘

PR #9574は2026年8月6日、GooseのメンテナーDOsinga氏によってマージキュー経由でmainにマージされた（25件のチェックがパス）。レビューはmichaelneale・jamadeo両氏が承認しているほか、GitHub Advanced SecurityとCodex（chatgpt-codex-connectorという自動レビューbot）がコメントを残している。Codexが指摘した内容には次のようなものがあった（いずれも該当コミットで修正済み）。

自動レビューbotが指摘した内容が実装者によってそのまま修正コミットとして取り込まれている点は、大規模リファクタリングのレビュー工程にAIツールが実質的な役割を果たしていることを示す一例といえる。なお、このPRの一連のコミットメッセージには「Co-Authored-By: Claude Fable 5 noreply@anthropic.com」という表記が繰り返し現れており、実装作業自体にもAIコーディングツールが関わっていたことがコミット履歴から読み取れる。

まだ実験段階、名前だけが先に公開された

冒頭で触れたとおり、リリースノート本文には「Unrolled agent loop」という項目名しかなく、この機能自体はGOOSE_STATE_MACHINEというフラグの裏にある実験的な実装だ。PR本文も「従来の応答ループとの動作の一致を確立するまでの間」という条件付きの表現をしており、Blockがこの新しい実装をいつデフォルトへ切り替える計画なのかは、本記事の調査範囲では確認できなかった。

フラグを有効にして実際に動かしたわけではない

本記事はGoose v1.46.0のリリースノート本文と、実装PR #9574の本文のみを情報源としている。この記事を書いている自分の手元で、実際にGOOSE_STATE_MACHINEフラグを有効にしてGooseを動かし、従来のループとの挙動の違いやプロセス再起動後の再開を確認する検証は行っていない。パフォーマンス面（従来のコルーチン方式と比べて速くなるのか遅くなるのか）についても、このPR本文には記載がなく、本記事でも言及していない。

関連記事: AIコーディングアシスタント比較──Copilot/Cursor/Claude Code【2026年】 / AIエージェントとは / subagentとは

感想・指摘はコメント欄へ。