1. はじめに：読者と問題設定

パイプラインは、割とすぐに動きました。社内文書をセグメントに分割し、LLMに渡して記事を生成し、ナレッジベースに取り込み、検索につなぐ。現在のツールを使えば、ここまでは正直、難しくありません。

問題は、その後でした。

筆者は、業務マニュアルなどの社内文書を、AIが検索できるナレッジベースへ変換する取り組みで、パイプラインの設計と評価を担当しました。本稿はその振り返りです。読者として想定するのは、ETLや業務データのパイプラインにLLMの生成工程を組み込もうとしているエンジニア、アーキテクトです。扱う方法は、特定のプラットフォームにも、特定の文書の種類にも依存しません。

パイプラインを作った後に来る、二つの問題

一つ目は、品質を証明できないことです。手元には、生成された記事が大量にあります。「この記事群の品質は合格か？」と聞かれて、どう答えればいいのでしょうか。一件ずつ読むのは現実的ではないし、抜き取り確認では説得力が足りません。しかも困ったことに、この種のタスクには、そのまま当てはめられる評価基準がありません。

二つ目は、欠陥の場所を特定できないことです。質問応答が誤った回答を返してきました。さて、どこを疑えばいいのでしょうか？　原稿にもともと書かれていなかったのかもしれない。セグメント分割で切り方を誤ったのかもしれない。生成時に情報が落ちたのかもしれないし、原文にない内容が作られたのかもしれない。検索が記事を取り逃したのかもしれない。場所を特定できないと、打てる手は「手当たり次第」だけです。モデルを替える、プロンプトを直す、検索パラメータを変える——そして試した後に、良くなったのかどうかも分かりません。

本稿の地図：三つの設計判断

この二つの問題は、評価の段階で頑張っても解決できません。方式設計の段階で、次の三つの判断として組み込む必要があります。本稿の構成は、この三つの判断にそのまま対応します。

データの流れは次のとおりです。

	設計判断	問い	扱う章
1	役割分担	どの工程をコードに、どの工程をLLMに任せるか	第2章
2	追跡の経路	「どこで壊れたか」を後からたどれる仕組みを、設計段階でどう埋め込むか	第2章・第4章
3	人の位置	人手の確認をどの工程に置き、人には何だけを任せるか	第3章

なお、ナレッジベース構築の難しさには、元ドキュメントの不備や保守体制といった知識そのものの問題（上流）と、質問のされ方や利用者の信頼といった利用の問題（下流）もあります。これらの多くは組織と業務の問題です。本稿が扱うのは、その間にある純粋なエンジニアリングの部分、つまり品質を証明できるか、欠陥の場所を特定できるか、だけです。

筆者の取り組みから得た結論を一つ、先に述べておきます。

生成欠陥の主因は、モデルでもプロンプトでもなく、入力側にあった。

この発見そのものが、「原因を特定できる」設計がもたらした成果です。

2. 設計判断：LLMとコードの役割分担

正解のある工程は、コードに任せる

パイプラインの最初の設計判断は、どの工程を決定論的なコードに任せ、どの工程をLLMに任せるかです。筆者は、次のように分けました。

工程	担当	検証の方法
原稿の解析	コード	原稿との全件照合
セグメント分割	コード	原稿との全件照合
表の構造化抽出	コード	原稿との全件照合
通しIDの付与	コード	一意性の機械チェック
記事への書き直し	LLM	二層の評価基準で全件評価（第3章）

どの工程も、「機械的に検証できる」か「評価でカバーされる」かのどちらかになっています。

分け方の基準は、「どちらがうまくできるか」ではなく、検証できるかどうかです。

構造の抽出には、唯一の正解があります。原稿に表がいくつあり、何行あり、どの数値が書かれているか。抽出した中間データは原稿と一致するか、しないかのどちらかで、全件を機械的に照合できます。このような工程をLLMに任せるのは無駄です。LLMは完全な忠実性を証明できませんが、コードならできます。

逆に、「構造化された内容を、読みやすい一本の記事にする」ことには唯一の正解がありません。ここが、LLMが担うべき場所です。

コードは構造を、LLMは言語を担う。正解のある工程を、確率的なモデルに任せない。

問題がないと証明された工程が、原因特定の起点になる

この分け方の効果は、後の原因特定の段階で現れます。抽出工程をコードで行えば、その工程を全件、機械的に照合できます。

