Ramp CPO Geoff Charles：「ログインは失敗の証拠」から読むAI組織設計

“

この記事は Inside Ramp, the $32B Company Where AI Agents Run Everything | Geoff Charles の内容を基に作成しています。

このページは、Rampの会社規模やAI導入比率を追う速報ではありません。Peter YangとRamp CPO Geoff Charlesの対談を、B2B productがAI worker化するときの組織設計メモとして読み直します。

入口に置きたい問いはひとつです。ユーザーが毎回ログインし、画面を探し、判断を手で運んでいるなら、productは本当に仕事を肩代わりできているのか。

“

"Fundamentally, a login in your product in the future I think is going to be a failure."

Geoffは、対談の冒頭で「ログインは失敗の証拠」と言い切りました。これは挑発的な未来予想ではなく、B2B productの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が経費処理、請求書管理、購買承認を肩代わりするなら、利用者が毎日画面に入ること自体が摩擦になります。重要なのは機能数ではなく、どの判断を人に残し、どの作業をagentに任せるかです。

---

この記事でわかること

1. 「ログインは失敗の証拠」: B2B productの成功指標を、利用時間ではなく摩擦削減で見る
2. Inspect / VoC / release bot: agentを開発前後のどこに置くか
3. 「フィードバックではなくプロセスを直せ」: リーダーの仕事を、指摘から仕組み作りへ移す
4. L0-L3フレームワーク: 全員をAI利用者ではなくsystem builderに近づける

基本情報

---

この対談を何として読むか

この対談の価値は、Rampがどれだけ速い会社かを眺めることより、AI agentを前提にしたとき、product teamの仕事の置き場所がどう変わるかを考える材料にあります。

特にstartupが持ち帰りやすいのは次の4点です。

---

コードコストが下がったとき、何がボトルネックになるか

Geoffの議論を理解するには、まず出発点を押さえる必要があります。対談では、Ramp社内でAIが書くproduction codeの比率が急速に上がり、coding escape velocityに近づいたという説明が出てきます。

ここで大事なのは、数字そのものよりも役割の変化です。コード生成が安くなるほど、PMが仕様書を書くだけで止まる意味は薄れます。デザイナーやoperationsの人も、動くprototypeを作って仮説を試せる。リーダーの仕事は「誰かに直してもらう」ことから「次に同じ指摘が出ないprocessを作る」ことへ移ります。

“

"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エージェント：人手の集計を判断材料に変える

Gong録音、Salesforceメモ、アプリ内アンケート、サポートチケット。顧客接点が増えるほど、feedbackは増えても、product decisionに届く文脈は薄まりがちです。

RampのVoice of Customerエージェントは、90日分のデータから8分で主要課題を特定する（従来は8日）。根拠となるチケット・チャットログへのリンクも自動提供。

ただしPeter Yangが「ロードマップが自動で作られるんですね」と言ったとき、Geoffはすぐに修正した。

“

「あくまで文脈を提供するだけ。何を作るかの判断は、まだあなた（PM）がする」

---

Inspect：PRの30%を自動生成、PMも本番コードを出荷

5分でPRを提出するデモ

動画内でGeoffは実際にInspectをデモした。

依頼内容: 「APテーブルの上に4つのメトリクスを表示：過去の未払い、0〜30日、30〜90日、未払い総額」

5分後: フロントエンド・バックエンド両方の実製品コードが生成され、既存デザインコンポーネントを自動参照し、PRを作成して提出可能に。

商用ツールではなく自社ビルドした理由

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）。

---

Dated Snapshot（対談・記事作成時点の時点情報）

ここから先の数値は、組織設計の読み方を支える時点メモです。Rampの恒久的な会社情報として固定せず、必要に応じて元動画や公式情報を見直してください。

---

「フィードバックではなくプロセスを直せ」

対談で最もリーダーシップ論として鋭かったのがこれだ。

“

"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（個人貢献者）モードに戻る時期」と宣言した。

---

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」と「エージェント管理型エンジニア」だ。

---

L0〜L3フレームワーク：全社員をL3に引き上げる

全社員L3への施策

1. トークン制限なし: 予算制限を設けない
2. 使用量ダッシュボード: 全社員のAI使用量を可視化し、低い場合はリーダーが介入
3. 全社集会でのショーケース: 非エンジニアの成果物を表彰
4. オフィスアワー: AI伝道師がセットアップをサポート
5. 採用要件: 新入社員は全員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つだけ：

1. 戦略のアライメント: どの問題に集中し、どれを手放すか
2. チームのコミットメント: 責任の明確化
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."

「あのアハ体験を──レッドピルを飲んだ瞬間を──経験したら、もう戻れない」

---

よくある質問（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年」は誇張では？

対談内では、少人数のPM teamで多数のfeatureを出荷している例が語られています。AIによる開発速度の加速を考えると、3ヶ月サイクルでも「やりすぎ」になりつつあるとGeoffは示唆。

Q6. PMとエンジニア、どちらが危ない？

Geoffの回答は「両方」。コードを書くだけのエンジニアも、スペックを書くだけのPMも危険。生き残るのは「エージェントを管理するエンジニア」と「自らビルドするPM」。

---

まとめ

主要ポイント

1. 「ログインは失敗の証拠」: B2Bプロダクトの成功指標は滞在時間の最小化。AIが業務を代行する世界では、ユーザーがアプリを開かないことが最高の体験
2. 「フィードバックではなくプロセスを直せ」: リーダーの仕事は個人への指摘から、プロセス設計への移行。同じフィードバックを二度出さない仕組みを作る
3. 「3ヶ月あれば3年分できる」: 長期計画は精度が落ちた。短サイクルで正確に実行する組織が勝つ。全社員をL3に引き上げ、AIを前提とした組織設計が必要

次のステップ

• 自社プロダクトの「ログインの必要性」を問い直す──AIが代行できるフローはないか
• リーダーとして「繰り返しているフィードバック」をリストし、プロセスに組み込めないか検討する
• チームのAI活用レベルをL0〜L3で評価し、L1→L2の具体的な成功体験を設計する

---

関連記事

---

参考動画

この記事は以下の動画を参考に作成しました：

• Inside Ramp, the $32B Company Where AI Agents Run Everything | Geoff Charles - Peter Yang

---

本記事はネクサフローのAI研究シリーズの一部です。