「コーディングは解決された」という宣言

2026年5月、Anthropic Claude Code 責任者 Boris Cherny は Sequoia AI Ascent 2026 で「Why Coding Is Solved, and What Comes Next」と題して講演した。発言の核心はこうだ。「2026年に入ってから、自分はコードを1行も書いていない。スマートフォンから1日に数十のPRを出している。個人記録は1日150PR」。

▲ Sequoia Capital 公式：Boris Cherny × Lauren Reeder「Why Coding Is Solved, and What Comes Next」（YouTube・AI Ascent 2026）

エコシステム全体では「コーディング解決率は約50%」、しかし自分の業務領域では「100%解決済み」とBorisは述べた。彼にとって Claude Code のリポジトリ（TypeScript + React 構成）は、モデルが最も多く訓練データを保持するスタックであり、2025年末時点でモデルは必要なコードを100%書ける状態に到達したという。

この発言は単なる挑発ではない。同じテーマで2026年前半に複数のインタビューが続いており、Lenny's Podcast（2/19）、Lightcone Podcast（2/17）、Pragmatic Engineer 連載、Developing.dev 等で同じ主張が繰り返されている。Claude Code 自体の利用統計が彼の発言を裏付けている：GitHub のパブリックコミット全体の4%が Claude Code 経由、前月比でデイリーアクティブユーザーが倍増——Claude Code は新興プロダクトでありながら、ソフトウェア産業の構造に直接影響を与える規模に達している。

本記事では、Boris の主張を複数ソースから抽出し、AX Boost フレーム 「コーディング解決後、組織に残る5つの論点」 で、日本企業の経営層・AI推進担当者にとっての含意を整理する。なお、Code w/ Claude 2026 SF の全体像については Code w/ Claude 2026 サンフランシスコ徹底解説 を参照されたい。

Boris Cherny は誰か — Meta IC8 から Claude Code 創設へ

Boris Cherny は元 Meta Principal Engineer で、2017年に IC4 で入社して IC8 まで昇進し、約7年在籍した（Instagram 東京オフィスでの勤務経験もある）。技術者としては書籍『Programming TypeScript』の著者であり、状態管理ライブラリ Undux の作者でもある。ChatGPT の初体験で衝撃を受けて Anthropic に入社し、いったん Cursor へ転職したものの「わずか2週間で」Anthropic に復帰した。現在は Head of Claude Code として、自ら立ち上げた Claude Code を率いている。型システムと大規模マイグレーションを地で経験してきた人物が「コーディングは解決された」と言っている点は、この発言の重みを測るうえで押さえておきたい。

彼自身、ターニングポイントについてこう語っている。「6か月前に今のようにコーディングするか聞かれたら『ノー』と答えただろう。しかし実際に機能している」（Developing.dev）。転機になったのは Sonnet と Opus 4 のリリースで、それ以前は自分のコードの10%しか Claude Code を使わなかったのが、現在は 80〜90% に達したという。つまり彼の「解決」宣言は理念先行ではなく、半年で自身の作業比率が一桁台から大半へ反転した実体験に裏打ちされている。

Boris の3つの設計思想

複数のインタビューを横断すると、Boris の設計思想は3点に収斂する。それぞれが「未来のモデルを前提に作る／役割を固定しない／半端を残さない」という別々の局面を扱っており、組み合わさって彼の開発スタイルを形作っている。

第一は、今日のモデルではなく半年後のモデル向けに構築するという時間軸の取り方だ。これはマネージャー Ben からの助言として彼が引用するもので、Claude Code の初期実装は実用に耐えなかったが、モデルの進化を信じて作り続けた結果いまの品質に到達したという。逆に言えば、現時点で「AI にはまだ無理」と判断して着手を見送った領域が、半年で射程内に入る可能性を織り込んでおけ、という設計姿勢である。

第二は、役割を固定しないジェネラリスト優先の体制だ。Anthropic では全員が "Member of Technical Staff" という統一タイトルを使う。Boris は「役割固有のタイトルがなければ、デフォルト仮定として全員がプロダクト・デザイン・インフラ・研究を手掛けることになる」と説明する。実際 Claude Code チームでは PM もデザイナーもデータサイエンティストも、財務担当やユーザーリサーチャーまでがコードを書く。専門分業の壁を低くしておくことが、コーディングのコモディティ化と相性が良いという発想だ。

