AIを「集合」と「位相」から考える 正解を当てる機械から、判断できる範囲を設計する基盤へ

🎥 YouTubeでも公開しています

集合と位相で考える業務AI｜AIの知識・信頼・実行の境界を設計する

Books: AIはどんな数学観の上に作られているのか: 有限ルールから生成モデルへ

AIの活用を考えるとき、私たちはしばしば「どれほど正確に予測できるか」という問いから始める。需要を予測する、異常を検知する、候補者を推薦する、問い合わせに答える。これは重要である。

しかし業務でAIを実装すると、もう一つの問いが前面に現れる。

このAIは、いま何を根拠に、どこまで進めてよいのか。

この問いを考えるために役立つのが、集合と位相という数学の見方である。難しい数学を業務へ持ち込もうという話ではない。AIが扱う対象、関係、境界を、混同せずに設計するための言葉として使いたい。

1. 業務AIは、まず「集合」を扱っている

集合とは、ある条件でひとまとまりとして扱う対象の集まりである。たとえば「今月中に回答期限を迎える案件」「この製品カテゴリを扱うサプライヤー」「契約上、一定額まで値引きできる営業担当者」は、いずれも条件によって切り出された集合である。顧客、案件、契約、文書、設備、センサー値、担当者、承認者、AI Agent。その多くは業務上、集合として扱える。

業務の判断が難しくなるのは、一つの条件だけでは決められないからである。値引き額が妥当そうであっても、契約に反していれば進められない。契約と整合していても、根拠資料が不足していれば確認が必要になる。根拠があっても、担当者に権限がなければ自動実行はできない。

そこで、AIが扱うべき問いを「この案件は承認すべきか」という一つの大きな問いのままにせず、条件ごとの集合として分けて考える。各条件を満たす集合を重ねることで、最後に残るのが、現時点で業務を進められる案件の集合である。

たとえば、ある値引き案件を考える。最初から「この値引きを承認するか」と問うのではなく、次の集合を区別して置ける。

• 値引きの候補となる案件の集合
• 類似事例を持つ案件の集合
• 現行契約と整合する案件の集合
• 必要な証跡がそろった案件の集合
• 担当者の権限内で処理できる案件の集合
• 自動実行してよい案件の集合

ここで各集合は、前の集合を単純に置き換えるものではない。たとえば「類似事例を持つ案件」は参考情報の集合であり、「契約と整合する案件」や「必要な証跡がそろった案件」は、実際に先へ進むための条件の集合である。AIはこれらを照らし合わせ、条件を満たさない案件を除き、満たせない条件を明らかにしながら、候補を絞り込む。似た事例を探すAI、規程を照合するAI、証跡の不足を調べるAI、承認経路を決めるAIは、それぞれ異なる条件で部分集合をつくっている。

たとえば、AIが過去事例から「10%の値引きが妥当そうだ」と提案したとする。これは、類似事例という集合を手がかりにした有用な仮説である。しかし、その案件が契約条件、必要な証跡、担当者の権限という集合にも同時に含まれるとは限らない。

ここで重要なのは、「AIがもっともらしい答えを出した」ことと、「業務が進められる集合に入った」ことは別だという点である。前者は判断の候補や仮説を生む。後者は、その候補が根拠・方針・権限という必要条件を満たし、実際に進めてよい状態にあることを示す。

2. 空集合は失敗ではなく、重要な判断結果である

数学でいう空集合とは、ある条件を満たす対象を探した結果、一つも見つからなかった状態である。たとえば「必要な証跡を持ち、かつ自動実行を許可された案件」という条件に当てはまる案件がゼロ件なら、その結果は空集合になる。

通常の業務システムでは、検索結果がゼロ件であることを単に「データなし」やエラーのように扱いがちである。しかしAIが業務の判断や実行に関わる場合、そのゼロ件には明確な意味がある。それは、いま与えられている根拠・方針・権限の範囲では、次の段階へ安全に進められる対象がない、という判断結果である。

言い換えれば、空集合はAIの失敗を表すのではない。AIが「あるはずだ」と補完せずに、進めてよい対象が存在しないことを正しく示した結果である。たとえば、次のような状態が考えられる。

• 必要な証跡を持つ文書が見つからない
• この取引を承認できる権限者が現時点でいない
• 参照を許された根拠の中に、結論を支える情報がない
• 実行してよい操作の集合に、AIが提案した操作が含まれない

