なぜSEPTが必要なのか
SEPTは、長年にわたるデータの検証、修正、統合、システム移行などの実務経験から生まれた設計原則です。長期間運用されるシステムでは、度重なる修正や移行によって、データの意味や変更の経緯が分からなくなることがあります。また、異なる情報源のデータを統合する際にも、元の分類や意味が失われる場合があります。
生成AIは大量の情報から回答を生成できるようになりました。しかし、LLMの回答をすべて保存することが、適切な知識管理につながるとは限りません。
重要なのは、元データとの関係を維持しながら、必要な情報を抽出・整理し、人間が理解・検証でき、AIも利用できる知識へと抽象化・汎化することです。
例えば、複数の事例から共通する規則を見つけても、新しい事例によって例外が見つかるかもしれません。その際には、条件の追加や仮説の修正が必要になります。
知識は完成したものとして保存するのではなく、新しい問いや証拠に応じて発展させられる状態で保持することが重要です。
SEPTとは
SEPTは、知識の作成、抽象化・汎化、統合、更新、共有、再利用の各段階において、知識の意味や根拠を失わないために考慮すべき4つの設計原則です。また、形成された知識や知識システムを評価するための観点としても利用できます。
| 原則 | 確認すること |
|---|---|
| 共有(Shared) | 他者が知識の意味を理解し、継承・再利用できるか? |
| 進化(Evolving) | 新しい証拠によって知識を追加・修正できるか? |
| 多元性(Plural) | 異なる情報や解釈を無理に統合していないか? |
| 追跡(Traceable) | 元データや判断の根拠を確認できるか? |
多元性(Plural)— 違いの意味を失わない
SEPTの中でも、特に重視するのがPluralです。
例えば、COVID-19のオープンデータでは、都道府県によって年代の分類が異なっていました。「10歳未満」と「未就学児」は同じ意味ではありません。また、「90代以上」と、「90代」「100歳以上」に分ける分類では、情報の粒度が異なります。
これらを無条件に同じ形式へ変換すると、元の情報が持つ意味を失う可能性があります。分類の定義が整合していれば、細かい区分をまとめることはできます。しかし、元データにない細分化を根拠なく行うことはできません。
歴史研究でも、同じ史料から異なる解釈が生まれることがあります。複数の解釈を必ず一つに統合する必要はありません。ただし、Pluralはすべての主張を同じ程度に正しいと認めるものではありません。
Pluralは、異なる情報や解釈の違いを保持し、必要に応じて比較・評価できるようにする原則です。
知識を作る段階から意識する
SEPTは、完成した知識の評価だけに使うチェックリストではありません。文書からの情報抽出、知識の汎化、データ統合、判断の記録など、知識を作成する最初の段階から利用できます。
最初から完全な知識体系を構築する必要はありません。現在の問いに必要な知識から始め、実際に利用・検証し、新しい問いや証拠に応じて追加・修正します。
問いの設定 → 必要最小限の知識の形成 → 適用・検証 → 不足点の特定 → 拡張・汎化
これは知識形成の実践的な進め方の一例であり、SEPTが定める必須の手順ではありません。また、必要最小限の知識とは、元データを最小限にすることではありません。元データや根拠を適切に保持する必要があります。
SEPTと技術の関係
SEPTは特定のAIやデータベースに依存しません。知識、情報源、解釈、変更、判断などを関係付けて表現するうえで、グラフデータモデルは親和性の高い方法の一つです。
また、Gitの考え方を参考に知識の変更履歴や差分、異なる解釈を管理する Knowledge Versioning(知識のバージョン管理) や、Knowledge Graph Diff といったアプローチにもつながります。ただし、これらはSEPTそのものではなく、実現方法の候補です。
目指すもの
SEPTが目指すのは、すべての情報を保存することでも、最初から完全な知識体系を作ることでもありません。
現在必要な知識から始め、その意味、異なる解釈、変化、根拠を維持しながら、人間が理解・検証でき、AIも利用できる形で継続的に発展させることです。
定義や適用範囲、評価の詳しい説明は、SEPT基本定義書をご覧ください。