AI API活用ビジネスガイド｜HubSpot連携と導入設計の進め方

2026年3月7日
最終更新: 2026年10月12日

この記事の結論

AI API活用とは、AIの処理を自社の業務システムにつなぎ、情報の整理や判断補助を業務フローに組み込むことです。入力から結果の確認、次の担当者への引き継ぎまでを設計することが要点です。

ブログ目次

「ChatGPTをブラウザで使っているが、毎回コピーして貼り付ける作業を減らしたい」
「CRMに登録した顧客情報を、手作業で別の画面へ移して分析している」
「AIの回答を業務に使いたいが、誰が確認し、どこに記録するか決まっていない」——

こうした課題を考えるとき、APIでAIを呼び出せるかだけを調べても、業務への組み込み方は決まりません。まず、何を入力し、どの結果を人が確認し、確認後に何を記録するかを決める必要があります。

AIに参照させる情報の整え方を詳しく知りたい方は「ファインチューニングの企業活用ガイド」をご覧ください。活用方法を広く整理したい方には、AI活用完全ガイドも参考になります。

この記事でわかること

AI APIを自社システムやHubSpotワークフローに組み込みたい開発者・DX推進担当者に向けて、対象業務を選ぶ順序、サービスの比較方法、結果を人に渡す条件、運用を見直す場面を説明します。読み進めながら、自社の問い合わせを例に「何をAIに任せ、どの結果なら担当者が採用できるか」を具体化できます。

AI APIの選び方 — OpenAI、Claude、Geminiを、同じ業務サンプルと評価基準で比較する方法を整理します。
HubSpotと連携する方法 — コネクターアプリ、カスタムコード、Webhookについて、必要な入出力と管理方法から使い分ける手順を示します。
業務に組み込む手順 — 対象業務、入力情報、出力形式、確認担当を決め、判定不能やエラーを扱うところまで解説します。
運用で決めること — APIキーの管理、結果確認、再処理、費用と品質の見直し方を説明します。

自社の業務に当てはめる際は、最初に「入力の原文を担当者が確認できるか」を確かめてください。そのうえで、期待する結果と採用できない結果を書き分けると、サービス比較から運用まで同じ基準で検討できます。

AI APIの活用は業務フローの設計から始めます

モデルを比較する前に、どの作業を変えたいのかを明確にします。スプレッドシートから情報を転記し、担当者が個別に要約や分類をしているなら、転記前の入力と、結果を受け取った後の作業も確認します。前後の工程が決まれば、AIに渡す情報と結果の記録先を選べます。

業務の段階	AIと人の役割を決める観点
情報が入る	処理に必要な入力項目を選ぶ
整理する	要約や分類の出力形式を決める
判断する	事業上の責任を伴う判断は担当者に残す
引き継ぐ	結果の記録先と次の担当を決める

手作業のどこにAIを置くか決める

現在の業務を次の段階に分けます。

情報が入る
内容を整理する
判断する
次の担当へ渡す

問い合わせ対応なら、フォーム送信後に内容を分類し、担当者が分類結果を確認してからチケットに記録し、担当チームへ引き継ぐ流れが考えられます。

各段階について、担当者が実際に参照する情報と、次の作業を始める条件を書き出します。たとえば分類結果を引き継ぎに使うなら、「分類名」だけで足りるのか、問い合わせの原文や判断に使った箇所も必要なのかを確認します。引き継ぎ先が原文を確認できない場合は、先に参照方法を整えます。

AIに任せる作業は、入力と期待する出力を言葉にできるものから選びます。

受注可能性の判断や顧客への最終回答など、事業上の責任を伴う判断は担当者が行います。

期待する出力を定義できない場合は、連携方法を選ぶ前に、担当者が現在使っている判断基準を整理します。

対象を選ぶときは、担当者が実際に行った処理をたどり、次を分けます。

原文から確認できる整理 ── 問い合わせの内容を短くまとめる作業なら、原文との照合方法を決めて試せます
顧客や取引に影響する判断 ── 対応の優先順位を決める作業では、何を優先するかの基準と最終判断者が定まるまで、AIの出力を参考情報として扱います

既存の管理表をそのまま自動化しない

