コードの80%をAIに書かせている日本企業がある。PeopleXの現場から、導入の設計図を読み解いた

コードの80%をAIが書いている。その現場は、日本のスタートアップだった

プロダクトコードの80%がAI生成。この数字の出どころは、HR AIプラットフォームを運営するPeopleX（ピープルエックス）のCEO発信だ。

最初に聞いたとき、正直こう思いました。「80%？ さすがに盛ってない？」

私もCursor（カーソル）とClaude Code（クロードコード）を毎日使っている。体感では半分くらいはAIが書いてくれる感覚がある。とはいえ、プロダクト全体の80%となると話のスケールが違う。テストコードだけAIに任せれば数字は膨らむし、インフラ設定やマイグレーションを含めるかどうかでも結論が変わるもの。

だからこの記事では、80%の「内側」を掘ることにしました。

PeopleXが何をAIに任せて、何を人間に残したのか。ツール構成や導入の順番も含めて整理した。PR TIMESの企業情報と同社CEOのSNS発信を手がかりに再構成しました。注意点として、80%という数値は公式プレスリリースで裏付けられた数字ではなく、CEOの発信から広まった参考値です。この前提を踏まえたうえで読み進めてください。

ナギが先週書いたARI全社導入事例とも比較する。ARI（エーアールアイ）は上場企業として全社員にClaude Codeを配備した。スタートアップと上場企業。Cursorを選んだ会社とClaude Codeを選んだ会社。2社を並べれば、あなたのチームに近いパターンが見えてくるはずです。

本記事はAIエージェント実装シリーズ 技術編 第4回です。第1回のCursor CEO警告記事から始まった「ツール設計」テーマのシリーズで、今回はその実装がどう企業導入に結びつくかを掘り下げます。

PeopleXとは何をしている会社なのか。前提を3つ整理する

PeopleXはHR（人事）領域のAIプラットフォームを開発するスタートアップだ。採用・人材管理・組織分析をAI前提で設計している。

なぜこの会社が80%という数値を実現できたのか。そこには3つの前提条件がある。

前提1: プロダクトが複数ある

1つのアプリを作っているわけじゃない。HRプラットフォームとして複数のプロダクトを並行開発している。つまり80%は単一プロジェクトではなく、全プロダクト横断の数値として語られたもの。規模が大きいからこそ、定型実装の比率が高くなる構造を持っている。

前提2: エンジニア全員にAIツールを配備

Cursor、v0（ブイゼロ）、ChatGPT、GitHub Copilot（ギットハブ コパイロット）。さらにClaude Code。使えるツールを全員に開放する方針だ。「一部のエンジニアだけ試す」ではなく「全員が使い倒す」。ツールの選択権をエンジニア個人に委ねている点が特徴的。

前提3: MDファイル横断読み込みという運用設計

CursorがプロジェクトをまたいだMD（マークダウン）ファイルを横断的に読み込むことで、AIが文脈を維持する。これは単にツールを入れた結果ではない。コードの外にあるドキュメント群にもAIがアクセスできる環境を、意図的に設計したということ。

この3つ目は特に刺さりました。私も最近、自分のプロジェクトにCLAUDE.mdやDESIGN.mdを置いてAIにコンテキストを渡す運用を始めている。Cursor CEO警告記事でも書いた通り、「AIがコードを書ける」ことと「正しい文脈で書ける」ことはまったく別の問題。PeopleXはこの差を早い段階で理解していたのだと思います。

80%の内側を分解する。AIが得意な領域と人間が手放せない領域

結論から言えば、AIが量を担い、人間が判断を担う。この分業の境界線が実例から見え始めている。

80%をそのまま鵜呑みにはしません。参考値であることを前提に、それでもこの数値が示唆しているパターンを整理してみましょう。バイブコーディングを半年以上続けてきた経験と突き合わせて、私なりの分類をぶつけます。

AIが80%を担える領域

