AIにAIを使わせる Claude CodeからCodexで画像を作って分かったこと

このブログの記事についている画像は、全部AIが作っています。

ただ、作っているのはClaudeではありません。Claudeが、Codexに発注しています。

記事を書いたClaude Codeが、そのままターミナルからCodexを呼び出し、画像を作らせて、できたものを受け取る。画像を作れという指示は、毎回は出していません。手順書に書いてあるので、勝手にやります。

誤解のないように書いておくと、記事そのものには人がかなり口を出しています。何をテーマにするか、どこを主題に置くか、どういう中身にして、どう帰結させるか。そこをAIと詰めたうえで最初の案を書かせ、上がってきたものに修正を指示し、直ったのを確認してから公開する。ここは今も人の仕事です。

自動で回っているのは、画像を作るところと、書き上がった原稿をチェックするところです。この記事は、その2つで分かったことを書きます。

最初からこの形だったわけではありません。はじめのうちは、Claudeに依頼文だけを作らせて、それを人がコピーして自分のCodexに貼って実行していました。手間はかかりますが、画像は作れる。

Claudeから直接Codexを呼べるようにしたのが、10日ほど前です。そこから毎日回してきて、1回で決まるときと、何度もやり直しになるときがありました。振り返ると、分かれ目はモデルの性能ではなく、こちらの発注のしかたにありました。

Claude Codeは絵を描けない。だから外に出す

まず、なぜ2つ使うのか。

Claude Codeには画像生成の機能がありません。Anthropicの公式ヘルプも、Claudeは画像生成ツールのように写真やイラストを作るわけではない、と書いています。ただしHTMLやSVGで図やチャートを組み立てることはできる、とも。理由は以前の記事に書きました。

この「SVGなら描ける」が、あとで効いてきます。放っておくと、Codex側もコードで図を組み立てようとするからです。

一方、Codexには画像生成が組み込まれています。公式ドキュメントによれば、内蔵の画像生成は gpt-image-2 を使うとのこと。UI素材、バナー、背景、イラスト、スプライトシート、プレースホルダーといった用途が想定されている、とも書かれています。

つまり役割分担ができます。文章はClaude、画像はCodex。1つのAIに全部やらせようとしない、というだけの話です。画像そのものを業務でどう使うかはGPT Image 2の記事にまとめました。

提供条件を2つ押さえておきます。まず、料金の説明に 画像生成はFreeプランでは利用できないと明記されています。有料プラン、またはAPIキーでの課金が要ります。

もう1つ。同じ公式ドキュメントに、画像生成を含むターンは、含まないターンに比べてプランに含まれる利用枠の消費が平均で3〜5倍速いと書かれています。画質やサイズによる、という条件つきです。定額の枠内なら即座に追加費用が出るわけではありませんが、作り直すたびに枠は減ります。枠を使い切ったあとの追加クレジットやAPI課金は、そのまま金額になります。

つなぎ方はコマンド1本。しかも毎回は打たない

仕掛けは、拍子抜けするほど単純です。Claude Codeがターミナルからコマンドを1本実行する。それだけです。

ただ、ここでいちばん言いたいのは別のところにあります。このコマンドを、私たちは毎回打っていません。

Codexには非対話モードがあります。公式ドキュメントは、CIやスケジュールジョブの一部として実行する、他のツールに流せる出力を作る、といった用途を挙げています。人が画面の前に座らずに走らせるための入口です。

実際に使っているのは、こういう形です。

codex exec -s workspace-write -m gpt-5.6-sol "(依頼文)"

押さえておくところが3つあります。

サンドボックス。-s で指定します。既定は読み取り専用で、ファイルを書かせるなら workspace-write が要ります。画像を保存させるので、ここは書き込み可にする。逆に、記事のレビューをさせるときは読み取り専用のままにして、原稿を勝手に書き換えられないようにしています。書き込み可にしたら、どこに何を書いたかは人が見る前提です。

モデル指定。-m で指定する gpt-5.6-sol は、Codex側で作業を進めるモデルです。画像そのものを描くのは、その中から呼ばれる gpt-image-2。ここは別々なので、混同しないでください。

