今週の問い：エージェントをクラウドへ移すとき、何を一緒に移してはいけないか

ローカルで便利だったコーディング・エージェントをチームで動かそうとすると、モデルの選択より先に、誰がツールを実行し、どこに状態を残し、どの操作を止められるかが問題になります。今週の材料は、エージェントのループと実行を同じプロセスに閉じ込めない設計です。

今週の結論は三つです。

  1. クラウド化の要点は、CLIをコンテナへ載せ替えることではなく、制御ループ、機密性の高いツール実行、セッション状態を分離することにある。
  2. 状態を中央で管理できても、ツールへ渡す権限・ネットワーク・データの境界を狭くしなければ安全性は上がらない。
  3. 導入の最初の単位は「全社エージェント基盤」ではなく、一つの読み取り専用タスクの実行契約でよい。

今週選んだ記事と、人気の判断

媒体 選定記事 公開日 選定根拠
Latent Space Can a Cloud-Native Harness Make Agents Reliable Beyond the Desktop? 10月7日 記事ページには52と4の数値が表示された。項目ラベルと閲覧数は公開範囲で確定できないため、反応の代替指標としてのみ扱う。
The Pragmatic Engineer 今週の対象なし — 取得できたアーカイブは人気順表示で、直近7日間に公開された記事を確認できなかった。

ハーネスを「モデルを呼ぶ箱」から、分けて運用する基盤へ

Latent Spaceの記事（2026年10月7日）は、Stacklokのオープンソース・プロジェクトMecatlを、クラウドネイティブなエージェント・ハーネスとして紹介しています。ここでいうハーネスは、LLMがツールを呼び、必要な文脈を引き継いで仕事を進める周辺の実行環境です。

記事で中心になるのは、エージェントのループを、クライアント、モデル提供者、状態ストア、実行環境から独立させるという考え方です。Stacklok側の説明では、ツール呼び出しやシェルのような機密性の高い操作、セッションとメモリの管理を、ループと別の管理可能なシステムへ置くことを目指しています。ローカル向けの一体型プロセスをそのままVMやコンテナへ移す方式では、停止・人の介入待ち・権限の切替を扱いにくい、という前提です。

これは性能比較の結論ではありません。Mecatlを使えば信頼性が上がる、と実測で証明した独立評価でもありません。けれど、エージェントにリポジトリや社内APIを触らせる場面で、会話履歴と同じ場所に「何を実行してよいか」まで置かない、という設計上の問いを具体的にしてくれます。

公式発表が示す、移行の時間軸と実行環境の選び直し

10月9日のDenoの公式発表は、DenoチームがCloudflareへ加わり、今後の開発を共通プラットフォームへ集中させることを伝えました。Deno runtimeは今後1年間、月次のバグ修正・セキュリティ更新を続け、その後は開発を終える予定です。Deno Deployは6か月後に終了し、有償顧客にはCloudflare Workersへの移行支援を行うとされています。

同発表は、Durable Objectsが、安価なサーバーレス実行、永続状態、WebSocket、高水準のJavaScript APIを組み合わせ、エージェント・ハーネスに有用な性質を持つと述べます。これはStacklokの記事の「制御ループと状態をデスクトップから切り離す」という問題意識と重なります。ただし、Denoの事業上の移行予定と、Mecatlのアーキテクチャは別の話です。片方がもう片方の採用根拠になるわけではありません。

Simon Willisonの10月9日の投稿は、この発表を受け、Denoの権限モデルとNode.jsの権限機能を比較しています。特定ネットワークホストの許可リストはNode.jsではまだ扱えない、と指摘しています。ここからの編集部の整理として、実行基盤を中央へ寄せるほど、リポジトリ読取、書込み、ネットワーク、外部操作を個別に許可できるかを確認する価値が上がります。

一致する点、食い違う点、未解決点

一致する点は、状態と実行をアプリの副産物ではなく、運用する対象として扱うことです。Latent Spaceの記事はループ・ツール・状態の分離を、Denoの発表は状態を持つサーバーレス実行の方向性を、それぞれ異なる文脈から示します。

食い違う点は、対象の規模です。Mecatlの議論は企業がエージェントを統制するためのハーネスを扱い、Denoの発表はランタイムとホスティングの将来を扱います。個人用CLIを使うだけなら、Kubernetesや中央制御面を直ちに導入する理由にはなりません。

未解決点は、分離した境界を誰が日々保守するかです。権限を狭めれば設定と例外処理は増えます。エージェントが失敗したとき、再実行する人、承認する人、実行ログを読む人を決めなければ、構成を分けても責任は曖昧なままです。

今週覚える用語

自分の開発・学習・キャリアへの意味

エージェントを使う開発では、「どのモデルが強いか」と同じくらい、「そのモデルが何を実行できるか」を説明できる必要があります。ツールの実行と状態を分けて考える習慣は、クラウド基盤を採用しなくても、CI、データ取り込み、社内ボットの設計にそのまま使えます。小さな自動化から、許可する操作と停止したときに残す記録を言語化しておくと、後でチームへ広げる判断がしやすくなります。

今週20分で試すこと：一つの自動処理に実行境界を描く

対象: 自分のリポジトリにある、AIを使うかどうかを問わず、複数の外部操作を行う自動処理を一つ選びます。CI、デプロイ前チェック、データ取得、Issue下書きなど、コードまたは設定だけを読めるものに限ります。

  1. 5分で、処理が読むもの、書くもの、ネットワークへ送るものを三列に分けて書き出します。
  2. 5分で、各列から「常に許可」「人の確認後だけ許可」を一つずつ選びます。
  3. 5分で、停止した場合に残る記録（ログ、ジョブID、出力ファイルなど）を一つ確認します。
  4. 5分で、同じ処理を再実行したときに二重実行してはいけない操作を一つ記録します。

完了条件: 一つの自動処理について、権限を渡す境界、停止後に読む記録、再実行前に確認する操作を各一つ説明できることです。

参照元

中心となる原資料を確認する ↗