Retoolのシステム開発の完全ガイド

Retoolは、既存データとの接続、業務画面、承認や自動化を組み合わせて、現場向けのアプリを作るための基盤です。

システム開発では、作れる用途や進め方、費用を押さえたうえで、運用環境と開発会社の選び方を確認します。各テーマの詳細は、関連記事もあわせてご覧ください。

▼関連記事一覧
・Retoolのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Retoolのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Retoolのシステム開発の見積相場や費用/コスト/値段について
・Retoolのシステム開発の発注/外注/依頼/委託方法について

Retoolのシステムの概要

Retoolは、複数のデータソースと現場業務をつなぐ業務アプリケーション層です。正本データをすべて保管する基幹システムとは、役割が異なります。

開発では、画面部品とデータ取得、更新処理を組み合わせます。権限や承認、通知、定期実行も、同じ部品の組み合わせで作ります。そのため、業務担当者が使うWebアプリやモバイルアプリを構築できます。

既存システムと現場業務の間にあるアプリ層

Retoolで現場の操作画面を作る前に、対象となるデータと接続先を整理しておきます。

  • 扱う情報:販売管理、顧客管理、在庫管理などを一画面で検索・確認・更新
  • 接続先:既存データベース、REST・GraphQL API、SaaS、スプレッドシート

Retoolは既存データへ接続し、業務に必要な操作画面を組み立てる考え方です。データソースそのものを置き換えるわけではありません。

この位置づけを押さえると、Retoolを入れるだけで基幹システムが完成するという誤解を避けられます。

まず、正本データの保存先と、APIやバックエンドで実行する処理を分けて決めます。そのうえで、Retoolに担当させる操作を明確にすることが、長期運用の出発点になります。

画面・データ操作・自動化を一つの開発基盤で扱う仕組み

Retoolでは、画面の構築から業務処理の自動化まで、一つの基盤で扱えます。

  • 画面とデータ操作:テーブルやフォーム、チャート、モーダル、タブの配置と、SQL・JavaScriptによる検索・登録・更新
  • バックグラウンド処理:Workflowsによる定期実行、Webhook、通知、承認、ETL
  • 追加機能:AI生成、Agents、モバイルアプリ、Portals、Retool Database

ただし、ローコードは「技術知識が不要」という意味ではありません。実際には、SQLの安全な記述やAPI認証、エラー時の再実行を設計します。データ整合性や権限継承、変更履歴も設計の対象になります。

共通部品やルールを再利用しやすいのも、Retoolの特徴です。

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

Retoolの用途を管理画面、申請承認ワークフロー、ダッシュボードなどの3種類に分けた図解。
利用者と業務に合わせて用途を選び分けます。

Retoolは、データを見て判断し、複数の操作や承認を経て次の処理へ進む業務に向いています。社内の利用者が中心であるほど、既存システムとつないだ管理画面や業務ツールとして効果を得やすくなります。

管理画面・検索更新画面

顧客情報や注文、契約などを検索し、内容を確認して更新する画面を作れます。在庫、申請、問い合わせも同じ形で扱えます。複数のテーブルを一つの画面にまとめられます。

検索条件やステータス変更、CSV入出力などを組み合わせます。コメントやファイル確認も、同じ画面に組み込めます。そのため、メールや表計算ファイルを行き来する作業を減らせます。

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

経費や仕入れ、値引きなどの申請に向いています。アカウント発行、審査、不正調査の申請にも使えます。申請内容を確認し、承認するか差し戻すかを分ける業務を組み立てられます。

申請の登録から担当者の割り当て、条件別の承認ルートまでを、一連の処理としてつなげられます。さらに、メールやチャットへの通知や、完了後の記録も加えられます。

例外処理を後回しにすると、本番運用で止まる原因になります。そこで、申請者と承認者が同じ場合や、期限超過、連携先の停止、二重送信などの例外も、通常の経路と同じ粒度で定義します。

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

利用者や業務に応じて、表示、現場入力、社外向けの機能を使い分けます。

  • ダッシュボード:KPIや売上、在庫、稼働状況、サポート件数などの表示
  • モバイルアプリ:現場入力が多い業務で、外出先からの登録
  • 外部ポータル:社外利用者向けの公開範囲と個人情報の管理

ダッシュボードでは、部門ごとに表示データを変えたり、グラフから明細へ移ったりできます。

社外の顧客や取引先に使わせる場合は、社内アプリとは要件が変わります。まず、ログインやテナント分離、外部ユーザー料金を先に確認します。ブランド表示や公開範囲、個人情報の扱いも、確認の対象です。