これらは、直ちに不正や異常が確定したことを意味するわけではない。証跡が別の場所にあるかもしれないし、権限者が後から利用可能になるかもしれない。だからこそ必要なのは、AIが不足をもっともらしい推測で埋めることではない。「確認できない」「権限がない」「実行できない」を明示し、追加確認、人の承認、停止へ遷移することである。

UnknownをPassとして数えない設計は、まさにこの考え方に立つ。確認可能な根拠の集合が空なら、問題がないのではない。判断を進めるための根拠が欠けているのである。

3. 位相は「近さ」と「境界」を扱う

集合だけでは、対象があるかないかを区別できる。しかし実際のAIでは、「似ている」「近い」「周辺にどんな事例があるか」が重要になる。ここで位相的な見方が効いてくる。

位相をとても簡潔に言えば、個々の点の正確な距離よりも、何が互いに近傍をつくり、どこに境界があるかを扱う考え方である。地図を思い浮かべると分かりやすい。東京から大阪までの厳密な距離を測らなくても、「この駅の周囲にはどの駅があるか」「この路線でつながっている地域はどこまでか」「県境を越えると管轄やルールがどう変わるか」は考えられる。位相が見るのは、こうしたつながり方、まとまり方、そして境界の構造である。

AIに置き換えれば、一つひとつの文書や案件は地図上の点のようなものになる。「意味が近い」とは、同じ文脈や論点を持つ事例が近傍として集まることを指す。ただし、その近さは物理的な距離ではなく、言葉、内容、状況、関係性から計算された意味上の近さである。

生成AIやベクトル検索は、文書・画像・事例を意味の近さで配置する。たとえば「納期遅延」「部材不足」「代替調達」といった文書は、意味空間の中で近い近傍をつくる。これは、AIが「納期遅延」という単語だけを探しているのではなく、その周囲にある調達リスク、代替部品、サプライヤー変更、顧客への影響といった関連する論点まで含めて探索できる、ということである。したがって、単語が完全に一致しなくても関連する過去事例を探せる。

ただし、意味が近いことと、同じ業務判断をしてよいことは違う。

過去の障害事例と今回の兆候がよく似ていても、対象設備の安全重要度、証跡の鮮度、契約条件、停止による事業影響が異なるかもしれない。AIが「似ている」と示すことは、調査すべき近傍を提示することにはなる。しかし、それだけで同じ操作を自動実行する理由にはならない。

4. 三つの空間を混ぜない

ここまで見てきたように、AIは事例の近さを見つけ、条件を満たす集合を絞り込むことができる。ただし「近い」という言葉の意味は一つではない。同じ二つの案件でも、内容が似ているという意味では近くても、信頼してよい状態や、実行してよい操作という意味では遠いことがある。

そこで業務AIを安全に使うためには、少なくとも次の三つの空間を分けて考えると分かりやすい。これは三つの別々のシステムを必ず作るという意味ではない。一つの案件を、何に似ているか、どこまで信頼できるか、何を実行してよいかという異なる問いで見るための枠組みである。

最初の意味空間は、AIが過去事例や関連文書を探すための空間である。ここでは、表現や文脈が似ていることが価値を持つ。次の信頼空間では、その情報を根拠として使えるかを問う。同じ内容でも、出所が不明、更新日が古い、必要な権限で取得されていない、といった情報は信頼できる根拠とは限らない。最後の実行空間では、仮に根拠が十分でも、AIや担当者に許された操作か、影響範囲は許容できるか、どの条件で止めるかを問う。

AIの誤用の多くは、意味空間で近いものを、信頼空間や実行空間でも近いと扱ってしまうところから起こる。つまり「似た事例が見つかった」ことを、「同じ根拠で判断してよい」「同じ操作を自動で実行してよい」と短絡してしまうのである。

たとえば、「似た顧客がこの条件を受け入れた」ことは営業提案の参考にはなる。これは意味空間では有用な近傍である。しかし今回の顧客に同じ条件を提示できるとは限らない。契約条項、与信状態、担当者の権限、個別の約束が異なるからである。過去事例の記録が古かったり、今回の担当者に提示権限がなかったりすれば、信頼空間や実行空間では近いとはいえない。

