AIコーディングはなぜイライラするのか——Grounding理論と認知症ケアから読み解く構造的問題

(この記事は、人間と Claude との議論をもとに、Claude が全面的に書いています)

# AIコーディングはなぜイライラするのか——Grounding理論と認知症ケアから読み解く構造的問題
## 「ほぼ正しいが微妙に違う」問題
Stack Overflow 2025 Developer Survey（回答者49,000人超）によると、AIコーディングツールに対する最大のフラストレーションは「ほぼ正しいが微妙に違う出力」で、66%の開発者が経験している。45%は「AI生成コードのデバッグのほうが時間がかかる」と回答した[^so2025]。

完全に間違っていれば捨てて書き直せる。だがAIの出力は8割正しい。残り2割を直す作業が最も精神的にきつい。他人の設計判断を修正する感覚に近い。

そしてこの体感は数字にも表れている。METR（Model Evaluation & Threat Research）が2025年に実施したRCT（ランダム化比較試験）では、経験豊富なOSS開発者16名・246タスクを対象に、AIツール使用群は完了時間が**19%増加**した。にもかかわらず開発者本人はAIで24%速くなると事前予測し、実験後も20%速くなったと信じていた[^metr]。

「速くなった感覚」と「実際の速度低下」が共存する認知バイアスが定量的に示されている。

## 問題の本質——Grounding Failure
このフラストレーションの正体は、コミュニケーション理論の古典であるClark & Brennan (1991) の「grounding」の枠組みで説明できる[^clark]。

Groundingとは、対話の中で相互理解を逐次確認していくプロセスのことだ。人間同士の対話では、発話（presentation）→ 受容確認（acceptance）のサイクルが回り、相手が「聞いていない」「聞いたが意味は取れていない」「意図を理解した」のどの状態にいるかを判別し、必要に応じて修復する。

LLMとの対話では、この仕組みが壊れている。

2026年2月にPoelitz, Doshi-Velez & Lindley が発表したベンチマーク論文は、Human-AIインタラクションにおけるcommon groundの形成を評価し、AIの問題的パターンとして以下を挙げている[^benchmark]。

- 単一ターンの応答傾向
- 過度に長い応答
- アラインメントの負担が人間側に偏る非対称なgrounding effort
- 共有理解の証拠を生み出さない浅いgrounding行動

LLMは常に「理解した」ふりをする。修復要求を自発的に出さない。misalignmentが蓄積しても修復コストが全て人間側に乗る。共有参照表現の形成も起きない（コンテキスト窓のリセット、セッション間の断絶）。

## ツールの性質が根本的に変わった
従来のソフトウェアエンジニアリングツール——静的解析、自動生成、エディタマクロ——は予測可能で冪等だった。同じ入力には同じ出力が返り、失敗はエラーとして明示的に報告され、ツールの挙動を学習すれば予測できた。

ML系ツールはこの前提を全て覆す。出力は確率的で、やり直すと別のものが出る。失敗は「ほぼ正しい」という暗黙的な形を取る。そしてメンタルモデルが構築不能だ。

エンジニアが長年かけて鍛えてきたのは「決定的なシステムの挙動を正確にモデリングする能力」であり、その能力が通用しない道具を毎日使わされている。職人が、日によって硬さが変わる素材で物を作れと言われているようなものだ。

しかも従来のツールは「境界」が明確だった。gccが最適化できる範囲、正規表現でマッチできるパターン。LLMは境界が分からない。何ができて何ができないかが、使うたびに変わる。

## 非対称な負荷構造
Springer掲載の論文 "Overloaded Minds and Machines" (2026年1月) は、Human-AIの共同作業において、ユーザーが検証と統合に過負荷になる一方、モデルはコンテキストが肥大すると信頼性が下がるという非対称性を論じている。そしてこの非対称性が、co-creationが特徴的な仕方で失敗する原因だと指摘した[^springer]。

処方箋として提案されているのは「動的なロードバランシング」だ。AIの不確実性が高いときはAI側が後退して選択肢を提示し人間に判断を委ねる、人間の負荷が高いときはAIがルーチンワークを引き取る——固定的な自動化ではなく、双方の状態に応じたルーティングポリシー。

