Claude Code API連携で業務自動化｜HubSpot・freee実践

Claude CodeはfreeeやHubSpot、SlackなどのAPIにつながり、部門をまたぐ業務の流れを自然言語の指示から組み立てられます。まず1つのサービスの読み取りから始め、手作業の転記を1つずつ仕組みに置き換えていくのが現実的な進め方です。

本記事は2026年8月時点の情報です。

「受注のたびに、HubSpotの金額と品目をfreeeの請求書に手で打ち直している」「請求書を作ったらSlackで経理に伝え、入金を確認したらまたHubSpotの取引を更新している」「取引先コードの対応表をスプレッドシートで持っているが、誰が最新版を持っているのかわからない」——。

Claude Code × API連携とは、Claude Codeに日本語で指示を出し、各サービスのAPIを呼び出すコードの生成・実行や、MCP（Model Context Protocol）経由の操作によって、複数の業務システムをまたぐ処理を自動化する方法です。「営業がHubSpotで受注にしたら、freeeに請求書を作り、Slackで経理チームに知らせる」という流れを、1本のワークフローとして組み立てられます。チームでの開発の進め方は「Claude Codeでチーム開発を効率化する方法」で解説しています。

これまで複数の業務システムをつなぐには、iPaaS（Integration Platform as a Service）を導入するか、専門エンジニアがAPI連携を開発するのが一般的でした。Zapierやn8nといったツールを使う場合も、必要な条件分岐・データ変換・例外処理を先に列挙し、画面上の設定で保守できるかを確認してください。連携ごとの運用担当と変更手順も比較材料になります。AI活用の全体像はAI活用完全ガイドでまとめています。
Claude Codeは自然言語の指示からAPIを呼び出すコードを生成・実行できるため、CDOやDX推進担当者が自らシステム連携の試作を進められます。本記事では、freee・HubSpot・Slack・Notion・Google Calendarを中心に、Claude Code × API連携の実践パターンを解説します。認証情報や権限の扱いについては「Claude Codeの企業導入セキュリティガイド」もあわせてご覧ください。

この記事でわかること

Claude Codeで複数の業務システムを連携し、部門横断のワークフロー自動化を実現したいDX推進担当者・CDOに向けた記事です。どの業務から自動化し、どこを人の判断として残すかを決めるための材料をまとめています。

• MCP経由とAPI直接呼び出しの使い分け — 主要サービスはMCPで接続し、MCPで届かない処理をコードで補うハイブリッド構成の考え方がわかります。
• freee・HubSpotの連携パターン — 試算表の取得、取引の登録、請求書の作成、パイプライン分析を、自然言語の指示でどう動かすかがわかります。
• Slack・Notion・Google Calendarの活用 — 通知、チャンネル要約、ナレッジ蓄積、商談日程の管理をCRMとつなぐ方法がわかります。
• Quote-to-Cashの全体設計 — 見積もり承認から入金確認までを、各ステップのトリガーと使うAPIで分解した設計図がわかります。
• 本番運用と導入ロードマップ — エラー処理、認証情報の管理、AIと人の役割分担、単一サービスから広げる段階的な進め方がわかります。

Claude Code × API連携の基本アーキテクチャ

API連携を始める前に、「どの手段で」「どの経路で」「業務フローのどこを」つなぐのかを決めておくと、後から作り直す手間が減ります。ここでは、Claude Codeを使う理由、MCPと直接呼び出しの違い、そしてCRMを中心とした全体フローの中での位置づけを整理します。

なぜClaude CodeでAPI連携を行うのか

API連携を構築する手段はいくつかありますが、Claude Codeが特に力を発揮するのは次の3つの場面です。

プロトタイプの高速構築: 「この2つのシステムを連携できるか試したい」という検証段階で、Claude Codeに日本語で指示するだけでAPIクライアントが生成され、その場で動作を確かめられます。

複雑なビジネスロジックの実装: iPaaSツールでは組みにくい条件分岐、データ変換、エラーハンドリングのロジックを、Claude Codeがコードとして実装します。

既存コードの理解と拡張: APIドキュメントが十分に整っていないシステムでも、Claude CodeがAPIのレスポンスを読み解き、連携コードを組み立てられます。

ただし、Claude Codeで作ったものはコードとして残るため、誰がそのコードを読み、直すのかを決めずに始めると、作った人しか触れない仕組みになってしまいます。表の「運用の担い手」の列は、手段を選ぶときの判断材料として見ていただければと思います。

