Retoolのシステム開発は、業務課題と成果指標を決め、要件と責任を整理してから、PoCを経て本開発と運用へ進めると、手戻りを抑えやすくなります。
発注形態はPoC・請負・準委任から要件の確度に合わせて選び、契約では成果物と責任範囲を定めます。
▼全体ガイドの記事
・Retoolのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Retoolのシステム開発を外注する全体像
Retoolは業務アプリの層として、既存のDBやSaaS、APIと担当者の操作をつなぎます。ただし、正本データや複雑なロジックまで自動で解決する製品ではありません。
発注時には、正本データ、操作権限、障害時の復旧担当を決めておきます。
Retoolのシステムの概要
Retoolは既存システムと接続し、社内向けの業務アプリを作る仕組みです。発注前に、接続先と用途を次のとおり整理します。
- 接続先：DB、RESTやGraphQLのAPI、SalesforceなどのSaaS、表計算ソフト
- 用途：社内向けの検索・登録・承認・集計画面やワークフロー
Retoolは既存システムのデータを現場が扱いやすくする業務アプリの層で、ERPや会計パッケージそのものとは別物です。この層として捉えると、外注する範囲の線引きがしやすくなります。
公式料金ページでは、作成・編集するBuilderと、アプリを使うInternal userを分けて料金を計算しています。さらに、2026年8月時点では、プランによってステージング、監査ログ、細かな権限の提供範囲が異なります。SSOやソース管理も、プランごとに違いがあります（出典: Retool公式Pricing、2026年8月確認）。
外注と内製の分け方
業務ヒアリングや画面設計、API・DB接続は外注できます。テスト、リリース手順、操作マニュアルも、開発会社に任せられる作業です。
一方で、優先順位や例外処理、承認ルールは発注側が決めます。正本データや社内責任者も、業務を知る発注側で決めておく必要があります。
画面は内製できても、データモデルの変更や外部API障害まで担えるとは限りません。個人情報や監査対応についても、社内で担えるかを確かめる必要があります。そこで、初回はベンダーが構築し、発注側がレビューや受け入れテスト、軽微な改修を受け持つ共同運用が有効です。
発注形態の選び方とPoC・請負・準委任の違い
全社分を一度に固定価格で頼む前に、PoCで不確実性を減らしてから本開発へ進む方法があります。契約は、データ連携や権限、例外処理の確度を中心に選びます。そのうえで、利用者数や監査要件も含めて判断します。
PoCで発注するケース
要件が固まっていない場合は、期間を2〜6週間とし、主要な1業務、1つのデータソース、少数の利用者に範囲を絞ります。完成版より、業務改善の効果とAPIの応答を中心に確かめます。データ品質や権限の理解度も、同時に見ておきます。
RFPには画面数だけでなく、検証仮説と合格条件を書いておきます。たとえば、入力漏れや検索時間、承認履歴などの成果を、数値または確認方法で定めます。
請負で発注するケース
画面仕様やデータ項目、連携方式、受け入れ条件が明確な部分は、請負に向いています。成果物には、画面定義書やAPI仕様、権限一覧を含めます。テスト結果や操作マニュアル、アプリも成果物とし、検収条件と修正回数を定めます。
請負は予算を管理しやすい一方で、要件が追加されると費用や納期が変わります。画面を一つ追加するだけでも、権限やSQLの作業が増えます。ワークフローや監査ログ、テストにも手が及ぶため、変更の扱いを事前に決めておきます。
準委任・ハイブリッドで発注するケース
要件整理や接続方式を発注側とベンダーで一緒に考える場合は、作業時間や体制を基準にする準委任が適しています。このとき、発注側が業務の判断を行い、ベンダーが設計や実装、レビューを支援します。
段階ごとに契約を分ける方法もあります。要件整理とPoCは準委任、確定した機能は請負、リリース後は月次の準委任にします。そのうえで、成果物の所有権やアプリ・設定の引き渡し、障害窓口をつなぐ責任者を決めておきます。
発注前にRFPと要件を整理する方法
RFPでは、業務背景や利用者、既存データといった前提を、すべての候補会社に同じ条件で伝えます。連携先やセキュリティの条件も、同じ粒度で書いておきます。納期、予算、保守の条件もそろえると、複数社の見積もりを比べやすくなります。
業務課題と成果指標の明記
業務フローと改善目標を対応させて、RFPに記載します。評価する工程と指標も、候補会社の間でそろえます。
- 業務フロー：担当者、入力、判断、出力、例外の順に整理
- 成果指標：処理時間、転記回数、入力ミス、承認待ち、問い合わせ件数
たとえば、営業がExcelに入力し、管理部門がメールで確認して基幹システムへ転記する業務なら、Retoolで置き換える工程を書き出します。
Retool公式事例では、Descriptが50以上のアプリを使い、複数チームで毎週数百時間の手作業を自動化したと公表しています。ただし、これは個別事例であり、自社の削減を保証する数字ではありません（出典: Retool公式Descript顧客事例、2026年確認）。
データ・権限・非機能要件の整理
データの持ち方、誰にどこまでの操作を許すかという権限、性能や監査などの非機能要件は、発注の段階で具体的に決めておきます。決めた内容がそろっているほど、候補会社の見積もりを同じ前提で比べられます。
- データ：正本、読み書き、個人情報、保持期間、バックアップ
- 権限：ロールに加え、部門・拠点・顧客・行や項目単位の要否
- 非機能要件：同時利用者数、応答時間、障害連絡、監査ログ、SSO、環境分離
正本の保存先は、Retool Database、PostgreSQL、MySQLから決めます。DWHや業務SaaSを正本にする場合も、同じ考え方で決めます。保存先が曖昧なままだと、二重管理や不整合が起きやすくなります。
2026年8月時点の公式料金表では、Business以上で監査ログや細かな権限を案内しています。Enterpriseでは、SAML／OpenID Connect SSOやソース管理を案内しています（出典: Retool公式Pricing、2026年8月確認）。必要な統制とプランを合わせて、RFPに記載します。
RFPに入れる項目
候補会社が同じ条件で回答できるよう、業務とシステムの前提をまとめます。RFPには、次の項目を記載します。
- 業務と利用者：背景、目的、対象業務、利用者数と役割、画面一覧、業務フロー
- データと統制：データソース、連携先、権限、認証、監査、移行対象
- 進行と費用：テスト、納期、予算上限または検討レンジ、納品物、保守条件
- 利用環境：CloudかSelf-hostか。未決定なら両案の提示を依頼
回答欄では、アプリ定義と環境設定の引き渡しや、SQL・JavaScriptのレビューについても尋ねます。さらに、API障害時の再試行と再委託の扱い、日本語窓口、追加費用の条件も確認します。
Retoolのシステム開発の進め方
基本工程は、要件定義、設計・実装、テスト・リリースの3つです。画面は早く組めても、要件が曖昧なまま実装を進めると手戻りが生じます。そのため、各工程の完了条件を決め、発注側も業務をレビューします。
企画とPoCでの対象業務の絞り込み
改善効果が大きく、データにアクセスでき、例外が複雑すぎない業務を一つ選びます。顧客サポートの検索・更新や審査の一覧・承認が候補になります。在庫入力やマスタ保守も候補です。
PoCでは正常系に加えて、権限不足や空データ、重複登録を試します。APIタイムアウトや承認者変更も、確認の対象に含めます。
終了時には、継続開発や既存バックエンドへ戻す処理、追加調査事項を整理します。その結果を、次の請負見積もりの前提にします。
設計と開発で決める事項
設計では、画面遷移や部品、クエリを定めます。ワークフローやAPIの仕様、エラー表示も定めます。ロールごとの操作可否も決めます。
複雑な業務ロジックを画面側に詰め込むと、保守しにくくなります。そのため、決済や会計計算、基幹台帳の更新は、サーバーサイドAPIや既存バックエンドへ分ける方針を確認します。
開発・ステージング・本番の接続先は分けておきます。Secretsや環境変数は、コードへ直接書き込まないようにします。Enterpriseのソース管理を使う場合は、Gitに保存する内容やレビュー担当、本番リリースの承認者を決めます。デモの動きに加えて、設定の再現と担当者への引き継ぎも成果物として確認します。
テスト・リリース・引き継ぎ
テストでは、画面表示だけでなく業務シナリオと権限、データ整合性を確認します。同時利用やAPI障害、監査ログへの対応も確かめます。バックアップと復旧も含めます。受け入れ時は、実担当者が日常業務を通して操作します。
リリース前には、利用者への告知と操作説明を済ませておきます。旧運用との並行期間や問い合わせ窓口、切り戻し手順も決めます。
引き継ぎでは、画面やクエリ・API、権限を受け取ります。データ項目や環境の情報、既知の制約、保守連絡先も受け取ります。
契約形態と責任分界を決めるポイント
契約では、契約名だけでなく、成果と判断の担当、変更時の精算を決めておきます。データ連携や個人情報を扱う場合は、納品後の運用責任も契約に含めます。
請負契約での成果物と検収の定め
成果物としては、Retoolアプリや画面仕様、API・クエリ設計書を示します。加えて、テスト結果と操作マニュアルを挙げます。環境設定と権限表も含めます。「システム一式」だけでなく、画面や対応ブラウザ、ロール、合格条件まで具体化します。
仕様どおりに動かない不具合と、業務ルールの変更や連携先の追加を分けて、無償修正の基準を決めます。Retoolの利用契約が発注側とRetool社の間で結ばれる場合もあるため、役務費とプラットフォーム費用は分けて扱います。
準委任契約での作業範囲と体制の定め
準委任では、月や期間ごとの稼働時間と担当者のスキルを定めます。さらに、定例会やレビューの進め方、問い合わせ、作業報告を取り決めます。発注側が優先順位を決め、ベンダーが作業計画を更新する進め方が、準委任には合っています。
準委任でも、成果物は必要で、期間の終わりには変更したアプリや設計メモを残します。未対応の課題と次月の提案、作業時間の内訳も残し、変更履歴と文書化を契約上の運用に組み込みます。
個人情報と再委託の確認
個人情報の委託条件を、アクセス管理と契約上の責任に分けて定めます。
- 取扱範囲：アクセス対象、開発環境への複製、海外拠点、再委託先
- 契約条件：目的・担当者、暗号化・ログ・保存期間、削除・返却・漏えい連絡、監査、再委託の事前承認
- 責任分界：プラン、Cloud・Self-host、接続先に応じて整理
個人情報保護委員会のガイドラインは、委託先の選定や契約、取扱状況の把握など、適切な監督を求めています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。
責任分界は、Retool公式のTrust情報や料金ページにあるセキュリティ機能だけでなく、契約書やDPAの条件を合わせて決めます。そのうえで、自社の法務・情報システム部門と確認します。
Retoolのシステム開発の費用相場と内訳
費用は、ライセンス、要件定義・開発・導入、保守運用の3つに分けて考えます。Retool固有の一律の相場はありません。ここで示す金額は、一般的な人月単価と製品特性をもとにした目安で、契約額を保証するものではありません。
ライセンス費用の考え方
ライセンス額は、Builder、Internal user、External userの人数とプランによって変わります。利用者区分ごとの月額単価を比べると、プラン選びの費用を見積もれます（公式米ドル表示、2026年8月確認）。
- Team：Builderは月10ドル、Internal userは月5ドル
- Business：Builderは月50ドル、Internal userは月15ドル
上記は公式Pricingの米ドル表示です（出典: Retool公式Pricing、2026年8月確認）。ただし、支払い周期や地域表示、Cloud・Self-hostの条件によっても変動します。
例として、Builder 2人、Internal user 20人で利用する場合を考えます。1ドル150円で換算すると、Teamは月約1.8万円、Businessは月約6万円です。
ただし、為替や税、契約条件は含めていません。AI credits、Agents、External user料金も、計算の対象外です。
利用料と開発会社への役務費を分け、利用者増加時の年間費用も確認します。
開発・導入費用の目安
開発規模ごとの費用と期間は、次のとおりです。小規模な案件では、データソースや利用者、権限が限定される前提になっています。
- 小規模PoC・1〜数画面：50万〜150万円、2〜6週間
- 小規模業務アプリ：検索・登録・承認・CSV出力で150万〜400万円、1〜3か月
- 部門業務の統合：複数DB・API、移行、権限、監査ログ、通知、教育を含み400万〜1,000万円、3〜6か月
- 全社統制型：SSO、Self-host、複数環境、厳格な監査、複雑な外部連携を含み1,000万〜3,000万円以上、6〜12か月になる可能性
この推定は、Retoolの公開価格ではありません。一般的な業務システムの相場に対して、画面部品の実装が減る分を見込み、要件やデータ品質、連携の作業を加えています。権限、テスト、教育の作業も加味しています。
リサーチノートの一般目安は、PMが月90万〜150万円、SEが月65万〜110万円程度です。体制や複雑さによって変わり、納期やセキュリティ要件も影響します。そのため、作業項目と工数を確認します。
ランニングコストの見積もり
初期費用のほかに、Retoolの利用料やクラウド・DB、監視・バックアップの費用がかかります。保守や問い合わせ、小改修、教育にも費用が発生します。
一般目安として保守運用費を初期開発費の年15〜25％とする考え方がありますが、そのまま適用できるとは限りません。
画面は内製で変えられても、DBスキーマやAPIの変更、権限の棚卸しは別途必要になります。障害調査や監査対応も、費用として見込みます。保守の条件として稼働時間や受付時間、障害優先度を決めます。目標復旧時間と改修単価も決めたうえで、年間の総保有コストを見積もります。
Retoolの委託先を選ぶポイント
認定表示は参考にとどめ、本番経験や業務理解を、どの会社にも同じ質問で比べます。データ・API設計や保守体制も確かめます。
海外企業に頼む場合は、英語や時差への対応を評価します。国内契約や個人情報の移転、日本語窓口も確認します。
公式パートナー表示と実績の確認
Retoolは2025年にAgency programを案内し、Agency plan、優先サポート、顧客紹介を説明しました。
公式のAgencyやPartner表示は候補選びの材料になりますが、認定が業務理解や成功を保証するものではありません（出典: Retool公式「Introducing the Retool Agency program」、2025年2月）。
実績を確かめるときは、アプリ数だけでなく、利用者数や同時アクセス、データソースを尋ねます。さらに、権限の粒度や保守期間、障害対応についても確認します。匿名化した要件定義書やテスト計画、運用引き継ぎの例も、品質を判断する材料として役立ちます。
技術力と業務理解の評価の分け方
担当者には、部品の配置だけでなく、SQLやJavaScript、APIの仕組みを説明してもらいます。認証やSecrets、環境分離についても説明を求め、エラー処理も確かめます。
業務の例外や承認ルールを聞かない会社は、使われない画面を作る恐れがあります。
面談では、「営業が申請し、管理者が承認し、部門ごとに顧客表示が異なる」ケースを示します。そのうえで、データや権限、画面の考え方を聞きます。エラー時の対応も聞き、前提の確認事項やリスク、代替案を説明できるかを見ます。
保守体制と引き渡しの確認
リリース後の一次切り分けの担当者と、Retoolの設定や接続先変更の承認者を確認します。見積もりには、受付時間や重大度別の初動、月次報告も含めます。さらに、権限の棚卸しや脆弱性・仕様変更への対応も、対象に入れます。
契約終了時には、アプリ定義やクエリ、ワークフローの受け取り形式を確認します。画像や文書、Git、環境変数一覧も、どの形で受け取るかを確かめます。契約名義や他社への保守移管も定め、特定ベンダーへの過度な依存を防ぎます。
Retoolの見積もりを比較するポイント
見積もりは、総額よりも、同じ前提でどの作業が含まれているかを比べます。要件定義だけが含まれ、移行や受け入れテストが別料金になる場合もあるため、追加になりやすい項目を事前に聞いておきます。
同じ前提での見積もり依頼
どの会社にも、同じRFPと画面一覧を渡し、データ項目や利用者数、納期も同じ条件で伝えます。そのうえで、項目別の工数と担当、単価を出してもらい、期間や前提も示してもらいます。初年度と2年目以降を分け、利用者が増えた場合の試算も依頼します。
作業の内訳は工程ごとに示してもらい、要件定義や連携、実装、権限の範囲を確かめます。テストや移行、教育は、別々の項目として立ててもらいます。リリースや保守も、項目を分けてもらいます。
ライセンスやクラウド、監視の料金も確認します。交通費や翻訳費、外部サービスの費用も、見積もりに含めてもらいます。External userやAI credits、Agentsやワークフロー実行回数は、利用量で変わる可能性があります。
安い見積もりに潜むリスク
安価な見積もりでは、要件の整理や例外処理が省かれている場合があります。権限やテスト、教育、保守も、含まれていないことがあります。認証情報の管理不備、閲覧範囲の誤り、エラー時の二重登録は、本番後の損失につながります。
見積もりでは、総額のほかに未確定の事項や追加費用の条件を比べます。成果物と検収、体制の条件、保守や終了時の引き渡しも確認します。価格差がどの作業から生じるかを説明できる会社を選びます。
見積比較のチェックリスト
各社の範囲をそろえるため、次の5項目を照合します。
- 対象範囲：対象画面と対象外画面、利用者数とロール
- データ連携：データソース、書き込み範囲、API・認証の責任者
- 環境と品質：CloudかSelf-hostか、環境構成、テストと受け入れ条件
- 移行と運用：移行・教育、保守時間とSLA、成果物と知的財産
- 契約条件：再委託、個人情報、追加費用の単価
回答は同じ表に転記して、評価します。評価の軸は、価格や納期、体制を中心に置きます。さらに、技術や業務理解も含めます。セキュリティや運用も、同じ軸で見ます。
例として、価格を30点、技術と業務理解を各20点とします。保守とセキュリティは各15点、提案の妥当性は10点とするなど、自社の優先度で配点します。
よくある質問
導入前に多い疑問を取り上げます。契約や料金は条件によって変わるため、一般的な考え方と、ベンダーへの確認事項を示します。
Retoolのシステム開発はどのような会社に向いていますか？
既存DB、SaaS、APIを使い、社内の業務を早く改善したい会社に向きます。改善の対象は、検索・更新・承認・集計の業務です。顧客サポートや審査、在庫の業務では、利用者を絞って効果を確かめやすいです。営業管理やマスタ保守も、この例に当たります。
会計・給与の正本、高度な一般消費者向けUX、ミリ秒単位で制御する大規模トラフィックでは、専用バックエンドやパッケージとの分担を検討します。Retoolで作る範囲をベンダーに提案してもらいます。
Retoolの開発を外注すると何か月かかりますか？
PoCは2〜6週間、小規模アプリは1〜3か月、複数システムの部門統合は3〜6か月が目安です。SSOやSelf-hostを含む場合や、複雑な権限、移行、厳格な受け入れがある場合は、6〜12か月になる可能性があります。
期間は画面数だけでなく、要件やデータの状態、発注側のレビュー担当、API仕様で変わります。発注側の確認と本番移行準備の期間も含めて見積もります。
SQLを書けない担当者でもRetoolを運用できますか？
日常利用や軽微な画面変更は、SQLなしでできる場合があります。一方で、データ更新や複雑な検索、API連携には、SQLやJavaScriptが必要なこともあります。権限や障害対応にも、同じ道具が必要な場合があるため、内製範囲と委託範囲を分けて考えます。
運用担当者へは、画面変更やテスト環境、リリース承認の教育を行います。問い合わせ先も、あわせて伝えます。
クエリの命名やコメント、レビューの方法も、文書で納品してもらいます。権限変更の手順も、あわせて渡してもらいます。
CloudとSelf-hostはどちらを選べばよいですか？
早く始めて、インフラの負担を抑えたい場合はCloudが候補になります。自社のVPC内でデータを管理したい場合や、社内規程でクラウド接続が厳しい場合は、Self-hostを検討します。
Self-hostでは、開発に加えて、更新や監視、バックアップの責任が増えます。復旧や可用性、脆弱性対応も含まれます。両方式の構成や体制、初期・年間費用、復旧手順を比べ、総保有コストで判断します。
まとめ
発注前には、業務課題と指標、正本データ、権限を整理します。さらに、Cloud・Self-hostの選択と保守の責任も決めておきます。そのうえで、不確かな要件はPoCや準委任で進め、確定した成果物は請負に分けると、予算と変更リスクを管理しやすくなります。
発注前の確認事項
RFPには画面のほかに、データやロール、非機能要件を記載します。さらに、テストや移行、教育、保守を記載します。再委託や成果物、追加費用の条件も、あわせて書いておきます。
発注側は、同じRFPで相見積もりを取り、価格差の理由を比べます。
小さく始める進め方と本番運用への移行
Retoolは現場アプリを試しながら改善を重ねる選択肢です。費用は画面数だけでなく、要件や連携、権限で変わります。テストや教育、保守の作業によっても左右されます。
まず一つの業務でPoCを行い、成果指標と運用条件を確認します。その結果をもとに本番範囲と委託先を決めます。
▼全体ガイドの記事
・Retoolのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。