【和訳】日・英・韓をひとつのコードで支える、多言語パーサー構築への挑戦

※本記事は、「The Challenges of Making Multi-language Parser」の和訳版です。

BoostDraftは、法務専門家向けに「法務版IDE」として機能するMicrosoft Wordのアドインを提供しています。

私は、ドキュメントパーサーの構築と保守を担当するチームに所属しています。このパーサーは、定義語、条項、相互参照など、法的文書から主要な構造要素を特定・抽出するコンポーネントです。これは、エラーチェックやインデント修正、ハイライト表示といったBoostDraftの機能の基盤となる非常に重要な部分となっています。

BoostDraftは2026年2月現在、日本語、英語、韓国語で書かれた文書をサポートしています。少し前までは、言語ごとに個別のパーサーを開発していました。当初はこの方法でスピーディに開発できましたが、顧客が増え、機能が複雑になるにつれて、言語ごとにパーサーを維持することが大きな負担になってきました。バグを直すにも機能を追加するにも、複数のコードで同じ修正を繰り返さなければならず、非効率でミスも起きやすかったのです。

この記事では、「統一された多言語パーサー」の構築へと移行する中で直面した課題、特に日本語と英語の両方を同じコードベースでサポートする際に生じた、ニュアンスの細かな問題について共有します。

よく使用される用語

• 定義語パーサー（Definition Parser）: 文書内の「定義語」を特定します。これは、テキストの他の場所で正確な意味が与えられている特別な単語やフレーズ（例：「施行日」や「秘密情報」など）を指します。
• 条項パーサー（Section Parser）: 文書構造を分析し、条番号、見出し、および階層レベル（例：「第1条第2項」、「Section 1.2」など）を検出します。

直面した課題

1. 単語の出現回数をカウントする：意外と簡単ではありません！

英語では、単語はスペースで区切られています。これはコンピュータにとって非常に好都合です。例えば、"I ate a pineapple" という文には "pineapple" という単語が含まれていることが明確であり、"apple" が含まれているわけではないと判断できます。

しかし日本語では、単語間にスペースがありません。そのため、「投資関連契約」という文字列には「投資」という単語が部分一致で含まれていますが、それが必ずしも独立した意味を持つ一致であるとは限りません。「投資」としてカウントすべきかどうかは、文脈に依存します。

例：

• ✅ 「まずは 投資 の基本を理解しましょう」 → 「投資」の正しい使い方。
• ❌ 「 投資 関連契約を締結した」 → 「投資」は複合語の一部であり、個別にカウントすべきではない。

一方で、英語にも特有の課題があります。"investor" と "investors" のような複数形は、過剰カウントやカウント漏れを防ぐために正規化（基本形への変換）が必要です。幸い、英語については既存のレンマ化（lemmatization）ロジックを再利用することができました。

2. 条番号の処理：言語特有の「書き方」の癖

条項パースも、日本語と英語で挙動が大きく異なる領域です。英語の契約書では、通常次のような構成を目にします。

• Section 1. Introduction
  • 1.1 Background
  • 1.2 Purpose

しかし、日本の法的文書では、第X条の下にある最初のサブセクション（第1項）は、ほとんどの場合において明示されません。通常、条文は「第X条」とラベル付けされ、その中のサブセクションは「第N項」と記されます。ところが、第一項については数字が表示されず、第二項以降から数字（ラベル）が表示されるのが一般的です。

つまり、以下のような構造をパースする場合：

• 第3条
  • （ラベルなしの第一項の内容）……
  • 2……（第二項）
  • 3……（第三項）

上記のように、隠れた第一項が存在することを推論しなければなりません。これは些細なことに思えるかもしれませんが、正確な構造パースや照応解析（reference resolution）においては極めて重要です。ここを間違えると、参照先の番号がずれたりアウトラインが崩れたりしてしまいます。法的文書エディタにおいて、こうしたミスは許されません。

3. 表形式で記載されている定義語の特定：人間には簡単、コンピュータには困難

以下のように定義語が表形式でリスト化されていることがあります。

用語	定義
施行日	本契約が開始される日
〇〇用語	……において定義される……を意味する

しかし、すべての表が定義であるとは限りません。単なる入力フォームであったり、リストであったり、レイアウトのためだけの要素であったりします。

表形式の定義語である可能性が高いものを検出するために、私たちはヒューリスティクス（経験則）を用いています。一つの有効なシグナルは、2つの列の長さの差です。一方の列（用語）のコンテンツが非常に短く、もう一方（説明）が非常に長い場合、それはおそらく表形式の定義語です。

しかし、日本語では単語が短いため、このヒューリスティクスが通用しないことがあります。例えば：

列1	列2
住所	●●県●●市
氏名	山田太郎

技術的には「短い vs 長い」の比率を満たしてしまいますが、意味的にはこれは表形式の定義語ではなく、単なる表です。
人間なら一目で判断できますが、コンピュータにとってはそうではありません。現在、私たちは「長さの比率」に加えて、句読点やキーワード（「〜〜をいう」「〜〜 means」等）、ドキュメントのレイアウト情報などを組み合わせたハイブリッド戦略を模索していますが、完璧な精度を実現するのは依然として困難な課題です。

開発の醍醐味

苦労は多々ありますが、この多言語パーサーの開発は非常にやりがいのある仕事です。特に面白いと感じているポイントをいくつか挙げます。

• 言語に依存しないロジックを設計しつつ、いつそのルールを破るべきか（言語固有のルールを導入すべきか）を見極めること。
• 法律用語の癖:例えば、英語では定義語が文中で宣言される（"Effective Date" means...）のに対し、日本語では文末で宣言されることが多いといった違い。
• ヒューリスティクスと誤検知の絶え間ないバランス調整: 一つの修正が、新たなエッジケースを生む可能性があります。
• 知的な満足感: Appendixの奥深くに一度だけ定義され、3ページ目で一度だけ使われているような用語を正しく特定できたときなど、システムが賢く動いた瞬間の知的な満足感は格別です。

おわりに

ドキュメントパースにおける多言語サポートは、単にテキストを翻訳すれば済む問題ではありません。それは、言語間の構造的、文法的、さらには文化的な違いを理解し、橋渡しをすることです。
英語、日本語、そしてそれ以外の言語でも機能する統一の多言語パーサーを構築することで、エッジケースや思い込み、そして実務における“言語非依存”の真の意味について、深く考えるきっかけになりました。
この記事を通じて、私たちが取り組んでいる挑戦の一端と、それが一見するよりも難しく（そして楽しい）理由を感じていただければ幸いです。