マネージドエージェント vs ローカルエージェントハーネス：何を残すべきか

AnthropicとOpenAIは、エージェントランタイムインフラを製品レイヤーへと変えつつあります。ホスト型セッション、サンドボックス、トレース、メモリ、ハンドオフ、ルーブリック、イベントストリームは、もはやチームのプライベートなスクリプトフォルダではなく、モデルプロバイダ側に置かれるようになりました。¹²

要点は何か？

• マネージドエージェントはランタイム層になりつつあります。 プロバイダがチームのセキュリティ基準を満たす場合、セッション、サンドボックス、トレース、イベント、非同期実行は、マネージドインフラに置かれるべき領域へと移行しつつあります。¹²
• ローカルハーネスは依然として重要です。 美意識、エビデンス、公開記事の整合性、プライバシー境界、ソース検証、プロジェクトメモリをコード化している部分は、必ず残しましょう。
• 移行の単位はコマンドではなく、ジョブです。 スラッシュコマンド、Codexスキル、SDKハンドオフ、MCPサーバー、マネージドアウトカムのいずれであっても、受入基準が保たれていれば同じワークフローを担えます。
• プライベートな仕掛けを公開してはいけません。 公開記事ではパターンと受入基準を説明すべきであり、プライベートなプロンプト、フックの中身、アカウント情報、内部スコアリングルールを書くべきではありません。
• 昇格には証拠が必要です。 明示呼び出しのみのモードから始め、実際のタスクを1つ走らせ、結果を記録し、ユーザーから見える経路が改善された場合にのみ昇格させましょう。

マネージドエージェントプラットフォームは、コモディティ化したランタイム作業を吸収すべきです。サンドボックス実行、状態を持つセッション、イベントストリーム、トレース、ファイル実行、非同期完了などです。ローカルハーネスは依然として重要ですが、その役割はより小さく、より鋭くなっていきます。製品としての美意識、エビデンスゲート、公開記事の整合性、プライバシー境界、ソース検証、プロジェクト固有の運用メモリをコード化している部分は残しましょう。誰もまだランタイムをパッケージ化していなかったから存在しているだけの部分は移しましょう。

悪い移行の典型は、プロバイダがマネージドインフラを出したからといってローカルハーネスを丸ごと消してしまうことです。もう一つの悪い移行は、かつて実際の課題を解決したからという理由だけで、すべてのローカルコマンド・フック・プロンプトを温存することです。正しい移行は、コンポーネントごとに1つの問いを立てます。これは自分の基準をコード化しているのか、それとも単に機械を動かしているだけなのか。

より広いアーキテクチャについては、AI Agent Architecture guideをご覧ください。本記事の背後にある実際のローカル移行パターンについては、Claude Code to Codex Migration Guide、AGENTS.md Patterns、Jiro Quality Philosophyをご参照ください。

この分割の「ローカルツール側」については、Claude Code as Infrastructureがプライベートなランタイム層が育つ理由を説明しており、Claude Code vs Codex CLI 2026はアクティベーション面と安全面を比較しています。

マネージドエージェントで何が変わったのか？

Claude Managed Agentsは、マネージドインフラ上で動作する事前構築済みのエージェントハーネスを開発者に提供します。Anthropicはこれを、長時間実行タスクや非同期作業に適するものとして説明し、エージェント、環境、セッション、イベントといったコアコンセプトを示しています。¹ 同じドキュメントには、Claudeがファイルを読み、コマンドを実行し、ブラウジングし、コードを実行し、MCPサーバーを使い、イベント履歴をサーバー側で永続化できるマネージド環境が記述されています。¹

Anthropicのエンジニアリング解説は、製品ドキュメントよりも明快にアーキテクチャ上のポイントを伝えています。Managed Agentsチームは、セッションログ、ハーネス、サンドボックスをそれぞれが独立して失敗・変更できるよう分離しました。³ この分離が重要なのは、壊れやすい1コンテナのエージェントループを、復旧可能なセッション状態、置き換え可能な実行環境、認証情報まわりの絞られたセキュリティ境界を持つシステムに変えるからです。³

OpenAIもAgents SDKを通じて同じ方向に進んでいます。2026年4月15日のアップデートでは、モデルネイティブなハーネス、ネイティブのサンドボックス実行、ワークスペース用のマニフェスト抽象化、そしてMCP、スキル、AGENTS.md、シェル実行、パッチ適用といった共通プリミティブのサポートが追加されました。² SDKのドキュメントはまた、マルチラン記憶のためのセッション、LLM生成・ツール呼び出し・ハンドオフ・ガードレール・カスタムイベントのトレース、専門エージェント間で作業を引き継ぐためのハンドオフを公開しています。⁴⁵⁶

