長時間エージェントを入れる前に決める、進捗の見え方
- 長時間かかるエージェントや非同期実行の導入を検討している人
- 「動いているはず」なのに、進んでいるのか止まっているのか説明できない人
- 停止条件とは別に、進捗の確認者と見え方を先に決めたい人
エージェントに長い仕事を任せると、最初は楽になります。
依頼を投げる。 画面を閉じる。 別の仕事に戻る。 あとで結果を見る。
ここまでは良い流れです。
問題は、その「あとで」のあいだに起きます。
進んでいるのか。 待っているのか。 止まっているのか。 誰が見れば分かるのか。
この四つが無いと、非同期は便利ではなく、放置になります。
本稿の主張は一文です。
長時間エージェントを入れる前に、止まっているのか進んでいるのかを、誰がどう確認するかを先に決める。
停止条件の話は重要ですが、本稿では扱いません。 ここでは 進捗の見え方と確認者 に限定します。
現場で起きる、「動いているはず」の空白
調査、集計、複数ファイルの整理、長い下書き。 どれも、一度投げて待つ仕事になりやすいです。
現場では、だいたいこうなります。
- エージェントに依頼する
- 「しばらくかかります」と出る
- 別件に戻る
- 30分後、まだ終わっていない
- 誰かに「どうなってる？」と聞かれる
- 「動いているはずです」と答える
この「はず」が続くと、不安は増えます。 不安が増えると、同じ依頼を二重に投げます。 二重に投げると、どちらが本番か分からなくなります。 分からなくなると、確認の仕事が人に戻ります。
長時間エージェントの失敗は、能力不足だけではありません。 待ち時間の説明責任が、設計されていないことです。
忙しいのに「何が進んだか」が説明できないときと同じ構造です。 忙しさは見えるのに、進みが見えない。 エージェントでも、同じ空白が起きます。
背景実行が増えると、見え方の設計が先になる
2026年7月7日、Googleは Gemini API の Managed Agents 向けに、background 実行などの更新を発表しています。 発表では、長い処理のために接続を開き続けないよう、非同期で実行し、IDを使って状態を確認できる、と説明されています。
ここで確認できるのは、「長く走らせる手段が増えた」という事実までです。 料金や地域、自社での提供可否は、推測で書きません。 導入判断は、公式の提供条件を都度確認する前提にします。
手段が増えたとき、現場が先に決めるべきなのは、機能のオンではありません。
誰が、どの画面で、何をもって「進んでいる」と言うかです。
状態が in_progress と出るだけでは足りません。
現場の言葉では、次が要ります。
- いま何をしているのか（調査中、生成中、待ち中）
- 最後に動いたのはいつか
- 次に人が見るタイミングはいつか
- 見に行く担当は誰か
この四つが無い進捗表示は、ランプです。 ランプは安心材料に見えますが、判断材料にはなりません。
進捗の見え方は、ステータス色だけでは足りない
色分けは分かりやすいです。 緑、黄、赤。 進行中、完了、失敗。
ただ、色だけでは現場は動けません。
週次の数字を見る会議の前に、「誰が何を変えるか」一行で決めると同じです。 見えることと、次の行動が決まることは別です。
長時間エージェントでは、次の三層を分けます。
1. 機械の状態
APIや管理画面が出す状態です。 実行中、完了、失敗、再接続待ち、など。
これは必要です。 ただし、これだけで現場説明は終わりません。
2. 仕事の進捗
現場が知りたいのは、状態名より中身です。
- 何件中の何件まで終わったのか
- どの工程まで来たのか
- 人の確認待ちなのか、計算待ちなのか
「進行中」の一語は、この差を隠します。 隠したまま会議に出すと、全員が別の絵を見ます。
3. 確認の役割
進捗を見に行く人と、結果を採用する人は、同じとは限りません。
- 見に行く人：止まっていないかを確認する
- 判断する人：出てきた結果を使うか決める
- 止める人：別テーマ（本稿では扱わない）
役割を混ぜると、「見ておいて」が誰の仕事か消えます。 消えると、結局いちばん不安な人が何度も開きに行きます。
エスカレーションに、閉じる担当の名前が要るの話と近いです。 開いた案件に、見る人と閉じる人が無いと、進行中のまま残ります。 エージェントの待ちも同じです。
進捗の見え方を先に決める、短い設計
tugiloでは、長時間エージェントの前に、次を残します。
1. 進捗の一行定義を書く
「動いている」では足りません。 次の形に落とします。
- 最後に更新された時刻が分かる
- いまの工程名が分かる
- 人の確認待ちか、機械の処理待ちかが分かる
この三つのどれかが欠ける表示は、進捗ではなく気配です。
2. 確認者を一人決める
全員が見られる状態は、誰も見ていない状態になりやすいです。 確認者は一人にします。
確認者の仕事は、結果の採否ではありません。 待ち時間中に、進みの説明ができることです。
AIと人の責任境界は、責任の置き場から決めるの延長で言えば、実行の責任と、待ちの説明責任は分けて置きます。 投げた人が忙しいなら、確認者を別に置きます。 置かないなら、投げた人が確認者です。曖昧にしない。
3. 確認のタイミングを先に決める
「気になったら見る」は運用ではありません。 次のように固定します。
- 開始直後に一度見る（受け付けられたか）
- 想定時間の半分で一度見る（進んでいるか）
- 想定時間を超えたら必ず見る（止まっていないか）
この三つが無いと、確認は感情に依存します。 感情に依存する確認は、忙しい日ほど遅れます。
4. 二重投入を防ぐ見え方にする
進捗が見えない現場では、同じ依頼が二重に飛びます。 だから表示には、次も必要です。
- いま走っている依頼ID
- 誰が投げたか
- 同じテーマの重複がないか
重複が見えない進捗画面は、安心装置ではなく、増殖装置です。
現場への説明文も、先に型を決めておきます。
「いまは〇〇の工程です。最後の更新は△△です。次の確認は□□が、想定時間の半分で見ます。」
この型があると、「動いているはず」が減ります。 減るのは不安だけではありません。 同じ質問を何度も受ける時間も減ります。
運用は、「待ちの説明」から始める
長時間エージェントの運用初日にやることは、高度な監視ではありません。
紙に、次の四行だけ書いてください。
- 進捗は何を見れば分かるか（一行）
- 確認者は誰か（一人）
- いつ見に行くか（開始直後／半分／超過）
- 同じ依頼の二重投入をどう防ぐか（一行）
この四行が書けないテーマは、まだ背景実行の出番ではありません。 先に、待ち時間の設計の出番です。
停止条件は別記事のテーマです。 止める話の前に、進みが見えないと、止める判断すら始まりません。 進みが見えない停止は、勘に近いです。
運用が回り始めたら、週に一度だけ振り返ります。
「今週、進捗の説明で詰まった依頼はあったか。」 「確認者が不在のとき、誰が代わりに見たか。」
この二つが曖昧なまま依頼だけ増えると、待ち時間の説明が属人化します。 属人化した待ちは、担当が休んだ日に一気に不安になります。 不安を減らすのは、監視の細かさより、確認者の名前です。
非同期は、人を待たせないための手段です。 待たせないことと、見えなくすることは違います。
長時間エージェントを入れる前に決めるのは、賢いエージェントの選び方だけではありません。 止まっているのか進んでいるのかを、誰がどう確認するかです。
その一行が無い導入は、自動化ではなく、説明不能な待ち時間の量産です。
長時間エージェントの前に、進捗の見え方と確認者の置き方を一緒に整理できます。