出力。公式によれば、進捗は標準エラーへ、最終的なメッセージだけが標準出力へ出ます。だから依頼文の最後に「保存したパスを報告して」と書いておけば、進捗に埋もれずに結果を受け取れます。決まった形式で機械的に処理したいなら --output-schema を使う手もあります。

1つ実務的な注意を。依頼文をそのまま二重引用符で囲むと、文中に " や $ が入ったときにシェル側で壊れます。あとで書くとおり、画像に入れる文字を引用符で渡す運用と相性が悪い。長い依頼文は標準入力から渡すほうが安全です。

なおMacでは、証明書の問題でCodexが起動しないことがあります。そこで詰まった話は別記事に書きました。2つを併用するときの設定ファイルの持ち方は、CLAUDE.mdの記事のほうです。

手順書に書いてあるので、指示しなくても動く

さきほどのコマンドを、人が毎回入力しているわけではありません。記事を書く手順そのものを、Claude Codeが読むファイルに書いてあります。

Claude Codeには、作業手順をまとめて置いておくスキルという仕組みがあります。うちはリポジトリの .claude/skills/ の下に1本置いて、記事を仕上げるまでの流れを書いています。テーマを決めて、調べて、書いて、画像をCodexに作らせて、レビューにかけて、公開前の確認をする。

ファイルの先頭には、どういうときに使うかの説明文を書きます。「記事化して」「ブログ記事を書きたい」といった言葉が出たら使う、という具合に。Claudeはその説明文を見て、いまの依頼に関係しそうだと判断したときに中身を読みます。

だから実際のやりとりは、こうなります。

今日のブログテーマだけど、(内容)にしたい。調査して記事化して

最初に人が出すのは、これだけです。ここから構成を詰めるやりとりが入り、そのあと本文を書きます。人が口を出すのは、主題がぼやけている、この言い切りは強すぎる、この章は削ろう、といった中身の話です。

画像の話は、そのどこにも出てきません。それでもClaude Codeは、本文を書き終えたところでスキルに従い、自分でCodexを呼び出します。上がってきた画像を確認して、崩れていれば作り直しまでやる。

1回きりの裏技ではなく、業務の手順として書いてあるからです。ただし、必ず発火する仕組みではありません。説明文と依頼が噛み合わなければ使われないこともあるので、そこは人が見ています。

そして、だからこそ次の話が重要になります。人が最後には見るとしても、途中の検査を書いておかないと、崩れた画像が人のところまで素通りしてくるからです。

効いたのは、依頼文に足した5つ

最初のころ、私たちはこう頼んでいました。

記事を読んで、内容を表すインフォグラフィックを自由に設計して生成してください。

丁寧に書いたつもりでした。出てきたのは、文字が1つも入っていない、アイコン2つと矢印1本だけの絵です。間違ってはいない。ただ、記事の中身は何も伝わらない。

やり直すうちに、効く指示が5つに絞れてきました。

コードで描かせない、と最初に書く

前の章で、Claudeは画像は作れないがHTMLやSVGでなら図を描ける、と書きました。Codex側も同じで、放っておくとSVGを書いて図を組み立てようとします。

出てくるものは整然としていますが、硬い。ブログのヒーロー画像は、正確さより「ぱっと見の温度感」が要るので、そこが合いません。

なので依頼文の冒頭に、毎回この一文を置いています。

SVGコード作図ではなく画像生成AIを使って自由に。文字も使ってOK

これを書かないと、残りの4つをどれだけ丁寧に書いても、返ってくるのは図面です。

密度を数字で伝える

「情報量のある図解に」では動きません。意味のあるブロックを3〜4つ、というように数を出す。

逆に詰め込みすぎたときは、上限を書きます。囲み枠を10個以上並べない、小さな正方形を敷き詰めた図は使わない。減らす指示も、数字にしないと伝わりません。

使ってよい語句をリストで渡す

これがいちばん効きました。記事本文に出てくる語句だけを抜き出して、そのまま渡します。

公式ドキュメントも同じことを言っています。画像内の文字は短くし、正確に指定すること。入れたい文字は引用符でくくって渡すこと、と。

副次的な効果もあります。AIが本文にない数字や固有名詞を作りにくくなる。完全に止まるわけではないので、最後は受け取った側で見ますが、そもそも出にくくなるのは大きい。図の中に、記事に書いていない数値が入るのは記事の信頼を直接壊すところなので。