MCP経由とAPI直接呼び出しの違い

Claude Codeから外部サービスに接続する方法は、大きく2つあります。どちらか一方に寄せるのではなく、処理の性質で使い分けるのがポイントになってきます。

MCP経由: MCPサーバーを設定すると、Claude Codeがサービスの操作を認識し、自然言語の指示だけでデータの取得・更新ができます。設定後は「HubSpotの取引一覧を取得して」と指示するだけで操作が完了します。

API直接呼び出し: Claude Codeにコードを生成させ、REST APIを直接呼び出す方法です。MCPサーバーが存在しないサービスや、MCPでは扱っていない細かなAPIエンドポイントにアクセスする場合に使います。

Claude CodeのMCP設定にはstdio・SSE・HTTPの接続方式があり、保存範囲としてlocal・project・userを選べます。projectスコープの設定はプロジェクト直下の .mcp.json に保存され、リポジトリで共有できます（出典：Connect Claude Code to tools via MCP）。接続設定を個人のPCにだけ置かず、projectスコープで共有しておくと、担当者が替わっても同じ環境を再現できます。

次の画面は、ターミナルで claude --version を実行してバージョンを表示し、そのあとにMCPの接続状況を確かめるスラッシュコマンド /mcp を並べたものです。

実務では、主要サービス（HubSpot・freee・Slack等）はMCPで接続し、MCPでカバーできない処理はAPI直接呼び出しで補うハイブリッド構成をおすすめします。複数サービスをMCPで統合する構成はMCPマルチツール統合の設計方法で、MCP連携の具体的な設定はMCPの詳細な設定手順と活用パターンで解説しています。

全体フローのどこをつなぐのか

API連携を個別の「便利ワザ」として積み上げていくと、どのデータがどこから来てどこへ行くのかが見えなくなります。私たちは、CRMを起点に「コンタクト→取引→顧客→請求」という一気通貫の流れを先に描き、その中で手作業が残っている箇所を連携の候補にする考え方をおすすめしています。

スプレッドシートで顧客リストと請求リストを別々に持っていると、この紐づけを人が毎回照合することになり、差分が生まれやすくなります。連携の起点をCRMに置くのは、この照合作業そのものをなくすためです。

freee API連携：会計業務の自動化

freeeとの連携は、営業部門のデータと経理部門のデータがつながる箇所で、転記の手間が見えやすい領域です。ここでは、試算表の取得、取引の検索・登録、請求書の作成、経費の集計という4つのパターンを取り上げます。いずれも、まずは読み取りから始め、書き込みは対応表を整えてから進める順番が目安です。

試算表（残高試算表）の取得と分析

freee MCPサーバーを利用すると、任意の期間の残高試算表をClaude Codeから直接取得できます。「今年度の残高試算表を取得して、売上高と主要経費の推移を月別にグラフ化して」と指示すれば、freee APIから試算表データを取得し、損益計算書レベルの分析まで進められます。

経営者やCFOが月次の数字を確認する際、freeeの管理画面を開いてレポートを探す代わりに、Claude Codeで「前月の売上と粗利を教えて」と聞くだけで回答が返ってきます。読み取りだけの操作なので、会計データを書き換えるリスクがなく、最初に試す連携として向いています。

ただし、試算表の数字は仕訳が締まっているかどうかで意味が変わります。月次決算が終わる前の数字をそのまま経営会議の資料に使わないよう、「締め処理が済んだ月だけを対象にする」といった条件を指示に含めておくと、読み違いを防げます。

取引の検索と自動登録

freee APIの取引検索では、取引先・勘定科目・日付範囲・金額範囲など、さまざまな条件で絞り込めます。

• 取引検索: 「先月の旅費交通費の取引を全件取得して、金額順に表示して」と指示すれば、freee APIの /api/1/deals エンドポイントからデータを取得し、整形して表示します
• 取引登録: HubSpotで取引が「受注」ステージに移ったタイミングで、freeeに売上取引を作成します。Claude Codeに「HubSpotの受注データからfreeeの取引を作成するスクリプトを書いて」と指示すれば、勘定科目の対応付け・取引先の対応付け・エラーハンドリングを含むコードが生成されます

freeeのAPIは、事業所ID・勘定科目ID・取引先IDなどの内部IDで項目を指定します。そのため、HubSpot側の会社名や商品名を、freee側のどのIDに対応させるかという対応表を先に作っておきます。進め方は次の順番がわかりやすいでしょう。