ニュースとしてはここまでです。戦略上の問いは別物です。プラットフォームがエージェントランタイムを提供するようになった今、ローカルハーネスは何を担うべきなのでしょうか。

ランタイムと判断の境界線はどこか？

ほとんどのローカルエージェントハーネスは、本来は必ずしも一緒に置く必要のない2つの仕事を混ぜ込んでいます。

1つ目はランタイムインフラです。ランタイムはセッションを開始し、ツールを付与し、ワークスペースを準備し、コマンドを実行し、イベントを保存し、中断を処理し、作業を再開し、ステータスをストリームし、トレースを記録します。この仕事は標準化に向いています。また、よほどの理由がない限り、個々のチームが自前で再構築すべきではないセキュリティエンジニアリングの恩恵も受けやすい領域です。

2つ目は判断です。判断は、良い仕事とは何か、どの公開記述に一次ソースが必要か、ガイドが古すぎて公開すべきでないのはいつか、フックがうるさすぎて強制適用すべきでないのはいつか、ソーススキャンを記事ではなくノートにとどめるべきはいつか、技術的には正しいが製品として相応しくない出力をエージェントが拒むべきはいつか、を決めます。この仕事は、製品、チーム、読者から生まれるものなので、ローカルに残ります。

マネージドインフラはより良いループを動かせます。しかし、自分たちの美意識がどうあるべきかは決められません。

何をマネージドエージェントへ移すべきか？

製品基準をコード化していないコンポーネントを移しましょう。

AnthropicのOutcomes機能は、この潮流の次の方向を示しています。開発者がルーブリックを定義し、マネージドハーネスが別途グレーダーをプロビジョニングし、エージェントはグレーダーのフィードバックに対して反復します。⁷ これによってローカル基準が消えるわけではありません。基準にランタイム上の居場所が与えられるのです。

同じパターンはOpenAIのトレースにも当てはまります。SDKは、ラン、エージェントスパン、生成、関数ツール呼び出し、ガードレール、ハンドオフをデフォルトでトレースし、トレース無効化や別の宛先向けプロセッサも備えています。⁵ ローカルスクリプトでも近いことはできますが、本番システムは標準化されたトレースを使い、チームが既にデバッグしている場所へ送るのが通常は望ましい選択です。

ローカルに残すべきものは何か？

自分の基準、読者、プライベートな運用コンテキストを定義するコンポーネントは残しましょう。

製品としての美意識。 プラットフォームはタスクを実行できますが、その結果が製品全体を良くしているかどうかは判断できません。雑然とした出力、汎用的な出力、品位の低い出力を退けるための美意識ルールは残しましょう。

エビデンスゲート。 当該セッション中の証拠、ユーザー経路の検証、ギャップの明示、根本原因分析を要求するルールは残しましょう。マネージドトレースは「何が起きたか」を教えてくれます。それで証拠として十分かを決めるのは、あなたの基準です。

公開記事の整合性。 引用ルール、ソース階層ルール、プライベート境界のチェック、SEO/AIOチェック、公開ゲートはサイトの近くに残しましょう。プライベートなワークフロー詳細のうち何を公開して安全かを、モデルプロバイダに決めさせてはなりません。

プロジェクトメモリ。 簡潔なプロジェクト規範、スタイル決定、既知の落とし穴、リリース境界、運用ログは、チームが点検できる場所に置きましょう。マネージドセッションストアが本当に耐久性を高める場合のみ、ストレージ層だけを移します。

ソースインテリジェンス。 編集ルーティング層は残しましょう。スキャナーは14件の良質な候補を見つけても、正解の打ち手がモニタリング、ガイド更新、プライベートノートのいずれかであれば、ゼロ件の記事しか生まないことがあるのです。

昇格ポリシー。 段階的導入のルールは残しましょう。スキルは明示呼び出しのみで開始し、フックはシャドウで動かし、プラグインは実作業が「邪魔より助けになる」と証明するまでインストール済みパイロットの状態で寝かせる、といった運用です。

このリストこそが本物のハーネスです。ファイルやコマンドは、その実装の一形態にすぎません。

チームが避けるべき移行の失敗とは？

この移行を最も簡単にしくじる方法は、ジョブではなく形だけを残すことです。

