AI・信頼性・評価

AI協働の役割分担：人・指示・仕組みを3つの問いで仕分ける

2026/7/20 （更新: 2026/10/12）

🤖 AIを使用して執筆

三つの問いで仕分ける

仕分けは、一つの軸ではなく、順に効く三つの問いで決まる。上から順に当てて、答えが担い手を決める。

一つ目の問いは、機械が判定できるかである。 その仕事の正しさは、型・境界・不変条件のように、機械が自動でチェックできる性質に落ちるか。この考え方自体は新しくない。Meyer の「契約による設計（Design by Contract）」は、事前条件・事後条件・不変条件を機械可読な契約として書き、破れば機械的に検出できるようにする設計法だ¹。判定できるなら、その性質が破られていないかの見張りは機械に任せられ、人の目に頼らずに済む。ただし限界がある。Naur は、プログラムの本質は書き手が抱く「理論」であり、それはプログラム本文にも文書にも汲み尽くせないと論じた。この「理論」は Ryle に由来する概念で、Naur はその解説の結びで、理論として保持された知識は原理的に規則として表現できず、拠り所となる類似性は基準としても表現しえないと書いている²。規則にも基準にも落ちないものが残るのなら、機械の判定に落ちない仕事が残る。だから最初の問いは、落ちるものと落ちないものを分ける関門になる。

二つ目の問いは、可逆かである。 機械の判定に落ちないとき、次に問うのは「外したとき戻せるか」だ。可逆性で判断の重みを変えるのは、Amazon が経営判断に据えた原則でもある。Bezos は決定を「一方通行の扉」（不可逆・ほぼ取り返せない）と「両開きの扉」（可逆・戻せる）に分け、後者に重い手続きを課すと、動きが遅くなり、無思慮にリスクを避け、実験が足りなくなって、結果として発明力が落ちると説いた³。戻せる仕事なら、外れに気づければ事後に直せる。速く任せて、あとで検証すればいい。もっとも、戻せる仕事でも失敗が黙って通るなら、事後の検証が外れを見落とし、戻す機会は来ない。そうした仕事の検証は、後で述べる人手の当て方と同じく、確かめる人がそこだけに注意を割ける形で行う。ただし Bezos が速く決めてよいとしたのは high judgment individuals or small groups であって、担い手を問わない委譲ではない³。戻せない仕事に、この速さは使えない。Bezos 自身も同じ段落の脚注で、不可逆な決定を軽い手続きで決める会社は大きくなる前に絶滅する、と逆側を書いている³。ここで言う不可逆には「戻せない」と「外したとき被害が大きい」の両方を含める。対外送信・破壊・秘密の露出のように、取り消せず影響も広いものが、二つ目の関門で止まる。

三つ目の問いは、静かに壊れるかである。 最後に問うのは、失敗が「赤く出る」か「黙って通る」かだ。エラーで即座に止まる失敗は、気づいて直せる。契約による設計でも、監視を有効にしていれば表明違反は例外として送出され、しかも「特別なケースではなく常にソフトウェアのバグの顕れ」だと原典は断じている¹。この区別は新しくない。後述する安全設計の古典も、許可を明示する側の誤りは「速やかに検出される」が、除外を明示する側の誤りは「通常の利用では気づかれないまま通る」と述べ、それを既定を安全側に倒す理由に挙げている⁴。厄介なのは、正しく見えたまま通り抜ける失敗である。静かな破壊は、戻す前に気づけない。しかも人間は、自動化の出力を過信して監視を緩めやすい。Parasuraman と Manzey は多数の実証研究を統合してこれを示したが、条件も明示している。手作業が自動化された作業と注意を奪い合う、複数タスク負荷の下で起きやすい、という条件だ⁵。静かに壊れる仕事を「人が最後に見ればいい」で受けると、確認役が他の作業と注意を奪い合うかぎり、その確認役自身が故障を見落としやすい条件に置かれる。だから静かさは、人手をどこに温存すべきかを決める問いになる。

戻せないが失敗が赤く出る仕事は、壊れた瞬間に分かっても元には戻らない。こちらは実行の前に承認で止める機構へ流し、常時の見張りの人手は充てない。ただし止める仕組みは機構でも、通すかどうかを決めるのは人である。Parasuraman と Manzey の論文は、誤った推奨にそのまま従う誤りも automation bias に数え、二人で重ねて監視させてもその強さは変わらなかったと報告している⁵。

三つの担い手へ流す

三つの問いへの答えが、仕事を三つの担い手のどれかへ流す。担い手は縛る力の強さで並ぶ。強い順に、機構・指示・人手だ。

機構は、コード・型・テスト・権限で構造的に縛る。「気をつける」ではなく「できないようにする」。最小権限と安全側に倒れる初期値（fail-safe defaults）を安全設計の基本原則としてまとめた Saltzer と Schroeder の古典が、その根拠だ⁴。機械が判定できる性質は、ここへ流す。機構は最も強く、人の注意力を消費しない。

