前時代の開発ツールは、非常に慎重に一歩ずつ磨き上げられてきた。動作は安定しており、インタラクションは抑制的で、問題が発生しても予想の範囲内であることがほとんどだった。しかし今日、Claude Code や Codex といったソフトウェア製品は、「AI にそれ自身を書かせる」ことをデフォルトの道筋としている。確かに AI によってコード作成は高速化されたが、「複雑なソフトウェアを長期的にどのように維持管理するか」という根本的な課題を自動的に解決したわけではない。
Claude Code はその典型例だ。Anthropic のこのツールはほぼゼロから作られたが、チームは「Claude Code のコードは 100% Claude Code 自身が記述する」という極めて攻撃的な内部方針を長年維持してきた。大規模なコードのリファクタリングやコミットの圧縮（squash commit）、さらには細かなコーディング作業に至るまで、内部エンジニアや研究者のあらゆるタスクが Claude Code に依存している。
問題なのは、基盤となるモデル自体が非決定的であるにもかかわらず、その能力を担う製品コードがこのような開発手法の下で急速に積み上げられた結果、システムが悪循環に陥りやすくなっている点だ。この 1〜2 年、Claude Code は機能拡張を急速に進め、インタラクションロジックは複雑化する一方であり、製品そのものが不安定さを増している。クラッシュ、不可解なエラー、バグの増加、そして速度の低下が相次いでいる。
事態はもはや不条理とさえ言える域に達している。これらのパフォーマンス問題を体系的に修正し直すよりも、中核依存ライブラリである Bun を買収し、そのランタイムチームに希望を託す方を選んだのだ。言い換えれば、自社の CLI ツールが平気で 2GB ものメモリを消費する事態を何としてでも防ぐために、ランタイムチームごと買い取ったということになる。
一方、Cursor の置かれている状況はまた別の複雑さを抱えている。同社が最初に向き合わされたのは、膨大かつ複雑で、しかも自らゼロから作り上げたわけではないコードベース、つまり VS Code のフォーク（分岐）だった。このスタート地点が、同社を初日から困難な戦いに巻き込んだことを意味する。白紙の状態から製品を作るのではない。巨大なエンジニアリングシステムの上で増改築を繰り返さねばならない。差別化された機能を絶えず追加し続けると同時に、このフォーク版を長期間維持し、可能な限りアップストリーム（元版）との同期も図らなければならない。大規模なエンジニアリングに携わった者なら誰でも知っている通り、これは本来的に極めて苦痛を伴う作業であり、時が経つほどに分岐は深まり、メンテナンスコストは跳ね上がる一方となる。
これらの現象を総合的に見ると、ある明確なトレンドが見えてくる。AI プログラミングツールは、間もなく「大規模な書き直し（ビッグ・リライト）」の波に襲われるだろう。
そのコードベース自体が、初期の急激なイテレーションの中で、もはや後戻り不可能な状態へと導かれてしまったからだ。これ以上機能を追加し続ければ、システムはさらに脆弱になるだけだろう。真の解決策は、もはや旧来の土台が制御不能であることを認め、ゼロから新たなシステムを構築し直すことにある場合が多い。
だからといって、すべてのチームがその段階に達するわけではない。
OpenCode は興味深い対照例を提供している。同社もまた AI プログラミングの波の中で構築されたツールだが、チームは全く異なる戦略を採用した。彼らは過去以上にコードベースの一貫性と制約を重視し、どのファイルも既定の規範から逸脱しないよう細心の注意を払っている。同時に、より制約が強く、設計哲学が明確なツールやフレームワークを多用し、ドメイン駆動設計（DDD）をより断固として実践している。
彼らの考えによれば、大規模言語モデル（LLM）が開発に参加する状況下では、コードベースが「汚れる」ことの影響は増幅される。LLM は「旧来のパターン」と「新しいパターン」を区別できず、古い記述方法を正解として学習し、現在の規範に適合しないコードを生成し続けてしまうからだ。したがって、不潔なコードベースがもたらす悪影響は、かつてないほど深刻化している。
その結果、ある種の直感に反する現象が起きている。彼らのコードベースは、かつてないほどクリーンになっているのだ。「私たちがこれまでに書いた中で、最も品質が高いコードの一つかもしれない」。OpenCode の創設者の一人である Dax Raad 氏はポッドキャストでそう語っている。
同時に、氏は「手書きのコード」そのものを放棄したわけでもない。「新機能や複雑なアーキテクチャを設計する際、コードを書くこと自体が思考プロセスなのです。私は長大で詳細な仕様書を書くのは得意ではありません。その代わりに、型定義を書き、関数の組み合わせを試行し、ファイル構成を調整する。コードを書くことを通じて問題を理解するのです。これは多くのプログラマーが長年行ってきた働き方です。なぜその方法を捨てる必要があるというのでしょう。コードを書くことは、私の思考そのものなのです」。
さらに氏は、コード品質の観点から Claude Code をわずかに皮肉ってもいる。「Claude Code はプロトタイプを作り、プロダクトマーケットフィットは極めて高かった。体験が完璧でなくても成功したのです。しかし、だからといって全員がその速度に到達するために品質を犠牲にしなければならないわけではありません」。
本記事は、当該ポッドキャスト動画を基に InfoQ が一部編集・要約したものである。
OpenCode の起源
ホスト：昨年 12 月以来、OpenCode の発展は目覚ましいものです。OpenCode がどのように誕生したのか、振り返っていただけますか。
Dax： 私たちは長年オープンソースに携わっており、開発者向けツールの構築を通じて、この分野における企業の興亡を目撃してきました。そのため、オープンソース製品の構築には多くの経験を蓄積しています。
直近のプロジェクトは SST でしたが、現在の OpenCode の規模には及びませんでしたが、かなり人気はありました。そこでは、オープンソースプロジェクトの立ち上げ方、成功の秘訣、日々の運営方法、そしてオープンソースの利点と欠点について、完全な実践経験を得ることができました。この分野には深く根を張ってきたと言えます。
2025 年 2 月頃、私たちは黒字化を達成しました。当時、会社のメンバーはわずか 3 名でした。黒字化したことで、次の一手を熟考し始めました。既存製品を深掘りするか、それとも新たな方向性を探るべきか。AI は明らかに時代の重要な潮流です。これを完全に無視するのは極めて非合理的でしょう。
そこで、AI 開発者のために何ができるか、より広範なレベルで何が可能かを模索し始めました。いくつかの方向性を試みましたが、実際に製品と呼べるまでには至りませんでした。アイデア自体は私たち自身にとって有益なものでしたが、洗練された製品に仕上げることはできませんでした。
ちょうどその頃、Claude Code を使い始めました。それ以前にも Cursor をはじめとする多くの AI プログラミングツールを見てきましたが、当時はすでに話題になっていました。しかし、私たちのチームで実際に使い続けた者はいませんでした。試してはみたものの、元々気に入っていた何かを捨てる代わりとして、十分な対価が得られないと感じたため、継続しなかったのです。
しかし、Claude Code は初めて「これこそが正しいワークフローだ」と感じさせたツールでした。それまで私たちが行っていたのは、コードを ChatGPT にコピー＆ペーストし、また戻すという繰り返しでした。「なぜこれらは直接ファイルシステムに接続できないのか？なぜこれほど手作業に依存しなければならないのか」と常に考えていました。
Claude Code は、これらのプロセスを一本化する賢い統合方法を提供しました。そこで私たちは、「もしこれが初めて私たちが『使い続けたい』と思えたツールだとしたら、これは重要なことではないか」と考えるようになりました。
次に考えたのは、「オープンソースでの経験を活かしたらどうなるか」ということでした。そこには明白な空白地帯がありました。なんと、オープンソースのコーディングエージェントがまだ存在しなかったのです。「マルチモデルに対応したオープンソースのコーディングエージェントを作れないか」と考えました。モデル間の競争は今後長期にわたり続き、激化していくと分かっていたからです。
この参入ポイントは、私たちにとって自然な拡張でした。
ホスト：現在の日常の開発ワークフローはどのようなものでしょうか。どれほど変化しましたか。あなたは開発者であると同時に、開発者向けツールを作る側の人間でもあります。その視点は非常に特殊です。
Dax： 私たちのチームメンバーは皆 Vim ユーザーで、作業のほぼすべてをターミナル上で行い、Vim による編集体験を非常に楽しんでいます。Cursor への移行はコストが高すぎました。コードは編集できますが、テキスト編集の体験が我々の基準では劣化しており、そこで得られるメリットではその損失を補えなかったからです。
Claude Code が「使い続けられた」理由は、従来のエディタを使い続けつつ、AI 関連のタスクを別の独立したスペースで行える点にありました。両者が干渉し合わないことが、私たちにとっては重要だったのです。
Cursor はある種の過渡期にある製品だと感じています。従来のエディタから AI プログラミングという新しいパラダイムへと、ユーザーを強引に導こうとしているように見えるからです。もちろん利点もありますが、私や多くの人々にとって、これは少し中途半端な状態に位置しています。私は単にエディタでコードを書きたいだけで、至る所から AI 機能が飛び出してくるのは望んでいないのです。
Cursor を使っていると、至る所に提案が表示され、新しい UI パネルが乱立しているように感じられ、非常に違和感を覚えました。私はエージェントを「隣に座る有能だが少し抜けている同僚」のように扱いたいのです。たまに何をしているか確認し、フィードバックを与え、その間に自分は別のことをする。作業は分離可能です。
したがって、Claude Code の最大の利点は、エディタの外側に独立したスペースを提供している点に他なりません。OpenCode を作る際も、この方向性を継承しました。この「独立したスペース」の中で、エージェントとの対話をいかに豊かに、いかに高品質に行えるか、そこに注力しているのです。
現在の私のワークフローは、Neovim でコードを編集し、エージェントタスクは Agent に処理させるというものです。確かにエージェントを使う頻度は増えており、エディタに向かう時間は相対的に減りましたが、手書きのコードを完全に放棄したわけではありません。依然としてエディタを多用し、手動でコードを書いています。
もはやコードは書かないのか？
ホスト：現在、トップクラスの開発者たちの間で「もはや一からコードは一行も書いていない」と主張する人が多く、「プログラミングの死」を意味すると捉える人もいますが、どうお考えですか。
Dax： その主張には困惑を覚えますね。手書きのコードの割合がどれほどかと聞かれても、答えに窮します。私は絶えずツール間を切り替えており、定量化が難しいからです。
もし誰かが「エディタはほぼ使わず、OpenCode や Codex といったエージェントツールの内だけで完結している」と言えば、驚きます。なぜなら、これらのツールはコードリーディングには向いていないからです。彼らはコードレビューを全く行わないのでしょうか。それとも GitHub にプッシュしてから確認するのでしょうか。
また、新機能を設計したり、複雑な事柄に取り組んだりする際、私にとってコードを書くこと自体が思考の一部です。ボタンの追加など単純な変更であれば、プロンプトを投げるだけでよく、生成されたコードを詳しく見る必要さえありません。周囲のコードと類似しているからです。
しかし、全く新しいものやシステムの設計を行う際は、コードを書くことで、具体的に何をすべきかを理解する必要があるのです。詳細な仕様書を長々と書いて AI に実装させるのは私には合いません。型定義を書き、異なる関数の組み合わせを試行し、ファイル構造を調整する。そのプロセスを通じて問題を理解する。これこそが、これまでに多くのプログラマーが実践してきた働き方です。
ですから、私にそのような行為をやめる理由が見当たりません。それが私にとって物事を理解する方法だからです。
「私は全くコードを書かない」と言う人がいれば、私はやや懐疑的になります。そこには心理的な要因が働いているように感じます。誰もが巨大な変化の最中にいると感じ、自分が取り残されることを恐れるあまり、「自分は最前線にいる」と自らを納得させようとしているのでしょう。
さらに現在、「この変化によって多くの人が淘汰され、生き残るのは一握りの人間だけだ」という物語が流れています。そのため、局所的な成功を「今はすべてがこのように行える」と過大評価する傾向があるのです。あるシナリオでうまくいけば、それが「すべてに適用可能」であるかのように語られ、やや誇張されているきらいがあります。
したがって、これらの発言から真実を判断するのは困難です。その裏には多くの感情や心理的要因が入り混じっているからです。
ホスト：その点は素晴らしいと思います。「意図的なマーケティング」とは思いませんが。例えば Claude Code の初期開発者の一人である Boris は「もはや一からコードは書いていない」と述べていますが、最近では「なぜ Anthropic は依然として開発者を採用しているのか」とも語っています。人間が依然として多数関与していることを示唆しており、非常に不可解です。
Dax： 同意見です。悪意があるわけではなく、興奮と不安が入り混じる中で、人々が現実を正確に表現できなくなっている結果です。これは新しい技術やフレームワークが登場する際によく見られる現象で、「働き方を根本から変えた」と主張する人が後を絶ちません。これを判断する有効な基準は、その成果物を直接検証することです。多くの場合、実際に実装された製品はなく、単なる試行段階に留まっています。製品があったとしても、品質が向上しているとは限らず、むしろ劣化していることさえあります。現在の AI プログラミングの実践においても同様で、「完全に AI にコードを書かせている」と主張する人々の成果物の品質が芳しくないのは、ある意味で現在の真の水準を反映していると言えるでしょう。
ホスト：OpenCode と Claude Code は直接競合するように見えますが、いかがですか。特に Anthropic がサブスクリプションの利用制限をかけた後、お考えに変化はありましたか。
Dax： 世界がゼロサムだとは考えていません。多くのシステムでは複数当事者の共存と共栄が可能です。しかしビジネスの領域では、現実に競争が存在します。ビジネスはスポーツ競技に似ており、世界に対する異なるビジョンを巡って争います。完全に一方が勝利するとは限りませんが、競争は確かに存在します。しかし、それ以上に重要なのが「ポジショニング」です。製品が似て見えても、ポジショニングが全く異なる場合があります。
OpenCode の成功は、製品品質だけでなく、むしろポジショニングに由来するところが大きいと考えています。私たちはモデル間の競争が継続し、クローズドソースとオープンソースの双方で激化すると予測しました。価格は低下し、競争は激化します。そこで私たちが選んだ道は、「単一モデルに縛られないツール」を作ることでした。これにより、モデル間の競争の恩恵を受けられます。次に、「オープンソースのコーディングエージェントの第一人者」という地位を占めることです。歴史が示す通り、データベース、コンパイラ、エディタなど、開発ツールの大半は最終的にオープンソース化します。
一方、Claude Code は垂直統合の道を歩んでいます。これは私たちのポジショニングとは異なります。ポジショニングの観点では、必ずしも直接競合するわけではありません。しかし価値観のレベルでは確実に対立しており、私たちの価値観の方がより良い結果をもたらすことを証明したいと考えています。
ホスト：Open Code と Claude Code の両方を使用したユーザーとして、Open Code の体験は非常に優れていると言わざるを得ません。要約すれば、オープンソースであること、異なるモデル間を自由に切り替え可能なこと、ロックインがないこと、そしてファーストムーバーアドバンテージがあることです。
Dax： おっしゃる通り、これらはスローガンではなく、具体的な細部にまで反映された中核的な方向性です。なぜオープンソースにこだわるのか。それは、より多くの人々が異なる環境で試すことになるからです。Open Code は設計の初期段階から、あらゆる環境への適応を想定しています。企業による厳しい制限下にあるノート PC で、Amazon Bedrock しか使用できない場合でも、正常に動作することを保証しています。オープンソースの利点は、社内で全ての環境を再現できなくとも、コミュニティがそれを補ってくれる点です。他者が実際の環境でテストし、問題を報告し、修正を提出してくれます。これにより、様々なテールエンドのシナリオを十分にカバーできるのです。製品の品質が現在の半分であったとしても、同様の成功を収めていたかもしれません。成功の要因は製品品質そのものよりも、むしろポジショニングにあるからです。
ホスト：OpenAI は少なくとも貴社との協力関係において、異なるアプローチを取っています。両社の関係はどのようなものでしょうか。なぜ OpenAI は異なる手法を選んだのでしょうか。
Dax： これもまた私たちのポジショニングに起因します。私たちがオープンソースの選択肢であれば、「標準」となり、他社がその上に構築したり、自社のシステムに組み込んだりする機会が生まれます。そのため OpenAI と協力する以前から、GitHub、GitLab、JetBrains 等と対話し、彼らの大規模モデルサービスを利用する際の推奨手段として Open Code を採用するよう働きかけてきました。私たちがこれにより多くを投資し、ユーザーフィードバックも良好だったからです。一部の企業を納得させた後で OpenAI に接触し、「業界にはすでに支持があるが、参加する気はあるか」と尋ねました。
OpenAI を選んだのは、彼らが Anthropic と競合関係にあり、コーディング分野では Anthropic のマインドシェアが高かったからです。OpenAI にとって、私たちを支援することはパブリック・リレーションズの利益となり、より多くのユーザーに Codex を利用させることにもつながります。私が彼らに連絡したタイミングは、まさに Anthropic が Cloud Max や Open Code をブロックした時期と重なり、彼らにとって逆転の機会と映ったのです。
OpenAI が真にこのモデルに共感しているのか、それとも短期的な競争動機によるものなのかは定かではありません。しかし、私たちは各陣営のインセンティブを洞察し、重要な節目で影響を与え、自社、ユーザー、そしてオープンソースコミュニティの双方に利益をもたらす局面を作り出すのが得意です。本質的には、インセンティブ構造を理解し、その駆け引きの中でより良い結果を創出することに他なりません。
ホスト：最近、業界では M&A（合併・買収）の事例が相次いでいますが、OpenCode が次になることはありますか。
Dax： 私たちは真に巨大な市場を長年探し求めてきましたが、ついにそれを見つけました。世界中に 3000 万から 5000 万人の開発者がおり、私たちの製品は理論上、全員にサービスを提供できます。このような機会は滅多にありません。したがって、それを容易に手放すのは極めて困難な決断です。実際、多くの買収提案を受けていますが、真剣に検討はしていません。非常に高額な提示がない限りね。AI 分野には法外な買収事例が存在しますから。
かつてチームのグループチャットで「ある企業から買収の申し出があった」と伝えたことがありますが、完全に無視され、製品の議論が続きました。もう一度注意すると、「ゼロを一つ増やしてからにしてもらえ（桁を一つ上げろ）」と言う始末です。チームは本当に物事を成し遂げることに注力しており、短期的な現金化には興味がありません。
もちろん、数年後に成長が停滞すれば、私の態度も変わるかもしれません。企業が成長し続けるのは、創業者が長年にわたり情熱を維持できるかどうかにかかっています。多くの M&A は、創業者の情熱低下や、道のりの長さに起因して発生します。現状では、私たちは最後までやり遂げたいと考えています。
ホスト：AI によってスピードは上がりましたが、その分技術的負債は蓄積されていませんか。このトレードオフの本質は変化したのでしょうか。
Dax： このトレードオフは常に存在するものです。多くの場合、人々は「速度のためにトレードオフした」と品質問題を正当化します。しかし振り返れば、問題の大半は意図的な選択ではなく、経験不足に起因しています。
私が初めて何かを行う際、問題の 95% は経験不足によるものであり、意識的な選択によるものではありません。次に同じことを行う際、同じ時間内でもより良い結果を出せます。
AI も同様で、全員の能力の上限を引き上げますが、怠ける口実にはなりません。私たちは依然として内省し、改善を続けるべきです。「動けばよい」と考えるべきではありません。
「コードは酷いものだか、書くのは速い」と言う人もいます。実際には、より経験豊富な人間であれば、同じ速度でもはるかに良いコードが書けるはずです。これは本質的に能力の問題なのです。
ホスト：では製品やユーザーの視点では、短期的にはポジショニングや速度が品質より重要になるのでしょうか。例えば Claude Code の場合、初期の迅速なリリースは適切だったのでしょうか。後になってアプローチを変えるべきだったのでしょうか。
Dax： 誰もが可能な限り迅速に進み、経験に基づいて異なるトレードオフを選択するものだと考えます。Claude Code のケースでは、プロトタイプを作り、プロダクトマーケットフィットが極めて高かったため、体験が完璧でなくても成功しました。これはよくあることですが、だからといって「全員がその速度に到達するために品質を犠牲にしなければならない」わけではありません。
私たちは Open Code をほぼ同時期に開始し、ターミナルフレームワーク、Zig による実装、React および SolidJS 用バインディング、Bun へのコンパイルなどを行いました。同様の速度でより高い品質を達成できたのは、これが私たちの得意分野だったからです。もちろん、私たちより優れた成果を出す者もいるでしょう。総じて、この業界には自分より 10 倍劣る者もいれば、10 倍優れる者も常に存在するものです。
開発者の選択
ホスト：コードの大部分が AI によって生成される際、効率向上と品質保証のバランスをどのように取っていますか。例えばコードレビューにおいて、コードを読まずにそのままマージすることはありますか。
Dax： やや直感に反する現象ですが、現在の私たちのコードベースは、かつてないほどクリーンです。いや、私たちがこれまでに記述した中で、最も品質が高いコードの一つかもしれません。その理由は、不潔なコードベースがもたらす悪影響が、以前よりもはるかに深刻化しているからです。
かつてのコードベースの典型的なライフサイクルは以下の通りでした。まず一連のパターンを策定します。数ヶ月後により良いプラクティスが見つかれば、チームに新しいやり方を通知しますが、既存のコードをすぐにリファクタリングすることはありませんでした。時間が経つにつれ、コードベース内には複数の歴史的スタイルが混在するようになりました。以前ならそれでも許容されましたが、現在では不可能です。大規模言語モデルは「旧パターン」と「新パターン」を区別できず、古い記述方法を正解とみなし、現在の規範に適合しないコードを生成し続けてしまうからです。
そのため、私たちは以前にも増して、明確かつ統一されたパターンの厳格な適用を重視し、コードベース内のどのファイルも規範から逸脱しないよう努めています。ある意味で、現在の方がコード品質を重視しています。なぜなら、私たちは「勤勉だが理解力に欠け、記憶力は抜群ながら、どのパターンが優れているかを自ら判断できない LLM」を雇用しているようなものだからです。私たちは、より強い制約と明確な設計哲学を持つツールやフレームワークを多用し、ドメイン駆動設計をより断固として実践しています。
すべてのコードを読むかどうかについては、リスクに基づいて判断しています。パターンが成熟し安定しているモジュールでは、出力結果に対する予測可能性が高いため、通常は簡易的なチェックのみを行います。一方、構造がまだ安定していない領域では、より慎重に一行ずつ確認します。チーム全体でも概ね同様の戦略を採用しています。
ホスト：すべてのコードを一行ずつレビューしないという発言に驚く人もいるでしょう。しかし振り返れば、巨大企業でさえ、すべてのコード行が真剣に読まれているわけではありません。開発者への信頼が確立されていれば、レビューも迅速に行われます。ある意味では、LLM に対してもある種の「信頼」を築くことができるとおっしゃっているのですね。
Dax： 私は依然としてやや保守的だと自負しています。巨大企業でさえ、少なくともコードを理解している人間、つまり作成者が一人は存在します。しかし AI 生成コードにおいて、それを理解する人間が一人もいないとすれば、それは不安です。
私は「リスク感」で判断する傾向があります。例えば最近、ターミナルインターフェースに新しいダイアログボックスを実装した際、レビューを最小限に抑えました。ユーザーの視点から十分にテストし、機能が正常に動作することを確認したからです。基礎となるコンポーネントが非常に成熟していたため、リスクは低いと判断しました。技術的な実装に細かな欠陥がある可能性はあり、実際後に修正を行いましたが、短期的には問題ありませんでした。ただし、不適切なコードがその後のモデル生成を汚染する可能性があるため、可能な限り早期に修正するようにしています。
本質的には過去と同じです。適度に「手抜き」をしても構いません。ただし、必ず戻って修正することを忘れないことです。
ホスト：現在、プログラミングの楽しさが損なわれ、開発者が「プロンプト工場」になっていると考える人がいますが、いかがですか。AI によってプログラミングへの興味が失われましたか。
Dax： 私の場合、答えはノーです。ただし、私は少数派かもしれません。自社の経営者であるため、仕事の方向性を自主的に選べるからです。AI ツールにより、新しいアイデアをより迅速に探求でき、反復的な作業ではなく、より創造的な部分に時間を費やせるようになりました。
しかし、多くの人が挫折感を抱く理由は理解できます。タスクを割り当てられ、プロンプトを入力して結果を待つだけで、より挑戦的な仕事がない場合、退屈に感じるのは当然です。実際、プログラミングには反復的な作業が多く含まれており、それが現在エージェントに代替されつつあります。
真に面白い部分、つまりシステム設計、方向性の判断、問題の定義は、依然として人間が主導権を握っています。そして、それは頻繁に起こることではありません。毎日ではなく、月に一度程度のことかもしれません。
ホスト：個人的には、AI によって楽しさが増したと感じています。より高次の抽象化に集中でき、構文の詳細に悩まされなくなりました。しかし、ツールへの依存が行き過ぎれば、スキルは低下しないかと懸念しています。
Dax： その懸念はもっともです。子供の頃、私は暗算が得意でしたが、今では明らかに衰えています。同様に、AI への長期依存により、特定のコーディング能力が萎縮する可能性があります。現実には計算機が暗算を代替したように影響は限定的かもしれませんが、複雑な問題に直面した際、その能力の差が顕著になるでしょう。
問題は、「瓶から精霊が出てしまった」ようなものです。楽に済むツールがあれば、人々はそれを使い続けます。重要なのは、節約されたエネルギーをより価値あることに使うのか、それとも TikTok を見るだけに費やすのかということです。
私は両方の状態を体験しました。没頭することもあれば、AI に作業を任せてぼんやりすることもあります。この現象が数百万人のプログラマーで同時に起これば、長期的な生産性がどれだけ向上するかは判断が難しいところです。特に、自分があまり関心のない仕事をしている場合、人間は自発的に余計な努力を払うことは稀です。
ホスト：では、コードを書くことが好きであることは、逆に弱点になるのでしょうか。技術に没頭するあまり、より重要な能力を見失う恐れはありませんか。
Dax： これは新しい問題ではありません。過去にも技術的詳細に没頭し、製品やビジネス判断を軽視する開発者は存在しました。優れている人々はバランスを取る術を知っています。いつ技術を深掘りし、いつ製品の方向性に注目すべきかです。
私の見解では、プログラミング能力は立派なキャリアポジションをもたらしますが、真の限界を突破するのは往々にして「第二の専門性」です。優れたプログラマーであると同時に、特定の業界（金融、医療、エネルギーなど）に詳しければ、極めて希少かつ強力なポジションに立てます。プログラマーはほぼすべての業界に参入できます。これが大きな強みです。もし担当分野で深い理解を蓄積できれば、見落とされていた構造的な機会を発見できるでしょう。
ホスト：あなたは買収や高給のオファーを何度も断っています。なぜ、より安定した道を選ばなかったのですか。
Dax： 若い頃、Snapchat が Facebook からの数百億ドル規模の買収を拒否した際、創業者は狂っていると感じました。しかし後に理解しました。キャリアが発展するにつれ、「安全網」は大きくなります。初期の頃なら良いオファーを断れなかったかもしれません。しかし蓄積があり、能力があり、逃げ道がある時、野心もまた成長します。買収を受け入れれば、これまでの夢を捨てることになります。「すべてのビジョンがここで終わる」という感覚は、短期的な安楽さよりも遥かに強烈です。したがって、条件が並外れて魅力的でない限り、そのような選択は私には困難です。
ホスト：多くの人があなたを「エリート開発者」と見ていますが、あなたの核となる強みは何だと考えますか。
Dax： 率直に言って、技術的な実行力においては私より優れた同僚が多くいます。私が最高のプログラマーであるとは限りません。私の強みはむしろ、全体像を捉え、トレンドを予測して適切な判断を下す能力にあります。他の 2 人の共同設立者も同様にこの点に優れており、互いに高め合っています。複雑な業界環境の中で法則性を見出し、長期的に成立する基本論理と、一時的に成立する認識を区別することに注力しています。チームはこの点に多くの時間を費やし、友人とも深く議論を交わします。この思考様式は移植可能で、プログラミング、事業運営、個人の意思決定、人材採用など多方面に適用できます。これがおそらく私の真の強みです。
ホスト：今おっしゃった能力は生まれつきのものですか。それとも後天的に養ったものですか。もし後天的なら、誰でも努力で向上できるのでしょうか。
Dax： 業界のトップクラスの人々と話すと、生まれつきの才能を持っているように感じますが、深く話すと、彼らの多くは平凡なスタートから、継続的な投資によって向上してきたことに気づきます。私にとって、この能力の中核は、自身の認知の最終的な「正しさ」を真に重視する点にあります。その場の議論での勝利を追求するのではなく、世界を正確に捉えるモデルを構築することです。これを目標とすれば、必要な行動が逆算されます。中核は思考を明確に保ち、自己と自己の不安感を認識することです。多くの場合、不安感が判断を歪め、主観的な期待から一方的な証拠を意図的に採用してしまいます。これには長期的な成長の積み重ねが必要です。
若い頃は自信がなく、物事を見る力も弱かったのですが、自信と成果の蓄積に伴い、思考様式も洗練されてきました。同時に、受け取る情報には注意深くある必要があります。情報の氾濫は思考を制限し、単一の認知環境に閉じ込める恐れがあるからです。自己認識と継続的な内省は、長期的に堅持すべきことです。現代社会において思考の明確さを保つことは多くの妨害に直面しますが、これを成し遂げるには、「最終的な正しさ」への追求を常に堅持する必要があります。
ホスト：採用について伺います。「近道」についてはどうお考えですか。学歴や大手企業での経歴は重要でしょうか。
Dax： 多くの人が「Google にいた」といった証明書を提示します。経験則から、この証明書は大きな影響を与えます。しかし不快に感じるのは、その影響が過大評価されている点です。Google、Meta、Amazon、Apple といったブランドを見ると、人々は特定の能力を自動的に付与してしまいます。確かに一定の相関はありますが、人々が思うほど強くはありません。
私たちは特殊な立場にいます。製品は開発者向けで、かつオープンソースです。そのため、潜在的な候補者はユーザーか貢献者であることが多いのです。混沌としたオープンソースの環境で質の高い貢献ができることは、それ自体が強力な選別メカニズムです。最近採用した 10 名以上は、従来の面接も経歴書の確認も行っていません。実際の成果にのみ注目しました。
マクロな視点で見れば、大規模な採用には学歴や企業経歴といった「近道」が必要です。しかし個人の視点では、このラベルはプラスとマイナスの両方向にバイアスをもたらします。履歴書に Google と書かれていると、私は本能的にネガティブな前提を抱いてしまいます。なぜそのキャリアパスを選んだのか、その動機や価値観、日常の協業スタイルを連想してしまうからです。同様に、この証明書だけで相手を過大評価するのも不公平です。結局のところ、その人と 1、2 回話すだけで、真の状態は容易に感じ取れるものです。私にとっては、非常に興奮するか、共鳴しないかのどちらかです。私たちの規模であれば、この方法で十分です。最終的に最も効果的なのは、成果を示すことです。十分に優れていれば、世界はいずれ過小評価を正してくれるでしょう。
参考リンク：
https://www.youtube.com/watch?v=IGsbARhERqc
本日の推奨記事
Jensen Huang 氏、GTC 2026 講演録：すべての SaaS 企業は消滅する。トークンコストは世界最低。「ロブスター」が歴史を創る。Feynman アーキテクチャは目前に
Anthropic のエンジニアも手放せない！深夜にふと思いついたオープンソースの神器、OpenAI に高額買収され、23 名のスタートアップが逆転劇
OpenClaw の父が中国のスピードに驚嘆！大手企業が次々と新戦線へ参入：AI を用いて「一人企業」を量産
会議推奨
OpenClaw の台頭、「エビ養殖」ブームの熱狂と、年始の Agentic AI への注目の高さは並々ならぬものです。この潮流の中、セルフホスト型エージェントの形態が急速に普及しています。多様なエントリーポイントでの対話、永続的メモリ、Skills ツールチェーンが強大な生産性をもたらしています。しかしその裏では、エンジニアリング実装における真の課題が露呈しています。権限境界と分離実行、Skills サプライチェーンのセキュリティ、観測可能性と追跡可能性、メモリの階層化とクロスコンテキスト汚染、そしていかにしてエージェントをチームの開発・運用プロセスに統合し、安定的な収益を生み出すかといった問題です。
こうした一連の課題に対し、4 月 16 日から 18 日に北京で開催される「QCon」では、特別企画として「OpenClaw エコシステムの実践」特集を組んでいます。最前線の実践事例と失敗からの教訓に焦点を当て、企業がどのようにプライベート Skills を構築し、セキュリティガードレールを策定し、監査および再生メカニズムを構築し、品質・効率の指標体系を確立し、最終的に使用可能なデモ段階から信頼性の高い本番システムへとセルフホスト型エージェントを進化させたかを共有します。