「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
生成AIを使用してドメイン・ナレッジを生成したい。
※ ドメイン・コンテキストと言う造語は「生成AIが保有している一般知識の重要度、比率、条件をドメインに特化させるためのコンテキスト」の意
暗黙知に付いての定義 †
ドメイン・ナレッジの前に、暗黙知に付いての定義をしておく。
生成可能か？不可か？ †
AIに質問した所、以下のような回答があった。
- LLMは大量の文章からパターンを学んでいるから、専門書で文書化されていたり、分析結果がデータ化されている「擬似的な暗黙知」は、かなり生成できる。
- しかし、身体感覚に強く依存するもの、非常に狭い界隈に限定されるもの、本人も言語化できていないレベルの直感など「完全な暗黙知」は、かなり生成できない。
完全 or 擬似的な暗黙知 †
- AI（言語モデル）自体が暗黙知を説明できるのはコーパスから学習した事を意味する。
- 「完全な暗黙知」は本質的に形式知化が不可能な部分もあるが（例：直感やセンス）、
- 「擬似的な暗黙知」は単一のナレッジ・ベースにまとまっていなかったりデータ化されていないケースが多い。
- 言語化し難いという側面に加えデータ化されていないと言う側面がある。
- 「職人の勘」のようなものも、データ化することで人間以上に再現可能になるものもある。
- しかし、「擬似的な暗黙知」も、コスパ観点やモチベーション観点の側面から「データ化」「情報集約」が促されないケースが多い。
- コスパ観点：形式知化がコスパ的に合わない。
- モチベーション観点：形式知化がデメリットになるなどで動機がない。
状況を決める因子 †
以下のようなものがある。
- 非言語的：感覚や身体動作など言語では捉え難く、また、データ化に専門知識が必要
- 組織文化：経験を形式知として残すことの価値の認識がない場合
- 認知の壁：そもそも自分のやってることは価値があるとの認識がない場合
- 状況依存性：文脈依存での場合が分けが多く、一般化・共有・活用が難しい
ドメイン・ナレッジと、その生成 †
基本的な専門知識は生成AIが保有しているから...
そもそもドメイン・ナレッジとは？ †
AIに質問した所、以下のような回答があった。
- 特定の分野・領域（ドメイン）に関する専門的な知識・経験のこと。
- ドメイン（分野・領域）＝業界・分野・領域の特有の知識を深く理解していることを指す。
- 医療ドメイン → 診断の流れ、保険制度、医療用語、規制（薬機法など）
- 金融ドメイン → 会計基準、金融商品の仕組み、コンプライアンス要件
- 製造業ドメイン → 生産工程、品質管理、サプライチェーンの慣行
- ECドメイン → 購買行動、在庫管理、物流コストの構造
では、ドメイン・コンテキストとは？ †
- 特定ドメインの情報の重要度、比率、条件を指定する文脈
- 例：他のIT系業種と比べて、SI事業で開発される業務システムで発生し易い性能問題は？
- 1. 夜間バッチ処理の長時間化（最も典型的な問題）
- 2. データベースクエリの性能劣化（SQLボトルネック）
- 3. ピーク時同時接続・負荷集中時のレスポンスタイム悪化
仮説：フォワード生成できるのでは？ †
情報の重要度、比率、条件を「ドメイン・コンテキスト」で調整して出力をドメインに特化させる。
- AIが保有していない知識は、「組織内の独自情報」（ルールなど）と、「完全な暗黙知」ぐらいではないか？と考える。
ドメインに適合させるイメージ †
一般的な情報に「XXX（ドメイン）においては？」と言う軸を加え「追加軸での分布（重要度、比率、条件）が追加された」情報を取得する。
|
|
|
| イメージA | イメージB |
| イメージA、イメージBとあるが、意味するところは同じ |
結構、良い絵が出たのでプロンプトをメモ
以下のような言語モデル生成AIの画像イメージを生成してください。
・情報が空間（2次元散布図）上に散らばっているものとします。
・プロンプトで2次元の集合から情報を抽出します。
・プロンプトを追加する事で2次元の集合に次元を追加し3次元の集合から情報を抽出します。
・集合からの情報抽出イメージは１つのプロットではなく複数のプロットを含む集合をポイントします。
・3次元の図については立体感を出してください。
※ 左右の図を関連付ける線と丸は、ペイント・ソフトを使用して追記しています。
出来ることと出来ないこと †
そもそもナレッジ生成はドメインに適合したナレッジ情報のセットを取得すること。
出来ること †
生成AIがドメイン知識を学習済みの場合のナレッジ生成（ナレッジのリサーチ）
ドメインに適合した（既知の）情報のセットを取得するためのプロンプトを与える。
- 既知問題（かんたん）
コーパスで学習しているハズなので、ソレを取り出すプロンプトを与える。
- 未知問題（ただし難しい）
コーパスで学習していないので、情報を組み合わせたり、傾向を探ったりするプロンプトを与え
「確定的な知識獲得」ではなく、類似ドメイン・隣接領域からの類推、構造的共通性の抽出をする。
出来ないこと †
膨大なコーパスで学習しているが、マイナーなドメインにおいては、
網羅性や重要度が目的変数として最適化されていないため
- 網羅性が無い「情報の網羅性の欠如」
- 重要度が無い「フォーカスポイントの欠如」
が発生する可能性がある。そのため、マイナーなドメインには特化せず、
- 「平均的な知識」「多数派の言説」「よく知られたトピック」に偏る。
- 膨大なコーパスで学習しているため、テンプレ的構造には強いが、
目的依存で内容の意味的な重みや本質的な論点を再定義する力は強くない。
- 重要な視点（低頻度重要問題）や最新の情報の項目（時間軸問題）が抜け落ちる可能性がある。
- 重要なハイレベル課題に人間が適切な軸をプロンプトとして与えなければリーチしない。
などの問題があるため、生成AIを使用し「０（零）」ベースで網羅性や重要度ドメイン知識を得るのは非効率と言える。
- 生成AIを使用しても「「私」と同じ（SI系生産技術の）知識」を生成AIを用いて入手するのは困難。
- 生成AIを使用しても「例えは特定ニッチ用途向けのDIY知識」を生成AIを用いて入手するのは困難。
※ 必要な「網羅性の高い情報」や「重要度についての情報」をプルできない。全体的にプッシュして貰った方が容易。
※ 生き字引には情報をプッシュする即応性（、文脈理解、経験値/暗黙知、例外判断、人間育成、創造性）に利点がある。
詳細 †
ドメイン・コンテキスト作成手法 †
ドメイン・コンテキストの生成方法次第で「フォワード生成」or「リバース生成」に分類できる。
アリモノ活用 †
例えば「性能問題のポイント」の目次項目を使用する。
フォワード生成 †
- 必要に応じて更に詳細化（4階層以下の生成）
CCCCにフォーカスしてさらに詳細化して下さい。
リバース生成 †
ソースを体系的ドメイン・コンテキストを生成するためのノウハウとして使用する。
- Wikiを生成AIのRAGソースにして、情報を抽出してドメイン・コンテキストとする。
Vector RAG、Graph RAGではダメ、Summary Indexはコストが掛かり過ぎる、Agentic RAGは良好。
- Wikiを生成AIのファイン・チューニング（FT）用コーパスにして、FTされたSLMの出力をドメイン・コンテキストとする。
現時点では、SLMに新規情報を学習させることが困難なため上手く機能しないという結論。
ドメイン・ナレッジ作成手法 †
（XXXXはドメイン、YYYYは対象）
アリモノ活用 †
例えば「性能問題のポイント」の目次項目を使用する。
フォワード生成 †
生成AIから生成させた文字列をプロンプトに加えることは「コンテキストの強化」と呼ばれ出力の質を向上させる効果がある。
- チャットUIで逐次、対象ドメインを絞る提案があるのでドリルダウンするケース：
- 入力：XXXXが遭遇し得るYYYYについて発生しやすい問題はどの様な問題ですか？
- 出力：...回答... もしよければ 👉️ 1111/2222、3333か？4444か？
- 入力：（例）1111の3333
- 出力：...回答... もしよければ 👉️ 5555/6666か？、7777/8888、9999か？
- 入力：（例）5555・7777
リバース生成 †
- Vector RAG：VDBに格納したWikiのチャンクから生成
- Top-K=50-100とRecall（取り零し抑止）を最大化したVector RAGのチャンクを使う。
- これを生成AIで「まとめ」ても、網羅性、体系化、重要度に問題が出やすい。
- 「チャンクに回答が含まれない」「Recallの最大化 ≒ ノイズも最大化」「情報圧縮で知識設計でない」
- もう少し複雑なプロンプト・フローにすれば解決可能な可能性はある？（チャンク毎にLLMで評価するなど）
- Agentic RAG：AgentのToolを用いてWikiなどを対象としたGoogle検索結果から生成
- Google検索は、VDB検索と異なり、Recallは捨てて、 Precisionを極限まで高めたHybrid Retrieval
- XXXXのYYYYについて検索キーワードで検索した結果から重要な情報を抽出しているモノと思われる。
参考 †
LLM Knowledge Base †
2026年4月3日：LLM にナレッジの「保守」を任せる（生のドキュメントを LLM に渡して、構造化された Markdown の wiki を「コンパイル」してもらう）アイデア
https://dev.classmethod.jp/articles/karpathy-llm-knowledge-base/
開発基盤部会 Wiki †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
