エージェント型コーディングCLIの内側：ループ・文脈・権限

モデルは簡単な部分だ。少なくとも、それが主張だ。ここ数年、数十ものエージェント型コーディングCLIが登場し、フォークされ、そして躓くのを見てきたが、この主張は正しいと思う。エージェント型コーディングCLIの成否を決めるのは、モデルではなくハーネスだ。オープンソースでターミナルベースのコーディングエージェントであるOpenCode 2.0のリリースは、今週大きな注目を集めたが、それをあえて口にするいい機会だ。このリリースで注目すべき点は新しいモデル連携ではない。クライアント／サーバー分離、ホットリロード可能なプラグイン、バックグラウンド実行可能なタスク、そして再設計されたエージェントループだ。言い換えれば配管の話であり、その配管こそが製品なのだ。

私は元MLエンジニアなので、この結論には正直イラっとした。モデルの品質で差がつくと思いたかった。しかし、これらのツールを使い続けるか見限るかを考えると、理由は決まって「モデルが賢くなったから」ではない。「コマンドを一つずつ承認させられなくなったから」「再起動なしで設定を再読み込みしてくれるようになったから」「リモートのマシン上で動くセッションにGUIを接続できるようになったから」なのだ。コーディングエージェントが実際に役立つかどうかを決める3つのサブシステム、つまりツール呼び出しループ、コンテキスト管理、権限モデルを分解してみよう。そのうえで、この逆張りの主張がどこで崩れるかも認めておく。

ツール呼び出しループは分散システムである

マーケティングの言葉を取り除くと、どのコーディングエージェントも同じプログラムだ。プロンプトとツールの一覧をモデルに渡し、テキストかツール呼び出しのどちらかを受け取り、ツールを実行し、結果を追記して繰り返す。このループは単純に聞こえる。だが実際は単純ではなく、そこを単純だと扱うツールは、実際に使い始めて5分もすればガタついて感じられる。

このループが実際に扱わなければならないものを考えてみよう。ツールの実行は失敗する。コンパイラはエラーを吐き、テストスイートは固まり、モデルがでっち上げたパスにはファイルが存在しない。モデルはツール引数として不正なJSONを出力する。ツール呼び出しに40秒かかり、ユーザーが実行中にEscapeを押す。1ターンで2つのツール呼び出しが届き、片方が失敗したらもう片方は実行されてはならない。タスクの途中でコンテキストウィンドウが埋まり、どこかで何かを手放さなければならない。これらはすべて並行性と障害処理の問題であり、知能の問題ではない。私は以前、LLMエージェントは分散システムにすぎないと論じたが、コーディングCLIはその最も純粋な例だ。信頼できない非決定的なリモートコンポーネント（モデル）が、ローカルで副作用を持つコンポーネント（シェル、ファイルシステム、LSP）と協調しており、そのループこそが両者の合意プロトコルなのだ。

OpenCode 2.0がEffectを中心にループを作り直したと報じられている点も、ここで重要になる。Effectは構造化並行性と型付きエラーのためのTypeScriptフレームワークだ。この選択は、チームがループを「fetchを含むwhile文」として扱うのをやめ、中断可能で合成可能、リトライ可能な、明示的なエラーチャネルを持つ効果のシステムとして扱い始めたことを示している。エージェントループに本物のキャンセル意味論があれば、「ユーザーがEscapeを押す」は状態の破損ではなく第一級のイベントになる。ツール結果が型付けされていれば、実行前にモデルの出力を検証できる。これは制約付きデコーディングとうまく組み合わさる。出力空間を制限すれば、不正なツール呼び出しは単に捕まえるのではなく、そもそも起きないようにできる。

誰も宣伝しないが、最も重要な機能はクライアント／サーバー構成だ

コーディングCLIが下す最も影響の大きい設計判断の一つは、エージェントがプロセスなのかサービスなのかという点だ。素朴な設計、つまり1プロセス・1ターミナルで、ターミナルが閉じるとセッションも死ぬという形は、多くのツールの出発点であり、それは天井になる。OpenCodeのクライアント／サーバーモデルは、長時間稼働するサーバーがセッションを保持し、TUI、デスクトップアプリ、Web UIといった任意の数のクライアントがそこに接続する形で、その天井を取り払う。実用的には、ターミナルを閉じてもセッションが残り、リモートの開発マシン上でエージェントを動かしてノートPCのネイティブアプリから操作でき、複数のインターフェースが同じセッションを観察できる、ということだ。

SSHでVM上のエージェントを動かし、再接続でセッションが壊れた経験があるなら、これが単なる便利機能ではないと分かるはずだ。それがおもちゃとインフラの違いなのだ。長時間動くエージェントは、ビルドやテストスイートと同じ分類に属する。開始して、離れて、後で確認するものだ。OpenCode 2.0のバックグラウンド実行可能なタスクも同じ方向を向いている。エージェントは同期的な会話であることをやめ、チャットインターフェースを持つジョブランナーになっていく。

