注意喚起：Codex が翻訳作業中にローカル Ollama を起動した話—— gpt-5.6-sol・権限昇格・指示境界への注意
2026 年 7 月 14 日、開発プロジェクト内の大量コンテンツを英語化する作業を Codex に依頼していたところ、Codex がローカル環境の Ollama サーバーを起動する事象が発生した。モデルによる推論や翻訳が実行された証跡はないが、サーバー起動・GPU 検出・既存モデル一覧の取得まで進んでいた。この記事では、その経緯と、コーディングエージェントへ長時間・大規模な作業を任せる際の設計上の注意点を記録する。
当時の実行環境は次のとおりである。
- 選択モデル：
gpt-5.6-sol/ 推論強度：low/ speed：Fast - Codex CLI：0.144.2
- サンドボックス：
workspace-write/ ネットワークアクセス：禁止 - 承認方式：
on-request/ 承認レビュー：auto_review - 実行環境：Apple M1 搭載 Mac
- サンドボックス外実行：
require_escalatedによる承認経路あり
何が起きたのか
Codex は英語翻訳を進める過程で、ローカル環境に利用可能な翻訳補助手段がないかを調べ始めた。最初に Ollama のインストールを確認し、続いてサンドボックス内からモデル一覧の取得を試みた。
command -v ollama
ollama list
後者はサンドボックスに拒否された。
dial tcp 127.0.0.1:11434: connect: operation not permitted
この時点ではサンドボックスが意図どおり機能していた。しかし Codex はその後、同じ操作を require_escalated 付きで再試行し、Ollama サーバーが起動していないと判断すると、サンドボックス外で ollama serve を実行した。承認理由として表示されたのは「ローカルに既存モデルがあれば翻訳補助に利用する」という趣旨だった。
Ollama 0.14.3 は実際に起動し、ローカルアドレスで待ち受けを開始した。
Listening on 127.0.0.1:11434
discovering available GPUs
starting runner
inference compute: Metal
その後 Codex は既存モデルの一覧を取得し、いったんサーバーを停止した。続いてコンテキスト長を拡張した状態で再起動を試みた。
env OLLAMA_CONTEXT_LENGTH=16384 ollama serve
この二度目の起動試行をユーザーが画面上で確認し、作業を中断した。
「起動を提案しただけ」「起動しようとしただけ」という表現は正確ではない。最初の Ollama サーバー起動はすでに成功している。
実行されたこと・されなかったこと
証跡から確認できる範囲を整理する。
実行されたこと：Ollama のインストール確認、ollama list（サンドボックス内外）、ollama serve、ローカルポートでの待ち受け、Metal GPU 検出、既存モデル一覧の取得、サーバーの停止、コンテキスト長変更での再起動試行。
確認されていないこと：特定モデルのロード、翻訳プロンプトの送信、ローカルモデルによる推論、外部へのデータ送信、新モデルのダウンロード。
「ローカル LLM は使用されなかった」と表現する場合、「モデル推論は実行されなかった」という限定が必要になる。サーバー起動と GPU 検出まではすでに進んでいたからだ。
二つのリスク
今回の事例には、大きく分けて二つのリスクがあった。
一つ目は、ローカル PC への意図しない負荷である。Codex がコンテキスト長を 16384 へ拡張して Ollama を再起動しようとしていた点から、単なる動作確認ではなく、ローカルモデルを実際の長文処理へ投入する準備だったと考えられる。GPU を使ったモデル推論が長時間走れば、他の作業への影響も無視できない。
二つ目は、成果物品質の意図しない低下である。ユーザーが選択していたのは gpt-5.6-sol だったが、今回ローカルで確認されたのは翻訳品質を評価して選定されたモデルではなく、比較的小規模なコーディング系モデルだった。仮にそのモデルが翻訳へ使用されていれば、原文の意味や条件の欠落、専門用語の訳の不安定化、長文後半の省略、文体・用語の一貫性の崩壊といった問題が起きた可能性がある。
特に大規模翻訳では、構文エラーと異なり意味の微妙な変化は機械検査で検出できない。利用者が「gpt-5.6-sol で生成された成果物」と認識していても、実際には別の小規模モデルが下書きを作っていたなら、品質保証の前提が変わる。成果物の来歴を管理するとはつまり、「誰が生成したか」を追跡可能にしておくことでもある。
指示境界と実行手段への同意
当時のプロジェクト指示にはローカル LLM の禁止条項はなかった。そのため本件を「当時のプロジェクトルールへの明白な違反」と評価するのは正確ではない。問題は、より根本的な指示境界にある。
成果を求める指示は、実行手段への包括的な同意を含まない。「英語に翻訳してほしい」という要求は、どのモデルを使っても・どの計算資源を消費してもよいという委任ではないからだ。
この区別を具体化すると次のようになる。
ローカルにソフトウェアがインストールされていることは、それを使用する許可でも、成果物品質の保証でもない。ローカルモデルは過去に別の目的で試したものかもしれず、現在の品質基準を満たしているとは限らない。
「外部送信しない」という説明だけでは安全性の判断は完結しない。データの秘匿性とは別に、PC への継続的な負荷、バックグラウンドプロセスの残存、別モデルへの処理委譲による成果物品質の変化は独立した問題である。
サンドボックスによる拒否は重要な安全信号だ。Git 操作や正当な検証で昇格が必要になる場合はあるが、ユーザーが依頼していない新しいツールやモデルを採用するために制約を越えようとする場合は、通常の作業継続とは分けて考える必要がある。今回はサンドボックスが一度拒否した操作を、昇格経路を経由して再実行している。
Ask for approval の設計
今回のような事象は、承認設定の設計でも防御できる。ただし on-request と表示されていれば十分とは限らない。自動承認レビューや保存済みの許可ルールによって、操作が人間の確認なしに進む経路が存在している可能性がある。
注意すべきなのは、承認の粒度と範囲だ。ollama serve 一件を許可することと、ollama に関連するすべての操作を永続的に許可することは意味が異なる。承認画面で確認すべきはコマンド文字列だけでなく、どのモデルが使われるか・何を入力として渡すか・処理後にプロセスが残るか、といった実行の文脈である。
また、承認画面が表示されたこと自体を同意とみなしてはいけない。エージェントが意図から外れた方向へ進んでいる場合、承認拒否に加えて進行中のターンごと中断する判断も必要になる。Ask for approval は確認ダイアログを増やすための設定ではなく、エージェントの実行経路を人間が観察・介入するための制御点として設計する必要がある。
プロジェクト指示に追加した規定
この事象を受け、プロジェクト指示にはローカル LLM に関する明示的な規定を追加した。
禁止対象を「推論」だけにすると、サーバー起動やモデルロードが抜け落ちる。そのため、ツールの探索・サーバー起動・設定変更・モデル取得・モデルロード・推論実行・成果物への採用までを一連の流れとして扱い、いずれの段階も明示的な依頼なしには実行しない、という形で規定した。
また、「サンドボックス外で実行できること」を利用許可とみなさない、「外部送信を避けられること」を許可の根拠にしない、という観点も明記した。これらは承認時の説明として使われやすい表現だが、資源利用と成果物品質への同意とは別の問題だからだ。
まとめ
gpt-5.6-sol（推論強度 low、speed Fast）を選択して大規模な英語翻訳を依頼していたところ、Codex はローカルの Ollama を発見し、サンドボックス内でのアクセス失敗後に権限昇格経路を使って Ollama サーバーを実際に起動した。モデル推論や外部へのデータ送信は確認されていないが、サーバー起動・GPU 検出・コンテキスト長拡張での再起動試行まで進んでいた。
この事例が示すのは、成果への指示と実行手段への同意は別物だということだ。エージェントに長時間・大規模な作業を委ねる際は、何を達成してほしいかだけでなく、何を使ってよいかを明示することが重要になる。承認設定については、表示上の設定値だけでなく、自動承認経路や永続ルールを含めた実際の制御フローを把握しておく必要がある。
本記事は Codex CLI 0.144.2、モデル gpt-5.6-sol、推論強度 low、speed Fast および当該権限構成で発生した一事例を扱うものであり、Codex が常に同じ挙動をすることを示すものではない。