Yoomとは？国産iPaaSの仕組み・料金・kintone連携の実装と採用判断【2026年版】

Yoom（ユーム）は、フローボットと呼ぶ自動化フローにトリガーとオペレーションを積み上げて、SaaSどうしをつなぐ国産のiPaaSです。提供元のYoom株式会社は2022年6月23日設立。この記事では、フローボットの構成要素、タスク実行数という課金単位、プラン別のステップ数上限、Webhook起動と起動間隔ポーリングの使い分け、kintone連携で公式ヘルプが原因を明記している重複起動の回避策までを実装者の粒度で扱います。

まとめ｜Yoomを採用してよい業務と外部委託に回すべき業務の線引き

Yoomが強いのは、kintone・freee・Chatworkなど国内SaaSを起点にしたバックオフィス業務の連携です。UIもサポートも日本語で、テンプレートから組み始められます。弱点は課金単位にあります。「タスク実行数」はオペレーションを重ねるほど増えるため、1件あたり何タスク使うかを設計段階で数えないと、想定より上のプランへ押し上げられる構造です。

採否の目安はこうです。1日の処理件数が数十件までで、扱うデータが1レコード単位に閉じ、例外処理が数パターンに収まるなら内製する価値があります。日次で数千件のバッチ、複数テーブルの一括更新、十数通りの例外分岐——このいずれかなら業務システム側の実装へ寄せてください。海外SaaS中心ならZapier、Microsoft 365基盤ならPower Automateが先の候補で、課金の考え方はZapierとは？読み方・できること・料金とタスク課金の仕組み【2026年版】、9製品の横並びはiPaaSの比較9製品｜料金と課金単位・接続数で選ぶ判断軸と規模別の結論で確認できます。

Yoomの基本構造｜フローボットとトリガー・オペレーションの関係

公式ヘルプが定義する用語の階層を押さえておくと設計が早く進みます。名称は独自ですが、構造は一般的なワークフローエンジンと変わりません。

フローボットの構成要素｜トリガー・オペレーション・アウトプットの役割

公式ヘルプは、フローボットを「一連の業務フロー」と定義し、複数の単一タスクを組み合わせて実行するものとしています。入口がトリガー（起動条件）、実処理の単位がオペレーション（対応依頼、承認、データ操作、アプリ連携、書類発行、メール送信など）です。各オペレーションの実行結果はアウトプットとして保持され、公式ヘルプはこれを「いわゆる『変数』のような役割」と説明しています。

オペレーション間には分岐・ループ・並列処理を挟めるので、直列パイプではなく条件付きの有向グラフとして組めます。実装者から見れば、トリガーがイベントソース、オペレーションがハンドラ、アウトプットがコンテキスト変数にあたる構造です。

7種類のトリガーと、業務イベントに合わせた起動条件の選び分け

公式ヘルプに掲載されている起動条件は、手動起動、フォーム送信、スケジュール指定、条件に合うメールの受信、アプリイベントの受信、Yoomデータベースのイベント、Webhook受信、Web会議の終了です。後続のオペレーションを設定したうえでトグルをONにしないと起動しない点も明記されています。トリガーだけでは有効化できない仕様です。

選び分けの基準はイベントの発生元です。相手アプリがWebhookを出せるならWebhook受信、出せないならアプリイベントの定期取得、社外申請が起点ならフォーム送信、締め日処理ならスケジュール指定。曖昧なまま「とりあえずスケジュール起動」で組むと、タスク消費が無駄に膨らみます。

プロジェクト単位でのフロー管理と、業務ごとに切る資産の分け方

公式ヘルプはプロジェクトを「いわゆるフォルダのような役割」と説明し、各プロジェクトの中にYoomデータベースとフローボットが紐づくとしています。設計の勘所は、部署単位ではなく業務単位で切ること。「経理部」ではなく「請求書発行」「経費精算」で分けておくと、業務の一部を外部委託へ切り出すときに対象プロジェクトだけを渡せば済みます。

タスク実行数という課金単位とフロー設計がコストへ直結する仕組み

