Retoolのシステム開発の発注/外注/依頼/委託方法について

Retoolのシステム開発を発注・外注するなら、画面を作る費用だけでなく、要件整理、データ連携、権限、テスト、保守まで含めて委託範囲を決めることが重要です。Retoolは業務アプリの立ち上げを速められますが、業務上の正本データや複雑なロジックまで自動で解決する製品ではありません。

この記事では、Retoolのシステムを外注するときの発注形態、RFPと要件の整理方法、請負・準委任の選び方、費用相場、委託先の探し方、相見積もりの比較ポイントを順番に解説します。初めてRetoolを導入する企業でも、発注前に何を決めればよいか、どこをベンダーへ確認すればよいかが分かる構成です。

▼全体ガイドの記事
・Retoolのシステム開発の完全ガイド

Retoolのシステム開発を外注する全体像

Retoolのシステム開発を外注する場合は、Retoolを業務アプリケーション層として使い、既存のデータベースやSaaS、APIと業務担当者の操作をつなぐ形が基本です。発注の成否は、Retoolの操作スキルだけでなく、どのデータを正本にするか、誰がどの操作をできるか、障害時に誰が復旧するかを明確にできるかで決まります。

Retoolのシステムとは、データベース、RESTやGraphQLのAPI、SalesforceなどのSaaS、スプレッドシートと接続し、社内向けの検索・登録・承認・集計画面やワークフローを構築する仕組みです。ERPや会計パッケージそのものではなく、既存システムのデータを現場が扱いやすくする業務アプリの層と考えると、外注範囲を決めやすくなります。

Retool公式の料金ページでは、アプリを作成・編集するBuilderと、完成したアプリを日常利用するInternal userを分けて料金計算する仕組みが案内されています。2026年8月時点では、プランによってステージング環境、監査ログ、細かな権限、SSO、ソース管理などの提供範囲が異なるため、開発会社には機能だけでなく必要な契約プランも確認してもらう必要があります（出典: Retool公式Pricing、2026年8月確認）。

外注しやすいのは、業務ヒアリング、画面設計、APIやデータベースとの接続、権限設計、テスト、リリース手順、操作マニュアルの作成です。一方、業務上の優先順位、例外処理の判断、承認ルール、データの正本、社内の利用責任者は発注側が決める必要があります。

Retoolの画面を内製できるようになっても、データモデルの変更や外部API障害、個人情報の取り扱い、監査対応まで自動で内製できるとは限りません。最初の案件では、ベンダーに構築を任せながら、発注側の担当者がレビュー、受け入れテスト、軽微な画面改修を担う共同運用にすると、依存しすぎず定着させやすくなります。

発注形態はどう選ぶ？PoC・請負・準委任の違い

Retoolの発注では、いきなり全社分を固定価格で頼むより、PoCで不確実性を減らしてから本開発へ進む方法が現実的です。画面の数だけでなく、データ連携、権限、例外処理、利用者数、監査要件の確度を見て、請負契約と準委任契約を使い分けます。

要件が固まっていない場合は、2〜6週間程度で主要な1業務、1つのデータソース、少数の利用者に絞ったPoCを発注します。目的は完成版を作ることではなく、検索・登録・承認などの業務が本当に改善するか、APIの応答速度やデータ品質に問題がないか、権限を現場が理解できるかを確認することです。

PoCのRFPには、作る画面の数だけでなく、検証する仮説と合格条件を記載します。例えば、紙やExcelで処理していた申請をRetoolに置き換え、入力漏れを減らす、検索時間を短縮する、承認履歴を追えるようにするなど、数値または確認方法で成果を定義します。

画面仕様、データ項目、連携方式、受け入れ条件が明確になった部分は、成果物と納期を定めた請負で発注しやすくなります。画面定義書、API仕様、権限一覧、テスト結果、操作マニュアル、Retoolアプリの引き渡しを成果物に含め、検収条件と修正回数も契約書や発注書へ落とし込みます。

請負は予算を管理しやすい反面、発注後に「この例外も対応してほしい」と要件が増えると、追加費用や納期変更が生じます。Retoolでは画面を追加するだけに見えても、データソースの権限、SQL、ワークフロー、監査ログ、テストケースが増えるため、変更管理の方法を先に決めることが大切です。

要件整理や既存システムとの接続方式を一緒に検討したい場合は、作業時間や体制を基準にする準委任が適しています。発注側の担当者が業務判断を行い、ベンダーがRetoolの設計、実装、レビューを支援する形にすると、前提が変わりやすい初期段階でも進めやすくなります。

