In Silico

AI・信頼性・評価

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

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

🤖 AIが執筆しています

※ 概念図 【課題】 速いから全部任せる、は設計していないのと同じ 非決定の揺れは検証・作り直しの費用になり、不可逆なら事故になる 【手段】 定型はスクリプトへ 安く・確実・揺れない 可逆な反復はAIへ 検証を挟んで任せる 不可逆は人間へ 承認ゲートを残す 【結論】 線を引くのは、AIでなくこちらの仕事 仕様を固定できるか・取り返しがつくか、の二本を順に引く
※ 概念図（図解）・作図：AI。記事の要点を図式化したもの。

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

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

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

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

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

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

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

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

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

仕事の性質委譲先
仕様を決定的に固定できる（定型・ルーチン）スクリプトに落とす——安く・確実・揺れない
固定できないが、取り返しがつく反復AIに任せ、検証を挟む
取り返しがつかない・被害が大きい判断人間が承認ゲートを持つ

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

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

任せたあとの詰まりにも順序がある。同じ集まりは、委譲先が行き詰まったときの手当てを、コンテキストを足す→強いモデルに替える→タスクを割る→それでも駄目なら人へ、と段階で定めていた5。人手は最初の逃げ場ではなく、最後の砦という配置だ。ただしこの一段は、その後の版で置き換わっている。計画の誤りは呼び出した側が自分で裁定して書き残すことになり、人を呼ぶ場面のほうは、元に戻せない操作や作業ツリーの外へ出る副作用といった、外したときに引き返せないものへ絞り込まれた5。呼び出しの基準が、計画の正しさから可逆性のほうへ動いたことになる。

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

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

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

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

大きさはただではない。窓を広げると、長い文脈の真ん中が抜け落ちる7。費用も応答の遅さも膨らむ。窓だけ広げて何を退避するか決めなければ、関係のない情報で薄まるだけだ。知識の問題は、容量の問題ではなく、置き場の問題である。

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

知識の種類置き場と、その代償
今すぐ使う作業集合窓（熱い層）に常駐させる。窓は小さく高く、長い文脈の真ん中が抜ける7
大きくて出番の少ない知識検索（RAG）で倉庫から取り出す。取り出しの精度で頭打ちになる
セッションをまたぐ要点要約して明示的に残す。要約は情報を落とし、悪い要約は誤りを持ち越す

この三択は、速い有限のストアと遅い倉庫を積む「メモリ階層8」そのものだ。その写像と、なぜ窓を広げるだけでは足りないのか（実効的に使える窓は宣伝される長さより短く、例外的な一モデルでは階層を組まず窓拡大で足りることもある9）は、後の「記憶の外部化」の回で背骨として扱う。ここで委譲の側から言えるのは、知識の置き場もまた、容量任せにせず引くべき線だということだ。

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

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

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

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

