title: "AIエージェントは人を解放しない——仕事が「認知的により管理的」になる時代に、私たちが設計すべきもの"
topic: "AIエージェント時代の認知的管理負荷とDecision Design"
concepts:
- AIエージェント
- Decision Design
- Decision Boundary
- Human Judgment
- AI Governance
- Judgment Architecture
author: "Ryoji Morii(森井亮史)"
organization: "Insynergy Inc.(Insynergy株式会社)"
language: "ja"
content_type: "note article"
framework: "Decision Design / Decision Boundary"
AIは速くなった。なぜ、人間は楽にならないのか
AIエージェントは、もう「賢いか賢くないか」の議論の段階を越えた。
コードを書き、メールを返し、データを整理し、調査レポートを出す。しかも複数を同時に動かせる。
それなのに、現場の人間はむしろ消耗している。
この記事は、その違和感の正体について書く。
AIエージェントの並列実行は、期待されたほどには人間を解放しない。仕事は減るのではなく、むしろ「認知的により管理的」になる。そして、その増加する負荷に対して、いま手元にある言葉——Governance、DX、Automation、AI ethics——はどれも微妙に足りない。本稿が扱うのは、そこに足りていない設計概念についてである。
並列実行で増えるのは、実行ではなく監督である
AIエージェントを複数同時に走らせると何が起きるか。
実行は並列になるが、人間はそうはいかない。
Djangoの共同開発者であり、"prompt injection" という言葉の提唱者でもあるSimon Willisonは、2026年4月に公開されたLenny Rachitskyのポッドキャスト "An AI state of the union" の中で、この現象を率直に語っている。コーディングエージェントを4つ並列で走らせていると、25年のエンジニア経験をフルに使ってようやく使いこなせる、それくらい認知的に重い作業で、午前11時にはもう消耗しきっている——と。書いているのはAIなのに、人間がぐったりする。なぜか。人間が一度に頭の中に保持できる文脈には、物理的な限界があるからだ。
エージェントAは設計を直している。エージェントBはテストを走らせている。エージェントCは別ブランチでリファクタしている。エージェントDはさらに別の問題を追っている。この四つを「同時に理解しておく」作業は、四つを自分で書くより疲れる。
なぜなら、自分で書いているときは、頭の中で文脈が一本につながっている。
並列監督では、四本の文脈を同時に保持し、どれが噛み合っていて、どれがズレているかを、自分の外側から観測しなければならない。これは単なるマルチタスクではなく、複数の意思決定ラインを頭の中で同時に走らせる作業である。
実行はAIに渡せる。
しかし、統合、評価、例外時の引き取りは、いまのところ人間の仕事として残る。
結果として、人間の役割はタスクの実行者から、並列に走る意思決定の監督者・統合者・最終責任者へと押し上げられる。仕事は減っていない。種類が変わり、そして重くなっている。
組織側の設計負荷という、もうひとつの現実
この問題は、個人の認知負荷だけにとどまらない。
BoxのCEO、Aaron Levieは、TechCrunchのインタビュー "Box CEO Aaron Levie on AI's 'era of context'"などで、エンタープライズにおけるAIエージェント導入の難しさを繰り返し指摘している。エージェントを入れるために実際に必要なのは、モデルの差し替えではなく、社内に散らばる非構造データの整備、既存ワークフローの解像度の高い理解、基幹システムとの接続、業務プロセス自体の組み替え、そしてエージェントの出力に対する人間側の監督と検証の仕組みの設計である、と。
つまり、本当のボトルネックはモデル性能ではなく、組織側の設計負荷のほうにある。
ここでも、焦点は同じ場所に戻ってくる。
AIは何をどこまでやるのか。
人間はどこで介入し、何をもって承認するのか。
誰が、最終的な判断責任を引き受けるのか。
この線引きを放置したままエージェントを増やしても、組織の中で起きるのは自動化ではない。監督工数と、あいまいな責任の増殖である。
制度の側も、同じ場所を見ている
この論点は、個別企業の実務だけでなく、制度の側からも見えている。
日本政府は、自律的に動くAIエージェントに対して、誤作動やプライバシー侵害のリスクを念頭に、「人間の判断を必須とする仕組み」を開発企業などに求める方向で議論を進めている。総務省・経済産業省が共同で策定している AI事業者ガイドライン1.2版 にも、人間の関与と責任の所在を明確にしようとする方向性が織り込まれている。
ここで注意したいのは、制度が言っているのは「AIを止めろ」ではないということだ。
むしろ、「人間の判断をどこに置くかを、明示せよ」に近い。
AIの出力に対して、誰が、どの段階で、どの権限で判断を差し込むのか。
それを運用側に委ねきるのではなく、仕組みとして埋め込めという要請である。
これは現場の疲弊と、ちょうど同じ場所を指している。
個人が疲れているのも、組織が立ち往生しているのも、制度が注意深くなっているのも、すべて「判断をどこに置くか」が未設計だからだ。
論点が、静かに移っている
ここまでを並べてみると、論点の輪郭が変わっていることに気づく。
数年前までの論点は、「AIはどこまで賢くなるか」「どの業務を自動化できるか」だった。
いま起きているのは、別の問いである。
どこまでをAIに任せ、どこからを人間が引き受けるのか。
その線は、誰が引くのか。
引き取った人間は、何を根拠に引き受けるのか。
これは、モデル性能の問題ではない。
組織の中で、判断が誰のどこに置かれているか、という構造の問題である。
既存の言葉では、少しずつ届かない
この構造の問題に、既存の言葉をあてはめてみる。するとどれも、微妙に届かない。
AI Governanceは、リスクと統制の言葉で考える。何を禁止し、何を監査し、どこに責任を置くか。重要だが、これは主に「事後に説明できる状態をつくる」ための枠組みだ。日々の運用の中で、AIエージェントの一つひとつの出力に対して、人間がどこでどう介入するかまでは決めてくれない。
DXは、業務のデジタル化と変革を扱う。プロセスをつなぎ、データを流し、意思決定を速くする。しかし、DXの語彙は「速く、つなぐ」側に最適化されていて、「どこで止めて、誰に返すか」を主題にはしない。判断の境界を引くことは、DX的にはしばしば「摩擦」に見えてしまう。
Automationは、さらに手前にいる。どの作業を機械にやらせるかの言葉であり、人間の判断構造そのものを設計対象にはしない。RPAにせよ、エージェントにせよ、「何を自動化するか」までは言えるが、「何を自動化してはいけないか」は、外側の設計に委ねられている。
AI ethicsは、方向を指し示す。公平性、透明性、人間中心。大事な方向だが、原則はそのままでは運用にならない。「公平であれ」と書いても、月曜朝のエージェント運用の中で、どの承認フローに誰を立たせるかは決まらない。
どれも間違っていない。
しかし、どれも、いま現場で起きている「認知的により管理的になっていく仕事」に対する設計言語にはなっていない。
まだ、名前がない
ここで正直に書く。
AIエージェントの並列実行で何が起きているかを描写する言葉はある。
それをガバナンスの観点から点検する言葉もある。
倫理の観点から位置づける言葉もある。
しかし、「人間の判断を、どこにどう置くか」を設計することそれ自体を主題にする言葉が、日本語にも英語にも、まだ十分に揃っていない。
足りていないのは、個別の施策ではない。
エージェント、ガバナンス、自動化、倫理——これらを横断して、「判断の線引きそのものを設計する」ための共通言語である。
問題の形は、だいぶ見えてきた。
輪郭もはっきりしてきた。
ただ、それにまだ名前が与えられていない。
ここから先に、その名前を置く
ここまで書いてきた問題——AIは速いのに人は楽にならず、仕事が認知的により管理的になり、既存の Governance / DX / Automation / AI ethics では横断しきれない問題——には、私の中で一つの呼び方がある。
それを、Decision Design(判断の設計) と呼んでいる。
Decision Designは、判断という行為そのものを設計対象とする思想である。
その中心には、Decision Boundary(判断の境界) という概念を置く。
誰が決めるのか。
どこまでをAIに任せ、どこからを人間が引き受けるのか。
その線を、運用の成り行きに委ねたまま放置せず、意図的に引き直し続けること。
それが、Decision Designという言葉で私が指している中身である。
有料記事では、この Decision Design と Decision Boundary を、もう一段具体的に展開する。
何を設計し、何を設計しないのか。どの問題に応答する概念なのか。そして、明日から組織で動かすとしたら、どう実装するのか——判断棚卸しから、境界設定、エスカレーション、記録、レビューまで、具体的な設計ステップに落として書く。
AIエージェントを増やす前に整えるべきは、モデルではない。判断の構造のほうである。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。