Zoho Creatorとは？Delugeとデータモデルから読み解く実装の勘所と導入判断【2026年版】

Zoho Creatorは、業務アプリを画面操作中心に組み立てつつ、足りない処理をDelugeというスクリプトで補うローコード開発基盤です。導入を検討する開発者が最初に知りたいのは「どこまでノーコードで済み、どこからコードを書くのか」「プランの上限が設計をどう縛るのか」という2点でしょう。この記事では製品紹介ではなく、データモデル・スクリプト・連携・上限という実装の四つの軸から、採用の可否を判断できるところまで解説します。

まとめ：Zoho Creatorを採る条件と見送るべき条件

先に結論を書きます。Zoho Creatorが向くのは、次の三つが同時に成り立つ場合です。第一に、Zoho CRMやZoho Booksなど他のZoho製品をすでに使っており、そのデータと業務アプリを同じ基盤の中でつなぎたいこと。第二に、業務部門の申請・台帳・進捗管理といった中小規模のアプリを、数本から数十本の単位で継続的に作りたいこと。第三に、必要な処理がフォーム保存時やスケジュール実行といったイベント駆動で表現でき、Delugeで書ける範囲に収まること。

逆に見送るべき場面もはっきりしています。ユーザーあたりのレコード数上限を大きく超える大量データを1アプリで抱える設計、ピクセル単位で作り込む独自UIや複雑な画面遷移、毎秒単位で外部システムを叩き続ける高頻度連携。これらはプラン上限とプラットフォームの制約に正面からぶつかるため、スクラッチ開発やデータ基盤側での処理に寄せたほうが総コストは下がります。ツールを横断して選定軸から比べたい場合はローコードツールとは？用途別の比較と選定基準・スクラッチ開発との使い分けを解説を先に読むと判断が早くなります。

Zoho Creatorとは何か：ローコード開発基盤としての位置づけ

Zoho Creatorは、フォーム（データを入力する画面兼テーブル）、レポート（一覧やカレンダーなどの表示形式）、ページ（ダッシュボード）という三つの部品を組み合わせて業務アプリを構成するプラットフォームです。ドラッグ操作でフィールドを並べれば、データベースのテーブル定義と入力画面、そして一覧画面が同時に生成されます。ここまではコードを書きません。

コードが登場するのはDelugeです。公式ドキュメントでは「Data Enriched Language for the Universal Grid Environment」の略で、Zohoの各サービスに組み込まれたオンラインのスクリプト言語だと説明されています。依存関係の解決やコネクションの管理はプラットフォーム側が済ませてあり、実現したい処理そのものだけを書けばよい設計です。Delugeに対応するZoho製品は40を超えるとされ、Creatorで覚えた記法はCRMやDeskでもほぼそのまま通用します。

この構造が意味するのは、Zoho Creatorが「単体のアプリビルダー」ではなく「Zoho群の業務データに手を入れられる実装レイヤー」だという点です。Zohoを使っていない組織にとっては数あるローコードの一つにすぎませんが、すでにZohoが基幹に入っている組織では、標準機能で足りない業務をCreatorで埋めるという使い分けが成立します。ノーコードとローコードの線引きそのものを整理したい方はノーコードとは？ローコードとの違い・できること・限界を実務目線で解説も合わせてご覧ください。

kintoneやPower Appsと比べたときの得意領域の違いを押さえる

同じ業務アプリ基盤でも、強みの出どころは異なるものです。kintoneはアプリ間のレコード連携と国内向けの運用エコシステムが厚く、JavaScriptによるカスタマイズで画面を作り込む方向に伸びます。Power AppsはMicrosoft 365やDataverseとの結合が前提で、Power Automateを含めた業務フロー全体をMicrosoft側で完結させたいときに効きます。Zoho CreatorはZoho製品群の業務データへ直接触れられる点と、Delugeという共通言語でサーバー側処理を書ける点が持ち味です。