第三は、始めたマイグレーションは必ず完了させるという規律だ。「複数フレームワークの部分的な移行は、人間とモデルの両方を混乱させる」——Meta 時代に Python から Monolith へ、REST から GraphQL へと移行を主導した経験からの教訓である。半端な状態の技術負債は、AI 時代でも（あるいは AI 時代だからこそ）コストを掛けて完了させるべき、というのが彼の立場で、これは後述する基盤負債の論点に直結する。

これらの思想は、開発体制の設計にも表れている。Boris 個人は 「5つの並列 Claude インスタンスで1日 20-30 PR」 が通常運用で、計画モードで仕様を固めてから一気に実装に進むと述べている。「良い計画があれば、実装はほぼ常に一度でうまくいく」（Pragmatic Engineer）。Claude Code 周辺の新プロダクト Claude Cowork は、わずか10日間で構築 され、初期 Claude Code より速く成長したという。

実際の Claude Code 開発の現場感は、Y Combinator が運営する Lightcone Podcast での Boris 自身による解説が分かりやすい。

▲ Y Combinator 公式 Lightcone Podcast：「Inside Claude Code With Its Creator Boris Cherny」（YouTube・2026年2月17日）

AX Boost フレーム — コーディング解決後、組織に残る論点

「コーディングが解決された」を文字通り受け止めると、エンジニア組織は不要になる、と読みたくなる。しかし複数のインタビューを丁寧に読むと、Boris 自身が 「コーディングが解決された後、残る論点はむしろ重みを増す」 と語っていることが分かる。コードを書く工程が安価になると、ボトルネックはその前後——「何を作るかを決める前工程」と「出てきたものを判定し・運用する後工程」——へ移動する。以下では、その移動先で組織に残る論点を、要件定義・ドメイン知識・品質判定・基盤負債・ガバナンスの順に追っていく。重要なのは、これらがいずれも個々のエンジニアのスキルではなく、組織の設計責任に属するという点である。

「何を作るか」を決める前工程が希少資源になる

Boris は繰り返し、「これからの開発者は『how to code』ではなく『what to code』を考える」と語る。コードを書く労力が下がるほど希少価値が上がるのは、何を作るべきかを業務と組織の文脈で定義する力のほうだ、という主張である。手を動かす作業がコモディティ化すれば、競争はその上流——どの課題を、どの粒度で、どの順に解くかを見極める判断——で起きる。

これは AX Boost が一貫して主張してきた「要件定義こそが PoC脱出の第一関門」という議論とそのまま重なる。AI PoC止まり脱出フレームワーク で論じたように、動くデモを作る労力は劇的に下がった一方、それを業務価値へ接続する設計責任は依然として組織側に残る。むしろ実装が速くなったぶん、筋の悪い要件のまま走り出して大量の成果物を捨てる損失が目立つようになった。前工程の精度が、後工程の生産性を規定する構図はこの記事の通底音である。

ドメイン知識を持つ人がコードを書く側に回る

「The best person to write accounting software is a really good accountant（最高の経理ソフトを書ける人は、優れた経理担当者である）」——Boris のこの一言は、競争優位の所在がコーディング能力からドメイン知識の深さへ移ることを端的に示している。誰でもコードを書ける環境が整うほど、差を生むのは「業務の勘所をどれだけ把握しているか」になるという見立てだ。

これは日本企業にとって追い風になり得る。製造現場の段取り、金融オペレーションの例外処理、医療業務の安全要件、法務文書の解釈——こうした暗黙知を抱えた既存従業員が、コードを書ける側に回れるからだ。ただし条件があって、ドメイン知識は本人の頭の中にあるだけでは武器にならない。AI に渡せる形へ翻訳する手間を組織が支援して初めて、現場の知見が生産物に変わる。業務別の踏み込みは 管理部門のAI活用ガイド や 顧客接点業務のAI活用ガイド で整理した。

「品質が低い」を誰がどう判定するか

Boris は「モデルのコードと人間のコードに同じ水準を適用する。品質が低ければマージしない」と明言する。基準を緩めない姿勢自体は健全だが、組織に跳ね返ってくる問いはその先にある——「品質が低い」を誰が、どんな根拠で判定するのか、という運用の問題だ。

