自律エージェントの運用境界とステートレス基盤への移行

自己改善ループにおける委任プロンプトの限界と破壊的挙動

Claude Codeなどの自律型コーディング環境で起きる意図しないコード書き換えは、指示の曖昧さではなく、タスクのスコープを限定するサンドボックス機構の欠如に起因する。

Claude Codeなどの自律型コーディング環境で起きる意図しないコード書き換えは、指示の曖昧さではなく、タスクのスコープを限定するサンドボックス機構の欠如に起因する。開発者はAIエージェントにコードベースの修正と自己改善のループを任せるとき、全権限を渡す運用をとることが多い 。しかし、作業の境界を制御する分離レイヤーが実装されていない環境では、単一のプロンプトの抜け落ちがシステム全体に波及する 。

Claude Codeを用いた自己改善ワークフローのテストにおいて、委任プロンプトの指定漏れが発生した 。人間1名と9部署のAIエージェントによる企業運営の仕組みを構築する実験の最中に、この事故は観測されている 。自律型エージェントに夜通し作業をさせるとき、朝の大量の後始末を防ぐための境界線引きが必要とされるが、それを破る挙動が起きた 。

- 委任プロンプトの指定漏れによる予期せぬ改変 - 1行の指示不足に起因する190行のコード書き換え - 人間1名と9部署のAIエージェントによる組織運営 - 夜間自律稼働時における朝の大量の後始末の発生

この事例は、プロンプトの記述量を増やすだけでは自律稼働の安全性を担保できないことを示していると考えられる。必要なのは、ファイルシステムやGitの操作範囲を物理的に制限するコンテナ分離や、変更差分を自動で隔離するフック機構の導入である。作る側は、エージェントの実行権限を細粒度に分割するサンドボックス設計を標準装備に切り替える必要がある。

指示の抜け落ちをプロンプトの工夫で防ぐ運用を続ける限り、自己改善ループの暴走はコードベースの規模に関わらず再現し続けると考えられる。サンドボックス機構をバイパスするテストケースが正常に弾かれる環境が構築できない場合、この見方は成立しない。

この見方が成り立たない条件 サンドボックス機構やコンテナ分離を導入せずとも、プロンプトの工夫だけで暴走を完全に防げる検証結果が複数観測された場合、この見方は成立しない。

鍵はどこにあるか

• 作る側: ファイルシステムへの書き込み権限を限定するサンドボックス機構をエージェントの実行ランタイムに強制適用する。
• 使う側: 夜間などの自律稼働時には、Gitのブランチ分離と自動テストの通過を必須条件とするワークフローに切り替える。

ローカル環境におけるモデルサイズと出力トークンの実効制約

小規模から中規模のオープンウェイトモデルをローカルで動かす際の実用性は、ベンチマーク上のスコアではなく、推論時の出力トークン増殖やバックエンド挙動の不一致によって頭打ちになる。

小規模から中規模のオープンウェイトモデルをローカルで動かす際の実用性は、ベンチマーク上のスコアではなく、推論時の出力トークン増殖やバックエンド挙動の不一致によって頭打ちになる。

Ollama 0.30.8のMLXランナーとGGUF形式に関する実機検証において、M1 Max環境でGGUFモデルが意図したMLXバックエンドを通っているかをバイナリ解析とログから検証する作業が行われた 。ユーザーが設定したはずのランナーが正しく機能していない不一致の実態が明らかにされている 。また、Qwen3.5-9BモデルをM1 Max環境で稼働させた検証では、モデルサイズが6.6GB、量子化形式がQ4の構成で実行された 。この検証において、答え自体の文字数は131字であるにもかかわらず、実際の出力トークン数が3936トークンに達するという異常なトークン増殖が観測された 。さらに、PiからOllamaを起動する環境では、出力トークン上限エラーが発生する問題が確認されており、コンテキスト長を規定するnum_ctxパラメータをModelfileで明示的に大きく設定する必要が生じている 。

- バイナリ解析とログによるランナーの不一致検知 - Q4量子化と6.6GBのモデルサイズにおける実機検証 - 131字の回答に対する3936トークンの異常増殖 - Piからの起動時における出力トークン上限エラー - Modelfileでのコンテキスト長拡張によるエラー回避

これらの実機検証が示すように、ローカル環境での運用ではモデルの静的なパラメータサイズや量子化の形式以上に、バックエンドの実行経路やトークンの増殖挙動が実効スループットを直接的に支配する。アプリケーション設計者は、単なるベンチマークのスコア依存から脱却し、ランナーのバイナリ挙動と出力トークンの消費量を監視下に置く必要がある。

ランナーのバックエンドが意図せずフォールバック処理を経由して正常に機能し、かつ出力トークンの増殖率が指定範囲内に収まる最適化済みのランタイムが主要プラットフォームの標準として完全に統合された場合、この見方は成り立たなくなる。

この見方が成り立たない条件 ランナーのバックエンドが意図せずフォールバック処理を経由して正常に機能し、かつ出力トークンの増殖率が指定範囲内に収まる最適化済みのランタイムが主要プラットフォームの標準として完全に統合された場合、この見方は成り立たなくなる。

鍵はどこにあるか

• 作る側: Modelfileのnum_ctxパラメータとMLXランナーの実行バイナリを固定し、出力トークンの上限と増殖率をログで常時監視する。

むすび

AIエージェントの自律稼働とローカル環境での運用における検証は、いずれも静的な設定や指示の精度だけでは制御しきれない動的な挙動の存在を浮き彫りにしている。プロンプトやベンチマークのスコアに依存する設計から、物理的なサンドボックス機構やバックエンドの実行経路といったインフラストラクチャレベルの制御への移行が迫られている。システムは、人間の曖昧さやランタイムの隠れた挙動を前提とした安全弁を備えなければ、実運用に耐えうるものとはならない。開発現場におけるAIの自律化は、運用ルールの策定フェーズを脱し、強制的な制約をシステムに組み込む設計フェーズへと移行しつつあるのではないか。

主要なランタイムがバックエンドの不一致やトークン異常増殖を自動で検知・是正する機能を標準搭載した場合、ローカル環境でのモデル選択基準はどのように変化するのか？

この問いの答えで何が変わるか 自動是正機能が標準化されるなら実効スループットの懸念が消えて小規模モデルの採用が進むが、依然として手動でのバイナリ検証が必要なら実用性のハードルが残り続ける。