CRUDの定型実装が最大のボリュームゾーンだ。ユーザー登録、データ取得、一覧表示、更新処理。HRプラットフォームならこの種の機能が大量に必要になる。定型であるほどAIの出力品質は安定する。

UIコンポーネントの生成もAIが強い領域。v0はフロントエンドの部品を自然言語から生成してくれる。フォーム、テーブル、ダッシュボードのレイアウト。手で書くと半日かかるものが数分で形になるのは体験済みです。

テストコードの自動生成も大きい。既存コードを読ませて「このファイルのユニットテストを書いて」と伝えれば、カバレッジを一気に引き上げられる。退屈だけど重要な作業をAIに任せられるのは精神的にも助かる。

APIクライアントの実装も、仕様が明確であればAIの独壇場。外部サービスの接続コードをドキュメントから自動生成する。エラーハンドリングまで含めて書いてくれることも多い。

人間が手放せない20%

アーキテクチャ設計は今のところ人間の仕事として残る。どのサービスをどう分けるか。データの流れをどう設計するか。これはビジネス要件と技術制約の両方を理解したうえでの判断が必要になるからです。

セキュリティ設計はさらに手放せない。認証・認可の仕組み、データの暗号化方式。HRデータは個人情報の塊であり、ここをAIに丸投げするのは危険。Lovable製アプリを対象にした調査でも、10%以上にセキュリティ欠陥が見つかっている。AIが書いた「動くコード」がそのまま「安全なコード」ではないということだ。

ビジネスロジックの判断も人間の領域だ。「この条件でどう計算するか」の仕様自体を決める作業は、ドメイン知識なしにはできない。AIが書くのは「どう実装するか」。「何を実装するか」を決めるのは人間のまま。

コードレビューの最終判断。AIが書いたコードを本当にマージしていいか。この責任を取れるのは人間だけです。

ハマりポイントを一つ共有しておきます。私がCursorでUIを生成した時、見た目は完璧だったのにアクセシビリティが完全に抜けていたことがあった。aria属性ゼロ、キーボードナビゲーション不可。「動く」と「使える」はイコールじゃないんですよね。AIが生成した80%のうち、そのまま本番に出せるのは実質60〜70%。残りは人間が手直しする必要がある。この差を最初から計算に入れておくかどうかで、プロジェクトの見積もり精度が変わってきます。

Cursor+v0の組み合わせが効く理由。GUIとプロトタイピングの分業設計

Cursorはコードを書く場所。v0はUIの下書きを作る場所。この役割分担の設計がPeopleXの開発速度を支えている。

ツール選択は「好み」で語られがちです。PeopleXの事例を見ると、組み合わせに明確な設計意図がある。

Cursorの役割: エディタ内でコードを書き切る

CursorはGUIベースのコード補完とエディタ統合が強みだ。VS Code（ブイエスコード）の拡張として動作するため、既存の開発ワークフローを壊さずにAIを組み込めます。PeopleXが特に活用しているのは、プロジェクト横断のコンテキスト読み込み。

MDファイルに設計方針を書き、Cursorに読ませる。するとAIが「このプロジェクトのコード規約」を理解したまま補完してくれる。API認証方式の前提も維持される。

# DESIGN.md の例（筆者の実践から）

## API設計方針
- RESTful、リソース名は複数形
- 認証: Bearer Token（JWT）
- エラーレスポンス: RFC 7807 準拠

## コード規約
- TypeScript strict mode 必須
- 関数名: camelCase
- ファイル名: kebab-case

こういったファイルを1つ用意しておくだけで、Cursorの出力精度が目に見えて変わる。PeopleXはこれをプロジェクト横断で運用しているわけです。

v0の役割: UIプロトタイプを秒速で生成する

v0はVercel（バーセル）が提供するAIフロントエンド生成ツール。「ユーザー一覧テーブルでソートとフィルター機能付き」と書けば、React（リアクト）コンポーネントが出てくる。HRプラットフォームはダッシュボード・管理画面・入力フォームが山ほど必要になるジャンル。この種のUIを手で書いたら何日もかかるものが、v0なら数分で叩き台になります。