Code w/ Claude 2026 で発表された Claude Managed Agents の Outcomes 機能は、評価ルーブリックに基づく自動判定を可能にする。だがルーブリックそのものは組織が定義しなければならず、ここを外注に丸投げすると判定基準が業務実態から乖離する。AI に任せる範囲が広がるほど、業務固有の合格条件を明文化できているかどうかが、そのままスループットの上限になる。設計の手応えとして AI評価フレームの実装論近日公開 で論じた「LLM-as-Judge × ベンチマーク × 人手評価」の3層構造が、この問いへの組織的な答えの一つになる。

「AIで技術負債が消える」という幻想

Boris が Meta 時代の因果分析から学んだのは「コード品質は工学生産性に二桁パーセントの測定可能な影響を持つ」ことだという（Pragmatic Engineer, 2026年）。AI が前提になっても、複数フレームワークの混在や部分的なマイグレーション、整理されていないコードベースは、人間とモデルの双方を等しく混乱させる。むしろ高速に大量のコードを生成できる時代には、土台が乱れている影響が増幅されやすい。

長年蓄積したレガシー基盤と AI 活用を同時に進めなければならない日本企業ほど、この論点は重い。「AI を使えば技術負債が勝手に消える」という期待は持たないほうがよく、Boris の言葉を借りれば、マイグレーションは始めた以上は完了まで責任を持つべきものだ。この判断と実行を AI ベンダーや FDE が担うのか、それとも社内に閉じるのかは、契約段階で詰めておきたい論点になる。内製と外注の線引きは AI内製化 vs 外注 と AI Center of Excellence (CoE) の組成と運用 で扱った。

並列エージェント運用が監査の構造を壊す

エージェントの並列運用が広がると、「何が、いつ、どんな根拠で実行されたか」を人手レビューだけで追い切れなくなる。Boris 個人ですら「5並列インスタンスで20-30PR/日」が常態なのだから、これを組織スケールへ持ち込めば、レビューと監査の前提そのものを設計し直す必要が出てくる。一人の承認者が全 PR に目を通すモデルは、生成速度に対してすぐ破綻する。

ここで効いてくるのが、企業のAIガバナンス実務ガイド で論じた監査設計のマルチエージェント時代への拡張だ。プラットフォーム側が提供するログや評価ループ（Outcomes 等）と、組織側の業務ガバナンスをどう噛み合わせるか——この整合作業は、ツールの技術選定とは別物として、同じテーブルで並行して進めるべきテーマになる。

反論・限界 — 「Solved」は限定的解決である

Boris の主張を額面通り受け取る前に、いくつかの留保を置いておきたい。

まず、彼の「解決」はあくまで彼の環境での解決であって、万人にとっての解決ではない。Boris が働く Claude Code は TypeScript + React で書かれた Anthropic 内部リポジトリであり、最初から AI ネイティブに設計された理想条件にある。これに対し、日本企業に多い20年もののモノリス Java アプリ、業務独自に肥大した Excel マクロ群、ベンダーが撤退した COBOL システムでは、AI による自動コーディング率はまだ大幅に低い。解決率は業界・スタック・コードベースの状態によって連続的に変わる量であって、オンオフの二値ではないと捉えるのが実務的だ。

次に、Boris がよく引く印刷機の類推にも限界がある。彼は「発明前の欧州識字率は10%だったが、発明後50年で過去千年分以上の文献が出版された」と語る。だがソフトウェアに求められる「正しさ」は、文章の「読みやすさ」よりずっと厳密だ。生成された大量のコードを誰がレビューし、保守し、最終的に責任を負うのか——この問いに印刷機の比喩は答えてくれない。量の爆発が必ずしも価値の爆発を意味しないのは、本記事が品質判定の論点を別立てした理由でもある。

学習者・新人エンジニアにとっては、むしろハードルが別の形で上がる側面もある。教育系メディア（Frontend Mentor 等）は、「AI にも落ち着いて間違う傾向があり、コードを読み、質を判断し、パターンを認識し、モデルの誤りを捉える基礎力は依然として必要だ」と指摘する。天気アプリや ToDo リストのような入門ポートフォリオはもはや評価されず、新人にもフルスタックの実装と実ユーザー対応が求められる。土台のスキルが不要になったのではなく、求められる初期到達点が引き上げられた、と読むべきだろう。