指示は、言葉で頼み、相手が気をつけると約束して守る運用だ。レビューする、手順を踏む、危険な操作の前に確認する。機構より弱い既定である点は正直に見ておく必要がある。約束は破れる。先ほどの論文は、判断支援の推奨を確かめよと人間の操作者に明示的に指示しても automation bias は防げない、と結論している⁵。同論文はこれを熟練者にも、個人にもチームにも現れる頑健な現象として報告している⁵。指示が「静かに緩む」という言い方と、人の注意の偏りを AI に重ねる見方はここでの類推で、原典が示したのは人への指示では防げないという事実である。AI への指示についても、遵守の保証が無いことは後の節で挙げる製品文書と研究が示している⁶⁷。機械の判定に落ちないが可逆な仕事、つまり外しても戻せるものは、指示や、事後検証つきで AI に任せる領域になる。

人手は、希少な人間の判断だ。最も高く、遅く、スケールしない。安く速い担い手が増えた今、人手は乱用でなく温存の対象になる。三つの問いがすべて「危ない」側に振れた仕事、つまり機械の判定に落ちず、戻せず（外せば影響も広く）、静かに壊れる仕事にこそ、人間の判断を充てる。ただしそれは「最後にもう一目見る」ことではない。他の負荷を外し、そこだけに注意を割ける形で当てる、という意味だ⁵。ここを機構や指示で代用しようとすると、機械判定に落ちない仕事を、判定できないツールに預けることになる。強く縛っているつもりで、実は何も縛っていない。

配達は機構、遵守は指示

三つの担い手は、縛る力の強さで並べた。この並べ方は、暗黙に一つのことを仮定している。届けることと守らせることを、同じ担い手が引き受けるという仮定だ。機構なら、検査はコードが走らせ、落ちれば止まる。指示なら、人が読み、人が気をつける。だが実在のツールを見ると、この二つは分かれる。

分けて見るには、軸を二本立てればいい。配達は、その決まりごとが相手の目の前に確実に届くかどうか。遵守は、届いたものに従うことを構造的に保証できるかどうかだ。機構は両方を持ち、純粋な指示はどちらも持たない。実際に多いのは、配達だけを機構が引き受け、遵守は指示のままという中間の形である。本稿ではこれを 「機構が配達する指示」（短く: 機構配達の指示）と呼ぶ。システム設計で言う advisory（勧告的）に近い。advisory lock は、ロックの仕組みを備えるが、取りに行くかどうかを各プロセスの作法に委ねる。仕組みは在る。強制は無い。

例は、いま広く使われているツールの中にある。Claude Code は、規約ファイル（CLAUDE.md）を毎回のセッション冒頭に自動で読み込む。だが Anthropic 自身が公式ドキュメントで、CLAUDE.md はシステムプロンプトの後にユーザーメッセージとして届くだけで、厳密な遵守の保証は無いと書いている。行為そのものを止めたいならフックを使え、とも案内している⁶。Cline の Focus Chain は、依頼を受けた時点で手順の一覧を作り、既定では6メッセージごとにそれをコンテキストへ入れ直す。同社は狙いを、逸れた注意を本筋へ引き戻すことだと説明している⁸。スキル集 superpowers が定義するフックは、セッション開始時に指示文書の全文を冒頭へ注入する一つだけで、実行時に操作を止めるフックは無い⁹。三つとも、配達は機械が引き受ける。従うかどうかは、受け取った側が決める。

この形が厄介なのは、失敗が可視化されないことだ。純粋な指示は「書いてあるが読まれなかった」という形で失敗する。読まれなかったことは、後から辿れる余地がある。純粋な機構は「赤く落ちる」という形で失敗し、落ちた瞬間に分かる。機構配達の指示は、そのどちらでもない。配達はふつう成功するので「届かなかった」とは言いにくく、止める力は無いので、無視しても何も起きない。無視が可視化されない。残るのは配達の記録だけだ。ただし配達そのものも静かに落ちることがあり、Claude Code の公式ドキュメントは、まず /context で、起動時に読み込まれるはずの規約ファイルが一覧に在るかを確かめよ、そこに無ければ Claude には見えない、と案内している⁶。進捗の一覧を持つツール（Focus Chain）もあるが、それを書き込むのは受け取った側なので、遵守の失敗はそこにも現れない。マルチエージェントの失敗を分類した研究も、徹底的な検証を指示されている検証役の多くが、実際にはコンパイルが通るかや TODO の残りを見るだけの表層的な確認しかしていなかったと報告している⁷。

だから仕分けの答えは変わらない。配達をどれだけ機械化しても、遵守を読み手に任せるかぎり、その仕事の担い手は指示のままだ。注入したから守られる、とは読まないこと。機械判定に落ちる性質をここで代用すると、機構を持ったつもりで指示を運用していることになり、しかもそのズレは赤く出ない。

難所は、型の外ではなく当てはめにある

型があることと、型を正しく当てられることは、別だ。難所は型の外側にあるのではない。どの仕事がどの問いのどちら側に落ちるかを見極める、その当てはめにある。マルチエージェントの失敗を分類した研究は、失敗の相当部分がモデルの限界ではなく、仕様の曖昧さや連携設計の欠陥に由来すると報告している。同じ分類の三つ目の柱は検証の失敗、すなわち検出も訂正もしない検証と、早すぎる打ち切りである⁷。同じ論文は、基盤モデルの能力向上だけでは分類の全体は解けないだろうと述べ、同じモデルのまま設計を変える介入で最大 15.6% の改善を報告している⁷。本稿の言う当てはめの失敗は、たとえば次の形をとる。可逆だと思って任せたものが、実は戻せない。判定できると思ったものが、実は判断を含んでいる。

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