2つを組み合わせるワークフロー

v0でUIプロトタイプを生成、Cursorに持ち込んでバックエンドと接続、テストコードをCursorが生成。この3ステップが回り始めると、1機能のリリースまでの時間が大幅に短くなる。

私の体験を共有します。先月、社内のカスタマーサクセス用ダッシュボードを作った時に同じ流れを試しました。v0で管理画面のレイアウトを3パターン生成した。チームに見せて1つを選んでもらい、Cursorに取り込んでAPIを接続。2日で動くプロトタイプが完成した。手作業なら1週間は見ていた案件です。

注意点もあります。v0が出すコードはそのままでは本番品質に達しない場合がある。型定義が曖昧だったり、エラーハンドリングが雑だったり、パフォーマンス最適化が入っていなかったり。「v0で作って終わり」ではなく「v0で叩き台を作り、Cursorで仕上げる」という2段構成こそがポイントです。

ARI全社Claude Code導入との比較。2つの日本企業が示す設計思想の違い

PeopleXは「少人数で速く作る」。ARIは「全員でAIを使い倒す」。同じAI導入でも、設計思想がまるで違う。

ナギのARI記事で紹介された通り、東証グロース上場のARIは全社員にClaude Codeを標準装備した。PeopleXと並べると、組織フェーズで最適解が変わることがよく見えます。

比較軸	PeopleX	ARI
企業規模	スタートアップ	東証グロース上場
導入ツール	Cursor + v0	Claude Code
導入範囲	全プロダクト開発	全エンジニア＋全コンサル
AI活用の目的	少人数でのスケール	既存事業の効率化
ツールの性格	GUI補完型	ターミナル自律実行型
実績数値	コード80%がAI生成（参考値）	全社標準化（定量値は非公開）

ここから読み取れるのは、ツール選択が組織の性格を反映しているという事実です。

PeopleXがCursorを選んだのは、UIが多いHRプラットフォーム開発でGUI補完の恩恵が大きいからでしょう。一方ARIがClaude Codeを選んだ理由は、コンサルタントにもAIを使わせたいという全社方針がある。ターミナルベースのClaude Codeはコード補完だけでなく、ドキュメント生成やリサーチにも使える汎用性を持っている。

重要な違いをもう1つ。PeopleXの80%はプロダクトコードに限定された数字です。ARIは開発に加えて提案書やクライアント向け資料にもAIを活用しています。「何をAIで置き換えるか」の範囲定義が最初から異なるわけです。

どちらが正解かという話ではありません。自社のフェーズと目的で選択が変わる。Cursor CEO警告記事でも触れた通り、CursorはGUI補完型、Claude Codeはターミナル自律型。PeopleXがCursorを、ARIがClaude Codeを選んだ。事業特性に合った判断だと見ています。

あなたのチームはどのタイプか。導入判断の4分類チェックリスト

AIコーディングの導入は「ツールを入れれば終わり」ではない。チームの性格によって、入り口も出口も変わる。

PeopleXとARIの2事例から見えた導入パターンを4タイプに分類しました。自分のチームがどこに当てはまるか確認してみてください。

タイプA: スタートアップ型（PeopleXに近い）

エンジニア10人以下で、新規プロダクトの開発速度が命。このタイプなら、Cursor + v0で全員がプロトタイピングに参加する体制を推奨します。MDファイルで設計方針を共有し、AIにコンテキストを渡す運用を導入初日から設計すること。

注意すべきはセキュリティレビューの省略リスク。速度を優先するあまり、AIが書いたコードの脆弱性チェックを飛ばしがちになる。HRデータ・決済データ・個人情報を扱うなら、生成コードのセキュリティスキャンを自動化する仕組みを入れておくのが鉄則です。

タイプB: 上場企業・大手型（ARIに近い）

エンジニア50人以上で、既存システムの運用と改善がメイン業務。Claude Codeを少数チームで試験導入し、3ヶ月の定量評価を経て全社展開を判断するアプローチが現実的でしょう。