一般消費者向けの大規模サービスや、高度な画面体験が中心の場合は、専用フロントエンドとAPIを用意する方法があります。その場合は、Retoolを運用画面に限定するほうが適切なこともあります。

ポイント

業務データを見て判断し、複数の操作や承認を経て次の処理へ進む業務かどうかで、Retoolが向くかを判断します。利用者が社内中心なら、管理画面や業務ツールから検討するのが目安です。

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

画面を先に作ると、業務目的や正本データが曖昧なまま開発が進みがちです。その結果、権限や例外処理が不足することがあります。そこで、企画、PoC、設計、本開発、テスト、運用の順に、各段階でのRetoolの担当範囲を定めます。

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

1. 業務課題と成功指標の整理

まず、誰がどのデータを使い、どの判断をして、どこへ記録するかを整理します。現在の画面や表計算ファイル、メールを並べ、手作業の転記も書き出します。

時間がかかる箇所やミスが起きる箇所を特定します。「画面を作る」ことは指標にならず、処理時間を何分短縮するかといった業務の結果を置きます。

入力ミスを何件減らすか、問い合わせを何割減らすかも、業務に合わせた指標になります。

同時に、業務の正本データも決めます。既存データベースや業務SaaSを正本にするか、Retool Databaseを使うかを選びます。

Retool側には、表示用のデータだけを置くか、更新も許可するかを定めます。ここを決めないまま複数の画面から同じ情報を更新すると、不整合が起きやすくなります。

  • 業務の流れ:利用者、データ、判断、記録先の一覧
  • 成功指標:処理時間、入力ミス、問い合わせの改善目標
  • 正本データ:保存先と、Retool側での更新範囲

2. 主要業務を選んだPoC

問い合わせ対応や審査受付から、PoCの対象業務を選びます。在庫確認やマスタ更新も、候補になります。

  • 選定条件:効果を測りやすく、連携が限られ、利用者の協力を得やすい業務
  • 検証項目:実データに近い条件での権限、承認、エラー、同時利用、処理速度

導入の可否は、画面の見た目だけでなく、実際の動作を確かめて判断します。

Retool公式の製造業事例では、生産計画の処理時間が2日から4時間へ92%短縮され、納期どおりに届けられる割合も15%改善したと紹介されています。別の事例では、50以上のカスタムアプリを日常的に使い、週に数百時間の手作業を自動化したとされています。

いずれもRetool社が公表した事例なので、自社で同じ結果が出るとは限りません(出典: Retool公式顧客事例、2026年8月確認)。

3. 設計・開発・テスト・リリースの区分

本開発では、画面と合わせて、データソースやAPI、権限グループを決めます。Secretsやエラー表示も、このとき決めておきます。ログや監視方針も、本開発の中で扱います。

Enterpriseでは、ソース管理やエラー監視などを利用できます。組織の変更管理に合わせて、プランを選びます。

  • 環境とリリース:開発・ステージング・本番の分離、リリース単位、ロールバック方法
  • テスト:権限、二重登録、連携停止時の案内、タイムゾーン、文字コード
  • 運用改善:利用率や処理時間、エラー・問い合わせ件数の計測と、優先度の見直し

ポイント

画面より先に、業務目的と正本データを決められるかが、開発の進め方を左右します。PoCで実データに近い条件を試し、権限や例外処理まで確かめてから本開発に進む流れが目安です。

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

初期開発費の4区分と、それぞれの記事記載の費用レンジを並べた横棒図。
規模が上がるほど費用レンジも広がります。

Retoolの費用は、プラットフォームのライセンスと開発費用に分けて考えます。開発費の中身は、要件定義や連携、権限設計、テストなどです。

画面実装の工数が減っても、データ品質の確認や業務設計の費用は残ります。さらに、セキュリティや教育、保守の費用もかかります。

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

BuilderとInternal userで変わるライセンス費用

年払い・月払い、Cloud・Self-host、契約時期によって条件が変わります。発注前には、最新の見積もりを確認してください(出典: Retool公式Pricing、2026年8月確認)。

  • Free・Team:Freeは無料、TeamはBuilder月10ドル、Internal user月5ドル
  • Business・Enterprise:Builder月50ドル、Internal user月15ドル。Enterpriseは個別見積もり
  • 利用者の役割:Builderは作成と編集、Internal userは主に完成したアプリの利用

料金の試算例として、Builder 2人とInternal user 20人の構成を想定します。

この構成では、1ドル150円換算の月額がTeamで約1万8,000円、Businessで約6万円です。年額は、それぞれ約21万6,000円と約72万円になります。

