目次
TL;DR
- 発見: Claude Code 本体は自前で画像を生成できないが、OpenAI 公式 Codex プラグイン経由で Images 2.0 に委譲でき、結果として Claude Code から画像生成が可能になる
- 4 つの罠: そのまま丸投げすると、バックグラウンド実行死亡 / サンドボックス書き込み制限 / CJK 文字化け /
Skill()経由のセッション hang に遭遇する - 解決と設計:
Skill()ではなくAgent(subagent_type="codex:codex-rescue", ...)で呼び、サンドボックス越えのcp・ls -la検証・Read 目視は親エージェントが担う(責務分業+「完了報告を鵜呑みにしない」実体検証)
2026年6月20日 更新: 本記事の公開後、セッションによっては
Agent(codex:codex-rescue)の Bash 承認が拒否され、画像生成に到達できない失敗が頻発すると分かりました。原因と回避策(親が同じ生成を直接実行するフォールバック)を本文末尾の「追記」に加えています。
はじめに
普段づかいは Claude Code なので、正直「Codex 経由で Images 2.0 がこんなに簡単に呼べる」ことを知りませんでした。
Claude Code でも画像や動画の生成自体はできます。HiggsField などの MCP をつなげばいい。ただクレジットを消費するので、ラフ案を何枚も出すような気軽な使い方には向きません。
一方 Images 2.0(OpenAI 最新の画像生成モデル、GPT Image 2)はクオリティが高く、Web デザインのモックや記事バナー、図解など使い所が広い。これを気軽に呼べたら相当便利です。
そして、その入口はすでに公式に用意されていました。
結論: Claude Code から Images 2.0 を呼べる
Claude Code では画像を生成できない、と諦めていませんか? 実は OpenAI が公式に出している Codex プラグイン openai/codex-plugin-cc を入れるだけで、Claude Code 内から imagegen(OpenAI 最新の画像生成モデル Images 2.0 / GPT Image 2)にアクセスできます。Claude Code から間接的に画像生成ができる のです。

