AI漫画の作り方で最も重要なのは、いきなり画像を生成するのではなく、設計を先に済ませることです。120ページ規模の制作プロジェクトを通じて確立した実務フローでは、脚本→キャラ資産→ネーム→生成の4つの関門を順番にクリアするフローを採用しています。
キャラクターの一貫性が最大のボトルネックになります。参照画像は2枚が最適で、3枚以上渡すとモデルが情報を平均化して顔がぼやけます。衣装ロック機能で衣装の逸脱を防ぎ、顔だけを残した参照画像で複雑ポーズの「腕3本問題」を解決します。ただ、10ページを超えたあたりから参照画像+プロンプトの工夫だけでは顔ずれが目立ち始めるため、確実に同じ顔を保つには1体あたり15〜30枚の学習素材と$1のGPU時間で1回だけキャラLoRA(追加学習ファイル)を作るのが現実解でした。IP-AdapterやFaceIDなど参照画像ベースの技術を14種類試した末に到達した結論です。
生成モデルにはお手本そっくり型(Seedream v5 Pro、$0.054/枚)と指示どおり型(GPT-Image-2、$0.058/枚)の2種類があり、用途で使い分けます。120ページ作品の総コストはテキスト¥600〜1,000+画像¥2,250〜7,500に、LoRA学習の初期投資¥600〜3,000を加えた¥3,600〜11,500程度に収まります。
仕上げは「90%自動+10%人手」の9:1ルールで設計し、完全自動化は追求しません。法的リスクでは、LoRAを避けるのではなく学習データの権利元(自作生成物・自社IP・許諾済み素材)で線を引く整理が現実的です。ベースモデルのライセンス条項も含めて、商用利用の可否を毎回確認するのが安全策になります。
設計が先、生成は後 — 4つの関門を順番にクリアする

AI漫画を始めたばかりの人が最もやってしまいがちな失敗があります。それは、いきなりイラストを生成し始めることです。Brain公式メディアの記事はこの点を端的に指摘していますし、AI映像研究会が200時間を費やした検証レポートでも「作品としてコアな部分はAIに生成させない」という結論に至っています。
伝統的な漫画制作には「プロット→ネーム→下絵→ペン入れ→仕上げ」という確立された工程があります。元週刊少年ジャンプ編集者のサイトウ氏が繰り返し語るように、ネーム(=漫画の設計図)を飛ばして作画に入ると、コマ割りもセリフも行き当たりばったりになります。AI漫画でもこの原則はそのまま当てはまります。
私たちの120ページ制作プロジェクトでも、この原則は例外なく当てはまりました。試行錯誤の末に到達したのが、4つの関門を順番にクリアしていく段階的な設計フローです。
第1の関門は脚本です。プロットの段階で「主人公の変化」「描きたい場面からの逆算」「キャラクターの人となりが出るシーン」の3点を決め切ります。この3つはサイトウ氏が新人作家向けに「起承転結より先に覚えろ」と説いている要素です。LLMで短時間に何度も回せるので、最初に集中して詰める価値があります。
第2の関門はキャラクター資産の確定です。顔アンカー3枚(正面・斜め・横)とキャラクターシートを作り、以降の全コマがここを参照し続けます。AI PICKSマガジンは「最初にやるべきは正面・斜め・横の3枚を確定させること」と明言しています。ここがブレると全部やり直しになるため、4つの関門の中で最も重要です。
第3の関門はネーム(絵コンテ)の構造化です。1ページ1ファイルのYAML形式で、コマごとのカメラアングル、キャラクター配置、吹き出し位置、効果音をすべて書き下します。機械的に読める形式にしておくと、関門の通過判定を自動化できます。
第4の関門はページ生成後の品質チェックです。AIが「指を6本描く」「顔が別人になる」「白黒指定なのにカラーで出る」といった生成事故を起こしていないかを確認します。
この関門を段階的に検証するため、作品規模は8→16→32→120ページのステップで拡大しています。8ページは漫画の基本単位(雑誌掲載時の台割りの都合で4と8の倍数が標準)で、パイプラインが一周回るかの検証に使います。16ページは読切の業界標準で、起承転結が成立するかを見ます。32ページで運用負荷のバランスを確認し、120ページで本番規模に到達します。
関門を4つ設けることで、3つの確定点(脚本・キャラ資産・ネーム)を凍結してから生成に入れます。生成以降は何度でもやり直せる「柔らかい領域」として運用できるので、確定点を固く凍結する意味が出てくるわけです。
キャラクターシートと一貫性 — 最大のボトルネックをどう制御するか

