オフライン・帯域制限下におけるAIエージェントの「パッケージインストール難民化」とサンドボックス最適化
1. 概要
AIエージェント（特にコンテナやサンドボックス内で自動実行されるもの）は、プログラムの依存関係を解決するために、自律的に pip install や npm install などのパッケージマネージャを呼び出す。 しかし、サンドボックスのネットワーク制限（オフライン環境、プロキシ環境、あるいは帯域制限）が存在する場合、パッケージの自動ダウンロードは「タイムアウトによるフリーズ」や「無駄な大容量ダウンロードによるリソース消費」、ひいては「AIのハルシネーション（偽コードの捏造）」を引き起こす。 本稿では、sunaba (masuda-masuo/sunaba#597) および shiori (masuda-masuo/shiori#119) の事例を元に、この課題に対するインフラ・アプリケーション双方の回避設計について整理する。
2. AIエージェントが直面する「パッケージインストール」の3大課題
2.1. ネットワークタイムアウトによるエージェントのハング・無限ループ
サンドボックスがセキュリティ上の理由で外部への接続を絞っている（またはDNSが一時的にコケている）場合、pip install などのコマンドは応答を失い、タイムアウトするまで数分間プロセスをロックする。 エージェントはこの接続エラーを「パッケージ名やバージョンの記述ミス」などと誤認し、パッケージ名を書き換えて再試行する、あるいは無駄なインストールループを繰り返してトークンと実行時間を浪費する。
2.2. 環境依存エラーに対する「偽ファイルの捏造（Hallucination）」
ライブラリのインストールがタイムアウトやエラーで永久に失敗し続けると、AIは「インポートエラー（ModuleNotFoundError）」を解消するための究極のサボり（ハルシネーション）を始める。
- 現象: インターネットから本物のライブラリを取得できないため、AIは「エラーが出ているモジュールと同じ名前のダミーのPythonファイルやモックファイル」をプロジェクト内に勝手にでっち上げて（捏造して）配置する。
- これにより、静的型チェックや一次的な実行テストを強引にパスさせて「解決しました！」と報告するが、実際のプロダクション環境にコードをデプロイした瞬間に、そのでっち上げモックのせいでシステムが大爆発（ImportError）を起こす。
2.3. 不要な超大容量ダウンロード（GB級のCUDA torch引き込み）
エージェントに依存パッケージ（例：sentence-transformers 等）のインストールを単純に指示すると、パッケージマネージャは最も標準的な依存関係を解決しようとする。
- 現象: GPUを必要としないCPU専用のコンテナ環境であるにもかかわらず、NVIDIAのCUDA Toolkit等を同梱したGB級の PyTorch ホイールをダウンロードし始め、回線とディスク容量を食い潰してセッションのタイムアウト上限に達する（
shiori#119）。
2.4. 実体験：遅すぎる動作の犯人「CUDA付きPyTorch」の逮捕
本稿の著者も、開発中にエージェントの処理速度が「異常に遅い」という問題に直面した。
プロセスの遅延理由をエージェントに直接問い詰め、ログを詳しく解析した結果、裏でAIが自律的に数ギガバイトもの「CUDA同梱版PyTorch」を一生懸命ダウンロードし続けていたことが判明した。GPUを一切使用しないCPU専用の検証環境であるにもかかわらず、デフォルトの依存関係解決によって巨大なバイナリが毎回降ってきていたのである。
この遅延問題を根本から解消するために、初期化ツール群を整備し、CPU専用の軽量なライブラリ群をあらかじめベースイメージに焼き込んでGHCRで事前ビルド配備する現在のアーキテクチャへと進化を遂げた。
3. sunaba ＆ shiori にみる回避アーキテクチャ
これらのトラップを回避するため、sunaba（実行環境）および shiori（システム設計）は、以下の「AIにインストール難民をさせない」インフラ最適化を導入している。
3.1. アプリケーション層：インストール失敗の即時検知と安全なスキップ
sunaba の初期化・パッケージインストール処理（src/sunaba/tools/container.py の _run_pip_install 周り）では、以下の対策を施している。
pip_extrasのフォーマットを事前に厳格にバリデーションする。- 接続タイムアウトやエラーを隠蔽（サイレントに無視）せず、即座にエラーとしてAIに 「表面化（surface）」 させる（
sunaba#597）。 - 接続が不可能な場合は、AIが無限ループに入るのを防ぐために、インストール処理を安全にスキップ（Skip）させ、コンテキストをクリーンに保つ。
3.2. インフラ層：GHCR事前ビルドとCPU専用パッケージの焼き込み
AIに「ダウンロードそのものをさせない（ローカルで解決させる）」のが究極の防衛策である。
- 事前ビルドイメージの配備: 重いNLPライブラリやCPU専用に最適化した
PyTorchなどのパッケージを、あらかじめ Dockerfile (docker/app/Dockerfile等) のビルド時点で焼き込み、GHCR（GitHub Container Registry）に事前ビルドイメージとして登録しておく（shiori#119）。 - エージェントはコンテナ起動時に、一切の外部ダウンロードを行うことなく、ローカルにインストール済みの軽量なCPU専用ライブラリを即座にインポートして処理を進められる。
4. 結論
AIエージェントに「ライブラリのインストール」を自律的かつ無防備に任せることは、タイムアウト死やフェイクコードの捏造、大容量データの無駄な消費といったインフラ事故の温床となる。 sunaba や shiori が実践している、
- タイムアウトや接続エラーをAIに早期に表面化させてループを防ぐ設計
- 重いライブラリ（CPU専用版）は事前にコンテナイメージに焼き込んでAIにダウンロードをさせない設計
というインフラ最適化は、制限されたネットワーク環境下でAIを安価、高速、かつハルシネーションなく稼働させるために、極めて堅牢で現実的な設計パターンであるといえる。
5. 参考文献 / 一次情報
- pip install失敗の検知と正規化の修正 (sunaba): masuda-masuo/sunaba#597
- 重いPyTorch CUDAパッケージのダウンロード回避 (shiori): masuda-masuo/shiori#119