Claude Codeのスラッシュコマンド、Codexスキル、SDKツール、マネージドアウトカム、MCPサーバーは、同じものに対する互換構文ではありません。これらは異なるアクティベーション面です。スラッシュコマンドはスキルになるかもしれません。スキルはマネージドアウトカムのルーブリックになるかもしれません。フックはトレースプロセッサになるかもしれません。プラットフォームがセッションやWebhookを公開した瞬間、ローカルスクリプトは不要になることもあります。

Anthropicの長時間実行エージェントに関する解説は、逆方向から同じ点を述べています。コンパクションだけでは本番品質の作業は生まれず、効果的なパターンは機能リスト、進捗成果物、整理されたハンドオフ状態、エンドツーエンドのテストを加えていました。⁸ これらはUI規約ではなく、証明義務なのです。

移行で問うべきは「/scan-intelをどこに置くか」ではありません。「ソースインテリジェンスのワークフローはどんな仕事を担っていたのか」です。

ソーススキャナーの仕事は「コマンドを実行する」ことではありません。設定済みのソースをスキャンし、ソース到達性を証明し、候補をスコアリングし、低シグナルの広範な書き込みを拒否し、有用なノートをプライベートに保ち、公開すべき機会を編集レビューへルーティングする──これがジョブです。アクティベーション用の語句が変わっても、ワークフローは失われません。

同じルールが品質ドクトリンにも当てはまります。プライベートなプロンプト集を公開してはいけません。ドクトリンを観測可能な完了ゲートに変換しましょう。すなわち、エビデンス、ユーザー経路の検証、プライベート境界のレビュー、そして製品を弱める作業を拒む権利です。

ソースインテリジェンスのスキャナーにどう適用するか？

ソースインテリジェンスのスキャナーは、この分割を具体的に示してくれます。

ランタイム側は移せます。マネージドプラットフォームはスケジュールジョブを動かし、セッションを保存し、ブラウザやフィード取得のツールを実行し、イベントを発行し、トレースを保持できます。スキャンがタイムアウトしても、マネージドセッションは「何が動いたか、どのソースが失敗したか、次のランはどこから再開すべきか」を把握しているはずです。

判断側はローカルに残しましょう。スキャナーには依然として、プライベートなソースマップ、スコア閾値、重複チェック、書き込み量の制限、編集ルートが必要です。14件の候補を見つけたスキャンが、自動で14件のノートや1本の記事を出してはいけません。正解は、プライベートノート、ガイド更新タスク、モニタリングキュー、あるいは「何も公開しない」という拒否であることもあるのです。

この区別が、騒がしい自動化を有用なワークフローへと変えます。

同じロジックは、コーディング、ガイド保守、翻訳、公開記事のワークフローにも当てはまります。プラットフォームの方が上手にできる実行機構は移しましょう。「その出力が存在に値するか」を決める基準は残しましょう。

ハーネスを移す前に使うべきチェックリストは？

ローカルハーネスのコンポーネントをマネージドエージェントプラットフォームに移す前に、このチェックリストを使ってください。

昇格の道筋は、退屈なまま保ちましょう。

1. コンポーネントを棚卸しする。
2. それが担うジョブに名前を付ける。
3. ランタイム、判断、メモリ、公開、ソースインテリジェンス、安全性のいずれに分類されるかを判定する。
4. 最小限の有用な版を移植する。
5. 実際のタスク1件で動かす。
6. 何が起きたかを記録する。
7. 昇格、改訂、または削除する。

これ以上凝った手順は、たいてい不確実性を覆い隠しているだけです。

今日、現実のハーネスをどう分割すべきか？

本格的なコーディングと執筆のセットアップであれば、私はこう分割します。

プロバイダまたはマネージド層：

• サンドボックスの作成
• ファイル実行
• 永続セッション
• イベントストリーム
• Webhook
• トレースとスパン
• 長時間実行ワーカーの復旧
• 基本的なマルチエージェントの委譲
• プロバイダが対応する場合のルーブリック実行

ローカルまたはプロジェクト層：

• AGENTS.mdまたは同等のプロジェクトポリシー
• 公開記事の基準
• 引用とソース階層のルール
• 製品品質ドクトリン
• プライベートな運用メモリ
• サイト固有のSEO/AIOチェック
• ソースインテリジェンスのルーティング
• 最終公開ゲート
• プラグインや共有パッケージのリリース境界ポリシー

分割線は「マネージドかセルフホストか」ではありません。分割線は「コモディティ化したランタイムか、製品としての判断か」です。

マネージドエージェントで依然として注意が必要な点は？

