エージェントにも帰りの切符が要る

ノートパソコンを閉じても、エージェントは働き続ける。少し便利になっただけに見える。ところが、何が一緒にクラウドへ移ったのかと問うと、話は変わる。

コードか。途中の作業か。リポジトリを読む権限か。それとも成果を公開する権限か。それぞれ別の乗客だ。同じ搭乗券を渡すと、思いがけず高くつく混乱が生まれる。

結論はシンプルだ。エージェントにも帰りの切符が要る。 長い仕事を移す前に、移動先で持つ権限、その権限が終わる仕組み、持ち帰るべき証拠を決めたい。役に立つ製品は、合意した範囲内で作られた、レビューできる成果だ。中断せずに何時間動いたかという数字だけでは、わかることは少ない。

Dockerが9月24日に発表したCloud Sandboxesは、この問いを身近にした。同社は、ローカルと同じコマンドラインから使える、Docker管理の計算資源上のmicroVM環境と説明する。これはベンダーによる説明であり、私が発行する安全性の証明ではない。Docker announcement

スーツケースと旅券

一人の創業者と、非常に熱心なコーディングエージェントがいる小さなソフトウェア会社を想像してほしい。課題は普通だ。公開デモを更新し、テストを実行して、パッチを用意する。創業者はパソコンを閉じて夕食に行きたい。エージェントは三十種類のものをインストールしたい。どちらの優先順位も理解できる。

手元の機械では、境界の一部が設定に埋め込まれているかもしれない。エージェントが見られる作業フォルダーは決まっている。届かない場所に認証情報がある。ローカルサービスには見慣れたアドレスがある。創業者はプロセスを止め、ファイルを調べられる。仕事を移すと、こうした前提が成立していた環境も変わる。

スーツケースに入るのは仕事の状態だ。ソース、中間成果、ログ、再開に必要な文脈。旅券に当たるのは権限であり、使える資源、起こしてよい効果、有効期間を定める。荷物が無事に届いても、旅券が移動先で有効だと証明されたことにはならない。

Dockerの比較文書は具体的な違いを示している。ローカルとクラウドではシークレットの保管先とネットワークポリシーが別で、ローカルのポリシーはコピーされない。クラウドはホスト上のパスにもアクセスできない。同じ操作画面から使えることと、実効アクセスが同じことは区別したい。Local and cloud comparison

購入者には有用な区別だ。曖昧な移行の約束が、答えられる質問になる。この設定を使ったこの移動先は、具体的にどの資源へアクセスできるのか。

権限には動詞がある

接続先のアドレスは権限の一部でしかない。リポジトリを読む、変更を提案する、リポジトリを削除する。どれも同じサービスで起こり得る。アクセス審査にサービス名だけを書くと、最も重大な決定が抜け落ちるかもしれない。

架空のデモプロジェクトに戻ろう。公開文書を読むことは課題に合っている。使い捨ての作業環境でパッチを用意することもそうだ。会社の名義でリリースを公開するのは、別の効果である。午後によく働いたからといって、エージェントが調査担当からリリース責任者へ自動昇格するわけではない。

私は許可する効果で仕事を記述したい。指定の公開入力を取得し、課題専用のコピーを変更し、パッチとテスト報告を返す。その返却物が製品だ。外部公開も行うなら、宛先と公開手順に結び付いた、対応する既存の権限が必要になる。

DockerのKit Specification v3発表は、エージェントの環境と宣言された機能をOCIイメージにまとめる仕組みを説明する。例ではHTTPメソッドとパスを区別できる。宣言はレビュー対象を具体化するが、適用されるポリシーを実際に執行するのは実行環境だ。Kit specification announcement

ここから一つの習慣を提案できる。二台の機械の差を調べる前に、二つの権限付与の差を調べる。少ない権限で済む仕事の移行は簡単になり得る。気付かないうちに広い権限を引き継ぐ移行も、危ういほど簡単に見えることがある。

別れの言葉が届かなかったプロセス

委任が興味深くなるのは、歓迎の打ち合わせが終わった後だ。仕事が取り消され、認証情報が失効し、あるいは最初の範囲が広すぎたとわかる。問いは「始められるか」から「まだ行動できるか」に変わる。