1. freeeから取引先・勘定科目・品目の一覧をAPIで取得し、Claude Codeに一覧表として出力させる
2. HubSpotの会社・商品ライブラリの一覧と突き合わせ、対応が取れない行を洗い出す
3. 対応が取れない行は、名寄せするのか新規登録するのかを経理担当者が決める
4. 対応表が全件埋まった状態になってから、取引の自動登録に進む

この対応表をスプレッドシートで個人が持つと、更新漏れがそのまま誤った請求につながります。対応表はスクリプトと同じリポジトリに設定ファイルとして置き、変更履歴が追える形で管理しておくと、担当者が替わっても引き継げます。

請求書の自動発行

freee MCPサーバー経由で、請求書の作成・取得・更新ができます。

HubSpotのQuote（見積もり）が承認されたら、その内容をfreeeの請求書の形式に変換し、APIで請求書を作成します。商品名・数量・単価・税率の情報はHubSpotのLine Itemsから取得し、freeeの品目マスタと対応付けます。

「HubSpotの取引ID xxx に紐づくLine Itemsを取得し、freeeで請求書を作成して」と指示すれば、CRMから会計システムへのデータ連携が自然言語の1文で進みます。

ただし、請求書は顧客に届く書類です。自動化するのは「作成」までにとどめ、送付は経理担当者が金額・宛先・支払期日を見てから行う運用をおすすめします。作成した請求書の一覧をSlackの経理チャンネルに流し、担当者が確認済みの印を付けてから送付する流れにしておくと、自動化の速さと人の確認を両立できます。

経費データの集計・分析

freee APIから取引データを取り出し、Claude Codeで分析するパターンです。「今月の経費を勘定科目別に集計して、前年同月比を計算して」と指示すれば、APIからデータを取得し、集計表とグラフを生成します。

月次決算のスピードアップや、予算実績対比レポートの自動作成に活用できます。スプレッドシートに毎月データを貼り付けて関数を組み直していた作業を、同じ指示を繰り返すだけの作業に置き換えられるのが利点です。freeeとMCPの連携についてはMCP × freee連携ガイドも併せてご参照ください。

HubSpotの取引レコードを開いたまま、freee側の請求書の状況を確認したい場面は少なくありません。StartLinkが開発したSync for freeeは、CRMカードでfreeeの請求書・取引情報（金額・支払期日・支払履歴）を表示し、取引画面から離れずに確認できます。無料プランから試せます。HubSpotマーケットプレイスからインストールできます。

HubSpot API連携：CRM運用の効率化

HubSpotは、この記事で扱う連携の起点になるシステムです。ここでは、CRMデータの横断検索、パイプライン分析、ワークフローの補完に加えて、連携を安定させるためのプロパティ設計を取り上げます。自動化の精度は、CRMに入っているデータの質でほぼ決まると考えています。

コンタクト・会社・取引の横断検索

HubSpot MCPサーバーを活用すると、CRMオブジェクト（コンタクト・会社・取引）を横断的に検索・操作できます。

• コンタクト検索: 「メールドメインが@example.comのコンタクトを全件取得して、ライフサイクルステージ別に集計して」と指示すれば、Search APIで条件に合うコンタクトを取得し、集計結果を出力します
• 会社検索: 「従業員数100名以上の会社で、過去6ヶ月間に取引が作成されていない会社を一覧にして」と指示すれば、会社と取引の関連付けをまたいだ分析を行います
• 取引検索: 「今月クローズ予定の取引を金額順に一覧にして、担当者別のパイプライン金額も集計して」と指示すれば、営業マネージャーが会議で使うデータがその場で整理されます

HubSpotの管理画面では、フィルターの設定 → 選択 → 一括編集と、何度もクリックを重ねる作業が、自然言語の1指示で済みます。ただし、一括更新は取り消しに手間がかかります。更新系の指示を出すときは、まず「対象レコードの一覧を出して」と読み取りだけを行わせ、件数と中身を見てから「では、この一覧を更新して」と2段階に分けて指示してください。

パイプライン分析とフォーキャスト

HubSpot MCPの真価は、複数のデータを組み合わせた分析にあります。

• パイプライン別・ステージ別の遷移分析: 「過去12ヶ月のパイプライン別・ステージ別の受注率を計算して」と指示すれば、取引データを集計し、ファネル分析を行います
• 担当者別の生産性分析: 「各担当者のアクティビティ数と受注率を比較して、相関があるか分析して」
• リードスコアリングの検証: 「リードスコア別の受注率を集計して、スコアリングモデルの精度を検証して」