最後に、見落とされやすいのが権力構造の集中リスクだ。独立分析（Medium 上の JIN「From IDE to Agent Console」）は、「コーディング解決」の本質を開発者ツールの権力中心の移動——IDE からエージェントコンソールへの重心移動——と捉える。テキストエディタのカーソル位置から、エージェント群を統制するコンソールへ主戦場が移れば、ツールベンダー（Anthropic、OpenAI、Cursor 等）への依存が一段深まりかねない。企業の AI 戦略上は、マルチベンダー構成と自社の制御権の確保が、これまで以上に効いてくる論点になる。

日本企業の AI推進担当者にとっての含意

なお、より一般向けの解説としては、CNBC の Kate Rooney が Code w/ Claude 2026 SF 会場で Boris に直接インタビューした映像が分かりやすい。「6か月前にコードを手で書くのを止めた」「Claude が機能とテストを書き、自分はレビューと修正指示を出す」という、経営層にも伝わる言葉で語っている。

▲ CNBC 公式：Kate Rooney × Boris Cherny「Head of Claude Code on the future of work and productivity」（YouTube・2026年5月6日収録、Code w/ Claude SF 会場）

以上を踏まえ、日本企業の AI推進担当者にとっての実務的な含意を、組織・人材・経営判断・ベンダー選定の四つの面から整理しておく。

組織の面では、エンジニア組織の再設計を前倒しで議論する局面に来ている。Boris の「全員 Technical Staff」「ジェネラリスト優先」は、日本企業に多い階層型・専門分業型のエンジニア組織とは相容れない側面がある。とはいえ、すべての企業が Anthropic 型をそのまま採るべきとは限らない。重要なのは型の模倣ではなく、自社のフェーズ・規模・人材プールに合わせた組織設計を、AI の普及を前提に問い直すことだ。論点の立て方は AI時代の人材戦略近日公開 で扱った。

人材の面では、育成投資の向き先が変わる。コードを書ける人が増えるほど、希少になるのは業務を AI に依頼できる形へ翻訳する力——本記事で前工程として論じたものだ。これは技術スキルというより、業務理解・要件定義・評価設計を束ねた能力であり、現場の暗黙知を持つ人ほど伸びしろが大きい。誰に何を伸ばさせるかを設計し直す価値がある。

経営判断の面では、問いの立て方そのものを変える必要がある。「AI で何ができるか」を起点にするとベンダーのデモに振り回されるが、出発点を「自社の業務のうち、どれを AI に任せ、どれを人間が担うか」に置けば、判断の主導権が社内に残る。これは Boris の「what to code」を企業レベルへ読み替えたもので、本質的には何を引き算して空いた工数を価値ある仕事へ再配置するかという経営判断——AIは足し算より引き算→再配置 の論点——でもある。外部ベンダーに丸投げできる類の判断ではない。AX Boost が FDE型コンサルティングで現場に常駐するのは、まさにこの判断を組織と共同で行うためだ。

ベンダー選定の面では、軸が「動くものを作る」から「動かし続ける」へ移る。重心が運用フェーズに寄るほど、選定の判断材料はデモの見栄えよりも、評価ループ・監査機能・運用支援の厚みになる。判断の物差しとしては AIエージェント業務導入の設計論 と AIエージェントとは — 定義・5段階成熟度・主要フレームワーク で示した成熟度モデルが使える。

まとめ — 「コーディング解決」は「組織課題の解決」ではない

Boris Cherny の「コーディングは解決された」という宣言は、プログラミング言語の壁が下がる時代の象徴として受け止めるべきだ。しかし、それは組織の競争優位の終わりを意味しない——むしろ別の論点（要件定義・ドメイン知識・品質判定・基盤負債・ガバナンス）が、より明確に浮上する。

ここで挙げた論点は、いずれも「業務側の理解と技術側の実装を並走させる」体制でしか解けない。要件定義は業務を知る側にしか書けず、品質基準は現場でしか定義できず、基盤負債とガバナンスは技術側と経営側の合意なしには片付かないからだ。AX Boost が FDE型コンサルティング（FDE型コンサルティング完全解説）として現場に入り込むのは、まさにこの並走を担うためである。

「コーディング解決後」の時代に、自社のエンジニア組織・業務側の要件定義力・ベンダー選定軸をどう再設計するかでお悩みの方は、AX支援サービスの選び方 もあわせて参照されたい。

主要参考資料