AI credits、Agents、外部ユーザーの料金は、別途確認が必要です。さらに、追加容量やサポートに加えて、為替や税金も確認の対象になります。この料金は、開発会社へ支払う初期開発費ではなく、利用人数に応じたプラットフォーム料金です。

初期開発費の目安(50万円〜3,000万円以上)

Retool固有の案件価格を一律に示す公開統計はありません。そのため、一般的な業務システム開発の工数を踏まえた目安を示します。

共通UIの実装量は抑えられる一方、金額は画面数よりも、データソース数やAPIの状態、権限や例外処理によって変わります。将来の権限やデータモデルに影響する設計は、初期段階で確かめておきます。

  • PoC・小規模ツール:50万〜150万円程度
  • 小規模業務アプリ:150万〜400万円程度
  • 部門統合システム:400万〜1,000万円程度
  • 全社統制型:1,000万〜3,000万円以上

データ移行やテストも、金額を左右します。利用者数や運用要件も、金額に影響します。期間の目安として、PoCや1〜数画面の社内ツールは2〜6週間程度です。

検索や登録、承認に加えて、CSVと基本権限を含む小規模アプリは、1〜3か月程度です。複数のDBやAPI、移行、ロール別権限を含み、監査や教育まで扱う部門統合システムは、3〜6か月程度が目安です。

SSOやSelf-host、複数環境を含む全社統制型は、6〜12か月かかる場合があります。厳格な監査や冗長化、複雑な外部連携も、この区分に含まれます。ここでの金額は、ライセンスではなく、要件整理から本番運用までの導入費用を指します。

保守・運用費と将来の料金変動

導入後の支出は、保守作業や利用量に応じた料金まで含めて見積もります。

  • 基盤・保守:DBやAPIの維持費、監視、バックアップ、問い合わせ対応
  • 継続作業:権限変更、小改修、障害対応。内製範囲が広いと費用を抑えられる場合がある

一般的な業務システムでは、初期開発費の年15〜25%を保守費の目安とする考え方があります。

専門の担当者が社内にいない場合は、外部への支援費が必要になります。AI creditsは、アカウント単位で毎月更新され、繰り越されません。

追加パックやAgents、ユーザー数に加えて、外部ユーザー料金や料金改定、為替も含め、1年分と3年分の総保有コストを試算します。利用量が増えたときの単価と契約変更の条件も確認すると、予算のぶれを抑えられます。

ポイント

費用は、ライセンスと初期開発費、保守・運用費を分けて比べます。ライセンスは利用人数と役割で変わり、初期開発費は画面数よりもデータソースや権限、例外処理で動くと考えます。

RetoolのCloudとSelf-hostの選び方

短期間で検証し、インフラ運用の負担を軽くしたい場合は、Cloudが候補になります。一方で、社内ネットワークや自社の仮想プライベート環境で運用したい場合は、Self-hostを検討します。

また、データの境界やアップグレード時期を自社で管理したい場合も、Self-hostが候補になります。最終的な選択は、セキュリティ規程と運用責任の分担で決めます。

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

Cloudを選ぶ際は、導入の速さやインフラ運用の負担に加えて、接続構成も確認します。

  • 導入速度:インフラの初期構築や製品更新を自社で抱えにくいこと
  • 適した用途:Retool提供環境を使い、PoCや部門単位の業務改善を早く始めたい場合
  • 接続構成:複数利用者向けの形で、クエリはRetoolのバックエンドを経由する

接続先のデータだけでなく、外部データソースの保存範囲も確かめます。データ本体を保存しない接続方式でも、暗号化された認証情報やユーザーメタデータ、アプリ構造は保持されます。

クエリやワークフローのキャッシュを有効にすると、データが一時保存されます。そのため、キャッシュ期間や削除方法、障害時の挙動を、設計書に残しておきます(出典: Retool公式Trust Guide、2026年8月確認)。

運用責任の分担と運用体制を用意できる場合のSelf-host

Self-hostでは自社環境に配置できる一方、運用上の責任も自社側に広がります。

  • 自社管理:仮想プライベート環境などへの配置と、社内データへの接続しやすさ
  • 運用責任:可用性、バックアップ、監視、脆弱性対応、復旧、更新を自社で担うこと

インフラの境界やアップグレード計画を、自社の規程に合わせやすい方式です。

選ぶ前に、夜間障害の担当者や、復旧目標時間と復旧時点、バージョン検証の方法を決めておきます。

2026年7月末時点でも、複数の安定版が公開されています。このため、更新ごとに互換性テストを行える体制が必要です(出典: Retool Docs、2026年8月確認)。

ポイント

Cloudは導入の速さと運用負担の軽さ、Self-hostは自社での管理範囲と運用責任が決め手になります。セキュリティ規程で求められる管理範囲と、運用を担える体制があるかを照らして選びます。

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

