SEPT Principles — 基本定義書

Shared / Evolving / Plural / Traceable

Koji Annoura（案浦浩二）

1. はじめに — 知識を単純化することと、意味を失うことは違う

生成AIの発展によって、大量の情報から回答を生成し、複雑な問題を分析することが容易になった。しかし、LLMが生成した回答をすべて保存するだけで、知識を適切に管理できるとは限らない。

重要なのは、元となるデータを適切に保持したうえで、必要な情報を抽出し、整理し、関係付け、人間が理解・検証でき、AIも利用できる知識へと抽象化・汎化することである。

例えば、多くの事例から共通する条件や関係を見つけ、一つの規則や仮説として表現できる。複雑な判断であっても、その基礎に比較的単純な原則や条件、関係が存在する場合がある。

しかし、抽象化・汎化・統合によって、元の情報の重要な条件、例外、異なる解釈が失われることがある。分かりやすい説明が、必ずしも元の判断過程を正確に表しているとも限らない。

知識を単純化することと、知識の意味を失うことは同じではない。

必要な知識を簡潔に表現しながら、適用条件や元データ、異なる解釈との関係を確認できることが重要である。

知識は完成品ではない

物理学では観測から規則性を見いだし、その適用範囲を検証する。数学では個別の問題から一般的な構造を見いだすことがある。ただし、経験的な規則性と数学的な証明は異なり、条件を追加しただけで仮説が正しくなるわけではない。

新しい証拠が既存の規則と合わなければ、仮説や適用条件を見直し、再検証する必要がある。その際、以前の知識を単に上書きするのではなく、元データや根拠を確認できることが重要である。

知識は完成したものとして保存するのではなく、新しい証拠によって条件を追加し、修正し、再び汎化できる状態で保持する。

SEPTは、知識の作成段階から意味や根拠の扱いを考えるための設計原則である。

SEPTの着想の背景

SEPTは、著者が長年にわたりデータの収集、検証、変換、統合、モデリングに携わる中で直面した問題から生まれた設計原則である。

長期間運用される業務システムでは、不具合への暫定対応やデータの直接修正、業務ルールの変更などが積み重なる。その結果、現在の仕様やデータモデルだけでは説明できない値や不整合が残ることがある。

また、新システムへのデータ移行が一度で終わるとは限らない。複数回の移行を経て、過去の例外的なデータや不整合が引き継がれ、元の値の意味や修正の経緯が分からなくなる場合もある。

異なる情報源を統合する際にも、同じ項目名であっても定義や分類基準が異なることがある。COVID-19の公開データの統合作業では、都道府県ごとの年代区分の違いや、一次データ自体の誤りに直面した。

こうした経験から、現在のデータだけでなく、その意味、成立過程、変更の経緯、異なる定義との関係を維持することの重要性を認識した。

SEPTは、特定の既存理論やフレームワークを着想源として考案したものではない。実務経験から生まれた問題意識を、知識の設計原則として整理したものである。関連する研究や技術との共通点は存在するが、それらは着想源と同一ではない。

2. SEPTの基本定義

2.1 SEPTとは何か

原則	名称	中心となる問い
S	共有（Shared）	他者が知識を理解し、継承・再利用できるか？
E	進化（Evolving）	新しい情報に応じて変更・発展させられるか？
P	多元性（Plural）	異なる情報や解釈の意味を失わずに扱えるか？
T	追跡（Traceable）	根拠や成立・利用過程を追跡できるか？

SEPTは、知識の作成、抽象化・汎化、統合、更新、共有、再利用の各段階において、知識の意味や根拠を失わないために考慮すべき4つの設計原則である。また、形成された知識や知識システムを評価するための観点としても利用できる。

SEPTには、知識を扱う際の設計指針と、形成された知識・知識システムの評価観点という2つの用途がある。

SEPTは特定のAI、データベース、データモデル、通信プロトコル、業務フレームワークを規定しない。知識の正しさを保証するものでも、最適な知識形成アルゴリズムでもない。

2.2 SEPTが対象とする知識

SEPTは知識について唯一の哲学的定義を与えるものではない。人間やシステムが理解、評価、共有、再利用する対象として、観測や記録から形成された主張、解釈、仮説、規則、判断などを扱う。

