メインコンテンツへスキップ

Claude Code でも画像生成できた — OpenAI 公式 Codex プラグインで Images 2.0 を呼ぶ(+ 4 つの罠と委譲設計)

Claude Code でも画像生成できた — OpenAI 公式 Codex プラグインで Images 2.0 を呼ぶ(+ 4 つの罠と委譲設計)のアイキャッチ画像
目次

TL;DR

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 CLI(OpenAI)へ委譲し、imagegen を経て Images 2.0 に到達する委譲フロー図

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)へ作業を流せます。

つまり「画像生成できた」は氷山の一角で、本質は クロスプロバイダ委譲の入口 がすでに公式提供されている、という点です。

ここからは「スムーズに使う」までの話

「呼べる」と「スムーズに使える」の間には 4 つの罠がありました。時系列で、それぞれをどう潰し、最終的に自作スキル codex-image-gen へどう落とし込んだかを共有します。


罠 1: バックグラウンド実行で黙って死ぬ

最初は素朴に、/codex:rescue に「この図を画像にしてほしい」と依頼しました。

返事:

imagegen スキルを使います

そのまま、何も起きなくなりました

原因

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:rescueslash 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つ:

対策: 親が同じ生成を直接実行する(フォールバック)

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

それでも親の node まで拒否されるとき

質問ループに入らず、次のいずれかで復旧します。


まとめ

Claude Code 単体では画像を作れなくても、OpenAI 公式 Codex プラグイン経由で Images 2.0 に委譲すれば生成できます。ただし実用化のキモは、画像生成そのものより 委譲の作法 でした。

参考

ZSL
ZSL

AIエンジニア

生成AIを活用した開発ワークフローの研究・実践をしています。