Claude Codeを使うとファウンダーとして劣化するのか？

まとめ

私はAI企業eeselを経営している。正直に言うと、今やコードの大半はAIエージェントが書き、このブログの多くもエージェントが下書きし、自社のサポートチケットの増加する割合もエージェントが解決している。だからファウンダーたちがClaude Codeによって自分が「ファウンダーとして劣化するのでは」と尋ねてきたとき、それを仮定の話としては聞かない。2年間、この問いの中に生きてきた。

私の答えはこうだ。Claude Codeはあなたをファウンダーとして劣化させない。それはファウンダーシップの本質ではなかった部分を消し去り、常に本質だった部分を露わにする。コードを打ち込むことは決して本業ではなかった。何を作るべきかを知り、結果が良いかどうかを判断し、アウトカムに責任を持つことが本業だ。AIはその三つすべての価値を下げるのではなく、高める。

本当のリスクはアイデンティティへの脅威ではない。判断力への脅威だ――そして、機械が渡してくるものを確認しなくなった場合に限り。空洞化するファウンダーは、読まずにコードを出荷する者たちだ。鋭さを増すファウンダーは、ハンドルから手を離さずにエージェントに運転させる者たちだ。

不安は本物だが、向き先が間違っている

その心配はたいていこう聞こえる。「自分で書いていないなら、本当に作ったと言えるのか？書き続けなければ、いつか忘れてしまうのでは？」

感じること自体はもっともだ。Claude Codeを起動し、コードベース全体を読み込み、十数ファイルを編集し、テストを走らせ、コーヒーを飲みながらプルリクエストを開くところを眺めていると、かつての勲章――一行一行、自分で作り上げた――が自分のものではなくなった気がしてくる。数字で見ると鮮明だ。Claude Codeを作るチームにインタビューしたエンジニアのGergely Oroszは、Claude Code自身のコードの90%はClaude Codeが書いていること、そこのエンジニアは1日に約5件のプルリクエストをマージし、全員が導入した1年でエンジニア1人あたりのプルリクエスト処理量が67%増加したと報告している。

しかし、その不安が本当に悼んでいるものに目を向けてほしい。それはタイピングだ。そしてタイピングは、ファウンダーが行う最も価値の低い行為だった。企業を築く難しい部分――何が存在する価値を持つかを決め、プロダクトのどこがおかしいかを感じ取り、何を削るかを選ぶ――は、キーストロークの中にあったことは一度もない。頭の中にあった。Claude Codeはそれには触れない。ただ手作業を退けて、それらのためのスペースを増やすだけだ。

実際に萎縮するものと、そうでないもの

ここが正直なバージョンの答えが宿る場所なので、正確に話したい。何かは確かに萎縮する。ただし、予想とは違うものだ。

30日間Claude Codeを使い続けたある開発者が、私が読んだ中で最も率直な記録の一つを書いた。彼は1ヶ月で過去6ヶ月分以上を出荷し、その一方でスキルが静かに離れていくのを見た：

「2週目に不穏なことに気づいた。私はコードをゼロから書く能力を失いつつあった。なぜアルゴリズムを考えなければならないのか、Claude Codeが瞬時に生成できるのに？私はプログラマーではなく、AIアウトプットのマネージャーになりつつあった。」

Prassanna Ganesh Ravishankar、Claude Code 30日間使用記

最後の行がすべてで、それが悲劇かどうかは「マネージャー」という言葉にかかっている。あなたがプログラマーで、価値が記憶からアルゴリズムを書くことにあるなら、AIアウトプットのマネージャーになることは損失だ。ファウンダーなら、アウトプットのより鋭いマネージャーになることは、何年もかけて自分に与えようとしていた昇進そのものだ。萎縮するスキルは、ファウンダーが最初から委任しているべきだったものだ。

積極的に怠らない限り萎縮しないのは、判断力だ。シニアエンジニアのJesse Altmanはその変化の核心を突いた。コードを書くことはもはや難しい部分ではなく、「プロセスの最も困難で時間がかかる部分は今や意思決定であり、その情報を伝えること」だと言った。それはあなたの役割の格下げではない。ファウンダーシップが常に何であったかの説明だ。

私が見た中で最も明確な枠組みは、AIエデュケーターのSantiago Valdarramaが2つのモードの境界線を引いたものだ：

「モード1：AIがコードを書き、人間がコパイロットする。モード2：人間がコードを書き、AIがコパイロットする。この2つは大きく異なる。一方が他方を置き換えるわけではない。プロの開発者は両方を使う。IDEは依然として王者だ。」

Santiago Valdarrama（X）

ファウンダーは主にモード1で生きる、それは正しい。多くのビルダーはモード2の作業のためにCursorのようなエディタベースのコパイロットも開いていて、それはそれで構わない。罠はモード1にいることではない。罠は目を閉じたままモード1にいることだ。

分岐点：鋭くなる者と空洞化する者

ここが誰も聞きたくない部分なので、はっきり言う。Claude Codeは優れたファウンダーをより優れた者にし、怠惰なファウンダーをより劣った者にする。その違いはアウトプットをまだ読んでいるかどうかだ。

見ようとすれば、警告の物語はいたるところにある。あるエンジニアリングリーダーは5倍速で機能を出荷し、すべてのテストに合格するのを見て、その後実際のコードを見たところ、AIが再利用可能な関数1つではなくほぼ同一のメソッドを5つ書いていたことを発見した。彼の評決は私の記憶に残っている：

