Index-TranslateをMacで試す。用語・JSON保持と見逃せない誤訳

Index-Translateは、BilibiliのIndexチームが公開する翻訳モデル群です。2026年10月3日に手元のパソコンで使いやすい公式量子化版、10月4日に評価資料とコードが公開されました。本記事は2026年10月4日に実施した、2Bモデルへの6リクエストの記録です。比較相手のモデルは動かしていません。公式更新履歴

最初のモデル公開は9月30日です。今日になって初めて翻訳できるようになった、というニュースではありません。10月3日の更新で公式のGGUF（GPT-Generated Unified Format）形式が加わり、llama.cppで動かす選択肢ができました。今回選んだ2BのQ4_K_Mは約1.31GBです。量子化でファイルを小さくした版で、必要なメモリ全体が1.31GBという意味ではありません。文章の翻訳だけなら、画像処理用の追加ファイルは不要です。公式2B GGUFモデルカード

10月4日の公開には、指示への従い方、俗語、字幕の音節、長文を調べる別々の資料があります。ただし、長文評価用の小説本文まで一式が配られたわけではありません。また、機械的な確認だけで終える実行モードは、完全なベンチマークの点数とは区別されています。この切り分けは、小さな社内試験にも役立ちます。公式評価資料の案内

例えば海外の取引先へ出す案内なら、まず「見積書」「検収」「担当窓口」の呼び方をそろえる。その後で、誰が何をするか、何が不要なのか、いつまでなのかを読む。今回も、文字が残ったかと、仕事の条件が残ったかを別々に確認しました。

試験には実際の顧客情報を使わず、短い架空文を作りました。同じ案内文を通常の依頼と用語指定付きの依頼で1回ずつ翻訳し、残り4件で形式や意味を確認しています。出力を見てから成功しやすい文に差し替えたり、再生成してよい結果だけを残したりはしていません。

公式カードが示す依頼形式に合わせ、原文と制約を分けた中国語の指示を使いました。日本語の依頼文で同じ結果になるかは試していません。 原文は日本語ですが、指示に使う言語も条件の一部です。固定モデルと実行版、実際の設定は教材に記録しました。公式の翻訳依頼形式

今回のMacは余裕のある構成です。小型ノートでも同じ速度で動く、これだけのメモリが最低限必要、といった判断はできません。WindowsやLinuxでの実測、ほかの量子化版、長い文書、英語から日本語への翻訳も今回の範囲外です。

最初の原文は、提出期限と検収予定を伝える短い案内です。

通常の翻訳依頼では、見積書は「estimate」、検収は「inspection」、さくら窓口は「Sakura window」になりました。用語指定がないため、指定違反とは呼べません。ただ、顧客が知っている部署名がSakura Deskなら、直訳のwindowでは別の場所と受け取られるおそれがあります。

そこで同じ原文に、次の3つの対訳と、日時を保ち情報を加えない制約を添え、制約付きの依頼形式で翻訳しました。モデルは変えていませんが、用語以外の指示も変わっているため、用語表だけの効果を分離した比較ではありません。

指定付きの実際の出力は次のとおりです。

3つの用語に加え、10月8日17時の期限と10月15日の予定が残りました。この1例から期待できるのは、毎回ばらつかせたくない訳語を依頼に添える使い方です。部署名や商品名を大量に渡した場合の順守率までは測っていません。検収の訳も業界や契約によって違うため、今回の対訳を全社共通の正解として使うのではなく、自社で合意した表記に置き換えてください。

残りの試験では、JSON（JavaScript Object Notation）のキーと数値、文中の変数、参照先の文字列を変えないように指定しました。JSONは文章を入れた箱としてそのまま処理し、翻訳してよい欄をmessageに限定しています。読み込める形式かどうかに加え、数値の3が文字列の「3」に変わっていないかも確認しました。

問題が出た原文は、次の3文です。

実際の出力では2文目が変わりました。