スプレッドシートに項目や例外処理が積み重なっている場合は、各項目が現在の判断や引き継ぎに必要かを確認します。必要性を説明できない項目は入力候補から外し、後続業務に必要と分かったものを選び直します。

項目ごとに、次を確かめます。

誰が入力するか
何の判断に使うか
情報が空欄ならどうするか

用途が同じ項目や、担当者によって意味が異なる項目があれば、AIへ渡す前に定義をそろえます。空欄をAIの推測で埋める運用にはせず、確認を求める経路を決めます。

HubSpotを使う場合は、コンタクト、会社、取引、チケットのうち、どのレコードに必要な情報があるかを調べます。AIの出力を保存するプロパティも、後続の担当者が参照する目的から決めます。記録先を決められない出力は、保存項目を増やす前に用途を見直します。

たとえば「問い合わせ種別」という項目が管理表とチケットの両方にあるなら、どちらを担当者が更新し、どちらを引き継ぎに使うかを確認します。意味や更新の責任者がそろわない状態でAIの結果を書き込むと、担当者がどの値を採用すべきか判断できません。入力元と採用結果の記録先が定まってから、連携する項目を確定します。

小さな処理から運用を広げる

最初の対象は、結果を人が元情報と照合でき、誤りがあれば後続の処理を止められる作業から選びます。例えば、問い合わせ文の要約を担当者向けに表示し、分類結果は確認後にチケットへ反映する形です。

試す際は、通常の問い合わせだけでなく、次のものを用意します。

必要な情報が欠けたもの
分類が分かれそうなもの

担当者が原文と出力を見比べ、採用・修正・判断保留のいずれかを選べる状態にします。判断保留の扱いが決まらなければ、担当振り分けの自動化には進めません。

たとえば「料金を知りたいが、ログインもできない」という問い合わせでは、料金と技術的な問題の両方を担当者に示します。どちらの担当へ先に渡すかが決まっていなければ、AIに一方を選ばせず判断保留にします。先に扱う内容と引き継ぎ先を担当者が決め、同じ種類の問い合わせで判断が分かれないよう基準に反映します。

この例を試すときは、次を一緒に記録します。

原文
AIが示した両方の意図
担当者が決めた対応順
実際の引き継ぎ先

AIが料金だけを抽出したなら出力の欠落、両方を抽出したのに一方へ自動で振り分けたなら後続処理の条件を見直します。

原因を分けて確認できれば、プロンプトを直すべきか、振り分けを確認待ちにすべきかを判断できます。

運用中は、入力情報の不足、分類に迷った理由、担当者による修正を記録します。それぞれ次のように対応します。

情報不足 ── 入力項目を見直す
分類の解釈が分かれる ── 基準をそろえる
元情報にはない内容が出る ── その結果を採用しない手順を整える

担当者が採用できなかった結果も扱えるようになってから、通知や担当振り分けへの利用を検討します。

OpenAI、Claude、Geminiは業務要件で選びます

サービス名や一般的な評価だけで選ばず、対象業務の入力例と期待する出力を用意します。同じ情報を使い、日本語の表現、必要な情報の保持、社内システムとの接続条件を比べます。利用できる機能や条件は、自社の契約・利用環境で確認します。

比較する観点を決める

次の表は、各サービスを調べる際の観点を整理したものです。表に挙げた処理や連携を利用できるかは、導入時に各サービスの提供条件と利用環境で確認します。

判断項目	OpenAI	Claude	Gemini
主な選定観点	開発資料やツール連携の活用	長文の分析や文章の確認	画像・動画・音声を含む処理やGoogle環境との連携
試す業務	問い合わせ分類、要約、ツール利用	長文資料の整理、レコード要約	画像などを含む情報の整理
選定時の確認	必要なAPI機能と利用条件	入力できる情報と応答形式	使うサービスとデータ処理条件

まず、自社の処理に必要な入力、出力、接続方法を定め、候補となるサービスで扱えるか確認します。条件を満たすものに同じ業務サンプルを渡し、担当者が結果を確認・修正しやすいかまで比べます。必要な入力を扱えない、または結果を後続業務へ渡せない場合は、文章の出来だけで採用しません。

比較前に、候補を外す条件も明記します。たとえば、次の場合です。

