生成AIを使うと頭が悪くなる問題をどう解決するのか
この記事の目次
※こちらは、社内LT会にて発表した内容になります!マイナビではこういったLT会を定期的に開催しております!
発表資料はこちら
最近自分の身の回りや自分でも、
- 生成AIがやってくれるからやる気が出ない
- 無気力になる
- なんか自分で考えなくなった気がする
いわゆる 「生成AI鬱」 みたいな人が増えてきたような気がしています...
最近色々試してみて若干改善してきたのでそれを共有できればなと思います。
まず初めに自分がどうだったのか
とりあえず、モチベーショングラフを作ってみました。

何も無しの状態(約1年前)から現在に至るまではざっくりこんな感じ
- チャット系の機能で利用するようになる: 簡単なデータ整形作業とかをしてもらう
- AIコード保管系が出てくる: スタイル書く時にめっちゃ使って捗り始める
- AIエージェントを使い始める(cursor) :個人開発がめっちゃ捗る ← 最高潮
- 超自立型(claude code)が出る: バイブコーディングの割合が増えて徐々にやる気がなくなってくる
- 何も自分で考えなくなる
- 少しマインドを変えると捗るようになる ← 今ここ
→エージェントがいい感じになり始めてから、自分で考えて手を動かすということがなくなっていきました...
その中で、記事を読み漁ると「生成AIを使うと頭が悪くなっていく問題」をどうするか?のこの画像が話題になっているのを見つけました
→ 今自分が陥っているのはこれだ! となりました。

