スクラムの文献でLLM Wikiを作る - 用語と概念の選定
前回書いた記事の続きです。 スクラム文献をもとにした LLM Wiki の用語・概念の選定について、「個人的にはこうしてみた」という試行錯誤を書いてみます。
概念と用語の違い
そもそも、なぜ概念と用語を分けたかったのか
まず、Karpathy 氏の llm-wiki には用語や概念についての言及はありません。 ではなぜ分けたのかというと、オントロジー (情報科学) - Wikipedia を調べているときに、「Wiki のページに2種類あると都合が良さそうだな」と感じたからです。 オントロジー由来のクラスを「概念」とおき、文献に出てくる言葉を「用語」として抜き出せば、Wiki の構造として見やすくなるのでは、くらいの軽いノリで分けておくことにしました。
概念と用語の違い（日本語としての意味）
改めて日本語の意味としての違いを辞書で引いてみると、次のようになります。
- 概念（概念 - Wikipedia より引用）
概念（がいねん）とは、物事の概括的な意味内容のことである。
- 用語（用語 - Wikipedia より引用）
用語とは、特定の分野で特に使われる語や句を指している。
個人的な理解と、Gemini による否定
正直なところ、Wikipedia を読んだだけではピンと来ませんでした。 そこで、自分の中では以下のように解釈していました。
- 「果物」を概念とすると、「リンゴ」が用語である
- Java で言えば、具象クラスが用語で、それに対する抽象クラスやインターフェースが概念である
ところが、この理解で合っているかを Gemini に壁打ちしてみたところ、あっさりと否定されてしまいます。 そこからさらに議論を重ねた結果、今回の LLM Wiki では次のような方針で役割分担させることに落ち着きました。
| 観点 | 概念（Concept） | 用語（Term） |
| 位置づけ | オントロジー由来の「意味の骨格」 | 文献由来の「具体的な表現・実例」 |
| 役割 | 知識の正規化、構造化、コンテキストの提供 | 各種ドキュメントや書籍に基づく定義、知識の入口、インデックス |
| Wiki内の実体 | 独立したMarkdownページ（解説・関係性・背景） | 概念ページへのポインタ、エイリアス、原典・文献の用例・1行定義 |
| 生成・管理アプローチ | トップダウン設計、あるいは主題・構造抽出 | 文献からの抽出・収集（書籍、論文、仕様書、開発ログ等） |
| 変化の速度 | 比較的緩やか（ドメインの本質的なモデル） | 文献の追加や参照ソースの増加に伴い継続的に蓄積 |
概念の選定
概念の抽出は、ドメイン知識（スクラムの知識や経験）がないとかなり厳しそうです。 すでにある程度概念化されている枠組みがないかと探したところ、SRO（Scrum Reference Ontology）を見つけました。 このオントロジーでモデル化されているものをベースにすれば筋が良さそうだと考え、SRO をベースに概念を選定しています。
視野を広げるとソフトウェア開発プロセス全般をオントロジーにしたものもいくつかあり、そちらもインプットに使えそうでした。 ただ、それを取り込むと「スクラムの LLM Wiki」という枠から外れてしまいそうだったので、今回は見送っています。 調べてみた範囲では、次のようなものがありました。 なお SRO は、下表にある SEON を継承したオントロジーです。
| オントロジー名 | 主な対象・概要 | 主な特徴 | メリット | デメリット・注意点 | 出所（URL） |
|---|---|---|---|---|---|
| SEON(Software Engineering Ontology Network) | ソフトウェア工学全般（要件・設計・実装・テスト・品質） | 基礎オントロジー（UFO）をベースに体系化された包括的オントロジー群 | ライフサイクル全体を一貫した概念で厳密にモデル化できる | 規模が大きく緻密なため、導入・運用コストが高い | プロジェクトサイトGitHub |
| SWO(Software Ontology) | 科学研究・バイオ等におけるソフトウェア資源 | ツール、ライブラリ、ライセンス、動作環境などのメタデータ管理 | ソフトウェアの特定、分類、ライセンス互換性検証に適する | コード内部構造やアーキテクチャ詳細までは表現できない | OBO FoundryGitHub |
| EDAM(EDAM Ontology) | データ解析ツール・バイオインフォマティクス | 操作、トピック、データ型、フォーマットの体系化 | 入出力を機械可読化し、パイプラインやワークフローの自動構築を容易にする | データ処理・解析領域に特化しており、一般業務アプリには転用しにくい | 公式サイトGitHub |
| CWE(Common Weakness Enumeration) | ソフトウェアのセキュリティ脆弱性概念 | バッファオーバーフローやインジェクションなどの脆弱性体系 | 静的解析ルールや自動診断における概念共有・標準化に寄与 | 脅威動向の変化に伴い、継続的な更新追従が必要となる | MITRE 公式サイト |
| DOAP(Description of a Project) | オープンソースプロジェクトのメタデータ | リポジトリURL、バグトラッカー、言語、メンテナー情報を表現する軽量RDF | シンプルで扱いやすく、分散プロジェクトのメタデータ集約に向く | 表現力が限定的で、高度な推論や内部構造の解析には向かない | GitHub (仕様)ネームスペース |
ライセンスも CC BY 4.0 や Apache License などがあり、二次利用しやすいものが多い印象でした。
用語の選定
用語の選定は LLM に任せる部分もあるものの、人間によるトップダウン指定で抽出すれば精度が上がるのでは、という思いがありました。 幸い、スクラムの文献には用語集が載っているものもあります。 それらを元に統合した用語集を作り、「用語集ベースの抽出 ＋ LLM での蓄積」という形をとることにしました。
用語集の抽出には、文献の Markdown を解析して用語集 JSON を生成する Python スクリプトを作って実行しています。 スクリプトの動作概要は次の通りです。
スクリプトの概要
インプットとアウトプット
- 入力：用語集を探す対象の文献リスト、文献 Markdown ファイル
- 出力：用語集 JSON ファイル
抽出の2つのパターン
-
表形式の用語集からの抽出（大半のケース） 多くの文献では「用語集」の見出し配下に、英語・日本語・説明の列を持つ表が配置されている。これを以下の手順で処理する。
- 見出しから「次の同レベル以上の見出しが現れるまで」を用語集の範囲として特定
- 表のヘッダー（列名）から英語名・日本語名・説明の列を自動判定（表記揺れや OCR 崩れにも対応）
- 各行を1つの用語レコードとして抽出 これらはすべてルールベースの処理であり、実行コストを抑えるため LLM は使わず機械的に処理している。
-
「見出し＝用語」形式の特殊ソース（Scrum Guide Reordered）
Scrum Guide Reordered は用語集そのものの構成を持つため、他文献からの抽出処理とは別に専用の実装を用意して抽出している。
地味な実装の工夫
- PDF 由来のデータ崩れの補正：PDF から Markdown への変換時に単語が途中で改行されてしまう問題（例:
Subject<br>Matter）を復元 - 表記揺れ対策：全角・半角、異体字、大文字小文字などの違いを吸収してから列の役割を判定
- 説明文が文献ごとに食い違うケースの扱い：同じ用語でも文献によって説明が異なる場合、後続処理でのデータ活用のために削除せずすべて保持
実際に用語集が抽出できた文献
ひとまず概念と用語の選定・切り分けについては以上です。
次回は、これらを使って実際にどうやって Wiki ページを生成・リンクさせていったのかを書いていく予定です。