今、多くの企業がノーコードツールのMake（旧Integromat）とOpenAI APIを組み合わせて、業務効率化を進めています。これは非常に合理的なアプローチです。しかし、単にAPIを繋いだだけの「冷たい自動応答」が、かえってブランドイメージを損なっているケースも珍しくありません。
特に2026年2月現在、OpenAIのモデル環境は大きな転換期を迎えています。長文の安定処理や高度な推論を備えた標準モデル「GPT-5.2」や、エージェント型コーディングモデル「GPT-5.3-Codex」がリリースされる一方で、GPT-4oやGPT-4.1などのレガシーモデルは段階的に提供が終了しています。API経由での旧モデル利用は当面継続されるものの、公式からはGPT-5.2への移行とプロンプトの再テストが強く推奨されています。
このモデル移行が求められるタイミングは、既存の自動化フローを根本から見直す絶好の機会となります。今回は、エンジニアではないマーケティング担当者やカスタマーサクセス責任者の方々に向けて、最新モデルを活用しながらAI応答に「人間らしさ」と「安全性」を実装するための実践的なアプローチを共有します。
高度なコードを書く必要はありません。必要なのは、少しのロジックと、相手を思いやる想像力、そしてGPT-5.2の特性に合わせてプロンプトを再設計する視点です。まずは動くプロトタイプを作り、仮説を即座に形にして検証していくアプローチが有効です。
なぜ「ただ繋ぐだけ」の自動応答は失敗するのか
MakeでWebhookを受け取り、OpenAIのAPIに投げて、その結果をメールやチャットで返す。この一連のフローを作るのは、ノーコードツールの普及により驚くほど簡単になりました。しかし、GPT-5.2などの最新のAIモデルを組み込んだとしても、この「素のままの連携」には、カスタマーエクスペリエンス（CX）において致命的な課題が潜んでいます。
「早すぎる返信」が招く不信感
AIモデルの進化により、生成速度は飛躍的に向上しています。特にGPT-5.2のように高度な推論（thinking）と高速応答（instant）の自動ルーティングを備えた最新モデルでは、人間が瞬きをする間に回答を生成することも可能です。しかし、長文の深刻な相談を送った1秒後に「お問い合わせありがとうございます。その件については…」と詳細かつ完璧な回答が返ってきたら、顧客はどう感じるでしょうか？
「本当に内容を理解したのか？」「キーワードだけで自動返信しているのではないか？」という疑念を抱かせてしまうリスクがあります。デジタルの世界であっても、コミュニケーションには信頼を醸成するための適切な「リズム」と「間（ま）」が必要です。技術的な即時性が、心理的な正解とは限らないのです。
文脈を無視した一問一答の限界
APIを単純に叩くだけのステートレスな実装では、AIは「その場限りの対応」しかできません。たとえGPT-5.2のように100万トークン級の長大なコンテキストウィンドウや高度な推論能力を持つモデルを使用したとしても、過去の会話履歴や顧客データを適切に渡さなければ、AIは「さっきの件」が何のことか理解できません。
「先日ご相談した件ですが」と顧客が問いかけたとき、AIが「どのようなご用件でしょうか？」と返してしまえば、それはまるで記憶喪失の担当者と話しているようなものです。高度な処理能力を持つ最新AIだからこそ、文脈（コンテキスト）の欠如は、より一層ちぐはぐな印象を与え、顧客に強いストレスを与えてしまいます。
目指すべきは「人間とAIのハイブリッド」
目指すべきゴールは、高性能なAIですべてを機械的に処理することではありません。最新のエージェント機能の力を借りつつ、定型的な処理はAIに任せ、感情的な機微や複雑な判断が必要な場面では人間が介入する設計が不可欠です。実際、最新のAI開発トレンドでも、タスク実行中にリアルタイムで人間が介入し指示を調整するアプローチが重要視されています。
これから紹介する5つのティップスは、単なるAPI連携を超えて、この「人間とAIのハイブリッド」な体験を、Makeというキャンバスの上でどう描くかという実践的な処方箋です。AIに限りなく人間に近い「振る舞い」を演じさせるための具体的な手法を解説します。
Tip 1: 「感情分析」を挟んで温度感を調整する
クレーム対応の原則として、まずは相手の感情を受け止めることが重要です。しかし、どれほど高性能なAIモデルであっても、そのまま応答させると、相手が激怒している状況でさえ淡々と論理的な解決策を提示してしまいがちです。これでは火に油を注ぐ結果になりかねません。
システム思考の観点から推奨されるアーキテクチャは、回答を生成する前に、ワンクッション「分析」のフェーズを挟むことです。最新の推論能力に優れたモデルを活用することで、表面的な言葉だけでなく、文脈に潜む感情の機微まで捉えることが可能になります。
OpenAIに「怒り」を検知させるステップ
Makeのシナリオにおいて、ユーザーからのメッセージを受け取った直後に、回答生成用とは別のOpenAIモジュールを配置します。ここで実行するのは「感情分析（Sentiment Analysis）」です。
プロンプトには、以下のように構造化されたデータ出力を意識した指示を出します。
「以下のユーザーメッセージの感情を分析し、1から5のスコアで評価してください。
評価基準:
1: 非常にネガティブ（激しい怒り、強い不満、緊急性あり）
2: ネガティブ（懸念、失望、軽い不満）
3: ニュートラル（質問、事実確認）
4: ポジティブ（納得、期待）
5: 非常にポジティブ（感謝、賞賛）出力は数字のみを返してください。」
こうすることで、AIはユーザーのメッセージが「怒っている」のか「喜んでいる」のかを数値化してくれます。特に2026年2月現在の最新標準モデルであるGPT-5.2を使用すれば、高度な推論能力（Thinking機能による自動ルーティングの向上など）によって、言葉尻は丁寧でも内容は激怒している「静かな怒り」や、皮肉のような複雑なニュアンスも高精度に検知できます。
なお、OpenAIの公式情報によると、GPT-4oなどのレガシーモデルは2026年2月13日をもって提供終了となっています。そのため、MakeのOpenAIモジュールで古いモデルを指定している場合は、より長文の安定処理や感情の読み取りに優れたGPT-5.2のAPIへ移行し、プロンプトを再テストしておくことが重要です。
感情スコアによるルート分岐の作り方
次に、Makeの機能である「Router（ルーター）」を使います。ここで先ほどのスコアに基づいたフィルタリングを設定し、ワークフローを分岐させます。
- スコアが1〜2の場合（ネガティブ・緊急）:
AIによる自動回答を行わず（または「担当者に確認します」とだけ伝え）、即座にSlackやTeamsでCS担当者に「対応が必要な案件」として通知を送るルートへ流します。 - スコアが3〜5の場合（通常・ポジティブ）:
通常通りAIに回答案を作成させ、自動返信を行うルートへ流します。
この分岐を設けることで、AIの高速な処理能力と、人間が持つ共感力を適材適所で組み合わせるワークフローが実現します。
謝罪が必要な時はAIに任せない勇気
「AIのエージェント機能が進化しているから、謝罪も任せればいい」と考えるのは危険です。AIによる謝罪は、どれほど言葉巧みであっても、相手に「機械的に処理された」という印象を与え、B2Bの信頼関係に致命的な亀裂を入れるリスクがあります。
リスクが高いと判断された場合は、自動化を断念し、人間に対応を任せる判断（Human-in-the-loop）を組み込むことが極めて重要です。システム思考とは、すべてをシステムで自動化することではなく、システムの限界を正確に把握し、人間が介入すべきポイントを設計に含めることなのです。最新のAI技術を駆使するからこそ、人間が担うべき「責任」と「誠意」の領域を明確に切り分ける必要があります。
Tip 2: 「記憶」を持たせて会話を繋げる
「以前もお伝えしましたが…」と顧客に言わせてしまう状況は避けたいものです。しかし、API連携のデフォルト状態では、AIは過去のやり取りを知りません。APIは基本的にステートレス（状態を持たない）であるため、ここで必要になるのがワークフロー内での簡易的な「記憶（メモリ）」の実装です。
Data Storeを使った簡易的な会話履歴の保持
本格的な開発であればベクターデータベースやOpenAIのAssistants API（スレッド管理機能）を利用することもありますが、Make内で完結させるなら標準機能の「Data Store」が非常に有効です。これはスプレッドシートのような簡易データベースとして機能します。
顧客ID（メールアドレスやLINEのユーザーID）をキーにして、直近の会話内容を保存するように設定します。構造はシンプルで構いません。
- Key: ユーザーID
- Value: { "user": "前回の質問内容", "assistant": "前回の回答内容" }
前回の問い合わせ内容をプロンプトに含める方法
そして、回答を生成するOpenAIモジュールの直前で、このData Storeからデータを「Get」します。もし過去の履歴があれば、それをプロンプトの冒頭に「コンテキスト情報」として埋め込むのです。
OpenAI公式サイト（2026年2月時点）によると、GPT-4oなどのレガシーモデルは廃止され、現在は業務標準モデルとしてGPT-5.2が提供されています。このGPT-5.2は100万トークン級の長文コンテキスト処理能力と高度な推論機能を備えており、こうした構造化された履歴データを極めて正確に解釈できます。
「以下は過去の会話履歴です。この流れを踏まえて、新しい質問に回答してください。
---履歴開始---
{{Data Storeからの取得値}}
---履歴終了---」
これだけで、AIの応答品質は大きく向上します。「先ほどの件ですが」という指示語が通じるようになり、GPT-5.2が持つ高度な対話能力をフルに活かせるようになります。なお、以前からMakeを利用しており旧モデル（GPT-4o等）を指定している場合は、APIエラーを防ぐためにもOpenAIモジュールの設定をGPT-5.2へ変更し、プロンプトの動作を再テストすることをお勧めします。
顧客情報に基づいた対応
さらに、Data Storeに来店回数や契約プランなどの属性情報を入れておけば、プロンプトで「あなたは長年のロイヤルカスタマーに対する担当者として振る舞ってください」といったパーソナライズされた指示も可能になります。GPT-5.2の高度な推論能力により、こうした細かなペルソナ設定も忠実に反映されます。
「記憶」は信頼の証です。技術的には小さなJSONデータの受け渡しに過ぎませんが、受け取る側にとっては「自分を認識してくれている」という安心感に繋がるでしょう。
Tip 3: あえて「間」を作って人間らしさを演出する
冒頭で触れた「早すぎる返信」の問題を解決しましょう。これはシンプルなアプローチですが、効果が期待できます。
Sleepモジュールの効果的な使い方
Makeには「Sleep」というツールがあります。処理を指定した秒数だけ一時停止させる機能です。これを、AIが回答を生成した後、実際にメッセージを送信する直前に配置します。
これだけで、ユーザー体験は変わる可能性があります。30秒〜1分程度の「間」があることで、ユーザーは「担当者が内容を確認して書いてくれているんだな」と感じるかもしれません。
文字数に応じた待機時間の計算式
さらにこだわりたい場合は、固定の待ち時間ではなく、AIが生成した回答の「文字数」に応じてスリープ時間を可変にすると、より自然になります。
人間がタイピングする速度は、おおよそ1分間に60〜100文字程度と言われています。Makeの数式機能を使って、以下のような計算ロジックを組み込んでみてください。
Sleep時間(秒) = (回答の文字数 / 10) + 5
例えば、300文字の回答なら約35秒待機する。これなら、長文の回答が一瞬で届く不自然さを解消できます。
「入力中...」のステータス活用
SlackやLINEなどのチャットツールと連携している場合、API経由で「入力中（Typing...）」というステータスを表示できることがあります。Sleepモジュールが動いている間、このステータスを表示させ続けることができれば、ユーザーは画面の前で「今、書いてくれている」と待つことができます。
こうした「演出」は、エンジニアリングというよりは、心理学に近い領域です。しかし、AI駆動開発においては、こうした人間心理への配慮が、優れたUX（ユーザー体験）を生み出すと考えられます。
Tip 4: AIの「ハルシネーション」を防ぐ安全装置
生成AIの課題は、もっともらしく嘘をつく「ハルシネーション（幻覚）」です。特に製品仕様や価格について誤った情報を伝えてしまうと、企業のコンプライアンス問題に発展しかねません。
「分からない」と言える勇気をプロンプトに仕込む
プロンプトエンジニアリングの基本ですが、Systemプロンプト（AIへの役割指示）において、制約条件を厳しく設定することが重要です。
「あなたは弊社のカスタマーサポート担当です。提供されたドキュメント情報のみに基づいて回答してください。情報にない質問をされた場合は、無理に回答を作らず、『申し訳ありませんが、その件については担当者から直接ご回答させていただきます』と答えてください。決して想像で回答しないでください。」
AIに対して「創造性」を求めてはいけません。CS業務においては「正確性」と「謙虚さ」を学習させることが重要です。
回答後の人間によるレビューフローの組み込み
それでも不安な場合は、Makeのワークフローに「Human in the loop（人間による承認）」を組み込みます。
- AIが回答案を作成する。
- その回答案をユーザーに送るのではなく、まず社内のSlackチャンネル（承認用）に投稿する。
- Slackのボタン機能（Interactive Components）を使い、「承認」「修正」「却下」ボタンを配置。
- 担当者が内容を目視確認し、「承認」ボタンを押したときだけ、Webhook経由でMakeが動き出し、ユーザーへ送信される。
これなら、完全自動化のスピードメリットは薄れますが、AIによるドラフト作成で工数を削減しつつ、誤情報の流出リスクを低減できます。特に導入初期や、センシティブな内容を扱う場合には、この半自動化モデルを推奨します。まずは動くプロトタイプとしてこのフローを構築し、実運用の中で検証していくのが実践的なアプローチです。
Tip 5: コストと暴走を管理する運用設計
システムの安定性とコスト効率を守るための設計について解説します。API連携は基本的に従量課金制で稼働します。予期せぬアクセス集中や設定ミスが、高額請求やシステムダウンを招くリスクは常に存在するため、経営者視点とエンジニア視点の双方からリスクと便益を考慮した堅牢なアーキテクチャが求められます。
無限ループを防ぐための実行回数制限
自動応答ボット同士が会話を始めてしまい、無限にメッセージを送り合う現象は、稀ではあるものの実際に起こり得るリスクです。Makeの設定において、同一ユーザーからのリクエスト頻度に制限（Rate Limiting）をかけたり、一回の実行フローにかかるコストや回数の上限を設定したりすることは、システム全体のリスク管理として不可欠なアプローチです。
トークン節約のための入力テキスト整形
ユーザーから送られてくるテキストは、必ずしもAIにとって処理しやすい形に整理されていません。無駄に長い文章や、そのまま貼り付けられた大量のログデータなどが含まれるケースは多々あります。これらをそのままモデルに投げると、トークン（課金単位）を浪費するだけでなく、コンテキストウィンドウを圧迫し、回答精度を下げる原因になります。
対策として、OpenAIのAPIにリクエストを送る前に、MakeのText機能を使って「最初の1000文字だけを切り取る」といった前処理を組み込むアプローチが効果的です。また、要約や情報抽出のタスクには、適切なモデルの選定が重要になります。かつてはGPT-4o miniのような軽量モデルが主流でしたが、OpenAI公式情報によると、GPT-4oやGPT-4.1 miniなどの旧モデルは2026年2月13日に廃止されます。現在主力となっている「GPT-5.2 Instant」などの最新バージョンは、長い文脈理解や要約タスクにおける構造化能力が大幅に向上しており、応答速度も優れています。旧モデルに依存したフローを構築している場合は、予期せぬシステム停止を防ぐために早急にGPT-5.2系へのAPI移行を計画し、コスト効率と処理精度のバランスを最適化する必要があります。
エラーハンドリングと通知設定
OpenAIのAPIが一時的にダウンしている場合や、Makeの実行エラーが起きた際、ユーザーに何も返信が届かず放置されてしまう事態は避けなければなりません。このような沈黙は、ユーザー体験（UX）を大きく損なう要因となります。
Makeには「Error Handler」という機能が備わっており、メインの処理が失敗した場合に発動する予備ルート（フォールバック）を設定できます。ここで「ただいまシステムが混み合っております。お手数ですが時間を置いて再度ご連絡ください」といった安全な定型文を返す処理や、システム管理者にSlackやメールで緊急通知を飛ばす設定を組み込んでおくことが、信頼される自動応答ボット運用の必須条件と言えます。
まとめ：まずは社内ツールから小さく試そう
ここまで、MakeとOpenAIのAPIを連携させ、単なるボットではない「体温」を感じさせる自動応答の構築手法を整理してきました。
- 感情分析でユーザーの温度感を察知し、リスクを回避する。
- 記憶（コンテキスト）を持たせて文脈を自然に繋ぐ。
- 意図的な「間」を作って人間らしいリズムを演出する。
- 安全装置（ガードレール）でハルシネーションを防ぐ。
- 運用設計でコストと暴走を継続的に管理する。
これらはすべて、現在の環境ですぐに実装可能なテクニックです。特にOpenAIのモデルは日々進化を続けています。2026年2月にはGPT-4oなどのレガシーモデルが段階的に廃止され、100万トークン級のコンテキスト処理や高度な推論（thinking自動ルーティング）を備えた「GPT-5.2」が標準モデルとして展開されました。さらにAPI側でも、高度な音声変換（STS）モデルや画像入力、SIP電話通話サポートなどが追加され、より立体的で人間らしい対話制御が実現できるようになっています。
しかし、技術がいかに進化しても、いきなり顧客向けのメインチャネルに全展開するのはリスクが伴います。
まずは「社内ヘルプデスク」や「総務への問い合わせ対応」から小さく始めることを強くおすすめします。社内のメンバーであれば、フィードバックも直接もらいやすく、万が一の誤答も許容範囲内で収められます。まさに「まず動くものを作る」プロトタイプ思考の実践です。
そこでプロンプトを調整し、GPT-5.2の高度な推論能力やマルチモーダル特性に合わせてチューニングを行い、「これなら確実に機能する」という手応えを得てから、顧客向けにリリースするのが手堅いステップです。もし旧モデル（GPT-4oなど）で構築した既存のプロンプトがある場合は、新しい標準モデル環境で再テストし、挙動の違いを吸収しておくことも重要になります。
AIによる自動応答システムは、導入して終わりではなく、実際の対話データをもとに運用しながら育てていくものです。最新のAPI機能やエージェント技術の動向をキャッチアップしつつ、ぜひ自社のビジネス環境に合った「血の通った自動応答」を実現してください。
コメント