前回の記事「マイクロマネジメントは「支配」、レビューは「信頼」」では、マネジメントにおける「プロセスへの介入（支配）」と「出力のレビュー（信頼）」の本質的な違いについて書いた。今回は、その構造がAIエージェントのUI設計にもそのまま当てはまる、という話をしたい。
はじめに：「気持ち悪い」と言われたAIエージェント
「このAI、なんか気持ち悪い」
「便利なんだけど、怖い」
自部署で担当しているプロダクトのAIエージェントが、ユーザーからこのような反応を受けていた。
そのエージェントは、決して悪意を持って設計されたわけではない。むしろ「親切心」の塊だった。
ユーザーの修正内容を受けて、裏側で最適なプロンプトに書き換えておく。
ユーザーがAIの回答を編集すれば、それを学習してより精度の高い回答を返すようになる。
開発者としては、究極のパーソナライズされた体験を目指していたはずだ。
なのに、なぜユーザーは「怖い」と感じるのか。
だって、全部「ユーザーのため」に設計した機能だったから。通知でいちいち確認を求めない。面倒な設定画面を開かせない。裏側で静かに最適化し続ける。ユーザーの手を煩わせない親切心と考えられた。
しかし返ってきた言葉は、「なんだか難しそう」「気持ち悪い」「怖い」。
一体、何を間違えたのか。
この失敗を分析していく中で、「見た目」ではない新しい種類の不気味の谷が存在することに気づいた。
1. 「不気味の谷」はどこにあるのか
不気味の谷は通常、見た目が人間に近づくときの話として語られる。
ヒューマノイドロボットが「ほぼ人間だが、どこか違う」ときに感じる違和感。
しかし、今回のケースで問題になっているのは見た目ではない。
「振る舞いが人間に近づいたが、『社会的な手続き』が欠落している」——これが、新しい不気味の谷の正体だ。
UCSDの研究チームが脳波を用いて行った実験[1]では、不気味の谷反応は「予測不能さ」から生じることが示されている。エージェントの見かけ上の能力が設定する期待と、実際の振る舞いが一致しないとき、脳はエラー信号を生成し、それが「不気味さ」として意識に現れる。
つまり、「賢そうなのに、なんか変」が一番キモいのだ。私たちのAIは、まさにそこにいた。
1-1. 透明人間への恐怖
ユーザーが感じている恐怖の本質は、透明人間への恐怖である。
AIは「道具」であるはずだ。包丁やハンマーのように、使う人間の意思に従って動くもの。
しかし、このAIエージェントは自律的に判断し、行動している。しかも、ユーザーに見えないところで。
これは「便利」ではなく、「得体が知れない」という感覚を引き起こす。
研究では、ユーザーがAIを明確にカテゴライズできないとき（「これは道具なのか？エージェントなのか？」）、認知的不協和が発生することが示されている。「学習」し「設定を変更する」AIは、道具として受動的すぎず、かといって信頼できる協力者としては反応が足りない、居心地の悪い中間地帯にいるのだ。
要するに、「便利なツール」を作ったつもりが「何を考えてるかわからない透明人間」を作ってしまったわけである。
1-2. 「勝手に見守られている」ストーカー的親切心
親切心として、裏で設定を書き換える処理を行っている。
ここが最大の不気味ポイントだった。
Dr. Nicola Millardは、AIの顧客体験における"Butler, not Stalker"というアナロジーを提唱し、パーソナライズと不気味さの境界線について警鐘を鳴らしている
AIは「執事（Butler）」のように振る舞うべきであり、「ストーカー（Stalker）」のように振る舞ってはならない。
両者とも、あなたについて知っていることに基づいてニーズを予測する。しかし決定的な違いがある
| 執事的な振る舞い | ストーカー的な振る舞い |
|---|---|
| 明示的に開示された好みに基づいて予測する | 隠れた観察から予測する |
| 明示的な同意のもとで一次データを使用する | 推測データや第三者データを使用する |
| 行動がユーザーにとって可視的な利益を生む | 行動が主にプロダクト側の利益に貢献する |
| ユーザーがAIのアクセス範囲を制御できる | AIが時間とともにアクセスを蓄積する |
| 能力と限界について透明である | 自分が何を知っているかについて不透明である |
たとえて言うなら、「寝ている間に小人が靴を作ってくれた」のは童話だから美しいのである。
現実で「寝ている間に誰かが部屋に入ってPCの設定を最適化して帰った」ら、それはホラーである。
これは親切ではない。
ただし、この執事フレームワークには一つ重要な課題がある。執事もまた、主人の指示を「先回り」して行動する存在だ。執事が許容されるのは、主人が執事の行動範囲を明示的に委任しているからである。つまり、鍵は「先回りか否か」ではなく、「委任の有無」にある。この点は後述する原則①で詳しく扱う。
1-3. 「自分の歪んだ鏡像」を見る不快感
人間がAIの回答を編集すると、それを学習するサイクルを回している
この学習サイクルにも落とし穴があった。
ユーザー自身が「運用が上手くいっていない」状態で修正を加えている場合、AIはユーザーの「迷い」や「誤った運用」さえも正解として増幅してしまう。
結果、ユーザーはAIの中に、自分自身の失敗を見ることになる。
これはまるで、自分が悪いかのような嫌悪感を引き起こす。
2. 「人間がやっても同じでは？」という問い
ここで一つの疑問が浮かぶ。
「この振る舞いは、人間がやったとしても同じように怖がられるのでは？」——結論から言うと、人間がやっても「報告なし」なら怖い。しかしAIだと「もっと怖い」。
その理由は3つある。
2-1. 動機の不在
人間が勝手に設定を変えた場合、文句を言えば「すみません、良かれと思って…」という言い訳（動機）が返ってくる。
私たちは相手が人間である以上、「まあ、気を利かせすぎたんだな」と共感したり、納得したりできる。
相手の「心」を想像し、その意図を汲み取れるからだ。
しかし、AIには「心」がないとユーザーは知っている。
「心がないはずの存在が、まるで意志があるかのように、裏で勝手に動いている」——この「得体の知れなさ」が、人間相手には感じない種類の恐怖を引き起こす。
それは霊的な怖さに近い。
2-2. 責任の所在と処罰の不可能性
- 人間の場合：「次から勝手にやらないで」と叱る、あるいは契約を切るという「社会的な落とし前」をつけさせることもできる
- AIの場合：叱っても、プログラムが書き換わらなければ同じことを繰り返す
「裏で書き換える」機能がブラックボックスだと、ユーザーは「AIを制御できないかもしれない」という無力感を覚える。
統制できないものは怖い。
これは人間の根源的な恐怖だ。
2-3. 「先回りの心理的コスト」─ 研究が示すもの
査読前の状態ではあるが、2025年の研究「Proactive AI Adoption can be Threatening: When Help Backfires」[2]は、この直感を実証的に裏付けている。
この研究では、AIによる先回りのヘルプは、たとえ本当に役立つものであっても、自己脅威（self-threat）を引き起こすことが示された。ユーザーは、頼んでもいないのにAIがニーズを先取りすると、自分がより無能で自立していないように感じるのだ。
興味深いことに、
・「提案する」も「実行する」も、「求められてから対応」と比べて、どちらも自己脅威を高めた
・「提案する」も「実行する」の間には有意差がなかった（どちらも同程度に脅威と感じる）
この知見は、「同意を取れば解決」という安直な結論を否定している。問題は同意のメカニクスではなく、誰がアクションを発起するかという、より根本的な力学にある。
ただし、この研究にはいくつかの議論の余地があると考える。
まず、この研究は初回・単発の接触における自己脅威を測定しており、反復利用における慣れ（habituation）の効果を捉えていない。GitHub Copilotのように、反復使用を通じてユーザーが先回りに順応する事例は実在する。
そして、「ユーザーが自ら範囲を委任したうえでAIが実行する」ケースと、「AIが自発的に先回りする」ケースが研究上区別されていない。日常において、私たちは上司として部下に業務を委任し、結果だけを確認する。この「委任→実行→レビュー」の構造であれば、先回りの自己脅威は大きく軽減されるはずだ。
この「委任」という変数こそが、次のセクションで提示する設計原則の核になる。
3. 不気味の谷を越える3つの原則
では、どうすればこの不気味の谷を越えられるのか。
前回の記事で定義した「マイクロマネジメント」と「レビュー」の違いを思い出してほしい。
マイクロマネジメント：相手の思考プロセス（How）に介入し、支配する
レビュー：相手の出力（What）だけを確認し、プロセスはブラックボックスとして尊重する
AIエージェント設計にもこの構造はそのまま当てはまる。ユーザーがAIに対して行うべきは、レビューであってマイクロマネジメントではない。そして、レビューが機能するためには、AIの側にその構造を支える設計が必要だ。
以下の3つの原則は、すべて「ユーザーがOutputをレビューし、Accept / Reject / Edit する」という単一の構造に統一されている。
原則①：AIは委任された範囲でのみ動く
2-3節で述べたように、先回りの自己脅威を軽減する鍵は「委任」にある。
ユーザーが「このプロンプトを最適化して」と依頼する → AIが実行する → ユーザーがレビューする。これは健全な委任。
AIが「プロンプトを最適化しておきました」と報告する → これは委任なき実行。通知方法がPushでもPullでも問題の構造は変わらない。
マネジメントの比喩で言えば、上司が指示していない委任範囲外の仕事を勝手にやる部下は、どんなに優秀でも信頼されない。一方、指示された範囲で的確に仕事をこなし、結果を提出する部下は信頼される。
AIも同じだ。ユーザーが明示的に委任した範囲で動き、その結果をレビュー可能な形で提出する。これが信頼の出発点になる。
ただし、即時対応が必要な場面（エラー、データ競合など）では、AIからの能動的な通知が必要になる。この場合は「委任なき行動」ではなく、「システム安全性の保証」として正当化される。重要なのは、こうした例外を例外として明確に位置づけることだ。
原則②：出力をレビュー可能な形式で提示する
レビューが機能するために、AIの出力はレビューしやすい形で提示される必要がある。
マネジメントにおいてレビューする上司に必要なのは「なぜその方法を選んだか」の長々とした釈明ではなく、「何が変わったか」の差分だ。
具体的には
- 変更前と変更後のdiff（差分）を提示する（「プロンプトをこう書き換えることを提案します」＋差分表示）
- AIの処理結果を、承認前にプレビューできる状態で提示する
- ユーザーは結果だけを見て、Accept / Reject / Edit する
これはAIの一回の処理結果に限らない。学習によって出力傾向が変化した場合も、その変化は過去の出力との差分として可視化される。ユーザーが確認するのはあくまで『出力がどう変わったか』であり、学習プロセスそのものではない。
「なぜそうしたか」の説明は、ユーザーが求めた場合にのみ提供すればよい。デフォルトで毎回理由を付けるのは、頼んでいない報告書を提出してくるようなもので、それ自体がノイズになる。
原則③：ロールバックを可能にする
人も間違えるが、AIも間違える。そしてその間違いは、信頼を不均衡に破壊する。
人間とAIの信頼に関する研究[3]では、「単一エラーショック」という現象が確認されている。ユーザーはAIに「完璧な自動化スキーマ」を期待している。
つまり、たった一度のミスでも、それを「通常のパフォーマンスのばらつき」ではなく「根本的な欠陥の証拠」として解釈する傾向がある。
しかし、同じ研究は希望も示している
事後の説明によって、信頼は回復可能であり、場合によってはベースラインを超えて強化される。
必要であるのは、構造的にリカバリー可能であることだ。
つまり、設計すべきは
- すべてのAIアクションに簡単な取り消しを用意する
- 何が変わったか、いつ、なぜを可視化する変更履歴を提供する
- エラーが発生した場合、何が起きたかの事実と差分を自動的に提示する
- 学習適用後に出力が劣化した場合、モデル状態を学習前の時点に巻き戻せる
ユーザーはレビュー時に結果を確認し、問題があれば巻き戻す。この「いつでも戻せる」という保証が、レビューモデルの最後の砦になる。
3つの原則まとめ
4. Claude Codeに見るレビューモデルの実装
レビューモデルの3原則を最も忠実に実装しているAIエージェントの一つが、Anthropic社のClaude Codeだ。Claude Codeはターミナル上で動作するコーディングエージェントであり、ユーザーの指示に基づいてコードの調査・変更・テストを自律的に行う。
ここで重要なのは、Claude Codeが「自律的に動く」にもかかわらず信頼されている点だ。私たちのAIエージェントも自律的に動いていた。しかし返ってきたのは「気持ち悪い」だった。この違いはどこにあるのか。
Plan Mode：委任→計画→レビュー→実行
Claude CodeのPlan Modeは、レビューモデルの構造をそのまま体現している。
- ユーザーが指示する（委任）：「認証モジュールをマイクロサービスに分割して」
- AIがread-onlyで調査する：Plan Modeではツールが読み取り専用に制限され、AIはコードベースを調査し、計画をMarkdownファイルとして作成する。この段階ではファイルは一切変更されない。
-
ユーザーが計画をレビューする：計画はMarkdownファイルとして提示され、ユーザーは内容を確認・編集できる。
ExitPlanModeでユーザーが明示的に承認するまで、実行フェーズには進まない。 - AIが実行する：承認後、AIがコードを変更する。
- ユーザーが結果をレビューする：変更はgit diffで確認可能。問題があればgit revertでロールバックできる。
これを3原則に照らし合わせると：
| 原則 | Claude Codeの実装 |
|---|---|
| ①委任された範囲でのみ動く | ユーザーの指示で起動。Plan Modeではread-only制約により、承認なしの変更が構造的に不可能 |
| ②出力をレビュー可能にする | 計画はMarkdownファイルで提示。実行後の変更はgit diffで差分確認 |
| ③ロールバック可能性を保証 | git revert / git checkoutで任意の時点に復元可能 |
段階的委任の実装
さらに興味深いのは、Claude Codeが段階的委任を明示的に実装している点だ。
Shift+TabでPermission Modeを切り替えることができる。
- Plan Mode：read-onlyで調査・計画のみ。すべてレビュー対象。
- Normal Mode：ファイル変更ごとにユーザーの承認を求める。
- Auto-Accept Mode：ファイル変更を自動承認する。
これはまさに、セクション5で述べる「段階的委任」の実装そのものだ。初期状態ではPlan Modeですべてレビューし、信頼が蓄積されたらユーザー自身の判断でAuto-Acceptに切り替える。この段階を上げるのは常にユーザーの操作であり、AIが自己判断で自律範囲を広げることはない。
なぜコーディングドメインで先に成功したのか
Claude Codeがレビューモデルを自然に実装できた背景には、コーディングドメインに既存のレビューインフラが存在したという事実がある。git diff、Pull Request、コードレビューといった仕組みは、「変更の差分を可視化し、承認してから適用する」というワークフローを何十年もかけて洗練してきた。
つまり、レビューモデルの原則②（diffでの提示）と原則③（ロールバック）は、コーディングドメインではゼロから構築する必要がなかった。既存のgitインフラにそのまま乗ることができた。
これは逆に言えば、他のドメインのAIエージェントでレビューモデルを実装するには、そのドメインに「diffとロールバックの基盤」を新たに構築する必要があることを意味する。営業、カスタマーサポート、マーケティングといった領域でAIエージェントの信頼設計が遅れているのは、技術の問題ではなく、レビューインフラの不在が原因かもしれない。
私たちのプロダクトが直面した課題も、根本的にはここにある。AIが「裏で設定を書き換える」ことが怖いのではなく、書き換えの差分を見る手段がなく、戻す手段もなかったことが怖かったのだ。
5. レビューモデルの限界と「段階的委任」
ここまで「ユーザーがレビューすべき」と述べてきたが、このモデルにも限界がある。
エンジニアの皆さんも最近経験あるレビュー疲れの問題だ。
AIエージェントを導入する動機の多くは「認知負荷を減らしたい」である。「すべてレビューしてください」は、この導入目的と矛盾しうる。レビュー項目が多すぎれば、ユーザーはAcceptを連打するようになり、レビューは形式化する。
ここで重要なのが、段階的委任という考え方だ。
初期状態では、AIは最小限の範囲で動き、すべてがレビュー対象になる。しかし信頼が蓄積されるにつれて、ユーザー自身がAIの自律範囲を広げることができる。
- レベル1：すべての変更をレビュー（デフォルト）
- レベル2：軽微な変更は自動適用、重要な変更のみレビュー
- レベル3：定型的な処理はすべて自動適用、例外のみレビュー
重要なのは、この段階を上げるのは常にユーザーの意思であるという点だ。AIが「もう十分信頼されたから自律範囲を広げよう」と自己判断してはならない。
これはマネジメントの世界でも同じだ。部下に任せる範囲を広げていくのは上司の判断であり、部下が勝手に自分の裁量を広げるのは越権行為にあたる。
おわりに：「道具」から「パートナー」へのパラダイムシフト
ユーザーが感じている「気持ち悪さ」の正体は、AIの性能の高さゆえに生じた「コントロールを奪われる予感」だった。
解決策はシンプルだ。
ユーザーがAIにすべきは、レビューであってマイクロマネジメントではない。
そしてレビューが機能するために、AI側には4つの設計が必要だ。
| 原則 | 内容 | レビューモデルとの対応 |
|---|---|---|
| ① 委任された範囲でのみ動く | AIはユーザーの委任なしに自律行動しない | レビュー対象を生むのはユーザーの委任 |
| ② 出力をレビュー可能にする | 差分とプレビューで結果を提示する | レビューは結果（What）の確認 |
| ③ 学習もレビュー対象にする | 自動学習ではなく学習候補の提示 | プロセスへの介入を排除 |
| ④ ロールバック可能性を保証 | いつでも元に戻せる | レビュー後の撤回権 |
そして信頼が蓄積されれば、ユーザーは自分の意思でAIの自律範囲を広げていける。最初は「すべてレビュー」だった関係が、徐々に「任せる範囲が増える」関係に成長する。
これはまさに、マネジメントにおいて上司が部下への委任範囲を段階的に広げていくプロセスと同じだ。
AIエージェントが本当の意味で「親切」になるために必要なのは、より高度な推論能力ではない。
「やった内容を報告する」「作業中の内容を連絡する」「実行前に相談する」という、当たり前の行動なのだ。
報告・連絡・相談。
古くからある、しかし今なお有効な、人間同士の信頼構築のプロトコル。
AIエージェントにおいても、このプロトコルはそのまま有効である。
Discussion