概念	内容
Source Data	観測、文書、実験結果などの元データ
Claim	対象について述べられた主張
Interpretation	特定の文脈や視点から情報に与えられた意味や説明
Hypothesis	観測や証拠に基づく仮説
Generalized Knowledge	事例から抽象化・汎化された規則や関係
Decision	情報や評価に基づく判断
Evidence	主張や判断を支持または否定する根拠

「資料XにAと記録されている」という記録上の事実と、「Aが事実である」という主張は異なる。「ある条件で方法Yが有効だった」という観測と、「その条件では一般に方法Yが有効である」という汎化も異なる。後者には追加の検証が必要である。

2.3 Knowledge Sustainability — 知識の持続性

SEPTでは、時間の経過や人間・組織・技術の変化があっても、必要な知識の意味、適用条件、異なる解釈、根拠、変化を理解・検証し、再利用できる性質を Knowledge Sustainability（知識の持続性） と呼ぶ。

単に情報が保存されていることとは異なる。過去の設計図が残っていても、設計の目的や制約が分からなければ、適切に変更することは困難である。

SEPTは知識を作る段階から4原則を意識することで、その持続性を支えることを目指す。ただし4原則だけで持続性が保証されるわけではない。

3. SEPTの4原則

3.1 共有（Shared） — 知識を共有し、継承できること

Sharedとは、知識を特定の個人やシステムに閉じ込めず、想定する利用者がその意味や文脈を理解し、継承・再利用できる状態にする原則である。

情報を渡すことと知識を共有することは異なる。熟練した技術者の判断基準が本人の経験の中にしかなければ、他者が同じ判断を行うことは困難である。設計図が残っていても、目的や制約が不明なら将来の変更は困難になる。

文書、図、データ、モデル、教育、実演、共同作業などを通じ、知識の意味や必要な文脈を伝えることが重要である。

人間が理解できる知識への汎化

AIは大量の情報を処理できるが、その結果がAIの内部でしか扱えなければ、人間が理解・継承することは困難である。複雑な判断の主要な概念、条件、関係を抽出し、人間が理解できる形に整理することは共有に役立つ。

ただし、すべての判断を単純な規則で説明できるわけではなく、理解しやすい説明が実際の判断根拠を忠実に表すとも限らない。

Sharedで重視するのは、想定する利用者が意味や条件を理解し、検証・再利用できることである。人間の理解とAIによる情報処理は同一ではない。また、機密性やアクセス権限を維持した適切な共有も含まれる。

設計時には、誰が、何のために、どのように知識を理解・利用するかを考慮する。

3.2 進化（Evolving） — 知識の変化と発展を保持できること

Evolvingとは、現実の状態、記録、知識や解釈の変化を区別し、その変遷を理解できるようにする原則である。

変化	例
現実の変化	組織構成やシステム状態の変更
記録の訂正	入力ミスの修正
情報の追加	新しい観測結果や史料の発見
解釈の変化	歴史学説の見直し
仮説の修正	反例による適用条件の変更
判断の変化	市場環境に応じた事業戦略の変更

新しい史料によって歴史の解釈が変わっても、過去の出来事自体が変化したわけではない。

COVID-19の公開データを確認する過程では、一次データそのものに誤りが見つかることもあった。これらの誤りについては、該当する都道府県に報告し、訂正を依頼した。これは現実の出来事の変化ではなく、記録の訂正に関する問題である。訂正が行われた場合には、訂正前後の内容と訂正理由を区別して扱う必要がある。

例えば「条件Aでは方法Xが有効」という仮説が反例に遭遇した場合、条件Bが必要な可能性がある。しかし「AかつBなら有効」と修正しても、新しい仮説の検証が必要である。

重要なのは以前の仮説を消すことではなく、どのように形成され、なぜ見直されたかを理解できることである。Evolvingは変更の周期を規定しない。

設計時には、将来の追加・訂正・再評価・再汎化を前提とする。

3.3 多元性（Plural） — 異なる意味や解釈を共存させること

Pluralとは、同一の対象や出来事について存在する異なる記録、分類、観測、主張、視点、解釈を、それぞれの意味や文脈とともに区別して保持し、必ずしも一つの結論への統合を要求しない原則である。

Pluralは、SEPTの中でも特に重視する特徴である。異なる情報は同じ意味を持つとは限らず、同じ事実から複数の解釈が導かれることもある。

異なる分類と粒度

Pluralの問題意識の出発点の一つは、COVID-19オープンデータの整理・統合である。当時、都道府県によって項目や分類が異なっていた。