「No quotation is required.」は、見積書そのものを不要としています。原文で不要なのは見積書を承認することです。例えば「Approval of the quotation is not required.」なら、その関係を保てます。この修正文は編集部が示す例で、モデルに再生成させた結果ではありません。

ここでは指定したquotationとacceptance inspectionの両方が出ています。用語検索だけなら合格です。文法的にも読みやすいため、流し読みでは見逃しやすい。今回、全6リクエストが事前に設けた文字列・形式の機械検査を通りましたが、それを「翻訳精度100%」とは扱えません。否定がかかる対象は、原文と訳文を並べて読む必要がありました。

一方、この失敗だけで製品全体の翻訳品質を決めることもできません。今回の固定版、量子化方式、依頼文、短文で出た1つの観察です。元の非量子化版との比較はしていないため、量子化が原因だとも判断していません。

架空原文・実測結果・検収表の教材ZIPには、入力、ローカル実行用スクリプト、期待条件、6件の生の応答を収録しました。モデル本体や公式評価データは含めていません。まず結果だけ読みたい場合はobserved/results.jsonとreviewer/observed-meaning-review.mdを開いてください。

自分で試す場合は、公式の2B GGUF配布ページとllama.cppの配布ページから、自分のOSに合うものを別途用意します。Macで使った起動設定、モデルの固定版とハッシュ値は教材のREADMEに記載しています。古い実行環境でモデルを開けない場合は、先に対応状況を確認してください。

サーバーを127.0.0.1:18749で起動し、教材のフォルダを開いた別のターミナルで、次を実行します。送信先は手元だけで、クラウドのAPI（Application Programming Interface）を呼ぶコードではありません。

cases.jsonがモデルに渡る入力で、reviewer/expected.jsonは人が検収するための答え側です。答えを入力に混ぜないよう分けました。付属の実測記録へ上書きせず、自分の結果は別のフォルダに残せます。作業後は起動したサーバーを終了してください。

自社の例を追加するときは、最初に「どの条件が変わったら使えないか」を決めます。文章全体に丸を付けるより、次のように仕事の意味を分解したほうが、修正すべき箇所がわかります。

短い案内文で確認が済んだら、次は自社の部署名を増やした文、二つの期限を含む文、例外条件が付く文を足すとよいでしょう。出力が読めるだけで合格にせず、送信前の確認項目に落とし込みます。入力と観察結果を残す考え方は、Whistleの短い音声を使った試用でも共通です。

公式は文章モデルについて150言語を扱うと説明し、公式クライアントには日本語を指定する対応表があります。ただし、150言語で品質が等しいという説明ではありません。音声・音節数・長文向けには別のモデルや対応範囲があり、今回の2B文章モデルの結果をそのまま広げることもできません。モデル群と対応範囲、公式クライアント

今回使ったモデルは公開の配布元からアカウント認証なしで取得できました。追加の推論料金は発生していません。モデルの表示ライセンスはApache 2.0（Apache License 2.0）ですが、機器の購入費、電気代、設定や検収の時間までゼロにはなりません。オンラインデモの料金や利用枠は今回の実測に含めていません。モデルの配布条件

モデルの利用条件と評価データの条件も別です。例えば公式評価資料のMEMEとinstTransはCC BY-NC 4.0です。モデルが商用利用しやすい条件だからといって、評価用の文章まで同じ扱いにはできません。本記事の試験は自作の架空文で行い、配布教材にも公式評価データを入れていません。評価資料ごとのライセンス

今回の結果から始めるなら、社内の訳語をそろえた下書きを作り、人が期日や否定を確認する用途が考えられます。承認や支払いの条件まで自動で確定させる運用は、この6回では支えられません。形式が正しいことと内容が正しいことを分ける点は、AstaBriefで出典を確認する記事ともつながります。

公式情報と試験結果の確認日：2026年10月4日。モデル更新や依頼文の変更で出力が変わる可能性があるため、教材の条件を残して比較してください。