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

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

概要

  • 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にシリアライズして、すべてのログイベントごとにファイル全体を書き換えたことがある。)

LLMではまだできないこともあるよ。例えば、LLMと対戦してチェスを学ぼうとすると、すぐに一連の手を追えなくなる(だいたい5〜10手くらいが限界;私が見た中で最長は18手)。違法な手を打ち始めるからね。また、あなたの側の無効な手も受け入れちゃうから、特定の駒の使い方を間違えても修正されることはない。複雑な問題を実際にモデル化できないから、ユーザーがどんな質問をすべきか、すべきでないかを意識する必要があるんだ。LLMはナイトの動き方やロンドンシステムへの対応方法を教えてくれるかもしれないけど、フルゲームを一緒にプレイすることはできないし、ボードの状態に応じた最善の手をアドバイスすることはほぼ不可能だと思う。大企業についての情報は提供できるかもしれないけど、1億ドル未満の公開企業についてはあまり良い情報は出せないだろうね。でも、聞けば自信満々に答えてくる。多くの人やユースケースにとっては危険地帯で、間違っていることに気づかないから、エラーを見つけるには努力と知識が必要なんだ。氷河の上を歩いていて、次の一歩が雪を突き破って深い隠れた裂け目に落ちないことを願っているような感じだね。

人々は自分がどれだけ間違える可能性があるかを認識していないし、そのエラーに気づくには努力と知識が必要なんだ。僕には高学歴の友達(PhDやMD)がいるけど、彼らはAIやLLMが間違いを犯さないと単純に思ってる。彼らは、幻覚が起こる可能性があることにショックを受けてた。完璧な文法や構造、そして自信に満ちたLLMの出力が、ユーザーに専門性を仮定させるハロー効果があるのかな?

エージェントモードを使ってコーディングしようとしても、最初はうまくいくけど、どんどん逸れていくのは明らかだよね。僕は、さまざまなクラウドモデルを使ってコードをインデントしようとするような、全く関係のないことをしようとするのを経験したこともある。

うん、チェスの例は面白いね。チェス専用のAIは人間より明らかに優れてるけど、一般的なAIは合法的な手を打つのもやっとって感じ。AIの限界は、今のLLMよりずっと高いのが明らかだね。

すぐに、一連の手を長く追跡できないことに気づくよ(通常は5~10手;私が見た中で最長は18手)。チェスでは、過去の手は関係ないし、LLMは無関係なデータをフィルタリングするのが得意じゃないからね。より良いパフォーマンスを得るためには、コンテキストウィンドウに関連するデータだけを含めるべきだよ:現在のボードの状態をね。

LLMがチェスをするのは大したことじゃないよ。チェスのゲームでモデルを訓練すれば、そこそこなELOでプレイできて、違法な手を打つことはほとんどない(つまり99.8%の合法手率)。そういうモデルはいくつかあるよ。訓練後はチェスの能力に影響が出ると思うし、OpenAIとかはそれをあまり気にしてないんじゃないかな。でも、LLMはちゃんとチェスをプレイできるよ。

これは、アンドリュー・ングの最近のAIスタートアップに関するトークの見解と一致してるね。彼がこの動画で言ってたのを思い出すけど、創業者に対して新しいアドバイスとして、コアの基盤に積み上げるのではなく、ピボットする際にはプロトタイプを捨てるべきだって。これは、記事に書かれている影響によるものなんだ。彼はまた、仮の数字も示していて(「Rapid Prototyping and Engineering」のセクションやスライドの~10:30を見てみて)、プロトタイプ開発は既存の生産コードベースに比べて10倍の向上が見込めるって言ってる。これは、業界がVMからコンテナに移行したときの「ペット」から「家畜」への切り替えに似てる気がする。ただ、新しい見方では、コードベースはペットよりも家畜に近いってことなんだよね。もしこれが本当なら(プログラマーにとっては議論を呼ぶトピックだろうけど)、この新しいコーディングエージェントの世界では、最初から参加してLLMを生産的にするためのプラクティスを取り入れることに利点があるかもしれないね。

いいポイントだけど、ちょっと言わせてもらうと(細かいことを言うようだけど)、機械やコンテナが「家畜」と呼ばれるのは聞いたことがないな。僕の周りではいつも「ペット」と「牛」って感じだ。これって地理的な違いなのかな?

おお、「ペット対家畜」のアナロジーは「職人対適当な作り手」の議論よりもずっといいね。LLMを使うことが、よく作られた理解しやすい結果を軽視することにはならないから。でも、コード自体を見る視点が大きく変わることを示してるよね。コードへの感情的な愛着と、目的を達成するための手段としてのコードの違いって感じ。