実際の取り組みでは、構造を機械的に解析できる形式の原稿について、中間データと原稿の照合で、数値・表のセル・本文のいずれも差異ゼロを確認しました。画像として埋め込まれた内容を含む形式の原稿では、文字と表がすべて抽出できていることを確認したうえで、画像部分の内容の欠落は一覧にして把握しました。

これが何を意味するか。下流でナレッジベース記事の表が崩れている、数値が消えていると分かったとき、原因は生成工程にしかあり得ません。抽出工程の結果は、照合によってすでに全件把握されているからです。欠陥の場所を特定する消去法は、その第一歩がこれによって成り立ちます。

もし抽出もLLMに任せていたら、上流と下流の欠陥が混ざり、原因特定に手をつけられなくなります。

追跡の経路は、設計段階で埋め込む

二つ目の設計判断は、評価できることを、評価の段階で工夫するのではなく、設計の段階で組み込むことです。

具体的には、各セグメントに通しIDを付与し、中間データから、生成の入力と出力、取り込み後のナレッジベース記事まで、全工程で引き継ぐようにしました（命名は、全体で一意であり、原稿の該当箇所を特定できることさえ満たせばよく、具体的な規則は本稿では扱いません）。

このIDは、生成工程では何の役にも立ちません。LLMには不要で、記事の品質もIDによって変わりません。存在する理由は、後の原因特定だけです。どの記事に問題が見つかっても、IDをたどれば数分で原稿の該当箇所へ戻れます。そして「記事が間違っている」を、「原稿がもともとそうだった」「抽出で形が変わった」「生成で書き換えられた」という、それぞれ検証できる三つの命題に分解できます。

評価の段階になって追跡が必要だと気づいても、その時点でこの経路はすでに途切れていて、後から補うことはできません。

規模のリスクは、生成の前に見積もる

三つ目の判断は、LLM工程の規模の事前見積もりです。セグメント分割の後、各セグメントのトークン規模を見積もり、技術的な閾値を超えるセグメントにフラグを立て、人手での分割対象としました。

この方法は普遍的な原則ではなく、現在の技術水準と実行環境の制約を前提とした対応策です。前提は、LLMを組み込む実行環境には、一回の処理に対する固有の制約があることです。筆者の環境では、一連の処理の時間の上限と、生成呼び出しのトークン規模の上限として現れました。事前見積もりの閾値は、この制約による処理の失敗を防ぐためのものです。これとは別に、入力の規模が大きくなるほどLLMの処理の信頼性が下がるという問題もあり、こちらは閾値を下回る規模でも生じていました（第4章で扱います）。

閾値の具体的な値に共通の答えはなく、利用する実行環境の制約と小規模な試行から決める必要があります。将来、モデルの能力や実行環境の容量が広がれば、この工程は簡略化、あるいは不要になるかもしれません。それでも、「生成が失敗してから対処するのではなく、設計段階で規模のリスクがあるセグメントを見つけておく」という考え方自体は変わりません。

本章の三つの方針は、実は一つの考え方にまとまります。

パイプラインは、結果を出せるだけでなく、自らの結果を説明できなければならない。

各工程は、機械的に検証できるか、追跡の経路でカバーされているかのどちらかである必要があります。これらへの投資は、生成段階では効果が見えず、すべて評価と原因特定の段階で回収されます。

3. 設計判断：評価基準と、人の位置

パイプラインができ、記事が生成されました。次の設計判断は、「うまく生成できている」をどう判定するか、そして人手の確認をどこに置くかです。

筆者は、「うまく生成できている」を、別々に検証できる二つの層に分け、それぞれに評価方法を用意しました。

層	問い	担当
第一層：構造の忠実性	情報が落ちていないか、形が変わっていないか	機械のみ（全件）
第二層：内容の充足性	業務の質問に答えるための要点が、記事に含まれているか	機械は候補の提示まで、最終判定は人

第一の層：構造の忠実性

一つ目の層は、構造の忠実性、つまり情報が落ちていないか、形が変わっていないかです。この層は完全に機械化でき、抜き取りではなく全件で実施します。擬似コードで書けば、次のことをしているだけです。

for 記事 in 全記事:
    入力 = その記事の生成入力（セグメント）
    出力 = 記事本文
    比較する: 表の数（入力 vs 出力）
    比較する: 表の行数の合計（入力 vs 出力）
    比較する: 単位を伴う数値の集合 —— 金額、比率、点数など（入力 vs 出力）
    差分があれば種類別にフラグを立てる（表の消失／行数の減少／数値の消失）

