Claude Code創業者がSequoiaカンファレンスで示した7つの重要な判断
TechFlow厳選深潮セレクト
Claude Code創業者がSequoiaカンファレンスで示した7つの重要な判断
今後10年間に業界を本当に変革するスタートアップ企業は、過去10年間と比べて10倍以上増える可能性がある。
Web3業界の深掘り報道に専念し潮流を洞察整理：アイン
Claude Code の創業者ボリス・チェルニー氏がシーケイア・キャピタル主催のカンファレンスで行った発表は、情報量が非常に豊かで、多くの見解を私は初めて体系的に耳にしました。この人物は、確かにAIに対する理解が深く、的確です。
以下に、私がまとめた要点を共有します。
01 コードはもはや希少資源ではない
多数の主流な開発シナリオにおいて、人手によるコーディングはすでに非効率な作業になりつつあります。
かつては、ある機能をリリースする際、エンジニアがまず実装方法をじっくり考え、その後一行一行とコードを記述していきました。このプロセスにおいて、エンジニアが持つ最大の価値は、「書けるか」「どれだけ上手に書けるか」「どれだけ速く書けるか」でした。
しかし、現在の働き方は異なります。
同じ機能を開発するにしても、エンジニアが行う作業は、まず要件を明確にし、それを複数のエージェントに分割して割り当て、検証基準を設定し、エージェントが出力した結果が正しいかどうかを確認することに近づいています。もし正しくなければ、プロンプトを調整して再度実行させます。
AIはすでに、ほとんどのコーディングタスクをこなすことが可能です。もちろん、100％とは言えません。巨大かつ複雑なコードベース、マイナーなプログラミング言語、あるいは特殊な実行環境などでは、現行のモデルのパフォーマンスは依然として不十分です。
全体として見ると、エンジニアの価値は「コードを書けるか」という点から、「タスクを適切に分割できるか」「目標を明確に説明できるか」「結果を正しく検証できるか」「エージェントを効果的に管理できるか」という点へと移行しています。
この変化は、まさに産業革命に似ています。
産業革命以前、鍛冶屋は鉄の加工・鍛造・研磨・組立まで、すべて一人で行いました。腕の良い鍛冶屋は当然、高価値でした。
その後、ライン生産方式が登場しました。各作業員は単一の工程のみを担当するようになり、その結果、手工業時代と比べて生産性が数十倍乃至数百倍に向上しました。
このとき、工場内で最も価値を持つようになったのは、特定の工程を最も巧みにこなす職人ではなく、ライン全体を設計・管理し、円滑に稼働させる能力を持つ人物でした。
作業員が消えたわけではありませんが、その役割は大きく変わりました。
ソフトウェア工学も今、同様の転換期を迎えています。コード自体はもはや希少なものではなく、コーディング能力は「PowerPointを使える」程度の基礎スキルへと位置付けられつつあります。
真に希少なのは、あいまいな要件を明確なタスクに分解できる力、エージェントが提示した複数の解決策の中から最適なものを選択できる判断力、そして複数のAIを連携させて一つの課題を達成できる統合力です。
これは、多くのベテランエンジニアにとって初めは受け入れがたい変化です。「自分の手でコードを書き上げる」という行為そのものが、過去数十年間にわたって多くの人々がこの業界を愛した理由だったからです。
それを機械に委ねることは、単なる作業スタイルの変化ではなく、自己アイデンティティの再構築を伴うものです。
しかし、トレンドはトレンドです。
02 グーテンベルクの活版印刷機に似た変革
コーディングは、専門的なスキルから、誰もが備えておくべき基礎的能力へと変貌しつつあります。これは、15世紀のヨーロッパにおける活版印刷の登場に例えることができます。
活版印刷が発明される前、ヨーロッパの識字率は約10％に過ぎませんでした。識字者は、文盲の貴族に雇われ、読み書きの代行という専門職を担っていました。
ところが活版印刷が登場すると、わずか50年間で、ヨーロッパで出版された書籍の総数はそれ以前1,000年に及ぶ累計を上回りました。さらに、書籍の価格は約100分の1にまで下落しました。その後、教育制度や経済構造などの周辺整備が数百年かけて進み、ようやく今日の世界平均識字率70％に至ったのです。
ボリス氏は、AIがソフトウェアにもたらす影響を、こうした活版印刷革命の加速版と位置付けています。ソフトウェアは、数十年のうちに完全に民主化され、誰もが自在に扱えるものになるでしょう。
最終的には、「ソフトウェアを作る」という行為は、「SMSを送信する」ことと同じくらい自然なものになるはずです。
03 本当に重要な能力とは？
AIによってコーディングのハードルが極端に低くなった後、個人の能力を真正に差別化するのは、プロダクト感覚（プロダクトセンス）および特定分野への深い理解です。
例えば、医師向けのプロダクトを開発するという状況を考えましょう。一方はコードを高速に書けるエンジニア、もう一方は病院の情報部門で数年勤務経験のある人物です。
従来であれば、エンジニアの方が製品を完成させる可能性が高かったでしょう。なぜなら、彼／彼女はアイデアを実装できるからです。
しかし、今は逆転しています。誰でもアイデアを実装できます。その中で、病院の日常業務フローを実際に知っている人がむしろ高価値になります。なぜなら、彼／彼女は「医師が実際に使う機能」と「単に理屈では良さそうに思える機能」を見分けられるからです。
つまり、AIによって実行のハードルが平準化された結果、判断力の差がより顕著に浮き彫りになったのです。
これは、「ジェネラリスト（多能工）」という概念の定義そのものを根本的に書き換えます。
これまで「ジェネラリスト」と言えば、iOS・Web・バックエンドのいずれも開発できるエンジニアを指していました。本質的には、エンジニアリング領域内でのフルスタック型人材です。
これからのジェネラリストは、学際的なフルスタック型人材です。
たとえば、プロダクト・デザイン・エンジニアリングの三つを兼ね備える人、あるいはプロダクト・データサイエンス・エンジニアリングを横断する人材などが該当します。こうした組み合わせは、かつてはほぼ不可能でした。なぜなら、それぞれの分野に長期間の専門訓練が必要だったからです。
しかし、AIは各分野の実行ハードルを大幅に下げました。そのため、個人が複数の領域を横断しながら、なおかつ一定の専門的深さを保つことが可能になっています。
Claude Codeチームはまさにそのようなチームです。エンジニアリングマネージャー、プロダクトマネージャー（PM）、デザイナー、データサイエンティスト、財務担当者、ユーザーリサーチャー——全員がコードを書いています。
デザイナーは、インタラクションのプロトタイプを自ら実行し、チームに直接デモできるようになりました。もはや、図面を作成してエンジニアの実装を待つだけではありません。
財務担当者は、独自に分析ツールを構築し、企業内の複雑な財務モデルを即座に実行できます。BIチームの対応を待つ必要はありません。
ユーザーリサーチ担当者は、自らデータを取得・分析し、かつてはデータチームとの連携を待っていた作業を自ら引き受けるようになりました。
彼らの専門的深さはそのまま維持されています。ただ、AIの支援により、「コードを書く」ことが、チーム全体で共通に使える言語へと変わったのです。
04 SaaSの護城河は崩れつつある
過去十数年にわたり、SaaS業界にはいくつかの「公理」とも言える共通認識がありました。
第一に「切り替えコスト」があります。ある企業が特定のSaaSシステムを導入すると、数年乃至十数年にわたり、データ・設定・フィールド・権限関係といった資産が徐々に蓄積されていきます。
別のシステムへ移行しようとすると、これらの要素を元のまま移行・再構築するだけで、既に相当な負荷がかかり、多くの企業はその煩雑さゆえに移行を躊躇します。
第二に「ワークフローのロックイン（固定化）」があります。従業員の日常業務、部門間連携、承認フローなど、すべてがそのSaaSを中心に形成されています。
システムを変更することは、単にデータを移動させるだけでなく、会社全体が数年かけて培ってきた「筋肉記憶」をゼロから作り直すことを意味します。
この二つの要因が、過去のSaaS業界における最も深い護城河を築いてきました。しかし、十分に強力なモデルが登場した今、その論理は変化し始めています。
まず、切り替えコストについて見てみましょう。従来、あるSaaSから別のSaaSへ移行するには、フィールドの整合やデータ構造の再現だけで、エンジニアリングチームが数カ月間残業を強いられていました。
しかし今では、両者のAPIとデータ構造をモデルに与えることで、モデル自身がマッピング関係を自動で解析し、最適解へと段階的に収束させることができます。本来数カ月かかる作業が、数日で実用可能なバージョンを出力することが可能になります。
次に、ワークフローのロックインについても、興味深い変化が起きています。従来、ワークフローが顧客を縛りつけられたのは、それが複雑で、暗黙的で、人間に依存していたからです。
従業員の頭の中に刷り込まれた「誰に依頼すべきか」「どこで承認が滞るのか」といった暗黙の了解は、そのまま他システムへ移植できません。
しかし、Opus 4.7のような高度なモデルは、複雑なワークフローを正確に読み取り、分解し、新しい環境で再構築することに最も長けています。しかも、再構築されたワークフローは、元のものよりもスムーズになる場合すらあります。
したがって、これまでデータの蓄積とワークフローの蓄積によって築かれてきた護城河は、今まさに崩れつつあります。
SaaS事業を展開している企業にとっては、これは悪いニュースかもしれません。しかし、SaaSを利用するすべての顧客、そして次世代SaaSを立ち上げようとするチームにとっては、まさにチャンスの窓が開いた瞬間なのです。
05 起業家にとって最高の時代
今後10年間に、業界を真正に変革するスタートアップ企業は、過去10年間と比較して10倍以上増加するでしょう。
その理由は、実は単純です。
小規模チームがAIを活用して、大企業と同等、あるいはそれ以上の品質のプロダクトを開発できるようになります。一方で、大企業がAIを本格的に活用しようとするのは、むしろ「負債」になります。
どういうことでしょうか？
歴史が10年以上ある企業は、すでに独自の業務フロー、職務分掌、協働習慣、研修体制、KPI評価基準といった一連の仕組みを確立しています。これらは、過去には資産であり、競争上の壁でもありました。
しかし、AIを本格的に組み込むには、これらすべてを再検討しなければなりません。業務フローの再構築、全従業員への再教育、一歩進むごとに押し寄せる内部の抵抗、N個の部署・N層の承認プロセスとの調整——これらは、すべて大きな障壁です。
一方、3人のメンバーで始まるスタートアップチームは、初日からAIをデフォルトの基盤として設計します。彼らには歴史的負担がなく、習慣を変える必要もなく、誰も説得する必要がありません。今日議論を終えれば、明日にはデモが走り、明後日にはユーザーに提供できます。
このスピード差は、AI登場以前にも存在しました。スタートアップは、もともと大企業に対してスピード優位性を持っていました。しかし、AIはこの差を何倍にも拡大しました。
なぜでしょうか？
AIが強くなればなるほど、一人の人が単位時間あたりに発揮できるレバレッジ（影響力）は大きくなります。AIを真正に使いこなす小規模チームは、今日の生産性がかつての10人分、明日には30人分に相当する可能性があります。
しかし、大企業の組織的重さは軽減されておらず、むしろAIの導入という課題を抱えることで、さらに重くなっています。AIが強くなればなるほど、小規模チームの加速度と、大企業の抵抗（ドラッグ）との差は、ますます広がっていくのです。
これがボリス氏が言う「負債」という意味です。大企業が資金・人材・意思がないわけではありません。むしろ、かつて儲けを生み出した「筋肉」が、今まさにAIの価値を最大限に発揮する道を妨げているのです。
06 MCPは死なない
MCPは死にません。
「Skill」が注目を集めた後、多くの人はMCPは不要になると予想しました。OpenClawの創業者も同様の見解を示しています。
しかし、ボリス氏はこう考えていません。彼は、MCPがAI時代におけるソフトウェアの接続層（コネクションレイヤー）になると予測しています。
かつてインターネット時代のソフトウェア接続手段はAPIでした。
しかしAPIの根本的な問題は、それがエンジニアのために設計されている点にあります。APIを使うには、まずドキュメントを読み、トークンを申請し、コードを書き、フィールドを整合させ、例外処理を実装する必要があります。要するに、APIは人間の開発者向けに作られています。
MCPは異なります。MCPはモデルが直接接続して利用できるように設計されており、モデル自身が理解して呼び出すことが可能で、途中にプログラマーが翻訳する必要はありません。
そのためボリス氏は、APIを「Human Developer Interface（人間向け開発者インタフェース）」、MCPを「Model Interface Protocol（モデル向けインタフェースプロトコル）」と呼び分けています。前者は人間が使い、後者はモデルが使います。
これはかつての状況とよく似ています。モバイルインターネット時代には、すべてのサービスがAPI化されることがデフォルトとなりました。AI時代には、すべてのサービスがMCP化されることがデフォルトとなるでしょう。
07 Computer Useは依然として重要
最近、Computer Useについて話すと、この方向性は実用化できないのではないかと感じられる方が多いようです。
その理由も妥当です：トークン消費が激しく、実行が遅く、安定性にも欠ける。今のところは、技術力を誇示するためのデモに過ぎず、実用レベルにはまだ程遠いように見えます。
しかし、ボリス氏の視点はまったく異なります。
彼が真に重視しているのは、Computer UseがAIの実用化における最大の課題を解決する点です。すなわち、現実世界には、APIもMCPもないシステムが大量に存在するという事実です。
特に企業の現場において顕著です。
実際に企業に入ると分かりますが、多くのコアシステムは非常に古く、ERP・OA・財務システム・内部承認システム・サプライチェーンのバックエンド・各種カスタムシステムなど、多くは外部インターフェースを開放しておらず、ドキュメントもなく、自動化機能も備えていません。それらは、毎日無数の従業員によって手動で操作され続けています。
では、なぜそれらに直接APIを提供しないのでしょうか？
それは、そもそも実現が困難だからです。これらのシステムを開発したベンダーは既に存在しないことも少なくありません。IT部門には再構築する意欲も予算もありません。
また、業務部門が半年から一年間も待っていられるはずもありません。これらのシステムは、完璧なAPIが登場するのを永遠に待ち続けることは決してありません。
短期的には、各主要モデルは引き続きComputer Use能力の向上に注力していくでしょう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
