スタートアップがClaude Codeで协作して得た5つの教訓

弁護士と医師が自らコードを提出、CEOもUI改修に着手

「全員がリリース」：問題を最も理解している人が直接最初の修正版を出す。ただしClaudeが彼らの日常ツールを見えることが前提。

Parahelp共同創業者のMads Lunau Liechti氏自身、非技術畑出身のCEO（会社の最高責任者）であり、UI（ユーザーインターフェース）変更も直接出している。Anthropicが観察した結果は：エンジニアのアウトプットは伸びており、非技術者のアウトプットはゼロから立ち上がってきた——後者にはさらにエンジニアには無いドメイン知識（特定業界で長期にわたって蓄積された実務経験）が備わっている。

Crosbyはこの路線をさらに推し進めた。共同創業者兼CEOのRyan Daniels氏は、Claude Codeが「Crosbyで弁護士であるということの意味」を変えたと語る：弁護士本身就是プロダクトのディープユーザーであり、コードツールによって彼らのプロダクト直感がそのまま成果物としての修正、つまりPR（Pull Request、コードリポジトリへの修正リクエスト）になる。

Heidiのレーンはさらに平坦だ。共同創業者兼CEOのThomas Kelly医師は、かつてのような层层转述（层层转述）を「伝言ゲーム」と呼ぶ：新しいアイデアは発案者→プロダクトマネージャー→デザイナー→エンジニアの4手を経由し、リリース時には往々にして原型を留めず、しかも数週間かかる。今は問題を知る人が直接PRを出し、デザイナーとエンジニアの判断が必要な場面でのみ彼らを巻き込む。

Clayの採用基準も変わった：わざわざ「折腾好き（いじり倒したがり）」の候補者を選ぶ。基準は、アイデアを実際に動くバージョンまで自分で押し進める意志があり、ドキュメントや会議で止まらないこと。これらの企業にはCrosby、Harvey、Heidiのような垂直業界（法律、医療）プレイヤーもいれば、ClickHouse、Omni、Cognition、Commureなどのインフラ・エンジニアリング効率化の企業も含まれる。

なぜ「コード補完」だけでは足りないのか：誰もやりたがらない作業ごと切り取る

4社が提示した数字はバラバラに見えるが、実は同じことを指している：Claude Codeがやっているのは「エンジニアにより多くコードを書かせる」ことではなく、triage（振り分け）、テスト実行、マージといった「やると面倒、しかしやらないと崩壊する」作業を丸ごと切り取ることだ。

これまでのAIプログラミングツールと何が違うのか？従来のツールはIDE内で補完を手伝うところで止まっていたが、Claude Codeのやり方はMCP（AIに外部ツール/データベースの読み書きをさせるオープンインターフェース）というパイプをチームの既存GitHub、データベース、内部システムに直接繋ぐ。

人はもうコンテキストをコピー＆ペーストしてAIに渡す必要がなく、AIが自分でデータを取得し、書き終えたら書き戻す。この橋が無ければ、あの4つの数字は一つも生まれなかった。

Clay、Artemis Security、Omni、ClickHouseがそれぞれ数字を一つ報告しているが、突破口は全て同じ箇所にある：機械が引き受けるのは「必ずやる必要があるが誰もやりたくなかった」部分。下記3枚のカードは、この4つの数字の具体的な根拠を示している。

正直に言っておくべきことがある：上記の4つの数字は全て、Anthropicが自社の長文記事の中で顧客からの自己報告として転述したもので、現時点では独立した第三者による検証は確認されていない。引用する際は「顧客がそう言っている」として読む方が、「客観的な成績表」として読むよりも正確だ。

浮いた人手はどこへ行ったのか？ClickHouseで増えた分の機能は、同じ機能をもっと多く出したのではなく、「琐事（些細な作業）」に圧迫されていた人員が解放されたことで新たに着手されたものだ。自動化が消化したのは工数ではなく、組織の中で「誰も引き受けない真空」だ。真空が埋まると、プロダクト開発サイクル全体のボトルネックは「誰がコードを書けるか」から「誰が good ideaを持っているか」に移動する。

権限を委譲した後、誰が尻拭いする？

非エンジニアにPRを出させる本当の難所は「誰でもコードを触れる」ことではなく、「なぜこのコードを信じて本番に出せるのか」だ。これらの企業のやり方：レビューは入場ゲートではなく、セーフティネットだ。

前述したHeidiの「伝言ゲーム」は、本質的には伝達の歪みであり、Claude Codeはその中間チェーンを断ち切った。

放し飼いにしているように聞こえる。Anthropicの今回のインタビューで繰り返し出てくる3つの言葉こそが本質だ：自動テスト、PRレビュー、権限の段階分け。ガードレールを撤廃したのではなく、取り付け直した。

Artemis Securityの極端な週間処理量、Clayの自動triageは、みな同じロジックの延長線上にある：人はコードの品質をレビューし、機械はコードが動くか、誰が変更したか、どこに触れたかをレビューする。

