kintone × クラウドBOT 連携で業務を一括自動化。ロボット連携プラグインの活用例

kintone は使い込むほどに「ボタン1つで他のシステムにもデータを渡したい」「夜間に自動で在庫を取り込みたい」というニーズが出てくる。標準アクションや Webhook、外部の iPaaS でできることも増えてきたが、相手側の Web サービスに API がない、もしくは認証が複雑で扱いきれないケースは依然として多い。そこで存在感を増しているのが、クラウド型 RPA「クラウドBOT」と kintone をつなぐ連携プラグインである。

提供元の株式会社 C-RISE は 2023 年 11 月の機能拡張で kintone との連携を大きく強化し、その後 2024 年に「BOT から kintone API を呼び出す機能」を追加。直近のアップデートでは 複数レコードを対象にしたロボットの一括実行 にも対応し、kintone を起点とした業務自動化の射程が一段と広がった。本記事では、はてなベース株式会社が kintone × freee の DX 導入支援で蓄積してきた運用知見をふまえ、プラグインの中身・既存自動化手段との違い・業務別の使いどころ・導入設計の落とし穴までを実務目線で整理する。

クラウドBOT 連携プラグインの中身を整理する

まずは事実ベースで、プラグインの仕様を押さえておく。提供元の公式情報および kintone エコシステム上の公開ドキュメントから、現時点で明らかになっている要点をまとめると以下の通りである。

提供元	株式会社 C-RISE（富山県高岡市）
対応プラットフォーム	kintone（サイボウズ提供の標準環境）
実行トリガー	アプリ画面の「実行」ボタン／レコード登録・更新・削除イベント／Webhook 連携
対応処理	Web ブラウザの自動操作 BOT 実行、kintone API 経由のレコード取得・追加・更新・複数レコード一括処理
プラグイン料金	無料
BOT 実行料金	クラウドBOT 無料プランで月 30 分の実行枠あり。以降は有料プランで実行時間を拡張
サポート	技術サポートは無料で提供

コア機能はシンプルで、kintone アプリにプラグインを設定すると「実行する」ボタンが現れ、対象レコードのデータを入力値としてクラウドBOT 側のロボットを呼び出せる。ロボットは Web ブラウザを自動操作して外部サービスにログインし、データ入力・取得・帳票出力などを行ったうえで、結果を kintone レコードに書き戻すという流れになる。

プラグイン v1.2.0 以降では、ロボットの出力結果を「新規レコード追加」だけでなく 既存レコードの上書き更新 としても保存できるようになった。さらにクラウドBOT 側のアップデートで、複数レコードを選択して一括でロボットを走らせる 運用や、kintone API 連携機能による「レコード取得／複数レコード取得／レコード追加／複数レコード追加／レコード更新／複数レコード更新／レコード追加・更新／複数レコード追加・更新」の 8 種類のアクションをロボット内から呼び出すことも可能となっている。2 要素認証や SAML 認証、クライアント証明書、AI-OCR との組み合わせもサポートされており、業務システムの自動化対象が広がる点が特徴だ。

既存の自動化手段と何が違うのか

kintone の自動化手段はここ数年で一気に増えた。標準のアクション機能、Webhook、サイボウズ純正の連携コネクタ、Power Automate、Zapier、Make などの iPaaS、そしてデスクトップ RPA。クラウドBOT 連携プラグインはこれらと競合する側面もあるが、得意領域はかなりはっきり分かれる。整理すると次のようになる。

kintone 標準アクション	アプリ間のレコード複製、ステータス連動の単純な処理	外部 Web サービスとの連携は不可
Webhook + 自社実装	API が公開されている SaaS との柔軟な双方向連携	外部側 API がないと打つ手なし、保守は自社責任
Power Automate / Zapier / Make	標準コネクタが提供されている SaaS 同士の連携、定型イベントの起点配信	コネクタ未対応の業務システムは扱えない、フロー数で課金が膨らみがち
デスクトップ RPA（WinActor / UiPath 等）	社内専用システム・基幹システムの画面操作、Excel マクロ補完	実行端末の電源管理・OS 更新影響・ライセンス費用が重い
クラウドBOT 連携プラグイン	API なしの Web 画面操作、2 要素認証つき社外システム、kintone を司令塔にした業務横断自動化	デスクトップアプリ操作は対象外、BOT 実行時間に応じた課金

ポイントは、「相手側に API がない／公開されていない Web サービス」を kintone から自動操作できる 点と、kintone を業務の司令塔に置き続けられる 点である。たとえば自治体ポータル、独自 EC モール、業界特化 SaaS のように、Zapier や Power Automate のコネクタが用意されていない先は意外と多い。こうした「最後の 1 マイル」を埋めにいけるのが画面操作型 RPA の強みであり、クラウドBOT はそれをクラウドで完結させられる点でデスクトップ RPA より運用負担が軽い。

一方で、API がきれいに整備されている freee や Salesforce、Google Workspace のような相手は、画面操作よりも素直に API 連携した方が安定する。はてなベースが freee と kintone で IT 導入補助金 の導入を支援してきた現場でも、freee 側は API、kintone 側はカスタマインや標準機能で結び、そこから先の「相手に API がない部分」をクラウドBOT のようなツールで補完する設計を採ることが多い。手段ごとの得手不得手を理解したうえで、適材適所に組み合わせるのが現実解である。

業務別に見るクラウドBOT × kintone 活用シナリオ

クラウドBOT 連携プラグインを最も活かせるのは、月次・日次で必ず発生し、しかも外部の Web サービスを人が画面でぽちぽち操作している業務である。はてなベースが実際の DX 導入支援で見てきたパターンと、提供元が公開している事例をベースに、業務別の使いどころを 4 つ整理する。

給与・人事労務まわり

