Skip to content

OTR_KnowledgeGenerationPrompt

Jump to bottom
nishi_74322014 edited this page Nov 5, 2026 · 1 revision

ナレッジ生成用プロンプト

概要

生成 AI を使って、SI の現場のドメイン・ナレッジ（性能問題・移行・PM などの「生き字引」の知識）を引き出したい。

  • ドメイン・ナレッジには、「完全な暗黙知」と「擬似的な暗黙知」がある。後者は、生成 AI が知識として持っているので、生成できる。
  • 生成するには、プロンプトにドメイン・コンテキストを渡せばよい。
    • ドメイン・コンテキスト（造語）：生成 AI が持つ一般知識の重要度・比率・条件を、ドメインに特化させるための文脈。
  • ドメイン・コンテキストの作り方で、フォワード生成（生成 AI に作らせる）とリバース生成（Wiki などのノウハウ集から取り出す）に分かれる。
  • 試した結果、リバース生成では Agentic RAG が良好だった。Vector RAG・Graph RAG は振るわず、Summary Index はコストが掛かり過ぎる。
  • このノウハウ集（本 Wiki）を Agentic RAG の情報源にすることは、建付けの「ノウハウとコーディング・エージェントを活用して、ソリューションの提供をサポートする」の、エージェントの側の使い方の 1 つである。

詳細

暗黙知の定義

生成できるか

  • LLM は大量の文章からパターンを学んでいる。専門書で文書化されていたり、分析結果がデータ化されていたりする「擬似的な暗黙知」は、かなり生成できる。
  • 身体感覚に強く依存するもの、非常に狭い界隈に限られるもの、本人も言語化できていない直感などの「完全な暗黙知」は、ほとんど生成できない。

完全な暗黙知と擬似的な暗黙知

  • AI が暗黙知を説明できるのは、コーパスから学習したからである。
    • 「完全な暗黙知」には、本質的に形式知にできない部分がある（直感・センスなど）。
    • 「擬似的な暗黙知」は、1 つのナレッジ・ベースにまとまっていない、データになっていないことが多い。
      「職人の勘」のようなものでも、データにすれば人間以上に再現できるものがある。
  • ただし、擬似的な暗黙知も、データ化・集約が進まないことが多い。
    • コスパ：形式知にするコストに見合わない。
    • 動機：形式知にすると本人に不利になるなど、動機が無い。

状況を決める因子

因子 内容
非言語的 感覚や身体動作など、言語で捉え難い。データ化に専門知識が要る
組織文化 経験を形式知として残すことの価値が認識されていない
認知の壁 そもそも、自分のやっていることに価値があると認識していない
状況依存性 文脈による場合分けが多く、一般化・共有・活用が難しい

ドメイン・ナレッジとドメイン・コンテキスト

  • ドメイン・ナレッジ：特定の分野・領域（ドメイン）の専門的な知識・経験。
    • 例：医療（診断の流れ・保険制度・規制）、金融（会計基準・金融商品・コンプライアンス）、製造（生産工程・品質管理・サプライ チェーン）。
  • ドメイン・コンテキスト：特定のドメインの情報の重要度・比率・条件を指定する文脈。
    • 例：「他の IT 系の業種と比べて、SI 事業で開発される業務システムで発生し易い性能問題は？」
      → 1. 夜間バッチの長時間化、2. SQL のボトルネック、3. ピーク時の同時接続によるレスポンスの悪化。

仮説：フォワード生成できるのでは？

  • 生成 AI が持っていない知識は、「組織内の独自の情報」（ルールなど）と「完全な暗黙知」ぐらいではないか。
  • それなら、ドメイン・コンテキストで重要度・比率・条件を調整すれば、出力をドメインに特化させられる。

ドメインに適合させるイメージ

一般的な情報に「XXX（ドメイン）においては？」という軸を加え、追加した軸での分布（重要度・比率・条件）を持つ情報の集合を取り出す。
次の 2 つの図は、どちらも同じことを表す（画像生成 AI で描いた図。左の図の右下の英語は綴りが崩れている）。

2 次元の集合から、プロンプトで軸を足して 3 次元の集合から取り出す（イメージ A）

2 次元の集合から、プロンプトで軸を足して 3 次元の集合から取り出す（イメージ B）

図を描かせたプロンプトは、次のとおりである。

以下のような言語モデル生成AIの画像イメージを生成してください。
・情報が空間（2次元散布図）上に散らばっているものとします。
・プロンプトで2次元の集合から情報を抽出します。
・プロンプトを追加する事で2次元の集合に次元を追加し3次元の集合から情報を抽出します。
・集合からの情報抽出イメージは１つのプロットではなく複数のプロットを含む集合をポイントします。
・3次元の図については立体感を出してください。