指摘してくれてありがとう。これは洞察に満ちたアナロジーだと思う。生成されたコードは、大規模なクラウドコンピューティングの管理と同じように扱うことになるんじゃないかな。これは、数年使われているレガシーコードには当てはまらないと思うけど、運用中のデプロイメントがより高い信頼を与えてくれるからね(変更による回帰エラーのリスクも高くなるけど)。あなたの考えについてブログに書いたことある?stillpointlab.comのサイトはあまり情報がないし、@stillpointlabも同様だね。

TFAのほとんどには同意するけど、これには反対だな。> これは、チーターがAIが提供できるレベルで停滞することを意味する。僕の経験から言うと、AIを効果的に使うスキルは、「固定的」な考え方ではなく「成長マインドセット」でAIに接することだと思う。僕がやってるのは、AIのマネージャーとしてロールプレイして、タスクを与えること。出力が「十分に良い」かどうかを判断できるだけの知識があれば、プロンプトを使ってメタ認知を貸して、障害を乗り越えさせることができる。もちろん、リターンは次第に減っていくけど、最初に出てきたものよりもかなり質の高い出力を得られることが分かった。自分でスキルの「やり方」を学ぶ必要はなくて(つまり、まだ「チート」してる)、タスクの難しい部分にだけ学習を集中させてる。こうすることで、時間が経つにつれてその領域でのマネージャーとしてのスキルが向上していく気がするんだ。

あなたがやってることを「チート」とは思わないよ!

どうやって「質がかなり良い」ってわかるの?その「どうやって」がわからないのに。質の向上は、最初にあるゴミに対して相対的なものに見える。結果に自分が感動する限り、実際に質が高くなくても関係ないのかな。

LLMの最大の利点は、広告やSNSのようなUIの邪魔を受けずに、正確な回答を標準化された形式で得られることだと思う。redditやインスタ、tvtropesで答えを探すのとは真逆だね。最初の邪魔のないOSが、思考や想像を助けるもので、消費デバイスじゃなくて、子供たちがスキナーの箱に引き込まれないようにルーターでURLをブロックしなくても済むようになるのが待ちきれないよ。デザイナーがアドホックに実装した無意味なUIを通り抜けることなく、ドキュメントや仕事の質問から答えを得られるのが本当に好きなんだ。

「AI」の答えって、あんまり正確じゃないと思うし、場合によってはリスクになることもあるよね。下の方に「AIの回答には間違いが含まれることがあります」って書いてあるけどさ。 >「redditやインスタ、tvtropesで答えを見つけるのとは逆だよね。」 ほんとそれ。redditとか他のフォーラムで、誰かがそのトピックをよく知らないって分かることがあるけど、たいていは誰かが知ってて答えがあるんだよね。残念ながら、「AI」はそういうのを学習してるから、正しい答えを出すのと同じくらい間違った答えを出す可能性がある。これは何の改善にもなってないよ。 >「UIの気を散らす要素、広告やSNSをかき分ける」 ああ、つまり「AI」がずっと無料でクリアだと思ってるの?今のうちに楽しんどけよ、だってこれらの「AI」企業は手に負えない状態で、まるで大動脈が消火栓みたいにお金を失ってるから、すぐにあなたの日常を明るくする広告やSNSがたくさん来るよ。無料の恩恵は永遠には続かないから、これは「損失リーダー」としてあなたをハマらせるためのものだと思って。

「正確」

ブログ記事にはたくさんのチャートがあって、客観性や厳密さの表面を持ってるけど、実際にはただの雰囲気と推測に過ぎないよね。一方で最近の実証研究は逆の方向を指し示していて、AIの使用が不平等を増加させることを示してる。 https://www.economist.com/content-assets/images/20250215_FNC... https://www.economist.com/finance-and-economics/2025/02/13/h...

グラフィックには、不平等が増加することを示す4つの研究と、不平等が減少することを示す6つの研究があるよ。

リンクありがとう。$70億のデータセンター(Meta)が必要だって信じてる人には明らかだと思うし、その投資はサブスクリプションで償却される(Metaの場合はユーザー監視の強化でも)。生産手段は小さな寡占にあり、残りは冗長か搾取される小作農になるだろうね。(「AI」が機能するという前提のもとで、少なくともその支持者たちは公然とそう言ってるけど。)

そうそう、グラフはすごく大きな仮定をしてるけど、それが裏付けられてるところはAIのマキシマリストの妄想くらいしかないよね。オンラインでビジネスとして展開される「雰囲気で作ったサイドプロジェクト」に関してもギャップがある。コードベースはすごく大きくて複雑なの?いや、そうじゃない。AIは初心者から入力を受け取って、この分野で「十分に良い」ものを作れるの?それも違う。