「AIは『動かす』ことを最適化するのであって、『保守しやすくする』ことは最適化しない。今日時間を節約するものは明日技術的負債を生む。うまくいくのは：AIをレビューが必要なジュニア開発者として扱うことだ。」

jkeaney（LinkedIn）

レビューが必要なジュニア開発者という言葉は、5つの単語で全ての規律を表している。優秀で、速くて、少し過信気味なジュニアが未読のままmainにマージするのを許すことはないだろう。AIエージェントにそれをし始めた瞬間、ツールはあなたを空洞化し始める。唯一重要な筋肉を鍛えることを止めたからだ。

10年のキャリアを持つ開発者が同じアイデアをアドバイスとして表現した。AIで出荷するすべてのファウンダーに渡したい言葉だ：

「勝つエンジニアはAIを最も使う者ではない。それを使って自分自身の理解を積み上げる者だ。Claude Codeは近道ではない。乗数だ――ただし、自分が基礎を持ち込んだ場合に限り。」

@ujjwalscript（X）

ファウンダーとして読み直し、「エンジニア」を「ファウンダー」に置き換えてみよう。勝つファウンダーは最も自動化する者ではない。自動化を使って自分のセンスとリーチを複利で増やす者だ。あなたが持ち込む基礎は判断力、プロダクトセンス、そして「それは違う、やり直せ」と言う意志だ。

ビルダーの視点からどう見えるか

ここは理論ではない。eeselでは実際にプロダクトの一部をバイブコーディングし、AIコンテンツライターを6ヶ月間社内でドッグフードしてから公開ブログを信頼し、AIエージェントを自社のサポートキューで動かしている。自信満々なエージェントが微妙に間違ったものを出荷するのを目の当たりにした。だからこそ今では、デモを額面通り受け取るのではなく、本番に出す前に必ず変更を履歴に対してシミュレーションしている。レバレッジは本物で、失敗モードも本物だ。両方と向き合うことで、境界線が本当はどこにあるかを学んだ。

AIをうまく導入するすべての顧客に見られるパターンがある。私自身がたどったのと同じ軌跡だ。まともな人は誰もフルオートパイロットに即座に切り替えない。AIが返信を下書きし、人間がすべてのアウトプットを承認するところから始まる。実際の結果の上に信頼が積み上がるにつれ、ルーティンを任せてスポットチェックするようになる。最終的に人間は作業をやめ、方向性を設定し始める。そのはしごの頂上は度胸では稼げない。判断力で稼ぐものだ。

このすべてにはもっと静かなシグナルもある。かつて離脱した顧客が、解約と同じ呼吸の中で、長期的には「AIで可能になったから自分たちで作る」と言った。5年前なら夢物語だった言葉だ。今は取締役会議の議題になっている。LovableやOpenAI Codexのようなツールは、forループを書けない人でも動作するプロトタイプを手の届く範囲に置いた。ソフトウェアを作るハードルが崩壊した。これは希少性が移動したことを意味する。もはや「誰が作れるか」ではない。「何を作る価値があるかを知っていて、作られたものが本当に良いかを判断できるのは誰か」だ。それがファウンダーの仕事であり、突然それがはるかに多く必要とされるようになった。

ただ、懐疑論者に正直でいる価値はある。なぜなら利益はタダではないからだ。エンジニアのMichael Novatiはキャリブレーションのポイントを的確に示した：AIエージェントはエンジニアの労力の1%を代替するだけで元が取れるが、それを本当のレバレッジに変えるには習得が必要なスキルであり、切り替えるスイッチではない。奇跡を期待してジュニアの最初のドラフトを受け取ることが、人々が失望に終わる理由だ。このツールはあなたがすでに持ってくるものの乗数であり、ゼロの乗数はまだゼロだ。

では、ファウンダーとして劣化するのか？

あなたが意思決定を任せてしまうなら、そうなる。

目を開けて使えば、Claude Codeは私が触れた中で最もファウンダーを増幅するツールだ。常に委任しているべきだったもの――手作業の生産――を取り上げ、判断するためのドラフトとして返してくれる。2人チームが10人チームのように出荷できる。「アイデアはあるが作る時間がない」を「今夜見せてもらおう」に変える。そのどれもあなたをファウンダーとして劣化させない。ファウンダーのスキル――センス、判断力、決断力――が希少である唯一のものになる。

目を閉じて使えば、あなたが理解できず保守もできないもっともらしい、未テストの、重複したコードの塔を喜んで作り上げる。そしてそれがあなたをファウンダーとして劣化させる。タイピングだけでなく思考を外注したからだ。ツールはあなたがどんなファウンダーになるかを決めない。差分を読むかどうかを選ぶたびに、あなたが決める。

eeselを試す

コードを直撃しているのと同じ変化がカスタマーサポートを直撃している。それが私がeeselを作った理由だ。Claude Codeはソフトウェアを作るためのインフラ；eeselはジョブを実際に実行するために採用するAIチームメート――この場合はサポートキューだ。Zendesk、Freshdesk、Gmailなどチケットが存在する場所に接続し、過去のチケットとヘルプセンターでトレーニングし、初日から下書きと解決を始める。その間、この投稿全体が語るコパイロットからオートパイロットへのループにあなたは留まる。それが下書きし、あなたが承認し、変更を本番前に実際の履歴に対してシミュレーションすることで信頼を積み重ねながら、より多くを任せていく。

判断力を失わずにコードを委任することが理にかなうなら、同じようにサポートを委任することも理にかなう。eeselを試すのは無料で、エージェントは数分で稼働する。営業電話は不要だ。