必要な情報を入力として扱えない
所定の形式で結果を受け取れない
担当者が原文と照合できない

これらを満たす候補の間で出力内容を比べると、文章の印象だけに選定が左右されにくくなります。

候補を絞る順序は次のとおりです。

まず必要な情報を扱えるか
次に後続業務で使う形で返せるか
最後に担当者が内容を採用できるか

いずれかで止まる場合は、その理由を入力・出力・確認方法のどこにあるか記録します。比較するサービスを変える前に、業務要件そのものが明確かを確かめられます。

同じ入力と評価基準で確認する

問い合わせ分類なら、想定カテゴリへの一致だけでなく、判断の根拠となる文面、判定できない場合の返答、CRMへ保存しやすい形式を確認します。通常の問い合わせに加え、情報が不足したものや、複数のカテゴリにまたがるものも同じ条件で試します。

比較用の記録には、次を並べます。

問い合わせの原文
担当者が期待する扱い
各サービスの出力
採用・修正・判断保留の結果
修正理由

たとえば料金と技術的な質問が同じ文面にある場合、どちらかへ強制的に振り分けるのか、複数の意図として人に渡すのかを先に決めます。どの候補にも同じ扱いを求めます。

担当者ごとの判断をそろえるため、結果の扱いも先に定義します。

採用 ── 原文と一致し、必要な情報が残っている
修正 ── 原文を見て正しい分類や要約に直せる
判断保留 ── 入力不足や複数の意図によって行き先を決められない

顧客対応の行き先を誤る分類や、原文にない事実を加えた要約はそのまま採用しません。原文にも情報がなければAIの出力で補わず、担当者の確認事項として残します。

比較を始める前に、どの誤りなら担当者の修正で扱え、どの誤りなら後続処理を止めるかも決めます。たとえば次のとおりです。

表現の言い換え ── 原文と照合して修正できる
原文にない契約条件を要約へ加えた結果 ── 確認前に顧客向け文面や振り分けへ渡さない条件にする
判定不能を示すべき入力で断定した場合 ── その理由を記録して確認待ちに戻す

各サービスの出力を比べる際は、結果だけでなく、原文のどの箇所を根拠にしたか、担当者が何を直したか、その修正で後続の引き継ぎ先が変わるかを記録します。同じ原文に対する期待結果が担当者間で異なるなら、サービスの優劣を決める前にカテゴリの定義を合わせます。

採用できなかった原因も分けます。

原文に必要な情報がない場合 ── 入力側を確認する
情報はあるのに出力から抜けた場合 ── 指示と出力形式を確認する
分類名は正しいのに記録できない場合 ── 連携方法を確認する

原因に応じて直す場所を変え、同じサンプルで再確認してから候補を選びます。

比較を終える条件は、担当者が採用できる結果を得られることに加え、修正と判断保留を後続業務から区別できることです。判定不能の入力を人へ渡せない候補は、通常の入力で良い結果が出ても、担当振り分けに使う候補としては保留します。入力や指示を直した場合は、問題になった入力だけでなく、これまで採用できた入力でも扱いが変わらないか確かめます。

料金表の数値だけで決めない

API費用を比較するときは、自社の業務サンプルで必要な品質を満たすかを先に確認します。品質の条件を満たした候補について、各社の公式料金と利用条件を確認し、想定する入力、出力、呼び出し方に沿って費用を見積もります。

同じサンプルでも、入力に含める情報や、判定不能時に再確認する方法が違えば、実際の処理内容は変わります。費用を比べる際は、比較時に使った入力範囲と処理手順をそろえ、担当者が結果の確認や修正に要する作業も記録します。必要な品質を満たさない候補は、見積額だけを理由に選びません。

分類と文章作成では求める品質や担当者の確認内容が異なります。処理ごとに結果、修正の手間、利用条件を比較します。通常の処理に加え、次も同じ業務単位で整理します。

判定不能時の確認
エラー後の再処理
設定の管理

一つの処理では適していても、別の処理で修正や確認が難しければ、用途を分けて選びます。

料金や業務量の条件が変わったときは、同じサンプルと評価基準で選択を見直します。その際はAPIの利用額だけでなく、担当者が採用までに行う作業と、採用結果が後続業務で使われているかを確かめます。

HubSpotでは対象レコードと後続業務を決めます