Yoomの費用を左右するのはユーザー数ではなくタスク実行数です。読み違えると、機能上は動くのに費用だけが膨らみます。

タスク実行数のカウント条件｜オペレーション単位で積み上がる消費量

公式ヘルプは、タスク実行数について「オペレーションの数やデータコネクト等を利用するとカウント」されると記載しています。フローボットを1回起動したら1タスク、ではありません。フローの中に置いたオペレーションの数だけ積み上がる建て付けです。データコネクトについては、100レコードの追加・更新ごとに1タスクとして数えるという説明が公開情報に出ています。

この違いは見積もりに直結します。5オペレーションのフローを1日30回起動する業務なら、単純計算で1日150タスク、営業日20日で3,000タスク。フロー1本でこの規模です。

分岐・ループ・並列処理がタスク消費を膨らませる設計上の落とし穴

消費が読みにくくなる典型がループです。取得した10件のレコードに対して1件ずつ更新と通知を行うと、ループ内のオペレーション数×件数が消費されます。件数が可変の業務では、繁忙期に月間上限へ到達する事態が起きます。

削り方は3つ。トリガー条件で処理対象を絞ってフローに入る件数を減らす、1件ずつ回さず一括更新に置き換える、通知や記録のような「なくても業務が止まらない」オペレーションを間引く。優先順位もこの順です。トリガー条件の絞り込みだけで消費が半分以下になる業務は珍しくありません。

月間タスク数の見積り手順｜対象業務の件数から必要プランを逆算

プランは機能で選ぶのではなく、件数から逆算します。手順は次のとおりです。

1. 対象業務の1か月あたりの発生件数を、繁忙期の実績で数える
2. フローボット1本のオペレーション数を数える（分岐は通る側の最大値で見る）
3. 件数×オペレーション数でフローごとの月間消費を出す
4. 載せる予定のフローを合計し、2割ほど余裕を上乗せする
5. その数値を満たすプランを選び、ステップ数上限も併せて確認する

繁忙期の実績で数える理由は、平常月の数字で契約すると期末や月初に上限へぶつかるからです。2割の上乗せは、運用開始後に「ついでにこれも」と要望が出る分の余白と考えてください。

料金プラン4段階の機能差と、ステップ数上限が実装設計に与える制約

料金は無料のフリープランに加えて有料3段階という構成です。ただし公開情報の金額には出典間で開きがあるため、契約前に公式の料金ページで確認する前提で読んでください。

フリー・ミニ・チーム・サクセスの4段階とタスク上限の対応関係

2026年6月28日時点で検証された第三者の比較情報では、次の構成が示されています。金額は税抜で、年契約にすると月あたり2割ほど下がる建て付けです。

フローボット数はフリーが5個、有料プランは無制限とされています。注意したいのは、ミニを9,600円、チームを24,000円と記載する出典も残っている点です。料金改定の前後で情報が混在しているため、稟議に使う数字は公式の料金ページと見積書から採ってください。

ステップ数上限がフロー分割を強いる場面と、分割時の連携の作法

金額より先に効いてくるのがステップ数の上限です。フリーの5ステップは、トリガー＋データ取得＋分岐＋更新＋通知でちょうど埋まります。実務のフローは、エラー時の分岐や補足情報の取得を足すとすぐ10を超えるため、本番運用は上位プランが前提になります。

上限に当たったときの逃げ道はフローの分割です。前段の終端でYoomデータベースへ書き込み、そのレコード更新をトリガーに後段を起動する。どこで止まったかがデータに残るので障害調査も追えます。ただし分割はタスク消費を上げるため、月間件数が少ないなら分割、多いならプラン変更が合理的な線です。

OCR・AI処理やAPI連携が上位プラン限定になる機能差の見極め

プラン差は金額とステップ数だけではありません。第三者の比較情報では、OCRや音声データの文字起こし、IP制限がチーム相当以上、SAML設定や二要素認証の必須化、ブラウザ操作の自動化がサクセス相当と整理されています。請求書をOCRで読み取る業務なら、下位プランでは検証すらできない可能性があります。

