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

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

RampのConnectorは「Anthropic verified」の表示つきで、Rampの財務データへの読み取り専用アクセスとして紹介されています。取引・立替経費・請求書・購買注文(purchase orders)・法人カード・取引先などを読み込み、照会・分析するためのものです。ツール一覧に並ぶのは、データを読み込む load_ 系と、照会する execute_query などです。承認・却下・新規作成に当たるツールはありません。中心はデータの照会と取り込みです。詳しくはClaude Ramp連携の始め方にあります。

したがって、Ramp×Coworkで自動化できるのは「発注申請の承認そのもの」ではありません。予算超過や滞留を検知して、承認担当者に判断材料を渡すところまでです。実際の承認・却下は、引き続きRampの画面で人が行います。

この線引きは弱点ではなく、Cowork側の安全ガイドとも噛み合います。定期実行のタスクには、まず要約や情報収集のような低リスクの作業から始め、購入や、自分の名前でのメッセージ送信のような取り消しにくい操作は避けるよう案内されています。承認権限をClaudeに渡さないまま「見落とし」を減らす用途が、財務データを扱うConnectorとの現実的な付き合い方です。

監視プロンプトに何を書くか

Rampのツールは、データを取り込む段と照会する段に分かれています。プロンプトで対象のデータ(購買注文、部門、取引先など)をはっきり名指しすると、どの読み込みツールを使うかが定まりやすくなります。次の3パターンは、それぞれ使うツールが異なります。

パターン

監視パターンと使うツール

• 部門予算の超過検知

  load_departments と load_limits で部門と支出上限を読み込み、execute_query で照会します。依頼文の例は「毎週月曜9時、先週の部門別支出を確認し、月間の支出上限の80%を超えた部門があれば部門名と超過額を報告して」です。予算額を別に管理している場合は、その数値をプロンプトに書いて渡します。

• 滞留した購買注文の洗い出し

  load_purchase_orders で購買注文を読み込みます。「毎朝8時、購買注文のうち5営業日以上ステータスが動いていないものを、担当者名つきで一覧にして」のように、日数の条件を数字で書きます。

• 取引先別の支出の変化

  load_vendors と load_spend_exports で取引先と支出を読み込みます。取引先ごとの金額を前月と並べる、月次の監視です。

高額な請求書の通知も、同じ型で書けます。Connectorの説明には請求書(bills)も対象データとして挙がっていますが、ツール一覧に請求書専用の読み込みツールはありません。最初は execute_query で請求書のデータが取れるかを実行結果で確かめます。取れるなら「毎日17時、1万ドルを超える請求書があれば、件数と合計金額を要約して」のように、金額と報告の形を指定します。

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

頻度は監視対象の重さに合わせます。部門予算のように月単位で動く数字を毎時チェックしても差分は出にくく、無駄な実行が積み重なるだけです。支払期限が迫る請求書は、毎日か平日のみの頻度が実務に合います。手動入力では頻度を1つ選ぶ形なので、性質の異なる監視は別タスクに分けます。

前提条件

始める前に、次の3点を確かめます。

• Ramp Connectorが接続済みであること。接続にはRampへのサインインが必要です
• Scheduled Tasksが使える有料プラン(Pro・Max・Team・Enterprise)であること
• 監視の対象がRampのデータだけで済むこと

3点目は、Scheduled Tasksの仕組みに由来します。定期実行のタスクはリモートで動くため、パソコンがスリープ中でもClaude Desktopアプリが閉じていても、設定した頻度で走ります。一方で、パソコン上のフォルダには結び付けられません。ローカルのファイルやアプリを必要とするタスクは、ローカルでしか動きません。Rampのようなコネクタ経由のデータ取得と要約は、この制約に当たらない用途です。

ProとMaxでは、2026年10月6日から新しいCoworkタスクがクラウドで動き、「設定 > 一般」の「Only on your computer」の選択肢が削除されます。すでにパソコン上で始めたタスクは、そのままパソコン上に残ります。

