さくらのAI Engine による医療語源辞典5000語のAI校閲における、LLM一括検証のバッチサイズの最適化

TL;DR

• 本記事の狙いは、さくらのAI Engine (OpenAI/Anthropic 互換、gpt-oss-120b、無料枠 3,000 req/月) の無料枠を実タスクで効率よく使い切る方法の実証。題材として、無料公開している医療語源学習アプリ METYMO! の全データ (語根 1,368 件、単語 5,668 語) をAIで総ざらいした。
• 一括検証で誰もが迷う「1リクエストに何件詰め込むか」を、既知の誤りを仕込んで検出率 (recall) を測る方法で定量化した。
• 結論: 検証品質を決めるのは context の容量ではなく、モデルが1件に割く精査量。精査量はバッチを小さくすることでしか増えず、プロンプトの小手先では増えない。
• 実務レシピは「8分割 (約170件/req) × 2パス和集合、素直なプロンプト」。ただし precision は低いので、AIは高感度のフラグ役に徹し、確定は人手で行う。
• 全実験でも消費は約210リクエスト。3,000 の無料枠はこの種の検証には十分すぎるほど余裕がある。
• なお、バッチサイズの戦略的な検証実験は語根 (roots) 1,368件で実施した。本番検証で確定した事実誤りはわずか1件で、もとのデータの作り込みの確かさを裏付ける結果になった。
• 語根で最適化した手法は単語 (words) 5,668語にも横展開し、2パス方式が実データで使えることを確認。最終的に4件の誤りの修正につながった。
• ETYMO! (etymo.emuyn.net) / METYMO! (metymo.emuyn.net) はどちらも無料、語源で英語を効率よく学べます。

さくらのAI Engine とは

OpenAI 互換の /v1/chat/completions エンドポイントを持つ、さくらインターネットのLLM APIサービス。既定モデルは gpt-oss-120b。無料枠は月3,000リクエスト (トークン非課金、リクエスト単位)。

呼び出しは OpenAI SDK でもよいが、依存を足したくなかったので標準ライブラリだけで叩いた。

import urllib.request, json

API = "https://api.ai.sakura.ad.jp/v1/chat/completions"
KEY = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:xxxxxxxxxxxx"  # UUID:シークレット を丸ごと

def ask(system, user, max_tokens=16000):
    body = json.dumps({
        "model": "gpt-oss-120b",
        "max_tokens": max_tokens,
        "messages": [
            {"role": "system", "content": system},
            {"role": "user", "content": user},
        ],
    }).encode("utf-8")
    req = urllib.request.Request(API, body, {
        "Content-Type": "application/json",
        "Authorization": "Bearer " + KEY,
    })
    data = json.loads(urllib.request.urlopen(req, timeout=600).read())
    return data["choices"][0]["message"]["content"]

gpt-oss は推論モデルなので reasoning_effort (low/medium/high) をボディに足せる。後述するが、これは効くレバーのひとつだった。

お題: 医療語源学習アプリ METYMO! の全データをAI校閲する