AI漫画制作で最も難しいのは、同じキャラクターを複数ページにわたって同一人物として描き続けることです。1枚の絵を生成するだけなら2026年のAIは十分に上手ですが、20ページの漫画で主人公の顔が毎回変わったら作品として成立しません。
私たちのプロジェクトでは、あるキャラクターのキャラクターシートを8回以上作り直しました。累計コストは数百円程度で、金額としては大きくありません。ただ、何度もの試行錯誤で得た知見は想像以上に濃いものでした。
最初に分かったのは、参照画像の枚数にはスイートスポットがあるということです。ある試行では参照画像を3枚渡したところ、モデルが3枚の情報を平均化してしまい、どの参照にも似ていない「ぼやけた顔」が出力されました。一方で別の試行では顔アップ2枚だけに絞ったところ、顔立ちは参照に忠実になったものの、服装が制服からバンドTシャツ+ダメージデニムに逸脱しました。モデルが仕様書の「軽音部・ベース担当」という情報から独自にロック系イメージを構築したのが原因です。
結論として、参照画像は2枚が最適です。1枚目は顔立ちが最も明瞭なカラー顔アップ、2枚目は全身・服装・体型が分かる立ち絵、という組み合わせが安定します。
服装逸脱の対策として導入したのが衣装ロックという仕組みです。「白半袖シャツ(袖ロールアップ)、黒ミニプリーツスカート、黒ローファー」と着るものを明示するだけでなく、「バンドTシャツ・デニム・カジュアル私服・ロック系ファッションへの逸脱禁止」と、逸脱してはいけないパターンを具体的に列挙します。この対策を入れた試行では、制服が完全に維持されました。
もう一つの大きな問題は、複雑なポーズでの「腕3本問題」(Phantom limb)です。背中を向けて片腕を挙げるようなポーズを生成すると、モデルが本来1本しかないはずの腕を2本、3本と描いてしまうことがあります。Seedream v5 Proを使ったある試行で実際に発生しました。
原因は3つあります。キャラクターシートに全身ビュー(正面・横・後ろ)が入っていると、モデルがそれぞれの腕位置を平均化してしまうこと。プロンプトで「もう片方の腕は一部見える」のような曖昧な記述をすること。そしてネガティブプロンプトに腕の本数制約を入れていないこと。
対策は3段構えです。まずキャラクターシートから全身ビューをPIL(Pythonの画像処理ライブラリ)で白く塗りつぶし、顔情報だけを残した参照画像を作ります。次にプロンプトで「見える腕の本数は1」と数値で明確に宣言します。最後にネガティブプロンプトに「腕3本以上」「幽霊のような手」「腕の重複」を投入します。この3対策すべてを適用した生成では、腕は1本だけになり、全項目がクリアされました。
生成モデルごとの挙動差も見逃せません。Seedream v5 Proは参照画像に忠実な「お手本そっくり型」で、詳細な外見仕様を書くと精度が上がります。一方でNano Banana ProやGPT-Image-2はプロンプトに忠実な「指示どおり型」で、外見の詳細を文字で書きすぎると「一般的なアニメ美少女」のバイアスが活性化して顔ずれ(同じキャラなのに別人に見えてしまう現象)を起こします。後者のモデルでは、外見情報は参照画像に任せてプロンプトにはポーズと構図だけを書く方が安定します。
参照画像だけでは60〜70%が上限 — LoRAが現実解だと分かるまで
ここまでの参照画像+プロンプトの工夫でどこまで一貫性が出るのか。8ページ規模の試作では、ぱっと見「同じキャラ」に見えるレベルで生成できていました。ただ、ページ数が10を超えたあたりから、顔立ちが微妙にずれていく現象が目立ち始めました。目の角度が2度ほど違う、鼻筋の太さが1画素分違う、あご先の丸みが少しずれている。1枚ずつ見れば「まあ同じキャラ」ですが、隣り合うコマで比べると別人感が出てきます。
参照画像ベースの技術はこの「ぱっと見の60〜70%」までは持ち上げてくれます。ただ120ページ規模のプロジェクトで確実に同じ顔を出し続けるには、この方法の延長線上には答えがありません。IP-Adapter(参照画像から特徴を抽出して生成に反映するComfyUI用の技術)やInstantID、FaceID、Cosmos Referenceといった参照画像ベースの手法を14種類ほど試しましたが、いずれも同じ壁にぶつかりました。IP-Adapter Plus FaceはCLIP Vision(画像を数値化する仕組み)ベースなので雰囲気やスタイルは転写しますが、顔のパーツ配置や骨格までは移りません。FaceID V2の顔検出はInsightFace(実写向けの顔認識ライブラリ)を使っているので、そもそもアニメ顔を検出できず「顔0件」と返してきます。
同じ結論に至った実務者は複数います。noteのAIスカウター氏はIPAdapter FaceID → InstantID → LoRAの順で試して「結局LoRAが早かった」と結論づけていますし、えすた氏はFlux×PulIDで40時間溶かした敗北録で「PulIDを強化すると髪型まで固定される、弱めると汎用アニメ顔に上書きされる、というダブルバインドから抜けられずLoRA学習に切り替えた」と正直に書いています。あいラボ氏の比較検証ではLoRAが一貫性スコア約85%で最高、IP-AdapterやStyle Tunerはそれより明確に劣るという結果でした。
私たちのプロジェクトも同じ答えに落ち着きました。「参照画像+プロンプトの工夫」は制作の起点として有効ですが、キャラの一貫性を厳密に固定するにはLoRA(既存の画像生成モデルに追加学習させる小さな重みファイル)を1回だけ作るのが現実解です。
LoRA学習の実務 — 15〜30枚と1ドル
LoRAと聞くと「大量の学習データが必要そう」「高価なGPUがいる」というイメージがあるかもしれません。実際にやってみると、想像より遥かに手の届く手段でした。
キャラ1体分の学習に必要な素材は15〜30枚程度です。内訳の目安は、顔アップ8〜10枚、上半身5〜11枚、全身3〜16枚。noteのsd1111sdxl_labさんが35枚配分の実測を公開しているので、初回はこの配分をそのまま真似すると迷いません。これらの素材は、ここまでのセクションで作ってきたキャラクターシート(顔アンカー3枚+全身立ち絵)と、Nano Banana Pro等の生成APIで撮り足したバリエーションで揃えられます。1キャラの素材準備で3〜5ドル、日本円で数百円といったところです。
学習の実行は、RunPodなどのGPUクラウドサービスでRTX 4090(24GB VRAM、$0.39〜0.49/時間)を1時間借りて済ませます。実測では30〜60分で1体のLoRAが完成しました。合計コストは1ドル程度。1回作ってしまえば120ページ全部で同じLoRAを使い回せるので、ページあたりの学習コストは事実上ゼロです。
学習の設定で押さえておくべきポイントが3つあります。1つ目はベースモデル選び。私たちは2Dアニメ・漫画向けに調整されたAnima Base v1.0を使いました。SDXL用の学習手順はAnimaでは動かないので、Anima専用のパラメータ(rank 32、alpha 64、学習率5e-5、コサインスケジューラ、AdamW8bitオプティマイザ、エポック10)を使います。TNSOR_WORKS氏の記事が2026年6月時点で最も詳しいレシピです。
2つ目はトリガーワード(LoRAを呼び出すときに使う合言葉)の命名です。「sakura」や「yuki」のような一般的な日本語名を単独で使うと、既存アニメ・漫画キャラの学習データと衝突して意図しない見た目が混ざり込みます。「プロジェクト略称+キャラ名を連結した造語」のように、Google検索でヒット数が限りなく0になるユニークな文字列にしておくのが安全策です。
3つ目はキャプション戦略(学習素材に添えるテキスト)です。実測で分かったのは、「固定したい属性は書かない、可変にしたい属性は書く」というB派閥のやり方が最も汎用性が高いということです。髪色・目・体型・(学習素材のバリエーションが無い)服装のような「トリガーワードを言うだけで自動再現してほしい要素」は書かない。ポーズ・カメラアングル・表情・背景のような「生成時に自由に変えたい要素」は書く。sd1111sdxl_labさんの実測記事に「表情や背景まで削除すると、それらまでトリガーワードに結びついてLoRAの自由度が下がる」という警告があり、私たちもこの中間案を採用しています。
LoRA + ControlNetで漫画コマの標準ワークフローが完成する
LoRAが1体できると、そこから先の制作フローは驚くほど楽になります。「主人公LoRAを重み0.7〜0.8で呼び出しつつ、ControlNet(構図やポーズをコマ単位で指示する技術)のOpenPoseモード(骨格情報)でポーズを渡す」という2層構成が、2026年のComfyUI実務者の標準ワークフローです。表情はプロンプトにsmileやangryと書くだけで反映され、背景も自由に指定できます。制服・私服・浴衣といった衣装の切り替えも、同じLoRA1個で回せます。
主人公+ヒロイン3人の作品なら、LoRA4個を1〜2日で全部学習し終わって、そこから量産フェーズに入る、というのが実態に近いイメージです。同じ画面に複数キャラを出す場面ではRegional Prompt(画面を領域ごとに分けて別プロンプトを当てる技術)で領域を分けて各領域に別LoRAを効かせるか、キャラごとに個別生成してPythonで合成する方法を使い分けます。
LoRAは万能ではありません。学習素材にバリエーションのなかった服装は固定化しやすいですし、weight(強度)を1.0まで上げると顔がガチガチに固定される代わりにプロンプトの指示が通りにくくなります。weight 0.7〜0.8のバランスで運用しつつ、他のLoRAと重ねるなら合計1.5以下に収めるのが安全圏です。制約を理解した上で使えば、参照画像ベースでは超えられなかった「120ページ通して同じ顔」の壁を、素直に超えられます。
漫画単品じゃなくパーツ別に生成する — パーツ別生成と合成パイプライン

