技術要約: DKSE – 構造化ドメイン・オントロジーの自動抽出

1. 問題提起

ソフトウェア要件定義書は、エンタープライズ・ソフトウェア開発における中核的な知識アーティファクトであり、システムのエンティティ、ルール、プロセス、およびインターフェースを定義するものである。しかし、これらの文書は非構造化された自然言語で存在しているため、自動化されたエンジニアリング・ツールチェーンでは利用できない。その結果、テスト生成、コード・スキャフォールディング、コンプライアンス・チェック、AI支援開発といったダウンストリームのタスクにおいて、これらの文章主体の文書に含まれる特定のシステム知識を直接処理することができない。

パターンマッチングのヒューリスティックから近年のNLPパイプラインに至る既存の自動化手法は、通常、浅い抽出（例：単純なエンティティ・リスト）に留まり、マルチページにわたる表、相互参照されるルール、埋め込まれたビジネスロジック、およびセクション間で分散した暗黙の制約を含む、現実世界の要件の複雑さに直面すると精度が低下する。大規模言語モデル（LLM）は、このような複雑な文書を理解し合成する能力を備えているが、その理解を、ソフトウェアエンジニアリングの自動化に適した包括的かつ機械判読可能な構造化オントロジーへと変換するツールは不足している。

2. メソドロジー: DKSE パイプライン

著者は、マルチフォーマットの要件文書を構造化されたドメイン・オントロジーへと自動変換するために設計されたツールである DKSE (Domain Knowledge Structuring Engine) を提示する。本システムはRust（約8,000行のコード）で実装されており、3段階のパイプラインとして動作する。

2.1 入力とパース（ステージ1）

DKSEは、DOCX、PDF、HTML、およびMarkdown形式の入力を受け付ける。

• DOCX: 表、見出し、およびセクション構造を保持するために、ZIP/XML抽出を介してパースされる。
• PDF: レイアウトを意識したテキスト抽出を通じて処理される。
• HTML: DOMトラバーサルを介してパースされる。
  このステージの出力は、正規化された構造化テキストである。

2.2 LLM誘導型セマンティック分析（ステージ2）

正規化されたテキストは、ドメイン固有の抽出プロンプトを用いて、OpenAI互換のエンドポイント経由でLLMによって処理される。決定的なのは、抽出がスキーマ誘導型である点である。プロンプトにはターゲットとなるYAMLスキーマが含まれており、出力が厳密にオントロジー構造に準拠することを保証する。LLMは以下を識別し、構造化する：

• エンティティの定義および属性スキーマ。
• 定式化された条件（フィールド + 演算子 + 値のトリプル）を持つビジネスルール。
• 関連するロール（役割）を伴うプロセスステップのシーケンス。
• APIエンドポイントの定義。
• ディクショナリの列挙。

2.3 オントロジーの組み立てと検証（ステージ3）

抽出されたアセットは、6種類のタイプからなるオントロジー・ディレクトリへと組み立てられる。DKSEは、以下の4つの特定の相互参照検証チェックを実行する：

1. 属性型チェック: ルールの条件が、エンティティ・スキーマ内の互換性のある型のフィールドを参照していることを確認する。
2. リレーションのカーディナリティ検証: リレーション（例：ONE_TO_MANY）が有効に抽出されたエンティティにリンクしていることを検証する。
3. ディクショナリの完全性: ルールによって参照されているディクショナリ・コードが存在することを確認する。
4. 重複検出: ドメイン内で同一の名前を持つアセットをフラグ立てする。
   失敗は、情報を静かに破棄するのではなく、人間によるレビューのためにログに記録され、完全な監査証跡を維持する。

2.4 オントロジースキーマ

出力されるYAMLエンコードされたオントロジーは、6つの異なるアセットタイプで構成される：

1. Entities (エンティティ): 名前、説明、および属性（名前、型、必須）。
2. Relations (リレーション): ソース/ターゲットのエンティティおよびカーディナリティ。
3. Rules (ルール): 名前、説明、優先度、および定式化された条件。
4. Processes (プロセス): 名前および順序付けられたステップとロール。
5. APIs (API): パス、メソッド、リクエスト、およびレスポンスの定義。
6. Dictionaries (ディクショナリ): 名前およびコード・ラベルのエントリ。
   すべての資産には、プロベナンス（由来）追跡のための、オリジナルの文書セクションを指す source_requirement フィールドが含まれる。

2.5 品質保証とツール