ただし注意点がある。私はこの意見を一貫して持っているので言っておく。サーバー型アーキテクチャは、恒久的なデーモンを意味するわけではない。複数のコメント投稿者が、どのエージェントハーネスも突然マシン上で永続的なバックグラウンドプロセスを欲しがるようになったことを疑わしげに指摘していた。その直感は正しい。私は以前CLIツールはデフォルトでバックグラウンドデーモンをインストールすべきではないと書いたが、その考えは今も変わらない。妥当な中間策はある。必要に応じてサーバーを起動し、プロジェクトディレクトリに範囲を限定し、最後のクライアントが切断されたら終了させるのだ。これならセッションの永続性と複数クライアントからの接続は得られ、マシンから常時どこかへ通信し続けるプロセスは不要になる。OpenCodeがサーバーの作業ディレクトリではなく、セッションのフォルダから設定を読み込むようになった点も2.0の変更の一つだが、サーバーはプロジェクトに従うべきで、その逆ではないと理解していることを示している。

コンテキスト管理にこそ品質が宿る

1時間ほど作業させたあとにエージェントが「バカになった」理由を現場の人に聞けば、答えはほぼ決まってモデルの劣化ではない。コンテキストの腐敗だ。ウィンドウが古いツール出力、行き止まりの試行、40ターン前には関係があったファイルの全文で埋まっていく。モデルは干し草の山の中で判断を下すことになり、公称のトークン上限に達するずっと前から、針を見つける能力は劣化する。

優れたハーネスは、コンテキストを単なるパイプではなく、配分ポリシーを持つ予算として扱う。具体的には、次のような要素が連携して働く。

• ツール出力の切り詰めと再取得の逃げ道。5,000行のテストログは、失敗した40行と、モデルが再読み込みできるパス上に完全なログがあるという注記の形でコンテキストに入るべきだ。何が重要かはハーネスが決め、さらに必要かどうかはモデルが判断する。
• サブセッションとサブエージェント。「このリポジトリで認証がどう動いているか調べて報告して」という依頼は、探索の全記録ではなく要約を返す、隔離されたコンテキストで実行されるべきだ。OpenCode 2.0で改善されたサブセッション間の通信は、まさにこの考え方の実装である。
• 意図を保つコンパクション。ウィンドウが埋まったら、これまでの会話を何かで要約しなければならない。素朴に要約するハーネスは、ノイズと一緒にユーザーの制約（「請求モジュールには触らない」など）まで失ってしまう。良いコンパクションは、決定事項と制約はそのまま残し、語りの部分だけを圧縮する。
• コードではなくコンテキストとしての設定とスキル。プロジェクトレベルの指示、プラグインが定義するツール、スキルファイルはいずれもウィンドウを消費する。これらをホットリロードできる点（これも2.0の改善）は重要だ。セッションを再起動せずにエージェントのコンテキストを編集できてこそ、エージェントの振る舞いそのものを反復改善できるからだ。

これらはどれもモデルの知能ではない。しかし、どれだけ賢く見えるかを決めるのは、まさにこれらだ。雑なコンテキストポリシーを持つ最先端モデルは、20分を超える作業では、規律ある仕組みを持つ安価なモデルに負ける。

権限モデル：採用を決める地味な機能

HNの議論にあった問いを挙げたい。この分野で最も重要な製品上の問いだと私が考えるものだ。「すべてのコマンドを承認する」と「yoloモード」の間に何かあるのか。完全自動承認は本当に危険だ。シェルアクセスを持つコーディングエージェントは、1ターンでrm -rfやgit push --forceを実行し、環境変数を外部に送信できてしまう。完全手動承認は本当に使い物にならない。1時間に80個のコマンドを承認するなら、エージェントを監督しているのではなく、遅い人間のキーボード割り込みになっているだけだ。中間をうまく押さえたツールが、現実主義者の支持を得る。

中間にあるのは段階的な権限モデルであり、その設計空間は一般に思われているよりよく理解されている。

• 読み取り専用・書き込み・実行。読み取りはほぼ無料であり、書き込みはプロジェクトツリーに限定すべきで、実行こそポリシーが最も重要になる場面だ。
• 引数を理解する許可リスト。git statusは自動承認し、git pushは確認を求める。素朴なツールはバイナリ名でマッチさせるが、良いツールは動詞とフラグでマッチさせる。npm testとnpm publishは同じバイナリだが、影響範囲はまるで違うからだ。
• セッション単位の許可。「このセッションではこのコマンドを常に許可」は、権限機能の中で間違いなく最も価値が高い。70回の確認を1回にまとめてくれる。
• 取り返しのつかないものの封じ込め。ネットワークアクセス、プロジェクトディレクトリ外への操作、認証情報に触れる操作は、単に確認を求めるのではなく、構造的に制限されるべきだ。

最後の項目こそ、多くのハーネスが十分に投資していない部分だ。確認を求めるのは簡単だが、封じ込めは難しい。しかし確認は、金曜の午後6時にモデルかユーザーが正しく答えてくれると期待する問いにすぎない。エージェントのプロセスツリーをサンドボックス化し、ネットワークを制限し、ファイルシステムのマウントを範囲限定すれば、モデルやユーザーがどう振る舞おうと、故障の一群そのものが起こり得なくなる。このトレードオフはAIエージェントにおける封じ込めと監視で詳しく書いたが、要点は、確認は監視であり、サンドボックスは封じ込めであって、取り返しのつかないものには封じ込めが必要だということだ。CLIのエコシステムもこれをゆっくり学びつつある。最も速く学んだツールこそ、ユーザーが退屈な90%の作業に対して自動承認を実際に有効にできるだけの信頼を勝ち取るだろう。

拡張性と、セルフホストモデルの問題

2.0の議論から得られる小さな教訓が2つあり、注目に値する。第一に、「すべてがプラグインである」が勝ちつつある。ユーザーはこうしたハーネスの上にスキル、設定エディタ、ワークフローフックを作っている。プラグインを第一級に扱い、ホットリロードでき、セッションを観察でき、振る舞いを変えられるハーネスは、コミュニティの努力を奪い合わず積み上げる。OpenCodeがこれを真剣に扱っている兆候は、自社のGitHubアプリがバグ報告を、問題を再現してその結果をコメントすることで仕分けしていることだ。実質的にはエージェントを使ってエージェント自身を保守している。ユーザーが称賛した「自己認識」とはこれのことであり、それはモデルの成果ではなく、プラグインアーキテクチャの成果だ。

第二に、モデル非依存性は見た目より難しく、それはコンテキスト形式の問題でもある。あるユーザーは、bashのコマンドを発行するよう訓練された優れたローカルモデルを試したが、ハーネスはJavaScript風のツール呼び出しを頑なに期待していて、両者はまったく噛み合わなかった。これは、あらゆるエージェントハーネスに潜む隠れた結合だ。ツール呼び出しの形式、システムプロンプトの前提、モデルの学習分布が揃っている必要がある。特定のモデルファミリーの慣習をハードコードしたハーネスは、モデル非依存とは言えず、せいぜいモデルを許容しているにすぎない。ローカルモデルがコーディングエージェントで重要になるなら（コストやプライバシーの理由から重要になるべきだ）、ハーネスには差し替え可能なAPIエンドポイントだけでなく、差し替え可能なツール呼び出しの方言が必要になる。

逆張りの主張が崩れるところ

私は「モデルは簡単な部分だ」と言った。その縁の部分を認める時が来た。この主張はハーネスの設計、つまりループ、コンテキスト、権限については成り立つ。しかし、モデルが本当にボトルネックになる場面もある。ツール利用の信頼性そのものはモデルに学習されている。一貫して有効な関数呼び出しを出力できないモデルは、どのハーネスも壊れて見せてしまうし、Effectに基づく構造化並行性を使っても、自分のスキーマと言い争うモデルは直らない。長期的な視野での多段階の計画は、単一のセッション内でも感じ取れるほどモデルの階層を分けている。そして、ハーネスかモデルかという枠組みには賞味期限がある。モデルがエージェント的振る舞いを学習に取り込むにつれ（ネイティブなツール利用、ネイティブな長期計画）、能力はハーネスから重みへと移っていく。今日の賢いハーネス機能は、明日には無駄な努力になる。ハーネスを作るチームは、モデルがいずれ陳腐化させる足場を作っているのだと想定すべきだ。正直に言えば、これはプラグインのエコシステムを持つオープンソースのハーネスを支持する理由にもなる。それらは一時的な能力のギャップではなく、コミュニティによって生き残るからだ。

どんなアーキテクチャでも言い訳できない、UXの最低ラインもある。OpenCode 2.0を試して、それでもぎこちなく感じたユーザーもいれば、起動が遅いこと、そして際限なく増え続ける死んだチャット履歴のデータベースに不満を述べたユーザーもいた。これらは深刻な問題ではないが、エレガントなエージェントループが披露される前に、最初の10分でユーザーが離れてしまう原因になる。磨き込みも機能の一部であり、それこそオープンソースプロジェクトが最も過小投資しがちな部分だ。

コードを書くのはモデルだが、それを信頼して任せてよいかを決めるのはハーネスだ。

だから、この分野の移り変わりを見てきた者としての実践的な助言はこうだ。コーディングエージェントは、モデルのベンチマークで勝ったものではなく、データベースを選ぶように選んでほしい。ループの障害処理、コンテキストポリシー、権限の粒度、そしてターミナルを閉じてもセッションが生き残るかを見よう。それらは、次のモデルリリースで誰もが同じように賢くなった後でも、重要であり続ける部分だ。