Claude Code (親エージェント・Anthropic)
└─ codex:codex-rescue サブエージェントへ委譲 (Agent 経由)
└─ Codex CLI (子エージェント・OpenAI)
└─ imagegen スキル → Images 2.0
OpenAI が競合 Anthropic の Claude Code 上に公式プラグインを出している、という構図自体が面白いところです。2026-03-30 リリースで、執筆時点(2026年6月16日)で 21,000 stars 超。クロスプロバイダで AI ツールを使うなら、知っておくと選択肢が広がります。
なぜこれが嬉しいか
Claude Code は plugin / skill / agent / subagent という階層化された拡張機構を持ち、Codex プラグインを通すと Anthropic 側のエージェント(Claude)から OpenAI 側のエージェント(Codex)へ作業を流せます。
- Anthropic 製モデル(Claude Opus/Sonnet)の強みを活かしながら、OpenAI 製モデル(GPT-5 系・imagegen 等)の能力も同じセッション内で呼べる
- 自分の OpenAI 課金で Codex を動かす形なので、特定ベンダー依存を緩められる
- 画像生成だけでなく、Codex の
review/adversarial-review/rescue等の機能も Claude Code 側から委譲できる
つまり「画像生成できた」は氷山の一角で、本質は クロスプロバイダ委譲の入口 がすでに公式提供されている、という点です。
ここからは「スムーズに使う」までの話
「呼べる」と「スムーズに使える」の間には 4 つの罠がありました。時系列で、それぞれをどう潰し、最終的に自作スキル codex-image-gen へどう落とし込んだかを共有します。
罠 1: バックグラウンド実行で黙って死ぬ
最初は素朴に、/codex:rescue に「この図を画像にしてほしい」と依頼しました。
返事:
imagegen スキルを使います
そのまま、何も起きなくなりました。
- 通知も来ない
- ファイルもできない
- Claude Code 側の
TaskList/TaskOutputは Codex 内部の task id を認識せず、wait_agentを投げるとinvalid agent id、thread を投げるとnot_found
原因
Codex のレスキューサブエージェントは、状況によって --background(fork)でデフォルト起動 します。fork した子プロセスは Claude Code の harness から追跡できず、終了通知も来ません。LLM 連携でありがちな「片方がバックグラウンドで勝手に走っている」状態です。
対策
委譲プロンプトに 「バックグラウンドにせず、フォアグラウンドで完了まで走り切ること」 を明示します。これだけで挙動が変わります。
罠 2: サンドボックスのパス制限
「フォアグラウンド完走」を明示した 2 回目の試行で、画像生成自体は成功しました。ところが指定した ~/Downloads/example-image.png への保存で:
Operation not permitted
原因
Codex CLI はデフォルトで workspace-write サンドボックスで動き、書き込めるのは 自分の workspace(セッションを開始した作業ディレクトリ)内に限られます。~/Downloads のようなホームディレクトリ直下は workspace の外なので、当然弾かれます(設定で writable_roots を足せば書き込み先を広げられますが、本記事では親側で cp する方針を採ります)。
対策
委譲プロンプトに 「書き込めない場合は workspace 内に保存して、その絶対パスを報告する」 を入れておきます。これで Codex は workspace 内(例: /path/to/workspace/generated/codex-image-xxx.png)に保存し、完了報告で絶対パスを返してきます。
その後、親エージェント(Claude Code 側)が cp で目的のパスへ救出します。サンドボックス越えは親の仕事、という分担です。
cp /path/to/workspace/generated/codex-image-xxx.png ~/Downloads/example-image.png
実測では 1 枚あたり 1〜2 MB 程度(後述する事例では 2,378,465 bytes)でした。
罠 3: CJK 文字化け
技術図のラベルに日本語を入れたら、「複雑」が「霊等」に化けていました。Images 2.0 は CJK の長文ラベルが苦手で、特に技術図のように文字が密集すると崩れます。
対策(トレードオフあり)
文字が多い技術図は Mermaid を canonical(正本)として併産し、Codex 画像は「見栄え版」として補助的に使う という運用に落とし込みました。
| 用途 | 推奨 |
|---|---|
| 文字が多い技術図(構成図、シーケンス図) | Mermaid を正本、Codex 画像は装飾用 |
| 文字が少ない 1 枚絵(イラスト、サムネ) | Codex 単体で OK |
| どうしても画像に CJK を入れたい | 英語併記 or 短いラベルに限定 |
Mermaid は正確だが見た目が定型的、Codex 画像は見栄えするが文字精度が落ちる、という素直なトレードオフです。
罠 4 (最大): Skill(codex:rescue) で hang する
3 つの罠を毎回手書きプロンプトで回避するのが面倒になり、codex-image-gen という自作スキルにまとめることにしました。ところがここで 最大の罠 を踏みます。
何をしたか
スキルの初版では、委譲フェーズでこう書きました。
Skill(skill="codex:rescue", args={prompt: "..."})
直感的には「公式の slash command を Skill ツールで呼ぶ」だけのつもりでした。実行すると:
Launching skill: codex:rescue
…が表示されたまま、体感で「明らかに時間がかかりすぎ」状態。ユーザー側で中断するしかなく、画像は生成されずじまい。
原因: 公式ドキュメントに明文で禁止されていた
~/.claude/plugins/cache/openai-codex/codex/{version}/commands/rescue.md を読み直すと、呼び出し方の鉄則がはっきり書いてありました。
| 呼び出し方 | 結果 |
|---|---|
Skill(codex:rescue) | NG — このコマンドに再入してセッションが hang する |
Skill(codex:codex-rescue) | NG — そんな skill は存在しない |
Agent(subagent_type="codex:codex-rescue", prompt=...) | OK — 正解 |
理由は構造的です。codex:rescue は slash command で、その内部で本物の subagent codex:codex-rescue を Agent ツール経由で起動します。そこへ Claude スキルから Skill(codex:rescue) を呼ぶと slash command が再帰的に呼び出され、内部状態が解決できずに hang します。
なぜ見落としたか
/codex:rescue という名前と Skill ツールの「slash command を呼べる」機能が表面的に対応して見えるのが、見落としの正体でした。codex:rescue(slash command)と codex:codex-rescue(subagent)は 名前空間が別物 で、叩く窓口は前者・自作スキルから呼ぶべきは後者。公式リポを読まず Skill ツールの一般論だけで設計したのが敗因です。
修正
委譲フェーズを Skill() から Agent() に書き換えました。
修正前(NG):
Skill(skill="codex:rescue", args={prompt: "<delegation prompt>"})
修正後(OK):
Agent(subagent_type="codex:codex-rescue", prompt="<delegation prompt>")
差分は小さいですが、「slash command 経由」から「subagent 直接呼び出し」への根本的な変更です。再発防止に、スキルの「ガードレール」最上位へ「Skill 経由禁止、Agent 経由必須」を明記しました。
修正後の実証
修正版スキルで縦長(9:16)の 1 枚絵を生成してみました。処理の流れと実測はこうです。
Codex が imagegen で画像生成(約 9 分 / 539,756 ms)
↓
workspace 内に保存(2,378,465 bytes)
/path/to/workspace/generated/codex-image-xxx.png
↓
親エージェントが cp で目的の Downloads ディレクトリへ救出
↓
親が Read で開いて目視確認 → 描画要素ほぼ完璧
「画像内にテキストなし」指定だったので CJK 文字化けリスクはゼロ。逆に CJK を含めたい場合は、今も罠 3 のトレードオフが残ります。
委譲プロンプトテンプレ(コピペ可)
実際に使っているテンプレをそのまま貼っておきます。前提チェックと委譲の部分です。
前提チェック
# Codex プラグインの存在確認
ls ~/.claude/plugins/cache/openai-codex/codex/
# バージョン v1.0.4 以降推奨
# 入っていなければ https://github.com/openai/codex-plugin-cc を参照
Codex への委譲(呼び出し方)
Agent(
subagent_type="codex:codex-rescue",
prompt=<下記の委譲プロンプトテンプレ>
)
ここで Skill(codex:rescue) を使ってはいけません。 公式の commands/rescue.md で禁止されています(理由は罠 4 参照)。
委譲プロンプトテンプレ本体
【タスク】
{用途・描画要素・スタイル・アスペクト比をここに記述}
【保存先】
{絶対パス。例: ~/Downloads/example-image.png}
【手順】
1. Images 2.0 / imagegen で画像を生成する
2. 上記の保存先パスに保存する。書き込めない場合は workspace 内に保存して、その絶対パスを報告する
3. `ls -la {保存先パス}` でファイルの存在とサイズを確認する
4. 完了報告にはファイルの絶対パスとバイト数を含める
【重要・厳守】
- バックグラウンドにせず、フォアグラウンドで完了まで走り切ること
- 保存と ls -la 確認を済ませてから報告すること(途中で止まらない)
- 日本語テキストを入れる場合は正確に描画する。CJK 文字が崩れる懸念があれば英語併記でよい
- imagegen スキルを呼び出した時点で停止せず、最後まで完遂すること
親側の救出・検証・目視(疑似コード)
# 1. サンドボックス越え救出
if (codex の完了報告が workspace 内パスを返した):
cp {workspace 内パス} {ユーザー希望パス}
# 2. 実体検証
ls -la {ユーザー希望パス}
# サイズが 0 でないこと、存在することを確認
# 3. 目視点検
Read({ユーザー希望パス})
# CJK 文字化けがあれば再生成 / 英語版 / Mermaid 切り替えを提示
追記: セッション依存で Agent の Bash 承認が拒否される
本記事の公開後、最も多く遭遇したのがこの失敗でした。正解どおり Agent(subagent_type="codex:codex-rescue", ...) で委譲しているのに、画像生成まで到達せず空振りすることがあります。
症状
親(メインループ)の Bash は通るのに、Agent サブエージェントの Bash だけが毎回拒否される。 この非対称が決定的なサインです。Codex が走った形跡(imagegen の出力や保存報告)がないまま、数十秒で何も起きずに返ってきます。
原因
Agent() がバックグラウンド(async)で起動されるセッションでは、背景サブエージェントが対話的な承認プロンプトを出せません。そのため承認が必要な Bash 呼び出しが「承認者不在」で自動的に拒否されます。これは セッション依存 で、別セッションでは同じ手順が通ることもあります。
注意点が2つ:
Agentのmode: "bypassPermissions"でも上位の deny には勝てない- チャットに「許可します」と書いても無効(ハーネスの権限ルールは変わらず、背景サブエージェントにはテキストとしてしか届かない)
対策: 親が同じ生成を直接実行する(フォールバック)
codex:codex-rescue は内部で素の companion コマンドを1つ叩いているだけなので、それを親が直接フォアグラウンドで実行すれば等価です。決定的な違いは、親のメインループ Bash なら承認プロンプトがユーザーに見える=その場で承認できる点です。
# インストール済み companion の絶対パスを解決(最新バージョン)
CODEX_DIR=$(ls -d ~/.claude/plugins/cache/openai-codex/codex/*/ | sort -V | tail -1)
COMPANION="${CODEX_DIR}scripts/codex-companion.mjs"
# Agent に渡すはずだった画像生成プロンプト全文をそのまま渡す
node "$COMPANION" task "<委譲プロンプト全文>" --write
--writeで workspace-write サンドボックス(書き込み可)。--backgroundは付けない- 以降は通常どおり
cp救出 →ls -la検証 →Read目視を流用する - これは
Skill(codex:rescue)の再入(hang する)とは別物。サブエージェントが叩くのと同じコマンドを親が直接実行するだけなので固まらない。あくまで Agent 経路が拒否されたときのフォールバック専用
それでも親の node まで拒否されるとき
質問ループに入らず、次のいずれかで復旧します。
- いちばん手軽: 上のフォアグラウンド実行で出る承認プロンプトをその場で許可する(このセッション限り・設定変更なし)
- 毎回のプロンプトも省きたい場合のみ
/permissionsで allow ルールを追加。ただし設定ファイルに永続保存される点に注意。Bash(node:*)は広すぎるので、companion のパスに絞るか.claude/settings.local.json(gitignore 対象)で影響範囲を限定する - 権限状態はセッションごとに変わるので、別セッションで開き直すだけで直ることもある
まとめ
Claude Code 単体では画像を作れなくても、OpenAI 公式 Codex プラグイン経由で Images 2.0 に委譲すれば生成できます。ただし実用化のキモは、画像生成そのものより 委譲の作法 でした。
- 呼び出し方は公式ドキュメントで確認する。
codex:rescue(slash command)とcodex:codex-rescue(subagent)のように名前が似た別物があり、スキルからはAgent()経由が正解 - 委譲先の「完了しました」を信用しない。サンドボックス越えの
cpと最終検証(ls -la・Read)は親に集約する。この責務分業は Codex に限らず MCP 経由の委譲全般に効く
参考
- OpenAI 公式 Codex プラグイン: https://github.com/openai/codex-plugin-cc
- ローカルにインストール済みの場合の鉄則ドキュメント:
~/.claude/plugins/cache/openai-codex/codex/{version}/commands/rescue.md - Images 2.0 / GPT Image 2(OpenAI 最新の画像生成モデル。2025年の GPT-4o image generation の後継で、2026-04 リリース)