「10歳未満」は年齢による分類であるが、「未就学児」は就学状況による分類である。両者は同一ではない。

また、「90代以上」としてまとめたデータと、「90代」「100歳以上」に分けたデータでは粒度が異なる。「90代以上」は100歳以上を含む。分類の定義が整合していれば、細かい区分をまとめることはできる。しかし、元データにない情報を根拠なく細分化することはできない。

共通形式への変換では、元の分類と変換規則を保持しなければ、意味や情報の粒度を失う可能性がある。

異なる解釈

歴史研究では同じ史料から複数の解釈が生まれる。ある改革について経済発展を重視する評価と、格差拡大を重視する評価は、異なる側面を論じている可能性がある。

企業でも同じ市場データから投資すべきという判断と、見送るべきという判断が生まれる。将来予測、リスク許容度、目的、価値観が異なるためである。採用されなかった意見も将来の再評価に役立ち得る。

違いを保持することと正しさの評価

異なる情報や解釈を、同一であると確認する前に統合しないことが重要である。元の主張、意味、条件、文脈、他との関係、未解決の違いを必要に応じて保持する。

ただしPluralは、すべての主張を同じ程度に正しいと認める原則ではない。誤った記録は訂正し、証拠によって否定された仮説と支持されている仮説は区別する。評価した結果だけを残し、異なる解釈が存在した事実を不用意に消すべきではない。

設計時には、違いを消すのではなく、その意味を保持して比較・評価できるようにする。

3.4 追跡（Traceable） — 知識の根拠と成立・利用過程を追跡できること

Traceableとは、知識の情報源、証拠、生成・変換・評価・判断の過程、および利用先との関係を追跡できるようにする原則である。

統計値があっても、元データ、集計期間、計算方法が分からなければ、その意味を正確に判断できない。一次資料や変換処理を参照できれば、集計結果がどの記録から導かれたかを検証できる。

知識の形成過程も同様である。一般化した規則がどの観測に基づくのかを追跡できれば、新しい反例に応じて再検証できる。

企業の意思決定は、例えば次のような過程で表現できる。

観測 → 仮説 → 意思決定 → 実行 → 結果 → 評価

結果だけでなく、当時何を観測し、何を予測し、どの代替案を検討して判断したかを理解できることが重要である。成功した結果と、適切な判断過程は同じではない。

Traceableは知識の正しさを保証しない。設計時には、情報源、変換、判断理由、利用先の関係を、後から検証できるようにする。

4. 知識の各段階におけるSEPTの適用

SEPTは完成後の評価だけでなく、作成から再利用までの設計指針である。

段階	SEPTを意識した判断
作成	何を知識として表現し、元データとどう関連付けるか
抽象化・汎化	どの条件を残し、何を統合できるか
統合	同じ意味と異なる意味をどう区別するか
更新	以前と現在の知識の違いをどう管理するか
共有	誰が、何を理解・利用する必要があるか
再利用	適用条件や根拠をどう確認するか

段階は固定された順序ではなく、繰り返したり同時に進んだりする。

必要な知識から始める

最初から完全なオントロジーや知識体系を構築する必要はない。現在の問いに必要な知識から始め、利用・検証し、新しい問いに応じて追加・修正する方法を重視する。

問いの設定 → 必要最小限の知識の形成 → 適用・検証 → 不足点の特定 → 拡張・汎化

これは反復的な知識形成の一例であり、SEPTが規定する必須の手順ではない。

必要最小限の知識と元データの違い

現在の問いに必要な知識だけを構築することは、その根拠となる元データを削除することではない。例えば、複数の障害報告から共通する故障条件を抽出する場合でも、個々の報告にある発生状況や例外を参照できるようにしておく。後に別の条件が重要と判明した際、元の記録に戻って仮説を見直せるためである。

4原則の相互関係

異なる意味や解釈を保持するのはPlural、それらの根拠を確認するのはTraceableである。知識の変遷を理解するにはEvolvingが関わる。情報源が明らかでも利用者が理解できなければSharedは不十分である。

4原則は完全に独立した機能ではなく、関連しながら異なる設計観点を提供する。

5. 既存研究と実装技術との関係

SEPTの要素はすべてが新発明というわけではない。FAIR Principlesは情報の再利用、W3C PROVは来歴、Version ControlやTemporal Databasesは変更、Semantic Heterogeneityは意味の違い、Knowledge Representationは主張や関係の表現などを扱う。

