はじめに
私たちは長い間、記憶に頼ることで漫画のコマを思い起こしてきました。
「あの話、何巻だったっけ」という曖昧な感覚を手がかりに、本棚の背表紙を一冊ずつ指でなぞり、アタリをつける行為は、単なる検索ではなく、作品との再会の儀式でした。
しかし2026年6月、集英社は「こち亀オンライン」に全コマ検索機能を実装し、200巻を超える作品の記憶を一瞬で引き出せる世界を出現させました。セリフを打ち込むだけで、望むコマが画面に現れる。もう部長がポケモンを集める話が107巻だと覚えたり、「日枝神社はここじゃなかったっけ？」と言い訳する話が151巻だと調べたりする必要はないわけです。
この革命の水面下では、どのような技術が息をしているのでしょうか？
その構造を妄想で辿ってみます。
1章. 文字を読む目——OCRという「読書」の自動化
マンガのページは、活字の論理を意図的に破壊した空間と言えます。縦書きと横書きが同じコマ内で共存し、擬音語はセリフではなく効果として絵に溶け込み、ルビは本文の文字よりはるかに小さく添えられています。さらに秋本治のこち亀は、警察内の書類やテレビ画面の字幕、店の看板といった背景の中の文字が異常なほど多い作品でもあります。
汎用OCRエンジンがこの地形で精度を落とす理由は比較的明確に説明できます。これらのモデルは整形されたドキュメントを前提に設計されており、縦書きフキダシの曲線的なテキスト配置や手書き風の変形フォントには対応しきれないと思われます。Manga109データセットで汎用ベースモデルのPaddleOCR-VLを評価した実験では、全文一致精度はわずか27%、文字誤り率は89%という数字が報告されています。10文字のセリフを読んでも、9文字近くが誤認識される計算になります。これでは検索インデックスとして機能しないはずです。
では、どのように解決するのでしょうか。鍵は、全ページを一度に処理しようとしない、という設計の転換にあると推測されます。
最初の工程は、1枚のページ画像からコマ（フレーム）の境界を検出することではないかと思われます。これは物体検出タスクとして定式化されており、YOLOアーキテクチャのモデルが主流と思われます。
Manga109データセット（v2026版）には109作品・10,602ページにわたる103,850件ものフレームアノテーションが収録されており、このデータで訓練されたモデルは高精度なコマ検出が期待できます。Manga109ベースのYOLO26sセグメンテーションモデルでは、フレーム・テキスト・フキダシの3クラスをピクセルレベルで分類するインスタンスセグメンテーションを行い、検証データでmask mAP@0.5 = 0.970という数値が報告されています。ほぼすべてのコマを取りこぼさずに切り出せる水準ではないかと思われます。
ただし、こち亀特有の難しさも存在する可能性があります。吹き出しのないト書き風のコマや、境界線なしに複数コマが並ぶ見開き構成は、一般的なフレーム検出モデルの想定外になりやすいです。この段階の誤検出は後工程全体に伝播するため、訓練データに類似作品を含めるか、後処理でルールベースの補正を加えるといった工夫がなされていると推測されます。
ステージ2：フキダシ検出——読むべき領域だけを切り出す
コマを切り出した後、次にそのコマ内部のフキダシ（吹き出し・ナレーションボックス）を特定する工程が続くと思われます。なぜコマ全体にOCRをかけないのでしょうか。インデックスに入れてはいけないテキストが大量に存在するからではないでしょうか。
背景の看板、効果音、キャラクターのネームプレート——これらをすべて抽出してしまうと、検索ノイズが激増してしまいます。両津のバカを検索したときに、バカという効果音が描かれたコマが大量にヒットするような状況は避けたいはずです。フキダシ領域だけを検出してクロップし、その内部のテキストだけをOCRに渡す設計が、精度を保つための現実的な選択ではないかと推測されます。
YOLO11nをManga109ベースで学習させたフキダシ検出モデルは、Precision 97.55%、Recall 97.03%、mAP@50 99.10%という精度を報告しています。フキダシの形状は楕円形・四角形・ギザギザの怒りフキダシなどにある程度パターン化されており、このタスクは物体検出の得意領域に合致していると言えそうです。
フキダシの一覧が得られたとしても、それをそのままOCRにかけるだけでは不十分な場合があると思われます。DBに格納するテキストには、コマ内のどのフキダシが何番目かという読み順情報が必要になるからです。
日本語マンガの読み順は右から左、上から下が基本ですが、こち亀ではコマ内に3〜5個のフキダシが複雑に配置されているケースも多く、単純な座標ソートでは順序を誤る可能性があります。現代の実装では、フキダシのバウンディングボックス座標から読み順をツリー構造で推定するアルゴリズムが使われているのではないかと推測されます。マンガ翻訳パイプラインのKoharuの技術ドキュメントによれば、この工程でフキダシをTextBlockレコードに変換し、OCRに渡す前に読み順を確定させる設計が採用されているとされており、全コマ検索でも類似のアプローチが取られているのではないでしょうか。
フキダシのクロップ画像が揃ったところで、ようやくOCRが登場します。選択肢として有力なのは大きく2つあると思われます。
manga-ocrは、Vision Encoder Decoderアーキテクチャをベースにした日本語マンガ専用モデルで、縦書き・多行テキストを1回の推論で処理できる設計が特徴とされています。軽量で推論が速く、バッチ処理のコスト面でも選ばれやすいモデルではないかと推測されます。
PaddleOCR-VL-For-Mangaは、109言語対応の汎用VLMであるPaddleOCR-VLを、Manga109-sの10万件テキスト領域クロップと150万件の合成データでSFT（Supervised Fine-Tuning）したモデルです。ベースモデルの27%・文字誤り率89%という精度を、Exact Match 70%・文字誤り率10%まで引き上げています。注目すべきは、このモデルがフルページではなくフキダシのクロップ画像を入力とする設計である点です。ステージ2のフキダシ検出と組み合わせて初めて真価を発揮するアーキテクチャになっており、前工程の品質に性能が強く依存していると思われます。
また、このモデルの主な誤認識パターンとして報告されているのが、全角・半角の混同や視覚的に酷似した漢字の取り違えです。この誤認識の傾向が、後で触れる漢字をかなで探せないという制約とも連動していると推測されます。OCRが出力する表層形テキストをそのまま信頼してインデックスを構築するという設計判断の根拠が、ここにあるのではないかと思われます。
ステージ5：スキーマへの格納——コマをレコードとして扱うという設計判断
OCRで得られたテキストは、コマ単位のメタデータとともにデータベースに格納されると推測されます。おそらく1レコードのイメージは次のような構造になっているのではないでしょうか。
{
"panel_id": "v095_c008_p042_f03",
"volume": 95,
"chapter": 8,
"page": 42,
"frame_index": 3,
"text_blocks": [
{ "order": 1, "text": "両津のバカはどこだ！" },
{ "order": 2, "text": "部長！落ち着いてください" }
],
"image_url": "https://cdn.example.com/panels/v095/p042_f03.webp",
"zebrack_url": "https://zebrack-comic.shueisha.co.jp/..."
}
コマをレコードとして扱うという一見当然に見えるこの設計が、システム全体の挙動を決定づけているのではないかと思われます。#95巻8話という構造化クエリが機能するのも、古い順・新しい順のソートが可能なのも、コマを選択した瞬間にゼブラックへのリンクが現れるのも、すべてこのスキーマに巻・話・ページ番号とリンクURLが格納されているからこそでしょう。全コマ検索の検索という機能は、このスキーマという土台の上に乗っているにすぎません。OCRパイプラインが産み出すのは文字列ではなく、構造化されたコマのデータなのではないかと推測されます。
2章. 転置インデックスという名の地図帳
OCRパイプラインが産み出すのは、コマごとに紐づいたテキスト文字列の集合です。しかしこのデータは、そのままでは高速な検索に耐えられません。仮に両津のバカという単語を検索するとき、10万件のレコードを上から順番に走査して一致を探すシーケンシャルスキャンを行えば、結果が返るまでに数秒から数十秒かかる可能性があります。瞬時に一覧表示されるという体験を実現するには、検索の前段階で別の構造を作っておく必要があります。それが転置インデックスです。
転置インデックスとは、どの言葉がどのコマに出現するかを逆引きした辞書のような構造です。通常のDBはレコードを起点に値を引きますが、転置インデックスは単語を起点にレコードのIDを引きます。両津というトークンに対して、それが出現するpanel_idのリストと出現位置・頻度がまとめて格納されていれば、ユーザーが検索した瞬間にそのリストを取り出すだけで済みます。スキャンではなくルックアップになるため、件数が10万であっても100万であっても応答速度はほぼ変わらないはずです。
英語であれば単語はスペースで区切られているため、転置インデックスの構築は比較的単純です。しかし日本語には分かち書きがなく、両津のバカはどこだという文字列をどこで区切るかをシステムが判断しなければなりません。この処理を形態素解析と呼び、日本語全文検索の根幹を担っています。
有力な候補として挙げられるのは、MeCabとSudachiという2つの形態素解析器ではないでしょうか。
MeCabはIPAdic辞書やmecab-ipadic-NEologdと組み合わせることで、両津のバカはどこだを両津・の・バカ・は・どこ・だというトークンに分解できます。処理速度が速く、ElasticsearchのICU Analyzerやkuromojiプラグインを通じて組み込む実績も多いと思われます。
一方で、形態素解析を使わずにn-gramトークン化で対応している可能性もあります。bi-gramであれば、両津のバカを両津・津の・のバ・バカという2文字単位に分解してインデックスします。辞書に依存しないため未知語に強い反面、トークン数が増加してインデックスサイズが膨らむというトレードオフがあります。検索の最小文字数が2文字以上という制約は、bi-gramインデックスの最小グラムサイズと一致しており、この方式を採用している傍証のひとつになるかもしれません。
公開されている挙動のうち、インデックス設計を推測する手がかりとして特に興味深いのが2点あります。
ひとつは、検索が2文字以上でなければ受け付けないという制約です。の・は・がのような1文字の助詞は、ほぼすべてのコマに出現します。1文字トークンを許可すれば、インデックスの当該エントリに数万件のpanel_idが紐づくことになり、結果が返ってきても絞り込みとして機能しません。Elasticsearchのn-gramトークナイザーにはmin_gramパラメータがあり、これを2に設定することで1文字トークンをインデックスに含めない設定が可能です。この制約はインデックス設計の都合が仕様としてそのまま表面化したものではないかと推測されます。
もうひとつは、2語入力するとどちらかを含むコマがすべて表示されるというOR動作です。ベクトル検索であれば、複数単語のクエリは1つのベクトルに埋め込まれて処理されるため、自然とAND的な近傍が返ってきます。しかしOR結果が返るということは、入力が複数トークンに分割されてから転置インデックスへの独立したルックアップとして処理されていることを意味すると思われます。Elasticsearchのboolクエリにおけるshouldクラス、あるいはMeilisearchのデフォルト動作がこれに相当します。再現率（recall）を最大化する一方で精度（precision）を犠牲にするこの設計が、脈絡のない単語を入れて思わぬコマを掘り当てるという公式推薦の使い方とも綺麗に一致しているのは偶然ではないでしょう。
全コマ検索には、漢字の単語をかなで探すことはできないという制約があります。これは一見すると使い勝手の問題に見えますが、インデックス設計の選択の痕跡として読むこともできます。
Elasticsearchには読みの正規化を行う手段があります。MeCabの読み（yomi）出力をインデックスフィールドに追加すれば、りょうつと入力しても両津のコマがヒットするよう設計できるはずです。それをあえてしていないということは、OCRが出力した表層形テキストをそのまま形態素解析してインデックスに格納する、最もシンプルな構成を採用している可能性があります。
読み正規化を追加しない理由として考えられるのは2つではないでしょうか。ひとつは実装コストの問題で、MeCabのyomi出力はOCRの誤認識を読み誤りとして増幅させるリスクがあります。もうひとつはデータの正確性への誠実さで、OCRが読んだ文字をそのまま格納することで、意図しない誤ヒットを防いでいるとも解釈できます。表層形インデックスという一見シンプルな選択が、むしろ堅牢性のための積極的な判断であるかもしれません。
転置インデックスを構築するエンジンとして、ElasticsearchとMeilisearchの2択が候補に挙がりやすいと思われます。
Elasticsearchはクラスタ構成でペタバイト級のデータを扱える実績があり、日本語形態素解析プラグイン（kuromoji・ICUアナライザー）の整備も充実しています。ただし運用コストと設定の複雑さが伴います。Meilisearchはより軽量なRust製エンジンで、日本語対応はLinderaというkuromoji互換ライブラリで実現されており、10万件程度のレコード規模であれば十分な速度が期待できます。開発・運営を担うロクトーナが出版社向けのWebサービスを主な領域とする会社であることを踏まえると、運用負荷の低いMeilisearchを採用している可能性もあるかもしれません。いずれにせよ、転置インデックスを持つ全文検索エンジンがこの仕組みの中核を担っているのではないかと推測されます。
3章. ベクトルという次元への跳躍
転置インデックスは強力ですが、ひとつの構造的な限界を持っています。それは、ユーザーが検索した文字列がインデックスのトークンと完全に一致しなければヒットしないという点です。両津のバカを検索すれば確かにヒットしますが、あの部長が怒っているシーンとか、両津がギャンブルで大失敗するコマという記憶の輪郭では、何も返ってきません。正確な言葉を思い出せないとき、キーワード検索は沈黙します。
この限界を超えるために登場するのがベクトル検索です。テキストや画像を高次元の数値ベクトルに変換し、意味の近さをベクトル間の距離として測る技術です。重要なのは、意味が似ているものは近い座標に配置されるという性質で、怒るという概念は怒鳴る・激高する・キレると近い位置にあり、両津勘吉という文字列は両さん・亀有の巡査・勘吉と近くなります。これは転置インデックスには存在しない次元です。
ベクトル検索をマンガコマの検索に応用するにあたって、最も有力な候補として挙げられるのがCLIPというモデルアーキテクチャではないかと思われます。CLIPはOpenAIが開発したモデルで、テキストと画像を同一のベクトル空間に埋め込む設計が特徴とされています。怒っている大原部長というテキストクエリと、実際に部長が怒鳴っているコマ画像が、同じ高次元空間の近傍に配置されます。これにより、言葉で画像を探すという操作が理論上は可能になります。
ただし、元のCLIPモデルは英語テキストを前提としており、日本語クエリへの対応には別のモデルが必要になると思われます。日本語対応の候補として名前が挙がりやすいのはrinna社が開発したjapanese-clip-vit-b-16やLY Corporationのclip-japanese-baseではないでしょうか。特にclip-japanese-baseは約10億件の画像テキストペアで学習されており、日本語テキストとの画像検索においてSTAIR Captionsデータセットでのrecall@1が0.30と、既存の日本語CLIPモデルのなかでも比較的高い数値を示しています。マンガ画像という特殊ドメインへの適用には追加のファインチューニングが必要かもしれませんが、ゼロショットでも一定の意味検索が実現できる可能性はあると思われます。
数万〜10万件のコマ画像をCLIPで埋め込むと、それぞれのコマが512次元あるいは768次元の浮動小数点ベクトルになります。これを格納して高速に類似検索するための仕組みとして、FAISSとpgvectorが候補に挙がりやすいと思われます。
FAISSはMetaが開発したベクトル検索ライブラリで、IndexHNSWFlatというアルゴリズムが近年の実装で特に多く使われているようです。HNSWはHierarchical Navigable Small Worldの略で、多層グラフ構造によって近似最近傍探索（ANN）を行います。逐次スキャンと比べて数千倍以上の高速化が報告されており、10万件規模のベクトルであれば10ミリ秒以下での検索も十分に実現可能ではないかと思われます。ただし、インデックス構築時のメモリ消費が多いという特性もあります。
pgvectorはPostgreSQLの拡張機能として提供されており、既存のリレーショナルDBにベクトルカラムを追加する形でベクトル検索を実現します。先述のコマレコードのスキーマにembeddingカラムを追加し、CREATE INDEX ... USING hnswという一行でHNSWインデックスを構築できます。既存のメタデータ（巻・話・ページ）によるフィルタリングとベクトル検索を同一のSQLクエリで組み合わせられる点が、このシステムとの相性として特に優れているのではないかと推測されます。
転置インデックスとベクトル検索は対立する技術ではなく、互いの弱点を補完する関係にあります。キーワード検索はトークンの完全一致には強いが曖昧な意味には届かず、ベクトル検索は意味の近さを捉えるが固有名詞や短い特定のセリフには弱い傾向があります。この2つを組み合わせる手法がハイブリッド検索です。
実装パターンとして有力なのが、Reciprocal Rank Fusion（RRF）と呼ばれる手法ではないかと思われます。キーワード検索の結果リストとベクトル検索の結果リストをそれぞれ独立して取得し、両方でランクが高いレコードをスコアリングして統合します。生のスコア値を正規化して足し合わせるのではなく、順位という情報だけを使うため、異なるスコールスケールを持つ2つのシステムをシンプルかつ安定的に融合できるとされています。研究ではハイブリッド検索が単一手法よりも8〜15%の精度改善をもたらすことが報告されており、こち亀のように固有名詞と感情表現が混在する検索においては特に効果が期待できるかもしれません。
ここまでの思い付きを一度引き戻す必要があります。現在公開されている全コマ検索の挙動を観察する限り、ベクトル検索が実際にユーザー向けの機能として動いている証拠は見当たりません。漢字をかなで探せないという制約や、2語入力がOR動作になるという仕様は、意味理解を伴う検索では起こりにくい挙動です。意味検索であれば両さんという口語でも両津勘吉に辿り着けるはずですが、そうはなっていない可能性が高いです。
これはベクトル検索が存在しないことを意味するのではなく、まだオフラインのバッチ処理層として動いているか、あるいは将来の機能拡張に向けて設計の余白が残されているという解釈が自然ではないでしょうか。100巻分のコマ画像を埋め込みベクトルに変換してインデックスを構築すること自体はすでに完了しており、UI側への接続だけが残っているという状況もあり得ると思われます。全200巻のデータベース化が完了し、検索のユースケースが蓄積されたとき、怒っている部長や両津が泣くシーンというクエリが通る日が来るかもしれません。
おわりに
両津のバカと打ち込んで、あきれ顔の大原部長が画面いっぱいに並ぶ光景は、笑えると同時に、奇妙な感覚を覚えました。
40年かけて積み上げられた記憶の堆積が、一瞬でひとつの座標に結晶化されてしまったような、技術の叡智とそのあっけなさに。
かつて「あのセリフは何巻だったっけ？」という問いは、本棚に向かう儀式と、曖昧なまま終わる諦めの両方を含んでいました。それが今は、検索ボックスに数文字を打ち込むだけで、秒単位で答えが返ってきます。
こち亀の膨大な話数のデータベースが、滅びることなく、老いることなく、ただそこにある。かつての思い出を超越した様に、感慨を覚えますね。