監視タスクを作る手順

Coworkの画面からは、手動で入力する方法とClaudeに作らせる方法があります。手動の流れは次のとおりです。

手順

Set up manuallyで作る流れ

1. 1

   Scheduledを開く

   サイドバーの「Scheduled」を開き、右上の「New task」から「Set up manually」を選びます。

2. 2

   名前とプロンプトを入れる

   タスク名と、監視内容を書いたプロンプトを入力します。対象データ、しきい値、報告の形をここに書きます。

3. 3

   承認モードと頻度を決める

   承認モードを選び、頻度を毎時・毎日・毎週・平日のみ・手動実行から選びます。モデルの指定は任意です。

4. 4

   フォルダは指定しない

   作業するフォルダの指定欄もありますが、任意です。ローカルのフォルダに結び付けると定期実行がローカル限定になるため、Rampの監視では空のままにします。

5. 5

   Saveで保存する

   「Save」を押すと「Scheduled」ページにタスクが並びます。「Run a task on demand」の操作で、頻度を待たずに1回試せます。

「New task」から「Create with Claude」を選ぶと、Claudeが確認の質問を挟みながら、最後にタスク名・頻度・内容を提示します。「Schedule」を押して確定します。ProやMaxで新しいClaudeの画面に切り替わっている場合は、メッセージ欄に「Chat」と「Cowork」の選択肢がありません。その場合は通常の会話の中で「毎週月曜9時に〜して」と頼み、提示された内容を見て「Schedule」を押します。

結果を読むか、Slackに投稿するか

通知の出し方は、タスクの安全性を大きく左右します。ここで、前節の安全ガイドとの兼ね合いを考えておく必要があります。

くらべる

通知の出し方は2通り

書き込みなし

実行結果を読む

報告を実行結果にとどめ、担当者が「Scheduled」ページで過去の実行を開いて読みます。Rampは読み取り専用で、外部へメッセージを送るツールも使いません。定期実行にまず求められる「低リスクの要約」に収まります。

書き込みあり

Slackに投稿する

担当者が通知に気づきやすい反面、自分の名前で外部へメッセージを送る操作が加わります。定期実行では避けるよう案内されている操作の1つなので、投稿内容を確認できる状態から始めます。

最初は前者で運用し、しきい値の判定が安定してから投稿を足すという順序が、安全ガイドの「まず簡単に始める」と合います。投稿を足すときは、モデルや通知先のConnectorの権限設定も見直します。

承認モードとコネクタ権限の組み合わせ

Coworkの承認は、モードとコネクタ側のツール権限の掛け合わせで決まります。ツール権限は「Customize > Connectors」のページで、ツールごとに「Always allow」「Needs approval」「Blocked」から選びます。

データの照会に使うRampのツールは読み取りなので、「Always allow」にしてあればAutomatically approveでは確認なしに通ります。この意味で、Rampの照会・要約だけのタスクはAutomatically approveと相性がよい構成です。

注意が要るのは、通知先のConnectorを加えた場合です。Slackへの投稿は書き込みに当たり、Automatically approveではClaudeの安全確認に判断が委ねられます。Skip all approvalsには、この確認がありません。送信や購入のように取り消しにくい操作が絡むときは、Manually approveに切り替えるよう案内されています。通知先の設定を初めて試すときは、最初の数回を内容を見ながら進められるManually approveが無難です。

Automatically approveには、確認の分だけ使用量の上限を多く消費するという性質もあります。毎時実行のような高頻度のタスクに使うと、上限の減りが目立ちます。

モードの選択肢はプランや画面で異なります。新しいClaudeの画面ではAutoとManual(既定)の2択です。Team・Enterpriseでは、Automatically approveは既定で使えますが、管理者がオフにすると選択肢から消えます。組織が書き込みを伴うコネクタのツールに都度の承認を求めている場合は、「Always allow」の設定が効かないこともあります。モード単体の挙動はCowork自動承認モードとはで扱っています。