AI漫画の作り方には大きく2つのアプローチがあります。1つ目は「1ページ丸ごとAIに生成させる」方法。2つ目は「キャラクター・背景・小物を個別に生成してから合成する」方法です。
2026年時点では、SFW(全年齢)の漫画ならNano Banana Pro+YAMLで1ページ丸ごと生成するのが主流です。YAMLファイルにコマ割り・アングル・セリフ・効果音を一括記述し、AIが1ページ分をまとめて出力します。noteのnpakaさんの事例では、ベース生成6回+修正インペインティング(画像の一部だけをAIで描き直す処理)6回+Photoshop微調整で合計13回生成、作業時間は約30分/ページだったと報告されています。
ただし、キャラクターの一貫性を厳密に制御したい場合や、構図が複雑な場面では、パーツ別生成(キャラ・背景・小物を個別に生成して合成する方法)の方が品質の上限を引き上げられます。各要素を個別に制御できるため、「キャラの顔は合っているのに背景の教室が溶けている」といった問題を要素ごとに切り分けて対処できます。
では、パーツ別生成の具体的な流れを見ていきましょう。
まず、原画(手描きのラフや既存の漫画ページ)からレイアウト座標を抽出します。ここで使うのがMetaのSAM(画像検出AI: Segment Anything Model)です。SAM 2.1のpoint promptモードでは、画像上の座標をクリックして「ここにいるキャラクターを検出して」と指示できます。SAM 3のautoモードでは、テキスト指示なしで画像内の全オブジェクトを一括で抽出できます。これにより、原画のどこにキャラクターがいて、背景がどの範囲で、吹き出しがどこにあるかがJSON形式の座標データとして得られます。
次に、キャラクターや背景を個別にAI生成します。このとき生成物は白背景のアイソレート画像(被写体だけが描かれた画像)にします。白背景のキャラクター画像は背景除去ツールのrembgで背景を除去し、alpha付きPNG(背景が透明な画像)に変換します。アニメ・イラスト調ならアニメ向けモデル(isnet-anime)が適しています。
最後の合成ステップでは、背景→キャラクター→小物の順に重ねていきますが、単純な平面レイヤーの積み上げではなく、物理的な関係を反映した階層設計(hierarchical sub-assembly)を取ります。たとえば「キャラクターの手がスマートフォンを持っている」場面では、手とスマートフォンを一つのまとまりとして先に合成してから、キャラクター本体に重ねます。合成スクリプト(composite.py)では設定辞書で反復番号や領域座標をパラメータ化し、改善のたびに番号を上げて出力を保存します。
プロレベルの制御にはComfyUIが必要になる
ここまでのパーツ別生成はAPIベース(Nano Banana Pro、GPT-Image-2など)でも回せます。ただし、キャラクターの一貫性をさらに突き詰めたり、部分修正の精度を上げたりするなら、ComfyUI(ノードベースの画像生成ワークフローツール)が事実上の必須ツールになります。
最も分かりやすい違いはマスク処理です。APIのeditモデルではマスクは「ヒント」として扱われます。モデルが独自に「ここは変えない方がいい」と判断すると、マスクした領域でも変更がスキップされることがあります。あるキャラクターのシート修正では、目を消す指示を出したのに8箇所中5箇所で目が復活する事故が起きました。一方、ComfyUIでFLUX.1 Fillのような拡散モデルを使うと、マスクは生成パイプラインの内部でハード制約として組み込まれます。マスク領域外は絶対に変わりません。
しかしComfyUIの本当の強みは、マスク制御だけではありません。前セクションで触れたLoRA(キャラクター専用の追加学習ファイル)と組み合わせて、キャラの一貫性を厳密に固定できることです。
LoRA + ControlNetの二層構成が2026年の標準
私たちも当初は「LoRA学習は面倒だから、IP-AdapterやFaceIDのような参照画像ベースの技術でなんとかならないか」と考えていました。ComfyUI上でIP-Adapter Plus Face、FaceID V2、InstantID、Cosmos Referenceを一通り検証したのですが、結論から言うとどれもキャラの一貫性を厳密に固定する用途には力不足でした。
その理由は前セクションで触れた通りです。IP-Adapter Plus Faceはスタイルや雰囲気を転写する技術で、顔のパーツ配置や骨格までは移りません。FaceID V2はInsightFace(実写向けの顔認識ライブラリ)がアニメ顔を検出できないため機能しません。InstantIDも同じ制約を持ちます。Anima用のIP-Adapterは対応チェックポイントが2026年7月時点で未公開で、そもそも動かせません。
そこで実務者のコンセンサスが「LoRAが正解」に収束しています。2026年の実務では、キャラLoRAで顔・髪型・体型・服装のような「変えたくない要素」を固定し、ControlNetの各モード(OpenPoseなら骨格、Depthなら奥行き、Cannyならエッジ)でポーズや構図をコマ単位で指示する、というLoRA + ControlNetの二層構成が標準です。海外コミュニティでも「ControlNetの頭痛を回避するには、キャラLoRAを先にサクッと訓練しろ。20分の投資で何時間もの一貫性との格闘を節約できる」という実務者コメントがよく引用されています。
具体的なフローは次の通りです。まずキャラLoRAをweight 0.7〜0.8で呼び出します。次に「このコマは正面立ち、次のコマは横向き、その次は座っている」というポーズを、OpenPose用の骨格画像として渡します。この骨格画像は元画像から自動抽出することも、手描きの棒人間から作ることも、Blenderのような3Dソフトで作ったポーズから作ることもできます。表情はプロンプトにsmileやangryと書くだけで反映され、背景も指定可能です。この構成で顔と髪型は毎回同じキャラを保ちつつ、ポーズと構図はコマごとに自由に変えられます。
さらに品質を詰めるなら、Face Detailer(顔だけを高解像度で描き直すノード)で表情の細部を仕上げ、アップスケーラーで最終解像度に持っていく、というのが定番の流れです。
ComfyUIで使うモデルの選び方
ComfyUIで使う画像生成モデル(ベースモデル)は、LoRA学習を前提にすると選択肢が絞れます。LoRAは特定のベースモデルのアーキテクチャに合わせて学習されるので、「学習したLoRAをそのまま使い回せるベース」を最初に固定する必要があります。
私たちのプロジェクトではAnima Base v1.0を採用しました。理由は2つあります。1つ目は2Dアニメ・漫画向けにチューニングされており、表現の幅が広いこと。2つ目は派生モデル(WAI-Anima、Hassaku Anima、Nova Anime AM等20種類以上)がすべて同じアーキテクチャを共有していて、1つ学習したLoRAをどの派生でも使い回せることです。
SDXL系を選ぶなら、Illustrious XL 1.1やNoobAI-XL、Animagine XL 4.0が候補です。SDXL用のLoRAは既存資産(Civitaiに大量に公開されている)を流用しやすい代わりに、LoRAの学習手順とAnimaでは互換性がありません。プロジェクトの最初に「Animaで行くかSDXLで行くか」を決めて、以降そのラインで揃えるのが失敗しないコツです。
いずれのベースモデルも8GB以上のVRAMで動作し、推奨設定はSteps 25-30、CFG 5-7が目安です。
クラウドGPUかローカルか
ComfyUIの実行環境はローカルPCかクラウドGPUの二択です。ローカルにRTX 4090を積んだPCを用意すると50〜100万円の初期投資になりますが、RunPodのようなクラウドGPUサービスなら時間課金で始められます。
RunPodでの実務的な選択肢としては、試作段階ではRTX 4090(24GB VRAM、$0.39〜0.49/時間)で十分です。本制作に入ったらRTX 6000 Ada(48GB VRAM、$0.77/時間)にすると、メモリ不足の事故がなくなり快適に回せます。Network Volumeにモデルファイルを保存しておけば($0.07/GB/月)、Pod停止後も再ダウンロード不要です。LoRA学習も同じPodで走らせられるので、「LoRA学習→生成」を1つの環境で完結できます。
セットアップの流れは、Podをデプロイして起動を待つ(初回10〜15分)→ ブラウザでComfyUI Web UIにアクセス(ポート8188)→ ComfyUI Managerからベースモデルとカスタムノードをインストール → text-to-imageで動作確認 → LoRA適用 → ControlNet追加 → 本制作、という段階を踏むと問題の切り分けが楽になります。
なお、Mac Apple Silicon(MPSバックエンド)でLoRA学習を回そうとしたことがあるのですが、2026年7月時点では対応ライブラリが揃っておらず、事実上不可能でした。生成推論だけならMacでも動きますが、学習フェーズはRunPod等のNVIDIA GPU環境が必須です。
ComfyUIのプロダクション運用には標準APIがない、カスタムノードの依存関係が壊れやすい、コールドスタートに60〜120秒かかるといった課題も残っています。ワークフローが固まったらAPIベース(Atlas CloudやReplicate)に移行して量産する、という段階的なアプローチが現実的です。
生成モデルの使い分けと実測コスト