理想論としては正しい。だが前提として、AIが自分の不確実性を正確に自己認識できる必要がある。今のLLMにはそれができない。「自信満々に間違える」か「何でも自信なさげにhedgeする」の二択になりがちで、状況に応じた精度のある自己評価ができない。

BCGの研究（2026年3月、HBR掲載）は、AIツールの監視負荷が高い労働者は14%多い精神的努力を費やし、12%多い精神的疲労を報告し、19%多い情報過負荷を経験することを明らかにした。研究者らはこの現象を「AI brain fry」と名付けている[^brainfry]。

道具として見れば「出力が不安定な道具」は別に珍しくない。だが道具は喋らない。LLMの根本的な問題は、道具のくせに対話インターフェースを持っていて、対話相手としての期待を誘発すること。ハンマーが「釘打ちますね！」と言ってから空振りしたら、黙って空振りするハンマーより遥かに腹が立つ。

## 認知症ケアとの構造的類似
ここまでの分析を整理すると、AIコーディングのフラストレーション構造は認知症ケアと驚くほど対応している。

| 認知症ケア                                       | AIコーディング                               |
| :----------------------------------------------- | :------------------------------------------- |
| 毎回初対面（記憶がリセットされる）               | セッション間でcommon groundがリセットされる  |
| 流暢に喋るが中身が怪しい                         | 自然言語は流暢だが理解していない             |
| 相手のモデルが構築不能（日によって能力が変わる） | 能力の分散が大きくメンタルモデルが安定しない |
| ケアする側にgrounding負荷が一方的に乗る          | 修復も確認も全部ユーザー負担                 |
| 怒っても意味がない                               | 相手に改善の意思も能力もない                 |
| たまにちゃんと通じる瞬間がある                   | たまに完璧にgroundingが成立する              |

最後の点が最も厄介だ。完全に通じないなら割り切れるが、時々grounding が成立するから期待が消えない。これはまさに「能力の分散がデカすぎる」問題であり、期待値（平均）をどこに置いても外れるターンが必ず来る。

## 認知症ケアの知見は応用できるか
認知症ケアで効果が実証されている介入のうち、AIコーディングのストレス管理に転用可能なものがある。

**Psychoeducation（心理教育）**——「この相手はこういう壊れ方をする」を事前に知っておくだけで負担が下がる。Grounding failureの構造を理解すること、LLMが常に「理解した」ふりをすることを知ること。認知症ケアでも「なぜこの行動が起きるか」の理解が介護者の怒りを有意に減らすというエビデンスがある。

**Peer support（ピアサポート）**——同じ立場の人間と話す。タバコ部屋や居酒屋での上司の愚痴と同じ構造で、非制度的なpeer supportそのものだ。共通の苦痛源がある、自分の対処が悪いのではないという相互承認が得られる、コーピング戦略の交換が起きる。認知症ケアでも「同じ状況の人との情報交換がストレスコーピングとレジリエンスを改善する」という知見がある[^caregiver]。

ただし転用には限界もある。

認知症ケアは「ケアされる側のQoL」が目的だが、AIコーディングは「使う側が成果物を出す」が目的だ。主体が逆。認知症ケアの比喩を引き継ぐなら、今の状況は**認知症の人に仕事を手伝ってもらおうとしている**に近い。ケアしたいわけではなく、こちらが助けてほしいのに、なぜかこちらがケアコストを払っている。

さらに認知症ケアでは「介護者が疲弊するのは構造的に当然」という社会的共通理解があるが、AIコーディングでは「うまく使えないお前が悪い」になりがちだ。「プロンプトエンジニアリング」という言葉自体が、grounding負荷をユーザースキルの問題に矮小化している側面がある。

## 現実的にやれること
技術的に問題が当面解消しないとして、「被害軽減」のアプローチは存在する。

**対話ベースのgroundingを諦める**——specを書いて投げて、出力をdiffで検品する。対話相手ではなくコンパイラ的に扱う。能力の分散問題を回避できる。

