Ramp Cowork連携で購買・経費の予算超過を定期監視する

Ramp×Coworkで自動化できる範囲

Rampの公式Connectorは、取引・立替経費・請求書・購買注文(purchase orders)・法人カード・取引先を照会・分析するためのツールです。公式に示されている利用例は読み取り操作のみで、承認や新規作成のような書き込み操作は挙げられていません(詳しくはClaude Ramp連携の始め方)。したがって、Ramp×Coworkで自動化できるのは「発注申請の承認そのもの」ではなく、予算超過や滞留を検知して、承認担当者に判断材料を渡すところまでです。実際の承認・却下は、引き続きRampの画面で人が行います。

この線引きは弱点ではありません。Cowork公式の安全ガイドも、金銭のやり取りや取り消しにくい操作は自動化に含めず、読み取りと要約で完結する軽いタスクから始めるよう案内しています。承認権限をClaudeに渡さない設計のまま、「見落とし」を減らす用途に絞るのが、Rampのような財務データを扱うConnectorとの現実的な付き合い方です。

前提条件

始める前に、次の2点を用意します。

• Ramp Connectorが接続済みであること(個人アカウントかTeam/Enterprise組織のOwnerによる有効化が前提です)
• CoworkのScheduled Tasksが使えるプラン(Pro・Max・Team・Enterpriseいずれかの有料プラン)

Scheduled TasksはRampのようなConnector経由のデータ収集・要約に向いており、ローカルファイルへの依存が無い分だけ、クラウド上で完結して安定して動きます。

監視タスクを作成する手順

1. サイドバーの「Scheduled」を開き、「New task」→「Set up manually」を選ぶ
2. タスク名と、監視内容を書いたプロンプトを入力する
3. 承認モードを選ぶ(次節で扱う)
4. 実行頻度を選ぶ(毎時・毎日・毎週・平日のみ・手動実行)
5. 「Save」で保存する

「New task」から「Create with Claude」を選び、Claudeとの対話で作成する方法もあります。この場合はClaudeが確認の質問を挟みながら、最後にタスク名・頻度・内容を提示し、「Schedule」をクリックして確定します。

監視パターンの実例

Rampの公式利用例(部門予算の監視・未処理請求書の追跡)を、そのまま定期実行の依頼文に落とし込むと次のようになります。

• 部門予算の超過検知: 「毎週月曜9時、Rampで先週の部門別支出を確認し、月間予算の80%を超えている部門があれば部門名と超過額をSlackの#financeに投稿して」
• 滞留した購買注文の洗い出し: 「毎朝8時、Rampの購買注文のうち5営業日以上ステータスが動いていないものを一覧にして担当者名つきで報告して」
• 高額な未処理請求書の通知: 「毎日17時、Rampで1万ドルを超える未処理の請求書があれば件数と合計金額を要約して」

いずれも「しきい値」と「通知先」を具体的に書くほど、実行のたびに同じ基準で判定されます。しきい値を曖昧にすると、実行ごとに拾う件数がぶれます。

頻度は監視対象の重さに合わせて選びます。部門予算のように月単位で動く数字を毎時チェックしても差分は出にくく、無駄な実行が積み重なるだけです。逆に高額請求書のように支払期限が迫る性質のデータは、毎日か平日のみの頻度で拾うほうが実務に合います。1つのScheduled Taskには1つの頻度しか設定できないため、性質の異なる監視は別タスクに分けます。

Vendor Analysisスキルと組み合わせた月次レビュー

Ramp連携には「Vendor Analysis」という専用スキルが用意されています。ベンダー別の支出データを分析し、接続済みの別システムへ書き出す用途向けのスキルです。Scheduled Tasksと組み合わせると、「毎月1日、先月のベンダー別支出をVendor Analysisスキルで分析し、前月比で20%以上増えたベンダーがあれば理由の推測を添えてレポート化して」のような月次レビューを定型化できます。

日次・週次の監視が「異常の早期発見」を担うのに対し、月次のベンダー分析は「支出構造そのものの変化」を追う役割です。両方を別タスクとして走らせておくと、短期の見落としと中期のトレンド変化を別々の頻度でカバーできます。特定のベンダーへの支出が数か月連続で増え続けているのに、日次・週次の監視では単月のしきい値を超えないケースもあります。月次のベンダー分析は、こうした緩やかな変化を拾うための頻度だと位置づけると役割分担がはっきりします。

