AI に判断を任せると、暗黙知はどこへ行くのか

そもそも、AI は毎回文章を書く必要があるのでしょうか。

TypeSafe AI が公開した「Jev」は、文章を書かずに、選択肢やスコアといった判断だけを返す AI です。この記事では、Jev の公開実装と、AI を導入した銀行・種子選別の現場研究をもとに、仕事の中の小さな判断を AI に任せると何が起きるのかを考えます。

Jev は、文章ではなく判断を返す

LLM は大量の文章から次のトークンを予測することで学習し、文章生成以外のさまざまなタスクにも対応できるようになりました。でも、文章を使って能力を身につけたことと、ソフトウェアがその能力を使うたびに文章を出力する必要があることは別です。

たとえば問い合わせの振り分けなら、欲しいのは丁寧な回答ではなく「営業」「サポート」「その他」のどれに回すかという判断だけかもしれません。

2026年9月に TypeSafe AI が公開した Jev は、こうした用途に特化しています。自由な文章の代わりに、事前に定義した選択肢やスコア、それぞれの確率を返します。公式の表現は「smart if-statements」。通常のコードでは書きにくい曖昧な条件を、AI で扱おうという発想です。

GitHub の実装は、小さな判断だけを任せている

では、実際に開発者は何を作っているのか。GitHub を見てみました。

税務書類の実装では、公開評価の753ページで誤分類は0。ただし38ページは確信度95%に届かず、自動確定の基準を満たしませんでした。作者らは、以前の LLM ベースの分類器よりコストが約34分の1、速度が約6倍だったと報告しています。これはあくまでこの実装の評価で、ほかの業務でも同じ数字が出るという意味ではありません。

ブラウザ操作の実装も、やっていることは似ています。「サイトを操作する」という仕事を一度に丸ごと処理するのではなく、現在のページから次の一手を選び、実行し、また選ぶ。

共通しているのは、仕事の途中にある小さな判断だけを AI に任せていることです。

仕事は「マイクロ判断化」していく

たとえばメール対応。普段は一つの仕事として数えていますが、途中ではいくつも判断しています。

flowchart TD
    A["問い合わせメールが届く"] --> B{"緊急か？"}
    B -->|はい| C["人間に即通知"]
    B -->|いいえ| D{"担当部署は？"}
    D --> E["営業・サポートなどへ振り分け"]
    E --> F{"返信が必要か？"}
    F -->|いいえ| G["記録して終了"]
    F -->|はい| H{"自動処理していいか？"}
    H -->|はい| I["返信案の作成・確認へ"]
    H -->|いいえ| J["人間が対応"]

最初は緊急度だけを AI に任せます。次に担当部署、さらに返信の要否。仕事を丸ごと置き換えなくても、分岐を一つずつ自動化できます。

これを、ここでは「マイクロ判断化」と呼ぶことにします。

判断の自動化そのものは昔からあります。ただ、Jev のような仕組みで曖昧な判断を安く組み込めるなら、今まで人間が100回判断していた仕事を AI に100回移すだけでは終わりません。「解約しそうか」「今返信すると効果がありそうか」といった、以前は判断するほどでもなかった項目まで増やせます。

Jev の名前が、効率化によって資源の利用量がかえって増える「ジェヴォンズのパラドックス」に由来するのも、ここにつながります。

判断の中にあった暗黙知

ここで気になるのは、判断の件数より、その判断を人間がどう身につけていたかです。

ベテランの担当者は、緊急度を見ながら「いつもと違う」「もう少し事情を聞こう」と思うかもしれません。本人も判断の全過程を言葉にできない、経験に根ざした知識があります。いわゆる暗黙知です。

もちろん、暗黙知がすべて正しいわけではありません。経験由来の偏見もありますし、AI は過去の行動から言語化されていないパターンを学ぶこともできます。

それでも、過去の判断結果を再現できることと、目の前の例外に気づいて追加で調べることは同じではありません。 判断を小さく切り出したとき、後者はどこに置けばいいのでしょうか。

同じ AI 導入で、二つの現場は違う方向に進んだ

ここで、AI 導入後の現場を調べた研究を見てみます。

銀行:経験が結論に還元されにくい