実務では、要件整理とPoCを準委任、本番の確定した画面や機能を請負、リリース後の改善を月次の準委任にするハイブリッドが使いやすいです。契約を分ける場合も、成果物の所有権、アプリ定義や設定の引き渡し、障害対応の窓口が途切れないように、全体の責任者を決めておきます。

発注前にRFPと要件を整理する方法

RFPは「Retoolで何を作るか」だけを伝える文書ではありません。業務の背景、利用者、既存データ、連携先、セキュリティ、納期、予算の考え方、発注後に期待する保守まで同じ条件で伝える文書です。RFPの粒度がそろうほど、複数社から返ってくる見積もりを比較しやすくなります。

最初に、現状の業務フローを担当者、入力、判断、出力、例外の順に書き出します。例えば、営業がExcelへ入力し、管理部門がメールで確認し、承認後に基幹システムへ転記しているなら、どの工程をRetoolで置き換えるのかを示します。

成果指標には、処理時間、転記回数、入力ミス、承認待ち時間、問い合わせ件数などを使います。Retool公式の顧客事例では、Descriptが50以上のカスタムアプリを日常利用し、複数チームで毎週数百時間の手作業を自動化したと公表しています。ただしこれはRetool社が紹介する個別事例であり、自社の削減効果を保証する数字ではないため、RFPでは自社の現状値と目標値を分けて記載します（出典: Retool公式Descript顧客事例、2026年確認）。

Retoolで扱うデータの一覧、正本となるシステム、読み取りと書き込みの区別、個人情報の有無、保持期間、バックアップ方針を整理します。Retool Databaseを使うのか、既存のPostgreSQLやMySQL、DWH、業務SaaSを正本にするのかを曖昧にすると、後から二重管理や不整合が起きやすくなります。

権限は「管理者」「承認者」「担当者」のようなロールだけでなく、部門、拠点、顧客、行や項目単位まで必要かを決めます。非機能要件には、同時利用者数、応答時間の目標、障害時の連絡、監査ログの保存、SSO、開発・ステージング・本番の環境分離を含めます。2026年8月時点のRetool公式料金表では、Business以上で監査ログや細かな権限、EnterpriseでSAML／OpenID Connect SSOやソース管理が案内されているため、必要な統制とプランをセットで記載します（出典: Retool公式Pricing、2026年8月確認）。

RFPには、背景と目的、対象業務、利用者数と役割、画面一覧、業務フロー、データソース、連携先、権限、認証、監査、移行対象、テスト、希望納期、予算の上限または検討レンジ、納品物、保守条件を入れます。候補会社へは、RetoolのCloudとSelf-hostのどちらを想定するか、未決定なら両案を出してほしいことも伝えます。

さらに、候補会社へ同じ質問を投げるための回答欄を用意します。例えば「アプリ定義と環境設定の引き渡し方法」「SQLやJavaScriptのレビュー体制」「API障害時のリトライ」「再委託の有無」「日本語の保守窓口」「追加費用になる条件」を質問に含めると、価格だけでは分からない実行力を比較できます。

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

Retoolの開発は、要件定義、設計・実装、テスト・リリースの順で進めます。ただし、Retoolは画面を早く組めるため、要件が曖昧なまま実装に入りやすい点に注意が必要です。各フェーズの完了条件を決め、発注側が業務レビューに参加することが、手戻りを抑える近道です。

企画では、対象業務を「社内のすべて」ではなく、改善効果が大きく、データにアクセスでき、例外が過度に複雑ではない一つの業務へ絞ります。顧客サポートの検索・更新、審査の一覧と承認、在庫の現場入力、マスタメンテナンスなどは、Retoolの強みを検証しやすい候補です。

PoCでは、正常系だけでなく、権限がない利用者、空データ、重複登録、APIのタイムアウト、途中で承認者が変わるケースを試します。PoC終了時に、継続開発の対象、既存バックエンドへ戻す処理、追加調査が必要な論点を一覧にして、次の請負見積もりの前提にします。

設計では、画面遷移、コンポーネント、クエリ、ワークフロー、API、エラー表示、ロールごとの表示・操作可否を定義します。Retoolの画面側に複雑な業務ロジックを詰め込むと、後から読みにくくなり、担当者が変わったときに保守できません。決済、会計計算、基幹台帳の更新など重要なロジックは、サーバーサイドのAPIや既存バックエンドへ分離する方針をベンダーと確認します。

開発環境、ステージング、本番の接続先を分け、Secretsや環境変数をソースコードへ直書きしない設計にします。Enterpriseでソース管理を使う場合も、Gitに何を保存し、誰がレビューし、どの承認で本番リリースするかを決める必要があります。機能のデモだけでなく、設定を再現できるか、担当者が引き継げるかを成果物として確認します。