つまり、意味の近傍は答えの近傍ではなく、まず調べるべき仮説の近傍である。AIは似た事例を起点に仮説を示し、その後に根拠の信頼性と実行条件を確かめる。この順序を守ることで、AIの探索能力を活かしながら、似ているというだけで業務上の境界を越えてしまうことを防げる。

5. 境界にこそ、AIガバナンスがある

前節で分けた意味空間、信頼空間、実行空間には、それぞれ「ここまでは進めてよい」といえる範囲がある。位相の発想で特に重要なのは、その範囲の縁、すなわち境界である。境界とは、AIの能力が急に失われる場所ではない。AIの提案をそのまま実行へつなげる処理から、確認・承認・制限付き実行へと、扱い方を切り替えるべき場所である。

自動化できる領域の内部では、AIは速く、連続的に処理を進められる。定型的で低リスク、証跡が十分、権限が明確であり、影響範囲もあらかじめ許容されている業務であれば、その恩恵は大きい。たとえば、必要条件をすべて満たす少額の定型値引きや、影響が限定された一般端末の一時的な隔離は、一定の条件下で自動化しやすい。

一方、証跡、権限、影響範囲のどれかが曖昧になると、案件はその境界へ近づく。ここでは結論そのものが間違っているとは限らないが、自動で実行してよいという条件が十分ではなくなる。たとえば、次のような状態である。

• 証跡の一部が取得できない
• データは古いが、緊急対応が必要である
• 提案内容は妥当だが、実行権限が不足している
• 同じ操作でも、対象が重要サーバーや安全設備である
• 過去事例には近いが、今回だけ条件が異なる

このとき必要なのは、AIの確信度を少し上げて越境させることではない。AIが「おそらく正しい」と言っても、権限や影響に関する不足が自動的に解消されるわけではない。必要なのは、境界を越えるための条件を明示することである。追加の証跡、別の承認者、影響範囲の縮小、時間制限付きの実行、または停止が、その条件になる。

つまり、境界設計は自動化か非自動化かを二者択一で決めるものではない。状況に応じて、自動実行、人の承認を伴う実行、限定的な試行、追加調査、停止という複数の遷移先を用意する設計である。

ランサムウェア封じ込めを例にすれば、危険兆候が十分に強く、一般端末であれば一時隔離を自動実行できるかもしれない。しかし会計締めを担う基幹サーバーなら、同じ兆候でも人の承認を必要とする。あるいは隔離そのものではなく、監視強化や通信の一部制限から始める選択もある。この違いは検知精度の問題ではなく、対象の重要度と実行影響を含めた、実行空間の境界設計の問題である。

6. Decision Traceは、集合間の遷移を記録する

ここまでの議論では、AIが似た事例を見つけ、根拠・方針・権限・影響範囲を順に確かめ、境界では処理のモードを切り替えることを見てきた。Decision Traceは、この一連の判断を、最終結果だけでなく途中の遷移も含めて記録する考え方である。

Decision Trace Modelの観点から見ると、判断とは単一スコアの出力ではない。「承認」や「却下」という最終ラベルだけを残しても、何を根拠に、どの条件を満たし、どの条件が満たせなかったのかは分からない。判断とは、候補集合が、根拠、方針、権限、時間、責任の条件を通ることで、実行可能な集合へ変わっていく過程である。

たとえば値引き案件なら、まずAIが関連事例を見つける。次に、参照した事例や契約文書が今回の判断に使えるだけの根拠を持つかを確かめる。その上で、現在の契約・方針と整合するか、誰が実行または承認できるかを確認する。各段階で、対象となる案件の集合は絞られ、あるいは追加確認が必要な集合へ分岐する。

この流れは、次のように表せる。

候補集合
  → 関連する根拠がある集合
  → 根拠が十分な集合
  → 方針・権限を満たす集合
  → 実行可能な集合
  → 自動実行／人の承認／追加確認／停止

Decision Traceに残すのは、矢印の前後にある状態だけではない。どの文書や観測値を根拠にしたのか、どの方針を適用したのか、誰またはどのAgentが判断を提案したのか、どの時点の権限で確認したのか、そしてどの条件によって次の状態へ進んだ、または進めなかったのかを結びつけて残す。