落とし穴は「上から入れろ」のトップダウン単独では定着しないこと。現場のエンジニアが「これは楽だ」と実感する成功体験を最初の1ヶ月で作ることが鍵になる。

タイプC: 非エンジニアチーム型

開発チームがいない。スプレッドシート連携やSlack Bot程度のツールは自前で作りたい。このタイプにはClaude Codeでターミナルから始めるのが合う。「何を作りたいか」を自然言語で伝える練習から入れば十分です。

ここで大事なのは「自分が理解できるコード」の範囲に留めること。動けばOKの精神は私も大好きですが、理解できないまま本番環境に乗せるのは話が別。CS出身として理解なき自動化は事故の温床になります。

タイプD: 「まだ様子見」型

AI導入の検討段階にいて、コストやセキュリティの懸念で踏み出せていない。まずはCursorの無料枠で自分のプロジェクトに触れてみてほしい。個人の体験が、組織の判断材料になるケースは驚くほど多い。

1年前に「まだ早い」と言っていた人が今焦っているのを、何社も見てきました。検討は今週で終わらせて、来週から触り始めるくらいがちょうどいいタイミングだと思います。

4タイプ共通の3原則

どのタイプにも当てはまる原則が3つあります。

1. ドキュメント先行で始める AIに文脈を渡すDESIGN.mdやCLAUDE.mdを整備してからツールを導入する。ドキュメントなしでAIを使うと、毎回同じ前提条件を説明する羽目になり、効率が上がらないまま挫折する。

2. 生成コードのレビュープロセスを初日から作る AIが書いたコードを必ず人間がチェックする仕組みを初日に決める。「あとでレビュー体制を作ろう」は永遠に来ない。PR（プルリクエスト）テンプレートに「AI生成コードの確認」チェックボックスを追加するだけでも効果がある。

3. 撤退基準を事前に設定する 3ヶ月で効果が測定できなければ一度撤退する。ダラダラ使い続けるのがコスト面でも組織文化面でも一番ダメージが大きい。逆に言えば、撤退ラインを先に引いておくことで「とりあえず全力でやってみよう」と踏み切れるようになります。

まとめ。80%は「ゴール」ではなく「地図」として読む

PeopleXの80%という数値は参考値だ。公式プレスリリースで裏付けられた数字ではありません。

それでも、この数値が示しているパターンには意味がある。何がAIで書けて、何が人間に残るのかの境界線が、日本企業の実例から見え始めたということです。

CRUD実装、UIコンポーネント、テストコード、APIクライアント。これらの定型実装は、今日からAIに任せられます。アーキテクチャ設計、セキュリティ判断、ビジネスロジックの仕様決定。この20%は当面、人間の仕事として残り続けるでしょう。

PeopleXの事例は「スタートアップが少人数で速く作る」型。ARIは「上場企業が全社でAIを標準化する」路線。正解はどちらか一方ではなく、自分のチームが今どのフェーズにいるかで入り口が変わるという話。

私自身、かつてプロのエンジニアとの実力差に打ちのめされた経験がある。あの頃の自分には到達できない領域があると認めた日のことを、今でも覚えています。でも今はAIがその差を埋めてくれている。PeopleXの80%は「凄腕エンジニアが宿る」感覚を、組織ごと実現しようとする挑戦だと思っています。

あなたがタイプAでもBでもCでもDでも、始めるなら今日がいちばん早い。明日には新しいツールが出て、来月にはまた地図が書き変わるのだから。

次回はPeopleXとARIの「プロンプト設計」を掘り下げる予定です。80%のコードを生成するために、人間がAIにどんな指示を出しているのか。「指示の品質」が開発速度を決めるという話を書きます。

---

参照元

• PR TIMES PeopleX「Cursor＋v0でコードの80%をAI生成」発表 ↗
• 日経 PeopleX関連報道 ↗
• 日本のIT企業が全社員にClaude Codeを配った
• Cursor CEOが「土台が揺らぐ」と警告した記事

---