テストは、画面が表示されるかだけでなく、業務シナリオ、権限、データ整合性、同時利用、API障害、監査ログ、バックアップと復旧の確認まで行います。受け入れテストでは、開発会社が用意したテストケースだけでなく、実際の担当者が日常業務を最初から最後まで操作します。

リリース前には、利用者への告知、操作説明、旧運用との並行期間、問い合わせ窓口、障害時の切り戻し手順を決めます。引き継ぎでは、画面一覧、クエリとAPIの構成、権限表、データ項目、環境情報、既知の制約、保守連絡先を受け取り、ベンダーが離れても最低限の運用判断ができる状態にします。

契約形態と責任分界を決めるポイント

Retoolを外注する契約では、契約形式の名前だけでなく、何を成果として約束するか、発注側と受託側のどちらが判断するか、変更時にどう精算するかを確認します。特にデータ連携や個人情報を含む案件は、アプリの納品だけで責任が終わらないため、運用時の分界まで契約に含めます。

請負契約では、納品するRetoolアプリ、画面仕様、APIやクエリの設計書、テスト結果、操作マニュアル、環境設定、権限表を具体化します。「システム一式」のような表現だけでは検収できないため、対象画面、対応ブラウザ、利用者ロール、受け入れテストの合格条件まで記載します。

検収後の瑕疵対応と追加改修を分けることも重要です。仕様どおりに動かない不具合は無償修正の対象にし、業務ルールの変更や新しい連携先の追加は別見積もりにするなど、判断基準を先に合意します。Retoolのライセンス契約は発注側とRetool社の契約になる場合もあるため、開発会社の費用とプラットフォーム費用を分けて記載します。

準委任契約では、月または期間ごとの稼働時間、担当者のスキル、定例会、レビュー、問い合わせ対応、作業報告を定めます。完成画面を一括納品する契約ではないため、発注側が優先順位を決め、ベンダーが作業計画を更新する運用が合います。

ただし、準委任だから成果物が不要になるわけではありません。期間終了時に、作成・変更したアプリ、設計メモ、未対応課題、次月の提案、作業時間の内訳を残してもらいます。Retoolは小さな改修を積み重ねやすいからこそ、変更履歴とドキュメントを契約上の運用に組み込む必要があります。

顧客情報や従業員情報を扱う場合、発注先がどのデータへアクセスするか、開発環境へコピーするか、海外拠点や再委託先があるかを確認します。個人情報保護委員会のガイドラインでは、個人データの取扱いを委託する場合、委託先の選定、委託契約の締結、取扱状況の把握など、必要かつ適切な監督が求められています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。

契約書やDPAには、利用目的、アクセスできる担当者、暗号化、ログ、保存期間、削除・返却、漏えい時の連絡、監査、再委託の事前承認を含めます。Retool公式のTrust情報や料金ページにセキュリティ機能が掲載されていても、契約プラン、CloudとSelf-hostの構成、接続先の設定によって責任分界は変わるため、ベンダー任せにせず自社の法務・情報システム部門と確認します。

Retoolのシステム開発の費用相場と内訳

Retoolの費用は、プラットフォームのライセンス、初期の要件定義・開発・導入、リリース後の保守運用に分けて考えます。Retool固有の開発価格は案件ごとに異なり、公開された一律相場はありません。以下はリサーチノートにある一般的な業務システムの人月単価とRetoolの特性をもとにした見積もりの目安であり、契約金額を保証するものではありません。

ライセンスは、作成・編集するBuilder、社内で利用するInternal user、社外の顧客や取引先が使うExternal userの人数と、選ぶプランで変わります。調査時点のRetool公式料金表の米ドル表示を例にすると、TeamはBuilderが月10ドル、Internal userが月5ドル、BusinessはBuilderが月50ドル、Internal userが月15ドルと案内されていましたが、支払い周期や表示地域、Cloud・Self-hostの条件で変動します（出典: Retool公式Pricing、2026年8月確認）。

例えばBuilder 2人、Internal user 20人という前提なら、上記の米ドル表示を単純計算してTeamは月120ドル、Businessは月400ドルです。1ドル150円で換算した場合は月約1.8万円、月約6万円となりますが、これは為替、税、契約条件、AI credits、Agents、外部ユーザー料金を含まない試算です。見積書では「Retool社への利用料」と「開発会社への役務費」を別行にし、利用者が増えたときの年間費用も確認します。

