世界を動かす技術を、日本語で。

AIは床を上げるものであり、天井を上げるものではない

2025年8月1日原文(elroy.bot)

概要

  • AIの登場 により、学習曲線や知識習得のプロセスが大きく変化
  • 個別最適化 された学習支援が可能になり、初心者の課題解決が容易に
  • 熟練者や専門家 にとっては依然としてAIの限界が存在
  • 創造分野や既存アプリ ではAIのインパクトは限定的
  • AIの恩恵と課題 が分野や利用者によって大きく異なる現状

AIによる学習曲線の変化

  • 従来の学習資源 は特定のターゲット層を想定して作成される
  • 自分の知識や背景 に合った教材を見つけるのは困難
    • 例:$topic_of_interestを$related_topicの知識で学びたい場合、適切な教材探しが難航
    • 必須スキル$prereq_skillの必要性に初心者が気付かない問題
    • 初級レベルで停滞し、中級の壁$intermediate_sticking_pointで苦戦
  • AIは利用者の理解度 に合わせて直接質問に答えたり、作業を代行
  • 学習曲線が滑らか になり、個別最適化学習が現実に

熟練者にとってのAIの限界

  • 専門家や上級者 はAIの限界を早期に実感
  • 高度なトピックや論争的な内容 はAIの訓練データが不十分または一貫性に欠ける
  • AIの出力は表層的 になりがちで、深い知識や信頼できる情報源の提示が難しい
  • マスタリー(熟達) の難しさは依然として残る

AIによる「カンニング」問題

  • OpenAI Study Mode の登場で、AIから答えだけを得る「カンニング」が容易に
  • AIの限界で学習が頭打ち になり、真のスキル向上には繋がらない
  • 長期的には「カンニング」利用者は成長が止まる という指摘

AIがもたらす学習曲線変化の社会的影響

  • 技術革新はエコシステム全体を変化 させ、恩恵と不利益が不均等に分布
  • インパクトの大きさ は、その分野で成果を出すために必要な熟練度で決定

コーディング分野でのAIの影響

  • エンジニアリングマネージャー などはAIで新しい技術やフレームワークを短期間で習得可能
    • 例:バックエンドEMがAIの助けでiPhoneアプリを開発
  • 大規模・複雑なコードベース ではAIの有効性が限定的
    • 既存の複雑な要件や実装への理解がAIには不足

クリエイティブ分野への影響

  • 創作分野ではAI生成コンテンツの影響は限定的
    • 競争が激しく、成功には「新規性」が必須
    • AIによる画像やテキスト生成は容易になったが、消費者の注意を引くには独自性が求められる
    • 例:Ghibli風アバターの流行は一過性、Howl's Moving Castleの文化的地位は不変

既存アプリ利用分野でのAIの影響

  • 既存の専用アプリがある分野 (例:メール、フードデリバリー)ではAIの影響が限定的
    • メール:既存アプリで十分に整理・フィルタリング可能、AIによる要約は有効性が低い
    • フードデリバリー:既存UIが最適化されており、AIがそれを超える設計をするのは困難

AIの普及とその不均一性

  • AIは知識労働の「底上げ」 を実現したが、全ての人に恩恵があるわけではない
  • 利用者や分野ごとにAIへの評価や影響が大きく異なる
    • 技術職の管理者には大きなインパクト
    • 置き換えを恐れる人、AIの有用性を見出せない人も存在
  • AIは万能ではないが強力な技術
    • 自分に合わなければ無理に使う必要はない
    • ただし「検索」分野は例外的に有用

Hackerたちの意見

AIは補間者であって、外挿者じゃないんだよね。

これを「侵入者」と読んじゃった。エクストラローパーって何?

すごく簡潔ですね、こういう洞察をシェアしてくれてありがとう。

これは、他のAIの分野でも同じことが言えると思う。平均以下の人でもAIを使えば、平均的な結果は得られるから。

だから、ここで反対してる人が多いのも納得だよね。みんな平均以上だと思ってるのかな。

これはAIに関する別の名言とも一致してるね。LLMから何か利益を得るためには、自分がLLMよりも多くのことを知っている必要がある。

平均以上の人もそれを使って平均的な結果を得ることができる。それも実際には役に立つことがあるよね。多くのタスクやユースケースでは、十分な結果の基準がかなり低いこともあるし。

「平均以下の人もAIを使って平均的な結果を得ることができる。でもそれは平均を上げることになる。」

エージェントは新しいプロジェクトには強いけど、既存のコードベースにはあまり向いてないから、新機能は(意見が強い)新しいプロジェクトとして準備しないといけないんだよね。壁から配線をぶら下げておいて、インターンがそのままプラグを差し込むだけで済むように。残りの作業は人間がやらないといけないし、インターンが壁を開けて絵を掛ける羽目になる。

そんなのありえない。npmのプロジェクトYで何かやり方が分からなかったら、GitHubからWebStormでチェックアウトして、ジュニに聞いてみなよ。すぐにいい答えが返ってくることが多いから。もしダメなら、コードベースを理解するための質問をしてみればいい。迷路のようなMapのデータ構造が分からなくても、どう使われているかをスキャンしてドラフトのドキュメントを作成してくれる。確かにJiraのチケットを指示してPRをもらうことはできないけど、ペアプログラマーとしては使えるよ。独りで作業するよりは速くはないけど、テストを書く量が増えて、エラーハンドリングについて議論することで、最終的にはより良い仕事ができるようになる。

そうじゃないよ。得意なこともあれば苦手なこともある。使えば使うほど、どっちがどっちか分からなくなってくる。

エージェントには、プロジェクトを立ち上げるのがあまり得意じゃなくて、中小規模の既存プロジェクトで使うとすごく良いけど、サイズが大きくなるにつれて徐々に悪化するカーブがあると思う。新しいプロジェクトだと、LLMが「例のような」コードに落ち込むことが多いんだ。これは本番環境には絶対に入れないようなコードだよ。(例として、クラウドが僕のプロトタイププロジェクトで、タスクごとのファイルログを配列にプッシュして、全体をJSONにシリアライズして、すべてのログイベントごとにファイル全体を書き換えたことがある。)

Hacker Newsで議論の続きを見る