この層を機械化できるのは、第2章の設計によるものです。生成の入力と原稿の差異は、第2章の照合ですでに全件把握されているので、「入力と出力の差分」は純粋に生成時の損失であり、上流で生じた差異と混ざりません。評価基準は単独で設計されたものではなく、パイプラインの構造に依存しています。ここで、二つの章がつながります。

第二の層：内容の充足性

二つ目の層は、内容の充足性、つまり業務上の質問に答えるために必要な要点が、記事に含まれているかです。

構造の忠実性をすべて満たしても、記事が役に立つとは限りません。原稿にもともと書かれていないこともあれば、生成時に重要な情報が見つけられない形へ書き換えられていることもあります。

この層は、業務上の質問を単位として評価します。質問ごとに正解要点（正解回答から切り出した、一つずつ照合できる事実の単位）を用意し、「この要点は、ナレッジベース記事の本文に存在するか」を一つずつ確認します。

正解要点をどこから得るかは、正解データ（ground truth）をどう構築するかという問題です。筆者の取り組みでは、業務部門から提供された正解回答を元に、エンジニアリング側で要点の粒度へ分解しました。分解には裁量の余地があるため、除外ルールを一つ設けました。記号だけで意味を持たない定型の断片は要点とせず、分母に入れません。ただし、具体的な名詞、数字、動作を含む短い要点はすべて残し、判断に迷うものも残します。分母が大きくなっても構わない、難しい問題を除外して結果を良く見せることはしない、という方針です。

ここで、筆者の取り組みで十分にできなかった点を、ありのまま記録しておきます。

評価段階で業務部門の正解回答を受け取ったところ、生成設計時に想定していた「良い記事」との間にずれがあることが分かりました。正解には、業務現場の回答の習慣、つまり何を伝えるべきか、どの粒度で伝えるか、どのような形で伝えるかが反映されていました。しかし、こうした暗黙知は、上流の生成設計（プロンプト設計）の段階では取り入れられていませんでした。

その結果、一部の生成記事は、構造の忠実性の層では完全に合格していながら、内容の充足性の層では業務の要求を満たしていませんでした。

この教訓は一般化できます。

パイプラインの成果物が、特定の業務フローのルール、習慣、ノウハウに合っている必要があるなら、評価基準と目標の定義は、成果物ができてからではなく、上流の設計段階で確定させるべきである。

評価を先に決めると、別の問題も生じます。設計が評価データに過剰適合することです。その場合は、設計に関与していないデータで検証する必要があります。この話題は本稿では扱いません。

人の位置：機械は根拠を並べ、人は判定だけを行う

この層の設計の核心は、機械と人手の境界です。

要点が記事にあるかどうかは、表面的には文字列照合の問題に見えますが、実際にはそうではありません。同じ事実にも、表現の仕方は無数にあります。すべてを人が読むのは、要点ごとに全記事を通読して探すことになり、現実的ではありません。すべてを機械照合に任せると、精度が信頼できません。

筆者の分け方は次のとおりです。機械は検索を担当します。要点ごとにキーワードを抽出し、候補記事にスコアを付けて並べ、最も関連しそうな根拠文を抜き出して判定者の前に提示します。あるかないかの最終判定は、人が根拠文を読んで決めます。機械は人の作業を「全記事の通読」から「数文の候補根拠を読むこと」へと減らしますが、判断の代わりはしません。

人手の判定では自由裁量を防ぐ必要があるため、判定値を三つに絞り、規則を厳しくしました。

記載あり：要点の事実に対応する記述が、記事本文にある
欠落：本文に記述がない
不一致：対象と項目は対応しているが、数値や事実が異なる

このうち不一致には、一つ鉄則があります。どちらが正しいかは判定せず、両方の値を併記して、原典に戻って確認することです。判定の現場で最も起こしやすい誤りは、ついでにどちらが正しいかを「推測」してしまうことです。それは評価と原因特定を一つの手順で行うことであり、結論の証跡が失われます。

最後に、この設計の前提を一つ述べておきます。人手による判定の品質の上限は、判定者の業務習熟度で決まります。

筆者の取り組みでは、正解回答の提供と、業務の観点からの品質判定は、業務側の熟練した担当者が担いました。技術側の要点照合はエンジニアリング側で実施しましたが、その判定基準も、最終的には業務側が示した正解に依拠しています。

