会社が AI を止める「本当の理由」

7 分7 min read

―― 承認を出せる根拠の地図

問題はモデルではない

AI の導入を止めているのは、たいてい「技術的にできないから」ではない。 承認を出せる根拠が無いからである。

止まっている案件を前に進めるために要るのは、より強力なモデルでも、より厚い規程でもない。 「何が見えて、何が見えないのか。その線を、後から証明できるか」という一点である。

この記事は、その線の引き方を地図にする。読み終えたとき、 自社が止まっている理由がどれなのかと、承認を出すために何が揃えば足りるのかが分かる状態を目指す。

audit を、監視から切り離す

「監査」と聞いて身構えるのは、正しい

AI のガバナンスの話は、しばしば従業員を見張る話に流れる。誰が何を入力したか、どんな相談をしたか。それは統制であって、信頼ではない。 そして実務的にも、その方向は続かない ―― 見張られる前提の道具は、使われなくなるからである。

私たちは監視を売らない。売るのは検証可能性である。

audit の再定義

audit ＝中身を覗くこと、ではない。本記事が使う audit は次の二つだけを指す。

来歴監査 ―― 何を、いつ渡したかが、後から辿れる。（AI の回答が何に基づいたかは、私たちの側からは見えない。見えるのは、境界を通ったものだけ。）
操作の事実の記録 ―― 誰が、いつ、どの操作をしたか。中身ではなく、事実だけが残る。

この二つが揃えば、承認は出せる。中身を覗く必要はない。

第三の道

見るべきもの（操作の事実・渡したものの来歴）は、見える。

見るべきでないもの（中身・私的な文脈）は、構造上見えない。

そして、その線が引かれていることを、後から証明できる。

「監視はできません」では稟議が通らない。「全部見られます」では現場が死ぬ。 通るのは三つ目の道だけである ―― 線を引き、線を示し、線を証明する。

誠実な限定

私たちの守備範囲は次に限定される。限定を先に言うのは、それが堀だからである。

入口で決めた帰属を、最後まで破らない（誰のものとして扱うかは、渡す側が宣言する。私たちはそれを判定しない）
本人が「それは違う」と言える（言えば、以後その観測は引き出されなくなる。記録そのものは消えない）
何を、いつ渡したかが残る（答えが何に基づいたかは、私たちの側からは見えない）

「全経路の漏洩を防ぐ DLP」とは名乗らない。 経路は他にもあり、私たちはそこを塞がない。 部分解を部分解と言えることが、この領域で唯一持続する信用である。

何が止めているのかを仕分ける

芯が共有できたところで、自社がどこで止まっているかを仕分ける。止める理由はたいてい次の三つで、 混ざったまま議論されているために結論が出ない。

#	止める理由	実際に起きていること	何があれば承認できるか
①	流出	入れた情報が外に出るかもしれない	何が外に出て、何が出ないかの線と、その証明
②	来歴	何を渡したのかが辿れない	来歴監査（何を渡したかが追える）
③	統制	線を引けない・引いても示せない	操作の事実の記録（中身でなく事実）

使い方: 御社が止まっているのは①か、②か、③か、あるいは全部か。 混ぜずに一つずつ当てはめる。①だけの案件に③の対策を積んでも承認は出ない。

①流出は、しばしば②③の不在が生む不安として現れる。「どこへ行くか分からないから、そもそも入れない」。この場合、必要なのはより強い禁止ではなく、線の可視化である。
②来歴が埋まると、多くの案件は急に動く。承認者が欲しかったのは安心ではなく説明可能性だからである。

なぜ今か

調達要件が変わりつつある。「AI を使っているか」ではなく「使い方を説明できるか」を問われる段階に入った。説明できない導入は、取引条件の側から止まる。
BCP・サプライチェーンの観点でも、外部サービスへの依存は「何が渡っているか」を言えることが前提になる。渡している中身が不明な依存は、事業継続の評価ができない。
これは煽りではない。 特定の事件を「予測していた」とは言わない。時勢は、なぜ今承認の基準を整えるべきかという文脈としてだけ使う。

承認を出すために揃えるもの

止めている理由を ①流出／②来歴／③統制に仕分ける。
②来歴から埋める（承認者が本当に欲しいのは説明可能性である）。
③操作の事実を、中身を覗かない形で残す。
線を示す ―― 見えるもの／構造上見えないもの／それを証明する手段。

AI を止めているのは技術ではない。証明できない線である。

FAQ

Q. これは「Semantic Web の再来」ではないのか

いいえ。姿勢が逆です。

Semantic Web は「あらかじめ意味を定義しておけば、機械が扱える」と考えた。世界中の情報に人手で意味づけをして回る必要があり、その労力の鶏卵問題で失速した。

Sens は定義しない。すでに使われている言葉から、話題の構造を観測して記録する。

定義 vs 記録 ―― 前者は「こう意味づけよ」と決める。後者は「実際にこう使われている」と記す。
LLM 以前 vs LLM 以後 ―― SW は記号推論を前提にした。その前提は LLM が別の道で乗り越えた。 Sens は LLM と競合しない。LLM の外側で、渡す文脈の側を扱う。
単一の正解 vs 主体ごとの意味 ―― SW は世界に一つの意味体系を志向した。 Sens は、同じ言葉が部署によって違う意味を持つこと自体を、記録すべき事実と考える。

これは誇張ではない。 新しいから優れているのではない。別の問題を解いているのであり、 SW が解こうとした問題（形式的推論）を Sens は解かない。

Q. 結局、従業員を監視できるのか

できません。そして、できないことが仕様です。 残るのは操作の事実であって、中身ではありません（「audit の再定義」で述べたとおり）。「監視できます」と言う製品と、私たちは目的が違います。

Q. どこまでが実装済みで、どこからが設計なのか

実装済み（v0.5、ブラウザの中で動く体験版）: 何を渡すかを、渡す前に確かめる。渡した記録はブラウザの中に残り、閉じると消える。
設計段階: 書き出しと、閉じても残る記録は、まだない。外部の AI へ自動で送る仕組みも設計段階（いまは、あなたの手で渡す）。
設計段階: 保管の層の拡張は v0.5 以降。
設計を実装として語りません。 ここを曖昧にする説明は、承認の根拠になりません。

Q. 精度はどれくらいか

単一の数値では答えません（答えられる、と言う方が不誠実です）。測っている軸ごとに到達度が違い、平均に畳むと意味を失うためです。公開している到達度は暫定であり、測定時点と測り方を添えて開示します。