Retoolのシステム開発の完全ガイド - ブログ

Retoolのシステムとは、既存のデータベースやAPIと業務処理をつなぎ、社内向けの画面・承認・自動化を短期間で構築するローコード型の業務アプリケーション基盤です。

「Retoolでどこまで作れるのか」「通常のシステム開発より安くなるのか」「本番運用の安全性に問題はないのか」と迷っている方に向けて、Retoolの位置づけ、作れるシステムの種類、開発手順、費用相場、CloudとSelf-hostの違い、開発会社・ベンダーの選び方、セキュリティまでをまとめます。最初に結論を言えば、Retoolは既存データを業務で使いやすくする画面とワークフローに強く、会計や決済などの正本データや複雑な中核ロジックまで単独で担わせる製品ではありません。

Retoolのシステムとは何ですか？

Retoolは、データを保管する基幹システムそのものというより、複数のデータソースと現場の業務をつなぐ「業務アプリケーション層」です。画面部品、データ取得、更新処理、権限、承認、通知、定期実行などを組み合わせ、業務担当者が使うWebアプリやモバイルアプリを作れます。

既存システムと現場業務の間に置くアプリ層です

たとえば販売管理、顧客管理、在庫管理、データウェアハウスなどに分散した情報を、担当者が一つの画面で検索・確認・更新できるようにします。Retoolがデータソースをすべて置き換えるのではなく、既存のデータベース、RESTやGraphQLのAPI、SaaS、スプレッドシートなどへ接続して、業務に必要な操作画面を構成する考え方です。

この位置づけを理解すると、「Retoolを導入すれば基幹システムが完成する」という誤解を避けられます。正本となるデータをどこに置くか、どの処理をAPIやバックエンドで実行するか、Retoolにはどの操作を担当させるかを分けることが、長期運用の出発点になります。

画面・データ操作・自動化を一つの開発基盤で扱えます

画面側ではテーブル、フォーム、チャート、モーダル、タブなどを配置し、SQLやJavaScriptを使って検索・登録・更新処理を組み立てます。Workflowsでは、定期実行、Webhook、通知、承認、ETLのようなバックグラウンド処理を扱えます。さらにAIによるアプリ生成、Agents、モバイルアプリ、外部ユーザー向けのPortals、Retool Databaseなども用意されています。

ただし、ローコードであることは「技術知識が不要」という意味ではありません。SQLの安全な書き方、APIの認証、エラー時の再実行、データの整合性、権限の継承、変更履歴を設計する必要があります。画面を速く作れることに加えて、共通部品やルールを再利用しやすいことがRetoolの価値です。

Retoolで作れるシステムの種類

Retoolが得意なのは、データを見ながら判断し、複数の操作を行い、担当者や上長の承認を経て次の処理へ進める業務です。利用者が社内に限られるほど、既存システムと接続した管理画面や業務ツールとして効果を出しやすくなります。

管理画面・検索更新画面

顧客情報、注文、契約、在庫、申請、問い合わせなどを検索し、詳細を確認して更新する管理画面を作れます。複数のテーブルを一つの画面にまとめ、検索条件、ステータス変更、CSV入出力、コメント、ファイル確認などを組み合わせれば、メールや表計算ファイルを行き来する作業を減らせます。

申請・承認・通知のワークフロー

経費、仕入れ、値引き、アカウント発行、審査、不正調査など、申請内容を確認して承認・差し戻しする業務にも向いています。申請の登録、担当者の割り当て、条件に応じた承認ルート、メールやチャットへの通知、完了後の記録までを一連の処理として設計できます。

ワークフローは便利ですが、例外処理を後回しにすると本番で止まりやすくなります。申請者と承認者が同じ場合、期限を過ぎた場合、連携先が応答しない場合、二重送信が起きた場合などを、通常経路と同じ粒度で定義しておくことが重要です。

ダッシュボード・モバイルアプリ・外部ポータル

KPI、売上、在庫、稼働状況、サポート件数などを可視化するダッシュボードも代表的な用途です。部門別の権限に応じて見せるデータを変えたり、グラフから明細画面へ遷移したりできるため、見るだけでなく判断とアクションにつなげられます。現場入力が多い場合は、モバイルアプリを使って外出先や作業場所から登録する構成も検討できます。

