目次
AIエージェントの本番化について、この1年で多くの企業が真剣に議論してきた項目がある。何をさせるか。どこまでの権限を渡すか。どんなガードレールを敷くか。ログはどこに残すか。稟議の形式も、ずいぶん整ってきた。
それでも、ほとんどの企業がまだ決めていない項目がひとつある。
「どれくらいの時間、人が見ていない状態で走らせてよいか」 である。
これまで決めなくてよかったのには理由がある。エージェントは「呼び出す」ものだったからだ。誰かが起動し、数十秒から数分で結果が返り、人がそれを受け取る。実行が終われば、そのセッションは閉じる。時間は、そもそも管理対象ではなかった。
2026年8月の1週間で、その前提が崩れた。
8月の1週間で、エージェントの「稼働時間」が桁で伸びた
エージェントの稼働時間が桁で伸びた1週間を示す図。2026年8月に並んだ3つの発表を3枚のカードで示す。1枚目は8月6日のAWSで、Amazon Bedrock AgentCoreのランタイムインスタンスが一般提供となり、セッションは最大14日間持続する。従来のmicroVMは最大8時間だった。2枚目は8月13日のWriterで、新フラッグシップモデルPalmyra X6が単一の目標に向けて最大8時間無人で稼働し、1タスクあたり平均26秒、コストは52パーセント減となる。3枚目は8月中旬のGoogleで、常時稼働型エージェントGemini Sparkの継続タスク機能が提供拡大され、端末を開いていなくても動く。下段は前提の転換を示す。これまでは呼び出し型で、1回の実行が1回の承認にあたり、実行が終われば証跡も閉じた。これからは常駐型で、1回の承認で14日ぶんが動き、証跡は走ったまま溜まり続ける
2026年8月6日、AWSはAmazon Bedrock AgentCoreに「ランタイムインスタンス」を追加し、一般提供を開始した。
これは、エージェントに永続的な実行基盤を与える機能である。従来のAgentCoreランタイムはmicroVM方式で、1回の呼び出しは最大8時間まで、というのが上限だった。新しいランタイムインスタンスは、AWSが管理するEC2基盤の上で動き、同一ホスト上の複数エージェントが共有するセッションを最大14日間持続させる。 GPUアクセラレーションに対応し、アイドル期間中はセッションを停止・再開して費用を抑えられる。提供リージョンには東京が含まれている。
用途として想定されているのは、AWS自身の説明によれば「数日にわたる多段ワークフローで状態を持ち続けるエージェント」「共有基盤上で協調する複数エージェント」である。オーケストレーター役のエージェントをmicroVM上に置き、重い作業を専用インスタンス上のワーカーに投げる、という構成も想定されている。
8月13日には、Writerが新しいフラッグシップモデル「Palmyra X6」を発表した。 ここでの訴求点も時間である。1タスクの平均完了時間は26秒、生成速度は毎秒82トークン。そして単一の目標に向けて、最大8時間、無人で走り続けられることが前面に置かれた。同社の言い方を借りれば、「コストと信頼性が持たなかったせいで現実的でなかった長時間の作業」を成立させるための更新である。エージェントハーネスとあわせて、従来比でコスト52%減・速度48%向上・品質10%向上、価格は入力100万トークンあたり2ドル、出力8ドルとされている。
同じ週、Googleの常時稼働型エージェント「Gemini Spark」の継続タスク機能も提供範囲を広げている。 SparkはI/O 2026で発表された、クラウド側で動くパーソナルエージェントだ。特徴は明快で、利用者の端末が開いていなくても作業が進む。 MCP経由で外部サービスと接続し、指示を受けたあとも動き続ける。
3つの発表に共通しているのは、性能の話ではない。エージェントが「呼び出されるもの」から「走り続けるもの」に変わった、という話である。
この変化が実務に効いてくるポイントは、ひとつに絞れる。承認の回数と、稼働の長さが、切り離されたことだ。
これまでは、1回の実行に1回の承認が対応していた。人が起動ボタンを押すという行為そのものが、事実上のチェックポイントとして機能していた。ところが14日間走り続けるセッションでは、承認は最初の1回しか発生しない。 その後の13日と23時間は、誰の判断も経ずに進む。
時間を2倍にすると、失敗は2倍ではなく4倍になる
稼働時間を2倍にすると失敗は4倍になることを示す図。長時間タスクにおけるエージェントの劣化構造を3つの数値で示す。1つ目は約35分で、人間換算でこの長さを超えると成功率が落ち始める。2つ目は4倍で、所要時間が2倍になると失敗率は2倍ではなく4倍になる。3つ目は25回から30回で、ツール呼び出しがこれを超えると20万トークンのコンテキストでも一貫性が崩れる。中段はMETRの時間地平分析で、人間が4分未満で終える作業では成功率はほぼ100パーセント、人間が4時間超をかける作業では成功率は10パーセント未満、50パーセント完了の時間地平は約7ヶ月ごとに倍増している。下段はMonte Carloの2026年調査で、72.7パーセントが監視・アラートなしでは本番投入しない、63.4パーセントが監視の欠如を拡大の最大障壁に挙げ、53パーセントが既存エージェントの大幅な再設計を見込んでいる
「8時間走れる」は「8時間ぶんの品質が保たれる」という意味ではない。ここは分けて考える必要がある。
長時間タスクにおけるエージェントの成功率は、時間に対して直線的には下がらない。加速して下がる。
基準になるのはMETRの時間地平分析である。ある作業を熟練者が終えるのに何分かかるかを基準に、モデルがその長さの作業をどれだけ成功させられるかを測る手法だ。人間が4分未満で終える作業なら、最前線のモデルはほぼ100%成功する。ところが人間が4時間を超えてかける作業になると、成功率は10%未満まで落ちる。 なお、50%の確率で完了できるタスク長は約7ヶ月で倍増しており、直近では約4ヶ月に短縮しているという分析もある。能力は確かに伸びている。しかし、伸びているのはあくまで「時間地平」という一本の線であって、線の先で成功率が急落する構造そのものは変わっていない。
2026年に相次いだ長期タスク評価の研究は、この急落をもう少し細かく分解している。
- 人間換算で約35分を超えたあたりから、成功率が落ち始める
- 所要時間が2倍になると、失敗率は2倍ではなく4倍になる
- ツール呼び出しが25〜30回を超えると、20万トークンのコンテキストを持つモデルでも一貫性が崩れ始める。 早い段階の結果を忘れる、完了済みのステップをやり直す、何をどこまでやったかの認識がぶれる、といった症状が出る
原因は「コンテキストが溢れる」だけではない。研究の用語では軌跡起因の劣化（trajectory-induced degradation） と呼ばれる。実行の履歴、ツールの出力、途中で書き換えた環境の状態、そして序盤に犯した小さな誤りが積み上がり、後半の判断を難しくしていく。文字数が増えることによる劣化（コンテキストロット）は、その一部にすぎない。
厄介なのは、長いコンテキスト窓を持つモデルほど、この劣化が止まりにくいことだ。以前は、コンテキストが溢れてエラーになることが、事実上の「強制終了装置」として働いていた。窓が広がった結果、その安全弁が作動しなくなった。終了条件が曖昧なまま走り出したエージェントは、成果が出ないまま探索を広げ続ける。
参考までに、長期タスク向けのベンチマークでは1タスクあたり平均990万トークン、約231エピソード、実行時間85分という規模が報告されている。これは1件の業務処理の話である。
プラットフォーム側もこの問題を認識している。AWSがAgentCore Observabilityについて公開している運用指針は、長時間セッションのメモリ肥大に対して、記録を無制限に積み上げるのではなく統合・要約する設定（consolidation）を必ず入れること、生イベントの保持期間を7〜365日の範囲で明示的に制御することを求めている。そして本番運用の最低ラインとして、運用メトリクス・アプリケーションログ・分散トレース・品質評価の4つを併用することを挙げている。どれかひとつで足りるとは書かれていない。
しかし、現場の準備はそこまで進んでいない。データ可観測性のMonte Carloが2026年に行った調査では、こうなっている。
- 72.7% が、監視とアラートなしにエージェントを本番投入することはないと回答
- 63.4% が、監視・可観測性の欠如を、AI展開を広げるうえでの最大の障壁として挙げた
- 53% が、すでにデプロイ済みのエージェントについて、大幅な作り直し・再設計が必要になると見込んでいる
- 別途、64% が「支える準備が整う前にエージェントを本番投入した」と回答している
監視が必要だと全員が知っていて、監視が足りないと全員が答えていて、それでも本番投入は進んでいる。 ここに14日間の連続稼働が乗る。これが2026年8月の実像である。
承認は1回、稼働は14日 ― 日本企業がいま失おうとしている統制
人が起動するをやめた瞬間に消える統制を示す図。国内調査に見る日本企業の現在地として、従業員100名以上で生成AIを活用する企業の548名を対象にした2026年6月調査の4つの数値を示す。67.1パーセントはAIの起動をいまも人が行っている。2.9パーセントのみが起動から後処理まで完全に自動化している。13.0パーセントのみがAIの利用状況を横断的に追跡できる。50.7パーセントは社内データが未整備のままである。中段は14日間の稼働中に実務で起きることとして3点を挙げる。1つ目は運用当番が交代し承認した本人が席にいなくなること。2つ目は週末や連休をまたぎ一次対応が薄くなる時間帯を通過すること。3つ目は参照している前提データや社内ルールが途中で更新されること。いずれも開始時の1回の承認では捕捉できない事象である。下段は制度側が継続的な監督を前提にしていることを示し、EU AI Actの高リスク義務は2026年8月2日から執行され、第14条の人的監視と自動生成ログの6ヶ月以上の保持が求められる
ここで日本の実態を見ておきたい。
株式会社Merが2026年8月6日に公表した「Japan AI Operations Report 2026 Summer」は、従業員100名以上で生成AIを業務活用している企業の管理職・実務者548名を対象にした調査である（調査期間は2026年6月24〜25日）。数字はこうなっている。
- 67.1% ─ AIの起動を、いまも人が行っている
- 2.9% ─ 起動から出力後の処理まで完全に自動化できている
- 27.2% ─ AIの出力が業務システムへ自動で反映される
- 13.0% ─ AIの利用状況を組織横断で追跡できている
- 50.7% ─ 社内データが十分に整備されていない
- 67.2% ─ それでもAI投資を拡大する予定がある
この並びを、「日本は遅れている」と読むのは早い。もう一段深く見ると、別の構図が浮かぶ。
「67.1%が人で起動している」というのは、裏返せば、日本企業のAI運用における最大の統制装置が『人が起動すること』だった、ということである。
起動のたびに、誰かが対象データを見て、前提が変わっていないかを確認し、押した。この行為は稟議にも運用手順書にも書かれていないが、実質的に品質チェックであり、承認であり、証跡だった。設計されていない統制である。
したがって、無人稼働に移行するとき、企業は2つのことを同時にやることになる。ひとつは業務の自動化。もうひとつは、気づかないうちに機能していた統制の喪失だ。後者は稟議に書かれない。だから誰も代替を用意しない。
そして、それを補うはずの追跡能力を持っているのは13.0%しかない。
日本の大企業には、さらに固有の事情がある。
第一に、変更管理が「業務時間内に人が承認する」前提で設計されていることだ。 変更申請には申請者と承認者の欄があり、CAB（変更諮問委員会）は人が集まって開かれる。夜間・休日に無人で走ることが許されてきたのは、バッチ処理という「あらかじめ決められた処理」だけだった。エージェントは違う。決められた処理をするのではなく、判断しながら走る。 夜間バッチの枠に入れてよい対象ではない。
第二に、運用保守を外部委託し、当番制で回している企業が多いことだ。 14日間走り続けるセッションは、当番の交代を必ずまたぐ。開始時に承認した担当者は、途中のどこかで席にいなくなる。「このエージェントは何のために、誰の承認で、いつまで走っているのか」を引き継ぐ様式が、いまの運用手順書にはない。
第三に、稼働中に前提が変わることだ。 参照している社内規程が改訂される。マスタデータが更新される。取引先の条件が変わる。14日という長さは、日本の大企業の月次サイクルに対して十分に長い。開始時点の前提で正しかった判断が、10日目には正しくなくなっている可能性がある。
制度の側も、この方向を織り込んでいる。EU AI Actの高リスクAIに関する義務は2026年8月2日から執行されている。 第14条が求める人的監視は、「導入時に一度確認した」で足りるものではない。自動生成ログを6ヶ月以上保持する義務も、監督がイベントではなく継続であることを前提にした設計である。
要するに、こういうことだ。多くの企業は「権限」の設計をようやく終えたところにいる。だが、権限を渡す設計をしても、時間を渡す設計をしていなければ、統制は成立しない。
「時間」を管理対象に入れる ― 日本の大企業がいま決める5つのこと
時間を管理対象に入れるための5つの決定を示す図。権限を決めた企業が次に決めていない項目として5点を挙げる。1つ目は最大稼働時間を決めることで、自律度ごとに上限を置き、無制限を既定値にせず、上限到達時の挙動まで書く。2つ目は定期チェックポイントを設計することで、経過時間・アクション数・累積コストの3トリガーで一時停止し、人が再承認する。3つ目は交代を前提にした引き継ぎ様式を作ることで、当番交代・週末・連休をまたぐ実行の引き継ぎ項目を変更管理の様式に組み込む。4つ目は劣化を経過時間別に測ることで、差し戻し率・手戻り工数・エスカレーション率を開始1時間目と8時間目で分けて集計する。5つ目は中断の粒度と再開を実測することで、全停止は押せないため個別停止の単位を決め、止めて再開できることを訓練で確かめる。結論として、決めるべきは何をさせるかではなく、どれだけの時間、見ずに任せるかである
抽象論で終わらせないために、明日から意思決定できる形に落とす。いずれも技術ではなく、経営と運用の決めごとである。
① 最大稼働時間を、自律度ごとに決める
エージェントごとに、無人で走ってよい時間の上限を明示する。観察のみなら長くてよい。助言までなら中程度。実行を伴うなら短く。「無制限」を既定値にしないことが要点である。あわせて、上限に到達したときの挙動――停止するのか、人にエスカレーションするのか、部分成果を保存して待機するのか――まで書く。基盤側にも、AgentCoreのセッション停止・再開のような機能はすでにある。決めるべきは、使うかどうかではなく、何分で止めるかだ。
② 定期チェックポイントを、3つのトリガーで設計する
「何かあったら止める」では遅い。経過時間・アクション数・累積コストの3つでチェックポイントを設ける。たとえば「2時間経過」「50アクション」「想定原価の1.5倍」のいずれかに触れたら一時停止し、人が再承認しない限り先へ進まない。全アクションを人が見る必要はない。見る場所を、時間軸の上に置き直すという話である。
③ 交代を前提にした引き継ぎ様式を作る
長時間稼働するエージェントには、変更管理の様式に次の欄を足す。目的、承認者、予定終了時刻、現在の進捗、いま何を待っているか、止めたいときの手順、止めた場合の業務影響。当番が交代しても、次の担当者がこれを読んで判断できる状態にする。日本企業の運用体制における現実的な最大のリスクは、技術ではなく「引き継がれないこと」である。
④ 劣化を「経過時間別」に測る
品質指標は、これまで平均値で見られてきた。長時間稼働では平均が意味を失う。差し戻し率・手戻り工数・エスカレーション率を、開始1時間目と8時間目で分けて集計する。 劣化のカーブが見えれば、①の上限時間を勘ではなく実測で決められるようになる。ここが、最も早く自社の資産になる部分でもある。
⑤ 中断の粒度を決め、再開を訓練する
全社一斉停止のスイッチは、実際には押せない。業務が止まるからだ。押せるようにするには、個別に止められる単位をあらかじめ設計しておくしかない。そして、止めたあとに再開できるかどうかは、机上では確認できない。訓練して実測する。 復旧時間を測っていないキルスイッチは、監査の場では機能していないのと同じ扱いになる。
これらはいずれも、モデルを差し替えても、基盤を載せ替えても残る。土台は借り物でよいが、上限時間の根拠と劣化のカーブは自社の資産になる。
まとめ ― 決めるべきは「どれだけの時間、見ずに任せるか」
2026年8月、エージェントの稼働時間は8時間から14日へ、一気に桁で伸びた。一方で、時間が伸びるほど成功率は加速度的に落ちる。そして日本企業の67.1%は、いまも人が起動することで、設計されていない統制を保っている。
この3つを並べると、次にやるべきことは自然に決まる。権限の設計は済んだ。次は時間の設計である。
- 稼働時間の上限を、自律度ごとに決める
- チェックポイントを、時間・アクション数・コストの3トリガーで置く
- 当番交代をまたぐ引き継ぎ様式を、変更管理に組み込む
- 品質の劣化を、経過時間別に測る
- 個別停止の粒度を決め、再開を訓練で確かめる
Wizitは「PoCで止まったAIを、本番運用とROIまで動かし切る」ことを仕事にしている。本番化の可否を分けるのは、多くの場合モデルの性能ではなく、業務側で合意された基準と、それを測り続ける仕組みがあるかどうかである。エージェントが走り続ける時代には、その基準に「時間」という軸がひとつ加わる。何時間なら任せられるのか、その根拠は何か、劣化はどこから始まるのか。ここを実データで持てた企業から、無人稼働は現実的な選択肢になる。
逆に言えば、この軸を決めないまま14日間のセッションを開始することが、2026年下半期に最も起こりやすい失敗である。
---
出典:
- AWS News Blog「Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore」（2026年8月6日）
- AWS「AgentCore runtime instances are now generally available」（2026年8月）
- AWS Machine Learning Blog「Optimizing production agents with Amazon Bedrock AgentCore Observability」
- WRITER「WRITER Makes Agentic AI Economically Sustainable at Enterprise Scale With Palmyra X6 Release and Major Harness Upgrades」（2026年8月13日）／ SiliconANGLE（2026年8月13日）
- Google「The Gemini app becomes more agentic, delivering proactive, 24/7 help」／ Gemini Spark 製品ページ
- METR「Measuring AI Ability to Complete Long Tasks」（時間地平分析）
- 長期タスク評価に関する2026年の研究群（Long-Horizon-Terminal-Bench、The Horizon Gap ほか）
- Monte Carlo「Builders in Production」調査（2026年）
- 株式会社Mer「Japan AI Operations Report 2026 Summer」（2026年8月6日公表、n=548、調査期間2026年6月24〜25日、IDEATECH「リサピー」にて実施）
- 欧州連合 AI Act（高リスクAIに関する義務、2026年8月2日執行／第14条 人的監視、ログ保持義務）