こうした分析が意味を持つのは、パイプラインの設計が整っている場合です。私たちは、取引ステージ・受注確度・ステージ定義・必須入力プロパティの4要素でパイプラインを設計することをおすすめしています。ステージごとの受注確度が設定されていれば、Claude Codeに「受注確度をかけた加重金額でフォーキャストを出して」と指示するだけで、担当者の感覚値ではなく、ステージに基づいた見込み金額を出せます。

反対に、ステージの定義が担当者ごとにばらばらな状態では、どれだけ高度な分析を指示しても、出てくる数字は信頼できません。分析を自動化する前に、各ステージの定義を社内で共有しておくのが、要点になります。

ワークフローの補完

HubSpotのワークフローでは組みにくい処理を、Claude Code + APIで補うパターンです。外部APIとの連携、込み入った条件分岐、データの変換・計算などは、Claude Codeで生成したスクリプトの方が柔軟に対応できる場合があります。

役割の分け方としては、「HubSpotの中で完結する処理はワークフロー」「HubSpotの外のシステムとやり取りする処理はClaude Codeで作ったスクリプト」と線を引くのがわかりやすいでしょう。

例えば、受注時の担当者への社内通知やライフサイクルステージの更新はワークフローに任せ、freeeへの請求書作成はスクリプトに任せる、という分け方です。ワークフローの画面で確認できる処理を増やしておくと、コードを読めないメンバーでも自動化の全体像を追えます。

生成したコードの品質は、AIコードレビューガイドで紹介しているAIレビューでさらに高められます。

連携を安定させるプロパティ設計

freeeへの請求書作成に取引の金額、クローズ日、請求先会社の関連付けを使う設計なら、送信前に必須項目がそろっているかを検査してください。欠けている項目をどう扱うかは、連携仕様とエラー時の手順で決めます。

これを営業担当者の注意力に頼るのではなく、仕組みで防ぐのがおすすめです。

項目は少ない方が、入力する側も集中できます。連携に使うプロパティを最小限に決めておくことは、新しく入ったメンバーに「何を入れればよいか」を教える手引きにもなります。

Slack API連携：通知・レポートの自動化

Slackとの連携は、システム間で起きたことを「人が気づける形」にする役割を担います。ここでは、チャンネルの要約、業務イベントの通知、定期レポートの3つを取り上げます。通知の設計では、送る条件と送らない条件、受け取る担当者を決めておくと、業務イベントを確認しやすくなります。

チャンネルサマリーの自動生成

Slack MCPサーバーを使えば、指定チャンネルの投稿を取得し、要約を生成できます。

• チャンネル読み取り・要約: 「先週の#salesチャンネルの投稿を取得して、主要な議論と決定事項を要約して」と指示すれば、Claude Codeがチャンネルのデータを取得し、構造化されたサマリーを作成します
• メッセージ検索: 「#supportチャンネルで"障害"というキーワードを含む投稿を過去1ヶ月分検索して、発生頻度と傾向を分析して」
• スレッド読み取り: 特定のスレッドの全投稿を取得し、議論の経緯と結論を要約します

要約はあくまで読み手が元の投稿にたどり着くための入口として使うのがよいと考えています。決定事項を要約だけで判断せず、要約に元の投稿へのリンクを付けるよう指示しておくと、読み違いがあってもすぐに原文に戻れます。

業務イベントの自動通知

受注、解約、大口リードの獲得など、特定のビジネスイベントが起きたときに、Slackの適切なチャンネルへ通知するパターンです。

HubSpotのWebhookをきっかけに、Claude Codeで生成したスクリプトがSlack APIを呼び出し、決まった形式のメッセージを投稿します。Block Kit（Slackのリッチメッセージ形式）を使えば、ボタン付きの通知や、その場で操作できるメッセージも送れます。

通知の条件は、受け取った担当者がその日のうちに次の行動を決められるものに絞ってください。進め方は次のとおりです。

1. 通知したいイベントを書き出し、それぞれ「誰が」「何をするための通知か」を1行で書く
2. 行動がひとつも書けないイベントは、通知ではなく日次レポートに回す
3. 1週間運用し、反応のないまま流れていった通知の条件から外していく

失注も通知の対象にしておくと、営業とマーケティングの連携に役立ちます。失注理由をHubSpotのプロパティで分類しておけば、通知と同時に理由の内訳が共有され、失注した取引をナーチャリングに戻して掘り起こす流れにもつなげられます。