HubSpotのワークフローにAI APIを組み込む構成を検討する場合は、どのレコードを起点にし、結果をどこへ残すかを先に決めます。コンタクトやチケットの情報を取引や顧客対応へ渡すなら、各段階で人が確認する内容も明確にします。請求関連の業務で結果を参照する場合は、その判断に必要な情報と責任者を別に定めます。

ワークフローで情報を順につなぐ

問い合わせ対応なら、フォームから入った情報を起点に要約・分類の結果を作り、担当者が元の問い合わせと照合する流れを設計できます。採用した結果をCRMに記録し、担当チームへの通知や引き継ぎに使います。営業に関連する問い合わせであれば、担当者の確認後に取引管理やフォローアップへつなげるかを決めます。

記録先を選ぶときは、後続の担当者が次を区別して確認できるかを見ます。

元の問い合わせ
AIの出力
採用した結果

確認待ち、採用、修正、判断保留のどの状態かも分かるようにします。その区別ができない場合は、自動で次の処理へ進める前に記録方法を整えます。

担当者が分類を修正した場合、後続業務では採用した結果を使います。修正前の出力が通知や振り分けに残っていないか、テスト用のレコードで開始条件から引き継ぎまでたどって確かめます。

ワークフローの開始条件も、記録先と合わせて確認します。問い合わせ内容が変更されたとき、すでに担当者が採用した結果があれば、新しい入力による確認を求めるのか、進行中の対応を優先して保留するのかを決めます。その扱いが決まるまでは、再実行した結果で採用済みの値を上書きしません。

連携方法の違いを見て選ぶ

連携方法は、必要な入力と出力、処理を置く場所から選びます。まず、利用可能なコネクターアプリで必要な処理と記録ができるかを確認します。不足する要件が明確になったら、カスタムコードやWebhookを使う構成を検討します。

方法	向いている状況	設計時に見る点
コネクターアプリ	標準的な要約・分類など、対応アプリの機能で足りる	対応する入力、出力、接続設定
カスタムコード	独自ロジックや複数項目への書き込みが必要	実行環境、秘密情報、エラー処理
Webhook	外部サーバーで前後処理を行う	認証、応答形式、再処理方法

方法ごとに、次を確認します。

必要な入力を取り出せるか
判定不能を担当者へ渡せるか
採用結果を所定のレコードへ記録できるか

いずれかができない場合は、その要件を満たす構成を調べます。どの方法でも、エラー時に元の問い合わせを見失わず、担当者が対応を続けられることを確認します。

カスタムコードを検討する場合は、実装方法を決めつけず、必要な入力・出力、秘密情報の扱い、エラー時の対応を整理します。そのうえで、自社のHubSpot環境で利用できる機能、利用条件、実行環境をHubSpotの公式資料と管理画面で確認してください。要件を満たせない場合は、外部サーバーで処理する構成と比べます。

構成を比べる際は、通常時の出力だけでなく、判定不能と接続エラーを担当者がどこで知るかを同じ条件で確認します。結果を保存できても、エラーを確認する場所がなく対応が止まるなら、連携方法の選択は終わりません。運用担当者が設定と障害時の対応を引き受けられる状態まで確かめます。

たとえば分類結果の保存はできても、判定不能を表す状態を残せない構成なら、担当者は未処理と処理失敗を見分けられません。その場合は状態の記録方法を先に決め、テスト用の問い合わせで担当者への通知まで確認します。状態を区別できてから、後続の振り分け条件を設定します。

利用できる仕組みから始める

利用可能なコネクターアプリがあり、必要な処理が対応範囲に収まる場合は、テスト用の入力で試します。渡せる項目、受け取る結果、記録先を確認し、担当者が元情報と照合できるかを見ます。

次の場合は、それぞれ対応を決めます。

必要なデータを渡せない場合 ── どの項目が欠けるかと、その項目が判断に必要な理由を記録する
結果を記録できない場合 ── 担当者が確認する場所と後続業務で使う場所を確認する
エラー時に担当者が処理を続けられない場合 ── 元の問い合わせを参照する方法と連絡先を決める