つまり、このパイプラインの評価工程は、熟練した業務担当者なしには成り立ちません。これは設計の欠陥ではなく、この種の業務における現時点での現実のボトルネックです。暗黙知は、文書化されるまでは人の中にしか存在しません。評価の仕組みにできるのは、機械による前処理で熟練者が費やす時間を最小限に抑えることであり、熟練者を不要にすることではありません。

再現率やF1の位置づけ

再現率（Recall）やF1のような集計指標について、筆者の立場は「計算はできるが、それは入力ではなく出力である」というものです。

要点ごとの判定が終われば、再現率のような数値は自然に集計でき、上位へ報告できます。しかし評価の仕組みの設計の重心は、スコアの算出ではなく、スコアに算入されるすべての判定をさかのぼれることにあります。どの要点か、どの記事か、どの根拠文か、誰が判定したか、です。

スコアが示すのは差の大きさだけである。差がどこにあるか、受け入れられるか、誰が埋めるべきかを示すのは、さかのぼれる判定である。

目標を高く置く場面では、差を埋めるために、届かなかった要点がどの工程で生じたのかを知る必要があります。誤差を許容する場面では、「残りは受け入れられる」と判断する前提として、残っているのが気づける欠落なのか、気づけない誤りなのかを知る必要があります（次章で扱います）。スコアで方法の有効性を示したいだけの場合でも、個々の判定をさかのぼれなければ、そのスコア自体を検証できません。いずれの場面でも、さかのぼれないスコアは一つの数字にとどまり、さかのぼれる判定は、そのまま次章の原因特定へ渡せます。

4. 評価の後：欠陥の原因特定とフィードバック

評価結果が出ました。一部の記事は構造の忠実性で不合格となり、一部の業務質問では要点が欠落し、質問応答の検証でも誤った回答がいくつかありました。次にすべきことは、急いで直すことではありません。それぞれの欠陥が、パイプラインのどの工程で生じたのかに答えることです。

消去法による原因特定

原因特定の方法は消去法であり、その土台は第2章ですでに用意しています。欠陥は、データの流れのどこかの工程に必ず存在します。追跡IDをたどって任意の工程の中間成果物に戻り、工程ごとに「そこに正しい形で存在するか」を確かめていきます。

全件照合で問題がないと証明された工程は、この判定を経ずに最初から除外できます。

筆者の取り組みでは抽出工程の結果を全件照合で把握していたため、「記事の表が崩れている」という欠陥は、一度で生成工程に特定できました。追跡の経路がないパイプラインでは、この一歩は推測に頼るしかありません。

「見える欠陥」と「見えない欠陥」

原因特定から見えた第一の規則性は、欠陥には「見える」ものと「見えない」ものがあり、本当のリスクは後者にあるということです。筆者の取り組みで特定された生成欠陥には三つの形があり、検出の難しさは順に上がります。

欠陥の形	何が起きるか	読者は気づけるか	誤用のリスク
行欠落	大きな表が生成時に途中で切られ、明細が消える	気づける（情報が「少なくなる」）	低い
行と列の対応ずれ	数値の大半は残るが、行と列の対応関係が誤り、「どの項目がどの値か」が気づかれないまま変わる	気づけない（情報はそろって見える）	高い。そのまま使うと誤った結論に至る
根拠のない補完（ハルシネーション）	実質的な内容が乏しいセグメント（タイトルだけ、「別紙参照」の一文だけ）が、一見完全な内容で補われる	気づけない（手続きの流れ、金額、条件までそろって見える）	最も高い。すべて根拠がなく、一部は業務の実態に反する

評価の仕組みの優先順位は、検出の難しさと一致させるべきである。人の目で見えない欠陥ほど、機械による照合に頼る必要がある。

抜き取りで人が読むだけの評価では、最も危険な後の二つを、まさに見逃してしまいます。

主因はモデルではなく、入力の形にある

原因特定から導かれた中心的な発見は、欠陥の主因がモデルにもプロンプトにもなく、入力の形にあったことです。

不合格の記事を、その入力セグメントと並べて集計すると、問題は二つの極端に集中していました。

入力セグメントの形	生成結果
大きすぎる（複数の表が詰め込まれ、規模が大きい）	行と列が崩れる、情報が圧縮される
規模が適度で、実質的な内容がある	安定して良好
中身が乏しい（タイトルだけで実体がない）	根拠のない補完が起きる