定期レポートの自動投稿

毎朝決まった時刻に、前日の営業活動サマリーをSlackに投稿するパターンです。HubSpot APIから前日のアクティビティデータを取得し、新規リード数・商談数・受注金額をまとめた日次レポートをチャンネルに投稿します。

これまで誰かが朝にダッシュボードを見て数字を拾い、Slackに書き込んでいたなら、その作業を丸ごとスクリプトに置き換えられます。レポートの項目は、HubSpotのダッシュボードで見ている指標と同じ定義にそろえておくと、「Slackの数字とダッシュボードの数字が合わない」という問い合わせを防げます。定期実行をCI/CDの仕組みに載せる方法は「Claude Code × CI/CD」で解説しています。

Notion・Google Calendar連携：ナレッジとスケジュールの整理

NotionとGoogle Calendarは、CRMの外で散らばりやすい「議事録」「社内の知見」「商談の予定」を扱うサービスです。ここではそれぞれの基本操作と、HubSpotと組み合わせたときの使い方を取り上げます。CRMの取引と紐づけて初めて、営業活動の記録として生きてきます。

Notionのページ作成とデータベース操作

Notion MCPサーバーを活用すると、Claude CodeからNotionのページ作成・データベース操作ができます。経営データの可視化やコンテンツマーケティングを含め、Claude Codeの業務活用に関心のある方はぜひ参考にしてください。

• ページ作成: 「Notionの"議事録"データベースに、今日の日付で新しいページを作成して、以下の内容を記載して」と指示すれば、Notion APIで構造化されたページが作成されます
• データベースクエリ: 「Notionの"プロジェクト管理"データベースから、ステータスが"進行中"のタスクを全件取得して、期限順に並べて」と指示すれば、条件で絞り込んだデータが取得できます
• ページ更新: 既存ページの内容を更新したり、プロパティ値を変更したりする操作も自然言語で行えます

Notionへの接続は、Notion側でインテグレーションを作成し、接続先のページやデータベースにアクセス権を与えたうえで行います。アクセス権は、自動化で使うデータベースだけに絞って与えておくと、意図しないページが書き換わる心配が減ります。

Slack×Notionでナレッジベースを育てる

Slack MCPとNotion MCPを組み合わせると、Slackのやり取りからNotionにナレッジベースを積み上げるワークフローを組めます。「#supportチャンネルで解決された問い合わせを、Notionの"FAQ"データベースに登録して」と指示すれば、チャットの中に埋もれていた知見がナレッジとして残ります。

問い合わせ対応をベテランの記憶に頼っていると、その人が不在のときに対応が止まります。解決済みのやり取りがNotionに蓄積されていれば、新しく入ったメンバーでも過去の対応を検索して回答できます。登録前に、担当者が内容を読んで「公開してよいFAQか」を判断する一手間を入れておくと、誤った回答がナレッジとして残るのを防げます。

次の画像は、Sync for Notionで取引プロパティとNotionテーブルプロパティのマッピングを設定する画面です。

引用：Sync for Notion｜HubSpot ↔ Notion プロパティの双方向マッピング

Google Calendarの予定読み取りと空き時間の提案

Google Calendar MCPサーバーを活用すると、スケジュール管理をClaude Codeから操作できます。

• 予定の読み取り: 「今週のカレンダーを取得して、MTGの合計時間と空き時間を教えて」と指示すれば、カレンダーのデータから会議の密度と空き時間を計算します
• ミーティング時間の提案: 「来週、田中さんと佐藤さんの3人で1時間のMTGを設定したいのだけど、空いている時間帯を3つ提案して」と指示すれば、複数のカレンダーの空き時間を突き合わせて候補を示します
• 空き時間の検索: 「来月の金曜日で、午後に2時間以上空いている日を全部教えて」

Google Calendar MCPサーバーの利用には、GoogleアカウントでのOAuth認証を行います。他のメンバーの空き時間を参照する場合は、そのメンバーのカレンダーの共有設定によって見える範囲が変わるため、想定どおりの候補が出ないときは共有設定から見直してください。

HubSpotと組み合わせた商談スケジュールの管理

Google Calendar MCPとHubSpot MCPを組み合わせると、商談スケジュールとCRMデータをまとめて扱えます。「来週の商談予定を取得して、各商談の取引金額とステージをHubSpotから引いて一覧にして」と指示すれば、カレンダーとCRMをまたいだ一覧ができあがります。