不足点を整理したうえで、カスタムコードまたは外部サーバーで扱えるか調べます。テストでは、正常な結果に加え、判定不能と接続エラーも確認します。結果を区別して記録でき、運用担当者が接続設定と障害時の対応を管理できる方法を選びます。

テスト範囲を広げる前に、元の問い合わせ、AIの提案、担当者が採用した結果、エラー時の状態を同じレコードから追えるか確かめます。途中で追跡できなくなるなら、その段階の表示先か記録先を直してから次へ進みます。

AIの出力は人が確認できる形で業務に渡します

自動化する範囲は、結果が次の業務に与える影響に合わせて決めます。要約や分類は担当者の準備に使い、顧客への送信や取引上の判断に進む前には確認を置きます。保存先だけでなく、確認担当、元情報との照合方法、誤りを見つけた場合の修正方法を決めます。

リード情報の要約は確認用の項目にする

フォームから登録された会社名、業種、問い合わせ内容を要約し、コンタクトまたはチケットで担当者が確認する構成を考えます。プロンプトには、次を明記します。

要約の目的
含める項目
情報がない場合の扱い

担当者が元の入力に戻れないなら、要約だけを判断材料にせず、参照方法を先に整えます。

担当者は、後続の対応に必要な情報が残っているか、入力にない事実が加わっていないかを見ます。たとえば問い合わせの目的が引き継ぎに必要なら、その内容が原文と同じ意味で残っているかを確認します。重要な内容が抜けた場合、原文に記載があれば入力範囲と要約の指示を見直し、原文にもなければ確認事項として引き継ぎます。

優先度を付ける場合は、判定の区分と判断材料を定義します。担当者が入力情報と照らして採用・修正できない結果なら、対応順への利用を進めず、判定基準を見直します。

メール文面は下書きで止める

取引ステージの変更をきっかけに、関連するコンタクトや会社の情報からフォローアップ文面の案を作る方法があります。生成文は担当者が確認できる場所に置き、事実関係、宛先、表現を確認してから送信する流れにします。

取引金額や導入時期などの重要情報が入力されていないときは、AIに補わせず、確認が必要な項目として明示します。顧客ごとの事情を反映する必要がある場合は、担当者が元情報を確認して文面を整えます。確認担当と送信担当が異なるなら、どちらが最終的な内容を確定するかも決めておきます。

下書きの確認では、文面に含まれる事実ごとに参照元を確かめます。参照元が見つからない内容や、現在の取引条件と一致しない内容は修正します。担当者が送信対象と確定した文面を確認できる状態になってから、送信作業へ渡します。

問い合わせ分類は引き継ぎを支える

問い合わせを技術質問、料金に関する質問、苦情、その他などに分類し、担当者の確認後にチケットのプロパティへ記録する流れが考えられます。分類カテゴリと各カテゴリの説明をそろえ、複数に当てはまる入力をどう扱うかも決めます。

分類に迷う入力やカテゴリに当てはまらない問い合わせは、無理に振り分けず、人が確認する経路へ送ります。分類結果、担当者の修正、最終的な対応を残し、判断が分かれた例をもとに基準を見直します。たとえば料金への質問に不具合の報告も含まれるなら、原文と両方の意図を担当者へ渡します。

担当振り分けに使う前には、複数の意図を含む場合の引き継ぎ先と、誰が対応の順序を決めるかを確かめます。順序を担当者が決める運用なら、AIの分類をそのまま振り分け条件にせず、確認待ちとして渡します。担当者が採用した分類だけを後続処理で使えるようにしてから、振り分けへの利用を検討します。

次の画面は、HubSpotのワークフローからOpenAIを呼び出す設定例です。画面上の設定項目を見る際は、入力に使う情報、結果の記録先、後続処理の前に確認する担当者を、自社の業務に沿って整理してください。

HubSpotのワークフローからOpenAIを呼び出し、問い合わせの判断を自動化する設定画面（デモ）です。

実装は入力、出力、確認の順に組み立てます

APIを呼び出す前に、どの情報を渡し、どの形式で結果を受け取り、失敗や判定不能をどう扱うかを決めます。テスト用の入力で一連の流れを確かめ、担当者が結果を照合・修正できることを確認してから対象を広げます。

設計するもの	確認する内容
入力	開始条件と、AIに渡すCRM情報
出力	要約や分類の形式と保存先
確認	判定不能やエラーを人に回す条件