社外の顧客や取引先に使わせる場合は、Internal user向けの社内アプリとは要件が変わります。ログイン、テナント分離、外部ユーザーの料金、ブランド表示、公開範囲、個人情報の扱いを先に確認してください。一般消費者向けの大規模サービスや高度な画面体験が中心なら、専用フロントエンドとAPIを用意し、Retoolは運用画面に限定する方が適切な場合もあります。

Retoolのシステム開発の進め方

Retoolは画面を早く作れるため、いきなり部品を配置して開発を始めたくなります。しかし、業務の目的や正本データを決めないまま進めると、見た目は完成しても権限や例外処理が不足します。企画、PoC、設計、本開発、テスト、運用の順に、Retoolで担当する範囲を明確にして進めます。

▶ 詳細はこちら：Retoolのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 業務課題と成功指標を整理します

最初に、誰が、どのデータを使い、どの判断を行い、どこへ記録するのかを整理します。現在の画面、表計算ファイル、メール、手作業の転記を並べ、時間がかかる箇所とミスが起きる箇所を特定します。「画面を作る」ではなく、「処理時間を何分短くする」「入力ミスを何件減らす」「問い合わせを何割減らす」のように成功指標を置くことが大切です。

同時に、業務の正本データを決めます。既存のデータベースや業務SaaSを正本にするのか、Retool Databaseを使うのかを決め、Retool側に一時的な表示データだけを持たせるのか、更新も許可するのかを定義します。この整理がないと、複数画面から同じ情報を更新した際に不整合が起こりやすくなります。

2. 主要業務を一つ選んでPoCを行います

最初から全社の業務を載せず、効果が測りやすく、データ連携が限定され、利用者の協力を得やすい業務を一つ選びます。たとえば問い合わせ対応、審査受付、在庫確認、マスタ更新などです。PoCでは画面の見た目だけでなく、実データに近い条件で、権限、承認、エラー、同時利用、処理速度を確かめます。

Retool公式の顧客事例では、製造業の業務アプリが生産計画の処理時間を2日から4時間へ92%短縮し、納期どおりに届けられる割合を15%改善したと紹介されています。また、別の事例では50以上のカスタムアプリを日常利用し、週に数百時間の手作業を自動化したとされています。いずれもRetool社が公表する導入企業の事例であり、自社でも同じ結果が出ると保証する数字ではありません（出典: Retool公式顧客事例、2026年8月確認）。

3. 設計・開発・テスト・リリースを分けます

本開発では、画面設計と同時にデータソース、API、権限グループ、Secrets、エラー表示、ログ、監視方針を決めます。開発・ステージング・本番の環境を分け、リリース単位とロールバック方法を定義してから本番へ進めます。Enterpriseではソース管理やエラー監視などを使えるため、組織の変更管理に合わせてプランを選びます。

テストは正常系だけでなく、権限のない利用者が見られないこと、同じ申請が二重登録されないこと、連携先の停止時に利用者へ適切な案内が出ること、タイムゾーンや文字コードが崩れないことを確認します。リリース後は、利用率、処理時間、エラー件数、問い合わせ件数を測り、改善の優先順位を定期的に見直します。

Retoolのシステム開発にかかる費用相場

Retoolの費用は、プラットフォームのライセンス費用と、要件定義・連携・権限設計・テストなどの開発費用を分けて考えます。Retoolで画面実装の工数が減っても、データ品質の確認や業務設計、セキュリティ、教育、保守の費用までゼロにはなりません。

▶ 詳細はこちら：Retoolのシステム開発の見積相場や費用/コスト/値段について

ライセンス費用はBuilderとInternal userで変わります

Retool公式料金ページでは、Freeは無料、TeamはBuilderが月10ドル、Internal userが月5ドル、BusinessはBuilderが月50ドル、Internal userが月15ドルと表示されています。Enterpriseは個別見積もりです。Builderはアプリやワークフローを作成・編集する利用者、Internal userは主に完成したアプリを使う利用者です。年払い・月払い、Cloud・Self-host、契約時期によって条件が変わるため、発注前に最新の見積もりを確認してください（出典: Retool公式Pricing、2026年8月確認）。