開発会社は、画面を作れるかだけでなく、本番後のデータ連携や権限、監査、障害対応まで任せられるかを確かめます。

Retool公式パートナーの表示は、参考になります。ただし、認定や掲載実績だけでは、業務理解や成功が保証されません。

本番運用と似た業務の実績

開発会社の実績は、「Retoolで作ったことがある」というだけでは、十分な判断材料になりません。

  • 案件の近さ:利用者数、データソース、更新処理、権限、SLA、監査要件
  • 稼働画面:本番画面の匿名デモによる、エラー表示や承認差し戻し、検索速度、操作ログの確認
  • 担当範囲:要件定義、データ・API設計、テスト、教育、保守のそれぞれの担当者

海外チームに頼む場合は、日本語での打ち合わせや時差、契約主体を比べます。さらに、再委託先や障害連絡窓口も確かめます。

同じRFPでの見積もりと納品物の比較

各社の提案を比べるには、依頼内容、費用の内訳、納品物の条件をそろえます。

  • 共通依頼書:画面数や要件定義、接続先一覧、権限マトリクスに加えて、移行から保守まで含める
  • 費用内訳:ライセンス、初期開発、外部サービス、クラウド基盤、年保守の区分と、対象外の明記
  • 成果物:アプリや環境の設定一式(接続情報の管理を含む)、権限一覧、API、テスト、障害手順と運用書、引継ぎ教育

契約が終わった後も自社で運用できるよう、設定や文書を受け取れるかを、初回の見積もり時に確認します。

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

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

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

Retoolのセキュリティと運用の確認事項

業務システムを中心に、操作権限やデータ管理、製品側と自社の対策で囲む図解。
製品と利用企業の両方で管理を続けます。

業務システムでは、安全に使い続けることが重要です。利用企業は、権限や個人情報、委託先を運用ルールとして定めます。ログやバックアップ、教育、退職者の停止も、運用ルールに含めます。

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

権限は、利用者の役割と操作範囲に加えて、必要なプラン機能に合わせて設計します。

  • 操作権限:画面の閲覧と、データの登録・更新・削除の範囲
  • 役割とデータ:営業、サポート、管理者、委託先ごとのグループ分けと、行・列・接続先の制御
  • プラン要件:料金ページでは、Business以上に監査ログや詳細権限、EnterpriseにSAML・OIDC SSO、ソース管理、エラー監視が掲載

必要な機能を、どのプランや契約で使えるかを確認します。Cloud・Self-hostの条件も、画面を作る前に確かめておきます。

個人情報と委託先の安全管理

個人情報を扱う場合は、扱うデータと委託先を押さえたうえで、自社と製品それぞれの対策を確認します。

  • データ管理:種類、目的、保存場所、閲覧者、委託先・再委託先、削除方法の整理
  • 製品側の対策:暗号化、アクセス監視、二要素認証、SSO、処理契約の確認
  • 自社の運用:規程、契約、アクセスレビュー、事故時の連絡体制の評価

個人情報保護委員会のガイドラインは、委託先に適切な安全管理措置を講じさせ、取扱状況を把握する考え方を示しています(出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年8月確認)。

Retool公式Trust Guideには、通信中と保存時の暗号化、アクセス監視、二要素認証の説明があります。さらに、SAML・OIDC SSOやデータ処理契約についても書かれています。

製品側の対策があっても、利用企業の責任が消えるわけではありません。

障害・変更・退職者対応の運用手順

継続運用に備えて、障害や変更への対応、利用者の入れ替わり、AI生成物の確認方法を定めます。

  • 障害・変更: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に向く業務から始める小さな導入

導入に迷ったら、効果を測りやすい業務を一つ選びます。問い合わせ対応や審査、在庫確認、マスタ更新などが候補になります。PoCの期間は2〜6週間程度です。

成功条件は、処理時間やミス率で設定します。そのうえで、実データに近い権限や例外、連携を確かめてから、部門展開や全社統制へ進みます。

標準業務は既存サービス、現場操作はRetool、独自の中核はバックエンドという役割分担

標準業務は既存のSaaSやパッケージに任せ、現場の検索や入力、承認はRetoolで組み立てます。一方で、競争優位となる複雑なロジックや台帳は、専用バックエンドに残します。

この境界を先に決めれば、Retoolの速さを活かしながら、将来の拡張や担当者の交代にも対応しやすくなります。

▼関連記事一覧
・Retoolのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Retoolのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Retoolのシステム開発の見積相場や費用/コスト/値段について
・Retoolのシステム開発の発注/外注/依頼/委託方法について

 

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。