対象業務と入出力を定義する

まず、処理を始める出来事と、対象となるCRM情報を決めます。次のような候補から、対象業務に合う開始条件を選び、AIに渡す項目を絞ります。

新規コンタクト作成
チケット作成
取引ステージ変更

必要な情報がそろっていないレコードは、処理を進めるか人に確認を求めるか決めておきます。

続いて、出力先と後続処理を決めます。要約文を保存するのか、分類カテゴリを記録するのか、担当者への通知まで行うのかを分けて考えます。

返答が所定の形式に合わない場合は、後続処理へ進めず、人へ回す経路を用意します。

テスト用のレコードでは、次を順に確かめます。

開始条件が意図した入力で動くか
入力不足を検知できるか
結果が予定した場所に残るか

正常な結果だけで完了とせず、所定の形式に合わない返答が後続の通知や振り分けに使われないことも確認します。

担当者が元情報、AIの出力、採用結果を見分けられ、判定不能のときに対応を引き受けられるなら、次の業務で試す条件を検討できます。途中で記録が途切れる場合は、その段階の入出力を修正します。

APIキーと接続情報を保護する

APIキーは、利用する環境で指定された秘密情報の管理方法に従って保管し、ソースコード、チャット、メールには記載しません。管理担当者と更新方法を決め、担当者が変わっても接続設定を確認できるようにします。

HubSpotを経由する構成でも、キーをコード内に書かず、自社環境で利用できる設定方法を確認します。テスト用の入力で接続、出力、エラー時の通知を確かめ、問題があれば設定と処理条件を修正してから業務での利用を検討します。

接続できなくなった場合に誰へ連絡するかも決めます。設定を直す担当者と、元の問い合わせを使って対応を続ける担当者を明確にし、復旧を待つ間の顧客対応を引き継げるようにします。

応答とエラー時の動きを決める

正常な応答が返らない場合に、処理をどこで止め、誰へ知らせるかを決めます。表示されたエラーに応じて、次のどこを確認するか分けます。

認証
利用条件
入力
通信

エラーの原因が分からない状態では、結果が保存されたものとして後続処理へ渡さないようにします。

再実行する場合は、同じ入力を繰り返してよい条件を先に決めます。入力内容や認証設定の修正が必要なら自動で繰り返さず、エラーを記録して担当者に渡します。復旧後にどのレコードを再処理するかも、業務開始前に確認します。

再処理の前には、次を確かめます。

そのレコードに採用済みの結果がないか
元の入力が変更されていないか

すでに担当者が対応を進めているなら、再処理結果をどう扱うか担当者が判断します。確認できない場合は再処理を保留し、重複した通知や引き継ぎを避けます。

エラーの記録には、次を残します。

対象レコード
処理を止めた段階
担当者が取った対応

復旧後は記録を見て、未処理のものと担当者がすでに対応したものを分けます。その区別ができてから再処理の対象を決めます。

レート制限を示す応答を受けた場合は、利用先が示す条件を確認し、その条件に沿って再試行の方法を決めます。再試行前に担当者が元の問い合わせで対応を始めていないか確認し、重複する処理は保留します。

入力の長さが利用先の条件に合わない場合は、判断に必要な情報を特定します。入力を短くするか処理を分けるかを選び、必要な文脈を失っていないことを担当者が確認してから再実行します。

プロンプトと記録項目を整える

プロンプトには、次を含めます。

AIの役割
参照する情報
行う処理
回答形式
推測を避ける条件

後続のシステムで使う結果は、保存先の項目と対応する形式で返すよう指定します。入力にない事実を補う必要が生じた場合は、推測した結果を採用せず、人による確認へ回します。

問い合わせ分類であれば、カテゴリ名だけでなく、判定できないときの返答と、複数の意図があるときの扱いも指定します。記録先にはAIの提案と担当者が採用した値を区別して残し、後続処理がどちらを参照するか決めます。採用前の値を引き継ぎに使ってしまう場合は、プロンプトを直す前に記録と参照の流れを修正します。

テストでは、通常の入力に加え、情報が不足した入力や複数の意図を含む問い合わせも確認します。期待する結果、実際の結果、担当者による修正理由を記録します。同じ種類の修正が続く場合は、次の順に原因を確認します。