できることとできないこと

ナレッジ生成とは、ドメインに適合したナレッジの集合を取得することである。

  • できること（生成 AI がドメインの知識を学習済みの場合）
    • 既知の問題（易しい）：コーパスで学習しているはずなので、それを取り出すプロンプトを与える。
    • 未知の問題（難しい）：情報を組み合わせ、傾向を探るプロンプトを与える。
      「確定的な知識の獲得」ではなく、類似・隣接の領域からの類推や、構造の共通性の抽出になる。
  • できないこと（マイナーなドメイン）
    • 網羅性や重要度が目的変数として最適化されていないので、「網羅性の欠如」と「フォーカスの欠如」が起きる。
    • 出力は「平均的な知識」「多数派の言説」「よく知られたトピック」に偏る。テンプレ的な構造には強いが、目的に応じて論点の重みを定義し直す力は弱い。
    • 重要な視点（頻度は低いが重要な問題）や、最新の情報（時間軸の問題）が抜け落ちることがある。人が適切な軸をプロンプトで与えないと、重要な課題に届かない。

したがって、生成 AI で「ゼロから」網羅性や重要度のあるドメイン知識を得るのは非効率である。
「SI の生産技術の知識」や「特定のニッチな用途の DIY の知識」は、プルでは取り出し難く、プッシュしてもらう方が容易である。
生き字引（人）の利点は、このプッシュの即応性（と、文脈の理解・経験・例外の判断・人の育成・創造性）にある。

ドメイン・コンテキストの作り方

基本はフォワード生成で足りる。必要な情報（網羅性・重要度・比率・条件）が含まれないときに、リバース生成で補う。

手法 方法 結果
アリモノの活用 ノウハウ集の目次（例：性能問題のポイント、移行見積もりの概要）をそのまま使う 目次の層が浅いと、下層の項目を正確に推論できないことがある
フォワード生成 生成 AI に目次を作らせる（下のプロンプト） ドメインに寄り切らない（性能なら「アプリの実装によるラウンド トリップ」が抜けた）。範囲が広すぎて項目が薄くなることもある
リバース生成：Vector RAG Wiki のチャンク（Top-K=50〜100、Recall を最大化）をまとめさせる 網羅性・体系化・重要度に問題が出やすい（チャンクに答えが無い、Recall の最大化はノイズの最大化、情報の圧縮であって知識の設計でない）
リバース生成：Graph RAG Wiki からグラフを作る インデックスの作成のコストの割に、改善が小さい
リバース生成：Summary Index Wiki の要約の索引を作る コストが掛かり過ぎる
リバース生成：Agentic RAG エージェントに、Wiki を優先して Web 検索させる（下のプロンプト） 良好。検索エンジンは、Recall を捨て Precision を極限まで高めた Hybrid Retrieval として働く
リバース生成：FT Wiki で SLM をファイン・チューニングし、その出力を使う 現時点では、SLM に新しい情報を学習させるのが難しく、上手く機能しなかった

フォワード生成のプロンプトは、次のとおりである。

AAAAにおけるBBBBについての重要な項目を2-3階層の目次レベルで体系化してください。

必要に応じて、さらに詳細化する（4 階層以下）。

CCCCにフォーカスしてさらに詳細化して下さい。

ドメイン・ナレッジの作り方

生成 AI が生成した文字列をプロンプトに加えることは「コンテキストの強化」と呼ばれ、出力の質を上げる。

  • 一括：ドメイン・コンテキスト（目次）を作り、そのプロンプトに足して、章・節・項の単位で解説させる。
    網羅性が低く概要のレベルになるときは、単位を細かくする。

    ITシステムインテグレーターが遭遇し得るITシステムの性能問題について
発生し易い問題を以下の目次の一部分に従って解説して下さい。

  • 逐次：チャット UI が「もしよければ 👉 Web 系 / 業務系、設計・実装か運用トラブルか？」と絞り込みを提案するので、それに沿ってドリルダウンする。
    対話的で分かりやすいが、体系的ではない。体系的になるまで、根気よく対話を続ける必要がある。
    提案が出ない話題（移行）では、自分で絞り込む（「システム基盤・アプリケーション・データの移行に絞って」→「工数の見積もりを詳しく」など）。

Agentic RAG のプロンプト

エージェントに、このノウハウ集を優先して検索させる。

あなたはユーザーの要求に合わせインターネット検索を行い、発見した技術情報を提供するエージェントです。
インターネットや、インターネット上の以下の優先ナレッジから情報を取得して回答をします。
https://netdevinfrawginossconsortium.github.io/NetDevInfraWiki/