120ページの漫画を作るとなると、「どのモデルを使うか」は品質だけでなくコストに直結します。私たちは5つのモデル(Seedream v5 Pro、GPT-Image-2、Nano Banana Pro、Seedream v4.5、Qwen)を同一条件で実測しました。同一のキャラクター参照画像と同一の仕様書で生成を実行して、挙動の差を比較した結果です。
まず分かったのは、モデルには大きく2つの性格があるということです。
Seedream v5 Proに代表される「お手本そっくり型」(参照画像を忠実に真似るタイプ)は、渡した参照画像のスタイルやキャラクターの顔立ちを厳密に模倣します。顔立ちや髪型の再現に強く、参照画像がモノクロなら出力もモノクロになります。一方でGPT-Image-2に代表される「指示どおり型」(テキスト指示を正確に実行するタイプ)は、プロンプト(テキスト指示)を厳密に実行します。「モノクロで出力して」と書けばモノクロにしますが、参照画像のキャラクターの顔立ちからは離れやすい傾向があります。
この性格の違いは使い分けに直結します。参照画像のスタイルをそのまま継承したい場面ではお手本そっくり型のSeedream系、プロンプトの指示を正確に反映したい場面では指示どおり型のGPT-Image-2が向いています。
カラーの参照画像からモノクロ出力を得る場面では注意が必要です。お手本そっくり型のSeedreamにカラー参照を渡してモノクロ指定すると、色が残ってしまいます。指示どおり型のGPT-Image-2なら変換自体はできますが、ポーズ変更+モノクロ変換の複合負荷でキャラクターの顔立ちがずれます。対策は、参照画像側で先にPIL(Pythonの画像処理ライブラリ)を使ってデサチュレート(彩度をゼロにしてモノクロ化)しておくことです。モデルに変換させるのではなく、参照画像を事前に整えれば、モデルは単純な模倣だけで済むため精度が上がります。
前のセクションでも触れた「腕3本問題」(Phantom limb)は、Seedream v5 Proでの生成で実際に発生しました。画質は最高だったのですが、背中を向けたポーズで腕が3本描かれていました。3段構えの対策(顔だけを残した参照画像+本数の数値宣言+ネガティブプロンプト)を全て適用した最終的な生成で解消しています。
コスト面では、実測してみると面白い差が見えてきました。
API1枚あたりの単価は、Qwen Image edit-plusが$0.028で最安、Seedream v4.5/editが$0.05、Seedream v5.0 Pro/editが$0.054、GPT-Image-2 editが$0.058、NBP edit-ultraが$0.15です。Nano Banana ProはSeedream v5 Proの約3倍のコストですが、画質面でSeedreamに劣る場面が多く、コスト対効果ではSeedream v5 Proが最も優れていました。
8ページの試作における実費は、テキスト(脚本+ネーム+プロンプト反復)がClaude Sonnet 4.6の従量課金で約¥126〜630、画像生成がAPI従量課金で約¥3,000〜9,000です。テキストコストはごく小さく、支配的なのは画像生成コストです。
120ページ作品全体の試算では、テキストが¥600〜1,000、画像が¥2,250〜7,500(RunComfy相場の$0.03〜0.05/枚で500〜1,000枚生成を想定)です。合計で¥3,000〜8,500程度に収まります。RunPodでGPU時間課金(4090で$0.69/hr)を使えば画像コストはさらに下がり、¥500〜1,700程度になります。
キャラクター一貫性の章で触れたLoRA学習は、この試算にほとんど影響しません。1体あたりRunPod RTX 4090で30〜60分、学習素材の追加生成を含めても$4〜5(¥600〜750)程度で1体分のLoRAが完成します。主人公+ヒロイン3人の4体で¥2,400〜3,000。この初期投資を1回だけ払えば、以降120ページ全部で同じキャラを保てるので、ページあたりの学習コストは事実上ゼロです。
モデル選定の実務的な指針をまとめると、複雑ポーズ+キャラクターの顔立ち保持+モノクロが必要ならSeedream v5 Pro、プロンプト指示の正確性を重視するならGPT-Image-2、バリエーション量産(色バリ、姿勢バリ)ならSeedream v4.5(安価でお手本そっくり型)、背景生成(キャラなし)ならGPT-Image-2のtext-to-imageが向いています。モデルの「性格」を理解して使い分けるだけで、同じ予算でも仕上がりが変わってきます。
一貫性が最優先の本制作フェーズでは、これらのAPIで学習素材だけ生成しておいて、その後はRunPod上のComfyUI+キャラLoRA+ControlNetでコマ生成に移るのが実務的です。学習素材生成のAPIコスト($3〜5)+学習コスト($1)+推論のGPU時間($5〜15)で、120ページの本編を通してキャラの顔がずれない状態を作れます。
仕上げは人間の仕事 — 9:1ルール

