AI導入の壁は、AIの能力ではなく「人間が管理できる状態空間の大きさ」
The Wall in AI Adoption Is Not AI Capability — It Is the Size of the State Space Humans Can Manage
著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info)
生成AIを業務に入れる話は、長いあいだ「AIに何ができるか」を中心に進んできた。
つまり、どこまでコードが書けるか、どこまで調べられるか、どれだけ長い文書を読めるか、ということだ。
最近、自分で小さな開発をしていて、詰まる場所が変わってきたと感じた。
AIはコードを書けるし、読める。だが作業が止まるのは、人間である自分が全体の状況を追えなくなったときだった。
1. AIを増やすと、「できること」は増える
人間とAIが一対一だったころ
生成AIの最初の使い方は単純だった。人間がAIに頼み、AIが成果物を返す。
間にあるのは一回のやり取りで、何が起きたかは画面を見れば分かった。
接続できるものが増えた
今は、AIに検索させ、コードを書かせ、別のAIにレビューさせることができる。
MCPのような仕組みで外部ツールにつなぎ、複数のエージェントを並行して動かすことも現実的になった。
理屈の上では、つなぐほどできることは増える。ただ、増えるのは能力だけではない。
2. 「状態」も一緒に増える
AIやツールを一つ足すと、それが持つ状態も増える。コンテキスト、作業途中の判断、ローカルファイル、外部サービス側のデータ、キャッシュ、権限、実行結果、他のエージェントとのやり取り。
二つのAIをつないだ場合、増えるのはAI一体分では済まない。Aの状態、Bの状態、AとBが共有している状態、AがBについて持っている理解、BがAについて持っている理解。そこに、人間に見えている状態が加わる。最後のものが前の五つと一致している保証はない。
接続点が増えるほど、人間が追わなければならないものは増える。これは処理能力の問題というよりも、可観測性の問題である。
この記事で「状態空間」と言っているのは、人間が追わなければならない状態、依存関係、判断の総量くらいの意味である。
3. 「今何が起きているのか」が分からなくなる
このシステムが大きくなると、難しくなるのは「何ができるか」より「今何が起きているか」のほうになる。
この判断は誰がしたのか。このファイルを変えたのはどのエージェントか。その処理は何を根拠に走ったのか。最新の仕様はどこにあるのか。このAIを止めたら何が壊れるのか。失敗したら、どこまで巻き戻せばいいのか。
どれもAIの性能が足りないから起きることではない。それぞれのAIが十分に動けるから、システム全体の状態が人間の把握できる量を超えていく。
物理の理論が次元を足して多くを説明できるようになっても、それを人間が直観で扱えるとは限らない。AIシステムにも少し似たところがある。
4. 管理AIを置くという案
AIが増えて管理しきれないなら、管理するAIを置けばいい。これは解決策としてよく出てくる案で、実際かなり有効である。ただし、問題を完全には消さない。
ログの集約、異常検知、状態の要約、タスクの振り分け、進捗の確認。こうした作業にAIは向いている。
ただ、管理AIを置くと問題は一段上に移るだけなのだ。AI群の上に管理AIがいて、その上に人間がいる構成では、管理AIが正しく管理しているかを誰が確かめるのかが残る。
管理AIを見張るAIを置けば、もう一段増える。どこかで人間が確認する層は、実は消えないのである。
5. 解決策：状態を「人間が判断できる形」に縮める
個人的には、上記のように管理を丸ごとAIに渡すより、AIが扱っている大きな状態を、人間が理解できる形に縮めるほうが現実的だと思う。
人間が内部状態をすべて理解する必要はない。意思決定に要るのは、現在の仕様、変更内容、判断が必要な箇所、テスト結果、異常くらいである。
大きなAI内部状態
↓
人間が読める中間表現
↓
判断
という流れを、どこかに意図して作っておくのである。
6. 実例：Claude Code、plan.md、Codex
作ろうとしていたもの
最近、ブログ記事公開予定から、別のSNSの予約投稿を準備するUserscriptを作っていた。
既存コードはすでに大きく、Ghost側だけでもかなりの量があった。
設計と実装を分けた
そこで作業を次のように分けた。
- Claude Codeに既存コードを読ませる
- 実装はさせず、設計だけさせる
- 設計結果をMarkdown（plan.md）に保存する
- 自分がplan.mdを確認する
- Codexにplan.mdを渡して実装させる
- 自分がgit diffとテスト結果を確認する
Claude
↓
plan.md
↓
人間
↓
Codex
↓
git diff
↓
人間
ClaudeとCodexは直接つながず、間にファイルと人間を挟む形とした。
plan.mdが果たしたこと
Claude Codeは、既存コード、テスト、UI構造、リスク、通信方式、実装順序まで、かなりの量を読んだ。その状態をそのままCodexに渡す必要はなかった。Claudeが考えた結果を一枚の文書にまとめておけば、Codexはその文書とコードだけを読めばいい。自分もClaudeとの長い対話履歴は追わず、plan.mdを読めば済んだ。
plan.mdはドキュメントであると同時に、AIの間で膨らんだ状態を一度縮める場所になっていた。ここでは、この状態を仮に「圧縮点」と呼んでみたい。
圧縮点に置いた文書は、その時点の正本にもなる。仕様で迷ったときに戻る先が、plan.mdに決まっている。
7. 接続できることと、管理しやすいこと
ここで、エンジニアならこう考えるかもしれない。
MCPやエージェント間通信を使えば、Claude、Codex、GitHub、外部ツール、管理AIを相互につなぐ構成も組めるじゃないか。技術的には可能だし、それ自体に問題があるわけでもないじゃないか。
ただ、よく考えてみてほしい。
接続を増やすと、隠れた状態、暗黙の依存、実行順序、権限関係、障害点も一緒に増える。システムとしては高度になっても、人間から見て追えなくなれば運用は難しくなる。今回の開発のように、つながないことを選んだ部分のほうが効くこともあるのである。
8. 人間が見る「境界面」の数
AIシステムを評価するとき、AIが何体いるかより、人間がいくつの境界面を見なければならないかを数えるといいのかもしれない。
AIを10個使っていても、人間が確認するのがplan.md、git diff、テスト結果の三つだけなら、管理できる見込みは高い。逆に、AIが3個でも、それぞれが独自に状態を持ち、勝手にやり取りし、どれが正本か分からないなら、管理は難しいだろう。
9. AIに頼む仕事を変える
AIに「全部管理しておいて」と頼むより、「判断できる形に整理して見せて」 と頼むほうが、人間との役割分担として安定するはずである。
要約する。差分を出す。異常だけを出す。判断が必要な点だけを提示する。AIには大きな状態を縮めて見せる仕事を任せ、最終的に人間が責任を持つ判断点は、人間から見える形に残す。
10. 何を縮め、どこを見るか、という問題
これまでのAI導入の議論は、主に「AIに何ができるか」だった。能力が十分に上がると、次に問われるのは、そのAI群を人間が管理できるかである。これ自体は散々言われてきたことだ。
AIやツールを足せば、システムの能力は増え、状態空間も広がる。人間の認知帯域は同じ速さでは広がらないことを意識した上で、利用設計で決めておくべきなのは、どこで状態を圧縮し、どこを人間の観測点にし、何を正本として固定するか、だと思う。AI導入の壁は、AIの能力より、人間が管理できる状態空間の大きさのほうにあるのだろう。
☕️よかったらコーヒー一杯。 https://buymeacoffee.com/mink_obs
著：霧星礼知(min.k) / リサーチ・構造支援：Claude Opus 5.5、ChatGPT / AI-assisted / Structure observation
For international readers
As AI models grow more capable and can be chained together through tools, MCP connections and multi-agent setups, the bottleneck in AI adoption is shifting. Adding agents and tools expands what a system can do, but it also expands its state: context, intermediate decisions, files, caches, permissions, dependencies, and the question of which version is authoritative. Human cognitive bandwidth does not grow at the same rate.
Placing a "manager AI" on top helps with log aggregation, anomaly detection and summarization, but it only moves the problem up a level: someone still has to verify the manager. The author argues that a more stable approach is to compress the AI-side state into representations humans can judge.
A personal example: while building a userscript that prepares scheduled X posts from Ghost's publishing schedule, the author had Claude Code read the existing code and produce only a design, saved as plan.md. After human review, Codex implemented from that file, and the human checked git diff and test results. The two AIs were never connected directly. The Markdown file served as a "compression point" and as the single source of truth.
The proposed metric is not how many AIs a system uses, but how many interfaces a human must watch. The design questions that matter are where to compress state, where to place human observation points, and what to fix as the source of truth.
Keywords
AI adoption, state space, observability, multi-agent systems, MCP, human-in-the-loop, Claude Code, Codex, source of truth, cognitive bandwidth, operations design
AI導入、状態空間、可観測性、マルチエージェント、MCP、管理AI、圧縮点、正本、Claude Code、Codex、plan.md、git diff、認知帯域、運用設計