%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
ChatGPT APIで業務自動化する方法とは、OpenAIのAI機能を業務に組み込み、入力から結果の確認、記録までの流れを設計することです。「ChatGPTへ毎回同じ指示を入力している」「問い合わせ内容を表へ転記する作業が減らない」「AIの回答をそのまま顧客対応に使うのは不安がある」——こうした課題を整理するには、AIの機能だけでなく、入力から確認、記録までの業務の流れを見る必要があります。
ChatGPT APIで業務自動化する方法とは、OpenAIのAI機能を業務に組み込み、入力から結果の確認、記録までの流れを設計することです。「ChatGPTへ毎回同じ指示を入力している」「問い合わせ内容を表へ転記する作業が減らない」「AIの回答をそのまま顧客対応に使うのは不安がある」——こうした課題を整理するには、AIの機能だけでなく、入力から確認、記録までの業務の流れを見る必要があります。
ChatGPT APIは、OpenAIのAI機能を自社のシステムや業務フローから呼び出すための仕組みです。業務へ組み込むには、出力形式を定め、内容を検証し、必要な場面に人の承認を置きます。
例えば問い合わせメールを処理するなら、最初に「分類結果を担当者へ見せる」ことと「顧客レコードを更新する」ことを分けます。前者は元のメールと分類結果を照合できれば試せます。後者は更新先の特定、変更値の確認、承認、更新後の照合まで決まらなければ進めません。この違いを業務ごとに書き出すと、試す範囲を決めやすくなります。
まず、扱いたい情報が文章、音声、画像のどれかを確認します。次に、必要な処理を分類、要約、検索、回答案作成などに分けます。下の表は、機能名と業務での使い道を見渡すための一覧です（2026年10月時点の整理）。実装に使うAPIと利用条件は、導入時点の公式ドキュメントで確認します。
| エンドポイント | 用途 | 代表的な業務活用 |
|---|---|---|
| Responses API | テキスト生成、会話、組み込みツールやFunction Callingの利用（新規案件では公式が推奨） | 問い合わせ応答、文書作成、要約、社内ナレッジ検索 |
| Chat Completions | テキスト生成・会話（継続対応） | 既存の問い合わせ応答や要約の仕組みの運用 |
| Embeddings | テキストのベクトル化 | 類似文書検索、FAQマッチング |
| 音声の文字起こし | 音声→テキスト変換（モデルの入れ替えあり） | 議事録作成、コールセンターの記録整理 |
| 音声合成 | テキスト→音声変換（モデルの入れ替えあり） | 音声ガイド、自動架電で使う音声の作成 |
| 画像生成（GPT Image系） | 画像生成（旧モデルのDALL-Eは終了済み） | マーケティング素材、プレゼン画像の作成 |
| Moderation | コンテンツ安全性チェック | UGC監視、チャットボットの入力確認 |
表の機能名は公式の廃止予定一覧で確認した内容です。Assistants APIは2026年8月26日に終了しました。 後継はResponses APIとConversations APIです。新たに対話やファイル参照を設計する場合は、OpenAIの移行ガイドで現在の構成を確認してください。音声と画像のモデルは入れ替わりが続いています（例えば音声の文字起こしのwhisper-1や音声合成のtts-1にも終了予定が示されています）。実装前に同じ一覧で終了日と推奨の移行先を確かめます。また、表の業務活用例は各機能だけで業務を完結できるという意味ではありません。入力データの準備、結果の確認、実行権限を合わせて設計します。
この記事では、入力、AI処理、承認、CRMへの反映をどの順序で設計するかを説明します。対象業務を選んだ後、通常の入力だけでなく、情報不足や処理失敗の例を使って確認する方法まで扱います。
関連する記事の一覧はAIツール比較ガイドをご覧ください。
この記事でわかること
ChatGPT APIを活用した業務自動化を検討しているDX推進担当者・開発者に向けた記事です。対象業務の選び方から、既存システムへの接続、承認と例外処理までを順に確認できます。読み終えたら、自社で試す業務について「何を入力し、誰が結果を確認し、どこへ記録するか」を書き出してみてください。
- OpenAI APIの使い分け — Responses API、Chat Completions、終了したAssistants APIの移行先、Embeddingsの役割を整理し、現在利用できる機能の確認方法と処理内容に応じた選び方を解説します。
- 業務特化アシスタントの設計 — 会話履歴や社内資料を扱う際の資料管理と、回答に必要な情報が見つからない場合の処理を紹介します。
- 既存システムとの連携方法 — Function Callingを使い、AIが出す処理案とアプリケーションによる実行を分ける考え方を説明します。
- 構造化データによる自動化 — Structured Outputsで回答形式を定め、元データとの照合を経て後続システムへ渡す方法を解説します。
- 段階的な導入と運用 — 検証対象の選定から承認、監視、失敗時の復旧までを整え、対象業務を広げる条件を紹介します。
OpenAI APIの全体像と選び方
APIを選ぶ前に、対象業務で受け取る情報、必要な結果、結果を使う担当者を書き出します。例えば問い合わせ対応なら、入力はメール本文、最初に必要な結果は分類、結果を使うのは振り分け担当者、正式な記録先は問い合わせの管理先、と分けます。「分類結果を見せる」段階で十分なら、顧客情報の更新機能まで同時に設計する必要はありません。
手作業で行っている分類や転記の流れを、単発処理、継続的な対話、資料検索、システムへの書き込みに分けます。書き込みが必要なら、AIの出力を確認する担当者と登録先の必須項目も先に決めます。判断に迷う場合は、同じ入力例を使い、必要な項目を得られるか、結果を元データと照合できるかを比べます。
確認表には、通常の入力、必須情報が欠けた入力、対象レコードを特定できない入力を並べます。各入力について「期待する出力」「処理を止める条件」「止まった後に確認する人」「再開に必要な情報」を記入してください。例えば会社名が書かれていても同名のレコードが複数見つかる場合は、AIに一件を選ばせて更新するのではなく、担当者の選択待ちにします。期待した保留処理ができない方式は、書き込みに使う前に構成を見直します。
主要なAPIと業務上の役割
OpenAI公式ドキュメントでは、用途に応じたAPIや機能が案内されています。下の表は機能が担う処理を整理したものです。利用可否や組み合わせ方は導入時点の公式情報で確認します。
| 機能 | 主な役割 | 適した業務 |
|---|---|---|
| Responses API | 指示と入力に応じたテキスト生成。組み込みツール、Function Calling、会話の状態保持も扱える | メール分類、要約、回答案作成、社内ナレッジ検索 |
| Chat Completions | 指示と入力に応じたテキスト生成（継続対応） | 既存のメール分類や要約の運用 |
| Assistants（終了済み） | 会話履歴やファイルを扱っていた旧構成 | 継続的な対話の移行要件整理 |
| Embeddings | テキストを検索や比較に使える形へ変換 | 類似文書検索、FAQの参照先の抽出 |
| Function Calling | 呼び出す処理と引数の案を出力 | CRM検索、取引作成、承認処理との連携 |
| Structured Outputs | 定義した形式に沿って回答を構造化 | メールや議事録からの項目抽出 |
分類や要約のように入力ごとに完結する処理なら、必要な情報を渡して結果を受け取る構成から考えます。OpenAIは移行ガイドで、Chat Completionsは引き続き利用できるとしたうえで、新規のプロジェクトにはResponses APIを推奨しています。既存のChat Completionsの仕組みを急いで作り替える必要はありませんが、新しく作る業務はResponses APIを前提に考えます。参照資料が必要なら、どの資料のどの版を使うかを先に決めます。外部システムを使う場合はFunction Callingで処理案を受け取り、アプリケーション側で引数と権限を検証します。登録先が決まった項目を必要とする場合は、Structured Outputsで形式を定めたうえで、各値を元データと照合します。
例えば分類結果を担当者が読むだけなら、表示と修正の方法を確認します。同じ結果をCRMへ登録するなら、対象レコード、登録項目、承認者、登録後の確認方法が追加で必要です。どの値を元データから確かめられないかが分かれば、その値は確認待ちにして、照合できる処理だけを先に試せます。
単発処理はResponses APIから考える
問い合わせの分類、文章の要約、返信案の作成など、入力ごとに処理が完結する業務では、必要な指示と情報をその都度渡す方法を検討できます。最初に「入力のどこを根拠に結果を判断するか」を決め、担当者が元の問い合わせと出力を並べて確認できる形にします。
過去のやり取りが回答に必要な場合は、どの履歴を参照させるか、履歴をどこで管理するかを決めます。同じ問い合わせを履歴なしで処理し、回答に必要な条件が欠けるかを確かめてください。欠けるなら必要な履歴を特定して渡します。不要な履歴を含めた結果に過去の条件が混ざるなら、参照範囲を絞り直します。
返信案を扱うなら、元の問い合わせ、参照資料、返信案を並べます。担当者が案の各条件を確認できた場合にだけ送信判断へ進みます。参照元が不明な内容や、問い合わせにない条件が含まれる場合は案を保留し、必要な資料の確認へ戻します。
API選定前に業務を分解する
「問い合わせ対応をAI化する」という単位では、設計対象が広すぎます。受信、分類、顧客情報の検索、回答案の作成、担当者の確認、送信、履歴保存へ分けると、それぞれの担当と保存先を決められます。
Excelやスプレッドシートへ転記してから担当者へ連絡し、さらにCRMへ入力している場合は、同じ情報をどこで作り、どこで管理するかを確認します。正式な管理先を決めた後で、AIが作った分類結果や回答案をどのレコードに結びつけるかを設計します。保存先が決まらなければ、APIの選定より先に管理方法を見直します。
各工程について「入力元」「確認者」「正式な保存先」「失敗時の戻り先」を記録してください。さらに、工程の完了を何で確認するかを加えます。分類なら担当者が結果を確認した状態、送信なら送信結果を確認した状態、CRM更新なら登録先を読み直した状態です。分類だけを試す段階では送信やCRM更新を含めず、元の問い合わせとの照合が安定して行えるかを次へ進む条件にします。
問い合わせ対応を分解した結果は、たとえば次のように整理できます（工程名や担当は架空の例です）。
| 工程 | 入力元 | 確認者 | 正式な保存先 | 失敗時の戻り先 | 完了の確認方法 |
|---|---|---|---|---|---|
| 分類 | 問い合わせメール本文 | 営業担当 | CRMの問い合わせ種別 | 分類不明は担当者の確認待ち | 担当者が種別を見て修正の要否を判断する |
| 顧客情報の検索 | 分類済みの会社名・メールアドレス | 営業担当 | CRMの会社・コンタクト | 候補が複数なら検索結果を示して止める | 担当者が対象を1件に確定する |
| 回答案の作成 | 分類結果と社内の回答資料 | サポート責任者 | 下書き（未送信） | 資料に該当が無ければ下書きを作らない | 責任者が内容を読んで承認する |
この表の「失敗時の戻り先」が空欄の工程は、自動化の対象にする前に、止まったときの受け手を決める必要があります。
どの業務から試すかは、技術より「間違えたときに戻せるか」で決めると判断がぶれません。次の3つの候補で考えてみます（業務は架空の例です）。
| 候補業務 | 間違えたときの影響 | 戻し方 | 最初に試すか |
|---|---|---|---|
| 問い合わせメールの種別分類 | 振り分け先がずれる | 担当者が種別を直せば元に戻る | 試す。結果を見せるだけの段階から始める |
| 商談メモの要約をCRMのメモ欄に追記 | 要点が抜ける | 元のメモが残るので読み直せる | 試す。追記前に担当者が要約を確認する |
| 見積金額をAIの抽出結果でCRMに登録 | 金額の誤りが請求まで伝わる | 誰がいつ直すかが決まっていないと戻せない | 後回し。承認と照合の手順を決めてから検討する |
上の2つは誤りが起きても人がすぐ気づいて直せるため、効果と手間を測る対象に向いています。3つ目のように数字が後工程へ流れる業務は、AIの精度が十分に見えても、承認者と照合方法が決まるまで自動登録の対象にしません。経営層に説明するときも、この表の「戻し方」の列を示すと、どこまで任せるかの合意を取りやすくなります。
社内資料を参照する業務特化アシスタントの設計
社内資料を参照する対話型の仕組みでは、会話の継続、資料の更新、回答範囲の管理が論点になります。次の表は現在の構成を前提にした要件別の整理で、終了した旧構成（Assistants API）との違いはその後の比較表にまとめています。新しい実装はOpenAIの移行ガイドで案内されるResponses APIとConversations APIを確認してください。
| 要件 | 推奨アプローチ | 理由 |
|---|---|---|
| 単発のテキスト処理 | Responses API（既存の仕組みはChat Completionsのまま運用も可） | 入力と出力の要件を定め、結果を照合できるか確認する |
| 対話型のアシスタント | Responses API + Conversations API | Assistants APIで扱っていた履歴とファイルを移行要件として整理し、移行先で再現できるか確認する |
| 外部システム連携 | Function Calling | 処理案を受け取り、実行前に引数と権限を検証する |
| 出力フォーマットの厳密制御 | Structured Outputs | 形式を定めたうえで、値を元データと照合する |
| ノーコードでの連携 | ノーコード連携ツール + OpenAI | 承認、履歴、失敗時の対応を扱えるか確認する |
| 大規模バッチ処理 | Batch API | 結果を待てる業務か、完了後に誰が確認するかを決める |
対話型の仕組みでは、回答に使う履歴と資料をどこで管理するかが決まるまで方式を確定しません。Batch APIでは、即時応答が必要か、結果が届くまで業務を待てるかを先に判断します。OpenAIのBatch APIガイドで利用条件を確認し、同じ入力例で結果の確認作業と処理手順を比較してください。
一括処理が業務に合うかは、結果を受け取るまで担当者が待てるか、入力と出力を対応付けられるか、一部が失敗した場合にその分だけ確認できるかで判断します。例えば問い合わせの分類結果を翌工程でまとめて確認できるなら一括処理を検討できます。問い合わせを受けた場で回答が必要なら、待機中の扱いを先に設計します。どの入力が未処理か追えない場合は、処理単位と記録方法を整えてから採用を判断します。
下の表は、現行のResponses API・Conversations APIと、終了したAssistants APIの構成を並べたものです。右の列は旧構成の整理用で、新しく作る業務には使えません。
| 項目 | Responses API・Conversations API（現行） | Assistants API（終了済み） |
|---|---|---|
| 状態管理 | 必要な文脈をアプリケーション側で選んで渡す。Conversations APIで会話を保持する方法もある | Threadで履歴を扱っていた |
| ファイル操作 | 組み込みのファイル検索ツールを使うか、参照する資料を別途準備する | File Search・Code Interpreterを利用していた |
| ツール連携 | Function Callingの結果をアプリケーション側で検証する | Function Callingと組み込みツールを利用していた |
| 会話履歴 | 必要な履歴と保存先を設計する | API側で履歴を管理していた |
| コスト | 入出力と利用する機能を基に確認する | 移行先の機能と課金条件を確認する |
| 適用シーン | 入力ごとに完結する処理から継続的な対話まで検討する | 対話型業務の移行要件を整理する |
この比較は、履歴やファイルをどこで管理するかを考えるためのものです。履歴がなくても期待する回答を作れるなら単発処理を先に試します。履歴が必要なら、何を引き継ぎ、誰が更新・削除し、回答時にどの範囲を参照できるかを決めます。現在の機能制限や課金項目は、実装時点の公式情報と照合してください。
状態を持つ対話と単発処理の違い
単発処理では、処理に必要な情報を毎回渡します。対話型処理では、前のやり取りを次の回答へどう引き継ぐかを設計します。画面がチャット形式かどうかではなく、履歴が回答の判断材料になるかで分けます。
| 判断項目 | 単発処理 | 対話型処理 |
|---|---|---|
| 会話履歴 | 処理ごとに必要な情報を渡す | 必要な履歴を選んで引き継ぐ |
| ファイル参照 | アプリケーション側で準備する | 参照先と利用できる機能を確認する |
| 主な用途 | 分類、要約、文章作成 | ナレッジ検索、継続的な相談 |
| 運用上の論点 | 入力形式と出力形式 | 履歴、資料更新、回答範囲 |
Assistants APIを利用していた場合は、旧構成の履歴のうち回答に必要な情報を整理します。対話型の業務を新たに作る場合は、引き継ぐ情報と保存期間を決め、現在利用できる方法で状態を管理します。
判断に迷う場合は、同じ質問を履歴なしと必要な履歴ありで試し、回答の違いを確認します。履歴がある場合にだけ正しく答えられるなら、その根拠となったやり取りを特定してください。無関係な過去の条件まで回答へ混ざるなら、引き継ぐ範囲を見直します。必要な履歴だけを選べることが、対話型の構成へ進む条件です。
ナレッジ品質が回答品質を左右する
社内マニュアルやFAQを参照させる前に、資料名、対象業務、版、更新日、問い合わせ先をそろえます。現行版を判別できない資料は検索対象へ追加せず、管理情報を補います。旧版を外す担当と手順も決めておきます。
回答には参照元を示し、必要な情報が見つからない場合は推測で補わず担当部署への確認へ切り替えます。確認には、現行資料で答えられる質問、旧版と答えが異なる質問、資料に答えがない質問を使います。現行版を参照できても、答えのない質問に断定して答えるなら、回答を保留する条件が不足しています。参照元を示せないなら、表示方法または資料の管理方法を見直します。
資料の更新後は、同じ質問で回答と参照元を確認します。旧版を根拠にしないこと、答えがない質問を担当部署へ渡せることを確かめてから利用対象を広げてください。
参照元の表示方法を検討する際は、以下の画面を確認してください。
旧構成から移行するときの確認点
Assistants APIで作った既存の構成を見直す場合は、会話履歴、ファイル、ツール実行のうち、どの機能を業務で使っていたかを整理します。機能名だけを置き換えるのではなく、それぞれについて保存先、参照権限、更新担当、回答できない場合の引き継ぎ先を書き出します。
OpenAIの移行ガイドで移行方法を確認し、移行前後で同じ入力例を使って回答と参照元を比べます。必要な情報を引き継げない場合は、利用範囲を広げる前に履歴や資料の管理方法を見直します。
移行後は、正しい回答に加え、参照権限のない資料を使わないこと、資料に答えがないときに担当者へ引き継げることを確認します。回答が合っていても根拠や権限を確認できなければ、その業務への適用判断は保留します。
Function CallingでAIと既存システムをつなぐ
Function Callingは、AIが呼び出す処理と引数の案を返し、アプリケーション側が実際の処理を行うために使います。CRMなどへ反映する前に、引数、対象レコード、実行権限を検証できます。
検索なら対象を正しく絞れるか、書き込みなら変更内容を誰が承認するかを先に決めます。同じ関数を呼び出せても、検索結果を見せる段階と取引を作成する段階では、進行条件が異なります。
AIの判断とアプリケーションの実行を分ける
Function Callingを使った処理は、次の流れで設計します。
| 段階 | 処理内容 | 主な担当 |
|---|---|---|
| 入力受付 | ユーザーの依頼やメール本文を受け取る | アプリケーション |
| 処理判断 | 呼び出す関数と引数の案を出す | AI |
| 検証 | 引数、権限、対象レコードを確認する | アプリケーション |
| 承認 | 更新や送信の可否を判断する | 人間または定義済みルール |
| 実行 | CRM検索や取引作成を行う | アプリケーション |
| 記録 | 入力、判断、実行結果を保存する | アプリケーション |
例えばAIが「この会社の取引を作成する」と提案しても、会社名だけで対象を一意に決められなければ検索結果を担当者へ示して止めます。対象が一意でも、金額が元の依頼に記載されていなければ値を補って登録しません。対象と変更値の両方を照合でき、承認者が内容を確認した場合に実行へ進みます。
承認画面には対象レコード、変更前後の値、元の依頼を示します。実行後は承認された値と登録先の値を照合します。APIの応答が得られない場合は、同じ操作を直ちに繰り返さず、先に登録先の状態を確認します。
HubSpotとの連携パターン
HubSpotのコンタクト検索と取引作成を例に考えます。ユーザーの依頼から会社名やメールアドレスなどの検索条件を抽出し、アプリケーション側で条件を確認してからHubSpot APIへ渡します。検索結果が続く場合はページネーションで取りこぼしを防ぎ、制限に達した場合は待機や再実行を行う設計にします。実装時には、対象のAPIに適用される制限をHubSpotの開発者向け資料と利用環境の設定で確認してください。
検索結果が見つからない場合、複数見つかる場合、一意に見つかる場合を分けて扱います。見つからなければ検索条件を担当者が確認し、複数なら対象の選択を求めます。一意に見つかった場合も、依頼にある識別情報とレコードの情報を照合してから次へ進みます。
取引を作成する場合は、取引名、金額、ステージ、関連するコンタクトを登録案として表示します。元の依頼で確認できない値があれば担当者へ戻し、必須項目と権限がそろってから承認を受けます。登録後は取引と関連付けを読み直して確認します。応答が得られなかった場合も、未登録と確認できた処理だけを再実行します。
複数ツールを扱う場合の設計
CRM検索、メール作成、予定登録などを組み合わせる場合は、各ツールが何を受け取り、何を返すかを分けて定義します。同じ依頼で複数のツールが選ばれるなら、説明や引数を見直し、選択理由を確認できる状態にしてから実行対象へ加えます。
例えばCRMへの登録後にメール作成が失敗した場合は、「CRM登録は完了」「メール作成は未完了」と別々に記録します。復旧時には登録先を読み直し、登録済みの取引を再作成せず、未完了のメール作成だけを再開します。担当者が完了済みの操作と残りの操作を区別できなければ、運用へ進む前に実行履歴の表示を見直します。
Structured Outputsで出力形式を整える
業務システムへAIの結果を渡すときは、後続処理が必要とする項目名とデータ型を決めます。Structured Outputsは、定義したスキーマに沿う出力を得るための機能です。
形式が整っていても、抽出内容が正しいとは限りません。設計時には「形式を満たすか」「元データと一致するか」「登録先で使えるか」を順に確認します。どこで止まったかを分けて記録すれば、修正すべき対象も特定できます。
自由形式の文章が自動化を止める理由
「会社名、担当者名、商品名を抽出してください」とだけ依頼すると、回答の項目名や順序が変わることがあります。後続のCRM登録では、どの値をどの項目へ渡すかを決めておく必要があります。
そこで、会社名は文字列、数量は整数、備考は文字列というように形式を定義します。値が見つからない場合に空欄を許すか、担当者へ確認を戻すかも項目ごとに決めます。形式を定めた後、抽出した値が元の文章にあるかを確認してから登録処理へ渡します。
例えばメールに会社名はあるが金額がない場合、会社名の抽出結果だけを確認し、金額は確認待ちにします。登録先で金額が必須なら登録全体を保留します。形式だけを満たした出力を登録可能と扱わず、元データと登録先の要件の両方に照らして判断してください。
業務データへ変換する設計例
| 活用パターン | 入力 | 出力スキーマ | 後続処理 |
|---|---|---|---|
| 受注メール→CRM登録 | メール本文 | 会社名・金額・商品名 | HubSpot API で Deal作成 |
| 名刺→コンタクト登録 | 名刺画像（OCR後） | 氏名・会社・役職・メール | CRM一括インポート |
| 議事録→タスク抽出 | 会議テキスト | タスク名・担当者・期限 | プロジェクト管理ツールに登録 |
| 問い合わせ→分類・回答 | 問い合わせ文 | カテゴリ・緊急度・回答案 | チケットシステムに自動起票 |
| 契約書→条件抽出 | 契約書PDF（テキスト化後） | 契約期間・金額・特記事項 | 契約管理DBに登録 |
表の後続処理は、出力をそのまま登録する指示ではありません。まず登録先の必須項目を確認し、元データとの照合方法と承認者を決めます。例えば受注メールに金額の記載がなければ、その値を補って登録せず、確認待ちへ回します。議事録に担当者だけがあり期限がなければ、期限を作らず、タスクの登録要件に応じて保留するか担当者へ確認します。
Structured Outputsの対応する形式と制約はOpenAI公式のStructured Outputsガイドで確認できます。strict: trueを使う場合も、対応するJSON Schemaの範囲を確認し、登録先に渡す前に値の妥当性を検証します。（出典：Structured Outputs guide）
構造化後にも検証が必要
形式がスキーマに沿っていても、金額、日付、顧客名が元のメールや文書と一致するとは限りません。誤登録の影響が大きい項目は、抽出値と元データの該当箇所を並べて確認できるようにします。
検証結果は「形式の不一致」「元データとの不一致」「元データに記載がない」「登録先の必須項目が不足」のように分けて記録します。形式の不一致ならスキーマや入力形式を見直し、値の不一致なら抽出方法と承認手順を見直します。記載がない情報は推測で埋めず、情報を持つ担当者へ確認します。
修正後は同じ入力例で、問題が起きた段階から再確認してください。形式の修正だけで内容の誤りまで解消したと判断せず、値と登録結果もそれぞれ照合します。
業務自動化を一気通貫で設計する
ChatGPT APIを業務へ組み込むには、入力経路、処理の制御、AI、登録先を一つの流れとして設計します。各段階で担当者、保存先、失敗時の扱いを決めます。
コンタクト、取引、顧客対応、請求に関する情報が別々の表へ分かれている場合は、どのシステムを正式な管理先とするかを先に決めます。修正が生じたときに誰がどこを直すかまで定めてから、AIの結果を記録する先を選びます。
レイヤーごとの役割を整理する
| レイヤー | 構成例 | 主な役割 |
|---|---|---|
| ユーザー接点 | Webフォーム、メール、チャット | 依頼や問い合わせを受け取る |
| オーケストレーション | API Gateway、ワークフローエンジン | 処理順序、分岐、再実行を管理する |
| AI処理 | Responses API、Chat Completions、Function Calling | 分類、要約、抽出、処理案の作成 |
| 業務システム | HubSpot、freee、メール、プロジェクト管理 | 正式なデータの保存と業務処理 |
表中のChat Completionsは既存の仕組みで使われ続けている構成です。新たに設計する場合は、Responses APIを含め現在利用できるAPIを確認します。設計図には、処理の順序に加えて各段階の完了を何で確認するかを記します。例えば「AIの回答を受け取った」「担当者が承認した」「登録先に反映された」は別の状態です。
AIが応答しなかった場合は入力を保持して担当者へ渡します。承認後にHubSpotへの登録が失敗した場合は、承認内容を保持し、登録先の状態を確認してから再実行する範囲を決めます。運用担当者が現在の状態と次の作業を追えない場合は、連携先を増やす前に記録方法を整えます。
AIと人間の役割を分ける
| AIに任せやすい処理 | 人間が判断する処理 |
|---|---|
| 問い合わせの分類 | 分類ルールの決定 |
| レコードや議事録の要約 | 顧客へ送る内容の承認 |
| メール回答案の作成 | 重要な顧客への最終回答 |
| 文書からの項目抽出 | 金額や契約条件の確認 |
| CRM操作の案の作成 | 書き込みの実行判断 |
AIが整理した内容を誰が確認するかは、業務ごとに決めます。顧客への送信や金額を伴う更新では、承認画面に送信先、対象レコード、元の依頼、変更前後の値を表示します。担当者がいずれかを確認できなければ実行を保留します。
承認操作を設けるだけでは、判断材料が不足している問題は解決しません。承認者が「この値は依頼のどこから来たか」「どのレコードが変わるか」を確認できる状態にしてから、書き込みを伴う処理へ進みます。
コストとセキュリティを設計に含める
費用を見積もる際は、対象業務の入力例を用意し、入力と出力の量、処理頻度、利用する機能を確認します。同じ入力例で方式を比べ、結果の確認、誤りの修正、失敗時の再実行に必要な作業も記録します。料金はOpenAIの料金ページで導入時点の情報を確認してください。
見積もりは、APIの利用料と人の作業を同じ表に並べると判断を誤りにくくなります。問い合わせ分類を例にすると、次の項目を埋めます（数値は自社の入力例で測った値を入れます）。
| 項目 | 記入する内容 | 測り方 |
|---|---|---|
| 月の処理件数 | 問い合わせの月間件数 | 過去3か月の受信件数の平均 |
| 1件あたりの入力・出力の量 | メール本文と分類結果の長さ | 入力例20件を実際に処理し、使用量の記録を見る |
| API利用料 | 件数×1件あたりの量×料金ページの単価 | 利用するモデルの単価を料金ページで確認 |
| 確認の作業時間 | 担当者が結果を見て直す時間 | 入力例20件の確認にかかった時間から1件あたりを出す |
| 再実行・修正の件数 | 失敗や誤分類で手を入れた件数 | 試行中の記録から割合を出す |
API利用料が小さくても、確認と修正の時間が今の手作業と変わらなければ、自動化の効果は出ていません。比べるのは「今の手作業の時間」と「API利用料＋確認・修正の時間」の合計です。
比較の条件が異なると、方式ごとの違いを判断しにくくなります。まず同じ業務の入力例と期待する出力を固定し、どの工程を担当者が行ったかを残してください。運用中に利用状況や確認作業が想定から外れた場合は、入力範囲、出力項目、処理方法の順に見直します。確認に必要な情報を削ってしまう変更は、同じ入力例で業務上の結果を再確認してから採用します。
顧客情報を扱う場合は、送信する項目を業務に必要な範囲へ絞り、APIキーの管理、入力と出力の検証、アクセス権限、ログに残す内容を決めます。OpenAIのデータ管理に関する資料で利用する機能の条件を確認し、自社の保持要件と照合してから送信データを決めます。条件が確認できない情報は、確認を終えるまで送信対象に含めません。
HubSpotとOpenAI APIを連携する方法
HubSpotのコンタクトや取引を起点にAIを使う場合は、分類、要約、回答案をどのレコードへ結びつけるかを決めます。結果を保存するだけでなく、担当者への通知、対応状況の確認、誤りの修正までを業務フローに含めます。
まず読み取りや回答案の作成で必要なデータと確認方法を確かめます。書き込みへ進むのは、対象レコードの特定、承認、失敗時の復旧方法がそろってからです。
連携方式を選ぶ
HubSpotとの連携方法には、次の方式があります。
| 連携方式 | 構成 | 適した状況 |
|---|---|---|
| Webhook連携 | HubSpotのワークフローから自社サーバーを経由してOpenAI APIを呼び出す。必要プランはData Hub ProfessionalまたはEnterprise（HubSpotナレッジベース） | 独自の検証や処理制御が必要な場合 |
| カスタムコードアクション | HubSpotのワークフロー内のコード（JavaScript（Node.js）、またはPython（ベータ参加時））からAPIを呼び出す。必要プランはData Hub ProfessionalまたはEnterprise（HubSpotナレッジベース） | ワークフロー内に処理をまとめる場合 |
| 外部連携ツール | ノーコードの連携サービスを中間に使う。連携ツール側の契約条件も確認する | 必要な承認と実行履歴を扱えるか検証する場合 |
方式を比べる際は、同じ問い合わせを入力し、「承認前に元の依頼と対象レコードを表示できるか」「失敗後にどこまで完了したか分かるか」「担当者が再実行範囲を選べるか」を確認します。対象レコードID、実行時刻、エラー、再実行結果を追えない方式では、書き込みを始める前に記録方法を見直します。利用できる機能や契約条件も導入時点で確認してください。
MCPを使った連携については「MCPでCRM・会計・MAを統合するAI連携ガイド」で解説しています。AIを用いたデータ活用については経営データの可視化サービスもご覧ください。前者ではシステム間で処理をつなぐ考え方を、後者では蓄積した情報を判断に使う方法を確認できます。
コンタクトから請求までの流れに置く
HubSpotのコンタクト検索をAIで補助する場合、その結果を取引の確認や顧客対応にどう使うかを決めます。受注後に会計システムへ情報を渡すなら、コンタクト、取引、顧客、請求の各段階で、どこが情報の管理先かを確認します。
スプレッドシート、メール、CRMへ同じ情報を入力している場合は、修正を最初に反映する場所と、ほかの場所へ伝える方法を定めます。例えば取引の金額を担当者が訂正したとき、どの記録を正式な値とし、後続の処理に訂正をどう伝えるかを決めます。この経路が曖昧なままでは、AIが正しく抽出しても異なる値が残ります。
AIには検索、要約、登録案の作成を担わせ、正式な記録と実行判断は業務システムと担当者の手順に沿って行います。変更の管理先と承認者が決まってから、後続の連携へ進みます。
自動化結果を可視化する
分類結果や処理結果をHubSpotのプロパティへ保存する場合は、担当者がレコード上で確認したい項目から選びます。取引やチケットとの関連付けが必要なら、後続の対応を追うためにどの関連付けを使うかも決めます。
表示する内容は、結果だけでなく「確認待ちの理由」「次に対応する人」「元の依頼を確認する場所」まで検討します。用途が説明できない項目は追加を見送り、まず既存項目や実行履歴で確認できるかを調べます。
保存後は担当者が実際の画面で結果と元の依頼を照合します。記録は残っていても対応すべき作業が見つからない場合は、通知や表示方法を見直してから利用範囲を広げてください。
ChatGPT API自動化の限界と注意点
AIの出力に誤りがある場合、応答が遅れる場合、APIや登録先が利用できない場合を想定します。失敗した処理を見つけ、担当者へ渡し、必要な範囲だけ再実行できる設計が必要です。
顧客への送信、金額や契約条件の変更、対象レコードの更新では、AIの結果を確認する担当者を明確にします。失敗の種類ごとに、止める場所と再開する場所を分けておきます。
技術面と運用面のリスク
| リスク | 業務への影響 | 対応方針 |
|---|---|---|
| 応答までの時間 | 即時応答が必要な処理を止める可能性がある | タイムアウトと代替処理を用意する |
| 出力内容の誤り | 数値、日付、対象レコードを誤る場合がある | 元データとの照合と承認を行う |
| 入力量による費用変動 | 長文入力や再処理で想定を超える場合がある | 入力制限と利用状況の監視を行う |
| APIの停止 | 依存する処理が進まなくなる | キューや手動処理への切り替えを用意する |
| 仕様変更 | モデルやAPIの更新対応が必要になる | 定期的に公式情報と動作を確認する |
| プロンプトの属人化 | 担当者ごとに結果が変わる | テンプレート、評価方法、変更履歴を共有する |
即時応答が必要な処理では、AIが応答しない場合に待機を続ける条件と、担当者へ切り替える条件を先に決めます。切り替え時には元の依頼、処理状況、顧客への対応状況を担当者へ渡します。担当者が引き継げないなら、その工程を自動実行の対象から外し、手動で扱える範囲を定め直します。
復旧後は、保留中の処理と手動で完了した処理を照合します。顧客への送信や登録が済んでいる操作を繰り返さず、未完了と確認できた工程だけを再開します。停止から再開までを担当者が追えた場合に、代替処理を運用へ組み込みます。
プロンプトを個人の技能にしない
指示文を変更する際は、対象業務、入力例、期待する出力、確認項目をまとめて管理します。通常の入力に加え、項目が欠ける入力や判断できない入力も残し、変更前後でそれぞれの扱いを比べます。
例えば分類名を変更したなら、後続の振り分け先も合っているか確認します。回答案の指示を変更したなら、元の問い合わせにない条件を追加していないか確認します。期待する扱い自体を変える場合は、その理由と承認した担当者を記録してから運用へ反映します。
結果が変わった理由を追えない場合は、利用範囲を広げる前にプロンプトやスキーマの変更履歴を整えます。担当者が変わっても同じ入力例と確認手順で判断できることが、次へ進む条件です。
高い影響を持つ処理には人の確認を置く
顧客へのメール送信、取引金額の更新、契約条件の抽出では、AIが作った案を元データと並べて表示します。担当者は送信先、対象レコード、金額や条件を確認し、必要なら案を修正します。元データにない値は推測で補わず、依頼元へ確認します。
承認後の実行をシステムへ任せる場合も、承認された内容と実行結果を照合します。実行結果が確認できないときは成功と扱わず、登録先の状態を調べます。登録済みならその結果を記録し、未登録と確認できた場合に再実行を判断します。
小さく始める導入ステップ
対象業務は、入力と期待する出力を説明でき、結果を元データで確認できるものから選びます。検証で例外を把握し、承認と復旧の方法を整えてから実務へ組み込みます。
読み取りや下書き作成で確認手順を固めた後、書き込みを伴う処理へ進むかを判断します。企業様によって最適な形は異なります。 顧客情報の扱い、承認体制、既存システムの管理方法に合わせて、導入する範囲を決めてください。
検証対象を選ぶ
問い合わせメールの分類と回答案作成、営業日報の要約、議事録からのタスク抽出は、入力と出力を定義して検証しやすい業務の例です。自社で選ぶ際は、手作業の発生箇所、入力形式、正解の照合方法、誤った場合の戻し方を一覧にします。
選んだ業務について、正常に処理できる入力、情報が不足する入力、判断を担当者へ戻す入力を用意します。それぞれに期待する結果だけでなく、結果を使ってよい条件と止める条件を書きます。例えば議事録からタスクを抽出するなら、担当者と期限が明記されたものは照合し、担当者が不明なものは割り当てず確認待ちにします。
たとえば問い合わせメールの分類を検証するなら、過去のメールから次のように入力例を用意し、期待する結果と止める条件を先に書いておきます（内容は架空の例です）。
| 入力例の種類 | 入力の例 | 期待する結果 | 止める条件 |
|---|---|---|---|
| 正常 | 「料金プランの資料をください。従業員は50名です」 | 分類＝資料請求、会社規模＝50名 | なし（そのまま下書きを作る） |
| 情報不足 | 「先日の件、どうなりましたか」 | 分類＝不明、理由＝案件を特定できない | 担当者の確認待ちにし、自動返信しない |
| 担当者へ戻す | 「契約を解約したい。返金について相談したい」 | 分類＝解約・返金 | 金額や契約に関わるため、AIの下書きは作らず担当者へ回す |
各種類を10件前後そろえ、AIの結果と期待する結果が食い違った件数を数えます。食い違いが「情報不足」に集中していれば指示文を、「担当者へ戻す」に集中していれば分類の定義を見直す、というように直す場所が分かります。
入力形式がそろい、結果を照合でき、誤りを修正できる業務から試します。いずれかが決まらない場合は、AI処理を始める前に元データの管理方法や確認担当を定めます。
検証から本番運用へ進む
| 段階 | 実施内容 | 確認すること |
|---|---|---|
| 検証 | 限定した入力でAI処理を試す | 分類や抽出の妥当性、例外の種類 |
| 本番準備 | 認証、ログ、エラー処理、承認を整える | 誰が確認し、失敗時にどう戻すか |
| 運用開始 | 対象を限定して実務へ組み込む | 処理状況、修正内容、利用量 |
| 横展開 | 成功した設計を別業務へ応用する | 共通化できる処理と業務固有の判断 |
検証段階では、担当者がAIの結果と元データを照合できるか、不足情報を保留にできるかを確認します。本番準備では、実データへ反映しない環境で入力不備、APIのタイムアウト、登録先のエラーを試します。担当者に通知が届くか、失敗した処理と対象レコードを特定できるか、修正後に必要な範囲だけ再実行できるかを確認してください。
次の表は、段階を進めるかどうかを決めるときの目安の例です。数値は検証を始めるための仮置きであり、公式の基準ではありません。業務の影響の大きさに合わせて見直してください（2026年10月時点の整理）。
| 判断項目 | 目安の例 | 満たさない場合の対応 |
|---|---|---|
| 検証用の入力例 | 通常、情報不足、対象重複の3種類を各10件前後 | 種類を増やしてから再検証する |
| 元データとの照合 | 金額・日付・顧客名など影響の大きい項目は全件を人が確認 | 自動登録に進まず、下書き作成までに留める |
| 修正の発生率 | 担当者の修正が同じ種類で繰り返されないこと | 指示文や出力形式を見直し、対象は広げない |
| 失敗時の復旧 | 失敗した処理と対象レコードを当日中に特定できること | 通知とログを整えるまで書き込みを止める |
確認できない項目があれば、ログ、通知、復旧手順を整えて同じ入力例で再度試します。運用開始後も担当者が修正した内容と発生した例外を確認します。同じ種類の修正が続く場合は入力形式や指示を見直し、例外を担当者へ渡せない場合は対象範囲を広げずに通知と復旧手順を直します。
横展開前に業務固有の違いを確認する
同じメール処理でも、営業問い合わせ、サポート依頼、受注連絡では、必要な項目と承認者が異なります。対象を広げる前に、入力、判断基準、出力先、失敗時の担当を業務ごとに確認します。共通のプロンプトやスキーマを使う場合も、その業務の入力例で結果を照合してから適用します。
例えば営業問い合わせで使えた分類が、受注連絡に必要な金額や商品名の確認まで担えるとは限りません。新しい業務で不足する項目があれば、その業務の確認手順を追加します。保留、承認、復旧まで担当者が追えることを確認してから横展開します。
AIツール全体の選定については「AI導入で失敗しないツール選定フレームワーク」も参考になります。選定時に比べる項目を整理したい場合に確認できます。ChatGPTとClaudeの法人利用における違いは「ChatGPTとClaudeの企業利用比較ガイド」で解説しています。
仕様変更に備えて見直しの手順を決めておく
APIの機能名・モデル名・終了予定は変わり続けます。記事や社内の設計書に書いた内容が古くなっても気づけるように、次のように「何を、誰が、どこで確かめるか」を台帳にしておきます（担当や頻度は自社で決める例です）。
| 確認する対象 | 確かめる場所 | 古くなっていた場合の動き |
|---|---|---|
| 使っているAPI・モデルの終了予定 | OpenAIの廃止予定一覧 | 終了予定のものを使っていれば、検証用の入力例で代替先を試し、結果が変わらないかを比べる |
| HubSpot側の連携方式と必要プラン | HubSpotナレッジベース | 契約中のプランで使えなくなっていれば、別の連携方式に切り替える案を担当者がまとめる |
| プロンプト・出力形式の変更履歴 | 自社の管理表 | 変更日と理由が残っていなければ、次の変更前に書き足す |
見直しのたびに、過去の検証で使った入力例をもう一度流して結果を比べます。食い違いが出たら、本番へ反映する前に、どの変更が原因かを切り分けます。
よくある質問
ChatGPT APIの導入時に確認したい費用、開発方法、顧客情報、APIの選び方をまとめます。それぞれの回答を自社の入力データと承認ルールに当てはめ、判断が残る場合は検証範囲を限定してください。
OpenAI APIの費用はどのように見積もりますか？
対象業務の入力例をそろえ、入力と出力の量、処理頻度、利用する機能を確認します。同じ条件で方式を比べ、試算した条件を記録します。料金はOpenAIの料金ページで確認してください。結果の確認、誤りの修正、再実行に必要な作業も比較に含めます。運用中に利用状況や確認作業が想定から外れた場合は、入力範囲と処理方法を見直し、同じ入力例で必要な結果を維持できるか確かめます。
プログラミングの知識がなくても利用できますか？
ノーコードの連携サービスで流れを検証できる場合があります。まず同じ入力例で、必要な入力を渡せるか、元データと結果を並べて確認できるか、実行履歴と失敗時の状態を追えるかを確かめます。承認や再実行を扱えない場合は、書き込みを含めず下書き作成までに範囲を絞るか、必要な処理を開発するかを判断します。
顧客情報をAPIへ送信してもよいですか？
利用条件、自社のプライバシーポリシー、関連法規、顧客との契約を確認して判断します。送信する項目を必要な範囲へ絞り、ログに残す情報とアクセス権限も決めます。データの取り扱いは、導入時点のOpenAIエンタープライズプライバシーを確認してください。送信可否を判断できない情報は検証データに含めず、確認できた範囲のデータで処理手順を試します。
Responses API、Chat Completions、旧Assistants APIはどう使い分けますか？
入力ごとに完結する分類や要約では、必要な情報を渡して結果を受け取る構成を検討します。過去の会話やファイルの継続的な参照が必要なら、回答に必要な履歴と資料を特定し、管理方法を先に決めます。新しく作る実装には、OpenAIが推奨するResponses APIを検討します。Chat Completionsは継続して利用できます。Assistants APIは2026年8月26日に終了したため、OpenAIの移行ガイドでResponses APIとConversations APIへの移行方法を確認してください。履歴なしでも答えられる入力と、履歴が必要な入力を比べると、対話型の構成が必要な範囲を判断できます。
OpenAI API以外の選択肢はありますか？
他社の生成AI APIや、Azure OpenAI Serviceのようなクラウド経由の提供形態も比較対象にできます。対象業務の同じ入力例を使い、必要な出力、顧客情報の扱い、既存システムとの接続、運用担当者による確認方法を比べてください。通常の入力に加え、情報不足や判断不能の入力で保留できるかも確認します。利用するサービスを決める前に、外部への送信と更新をどこで承認するかを明確にします。
まとめ
ChatGPT APIによる業務自動化では、入力、AIによる処理、内容の確認、実行、記録を順に設計します。各段階の担当者、保存先、失敗時の戻し方が決まってから業務システムへ接続します。
- 単発の分類や要約は、必要な入力と出力を定め、元データと照合してからAPIを選びます。
- 継続的な対話やファイル参照では、回答に必要な履歴と資料の管理方法を決め、現在利用できるAPIを確認します。
- Function Callingでは、AIが作る処理案とアプリケーションによる実行を分け、対象と引数を検証します。
- Structured Outputsで形式を定めた後も、重要な値を元データと登録先の要件に照らします。
- 顧客への送信や重要なデータ更新には、人間による確認と承認を置きます。
- 情報不足、対象の重複、処理失敗を試し、担当者が保留と復旧を扱える状態になってから対象を広げます。
2026年10月時点の公式情報を前提にすると、最初の一歩は小さく決めることです。まずは、スプレッドシートへの転記や手動分類が発生している業務を一つ選んでください。入力データと必要な出力項目を書き出し、AIが作る結果を誰がどの元データで確認するか決めます。次に、情報が欠けた場合の保留先、対象を特定できない場合の判断者、誤った結果の戻し方を決めます。そこまで確認できれば、同じ入力例を使って必要なAPIと連携方式を比較できます。
StartLinkは、CRMとAIを組み合わせた業務改善を、小さく試して効果を確かめてから広げる投資として捉えています。CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。対象業務の入力元、確認担当、承認が必要な操作、HubSpotへの記録先を整理し、どの工程から検証するかを検討する際にご相談いただけます。
あわせて読みたい
ChatGPT APIと周辺ツールを比較しながら検討したい場合は、次の記事も参考になります。非エンジニアによるAI開発、ブラウザAIによるWeb調査、音声入力の選び方を、それぞれの業務に必要な入力、結果の確認、次の工程へ進む条件の観点から読み比べられます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