入力項目
プロンプト
分類基準

入力に必要な情報があるのに出力へ反映されない場合と、担当者間で期待する分類が違う場合では、見直す場所が異なります。

プロンプトを直した後は、修正のきっかけになった入力だけで判断しません。これまで採用できた入力や、判定不能として人に渡すべき入力でも同じ確認を行います。修正によって別の扱いが変わった場合は、その理由を調べてから運用へ反映します。

費用と運用の見直しを業務単位で行います

API費用を確認するときは、利用量だけでなく、担当者の確認や修正にかかる手間も同じ業務単位で見ます。品質が足りない処理は、利用量を調整する前に入力や判断基準を見直します。結果が後続業務で使われているかも、継続の判断材料にします。

見直す観点	確認すること
利用量	呼び出し回数と入力・出力の量
品質	担当者の修正箇所と確認時間
運用	エラーと再実行、結果を次の業務に使えているか

処理の難易度に応じて選択肢を分ける

定型的な分類やラベリングと、複数の条件を考慮する文章作成では、確認すべき点が異なります。処理ごとに期待する出力と、人が確認する内容を定め、同じ入力で候補を比較します。

処理の種類	見るポイント	運用上の確認
分類・ラベリング	区分の一貫性、判定できない場合の扱い	誤分類の修正と人への引き継ぎ
要約・文章作成	重要情報の保持、事実に沿った表現	担当者が直した箇所と確認時間
複雑な分析	根拠の提示、条件の扱い	判断の責任者と記録方法

一つのモデルに処理をまとめる案と、用途ごとに使い分ける案は、処理別に比較します。

分類 ── 担当者が採用した区分と判断保留の引き継ぎを確認する
要約 ── 引き継ぎに必要な情報が残り、原文にない事実を加えていないかを確認する
複雑な分析 ── 根拠を担当者がたどれ、業務上の判断を誰が確定するかを確認する

各案について、次を並べます。

同じ入力で得た結果
担当者の修正内容
確認に必要な作業
接続設定と障害対応の担当

ある処理だけ品質を満たさない場合は、その処理の入力や指示を見直します。修正しても原文との照合ができない、または判断の責任者を決められない場合は、その処理を人が行う範囲に戻します。他の処理まで同じ結論にせず、業務に使える範囲を処理ごとに決めます。

構成を決めるときは、まず各処理で採用・修正・判断保留を区別できる案を残します。そのうえで、次を確かめます。

同じモデルを使う案 ── 確認担当と設定管理を共通にできるか
使い分ける案 ── 処理ごとの設定変更や障害対応を誰が引き受けるか

ある処理の品質を改善できても、担当者が結果の出所や修正方法を把握できない構成なら、運用へ進める前に記録方法を整えます。

たとえば分類は採用できても、文章作成で事実確認が難しいなら、分類の利用範囲を先に決め、文章作成の入力と確認方法は別に見直します。使い分けによって設定や障害対応の担当が増える場合は、その運用を引き受けられるかも確認してから構成を選びます。

文章作成の確認方法が定まるまでは、分類の採用結果を文章の自動送信につなげず、担当者の確認を置きます。

重複処理や不要な入力を抑える

同じ情報が繰り返し送られていないかを確認し、処理済みのデータが再び対象になる場合は開始条件を見直します。結果を再利用する場合は、元の入力が更新されたときに再処理する条件も決めます。更新後の情報が判断に関わるなら、古い結果をそのまま使わないようにします。

再処理の条件は、単にレコードが更新されたかではなく、AIの判断に使う情報が変わったかで確認します。

関係のない項目の更新で同じ処理が繰り返される ── 開始条件を見直す
判断に使う情報が変わった ── 担当者が古い結果と新しい結果を取り違えない記録方法を決める

結果をすぐに使わない業務では、まとめて実行する方法を検討できます。担当者の対応開始までに結果が必要なら、その時点に間に合う処理方法を選びます。業務の期限に合わない場合は、実行のタイミングを見直します。

入力範囲を見直すときは、次の順に進めます。

各項目が出力のどの判断に使われるかを確認する
使い道を説明できない項目は、後続の担当者に必要かを確かめてから外す
入力を変えた後は同じ業務サンプルで結果を見比べ、必要な情報まで失われていないか確認する

