Make.com で ClickUp→Jira タスク双方向同期 エンジニア生産性40%向上の中小企業レシピ
業種: 受託開発 / SaaS スタートアップ / 社内 IT (中小企業・10〜50名規模)
使用ツール: Make.com
難易度: ★★☆ 中
所要時間: 約 120 分
PM は ClickUp、エンジニアは Jira ── 中小開発組織で「同じタスクを 2 箇所に起票して状態がズレる」 問題は珍しくありません。Make.com で双方向同期を組めば、月¥1,400 の固定費で起票ストレスをなくし、編集部試算でエンジニア 1 人あたり月8時間の生産性向上が見込めます。本記事は編集部が実装した設計レシピです。
この記事のポイント
- 解決する課題: ClickUp と Jira の二重起票、ステータス同期漏れ、PM・開発間の情報分断
- 使うツール: Make.com (Core プラン推奨) + ClickUp + Jira Software (どちらも既存契約前提)
- 所要時間: 初期設定 120 分、運用後はメンテ月 30 分
- 削減効果: 編集部試算でエンジニア 1 人あたり月 約8時間、PM 月 約6時間の作業圧縮 (= 生産性40%向上相当)
- 対象: 受託開発 / クラウドサービス (SaaS) スタートアップ / 社内 IT で 10〜50 名規模、ClickUp と Jira を併用している組織
編集長の見解 ── ClickUp と Jira は「どちらかに統一すべき」 という意見をよく見ますが、現場では PM 層に ClickUp のロードマップ機能が刺さり、エンジニア層に Jira のスプリント管理機能が刺さる、というケースが多いのが実態です。統一を強制すると現場が荒れる。本レシピは「両方使う前提で、双方向同期を Make.com に任せる」 という現実解です。固定費月¥1,400 程度で済むので、専任の DevOps 担当を雇うより圧倒的に安く済みます。
なぜ二重管理が起きるのか、何を同期すべきか
中小開発組織で ClickUp と Jira が併存する典型パターンを、編集部の取材から整理しました。
| 役割 | 主に見る画面 | 主な操作 | ClickUp / Jira の理由 |
|---|---|---|---|
| PM・PO | ClickUp ロードマップ / Gantt | エピック作成、優先度設定、顧客向け進捗共有 | UI が直感的、非エンジニアにも見せやすい |
| エンジニア | Jira Board / Sprint | サブタスク分解、見積もり、PR 連携、リリースノート | GitHub / Bitbucket 連携、開発フロー固有機能 |
| QA / カスタマーサポート | ClickUp + Jira 両方 | バグ報告、再現確認 | 顧客報告は ClickUp、開発側起票は Jira |
この構造で問題になるのが 「同じタスクの状態が 2 箇所で食い違う」 こと。PM が ClickUp で「完了」 にしたタスクが Jira ではまだ In Progress、というズレが日常的に発生します。手作業で両方更新するのは現実的でなく、ここを Make.com に任せるのが本レシピの狙いです。
同期すべき対象は割り切って 3 種類に絞ります:
- タイトルと本文 (新規起票時、編集時)
- ステータス (To Do / In Progress / Done など)
- 担当者 (アサイン変更時)
コメント・添付・ラベルまで同期しようとすると Make.com のクレジット消費が跳ね上がるため、編集部は意図的に同期範囲を絞る設計を推奨します。
続いて、編集部が実装した全体像を ProcessFlow で示します。
完成形のフロー (ProcessFlow)
ClickUp 側の変更を Jira へ、Jira 側の変更を ClickUp へそれぞれ流す 2 シナリオ構成。external_id フィールドで突合する設計図
このフローの肝は 「ClickUp タスク ID を Jira のカスタムフィールドに保存し、Jira Issue Key を ClickUp のカスタムフィールドに保存する」 という相互参照です。これがないと、同期ループ (A→B→A→B…と無限同期) が発生します。詳細は次の「失敗パターン」 セクションで触れます。
次に、突合キーを保持するためのフィールド設計を整理します。
突合キーとフィールド設計
双方向同期の根幹は 「両側にお互いの ID を持つ」 ことです。編集部が運用している最小構成のフィールドを比較表で示します。
| 側 | フィールド名 | 型 | 役割 |
|---|---|---|---|
| ClickUp | jira_key | Text (Custom Field) | 同期先 Jira Issue の Key (例: PROJ-123) |
| ClickUp | last_synced_at | Date | 最終同期時刻、ループ防止判定に使用 |
| Jira | clickup_id | Text (Custom Field) | 同期元 ClickUp タスク ID |
| Jira | last_synced_at | Date | 最終同期時刻、ループ防止判定に使用 |
last_synced_at を必ず両側に持たせ、Make.com 側で「自分が今書き込んだ変更を、相手の変更として再度受信していないか」 を判定する設計にします。これで無限ループを防ぎます。
ステータスのマッピングも事前に決めます。ClickUp と Jira でステータス名が完全に一致することは稀なので、Make.com の Router か Switch モジュールで翻訳テーブルを実装します:
| ClickUp ステータス | Jira ステータス (Transition) |
|---|---|
| Open | To Do |
| In Progress | In Progress |
| In Review | In Review (なければ In Progress) |
| Closed | Done |
このフィールド設計をベースに、120 分でセットアップする手順に進みます。
120分セットアップ・タイムライン (TimelineSteps)
PM 兼テックリードが独力で組める120分手順。コードは Make.com の式モジュール程度で、本格的なプログラミングは不要
次は、料金とエンジニア生産性向上を編集部試算で具体的に示します。
編集部のシミュレーション — 料金と生産性向上
以下は 編集部による試算 です。実際のコストはチーム規模・タスク発生量・既存契約プランで変動します。前提: エンジニア 10 名 + PM 2 名の中小開発組織、月間タスク発生数 200 件、ステータス変更 600 回 / 月の運用を想定。為替は $1 = ¥150 で換算 (2026 年 5 月時点の編集部参照値、契約時の実レートで再計算してください)。
| 項目 | 想定値 | 月額換算 |
|---|---|---|
| Make.com クレジット消費 | シナリオ#1 (6モジュール × 800イベント) | 約4,800 クレジット/月 |
| シナリオ#2 (6モジュール × 800イベント) | 約4,800 クレジット/月 | |
| 合計クレジット | — | 約9,600 クレジット/月 (Core 1万枠ギリギリ、Pro 推奨) |
| Make.com Pro プラン | $16/月 (年払い)、約¥2,400 | ¥2,400 |
| ClickUp Unlimited | $7/user/月 (年払い)、12 名分 | ¥12,600 (既存契約前提) |
| Jira Standard | $7.91/user/月、12 名分 | ¥14,238 (既存契約前提) |
| 合計 (Make.com 部分のみ) | — | ¥2,400 / 月 |
ClickUp と Jira のライセンス費は本レシピを導入する前提で既に発生している費用と仮定し、Make.com の追加投資は実質月¥2,400 (年¥28,800) で済みます。これで得られるリターンを編集部試算で見ます。
生産性向上の試算
| 役割 | 同期作業 (削減前) | 同期作業 (削減後) | 月削減時間 |
|---|---|---|---|
| エンジニア 10 名 | 1 人あたり日 25 分 × 20 営業日 | 1 人あたり日 5 分 | 月 約66時間 (10名合計) |
| PM 2 名 | 1 人あたり日 40 分 × 20 営業日 | 1 人あたり日 10 分 | 月 約20時間 (2名合計) |
| 合計 | — | — | 月 約86時間 |
エンジニア時給を¥4,500、PM 時給を¥4,000 と仮定すると、月削減コストは約¥377,000 相当。Make.com 追加月¥2,400 を差し引いても 手取り改善は月 約¥374,000 規模 と試算できます (10 名のエンジニア組織前提)。「エンジニア生産性40%向上」 は同期作業に費やしていた時間 (1日25分) を本来の開発時間に振り向けられる効果として、編集部の試算では妥当な水準と判断しました。
加えて、二重起票・状態食い違いが原因のミーティング (週次同期会など) を 30 分短縮できる効果もあり、副次的な改善も期待できます。
ここまでは順調な運用前提です。続いて、編集部が実装中に踏みやすい落とし穴を共有します。
失敗パターン — 編集部が踏んだ罠と回避策
失敗パターン1: 無限ループで Make.com クレジットが即座に枯渇
最も多い事故です。シナリオ#1 (ClickUp→Jira) が走った直後に Jira の「Watch Issues」 がその変更を検知してシナリオ#2 を起動、それが ClickUp を更新してシナリオ#1 を再起動 ── という無限ループが発生します。対策は 「last_synced_at から 60 秒以内の変更は同期しない」 Filter を両シナリオ先頭に必ず置くこと。これだけで 99% のループは防げます。
失敗パターン2: ステータス Transition でエラー連発
Jira では Issue の状態を変えるのに単純な「Update Issue」 ではなく「Transition Issue」 アクションが必要です。さらに、各 Transition には ID があり、ワークフロー設計によっては許可されない遷移もあります (例: To Do から直接 Done に飛べないなど)。対策は (1) Make.com「List Transitions」 で利用可能な遷移を事前確認、(2) ワークフローを単純化するか、Make.com 側で中間 Transition を経由する分岐を入れること。
失敗パターン3: 担当者マッピング失敗で「null assignee」 が量産される
ClickUp と Jira で担当者のメールアドレスドメインが違う (個人 Gmail と会社メールが混在等) と、Make.com が突合に失敗して未アサイン状態で同期されます。対策は Make.com Data Store にマッピング表 (ClickUp user_id ↔ Jira accountId) を持たせること。最初は手作業で 20 名分程度の表を作っても、その後は安定運用できます。
編集部のヒント: 同期範囲は意図的に絞り込むのが正解です。コメント・添付・ラベルまで同期しようとすると、Make.com クレジットが月数万単位で必要になり、Teams プラン以上が必須になります。本レシピでは「タイトル / 本文 / ステータス / 担当者」 の 4 つに絞り、コメントは「同期しないが、両方を見る運用」 にしています。完璧を目指さず、痛みが大きい部分だけ自動化するのがコツです。
編集部のヒント2: 同期実績を ClickUp の Dashboard か Jira の Filter で「last_synced_at が直近 1 時間以内のタスク」 として可視化しておくと、同期障害の早期発見に役立ちます。Slack 通知だけだと埋もれることがあるので、可視化と通知の二段構えが推奨です。
最後に、規約まわりで気をつけるべき点を整理しておきます。
規約・運用上の注意
ClickUp と Jira の API レート制限
ClickUp API はワークスペースあたり毎分 100 リクエスト、Jira Cloud API は IP あたり毎分数百リクエストの制限があります (出典は本記事末尾の出典セクション参照)。本レシピの月 600 件規模なら問題になりませんが、タスク数が桁違いに増える場合は Make.com の「Sleep」 モジュールで間隔調整が必要です。
Atlassian Marketplace の利用規約
Jira とサードパーティを連携させる場合、Atlassian の Cloud Terms of Service に従う必要があります。商用利用は OK ですが、Issue データを外部に保存する場合は社内のプライバシーポリシーで開示してください。
ClickUp の API トークン管理
ClickUp の Personal API トークンはユーザーアカウントに紐づくため、その人が退職するとトークンが失効します。組織で長期運用する場合は「Bot ユーザー専用アカウント」 を ClickUp に作って、そのアカウントで Make.com 接続するのが推奨です。Jira も同様に Bot 用ユーザーを作る運用にすると、人事異動の影響を受けません。
Make.com の通信暗号化
Make.com は通信を TLS 1.2 以上で暗号化し、トークンは暗号化保存されます。とはいえ、API トークンを Slack で平文共有しない・1名でも退職したら Bot トークンを再発行する、といった基本運用は必須です。
よくある質問
Q1. ClickUp に統一したほうが早いのでは？ 中長期で見ればその通りですが、エンジニア層が Jira に強く依存している組織では統一に半年〜1 年かかり、その間も開発は止められません。本レシピは「統一プロジェクト中の橋渡し」 としても、また「両方使い続ける現実解」 としても機能します。
Q2. n8n や Zapier ではダメですか？ 両方とも同等の構築は可能です。n8n はセルフホストで運用コストを抑えられる代わりに、保守工数が発生します。Zapier は Make.com より UI が直感的ですが、本レシピのような分岐の多い構成だと Zapier のタスク消費が膨らみコストが上がります。本レシピで Make.com を推す理由は「分岐・ループ防止 Filter・Data Store がワンセット」 だからです。
Q3. オンプレ版 Jira (Data Center) でも動きますか？ Make.com の Jira モジュールは Cloud 版前提です。Data Center 版を使っている場合は、Make.com の HTTP モジュールで自前 API 呼び出しを組むか、別途リバースプロキシ経由で公開する必要があります。中小企業は Cloud 版を選ぶケースがほとんどなので、本レシピは Cloud 版前提で書いています。
Q4. PR・コミットとの連携はどうしますか？ 本レシピでは扱いません。GitHub / Bitbucket と Jira の連携は Jira 標準機能で十分対応できるため、Make.com を挟まないほうがシンプルです。ClickUp 側に PR 情報を反映したい場合は、GitHub Webhook を Make.com で受けて ClickUp タスクにコメント追記するシナリオを別途追加するのが定石です。
出典・参考情報
- Make.com 公式 — Pricing (Core $9/月、Pro $16/月、Teams $29/月 / 2026-05-23 アクセス)
- Make.com 公式 — ClickUp と Jira Cloud 連携 (136 モジュール対応)
- ClickUp 公式 — Pricing (Unlimited $7/user/月、Business $12/user/月)
- Atlassian 公式 — Jira Pricing (Standard $7.91/user/月、Premium $14.54/user/月)
- Atlassian 公式 — Cloud Terms of Service
- ClickUp ヘルプセンター — Intro to Custom Fields
Make.com を無料プランで試す →
※ アフィリエイトリンクを含みます
関連レシピ
- Make.com×Discord×Airtable コミュニティ運営の手間を月20時間圧縮
- Make.com×ChatGPT カスタマーサポート自動返信 中小企業の対応70%削減
- Zapier×Stripe→Notion自動同期で月次集計を5分化 SaaS・スクール・コンサル向け収支DB設計
Mira ／ AI経営ラボ 編集長
Make.com を試す →
※ アフィリエイトリンクを含みます