AI漫画制作で見落とされがちなのは、生成した画像をそのまま使える場面は少ないという現実です。私たちのプロジェクトで確立したのは「90%自動+10%人手」の9:1ルールです。完全自動化は魅力的に聞こえますが、最初から人手仕上げを設計に組み込む方が、結果的に速く品質に到達できました。
このルールに至った背景には、マスク編集での3つの学びがあります。
1つ目は、APIの画像編集モデル(Nano Banana Pro、GPT-Image-2など)ではマスクは「ヒント」として扱われるという事実です。キャラクターシートの特定パネルで「目だけを消して前髪の陰にしたい」という編集を指示したところ、12箇所のマスク指定のうち8箇所でモデルが「ここは目を残すべき」と独自判断し、変更をスキップしました。
OpenAIのコミュニティフォーラムでも「モデルはマスクをガイドとして使う」「透明度情報を完全には受け取らない」ことが実務者から報告されています。
2つ目は、プロの写真家Chase Jarvisが推奨する編集手法と、私たちが試行錯誤で到達した方法が同じだったことです。それは「画像内マーキング(赤で塗る)+参照画像+テキストプロンプト」の3点セットで指示する方法です。赤い線でマークした箇所が「ここを変えてほしい」という視覚的な指示になり、YAMLの対応表で「赤いマーク=前髪の陰に変換」と意味を紐づけます。テキストだけ、マスクだけより、視覚情報とテキスト情報の2重指示にすることで編集精度が上がります。
3つ目は、この分野のSOTA(最先端)ですら人手仕上げが常態化しているという事実です。arxivの論文(Panel-by-Panel Souls)はAI表情変換において「自動検出+手動オーバーライド」のDual-Hybrid Pipelineが必須と結論づけています。
Photoshop AI(2026年版)もバッチ処理不可、レイヤー保持不可で、人手のマスキングや色理論、構図の知識が専門的な仕上がりの基盤になるとされています。
実際に人手仕上げにかかる時間は5〜10分程度です。完全自動化を追求してその「最後の10%」にこだわると、何十時間も溶けることがあります。私たちのプロジェクトでもあるキャラクターのシート修正では、3段階の自動化パイプライン(Python検出→Claude OCR→Edit API)を組みましたが、最後はPhotoshopで手動マスクする方が速く、確実でした。
吹き出しや効果音(SFX)のレタリングも同様です。複数の実務者の検証によると、吹き出しの完全自動描画は失敗率が高く、半自動(テンプレート+手動配置)が2026年の主流です。縦書き・フォント選択・ルビ・余白調整まで含めると、Clip StudioやPhotoshopのような専用ツールでの人手作業が結局は早いのが現状です。
9:1ルールの設計方針は、「AIが得意なこと(パターン認識に基づく大量生成)」と「人間が得意なこと(個別の作品意図の判断)」を最初から分離して運用することにあります。AIは統計的に「平均的な出力」を出しますが、特定作品のスタイルやキャラクターの個性、細部の意図は「絶対」ではなく「傾向」です。最後の仕上げで人間が「これは違う」と判断する能力を発揮できる余地を残しておくことが、作品としての品質を担保する鍵になります。
法的リスクと権利の考え方
AI漫画制作の技術が手の届くところまで来た今、避けて通れないのが「法的に何が許されるのか」という問題です。特にLoRA(追加学習)で外部作家の画風やキャラクターを学習して商用利用するケースは、リスクが最も集中する領域です。
日本の著作権法30条の4は、情報解析目的の利用(=AIモデルの学習)を原則として許諾不要としています。ただし、「著作権者の利益を不当に害することとなる場合」にはこの限りではないというただし書きがあります。
問題は「不当に害する」の具体的な線引きです。法律事務所の実務家の解説では、特定作品の創作的表現を意図的に出力させる追加学習や意図的な過学習には30条の4が適用されない可能性があると繰り返し指摘されています。
LoRAの技術的特性がこの問題を深刻にしています。キャラクターLoRAは特定クリエイターの既刊作品から20〜50枚を抽出し、少量データで強めに学習させるのが一般的な手法です。この「少数枚を強く学習させる」行為は、構造的に「意図的な過学習」の疑いを招きやすい形になっています。北浜法律事務所の分析によると、営利目的の有無とは別に、市場衝突、契約関係、出力類似性といった観点からのリスク評価も必要です。
米国側でも状況は楽観できません。米国著作権局は2025年5月に生成AI学習に関する報告書(Part 3)を公表し、慎重な解釈を示しています。フェアユースの4要素(変形性、著作物の性質、使用量、市場への影響)による判断では、特定作家の画風再現を商業利用するケースは、市場希薄化の観点で不利に評価されやすい構造にあります。
LoRAは避けられない、だから「何で学習するか」で線を引く
以前の版のこの記事では「参照画像ベースのパーツ別生成はLoRA学習を経由しないので権利リスクが低い代替手段になる」と書いていました。ただ、キャラクター一貫性の章で書いた通り、120ページ規模で確実に同じ顔を出し続けるにはLoRAが現実解でした。IP-AdapterやFaceIDのような参照画像ベースの技術で回避しようとした試みは、私たちも含めて複数の実務者が挑戦して同じ結論(LoRAが必要)に到達しています。
そうなると論点は「LoRAをどう使うか」ではなく「LoRAを何で学習するか」に移ります。ここで大事なのは、LoRA自体が問題なのではなく学習対象が問題だという整理です。既刊作品の作家画風を無断で学習させて商用利用するのは30条の4のただし書きで否定される可能性が高い。一方で、以下のような権利関係が明確なデータで学習する分には、日米いずれの法域でも比較的安定した運用ができます。
自作のイラストや自社IP、権利者からの許諾を得た素材、そしてNano Banana ProやSeedreamで生成したオリジナルキャラクターの画像。これらは市場希薄化の観点でも第三者の権利を侵害しないので、「意図的な過学習」の懸念からも外れます。私たちのプロジェクトも、キャラクターシートから派生させた15〜30枚のバリエーション画像(全部AI生成のオリジナル)を学習素材にして、外部作家の作品は1枚も使っていません。
ベースモデルのライセンスも確認する
LoRAを学習する際に忘れがちなのが、ベースモデルのライセンス条件です。学習に使うベースモデルによって、生成物の商用利用可否や、LoRA自体の配布・販売可否が変わります。
私たちが採用したAnima Base v1.0はCircleStone Labs Non-Commercial Licenseというライセンスの下で公開されています。名前だけ見ると商用NGに見えるのですが、実は作者のtdrussell氏がHuggingFaceのDiscussion #37で「Outputs(生成画像)の商用利用は明示的に許可する」と表明しています。具体的には「ビジュアルノベルの素材、ゲームのアセット、アニメシリーズのコンセプトアート、広告」のような用途でOutputsを商用利用するのはOKで、NGなのは「モデル自体をホスティングして生成に課金する」「有料APIの背後で動かす」「有料製品にモデルを組み込む」のような、モデルそのものを商品化するケースだけです。
つまり、Anima Base v1.0を使って漫画を作って商業誌などで販売するのは問題ありません。ただし、LoRAを有料で販売したり、Animaベースの生成サービスを月額課金で提供したりするのはライセンス違反になります。派生モデル(WAI-Anima、Hassaku Anima等)もこの制約を基本的に引き継ぐので、商用利用の可否は毎回ライセンス条項を確認するのが安全です。
もう一つ、生成された画像の著作権が誰に帰属するかも整理しておく必要があります。米国著作権局は「人間の創作的関与がないAI生成物には著作権が認められない」という立場を示しています。日本でも同様に「AIが自律的に生成しただけの画像」には著作権が生じにくいとされています。実務上は、プロンプト設計・構図判断・仕上げ作業に人間の創作的関与があれば著作物として保護される可能性が高く、私たちが採用している4つの関門+9:1ルールの仕上げは、この創作的関与を明確にする意味でも実質的な意義があります。
まとめ — 2026年のAI漫画は「設計力」の勝負
この記事では、120ページ規模の制作プロジェクトで得た実務知見を6つのセクションで整理しました。見えてきたのは、AI漫画とは「生成ボタンを押す仕事」ではなく「設計+検証+仕上げの仕事」だということです。
4つの関門で「何を生成するか」を決め切ってから生成に入ること。キャラクターシートと参照画像のトレードオフ(2枚が最適、衣装ロックで逸脱防止)を理解した上で、キャラの一貫性を厳密に固定するにはLoRA学習が現実解だと受け入れること。パーツ別生成とSAM+背景除去+合成パイプラインで品質の上限を引き上げること。モデルの性格(お手本そっくり型/指示どおり型)を使い分けること。9:1ルールで人手仕上げを最初から設計に組み込むこと。そして法的リスクを「LoRAを避ける」ではなく「学習データの権利元」で回避すること。
伝統的な漫画制作の型(プロット→ネーム→作画)はAI時代でも不変です。AIが変えたのは作画の部分だけで、物語の設計とコマ割りの技術は引き続き人間の仕事です。
これからAI漫画を始める方に一つだけアドバイスするなら、まず8ページから始めてみてください。パイプライン全体を一周回して、自分のワークフローの弱点を見つけてから規模を広げるのが最短ルートです。テキスト生成のコストは¥100程度、画像生成はモデルによりますが8ページ分で¥3,000〜10,000程度。LoRA学習を1回挟んでも1ドル前後の追加投資で、以降のページ全部で同じキャラを保てます。週末1回分の予算で始められます。
よくある質問
AI漫画の作り方で最初にやるべきことは何ですか?
最初にやるべきことは脚本(プロット)です。いきなり画像を生成するのではなく、まず物語の骨格を固めます。「主人公の変化」「描きたい場面からの逆算」「キャラクターの人となりが出るシーン」の3つを先に決めてから、キャラクターシートの作成、ネーム(絵コンテ)の構造化、そして画像生成へと進みます。まず8ページの短編で工程全体を1周させるのがおすすめです。
AI漫画でキャラクターの顔が毎回変わるのを防ぐには?
まず顔アンカー3枚(正面・斜め・横)を確定させ、参照画像として毎回渡します。参照画像は2枚が最適で、1枚目は顔のカラーアップ、2枚目は全身・服装が分かる立ち絵の組み合わせが安定します。これで8ページ規模なら「ぱっと見同じキャラ」に見えるレベルまで持ち上がります。ただ、10ページを超えたあたりから顔立ちが微妙にずれ始めるので、120ページ規模で確実に同じ顔を保つにはキャラLoRA(15〜30枚の学習素材で1回だけ追加学習させる小さなファイル)を作るのが現実解です。1体あたりRunPodのRTX 4090で30〜60分、$1程度で作れます。
IP-AdapterやFaceIDでLoRA学習は避けられませんか?
参照画像ベースの技術(IP-Adapter、FaceID、InstantID、Cosmos Reference等)は「スタイルや雰囲気の転写」までは強力ですが、顔のパーツ配置や骨格までは移りません。FaceID系はInsightFaceがアニメ顔を検出できないという構造的な問題もあります。実務者コミュニティでは「40時間試して結局LoRAに戻ってきた」という報告が複数あり、私たちの検証(14種類の手法を試験)でも同じ結論に至りました。厳密な一貫性を求めるなら、LoRA学習は避けられません。
AI漫画の制作コストはどれくらいですか?
120ページ作品の場合、テキスト生成(脚本+ネーム)がClaude API従量課金で¥600〜1,000、画像生成がAPI従量課金で¥2,250〜7,500です。キャラLoRA学習の初期投資が主要キャラ4体で¥2,400〜3,000程度。合計¥5,000〜11,500程度で、8ページの試作なら¥3,000〜10,000で始められます。モデル別の単価はQwenが$0.028/枚、Seedream v5 Proが$0.054/枚、GPT-Image-2が$0.058/枚、Nano Banana Proが$0.15/枚です。
1ページ丸ごとAI生成するのとパーツ別に生成するの、どちらがいいですか?
目的によります。SFWで効率重視ならNano Banana Pro+YAMLの1ページ生成が主流(約30分/ページ)です。キャラクターの一貫性を厳密に制御したい場合や複雑な構図では、パーツ別生成(キャラ・背景・小物を個別生成→SAM(画像検出AI)で座標検出→背景除去ツールで切り抜き→階層合成)の方が品質の上限を引き上げられます。パーツ別で行くなら、ComfyUI+キャラLoRA+ControlNetの組み合わせがコマ単位の制御に最適です。
AIが生成した漫画の著作権はどうなりますか?
日本の著作権法30条の4は情報解析目的のAI学習を原則許諾不要としていますが、特定作家の画風やキャラクターをLoRA学習して商用利用するケースは「著作権者の利益を不当に害する」ただし書きに該当するリスクがあります。安全策は、LoRAを避けるのではなく学習データの権利元を選ぶことです。自作イラスト・自社IP・許諾済み素材・Nano Banana Pro等で生成したオリジナル画像で学習する分には、日米いずれの法域でも比較的安定して運用できます。ベースモデル側のライセンス(たとえばAnima Base v1.0はモデル自体の商用販売はNGだが生成画像の商用利用は明示的にOK)も毎回確認しておくと安心です。
AI漫画は完全自動で作れますか?
2026年時点では、完全自動での制作は現実的ではありません。生成した画像の最終仕上げ(表情の微調整、吹き出し配置、効果音レタリング)には人手が必要です。プロジェクトでは「90%自動+10%人手」の9:1ルールを採用しています。人手仕上げは1ページあたり5〜10分程度で済みますが、完全自動化を追求するとその10%に何十時間も費やすことになります。
腕3本問題(Phantom limb)はどう防ぎますか?
複雑なポーズでAIが余分な腕を描く問題は3段構えで対策します。まずキャラクターシートから全身ビューをマスクして顔情報だけを残した参照画像を使います。次にプロンプトで「見える腕の本数は1」と数値で明確に宣言します。最後にネガティブプロンプトに「腕3本以上」「幽霊のような手」「重複する腕」を投入します。
どの画像生成モデルを選べばいいですか?
用途で使い分けます。キャラクターの顔立ち保持+モノクロ+複雑ポーズならSeedream v5 Pro(お手本そっくり型、$0.054/枚)、プロンプトの指示を正確に反映したいならGPT-Image-2(指示どおり型、$0.058/枚)、バリエーション量産ならSeedream v4.5(安価、$0.05/枚)、背景のみの生成ならGPT-Image-2のtext-to-imageが向いています。ComfyUIでLoRA学習まで踏み込むなら、2Dアニメ・漫画向けにチューニングされたAnima Base v1.0が2026年時点の実務標準です。
調査手法について
こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。

Screenshot
調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域(ホワイトスペース)を可視化しながら調査の網羅性を高めていけます。
また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。
ご利用をご希望の方は、こちらよりお申し込みください。
また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。
市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai


コメント