利用状況を見て対象を調整する

利用量、エラー、担当者の修正状況を業務ごとに確認します。利用量が想定を超えたときは、次の順に調べます。

対象条件
入力の範囲
不要な再実行

修正が増えたときは、プロンプトだけでなく入力データや分類基準も見直します。

結果が次の業務で使われているかも確認します。使われない出力は用途と記録先を見直し、必要な判断につながらなければ処理条件を絞るか停止します。引き継ぎ先で使われていても、担当者が同じ箇所を繰り返し直しているなら、その修正理由をもとに入力や出力形式を変え、同じサンプルで再確認します。

見直しを始めるきっかけも決めておきます。問い合わせの内容や分類基準が変わったとき、担当者の修正理由が変わったとき、結果の参照先が変わったときは、以前の評価をそのまま使わず、対象業務の入力から引き継ぎまで確かめ直します。

よくある質問

AI APIを使うには、どのモデルを選べばよいですか？

対象業務に必要な入力と出力をそろえ、各APIで同じサンプルを試します。まず必要な情報を扱え、結果を所定の形式で受け取れる候補に絞ります。次に、通常の入力、情報不足、複数の意図を含む入力について、担当者の採用・修正・判断保留とその理由を比べます。期待する結果が担当者間で異なる場合は分類基準をそろえ、原文にある情報が出力から抜ける場合は入力と指示を見直してから選びます。判定不能を人へ渡せることと、採用前の結果が後続処理に使われないことも確認します。

プログラミング経験がなくてもHubSpotと連携できますか？

利用できるコネクターアプリがあり、必要な入力、出力、記録先をその機能で扱えるなら、設定を中心に連携を試せます。まずテスト用の情報で、通常の結果だけでなく判定不能やエラー時に担当者へ渡せるかも確認します。扱えない項目や処理があれば明確にし、その不足を解消する方法として、カスタムコードや外部サーバーを含む構成を検討します。

AIが生成したメールをそのまま送信できますか？

生成文は下書きとして扱い、担当者が元情報、取引条件、宛先に合う表現を確認してから送信する運用にします。必要な情報が欠けている場合は文面で補わず、担当者による確認へ戻します。確認を終えた文面と送信対象を区別できる状態にしてから、送信担当へ渡します。

Breezeと外部のAI APIはどう使い分けますか？

まず対象業務に必要な入力、出力、確認方法を決め、自社のHubSpot環境で利用できるBreezeの機能と照らし合わせます。満たせない要件が明確になったら、外部APIを使う構成で実現方法と運用負担を比較します。どちらを使う場合も、元情報との照合、判定不能の引き継ぎ、採用結果の記録ができるかを確認してから業務へ組み込みます。

まとめ

AI APIを業務に活用するには、モデル選びに先立って対象業務、入力情報、出力先、確認担当を決めます。HubSpotでは、コンタクトやチケットに入った情報を要約・分類し、担当者の確認を経て顧客対応へつなげる設計が考えられます。

まずは、手作業で行っている問い合わせの要約や分類から、次の順序で検討します。

現在の業務を確認し、AIに任せる処理を一つ選びます。期待する出力を定義できなければ、先に判断基準を整理します。
入力項目、出力形式、確認担当、エラー時の経路を決めます。結果を元情報と照合できなければ、記録方法を整えます。
同じサンプルで結果を比較し、採用・修正・判断保留とその理由を記録します。許容できない誤りを後続業務へ渡さず、担当者が結果を使え、誤りへの対応も決まったら、運用範囲を広げます。

比較の途中で判断が分かれたら、入力の不足、出力形式、担当者の判断基準のどこに原因があるかを確かめます。運用を始めた後も、修正理由や後続業務での利用状況が変われば、同じサンプルを使って入力から引き継ぎまで見直します。

企業様によって最適な形は異なります。CRM上のどの情報を使い、どこで担当者の確認を置くべきか整理したい場合は、StartLinkまでお気軽にお問い合わせください。

記事の内容を、そのまま実務に落とし込みたい方向け

無料で相談する資料をダウンロード

株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。

著者情報

今枝 / Imaeda

株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。