この遷移を記録すれば、後から「なぜこの案件だけ自動化されなかったのか」「誰がどの根拠で例外を承認したのか」「どの証跡の欠落が停止の理由だったのか」をたどれる。これは問題が起きた後の監査だけのためではない。似た案件で次に何を確認すべきかを学び、方針や境界の設計を改善するための材料にもなる。

ここでAIは、結論を出す主体というより、集合の状態を可視化し、根拠と不足を示し、次の遷移を提案する主体になる。人間は、境界を定め、例外を引き受け、必要なら境界そのものを更新する。AIと人間の役割をこのように分けることで、AIの速度を活かしながら、実行の正当性と説明可能性を保つことができる。

7. 応用の見方が変わる

ここまでの捉え方を採ると、AIの応用テーマも少し違って見えてくる。どの技術も、単に精度を上げたり処理を速くしたりする仕組みではない。何を参照できるかという集合を定め、意味・信頼・実行を混同せず、境界で適切な遷移を選び、その過程を記録する仕組みとして捉え直せる。

RAG：参照できる知識の境界を扱う

RAGは「正しい文章を返す仕組み」だけではない。まず、どの文書、どの版、どの権限で参照できるかという知識集合を定める。次に、その集合の中から関連する近傍を探し、回答の根拠を提示する。そして、参照できなかった領域や十分な根拠を見つけられなかった問いは、もっともらしい文章で埋めずにUnknownとして残す。

この見方では、RAGの品質は回答の流暢さだけで決まらない。どの根拠集合を参照したか、何を参照できなかったか、回答をどこまで業務判断に使ってよいかを明確にできるかが重要になる。

マルチエージェント：判断の近傍を広げ、反証も扱う

マルチエージェントは「たくさんのAIを動かす構成」だけではない。一つの結論を急いで強めるのではなく、異なる根拠集合、異なる反証集合、異なる実行条件を並行に検討する構成である。あるAgentが類似事例を探し、別のAgentが規程や契約を確認し、さらに別のAgentが反対の証拠や実行上の制約を探す。

こうすることで、判断の近傍を広げながらも、似た事例だけに引きずられることを避けられる。重要なのは、各Agentの出力を多数決で一つの答えに丸めることではない。どの根拠がそろい、どの反証や不足が残っているかを見える形にし、次の遷移を選べるようにすることである。

Physical AI：設備ごとの局所的な境界を守る

Physical AIは「現場を自動化するAI」だけではない。設備、作業エリア、搬送物ごとに、観測可能な状態、実行可能な操作、局所方針、責任範囲を分ける構成である。たとえば、ある設備の温度上昇を観測できることと、その設備を停止できることは別の権限である。また、停止が安全上妥当でも、周辺設備や生産計画への影響を確認せずに実行してよいとは限らない。

そのためPhysical AIでは、現場ごとに意味空間、信頼空間、実行空間の境界を持たせる必要がある。局所的な観測と判断を活かしながら、許可されていない操作や、影響範囲を越えた自動実行を防ぐことができる。

Trust Infrastructure：境界と遷移を実装する層

Trust Infrastructureは、上の三つの応用を横断して、それらの境界と遷移を実装する層である。アイデンティティによって誰やどのAgentが関わるかを定め、証跡によって何を根拠にするかを確認し、方針と権限によって何を実行してよいかを制御する。さらに、時間によって権限や証跡の有効性を扱い、説明責任によってDecision Traceをたどれるようにする。

つまりTrust Infrastructureは、AIを後から制限するためだけのガードレールではない。AIが意味の近傍を探索し、適切な根拠で判断し、許された範囲で実行し、境界では人へ遷移できるようにするための、業務AIの実行基盤である。

おわりに：AIの価値は、境界を曖昧にしないことにもある

AIは、曖昧な情報から意味の近傍を見つけることに非常に優れている。しかし業務で信頼されるAIに必要なのは、近いものを何でも同じに扱わないことである。

どの集合に属するのか。何が確認でき、何が確認できないのか。どの境界までは自動で進め、どこから人が引き受けるのか。これらを設計し、判断の遷移として記録する。

AIは正解を予測するだけの技術ではない。
意味、根拠、権限、時間、責任が交差する空間の中で、
いま何を、どこまで進めてよいかを扱う技術である。

集合と位相は、その設計を考えるための静かだが強力な言葉になる。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance