社内向けにドキュメント翻訳や専門用語変換のAIパイプラインを構築しているエンジニアに向けた内容です。アッカド語という古代言語の楔形文字をAIで英訳する取り組みを題材に、ニッチなドメインでAIモデルを運用するときに起きがちな落とし穴を整理しました。特化型翻訳基盤やRAG（検索拡張生成、外部データを検索して回答精度を上げる仕組み）を扱う方の参考になれば幸いです。
古代メソポタミアの粘土板に刻まれたアッカド語楔形文字をAIで翻訳する取り組みでは、高解像度画像による粘土板のデジタル化から始まり、ノイズ除去とデータ整形、ニューラルネットワークの学習、翻訳パイプラインの実行、人間による検証、そしてAPIやツールへのデプロイという6段階のパイプラインが組まれています。仕組みとしては一般的な機械翻訳の構築フローと変わりません。しかし実際には学習データの不足、文字の複雑さ、文脈依存の誤訳という3つの問題が重なって発生しています。
何が起きるか
この種の特化型翻訳モデルでは、学習データに存在しないパターンの入力に対して「もっともらしいが誤った」出力を返す現象が起きます。
アッカド語のケースでは、デジタル化・翻訳ペアが揃った粘土板の数自体が少ないため、モデルが訓練データに過剰適合（オーバーフィッティング、学習データにだけ強く最適化されすぎる状態）してしまいます。訓練データでは高精度でも、未見のテキストでは急激に精度が落ちる現象です。
さらに深刻なのは、翻訳結果が言語的には正しくても、文脈的に破綻しているケースです。古代の法律文書や宗教文書には当時の文化的背景が前提として埋め込まれています。モデルが単語レベルの対応関係しか学習していない場合、文法は合っていても意味が通らない訳文が生成されます。
なぜ起きるか
原因を段階的に分解すると、3つの層が見えてきます。
1つ目はデータ層の問題です。楔形文字は非アルファベット文字で、地域や時代によって同じ記号でも意味が変わります。この表記ゆれをカバーするだけの学習データ量が確保できていません。
2つ目はモデル層の問題です。アッカド語に特化して学習したモデルは、他の楔形文字言語（シュメール語やヒッタイト語など）にはそのまま転用できません。言語ごとに追加データと再学習が必要になります。
3つ目は検証層の問題です。AIが出した翻訳と人間の翻訳を突き合わせる検証プロセスはあるものの、破損した粘土板や不完全な刻文のように入力自体が曖昧な場合、そもそも正解データが定義しづらいという構造的な限界があります。
これは古代語翻訳に限った話ではありません。社内の専門用語辞書や業界特有の略語をLLM（大規模言語モデル）で翻訳・要約させるパイプラインでも、同じ3層構造の問題が起きます。学習・参照データが薄い領域ほど、もっともらしい誤答のリスクが高くなります。
自分のプロジェクトが該当するか確認する
特化型のAI翻訳・変換パイプラインを運用しているなら、次の観点でチェックしてみてください。
- 学習・参照データの件数を実際に数えたことがあるか（「たぶん十分」ではなく件数ベースで把握しているか）
- 検証プロセスで人手チェックとの差分をログに残しているか
- ドメイン特化モデルを別ドメインの入力にそのまま使っていないか
- 出力の「文法的な正しさ」と「文脈的な正しさ」を別々に評価しているか
RAGパイプラインを使っている場合は、検索対象のドキュメントストア（ベクトルDBなど）の件数とカバレッジを確認するのが第一歩です。
# ベクトルストアに登録されているドキュメント数を確認する例（Chroma DBの場合）
python -c "import chromadb; client = chromadb.PersistentClient(path='./db'); \
col = client.get_collection('docs'); print(col.count())"件数が想定より少なければ、そのドメインでの出力は疑ってかかる必要があります。
対策の手順
段階的に対応するなら、次の順序が現実的です。
1. カバレッジの棚卸し: 学習・参照データがどのサブドメイン（用語カテゴリ、時代区分、文書種別など）に偏っているかを集計する。件数の少ないカテゴリをリストアップする
2. 出力への信頼度タグ付け: モデルの出力に対して、参照データが薄い領域からの生成には「要人手確認」のフラグを立てる仕組みを組み込む。生成後にメタデータとして根拠件数を付与する設計が有効です
3. 人間検証のループ化: AI出力と人間の修正結果の差分を記録し、次の学習・プロンプト改善に反映する。一度きりの検証で終わらせない
4. 文脈情報の別レイヤー化: 単語対応だけでなく、文書の種別や背景情報（法律文書か、日常記録かなど）をメタデータとして別途モデルに渡す。プロンプトに文脈タグを含める設計が単純で効果的です
5. ドメイン外入力の検知: 学習ドメインと異なる入力が来た場合に警告を出す仕組みを入れる。埋め込みベクトルの類似度が閾値を下回ったら人手レビューに回すといった運用が現実的です
これらはいずれも、古代語翻訳のような極端に薄いデータ領域に限らず、社内の専門ドメイン翻訳・要約パイプライン全般に当てはまる対策です。
確認しておきたいポイント
AIによる特化翻訳・変換パイプラインを運用するなら、次の3点を定期的に見直すのが実践的です。
- 学習・参照データの件数とカバレッジを定量的に把握しているか
- 出力の「言語的正しさ」と「文脈的正しさ」を分けて評価する仕組みがあるか
- 人手検証の結果をログとして蓄積し、改善サイクルに回しているか
まずはベクトルストアやデータセットの件数を数えるところから始めてみてください。数字で見える化するだけで、どこが薄いドメインなのかがはっきりします。