# AIエージェント時代の心理的安全性——「AIに聞けばいいのに」をどう乗り越えるか
チームに Claude Code を導入してから、あることが気になり始めた。ジュニアエンジニアが以前より質問してこなくなったのだ。実装で詰まっているのはログを見ればわかる。でも Slack も静かで、1on1 でも「Claude に聞いてだいたい解決しました」という言葉が増えた。
喜ばしい自立心、と思っていた時期もあった。ただあるとき、ジュニアが Claude の提案をそのままマージした PR のレビューをしていて気づいた。動くけれど、チームのアーキテクチャの文脈を完全に無視したコードだった。それを指摘すると「Claude がこうしろと言ったので」という返事が返ってきた。
AIツールの普及は、コードを速く書けるようにした。その一方で、チーム内に新しい種類の断絶を生んでいる。「AI に聞けばいい」という選択肢が常にある環境では、「人間に聞く」という行為の意味が変質する。AI エージェント時代に生まれているこの断絶を、EM として今週から対処できる。
心理的安全性とは——なぜ今これが問題になるのか
Harvard Business School のエイミー・エドモンドソンが 1999 年に定式化した概念では、心理的安全性とは「対人的なリスクを取っても安全だという、チーム内で共有された信念」だ。
Google の Project Aristotle では、180 チームを超える調査から高パフォーマンスチームの条件を分析した。5つの要素（心理的安全性・信頼性・構造と明確さ・意義・インパクト）の中で、心理的安全性だけが他の4つの前提条件として機能していた。心理的安全性が高いチームは、組織を去る可能性が低く、幹部から「効果的」と評価される頻度も2倍だったという。
エドモンドソンは 2025 年に発表した研究で、経済的不確実性の時代における心理的安全性を「なければ困るもの」ではなく「不可欠な基盤（requirement, not luxury）」と再定義している（HBR 2025 年 11 月）。AI が急速に職場に浸透している今、この言葉はさらに重みを増している。
チームで起きている4つの新しい断絶
AI を使っていることを同僚に隠す
Laserfiche の 2025 年調査によると、米国の職場 AI 利用者の約 49% が AI の使用を同僚や上司から隠している。別の調査でも同様に 48% が非開示という結果が出ている。隠す理由は「抵抗感」ではなく「判断されることへの恐怖」だ。
Claude Code を使って書いたコードを PR に出すとき、「AI 生成だとわかったら評価が下がるかもしれない」という心配が働く。チームとして AI の活用を推奨していても、評価制度がそれを追いかけていなければ、人は使用を隠す。
「AIに聞けるのに人間に聞くのは恥ずかしい」という逆転
かつて、質問することは学ぶ姿勢の表れだった。今は「AI に聞けば即座に答えが出る」環境があるため、「それでも人間に聞く」という行為が「AI も使いこなせない」証拠に見えてしまうという心理が生まれている。
「AI でわからなかった場合だけ質問していい」という暗黙の序列が発生すると、そもそも質問の性質が変わる。技術的な詰まりは AI で解消できても、チームのコンテキストや設計判断の背景は AI には聞けない。この種の質問こそが人間同士のやり取りで磨かれるものなのだが、心理的なハードルが上がると最初から諦める。
AI の提案を否定できない
Stack Overflow の 2025 年 Developer Survey では、開発者の AI への信頼度が 2024 年の 40% から 2025 年には 29% に低下した。84% が AI ツールを使用または使用予定と答えながら、46% が AI の正確性を信頼しないという矛盾した状態が広がっている。
Claude Code や Copilot が自信を持って提示するコードに対して「これは違う」と言うには、十分な技術的根拠が必要だ。特にジュニアエンジニアは「自分の判断 vs AI の提案」で自分に自信が持てない。シニアに「なぜ AI の提案を採用しなかったのか」と問われることを恐れると、根拠のある懸念を飲み込んでしまう。
AI が書いたコードをコードレビューで指摘する際にも似た心理が働く。「AI が書いたコードを私が指摘する＝私は AI より優秀という証明が必要」という無意識の逆転だ。arXiv の研究（2512.05309）では、LLM とのやり取りは「非判断的・匿名性がある」ために開発者が心理的安全性を感じやすい一方、人間のレビュアーからのフィードバックには評判への懸念が伴うと指摘されている。
ジュニアが「サイレント・サイロ」に入る
LeadDev の AI Impact Report 2025 によると、エンジニアの 38% が「AI ツールによりシニアとジュニア間の直接的なメンタリングが減少した」と報告している。
複数の現場レポートから見えてきた現象として、「サイレント・サイロ」と呼ばれるものがある。かつてチームで頻繁に交わされた「なぜこのアーキテクチャはこう想定しているのか」という小さな質問が消え、ジュニアは AI に即座の答えを求めることで「遅さや未経験を見られる」という社会的コストを回避する。結果として、ペーストできるコードは知っているが動作原理は理解していないという状態が広がり、チームの暗黙知や設計判断の背景が伝承されなくなる。
ジュニアエンジニアは常に「明日のシニア・CTO」の育成母体だ。AI がエントリーレベルの仕事を処理し始めると、10 年後の組織は深刻なスキルギャップを抱えるリスクがある。
規模感を数字で確認する
これらの問題が「うちだけ」だと感じている場合、データを見ると景色が変わる。
LeadDev の Engineering Performance Report 2025 では、400 名以上のエンジニアリングリーダーを調査した結果、60% が AI によるチームの生産性向上を実感していない。39% が「わずかな改善（1〜10%）」と評価し、21% は改善なし・むしろ低下と回答している。54% が AI アプリのパフォーマンスを測定すらしていない。
MIT Technology Review の 2025 年 12 月レポートでは、わずか 39% のリーダーだけが組織の心理的安全性を「非常に高い」と評価している。22% のリーダーは失敗時の非難を恐れて AI プロジェクトの主導を躊躇していると回答した。
HBR に 2026 年 2 月に掲載されたエドモンドソンと 3M 主任科学者の共著（How to Foster Psychological Safety When AI Erodes Trust on Your Team）は、「生産性向上の期待に反してチーム全体のパフォーマンスが低下しており、メンバーが自分たちを疑い始め、信頼が目に見えない方法で侵食されている」と指摘する。AI 統合はツールや自動化の問題ではなく、「対人信頼・調整・意思決定の低下」として現れるという主張は、現場の感覚と一致している。
EM が今週から始める具体的なアクション
AI 利用のガイドラインをチームノームとして明文化する
「AI を使ってもいい」という雰囲気だけでは不十分だ。何が許容されるかが曖昧なまま放置されると、各自が最もリスクを避ける方向に解釈する。つまり「隠す」ことになる。
チームドキュメントに次の 4 点を明文化する。隠蔽インセンティブはルールがないまま放置すると消えない。
AI 使用を開示する基準を設ける
コード帰属の実践的枠組みとして、「Assisted-by」（AI 提案が 33% 以下）/ 「Co-authored-by」（35〜67%）/ 「Generated-by」（67% 以上）という 3 段階のラベルを PR に記載するルールを導入したチームがある（mattgoodrich.com の提案）。完璧な計測は難しいが、「開示が前提」という文化を作れればいい。
AI の提案を否定してよいと明文化する
「Claude がこうしろと言ったとしても、チームの判断を優先していい。AI の提案に疑問を持ったら声に出せ」という一文をドキュメントに入れる。これだけで、ジュニアが懸念を飲み込む確率は下がる。
AI 生成コードへの指摘を「推奨」と書く
コードレビューのガイドラインに「AI が書いたコードであっても通常のレビュー基準で指摘すること」と明記する。指摘は知識不足の証明ではなく、チームの品質を守る行為だ。
レトロスペクティブに「AI の失敗共有」を 5 分追加する
Martin Fowler のブログ「Feedback Flywheel」では、AI インタラクションが生み出す失敗信号を個人の経験から集団的改善に変える仕組みを紹介している。失敗信号の例として「新しいエンドポイントの認可チェックが生成指示に含まれていなかった」という気づきを即共有し、チームの学習ログに記録することで次回の生成指示に反映するパターンが挙げられている。
実装は軽量でいい。スプリントのレトロスペクティブの最後に「今週の AI 失敗・学び共有（5 分）」というアジェンダを 1 つ足す。重要なのはリーダー自身が先に自分の AI 失敗例を共有することだ。「Claude に任せたらデータのバリデーションを全部省略されていた」「プロンプトが曖昧で全然違うものが生成された」という経験を EM が公開する行動が、チーム全体の「失敗を隠さない」文化への最大の信号になる。
1on1 で「AI とどう協働したか」を問う
Worklytics の 2025 年秋レポートでは、従業員が実際にリーダーが把握しているより大幅に AI を使用しているケースが多く、パフォーマンスレビューで AI の関与をどう扱うかが課題になっていると指摘している。
1on1 で試してほしい問い方の変換がある。「AI を使いましたか？」という有無の質問から「AI とどう協働しましたか？どんな判断を自分でしましたか？」という質の問いへの転換だ。使用の有無を問うと隠蔽のインセンティブが生まれる。使い方を問うと、批判的思考や判断力が自然に見えてくる。AI の利用が評価の文脈に正直に入ってくる。
ジュニアを「AIの向こう側」に消えさせないために
Engineering Enablement のレポートでは、ジュニアエンジニアのメンタリングに関する 5 つの戦略が提案されている。そのうち筆者が特に有効だと感じているのは「コードレビューを議論の場に転換する」というアプローチだ。
コードの仕様を確認するレビューから、「なぜこうしたの？」「他のアプローチと比較してどう判断した？」という思考プロセスを問うレビューへのシフトだ。AI が書いたコードをそのままマージしたとしても、「このコードを採用した理由を説明して」という問いを立てれば、理解の深さが見える。AI が生成したものと自分の判断の境界を本人が意識する機会にもなる。
また、週に一度「AI なしのデバッグ演習」を取り入れているチームもある。意図的に AI ツールを使わない時間を設けることで、デバッグの直感を構築する「生産的な葛藤」を確保する。スキルの退化を防ぐための時間を意図的にデザインする。
チームに「AI と話すのは気軽にできるが、チームメンバーに質問するのは恥ずかしい」という空気が漂い始めたとき、EM にできることはツールの制限ではなく、人間同士の会話が安全に行われる設計を整えることだ。ガイドラインの明文化、失敗の共有、1on1 の問い方の変換。どれもこの 1 週間で始められる。あなたのチームの 1on1 で、今週 1 つ試してほしい。
コードレビューへの Claude Code 活用については「Claude Code をコードレビュアーにする」、1on1 でのフィードバック支援については「1on1 の準備に 30 分、フィードバックに 1 時間——Claude Code で「人を育てる時間」を取り戻す」も参考にしてほしい。
コメント