記事本文
ChatGPTに資料を渡したのに、社内で使っている言葉の意味が少しずれている。
文章は読みやすいけれど、そのまま仕事に使うには、事情を知っている人の修正が欠かせない。
そんな経験はないでしょうか。
たとえば、社内勉強会について「参加者へ資料を送って」と依頼したとき。
参加者とは、申し込んだ人なのか、当日出席した人なのか。
欠席しても資料を受け取れる人がいるなら、その条件まで伝わっているでしょうか。
この問題を考える手がかりが、ナレッジエンジニアリング、日本語でいう知識工学です。
人が知っていることを取り出し、意味や条件を整理して、コンピューターが利用できる形にする。
生成AIよりずっと前から続いている取り組みです。
その歴史を辿ると、いま注目されるコンテキストエンジニアリングとのつながりも見えてきます。
AIへの頼み方を工夫するときに、そもそも何を知識として用意しておくべきなのか。
今回は、そこから考えてみましょう。
ナレッジとは：記録に、意味と判断の条件を加える
まず、この記事で扱う「知識」を、身近な例で確かめておきたいと思います。
以下の勉強会の話は、概念を説明するための架空の業務例です。
申込フォームに名前が並んでいても、それだけでは資料の送付先を決められない。
「資料は申込者全員に配布する」という運営ルールがあって、初めて判断につながる。
さらに「社外講師の資料だけは当日参加者に限定する」という例外があれば、配布する資料の種類も確認しなければなりません。
ここで必要なのは、名簿という記録、その項目の意味、適用するルール、そして例外の組み合わせです。
知識を整えるとは、こうした関係を他の人やシステムにも使えるようにすること。
ファイルを集めたところで終わる仕事ではありません。
この考え方の背景を、代表的な節目に絞って振り返ってみましょう。
| 時期 | 代表的な取り組み | 知識を使ううえでの焦点 |
|---|---|---|
| 1960〜1970年代 | DENDRALなどの知識ベースシステム | 専門家が何を根拠に判断しているかを取り出す |
| 1990年代 | オントロジーによる知識の共有 | 用語・概念・関係を明示し、別のシステムでも意味を保つ |
| 2000年代 | セマンティックWeb、OWLの標準化 | Web上の情報にも、機械が扱える意味と関係を記述する |
| 2020年 | GPT-3、RAGの研究 | 文章で仕事を指示し、必要に応じて外部の知識を参照する |
| 2025〜2026年の事例 | 証拠を集めるエージェント、OpenAIの社内システム | 今回の仕事に必要な情報を選び、実行中も補う |
これは、古い方式が次の方式へ一斉に置き換わったという年表ではありません。
知識を取り出す、意味を揃える、必要な場面で使うという課題を、時代ごとの取り組みから見ていくための整理です。
1960〜1970年代：専門家の判断を、コンピューターで使える形へ
知識工学の初期の代表例として、1965年に始まったDENDRALがあります。
化学の測定データや専門知識を使って、分子の構造の候補を絞り込む研究でした。
1977年、研究者のエドワード・ファイゲンバウムは、知識工学の課題として、専門知識の獲得、表現、推論への利用などを論じました。
特定の分野の知識を、問題を解く仕組みにどう組み込むかが中心にあったわけです。
専門知識を蓄え、判断に使うこうした仕組みは、知識ベースシステムやエキスパートシステムとして知られています。Feigenbaumの論文（1977年）
利用する側から見ると、専門家の判断の一部を、決められた領域でシステムに支援してもらう試みでした。
一方、作る側には、その専門家が普段は省略している条件まで確かめる仕事が必要になった。
本人にとって当たり前の判断ほど、説明されないまま残りがちだからです。
勉強会の例なら、「いつも通り資料を送って」の中身を聞き出す段階に当たるでしょう。
何を見て送付先を決め、どの場合だけ扱いを変えるのか。
結論だけを記録しても、別の状況で同じ判断を再現できるとは限りません。
知識工学の入口には、人の判断を、その判断が成り立つ条件と一緒に取り出す仕事がありました。
1990年代：知識を共有するには、言葉の意味も揃える必要があった
知識を取り出せても、別のシステムが同じ意味で受け取れるとは限らない。
そこで次に見たいのが、知識の共有と再利用を扱う研究です。
トーマス・グルーバーの1993年の論文は、知識を共有するための語彙を明示し、異なる知識表現の仕組みへ移せるようにする方法を扱いました。
その中心にあったのが、オントロジーという考え方でした。Gruberの論文（1993年）
ここでのオントロジーは、ある分野にどんな概念があり、それらがどう関係するかを明示したものです。
単なる言葉の一覧よりも、一歩踏み込んだ整理と考えると分かりやすいでしょう。
勉強会なら、「人」「申込」「開催回」「出席記録」を区別する。
そのうえで、「人が開催回に申し込む」「出席記録は特定の開催回に結びつく」という関係を定める。
こうすれば、申込者と当日参加者を、同じ名簿の曖昧な呼び名として扱わずに済むでしょう。
ただし、この短い整理だけで、本格的なオントロジーが完成したとはいえません。
実務の入口として注目したいのは、情報を受け渡すときに、項目名だけでなく意味と関係も揃えるという考え方です。
名前が一致していても、意味が一致しているとは限らない。
この問題は、いまAIに複数の表や資料を読ませるときにも、そのまま現れます。
2000年代：Webの情報にも、機械が扱える意味を記述する
意味や関係を共有する取り組みは、Web上の情報を扱う技術にも広がりました。
その一つが、情報の意味を明示し、機械による処理や統合をしやすくするセマンティックWebの構想でした。
2004年には、Webの標準化団体W3Cが、オントロジーを記述する言語OWLを勧告として公開しました。
用語の意味や用語同士の関係を、アプリケーションが処理できる形で表すための仕様です。W3CのOWL概要（2004年）
利用者の仕事に引き寄せるなら、別々の場所にある記録を、何についての記録かを保ちながら結びつける方向といえるでしょう。
たとえば、申込ページと出席管理の表が同じ開催回を指していると確認できれば、人が毎回タイトルを見比べる作業を減らせるかもしれません。
ただ、意味を記述する仕様ができても、各資料の意味が自動で整うわけではありません。
何を同じものとみなすか、どんな関係を記録するかという設計は、引き続き必要でした。
2020年：文章で仕事を頼めても、社内の事情まで伝わるわけではない
ここまでの話には、知識を明示的に組み立てる手間がありました。
一方、大規模言語モデルは、多くの文章から学習した能力を、さまざまな言語処理に利用する方向を広げました。
OpenAIのGPT-3を扱った2020年の論文では、課題ごとにモデルを追加学習させず、文章の指示や少数の例を与える方法を評価しています。
翻訳や質問応答など、多様な課題で成果を示す一方、うまくいかない課題も報告されました。Brownらの論文（2020年）
利用者にとっての変化は、仕事を頼む入口にありました。
目的や例を文章で示す方法が広がり、細かな処理を一から組み立てなくても、試せることが増えた。
現在のChatGPTを使う感覚にもつながる変化でしょう。
ただ、文章を理解して案内文を書く能力と、今日の自社ルールを知っていることは、分けて考えなければなりません。
今朝決まった資料の配布条件を渡していなければ、それを回答の前提にできるとは期待できない。
一般的に自然な案内文ができても、今回の送付先が正しいかどうかは、別に確かめる必要があります。
生成AIで知識工学が必要になる理由は、この区別に表れています。
モデルの言語能力を仕事に結びつけるには、そこで使う言葉、判断条件、参照すべき情報を用意する役割が残るからです。
同じく2020年：RAGで、外部の知識を参照しながら答える
モデルの内部にある知識だけで答えようとすると、情報の更新や出典の扱いが課題になる。
その問題に取り組んだ代表的な研究が、2020年のRAG、検索拡張生成でした。
RAGは、質問に関係する情報を外部から検索し、その情報を使って回答を生成する仕組みです。
ルイスらの論文では、学習済みモデルとWikipediaの検索用データを組み合わせ、質問応答などの課題を評価しました。
モデル内部の知識と、外部で参照できる知識を組み合わせる点が特徴でした。Lewisらの論文（2020年）
社内業務に置き換えるなら、質問のたびに、関連する規程や手順書を探してから回答を作るイメージでしょう。
すべてを人が貼り付ける負担を減らせる可能性がある一方、検索対象をどう整えるかが重要になります。
たとえば、古い配布ルールと新しいルールが、どちらも「勉強会の資料配布」という名前で残っていたらどうでしょう。
質問によく似た文書を見つけても、それが今回適用すべき版だとは限らない。
出典が付いていても、その出典の選択が正しかったかは確認しなければなりません。
ここで、知識工学の仕事が再びつながってきます。
検索できるようにすることに加えて、有効な版、用語の定義、適用範囲を整理する。
資料を探す仕組みと、探した資料を判断に使える状態にする仕事は、両方必要でしょう。
2025〜2026年：知識を用意するところから、今回の文脈を組み立てるところへ
検索を使えるようになると、次の問いが生まれます。
見つかった資料のうち、いまの仕事には何を渡せばよいのか。
会話の途中で条件が変わったとき、何を追加し、どの情報を更新すべきなのか。
このように、AIがその時点で参照する情報を設計する取り組みが、コンテキストエンジニアリングです。
この記事では、依頼内容、関連資料、会話の状態、ツールで取得した結果などを、仕事に合わせて組み立てることとして扱います。
OpenAIが2025年10月に紹介した研究支援サービスConsensusの事例では、生成に先立って適切な証拠を集める取り組みを、同社がコンテキストエンジニアリングと呼んでいました。
論文やメタデータ、原研究に辿れる主要な知見をまとめて、回答の材料にする構成でした。OpenAIによるConsensusの事例
さらに、2026年1月に公開されたOpenAIの社内データエージェントでは、専門家によるデータの説明、社内の定義や文書、必要に応じた実行時のデータ確認などを組み合わせています。
これはOpenAIの内部専用システムの事例であり、ChatGPT全体の標準機能を説明したものではありません。OpenAIの社内データエージェント
この設計を業務の視点で読むと、蓄えておく知識と、その場で確かめる情報の役割を区別できるでしょう。
「参加者とは誰を指すか」という定義は繰り返し使う。
「今回の開催回で誰が出席したか」は、その回の記録から確かめる。
どちらか一方だけでは、送付先の判断は完成しません。
コンテキストは、長くすればよいわけではない
背景が必要だと分かると、資料を全部渡したくなるかもしれません。
けれども、今月の資料配布を判断する場面に、過去の全開催回の議事録まで必要でしょうか。
OpenAIの2026年2月の開発事例では、大きな指示ファイルに情報を詰め込む方法の問題が説明されました。
そこで採られたのは、短い案内から、整理された詳細資料へ辿れる構成でした。OpenAIのHarness engineering記事
この事例から実務に取り入れるなら、情報量を増やす前に、必要な情報へ辿る道筋を考えてみてください。
勉強会の資料配布なら、今回の依頼、現行の配布ルール、対象回の記録、今回だけの例外を揃える。
足りない条件があれば、その段階で確認する設計も考えられるでしょう。
プロンプトの書き方も、その中に含まれる大切な工夫です。
ただ、依頼文を磨くだけでは、参照資料の古さや、欠けている出席記録は補えません。
AIが何を見て仕事をするのかまで、考える範囲を広げる必要があります。
知識を整える仕事と、知識を渡す仕事をつなぐ
ここまでの違いを、仕事の設計に使うために整理してみましょう。
両者には重なる部分もあるため、次の表は厳密な学問上の境界ではなく、改善箇所を見つけるための目安です。
| 観点 | ナレッジエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 主に問うこと | 何を、どんな意味・条件を持つ知識として整えるか | 今回の仕事に、何を、いつ、どの形で渡すか |
| 勉強会の例 | 申込者・参加者の定義、配布ルールと例外を整理する | 対象回の記録と現行ルールを選び、今回の依頼と合わせる |
| 見直すきっかけ | 定義が曖昧、資料同士が矛盾、判断条件が記録されていない | 必要な資料が渡らない、古い会話が残る、現在の状態が欠ける |
たとえば、AIが誤った送付先を挙げたとき。
ルールそのものが曖昧なら、運営担当者と定義や例外を整理するところから。
ルールは明確なのに古い版が渡っていたなら、資料の選び方や更新の仕組みから見直してみてください。
同じ誤答でも、直す場所は違うかもしれません。
その違いを確かめてから、プロンプトやモデルの変更を試すほうが、改善の理由を追いやすくなるでしょう。
最初の一歩：一つの質問から、必要な知識を辿ってみる
会社全体の知識を、一度に整理しきる必要はありません。
まずは、繰り返し発生する質問を一つ選んでみてください。
たとえば、「今回の資料を誰に渡せばよいか」。
それに答えるための定義、現行ルール、対象回の記録を並べ、担当者が普段どこを見て判断しているか確かめる。
AIに渡して試したあとには、回答だけでなく、どの資料のどの条件を使ったかも確認してみましょう。
間違いがあれば、知識が足りなかったのか、選び方に問題があったのか、それとも渡した情報の解釈を誤ったのかを分けて記録する。
この区別があれば、次に手を入れる場所を選びやすくなるはずです。
専門家の判断を取り出す研究から始まり、意味を共有し、外部の資料を検索し、その時点の仕事に合わせて情報を組み立てるところまで。
技術が変わるなかでも、何を根拠に判断できるのかという問いは残ってきました。
生成AIを仕事で使うときは、依頼文と一緒に、その判断を支える知識にも目を向けてみてください。
「何を知識として整えるか」と「今回、何を渡すか」をつなぐところに、ナレッジエンジニアリングを学ぶ実務的な意味があるのではないでしょうか。
お読みいただき、ありがとうございました。