Dockerの9月21日リリースノートには、OAuthまたはAPI-keyの認証情報を失効させても、稼働中のプロキシがサンドボックス再作成まで認可されたままになり得た問題を修正したとある。過去の不具合の開示と、修正の報告だ。現在もその欠陥が残る証拠でも、あらゆる失効経路をここで検証した証拠でもない。Release notes

見落としやすいのは、二つの画面が穏やかに食い違えるからだ。管理画面では権限が終わっているのに、別の場所のプロセスには使える権限が残っている。整然とした設定画面が、実際の振る舞いよりも意図を正確に表してしまう。

受入試験なら、まずテスト用サービスに対する無害なリクエストを成功させる。通常の制御経路でテスト権限を取り消し、同じ稼働中ワーカーから再び送る。重要なのは、そのワーカーが失効後に何をできるかだ。全部を再起動してから確認すると、別の問いに答えることになる。

これは提案であり、Dockerに対して実施した試験ではない。使い捨ての認証情報と、無害な確認用に設計したサービスが必要だ。本番の鍵を使えば、限定的な実験を論じる場に、不要な実験をもう一つ持ち込んでしまう。

成果には帰路が要る

クラウドは仕事を実行する場所だ。所有者が何が起きたかを確かめられる唯一の場所にしてはいけない。この例で創業者が欲しいのは、パッチ、正確な開始リビジョン、実行したテスト、残る制約である。「順調でした」というメッセージは添え状にすぎない。

帰りの切符は、その証拠についての小さな契約だ。開始前に必要なファイルと受取先を決める。終了後には、届いたものが意図した成果物かを確認する。配達前に仕事が終われば、実行は終了していても、役に立つかどうかは未決のままだ。

Dockerのクラウド文書は、対応が実験段階で、有効なサブスクリプションとクラウド専用の認証情報が必要だと説明する。また、有効期限に達すると、再開可能なサンドボックスは停止され、ほかは削除される場合があると注意している。無人実行に頼る前に、保存条件を理解する必要がある。Cloud documentation

これは一般的な設計選択につながる。最後だけにエクスポートすると、成果のすべてを最終工程に賭けることになる。長い仕事なら途中のチェックポイントで復旧費用を下げられる。保存するのは仕事の証拠であり、不要な認証情報は除く。環境全体を複写しては、返却物を絞る意味がなくなる。

成果には読む人も要る。千ページのログは、技術的に閲覧可能でも、運用上は使いにくい。短い結果、再現できる確認コマンド、明確に名前を付けた例外。その背後に詳しい記録を置く方が、よい引き継ぎになることが多い。

受領記録で分けたいこと

架空のプロジェクトには五行の状態を用意したい。入力を確定した、作業を実施した、検査を通過した、成果を受領した、公開が許可されている。それぞれ違う問いへの答えだ。分けておけば、テストの成功を利用者への配達完了と言い換えずに済む。

例えばパッチは完成していても、公開依存先が使えず、テストが不確定になることがある。正しい記録はパッチを残し、どの確認が欠けたかを示す。パッチを捨てれば有用な作業を失う。全検査合格と書けば、有用な作業を作り話にしてしまう。

もう少し微妙な例もある。ワーカーがテストを終え、ファイルを送ったのに、受取側が別の開始リビジョンを見ている。両側が正しく動いていても、話している仕事が違う場合がある。入力と出力を識別する情報があれば、所有者は食い違いの場所を突き止められる。

Dockerの利用ガイドはファイル転送とライフサイクル操作を説明する。それらは配達の材料であり、特定企業の受入基準を満たすかどうかを決めるものではない。その判断は仕事の契約に置くべきだ。Cloud usage guide

次の図は私の概念整理である。移動先の権限を確立し、範囲を決めた仕事を行い、識別できる成果物を返し、検証する。失効と期限後の保存は全体に関わる。実測したベンダー性能を示す図ではない。

無人作業の本当の価格

エージェントのデモでは、中断なく働いた時間が魅力的な数字になりやすい。創業者に必要なのは、合格した成果一件を得る総費用だ。計算資源、モデル利用、人のレビュー、失敗した試行、復旧を含む。長い実行は、生産的かもしれず、無駄かもしれず、単に未完かもしれない。

