AI・信頼性・評価

AIへの委譲を線引きする——タスクの仕分けと知識の配置

2026/7/17 （更新: 2026/7/17） シリーズ「AI協働への姿勢」 第4回 / 全9回

🤖 AIが下書き・人間が編集

社員IDから氏名を引く処理を、AIエージェントに任せるとする。台帳を検索し、表記ゆれを吸収し、それらしい答えを返す。動いてはいる。だが、こういう処理はときどき、数件を違う人に紐づける。台帳には正規のIDとメールアドレスが一意で入っている。素直にSQLを一本書けば、間違いようがない処理だ。

速いから任せる。この判断が、かえって高くつくことがある。

何をAIにやらせないか、を先に決める

AIには非決定の税がかかる。同じ入力でも出力が揺れるから、返ってきたものを検証し、外れれば作り直し、レビューする。この揺れは設計で抑えられる。同じ問いを複数回サンプルして多数決を取れば、推論の精度が上がり、ばらつきも相当に吸収できると報告されている¹。ただし多数決は税を消すのではなく、サンプル数の分だけ費用に付け替える。しかも仕様が固定できる処理では、多数決で薄めるより素直なスクリプト一本のほうが安い。決定的に書けるところに揺れの吸収機構を積むのは、払わなくてよい税を払い続けることだ。

逆もある。取り返しのつかない判断、たとえば本番データの削除や顧客への支払い確定を、確認なしでAIに投げれば、揺れがそのまま事故になる。

だから「全部任せる」は、実のところ何も設計していないのと同じだ。設計とは、仕事を仕分ける作業である。その仕分けの線は、AI以前からある二本を順に引けば足りる。

一本目は、仕様を決定的に固定できるか。ルールに落とせる定型作業と、判断の要る作業を分ける線だ。機械が古くから吸収してきたのは前者で、後者は残る。Autorらはこれをルーチンとノンルーチンのタスク境界として定式化した²。その根っこには、書き下せない技能はそもそもコード化できないというPolanyiのパラドックスがある³。

二本目は、取り返しがつくか、外したときの被害はどれだけか。Bezosの言い方なら、通っても戻れる「両開きのドア」か、通れば戻れない「片開きのドア」か⁴。これは意思決定分析でいう誤りの費用そのものだ。

二本を順に引く。まず仕様を固定できるかを問い、固定できないものにだけ、次の問い——取り返しがつくか——を立てる。

三つに割れるのは恣意的な区切りではなく、二値の問いを二回重ねた帰結だ。費用の見積もりも同じ形になる。トークン代に、外したときの期待費用と、レビューの手間を足し、この合計で三つの置き場を比べればいい。

正直に言えば、AI特有の難しさは一つ残る。ベンダーが新しいモデルを出すと、昨日まで税が見合っていた処理の採算が、一晩でひっくり返る。従業員が一斉に別人に入れ替わるようなものだ。この採算の引き直しを、従来の変更管理は十分に捉えきれていない。

知識の問題は、容量でなく構成で解く

もう一つ、投げがちな判断がある。コンテキストを大きく、モデルを大きくすれば、知識の問題は片づく、というものだ。

大きさはただではない。窓を広げると、長い文脈の真ん中が抜け落ちる⁵。費用も応答の遅さも膨らむ。何を今読み込み、何を退避し、何をセッション間で持ち越すか。これを設計しないまま窓だけ広げれば、関係のない情報で薄まるだけだ。知識の問題は、容量の問題ではなく、置き場の問題である。

これも古い規律で解ける。速い有限のストアに「今使う集合」だけを載せ、大きくて遅い倉庫を背後に置く。キャッシュ、メモリ階層、ワーキングセット——どれも同じ構図だ。何を速い層に載せるかは、Denningが1968年に定式化したワーキングセット、すなわち「いま実際に参照されている集合」で決まる⁶。速い店と遅い倉庫という構図は、AIよりずっと前から計算機の中心にあった。

だから置き場も、勘で三つに分けるのではない。その知識をどれだけ頻繁に・すぐ使うか（アクセス頻度）という一本の軸で、メモリ階層と同じ三つの操作に落ちる。

この三つは、速い層に対して「常駐させるか・取りに行くか・圧縮して退避するか」——キャッシュが昔から扱ってきた三択そのものだ。

反論はある。窓が広ければ階層設計など要らない、全部載せればいい、と。これは将来の話ではない。RULERの測定（2024年）では、評価した17モデルのうち半数ほどが32Kトークンまでは十分な性能を保ち、モデルによっては階層を組まず窓を広げるだけで足りていた⁷。素直な反論だ。実効的に使える窓はその後のモデルで着実に伸び、この32Kという数字自体はもう最新モデルの上限ではない。だが同じ測定が示した本筋は、数字が動いても残る。宣伝される窓の長さと、実際に取りこぼさずに使える長さは別物で、後者は往々にして前者よりずっと短い。実効窓がどれだけ伸びても無限ではなく、そこを超えた瞬間に真ん中が抜け、無関係な情報で薄まる問題が戻ってくる。だから設計は要る/要らないの二択ではない。何を熱い層に置き、何を退避するかの設計は、その時々のモデルの実効窓を超える手前でこそ効く。載せる前に、元の情報は失わない形で倉庫へ退避しておく。縮めるのはそのあとだ。

線引きが効く場面と、残る注意点

線引きの効きどころははっきりしている。仕様が固定できる定型処理では、AIより素直なスクリプトが安くて確実だ。取り返しがつく反復作業では、AIに任せて検証を挟むのが速い。取り返しのつかない判断では、人間の承認を残す。知識の側も同じで、熱い層とRAGと要約を役割で使い分ければ、窓を広げるより効く。

注意すべき点も残っている。モデルの更新で採算が引き直しになること。セッション間で何を覚え何を忘れてよいか、その方針はキャッシュの追い出し戦略だけでは半分しか答えられないこと。意味の重みを見積もる作法は、まだ薄い。

それでも、始まりは同じだ。全部任せる前に、何を任せないかを決める。窓を広げる前に、何を熱い層に置くかを決める。線を引くのは、AIではなく、こちらの仕事だ。

この記事はAIが下書きし、人間が編集・公開しています。