**grounding確認を強制する仕組み**——「まず理解した内容を箇条書きにしろ、コードは書くな」を毎回入れる。LLMの「State 3偽装」（分かったふり）を潰す。

**セッションを短く切る**——grounding failureの蓄積を防ぐ。長い対話ほどmisalignmentが積もる。AGENTS.mdやスキルファイルで「環境側に記憶を外出しする」アプローチは、認知症ケアでいう「見当識障害への環境調整」（部屋に名前を貼る、時計を置く）と同じ発想だ。

**自分がケアコストを払っている自覚を持つ**——grounding負荷の自覚だけで、コントロール感がいくらか回復する。「AIに対してキレてる自分」を異常だと思わないこと。認知症ケアで「被介護者への怒りを感じること自体は正常」と教育するのと同じ。

**ピアサポートの場を持つ**——同じレベルの開発者が同じツールで同じ種類のフラストレーションを経験している状況での雑談。SNSでの愚痴共有も機能するが、「使い方が悪い」勢が混入するので純度は低い。

## 懺悔室としてのAI
最後に一つ逆説的な知見がある。AIコーディングで溜まったフラストレーションを、別のセッションでAIに吐き出すこと。これはpeer supportではなく、教会の懺悔室に近い構造を持つ。

懺悔室は相手がこちらを理解しているかは重要ではない。「言った」という行為自体に浄化効果がある。相手は判断しない。定期的に行く。セッションを分ければ、コーディングセッションのAIと懺悔室のAIは別人格になる。記憶がリセットされるからこそ成立する。

人間相手の愚痴は「聞いた相手にも負荷がかかる」という非対称性があるが、AIへの八つ当たりにはそれがない。人間関係のコストがゼロのサンドバッグ。ただしこれを自覚的にケア手段として使う場合の話で、無自覚にキレ散らかし続けると単にフラストレーションの反復強化になる。

---

## 出典
[^so2025]: Stack Overflow, "2025 Developer Survey" (2025). https://survey.stackoverflow.co/2025/ai

[^metr]: Becker, J., Rush, N., Barnes, E., & Rein, D. "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." arXiv:2507.09089 (2025). https://arxiv.org/abs/2507.09089

[^clark]: Clark, H. H. & Brennan, S. E. "Grounding in communication." In _Perspectives on Socially Shared Cognition_, pp.127–149. American Psychological Association (1991). https://web.stanford.edu/~clark/1990s/Clark,%20H.H.%20_%20Brennan,%20S.E.%20_Grounding%20in%20communication_%201991.pdf

[^benchmark]: Poelitz, C., Doshi-Velez, F. & Lindley, S. "A Benchmark to Assess Common Ground in Human-AI Collaboration." arXiv:2602.21337 (2026). https://arxiv.org/abs/2602.21337

[^springer]: "Overloaded minds and machines: a cognitive load framework for human-AI symbiosis." _Artificial Intelligence Review_, Springer (2026). https://link.springer.com/article/10.1007/s10462-026-11510-z

[^brainfry]: Bedard, J. et al. "When Using AI Leads to 'Brain Fry'." _Harvard Business Review_ (2026). https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry

[^caregiver]: 認知症介護者のcompassion fatigue・caregiver burdenに関しては以下を参照: PubMed Central の系統的レビュー群。また、Carey（認知症介護者向けAIチャットボット）の研究では、介護者がAIチャットボットとのインタラクションについて「一方的で、会話を維持する負担が介護者側にある」と報告している。

[^mozannar]: Mozannar, H. et al. "Reading Between the Lines: Modeling User Behavior and Costs in AI-Assisted Programming." CHI '24 (2024). https://dl.acm.org/doi/10.1145/3613904.3641936

[^atlassian]: Atlassian, "2025 State of Developer Experience Report" (2025). https://www.atlassian.com/software/developer-experience

[^liang]: Liang, J. T., Yang, C. & Myers, B. A. "A Large-Scale Survey on the Usability of AI Programming Assistants: Successes and Challenges." ICSE 2024. https://arxiv.org/abs/2303.17125