― Impact DBという考え方
AIシステムを設計していると、ある問題に何度も出会います。
それは、
「まだ分からない情報を、どうデータベースに保存するのか？」
という問題です。
一般的なデータベースは、「確定した情報」を扱うことが得意です。
例えば、
user_id = 1024
name = "Taro"
age = 42
のようなデータです。
名前が分かっている。
年齢が分かっている。
IDも分かっている。
非常に扱いやすい世界です。
ところが、現実世界の情報はそんなに綺麗ではありません。
Aかもしれない
Bの可能性もある
現時点では判断できない
情報が不足している
観測したが意味が分からない
過去にはAだった
今はAかどうか不明
誰かがAと言っている
AとBで意見が分かれている
といった情報が大量に存在します。
人間は、こうした曖昧さをある程度そのまま保持できます。
しかしコンピュータシステムでは、どうしても、
TRUE / FALSE
1 / 0
A / B
Confirmed / Not Confirmed
のように、どこかで確定させたくなります。
AIシステムになると、この問題はさらに大きくなります。
LLMは文章を理解し、推論し、候補を出し、要約します。
その結果、AIは非常に簡単に、
「推測」を「事実らしい文章」に変換してしまう
ことがあります。
そこで私たちは、VERTEXの設計の中で一つの考え方を導入しました。
それが、
Impact DB
です。
1. 「分からない」を失わない
Impact DBの一番重要な考え方は、非常に単純です。
分からないものを、無理に確定しない。
これだけです。
ただし、単純だからこそ難しい。
通常のシステムでは、
Input
↓
Interpretation
↓
Decision
↓
Database
という流れになりがちです。
例えばAIが、
「この情報はAである可能性が高い」
と判断したとします。
これをそのままデータベースへ保存すると、
result = A
になってしまうかもしれません。
しかし、本来の情報は、
候補：A
確信度：高い
確定：していない
です。
この3つは同じではありません。
2. 「推定」と「確定」は別物
これはAIシステムを設計する上で非常に重要です。
例えば、
「明日の天気は雨になりそうです」
という文章があります。
これは、
雨 = TRUE
ではありません。
「雨」という候補があり、
可能性がある
↓
予測されている
↓
確率が高い
という段階にあるだけです。
ところがデータベースへ入れるとき、
weather = "rain"
と入れてしまうと、後から見た人には「雨だった」という事実に見える可能性があります。
ここで失われたものがあります。
それは、
不確実性
です。
Impact DBは、この不確実性を消さないためのデータ層です。
3. 現実世界は「確定データ」だけでできていない
データベースは、確定した情報を整理するために非常に強力です。
例えば、
馬
馬主
調教師
牧場
診療
薬品
請求
などの情報は、かなり明確に構造化できます。
これはRDBが得意な領域です。
しかし現場では、
歩様が少しおかしい
いつもと何か違う
右前が気になる
昨日より動きが悪いように見える
疲れているように感じる
たぶん痛みがある
という情報が先に存在します。
これは「病名」ではありません。
「診断」でもありません。
しかし、重要な情報です。
普通のRDBに入れようとすると、
disease = ?
という問題が発生します。
何を入れればいいのか分からない。
そこで無理に、
disease = "lameness"
などと入れた瞬間、
観測情報が診断情報へ変換されてしまいます。
これは危険です。
4. Impact DBは「診断データベース」ではない
ここを明確にしておきます。
Impact DBは、
病名を保存するためのDB
ではありません。
また、
AIの推測結果を確定保存するDB
でもありません。
Impact DBが扱いたいのは、
「何かが起きている。しかし、その意味や原因や結果がまだ確定していない」
という状態です。
例えば、
Observation
↓
「右前の動きに違和感」
この時点では、
病気 = ?
原因 = ?
重症度 = ?
は未確定です。
しかし、
何かがおかしい
という観測そのものには価値があります。
Impact DBは、このような情報を捨てません。
5. 「意味」ではなく「影響」を保存する
Impact DBという名前には理由があります。
単純に「Uncertain DB」とすると、
「曖昧な情報を保存するだけのDB」
に見えてしまいます。
しかし、私たちが考えているのはもう少し違います。
重要なのは、
その曖昧な情報が、何に影響する可能性があるのか
です。
例えば、
「右前の動きに違和感がある」
という情報を考えてみます。
現時点では診断できなくても、
運動
↓
歩様
↓
脚部状態
↓
競走能力
↓
出走判断
などに影響する可能性があります。
この「可能性」を保持しておく。
つまり、
Observed
↓
Potential Impact
↓
Candidate
という構造です。
6. Impact DBの基本モデル
現時点で私たちが考えている概念モデルは、例えばこのようなものです。
Observation
│
├── Source
├── Timestamp
├── Context
│
▼
Uncertainty
│
├── Confidence
├── Candidate
├── Alternative
│
▼
Impact
│
├── Target
├── Severity
├── Scope
└── Relevance
│
▼
Evidence
│
└── Later Observation
│
▼
Confirmation
重要なのは、最後まで到達しないデータが普通に存在してよいことです。
つまり、
Observation
↓
Uncertainty
↓
Impact
で止まっても構わない。
後から新しい証拠が入ったら、
Evidence
↓
Confirmation
へ進む。
7. 「候補」を持つ
曖昧な情報を扱う場合、
A
B
C
のどれか一つを選ばなければならない、という設計は危険です。
例えば、
A = 70%
B = 25%
C = 5%
という推定結果があるなら、
result = A
とするより、
candidate:
A: 0.70
B: 0.25
C: 0.05
confirmed: false
という形で保持した方が情報量が多い。
当然、ここでいう確率は、システムが正しく較正された確率として扱えるとは限りません。
ですから、
confidenceという数値そのものを真実とみなすのではなく、「現在の推定状態」を表現するメタデータとして扱う
必要があります。
8. AIに「分からない」と言わせるだけでは不十分
AIシステムを作ると、
「分かりません」
と言わせれば良いと思ってしまうことがあります。
しかし、それでは不十分です。
例えばAIが、
「Aの可能性がありますが、確証はありません」
と言ったとします。
この文章をそのまま破棄したら、せっかく得られた情報を失います。
必要なのは、
可能性：A
確証：なし
根拠：X
観測時刻：Y
追加確認：Z
という構造化です。
つまり、
「分からない」を回答として終わらせるのではなく、「分からない」という状態をデータとして保存する
必要があります。
ここがImpact DBの重要なところです。
9. RDBとの違い
Impact DBを理解するには、RDBとの違いを見るのが分かりやすいです。
RDBは、
確定した事実を、整合性を保ちながら管理する
のが得意です。
例えば、
HorseID
OwnerID
TrainerID
BirthDate
Sex
などです。
一方、Impact DBでは、
Observation
Hypothesis
Candidate
Uncertainty
Potential Impact
Pending Evidence
などを扱います。
概念的には、
VERTEX DATA SPACE
┌─────────────────────────────┐
│ Impact DB │
│ │
│ uncertain / candidate │
│ observation / hypothesis │
│ potential impact │
└──────────────┬──────────────┘
│
evidence / confirmation
│
▼
┌─────────────────────────────┐
│ RDB │
│ │
│ confirmed / structured │
│ deterministic data │
└─────────────────────────────┘
となります。
つまり、
Impact DBからRDBへ移ることは、「データを保存する」ことではなく、「状態が確定した」ことを意味する
わけです。
10. データを削除するのではなく、状態を変える
通常、曖昧なデータが確定したら、
temporary_data
を捨てて、
confirmed_data
へ移す設計が考えられます。
しかしImpact DBでは、
元の曖昧な状態も重要な履歴として保持する
という考え方を取れます。
例えば、
Day 1
「右前に違和感」
↓
Day 2
「右前跛行の疑い」
↓
Day 3
画像診断
↓
Day 4
確定診断
となった場合、
最終的な確定診断だけを残してしまうと、
「どうしてその結論に至ったのか」
が分からなくなります。
Impact DBが残っていれば、
Observation
↓
Hypothesis
↓
Evidence
↓
Confirmation
という経路を追えます。
これはAIシステムにとって非常に重要な特徴です。
11. 「最初の間違い」が分かる
この設計にすると、もう一つ面白いことができます。
それは、
どこで判断がずれたのか
を追跡できることです。
例えば、
Observation
↓
Aという仮説
↓
AIがAと解釈
↓
Databaseへ確定保存
となっていた場合、最初に問題が起きたのはどこでしょうか。
AIが悪いのか。
入力が悪いのか。
解釈が悪いのか。
データモデルが悪いのか。
保存時の変換が悪いのか。
Impact DBを導入すると、
Observation
↓
Uncertain State
↓
Inference
↓
Evidence
↓
Confirmation
と境界を分離できるため、
最初に確定状態と現実が食い違った場所
を探しやすくなります。
これはAI監査にもつながります。
12. 「可能性」を消さないことの意味
従来のシステムでは、
Aなのか？
という問いに対して、
Yes / No
を返すことが重要でした。
しかしAIが扱う世界では、
A
B
A+B
不明
データ不足
観測矛盾
など、多数の状態があります。
さらに時間によって変わります。
t1: Aの可能性が高い
t2: Bの可能性も出てきた
t3: Aを支持する証拠
t4: A確定
この変化そのものが情報です。
つまり、
結果だけでなく、結果が変化する過程をデータとして扱う
という考え方が必要になります。
13. Impact DBとAIの相性
AIは確率的・推論的な処理を得意とします。
その一方で、データベースは確定性・整合性・検索性を得意とします。
この二つを無理に一つにすると問題が起きます。
AI:
「おそらくA」
Database:
A
この瞬間に、
「おそらく」
が消えます。
そこで、
AI
↓
Impact DB
↓
Evidence
↓
RDB
と分ける。
するとAIの性質を無理にRDBへ押し込まなくて済みます。
14. AIの「幻覚」だけを問題にする必要はない
AIの問題として「ハルシネーション」がよく語られます。
もちろん重要です。
しかしImpact DBの考え方では、問題を少し違う角度から見ます。
例えばAIが、
Aだと思う
と推測したこと自体が問題なのではなく、
その推測が、確定情報として保存されてしまうこと
が問題になる場合があります。
つまり、
Inference
そのものを禁止する必要はありません。
AIは推測してよい。
仮説を作ってよい。
候補を出してよい。
重要なのは、
推測が推測であることを保持したまま次の処理へ渡すこと
です。
この考え方は、Impact DBの核心です。
15. Evidenceによって確定する
では、いつRDBへ移すのでしょうか。
一つの答えが、
Evidence
です。
例えば、
Observation
があり、
Candidate A
があり、
その後、
Evidence X
が得られたとします。
そこで、
Candidate A
+
Evidence X
↓
Confirmed A
となる。
つまり、
確定とは、時間が経過したから発生するものではなく、十分な証拠によって状態が変化した結果
と考えます。
16. Evidenceは「証拠」だけではない
ここも面白いポイントです。
Evidenceは単に、
file
image
test result
だけではありません。
例えば、
別の観測
人間による確認
別Agentによる検証
センサーデータ
診療記録
実行結果
テスト結果
などもEvidenceになりえます。
つまり、
Impact DB
↓
Evidence
という一方向だけではなく、
Evidence
↓
Impact DB
という循環も考えられます。
新しい証拠によって過去の仮説が、
strengthened
weakened
rejected
confirmed
される。
これは通常のRDBだけでは扱いにくい世界です。
17. 仮説が否定されても無駄ではない
例えば、
Candidate A
が後から否定されたとします。
普通なら、
DELETE A
したくなります。
しかしImpact DBでは、むしろ保存しておく意味があります。
なぜなら、
Aが候補だったこと自体が、過去の情報だからです。
例えば、
A candidate
↓
Evidence X
↓
A rejected
↓
B strengthened
という経路が残っていれば、
「当時なぜAが候補になったのか？」
を後から解析できます。
AIの判断改善にも使えます。
18. Human Gateとの関係
VERTEXでは、AIにすべての確定権限を与えることを前提としていません。
そのためImpact DBは、Human Gateとも相性が良い。
例えば、
AI
↓
Candidate
↓
Impact DB
↓
Human Review
↓
Human Gate
↓
Confirmed
とできます。
これなら、
AIは十分に自由に推論できます。
しかし、
確定という不可逆性の高い操作だけは別の境界で制御する
ことができます。
これは単なる安全装置ではありません。
AIと人間で、
「推測してよい領域」
と
「確定してよい領域」
を分離する設計です。
19. Impact DBは「ゴミ箱」ではない
曖昧情報を保存すると、
「何でもImpact DBに入れたら、ゴミ箱になるのでは？」
という疑問が出てきます。
これは重要な懸念です。
だからこそ、Impact DBには、
source
timestamp
context
confidence
candidate
impact
status
evidence
expiry
などのメタ情報が必要になります。
単に、
unknown = true
を保存するだけでは意味がありません。
重要なのは、
なぜ不明なのか
です。
20. 「不明」には種類がある
例えば、
unknown
という一言でも、実際には全然違います。
Type A: 情報不足
必要なデータがない。
Type B: 観測矛盾
複数の情報が一致しない。
Type C: 推論不足
候補はあるが判断できない。
Type D: 将来確定
時間が経てば分かる可能性がある。
Type E: 本質的不確実性
原理的に確定できない。
これらはすべて同じ「不明」ではありません。
Impact DBでは、この違いを保持する価値があります。
21. 時間を重要な属性として扱う
曖昧性は時間で変化します。
例えば、
t1
Aの可能性あり
t2
AよりBの可能性が高い
t3
Aを支持するEvidence
t4
A確定
となります。
つまり、
情報の状態は静的ではない
のです。
そのためImpact DBでは、
observation_time
created_at
updated_at
evidence_time
resolution_time
など、時間情報を重要視する必要があります。
ここから先は、VXN-DBのような時間・空間を扱うデータモデルとの接続も見えてきます。
22. Impact DBとVXN-DB
VERTEXでは、
Impact DB
RDB
VXN-DB
をそれぞれ別の役割として考えています。
概念的には、
VERTEX DATA ARCHITECTURE
┌───────────┐
│ Impact DB │
│ uncertain │
│ candidate │
│ hypothesis│
└─────┬─────┘
│
Evidence
│
▼
┌───────────┐
│ RDB │
│ confirmed │
│ structured│
└─────┬─────┘
│
spatial / temporal
│
▼
┌───────────┐
│ VXN-DB │
│ space/time│
│ relations │
└───────────┘
もちろん、これは今後変化する可能性があります。
しかし重要なのは、
すべての情報を一つのDBモデルへ押し込めない
という思想です。
23. RDBに向いていないから別DBにする、という話ではない
ここも誤解されやすいところです。
Impact DBは、
「RDBでは曖昧情報を保存できないから作る」
というだけの話ではありません。
RDBでも、
nullable
status
confidence
candidate
などを持たせることはできます。
技術的には可能です。
問題は、
データモデルの中心思想
です。
「確定データを中心に設計したRDBへ、曖昧な状態を例外として追加する」
のと、
「曖昧性を第一級データとして扱う」
のでは、システム設計が変わります。
Impact DBでは後者を目指しています。
24. AI時代のDBは「Truth Storage」だけでよいのか
ここで、もっと大きな問題が見えてきます。
従来のDBは、
真であると判断されたデータ
を保存する場所として発展してきました。
しかしAIシステムでは、
Observation
Hypothesis
Inference
Potential
Candidate
Probability
Impact
Evidence
Decision
といった情報が大量に発生します。
このすべてを「確定データ」になるまで捨てていたら、
AIの思考過程に含まれている有用な情報を大量に失います。
だから私たちは、
AI時代には「Truth Storage」だけではなく、「Uncertainty Storage」が必要なのではないか
と考えています。
Impact DBは、その一つの試みです。
25. 重要なのは「確定しないこと」ではない
Impact DBという名前から、
「何でも曖昧なままにする設計」
と思われるかもしれません。
もちろん、それが目的ではありません。
むしろ逆です。
目指しているのは、
適切なタイミングで適切な確度まで確定させること
です。
つまり、
曖昧
↓
観測
↓
候補
↓
検証
↓
証拠
↓
確定
という流れを管理します。
「確定しない」のではなく、
確定を急がない
という考え方です。
26. 「確定すること」が情報損失になる場合
これはImpact DBの思想を理解する上で非常に重要な点です。
例えば、
A = 51%
B = 49%
という状態があるとします。
これを、
A = TRUE
に変換すると、一見シンプルです。
しかし、
B = 49%
という情報は消えました。
さらに、
なぜAだったのか？
も消える。
そして後日Bが正しいことが分かったとしても、
昔Aと判断していた
という履歴すら残っていないかもしれません。
つまり、
早すぎる確定は、データを増やすのではなく、情報を削ることがある
わけです。
27. Impact DBは「情報の圧縮」ではなく「情報の保存」
普通のデータベース設計では、
生データ
↓
整理
↓
正規化
↓
確定
という流れが重視されます。
しかしImpact DBでは、
生データ
↓
観測
↓
意味候補
↓
不確実性
↓
影響
という情報を残します。
これは、一見すると冗長です。
しかし将来的には、その冗長性が価値になります。
なぜなら、
後から新しいEvidenceが来たときに、過去の情報を再解釈できる
からです。
28. AIの学習にもつながる
例えば、
AIがAと判断した
↓
実際はBだった
というケースがあったとします。
最終結果だけ保存してしまうと、
B
しか残りません。
しかしImpact DBに、
Input
Candidate A
Candidate B
Evidence
Final B
が残っていれば、
なぜAIがAを選んだのか
を後から分析できます。
これはモデル改善だけでなく、
- Prompt改善
- RAG改善
- Knowledge改善
- Agent設計改善
- Validator改善
- Human Gate設計改善
にも使える可能性があります。
29. 「間違い」を捨てない
一般的なシステムでは、最終結果が正しいことが重要です。
しかしAI開発では、
間違えたことそのものが学習材料
になります。
だから、
Wrong Candidate
も重要なデータです。
Impact DBでは、
candidate = A
status = rejected
reason = evidence_conflict
のように、候補が否定されたことも保存できます。
つまり、
失敗した仮説もデータである
という考え方です。
30. これはAIの「思考過程を全部保存する」という意味ではない
ここは区別が必要です。
Impact DBが目指しているのは、LLMの内部推論をそのまま全部保存することではありません。
保存したいのは、
システムとして必要な状態・候補・根拠・判断境界
です。
例えば、
Candidate A
Confidence: high
Evidence: X
Status: pending
なら保存価値があります。
一方で、LLMが生成した大量の内部テキストをすべて保存する必要があるとは限りません。
つまり、
Reasoning TraceとEvidence Stateは別物
として扱う必要があります。
31. Impact DBと監査
AIシステムでは、
「なぜこの結果になったのか？」
が問われる場面が増えます。
ここで、
Final Answer
だけ残っていると説明が困難です。
Impact DBがあれば、
Observed X
↓
Candidate A
↓
Impact detected
↓
Evidence Y
↓
Candidate A weakened
↓
Candidate B strengthened
↓
Human Gate
↓
Final decision
という履歴を持てます。
これは単なるログとは違います。
意味を持った状態遷移です。
32. Impact DBは「未来のためのDB」なのかもしれない
ここまで考えてくると、Impact DBには面白い性質があります。
RDBが、
現在確定している世界
を表すなら、
Impact DBは、
まだ確定していない未来の候補
を表しているとも考えられます。
つまり、
RDB
= Known World
Impact DB
= Possible World
という見方もできます。
もちろん、これは厳密な形式化ではなく、設計思想としての表現です。
しかし、この考え方をすると、
AIシステムにおける「予測」「候補」「懸念」「仮説」の置き場所が見えてきます。
33. Impactという概念
では、なぜ名前が「Impact」なのでしょうか。
これは、
「何であるか」
よりも、
「何に影響する可能性があるか」
を重視するためです。
例えば、
原因は不明
でも、
安全性への影響
は評価できる場合があります。
つまり、
Cause = Unknown
Impact = High
という状態があり得ます。
これは現実世界では非常に重要です。
原因が分からないから何もしない、とは限りません。
逆に、
Cause = Known
Impact = Low
という状態もあり得ます。
「分かっているかどうか」と「重要かどうか」は別軸です。
34. 原因と影響を分離する
通常のデータモデルでは、
problem → cause
を求めたくなります。
しかし現実には、
problem
↓
cause unknown
↓
impact high
というケースがあります。
Impact DBなら、
Observation
↓
Problem Candidate
↓
Cause = Unknown
↓
Impact = High
という状態を自然に表現できます。
つまり、
原因が不明でも、影響は評価できる
という世界を扱えます。
これはAIによるリスク管理とも相性が良い考え方です。
35. 「曖昧なままでも動ける」
Impact DBの最終的な目的は、
曖昧なものを曖昧なまま保存すること
だけではありません。
もっと重要なのは、
曖昧な状態でも、システムが次の行動を取れるようにすること
です。
例えば、
Cause unknown
Impact high
なら、
Investigate
というActionを生成できます。
Cause unknown
Impact low
なら、
Observe
でよいかもしれません。
つまり、
Uncertainty
+
Impact
によって、
次に何をするべきか
を決められます。
36. Impact DBからActionへ
概念的には、
Observation
↓
Uncertainty
↓
Impact
↓
Action
という流れを作れます。
例えば、
Observation:
「いつもと違う」
Uncertainty:
原因不明
Impact:
高
Action:
追加観測
ということです。
ここまで来ると、Impact DBは単なるDBではなく、
意思決定システムの中間層
として機能します。
37. AI Consultantとの接続
この考え方は、VERTEX Consultant Systemとも接続できます。
AI Consultantが、
現状分析
↓
問題特定
↓
原因整理
↓
解決策
を行う場合、
途中で必ず、
確定した情報
と、
仮説
が混ざります。
そこで、
RDB
= Known Facts
Impact DB
= Open Questions / Hypotheses / Risks
と分ける。
するとコンサルタントは、
「分かっていること」
と
「まだ分かっていないが、意思決定に影響すること」
を別々に扱えます。
これはAIコンサルティングにおいてかなり重要な構造になる可能性があります。
38. Humanが最後に決める
Impact DBを導入したからといって、AIがすべてを決める必要はありません。
むしろ、
AI
↓
Hypothesis
↓
Impact
↓
Evidence
↓
Human Gate
↓
Decision
という構造を作ることで、
AIは、
- 発見する
- 推測する
- 候補を作る
- 影響を評価する
- 必要な証拠を提示する
ことに集中できます。
人間は、
確定させる
という重要な境界に集中できます。
39. 「不確実性を消さない」は、AI時代のデータ設計思想になり得るか
Impact DBは、まだ完成された標準技術ではありません。
また、すべてのシステムに必要だとも考えていません。
しかし、AIがシステムの中核になるにつれて、
Observation
Hypothesis
Inference
Candidate
Uncertainty
Impact
Evidence
Confirmation
を扱う必要性は増えていく可能性があります。
そのとき、
「確定データだけを保存するDB」
とは別に、
「確定前の情報を保存するDB」
という考え方が必要になるかもしれません。
Impact DBは、その一つの実験です。
40. おわりに
私たちは長い間、
データベースとは、分かったことを保存する場所だ
と考えてきました。
しかし、AI時代には少し違う考え方が必要なのかもしれません。
AIは、
分かった
だけではなく、
たぶん
おそらく
可能性がある
AかB
情報不足
矛盾している
追加観測が必要
という状態を大量に扱います。
それなのに、
Database
へ入れる瞬間に、
A
へ変換してしまったら、
AIが持っていた不確実性という重要な情報を捨てることになります。
だからこそ、
曖昧な情報を、曖昧なまま保存する。
ただし、
曖昧だから放置するのではなく、影響・候補・証拠・時間・状態を管理する。
そして、
Observation
↓
Impact
↓
Evidence
↓
Confirmation
という流れの中で、必要なタイミングで確定させる。
私たちはこれを Impact DB と呼んでいます。
もしかすると、AI時代のデータベースに必要なのは、
「何が真実なのか」
だけではなく、
「まだ何が真実か分からないのか」
を保存する能力なのかもしれません。
そして、その「分からない」を捨てずに保持しておくことで、
AIは未来のEvidenceを待ちながら、より安全に、より柔軟に、より現実世界に近い判断を行えるのではないかと考えています。
Impact DB Research Series
今後はImpact DBについて、
- データモデル
- State Machine
- Candidate / Confidence設計
- Evidenceとの連携
- RDBへのResolution
- VXN / VXN-DBとの接続
- AI Agentによる利用
- Human Gateとの境界
- 実装とベンチマーク
などを実装と検証を通して掘り下げていく予定です。
「確定しないこと」を、どうやってコンピュータに扱わせるのか。
これは、AI時代のデータ設計における一つの重要なテーマになるかもしれません。