24体のAIに同じ原稿を別々の目で読ませる——部品表で組んだ、もう1本のパイプライン
前回『借りる部品×自作部品』の部品表を作り、次回はその部品表で資料群の ingest パイプラインを組むと予告した。その前に——まったく別タスクで既に動いている実例を1本見せる。マンガの英訳チェックを、24体のサブエージェントの fan-out・schema 契約・人間の承認ゲート・決定論的な適用で組んだら、同じ部品表にそっくり載った。安いオラクルが無い領域では、ゲートは人間が務める。
← 前の記事: 汎用エージェント基盤は「借りる部品」と「自作する部品」でできている——組み立て前の部品表前回、エージェント基盤の部品表を作った。プラットフォームから借りる部品（skill・hook・MCP・subagent・Dynamic Workflows）と、自分のフレームワークで自作する部品（外部ループ・決定論ゲート・schema 契約・state 外部化）の2系統に割れる、という話だ。そして末尾で「次回はこの部品表で、資料群を ingest → extract → compile → query する最小 PoC を組む」と予告した。
その予告を回収する前に、もう1本だけ寄り道する。まったく別タスクで、すでに動いている実例があるからだ。マンガの英訳チェック。前回予告した資料パイプラインとは縁もゆかりもないこの作業を、同じ部品表で組んだら、ほぼ一対一で部品が填まった。部品表が「ある特定のパイプラインのための後付けの説明」ではなく、タスクをまたいで効く設計図だと示すには、毛色の違う2本目を見せるのが一番早い。
これは「マンガを英訳する AI」の紹介ではない。品質がシビアなタスクで、信頼できるパイプラインをどう組むかの話だ。
まず、なぜ「英文校正」では足りないのか
英訳マンガの品質保証を「英文を校正する」だと思うと、最初の一歩で踏み外す。実際にこのパイプラインが拾った、こんな指摘がある。
JA : ……これメモ。
EN before: ...Noted.
EN after : ...Make a note of that.
Noted. は英文として完璧だ。スペルも文法も句読点も非の打ちどころがない。英文校正を100回かけても素通りする。だが原文と並べた瞬間に壊れているのが分かる。「これメモ」は相手への指示（メモしておいて）なのに、Noted. は話者自身の了承（こちらは把握した）になっている。話者の向きが180度反転している。
ここから設計の制約が1つ決まる。訳文だけを見せても判定できない指摘がある。 原文と訳文をペアで渡さないと、誤訳・強調位置のズレ・話者の向きの反転は構造的に見えない。これが、パイプラインの入口を「英文の山」ではなく「JA↔EN のペアの列」にする理由になる。
パイプライン全体
組んだものはこうなる。
入口の「ペア抽出」は決定論的なスクリプト1本だ。対訳マンガのデータ（story.json）では、各セリフが「吹き出しノード＋子テキストノード」で表現され、日本語の吹き出しと英語の吹き出しが同じコマの下に並ぶ。これを reading order で ja[i] ↔ en[i] に組み直し、各ペアに「修正対象テキストノードの id」を添える。あとで機械的に書き戻すための住所だ。
LLM に「ペアにしておいて」と頼まない。形が決まっている前処理は決定論コードに任せる——これは部品表でいう自作部品側の仕事だった。
24体に、別々の目で読ませる
中核は fan-out だ。原稿を8チャンクに割り、それぞれに観点の違う3つのレンズを当てる。8 × 3 で24体のサブエージェントが並列に走る。
レンズは3つ。grammar（文法・スペル・強調範囲・句読点だけを見る。口語的な断片を誤りにしない）、fidelity（原文と突き合わせ、誤訳・脱落・余計な追加・話者の向きだけを見る）、localize（英語圏の読者に自然に響くか。translationese の硬さ、吹き出しのテンポ、過剰修正の禁止）。
なぜ1体に「全部チェックして」と頼まないのか。ここが設計の勘どころで、冗長性ではなく多様性が効くからだ。同じプロンプトを3回投げても、3回とも同じ見落とし方をする。だが観点を割った3体は、互いに盲目なまま別の失敗モードを拾う。さっきの Noted. は grammar レンズには永遠に見えない——文法的に正しいからだ。fidelity レンズだけが、原文と突き合わせて初めて気づく。1レンズが素通りしても、別のレンズが拾うように観点を直交させる。これが fan-out を「同じ仕事の水増し」ではなく「探索の網」に変える。
各エージェントは自由文では返さない。{en_id, severity, current, suggestion, reason} という構造化スキーマで返す。severity は high / med / low。これがあるから、24体ぶんの指摘を機械的に severity 順へ並べ、diff として提示できる。出力の形を schema で縛るのは借りる部品側——Dynamic Workflows の schema も自前パイプラインの JSON フォーマット指定も同じ役割だ。形が保証されているから、集約は手で JSON.parse する脆さなしに決定論コードで書ける。
確定権は人間に残す——安いオラクルが無いから
集約した指摘は、severity の高い順に diff で並べて人間に見せる。致命的なもの（誤訳・文法・強調位置のズレ）は確実に、low の任意ポリッシュは最小限に。ここで人間が赤入れし、採否を決める。AI は指摘を足し、人間は赤入れで引く。 全自動で story.json を書き換えることはしない。
なぜ自動で確定させないのか。前回の部品表では、借りる部品（hook）が供給しない「何を検査するか＝意味の判定」の穴を、自作部品（決定論ゲート・LLM judge）で埋めると書いた。だが翻訳の自然さには、PDF が実在するか のような安い自動オラクルが存在しない。「この英文はキャラの口調として自然か」を機械が確実に裁定する術が、今のところ無い。
製品を3類型に分けたとき、選択は「ループ内に人間がいるか／安いオラクルがあるか」で決まる、と詰めた。翻訳QAは、まさに安いオラクルが無いから人間をループ内に置く側の典型だ。決定論ゲートの代わりに、人間の承認ゲートを置く。これは妥協ではなく、軸に沿った正しい配置になる。
ひとつ現場の罠を挙げておく。1つの文が2つの吹き出しにまたがることがある。前の吹き出しが , で終わり、次が小文字で続くケースだ。
吹き出し1 EN: Time reversal is when the scattered balls all reverse their trajectory at once,
吹き出し2 EN: rolling backward at exactly the right speeds and reassembling into the tight triangle.
片方だけ直すと、大文字小文字や句読点が不整合になる（at once, の次がいきなり大文字 Rolling になる、など）。連結したセリフはペアで適用する。承認ゲートを人間にしている効用がここにも出る——機械的な diff だけでは、この「文として繋がっている」関係は見落としやすい。
適用は決定論的に、可逆に
承認された修正は {en_id: 新しいEN本文} の形にまとめ、適用スクリプトが story.json のテキストノードを直接書き換える。書き換える前に必ず story.json.bak_pre_en_text というバックアップを取る。en_id は先頭8文字でも前方一致で解決する。
生成と適用を分離し、適用は決定論的で可逆にする。 壊れたら戻せる。バックアップは部品表でいう state 外部化——重さと引き換えに再実行性と監査証跡を買う、自作部品側の振る舞いだ。
実際にこのパイプラインが AInic Dialogs の英語版（ワープ航法編）を出す準備として拾い、適用した修正の一部を挙げておく。translationese の硬さが、会話として噛み砕かれていく。
JA : 局所性に関する私たちの日常的な理解を、根本的に挑戦する記念碑的な業績です。
EN before: It's a monumental achievement that fundamentally challenges our everyday understanding of locality.
EN after : It's a landmark result — one that shakes our everyday notion of locality to its core.
JA : ……アインシュタインは、完全に軽蔑しました。
EN before: ...Einstein utterly despised it.
EN after : ...Einstein absolutely hated it.
JA : ……のり子さん、それは作っただけで満足するパターンですね。
EN before: ...Noriko, that's the satisfied-just-by-building pattern.
EN after : ...Noriko, that's the classic "happy just to have built it" trap.
最後のは calque（直訳の複合名詞）が慣用句に化けた例で、localize レンズの仕事だ。satisfied-just-by-building は英語として意味は通るが、ネイティブはこう言わない。
部品表に載せ直す
このパイプラインを、前回の「借りる部品 / 自作部品」の語彙にそのまま載せるとこうなる。
| 工程 | 実装 | 部品表での位置 |
|---|---|---|
| ペア抽出 | extract_pairs.py（JA/EN を reading order でペア化） | 自作：決定論抽出 |
| 24 並列レビュー | 8 チャンク × 3 レンズ | 借りる：subagent fan-out + Dynamic Workflows |
| 構造化指摘 | {en_id, severity, current, suggestion, reason} | 借りる：schema 契約 |
| 集約・diff | severity ソート＋ diff 提示（決定論コード） | 自作：決定論ゲート |
| 承認（赤入れ） | 人間が採否を確定 | オラクル＝人間 |
| 適用 | apply_en.py（FS 直編集＋ .bak） | 自作：決定論適用＋ state 外部化 |
資料パイプラインの ingest → extract → compile → query とは工程の名前も中身もまるで違う。なのに使っている部品は同じ顔ぶれだ。fan-out で幅を取り、schema で形を縛り、決定論ゲートで集約し、可逆な適用で書き戻し、ゲートの判定者だけタスクの性質に応じて差し替える。 翻訳QAでは判定者が人間になった。それだけだ。
これは翻訳の話ではない
5つの設計判断を抜き出すと、どれも翻訳に固有のものではない。
- 単体では判定できないものを判定させない（原文とペアで渡す）
- 冗長ではなく多様な観点を並列に（盲目な専門家を並べる）
- 出力を schema で縛り、集約を決定論に（自由文で返させない）
- 確定権を人間に残す（安いオラクルが無い領域では、人間がオラクル）
- 適用は決定論的で可逆に（生成と適用を分離し、バックアップを残す）
このまま専門ドメインのリサーチ系の引用照合にも、文書生成系の論拠チェックにも置き換わる骨格だ。題材がマンガの英訳だっただけで、見せているのは知的労働を、信頼できる形でコードに置き換えるための土台そのものになる。次回はいよいよ、この同じ部品表で資料群の ingest → extract → compile → query を組む。読み物だった部品表が、2本目の再現可能な実物に変わる。