勤怠データを kintone で集約しつつ、給与計算自体は外部の SaaS や社労士事務所が管理しているケースは中小企業で非常に多い。「給与確定後に各従業員へ明細を配布する」「年末調整書類のステータスを月次で取りに行く」といった工程は、API が公開されていない給与システムだと毎月手作業で繰り返すことになりがちだ。クラウドBOT で対象月の従業員レコードを一括選択し、外部システムから明細 PDF をダウンロードして kintone レコードに添付する、というロボットを組めば、月数時間の手作業がボタン 1 クリックに置き換わる。

経費・仕訳の取り込み

経費精算は freee や マネーフォワード のように API が整っている SaaS が増えたが、現場では依然として「専用 Web ポータルから CSV を落とし、kintone に取り込み、別の会計システムにアップロードする」というオペレーションが残っていることが多い。クラウドBOT で「ポータルからの CSV ダウンロード → kintone へのレコード一括追加 → 担当承認ステータスの更新」までを一連の BOT として組めば、経理担当が月初に張り付いて行っていた取り込み作業を夜間バッチに寄せられる。kintone API 連携機能の「複数レコード追加・更新」が効くのはまさにこの領域だ。

営業・顧客対応の日報自動化

営業日報やインサイドセールスの活動ログを kintone で管理しているチームは多いが、商談相手の情報を毎回検索して転記する手間がボトルネックになりがちだ。kintone レコード登録をトリガーに、企業名から法人番号公表サイトを照会して所在地・業種を補完する、不動産業なら住所から緯度経度や最寄駅を自動取得して案件レコードに反映する、といった用途はクラウドBOT が得意とする領域である。提供元の事例でも、不動産業の Y 社が「住所からの緯度経度・最寄駅取得」をプラグインで自動化したことで、コピペ作業の効率を大きく改善できた事例が公開されている。

在庫・EC マスタの双方向連携

EC を複数モールで展開している事業者にとって、在庫数と価格のモール間同期は典型的な悩みどころである。提供元事例では、物販業の T 社が kintone を在庫マスタにして、3 つの EC サイトに在庫情報を自動連携することで、1 日 2 時間・月 40 時間以上の作業時間を削減したという。kintone レコード更新を Webhook で受け取り、各 EC サイトの管理画面を BOT が巡回して在庫数・価格を反映するという構成は、API 連携が不完全なモールでも実装可能だ。複数レコードを一括対象にできるようになったことで、季節商品の棚替えや一斉価格改定のような「面で動かす」タスクが現実的な所要時間に収まる。

はてなベース推奨アクション。自動化を「壊れにくく」運用するための設計指針

RPA 系ツールの導入で必ず起きるのが「最初は華々しく回ったのに、半年後には誰も触らない壊れたロボット」が量産される問題だ。クラウドBOT も例外ではない。kintone × クラウドBOT を長く運用するために、はてなベースが導入支援の現場で守るようにしている設計指針を 4 点共有しておく。

• 1. 司令塔は kintone に固定する — 自動化の起点・状態管理・履歴をすべて kintone レコードに集約する。BOT 側に状態を持たせると、画面構造が変わった瞬間に何が動いていたか追えなくなる。kintone のステータス管理と通知機能を組み合わせ、BOT は「処理する手」だけに徹させる
• 2. 一括実行は段階的に育てる — いきなり数百レコードに対して BOT を走らせるのではなく、まずは 1 件、次に 5 件、最後にバッチ全件、という順で慣らす。kintone 側で BOT 実行ステータスを保持しておき、失敗レコードだけ再実行できる作りにしておく
• 3. 認証情報のガバナンスを最初に決める — 2 要素認証や SAML、クライアント証明書を BOT に持たせる場面では、誰がいつ更新するのか、退職者の認証情報をどう失効させるのかを運用ルールとして文書化する。情シスを巻き込まないまま BOT を量産すると、退職時の権限剥奪が形骸化する
• 4. 「手で 30 秒の仕事」を BOT 化しない — 自動化の費用対効果は実行頻度 × 1 件あたりの削減時間で決まる。月 1 回・30 秒の作業を自動化しても運用コストの方が高い。月次・日次で発生する 5 分以上の繰り返し業務に絞って投資判断する

特に重要なのは 3 点目の認証情報ガバナンスだ。クラウドBOT は 2 要素認証つきアカウントへの自動ログインや AI-OCR にも対応しており、業務の自動化対象が一気に広がる反面、ロボットが扱う認証情報の量が膨らむことを意味する。情シス部門・社労士・税理士・営業マネージャなど、kintone 上で複数の役割が交差する組織では、「どの BOT がどの認証情報を使っているか」を kintone アプリ自体で台帳化しておく ことを強くおすすめしたい。RPA はガバナンスを後から付け足すのが極めて難しい領域である。

まとめ

クラウドBOT 連携プラグインは、「API がない Web サービス」と「kintone を司令塔にしたい業務オペレーション」をつなぐ実用的なピースである。プラグイン本体は無料、クラウドBOT 自体にも無料プランがあるため、まずは月次で繰り返している 1 業務をターゲットに小さく試すのが最短の入り口になる。複数レコード一括実行や kintone API 連携の拡張により、給与・経費・営業・在庫管理といった主要業務領域で実用レベルの自動化が組めるところまで来ている。

肝になるのは、技術選定そのものよりも「何を司令塔に置き、どのツールを画面操作の手として使い、認証情報をどう運用するか」という設計判断だ。はてなベースは kintone × freee を軸に、外部 SaaS や RPA も含めた業務自動化の全体設計から運用定着までを一貫支援している。kintone をハブにした業務自動化を本格化させたい企業は、まずは現行の手作業棚卸しから一緒に始めるのがおすすめだ。