メインコンテンツへスキップ
見出し画像

【マンガ解説】Gemini|AI漫画を無料で量産する全手順

    ニュース解説の漫画を、AIで毎日1本ずつ作れるようになった。

    費用はゼロで、使うのはブラウザのGeminiだけである。

    鍵になったのは画像生成の腕前ではなく、絵を頼む前にYAMLで設計図を書くこと、コマ割りを画像で渡すこと、キャラの外見を英語のテキストで固定することの3つだった。

    この記事では、その仕組みと、実際に何度も失敗した箇所を手順どおりに書く。

    画像
    画像
    画像
    画像

    なぜ「うまいプロンプト」ではなく仕組みなのか

    画像生成AIに漫画を頼むと、最初はうまくいったように見える。

    崩れるのは2枚目からである。

    キャラの服が変わり、目の色が変わり、頼んでいないコマが増える。

    1枚ずつ会話で直していくと、直すたびに別の場所が崩れる。

    原因は、毎回のプロンプトが少しずつ違うことにある。

    人間が自然文で書き下ろす限り、前回と完全に同じ指定を再現できない。

    そこで、毎回変わってはいけない部分をファイルに固定し、変わってよい部分だけをその都度書く形に分けた。

    固定するのは、キャラの外見、コマ割り、禁止事項の3つである。

    これがこの仕組みの中心にある考え方で、以降の手順はすべてこの分割から出てくる。

    部品1:YAML設計図を先に書く

    絵を1枚も生成する前に、4ページ分の設計図をYAMLというテキスト形式で書く。

    YAMLは、項目名と値を「名前: 値」の形で並べるだけの、人が読み書きしやすい設定の書き方である。

    構造は3層にしている。

    第1層は全体設定で、タイトル、画風、トーン、ページ数を書く。

    第2層は登場人物で、名前と役割、参考画像のパス、外見の英語表現を書く。

    第3層がコマ設計で、1コマごとにカメラアングル、状況説明、感情、セリフを書く。

    実際の3層目は次のような見た目になる。

      - page: 2
        koma_template: "AImanga/コマ割り/koma4-3.png"
        theme: "決め手は上司の上司"
        scenes:
          - panel: 1
            camera: "正面アイレベル"
            description: "ハチワレが指を立てる"
            dialogue: "経歴でも役職でもなかった"
          - panel: 2
            camera: "キジトラのバストアップ"
            description: "キジトラが詰め寄る"
            dialogue: "じゃあ何"

    先にここまで書く利点は2つある。

    ひとつは、話の破綻を絵にする前に見つけられることだ。

    セリフだけを縦に読めば、説明が飛んでいる箇所や、オチが立っていない箇所がすぐわかる。

    生成し直すコストがかかるのは絵で、テキストの書き直しはほぼ無料である。

    もうひとつは、あとから直せることだ。

    「3ページ目の3コマ目だけ言い回しを変えたい」というとき、設計図が残っていれば、その部分だけを差し替えて再生成できる。

    設計図を残さずに会話だけで作ると、同じ漫画を二度と作れない。

    構成の決まりも設計図の段階で守らせている。

    同じカメラアングルを3コマ以上続けない、1ページに1コマは無言のコマを置く、感情に応じてアングルを変える、という3つである。

    全コマにセリフを詰めると、絵ではなく吹き出しの羅列になって読みにくくなる。

    部品2:コマ割りは画像で渡す

    コマ数は、文章で指定しても守られない。

    「4コマで」と書いても5コマや6コマが返ってくる。

    解決策は、白い枠線だけを描いたコマ割りのテンプレ画像を作り、毎回プロンプトに添付することだった。

    枠が入力として与えられると、生成AIはその枠を埋める形で描く。

    4コマ・3コマ・5コマなど15種類を用意し、ページの役割ごとに使い分けている。

    このとき、テンプレ画像に振ってあるコマ番号がそのまま絵の中に描き込まれてしまう事故が起きる。

    プロンプトに「レイアウトの番号を描くな」という一文を足すと止まる。

    コマ数の指定は、文章側でも重ねて書く。

    「ちょうど4コマ」「余分なコマを追加するな」の2つを英語で明示する。

    テンプレ画像と文章指定の両方を入れて、はじめて安定した。

    部品3:キャラの外見は英語の定型文で固定する

    顔と服装の一貫性は、参考画像だけでは保てなかった。

    毎回、三面図(正面・横・背面を並べた設定画)を2枚添付しているが、それでも服の色が変わることがある。

    効いたのは、外見を英語で書いた定型文を1か所に保存し、プロンプトに毎回そのまま貼ることだった。

    毛の色、目の色、帽子の形、制服の素材と色、ベルト、しっぽまでを1文にまとめてある。

    失敗したのは、その定型文を使わずに、その場で英語を書き起こしたときである。

    グレーの制服のはずが紺色になり、帽子が消えた。

    書き起こすたびに語が変わるので、同じ指示にならない。

    参考画像の添付と定型文の貼り付けは、どちらか一方では足りない。

    画像は顔の造作を、テキストは服装と色を担っている。

    部品4:ブラウザのGeminiを自動で操作する

    画像生成のAPIは有料である。

    一方、ブラウザ版のGeminiは無料枠で画像を生成できる。

    そこで、人間がブラウザを触る代わりに、自動でブラウザを操作して生成と回収まで行う形にした。

    流れは、新しいタブでGeminiを開き、参考画像を添付し、プロンプトを入力して送信し、できた画像をダウンロードする、というものである。

    ここで最も手こずったのがファイルの添付だった。

    ブラウザ操作用の添付機能は権限の制約で使えず、代わりにOSのファイル選択ダイアログを直接操作する方式に切り替えた。

    ダイアログが開いた瞬間に、パス入力欄を呼び出してファイルの場所を打ち込む。

    この方式には落とし穴が2つある。

    ひとつは、日本語を含むパスが打ち込めないことだ。

    添付したい画像は、いったん英数字だけのフォルダにコピーしてから指定する。

    もうひとつは、入力先を間違える危険である。

    ダイアログへの入力は「今いちばん前にあるウィンドウ」に送られるので、別のアプリが前に出てくると、そちらに文字が打ち込まれる。

    実際に誤入力の事故を起こしたため、入力の直前に前面ウィンドウの名前を確認し、想定と違えば中止する処理を挟んでいる。

    送信そのものも確実ではない。

    プロンプトを入力したのに送信されていないことがあるので、送信後にスクリーンショットを撮り、チャット欄に自分の発言が出たことを確認してから生成を待つ。

    4ページの役割分担

    漫画は記事の構成をそのまま割り当てている。

    1ページ目は掴みで、何が起きたかを提示する。

    2ページ目は核心で、仕組みと数字を出す。

    3ページ目は効果や比較を扱う。

    4ページ目は注意点で、3コマに減らして締める。

    最後のページのコマ数を減らすのは、読み終わりの印象を軽くするためである。

    4ページとも同じ密度だと、最後まで読ませる負荷が高い。

    数字は、図解ではなく漫画のセリフに入れている。

    以前は別途グラフの図解を差し込んでいたが、漫画が同じことを絵で説明するため役割が重複していた。

    3ページ目で崩れる

    複数ページを続けて作ると、3ページ目あたりで品質が落ちる。

    これは毎回起きる。

    崩れ方は決まっている。

    目の色が変わる、日本語のセリフが縦書きから横書きに変わる、ページ番号が絵の中に文字として描き込まれる、の3つである。

    対策は2段構えにした。

    事前の対策として、プロンプトに「日本語のセリフはすべて縦書きで、上から下、右から左に書く」という一文を毎回入れる。

    これを省くと、後半のページで確実に横書きになる。

    横並びのコマについても「日本語の読み順なので、1コマ目が右、2コマ目が左」と明示する。

    事後の対策として、回収した画像は必ず目で見て点検する。

    崩れていたら「同じ構図、同じセリフのまま、目の色だけ直して再生成」と指示を出す。

    条件を限定して追撃すると、たいてい1回で直る。

    やり直した版は上書きせず、不採用の理由を名前に書いて残している。

    また、ページは1枚ずつ順番に作る。

    まとめて並行で作らせると、後半の顔が崩れる。

    アイキャッチは「絵」と「文字」を分ける

    記事の見出し画像も漫画テイストで作るが、文字はAIに描かせない。

    生成AIは日本語も英語も綴りを間違えるためである。

    そこで、Geminiには文字のない絵だけを描かせ、その上に文字をプログラムで重ねる方式にした。

    絵を頼むときは「文字を入れるな、吹き出しを描くな」と指定し、あわせて「左上は文字を載せるので簡素にしておけ」と伝える。

    文字の合成側では、白抜きの文字に黒い縁取りと落ち影を付けている。

    背景の絵が何色でも読めるようにするためで、note の一覧では画像が小さく表示されるため、コントラストがそのまま視認性になる。

    数字だけを1.6倍にして色を変える指定も入れてある。

    note への投入で詰まった2点

    できた画像と記事をnoteの下書きに入れる工程でも、2回つまずいた。

    1つ目は、見出しの変換である。

    文章を1文字ずつ入力して行頭に記号を打つ方式では、noteの見出し変換が働かなかった。

    本文をHTMLとしてクリップボードに載せ、一度の貼り付けで流し込む方式に変えると、見出しも太字も箇条書きもそのまま反映された。

    2つ目は、画像のサイズである。

    生成直後の画像は1枚6メガバイト前後あり、これを貼り付けるとエラーも出ないまま何も起きない。

    横幅1000ピクセル程度に縮小してから貼ると通る。

    失敗しても無言なので、原因にたどり着くのに時間がかかった。

    考察:AIに任せてよかったのは、判断ではなく反復だった

    この仕組みを作ってわかったのは、生成AIに任せて成果が出た部分と、出なかった部分がはっきり分かれることである。

    任せてよかったのは、決まった指示を何度も実行する部分だった。

    同じ英語の定型文を貼り、同じテンプレを添付し、同じ禁止事項を並べる作業は、人間がやると必ず抜ける。

    任せると崩れたのは、その指示の中身を決める部分だった。

    コマ数、キャラの服装、セリフの言い回しといった、一度決めたら変えてはいけない要素は、AIに毎回考えさせるほどぶれる。

    だから設計図と定型文をファイルに固定した。

    言い換えると、この仕組みで増えた作業は「決めごとを書き留めること」で、減った作業は「毎回それを思い出して実行すること」である。

    画像生成の話に見えて、実際にやっていたのは手順の外部化に近い。

    品質の限界も正直に書いておく。

    3ページ目が崩れる現象は、まだ再生成で対処しており、根本的には解決していない。

    1本作るのに、生成と点検と追撃を合わせて1時間前後かかる。

    無料で毎日続けられる範囲に収まってはいるが、完全に自動で放置できる状態ではない。

    出典

    • Google Gemini(画像生成、ブラウザ版)https://gemini.google.com/

    • 笹沢博紀「AI漫画の作り方」note https://note.com/hiroki_sasazawa/n/n656892945089

    #AI #AI漫画 #Gemini #生成AI #AIニュース

    あなたへのおすすめ