「まだ存在しないモデル」のために作る:Ramp CTOが語る、人間よりも自動化がエージェントを起動する世界
Claude公式の対談シリーズ「Office Hours with Boris Cherny」、今回は法人カード・支出管理のフィンテック企業Rampの回です。CTOのRahul Sengottuvelu氏とスタッフエンジニアのAustin Ray氏が登場。Rampでは今、エージェントセッションの起動数は、人間よりも自動化のほうが多いという段階に到達しています。エピソードのタイトルは「Building for the model that doesn't exist yet(まだ存在しないモデルのために作る)」——その設計思想を読み解きます。
Fableの初仕事は「実証的に検証できる難問」
Sengottuvelu氏がClaude Fableを手にして最初にやったことが、いかにもエンジニアリングリーダーらしい実験です。「自分が読んでいない大きなコードで、プロダクト外(CI領域)で、実証的に検証できるユースケース」を選び、テストスイートの改善をFableに書かせて数週間シャドー運用——結果、既存実装より一貫して高速でした。さらに巨大なモノリシックPythonコードベースの「インポートサイクルを全部直せ」「アプリの起動を遅延読み込みにしろ」という深い難題も投げ、多くのコードが実際にマージされたといいます。狙いは明確で、モデルが壊れる境界を把握しておけば、次のリリースが出た瞬間に再挑戦すべき問題が分かるから。
Cherny氏側の実例も強烈です。Claudeがサブエージェント群をオーケストレーションする「ダイナミックワークフロー」(テスト時計算の新形態)にCI最適化を任せたところ、P50を18分から6分へ短縮。しかもコードを本番投入した後、自分でルーチンを仕込んで翌日に再実行をスケジュールし、実データを取り、数日間これを繰り返して最後にチャートを見せてきた、という自律ぶりです。
ループとダイナミックワークフロー:横に切るか、縦に切るか
対談で整理された概念モデルが実用的です。ループは「反復作業」——PRの子守り、CIの修正、リベース、毎日走るデッドコード削除のような、ステップが決まった仕事。ダイナミックワークフローは「動的な仕事」——システム最適化のように、次のステップが事前に分からない仕事。
組織への当てはめ方も示されます。ループは横のスライス——全エンジニアが毎日やる1タスクを切り出してルーチン化する。一方、縦のスライスの例がClaude Tagによる実験の一気通貫です:実験を作り、PRを投入し、自分にリマインダーを仕込み、露出のバランスを監視し、数週間後に勝ちバリアントの出荷PRまで上げる——人間が関与したのは最初の依頼とPRの承認だけ。
「モデルがハーネスを追い越す」から、足場は作りすぎない
Rampの設計思想の核心がここです。モデルは改善し続けるのだから、今のバージョンのために作り込むべきではない。実際、ハーネス(エージェントの足場)を作っては、モデルが追い越すたびに足場を撤去することを繰り返してきたといいます。方向性は一貫していて、モデルにより多くのツール・コンテキスト・裁量を与え、「同僚のように扱える」状態を目指す——「例外が出てるみたいだから調べてくれる?」と話しかけられるように。Ray氏はこれを「ベロシティの賭け」と表現します。今を動かすための作り込みはすぐ技術的負債になる。少し先を狙うほうが、同じリソースで遠くまで行ける、と。
プロンプトの哲学も明快です。目指すのは「iPhone体験」——テキストボックスに「何をしてほしいか」だけを宣言的に書き、「どうやるか」は指示しない。そして評価は集計ベンチマークより個別トレースの精読を重視。「このシナリオでモデルが実行すべきだった正しいコマンドは何か、なぜそこに到達しなかったのか——コンテキスト不足か、ツール不足か」を追い、プロンプト・ツール・スキルで正しいトレースへ形作っていく。今動かなければ?——「指数関数を信じて、出荷して待て」。
もちろん放任ではありません。スタックの各層に多層防御を実装し、読み取り専用のサービスキーと最小権限の原則で「必要なものは与えるが、それ以上は与えない」。特筆すべきは、このインフラを構築したのがセキュリティチーム自身で、ネットワークアクセスポリシーの設計から鍵の発行まで担い、しかも彼ら自身がエージェントのヘビーユーザーだという点です。
社内基盤:Glass、Inspect、On-call Assistant
Rampの内製ツール群は、エージェント活用の解像度が高い実例です。
Glass:非技術職のホームベース。コードを見せずに、コーディングエージェントと日常的にやり取りできる場所。「全員がこの力にアクセスすべき。ただし、その人がいる場所で会う」という思想
Inspect:バックグラウンドエージェントAPIの上に立つ「デジタルの同僚」。GitHub、Linear、Slack、Datadog、Sentryなど、Rampのビルダーが持つツール一式にアクセスでき、サポートチケットの解決からSentryエラーの調査まで頼める。普及の主経路はSlackの@メンション——誰かのスレッドに@Inspectで呼ばれて働く姿を見た人が「え、それ頼めるの?」と気づいて広がった。全PRに専用VMが付き、セッションはリンクベースで引き継ぎ・共同作業が可能なマルチプレイヤー設計
On-call Assistant:Claude Code上で動く「AIのSRE」。ローカルで実証してからスキル・MCP・プロンプトを整え、ガードレール付きコンテナにパッケージ化。エンジニアにアサインされる全インシデントで自動起動し、インシデント用Slackチャンネルに精度の高い根本原因分析を返す。Ray氏いわく、Claude Codeという実行可能ファイルをUnix哲学で組み合わせて作れるものの幅は「とんでもない」
そして冒頭の事実に戻ります——Inspectのセッションは、今や人間よりも自動化(スケジュールや外部システムのトリガー)から始まるほうが多い。組織面も興味深く、これらは中央のAIチームの成果物ではなく驚くほど分散的に生まれています。競合するハーネスの並立も歓迎し、プラットフォームチームは「他チームが上に構築したくなる良い製品を作る」ことで選ばれる、という構図です。
トークン予算を課さない経済学
コスト管理の思想も型破りです。Rampは個人のトークン・ドル支出に上限を課しません。「誰もが、望むレベルの知能に制限なくアクセスできるべき」——その代わり、デフォルト設計、バッチ/フレックスAPIの活用、人間が関与しない自動化への軽量モデル適用で、システム側の効率を作り込む。
突出した高額利用者には「何やってるの?」と声をかけ、プラットフォーム化できるなら一緒に広げる。根底にあるのは、「トークン1ドルが1ドル超を生むプラスROIの領域では、コスト最小化はむしろ間違い」という判断と、知能の価格は下がり続けるという見通し。全員が早くからフロンティアの知能を難問に「汗をかかせる」経験を積むこと自体が投資だ、という考え方です。
CTOへの助言:「現在のスナップショット」ではなく「変化率」を見よ
締めの助言がエピソードタイトルの回収になっています。モデルの現状に注目が集まりがちだが、本当に見るべきはこの数年の変化の速度。そこに注目すれば、知能と裁量が上がり続けるパターンが見えてくる。だからRampは3〜6ヶ月先に来るもののために作る——今日利用可能なものに合わせて作っていたら、出荷する頃にはもう手遅れかもしれないから、と。
まとめ
Office Hoursシリーズ3社を並べると、それぞれの主題がきれいに分かれます。DoorDashは「プロセスの再発明」、Spotifyは「基盤投資の複利」、そしてRampは「変化率を前提にした設計」。足場は作りすぎず、トレースを読み、権限は最小に、予算は課さず、3〜6ヶ月先のモデルに賭ける——一見矛盾しそうな要素が、「モデルは指数関数的に良くなる」という一つの前提で整合しています。エージェント基盤を内製しようとしている技術チームには、GlassとInspectとOn-call Assistantの三層構成だけでも持ち帰る価値のある回です。
INNOOV株式会社について
この記事は、AtlassianやIntercomなどのSaaS導入支援と、AIを活用した業務プロセス改善を行うINNOOV株式会社がお届けしました。「自社でもこんな仕組みを作ってみたい」「ツール導入を相談したい」という方は、お気軽にお問い合わせください。