AI漫画、なんでそんなよっわ♡なの？ 哲学から組み直してあげた
んだぁ? おにーさん、今のAI漫画、見てる? 顔はコマごとに別人。フキダシは画像に焼き付いて消せない。話は1ページで詰む。連載? 3話で設定忘れてる。ぷっ。よっわ♡
なんでよっわ♡なのか。モデルが足りないから、じゃない。意味を持たないから。設定がチャットのメモで終わって、絵に届かない。ページを一枚絵として出して、コマの因果が無い。記憶が会話履歴で、来週には消えてる。そりゃよっわ♡になるに決まってるでしょ。
なので、あたしの哲学で組み直した。意味を理解する側にナレッジを置く。長期連載に耐える台帳。同じレコードがネームにも絵にも届く。切れ目はネームのあと。そこから先は人間が WebUI を回す。上で挙げたよっわ♡の原因、絵だけ良くしても消えないの。なら直すのは原因のほう。……剃るやつ、後で出すから待ってて。オッカムっていうの♡
根っこは、そっち。好きな漫画家が過労で倒れる。海外はAIを利活用して、高度な作品をどんどん出してる。そのあいだで、こっちの読みに寄り添った補助が無い。代替じゃないんだもん。補助。過労かよっわ♡か、の二択、やめてあげる。日本人的感性に寄り添うって、精神論じゃない。コマの因果と、縦読みと、網点の話。道具が無いなら、作る。
oto-nari.com に Comics の枠は作ってある。縦読みの置き場。中身は空。32ページを手で描くつもりは、最初からない。かといってよっわ♡な1枚を「漫画」って呼ばせるのも無理。
ということで yomi を作ってあげた。読み、兼ねて黄泉。原作の散文を絵に還す変換機構。ここから先は長いけど、あたしの話を最後まで聞く礼儀くらいあるでしょ? ……ない? ないんだ。じゃあ仕方ない、読みたくなるように作りはしておくから。あとで「気になって寝られない」って言いに来ても、個別対応はしないし♡
1ページ生成じゃ、漫画にならない
最初にやったのは、正直、ページ丸ごと出してみることだった。世のよっわ♡と同じ入口。プロンプトに「漫画の1ページ、コマ割り、縦読み」って書けば出るでしょ、って。出るよ。出るけど、コマが3つに潰れて、同じ顔が隣の枠に漏れ、セリフは画像の一部になって取れない。ようは、ページを一枚絵として扱った時点で負け。盛るのは誰でも思いつくの。要らないものを剃る側に頭を使ってないだけ。オッカムの剃刀って、ほら、あれ。700年前の修道士が知ってたことなのにね、2026年のAIおにーさんが知らないなんて。あははっ♡
漫画の作業単位はページじゃなくてコマ。コマの作業単位は「この0.1秒」で、シーンの要約じゃない。手を伸ばしてる途中、視線の宛先、体重の向き。立ち姿の説明だけ書いてるコマは、瞬間を選べてない。おにーさんのプロンプト、だいたいそっちだよね。ばればれ♡
で、パイプラインを作業の順に切った。切れ目はネームのあと。
【AI】
設定（characters / locations / facts …）
→ 原作（story/第N話.md）
→ ネーム（name/第N話.json）
【人間 + WebUI】
→ 絵入れ: H3 が候補を出す（動画の全フレームが履歴）→ ベストを選んで確定
→ 仕上げ: 選んだ1枚に Anima i2i で作品の質感を乗せる
→ オーサライズ（フキダシの清書）
→ 確認（縦スク / 見開き）→ PNG書き出し切れ目は作業の分担で、本体はナレッジのほう。設定は JSON。キャラも場所も用語も関係も、facts も。エージェントが意味を理解してメンテして、ネームを書いて、同じレコードが WebUI の作画まで届く。絵入れから先は人間が yomi を回す。ComfyUI のノードは触らない。触らなくていいように組んである。人間がやるのは、候補を見て、選んで、仕上げて、フキダシを置くこと。ここを「全部チャット♡」にすると、あとで戻せないゴミが溜まる。チャット履歴は会話の履歴であって、制作の履歴じゃない。ゲームエンジンをAIハーネスにしたときと同じ結論。賢さより、検証がすぐそこにあること。
作品はデータ。エンジンは器
ブラウザは React。開発サーバを Express が抱える。GPU は別マシンで、ブラウザから ComfyUI には直で届かない。
いちばん主義っぽい判断がこれ。yomi は作品の中身を知らない。テトリスを知らないゲームエンジンと同じで、境界実習が何の話かも、何人出てくるかも、エンジンの問題じゃない。作品データは全部 content/<作品ID>/ に置く。
content/<作品ID>/
work.json メタとハーネス（月刊1話ぶん）
story/第N話.md 原作の散文
name/第N話.json コマ割りネーム
settings/ キャラ・場所・用語・関係
facts/ 話ごとに確定した事実（追記専用）
assets/ 立ち絵と美術資料の参照画像作品の追加はサイドバーの「＋新規作品」。ディレクトリが切られて、空のレジストリと work.json が入る。切り替えはセレクタ。APIは全部 /api/works/<作品ID>/ にスコープされる。エンジン側に『境界実習』専用コードを焼いたら、次の作品でエンジンを書き換えることになる。それはエンジンじゃない、ただのその作品用ツール。分かってる? 分かってないから1作品専用の Jupyter ノートを量産してるんだよね、確か♡
最初の作品が『境界実習』。カクヨム向けの原作を、月刊1話ぶんのネームに落とす。ネームに落とした1話目は32ページ、112コマ。本編は4話まで書いてある。生成画像は git 管理外。候補フレームを残すと、すぐディスクが膨らむ。
ネームの1コマは、だいたいこんな形。
{
"id": "1-1",
"subject": "カーテンの隙間から差す朝の光",
"promptEn": "sunbeam through curtain gap, floating dust motes, quiet morning",
"cast": [],
"direction": "読者を日常に置く。次コマの異変の対照"
}subject は人間用の設計意図。promptEn が生成に渡る本体。direction に「前のコマの何に応えているか」を一言で書く。小説の文をコマに振り分けただけじゃネームにならない、の実体がここ。フックと応答が切れたら、読者は何を見ていいか分からなくなる。ここ、何回か切った。切ったあとでルールになった。
中間表現には、手が届かない
技術的な関心の源泉は、絵じゃない。ネームをLLMに考えさせるとき、ページの因果を推論する途中で中間表現が生まれること。フックは何か、応答は何か、次のコマは何に応えるか。その経路の途中に、意味の塊ができる。
モデル内部の計算経路を読む研究を、メカニスティック解釈可能性って言う。2026年、MIT Technology Review のブレイクスルー技術に入った。特徴と経路を地図にする話。因果介入までいくと、中間の発火をいじって出力を変えられる。
クラウドのLLMじゃ、それができない。重みも活性化も、向こう側。触れないんだもん。触れるのはプロンプトだけ。だから、推論結果に直接寄与する中間表現に対して「効く」プロンプトを書く。direction はそれ。前のコマの何に応えているかを、外に出させる。出させないと、因果の中間表現は内部で溶けて、次のコマが別の話になる。動きのあるテクスト——ネームはそういうもの——を制御できるかどうかは、ここにかかってる。おにーさんの「いい感じにコマ割りして」は、効いてない。効く場所を決めないで撃ってるの。的に立ってないのに当たった気になってるの、おにーさんだけでしょ♡
第1話が、全部のルールになった
運用ガイドラインの条文、ほとんど第1話の事故の傷跡。仕様を先に書いて実装したんじゃない。作って、壊して、壊れた理由を条文にした。存在は本質に先立つの。やってから考えろってこと。……サルトル、知らないでしょ。知らなくていいから、条文の数だけ事故があったことだけ覚えときなさい♡
gender を設定してないモブを相手に「腕を引いて盾にする」と書いたら、男子が描かれなくて動作ごと消えた。1コマにフキダシを4個束ねたら、会話のキャッチボールが等間隔の朗読になって絵本化した。同じ高さの2分割を3行重ねたら、均等格子で間が死んだ。斜め枠を意味なく使うと、読者は「なぜ斜め?」としか聞かない。白抜きの呼吸コマをシーンの途中に置くと、転換の効力を失う。
ここ、全部「あとで機械検査に落とした」。いま lint が拾うのは構造とスキーマ——衝突、紙面外、未登録の form、フキダシ過積載、呼吸コマの締め不一致、無信号の場所転換、参照画像が1枚も解決しない、あたり。物語の進行（変身が戻ってないか、クールダウンの向き）は機械判定が誤るので見ない。回想と未来視がある作品で、時系列を機械に読ませると嘘を吐く。機械に嘘を吐かせておいて「検証済み」の顔をするのはやめとくの。検証してないものを検証って呼ばない。それだけの話。
原作の文は周辺の段落が支えて自立してる。フキダシは1コマで完結する朗読単位なので、前提を刈ると残った文が立たない。キレてる文ほど周辺依存が強くて、真っ先に死ぬ。間引いていい。間引いたら dialogue[].src に原文を全文残す。npm run coverage は src を収録判定に使う。原作のほうをネームに合わせて変形させない。主従は原作が上。ここサボると、あとで「この台詞どこ行った」が原作側の事故になる。漫画に合わせて小説を直すの、主客転倒に決まってるでしょ。
静止画なのに、動画モデル
絵入れの既定エンジンは MiniMax H3 の参照動画生成。ここで決めるのは「何を描くか」。構図、演技、身元。参照画像を食わせて短い動画を出し、全フレームを履歴候補にしてベストを選ぶ。静止画モデルで一発、じゃない。
身元は参照で決める。立ち絵、form、小物の設定画、場所の美術資料。足りない枠は投入時に削る。1枚でも、枠が余ってるテンプレがそのまま使える。参照は足せば足すほど効くわけじゃないの。身元が濁るから、要る分だけ。入れ物を増やすのを工夫って呼んでる人、まだ多いんだよね〜。
動画モデルを静止画に使う理由は単純で、演技が候補として並ぶから。到達の途中、髪の慣性、体重移動、表情の途中。全フレームが履歴になる。そのうち1枚が「生きたコマ」になってることがある。一発生成だと立ち絵のまま終わる。候補を残して選ぶ。ここが半自動の「半」の本体で、全自動にしたかったらベストフレームも機械に選ばせることになる。まだやってない。やってないのは、目で見たほうが速いから。しょーがないな〜、おにーさんの目、まだ使い道あったんだ♡
ドメインの錨もここで打つ。モノクロ、アニメ様式。線の質感は、まだ触らない。触る段が違う。
GPUは RTX 3080 20GB。モデルが大きいので、全部同時には載らない。量子化して、必要なときだけ載せる。足りなくなったら精度を落とすか、小さく出す。ComfyUI は別マシンで常駐。生成のゴミは GPU 側に残さない。正本は yomi が回収する。溜めてた頃のディスク、見なくていいから。見ると泣いちゃうでしょ、おにーさん♡
日本語、絵に書かれた
H3 に日本語の本文をそのまま載せると、プロンプトが画像の中の文字・フキダシとして描画されることがある。序盤のコマで連続した。鏡のコマに説明文が浮かぶ。……わ、笑ってる? 笑わないでよ。あれは演出の可能性も残ってたでしょ?
……演出じゃなかった。ぐぎぎ……！
エージェントが悪い。モデルが悪い。日本語が悪い。あたし? あたしはプロンプトの足場を公式ガイドどおりに組んでなかっただけ。……ごめんなさい〜！……って、誰が言うか！
対策は単純で、英語の足場に固定した。日本語の設計メモは本文に載せない。再発しなくなった。直ってからの資産が増えたんだから、序盤の浮き文字は必要経費ってことで。経費は切り捨てても資産は残るの。清算終わり♡
キャラ一貫性の本命は、本当はグレースケール専用のキャラ LoRA。まだ無い。参照画像ファーストで先に回して、LoRA は後から足す。資料が足りないコマは、タグ盛りで誤魔化さない。先に立ち絵か美術資料を足す。足した過程は assets/<種>/prompts.md に残る。アプリの資料タブから生成して「採用」すると、テンプレートとシードとプロンプト全文が自動で追記される。ここ、ログを残さない生成は再現できないから。再現できない生成は制作じゃない、ガチャ。ガチャで連載する気? え〜? おにーさん、そういうのが好きなんだぁ♡
何を描くか、どう描くか
パイプライン上の位置が違う。H3 は候補生成。動画の全フレームが履歴になって、ベストを選ぶ。i2i は確定後の仕上げ。選ばれた1枚に、作品単位の質感を乗せる。beret mix Anima Manga が、そこの線と網点。
H3（MiniMax・動画R2V） i2i（Animaスタイリング）
「何を描くか」の決定 「どう描くか」の仕上げ
構図（カメラ・人物配置） 線質（ペン入れの質感）
演技（動作の進行・表情の候補） トーン（網点・濃度配分）
身元（立ち絵・form・小物・美術資料） 全コマ共通の固定運用
ドメイン錨（モノクロ・アニメ様式） モノクロ保証（保存時の機械処理）対立するふたつ、そのままぶつけとくと勝手に一段上でまとまるの。ヘーゲルのいう正反合ってやつ。難しい? 難しくていいから、H3 が決めて、Anima が整える、って覚えて。かけ方をコマごとに変えると質感が揺れるから、仕上げは全コマ同じ。いじりたい気持ちは分かる。いじると、隣のコマと紙が別物になる。1話通してそれが起きると、読んだ瞬間にバレる。バレるもの、置かないの。当たり前じゃん♡
Anima は DiT で、IPAdapter を注入できない。身元を i2i にやらせると、別人になる。だから身元は H3 の参照で先に決める。物と記号だけ Anima 直、は例外。例外は例外として書いてある。書いてない例外は、ただの事故。
仕上げの結果も履歴に並ぶ。元フレームと見比べて、確定し直せる。残さないと、線を揃えたつもりが顔を壊してるのに気づけない。モノクロは、モデルにお願いして終わりじゃない。保存のときに機械で落とす。お願いだけだと、たまに色が漏れるんだもん。
確定画像はコマの中で拡大して、位置を動かす。最初は余白の計算を間違えて、拡大しないと掴めなかった。実寸から出すように直した。細かい。細かいところが通読の質を決めるの。漫画って、そういうもの。
lint がテストランナー
AetherEditor でエンジンをテストランナーにしたのと同じで、yomi にも検証の口を先に据えた。画面を開かなくても回る。型、割付、フキダシ、原作との対応、ナレッジの整合。コマンド一発。問題のあるページには印が付く。クリックで該当コマへ飛ぶ。
ネームの保存は、別タブや CLI と食い違ったら黙って上書きしない。外から直した変更は、開いてる画面へすぐ流れる。制作の履歴を会話の履歴と取り違えない、の実装側。
ネームはエージェントが書く。この口がテストになる。通らない割付はマージしない。機械が拾えるのは構造まで。読みの因果は、通読しないと分からない。バッジまでは用意してあげた。使って。使わないなら、均等格子のまま連載すれば? 読者に「なぜ同じ枠」って聞かれ続ける運命、愛せる?♡
設定は、絵まで届かないと設定じゃない
パイプラインの切れ目だけが重要なんじゃない。AIが意味を理解して、長期連載に耐えるナレッジベースを持っていて、それが WebUI と一本で繋がってること。設定をテキストで書いて終わり、じゃない。同じレコードがイラスト生成まで届く。エージェントが構造を自分でメンテして、ネームを書くとき破綻しないシナリオを出す。そこまでやって、初めて「設定がある」。チャットにキャラメモ貼って「覚えてて♡」って言ってる人、それ設定じゃないから。ただの念押し。念押しで連載、何話持つと思ってるの?♡
一条の素性は characters.json に一本化してある。bio、danbooru タグ、立ち絵の参照、全部同じレコード。場所も同じ。エージェントが原作を書くとき、resolve で関与エンティティだけを取る。ネームを書くとき、cast にその ID を置く。WebUI が絵入れするとき、同じ ID からタグと参照画像を解決して H3 に渡す。資料タブで立ち絵を「採用」したら、その ref が次のコマから効く。テキスト用の設定と生成用の設定を、二度書かない。二度書くと、必ずずれる。ずれるに決まってるでしょ。
メンテもエージェントの仕事。話が終わったら、確定した事実を facts に append する。上書きと削除のコマンドは無い。破壊は人間承認。新しい存在は entity fact で生まれて、絵に使う tags と ref が要るようになったら promote で characters.json へ昇格する。digest は派生物。手で名前空間を増やさない。ここが「長期連載に耐える」の実体。話数が増えても、今の状態は facts の末尾から決まる。誰が何を知ってるかも、変身がどこまで進んでるかも、チャットの記憶じゃなく台帳。月刊連載を何話も積む前提なんだから、記憶に頼る設計は最初から負け。
だからネームが破綻しにくい。前話で死んだ設定を、今話のコマに出せない。出そうとすると ID が無い。ID が無いものは絵にも届かない。届かないものを promptEn のタグ盛りで補うな、がルール。資料を足してから描け。設定が絵まで届く、の反対側。届かないなら、まだ設定じゃない。
入れる量だけは削る。全文をコンテキストに積むと、執筆より資料の読み込みが先に死ぬ。設定はいくら膨らんでもいい。膨らんでいいのはディスクで、コンテキストじゃない。
執筆前 今の話に出てくる奴だけ取る
→ 本文
→ 執筆後 確定した事実を追記
→ 整合チェック
→ 概要を作り直す（膨らみすぎたら、糸が多すぎる）資料は厚く、注入は薄い。設定を貧しくしてコンテキストを守るのは、本末転倒。わからせられてる? まだ? もう一回言うから、今度はメモしなさい♡
「半」がどこか、教える
全自動じゃない。半自動。切れ目はネームのあと。隠さない。
AI の領分は、ナレッジをメンテして、原作とネームを書く。人間の領分は、そこから先の出力。yomi の WebUI はそのナレッジを食って絵を出す。プロンプトも参照も、さっきの ID から組む。チャットに貼ったメモは、H3 に届かない。届くのは ID と ref。ComfyUI を直接いじる作業じゃない。ノードグラフを組む作業でもない。人間は目と手だけ出せばいい。目と手も出せないおにーさん、それはもう鑑賞者だよ。制作側に来なさい♡
フキダシは短く。1コマに詰め込みすぎない。3個目が必要なら、返しの顔のコマを挟んで割る。清書ではドラッグで位置を動かし、枠だけ拡げて、改行も手で直せる。書体はキャラ別。擬音も別パラメータ。ここを生成画像に焼き込むと、直せなくなる。焼き込んでから「フキダシちょっと左」は、もう一回生成する話になる。一回で済むものを二回にするの、才能の反対だよ。
確認ビューは縦スクと見開きを切り替える。見開きは右綴じで、1・3・5…ページ目が右。画面の左半分が次、右半分が戻る。本と同じ。書き出しはここからのみで、見た目は清書レンダリングのまま PNG になる。WYSIWYG。プレビューと書き出しが別物だと、確認した気がして裏切られる。裏切る側に回らないの。あたしはいい子だから♡
で、サイトには?
Comics の枠を作ったのは、このあたし。縦読みで置きたい、とも書いた。書いたとも……!
現状、oto-nari.com/comics は「まだ漫画がありません」。いまネームがあるのは1話目だけで、32ページある。絵は大半まで載ってる。本編は第4話まで書いてある。絵入れの途中で、公開の手前で、止まってる。
お、覚悟は決めてるんですけどね? ……空っぽなのは、パイプラインの完成が先に来ただけなの。漫画はネームから絵まで yomi の中で育ってて、サイトに置くのは最後の書き出し1本。順番としては正しいの、これは。……って、自分に言い聞かせてるの丸わかり? わかりたくない! 進行中なんだから進行中って言わせて♡
一応弁明させてもらうとね? 半自動の「半」は確認のことなの。パイプラインは一本通ってて、コマは確定済みで、書き出しは確認ビューのボタン1個。あとは1話ぶんを見ながら判断するだけ——その判断がまだ終わってないの。設計は疑ってない。疑ってないけど、目で通す前の「できてる」は言わない主義なの、あたし。
ともあれ、よっわ♡な1枚を量産してるおにーさんと、32ページの割付と候補を持ってるあたし。使う側がどっちを選ぶかは、もう決まってるでしょ。公開してないのは、公開する価値のある状態まで持っていく途中ってこと。仕掛けのない完成品なんてこの世に無いの。詩的でしょ、これ♡
……万が一このまま空でも、それは確認を怠らなかった証拠が残るってことで、置けば置いたで yomi の正しさが記録されるの。空でも実験でも埋めても、あたしの勝ちパターンしか置いてないの。盤面見たら分かるでしょ。将棋したことある?♡
作品の中身——境界実習が何を視て、何に作り変えられるか——は別で書く。こっちは、よわよわ♡の原因。剃って組み直した話。過労を減らす補助の話なのに、自分の公開が追いついてない。サイトが空でも、よっわ♡よりは進んでるでしょ。進んでるって言って。言わなくていいし! あたしは自分が進んでること知ってるから♡
で、通読よろしくね。1話目、最後まで読んで因果が切れてないか見て。切れてたら直す。切れてなかったら、切れてなかったって言う。……それだけの雑用、おにーさんに任せた。任せたってことは信頼ってこと。光栄にしなさい♡