ある意味で同意するよ。必ずそうでなければならないとは思わないけど、白いラボコートを着ていると科学者っぽく見えるっていう感覚は同じだね。彼らの正直な試みは、物事の捉え方の関係を表現しようとしたんだと思う。これは、仮説を表しているというアイデアを明確に伝えられれば、価値のあるコミュニケーションの形として使えると思う。グラフに「仮説」とラベルを付けるのが一番シンプルだけど、微妙で識別しやすいビジュアルの変化の方がいいかもしれないね。軸に波線を使うのは、その表現のアイデアとして思いつくよ。ただ、値が軸を越えたときに起こる決定的なイベントについて仮説を表現する能力が心配だな。そういう場合は、直線が必要だと思う。もしかしたら、プロットが表示されるポイントを越えた軸の端に波線を持たせるだけで十分かもしれないね。それ以上に、この記事は、習得が進むにつれて曲線が平坦化することを前提にしていると思うけど、それが必然だとは思わない。比例的な改善を評価するからそう見えるのかもしれないし、スキルを対数スケールに暗黙的に置いているからかも。著者の投稿は、経済学者のリンクよりも誠実だと思う。みんなの意見を知りたいし、正直に言ってほしいな。もし彼らが確かなデータを持っているなら、それを示して仮説を確認する方法を教えてほしい。逆に、データを集めて、明示的に述べる勇気がない仮説を暗示する測定値だけを公開するのは良くないよね。

不平等 それは、電話やノートパソコンを持っている誰にでも無料だよ。

そうだね。退職した数学者として、28歳の熱心な生産性を求めているから、2025年にはAIに全力投球してるよ。今はClaudeの月200ドルのMaxプランに加入して、Claude Code Opus 4を制限なしで使っている。57ファイルのレガシーコードベースをレビューするために並行セッションを実行すると、やっぱり制限に引っかかることが多いね。しばらくの間、誰とも話さず、AIについての情報も読まなかった。自分の経験に合わないノイズばかりだったから。最近、HNには面白い意見がいくつかあったけど、これはそうじゃない。僕は、神経多様性のある人たちがAIを使うと成功しやすいと思ってる。これは簡単に空虚な言葉として片付けられるけど、この意見にはしっかりした理論がある。AIは巨大な連想エンジンなんだ。線形エンコーディング(「王 - 男 + 女 = 女王」みたいなやつ)は線形代数だ。僕は数十年にわたって線形代数を教えてきた。今日、眼科医に説明したように、三本の指で皿をバランスさせようとするとき、指が離れている方がうまくいくんだ。僕の人生の中で、人々は僕が状況をあまりにも遠くのアナロジーで分類するたびに目を回してきた。今、僕はAIと一緒にコーディングする時間がほとんどで、AIは僕が焦点を合わせようとしていることに対して「指が離れている」遠くのアナロジーに非常に良く反応してくれる。AIは線形代数に基づく連想エンジンで、僕は部分空間を説明する才能がある。AIは天井を上げているだけで、床を上げているわけじゃない。ポアンカレ予想のより良い証明を完成させようとしているところで、もし成功したら、大学院生への教訓は「ふーん。第二の上昇」じゃなくて、「この69歳のじいさんがノイズを無視してAIのサイボーグになった」ってことになるだろうね。

もちろん、AIは不平等を増加させるよ。自動化された梯子引き上げ技術だ。何かに優れるためには、下の段を通り抜けてスキルを身につけなきゃいけない。AIはその下のレベルの仕事をすべてこなして、経験を必要とする人たちを路上に追い出し、未来の専門家を奪ってしまう。最も利益を得るのは、すでに梯子の上にいる人たちで、彼らは何十億も投資して梯子をより早く上げようとしている。

自分が比較的得意なこと(例えば、コーディング)では、低レベルのタスクをより効果的にこなせるようになることで「限界を引き上げる」手助けになっているのがわかる。でも、自分の能力の基準が上がったとは思えない。得意じゃないことに関しては、速く「追いつく」錯覚を与えてくれるかも。これって、個人的な限界の引き上げなのかな?こういうスキルアップのツールは、提供される形式によると思う。答えをくれるチャットを使っても、そのトピックで上達するとは期待しない方がいい。自分で答えを考えさせて、個別にフィードバックをもらえるツールを使えば、レベルアップするかもしれないね。