したがって選定は「機能表の優劣」ではなく「どのSaaS群に業務の中心があるか」で決まります。kintone側の判断材料はkintone開発とは？カスタマイズ手段・費用相場・内製と外注の判断まで解説に整理しました。

データモデル設計の要点：フォーム・サブフォーム・参照関係の組み立て

Zoho Creatorの設計ではフォーム定義が出発点です。フォームは画面であると同時にテーブルであり、フィールドの型がそのまま列の型になります。単一行テキスト、複数行テキスト、数値、通貨、日付、選択リスト、ファイルアップロードといった標準型に加え、他フォームのレコードを指す参照（Lookup）フィールドと、明細行を持たせるサブフォームが実装上の要になります。

参照フィールドは、受注フォームから取引先フォームを指すような1対多の関係を表現します。参照先のレコードは独立して存在し、複数のフォームから共有が可能です。一方サブフォームは、受注ヘッダーの中に受注明細を何行でも持たせるような親子構造で、親レコードに従属します。この違いを設計時に取り違えると、後からレポートが組めなくなったり、集計スクリプトが煩雑になったりします。

サブフォームと参照フィールドの使い分けと設計時に効く判断の基準

判断は次の問いで切り分けます。その明細行は、親レコードと切り離して検索・集計する必要があるか。必要ならサブフォームではなく独立フォーム＋参照フィールドにします。サブフォームの行は親に紐づく形で保持されるため、行単位で横断的に絞り込む要件が後から出てくると設計変更が重くなるからです。逆に、行が親と一蓮托生で、削除も親と同時でよいならサブフォームが素直に収まります。

もう一点、レコード数の上限がユーザー単位で決まる仕様も設計に効きます。ログデータや測定値のような行数が伸び続けるデータをそのままフォームに貯めると、早い段階で天井に当たります。履歴系は外部データベースに逃がし、Creator側には集計済みの要約だけを持たせる。この分担を最初に決めておくと、後からの移行コストを避けられます。

Delugeスクリプトはどこで動くか：実行タイミングと記述の型

Delugeはどこにでも書けるわけではなく、決められた実行地点に紐づけて書きます。フォームのワークフローでは、レコード追加時、編集時、追加または編集時、削除時といったタイミングを指定できます。入力途中の挙動を制御したいときはフィールドのon user input、保存前の検証ではon validateが配置先です。時刻起動が必要ならスケジュール、レポートの一覧から手動で走らせたいならカスタムアクションを使います。共通処理は関数として切り出し、各所から呼び出す構成が保守しやすくなります。

記述の型はおおむね三つに集約されます。一つ目はレコード操作で、フォームのレコードを作成・更新・削除する組み込みタスク。二つ目は他のZoho製品を呼ぶタスクで、CRMのレコードを読み書きする処理などが該当します。三つ目が外部API呼び出しのinvokeurlで、認証情報はコネクションとして分離して渡します。

// 受注フォームの保存後に Zoho CRM の取引先へ備考を書き戻す
resp = zoho.crm.updateRecord(
  "Accounts",
  input.crm_account_id,
  { "Description" : input.remarks }
);
info resp;

外部システムへ投げる場合は次の形になります。URLや認証をスクリプト中に直書きせず、コネクション名で参照するのがプラットフォーム側の作法です。

response = invokeurl
[
  url        : "https://api.example.co.jp/v1/orders"
  type       : POST
  parameters : { "order_id" : input.ID, "amount" : input.total } .toString()
  connection : "kikan_system"
];
info response;

実装上の注意は二つあります。まずDelugeはサーバー側で同期実行されるため、外部APIの応答が遅いとフォーム保存そのものが待たされます。重い連携はスケジュールや非同期の関数に逃がしてください。次にエラー処理で、外部呼び出しの戻り値は必ず受け取り、想定外のステータスなら通知や再試行のフラグを立てる設計にしておくと、原因不明のデータ欠落を防げます。

他のZoho製品と外部システムを連携させる実装手段の選び分け

連携の手段は目的ごとに分かれており、どれを選ぶかで運用負荷が変わります。Zoho製品間であれば、Deluge組み込みのタスクで直接読み書きするのが最短です。コードを書かずに条件分岐と処理をつなぎたい場合は、Zoho Flowのような連携サービスを挟む選択肢もあります。

外部システムに対しては三つの入口があります。CreatorからAPIを叩きに行くinvokeurl、外部で定義した接続情報をまとめて管理するコネクションとカスタムコネクター、そして外部からCreatorのデータを操作するREST APIです。データソースやカスタムコネクターの登録数はプランで上限が決まっているため、連携先が増える見込みなら早い段階で数を見積もっておきます。

Creator側のAPIは現行がv2.1で、認証はOAuth 2.0によるアクセス委譲です。レコードの追加・取得・更新・削除を扱うData API、公開コンポーネント向けのPublish API、ファイルの送受信を担うFile API、メタ情報を返すMeta API、そして大量データを扱うBulk APIという構成になっています。数万件規模の初期移行や夜間の一括同期では、通常のData APIを繰り返すのではなくBulk APIを前提に組んだほうが、後述する呼び出し上限に引っかかりにくくなります。

APIの上限とプラン別の制限から逆算する実装設計と回避策の検討

ここが実装設計を最も強く縛る部分です。公式の比較表では、プランごとに次のような上限が示されています（2026年7月31日時点の記載）。

この表から読み取るべき設計上の含意は三つあります。第一に、アプリ数が1に制限されるスタンダードでは複数業務を1アプリに同居させることになり、権限設計が窮屈になります。業務ごとにアプリを分けたいならプロフェッショナル以上が前提です。第二に、レコード数とストレージがユーザー単位の積算である以上、少人数で大量データを扱う構成は不利に働きます。ユーザー10名でレコード数百万件という形は成り立ちません。

第三に、Deluge実行文とAPI呼び出しの上限は日次で効くため、1件の保存につき何回スクリプトが走り何本のAPIを叩くかを、設計段階で概算しておく必要があります。1レコード保存あたり外部APIを3本呼ぶ実装で、1日500件の登録があれば1,500回。スタンダードのユーザー単価換算では容易に届く水準です。

回避策は三つに整理できます。ひとつは呼び出しのまとめ方を変えること。レコード単位で都度叩くのをやめ、スケジュール実行で差分をまとめて送る方式に変えれば呼び出し回数は桁で減ります。ふたつめはデータの置き場所を分けること。参照専用の大量データは外部データベースに置き、Creatorからはデータソース経由で読むだけにします。みっつめは処理の重心を外に出すこと。複雑な計算やバッチはクラウド関数や自社の連携基盤に持たせ、Creatorは入力と表示に徹する構成です。

料金プランと環境分離の考え方：開発から本番運用に移すまでの流れ

プランはスタンダード、プロフェッショナル、エンタープライズ、そして機能を選んで見積もるフレックスという構成で、いずれもユーザー課金です。無料トライアルは15日間で、クレジットカードの登録は不要と案内されています。金額はUS向けの比較表でスタンダードがUS$8、プロフェッショナルがUS$20、エンタープライズがUS$25（いずれもユーザーあたり月額・年間払い・2026年7月31日時点の表記）と示されていますが、日本円での請求条件は為替や販売経路で変わるため、必ず公式の料金ページで確認してください。

実装の観点で見落とされがちなのが環境分離です。本番アプリを直接編集すると、テスト中の変更が業務中のユーザーに露出します。開発用の環境で変更を積み、検証を通してから本番へ反映する流れを作れるかどうかは、運用フェーズの安全性を左右する要因です。あわせて、リリース時に既存レコードへどう移行を当てるか、フィールド追加のたびに既存データの初期値をどう埋めるかも、最初のリリース前に手順化しておくと後が楽になります。

権限設計も同時に決めます。ロールとプロフィール、フィールド単位の権限、そして社外向けに絞った画面を出すポータル。ポータルの権限セット数もプランで上限が決まるため、取引先に入力してもらう運用を予定しているなら、必要なパターン数を先に数えておきます。