マネージドエージェントプラットフォームは、難しい部分を消し去りはしません。場所を移すだけです。

ツール、ファイル、ネットワークアクセス、認証情報のセキュリティモデルは依然として必要です。Anthropicのアーキテクチャは、生成コードを動かすサンドボックスと認証情報を明確に分離していて、これは正しい方向ですが、それでもチームはリソース、シークレットボルト、アクセス境界を正しく構成する必要があります。³

可観測性も依然として必要です。トレースは呼び出しグラフを示せますが、その仕事に出荷の価値があったかどうかは教えてくれません。グレーダーはルーブリックを評価できますが、そのルーブリックが正しい美意識を表現しているかは判定できません。

コンテンツの境界も依然として必要です。公開用の移行記事はパターンを説明できますが、プライベートなプロンプト、フックの内部、プライベートなファイルパス、ソースリスト、アカウント情報、独自の編集スコアリングを丸出しにしてはいけません。

段階的導入も依然として必要です。Anthropicは、Managed Agentsはベータ段階であり、すべてのエンドポイントにmanaged-agents-2026-04-01ベータヘッダが必要で、一部の機能はプレビューアクセスを要する旨を明記しています。¹ ベータ段階のランタイムは、すべてのワークフローのデフォルト経路にしなくても十分有用に使えます。

持ち帰るべきポイントは？

エンジニアリングリーダー向け：

• プラットフォームがセキュリティ基準を満たすときは、ランタイム作業をマネージドセッション、サンドボックス、イベント、トレースへ寄せましょう。
• エビデンス、ソース品質、製品としての美意識、リリース境界に関するローカル基準は残しましょう。
• マネージドルーブリックは、自分たちの基準を実行に移すためのスロットとして扱い、基準の置き換えとは見なさないことです。

エージェントを作る人向け：

• コマンドを1対1で移植してはいけません。ジョブベースで移植しましょう。
• 明示呼び出しのみから始め、実タスクが価値を証明したら昇格させましょう。
• プライベートなプロンプト考古学よりも、トレース、セッションログ、公開成果物を優先しましょう。

公開記事を書く人向け：

• プライベートなプロセスを、公開可能な受入基準へと変換しましょう。
• 現在の挙動については、公式の製品ドキュメントを引用しましょう。
• より良い記事が「判断のフレームワーク」になり得るときは、振り返り型のリキャップを書くのを断りましょう。

簡潔なまとめは？

マネージドエージェントプラットフォームは、ローカルハーネスを「不要」にするのではなく「より小さく」します。プラットフォームがその信頼に値するときは、ランタイム作業をマネージドセッション、サンドボックス、トレース、イベント、オーケストレーションに移しましょう。品質、エビデンス、プライバシー、公開記事の整合性、そして「どの仕事が出荷に値するか」を定義するローカル基準は、残しましょう。

FAQ：マネージドエージェントとローカルハーネス

マネージドエージェントはローカルAIエージェントハーネスを置き換えますか？

いいえ。マネージドプラットフォームが置き換えるのは、より多くのランタイム層──セッション、サンドボックス、イベントストリーム、トレース、ツール実行などです。製品基準、エビデンスゲート、公開記事のルール、プライバシー境界、ソースインテリジェンス、プロジェクト固有のメモリをコード化している場合、ローカルハーネスは依然として重要です。

AGENTS.mdやCLAUDE.mdに何を残すべきですか？

長期的に通用するプロジェクトルールを置きましょう。製品が大切にしているもの、完了をどう検証するか、公開してはいけないプライベート情報、公開記事のチェック方法、タスクが完了とみなされる前に動作していなければならないユーザーから見える経路、などです。一過性のツール出力やプライベートなプロンプト本文を、恒久的な指示ファイルに詰め込んではいけません。

マネージドエージェントプラットフォームをいつ使うべきですか？

長時間実行、安全なコンテナ、耐久性のあるセッション、イベントストリーム、非同期完了、トレース、マネージドなマルチエージェントオーケストレーションが必要な作業に対し、プロバイダのセキュリティ、コスト、データコントロールがユースケースに合うときに、マネージドインフラを使いましょう。¹²

公開ハーネスパッケージに入れてはいけないものは何ですか？

プライベートなプロンプト、フックの中身、機微なファイルパス、アカウント識別子、トークンの取り扱い、プライベートなソースリスト、独自のスコアリングルール、その他「他人があなたの内部運用システムを再構築できてしまう情報」は公開してはいけません。公開すべきはパターンと受入基準です。

References