--- read_when: - エージェントがツールを使用している間に誘導がどのように動作するかを説明する - アクティブ実行キューの動作またはランタイムステアリング統合の変更 - steer、queue、collect、followup の各モードの比較 summary: アクティブ実行ステアリングがランタイム境界でメッセージをキューに入れる仕組み title: ステアリングキュー x-i18n: generated_at: "2026-05-04T02:23:50Z" model: gpt-5.5 provider: openai source_hash: c8df35b127ae0c1e1b3b684a1f63ce33874eb3d0b7bf9d0df7cb9dfce093090a source_path: concepts/queue-steering.md workflow: 16 --- 実行中のセッションがすでにストリーミングしている間にメッセージが届いた場合、OpenClaw は 同じセッションに対して別の実行を開始する代わりに、そのメッセージをアクティブなランタイムへ 送信できます。公開モードはランタイムに依存しません。Pi とネイティブ Codex app-server ハーネスは、配信の詳細を異なる方法で実装しています。 ## ランタイム境界 ステアリングは、すでに実行中のツール呼び出しを中断しません。Pi はモデル境界で キューに入ったステアリングメッセージを確認します。 1. アシスタントがツール呼び出しを要求します。 2. Pi が現在のアシスタントメッセージのツール呼び出しバッチを実行します。 3. Pi がターン終了イベントを発行します。 4. Pi がキューに入ったステアリングメッセージを排出します。 5. Pi が次の LLM 呼び出しの前に、それらのメッセージをユーザーメッセージとして追加します。 これにより、ツール結果はそれを要求したアシスタントメッセージと対応したままになり、 次のモデル呼び出しが最新のユーザー入力を確認できます。 ネイティブ Codex app-server ハーネスは、Pi の内部ステアリングキューの代わりに `turn/steer` を公開します。OpenClaw はそこで同じモードを適用します。 - `steer` は、設定された静音ウィンドウの間キューに入ったメッセージをまとめてから、 収集したすべてのユーザー入力を到着順に含む単一の `turn/steer` リクエストを送信します。 - `queue` は、個別の `turn/steer` リクエストを送信することで、従来の直列化された形を維持します。 - `followup`、`collect`、`steer-backlog`、`interrupt` は、アクティブな Codex ターンの周囲で OpenClaw が所有するキュー動作のままです。 Codex レビューと手動 Compaction ターンは、同一ターンのステアリングを拒否します。ランタイムが ステアリングを受け入れられない場合、OpenClaw はそのモードで許可されている範囲でフォローアップキューに フォールバックします。 このページでは、通常の受信メッセージ向けのキューモードステアリングについて説明します。明示的な `/steer ` コマンドについては、[ステア](/tools/steer)を参照してください。 ## モード | モード | アクティブ実行の動作 | 後続フォローアップの動作 | | --------------- | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | `steer` | 次のランタイム境界で、キューに入ったすべてのステアリングメッセージをまとめて注入します。これがデフォルトです。 | ステアリングを利用できない場合にのみフォローアップへフォールバックします。 | | `queue` | 従来の 1 件ずつのステアリングです。Pi はモデル境界ごとにキュー内のメッセージを 1 件注入し、Codex は個別の `turn/steer` リクエストを送信します。 | ステアリングを利用できない場合にのみフォローアップへフォールバックします。 | | `steer-backlog` | アクティブ実行のステアリング動作は `steer` と同じです。 | 同じメッセージを後続のフォローアップターン用にも保持します。 | | `followup` | 現在の実行をステアリングしません。 | キューに入ったメッセージを後で実行します。 | | `collect` | 現在の実行をステアリングしません。 | デバウンスウィンドウ後に、互換性のあるキュー内メッセージを 1 つの後続ターンに結合します。 | | `interrupt` | アクティブな実行を中止し、その後で最新のメッセージを開始します。 | ありません。 | ## バースト例 エージェントがツール呼び出しを実行している間に 4 人のユーザーがメッセージを送信した場合: - `steer`: アクティブなランタイムは、次のモデル判断の前に 4 件すべてのメッセージを到着順で受け取ります。 Pi は次のモデル境界でそれらを排出し、Codex は 1 つにまとめられた `turn/steer` として受け取ります。 - `queue`: 従来の直列化されたステアリングです。Pi はキュー内のメッセージを 1 件ずつ注入し、 Codex は個別の `turn/steer` リクエストを受け取ります。 - `collect`: OpenClaw はアクティブな実行が終了するまで待機し、その後デバウンスウィンドウ後に 互換性のあるキュー内メッセージを含むフォローアップターンを作成します。 ## スコープ ステアリングは常に現在のアクティブなセッション実行を対象にします。新しいセッションを作成したり、 アクティブな実行のツールポリシーを変更したり、送信者ごとにメッセージを分割したりしません。 複数ユーザーのチャンネルでは、受信プロンプトに送信者とルートのコンテキストがすでに含まれているため、 次のモデル呼び出しは各メッセージの送信者を確認できます。 互換性のあるメッセージを結合し、フォローアップキューのドロップポリシーを保持できる後続の フォローアップターンを OpenClaw に構築させたい場合は、`collect` を使用します。以前の 1 件ずつの ステアリング動作が必要な場合にのみ `queue` を使用します。 ## デバウンス `messages.queue.debounceMs` は、`collect`、`followup`、`steer-backlog`、およびアクティブ実行の ステアリングを利用できない場合の `steer` フォールバックを含む、フォローアップ配信に適用されます。 Pi では、アクティブな `steer` 自体はデバウンスタイマーを使用しません。Pi は次のモデル境界まで 自然にメッセージをまとめるためです。ネイティブ Codex ハーネスでは、OpenClaw はバッチ化された `turn/steer` を送信する前の静音ウィンドウとして、同じデバウンス値を使用します。 ## 関連 - [コマンドキュー](/ja-JP/concepts/queue) - [ステア](/tools/steer) - [メッセージ](/ja-JP/concepts/messages) - [エージェントループ](/ja-JP/concepts/agent-loop)