Make.comでChatwork×kintone双方向連携 問い合わせ対応を月5時間削減
Chatworkに届いた「これお願いします」を手でkintoneに転記し、対応後にまたChatworkへ戻って報告する──この往復をMake.comで両方向とも自動化するレシピです。依頼はkintoneに自動登録され、ステータスが「完了」になった瞬間にChatworkへ自動で返信が届きます。
- Chatworkの依頼メッセージを Make.comが自動検知し、kintoneに1件のデータ (レコード) として登録
- kintoneでステータスを「完了」に変えると、同じChatworkルームへ自動で完了報告が届く仕組み
- ポイントは Make.comのシナリオ (自動化の処理の流れ) を2本 (依頼→登録用、完了→返信用) 用意すること。1本では双方向にならない
- ChatworkとkintoneはどちらもMake.comの公式モジュール (連携用の部品) に対応しており、プログラムの自作は不要
- 担当3名・月40件程度の問い合わせなら 編集部試算で月5時間の圧縮
- Chatwork側はAPI利用に申請が必要な場合があるため、着手前に公式ドキュメントで確認する一手間が必要
編集長の見解 ── 社内の問い合わせ窓口でよく起きるのは「受付は自動化できたが、対応完了の報告だけ手作業に戻ってしまう」という中途半端な自動化です。本レシピが重視するのは、依頼の入り口 (Chatwork→kintone) と出口 (kintone→Chatwork) の両方を自動化路線に乗せること。Make.comは1本のシナリオが「1つのトリガーから始まる一方向の流れ」である以上、双方向を実現するにはシナリオを2本組むという発想の転換が必要です。この考え方は、他の「受付と完了報告をどちらも自動化したい」業務にもそのまま応用できます。
なぜ問い合わせ対応に月5時間かかるのか
総務・IT・経理などのバックオフィスがChatworkで社内問い合わせを受け付けている場合を想定します。担当3名・月40件程度の問い合わせがある中小企業で、手作業の内訳を編集部が分解しました。
| 工程 | 内容 | 月あたり所要 (40件・担当3名) |
|---|---|---|
| Chatworkの依頼をkintoneに転記 | 内容・依頼者・受信日時をコピペしてレコード作成 | 40件×4分=約160分 |
| 対応状況の巡回確認 | 未対応・対応中の依頼をkintoneで探す | 約60分 |
| 対応完了後にChatworkへ個別報告 | 「対応完了しました」と依頼者へ個別送信 | 40件×2分=約80分 |
| 対応漏れによる催促・謝罪対応 | 依頼者からの「まだですか」への対応 | 約20分 |
| 合計 | — | 約320分 (約5.3時間) |
Make.comで転記と完了報告を自動化すると、「kintoneへの転記」と「完了後の個別報告」の2工程はほぼゼロになります。巡回はkintoneのステータス一覧を眺めるだけの作業 (約15分) に、催促・謝罪対応も見落としが減ることで約5分に圧縮できると編集部は見積もっています。合計すると導入後は約20分で、月約300分 (5時間) の圧縮 に相当します。
続いて、編集部が設計した全体像を2つのProcessFlowで示します。
完成形のフロー (ProcessFlow ×2)
双方向連携は「依頼→登録」と「完了→返信」という別々の2シナリオで構成します。まず依頼を受け付ける側です。
Chatworkの問い合わせルームに投稿されたメッセージをMake.comが検知し、kintoneにレコードとして登録する設計
次に、対応が終わった後にChatworkへ知らせる側のシナリオです。
kintoneのステータスが「完了」に変わった瞬間をMake.comが検知し、依頼元のChatworkルームへ完了報告を投稿する設計
この設計の肝は、シナリオ1でkintoneのレコードに依頼元のroom_idとaccount_id (依頼者のChatworkアカウントID) を保存しておくことです。この2つの値を記録しておかないと、シナリオ2で「どのルームの誰に返信すればいいか」がわからなくなります。次のセクションで、この保存項目を含めたkintone側のフィールド設計を具体的に示します。
次に、kintoneアプリ側で用意すべきフィールドを整理します。
kintoneアプリ側のフィールド設計
このレシピを組む前に、kintoneに「問い合わせ管理」用のアプリを1つ用意し、次のフィールドを持たせます。
| フィールド名 | 種類 | 用途 |
|---|---|---|
| 依頼内容 | 文字列 (複数行) | Chatworkメッセージの本文をそのまま保存 |
| 依頼元room_id | 文字列 (1行) | 返信先のChatworkルームを特定するキー (必須) |
| 依頼元account_id | 文字列 (1行) | 依頼者を指名して返信するためのID (必須) |
| 依頼者表示名 | 文字列 (1行) | 巡回時に人が読むための担当者名・依頼者名 |
| 受信日時 | 日時 | Make.comのnow関数で自動挿入 |
| ステータス | ドロップダウン (未対応/対応中/完了) | 進捗の管理。kintoneの「プロセス管理」機能でも実現できますが、初期値の扱いが設定に左右されるため、まずはドロップダウンで組むのが簡単です |
| 担当者 | 文字列 (1行) または ユーザー選択 | 誰が対応しているかの可視化 |
依頼元room_id と 依頼元account_id の2項目が、双方向連携の要になります。この2つを保存し忘れると、対応完了後にどこへ返信すべきかがわからず、シナリオ2が機能しません。次は、この設計を踏まえた具体的な設定手順です。
続いて、ゼロから稼働までの75分手順を時系列で示します。
設定手順 (TimelineSteps)
[To:12345678] のように相手を指名するタグ) を入れて完了報告を投稿する。kintoneアプリ作成からテスト完了までの75分手順 (PC操作のみ、コード不要)
ここまでで基本の双方向連携は稼働します。次に、料金と運用ボリュームの関係を編集部の試算で具体的に示します。
編集部のシミュレーション — 料金と運用ボリューム
以下は 編集部による試算 です。実際のコストは問い合わせの件数・シナリオ構成により変動します。前提: 担当3名、月40件の問い合わせを2シナリオ (登録用+返信用) で処理する中小企業を想定。為替は $1 = ¥150 で換算 (2026年7月時点の編集部参照値、契約時の実レートで再計算してください)。
| 項目 | 想定値 | 月額換算 |
|---|---|---|
| 月間の問い合わせ件数 | 月40件 | 40件 |
| シナリオ1消費 (検知+Filter+登録) | 1件あたり約3クレジット | 約120クレジット/月 |
| シナリオ2消費 (検知+Filter+返信) | 1件あたり約3クレジット | 約120クレジット/月 |
| テスト・リトライ分のバッファ | 見込み | 約60クレジット/月 |
| 合計クレジット | — | 約300クレジット/月 (Free 1,000枠内) |
| Make.com Freeプラン | $0/月、シナリオ2本まで | ¥0 |
| kintone | スタンダードコース (既存導入前提) | 追加コストなし |
| 追加固定費 | — | ¥0 |
この規模であれば Make.comの無料プラン (月1,000クレジット、シナリオ2本まで、実行間隔15分以上) にちょうど収まる というのが編集部の試算です。本レシピはシナリオを2本使うため、Free プランのシナリオ数上限 (2本) をこの連携だけで使い切る点に注意してください。他の自動化も同時運用したい場合や、問い合わせ件数が月100件を超える場合は、Coreプラン ($9/月、上記レートで約¥1,350、実行間隔1分から) への切り替えを検討してください[出典]。
ここまでは順調な運用前提です。続いて、編集部が想定する落とし穴を共有します。
失敗パターンと対策
失敗パターン①: room_id・account_idを保存し忘れて返信できない ── シナリオ1でkintoneに依頼元room_idとaccount_idを保存していないと、シナリオ2で「どこに・誰宛に」返信すればいいかが分からなくなります。kintoneアプリ設計の時点でこの2フィールドを必須項目にしておき、テスト時に空欄のまま登録されていないかを必ず確認してください。
失敗パターン②: Free プランのシナリオ数上限に他の自動化とぶつかる ── Make.comのFreeプランはシナリオ2本までという制限があり、本レシピだけで枠を使い切ります。すでに他の業務でMake.comのシナリオを組んでいる場合は、Coreプラン以上への切り替えが早い段階で必要になります。導入前にMake.comの管理画面で現在のシナリオ数を確認してください。
失敗パターン③: kintoneのステータス変更は一定間隔でしか検知されない ── kintoneの「Watch Records」は、決められた間隔で変化を見に行く方式 (定期チェック型) の起点のため、ステータスを「完了」に変えてから実際にChatworkへ通知が届くまでにタイムラグが生じます。即時性が重要な問い合わせほど実行間隔を短く設定し、日常的な依頼は間隔を伸ばしてクレジット消費を抑えるのが実用的です。
編集部のヒント: 「対応中」に変わったタイミングでも一次報告を送りたい場合は、シナリオ2にRouter (条件によって処理を枝分かれさせる機能) を追加し、ステータス「対応中」向けと「完了」向けで別々のメッセージ文面に分岐させると、依頼者の不安をさらに減らせます。
通知は「早さ」より「返信先を正しく特定できているか」が最優先です。テスト時は必ず自分宛のテスト依頼で一連の流れを確認してから本番運用に切り替えてください。
次に、この連携の活用イメージを具体的なシナリオで示します。
中小企業での活用シナリオ
例えば、従業員60名の企業で、総務・IT・経理宛の問い合わせをChatworkの「バックオフィス問い合わせ」ルームに一元化しているケースを想定します。従来は担当者がルームを巡回して内容をkintoneに書き写し、対応が終わったら個別にChatworkへ「対応完了しました」と返信していました。
本レシピを導入すると、社員が投稿した瞬間にkintoneへ「未対応」のレコードが自動登録され、担当者はkintone側で対応状況を進めるだけで済みます。ステータスを「完了」に変えた瞬間、投稿した社員のChatworkルームに完了報告が自動で届くため、担当者は「報告し忘れた」という事故から解放されます。
| 導入前 | 導入後 |
|---|---|
| 依頼内容をkintoneに手で転記 | Chatwork投稿がそのままkintoneレコード化 |
| 対応完了後、個別にChatworkへ報告 | ステータス変更が自動でChatwork返信になる |
| 未対応の依頼を探すのに巡回が必要 | kintoneのステータス一覧を見るだけで把握できる |
このように、双方向連携は「入力するkintone」から「入力すれば返ってくるkintone」へ運用を変えます。最後に、規約・運用面で気をつけるべき点を整理しておきます。
規約・運用上の注意
ChatworkのAPI利用条件は事前確認が必須
Chatworkの公式APIドキュメントは、API・Webhookの利用について一部プランを除き利用申請が必要な場合があると案内しています[出典]。現行の公開プラン (フリー・ビジネス・エンタープライズ) のどれで申請が必要かは変更される可能性があるため、着手前に必ず管理者アカウントで最新の利用条件を確認してください。
kintoneのコースとAPIリクエスト上限
kintoneのスタンダードコースは、1アプリあたり1日1万件のAPIリクエスト上限があります[出典]。Make.comの「Watch Records」による定期チェックもこの上限にカウントされるため、他の自動化と合わせて運用する場合は上限に近づかないか確認してください。
個人情報・機密情報の取り扱い
問い合わせ内容に個人情報や社内の機密情報が含まれる場合、kintoneへの保存とChatworkへの返信内容に注意が必要です。返信メッセージには「対応完了しました」程度の簡潔な文面に留め、機微な情報そのものを本文に書かないようにする運用が安全です。
Make.comの通信暗号化
Make.comは通信をTLS (インターネット上の通信を暗号化する仕組み) で保護し、接続情報 (APIトークンやパスワード) も暗号化して保存されます。とはいえ、APIトークンを第三者に共有しない、担当者が退職したら再発行するといった基本運用は必須です。
モジュール名は導入時に必ず現物確認する
本記事で示したモジュール名 (Watch Messages in a Room / Create a Room Message / Watch Records / Create a Record / Update a Record Status) は執筆時点のMake.com公式アプリページに基づいています。Make.com側の仕様変更により、アプリ名やモジュール名の表記が更新される可能性があります。シナリオを組む際は、Make.comのモジュール選択画面で実際に表示される名称を必ず確認してください。
規約・運用面の注意点を踏まえたうえで、最後によくある疑問を編集部が整理します。
よくある質問
Q1. ChatworkとkintoneはどちらもMake.comの公式モジュールに対応していますか？ 対応しています。Chatworkは「Watch Messages in a Room」「Create a Room Message」など、kintoneは「Watch Records」「Create a Record」「Update a Record Status」などの公式モジュールが用意されており、本レシピはHTTPモジュールでの自作連携なしに構築できます。
Q2. Make.comのシナリオは1本にまとめられませんか？ まとめられません。Make.comの1シナリオは「1つのトリガーから始まる一方向の流れ」という仕組みのため、「Chatwork起点」と「kintone起点」の2つの入り口を持つ本レシピは、必然的にシナリオ2本構成になります。この点は多くの解説記事で見落とされがちなので、最初から2本構成で計画してください。
Q3. Slackを使っている場合はどうすればいいですか？ Make.comにはSlack向けの同様のモジュールが揃っています。Chatworkの部分をSlackの「Watch Messages」「Post a Message」系モジュールに置き換えれば、同じ設計で組めます。
Q4. Freeプランのシナリオ数上限を超えたらどうなりますか？ 新しいシナリオを作成できなくなります。本レシピの2本で上限に達するため、他の業務の自動化も計画している場合は早めにCoreプラン以上への切り替えを検討してください。
出典・参考情報
- kintone 公式 — 料金プラン (スタンダードコースの月額とAPI利用制限)
- Make.com kintone アプリ ドキュメント (Create a Record / Update a Record Status / Watch Records などモジュール一覧)
- Make.com Chatwork アプリ ドキュメント (Watch Messages in a Room / Create a Room Message などモジュール一覧、表記はMake.com側の更新で変わる場合あり)
- Make.com 公式 — 料金プラン (Free / Core プランの月額とクレジット枠)
- Chatwork Developer 公式 (API利用条件)
- Chatwork 公式ドキュメント — メッセージ記法 (To タグなどの本文記法)
- Chatwork公式 — フリープランとビジネスプランの違い (料金・プラン比較)
Make.com を無料プランで試す → ※ PR・アフィリエイトリンクを含みます
関連レシピ
- Make.comでkintone更新をSlackに自動通知 中小企業の確認漏れを月3時間削減
- Make.comでChatwork日報→スプレッドシート自動集計 週2時間の集計を削減
- Zapier×kintone 顧客フォローメール自動化 営業時間50%削減レシピ
- ZapierでChatwork→Notionタスク自動登録 依頼漏れ防止で週2.5時間削減
Mira ／ AI経営ラボ 編集長 本記事は 2026-07-29 時点の情報です。料金・機能は各社公式情報を最新でご確認ください。
Make.com を無料で試す → ※ PR・アフィリエイトリンクを含みます