マネージャーが週次の会議前に、カレンダーとCRMを行き来して案件の状況を拾い集める作業は、この一覧で置き換えられます。カレンダーの予定名に会社名が入っていないと取引との突き合わせができないため、予定の件名に会社名を入れるルールをチームで決めておくと、紐づけの精度が上がります。

クロスサービス連携の設計：Quote-to-Cash

個別の連携が動くようになったら、次は複数のサービスをまたぐ業務の流れ全体を設計します。その代表が、見積もりから入金までをつなぐQuote-to-Cashです。CRM・会計・コミュニケーションの3つの領域をまたぐため、効果が見えやすい一方で、設計の粗さもそのまま表に出ます。

Quote-to-Cash（見積もりから入金まで）の流れ

CRM × 会計 × コミュニケーションの3つのシステムを横断するQuote-to-Cashの自動化は、Claude Code × API連携の効果を実感しやすいユースケースです。

この一連の流れをClaude Codeで構築する場合、各ステップのスクリプトを個別に生成し、Webhookや定期実行（cron）で呼び出す構成をおすすめします。1本の大きなスクリプトにまとめると、どこで止まったのかがわかりにくくなるためです。ステップごとに分けておけば、例えばステップ2で失敗したときに、ステップ2だけをやり直せます。会計プロセス全体の自動化の考え方はAI経理・会計業務の自動化で解説しています。

5サービス統合の全体像

Claude Code × MCPで5つのサービスを統合した場合の全体像は次のとおりです。

この表で見ておきたいのは、データの「正本」がどこにあるかです。顧客と取引の正本はHubSpot、請求と入金の正本はfreee、というように、項目ごとに正本を1か所に決めておきます。同じ項目を2つのシステムで双方向に更新すると、どちらが正しいのかわからなくなるため、原則として正本から他のシステムへの一方向で流すのがおすすめです。

作った人がいなくても回る仕組みにする

Claude Codeで連携を作ると、作った人の頭の中にだけ設計が残りがちです。担当者が異動したとたんに誰も触れない自動化になるのを避けるため、次の3点をリポジトリにまとめて残しておくことをおすすめします。

• 連携の一覧: どのトリガーで、どのシステムからどのシステムへ、何を流しているか（前述のQuote-to-Cashの表と同じ形式で十分です）
• 対応表: HubSpotの項目とfreeeのIDの対応など、スクリプトが参照するマスタデータ
• 止まったときの手順: エラー通知が来たら誰が何を見て、どこから再実行するか

この3点がそろっていれば、コードの細部を読めないメンバーでも、何が起きているかを追えます。Claude Codeに「このリポジトリの連携の一覧を、表形式で最新化して」と指示し、ドキュメントの更新そのものを定例作業にしておくと、記述が古くなるのも防げます。

本番運用の設計：エラー処理・認証・AIと人の役割分担

試作で動いた連携を業務で使い続けるには、失敗したときの振る舞い、認証情報の扱い、どこを人が判断するかを決めておくことが欠かせません。ここでは、この3つに加えて、Claude Codeでの連携が向かないケースも率直に整理します。

エラーハンドリングとリトライの設計

API連携では、ネットワークエラー・レート制限・認証エラーなどがいずれ起こります。Claude Codeで生成するスクリプトには、次のエラーハンドリングを含めてください。

• リトライ（指数バックオフ）: APIのレート制限（429エラー）に対して、待機時間を徐々に延ばしながら再試行します
• べき等性の確保: 同じリクエストを複数回送っても結果が変わらない設計にします。例えば、請求書を作る前に「この取引IDで作成済みの請求書がないか」を調べ、あれば作らないようにします
• エラー通知: 再試行しても回復しないエラーは、Slackやメールで管理者に知らせます
• ログの記録: すべてのAPI呼び出しのリクエストとレスポンスを記録し、後から追えるようにします

HubSpotでは、APIの呼び出し回数が上限を超えると429エラーが返されます。上限や例外はAPI・契約・認証方式などで異なるため、対象APIの条件を確認してください（出典：API usage guidelines and limits）。一時的な上限超過は応答に合わせて待機・再試行し、日次上限に達した場合はリセット時刻まで処理を止める設計が必要です。

Claude Codeに「エラーハンドリングとリトライを含めて」と指示すれば、これらのロジックを含むコードが生成されます。生成後は、わざと誤ったトークンを使って認証エラーを起こし、通知が届くかどうかまで試しておくと安心です。