AIに指示出している間気づいたら何も考えていない... というか何もしてない...
今回はこの記事にインスピレーションを受けつつ、
- 「統計と研究的にどうなっているのか」
- 「試して良かったこと」
をまとめていこうと思います。
研究的にはどうだったのか
世界的にも、生成AIを使うと頭が悪くなる問題ついての研究があったりします。
METR(Model Evaluation & Threat Research)という非営利研究機関が2025年に行った研究で、経験豊富なオープンソース開発者にAIツールを使わせたところ、逆に19%も作業時間が長くなったのに、20%作業が早くなったと認識するという驚きの結果が出ました。
こんな感じで自立して考えられなくなる
経験豊富なオープンソース開発者にAIツールを使わせる実験 (AI要約)
経験豊富なオープンソース開発者にAIツールを使わせる実験
METR(Model Evaluation & Threat Research)という非営利研究機関が2025年に行った研究で、経験豊富なオープンソース開発者にAIツールを使わせたところ、逆に19%も作業時間が長くなったという驚きの結果が出ました。
実験の内容
- 対象者: 16人の経験豊富なオープンソース開発者
- 条件: 自分が長年携わっているプロジェクト(平均5年の経験)で246のタスクを実行
- 方法: 各タスクをランダムにAI使用可・不可に割り当て
- 使用ツール: 主にCursor Pro + Claude 3.5/3.7 Sonnet
認識と現実のギャップ
最も興味深いのは、開発者自身の認識と実際の結果に大きなギャップがあったことです:
- 事前の予想: AIで24%速くなると予測
- 事後の認識: AIで20%速くなったと感じた
- 実際の結果: 19%遅くなった
なぜ「頭が悪くなる」と言えるのか
- 認知能力の誤判断
開発者は自分の生産性が向上したと錯覚していましたが、実際は低下していました。これは、AIに依存することで自分の能力を正しく評価できなくなっていることを示しています。 - 問題解決能力の低下
経験豊富な開発者が、慣れ親しんだプロジェクトで逆に時間がかかるようになったということは、本来持っていた問題解決能力が阻害された可能性があります。 - 学習効果の阻害
AIに頼ることで、本来なら経験から学習できるはずの部分が阻害される可能性があります。
考えられる原因
研究では以下の要因が特定されました:
- 過度な依存: AIの提案を検証・修正する時間が余計にかかる
- コンテキストの複雑さ: 大規模で品質要求の高いプロジェクトではAIが十分に理解できない
- 学習カーブ: AI支援ツールを効果的に使うには長期間の習熟が必要
- 品質基準の維持: 高品質なコードを書く際の暗黙的要求事項への対応
- 認知負荷の増加: AI出力の評価・統合に余計な脳力を消費
より広い意味での「頭が悪くなる」問題
この研究結果は、生成AIの使用が以下のような認知的な問題を引き起こす可能性を示唆しています:
- 本質的理解の欠如: 表面的な解決に満足してしまう
- 判断力の低下: 自分の能力を正確に評価できない
- 依存症的思考: 実際には効率が悪いのにAIに頼り続ける
- 批判的思考の減退: AI出力を十分に検証しない傾向
他にも面白い記事があったりするのでよければ見てみてください!
試して良かったこと
個人的に試して良かったこと2つを具体例とともに紹介していこうかなと思います。
- AIに対して前のめりに接していく
- AIに自分がわかるまで説明してもらう
①AIに対して前のめりに接していく (丸投げ禁止)
考えることを放棄しないために、意識的にAIに切り込んでいくことを意識してプロンプトを書いてみてます。
ポイントは、オープンクエスチョンを避けて、+aを加える ということです。
【NG例】
① ${エラーコピペ}を解決してください。
② Buttonコンポーネントをよしなに作ってください。
※ ↑カスタムインストラクションに全てを書いているとかならOK
【OK例】
① ${エラーコピペ}を解決してください。私は、このファイルあたりのこの処理が怪しいと思っていて、**の方針で修正して欲しいです。
→ 返答が早くなる。AIが暴走しにくくなる。
② ButtonコンポーネントをBadgeのコンポーネントのような書き方で実装してください。ボタンにバリエーションはなくシンプルなProps設計にしてください
→ AIが迷わなくなる。余計なものを作らなくなる。
実際にやってみよう
②のようなユースケースで両者比較してみましょう。
Reactのプロジェクトを作って、サンプルでBadgeの実装をしておきました。×よしなにボタンを作ってください
×よしなにボタンを作ってください
button.tsx
import React from 'react';
import './Button.css';
interface ButtonProps {
children: React.ReactNode;
onClick?: () => void;
variant?: 'primary' | 'secondary' | 'outline';
disabled?: boolean;
className?: string;
}
const Button: React.FC<ButtonProps> = ({
children,
onClick,
variant = 'primary',
disabled = false,
className = '',
}) => {
return (
<button
className={`custom-button ${variant} ${className}`}
onClick={onClick}
disabled={disabled}
>
{children}
</button>
);
};
export default Button;〇ボタンを作ってください +a
プロンプト.txt
ボタンコンポーネントを作成してください
書き方はBadgeを参考にしてください
Propsの中のボタンのパターンは、variant: solid,outline と color: red, yellow, blue で作成して欲しいです。button.tsx
import React from 'react';
import './Button.css';
type ButtonColor = 'red' | 'yellow' | 'blue';
type ButtonVariant = 'solid' | 'outline';
interface ButtonProps {
children: React.ReactNode;
color?: ButtonColor;
variant?: ButtonVariant;
onClick?: () => void;
disabled?: boolean;
type?: 'button' | 'submit' | 'reset';
}
export function Button({
children,
color = 'blue',
variant = 'solid',
onClick,
disabled = false,
type = 'button',
}: ButtonProps) {
return (
<button
className={`button ${variant} ${color}`}
onClick={onClick}
disabled={disabled}
type={type}
>
{children}
</button>
);
}どちらもBadgeを参照していますが、意図通りになったところとそうでなかったところがあります。
両者問題なかったところ
→何も言わなくても、Badgeの形式と実装方法を参考にしてくれた◎
問題があったところ
→Propsの形式の意図を伝えないと、後で修正してめんどくさくなる…
×よしなにボタンを作ってくださいだと...
→よしなに作ってくれるが修正が必要
variant?: 'primary' | 'secondary' | 'outline';〇ボタンを作ってください +a
→ちゃんとPropsを伝えているので修正要らず
color: 'red' | 'yellow' | 'blue';
variant: 'solid' | 'outline';ちなみに今回は、Buttonという一般的(AIがよく学習してそう)なUIなので、出しやすいですが、もう少し癖があると、もっと差が出ます。
+a 本当に何もわからない場合は、プランニング(丸投げ) + 指摘 もおすすめ
先ほど共有したOK例では、ある程度内部構造や原因がわかっている程の指示でした。
しかしながら、「何が原因かわからない」「何から始めたらいいかわからない」みたいなケースもあると思うので、プランニング (丸投げ) + 指摘 もおすすめです。
【プランニング(丸投げ)】
[私] **を実装して欲しいのですが、解決策を複数案検討してくれませんか?
[AI] 解決策としては、A案とB案があって...(以下略)
【指摘】
[私] A案良さそうなのでA案ベースで進めてください!A案の**の部分はもう少しシンプルな実装でいいかなと思いました。**の関数は共通で実装されているのでそれを活用してください!
[AI] 対応します! (以下略)
②AIにわかるまで説明してもらう
先ほどもちらっと触れましたが、課題の解像度を上げることが良いプロンプト出すために一番必要な部分だと思います。
ですが、ネットで調べたり本で読んだり、みたいな知識の定着方法もありますが、AIのスピード感に自分の学習がついてかないみたいなケースがあるので、AIに解説してもらうっていうのもありです。
**ってなにみたいな感じで雑に聞くのもありですが、一工夫すると、AIがもっとわかりやすく説明してくれるようになります。
【ただ聞くだけ】
**ってなんですか。
【おすすめ】
**ってなんですか。友達の初心者にもわかりやすいように、例え話を交えながら解説してください。
これだけです。
ただ聞くだけだとモノによっては専門用語まみれになって、わからなくなってしまうので、初心者 + 例え話 がポイントです。
詳細はお好みで調整してください。ちなみに友達にした方が、例え話がわかりやすい気がするので加えてます。
実際にやってみよう
今回は、ストリーミングSSRについて解説してもらいました。
Webエンジニアでもギリ聞きなれない単語だと思い選びました。
↓実際の出力 claude-4-sonet
ストリーミングSSRってなんですか?
ストリーミングSSR(Server-Side Rendering)は、従来のSSRを改良した技術で、サーバーサイドでレンダリングしたHTMLコンテンツを段階的にブラウザに送信する手法です。
従来のSSRとの違い
従来のSSRでは、サーバーですべてのHTMLを生成し終わってから一度にブラウザに送信していました。
ストリーミングSSRでは、HTMLの生成が完了した部分から順次ブラウザに送信します。これにより、ユーザーは完全なページの読み込みを待つ必要がなく、コンテンツを段階的に見ることができます。
主な利点
初期表示の高速化: ページの一部が早期に表示される
体感パフォーマンスの向上: ユーザーが待ち時間を感じにくい
SEOフレンドリー: 検索エンジンが段階的にコンテンツをクロールできる
リソース効率: メモリ使用量の最適化
実装例
React 18のSuspenseを使った例:
jsxfunction App() {
return (
<html>
<body>
<Header /> {/* すぐに送信 */}
<Suspense fallback={<Spinner />}>
<SlowComponent /> {/* 準備できたら送信 */}
</Suspense>
<Footer /> {/* すぐに送信 */}
</body>
</html>
);
}対応フレームワーク
React: React 18のSuspenseとrenderToPipeableStream
Next.js: App Routerでデフォルト対応
Remix: 標準でサポート
SvelteKit: ストリーミング機能あり
ストリーミングSSRは、特にデータ取得に時間がかかるアプリケーションで、ユーザー体験を大幅に改善できる技術です。
ストリーミングSSRってなんですか?初心者の友達に教えるように、例とか使いながらおしえて
ストリーミングSSRについて、友達に説明するみたいに話すね!
まず、SSRって何?
SSR(Server-Side Rendering)っていうのは、サーバー側でHTMLを作ってからブラウザに送る仕組みのこと。普通のReactアプリ(CSR:Client-Side Rendering)だと、ブラウザが空っぽのHTMLを受け取ってから、JavaScriptでページを組み立てるんだけど、SSRはサーバーで最初からHTMLを完成させちゃう。
例えば:
CSR: 「空の箱を送るから、中身は君が組み立ててね」
SSR: 「完成品の箱を送るよ、すぐ使えるよ」
じゃあ、ストリーミングSSRって?
従来のSSRは、ページ全体が完成するまで待ってから一気にブラウザに送ってた。でもストリーミングSSRは、できた部分から順番に送ってくれるんだ。
料理で例えると:
従来のSSR: 全ての料理が完成してから一気にテーブルに運ぶ
ストリーミングSSR: できた料理から順番にテーブルに運ぶ
具体例で見てみよう
ブログページを表示する場合:
- ヘッダー(すぐできる)→ 即座に表示
- ナビゲーション(すぐできる)→ 即座に表示
- 記事本文(データベースから取得中...)→ 少し待つ
- コメント欄(API呼び出し中...)→ さらに少し待つ
- 関連記事(推薦システムから取得中...)→ 最後に表示
従来だと全部揃うまで真っ白な画面だったけど、ストリーミングなら上から順番に表示されていく!
メリット
体感速度が速い:ユーザーがすぐに何かを見られる
SEO効果:検索エンジンもすぐに内容を読める
ユーザー体験向上:待ってる感じが少ない
実際の技術例
React 18のSuspense + streaming
Next.js 13+のApp Router
Remix
こんな感じで、ストリーミングSSRは「待たせない優しい技術」って覚えておくといいよ!ユーザーが退屈しないように、できたところから見せてくれるんだ。
何か他に気になることある?
【ただ聞くだけの場合】
ノーマルの場合だと、Reactがちゃんとわかっていれば、なんとなく理解できる感じだと思います。
【おすすめ】
ただ聞くだけよりもかなりわかりやすくなったんじゃないでしょうか...?
まず、SSRって何?
おすすめのプロンプトの方だと、まずそもそも SSRとは何かを解説してくれてますね。
料理で例えると:
従来のSSR: 全ての料理が完成してから一気にテーブルに運ぶ
ストリーミングSSR: できた料理から順番にテーブルに運ぶ
HTMLの分割送信をするみたいなのを料理に例えて解説しているみたいです
具体例で見てみよう
ブログページを表示する場合:
料理で説明した上で実際のWebサイトではどうなのかみたいなところも書いてあってよりわかりやすいですね。
試してみてどうだったのか
生成AI鬱の状態では、
受け身で解題の解像度が低く
- ふわっとしたプロンプトを書く
- ふわっとした結果が返ってくる
- AIを使う技術が身につかない + 知識もつかない
AIを使いこなせると、
前のめりでで解題の解像度が高いから

最後に
最後まで見ていただきありがとうございました。
「実際こんなの当たり前にやっているよ」「今更ですか」みたいなところもあると思いますが、気づいたら何も考えてないみたいなこともあったりするので、もしそうなった方の一助になれればと思います!
参考
インスピレーション元: 「生成AIを使うと頭が悪くなっていく問題」をどうするか?
※本記事は2025年11月時点の情報です。