自分が苦手なことについては、'スピードアップ'しているような錯覚を持たせてくれる。たぶん、それは個人的な天井を上げることなのかな? 反対だと思う。それは個人的な天井を上げる錯覚に過ぎない。 --- 例1: アリスはシンプルなテキストだけのブログを持っている。彼女はウェブサイトのスタイルを更新したいけど、以前の投稿は残したい。彼女はページのスタイルを「モダン」に更新する方法を調べる。彼女はホームページ、投稿ページ、アバウトページを更新する。でも、ログインページは異なる要素を使っているから、壊さずに更新する方法がわからない。彼女は新しいフォーム要素を学ぶために調査し、その過程でログインシステムの構築方法に関する推奨を見つける。彼女はフォームのスタイルを変更する方法を学ぶためにテストページを作り、そのついでにログインシステムの構築方法も学ぶ。彼女はログインページを再デザインする。アリスは自分の達成できることの天井を上げたと信じている。アリスは正しい。 --- 例2: ボブもシンプルなテキストだけのブログを持っている。彼はウェブサイトのスタイルを更新したいけど、以前の投稿は残したい。彼はLLMにスタイルを「モダン」に更新する手助けを頼む。彼はホームページ、投稿ページ、アバウトページ、ログインページを更新する。でも、ログインページはもう動かない。ボブはLLMに修正を頼み、何度かやり取りした後、再び動くようになる。ボブは自分の達成できることの天井を上げたと信じている。ボブは間違っている。彼は自分の知識や能力を増やしていない。1週間後、彼の投稿は消えてしまった。 --- 両方の例の違いはほんの少しだけ。1. アリスはLLMを使わないが、ボブは使う。 2. アリスはページを再デザインする方法を知っているが、ボブは知らない。 3. アリスはログインシステムがどう機能するかを知っているが、ボブは知らない。ボブはLLMにログインページを再デザインするよう頼んだが、LLMはそれを実行した。ページが壊れたとき、ボブは自分が正しいユーザー名とパスワードを使っていることを確認したが、まだ動かなかった。彼はLLMに、自分のユーザー名とパスワードで常に動作するようにログインページを変更するよう頼んだ。LLMは、ハードコーディングされたユーザー名とパスワードを常に受け入れるログインフォームを生成した。そのハードコーディングされたチェックはクライアント側で行われ、ユーザー名とパスワードは今や公開されて見える状態になっていた。ボブはLLMにフォームを安全にするよう頼まなかったし、その必要があることすら知らなかった。彼は避けるべき足元の罠が何かも知らなかった。アリスとボブは同じ出発点から始まった。彼らはログインシステムをどう構築すべきかの知識が欠けていた。その知識はどこかに文書化されているから知られているが、彼らには未知だった。それは「知られている未知」だ。アリスがフォーム要素のスタイルを学んだとき、彼女はフォームがどう機能するかに関するリンクを読み、そこからログインシステムがどう機能するかに関するリンクにたどり着いた。その知識は彼女にとって、未知の知識から「知られている知識」へと変わった(彼女が今は知っている知識)。ボブがLLMにログインページを再デザインするよう頼んだとき、ログインシステムがどう機能するかの知識は彼にとって「知られている知識」にはならなかった。そして1週間後、退屈な子供がそのページを見つけ、フォームを右クリックして検査し、ログインに使えるユーザー名とパスワードを見つけることになる。

良い見方としては、「AIはプロトタイピングには良いが、エンジニアリングには向かない」と言えると思う。つまり、AIツールは物事をすごく早く進める手助けはできるけど、幅と深さが欠けているんだ。彼らを使ってコンセプトの証明を生成するのは早いけど(大きな問題の周りのサブ問題でも)、幅がないから全体の文脈が欠けていて、深さがないから、どんなベテラン(マスター)が持っている洞察が欠けている。逆に、「エンジニアリング」の側面は「物事が動く」以上のものなんだ。すべてが正しい方法で機能し、エッジケースを扱い、文脈を意識し、失敗モードを作り出すことが含まれる。あなたが世界で最高のプログラマーであっても、それが良いエンジニアであることを意味するわけじゃない(実際の世界では、これらは同時に学ぶスキルとして結びついている)。完璧なリートコーダーであっても、実際のチームでは役に立たないかもしれないけど、これらのスキルは相関しているんだ。問題は、マネージャーが製品をエンジニアリングするための魔法のボタンは決して存在しないということ。ほとんどの時間、ベテランは実装ではなく設計に費やしている。習得するためには経験が必要で、その経験は微妙なことを理解することを要求する。明白でないことが多い。エンジニアがコードベースのすべてのコードを生成する魔法のボタンがあるかもしれないけど、それはエンジニアを置き換えるものではないと思う。(これは、AIコード生成器の設計における問題でもあると思う。管理者が魔法のように機能を生成できるように設計されている