情報システム部門が入る案件では、IP制限とSAMLの位置づけを先に確認してください。この2つは後から要件に挙がる頻度が高く、そのときプラン変更が避けられません。セキュリティ要件を満たすプランの金額を初期見積もりへ入れておくと安全です。

アプリ連携の実装｜Webhook起動と起動間隔ポーリングの使い分け

Yoomでアプリを起点にフローを動かす方法は2系統あります。どちらを選ぶかで、反映までの待ち時間もタスク消費も変わります。

Webhook起動と起動間隔トリガー｜遅延と負荷で決まる方式選択

Webhook起動は、相手アプリ側のイベント発生を受け取って即座にフローを動かす方式です。起動間隔トリガーは、指定した間隔でYoomが相手アプリを見に行き、変化があれば動かすポーリング方式にあたります。

即時性が業務価値に直結するなら前者、そうでないなら後者。判断はこれだけで足ります。承認依頼の通知が5分遅れても業務は回りますが、店舗のオーダー連携が5分遅れると回りません。許容遅延を先に決めてから方式を選んでください。

起動間隔5分・15分・30分・60分の選択と業務要件のすり合わせ

公開情報によれば、kintoneのアプリトリガーでは起動間隔を5分・15分・30分・60分から選べます。短い間隔ほど反映は速くなりますが、そのぶん巡回の回数が増えます。締め日にまとめて処理する業務で5分間隔を選ぶ理由はありません。

決め方は業務の締め切りからの逆算です。夕方17時までに担当者が確認すればよい情報なら60分で足ります。当日中に一次対応が要るなら30分、相手を待たせる場面が挟まるなら15分以下。この順で下ろせば、間隔を必要以上に短くせずに済みます。

マイアプリ登録とアカウント権限｜連携が止まる典型的な失敗原因

連携が動かない原因は、フロー設計よりマイアプリ側にあることが多いものです。登録アカウントの権限が対象レコードに届いていない、認証の有効期限が切れた、退職者のアカウントで登録されていた——この3つで大半を占めます。

テスト時に固有のつまずきもあります。公式ヘルプは、Webhook起動でも起動間隔トリガーでも、設定後にアプリ側で該当イベントが発生していないとテストがエラーになると説明しています。「設定したのにテストが通らない」の多くは不具合ではなく、テスト用のレコードを1件作れば解消する事象です。

未対応SaaSへの接続｜カスタムWebhookとHTTPリクエストの橋渡し

連携先の一覧に載っていないサービスでも、つなぐ道は残っています。

カスタムWebhookで受け取る外部イベントと発行URLの扱い

公式ヘルプは、未連携のアプリでもWebhook機能を持つサービスなら、Yoomが受け取ってフローボットを起動できると説明しています。手順は、フローボット編集ページでアプリトリガーを選び、連携アプリの選択で「カスタムアプリ」、トリガーアクションで「カスタムWebhook」を指定する流れです。発行URLを相手サービスに設定すれば、受け取ったレスポンスをアウトプットへ格納して後続から参照できます。

運用上の注意は2点。発行URLを知る者は誰でもフローを起動できるため、認証情報と同じ扱いで管理します。もう1点、公式ヘルプにはこの設定がサポート外である旨の但し書きがあり、相手サービスのペイロード仕様変更には自力で追随する体制が要ります。

自社システムとつなぐ設計｜API公開範囲とサポート外領域の切り分け

自社の基幹システムとつなぐ場合、イベントを出す側を自社に寄せるか、Yoomから取りに行くかで難易度が変わります。自社側にWebhook送信を実装できるならカスタムWebhookで受け、改修が難しいなら中間テーブルをYoomから定期的に見に行く構成にします。

線を引くべきはサポートの届く範囲です。標準連携の不具合はYoomのサポートで解決できますが、カスタムWebhookや自社API側の仕様変更は自社の責任範囲になります。連携本数が5本を超えるあたりから、この保守負担は無視できません。iPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説で整理したとおり、iPaaSはつなぐ手段であり、つないだ後の保守までは肩代わりしません。

