結論:Fable 5の影に隠れた本丸はこちらだ。「定時実行・秘匿情報・監視」という本番移行の3つの急所に、運用機能の回答が揃った
Anthropicは6月9日、公式ブログでClaude Managed Agentsの スケジュール実行(Scheduled Deployments) と Vaultによる環境変数の秘匿管理 を発表した(いずれもClaude Platform上のパブリックベータ)。前日の6月8日には、MCPベースの コネクタ可観測性ダッシュボード もパブリックベータとして公開している。
同時期のClaude Fable 5の一般提供がモデル性能の話題をさらったが、エージェントをPoCから本番に出せずにいる企業にとっての本丸はこちらだ。「決まった時刻に確実に動くか」「APIキーや認証情報を安全に渡せるか」「動き続けるエージェントを監視できるか」 ——本番移行を阻んできた運用面の障壁に、各個撃破の機能が揃った。RPAや夜間バッチの置き換え先としてAIエージェントを検討する際の前提条件が、具体的に変わり始めている。
プラットフォーム間の競争が「モデルの賢さ」から「本番運用機能」へ移っていることを示す動きでもあり、Claudeを使っていない企業にとっても、自社のエージェント基盤に同等の機能があるかを確かめるベンチマークとして読む価値がある。
押さえるべき1点:エージェントの本番移行を阻むのはモデルの賢さではなく運用要件である。定時実行・秘匿情報・可観測性の3点は、どのプラットフォームを使うかにかかわらず本番化の必須チェック項目だ。
何が追加されたか:3機能の整理
| 機能 | 内容 | 公開日 | 状態 |
|---|---|---|---|
| Scheduled Deployments | エージェントにcron形式のスケジュールを設定し、定期タスクを自動実行。実行ごとに新しいセッションを開始。一時停止・再開・アーカイブ・手動の追加実行が可能 | 6月9日 | パブリックベータ |
| Vault環境変数 | APIキー等をVaultに保管し、エージェントのCLIツールに環境変数として注入。サンドボックス内にはプレースホルダのみが置かれ、実際の鍵は許可済みドメイン宛ての通信時にネットワーク境界で付与 | 6月9日 | パブリックベータ |
| コネクタ可観測性 | MCPコネクタの利用状況(アクティブユーザー・ツール呼び出し数)、健全性スコア・エラー率・レイテンシ、ツール別エラー内訳をダッシュボードで監視。Claude・Claude Code・Cowork等の製品横断で利用を比較 | 6月8日 | パブリックベータ |
3機能ともパブリックベータとしての提供であり、仕様・提供条件は今後変わり得る。スケジュール実行とVaultはClaude Platform上で、可観測性ダッシュボードは組織設定から利用する形だ。
スケジュール実行は、週次のコンプライアンススキャン、夜間のデータ同期、日次ダイジェスト生成のような 「人がいない時間に確実に回したい定型業務」 が想定用途として挙げられている。実行のたびに新しいセッションが立ち上がる設計のため、前回実行の状態を引きずらず、失敗した回を切り離して扱いやすい。一時停止・再開・アーカイブ・必要時の手動追加実行が管理操作として用意されており、これまで必要だった自前スケジューラの開発・ホスティングが不要になる。
事例も具体的だ。公式ブログでは、楽天のチームがスプレッドシートのデータ分析とレポート・資料生成を週次・月次のスケジュールで回している事例が紹介されている。国内大手の実名事例が公式ブログに載った意味は小さくない。「他社はどう使っているのか」という稟議の定番質問に、一次情報で答えられる材料が増えたということだ。ほかにも、Browserbaseがスケジュール実行で公開カタログの検証を回し、Milanaが安全なコードベースアクセスのもとで自動バグ修正を行う事例が挙げられている。Vault環境変数の対応CLIとしてはBrowserbase・KERNEL・Notion・Ramp・Sentryが列挙されている。
なぜ自社事か:この3機能は「本番に出せない理由」の裏返しである
AIエージェントが本番に出せない理由で整理したとおり、PoC止まりの原因はモデル性能ではなく、運用・統制・秘匿の3領域に集中している。典型的なシナリオはこうだ——デモでは見事に動いたエージェントを本番に出そうとした瞬間、「毎朝8時に確実に動かす仕組みは誰が作るのか」「基幹システムのAPIキーをエージェントにどう渡すのか。プロンプトインジェクションで抜かれないか」「動き続けるエージェントの失敗を誰がどう検知するのか」という3つの問いが情シスとセキュリティ部門から飛び、答えられずにPoCのまま停滞する。今回の3機能はこの問いへの回答として読むと位置づけが明確になる。
| 本番移行を阻む問い | 従来の対応 | 今回の機能 |
|---|---|---|
| 毎朝8時に確実に動かす仕組みは誰が作るのか | スケジューラを自前で開発・ホスト | Scheduled Deployments(cronをプラットフォーム側が提供) |
| APIキーをエージェントにどう渡すのか | プロンプトや設定ファイルに記載(漏えいリスク) | Vault環境変数(実鍵はモデルに渡らずネットワーク境界で付与) |
| 動き続けるエージェントの失敗を誰が検知するのか | ログを個別に集めて手作業で確認 | コネクタ可観測性(エラー率・レイテンシ・健全性スコアを標準ダッシュボード化) |
第一に、定時実行。 これまでエージェントを定期実行するには、自前でスケジューラを開発・ホストする必要があった。cronスケジュールをプラットフォーム側が持つことで、「RPAの夜間ジョブをエージェントに置き換えたいが、起動の仕組みから自作するのは重い」という構図が変わる。
第二に、秘匿情報。 シークレット管理はエージェント以前から開発運用の鬼門であり、「設定ファイルに書かれた鍵がリポジトリごと漏れる」事故は繰り返されてきた。エージェントではさらに条件が悪い。自然言語の指示で動く以上、プロンプトインジェクションという「ソーシャルエンジニアリングをソフトウェアに対して行う」攻撃が成立し、コンテキストに鍵があれば吐き出させられる恐れがある。Vault設計の要点は、モデルのコンテキストに本物の鍵を一切入れない ことだ。サンドボックス内にあるのはプレースホルダだけで、実際の鍵は利用者が許可したドメイン宛てのリクエスト時にネットワーク境界で付与される。公式ブログは、プロンプトインジェクションでエージェントが操られても、モデルのコンテキストには本物のシークレットが存在しないと説明している。鍵のローテーションもVault側の更新だけで済み、実行中のセッションは次回呼び出し時に新しい値を拾う。Browserbase・KERNEL・Notion・Ramp・SentryのCLIに対応し、NotionはAPIトークンをモデルに渡すことなくCLI機能を展開した事例として紹介されている。
第三に、可観測性。 自社開発のコネクタ(私設MCPサーバー)を社内展開した後、「誰が使っていて、どのツールがどれだけエラーを出しているか」を把握する手段が標準で提供される。ダッシュボードではアクティブユーザー数・ツール呼び出し総数・ディレクトリ内ランクの推移、健全性スコア・エラー率・レイテンシ、さらにツール単位のエラー内訳まで確認でき、Claude・Claude Code・Cowork といった製品面ごとの利用比較も可能だ。組織設定のDirectoryから利用でき、TeamまたはEnterpriseプランの管理者・オーナー権限(Enterpriseはカスタムロールでの委譲も可)が必要となる。あわせて、自作MCPサーバーのディレクトリ申請がアプリ内から直接できるようになった。公式ブログによればディレクトリにはすでに300を超えるサードパーティコネクタが並んでおり、社内コネクタを「作って配って終わり」にせず計測しながら育てる前提が整いつつある。MCPで社内システムを繋ぐ設計論はMCPで社内システムをAIエージェントに繋ぐで、コネクタ・ツールの統制設計は導入前チェックリスト:MCPツールガバナンスで整理している。社内APIをMCPコネクタとしてエージェントに開放する構成は便利な反面、「作った人しか状態を知らない接続」が増殖しやすい。可観測性が標準機能になったことで、社内コネクタにも稼働率・エラー率という運用指標を当然に求められるようになる。
Claudeを使っていない企業にとっても、この3機能のラインアップは 「本番運用に最低限必要な機能セット」のベンチマーク として読める。自社が使う予定のプラットフォームに同等の機能があるか、なければ誰がどう補うのか——この確認だけで、PoC計画の解像度は一段上がる。2026年後半のプラットフォーム評価は、デモの見栄えではなく「夜間に1か月、無人で安全に回り続けるか」で行うべきであり、その判断材料が今回の更新で具体的に増えた。
発注側への含意も大きい。プラットフォーム間の競争軸が「モデルの賢さ」から「本番運用機能の充実度」へ移るということは、ベンダー選定・RFPにも運用要件を明記する時代になった ということだ。「どのモデルを使うか」だけを指定した発注では、定時実行・秘匿管理・監視といった運用面が見積もりから抜け落ち、本番直前に追加費用として現れる。次章のチェックリストは、社内検討だけでなくRFPの要求事項としてもそのまま使える。
なお、本記事は運用機能の実装軸での整理であり、モデル選定・コスト試算の軸はFable 5の解説記事を参照してほしい。また、こうした統制・運用レイヤーは国産製品でも動きが出ており、同日公開のセゾンテクノロジーAgent Orchestrationの解説とあわせて読むと選択肢の全体像がつかめる。
エージェント本番化の運用要件チェックリスト
プラットフォームを問わず、本番移行の判定に使える7項目を挙げる。社内のPoCを本番に上げる判定会議で使うもよし、開発を外部に発注する際のRFP要求事項に転記するもよし、である。
- 定時実行の信頼性:スケジュール起動の失敗時に検知・通知・再実行の手順が決まっているか。「動かなかったことに翌週気づく」状態は本番とは呼べない
- 秘匿情報の注入方式:APIキー・認証情報がモデルのコンテキストに入らない設計か(プロンプトインジェクション耐性)。プロンプトに鍵を書く運用は論外として、環境変数でも注入経路の設計次第で露出し得る
- 接続先の許可リスト:エージェントが鍵を使って通信できるドメインを明示的に絞っているか。許可リストが「とりあえず全部」なら秘匿設計の意味は半減する
- コスト上限と停止条件:実行回数・トークン消費の上限と、暴走時の自動停止が設定されているか。定時実行は「夜中に静かに課金が積み上がる」リスクと表裏一体だ
- 監査ログ:誰が作ったどのエージェントが、いつ・何をしたかを後から追えるか。インシデント時の説明責任はログの粒度で決まる
- コネクタの健全性監視:ツール呼び出しのエラー率・レイテンシを継続的に観測しているか。エラー率の上昇は接続先システムの変更を検知する早期警報にもなる
- 人手承認の挿入点:取り消しの難しい操作(送信・決済・削除等)の前に人の承認を挟んでいるか
チェックの勘所:1〜3はプラットフォーム機能で大きく解決できるが、4〜7は機能があっても「設定し運用する」のは自社である。機能の有無と運用の有無を混同したまま本番に出すのが最も危険だ。コスト上限の設計は導入前チェックリスト:コスト暴走を止める設計を参照。
あわせて、定時実行ならではの運用の落とし穴も3つ挙げておく。第一に スケジュールの集中。各チームが申し合わせたように同じ時刻(始業前など)へジョブを置くと、その時間帯だけ実行とコストが集中する。第二に 通知疲れ。失敗通知を全部署同報にすると数週間で誰も読まなくなる。担当と一次対応をジョブ単位で決めておく。第三に 読み手のいないレポート。「毎週自動で作れる」ことと「毎週読む価値がある」ことは別であり、定期実行ジョブこそ四半期ごとの棚卸し対象にすべきだ。
よくある質問(FAQ)
Q. RPAや夜間バッチをエージェントに置き換えられるのか? A. 段階的には可能になってきたが、一斉置換は推奨しない。RPAは決められた手順を決定的に繰り返すのに対し、エージェントは判断を伴うぶん出力が一定しない。逆に言えば、画面変更のたびに壊れるRPAの保守地獄や、条件分岐を書き切れない非定型処理は、エージェントのほうが向く領域だ。定型性が高く失敗してもリカバリ可能な業務(レポート生成・データ集計・ダイジェスト配信等)から始め、確実性が最優先の基幹バッチは従来方式を残すのが現実的である。スケジュール実行はパブリックベータであり、その前提での適用範囲設計が必要だ。
Q. Vaultに入れた鍵は本当にモデルに渡らないのか? A. 公式の説明では、サンドボックスにはプレースホルダのみが置かれ、実鍵は許可済みドメイン宛て通信時にネットワーク境界で付与されるため、モデルのコンテキストにシークレットは入らない。ただしこの防御は許可ドメインの設計が前提であり、許可リストを広く取れば効果は薄まる。鍵ごとに「その鍵が正当に使われる宛先」だけを最小限で列挙し、定期的に棚卸しする運用までを含めて初めて防御として機能する。設計レビューは依然として必要だ。
Q. Claude以外のプラットフォームを使っている場合、この記事は関係ないか? A. 関係ある。本記事のチェックリスト7項目はプラットフォーム共通の本番化要件であり、各社の機能がこの要件をどこまで埋めるかが選定基準になる。主要プラットフォームの運用機能は今後も急速に揃っていくため、「いま使っている基盤にない機能」を内製で埋めるか待つかの判断材料にもなる。なお、可観測性ダッシュボードはTeamまたはEnterpriseプランの管理者・オーナー権限が前提など、機能ごとに利用条件が異なる点は一次情報での確認が必要だ。
Q. パブリックベータの機能を本番業務に使ってよいのか? A. 一律の正解はないが、「ベータだから禁止」と「ベータでも無条件に許可」の二択にしないことだ。仕様変更・提供中止があり得る前提で、①止まっても業務が破綻しない用途に限る、②代替手段(従来のバッチ・手作業)を残す、③ベータ機能の利用箇所を台帳化しておく——の3条件を満たすなら、ベータ段階から知見を貯める価値は大きい。GA(一般提供)を待ってから検討を始めると、競合はその間に運用ノウハウを積んでいる。
いつGXOに相談すべきか
- エージェントのPoCは動いたが、定時実行・秘匿管理・監視を含む本番運用設計 を自社だけで組み切れない(セキュリティ部門の指摘に答えられない場合を含む)
- RPA・夜間バッチの置き換え候補を 業務の定型性とリスクで仕分け し、段階的な移行ロードマップを作りたい
- 社内システムと繋ぐ MCPコネクタの設計・実装と、その後の運用監視 まで含めて任せたい
GXOは、AIエージェント導入支援でPoCから本番移行までの運用設計・実装を伴走し、DX・システム開発で既存業務システムとの組込み・自動化を支援している。プラットフォーム機能の進化を踏まえた「いま作るべき部分・待つべき部分」の切り分けから相談できる。→ AIエージェント本番化の相談はこちら
関連記事
- AIエージェントが本番に出せない理由2026|準備度・ガバナンス・発注設計
- Claude Fable 5登場|AI開発のコスト試算とモデル選定
- AIエージェント導入前チェックリスト|コスト暴走を止める設計
- セゾンテクノロジー「Agent Orchestration」発表|野良AIエージェント統制基盤が月額68万円から
参考資料
- Anthropic(Claude公式ブログ)「New in Claude Managed Agents: run agents on a schedule and store environment variables in vaults」(2026年6月9日)
- Anthropic(Claude公式ブログ)「Connector Observability and In-App Directory Submission」(2026年6月8日)
- Releasebot「Anthropic Release Notes - June 2026」(二次情報)
本記事は2026年6月12日時点の公開情報をもとに作成。スケジュール実行・Vault環境変数・コネクタ可観測性はいずれもパブリックベータであり、対応プラン・機能範囲は変更される可能性があるため、Anthropicの一次情報の最新版を必ず確認すること。
「PoCは動いた。でも本番に出せない」を終わらせませんか
定時実行・秘匿情報・可観測性・コスト上限・人手承認——本番移行に必要な運用要件の設計から、MCPコネクタの実装、移行後の監視運用まで一気通貫で支援します。プラットフォーム機能で済む部分と作るべき部分の切り分けから相談に乗ります。
※ 営業電話はしません | オンライン対応可 | PoC段階からの相談歓迎