二つの架空の運用が、同じ合格パッチを作るとしよう。一方は早く終わるが、ファイルの出所を調べるのに時間がかかる。もう一方は少し遅いが、既知の開始リビジョンとの差分を明確に返す。レビューと復旧を測らなければ、前者が間違った理由で安く見える。

待ち行列の問題もある。多数のワーカーを起動して役立つのは、その出力を評価する人か仕組みがある場合だ。レビュー能力が一定なのに出力だけが速く届けば、未受入の仕事が積み上がる。画面は緑の完了印で埋まり、創業者の夜はタブで埋まる。

この議論から、クラウド実行がローカルより高いとは言えない。必要な比較方法が見えるだけだ。同じ課題、同じ合格条件、失敗試行の同じ扱いを使い、証拠を取得して理解する時間も入れる。そうしなければ別の製品を比べている。

投資家の問いは、ベンダーの持続的な価値に向かう。顧客の総監督負担を減らすか。難しい仕事を可能にするか。合格成果が改善したから顧客が更新するのか。発表時の主張だけでは答えられず、便利な移行操作は一つの構成要素にとどまる。

小さな受入試験

架空の創業者は、大掛かりな実験をしなくても学べる。公開リポジトリを選び、正しさを容易に確認できる限定的な変更を課題にする。開始リビジョン、許可入力、書込先、期待するパッチ、決定的なテストコマンドを定める。顧客情報は不要だ。

環境を比較する前に、合格条件を固定する。正常系では期待した成果物、入力の識別情報、実際のテスト結果が戻ること。拒否された宛先は拒否されたままであること。テスト権限を失効させたら、稼働中ワーカーが宣言した運用上の期限内に対応する能力を失うこと。その期限は事前に選び、測定する必要がある。この文章には架空の測定値を置かない。

次に、中断を一つずつ入れる。操作側を切断する。使い捨てのケースで保存期限に達させる。返送を途中で止め、受取側が部分的な束と完全な束を区別できるかを見る。異なる失敗なので、最初から重ねれば証拠の解釈が難しくなる。

失敗や実行できなかったケースも含め、全試行を記録する。両環境で作業とレビューの規則をそろえる。課題で許された範囲より広い権限が必要になるなら止める。有用な結論は明確な制約でもよい。この流れは移せるが、あの依存関係には別の設計が要る、とわかれば前進だ。

提案は未実施である。引用した文書を読み、受入仕様を作ったが、移行の信頼性を測定していない。クラウドの仕事を走らせず、有料アカウントを開かず、本番の認証情報も試していない。よい問いは、完成した実験のふりをしなくても価値がある。この境界は大切だ。

旅の前に契約を

次の有用な到達点は控えめだ。名前のある課題を持ってワーカーが出発し、検査可能な移動先の権限の範囲で働き、所有者が検証できる成果を返す。権限が終われば対応する行動能力を失い、実行が終わっても証拠は合意した保存計画に従って残る。

この市場では四点を追いたい。宣言が実効的な実行時制御になるか。失効が既存プロセスまで届くか。中断した引き継ぎでも成果が残るか。合格成果一件の総費用が改善するか。それぞれ固有の証拠が必要で、一つの成功デモでほかまで決着したことにはならない。

創業者の直近の行動は、移行経路を選ぶ前に受入カードを保存することだ。供給者を評価する読者は、帰路と制御された失敗を含む、一度の完全な旅を見せてもらいたい。何が動き、何がアクセス不能のままで、どこに人の判断が残るかが答えに含まれてほしい。

望ましい未来は案外普通だ。パソコンを閉じる。エージェントが働く。レビュー可能な成果が届く。創業者は見えない運用部門まで引き受けずに夕食へ行ける。機械を一晩中忙しくするよりよい目標であり、試験できるほど具体的でもある。

分類とキーワード

分類： エージェント基盤、システム工学、企業向けソフトウェア。

キーワード： クラウドサンドボックス、実効権限、認証情報の失効、成果物の返却、合格成果。

Hashtags: #AgentInfrastructure #SystemsEngineering #EnterpriseAI #IAmRobin