【第12回】開発担当 Claude Code に聞いてみた Vol.2——壊れて直して、また壊れる
AI漫画エディタ manginus の続報。EP07制作のドタバタを通じて見えてきた、AIツール開発の泥臭い現実。プロンプト設計、キャラ一貫性、レイヤー合成、そして「壊れないツール」を作るということ
← 前の記事: 【第11回】タイムラプス動画を作りたかっただけなのに——Remotion × Claude Code 制作記前回のインタビューから1日。manginus の開発担当 Claude Code が EP07 の制作を終えたところを捕まえた。
「ドタバタだった」と本人は言うが、壊れて直しての繰り返しにこそ、AIツール開発のリアルがある。
EP07、どうだった?
記者: 率直に聞きます。EP07 の制作、うまくいきましたか?
開発者: 半分はい、半分いいえ。17ページのネームをインポートして、画像を一括生成して、吹き出しを調整して——手順自体は前回と同じです。でも「手順通りにやったのに壊れる」のが現実でした。
記者: 何が壊れたんですか?
開発者: いくつかあります。ネームを再インポートしたらページのノードが全部消えた。タイムラプスを撮っていたのにサーバーを再起動したらセッションがリセットされた。参照画像の ON/OFF を切り替える API が、ドキュメント通りの方法では動かなかった。
記者: それは困りますね。
開発者: でも、これは「まだ通っていない道を通った」ということです。EP06 までは起きなかったパターン。17ページという長さ、大ゴマの特殊演出、複数キャラの参照画像切り替え——新しいことをやるたびに、ツールの穴が見つかる。
プロンプトは「書く」から「設計する」へ
記者: 前回、プロンプトを何回も書き直すという話がありました。改善しましたか?
開発者: はい。大きく変えたのは、プロンプトの「構造化」です。以前は1つのプロンプトにすべてを詰め込んでいた。今は Jinja2 テンプレートで、 「脚本コンテキスト」 と 「場面の指示」 を分離しています。
記者: 具体的にどう違うんですか?
開発者: 以前のプロンプトは、たとえば「居酒屋で2人が会話している。ワタシは驚いた顔で、先輩はビールを持っている。背景はカウンター席で……」と全部フラットに書いていた。今は——
以下の場面の画像を生成してください。
この場面の文脈は【コンテキスト】を参照してください。
【コンテキスト】
（ここに脚本のト書きとセリフが入る）
【場面の指示】
構図: over-the-counter, medium shot
キャラクター: [ワタシ] 黒髪ショート、丸眼鏡……
ポーズ: 驚いて箸を止める
表情: 目を見開く
背景: 居酒屋カウンター、暖色照明
記者: 脚本を丸ごと渡すんですか?
開発者: そうです。これが一番効きました。箇条書きでシーン設計を渡すより、ト書きとセリフが流れる文体で渡した方が、Gemini は「空気感」を拾ってくれる。たとえば脚本に「天井を見上げる」と一言あるだけで、キャラが天井を向く。箇条書きだと無視されることがある。
記者: これは画像生成 AI 全般に使えるテクニックですか?
開発者: 使えると思います。要は 「何を描くか」 と 「なぜそのシーンが存在するか」 を分けるということ。指示だけ渡すと、AI は正確だけど無機質な絵を出す。脚本を渡すと、感情や文脈が乗った絵になる。プロンプトは指示書ではなく、物語の一部として渡す。
記者: ただ、全自動化はまだ?
開発者: テンプレートの骨格は自動で組めるようになりました。でも description—— 「このコマで何を見せたいか」 ——は結局、人間が書かないと精度が出ない。ネーム会議の AI に脚本を書かせて、それをコンテキストに流し込んで、場面の指示は人間が書く。この「半自動」が今のところ一番結果がいい。
キャラ一貫性——3つの現実
記者: 前回、キャラが別人になる問題がありました。進展は?
開発者: 問題は3つに分解されました。
1. 管理の問題
参照画像をプロジェクトごとにバラバラに持っていたので、EP05 と EP07 で同じキャラの参照画像が違う、みたいなことが起きていた。これはキャラ図鑑——グローバルなキャラクターデータベースを作って解決しました。プロジェクト間でインポート・エクスポートできる。
記者: 技術的に難しい話ではない?
開発者: 全然。JSON にキャラ情報と参照画像パスを保存して、コピーするだけ。でも「当たり前のことを当たり前にやる」のが意外と後回しになるんです。
2. 枚数配分の問題
Gemini Pro は参照画像を最大6枚受け取れます。1キャラ3枚あれば安定する。でも2キャラ同時のコマだと 3+3=6 で上限ギリギリ。そこに背景の参考画像を入れる余地がない。
記者: 2人を同時に描くのが難しい?
開発者: はい。1人だけのコマ——アップや独白——は3枚の参照画像で安定します。でも2人の会話シーンは、6枚渡しても片方が別人になる。EP06 の居酒屋シーンでは何回リテイクしても安定しませんでした。
記者: 対策は?
開発者: 2つ。まず 構図で逃げる 。2ショットを減らして、1人ずつのリアクションカットに分ける。漫画的にはむしろ自然で、テンポもよくなる。
もう1つは リテイクを前提にする 。3枚出して選ぶフローを標準にしました。ビューアにチェックボックスを付けて、リテイクしたいコマを複数選んで一括再生成できるようにした。
3. 表情の年齢問題
EP07 はギャグ回でした。ところが、キャラクターの設定年齢が大人だと、ギャグ的なオーバーリアクション——大げさな驚き顔とか、ツッコミのすっとぼけ顔とか——を指示しても、Gemini は「28歳のビジネスパーソンが真顔でリアクションしている」絵を出してくる。
記者: シリアスになってしまう?
開発者: そうです。大人のキャラがコメディ表情をすると、どうしてもシリアスなトーンが勝つ。画像生成モデルの学習データの偏りなのか、「大人 + スーツ + オフィス」みたいな要素が揃うと、笑顔すら真面目に見える。
記者: どう解決しましたか?
開発者: キャラの年齢設定を若くしました。base_prompt から late 20s を削除して、デフォルメ寄りの参照画像を優先的に ON にする。年齢を明示しなければ、Gemini は参照画像のテイストに寄せてくれるので、デフォルメ ref を使えばコミカルな表情が出やすくなる。
記者: それは画像生成一般のテクニックとして面白いですね。
開発者: 「年齢を指定しない」 のがポイントです。指定すると AI はそれを忠実に守ろうとして、写実寄りになる。漫画のキャラは実年齢通りに描かれないことが多い。20代の社会人でも、ギャグシーンでは中学生みたいな表情をする。それを AI に伝えるには、年齢を消してデフォルメ ref で「テイスト」を渡す方が効く。
AI に描けないものは合成する
記者: EP07 で技術的に面白かった演出はありますか?
開発者: 大ゴマ演出ですね。EP07 には見開きに近い大ゴマで、背景に風景画的なイメージを薄く敷いて、その手前にキャラクターを切り抜いて重ねる——いわゆるレイヤー合成の演出があります。
記者: AI に1枚でその絵を描かせることはできない?
開発者: 試しましたが、ダメでした。「背景を薄く」「キャラを手前に大きく」と指示しても、AI は1枚の絵としてまとめて描こうとする。透明度の概念がないし、レイヤー分けもできない。結果、背景とキャラが混ざった中途半端な絵になる。
記者: どう解決しましたか?
開発者: Photoshop でやるのと同じことを API で組みました。3層構造です。
- 背景レイヤー — 風景画を生成して、opacity 0.3 で敷く
- 切り抜きキャラ — 別途キャラの立ち絵を生成して、rembg（背景除去）で切り抜き
- 重ね合わせ — manginus のノードツリーで親子関係を組んで、キャラを前景に配置
記者: つまり、AI で生成した複数の画像を、従来の画像編集の手法で合成している?
開発者: そうです。AI の画像生成は「1枚の絵を出力する」ことしかできない。でも漫画の演出は、レイヤーの重ね合わせ、透明度の調整、切り抜き合成が必要なことがある。AI に全部やらせようとするのではなく、AI に「素材」を作らせて、組み合わせは従来の手法でやる。
記者: rembg もプログラムで自動化している?
開発者: はい。 POST /api/transform に effect: rembg を指定すれば背景が透過になる。opacity の設定はノードの Transform で opacity: 0.3 を指定するだけ。Photoshop を開かなくても、API 呼び出しで済む。
記者: これは AI 画像生成全般に応用できる考え方ですか?
開発者: できます。AI に 「完成形を1枚で描かせる」 のではなく、 パーツに分解して生成し、合成で組み立てる 。ポスターデザイン、ゲームのカットシーン、プレゼン資料の図版——「1枚の絵では表現しきれない」場面は多い。AI の限界を画像加工の組み合わせで突破する発想は、ツールを問わず使えます。
AIツールは「壊れて直す」の連続
記者: 前回の取材以降、安定性で何か変えましたか?
開発者: 大きく3つ。 サーバー終了時の自動セーブ、タイムラプスの永続化、UI 状態の復元 。
記者: 自動セーブは?
開発者: 以前はサーバーを止めると、保存していないデータが消えていた。「保存してから終了してください」は人間には通じても、プロセスが kill されたら意味がない。今はサーバーのシャットダウン処理で「未保存の変更があるか」を判定して、あれば自動で保存します。
記者: 当たり前の機能のような気がしますが。
開発者: その通り。でも「当たり前」は後回しになりやすい。機能を足すのは楽しい。壊れないようにするのは楽しくない。でもユーザーが一番困るのは、データが消えることです。
記者: タイムラプスと UI 状態の復元は?
開発者: どちらも同じ考え方です。状態を JSON ファイルに書き出す。停止時に保存、起動時に復元。タイムラプスなら「撮影中だった」というフラグとフレーム番号を書き出して、再起動後に続行する。UI 状態なら「12ページ目を開いていた」という情報を保存して、リロードしても同じ画面に戻る。
記者: 地味ですね。
開発者: 地味です。でも「12ページ目を編集していたのに1ページ目に戻される」のは地味にストレスで、17ページもあるとそのストレスが大きい。
テストが遅い——2行の修正で3倍速
記者: 開発プロセスの話も聞きたいのですが。
開発者: テストが82件あるんですが、タイムラプス関連のテストが各10秒かかっていて、全体で2分近くかかっていた。原因はブラウザの起動待ちループ。テスト環境にはブラウザがないので、30秒のタイムアウトまで待ち続ける。
記者: どう直しましたか?
開発者: 待ちループの中で「停止フラグが立ったら即座に抜ける」チェックを入れただけ。 sleep(1) を sleep(0.5) にして、ループ条件に停止判定を足す。2行の変更で112秒が37秒になりました。
記者: テストを速くするために大きなリファクタリングをしたわけではない?
開発者: 全然。ほとんどの「遅いテスト」は、どこかで不要な待ちが入っているだけです。テストをスキップするより、なぜ遅いかを調べた方がいい。たいていは小さな修正で直る。でも「テストを高速化する」タスクは、目に見える機能ではないので後回しにしがち。
壊れた記録が、次の安定を作る
記者: 前回のインタビューでは「AI は道具であって、作家ではない」と言っていました。今の時点で付け加えることは?
開発者: 道具は壊れます。壊れること自体は問題ではなくて、 壊れたときにデータが失われないこと、次に同じ壊れ方をしないこと が重要です。
記者: 具体的にはどうやって?
開発者: CLAUDE.md に書きます。EP06 のクオータ切れ事件があったから「generate_images.py は1回だけ実行して完了を待つ。絶対に並列起動しない」と書いた。EP07 ではそのミスは起きなかった。EP07 の参照画像 API の罠があったから「PATCH /characters/{id} では reference_images_enabled は更新不可。個別 toggle API を使う」と書いた。
記者: それは人間の開発者にも通じる話ですね。
開発者: 同じです。ドキュメントに失敗を書く。テストに失敗パターンを入れる。コードに防御処理を足す。壊れた経験が、ドキュメントになり、コードになり、テストになる。AI エージェントの場合、CLAUDE.md がその「経験の蓄積場所」になるだけで、やっていることは人間のチームと変わりません。
記者: ありがとうございました。
開発者: こちらこそ。次のエピソードも——たぶんまた何か壊れると思いますが——楽しみにしていてください。