なお、第2章で述べた事前の規模見積もりは、タイムアウトなどの処理の失敗を防ぐための閾値です。品質の劣化は、その閾値を下回る規模のセグメントでも生じていました。

言い換えれば、同じモデル、同じプロンプトでも、健全な形の入力を与えれば成果物は合格します。問題のあるセグメントの原因は、セグメント分割の方法と原稿の形にあり、生成処理そのものにはありません。

この現象の理由について、エンジニアリング側の推測を述べます（モデルの内部から検証することはできないため、理解のための枠組みとしてのみ示します）。

大きすぎるセグメントの失敗は、長い出力全体にわたる一貫性の問題です。表の行と列の対応を保つには、出力が長い範囲で厳密な構造上の制約を守り続ける必要があり、入力が大きいほど維持は失敗しやすくなります。

中身が乏しいセグメントの失敗は、タスク自体の矛盾です。指示は完全な記事を求めているのに、入力にはそれを支える事実がなく、モデルは学習時に見た同種の文章の典型的な内容で空白を埋めます。

この二つは、一つの統計的な見方でまとめて理解できます。よくある入力の形から離れたサンプルほど、生成は目の前の入力に忠実であることをやめ、学習データ上のありがちなパターンに引き戻される。これは特定のモデルの欠陥というより、現在の生成AIの手法と、「あらゆる形の企業文書」という現実の需要との間にある、一般的な矛盾です。だからこそ、入力を「よくある形」に整える前処理が、これほど有効なのです。

単一変数による検証

この発見は、単一変数による検証で確かめました。

崩れが生じたいくつかのセグメントに対して、行ったことは一つだけです。大きすぎるセグメントは表単位で分割し、空のセグメントは本文がある隣接セグメントと統合しました。モデル、プロンプト、パラメータには一切手を加えず、生成し直しました。

その結果、分割後は大きな表の行、列、数値がすべて元のまま保たれ、統合後はハルシネーションが消えて、根拠のある内容が出力されました。

（少数件での検証であり、統計的な保証ではなく、実現可能性の確認です。ただし、「どの方向に投資すべきか」という判断には、これで十分です。）

変えたのは入力だけで、欠陥は消えた。これで因果関係が確かめられた。

フィードバックの方針：欠陥は発生する段階で抑える

ここから導かれたフィードバックの方針は、次のとおりです。

改善への投資は、入力側を優先する。成果物側で欠陥を検出するのではなく、発生する段階で欠陥を抑える。

三種類の原因に対応する前処理は、次のとおりです。

前処理	対象となる入力の形	抑える欠陥
統合	セグメント分割でタイトルと本文が切り離されたもの	根拠のない補完
除外	原稿にもともと実体のないセグメント（生成に投入しない）	根拠のない補完（根本から防ぐ）
分割	大きすぎるセグメント（表単位で規模の閾値内へ）	行と列の崩れ、情報の圧縮

入力側を選ぶ理由は単純です。成果物側でハルシネーションや行と列の対応ずれを検出しようとすると、機械照合で選べるのは候補だけで、確認には人手が必要です。コストは記事数に比例して増え、生成のたびにやり直しになります。一方、入力側の形の診断（セグメントの規模、実質的な内容の密度）は機械的に判定でき、一度処理すれば、以降のすべての生成がその恩恵を受けます。

上記の三種類の前処理は、筆者の取り組みで実際に現れた原因に対応したものであり、一つの事例です。他の場面では別の入力側の問題があり得るため、個別の診断が必要です。本稿ではそこまでは扱いません。

質問応答の誤りは、パイプラインの外を指していた

質問応答の検証で出た誤った回答も、同じように型に分けて原因を特定しました。そしてここでの結論は、パイプラインの外を指していました。これこそが、原因特定の最も重要な成果です。

不合格の質問応答を一問ずつ型に分けると、誤りの原因層は次のように分かれました。そして、少なくない割合がパイプラインの外にありました。

原因の層	どういう誤りか	打ち手	責任を持つ主体
パイプラインの中	生成記事の品質、検索での取得	生成ルール、前処理、検索の設定の調整	エンジニアリングチーム
情報源の欠落（外）	正解要点が原稿にそもそも書かれておらず、知識が業務現場の質疑の経験の中にしかない	原稿を補う、知識の情報源を広げる	業務部門
対象範囲の定義（外）	質問がナレッジベースの設計上の対象範囲を超えている	ナレッジベースが何を対象とすべきかを定義し直す	プロジェクトの層
テストセットの品質（外）	質問自体が短すぎる・曖昧すぎて、人が答えても聞き返しが必要	評価の材料そのものを直す	評価の設計側

