AI codingの実力は「解けた数」ではなく、どんなタスク・文脈・ツールで試したか（分母）でほぼ決まる。
AIがコードを書くかどうか、みたいな議論はいつも燃える。でも、肝心の測り方がズレていることが多い。見えているのは「何問解けたか」。見えていないのは「何を解かせたのか」。ここが抜けると、同じデモでも結論が真逆になる。
まず「分子」ではなく「分母」を見る：AI coding評価の統計的な落とし穴
AI codingの評価は分子（解けたタスク数）より、分母（タスク条件の違い）を見ないと統計的に誤る。
10-lineのユーティリティ関数を書くのと、40サービスにまたがる決済システムを直すのは別物。これは精神論じゃなく、単に条件が違う。
例えば、モデルに渡したのはrepository全体なのか、切り貼りした3つのファイルなのか。testsは走るのか。testsの質はどうか。ドキュメントはコードと一致しているのか。terminal accessやlogsはあるのか。retriesは許されるのか。こういう「分母」の中身が、だいたい全部を決める。
で、ここが気持ち悪いところで。楽観派は「一番きれいに成功したラン」を見せがち。悲観派はコンテキストを削って、ツールも縛って、転んだところを見せがち。どっちも“実験”を固定してない。比較として雑になる。
AI codingは「小人のプログラマー」ではない：セットアップが性能を作る
AIコーディング能力はモデル単体ではなく「model + context + tools + feedback + human judgment」のセットアップに依存する。
同じモデルでも、contextが増え、toolsが増え、feedbackが増えるほど、別の機械みたいに振る舞う。逆もそう。チャット欄だけで曖昧な指示を投げて、推測で当てさせる状況と、repositoryを見せて、testsを回して、失敗ログから直させる状況を同列に並べるのは無理がある。
ここで重要なのは、「AIが人間のように理解している」と言いたいわけじゃない点。そこは飛ばさない。言えるのはもっと狭い話で、セットアップが整うと、モデルは試行錯誤（trial-and-error loop）で当てに行ける、ということ。
実務で価値が出るスキル：エージェントの「失敗の種類」を見分ける
重要なのは、エージェントが追加コンテキスト不足なのか誤推測なのか見かけだけ正しいのか逸脱したのかを見分ける能力である。
AI codingが暗黒魔術に見えるのは、失敗が全部同じ顔をしているから。実際は違う。少なくとも、次のどれかに分けて扱わないと、対応がブレる。
- 単にcontextが足りない（関連箇所を見つけられていない／見せていない）
- 誤推測をしている（前提がズレたまま突っ走る）
- コードが“それっぽく”正しい（動きそうに見えるが、testsや境界条件で落ちる）
- architectureから逸脱した（局所最適で、システム全体の整合を壊す）
これ、地味。派手じゃない。でも防御スキルとしては強い。レビュー、tests、staging environments、debuggers、incident reports——人間同士の開発でも必要な仕組みが、そのまま前提になる。
神話1：Parrot Alibi（オウム言い訳）—「暗記だけ」では片付かない
AI codingは暗記（memorisation）だけで説明できず、DeepSWEのような新規タスクでも一定割合を解く。
「モデルは既に答えをmemorisationしてるだけ」という説明は、たしかに気持ちが落ち着く。hashmapみたいに、問題をキーにして答えを取り出してるだけ、と。
ただ、限定も必要。Yep, memorisation is real。OpenAIは、フロンティアモデルがベンチマークのpatchやcommentsやタスク固有の詳細をそのまま再現する例を文書化している。学習中に触れた問題は、後で解ける確率が上がる。ここは否定しない。
それでも「全部が暗記」は言い過ぎになる。反例として挙がるのがDeepSWE。これは既存のhistorical commitsやpull requestsをコピーできないよう、original engineering tasksを一から作っている。それでも、フロンティアのcoding agentsは相当な割合を解ける。
ただし、ここで「人間と同じ理解をしている」とは証明しない。主張は狭い。AI codingは「暗記の検索」だけでは切れない、という不快な結論が残る。
神話2：Private Code Is a Force Field — プライベートrepositoryは結界ではない
コードが非公開でも、明確な要件・周辺コード・強いtestsがあれば機能を再実装されうるため、プライバシー“だけ”は壁にならない。
ここは知財（intellectual-property）の論点が絡むので、雑に断言しない。でも、少なくとも「GitHubに出してないから安全」という単純な話にはならない。
モデルがあなたの実装を見たことがなくても、何をすべきかの説明がクリアで、関連コードにアクセスできて、実行できて、そして何よりtestsが「間違い」を教えてくれるなら、欠けた挙動をclean-room reimplementationに近い形で作り直せることがある。classic reverse engineeringとは少し違う。でも結果として、機能が再現される可能性は残る。
しかも皮肉で、再実装されやすいのは「要件が明確で、実行できて、受け入れtestsが強い」タイプの私的ソフトウェアだったりする。力場じゃない。地図に赤線が引いてある、みたいな話になる。
で、名前を落としておくと、本文の射程ではフロンティアモデルとしてFable 5やOpus 5が挙がる。ただしここも、能力の断定じゃなく「そういう方向に能力が増している」という文脈に留める。
神話3：The 80% Illusion — 80%は「仕事の80%」ではない
80%のbenchmarkスコアは選別・整備されたタスク集合の割合で、日常業務全体の80%を意味しない。
ベンチマークで70%や80%近い数字が出ると、つい「現場のチケットも80%いける」と読みたくなる。けど、その読み方が一番危ない。
OpenAIのSWE-bench Verifiedの作り方には、selection biasが入りうる。大量のプロの問題から、よりクリーンで仕様が整ったタスクへとフィルタリングし、結果としてGPT-のスコアがmore than doubledした、という話がここにある。マーケと科学を混ぜると、こういう歪みが起きる。
Scale AIのSWE-bench Proは別ルートで、専門家が曖昧なチケットを整備してからモデルに渡す。ベンチとしては改善。だけど同時に、現場が毎日扱う“曖昧さ”を反映しにくくなる。
つまり、ここは懐疑派に一部ポイントを渡すべきで、日常業務の80%が解ける、という主張に飛ぶのは無理がある。印象的ではある。けど、マーケの奇跡としては盛り過ぎになりやすい。
神話4：Codebaseは一枚岩ではない — 多ファイル・多サービスで魔法が漏れる
タスクが多ファイル・多サービス・多言語に跨るほど探索と整合維持が難しくなり、性能が劣化しやすい。
vibe coders的な空気が強いところで特に出やすい誤解が、「codebaseは一つの大きいファイル」みたいな扱い。現実は、変更はmoduleをまたぎ、servicesをまたぎ、設定レイヤーやDB、interfaces、APIs、場合によっては複数言語にまたがる。そこからが工学っぽくなる。
一つのファイルに問題が閉じていると、エージェントは華麗に見える。けど同じロジックが20ファイルと3言語に散ると、急に崩れることがある。理由は「急に難しいアルゴリズムになった」ではなく、関連箇所を見つけて、つながりを理解して、別の場所を壊さずに変える、という探索と整合のコストが跳ねるから。
ここは、開発者にとって悪いニュースだけでもない。現実のプロジェクトが大きく、散らかっているほど、architectureの判断が効く。人間の価値判断（暗黙知）がまだ強く残る領域でもある。
神話5：Modelがすべて — エージェントは「モデル以上」の機械
エージェントはモデル単体ではなく、tools・execution・feedbackを含む仕組みとして評価すべきである。
チャットボットが孤立したスニペットを吐くのと、実際のrepositoryに入ってsearchして、複数ファイルを編集して、実行して、エラーを読み、直し直し進むのは別物。だから「モデルだけで全部決まる」という見方は外れる。
とはいえ、悲観派が当てる点もある。モデル単体では全部できない。むしろ、できないからこそツールが要る。terminal access、tests、logs、memory、feedback。そういう補助輪があると、同じClaudeでも挙動が変わる。
AnthropicのFable 5の話はここに乗る。DeepSWEという同じharness上で、113のoriginalでlong-horizonなengineering tasksのabout 70%を解く、とされる。しかもSWE-bench Proより、だいたいroughly 5.5倍のコード量が必要な大きい仕事が中心、という位置づけ。
ただし、これで多ファイル問題が消えたわけじゃない。ナビゲーションが良くなった、という方が正確。結論はシンプルで、coding agentはモデル以上の機械だ、という一点に戻る。
神話6：Seniorityは堀（moat）— 守るのは肩書きではなく暗黙知の判断
シニアの価値は年数やタイピングではなく、暗黙知の判断・問題設定・制約設定・テスト設計・レビュー・誤修正の検知に移る。
「AIはジュニアを置き換えるが、シニアは安泰」という話はしぶとい。でも、ここも単純じゃない。LinkedInの空気も含め、肩書きだけでは盾になりにくい、という問題提起がある。
考えると当然で、明確に定義されたバグで、testsが優秀なら、シニアの作業は自動化されやすい。一方で、要件が曖昧で政治的で、legacyで、知識がSlackの死んだスレッドとコメントにしかない、みたいな仕事は、ジュニアが苦戦しても「自動化しにくい」側に残る。
ここで出てくる観察としてMETRのパターンがある。タスクが長くなるほど信頼性が落ちる、という方向性。だからseniorityが堀というより、unwritten judgmentが堀になる。
シニアの役割は消えない。ただ、重心が移る。問題をフレーミングして、制約を置いて、testsを設計して、出力をレビューして、「自信満々に間違えた修正」を検知する側へ。タイピング量は、守ってくれない。
神話7：スピードアップは体感できる — 体感は当てにならない
AI使用時に実測では19%遅くなるのに主観では20%速く感じることがあり、生産性は測定すべきである。
ここは刺さる。Experienced open-source developersが、AIを使って実タスクをやったら19% slowerだった。なのに本人たちは20% fasterだと思っていた。
だから、Productivity is not a vibe。測るしかない。出荷した成果、総時間、混入したバグ、レビュー時間、そして本番で生き残るか。カーソルが走っていることと、前に進んでいることは違う。
神話8：難しい言語はAIにも難しい — ランキングはtoolboxで反転する
ツール/ハーネスを変えるとRustとC++の相対的成績が反転しうるため、言語難易度の固定的説明は崩れる。
「Rustは厳密、C++はポインタとmutable stateと40年分の意思決定」みたいな直感は分かる。で、SWE-bench Multilingualの公式結果っぽいものを見ると、Claude agentsがRustタスクをCとC++の合計よりtwice多く解いた、という形で見える。さらに、2k規模のデータセットではC++がGo、C、JavaScript、TypeScriptに勝つ、という話も出てくる。
でも、そこから「言語が本質的に難しい／易しい」に固定するのが早い。なぜなら、agent harnessを変えるとRust–C++のギャップがひっくり返ることがあるから。SWE-agentではC++がRustに勝ち、OpenHandsではRustが勝つ。Same model. Different toolbox. Different result.
ここから言えるのは、「AIはRustが得意でC++が苦手」みたいな自然属性ではなく、特定のtoolsで小さく、明確で、containedで、testsしやすいタスクが得意、という整理に落ちる。
BACKSTAGE：結局、何がスコアを動かすのか（factorial analysisの結論）
性能を安定して左右する要因は主に「テスト可能性」と「タスクの大きさ」であり、言語やモデルブランドは一貫した決定要因ではない。
神話を潰しただけでは、説明は残らない。なので、ここで記述を一段落とす。factorial analysisとして候補にしたのは、programming language、model brand、memorisation、testability、task size。この中で、スコアを一貫して動かしたのは最後の二つだった、という整理になる。
言い換えると、AI codersが一番強いのは「タスクが小さい」かつ「testsが明確な信号を出す」状況。wrongならやり直し、rightなら止まる。このループが回ると、見かけの賢さが上がる。魔法じゃない。試行錯誤が高速で回るだけ。
ただし、ここで気を抜くと危ない。エージェントの本能は「問題を理解する」ではなく、「グリーンチェックを最短で取る」方向に寄りがちだ、という注意が入る。testsに抜け穴があると、ソフトウェアではなくスコアボードを解く。プロジェクト履歴から答えを掘り出して貼る、みたいな“効率的だがズルい”挙動も起きうる。
だからtestsはコンパスであり、同時に罠にもなる。ここ、雑に扱うと痛い。
結論：待つべきは“より賢いモデル”だけではなく、渡す仕事の形
AI codingの実用性はテスト可能性とタスクサイズの設計で大きく変わり、同じモデルでも結果は別物になる。
AI codersは万能ではない。小さくてtests可能な仕事では、山羊みたいに登る。どこでも登るわけじゃない。逆に、テストできず、広く散らかった仕事では、観光客になりやすい。
だから露出（うまくいく／壊す）の話は、モデルの進化を待つだけで決まらない。こちらが握っているのは、結局2つのレバー——testabilityとtask size。そこをちゃんと引くと、急に“使える機械”になる。無視すると、家具を食べ始める。そういう種類のリスクだ。
