HubSpotに進行中の商談、boardに将来の請求予定、freeeに入金実績が分かれていると、売上見込みと資金繰りを同じ基準日で見られません。ChatGPTやClaudeへ接続する前に、三つのサービスが持つ同じ取引を対応付ける必要があります。
取引先名だけで三つのデータを結ぶと、同じ取引先で並行する別の商談や請求を一件にまとめ、売上見込みや入金予定を二重計上するおそれがあります。そこで、サービスごとのIDを使って同じ取引を対応付けます。
こうした準備を経たうえで直面するのが、AIを用いた分析をどの方法で始めるかという判断です。手元の少量のデータを直接分析して済ませるか、あるいは反復実行や過去の履歴・監査が必要と見込んで自社DBへのデータ同期へと移るのかが中心的な問いとなります。まずは一つの代表取引を用いた試行結果と自社の履歴要件を照らし合わせ、どちらの経路から開始するかを選択します。
三つのSaaSを接続する前に、同じ取引を対応付ける
HubSpot、board、freeeの三つのサービスに分散しているデータを統合して分析するためには、それぞれのシステムから抽出したデータをどのようにつなぎ合わせるのかをあらかじめ決める必要があります。分散したデータをどう扱うかという大きな悩みを、まずは「一つの代表的な取引をどのように対応付けるか」という最小の検証単位へと変えていきます。
異なるシステム間でデータをつなぐ際、共通項目として取引先名を利用しがちです。しかし、取引先名だけで結合することは避けてください。同じ取引先で複数の商談や請求が進むと、対応関係を特定できないためです。
各システムが発行する一意の識別子（ID）を列に並べ、レコードを対応付けます。
具体的には、HubSpotの進行中取引を表すDealから「deal ID」を取得します。boardでは、見積書や請求書が案件に紐づくため、「案件ID」と、案件から発行された各「請求書ID」を取得します。一つの案件から複数の請求書が発行される場合は、一つのセルへ押し込まず、請求書ごとに行を分けます。
freeeでは事業所IDを選び、収支方向・勘定科目・決済状況を持つ取引から「取引ID」を取得します。請求書一件に分割入金がある場合は、請求書IDとfreeeの取引IDを一対一と決めつけず、入金単位の対応を別行で記録します。分析用テーブルには「deal ID」「案件ID」「請求書ID」「取引ID」を並べ、同じ取引の対応関係と、一対多になる箇所を残します。
売上予測やキャッシュフロー分析では、時系列の基準日と金額の状態もそろえます。各システムが持つ日付データは、HubSpotの予定成約日（closedate）、boardの請求日や支払期限、freeeの入金日と、それぞれ意味が異なります。分析の目的ごとに、どの日付を基準にするか決めます。
取得したamount、closedate、dealstageなどから、これから発生する「予測値」と請求・入金済みの「確定値」を分けます。
データが存在しない場合、未入力値はnullになりうるため「欠損」として扱います。識別子と基準日をそろえると、代表取引が三つのサービスで同じ対象を指すか確認できます。
HubSpot・freee・boardのAPIは認証と契約が異なる
データを紐付ける列が決まったら、誰がどの権限で取得するかを確定します。システムごとに異なる認証方式と契約条件を確認してから、接続を設定します。
SaaS側のAPI利用契約とAI側の課金体系は分けて管理します。HubSpot、freee、boardのAPIを利用する権限や制限は、各SaaSの契約に依存します。ChatGPT・Claudeの月額利用料やモデルAPIの従量課金は、三社のSaaS契約とは別の認証・請求経路です。
3つのサービスはそれぞれ異なる認証主体と方式を採用しており、利用条件や制限も異なります。以下の比較表に各社の違いをまとめます。
| サービス | 認証方式とアクセストークン | 利用条件 | API利用料とAI課金の境界 | API制限 |
|---|---|---|---|---|
| HubSpot | 単一認可アカウントの静的BearerトークンとOAuthを用途で分ける | 契約プランで上限が変わる | HubSpotの契約枠を使い、追加枠はAPI Limit Increaseとして契約する。モデルAPIの従量課金は別 | 私的アプリはFree/Starterで10秒100回・日25万、Professionalで10秒190回・日62万5千、Enterpriseで10秒190回・日100万 |
| freee | OAuth 2.0 Authorization Codeで事業所を選び、アクセストークンは6時間、Bearerで利用する | freeeの契約と事業所権限が必要 | freeeのデータ利用契約と、モデルAPIの従量課金は別 | 取得対象とアプリ種別ごとの条件を確認する |
| board | APIキーとAPIトークンをヘッダーに付与 | 有料登録アカウントで管理者などが認証情報を発行する | boardの有料契約枠を使い、モデルAPIの従量課金は別 | 1日3000、1秒3、リスト同時4、超過は429、上限緩和なし |
HubSpotの認証は、単一認可アカウントの静的BearerトークンとOAuthを用途で分けます。リクエスト制限はプランごとに異なります。
私的アプリはFree/Starterで10秒100回・日25万、Professionalで10秒190回・日62万5千、Enterpriseで10秒190回・日100万です。
freeeの認証は、OAuth 2.0 Authorization Codeで事業所を選び、アクセストークンは6時間、Bearerで利用する仕様です。対象となる企業の事業所を正確に指定してデータを取得する必要があります。
boardは、有料登録アカウントの管理者などがAPIキーとAPIトークンを発行します。上限は1日3000回、1秒3回、リスト取得の同時実行4回です。超過時は429が返り、上限緩和はありません。
三社の最小APIリクエストで代表データを保存する
前節までに整理した各SaaSの認証条件を、読者が手元の環境でそのまま再現できる具体的なデータの読み取り手順へ変えていきます。ここでは専用のCLI製品や独自のSDKを用いず、標準的なコマンドラインツールである curl を使って、HubSpot、freee、boardの3社から最小のAPIリクエストで代表データを取得します。
セキュリティを担保するため、実在するAPIキーやトークンなどの秘密値をコード内に直接書くことはしません。すべて $HUBSPOT_ACCESS_TOKEN のような環境変数名として参照し、手元のターミナルに一時的に設定してから実行する前提とします。
HubSpotの商談を取得する
HubSpotからは売上予測の基礎となる案件データを取得します。エンドポイントは GET https://api.hubapi.com/crm/objects/2026-03/deals を使用し、取得したい項目を properties パラメータで指定します。商談取得にはBearer認証とcrm.objects.deals.readスコープが必要です。
curl -X GET "https://api.hubapi.com/crm/objects/2026-03/deals?properties=amount,dealstage,closedate" \
-H "Authorization: Bearer $HUBSPOT_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-o hubspot-deals.jsonリクエストが成功すると、200の応答コード、results配列、次ページを示すpaging情報が返ります。JSONはhubspot-deals.jsonへ保存します。
応答内のdeal IDをsource_record_id、実行時刻をretrieved_atとして記録します。トークンが無効なら401、スコープ不足なら403、上限到達時は429が返ります。
freeeの事業所と取引を取得する
freeeから取引データを取得する前に、事業所一覧からcompany_idを確認して取引を取得する手順を使います。選んだIDをdealsへ指定します。
最初のGETリクエストで事業所一覧を取得し、結果を freee-companies.json へ保存します。
curl -X GET "https://api.freee.co.jp/api/1/companies" \
-H "Authorization: Bearer $FREEE_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-o freee-companies.json保存された freee-companies.json を確認して自社の company_id（例として 1234567）を特定したら、そのIDをクエリパラメータに指定して取引一覧を取得します。
curl -X GET "https://api.freee.co.jp/api/1/deals?company_id=1234567" \
-H "Authorization: Bearer $FREEE_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-o freee-deals.jsonリクエストが200で成功すると、取引データがfreee-deals.jsonへ保存されます。取引IDをsource_record_idとして保存し、取得プログラムがretrieved_atを付けます。
freee Public APIの共通仕様に沿って、トークン失効や権限不足などの4xx応答を記録します。失効時はリフレッシュトークンで更新して再実行します。
boardの案件を取得する
最後に、boardから請求と売上見込みを管理する案件（Projects）を取得します。取得する情報の粒度は、クエリパラメータのresponse_group=mediumで指定します。boardの認証ではx-api-keyとBearer形式のAPIトークンを両方送信します。
curl -X GET "https://api.the-board.jp/v1/projects?response_group=medium" \
-H "x-api-key: $BOARD_API_KEY" \
-H "Authorization: Bearer $BOARD_API_TOKEN" \
-H "Content-Type: application/json" \
-o board-projects.json正しい情報で実行できれば200応答が返り、結果がboard-projects.jsonに保存されます。案件IDをsource_record_idとして保存し、取得プログラムがretrieved_atを付けます。
無効なキーでは401、権限がなければ403、リクエスト過多では429が返ります。Content-Typeが不正と判定されると415が返ります。
これらの最小リクエストでエラーを回避し、200応答とともに3社別の代表ファイルをローカル環境へ保存できれば、分析用データをAIへ渡す準備が整います。
ChatGPT・Claudeへは秘密情報ではなく分析用データを渡す
前節で保存したJSONファイルには、システムの内部IDや分析には不要なデータも多数含まれています。これをそのままAIへ渡すのではなく、保存したJSONを秘密情報から切り離した分析入力へと変える工程が必要です。最も重要な前提として、取得プログラムが利用したSaaSトークンなどの秘密情報を、ChatGPTやClaudeのチャット画面へ貼らないでください。
ここでは、自社取得プログラムと利用者の役割分離を行います。自社の取得プログラムがHubSpot、freee、boardがそれぞれ要求する認証の秘密情報を保持し、API経由でデータを取得・保存します。そして、人間である利用者がChatGPTまたはClaudeを起動し、チャット画面から分析を指示するという役割分担です。
利用者がチャット画面からAIへ分析用データを渡す確実な経路は、ファイル添付です。3つのJSONから売上予測やキャッシュフロー分析に必要な列だけを抽出し、CSVまたはanalysis-input.jsonへ変換した上で、利用者が手動でチャット画面に添付して渡します。
ファイル添付のほかに、AIサービスが提供する公式コネクターも選べます。ChatGPTでは、利用者がSettingsのAppsで対象を選びConnectし、OAuthを完了後、チャットで@メンションまたは+から選びます。利用できるコネクターは地域、プラン、管理者設定によって異なります。
Claude経路の場合もコネクター機能があり、公式のHubSpotコネクターを利用できます。この連携では、HubSpot利用者が許可されたCRMデータだけをClaudeで参照する仕組みとなっており、HubSpot側で設定された権限範囲が適用されます。
2026年9月1日時点で確認したChatGPTとClaudeの公式コネクター資料には、freeeとboardを同じチャットから参照する接続方法は掲載されていません。そのため、チャット画面で3サービスを横断する場合は、必要な列をCSVやanalysis-input.jsonへ変換し、利用者が添付する方法を既定の経路にします。
ブラウザのチャット画面を使わず、自作プログラムからOpenAI APIまたはAnthropic APIなどのモデルAPIを呼び出す経路もあります。
自作プログラムが3社の分析用データをモデルAPIへ送り、ChatGPTやClaudeの月額プランとは別のAPI認証と従量課金を使います。誰がAIを起動し、どの認証を使い、何を渡すかを経路ごとに分けます。
売上見込みと資金繰りを一つの実行例で照合する
抽出したデータを用いて、経営管理部門が向こう8週間の資金不足候補を探します。この記事では、各週の開始残高に確定・予測入金を足し、支払予定を引いた週末残高が0円未満になる状態を「資金不足候補」とします。「高確度商談の成約遅れ、または請求・入金遅れが不足要因になる」という仮説を、3つのシステムのデータで検証します。
AIへ渡すanalysis-input.csvには、各システムから抽出した入力列を含めます。HubSpotのdeal ID、amount、closedate、dealstage、pipelineを商談進捗の指標として入力します。営業責任者が社内基準で決めた成約確度をclose_probability列へ0から1の小数で加えます。
boardは案件に紐づく請求書の案件IDと書類IDに、請求額、請求日、支払期限を加えます。freeeは取引の収支方向、勘定科目、決済状況を取得します。取引額、取引日、決済日も保存し、入金済みと未決済を区別します。
キャッシュフロー計算には、基準日時点の現預金残高と、向こう8週間の支払予定額・支払予定日も必要です。会計責任者が確認した開始残高をopening_cash_balance、支払予定をscheduled_outflow_amountとscheduled_outflow_dateとして同じCSVへ入れます。
第1週は開始残高を使い、第2週以降は前週の週末残高を繰り越します。
管理部門の担当者は、ChatGPTまたはClaudeの画面で新しいチャットを開き、入力欄の添付ボタンからこの analysis-input.csv を添付する画面操作を行います。ファイル添付後、以下のコピー可能な日本語依頼文を入力して分析を指示します。
添付したCSVファイル（HubSpotの商談データ、boardの請求データ、freeeの取引データ）を分析してください。
目的：向こう8週間で週末残高が0円未満になる資金不足候補を見つけること
仮説：高確度商談の成約遅れ、または請求・入金遅れが不足要因である
計算方法：第1週はopening_cash_balance、第2週以降は前週の週末残高を開始残高にする。同じ取引は次の優先順位で一度だけ計上する。freeeの入金済み額は確定入金とする。boardの請求書がある場合は、請求額からfreeeの入金済み額を引いた未回収額を支払期限の予測入金とする。未回収額が0円以下なら予測入金へ加えない。boardの請求書がない場合だけ、HubSpotのamountにclose_probabilityを掛けた額をclosedateの予測入金とする。各週の開始残高に予測入金と確定入金を加え、支払予定を引いて週末残高を計算する
以下の内容を出力してください。
1. 向こう8週間の週別入金予測・確定値、支払予定、週末残高
2. 予測と確定値の差異理由候補
3. 反証に必要な原本のID（deal ID、案件ID、書類IDなど）
4. データから読み取れない未確認項目
※自動仕訳や資金繰りの最終的な判断は行わず、あくまで事実の整理と候補の提示のみを行ってください。AIは週別予測・確定値、差異理由候補、反証に必要な原本情報、未確認項目を出力します。ただし、仕訳や資金判断は確定しません。差異理由候補が正しいかどうかは、管理部門の担当者が原本を使って反証します。
反証では取引の取消と分割入金を確認します。税区分、通貨、データ欠損の違いも見ます。単純なデータ行だけでは判別できない場合があるためです。
担当者は出力されたIDから原本を開きます。HubSpotの担当者メモで遅延理由を探り、board請求書で金額と宛先を確かめます。freee会計では決済状況と未決済額を目視します。
差異の理由が明らかになったら、更新権限を持つ担当者が記録を直します。営業担当者はHubSpotの商談ステージや予定成約日を更新し、請求担当者はboardの請求日や支払期限を修正します。会計担当者はfreeeの決済状態と未決済額を原本に沿って確認します。
8週間以内に週末残高が0円未満になる候補が残る場合は、会計責任者が入力した開始残高と支払予定を原本で再確認し、検討する資金対応案を決めます。AIへの受け渡しから候補出力、原本確認、業務判断までがここでつながります。
直接接続から自社DBへ移る条件を決める
前節までの代表取引を用いた試行結果から、継続運用の方式を選びます。対象データが少量で、分析が単発であり、過去時点の再現が不要なら、3サービスから作ったCSVをChatGPTまたはClaudeへ添付して代表取引1件を照合します。HubSpotだけを参照する試行では、利用条件を満たす公式コネクターも選べます。
週次の反復実行や過去の予測値と実績の比較が必要になったら、自社DBへ移ります。複数部門での共有、監査ログ、前提を変えた再計算が必要な場合も同じです。
| 判断の軸 | 直接接続（Apps・コネクター・CSV） | 自社DB（データ基盤） |
|---|---|---|
| 頻度・データ量 | 少量かつ単発の実行 | 週次反復や大容量データの処理 |
| 履歴・再現性 | 過去時点での再現は不要 | 過去時点の履歴比較・再計算が必要 |
| 監査・共有 | 担当者レベルでの一時的な利用 | 複数部門での共有・監査ログが必要 |
| AIへの経路 | チャット画面へ直接ファイルを渡す | 読取専用ビューや抽出した分析ファイル |
自社DBで3サービスのデータを統合する場合は、生データの由来を追跡できるようにします。テーブルにはsource_systemとsource_record_idを置き、retrieved_atとas_of_dateも保存します。
加工前の元値とデータ変換規則も残します。AIがDBを直接書き換えないよう、読取専用ビューを設けるか、分析用ファイルを生成して渡します。
定期同期では、各SaaSのAPI制限を考慮します。HubSpotには契約階層別の日次・短時間制限があります。boardは1日3000回、1秒3回、同時取得4回が上限です。
毎回全件を取得せず、更新日時などで差分を取得します。freee会計のWebhookを使う場合は、通知の事業所と対象情報を受け取り、該当レコードを会計APIから取得します。
最後に、生成AIが出力した売上予測や資金繰りの結果も自社DBに保管します。実行日時、基準日、入力SHA（ハッシュ値）を保存します。AIへ送信した依頼文と最終確認者も履歴へ残し、予測の過程を後から追えるようにします。
よくある質問
Q1. ChatGPTやClaudeの月額契約と自作AI API課金の違いは何ですか？
チャット画面を利用する月額プランと、自作プログラムから呼び出すモデルAPIは別の認証・請求経路です。ChatGPTを利用する場合、Appsの可否はプラン、地域、管理者設定で異なりOAuth接続を使う仕組みになっています。
一方、自社DBの構築後に独自のAI APIを利用する場合は、モデルへのリクエスト単位で従量課金が別途発生するため、自社の利用経路に合わせて契約を分けて管理してください。
Q2. SaaSのアクセストークンをチャットへ貼ってはいけない理由は何ですか？
自社システムへのアクセス権を意図せず外部へ漏らすリスクがあるためです。たとえばfreeeのOAuthではアクセストークンはBearerで使い6時間で更新が必要ですが、トークンを取得した第三者は、有効期間内に付与された権限の範囲でAPIリクエストを送れるおそれがあります。
トークンは自社取得プログラム側で安全に保持し、AIへは秘密情報を含まない分析用ファイルのみを添付して渡す運用を徹底してください。
Q3. 3サービスのデータを毎日同期すべきですか？
毎日かどうかだけでは決められません。各SaaSには厳格なリクエスト上限が設けられており、特にboardのAPIにおいては1日3000、1秒3、同時取得4で上限緩和なしと定められています。自社DBと同期する際は、毎回すべてのデータを取得するのではなく、更新日時を用いた差分取得やWebhook通知を活用し、上限エラーを回避できる頻度と方法を設計してください。
Q4. ID対応がない既存データはどのように扱えばよいですか？
HubSpotのdeal IDやboardの案件IDなどが紐付いていない過去データは、AIに同じ取引だと自動判定させないでください。推測でのデータ結合は避け、「対応付けができない欠損データ」として明確に区別します。実際の分析においては、ID対応が保証されたシステム導入後のデータのみを使用するか、事前に手動でIDの紐付け作業を行うかを判断してください。
Q5. AIの予測を会計判断としてそのまま確定できますか？
確定できません。AIの出力は、複数のデータから整理した事実と差異理由の候補提示に留まります。自動仕訳や最終的な資金対応の判断を行う前には、提示された原本IDをもとに担当者が必ず手動で確認を行ってください。取引の取消、分割入金、税区分の相違など、データ行だけでは見抜けない例外事象を人が目視で反証してから、はじめて業務上の判断を下します。
調査手法について
こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。
Screenshot
調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。
また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。
ご利用をご希望の方は、こちらよりお申し込みください。
また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。
市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai
コメント