Anthropicは各社の具体的なCI/CD（コード自動テスト + デプロイパイプライン）の構成を明かしていないが、「軽量だが追跡可能」を繰り返し強調している——レビューは必ず存在するが、エンジニアと非エンジニアの协作のボトルネックになってはいけない。

この分業はもう一つの副作用ももたらす：エンジニアの仕事が再定義された。弁護士、カスタマーサポート、デザイナーが直接フロントエンドを触れるようになると、エンジニアのコアバリューは「コードを書く」から「パイプラインを築く」へと移る——テストフレームワークの構築、権限ポリシーの策定、PRレビュー規則の作成。Heidiの言い方では「彼らの専門が必要な場所で彼らを招く」。非エンジニアが境界を外側に広げ、エンジニアが基盤を内側に引き締める。

コードは消耗品であり、資産ではない

5番目のルールは5つの中で最も常識外れだ：今日書いたコードは、基本的に数ヶ月後には捨て去るものとみなす。モデルは数週間ごとにイテレーションし、要求は日々変わるため、补丁式修补（パッチ的修正）（古いコードにパッチを当てて運用を続けること）は多くの場合、全体を書き直すより高くつく。

Anthropicのロジックは明白だ：基盤モデルは数ヶ月ごとに能力の跳躍を起こし、古いプロンプト、古いAPI呼び出し方式、古いコード組織構造はすべてともに減価する。丹精込めて磨き上げた関数でも、次世代モデルの前では3行で足りるかもしれない。古いコードにパッチを当てるのは、必ず陳腐化する足場にエンジニアリング人材を貼り付けるようなものだ。

これは過去10年のソフトウェアエンジニアリングの主流ナラティブも書き換えている。改変を控えめに、慎重にリファクタリングし、長期の保守性を追求する——これはエンジニアの昇格面接での模範回答だった。Claude Codeが推し出す逆のシナリオは：コードを消耗品として扱う。

プロトタイプ、公開、数ヶ月運用、モデルのアップグレードを確認、アップグレードされていたら書き直す。Anthropicはこのリズムを「Build for rebuilding」というルールに書き込んだ。

チームのスケジューリング優先度も変わる。Clayのバグ振り分け、Artemis SecurityのPR処理量は、コードベースの「半減期」が意図的に短縮されたことを意味する。新しいコードを読む時間に投資する方が、古いコードを維持するよりも価値がある。新人のオンボーディングの重心は「過去のしがらみを理解する」から「過去のしがらみを素早く捨てられる」に移るべきだ。

このルールが本当に地に足の着いたものかどうかをどう判断するか？今後3〜6ヶ月で、これらのスタートアップが「書き直し率」の指標を公開し始めるかを見ればいい——例えば四半期ごとに何行のコードが一行ずつ修正されるのではなく、全体として置き換えられたか。一方で、もしエンジニアリングブログが「書き直しによるリグレッションバグ」や「コンテキスト喪失」の増加を嘆き始めたら、「書き直しのための書き直し」がエンジニアリング規律の天井にぶつかったということで、ルールはこっそり割引かれるだろう。

読み終えてから判断を：まずチームアカウントを待つ

情報源には非エンジニア向けの完全なチュートリアルは無く，更多的是創業者たちが語るプロセスと文化だ——今すぐできるのは、あなたの身边で起きているかもしれない一つの事象を観察すること。

元报道の5原則は14社のスタートアップ向けであり、個人ユーザー向けの开箱指南ではない。「ダウンロード、インストール、初回通し実行」といった手順は書かれておらず、繰り返し强调されるのは一件事：コードを書いたことがない人でもPR——つまりコードベースに修正をプッシュして他者のレビューを仰ぐリクエスト——を出せるようにすること。Crosbyの共同創業者は率直に言っている、弁護士は今やプロダクト内で最も発言権を持つ人々であり、なぜなら彼ら自身がユーザーだからだ。

一般読者が今できる最初の事は、自分のチームに问うことだ：誰が最も问题に近く、しかしコードの外で阻まれているか？Heidiの創業者Kellyはかつてを「ある人がアイデアを出し、PMに渡し、PMがデザイナーに渡し、デザイナーがエンジニアに渡す——アイデアがリリースに辿り着く頃にはもう原型を留めていない」と表现した。もしこの事があなたの会社で耳に覚えがあるなら、次のステップに意味が出てくる。

次のステップは実は「Claude Codeを触ってみる」ことではなく、公式の発表を盯めること。元报道はAnthropicブログに掲載され、文末に5ルールとチェックリストをまとめたPDFがあると触れられ、原文には直接ダウンロードリンクが記載、タイトルは「The Claude Code guide for startups」。個人が使えるか、どう支払うか、情報源には具体的な経路が書かれていない——勘で推测せず、公式を待て。

この記事を読んで本当に持ち帰るべき判断は一つだけだ：ある企業が律师、医師、カスタマーサポートにPRを出させ始めた時、「エンジニアとは何か」という線引きを引き直さなければならない。ツールが要ではなく、その線を引き直すことこそが要だ。