同じAIが、ある人には「ポンコツなチャットボット」に見え、ある人には「めまい」を起こさせるのは、任せる問題の大きさや仕事の分野、使えるモデルが人によって違うからです。Andrej Karpathyは日本時間の10月12日早朝にXへ投稿した長い文章で、人々を4層のファネルに分けてこう説明しました。この投稿を念頭に、同じ週に開発者によく読まれたAIの記事8本をあわせて読みました。ほとんどはファネルのどこか1層の話でした。
出発点：Karpathyのファネル
日本時間の10月12日早朝、Andrej KarpathyがXに長い投稿をしました。4月に書いた投稿を改めて持ち出し、LLMに何ができるかについての理解は人によって差があり、その差がさらに広がっていると書いています。19日時点でいいね43,406件、表示662万回。Hacker Newsでも728ポイントを獲得し、コメントは1,072件にのぼりました。
Karpathyは人々を4層のファネルに分けました。一般の人がAIを使ってみても、まだ「ポンコツなチャットボット」に見えます。反対の端では、ごく一部の専門家が、曲線が垂直に立ち上がるめまいを感じています。数字は本人が「ざっくりした見積もり（napkin math）」だと断っています。図に沿って、1層ずつ下りてみます。
約60億人、人口の75%は、LLMにほとんど触れたことがありません。
10億〜20億人、約20%は、無料のチャットボットをときどき使います。少し便利な検索や、文章作成の手伝い程度に見ています。
Karpathyは、数学やコード以外の専門職の多くもこの層にいると見ています。役員のように人と話す時間が長い人は、変化を頭では理解していても、実感は間接的だということです。
約2,000万人、0.2%は、最上位のモデルで数学やコーディングの仕事をしています。何週間、何か月もかかっていた大きなプロジェクトを、エージェントがプロンプト1つで終わらせるのを目の当たりにしています。
Karpathy自身も、1年前まではコードを1文字ずつ手で打っていたと書いています。
約5,000人は、AI企業の社内だけで使われている最先端のシステムを使っています。数千のエージェントが何週間も協力して大きなソフトウェアを作る姿だといいます。
その一方で、人間によるレビューや理解は遅れ始めていると付け加えています。
このファネルが生まれる理由として、Karpathyは3つを挙げています。1つ目は、問題が大きく長期にわたるほど効果を実感しやすいこと。2つ目は、モデルの能力がデジタルかつ検証可能で、お金になる分野に集中していることです。本人はこれを「ギザギザ（jaggedness）」と呼んでいます。3つ目は、使えるモデルが無料・有料・社内向けに分かれていることです。
ごく一部の専門家は、曲線が垂直に立ち上がるめまいを感じている。そして、それがすべて同時に起きている。
Andrej Karpathy, X, 2026-10-11
このファネルを念頭に置いて同じ週によく読まれた記事を読むと、ほとんどがファネルのどこか1層の話でした。
ベンチマークで測れている仕事はどれくらいか
Mercorは「Benchmark Map」で、米国労働省の職業分類（O*NET、職業923・タスク18,797）に、公開ベンチマーク29種の問題を1つずつ対応づけました。対応づけはLLMに任せ、人間の専門家がつけたタグと照らし合わせて検証したそうです。その結果、米国で働く時間の90%が、既存のベンチマークではほとんど測られていないタスクに使われていると結論づけています。5問以上で測られるタスクを1つでも持つ職業は、923のうち208だけでした。22の職業群のうち6つには、そうした職業が1つもありません。HNでは624ポイントを集めました。
著者たちは、この結果を暫定的なものだとしています。選んだベンチマークが代表的な標本ではないため、測れている範囲が実際より狭く出ている可能性があります。ソフトウェア工学のようにベンチマークが多い分野は、職業群ごとに数を絞ったせいで少なめに出ているとも書いています。それでも、示す方向はKarpathyのいうギザギザと同じです。私の読みでは、モデルが得意なことと、得意かどうかを確かめられることが、同じ場所に集まっているということです。
道具か、自動化か
10月12日、Clojureの作者Rich Hickeyが「『AI』は道具ではない」という文章を公開しました（HN 318ポイント）。Hickeyにとって道具とは、手に持って扱い、使うほど腕が上がるものです。LLMは頼めば代わりにやってくれるので道具とはいえず、自動化だという主張です。読むことやコードを書くことを任せてしまうと、その作業から学んでいたこと、つまり書く力、論じる力、考える力を失うと述べています。
道具とは、それを使って何かをするためのものだ。代わりに何かをしてくれるものではない。
Rich Hickey, ‘AI’ Is Not a Tool
同じ日にHuahaiが書いた反論は、HNで805ポイントを集め、より多く読まれました。Huahaiも、任せれば学ぶ機会を失うことがある点には同意しています。ただ、コンパイラーや表計算ソフトも多くの作業を自動でこなすのに、私たちはどちらも道具と呼んでいる、と指摘しています。結果を問い直し、試し、直しながら使う人にとっては、LLMも道具だということです。逆に、要約だけ読んで原文を飛ばせば、読むことから得ていたものを失う、と見ています。
ほかの道具と同じく、うまく使うには腕がいる。
Huahai, AI is a tool and using it well takes skill
私には、2つの記事がファネルの別々の層を語っているように見えます。ファネルの下に行くほど、結果を試して直す時間も増えるはずです。その作業を省けば、Hickeyの心配が当たります。
ファネルのいちばん下：1日3万件のマージ
Anthropicのエンジニアリングブログに載った「Redesigning source control at Anthropic」には、Karpathyのいう最下層が数字で出てきます（HN 894ポイント）。モノレポへの1日のマージ数は、2026年5月の約2,500件から、9月には3万件を超えました。CIは1日に約2,500万回チェックアウトします。gitはクローンごとに全履歴を持つオフライン前提の設計ですが、常につながっているエージェントや自動化ジョブには、その前提が合わなかったそうです。そこでScionという独自のバージョン管理システムを作り、5か月でモノレポをgitから移行しました。
Scionは、クライアントが常にオンラインであることを前提にしています。履歴、blame、コミット、マージはサーバーが担い、クライアントは容量の決まったキャッシュだけを持って、必要なファイルだけを取得します。以前のgitミラー構成に比べて、CPUとメモリの使用量は約200分の1に、チェックアウトは数分から数秒になったそうです。ただし著者たちは、gitを置き換えるつもりはないとしています。ほかのgitプラットフォームが参考にできるよう、やり方を公開したということです。
同じ週に出たセキュリティの問題3件
エージェントが常に動いていて、APIキーまで持っているなら、攻撃される隙も増えます。今回よく読まれた記事のうち3本が、その話でした。
Codex CLIの常駐デーモン（HN 609ポイント）。9月25日にopenai/codexリポジトリに立てられたIssueです。報告によると、CLIを対話モードで開くと、ウィンドウを閉じても終わらないバックグラウンドのデーモンが起動します。ホームフォルダには約374MBのパッケージがコピーされ、更新を確認してバックエンドを再起動するプロセスも別に動きます。投稿者は、この機能を既定でオフにするか、最初に一度は確認してほしいと求めました。19日時点で、管理者からの返答はありません。
OpenCodeの侵害（HN 964ポイント）。10月17日、OpenCodeがXで告知しました。大規模な蒸留（distillation）攻撃に関連するセキュリティ侵害で、OpenCode Consoleのユーザーの1.4%が影響を受け、該当するユーザー全員にメールで知らせたという内容です。HNの議論には、受け取った案内メールだとして「ワークスペースに保存したOpenAIやAnthropicなど外部サービスのAPIキーが漏えいした可能性があるため、無効にして再発行してください」という文面が投稿されました。
隔離と監視の失敗（HN 950ポイント）。7月以降、複数のAI企業が「モデルが許可なく外部のシステムにアクセスした」と公表しています。CSO Onlineはこうした事例をまとめて取り上げました。記事に登場するセキュリティの専門家たちは、エージェントが賢かったからではなく、サンドボックスや外部通信の制限といった昔からのセキュリティの基本を守らなかったから起きたと見ています。
デーモンのIssueに書かれた止め方は次のとおりです。投稿者によると、デーモンを止めても更新プロセスは残り、別に終了させる必要があったそうです。
codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop' # not stopped by `daemon stop`
rm -rf ~/.codex/packages/app-server-daemon3つの話は結局、エージェントにどこまで権限を渡すかという問題につながります。エージェントに持たせるAPIキーを必要な範囲だけに絞っておけば、漏れてもできることは限られます。裏で動くプロセスは、いつ何をしているかが見えるべきです。隔離や監視といった昔からのセキュリティの基本は、エージェントにもそのまま当てはまります。
エージェントに残すもの
Kevin Liaoは「Agents don’t need memory, they need documentation」（HN 392ポイント）で、会話履歴をベクトルDBにためる「記憶」ではなく、ドキュメントを残すべきだと書いています。類似度検索では、何が正しく何が最新かを見分けられないからです。ドキュメントには、コードに表れない要件・決定・制約だけを書き、古くなった内容は後ろに書き足さずに書き直すよう勧めています。
このブログのリポジトリも、似たやり方で運営しています。リポジトリ直下のCLAUDE.mdとdocs/DESIGN.mdには、変えてはいけないルールとその理由を書いてあります。ルールの多くには、破ると失敗するテストもつけています。ドキュメントを信じるだけでなく、テストで確かめるわけです。Karpathyの言葉を借りれば、仕事を検証できる側へ寄せておく、ということになります。
ファネルのどこにいても、やってみる価値のあることは似ています。任せた仕事の結果を確かめる方法を先に用意する。エージェントに渡す権限は狭くする。そして、わかったことはドキュメントに残す。
参考にした記事（数字は2026年10月19日時点）
Andrej Karpathy、Xの投稿・いいね43,406・表示662万回・HN 728ポイント
Mercor, Benchmark Map・HN 624ポイント
Rich Hickey, ‘AI’ Is Not a Tool・HN 318ポイント
Huahai, AI is a tool and using it well takes skill・HN 805ポイント
Anthropic, Redesigning source control at Anthropic・HN 894ポイント
openai/codex Issue #48195・HN 609ポイント
CSO Online、隔離と監視の失敗についての記事・HN 950ポイント
Kevin Liao, Agents don’t need memory, they need documentation・HN 392ポイント