Rampのデータを読むときのリスク

Rampから読み込むデータには、社外の人が入力した文字列が混ざる可能性があります。請求書に載る取引先名や、立替経費に付くメモなどです。load_memos というメモを読み込むツールも用意されています。

安全ガイドは、プロンプトインジェクション(外部の文章に仕込まれた指示でClaudeを操る攻撃)が成り立つ条件を2つ挙げています。信頼できる範囲の外にある情報をClaudeが読めること、そして利用者に害のある操作をClaudeが実行できることです。どちらかが欠ければ、攻撃は難しくなります。

この条件を監視タスクに当てはめると、次のようになります。

• 照会と要約だけのタスクは、読む条件を満たしても、実行できる操作が照会と要約に限られる
• Slackへの投稿やメール送信を足すと、2つの条件がそろう

通知先を足す前に、Rampのデータを読んで外部へ書き出す経路ができることを意識しておきます。投稿する文面はRampの数字と部門名に絞り、データ側の文章をそのまま転記させない書き方が、その対策の1つです。

月次で取引先別の支出を追う

日次・週次の監視は異常の早期発見を担います。一方、月次の取引先別レビューは、支出構造そのものの変化を追う役割です。「毎月1日、先月の取引先別支出を読み込み、前月比で20%以上増えた取引先があれば、増えた金額を添えてレポート化して」のようなタスクが、この役割に当たります。

特定の取引先への支出が数か月続けて増えているのに、日次・週次の監視では単月のしきい値を超えないという場面があります。月次のレビューは、こうした緩やかな変化を拾うための頻度です。短期の見落としと中期のトレンド変化を、別々のタスクで別々の頻度で見る形になります。

実際の承認は誰が行うか

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

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

承認者がRampを開いたときには、すでに超過・滞留の要点が通知として届いています。対象の取引を1件ずつ探す時間が要りません。承認の判断にかかる時間は変わらず、判断材料を集める時間が削れる点が、実務上の効果です。

よくあるつまずき

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

Ramp Connectorがオフの場合や、接続したRampアカウントの権限で対象データが見えない場合は、実行結果が空になることがあります。「Scheduled」ページで過去の実行結果を開き、タスクが失敗せずに動いているかをまず見ます。定期実行は画面の前にいない間に走るので、保存後の数回は結果を自分で読む運用が安全ガイドにも沿います。

しきい値の判定がぶれる

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

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

Rampのツール一覧に承認・却下・新規作成に当たるものがないため、プロンプトに含めても実行できません。タスクの範囲は監視と通知までとし、承認はRamp本体で行う前提で設計します。

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

変化がない回にも通知が届くと、そのうち読み飛ばされます。「超過や滞留を検知したときだけ報告し、無ければ何もしない」とプロンプトに明記すると、通知が来ないこと自体が「正常」の合図になります。

使用量の上限が思ったより減る

Automatically approveの確認処理は、使用量の上限を多く消費します。高頻度で回すなら、頻度を落とすか、モードを見直す選択肢があります。

よくある質問

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

Rampと同時に接続しているConnector次第です。メールやチームチャットに投稿できるConnectorが接続済みなら、同様の依頼文で通知先を切り替えられます。通知先を足すと書き込み操作が加わるため、前節のモード選びを見直します。

無料プランで試せますか

定期実行のScheduled Tasksは有料プラン(Pro・Max・Team・Enterprise)の機能で、Coworkそのものも有料プランが対象です。まずは有料プランで、同じプロンプトを「Run a task on demand」の操作で1回走らせ、期待どおりの結果になるかを見てから、頻度を設定する進め方が現実的です。

まとめ

出発点としては、週次か日次の頻度で、通知は実行結果を読む形にし、承認モードはAutomatically approveにする組み合わせが収まりがよい構成です。

Slackなどの通知先を足す段階で、書き込みが加わります。その時点でManually approveへ切り替え、投稿内容を見ながら数回回す流れが無難です。