たとえばBuilderが2人、Internal userが20人の場合、単純計算ではTeamが月120ドル、Businessが月400ドルです。1ドル150円で換算すると月約1万8,000円と約6万円、年約21万6,000円と約72万円になります。ただし、AI credits、Agents、外部ユーザー、追加容量、サポート、為替、税金などは別に確認が必要です。この金額は開発会社へ支払う初期開発費ではなく、利用人数に応じたプラットフォーム料金です。

初期開発費は50万円から3,000万円以上まで幅があります

Retool固有の案件価格を一律に示せる公開統計はありません。以下は一般的な業務システム開発の工数と、Retoolで共通UIの実装量を抑えられる点を踏まえた見積もりの目安です。実際の金額は、画面数よりもデータソース数、APIの状態、権限の細かさ、例外処理、移行、テスト、利用者数、運用要件で大きく変わります。

PoCや1〜数画面の小さな社内ツールは、50万〜150万円程度、期間は2〜6週間が一つの目安です。検索・登録・承認・CSV・基本権限を含む小規模業務アプリは150万〜400万円程度、1〜3か月程度が想定されます。複数のデータベースやAPI、データ移行、ロール別権限、監査、利用者教育を含む部門統合システムは400万〜1,000万円程度、3〜6か月程度が目安です。

SSO、Self-host、複数環境、厳格な監査、冗長化、複雑な外部連携を含む全社統制型では、1,000万〜3,000万円以上、6〜12か月かかる場合があります。これはRetoolのライセンス価格ではなく、要件整理から本番運用までの導入プロジェクト費用です。小さく始める場合も、将来の権限やデータモデルに影響する設計だけは初期段階で確認してください。

保守・運用費と将来の料金変動も含めます

運用開始後は、ライセンスに加えて、データベースやAPIなどの基盤費、監視、バックアップ、問い合わせ対応、権限変更、小改修、障害対応が発生します。一般的な業務システムでは、初期開発費の年15〜25%を保守費の目安とする考え方がありますが、Retoolで内製できる範囲が広いほど費用が下がる一方、専門担当者が不在だと外部支援費が必要になります。

AI creditsはアカウント単位で毎月更新され、繰り越されない仕組みです。追加パックやAgentsの課金、ユーザー数の増加、外部ユーザー料金、料金改定、為替を含めて、1年分と3年分の総保有コストを試算します。初期費用だけでなく、利用量が増えたときの単価と契約変更条件まで確認すると、予算のブレを抑えられます。

RetoolのCloudとSelf-hostはどちらが向いていますか？

短期間で検証し、インフラ運用を軽くしたい場合はCloudが候補になります。一方、社内ネットワークや自社の仮想プライベート環境で運用したい場合、データの境界やアップグレード時期を自社で管理したい場合はSelf-hostを検討します。どちらが優れているかではなく、セキュリティ規程と運用責任の分担で決める選択です。

Cloudは導入速度と運用負荷のバランスを取りやすい選択です

Cloudでは、Retool側が提供する環境を利用してアプリを構築します。インフラの初期構築や製品アップデートを自社で抱えにくいため、PoCや部門単位の業務改善を早く始めたい場合に向いています。公式Trust Guideでは、Cloudは複数利用者向けのクラウド構成で運用され、接続先データへのクエリはRetoolのバックエンドを経由すると説明されています。

ただし、Cloudでもデータの保存範囲を確認する必要があります。外部データソースのデータ本体を保存しない接続方式でも、暗号化された認証情報、ユーザーメタデータ、アプリ構造は保持されます。クエリやワークフローのキャッシュを有効にすればデータが一時保存されるため、キャッシュ期間、削除方法、障害時の挙動を設計書に残します（出典: Retool公式Trust Guide、2026年8月確認）。

Self-hostは責任分界と運用体制を用意できる場合に向きます