DKSEには、特定のコマンドを持つCLIおよびWebインターフェースが含まれる：

• dkse validate: オントロギーの整合性（型、カーディナリティ、参照）をチェックする。
• dkse diff: 増分的な変更（追加、修正、削除されたアセット）をハイライトするために、オントロジーのバージョンを比較する。
• dkse probe: オントロジーから、機械判定可能な評価プロブ（exact-value, exact-field, set, ordered）を生成する。
• dkse serve: オントロジーの閲覧、検索、および比較のためのWeb UIを提供する。

3. ケーススタディと結果

著者は、6つの要件文書（約80万中国語文字）を用い、4つの銀行サブドメイン（資金拠出管理、顧客管理、クレジット契約管理、および関連当事者取引）にわたるDKSEの評価を行った。

3.1 抽出統計

DKSEは、3,439個の構造化アセットを正常に抽出した：

• エンティティ: 215
• ルール: 1,227
• リレーション: 739
• プロセス: 182
• API: 594（クロスドメイン）
• ディクショナリ: 482

3.2 品質指標

• カバレッジ: DKSEは100%の機能モジュール・カバレッジを達成し、文書の目次に宣言されたすべてのモジュールに対して、少なくとも1つのエンティティ、ルール、およびプロセスを抽出した。
• 正確性: ドメインエキスパート（シニア・バンキング要件エンジニア）が、100個のアセットの層化サンプルをレビューした。
  • 96% が完全に正確であると評価された。
  • 3つ は軽微な命名の差異（意味的に同等）を示したが、使用可能であった。
  • 1つ は、リファインメント・パスにおいて条件の欠落が捕捉された。
  • 0個 のハルシネーション（幻覚）によるアセットは見つからなかった。
• プロベナンス: サンプリングされた100個のアセットすべてにおいて、オリジナルの文書セクションへの正しいソース・ポインタが確認された。

4. ダウンストリームの応用

本論文は、抽出されたオントロジーによって可能となる3つの具体的なダウンストリームのユースケースを示している：

1. 自動ベンチマーク生成: dkse probe コマンドにより、機関ベンチマーク（FinBench）向けに1,214個の機械判定可能な評価プロブ、および4つのドメインにわたる継続的事前学習評価用に200個のプロブを生成した。
2. LLMトレーニングコーパスの構築: オントロジーと要件テキストを組み合わせ、約200万トークンの構造化テキストコーパスを作成した。これは、教師あり微調整（SFT）および継続的事前学習に適している。
3. ナレッジグラフへの取り込み: オントロジーをGraphRAGシステムに投入した結果、5,803個のノードと6,261個のエッジが得られた。これにより、精密な値のクエリに対する検索ソースを提供し、重み注入型トレーニングと比較して、検索不可能な値の捏造を防ぐという安全性上の利点をもたらした。

5. 意義と主張

著者は、本研究を一般的な目的の検証ではなく、単一の業界（中国の銀行業）における**概念実証（PoC）**として位置づけている。

• 核心的な貢献: DKSEは、要件文書が、単純なエンティティ・リレーション・グラフを超えて、型付きのルール、順序付けられたプロセス、およびAPIスキーマを含む、機械実行可能な構造化知識（オントロジー）へと変換可能であることを実証している。
• 実用的な価値: このツールは、人間が読みやすい要件と、自動化されたソフトウェアエンジニアリングとの間のギャップを埋め、自動ベンチマーク作成、コーパス作成、および知識駆動型のコード生成といったタスクを可能にする。
• 限界と範囲: 著者は、追加のドメイン、言語、およびベースライン抽出手法に対する定量的な評価は今後の課題であると明示している。また、LLMによる抽出が高度な正確性（96%）を達成している一方で、残存するエラーに対しては専門家によるレビューが必要であること、およびシステムが基礎となるLLM（中国語の用語に対応する中国語学習済みモデルなど）の能力に依存していることを認めている。
• 進化: 論文は、手動による構造化（1つのドメインに数週間を要する）から、自動抽出（1ドメインあたり数分）への移行を強調しており、同時に、特殊なパースを必要とする表形式が依然として困難な課題であることを指摘している。

本稿は、より広範な主張にはさらなる評価が必要であるとしつつも、DKSEがソフトウェアエンジニアリングの自動化のためにドメイン知識を構造化するための、LLM誘導型パイプラインの使用の実現可能性を正常に検証したものであると結論付けている。