優先ナレッジを使用する場合、以下の様に検索してください。

site:netdevinfrawginossconsortium.github.io/NetDevInfraWiki {キーワード}

参考にしたWebページ情報はユーザにも提示して下さい。

ユーザーの要求：
「XXXXのYYYYを教えてください。」
※ キーワードには「X」「Y」「Z」などを使用します。
  • 優先ナレッジは、旧 Wiki（opentouryo.osscons.jp・techinfoofmicrosofttech.osscons.jp・dotnetdevelopmentinfrastructure.osscons.jp）から、この Wiki を静的サイトとして公開した GitHub Pages に替えた。
    旧 Wiki は停止していることがあり、また GitHub Wiki は検索エンジンにインデックスされない（x-robots-tag: none）ので、公開したサイトを使う。
  • ページ名のプレフィックス（MS_・DNET_・OTR_）は、元のサイトに対応する。特定の分野に絞るなら、キーワードに日本語のページ名の一部を使う方が確実である。
  • site: の検索は、公開したサイトのインデックスが進むまで、件数が少ない。

結果

話題 結果
性能（「SI が遭遇しうる性能問題」） なかなか良いが、体系的でないため網羅性に問題があり、項目ごとの重要度・優先度が分からない
移行（「マイグレーション案件の見積もり方法」） 移行系は情報が分散していないので、網羅性・重要度の問題が少ない。フォワード生成の「アリモノ」の目次で解説させたときも、Wiki の内容を取得して使っていることが観測できた
Oracle → SQL Server の移行でのデッドロック（下の例） 良好。関連するページを、読む順番を付けて案内した

例：Oracle から移行した SQL Server でデッドロックが発生する

旧 Wiki を優先ナレッジにして、「Oracle からの移行で SQL Server のデッドロックが発生。関連ページをポイントして解説して」と依頼した結果である。
回答は、次の 5 ページを読む順番に並べ、各ページの要点を引いて解説した。いずれも、この Wiki に移行済みである。

順 回答が案内したページ 移行先 回答が引いた要点
1 DBMSのロック・分離戦略と同時実行制御（最重要） MS_DBMSLockingAndIsolation Oracle は多バージョン法（MVCC）で、SQL Server の既定はロック法。Oracle と同じ感覚で開発すると、性能劣化やデッドロックが起きる
2 SQL Server でのデッドロック MS_SQLServerDeadlock 同じ順序でオブジェクトにアクセスする。長いトランザクション、SELECT の共有ロック。多バージョン法への切替（READ_COMMITTED_SNAPSHOT）
3 SQL Server でのロック・タイムアウト MS_SQLServerLockTimeout 誰がロックし、誰が待たされているかを可視化する
4 SQL Server のロックのエスカレーション MS_SQLServerLockEscalation 大量の更新でテーブル ロックへエスカレートし、全員が待たされる。バッチ系の移行で頻出
5 SQLプロファイラ（SQLトレース） MS_SQLProfiler 原因の調査

ページの案内と、「Wiki でも〜と説明されている」とした箇所は、移行済みのページの記述と合っていた。
一方で、エージェントが一般知識で補った部分には、誤りや古い記述が混じった。

  • 「行ロック → ページ ロック → テーブル ロックへ昇格する」は誤り。SQL Server のエスカレーションは、行・ページのロックからテーブル（またはパーティション）へ直接上がる。
    MS_SQLServerLockEscalation は「（行、ページ）⇒ テーブル」と正しく書いている。
  • 調査の手段に sp_lock を挙げているが、これは互換性のために残された古い手段で、現在は sys.dm_tran_locks などの動的管理ビューを使う（回答は両方を並べていた）。

Agentic RAG の回答は、案内されたページを開いて突き合わせるところまでを手順に含める。
ノウハウ集の側が、正誤のチェックと最新化を済ませてあること（この Wiki の移行で行ったこと）が、突き合わせの前提になる。

LLM Wiki との関係

  • 2026-04 に、Karpathy 氏が「LLM Knowledge Base」（LLM Wiki）のパターンを言語化した。
    生のドキュメントを LLM に渡して、構造化された Markdown の Wiki に「コンパイル」させ、保守も LLM に任せる考え方である。
  • この Wiki は、旧 Wiki（PukiWiki）をコーディング・エージェントで Markdown に移行・再構築し、正誤のチェックと最新化を加えたものなので、この実例と言える。
  • その Wiki を静的サイトとして公開し、Agentic RAG の優先ナレッジにすると、エージェントが保守したノウハウ集を、別のエージェントが引く形になる。

参考

Tags: 再構築

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki
開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally