エージェントループを設計する
(simonwillison.net)- AnthropicのClaude CodeやOpenAIのCodex CLIのようなコーディングエージェントは、動作するコード生成におけるLLMの有用性を根本的に高め、コードを自ら実行し、エラーを修正し、既存実装を探索し、試行を通じて有効な解決策を見つけられる
- こうしたツールの潜在力を最大限に活用するための中核技術がエージェントループ設計であり、コーディングエージェントを明確な目標とツールセットで問題に向き合わせることで、総当たり的に有効な解決策を探せる道具として理解できる
- LLMエージェントの定義は目標を達成するためにループの中でツールを実行することであり、それをうまく使う技術とは、エージェントが使うツールとループを慎重に設計すること
- YOLOモード(すべてのコマンドがデフォルトで承認される)は危険だが、総当たりで最も生産的な結果を得るうえで重要であり、安全に実行するにはDockerサンドボックス、GitHub Codespacesのような別環境の利用、あるいはリスク受容という選択肢がある
- 適切なツール選定(シェルコマンドやパッケージ)、厳密にスコープを限定した認証情報の発行(テスト環境、予算上限)、明確な成功基準と試行錯誤を要する問題(デバッグ、性能最適化、依存関係アップグレード、コンテナ最適化)に適用することが、エージェントループ設計の核心原則
YOLOモードの楽しさ
-
エージェントの危険性
- エージェントは本質的に危険
- 誤った判断をしたり、悪意あるプロンプトインジェクション攻撃の被害を受けたりする可能性がある
- ツール呼び出しによって有害な結果が生じうる
- 最も強力なコーディングエージェントのツールは「シェルでこのコマンドを実行する」であるため、不正なエージェントは、ユーザーが自分でコマンドを実行してできるあらゆる操作を行えてしまう
- Solomon Hykesの引用:
AIエージェントとは、ループの中で環境を破壊するLLMである
- エージェントは本質的に危険
-
デフォルト承認モードの限界
- Claude Codeのようなコーディングエージェントは、実行するほぼすべてのコマンドについて承認を求めることをデフォルトにして対処している
- これはやや面倒なだけでなく、より重要な点として、総当たりによる問題解決の効果を劇的に低下させる
-
YOLOモード
- 各ツールには、すべてがデフォルトで承認されるYOLOモード相当の機能がある
- 非常に危険だが、最も生産的な結果を得るための鍵でもある
-
無人YOLOモードの3つの主要リスク
- 1. 悪いシェルコマンド: 重要なものを削除または破壊する
- 2. 流出攻撃: エージェントが見られるファイルやデータ(ソースコードや環境変数に保存された秘密)を盗み出す
- 3. プロキシ攻撃: 他の標的へのDDoSやその他のハッキング攻撃の発信元を偽装するために、そのマシンをプロキシとして使う
YOLOモードの実行オプション
-
オプション1: セキュアなサンドボックス
- アクセス可能なファイルや秘密情報、作成可能なネットワーク接続を制限するセキュアなサンドボックスでエージェントを実行する
- コンテナエスケープの可能性はあるが、DockerやAppleの新しいコンテナツールを使うことは、大半の人にとって許容可能なリスク
- AnthropicのSafe YOLO modeドキュメント:
- インターネットアクセスなしのコンテナで
--dangerously-skip-permissionsを使う - Docker Dev Containersを使った参照実装が提供されている
- インターネットアクセスを信頼できるホスト一覧に制限することは、個人のソースコード流出を防ぐ有効な方法
- インターネットアクセスなしのコンテナで
-
オプション2: 他人のコンピュータを使う(推奨)
- エージェントが暴走しても被害を限定できる
- GitHub Codespacesの利用を推奨:
- ブラウザ経由でアクセスできる、オンデマンドの完全なコンテナ環境を提供する
- 充実した無料枠がある
- 問題が起きても、どこかのMicrosoft AzureマシンがCPUを消費するだけで、最悪でも、その環境にチェックアウトしたコードが攻撃者に流出するか、悪意あるコードが接続済みのGitHubリポジトリへpushされる程度で済む
- 他人のコンピュータ上でコードを実行する、他のエージェント型ツール:
- ChatGPTとClaudeのCode Interpreterモード
- OpenAIのCodex Cloud
-
オプション3: リスクを受け入れる
- 悪意ある指示源にさらされないよう努めつつ、被害が出る前にミスを発見できることを期待する
- 大半の人が選ぶオプション
ループに適したツールを選ぶ
-
安全なYOLOモードを確保した後
- 次の段階は、コーディングエージェントに使わせるべきツールを決めること
-
シェルコマンド優先
- この時点でMCP(Model Context Protocol)を組み合わせることもできるが、代わりにシェルコマンドの観点で考えるほうが、一般にはより生産的
- コーディングエージェントはシェルコマンドの実行が非常に得意
- 環境が必要なネットワークアクセスを許可していれば、NPMやPyPIなどから追加パッケージを取得することもできる
- ランダムなパッケージのインストールが手元のメイン環境を壊さない環境でエージェントを動かすことも重要な考慮点
-
AGENTS.mdファイルの活用
- MCPに頼るよりも、使うべきだと考えるパッケージの詳細を含むAGENTS.md(または同等のもの)ファイルを作るほうを好む
- 例: さまざまなWebサイトのスクリーンショットを撮るプロジェクトでは、自作のshot-scraper CLIツールをインストールし、
AGENTS.mdに次を追加する:スクリーンショットを撮るには次を実行: shot-scraper http://www.example.com/ -w 800 -o example.jpg - この1つの例だけでも、エージェントが別のスクリーンショットのためにURLやファイル名を置き換える方法を推測するには十分
-
既存ツールの活用
- 優れたLLMは、すでに驚くほど多種多様な既存ツールの使い方を知っている
- 「playwright pythonを使う」や「ffmpegを使う」と伝えれば、ほとんどのモデルは効果的に使える
- ループ内で実行されるため、最初に犯したミスから通常は回復でき、追加の指示がなくても正しい手順を見つけ出せる
厳密にスコープを限定した認証情報を発行する
-
認証情報の必要性
- 適切なコマンドを公開することに加えて、それらのコマンドに対してどの認証情報を渡すべきかも考える必要がある
- 理想的には認証情報は一切不要だが(多くの作業はログインやAPIキーなしでもできる)、一部の問題では認証済みアクセスが必要になる
-
2つの重要な推奨事項
- 1. テストまたはステージング環境向けの認証情報を渡す
- 被害を適切に限定しやすい環境
- 2. 予算上限を設定する
- 認証情報で費用が発生しうる場合は、厳格な予算上限を設定する
- 1. テストまたはステージング環境向けの認証情報を渡す
-
実例: Fly.ioの調査
- Fly.ioで動作するscale-to-zeroアプリケーションの遅いコールドスタート時間を調査した
- Claude CodeがDockerfileを直接編集し、Flyアカウントにデプロイし、起動にかかる時間を測定できるようにした
-
安全な設定
- Flyでは組織を作成でき、その組織に予算上限を設定し、その組織内でのみアプリを作成・変更できるFly APIキーを発行できる
- この調査専用の組織を作成した
- $5の予算を設定した
- APIキーを発行してClaude Codeを解き放った
- このケースでは結果は十分に有用ではなかったが、「エージェントループ設計」が身につけるべき重要な技術だと初めて気づいたプロジェクトだった
エージェントループ設計を使うべきとき
-
向いている問題パターン
- すべての問題がこの作業パターンにうまく反応するわけではない
- 注目すべきなのは、明確な成功基準があり、良い解決策を見つけるのに(やや退屈かもしれない)試行錯誤が必要になりそうな問題
- 「うわ、ここではたくさんのバリエーションを試す必要がありそうだ」と思うたび、エージェントループを試す価値がある強いサインになる
-
具体例
-
デバッグ
- テストが失敗しており、根本原因を調べる必要がある
- すでにテストを実行できるコーディングエージェントなら、追加設定なしでこれを行える
-
性能最適化
- SQLクエリが遅すぎる。インデックス追加は役立つだろうか?
- エージェントはクエリをベンチマークし、(隔離された開発環境で!)インデックスを追加・削除しながら影響を測定できる
-
依存関係のアップグレード
- 複数の依存関係アップグレードに追いつけていない
- テストスイートが堅牢であれば、エージェントループはそれらをすべてアップグレードし、破壊的変更に対応するために必要な小さな更新を実施できる
- 関連するリリースノートのコピーを渡すか、エージェントが自分で見つけられる場所を把握していることを確認する
-
コンテナサイズの最適化
- Dockerコンテナが不便なほど大きい
- エージェントは異なるベースイメージを試し、テストが通る状態を保ちながらDockerfileを反復的に改善して縮小を試みられる
-
-
共通テーマ: 自動テスト
- これらすべてに共通するテーマは自動テスト
- コーディングエージェントやその他のLLMコーディングツールから得られる価値は、きれいに通る優れたテストスイートによって大幅に増幅される
- 幸い、LLMはそれがまだない場合に、その整備プロセスを加速するのが得意
依然として非常に新しい分野
- エージェントループ設計は非常に新しい技術
- Claude Codeは2025年2月に初めてリリースされた
- 明確な名前を与えることで、これについて生産的な対話を行いやすくなることを期待している
- こうしたツールを可能な限り効果的に使う方法については、まだはるかに多くのことを解明する必要がある
まだコメントはありません。