Ramp CPO Geoff Charles：「ログインは失敗の証拠」──$32B企業のAIネイティブ組織論
この記事の要約
Ramp CPO Geoff Charlesが語るAIネイティブ組織の全貌。「ログインは失敗の証拠」という逆説、Inspect（PR30%自動生成）、「フィードバックではなくプロセスを直せ」というリーダーシップ論、「3ヶ月＝3年」のプランニング哲学まで。
この記事は Inside Ramp, the $32B Company Where AI Agents Run Everything | Geoff Charles の内容を基に作成しています。
将来のプロダクトで、ユーザーがログインする時点で、そのプロダクトは失敗している。
"Fundamentally, a login in your product in the future I think is going to be a failure."
Ramp CPOのGeoff Charlesは、Peter Yangとの対談でこう言い切った。FacebookやNetflixが「エンゲージメント最大化」を追求するのとは正反対だ。Rampはアプリ内滞在時間を減らすことをKPIにしている。
"We track the amount of time you spend in Ramp and how we can actually reduce that time as much as possible—which is by the way the opposite of how many PMs are trained."
「Rampでの滞在時間を測り、いかに減らせるかを追求している──多くのPMが教わるやり方とは正反対です」
なぜか。AIが顧客の経費処理・請求書管理・調達承認を代行するなら、ユーザーがアプリを開く必要はない。経費が自動で処理され、異常だけが通知される。それがRampの目指す世界だ。
本記事の表記について
- 金額の日本円換算は1ドル=150円で計算しています
- 下線付きの用語にカーソルを合わせると解説が表示されます
- Rampは法人カード・経費管理・請求書支払い・調達・旅行を統合するフィンテック企業（評価額320億ドル、約4.8兆円）
- Peter Yangは元Meta/Twitch/Reddit PM、ニュースレター「Behind the Craft」（読者14万人超）を運営
この記事でわかること
- 「ログインは失敗の証拠」: B2BプロダクトのKPIを根底から問い直す逆説
- Inspect：PRの30%を自動生成: PM・デザイナーも本番コードを出荷する仕組み
- 「フィードバックではなくプロセスを直せ」: AI時代のリーダーシップの再定義
- 「3ヶ月あれば3年分できる」: プランニングの根本的転換
基本情報
| 項目 | 内容 |
|---|---|
| ホスト | Peter Yang（元Meta PM、Behind the Craft運営） |
| ゲスト | Geoff Charles（Ramp CPO） |
| カテゴリ | AIネイティブ組織・プロダクト開発 |
| 難易度 | 中級 |
| Geoff Charlesの経歴 | |
|---|---|
| 学歴 | コロンビア大学（理学士） |
| 前職 | Oliver Wyman（コンサルタント）→ LendUp → Mission Lane |
| Ramp | CPO（プロダクト・オペレーション・サポート統括） |
| Ramp基本データ（2025年） | |
|---|---|
| 評価額 | 320億ドル（約4.8兆円） |
| 年間売上 | 10億ドル超 |
| PM人数 | 25名 |
| AIコード生成比率 | 50%（2026年初頭、目標80%） |
| Inspect PR比率 | merged PRの30% |
Rampのツールエコシステム全体像「コードのコストはゼロになった」：すべての前提
Geoffの議論を理解するには、まず出発点を押さえる必要がある。
| 時期 | AIが書くコードの割合 |
|---|---|
| 2025年12月 | 30% |
| 2026年初頭 | 50% |
| 2026年3月（目標） | 80% |
Geoffはこの状態を「コーディング脱出速度（coding escape velocity）に達した」と表現する。コードの生産コストが事実上ゼロに近づいた。
この前提が全てを変える。コードが無料なら、PMが仕様書を書く意味は薄れる。デザイナーが直接プロダクトを作れる。リーダーの仕事は「フィードバック」から「プロセス設計」に変わる。
"My job is to automate my job and our all our jobs is to automate our jobs."
「私の仕事は自分の仕事を自動化すること。全員の仕事は自分の仕事を自動化すること」
AIに質問するな、ゴールを伝えろ
Rampが社内でAI活用を教えるとき、最初に伝えるのがこれだ。
"You ask a question, but you have a goal. So sometimes you ask the question and you get the result, but you should just tell AI what your goal is. And you'll actually be surprised at the questions that the AI can actually ask themselves to get to the goal."
「あなたは質問をするが、本当はゴールがある。AIにはゴールを伝えてください。AIが自ら問いを立てて、そのゴールにたどり着こうとすることに驚くはずです」
「プロンプトは質問文」という初学者の誤解を覆す。質問を投げるのではなく、達成したい状態を伝える。AIが必要な質問を自分で立てる。
VoCエージェント：8日分の仕事を8分で
55,000社・100万人のユーザーから届くフィードバック。Gong録音、Salesforceメモ、アプリ内アンケート、サポートチケット。人間が処理するのは不可能だ。
RampのVoice of Customerエージェントは、90日分のデータから8分で主要課題を特定する（従来は8日）。根拠となるチケット・チャットログへのリンクも自動提供。
ただしPeter Yangが「ロードマップが自動で作られるんですね」と言ったとき、Geoffはすぐに修正した。
「あくまで文脈を提供するだけ。何を作るかの判断は、まだあなた（PM）がする」
Rampのプロダクト開発プロセスInspect：PRの30%を自動生成、PMも本番コードを出荷
5分でPRを提出するデモ
動画内でGeoffは実際にInspectをデモした。
依頼内容: 「APテーブルの上に4つのメトリクスを表示：過去の未払い、0〜30日、30〜90日、未払い総額」
5分後: フロントエンド・バックエンド両方の実製品コードが生成され、既存デザインコンポーネントを自動参照し、PRを作成して提出可能に。
InspectによるPM実装デモ（08）商用ツールではなく自社ビルドした理由
RampはGitHub CopilotではなくInspectを自社開発した。理由は「統合の深さ」。InspectはModal上のサンドボックスVMで動作し、DB・CI/CDパイプライン・監視システム・フィーチャーフラグへのフルアクセスを持つ。テスト実行、監視ダッシュボード確認、コードレビュー参加まで自動化されている。
さらにInspectはエスカレーション対応にも使われている。障害やサポートチケットが発生すると、Inspectが自動でコードを分析し、修正PRを作成する。新規開発だけでなく、保守・運用も自動化の対象だ。
スペック文書はAIが読んでいる
「PMはスペック文書に誇りを持つが、実は今はエンジニアではなくAIがそのスペックを読んでいる」
だからスペックは「人間向けドキュメント」ではなく「AIへのプロンプト」として設計すべきだ。Rampの「Claudeスキル」は、会話型で20の問いを立て、トレードオフを明示してから実装に入る。
リリースを自動化する：Ramp Releasesボット
記事の多くの読者が見逃しがちだが、Rampはリリースプロセス全体も自動化している。
「Ramp Releases」ボットは、リリース時に以下を全自動で生成する：
- ヘルプセンター記事
- 社内イネーブルメント資料
- Slackへのアナウンスポスト
コードの複雑度に基づいて自動ルーティングされ、シンプルな修正はそのまま出荷。複雑な変更は段階的に展開（Dogfooding → Alpha → Beta → GA）。
「フィードバックではなくプロセスを直せ」
対談で最もリーダーシップ論として鋭かったのがこれだ。
"Giving feedback to the person so that they can just fix it, that's a one-time band-aid. What you want to do is figure out within the process what broke down and fix that process so that next time you never have that feedback again."
「人にフィードバックして直してもらうのは一時的な絆創膏だ。プロセス上の何が壊れていたかを突き止め、次回は同じフィードバックが不要になるようプロセスを直す」
例：CTAボタンの位置を10回指摘するのではなく、デザインシステムのプロンプト・スキルに「CTAは上部に配置」を組み込む。リーダーの仕事は個人へのフィードバックからプロセス設計に変わる。
"Management is probably dead."
「マネジメントはおそらく終わりだ」
これは「チームリーダーが不要」という意味ではない。「スキル変化の中間管理」が難しくなるという警告だ。Geoff自身も「ミーティングを大幅削減し、夜と週末にAIを自ら学んでいる。今こそIC（個人貢献者）モードに戻る時期」と宣言した。
AI活用組織フレームワークの説明（17）PMとエンジニアの役割逆転：誰が本当に「終わる」のか
Peter Yangが「PMは終わりですか？」と問いかけた。Geoffの回答は意外だった。
"I thought to myself it's over for the engineer—for most engineers."
「心の中で思ったのは、エンジニアこそ、多くのエンジニアにとっては終わりが来るのではないかと」
コードが自動生成されるなら、「コードを書く」だけのエンジニアは最も脅威にさらされる。だが──
"I think an engineer now is managing hundreds of thousands of agents and they can actually scale their impact."
「優れたエンジニアは何十万ものエージェントを管理し、自分のインパクトをスケールさせる存在になる」
PMもエンジニアも、両者とも役割変容が必要。コードを書くだけのエンジニアは危ない。スペックを書くだけのPMも危ない。生き残るのは「ビルダー型PM」と「エージェント管理型エンジニア」だ。
従来PMとAI時代のPMの比較L0〜L3フレームワーク：全社員をL3に引き上げる
| レベル | 定義 | Rampでの扱い |
|---|---|---|
| L0 | ChatGPTを時々使う | 採用対象外。既存社員なら去ってもらう |
| L1 | カスタムGPT作成、Claude Code基礎 | L2への引き上げが目標 |
| L2 | 自分の業務を自動化するアプリを構築済み | L3への引き上げが目標 |
| L3 | システムビルダー。組織全体に影響力 | 目指すべき状態 |
全社員L3への施策
- トークン制限なし: 予算制限を設けない
- 使用量ダッシュボード: 全社員のAI使用量を可視化し、低い場合はリーダーが介入
- 全社集会でのショーケース: 非エンジニアの成果物を表彰
- オフィスアワー: AI伝道師がセットアップをサポート
- 採用要件: 新入社員は全員AI活用の実演が必須
"If you're not a self-starter and you don't have that growth mindset, it's going to be very hard to train you out."
「自走できず成長マインドセットがなければ、その状態から変えることは非常に難しい」
「3ヶ月あれば3年分できる」
"Within 3 months, you can do what you can do in 3 years now. So 3 months is actually a really long time."
「今や3ヶ月あれば、以前なら3年かかったことができる。だから3ヶ月は実はとても長い時間です」
AIが加速させる世界では、長期計画の精度が著しく低下した。Rampのプランニング目的は3つだけ：
- 戦略のアライメント: どの問題に集中し、どれを手放すか
- チームのコミットメント: 責任の明確化
- セールスへの情報提供: 顧客との会話を支える基本ロードマップ
それ以外の「計画のための計画」はAIが不要にした。
「ソフトウェアは死んだ、全てコワーカーになる」
対談の終盤、Geoffは最も大胆な宣言をした。
"Fundamentally software is dead. It's all going to be like co-workers."
「根本的にソフトウェアは死んだ。全ては『コワーカー』になる」
テーブルとチャートのUIから、会話型のコワーカーへ。Ramp自身が「ログイン時間の削減」をKPIにしているのは、この哲学の実践だ。
だが「ソフトウェアが死ぬ」世界で何が重要になるか。ドメイン専門知識だ。AIが顧客の仕事を代行するなら、開発者はCPA（公認会計士）並みの会計知識を持つ必要がある。経費の文脈、会計処理のルール、税法の基礎──これらを理解しなければ、AIに正しい「ゴール」を伝えられない。
採用面接で「プロダクトを見せろ」
Rampの採用面接には、他社にない専用セッションがある。
"You're going to show me a product that you've built and you tell me exactly how you built it."
「あなたが作ったプロダクトを見せてください。どう作ったか正確に説明してください」
ポートフォリオではなく、動くプロダクトの実演。AIを使って何を作れるかを、面接の場で証明する。L0の人材はこの段階でフィルタされる。
"Once you get that aha moment—that red pill—there's no coming back."
「あのアハ体験を──レッドピルを飲んだ瞬間を──経験したら、もう戻れない」
Geoffと Peter Yangの対談（03）よくある質問（FAQ）
Q1. Inspectは外部から使えますか？
現時点ではRampの社内ツール。ただし自社ビルドを選んだ理由（DB・CI/CD・監視システムへのフルアクセスが必要）を考えると、外部提供時には統合の深さが課題になる。
Q2. AIがコードを書くと品質は下がらない？
複雑度ベースの自動ルーティング + 段階的リリース（Dogfooding→Alpha→Beta→GA）+ 自動テストで品質を維持。シンプルな修正は自動承認、複雑な変更は人間レビュー。
Q3. 「ログインは失敗」なら、UIは不要になる？
管理画面としてのUIは残る。だが「毎日ログインして経費を確認する」体験は消える。AIが代行し、異常だけを通知する。滞在時間の短縮＝プロダクトの成功。
Q4. L0の社員はクビになるのか？
Geoffは「L0はRampでは不適合」と明言。採用時にAI活用の実演を求め、既存社員にも成長を求める。自走できなければ「去ってもらう」という姿勢。
Q5. 「3ヶ月＝3年」は誇張では？
Rampの実績：25人のPMで500以上のフィーチャーを2025年に出荷。AIによる開発速度の加速を考えると、3ヶ月サイクルでも「やりすぎ」になりつつあるとGeoffは示唆。
Q6. PMとエンジニア、どちらが危ない？
Geoffの回答は「両方」。コードを書くだけのエンジニアも、スペックを書くだけのPMも危険。生き残るのは「エージェントを管理するエンジニア」と「自らビルドするPM」。
まとめ
主要ポイント
- 「ログインは失敗の証拠」: B2Bプロダクトの成功指標は滞在時間の最小化。AIが業務を代行する世界では、ユーザーがアプリを開かないことが最高の体験
- 「フィードバックではなくプロセスを直せ」: リーダーの仕事は個人への指摘から、プロセス設計への移行。同じフィードバックを二度出さない仕組みを作る
- 「3ヶ月あれば3年分できる」: 長期計画は精度が落ちた。短サイクルで正確に実行する組織が勝つ。全社員をL3に引き上げ、AIを前提とした組織設計が必要
次のステップ
- 自社プロダクトの「ログインの必要性」を問い直す──AIが代行できるフローはないか
- リーダーとして「繰り返しているフィードバック」をリストし、プロセスに組み込めないか検討する
- チームのAI活用レベルをL0〜L3で評価し、L1→L2の具体的な成功体験を設計する
関連記事
参考動画
この記事は以下の動画を参考に作成しました：
本記事はネクサフローのAI研究シリーズの一部です。
この記事の著者
中村 知良
代表取締役
早稲田大学卒業後、ソフトバンク株式会社にてAI活用やCEO直下案件のプロジェクトマネージャーに従事。その後、不動産スタートアップPit in株式会社の創業、他スタートアップでの業務改善・データ活用を経験後、2023年10月、株式会社ネクサフローを創業し代表取締役CEO就任。
