整理：阿颖Claude Code 創始人 Boris Cherny がセコイアカンファレンスでの共有、情報量が非常に多く、多くの見解を初めて完全に聞いた。彼は確かにAIの理解がかなり的確だ。私も自分のまとめを共有する。01 コードはもはや希少ではない多くの主流開発シナリオにおいて、人手でコードを書くことは、すでに効率の低い作業になりつつある。以前は、機能を納品するために、エンジニアは座って、まずどう実現するかを考え、一行一行コードを書き出していた。この過程で、エンジニアの最大の価値は：書けるかどうか、良く書けるか、速く書けるかだった。今の働き方は違う。同じ機能でも、エンジニアの作業はむしろ：まず要求を明確に伝え、それをいくつかの部分に分解してエージェントに任せ、受け入れ基準を設定し、その結果が正しいかどうかを確認し、間違っていればプロンプトを調整して再実行する、という流れに近い。AIはすでに大部分のコーディング作業をこなせる。もちろん、100%ではなく、巨大で複雑なコードベースやマイナーな言語、特殊な環境では、今日のモデルのパフォーマンスはまだ十分ではない。全体として、エンジニアの価値は、コードを書けるかどうかから、タスクを分解できるか、目標を明確に伝えられるか、結果を検証できるか、エージェントを管理できるかに変わってきている。この変化は、実は産業革命に非常に似ている。産業革命前、鍛冶屋は鉄を打ち、鍛え、研磨し、組み立てる全工程を一人で行っていた。腕の良い鍛冶屋は自然と価値があった。その後、ライン生産が登場した。各作業者は一つの工程だけを担当し、全体の生産性は手工業時代の数十倍、百倍に向上した。この時、工場で価値があるのは、特定の工程を最も上手に行える職人ではなく、ラインを設計し、管理し、スムーズに動かせる人だった。作業員は消えたわけではないが、その役割は変わった。ソフトウェアエンジニアリングも今、似たような転換を経験している。コード自体はもはや希少品ではない。コードを書くことは、PPTを使えることと同じくらいの基本スキルになりつつある。本当に希少なのは、曖昧な要求を明確なタスクに分解できるか、エージェントの提案の中から最適なものを選び出せるか、一群のAIを協働させて一つのことを完遂できるか、だ。これは、多くの古いエンジニアにとって最初は受け入れ難いことだ。自分でコードを書き出すこと自体が、過去数十年、多くの人がこの仕事を愛した理由だった。これを機械に任せることは、多くの人にとって、単に働き方が変わるだけでなく、アイデンティティの再構築でもある。しかし、トレンドはトレンドだ。02 古登堡の印刷機のようにコーディングは、専門的なスキルから基礎的な能力へと変わりつつある。このことは、15世紀のヨーロッパの印刷術に例えられる。印刷術が発明される前、ヨーロッパの人々の識字率は約10%だった。これらの人々は、多くの場合、非識字の貴族に雇われて、読む・書くのを手伝っていた。その後、印刷術が登場し、50年でヨーロッパの出版物は過去千年の総数を超え、書籍の価格は約100分の1に下がった。さらに数百年の教育制度や経済構造の整備を経て、世界の識字率は今日の70%に達した。Borisは、AIがソフトウェアに与える影響は、加速版の印刷革命だと考えている。ソフトウェアは数十年以内に完全に民主化され、誰もが操れるものになる。最終的には、ソフトウェアを作ることは、SMSを送るのと同じくらい自然なことになる。03 何が最も重要な能力か？コードを書くハードルがAIによって極端に下がったとき、本当に人の能力を区別するのは、そのプロダクト感覚や、特定分野への深い理解だ。例を挙げると、医師向けのプロダクトを作る二人のエンジニアがいるとする。一人はコードが速く書けるエンジニア、もう一人は病院情報科で数年働いた経験がある人。以前なら、前者の方が成功確率が高かった。アイデアを実現できるからだ。しかし今や、誰でもアイデアを実現できる。そうなると、医療の現場を理解している人の方が価値が高い。なぜなら、彼は医師が本当に使う機能と、ただ聞こえが良いだけの機能を区別できるからだ。つまり、AIによって実行のハードルが均一化された結果、判断力の差が拡大している。このことは、「ジェネラリスト」という言葉の意味も書き換える。過去、ジェネラリストは、iOSもWebもバックエンドも書けるエンジニアを指していた。これはエンジニアリングの内側のフルスタックだった。未来のジェネラリストは、学際的なフルスタックだ。製品、デザイン、エンジニアリングを理解している人もいれば、製品、データサイエンス、エンジニアリングを理解している人もいる。これらの組み合わせは、かつては長い訓練が必要だった。しかし今、AIが各分野の実行ハードルを下げたことで、一人で複数の領域を横断し、専門性を保ったまま働ける。Claude Codeチームもそうだ。エンジニアマネージャー、PM、デザイナー、データサイエンティスト、財務、ユーザーリサーチ、皆がコードを書いている。デザイナーは自分でインタラクションのプロトタイプを作り、チームに見せることもできる。もはや、図を出してエンジニアに実装させるだけではない。財務は自分で分析ツールを作り、会社の複雑な財務モデルを動かす。BIに並んで待つ必要もない。ユーザーリサーチの同僚も自分でデータを処理し、過去にデータチームに依頼していた作業を引き受けている。各人の専門性は依然として高いままだが、AIの支援により、コードを書くことは皆の共通言語になりつつある。04 SaaSの堀が崩れつつある過去十数年、SaaS業界にはいくつかの公理的な共通認識があった。第一は切り替えコスト。ある企業があなたのシステムを使い始めると、そこに数年、あるいは十数年分のデータ、設定、フィールド、権限関係が蓄積される。別のシステムに移行しようとすると、これらをそのまま移し替えるだけでも頭が痛くなる。第二はワークフローのロックイン。社員の日常操作、部門間の協力、承認の流れはすべてこのSaaSに依存している。別のシステムに変えるのは、データを移すだけでなく、過去数年の企業の「肌感覚」をすべてリセットすることに等しい。これら二つが、過去のSaaSの最大の堀だった。しかし、十分に強力なモデルが登場すると、状況は変わり始める。まず切り替えコストの側面から見ると、従来は、あるSaaSから別のSaaSに乗り換えるには、フィールドの整合やデータ構造の再構築に数ヶ月かかっていた。今では、両者のインターフェースやデータ構造をモデルに渡し、自己学習させることで、最適なマッピングを見つけ出し、数日で使えるバージョンを作り出せる。次に、ワークフローのロックインの方が面白い。従来、ワークフローが顧客をロックしていたのは、その複雑さと暗黙性、そして人に依存していたからだ。社員の暗黙の了解、誰が誰に承認を求めるか、どの段階で詰まるか、これらをそのまま持ち出すことはできない。しかし、Opus 4.7のようなモデルは、複雑なフローを理解し、分解し、新しい環境で再構築するのが得意だ。むしろ、再構築されたバージョンは元よりもスムーズに動くこともある。したがって、従来、データやフローの蓄積によって築かれた堀は崩れつつある。SaaSを運営する側にとっては悪いニュースかもしれないが、SaaSを利用する顧客や、新たな次世代SaaSを作ろうとするチームにとっては、これは大きなチャンスだ。05 起業家にとって最良の時代今後10年で、業界を根底から覆すスタートアップは、過去10年の10倍以上になる可能性がある。その理由は単純だ。小さなチームでも、AIを使えば大企業と同等、あるいはそれ以上の製品を作れる。逆に、大企業がAIを本格的に導入しようとすると、むしろ負の資産になる。どういうことか？十数年の歴史を持つ企業は、すでに独自の業務フロー、役割分担、協力習慣、研修体系、KPI評価などを築いている。これらは過去の資産であり、壁となっていた。しかし、AIを本格的に取り込むには、これらすべてを見直す必要がある。業務フローの再構築、社員の再教育、各所の抵抗、複数部署や承認層の調整など、多大なコストと時間がかかる。一方、三人のスタートアップは、最初からAIを前提にしている。過去の負債もなく、習慣も変えずに済む。今日話し合えば明日デモを作り、翌日にはユーザーに提供できる。この速度差は、AI以前からあった。スタートアップは大企業に比べてスピードの優位性を持っていたが、AIによってその差は何倍にも拡大している。なぜか？AIが強力になるほど、一人の働き手が動かせるレバレッジは大きくなる。AIをうまく使う小さなチームは、今日の生産性は過去の十人分、明日には過去の三十人分に匹敵する。しかし、大企業の組織の重さは変わらず、むしろAIの導入により、より重くなる。AIが強くなるほど、小さなチームの加速と、大企業の引きずる力の差はますます広がる。これが Boris の言う「負の資産」だ。資金や人手、意欲がないわけではない。むしろ、過去に稼いできた筋肉が、今やAIの価値を最大化する妨げになっている。06 MCPは死なないMCPは死なない。Skillが流行った後、多くの人はMCPも不要になると考えた。OpenClawの創始者も同様の見解だ。しかし、Borisはそうは考えていない。彼は、MCPはAI時代のソフトウェア接続層になると見ている。従来のインターネットのソフトウェア接続はAPIだった。しかし、APIの核心的問題は、それがエンジニア向けに設計されていることだ。APIを使うには、まずドキュメントを読み、トークンを申請し、コードを書き、フィールドを整合させ、例外処理を行う必要がある。要するに、APIは人間の開発者向けだ。これに対し、MCPは違う。モデルが直接接続でき、自己理解して呼び出せる仕組みであり、プログラマの翻訳作業を必要としない。だから Borisは、APIを「Human Developer Interface（人間開発者インターフェース）」と呼び、MCPを「Model Interface Protocol（モデルインターフェースプロトコル）」と呼んでいる。一つは人間用、もう一つはモデル用だ。これは、かつてのモバイルインターネット時代に似ている。すべてのサービスはAPI化されるのが当然だった。AI時代は、すべてのサービスがMCP化されるのが当然になる。07 コンピュータ利用は依然重要多くの人は今、Computer Useについて話すと、これはうまくいかないのではと感じる。理由ももっともで、トークン消費が多く、遅く、不安定に見える。あまり実用的なデモには見えず、遠い未来の話のように思える。しかし Borisが見ている視点は全く違う。彼が重視しているのは、Computer UseがAIの実用化における最大の課題の一つを解決している点だ。現実世界には、APIもMCPも持たないシステムが大量に存在する。特に企業の世界だ。実際に企業に入ると、多くのコアシステムは非常に古い。ERP、OA、財務システム、内部承認、サプライチェーンのバックエンド、さまざまなカスタムシステム。多くはインターフェースもドキュメントもなく、自動化もされていない。そこに毎日、多くの社員が手動で操作している。では、なぜこれらに直接APIを作らないのか？作れないからだ。これらのシステムを作ったベンダーはすでにいないかもしれない。IT部門も再構築の予算も動機もない。ビジネス部門も、半年や一年待つわけにはいかない。これらのシステムは、完璧なAPIができるまで待ってくれない。短期的には、各種大規模モデルは、自身のComputer Use能力を高める方向に進むだろう。
Claude Code 創始人在紅杉大會上的 7 個重要判斷
整理：阿颖
Claude Code 創始人 Boris Cherny がセコイアカンファレンスでの共有、情報量が非常に多く、多くの見解を初めて完全に聞いた。彼は確かにAIの理解がかなり的確だ。
私も自分のまとめを共有する。
01 コードはもはや希少ではない
多くの主流開発シナリオにおいて、人手でコードを書くことは、すでに効率の低い作業になりつつある。
以前は、機能を納品するために、エンジニアは座って、まずどう実現するかを考え、一行一行コードを書き出していた。この過程で、エンジニアの最大の価値は：書けるかどうか、良く書けるか、速く書けるかだった。
今の働き方は違う。
同じ機能でも、エンジニアの作業はむしろ：まず要求を明確に伝え、それをいくつかの部分に分解してエージェントに任せ、受け入れ基準を設定し、その結果が正しいかどうかを確認し、間違っていればプロンプトを調整して再実行する、という流れに近い。
AIはすでに大部分のコーディング作業をこなせる。もちろん、100%ではなく、巨大で複雑なコードベースやマイナーな言語、特殊な環境では、今日のモデルのパフォーマンスはまだ十分ではない。
全体として、エンジニアの価値は、コードを書けるかどうかから、タスクを分解できるか、目標を明確に伝えられるか、結果を検証できるか、エージェントを管理できるかに変わってきている。
この変化は、実は産業革命に非常に似ている。
産業革命前、鍛冶屋は鉄を打ち、鍛え、研磨し、組み立てる全工程を一人で行っていた。腕の良い鍛冶屋は自然と価値があった。
その後、ライン生産が登場した。各作業者は一つの工程だけを担当し、全体の生産性は手工業時代の数十倍、百倍に向上した。
この時、工場で価値があるのは、特定の工程を最も上手に行える職人ではなく、ラインを設計し、管理し、スムーズに動かせる人だった。
作業員は消えたわけではないが、その役割は変わった。
ソフトウェアエンジニアリングも今、似たような転換を経験している。コード自体はもはや希少品ではない。コードを書くことは、PPTを使えることと同じくらいの基本スキルになりつつある。
本当に希少なのは、曖昧な要求を明確なタスクに分解できるか、エージェントの提案の中から最適なものを選び出せるか、一群のAIを協働させて一つのことを完遂できるか、だ。
これは、多くの古いエンジニアにとって最初は受け入れ難いことだ。自分でコードを書き出すこと自体が、過去数十年、多くの人がこの仕事を愛した理由だった。
これを機械に任せることは、多くの人にとって、単に働き方が変わるだけでなく、アイデンティティの再構築でもある。
しかし、トレンドはトレンドだ。
02 古登堡の印刷機のように
コーディングは、専門的なスキルから基礎的な能力へと変わりつつある。このことは、15世紀のヨーロッパの印刷術に例えられる。
印刷術が発明される前、ヨーロッパの人々の識字率は約10%だった。これらの人々は、多くの場合、非識字の貴族に雇われて、読む・書くのを手伝っていた。
その後、印刷術が登場し、50年でヨーロッパの出版物は過去千年の総数を超え、書籍の価格は約100分の1に下がった。さらに数百年の教育制度や経済構造の整備を経て、世界の識字率は今日の70%に達した。
Borisは、AIがソフトウェアに与える影響は、加速版の印刷革命だと考えている。ソフトウェアは数十年以内に完全に民主化され、誰もが操れるものになる。
最終的には、ソフトウェアを作ることは、SMSを送るのと同じくらい自然なことになる。
03 何が最も重要な能力か？
コードを書くハードルがAIによって極端に下がったとき、本当に人の能力を区別するのは、そのプロダクト感覚や、特定分野への深い理解だ。
例を挙げると、医師向けのプロダクトを作る二人のエンジニアがいるとする。一人はコードが速く書けるエンジニア、もう一人は病院情報科で数年働いた経験がある人。
以前なら、前者の方が成功確率が高かった。アイデアを実現できるからだ。
しかし今や、誰でもアイデアを実現できる。そうなると、医療の現場を理解している人の方が価値が高い。なぜなら、彼は医師が本当に使う機能と、ただ聞こえが良いだけの機能を区別できるからだ。
つまり、AIによって実行のハードルが均一化された結果、判断力の差が拡大している。
このことは、「ジェネラリスト」という言葉の意味も書き換える。
過去、ジェネラリストは、iOSもWebもバックエンドも書けるエンジニアを指していた。これはエンジニアリングの内側のフルスタックだった。
未来のジェネラリストは、学際的なフルスタックだ。
製品、デザイン、エンジニアリングを理解している人もいれば、製品、データサイエンス、エンジニアリングを理解している人もいる。これらの組み合わせは、かつては長い訓練が必要だった。
しかし今、AIが各分野の実行ハードルを下げたことで、一人で複数の領域を横断し、専門性を保ったまま働ける。
Claude Codeチームもそうだ。エンジニアマネージャー、PM、デザイナー、データサイエンティスト、財務、ユーザーリサーチ、皆がコードを書いている。
デザイナーは自分でインタラクションのプロトタイプを作り、チームに見せることもできる。もはや、図を出してエンジニアに実装させるだけではない。
財務は自分で分析ツールを作り、会社の複雑な財務モデルを動かす。BIに並んで待つ必要もない。ユーザーリサーチの同僚も自分でデータを処理し、過去にデータチームに依頼していた作業を引き受けている。
各人の専門性は依然として高いままだが、AIの支援により、コードを書くことは皆の共通言語になりつつある。
04 SaaSの堀が崩れつつある
過去十数年、SaaS業界にはいくつかの公理的な共通認識があった。
第一は切り替えコスト。ある企業があなたのシステムを使い始めると、そこに数年、あるいは十数年分のデータ、設定、フィールド、権限関係が蓄積される。
別のシステムに移行しようとすると、これらをそのまま移し替えるだけでも頭が痛くなる。
第二はワークフローのロックイン。社員の日常操作、部門間の協力、承認の流れはすべてこのSaaSに依存している。
別のシステムに変えるのは、データを移すだけでなく、過去数年の企業の「肌感覚」をすべてリセットすることに等しい。
これら二つが、過去のSaaSの最大の堀だった。しかし、十分に強力なモデルが登場すると、状況は変わり始める。
まず切り替えコストの側面から見ると、従来は、あるSaaSから別のSaaSに乗り換えるには、フィールドの整合やデータ構造の再構築に数ヶ月かかっていた。
今では、両者のインターフェースやデータ構造をモデルに渡し、自己学習させることで、最適なマッピングを見つけ出し、数日で使えるバージョンを作り出せる。
次に、ワークフローのロックインの方が面白い。従来、ワークフローが顧客をロックしていたのは、その複雑さと暗黙性、そして人に依存していたからだ。
社員の暗黙の了解、誰が誰に承認を求めるか、どの段階で詰まるか、これらをそのまま持ち出すことはできない。
しかし、Opus 4.7のようなモデルは、複雑なフローを理解し、分解し、新しい環境で再構築するのが得意だ。むしろ、再構築されたバージョンは元よりもスムーズに動くこともある。
したがって、従来、データやフローの蓄積によって築かれた堀は崩れつつある。
SaaSを運営する側にとっては悪いニュースかもしれないが、SaaSを利用する顧客や、新たな次世代SaaSを作ろうとするチームにとっては、これは大きなチャンスだ。
05 起業家にとって最良の時代
今後10年で、業界を根底から覆すスタートアップは、過去10年の10倍以上になる可能性がある。
その理由は単純だ。
小さなチームでも、AIを使えば大企業と同等、あるいはそれ以上の製品を作れる。逆に、大企業がAIを本格的に導入しようとすると、むしろ負の資産になる。
どういうことか？
十数年の歴史を持つ企業は、すでに独自の業務フロー、役割分担、協力習慣、研修体系、KPI評価などを築いている。これらは過去の資産であり、壁となっていた。
しかし、AIを本格的に取り込むには、これらすべてを見直す必要がある。業務フローの再構築、社員の再教育、各所の抵抗、複数部署や承認層の調整など、多大なコストと時間がかかる。
一方、三人のスタートアップは、最初からAIを前提にしている。過去の負債もなく、習慣も変えずに済む。今日話し合えば明日デモを作り、翌日にはユーザーに提供できる。
この速度差は、AI以前からあった。スタートアップは大企業に比べてスピードの優位性を持っていたが、AIによってその差は何倍にも拡大している。
なぜか？
AIが強力になるほど、一人の働き手が動かせるレバレッジは大きくなる。AIをうまく使う小さなチームは、今日の生産性は過去の十人分、明日には過去の三十人分に匹敵する。
しかし、大企業の組織の重さは変わらず、むしろAIの導入により、より重くなる。AIが強くなるほど、小さなチームの加速と、大企業の引きずる力の差はますます広がる。
これが Boris の言う「負の資産」だ。資金や人手、意欲がないわけではない。むしろ、過去に稼いできた筋肉が、今やAIの価値を最大化する妨げになっている。
06 MCPは死なない
MCPは死なない。
Skillが流行った後、多くの人はMCPも不要になると考えた。OpenClawの創始者も同様の見解だ。
しかし、Borisはそうは考えていない。彼は、MCPはAI時代のソフトウェア接続層になると見ている。
従来のインターネットのソフトウェア接続はAPIだった。
しかし、APIの核心的問題は、それがエンジニア向けに設計されていることだ。APIを使うには、まずドキュメントを読み、トークンを申請し、コードを書き、フィールドを整合させ、例外処理を行う必要がある。要するに、APIは人間の開発者向けだ。
これに対し、MCPは違う。モデルが直接接続でき、自己理解して呼び出せる仕組みであり、プログラマの翻訳作業を必要としない。
だから Borisは、APIを「Human Developer Interface（人間開発者インターフェース）」と呼び、MCPを「Model Interface Protocol（モデルインターフェースプロトコル）」と呼んでいる。一つは人間用、もう一つはモデル用だ。
これは、かつてのモバイルインターネット時代に似ている。すべてのサービスはAPI化されるのが当然だった。AI時代は、すべてのサービスがMCP化されるのが当然になる。
07 コンピュータ利用は依然重要
多くの人は今、Computer Useについて話すと、これはうまくいかないのではと感じる。
理由ももっともで、トークン消費が多く、遅く、不安定に見える。あまり実用的なデモには見えず、遠い未来の話のように思える。
しかし Borisが見ている視点は全く違う。
彼が重視しているのは、Computer UseがAIの実用化における最大の課題の一つを解決している点だ。現実世界には、APIもMCPも持たないシステムが大量に存在する。
特に企業の世界だ。
実際に企業に入ると、多くのコアシステムは非常に古い。ERP、OA、財務システム、内部承認、サプライチェーンのバックエンド、さまざまなカスタムシステム。多くはインターフェースもドキュメントもなく、自動化もされていない。そこに毎日、多くの社員が手動で操作している。
では、なぜこれらに直接APIを作らないのか？
作れないからだ。これらのシステムを作ったベンダーはすでにいないかもしれない。IT部門も再構築の予算も動機もない。
ビジネス部門も、半年や一年待つわけにはいかない。これらのシステムは、完璧なAPIができるまで待ってくれない。
短期的には、各種大規模モデルは、自身のComputer Use能力を高める方向に進むだろう。