『Journal of Management Studies』に掲載された現場研究では、ドイツの銀行で融資判断を AI に移したあと、担当者が顧客情報を入力し、出された結論を顧客に説明する役割になっていました。担当者の経験と AI の結論が食い違っても、簡単には覆せません。中には、AI が示した理由をそのまま見せず、自分の言葉で説明しようとする担当者もいました。

顧客が疑問を持っても、その場で判断を変えられるとは限りません。担当者は専門知識を持ち、顧客とも接しているのに、その知識が結論へ還元されにくくなっていました。

種子選別: AI の出力から新しい知識が育つ

ところが、同じ研究の種子選別の現場では、違うことが起きていました。

以前は、担当者が長年の経験を頼りに種子を手で触り、見た目を確かめ、品質を評価していました。AI 導入後は、画像などから品質を判断する仕組みが中心になります。担当者たちも最初は AI の結論をうまく説明できず、従来の経験に引き寄せて説明しようとしていました。

それでも取引先から、「なぜ低品質なのか」「この種子はどの用途に向くのか」と具体的に聞かれ続けます。担当者は AI の画像やグラフと実物を見比べ、どの特徴が何を意味するのか調べるようになりました。やがて、以前は持っていなかった専門知識を身につけ、説明の仕方も変えていきました。

二つの現場の違い

研究が注目した違いの一つは、相手とのやり取りの密度です。銀行では顧客との接点が単発になりやすく、種子選別では同じ取引先との継続的なやり取りが、担当者に新しい問いを与えていました。

ここが面白いところです。同じように AI へ判断を移しても、人間の知識が必ず失われるわけではありません。AI の結果を受け取ったあと、現場の人が何を調べ、誰から何を聞けるかによって、経験の積まれ方が変わっていました。

現場で分かったことは、どこへ還元されるのか

メールの例に戻すと、AI が「緊急ではない」と分類した問い合わせを、後から担当者が「これは急ぎだった」と知ることがあるはずです。

そのとき、担当者が処理だけ済ませて終われば、次も同じ種類の問い合わせを見落とすかもしれません。一方、誤分類の記録を残して基準や入力情報を見直せるなら、現場の発見を次の処理に使えます。これは Jev に限らず、システム全体の設計の話です。

銀行の担当者に必要だったのも、AI の結論を流暢に説明することだけではありませんでした。種子選別の担当者が得られたのも、AI のグラフを読む技術だけではありませんでした。現場で新しく分かったことを、その後の仕事に使えるかどうかが違っていました。

マイクロ判断化が進めば、人間が一件ずつ判断する機会は減ります。だからといって、人間の経験が必ず薄くなるわけではありません。AI が拾った大量の結果と実際の出来事を照らし合わせることで、むしろ以前は気づかなかったパターンを学べる場合もあります。

逆に、判断結果だけが降りてきて、その正しさを確かめる機会も、次の判断に反映する経路もなければ、現場に知識があっても使われなくなります。

AI に判断を任せたあと、何を残すのか

もし自分が住宅ローンの審査に落ちたら、と考えてみます。転職したばかりで勤続年数は短い。でも、収入は上がっている。そういう事情を話したとき、結論が変わるかどうかより、事情を汲もうとしてくれる人がいることに救いを感じる気がします。

ベテランが「もう少し事情を聞こう」と思う、その一歩。判断を小さく切り出して AI に任せるとき、真っ先に消えやすいのは、この一歩なのかもしれません。

Jev を見て最初に面白いと思ったのは、文章を書かずに判断できることでした。けれど GitHub の実装や現場研究を見ていくと、別のところが気になってきました。

判断を一つずつ AI に任せるとき、その判断を通じて人間が学んでいたことまで、仕事から取り除いていないか。

自分がこの仕組みを作るなら、「何件自動処理できたか」と同じ画面で、現場がどんな誤りや例外を見つけたかも見たい。その情報が次の判断に使われたのかまで追えるようにしたい。

暗黙知が全部 AI に移るとも、全部消えるとも思いません。ただ、現場で気づいたことが使われない状態を、そのまま効率化と呼ぶのは違う気がします。

参考資料

• Introducing System One Models and Jevtypesafe.ai
• tax-doc-classifierGitHub
• jev-browserGitHub
• “Let Me Explain”: A Comparative Field Study on How Experts Enact Authority Over Clients When Facing AI Decisionsonlinelibrary.wiley.com