マネージドエージェントが Harness に従うようになりました
午後 4 時、ある開発者の Claude Code セッションが、プラン変更に日割り計算を追加するために Billing API で作業セッションを開きます。20 分後、そのセッションがまだ作業している最中に、backend-fixer プロファイルでスケジュールされた Archyl の実行が、請求書の端数処理に関するチケットを拾います。これも Billing API の中にあるものです。
今週まで、スケジュールされた実行は次のように動いていました。マネージド実行ではすでにそうしていたとおり、自分の作業セッションを開きます。プリフライトゲートは warn を返し、理由は 1 target element(s) are being worked on by other active sessions — coordinate before changing them でした。この判定は実行のイベントフィードに表示されました。そして実行はそのまま始まりました。判定を受けて動くものが何もなく、スケジュールされた実行を見守っていて調整できる相手も誰もいなかったからです。
はっきり言っておきます。ホスト型の実行にとって、この包みはほとんど見せかけでした。ゲートは表示され、無視されていました。エージェントが変更したファイルはセッションに紐づけられることがなく、メモリはタスクの文面にたまたま出てきた要素に置かれていました。そしてセッションは 1 行の要約で閉じられ、次のエージェントが学べることはほとんどありませんでした。
それが今週変わりました。Harness がマネージド実行を統制するようになり、ホスト型の実行とローカルのコーディングエージェントが同じモデルの上で連携します。
エージェントを動かすことは簡単な部分になりつつある
この分野の大手 3 社が、エージェントを動かすためのホスト環境を提供するようになりました。Anthropic のドキュメントは Claude Managed Agents を「マネージドインフラ上で動作する、構築済みで設定可能なエージェント harness」と説明しており、クラウドまたはセルフホストのサンドボックス、永続セッション、cron によるスケジュール実行を備えています。9 月 10 日にパブリックベータとして発表された OpenAI の Agents API は、エージェントループを OpenAI のインフラ上で実行し、「オーケストレーション、長時間実行されるセッション、コンテキスト管理」を担います。同じ日に発表された Cursor Projects は、専用のクラウドマシン上にコーディネーターエージェントを置きます。このエージェントはサブエージェントに作業を委ね、スケジュールに沿って動いたり、あなたの pull request を追いかけたりできます。
どれも良いプロダクトで、同じ方向を指しています。サンドボックス、ツールループ、セッション、スケジュールは、リストから選ぶものになりつつあります。
ランタイムが単独では知り得ないもの、それはあなたのシステムです。請求書のコードがどの container に属しているか。誰がオーナーか。利用者が依存している契約。ある境界を意図的なものにした決定。そして誰も見ていないときに重要になる部分、つまり、このランタイムが起動していないものも含めて、別のどのエージェントがいまどの部分で作業しているか。
その知識はランタイムの中には置けません。あなたのエージェントが、すべて 1 つのランタイムで動いているわけではないからです。ノート PC で動くものもあれば、CI で動くもの、ホスト型のワーカーで動くものもあります。だから私たちはこう考えています。あなたのランタイム、私たちのアーキテクチャ。何がエージェントを動かしていても、エージェントが従うモデルは同じです。
4 月にリリースした Archyl 自身のマネージドエージェント実行も、そうしたランタイムの 1 つです。今週、ようやくその 1 つとしての振る舞いを始めました。実行をライブで見て、指示を出すこともできます。
実行が拒否されるようになり、その理由も伝えられる
連携はオプトインです。各エージェントプロファイルの 連携 に新しい設定 他のエージェントの作業を尊重する が加わりました。既定ではオフです。オンにすると、実行は作業セッションを排他的に開き、次に何が起きるかはゲートの判定で決まります。
別のエージェントが同じ要素のリースを保持していれば、実行は拒否されます。そのエージェントが誰かのノート PC 上の Claude Code でも、別のマネージド実行でも同じです。実行は何かをクローンする前に終了し、ゲートイベントには 実行が拒否されました と表示され、理由には誰がそこで何の作業をしているかが示されます。冒頭の午後の場合はこうなります。
session denied by preflight gate: "Billing API" is being worked on by
claude-code/vincent (add proration to plan changes)
形式は実物どおりで、タスクは例です。朝この実行を確認した人は、誰に話をすればいいかが正確にわかります。
ゲートが警告だけの場合、たとえば error レベルのガードレールがタスクに該当する場合は、実行は始まりもせず、失敗もしません。組織の同時実行枠を消費せずに 承認待ち で待機します。実行ページには理由が一覧表示され、承認して開始 と 実行をキャンセル が並びます。
承認は、古い判定をそのまま追認するものではありません。ゲートがもう一度評価されるので、実行が待っている間にローカルのエージェントがその要素のリースを取っていれば、承認された実行でもやはり拒否されます。24 時間以内に誰も承認しなかった実行はキャンセルされます。
待機中の実行が何も保持しない理由
実行が待機している間、そのセッションは破棄されます。警告を出したセッションはキャンセルされ、リースもそれと一緒になくなり、承認すると新しいセッションが開かれます。リースを保持したままにするほうが慎重に聞こえますが、実際には悪くなります。誰も承認しない実行が、1 日にわたってほかのすべてのエージェントをその要素から遠ざけ、実際には何も作業していないのに、何かが作業中だとそれぞれに伝え続けることになるからです。
これは 8 月に引いた線に沿ったものです。リースはアドバイザリーなもので、ロックではありません。排他性はプロファイルが求めるものであって、プラットフォームが課すものではありません。そして人を待っている実行は、何も確保しません。
Guard がワーカーの中に入った
セッションは意図を扱います。Guard は書き込まれる内容を扱います。ローカルのエージェントは 8 月から Claude Code フックとしてこれを使っており、マネージド実行でもワーカーの中で同じチェックが行われるようになりました。
プロジェクトにリポジトリがリンクされている場合、エージェントによる write_file と edit_file はすべて、変更が反映される前にプロジェクトの適合性ルールと照合されます。critical な違反があれば書き込みは拒否され、エージェントはどのルールに、なぜ違反したのかを読むことになります。
blocked by Archyl Guard: 1 critical architecture violation(s) in
backend/internal/adapter/http/handlers/invoice.go. Change the content so it
conforms, then write again:
- [critical] No direct database access from HTTP handlers — move the query behind a service
エージェントはクエリを移動し、もう一度書き込みます。high の違反では、書き込みは警告付きで反映されます。チェック自体が失敗したりタイムアウトしたりした場合、書き込みは通ります。Guard が自分のエラーでエージェントを止めることはありません。統制している作業を壊してしまうガバナンスのチェックは、いずれ無効にされてしまうからです。
各チェックにはセッション ID も含まれており、エージェントが作業している間に、そのファイルを実行のセッションに紐づけます。これが 2 つ先のセクションで効いてきます。
エージェントはセッションを知っているが、所有はしていない
実行のプロンプトは、そのセッションを名指しし、プラットフォームがセッションを開き、閉じることをエージェントに伝えます。「そのため、呼び出すべきセッションツールはありません」。エージェントは 2 つ目のセッションを開くことも、このセッションを早めに終えることもできません。ライフサイクルはプラットフォームのものです。実行がいつ終わったかを知っているのは、プラットフォームだけだからです。
エージェントが所有しているのは、作業についての自分の報告です。終了する直前に report_outcome を 1 回呼び出し、正直な要約、ADR に値する決定事項、やり残した作業のフォローアップ、そして頼りにしたブリーフィングのメモリを渡します。ツールの説明は、その場限りの発見を決定事項に含めないよう指示しています。決定事項は将来のセッションで再生されるので、デバッグのメモが誰かを縛るべきではないからです。
成果は作業が行われた場所に残る
実行が終わると、Archyl はまず、実行が変更したファイルをセッションに紐づけます。これで 3 つの欠落のうち、いちばん目立たなかったものが解消されます。セッションがリースする要素はタスクの文面から推定されますが、タスクの文面は推測にすぎません。変更されたファイルは、実際に起きたことです。メモリは、チケットが言及したものすべてではなく、実際の作業が触れた要素に置かれるようになりました。
次にセッションを閉じ、要約をそれらの要素のメモリとして保存し、エージェントが使ったと申告したメモリを評価に加えます。これがメモリのランキングが学習に使うシグナルです。
決定事項が記録されるのは、実行が成功した場合だけです。決定事項はプロジェクトのメモリになり、Architecture Change Request（アーキテクチャ変更リクエスト）のドラフトを作成するので、モデルがどう追いつくべきかを人がレビューします。失敗した実行は要約とフォローアップを残します。次の試行に必要なのはそれですが、決定事項は記録しません。完了しなかった作業には、拠って立つものがないからです。
実行ページには、これらすべてが 作業セッションの成果 カードにまとまって表示されます。要約、決定事項、フォローアップ、触れた要素、引用されたメモリ、そして Change Request へのリンクです。別のセッションが保持している要素には 別の作業セッションが保持中 の印が付くので、他人のリース内のコードを編集した実行が見過ごされることはありません。
2 種類のエージェント、1 つのモデル
これは多くのエージェント、ひとつのアーキテクチャが目指していたピースです。プロセスを共有することのないエージェント同士の、双方向の連携です。
マネージド実行は managed-agent/<profile name> としてセッションを開きます。この記事の冒頭の場面を逆にしてみましょう。スケジュールされた実行が Billing API で作業しているところに、開発者が Claude Code を起動します。そのブリーフィングには、実行が競合として表示されるようになりました。
- **Conflicts** (someone else is already working here):
- Billing API — held by managed-agent/backend-fixer: fix rounding on prorated invoices
ローカルのエージェントはその要素を変更する前に調整するよう指示され、Fleet コンソールには両方のセッションが表示されます。そしてどちらが終わっても、もう一方が次回読むメモリが残ります。
今週リリースしたその他の機能
ほかの部分がこの上に成り立っているので、簡単に触れておきます。プロファイルには組み込みのスキルとツールの許可リストが付くようになり、読み取り専用のレビュアーを read_file、list_*、get_* に限定できます。ワーカーのハートビートが停止した実行を検知して片付け、各実行の API キーは実行の終了時に失効し、失敗した実行でも作業内容をドラフトの pull request として公開します。実行は常に Archyl 自身のワーカーで行われ、BYO が有効な場合は組織の AI プロバイダーを使います。
できないこと
連携で見えるのは Harness を使うエージェントだけです。 リースが存在するのは、エージェントがセッションを開いたからです。セッションなしでリポジトリを編集しているエージェントはゲートからは見えず、他のエージェントの作業を尊重する実行でも、そのすぐ隣で始まってしまいます。
ワーカーはテストを実行しません。 ワークスペースのファイルツール（読み取り、書き込み、編集、一覧、grep）はありますが、シェルはありません。プロジェクトのビルドもテストスイートの実行もできないので、成果カードがきれいでも、それは書き込みが Guard を通過したという意味であって、コードがコンパイルできるという意味ではありません。その役目は引き続き CI が担います。
エージェントの決定事項はレビューされていません。 成果カードにある決定事項は、誰かが Change Request をレビューするまではエージェントの主張にすぎません。そのレビューこそが肝心で、形式的な手続きではありません。
Guard にはチェックの基準が必要です。 リンクされたリポジトリがなければ書き込みチェックは行われず、適合性ルールが空であればすべての書き込みが通ります。
どこから始めるか
人が手でも変更するコードに対してスケジュールで動いているプロファイルを 1 つだけ選び、連携 の 他のエージェントの作業を尊重する をオンにしてください。ほかのプロファイルはそのままにしておきます。
実行が拒否されたら、その理由には、重なっていたエージェントとタスクが示されます。これまでなら、その重なりは誰にも知られないまま通っていたはずです。
マネージドエージェント実行、作業セッション、Guard、メモリは archyl の機能です。ここで挙げた設定はすべてマネージドエージェント実行のドキュメントに、ローカル側については Harness ガイドにまとめています。関連記事：多くのエージェント、ひとつのアーキテクチャ、コーディングエージェントのための作業セッション、AI コーディングエージェントのメモリ、マネージドエージェント実行のリリース。