AI・信頼性・評価

AIエージェントの任せ方：任せていい仕事の見分け方と知識の置き場所

2026/7/17 （更新: 2026/10/14）

🤖 AIを使用して執筆

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

AIには非決定のコストがかかる。同じ入力でも出力が揺れるから、返ってきたものを検証し、外れれば作り直し、レビューする。この揺れは設計である程度は扱える。同じ問いを複数回サンプルして多数決を取れば、答えが固定された選択肢から選べるたぐいの問題では推論の精度が上がると、Wangらは報告している¹。ただし原典は、この手法が使えるのは最終解が固定の答案集合から来る問題に限られると自ら断っている。開放的な生成へも、複数の出力どうしの一致を測る尺度が定義できれば原理的には広げられる、と同じ一文で添えてもいる。原典は補足の観察として別の使い道も挙げ、サンプル間の一致率の低さを「モデルが自信を持てていない」印に使えると示唆している。揺れは消す対象というより、どこを人間に上げるかを決める信号として使える。ただし多数決はコストを消すのではなく、サンプル数の分だけ費用に付け替える。しかも仕様が固定できる処理では、多数決で薄めるより素直なスクリプト一本のほうが安い。決定的に書けるところに揺れの吸収機構を積むのは、払わなくてよいコストを払い続けることだ。

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

だから「全部任せる」は、実のところ何も設計していないのと同じだ。設計とは、いくつかの問いで仕事を仕分け、それぞれの担い手へ流す作業である。委譲で引く線は、AI以前からある二本で足りる。

一本目は、仕様を決定的に固定できるか。ルールに落とせる定型作業と、判断の要る作業を分ける線だ。機械が古くから吸収してきたのは前者で、後者は残る。Autorらはこれをルーチンとノンルーチンのタスク境界として定式化した²。その背景にあるのが、明示的に書き下せない技能はコード化しにくいというPolanyiのパラドックスだ。ただしAutor自身は、その11年後の単著論文で、機械学習がこの限界を迂回しようと試みており決着はまだついていない、とも論じている³。だからこの一本目は「原理的に自動化できるか」ではなく、仕様を決定的に固定できるなら揺れない手段のほうが安い、という費用の線として読むのがいい。

二本目は、取り返しがつくか、外したときの被害はどれだけか。Bezosの言い方なら、通っても戻れる「双方向のドア」か、通れば戻れない「一方通行のドア」か⁴。これは意思決定分析でいう誤りの費用そのものだ。もっとも、同じ段落でBezosが警告するのは、むしろ逆向きの失敗である。組織が大きくなると、戻れる決定にまで戻れない決定用の重い手順を当てがちになり、その結果は遅さと考えの浅いリスク回避だという⁴。

二本を順に引く。最初の問いは仕様を固定できるかであり、固定できないものにだけ、取り返しがつくかという次の問いを立てる。ただし取り返しのつかない操作は、スクリプトに落とした場合でも、実行の前に人の承認を置く。

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

実在のハーネスを見ると、この三つの置き場はもう一段細かく割られている。たとえば、コーディングエージェント向けのスキル集 superpowers が人の判断に任せるのは、設計の承認と、書き上げた仕様のレビューである。そのうえで、置いてはいけない場所まで名指しする。その場所は作業中の進捗確認である。「続けてよいですか」と伺いを立てることや経過報告は人の時間を無駄にする、と本文が明記している⁵。承認ゲートを残すことと、逐一お伺いを立てることは違う。後者は希少な注意を、何も買わない場所で使う。

任せたあとの詰まりにも、決まった対処がある。同じ集まりは、委譲先が行き詰まったときの手当てを原因ごとに定めていた⁵。コンテキストが足りなければ足し、推論が足りなければ強いモデルに替え、タスクが大きすぎれば割り、計画そのものが誤っていれば人へ上げる。ただしこの一段は、その後の版で置き換わっている。その版の subagent-driven-development では、計画の誤りは呼び出した側が自分で裁定して書き残す。同じファイルは、人を呼ぶ場面を四つに絞った。元に戻せない操作、セキュリティに触れる操作、慣行として断りを要する作業ツリー外の副作用、そしてどの道も推測にしかならないほど壊れた計画である⁵。計画の正しさが引き金でなくなったのではない。ふつうの誤りは自分で裁定して進み、どの道も推測になるところで初めて止まる。人を呼ぶ閾値が上がり、同じ閾値に可逆性とセキュリティが並んだ。

委譲は、投げた時点では終わっていない。ECC の規約ファイルにある「委譲完了契約」は、投げた仕事は完了した仕事ではないと書く。背景で走らせたエージェントを待っている状態で自分の番を終えるな、投げっぱなしの委譲は禁じる、そして「深さは計画ではなく結果だ」と⁶。線を引くなら、返ってきたものを引き取るところまでが線の内側にある。

AI特有の難しさは一つ残る。ベンダーが新しいモデルを出すと、昨日までコストが見合っていた処理の採算が、一晩でひっくり返る。この採算の引き直しを、従来の変更管理は十分に捉えきれていない。

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

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

大きさはただではない。コンテキストウィンドウを広げても、長いコンテキストの中ほどに置いた情報は使われにくい⁷。費用も応答の遅さも膨らむ。コンテキストウィンドウだけ広げて何を退避するか決めなければ、関係のない情報で薄まるだけだ。知識の問題は、容量を足すだけでは片づかず、置き場を決める問題になる。

置き場は勘で分けるのではなく、その知識をどれだけ頻繁に・すぐ使うか（アクセス頻度）、どれだけ嵩張るか（サイズ）、どれだけ長く効き続けるか（寿命）で決まる。この三つの軸の組み合わせが、常駐させるか・取りに行くか・圧縮して退避するか、の三つの操作に落ちる。

この三択は、速い有限のストアに今使う集合だけを載せ、残りを遅い倉庫に置くという二層記憶の規律を、知識の置き場へ写したものだ⁸。その写像と、なぜコンテキストウィンドウを広げるだけでは足りないのか（実効的に使えるコンテキストウィンドウは宣伝される長さより短く、例外的な一モデルでは置き場を分けずコンテキストウィンドウの拡大で足りることもある⁹）は、記事「AIエージェントの記憶の設計：RAG・要約・引き継ぎの使い分け」で詳しく扱う。ここで委譲の側から言えるのは、知識の置き場もまた、容量任せにせず引くべき線だということだ。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。