使ってはいけない語句も渡す

見落としがちですが、これも要ります。

記事を書き直して、いったん採用した表現を撤回することがあります。そのとき禁止語句を書かずに再依頼すると、古い表現が復活します。毎回あたらしく codex exec を呼んでいるので、前回のやりとりは引き継がれません(codex exec resume を使えば継続できますが、うちはそうしていません)。結果として、渡した記事から拾い直すか、前の画像を参照してしまう。

変えない部分を明示する

いちばん最近やらかしたのが、これです。

できあがった画像の見出しを、一語だけ直したいことがありました。「構図はそのまま、この1語だけ変えて」と頼んだところ、文字は正しく直った代わりに、画像全体の色が褪せました。

指示していない属性は、再解釈されます。人に頼むなら「他は触らないで」で通じますが、AI相手には、何を維持するかまで書く必要がありました。どれくらい変わったかは、次の章で数字にします。

自己申告は当てにしない。測るのは受け取った側

Codexは作業のあと、こう報告してくることがあります。

拡大して全文字を1文字ずつ目視確認済みです。文字化け、濁点の潰れ、にじみ、はみ出しはありません。

丁寧です。そして、そう報告してきた画像に崩れがあったことが、何度もあります。嘘をついているわけではなく、自分の出力を自分で評価することの限界だと思っています。人の校正と同じで、書いた本人はミスを見つけにくい。

ここで大事なのは、依頼文に「ちゃんと測って」と足すだけでは解決しないことです。測った結果を報告するのも同じCodexなので、自己申告が一段増えるだけになる。

だから役割を分けています。

誰が	何をするか
Codex	画像を作る。自分でも確認する
Claude Code	受け取ったあと、あらためて自分で測る
人	最終的に見て、公開するかを決める

真ん中が肝です。Claude Codeが画像を開いて、見出しやラベルを拡大して切り出し、1文字ずつ見る。あわせて、色や比率を実際に数える。

厳密に言えば、文字を見るほうは別のAIの主観なので、目が変わるだけです。数えるほうは違います。スクリプトが出す数字に主観は入らないので、ここは自己申告から離れます。最終的な合否は人が決める、という順番です。

例を2つ挙げます。

1つは比率。「50%増」を表す横棒を作らせたとき、シアン部分とアンバー部分の横幅を測ったら、アンバーがシアンの66%ありました。ラベルは50%増なのに、絵は66%増。そこで依頼文にこう足しました。

生成後、シアン部分とアンバー部分のピクセル幅を実際に測り、アンバーがシアンの45〜55%に収まっていることを確認すること。外れていたら保存せず再生成する

次に上がってきた画像をこちらでも測ると49%。Codexの申告値とも一致しました。

もう1つは色です。できあがった画像の見出しを一語だけ直させたとき、文字は正しく直った代わりに、指定していたシアンの画素が17,718個から0個になりました。淡い水色に置き換わっていた。目で見ても「なんとなく褪せた」とは思うのですが、感覚だけだと差し戻しにくい。

そこで依頼文に画素数の下限を書き、こちらでも同じ条件で数えるようにしました。次の画像は、変わったのが88×86ピクセルの1文字分だけで、それ以外は元画像と完全に一致していました。

測り方は難しくありません。画像を読み込んで、指定した色に近い画素を数えるだけです。数十行のスクリプトで足ります。

「確認してください」と「数えて、閾値を外れたら保存するな」の差です。前者は主観なので通ってしまう。後者なら、作る側と受け取る側が同じ物差しで判断できます。

公式ドキュメントにも、文字の多い画像や仕上がりが重要なタイポグラフィについては、一語ずつ確認し、必要ならデザインツールで仕上げることと書かれています。作る側も、そこは人が見る前提で設計しているということです。

AIがAIに発注するとき、誰が検収するのか

ここまで画像の話でしたが、効いた4つは画像に限りません。

• 曖昧な依頼には、最小構成の答えが返る
• 使ってよい材料を渡すと、勝手な創作が減る
• 変えてほしくない部分は、明示しないと変わる
• 検収の基準は、数値にしないと通ってしまう