SEPTはこれらに代わるものではなく、知識の作成・汎化・統合・更新・共有・再利用を通じて、意味、異なる解釈、変更の経緯、根拠を一貫して考慮する提案である。

グラフデータモデル

SEPTは技術に依存しない。リレーショナルデータベースや文書システムでも実現できる。一方、知識、情報源、解釈、時間、判断を関係付けて表すには、グラフデータモデルは親和性の高い選択肢の一つである。

Property GraphやRDFなど、さまざまな技術が考えられるが、グラフデータベースを使うだけでSEPTが実現するわけではない。重要なのはデータモデリングである。

Knowledge Versioning

Knowledge Versioning（知識のバージョン管理） は、知識の変更履歴、差分、異なる解釈、修正を管理する構想である。Gitのバージョン管理の考え方を参考にしているが、Gitそのものを利用する製品や仕組みを意味しない。知識では異なる解釈が必ずしも競合せず、一つに統合する必要がない場合がある。また、意味や根拠の変化は単純なテキスト差分とは異なる。

Knowledge Versioning と Knowledge Graph Diff はSEPTを実現するためのアプローチの候補であり、必須の技術ではない。

6. SEPTの評価

SEPTは知識の表現と管理の状態、そして知識を扱う仕組みの評価に利用できる。ここでは人、組織、業務、文書、データ、ソフトウェアなどから構成される仕組みを Knowledge System と呼ぶ。

評価する際は対象知識、目的、利用者、期間、システムの境界を明確にする。

原則	評価観点
Shared	想定する利用者が意味や条件を理解し、再利用できるか
Evolving	変更内容や理由を確認し、追加・修正できるか
Plural	異なる分類・主張・解釈を意味を失わず保持・比較できるか
Traceable	元データ、根拠、変換・判断過程を追跡できるか

これらは完成したシステムだけでなく、個別の知識表現や作成・変換過程にも適用できる。ただし知識の正確性や有用性の評価に代わるものではない。

評価例：一次データの訂正と影響調査

COVID-19の公開データのように、一次データの誤りが後から判明する場合を考える。訂正された記録がすでに集計や分析に使用されていれば、元の記録を単に上書きするだけでは、訂正前の結果を検証したり、影響する分析を特定したりすることが難しくなる。

この事例では、特にEvolvingとTraceableが重要となる。訂正前後の記録と変更理由を確認できるか（Evolving）、訂正が影響する集計や判断を追跡できるか（Traceable）を評価する。訂正の内容を利用者が理解できるようにする点では、Sharedも関係する。

重要なのは「SEPTを採用した」と名付けることではなく、必要な意味や根拠を保持するために実際にどう設計したかである。

7. 適用範囲と限界

SEPTは、人間の知識継承、科学・歴史研究、企業の意思決定、データ統合、ソフトウェア設計、AIシステムなどに適用を検討できる。

ただし次のものを規定・保証しない。

知識の抽出・汎化アルゴリズムや最適な戦略の発見
知識の正しさ、完全性、適用条件の自動検証
完全なオントロジーやデータモデルの構築手順
Scrumなどの開発フレームワークや、具体的な業務プロセス
特定のAIやデータベースの実装方式
すべての情報の永久保存
4原則だけによるKnowledge Sustainabilityの保証

複雑な知識が常に単純な規則に還元できるとは限らない。保存、アクセス制御、機密性、完全性、法的な保存・削除義務、運用なども別途必要である。

また、4原則がKnowledge Sustainabilityの必要条件または十分条件であることは、現時点では確立されていない。具体的な事例で有効性と限界を検証する必要がある。

おわりに — 知識を作るときからSEPTを意識する

最初から完全な知識体系を作るのではなく、現在の問いに必要な知識から始め、新しい問いや証拠に応じて追加・修正・再汎化する。その過程では、元の意味、異なる解釈、変更の経緯、根拠を保持することが重要である。

AIの複雑な分析結果をAIの内部だけに閉じ込めず、必要な概念、条件、関係を人間が理解・検証できる形で表現し、将来へ引き継ぐことが重要である。

SEPTは、知識の作成から再利用までの各段階で、何を保持し、何を区別し、何を検証可能にすべきかを考えるための設計原則である。同時に、形成された知識や知識システムを評価する観点でもある。