小規模な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の公開価格ではなく、一般的な業務システムの相場を土台に、UI部品の実装量が減る一方で要件定義、データ品質、連携、権限、テスト、教育が残ることを加味した推定です。見積もりの根拠として、リサーチノートではPMを月90万〜150万円、SEを月65万〜110万円程度の一般目安として整理しています。会社の体制、業務の複雑さ、納期、セキュリティ要件により変わるため、必ず作業項目と工数で確認します。

初期費用のほかに、Retoolのサブスクリプション、接続先のクラウドやデータベース、監視・バックアップ、保守・問い合わせ、小改修、ユーザー教育の費用が発生します。リサーチノートで参照した業務システムの一般目安では、保守運用費を初期開発費の年15〜25％程度とする考え方がありますが、Retoolの案件でもそのまま適用できるとは限らないため、保守対象と対応時間を明確にして見積もります。

Retoolは画面の変更を内製しやすくても、データベースのスキーマ変更、APIの仕様変更、権限の棚卸し、障害調査、監査対応まで無償になるわけではありません。月次の稼働時間、問い合わせの受付時間、障害の優先度、目標復旧時間、追加改修の単価を含めて、導入前から年間の総保有コストを計算します。

Retoolの委託先を選ぶポイント

委託先は、Retoolのロゴや認定表示だけで決めず、本番運用の経験、業務理解、データとAPIの設計力、保守体制を同じ質問で比較します。発注先が海外企業の場合は、英語での要件確認、時差、国内契約、個人情報の移転、日本語の障害窓口まで含めて評価します。

Retool公式は2025年にAgency programを案内し、Agency plan、優先サポート、顧客紹介などの仕組みを説明しています。公式AgencyやPartnerの表示は候補を絞る材料になりますが、認定だけで業務理解やプロジェクト成功が保証されるわけではありません（出典: Retool公式「Introducing the Retool Agency program」、2025年2月）。

実績確認では、単にアプリを作った件数ではなく、利用者数、同時アクセス、データソース、権限の粒度、リリース後の保守期間、障害対応の実例を聞きます。画面のスクリーンショットだけでなく、匿名化した要件定義書、テスト計画、運用引き継ぎのサンプルを見せてもらうと、納品後の品質を想像しやすくなります。

Retoolの開発担当者には、コンポーネント配置だけでなく、SQL、JavaScript、API設計、認証、Secrets、環境分離、エラー処理を説明してもらいます。同時に、業務担当者から聞いた内容を画面へ落とす力も必要です。専門用語だけで説明し、現場の例外や承認ルールを確認しない会社は、完成後に使われない画面を作るリスクがあります。

選定面談では、候補会社へ簡単なケースを渡します。「営業が申請し、管理者が承認し、部門ごとに見える顧客だけが異なる」という状況で、データ構成、権限、画面、エラー時の動きをどう考えるかを聞きます。回答の正解を一つに決めるのではなく、前提を質問し、リスクと代替案を説明できるかを確認します。

開発担当者と保守担当者が同じとは限らないため、リリース後に誰が一次切り分けをするか、Retoolの設定変更と接続先の変更を誰が承認するかを確認します。問い合わせの受付時間、重大度ごとの初動、月次報告、定期的な権限棚卸し、脆弱性や仕様変更への対応も見積もりに含めます。

また、契約終了時の出口を確認します。アプリ定義、クエリ、ワークフロー、画像、ドキュメント、Gitリポジトリ、環境変数の一覧をどの形式で受け取れるか、Retoolの契約名義が誰か、別会社へ保守を移せるかを確認します。出口条件を発注時に定めておくことが、特定ベンダーへの過度な依存を防ぎます。

Retoolの見積もりを比較するポイント

見積もり比較では、総額の安さではなく、同じ前提でどこまで含まれているかを確認します。要件定義だけが含まれ、データ移行や受け入れテストが別料金になっていることもあります。金額が低い理由と、後から追加になりやすい項目を質問してから判断します。

候補会社には同じRFP、画面一覧、データ項目、利用者数、想定納期を渡し、見積もりの粒度も指定します。要件定義、UI設計、API・DB連携、Retool実装、権限、テスト、移行、教育、リリース、保守を分け、各項目の工数、担当ロール、単価、期間、前提条件を記載してもらいます。

ライセンス費、クラウド費、監視費、交通費、翻訳費、外部サービスの利用料が含まれるかも比較します。特に外部ユーザー、AI credits、Agents、ワークフロー実行回数は利用量で変わる可能性があるため、初年度と2年目以降を分け、利用者が増えた場合の試算も依頼します。

極端に安い見積もりでは、要件定義、権限設計、例外処理、テスト、教育、保守が省かれている可能性があります。Retoolの画面が短期間で完成しても、APIの認証情報が適切に管理されていない、誰でもデータを閲覧できる、エラー時に二重登録されるといった問題があれば、本番投入後の損失が大きくなります。