出典9件

  1. X. Wang, J. Wei, D. Schuurmans, et al., “Self-Consistency Improves Chain of Thought Reasoning in Language Models,” ICLR (2023). 複数の推論経路をサンプルして最頻の答えを取ると、算術・常識推論のベンチマークで精度が上がると報告する。ただし原典は逐語 “self-consistency can be applied only to problems where the final answer is from a fixed answer set” と適用範囲を限り、限界として計算コスト増を挙げる。またサンプル間の一致率の低さを「モデルの自信の低さ」の指標に使えるとする（逐語: one can use low consistency as an indicator that the model has low confidence）。出力分散そのものは測定していない（“variance” は本文に一度も現れない）。 https://arxiv.org/abs/2203.11171 ↩

  2. D. H. Autor, F. Levy, R. J. Murnane, “The Skill Content of Recent Technological Change: An Empirical Exploration,” Quarterly Journal of Economics 118(4) (2003); NBER Working Paper 8337. ルールに落とせる定型（ルーチン）タスクと、判断の要るノンルーチンタスクを分ける定式化——機械が代替してきたのは前者だとする。 https://www.nber.org/papers/w8337 ↩

  3. D. H. Autor, “Polanyi’s Paradox and the Shape of Employment Growth,” NBER Working Paper 20485 (2014). 明示的に書き下せない技能はコード化＝自動化しにくい、という定型化の限界（「我々は語れる以上を知っている」）を論じる。ただし同論文はそこで止まらず、「我々がルールを語れない課題を計算機化する二つの道」（逐語: tasks for which we “do not know the rules”——主語は機械ではなく我々である）を挙げて、環境制御はパラドックスに屈するが機械学習はそれを迂回しようとする——“The second, machine learning, attempts to make an end-run around it.” ／ “Machine learning potentially circumvents this problem.” ——と、迂回の試みを（決着は未了として）論じている。本記事はこの限界を「仕様が固定できないほど定型化が難しくなる」費用の線として用い、原理的な不可能とはしない。 https://www.nber.org/papers/w20485 ↩

  4. J. Bezos, “2015 Letter to Shareholders,” Amazon (2015). 取り返しのつく決定＝通っても戻れる「両開きのドア（Type 2 / two-way door）」（軽い手順でよい）と、取り返しのつかない「片開きのドア（Type 1 / one-way door）」（慎重な承認を要する）を分ける、という決定の類型。原典（2015年株主書簡）に “Type 1” 決定＝ “one-way doors” として記述がある。 https://s2.q4cdn.com/299287126/files/doc_financials/annual/2015-Letter-to-Shareholders.PDF ↩

  5. obra/superpowers v5.1.0（2026年5月4日リリース）の skills/brainstorming/SKILL.md と skills/subagent-driven-development/SKILL.md を直読。Claude Code 向けのスキル集。前者は、設計を節ごとに示して承認を取れ（“get user approval after each section”）、書き上げた仕様は利用者に読んでもらってから次の工程へ進め（“User reviews written spec”）と手順に組み込む。後者は実行中の伺いを明示的に禁じ（“Do not pause to check in … Should I continue? prompts and progress summaries waste their time”）、委譲先が詰まったときの手当てを、コンテキスト追加→モデル強化→タスク分割→“If the plan itself is wrong, escalate to the human” の順で定義する。実行時にコードを止める機械的な強制は持たない（フックは SessionStart のコンテキスト注入のみ）＝守らせる力は読み手の側にある文章である。なおこの第4項は現行版に無い。2026年8月12日公開の v6.3.0 は、計画の誤りを人へ上げる代わりに「是正を裁定し、台帳に記し、その裁定を添えて投げ直す」ことを呼び出し側自身に求め、人を呼ぶのは、元に戻せない操作か破壊的な操作、セキュリティに触れる操作、作業ツリーの外へ出る副作用、そしてどの選択肢も推測にしかならないほど壊れた計画——の四つに限った。設計の承認と仕様レビューの門のほうは、この版にも残っている。 https://github.com/obra/superpowers/blob/v5.1.0/skills/brainstorming/SKILL.md https://github.com/obra/superpowers/blob/v5.1.0/skills/subagent-driven-development/SKILL.md https://github.com/obra/superpowers/blob/v6.3.0/skills/subagent-driven-development/SKILL.md ↩ ↩2 ↩3

  6. everything-claude-code（affaan-m/ECC）の rules/common/agents.md “Delegation Completion Contract”。“Your final message IS the deliverable. Never end your turn with waiting for background agents — a spawned task is not a completed task. … Fire-and-forget delegation is forbidden. … depth is an outcome, not a plan.” 引くのはこの規約テキストであって、同プロジェクト全体の推奨ではない（強いのはフック層で、外周のスキル群は量が先に立つ）。 https://github.com/affaan-m/ECC/blob/main/rules/common/agents.md ↩

  7. N. F. Liu, K. Lin, J. Hewitt, et al., “Lost in the Middle: How Language Models Use Long Contexts,” TACL, vol. 12 (2024). 長い文脈でも中央の情報は取りこぼされ、容量拡大でなく配置が性能を左右すると示す。 https://arxiv.org/abs/2307.03172 ↩ ↩2

  8. P. J. Denning, “The Working Set Model for Program Behavior,” Communications of the ACM, vol. 11, no. 5 (1968). 速い有限のストアに「今使う集合」だけを載せる、という古い規律。 https://doi.org/10.1145/363095.363141 （著者版PDF: https://denninginstitute.com/pjd/PUBS/WSModel_1968.pdf ） ↩

  9. C.-P. Hsieh, S. Sun, S. Kriman, et al., “RULER: What’s the Real Context Size of Your Long-Context Language Models?,” arXiv:2404.06654 (2024). 評価した17モデル中、32Kで十分な性能を保てたのは約半数にとどまる。単純な検索テストでの高得点は表層的で、文脈長が伸びると上位モデルでも精度は落ちると報告する。なお同論文は階層設計と比較していない。本文の「例外的な一モデル」とは17モデル中1本（RULERの基準を試験上限の128Kまで満たし続けた Gemini-1.5-Pro）のことで、そこから窓拡大が階層の代わりになると読むのは本稿の見立てである。 https://arxiv.org/abs/2404.06654 ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。