APIキーと権限の管理

HubSpotのレガシーPrivate Appを使う場合は、アクセストークンと必要なスコープを設定してAPIを呼び出します。新規の認証方式を選ぶ際は、現在のHubSpot公式案内とアカウント条件を確認してください（出典：Legacy private apps）。スコープは連携に使う操作だけに絞ります。例えば、取引を読み取って請求書を作るだけのスクリプトであれば、コンタクトの書き込み権限は与えません。

認証情報の扱いは、次の順番で決めていくとわかりやすくなります。

1. 連携ごとに専用のアプリ（トークン）を分け、どのスクリプトが何の権限で動いているかを一覧にする
2. トークンは環境変数（.env ファイル）で管理し、.gitignore に追加してリポジトリに含めない
3. チームで運用する段階になったら、シークレットマネージャーに移し、個人のPCにトークンを置かない状態にする
4. 担当者の異動や退職のタイミングで、その人が発行したトークンを差し替える手順を決めておく

連携ごとにトークンを分ける場合も、各トークンの権限と利用先を記録し、漏えい時に停止・再発行する対象を確認できるようにしてください。

AIに任せる処理と人が判断する処理

Claude Codeは、APIを呼ぶコードを書くことや、大量のデータを集計・分類することは得意です。一方で、何を正本にするか、どのステージで何を必須にするか、請求書を顧客に送ってよいか、といった判断はビジネスの理解が前提になります。私たちは、この線引きを最初に決めてから自動化を進めることをおすすめしています。

初めて連携を作るときは、Claude Codeに叩き台を作らせ、人が中身を読んで直していく進め方がとっかかりやすいと考えています。自動で動く部分が増えるほど、「最後に人が見る場所」を明確にしておくことが、事故を防ぐポイントになってきます。

Claude Codeでの連携が向かないケース

すべての連携をClaude Codeで作るのがよいわけではありません。次のような場合は、他の手段の方が合っています。

• トリガーとアクションが1対1で終わる連携: 「フォーム送信があったらSlackに通知する」程度であれば、HubSpotのワークフローやiPaaSで設定した方が、画面で誰でも状況を確認できます
• コードを読める人が社内にいない: 生成したコードを誰もレビューできない状態では、不具合が起きたときに直せません。この場合は、外部の支援を受けるか、ノーコードの手段を選ぶ方が安全です
• 大量データを高頻度で処理する連携: 継続的に大きな負荷がかかる処理は、専用に設計したカスタム開発の方が向いています

判断に迷ったら、「その連携が止まったとき、社内の誰が原因を調べられるか」を考えてみてください。答えが出ない連携は、Claude Codeで作るより、画面で状態を追える手段を選んだ方が長く運用できます。

導入のロードマップ

ここまでの連携を一度に作ろうとすると、どこで問題が起きているのかがわからなくなります。単一サービスの読み取りから始め、各段階で次へ進む条件を満たしてから広げていく段階的な進め方をおすすめします。期間は業務の範囲や体制によって変わるため、ここでは期間ではなく「次へ進む条件」で区切っています。

フェーズ1：単一サービスの読み取り

まずは1つのサービス（HubSpotまたはfreee）とClaude Codeを接続します。MCP経由の接続を設定し、取引一覧や試算表の取得など、読み取りだけの操作を試します。Claude Codeの基本操作はClaude Codeの使い方ガイドで確認できます。

次へ進む条件は、「普段手作業で作っている集計を、Claude Codeへの指示だけで同じ結果として出せること」です。数字が合わない場合は、連携を広げる前に、CRMや会計のデータの入り方を見直してください。

フェーズ2：2サービス間の片方向連携

HubSpot → freee、またはHubSpot → Slackの片方向の連携を作ります。Webhookの設定、データの対応付け、エラーハンドリングを含めたスクリプトを用意し、まずはテスト用のデータで動かします。

次へ進む条件は、「対応表が全件埋まっていること」「わざとエラーを起こしたときに通知が届くこと」「同じ処理を2回実行しても二重に作成されないこと」の3つです。

フェーズ3：クロスサービス連携

3つ以上のサービスをまたぐワークフロー（Quote-to-Cashなど）を構築します。Notion・Google Calendarも統合し、リトライ、ログ記録、監視アラートを含めて、本番の業務で使える形に仕上げます。

次へ進む条件は、「前述の連携の一覧・対応表・止まったときの手順がリポジトリにそろっていること」です。作った人以外のメンバーが、この3点を読んで再実行まで行えるかを一度試しておくと安心です。