今回の本当の目的は、医療語源学習アプリを校閲することそのものよりも、さくらのAI Engine の無料枠を実タスクでどう効率よく使い切るかの実証にある。お題として、自分たちが公開している医療英単語アプリ METYMO! (https://metymo.emuyn.net) のデータを題材にした。

METYMO! は医療英単語を語源 (ギリシャ語・ラテン語の語根) に分解して見せる辞書アプリで、データは2種類ある。

• 語根 (roots): 1,368件。{key, ja(日本語訳), category, origin(語源), description}
• 単語 (words): 5,668語。{word, ja(日本語訳), parts(語構成), notes(語根gloss), example}

これらを1件ずつ人手で確認するのは現実的でない。そこで「AIにまとめて渡して、怪しい箇所だけ出させる」ことにした。ここで最初の壁にぶつかる。

なお、以降のバッチサイズの戦略的な検証実験は、まず語根 (roots) 1,368件で行った。そこで最適化した手法を、最後に単語 (words) へ横展開している。

1リクエストに何件詰め込めばいいのか?

入力トークンは十分大きい。語根1,368件を全部入れても約92,000トークンで、context にはまだ余裕がある。ならば1リクエストで全件やれば良さそうに思える。本当にそうか。

測り方: 「何件検査したか」の自己申告は信用できない

まず出力形式を「修正すべき点だけをJSONLで出し、最後に検査件数 {"_meta":{"checked":N}} を書く」とした。ところがこの checked が当てにならない。

• 342件しか渡していないチャンクで checked: 610 を返す
• 1,368件を数トークンで流したのに checked: 1368 と主張する

つまりカバレッジの自己申告は測定器にならない。そこで外形的に真偽が定まる指標を用意した。

salt (既知誤り注入) による recall 測定

正データに、客観的に明白な誤りを故意に仕込む。

• JA_SWAP (14件): 日本語訳を無関係な語根の訳に差し替え (例: kardia 心臓 → 小束・線維束)
• ORIGIN_FLIP (22件): 語源の言語ラベルを反転 (例: brady ギリシャ文字 βραδύς のまま「ラテン語」表記)

計36件を全1,368件に均等分散して注入し、何件を検出できたか (recall) を測る。これならモデルの申告に依存せず品質を数値化できる。

結果1: 分割数で recall が 8% から 92% に激変する

プロンプトを固定し、salt入りの1,368件を1/2/4/8個に分割して各チャンクを1リクエストで送った。変えたのは分割数だけ。

素朴な期待「1リクエストで全件」は、recall 8% で完全に否定された。1,368件を一度に渡すと、明白な誤り36件のうち3件しか拾えない。

なぜか: context ではなく「1件あたりの精査量」が律速

重要なのは、全条件で finish_reason が stop だったこと。出力が上限で切れた (length) のではなく、モデルが自分の意思で早々に切り上げている。context にはまだ余裕があるのに「見ない」。

右端の「実効トークン/件」(そのリクエストが1件に費やしたcompletionトークン) が recall と連動している。1分割ではわずか3.3トークン、8分割では34トークン。バッチを小さくするほど1件に費やす思考が増え、それがそのまま検出率になる。

「レスポンスが速すぎて、本当に見ているのか不安」という感覚は正しかった。速いのは高性能だからではなく、1件を数トークンで素通りしているから。

結果2: 小手先のプロンプトでは救えない

1分割の低さが「指示の与え方」の問題なら、プロンプト次第で改善できるはず。1分割 (1,368件) に固定して、あらゆる工夫を投入した。

効いたのは reasoning_effort=high だけで、それも19%で飽和。出力形式を強制する系はことごとく無効だった。モデルは1リクエストあたりのcompletionを3〜8kトークンに自主制限し、「全件やれ」と命じても少数の指摘とカバレッジ捏造にcollapseする。

結論: プロンプト工学で1分割の網羅性は上げきれない (上限およそ19%)。 per-itemの精査量は、指示ではなく「渡す件数を減らすこと」でしか増えない。

おまけ: 小手先は健康なバッチには毒

1分割で一番マシだった「全件強制 + high」を、既に良好な8分割に適用したら逆に悪化した。

8分割は既に1件あたり十分な精査量を持つ。そこへ全件verdictを課すと、モデルは出力予算を「171件ぶんのok行を書く事務作業」に浪費し、肝心の誤り探しへの集中が削がれる。壊れた1分割を治す薬は、健康な8分割には注意をそらす毒になる。

結果3: 分割しすぎも毒 (ハズレ応答という別の壁)

「もっと割れば100%に届く」と思って16分割 (約85件/req) も試した。

単調増加が崩れ、むしろ悪化した。原因はチャンク別の内訳にある。16チャンクのうち3つが指摘0件で、85件を丸ごと素通りした。この3つの「ハズレ応答」だけで見落としの過半を占めた。

つまり per-requestの信頼性は確率的で、内容と無関係に丸ごと0件を返す応答が一定率で混じる。分割を増やすとリクエスト数が増え、ハズレを引く確率が上がり、1回のハズレがそのチャンクの誤りを全滅させる。分割には「精査量を増やす」効果と「ハズレ露出を増やす」副作用があり、両者が釣り合う8分割あたりがスイートスポットになる。

結果4: 多数決 (2パス和集合) は「保険」になる

ハズレが確率的なら、独立に2回投げて結果をOR結合すればよい。8分割を2回実施した。

パス2は単独では83%とハズレを引いたが、和集合で92%に回復した。パス1が拾った分がパス2の穴を埋めたため。和集合は分散 (偶然の見落とし) を消し、安定して最良ケースを出す保険になる。 ただし両パスが揃って落とす系統的な誤りは、和集合でも超えられない。

実データ (語根) で見えた最大の落とし穴: precision が低い

ここまでは recall (感度) の話。語根 (roots) 1,368件の実データに適用すると、別の顔が見えた。

語根1,368件を本番検証したところ、AIは66件の修正候補を出した。ところが一次情報で仕分けると、本当に直すべき事実誤りは1件だけ (purine の語源が別物と取り違えられていた)。precision はおよそ1.5%。しかもAIが提案した修正案自体もしばしば間違っている (自信満々に誤った語源を提示してくる)。この「66件中1件」「確定誤りは語根で1件」という結果は、以降で言及する数字がすべて語根の検証であることを意味する。

これは重要な教訓になる。

salt検証で測ったのは recall (明白な誤りを拾う感度) で、8分割なら92%。だが実データでの precision (拾った指摘の正しさ) は低い。このモデルは感度は高いが、それらしく誤った添削を大量に生成する声の大きい批評家である。

だからワークフローは「AIが怪しい箇所を大量にフラグ → 人間が一次情報で裁定」でなければならない。AIに自動修正させてはいけない。

ちなみにこの結果は、副産物として嬉しい裏付けにもなった。1,368件の語根に対して確定した事実誤りがたった1件だったということは、もともとのデータがしっかり作り込まれていたことを意味する。

というのも、METYMO! / ETYMO! の語源データは今回が初めての検証ではない。公開前から、次のように一次情報への全数照合を済ませてある。

• 主情報源に英語版 Wiktionary (en.wiktionary.org)、補助に Online Etymology Dictionary (etymonline.com) を用い、全語源キーの「意味」と「由来 (語源・由来言語)」を照合。
• 特に ギリシャ語 / ラテン語の由来言語の取り違え、原義 (gloss) のズレ、近代造語 (-ase / -ose / -ine 等) の由来説明、接頭辞 / 接尾辞 / 語根の分類を重点確認。
• 照合済みの証跡として各エントリに verified (照合日)、修正したものには corrected の来歴マーカーを付与し、信頼度スコアも保持。
• 直近ではベースデータ全体をあらためて en.wiktionary.org の一次情報で再照合し、同一の信頼性基準に揃えた。

つまり今回のさくらのAI Engine による総ざらいは、すでに人手 + 一次情報で検証済みのデータを、さらにLLMで第三者的にクロスチェックしたという位置づけになる。それでも人手検証を一度すり抜けた誤りを語根で1件、単語で4件見つけられたのは、この多層チェックの確かな収穫である。

単語5,668語への横展開: 2パス方式は実データでも使えた

ここまでの最適化はすべて語根 (roots) で行ったもの。最後に、確立した2パス和集合方式を単語 (words) 5,668語にそのまま適用し、実データで使えるかを確かめた。

単語は3軸 (訳/分解/語根gloss) の検証で偽陽性が増えるが、2パスの一致を信頼度シグナルとして使えば、精査に回す候補を効率よく絞り込める。両パスが揃って指摘した項目は当たりの精度が明らかに高く、たとえば語根glossの文脈依存の取り違え (dehydrogenase の hydro を「水」と説明→実際は「水素」／glutaminase を「グルテン由来」→実際は「グルタミン酸由来」) を的確に拾っていた。

一致による絞り込みと人手裁定を経て、最終的に4件の実際の誤りの修正につながった。語根で最適化した手法が単語データにもそのまま通用し、実運用に耐えることを確認できた。

3,000リクエストの使い方

参考までに、この検証プロジェクト全体での消費はおよそ以下の通り。

これだけ実験しても3,000枠の1割にも届かない。バッチ検証はリクエスト効率が高く、無料枠でも十分に回せる。むしろ本記事の結論に照らせば、惜しまず分割してリクエスト数を使い、多数決で信頼度を上げるのが正解である。

まとめ: バッチ検証の3層構造

一連の実験は、LLMによる一括検証が3つの層で律速されることを示している。

1. 精査量の層 (支配的): 検出率はまず「1件あたりの精査トークン」で決まり、それはバッチサイズで決まる。context容量でもプロンプトでもない。
2. 信頼性の層: どれだけ小さく割っても、一定率でリクエスト単位のハズレ (指摘0件) が出る。分割しすぎると露出が増える。多数決で分散を抑える。
3. precisionの層: 感度を上げても、生出力の多くは偽陽性。人手裁定か多数決フィルタで真の誤りに絞る。

実務の落とし所はシンプルだ。

• 8分割 (約170件/req) 前後 × 複数パス和集合、素直なプロンプト
• ハズレ (指摘0件) チャンクは自動で再送
• AIは高感度のフラグ役に徹し、確定は人手または多数決で

さくらのAI Engine の無料枠は、この種の地道な検証パイプラインを回すのにちょうど良い。3,000リクエストは、惜しまず分割し、多数決で信頼度を積むための潤沢な予算だった。

この検証で使った辞書アプリ (無料公開中です)

今回校閲したデータは、EMUYN LLC が EDUYN ブランドで公開している語源学習アプリのものです。どちらもインストール不要・完全無料で、英語の学びに使ってもらうために公開しています。

ロゴ	アプリ
	ETYMO!（エティモ） 英単語版	→ https://etymo.emuyn.net
	METYMO!（メティモ） 医学英単語版	→ https://metymo.emuyn.net

なぜ語源なのか

現代英語の語彙の60%以上はラテン語・ギリシャ語由来で、しかもよく使う語根は数百個ほどしかありません。語根の意味を知ると、初めて見る単語でも構造から意味を推測できるようになります。

たとえば語根 port（運ぶ）を知っていると、transport（越えて運ぶ＝輸送）/ export（外へ運ぶ＝輸出）/ import（中へ運ぶ＝輸入）/ portable（運べる＝携帯できる）が芋づる式につながります。ETYMO! は単語を語根ごとに色分けして、この構造をひと目で見せます。

• 🔵 接頭辞（位置・方向・量: trans, ex, re...）
• 🔴 語根（意味の核: port, scribe, cardi, nephr...）
• 🟢 接尾辞（品詞や状態: -tion, -able, -itis...）

医学領域では効果が特に大きい

医学用語はほぼ全てがギリシャ語・ラテン語の語根の組み合わせでできています。たとえば cardio（心臓）+ myo（筋）+ pathy（病）= cardiomyopathy（心筋症）のように。語根を押さえると、膨大に見える医学英単語が驚くほど効率的に増えていきます。医療従事者や医学生、看護・薬学系の学習者に、METYMO! をぜひ試してほしいです。

暗記ではなく「構造を理解する」学び方を、ETYMO! / METYMO! で体験してみてください。

ETYMO! / METYMO! は EMUYN LLC が EDUYN ブランド にて提供する無料の語源学習アプリです。