重複起動と無限ループ｜kintone連携で起きる不具合と回避の設計

Yoomとkintoneの組み合わせは国内で最も使われるパターンの一つですが、公式ヘルプが原因と回避策を明記している既知の落とし穴があります。設計前に知っておくと、稼働後の障害を1件減らせます。

kintone連携で重複起動が起きる3つの原因と監査ログでの切り分け

公式ヘルプは、kintoneのWebhookトリガーおよび起動間隔トリガーが重複起動する原因を3つ挙げています。1つ目は重複登録で、同一のWebhook URLが同一アプリ内に複数設定されていると1度のイベントでも複数回検知される可能性があるとしています。2つ目は自動処理の検知。JavaScriptによるプログラム実行もkintone側ではWebhookアクションとして扱われます。3つ目が無限ループです。

切り分けは順番どおりに進めます。まずkintoneのWebhook設定でYoom発行のURLが複数登録されていないかを確認し、次に監査ログでレコードを更新した主体が人か自動処理かを見る。この2つで原因の大半は特定できます。

レコード更新の無限ループ回避｜処理対象を絞る条件分岐の入れ方

最も厄介なのが無限ループです。公式ヘルプによれば、kintoneのレコード編集をトリガーに起動し、その処理内で同じレコードを再編集すると、その編集をトリガーが再び検知して起動する状態になります。1件の更新がタスクを延々と消費する事故です。

回避策は決まっています。「処理済みフラグ」のフィールドを持ち、トリガー直後の分岐で処理済みなら何もせず終了、更新オペレーションでフラグを立てる。この一往復を必ず入れます。トリガー条件を特定ステータスへの変更に絞れるなら、そちらの方が確実です。アプリ側で解く部分とYoom側で解く部分の切り分けは、kintoneとは？できること・料金・プラグインからノーコードで内製する判断まで解説が判断材料になります。

二重実行に備える冪等性の作り込みと、失敗時の再実行の設計方針

重複起動を完全にゼロにはできない前提で組むのが、実装者としての安全側の判断です。同じ入力で2回動いても結果が変わらない状態、つまり冪等性を業務側に持たせておきます。

レコードIDや伝票番号のような業務キーを外部システム側の一意キーに使い、登録ではなく「存在すれば更新」へ寄せます。メール送信や決済のように取り消せない副作用を持つオペレーションは、実行前に送信済み記録を確認する分岐を挟む。途中から再開できる粒度でフローを分けておけば、手動リカバリの負担も下がります。

Yoomで作らない方がよい業務｜見送り条件と受託開発への切り替え点

ここは他社の解説記事が踏み込まない部分なので、条件を付けて言い切ります。Yoomは万能ではなく、向かない業務に載せると運用が壊れます。

大量データのバッチ処理と厳密な整合性を求める業務での見送り判断

日次で数千件を超えるレコードを処理する業務に、Yoomを使うべきではありません。理由は性能ではなく課金構造です。タスク実行数はオペレーション単位で積み上がるため、件数が増えるほど費用が線形に伸びます。データベース側で1本のクエリを流せば終わる処理を、レコード単位のループで回すのは設計として筋が悪いという判断になります。

もう一つの見送り条件が、複数システムへの更新を成功か失敗かに揃えたい業務です。在庫引当と受注登録と会計仕訳を「どれか失敗したら全部戻す」形にしたいなら、フローボットの途中失敗では戻し切れません。補償処理を自前で全部書くくらいなら、業務システム側でトランザクションを張る方が確実で保守も読めます。

例外処理が多い業務フローを内製で抱え込むと運用が破綻する条件

件数が少なくても危ないパターンがあります。例外分岐が十数通りに広がる業務です。「この取引先だけ締め日が違う」「この商品だけ承認者が2人」といった例外を分岐で足していくと、フローボットは急速に読めなくなります。作った本人が異動した瞬間、誰も触れない資産に変わります。