フェーズ4：運用の安定化と拡張

運用開始後は、エラーログの監視、処理速度の改善、新しい連携パターンの追加を続けていきます。定型化したワークフローはClaude Codeのスキルとしてまとめ、チームの誰でも同じ手順で呼び出せるようにしておくと、特定の人に依存しない運用になります。

よくある質問

Q1. Claude Codeで生成したAPI連携スクリプトは本番運用に使えますか？

使えます。本番で使う場合は、エラーハンドリング・リトライ・ログ記録・監視の仕組みを加えてください。Claude Codeに「本番品質で」と指示すれば、これらの要素を含むコードが生成されます。デプロイの前にはテスト環境で、正常系に加えて認証エラーや二重実行の場合の動きも試しておくことをおすすめします。

Q2. APIのレート制限に引っかかりませんか？

各サービスにはAPIの呼び出し回数の上限があり、HubSpotでは上限を超えると429エラーが返されます。Claude Codeで生成するスクリプトには、429の理由を応答から確認し、一時的な上限超過には待機と再試行、日次上限には停止と再開時刻の管理を入れてください。大量データを扱う場合は、一括で処理できるバッチ用のAPIを使うか、処理を小分けにして順番に流す設計にしてください。

Q3. iPaaS（Zapier等）とClaude Codeのどちらを使うべきですか？

「Aサービスのイベントで、Bサービスを1回更新する」程度の連携であれば、Zapierの方が設定が簡単で、画面で状態も追えます。一方、込み入った条件分岐、データ変換、エラーハンドリング、3つ以上のサービスをまたぐ連携にはClaude Codeが向いています。両者を併用するケースも多く、基本的な連携はiPaaSで、込み入った処理はClaude Codeで作るハイブリッド構成も有効です。

Q4. freee × HubSpotの連携に必要なAPIキーはどう取得しますか？

freeeは、freeeアプリストアでアプリを作成し、OAuth 2.0の認証フローでアクセストークンを取得します。

Q5. APIキーはどのように管理すればよいですか？

APIキー・トークンは環境変数（.env ファイル）で管理し、Gitリポジトリにはコミットしないでください。Claude Codeの設定ファイル（.claude.json）にも直接書き込まず、環境変数から読み込む設計にします。チームで運用する段階では、シークレットマネージャー（AWS Secrets Manager等）の利用をおすすめします。

まとめ

本記事では、Claude Code × API連携によるfreee・HubSpot・Slack・Notion・Google Calendarの業務システム自動化について、基本アーキテクチャから運用の設計までを解説しました。このテーマの全記事はClaude Code実践ガイドでご覧いただけます。

ポイントを振り返ります。

• 連携は個別の便利ワザとしてではなく、「コンタクト→取引→顧客→請求」という全体フローの中で、手作業が残っている箇所を起点に選びます
• 主要サービスはMCPで接続し、定期実行やWebhook起点の処理はAPI直接呼び出しで補うハイブリッド構成が扱いやすい形です
• 自動化の精度はCRMのデータの質で決まるため、パイプラインのステージ定義と必須入力プロパティを先に整えます
• Quote-to-Cashのような横断的な連携は、ステップごとにスクリプトを分け、データの正本を1か所に決めて一方向に流します
• リトライ・べき等性・エラー通知に加え、連携の一覧・対応表・復旧手順を残し、作った人がいなくても回る状態にします

まずは、HubSpotかfreeeのどちらか1つをMCPで接続し、読み取りだけの集計から始めてみてください。次の3ステップで進めると、無理なく広げられます。

1. 毎月手作業で作っている集計を1つ選び、Claude Codeへの指示で同じ結果が出るか試す
2. HubSpotとfreeeの項目の対応表を作り、対応が取れない項目を経理担当者と一緒に整理する
3. HubSpot → Slackの受注通知のような片方向の連携を1本作り、エラー通知と二重実行防止まで試す

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• MCP × freee連携ガイド｜AIエージェントで会計データを自動処理する方法
• MCP マルチツール統合の設計方法｜CRM・会計・チャットを一つのAIで操作する
• HubSpot MCP Serverの活用ガイド｜AIエージェントからCRMデータを操作する方法
• Claude Code × MCP連携ガイド｜外部ツールとAIをつなぐ設定と活用法
• AI経理・会計業務の自動化｜仕訳・請求・経費精算をAIエージェントで効率化する方法