Self-hostでは、自社の仮想プライベート環境などにRetoolのサービスを配置できます。社内ネットワーク内のデータへ接続しやすく、インフラ境界やアップグレード計画を自社規程に合わせやすい一方、可用性、バックアップ、監視、脆弱性対応、障害復旧、バージョン更新を自社側で担う範囲が増えます。

Self-hostを選ぶ前に、誰が夜間障害を受けるのか、復旧目標時間と復旧時点をどう置くのか、Retoolのバージョンをどう検証するのかを決めます。2026年7月末時点でもSelf-host向けの複数の安定版が公開されているため、更新のたびに互換性テストを行える体制が必要です（出典: Retool Docs、2026年8月確認）。

Retoolの開発会社・ベンダーの選び方

Retoolの開発会社を選ぶときは、単に画面を作れるかではなく、本番稼働後のデータ連携、権限、監査、障害対応まで任せられるかを確認します。Retoolの公式パートナー表示は一つの参考になりますが、認定や掲載実績だけで業務理解やプロジェクト成功が保証されるわけではありません。

本番運用と似た業務の実績を確認します

実績を見る際は、アプリの画面数より、利用者数、データソースの種類、更新処理の有無、権限の細かさ、SLAや監査要件を確認します。可能であれば、本番稼働中の画面を匿名化したデモで見せてもらい、エラー時の表示、承認の差し戻し、検索速度、操作ログの確認方法まで質問します。

「Retoolで作ったことがある」という説明だけでは不十分です。要件定義、データモデル、API設計、テスト計画、利用者教育、リリース後の保守を誰が担当したのかを分けて聞きます。海外チームの場合は、日本語の打ち合わせ、時差、契約主体、再委託先、障害連絡の窓口も比較対象になります。

同じRFPで見積もりと成果物を比較します

相見積もりでは、画面数だけでなく、要件定義、接続先一覧、権限マトリクス、データ移行、テスト、教育、ドキュメント、保守を同じ依頼書に含めます。見積書はライセンス、初期開発、外部サービス、クラウド基盤、年間保守を分けてもらい、何が含まれないかも明記してもらいます。

納品物はアプリだけではありません。アプリ定義、環境設定、接続情報の管理方法、権限一覧、API仕様、テスト結果、障害時の手順、運用マニュアル、引き継ぎ教育の範囲を確認します。契約終了時に自社で継続運用できるか、設定やドキュメントを受け取れるかも、初回の見積もり段階で確認してください。

Retoolのシステム開発会社を詳しく比較する方法

▶ 詳細はこちら：Retoolのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Retoolのシステム開発の発注/外注/依頼/委託方法について

Retoolのセキュリティと運用で確認すべきこと

業務システムでは、作れることより安全に使い続けられることが重要です。Retool側の機能を確認するだけでなく、利用企業が権限、個人情報、委託先、ログ、バックアップ、教育、退職者のアカウント停止を運用ルールに落とし込みます。

ユーザー・グループ・データ単位の権限を設計します

権限は「ログインできるか」だけでなく、どの画面を開けるか、どのデータを見られるか、登録・更新・削除のどこまで許可するかで設計します。営業、サポート、管理者、外部委託先など、役割ごとにグループを作り、行・列・データソース単位の制御が必要かを整理します。

Business以上では監査ログや詳細な権限管理が料金ページに示され、EnterpriseではSAMLやOIDCによるSSO、ソース管理、エラー監視などが追加されます。必要な機能がどのプラン、契約、Cloud・Self-host条件で使えるかは、画面を作る前に確認してください。

個人情報と委託先の安全管理を確認します

個人情報を扱う場合は、データの種類、利用目的、保存場所、アクセスできる人、委託先と再委託先、契約終了後の削除方法を整理します。個人情報保護委員会のガイドラインでも、委託先に必要かつ適切な安全管理措置を講じさせ、委託先の取扱状況を把握する考え方が示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

Retool公式Trust Guideには、通信中・保存時の暗号化、アクセス監視、二要素認証、SAML・OIDC SSO、データ処理契約などの説明があります。ただし、製品側の対策だけで利用企業の責任がなくなるわけではありません。自社の規程、契約、アクセスレビュー、インシデント時の連絡体制まで含めて評価します。