目安はこうです。分岐が5本を超えたら設計を疑い、10本を超えたらノーコードで持ち続ける判断を見直す。分岐が増える原因は業務ルールの不統一にあることが多く、ツールを変えても解決しません。ノーコード全般の限界はノーコードとは？ローコードとの違い・できること・限界を実務目線で解説にまとめています。

Yoomで作り、受託開発へ引き継ぐ｜業務規模で決める役割分担の線

現実的な着地点は併用です。発生件数が少なく変更が多い業務はYoomで現場が持ち、件数が多く仕様が固まった業務は開発側へ寄せる。この線引きなら現場の機動力と基幹処理の堅牢さを両立できます。

切り替えのサインは3つ。月間タスク数が契約プランの上限に近づいた、ステップ数上限のためフローを3本以上に分割した、同じフローの改修を月2回以上行っている。いずれかに当てはまる業務は、ノーコードの適用範囲を超えています。一創ではiPaaS導入支援（Zapier／Make／Workato／Yoom）として、フローの棚卸しから開発へ移す業務の切り出しまで対応します。動いているフローを捨てず、重い部分だけを実装へ移す進め方が現実的です。

よくある質問

Yoomの導入検討で実際に多い質問を、公式ヘルプと公開情報の範囲で答えます。

Yoomの読み方は？社名との関係はどうなっていますか？

読み方は「ユーム」です。提供元のYoom株式会社は2022年6月23日に設立され、同年7月29日に株式会社TimeTechnologiesからYoom事業を譲り受けました。サービス自体は2021年8月にTimeTechnologiesが開始したもので、公式ヘルプセンターの表記に旧社名が残る箇所があるのはこの経緯によります。

Yoomの無料プランだけで実務は回りますか？

本番運用には向きません。公開情報のフリープランはフローボット5個・月100タスク・ユーザー1名で、ステップ数の上限も5とされています。トリガー＋データ取得＋分岐＋更新＋通知でちょうど埋まる規模です。使いどころは、対象アプリのトリガーが実際に発火するか、必要なデータ項目がアウトプットに出るかを確かめる検証に限られます。

Yoomの評判で多い不満はどこにありますか？

公開されている比較記事やレビューで繰り返し挙がるのは、タスク実行数の消費が想定より速いという声と、フローが増えたときの管理が煩雑になるという声です。前者はオペレーション単位で数える課金構造を理解すれば設計で抑えられ、後者はプロジェクトを業務単位で切って命名規則を決めれば軽減できます。どちらも導入初期の設計で決まる部分です。

YoomとkintoneのAPI連携はどこまで作り込めますか？

標準のkintone連携でレコードの取得・追加・更新・削除を扱えます。Webhook起動と起動間隔起動の両方に対応し、起動間隔は5分・15分・30分・60分から選択。届かない範囲はカスタムWebhookで受ける形に寄せます。注意点はJavaScriptカスタマイズが入った環境で、その更新もWebhookイベントとして検知されます。

Yoomで作ったフローは他の担当者へ引き継げますか？

引き継げます。フローボットはプロジェクト単位で管理され、その中にYoomデータベースとフローボットが紐づく構造です。ただし連携先アカウントを登録するマイアプリは登録者に紐づくため、個人アカウントのままだと担当者の退職時に連携が止まります。部署として管理するアカウントで登録するのが引き継ぎ前提の設計です。

関連記事

• iPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説：Yoomが属するiPaaSという分類そのものの定義と、RPAとの役割の違いを整理しています
• iPaaSの比較9製品｜料金と課金単位・接続数で選ぶ判断軸と規模別の結論：Yoomを含む9製品を料金と課金単位で横並びに比較し、規模別の結論を示しています
• kintoneプラグイン開発とは｜manifest構成から配布・内製外注の判断まで：Yoomで解かずkintone側で解くべき処理を、プラグイン実装の観点から判断できます
• Amazon AppFlowとは｜SaaS連携のノーコード統合の仕組み・料金・実装と採用判断を解説：AWS基盤でSaaS連携を組む場合の選択肢として、課金単位と実装方法を比較できます