内製と外注の分岐点：Zoho Creator案件で外部に頼む条件

Zoho Creatorは業務部門でも触れる基盤ですが、すべてを内製で回すのが得というわけでもありません。内製で完結しやすいのは、単一部門の台帳・申請・進捗管理で、外部連携がないか、あってもZoho製品の中で閉じるケースです。フォーム設計とレポート定義が中心で、Delugeも保存後の通知や簡単な計算にとどまるなら、社内の担当者が学びながら組める範囲に収まります。

外部の手を借りたほうがよいのは次の三つです。ひとつは基幹システムや外部SaaSとの双方向連携があり、認証やエラー時の再送、重複防止まで設計する必要がある場合。ふたつめは既存の業務データを数万件規模で移行する場合で、データモデルの決め方と移行スクリプトが品質を左右します。みっつめは全社導入で、権限・環境分離・監査の観点を最初から織り込む必要がある場合です。いずれも、後から作り直すと業務を止めることになり、初期の設計判断が費用対効果を決めます。

一創では、Zoho製品群の導入と業務アプリの実装をあわせて支援しています。Zoho Creatorでどこまで内製し、どこを外部に任せるかの線引きから相談したい場合はZoho導入支援サービスをご確認ください。既存のZoho CRMとの連携方針を含めて、実装前の設計段階からご一緒できます。

よくある質問

Zoho Creatorは無料のまま業務で使い続けられますか？

無料プランはアプリ1本、レコード5,000件、ストレージ250MBという範囲で提供されています（2026年7月31日時点）。小さな台帳を試す用途なら成り立ちますが、業務データが増える前提の運用では早い段階で上限に届きます。試用目的では15日間の無料トライアルで有償プランの機能を確かめる進め方が現実的です。

Delugeはプログラミング未経験でも書けるようになりますか？

公式ドキュメントではDelugeを、学習しやすく多くのプログラミング知識を必要としないスクリプト言語と位置づけています。変数と条件分岐、繰り返しといった基礎が分かれば、通知や自動計算のような処理は業務担当者でも書けます。ただし外部API連携やエラー処理、大量データの扱いになると設計の勘所が要るため、そこから先は開発経験者の関与を前提にしたほうが安全です。

Zoho CRMのデータをZoho Creatorから直接読み書きできますか？

できます。Delugeにはzoho.crmで始まる組み込みタスクがあり、レコードの取得や更新をスクリプトから直接実行できます。CRM側を正としてCreatorで業務処理を組む構成も、その逆も可能です。どちらをマスタにするかを先に決め、更新の向きを一方向に固定しておくと、二重更新による不整合を避けられます。

レコード数の上限を超えそうな場合はどう対処しますか？

三つの手が考えられます。上位プランへ移行してユーザーあたりの枠を増やす、古いデータを外部データベースやストレージへ退避して参照時だけ読みに行く、あるいは明細レベルのデータを外部に持たせCreatorには集計値だけを残す構成に変える方法です。上限に近づいてから慌てるとデータ移行が重くなるため、想定件数が枠の7割に達した時点で方針を決めておくことをおすすめします。

既存のkintoneアプリをZoho Creatorへ移行できますか？

データそのものはCSVやAPI経由で移せますが、画面やカスタマイズはそのままでは移りません。kintoneのJavaScriptカスタマイズはDelugeへの書き換えが必要で、プラグインに依存した機能は代替手段を設計し直すことになります。移行の実質的な作業量はレコード件数ではなくカスタマイズの量で決まるため、まず現行アプリのカスタマイズ棚卸しから着手してください。

関連記事

• ローコードツールとは？用途別の比較と選定基準・スクラッチ開発との使い分けを解説
• ノーコードとは？ローコードとの違い・できること・限界を実務目線で解説
• kintone開発とは？カスタマイズ手段・費用相場・内製と外注の判断まで解説