障害・変更・退職者対応を運用手順にします

本番運用では、APIが停止したときの再試行、データが不整合になったときの訂正、アプリを変更するときのレビュー、権限申請の承認、退職者のアカウント停止を決めます。監査ログを誰が週次・月次で確認するのか、保存期間を何年にするのか、利用者からの問い合わせをどこで受けるのかも明文化します。

AIで画面や処理を生成する場合は、生成結果をそのまま本番へ出さず、SQL、権限条件、個人情報の参照範囲、プロンプトやログの取り扱いを人が確認します。生成速度が上がっても、レビュー、テスト、承認、変更履歴を省略しないことが、継続運用の前提です。

よくある質問（FAQ）

Retoolのシステム開発を検討する際に、特に質問が多いポイントをまとめます。費用や技術の話だけでなく、誰が使うのか、どこにデータを置くのか、導入後に誰が直すのかまで確認すると判断しやすくなります。

Retoolはノーコードですか？SQLを書けない人でも使えますか？

Retoolは、部品配置だけで作れる部分と、SQLやJavaScriptなどを使って拡張する部分を併せ持つローコード型の開発基盤です。SQLを書けない人でも既存の部品や設定を使える場合はありますが、複雑な検索・更新・権限・エラー処理を安定運用するには、データベースやAPIを理解する担当者が必要です。

Retoolはスクラッチ開発より安いですか？

画面部品や共通機能の実装量を減らし、利用者の声を受けながら短い周期で改善できるため、一定の業務では開発期間と初期費用を抑えられる可能性があります。ただし、ライセンス、連携、データ移行、権限、監査、教育、保守の費用は残ります。画面数ではなく、3年間のライセンスと開発・運用を合わせた総額で比較してください。

会計や基幹システムもRetoolだけで作れますか？

複雑な会計、給与、決済、在庫評価、厳格な台帳管理などをRetoolだけで完結させることは慎重に検討してください。正本データと中核ロジックは既存パッケージや専用バックエンドに置き、Retoolは検索、入力、承認、現場向けの操作画面に使うハイブリッド構成が現実的です。

Retoolのシステム開発は内製と外注のどちらがよいですか？

既存のデータ構造と業務を理解する担当者がいて、対象業務が小さく、SQLやAPIを扱えるなら、PoCを内製して適性を確かめる方法があります。一方、複数システム連携、権限、個人情報、Self-host、本番運用まで必要なら、要件定義から支援できる開発会社・ベンダーへ相談し、内製担当者と役割分担する方が安全です。

Retoolは日本語で使えますか？

画面やドキュメントの表示、開発チームとのコミュニケーション、日本語での保守窓口は分けて確認してください。日本語で業務を定義できても、製品仕様やエラーの調査、API連携の技術資料が英語中心になる場合があります。担当者の読み書き、翻訳体制、障害時の連絡方法を契約前に決めておくと安心です。

まとめ

Retoolは、データベースやAPIにつながる業務アプリ、管理画面、承認、通知、ダッシュボード、ワークフローを短期間で作り、現場の改善サイクルを速めるための基盤です。画面作成の速さだけで判断せず、正本データ、権限、監査、エラー処理、CloudとSelf-hostの責任分界、ライセンスと開発費を含めた総額を確認してください。

Retoolに向く業務から小さく始めます

導入を迷ったら、問い合わせ対応、審査、在庫確認、マスタ更新など、効果を測りやすい一つの業務を選び、2〜6週間程度のPoCで検証します。成功条件を処理時間やミス率で置き、実データに近い権限・例外・連携を確認したうえで、部門展開や全社統制へ進みます。

標準業務は既存サービス、現場操作はRetool、独自の中核はバックエンドに分けます

最も再現性が高いのは、標準業務を既存のSaaSやパッケージに任せ、現場の検索・入力・承認をRetoolで整え、競争優位となる複雑なロジックや台帳を専用バックエンドに残す分担です。この境界を最初に決めれば、Retoolの速さを活かしながら、将来の拡張や担当者交代にも耐えやすいシステムになります。