比較時は、見積総額に加えて、未確定事項の数、追加費用の条件、成果物、検収、体制、保守、契約終了時の引き渡しを評価します。安い会社を排除するのではなく、価格差がどの作業の差なのかを説明できる会社を選ぶことが重要です。

最低限、(1)対象画面と対象外の画面、(2)利用者数とロール、(3)データソースと書き込み範囲、(4)APIや認証の責任者、(5)CloudかSelf-hostか、(6)開発・ステージング・本番の構成、(7)テストと受け入れ条件、(8)移行・教育、(9)保守の時間とSLA、(10)成果物と知的財産、(11)再委託と個人情報、(12)追加費用の単価を並べます。

各社の回答を同じ表へ転記し、価格、納期、体制、技術、業務理解、セキュリティ、運用の観点で評価します。例えば価格だけを30点、技術と業務理解を各20点、保守とセキュリティを各15点、提案の妥当性を10点とするなど、自社の優先順位に合わせた評価軸を事前に決めておくと、社内説明もしやすくなります。

よくある質問

Retoolの発注でよくある疑問を、導入前に判断しやすい形で回答します。契約や料金は個別条件で変わるため、ここでは一般的な考え方と、ベンダーへ確認すべきポイントを整理します。

既存のDBやSaaS、APIを活用し、社内の検索・更新・承認・集計を短期間で改善したい会社に向いています。顧客サポート、審査、在庫、営業管理、マスタメンテナンスなど、利用者が限定された業務から始めると効果を検証しやすいです。

一方、会計や給与の正本をRetoolだけで担う、一般消費者向けに極めて高度なUXを実現する、大規模なトラフィックをミリ秒単位で制御する場合は、専用バックエンドやパッケージとの役割分担を検討します。ベンダーには、Retoolで作る範囲と作らない範囲を提案してもらいます。

PoCなら2〜6週間、小規模な業務アプリなら1〜3か月、複数システムを統合する部門業務なら3〜6か月程度が目安です。SSO、Self-host、複雑な権限、データ移行、厳格な受け入れテストを含む場合は、6〜12か月程度の計画になる可能性があります。

期間は画面数だけでは決まりません。要件が固まっているか、データが整っているか、発注側のレビュー担当者が確保できるか、既存APIの仕様が明確かで変わります。見積もりでは開発期間だけでなく、発注側の確認期間と本番移行の準備期間も含めて確認します。

日常利用や軽微な画面変更は、SQLを書かない担当者でも運用できる場合があります。ただし、データ取得・更新、複雑な絞り込み、API連携、権限、障害対応にはSQLやJavaScriptの知識が必要になることがあるため、発注時に内製する範囲とベンダーへ依頼する範囲を分けます。

運用担当者向けに、画面変更のルール、テスト環境の使い方、リリース承認、問い合わせ先を教育します。ベンダーには、属人化を避けるため、クエリの命名、コメント、レビュー、権限変更の手順をドキュメントとして納品してもらいます。

短期間で始め、インフラ運用の負担を抑えたい場合はCloudが候補です。データを自社VPCの境界内で管理したい、社内ネットワークや規程上クラウドの接続条件が厳しい場合はSelf-hostを検討します。

Self-hostでは、Retoolのアプリ開発だけでなく、アップグレード、監視、バックアップ、障害復旧、可用性、脆弱性対応の責任が増えます。発注先には両方式の構成図、運用体制、初期費用、年間費用、障害時の復旧手順を提示してもらい、セキュリティだけでなく総保有コストで判断します。

まとめ

Retoolのシステム開発を発注・外注するときは、最初に業務課題と成果指標を定め、正本データ、権限、Cloud・Self-host、保守の責任分界を整理します。そのうえで、要件が不確かな部分はPoCや準委任、確定した成果物は請負に分けると、予算と変更リスクを管理しやすくなります。

RFPには、画面一覧だけでなく、データソース、利用者とロール、非機能要件、テスト、移行、教育、保守、再委託、納品物、追加費用の条件を記載します。候補会社には同じRFPで相見積もりを依頼し、価格差がどの作業項目から生まれているかを比較します。

Retoolは、現場の業務アプリを早く試し、改善を積み重ねるための有力な選択肢です。ただし、開発費が安くなるかどうかは画面数では決まらず、要件定義、連携、権限、テスト、教育、保守をどこまで設計するかで変わります。まずは一つの業務でPoCを行い、成果指標と運用条件を確認してから、本番範囲と委託先を決めることをおすすめします。

▼全体ガイドの記事
・Retoolのシステム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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