外注に置き換えると、どれも当たり前です。「いい感じにお願いします」で発注して、上がってきたものを見て「そうじゃない」となる。制作会社との間で起きることが、そのままAIとの間でも起きています。

違うのは2つ。やり直しのコストが安いことと、検収する人がいなくなりがちなことです。

前者のせいで、雑な発注でも回ってしまう。回ってしまうから、発注のしかたが上達しません。

厄介なのは後者です。外注なら、納品物を検収するのは発注側の人間でした。AIに任せると、そこまで省きたくなる。「AIに作らせて、AIに確認させた」で完結したように見えてしまうからです。

しかし、作った当人の確認は検収ではありません。誰が合否を決めるのかを先に決めておかないと、品質の責任が宙に浮きます。うちの場合は、測るのをClaude Code、決めるのを人、と分けました。

これもスキルに書いてあります。依頼のしかたを自動にしたなら、検査のしかたも同じ場所に書いておく。片方だけ自動にすると、人のところに来る前の関門がなくなります。

文章のほうは、逆向きに頼んでいる

同じ考え方を、記事本文にも当てはめています。画像とは向きが逆で、書くのがClaude、読むのがCodexです。

原稿ができたら、書き込み権限を外したCodexに読ませます。見てもらうのは5つ。事実が正しいか、話のつなぎ方に飛躍がないか、読者が誤解する言い切りがないか、文章がAIっぽくなっていないか、この記事にしかない視点があるか。

読み取り専用にしているのは、勝手に直させないためです。直すかどうかを決めるのは、指摘を受けた側の仕事なので。

なぜCodexなのか、とも聞かれます。Claude Code同士でも、セッションを分ければレビューはできます。それでも別のAIに読ませているのは、視点を変えたいからです。同じモデルだと、書いたときと同じ前提のまま読んでしまう。あとは単純に、Claude側のトークンを使わずに済む、という理由もあります。

実際に効きます。この記事も、最初の版では標準出力の挙動を「その1行だけ受け取れる」と書いていました。公式が保証しているのは「最終メッセージだけが標準出力に出る」ことで、1行である保証はない。指摘されて直しました。自分で書いて自分で確認していたら、まず気づいていません。

まとめると、こうなっています。

作るのは	検査するのは
画像 = Codex	Claude Code が測る
文章 = Claude	Codex が読む

どちらも、作った本人以外の目が1つ入っています。主たる検査役を、作った側とは別のAIに置く。それだけの話ですが、いまのところ一番効いています。

もちろん作った側も自分で確認しますし、最後は人が見ます。代わりではなく、間に1枚挟むという話です。

記事1本の画像で、最大4回作り直したことがあります。そのうち3回は、依頼文に書いていなかったことが原因でした。AIの性能ではなく、こちらの指示の穴です。

指示の型が固まってからは、1回で決まることが増えました。同じモデル、同じツールです。変えたのは頼み方と、検収のしかただけ。

まとめ AIに任せる前に、発注書と検収基準を書けるか

要点を並べます。

• 画像生成はClaude Codeにはなく、Codexには内蔵されている。描くのはgpt-image-2。Codex側で作業を進める -m のモデルとは別
• 画像生成はFreeプランでは使えない。有料プランかAPI課金が要る。画像を含むターンは、含まれる利用枠を平均3〜5倍速く消費する
• つなぎ方は codex exec を1本呼ぶだけ。ファイルを書かせるならサンドボックスは workspace-write
• 効いた指示は5つ。コードで描かせない / 密度を数字で / 使ってよい語句をリストで / 禁止語句も渡す / 変えない部分を明示する
• 作った当人の確認は検収ではない。測るのは受け取った側。閾値を決めておけば、主観で通らなくなる
• 依頼も検収も手順書に書いておく。依頼だけ自動化すると、誰も確認しないまま出ていく
• 画像はCodexが作ってClaude Codeが測り、文章はClaudeが書いてCodexが読む。作る側と検査する側を入れ替える

すぐ試すなら、いまAIに頼んでいて出来に満足していない作業を1つ選んでください。そして、その依頼文に、変えてほしくないことと、合格の基準を足してみてください。たいていはその2つが抜けています。

そのうえで、合否を誰が決めるのかも決めておく。うちの画像は、そこを整理しただけで作り直しがぐっと減りました。