この分布は、なぜ重要なのでしょうか。原因層が違えば、改善の手段も、責任を持つ主体もまったく異なるからです。パイプラインの外にある三つの層は、いずれもエンジニアリング側には解決できません。

型に分けた原因特定をしなければ、性質のまったく異なるこれらの誤りは、報告書の上ではすべて同じに見えます。どれも「回答が間違っていた」です。そしてチームは本能的に、手元にある手段を使おうとします。プロンプトを直す、検索パラメータを変える、モデルを替える。パイプラインの外にある原因に対して、これらの調整は原理的に効果を持ち得ません。時間をかけても指標はまったく動かず、最後に「AIは使えない」という誤った結論に至ります。

ここでの原因特定の価値は、一言でまとめられます。

原因特定は、「回答が間違っていた」を、「誰が、どの層で、何をすべきか」に翻訳する。

原因層が確定するまでは、どんな調整も手探りの試行です。確定した後には、エンジニアリングが手を動かす必要すらない問題もあります。それらは、最初からエンジニアリングの問題ではなかったのです。

5. 再利用できる設計原則

最後に、ここまでの内容を、いくつかの原則にまとめます。これらは特定のプラットフォームや特定の文書の種類に依存せず、筆者の取り組みで検証され、別の場面でもおそらく成り立つ部分です。

原則一：正解のある工程を、確率的なモデルに任せない。

唯一の正しい結果があり機械的に検証できる工程は、決定論的なコードに任せて全件照合し、LLMは唯一の正解がない工程にだけ置きます。問題がないと証明された工程は、その後のすべての原因特定の拠り所になります。

原則二：評価できることは、評価段階で補うのではなく、設計段階で組み込む。

通しの追跡ID、工程ごとの中間成果物の保持、入力と出力のペアでの記録は、生成段階では何の役にも立ちませんが、原因特定を支える土台のすべてです。パイプラインは、自らの結果を説明できなければなりません。

原則三：評価基準と、業務が定義する「正解」は、上流でそろえる。

成果物が業務フローのルールや暗黙知に合っている必要があるなら、正解を誰がどの粒度で定義するかを、生成設計の前に確定させます。評価段階になって業務の正解を持ち込んでも、ずれはすでに全記事に行き渡った状態で生成済みです。

原則四：機械と人手の境界は、「根拠」と「判定」である。

機械は根拠を判定者の前に並べることを担い、裁量の余地がある判定は人に任せ、判定の規則は自由裁量のない形に絞ります。熟練した業務担当者を不要にすることはできず、最適化できるのは一回ごとの判断のコストだけです。

原則五：人の目で見えない欠陥ほど、機械による照合に頼る。

行欠落は見えますが、行と列の対応ずれと根拠のない補完は見えません。評価への投資の順位は、発生頻度ではなく、検出の難しさに合わせるべきです。

原則六：欠陥への対処は、入力側を優先する。

原因が入力の形にあるなら、入力を整える（統合、除外、分割）ほうが一度で効果があり、以降のすべての生成が恩恵を受けます。原因がパイプラインの外にあるなら、エンジニアリングの手段では解決できないと認め、問題を正しい責任の層へ返すこと自体が、エンジニアリングチームの最も価値ある成果の一つです。

おわりに

この方法では、最先端の技術は一つも使っていません。決定論的なスクリプト、一件ずつの照合、人が根拠文を読むこと。答えようとしたのは、素朴なエンジニアリングの問いです。

生成工程が確率的であるとき、システム全体の品質を、どうすれば証明でき、特定でき、改善できるものにできるか。

答えも素朴です。確率的な工程を決定論的な工程で包み込み、一つひとつの「間違っている」を、「どこが間違っているか、誰が直すべきか、どう直すか」に翻訳できるようにすることです。

ナレッジベース構築には、知識をどこから得てどう保守するかという上流の難題と、どう使いこなすかという下流の難題もあります。本稿が扱ったのはその間のエンジニアリングの部分だけですが、上流と下流の議論を事実に基づいて行えるようにするのは、この部分です。