承認モードをどう選ぶか

CoworkにはManually approve・Automatically approve・Skip all approvalsの3つの承認モードがあります。公式に示されている利用例は照会・分析のみで、Rampへの書き込み操作は挙げられていません。実務上は、通知先への投稿を伴う点を踏まえてモードを選びます。

AutoモードはPro・Maxのモード選択肢で、Team・Enterpriseでは表示されません。Team・Enterpriseでコネクタ側の権限設定と組み合わせた挙動はCowork自動承認モードとはで扱っています。

実際の承認は誰が行うか

監視タスクが検知した超過や滞留は、通知を受け取った担当者がRampの画面に戻って確認し、承認・却下・差し戻しを判断します。Claudeが用意するのは「どの部門が」「いくら」「いつから」超過・滞留しているかという材料までで、稟議の可否そのものを判断する立場には置きません。

この構成は、書き込み可能なMCPサーバーを使う他の承認ワークフロー連携(kickflowなど)とは前提が異なります。kickflow連携のように書き込みAPIが提供されているConnectorでは、承認・却下の実行自体をCoworkの承認モードで統制する設計が選べますが、Ramp連携ではその選択肢自体がありません。書き込み可能なConnectorとの承認設計の違いはkickflow Cowork連携で稟議承認フローを自動化するで比較できます。

言い換えると、Ramp×Coworkの監視タスクは「承認者の手前」までを担う仕組みです。承認者がRampを開いたときにはすでに超過・滞留の要点が通知として届いているため、Rampの画面上で対象の取引を1件ずつ探す時間が要りません。承認の判断そのものにかかる時間は変わりませんが、判断材料を集める時間を削れる点が実務上の効果になります。

よくあるつまずき

通知が来ない、または実行結果が空になる

Ramp Connectorがオフになっている、またはRampのロール権限で対象データが見えない場合、実行結果が空になります。「Scheduled」ページから過去の実行結果を確認し、まずタスクが失敗せず動いているかを見ます。

しきい値の判定がぶれる

「予算超過」「金額が大きい」のような主観的な表現は避け、「月間予算の80%を超えたら」「1万ドルを超えたら」のように具体的な数値条件に落とし込みます。最初の数回は結果を見ながら条件を調整すると安定します。

承認・却下をタスクに含めようとしてしまう

Ramp連携で公式に案内されているのは照会・分析の操作だけのため、承認・却下・新規作成をプロンプトに含めても実行されません。監視と通知までをタスクの範囲とし、実際の承認操作はRamp本体で行う前提で設計します。

毎回「異常なし」の通知が届いて埋もれる

しきい値を厳しくしすぎると、変化がない回でも通知が届き、そのうち読み飛ばされるようになります。「超過や滞留を検知したときだけ投稿し、無ければ何もしない」とプロンプトに明記しておくと、通知が来ないこと自体が「正常」の合図になり、届いたときだけ確認する運用に切り替えられます。

よくある質問

発注申請の承認自体をClaudeに任せられますか

任せられません。Ramp連携の公式な利用例は読み取り操作のみで、承認・却下に相当する書き込み操作は挙げられていません。任せられるのは、超過や滞留の検知と担当者への通知までです。

通知先はSlack以外にもできますか

Rampと同時に接続しているConnector次第です。メールやチームチャットツールへの投稿に対応するConnectorが接続済みであれば、同様の依頼文で通知先を切り替えられます。

個人アカウントでも使えますか

使えます。Ramp Connector自体は無料プランを含む全プランで接続できます。定期実行に使うScheduled Tasksが有料プラン(Pro・Max・Team・Enterprise)限定のため、定期監視の構成には有料プランが必要です。無料プランでは、まず通常のCoworkタスクとして同じプロンプトを1回試し、期待通りの結果になるかを確認してから有料プランで定期実行に切り替える進め方が現実的です。

まとめ

Ramp×Coworkの組み合わせは、購買・経費の異常を人より先に見つけて知らせる用途に向いています。発注申請の承認そのものを自動化する構成ではなく、Ramp連携の公式な利用例が照会・分析に限られている以上、承認・却下の実行は引き続きRampの画面で人が行います。Scheduled Tasksで監視の頻度としきい値を固定し、検知したときだけ通知が届く設計にしておけば、担当者は「確認して問題なければ何もしない」運用に切り替えられます。