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

Sinatraのシステム開発は、要件を整理し、提案を比べ、契約と検収を経て、保守まで確認する流れで発注します。要件と責任範囲を先に揃えておくと、見積を同じ条件で比べやすくなります。

進め方、契約、費用、委託先、保守の順に説明します。方式の全体像は完全ガイドでも確認できます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Sinatraのシステムを発注する前に決める全体像

Sinatraは、RubyでWebアプリケーションを作るための軽量なDSLです。RailsのようにORM、認証、管理画面、ジョブ処理が標準で揃うフルスタック型ではありません。そのため、必要な機能はGemや自社設計で組み合わせて作ります。

API、Webhook、社内ツール、公開側ページでは、この自由度が活きます。一方で、権限、監査、帳票、ワークフローは、Sinatraだけでは自動的に揃いません。

Sinatraの採用が向く業務と向かない業務

Sinatraは、画面や業務ルールが少なく、処理の流れをチームが説明できる案件に向きます。標準機能を持たないことが、開発のしやすさにつながります。

• 小規模API：5〜15エンドポイント程度の業務処理
• 連携処理：外部サービスからのWebhookを受け取る処理
• 社内ツール：入力、検索、CSVの入出力を行う機能
• 限定公開画面：管理画面や既存システムに添える補助機能

多数の部署やテナントが異なる権限で使う案件や、承認と複雑な帳票を含む案件があります。さらに、バッチ、監査、決済、リアルタイム処理を一つに集める案件もあります。その場合は、Sinatra単独にこだわらない判断が必要です。

公開側と管理側をSinatraとRailsで分ける方法があります。また、既存SaaSを使い、独自APIだけをSinatraで作る方法もあります。最初からRailsなどのフルスタックフレームワークを比較する選択肢も、RFPに残します。

単独・Rails併用・SaaS連携の選び方

判断の起点は、Sinatraで作れるかではなく、どの機能を自社固有の資産として持つかです。

• SaaS連携：会員管理、通知、決済、ファイル保管はSaaSに任せ、業務固有の判定と既存連携をSinatraで実装する
• Rails併用：管理画面や複雑なドメインモデルが中心なら候補にする
• 見積比較：三案の概算と、将来の移行・保守コストを同じ条件で求める

2026年8月時点のRubyGems掲載情報では、Sinatra 4.2.1は2025年10月10日公開です。同ページでは、Rack 3系を含む依存関係と、Ruby 2.7.8以上という要件が示されています（出典: RubyGems.org「sinatra 4.2.1」、2025年）。

新規開発では、Ruby 4.0または3.4系を候補にできます。互換性は、Sinatra、Rack、DBドライバ、認証関連Gemを実機で検証してから採用します。

Sinatraのシステム発注・外注の進め方

発注は、相談先を探し、要件を整理し、RFPを配って提案を比べ、契約を結んでから、設計・開発、受入テスト、リリース、保守へと進みます。自社で先に決める事項と、委託先に提案してほしい事項を分けておくと、見積を同じ条件で比べられます。

業務フローと発注範囲の整理

業務フローと発注範囲は、次の5項目を書き出して確かめます。

• 業務の流れ：利用者、担当部署、開始条件、入力、判断、出力、例外、既存連携
• 例外処理：「注文登録」だけでなく、在庫不足、重複、承認差し戻し、APIタイムアウト、担当者の異動、取消後の返金
• 処理規模：利用者数、1日あたりの処理件数、ピーク時間、同時接続数、保存年数
• 機能と運用範囲：MUST・SHOULD・将来検討の区分と、Sinatra・SaaS・既存システム・自社運用の切り分け
• RFPの前提：予算上限、希望時期、社内担当者、データ保管場所、既存ベンダーとの役割

RFPでの機能要件と非機能要件の分け方

RFPは、目的と対象範囲、機能の規模、品質条件を分けて書くと、提案を比べやすくなります。

• 背景と範囲：目的、利用者、課題、対象業務、画面・API、外部連携、データ移行
• 規模と進行：成果物、納期、予算、提案書の提出条件、画面・API・ロール・帳票・連携先の数
• 品質と運用：可用性、性能、拡張性、セキュリティ、バックアップ、復旧、監視、ログ保持、対応時間、移行性
• 測定条件：「速く」「安全に」ではなく、ピーク時の応答時間、RTO・RPO、障害通知までの時間という数値

機能要件は「誰が何をすると、何ができるか」の形で書きます。非機能要求グレードは、項目とレベルをそろえることで、発注側と委託先の認識の行き違いを減らす考え方です（出典: IPA「システム構築の上流工程強化」、2026年確認）。

小さなPOCによる技術と業務のリスクの事前検証

技術と業務のリスクは、本開発に入る前に先に洗い出します。特に採用経験が少ない場合は、この確認を省かないことが大切です。

• POCの範囲：採用経験が少ない場合は、本開発の前に認証、DB、主要API、外部連携、ログを検証する範囲
• POCの目的：完成品を安く作ることではなく、Gem互換性、データ構造、性能、運用、チーム理解度を確かめること
• 引き継ぎ条件：POCの成果物と、本開発へ引き継げる条件を先に決めておくこと
• 既存環境の調査：リポジトリ、Gemfile、Ruby版、CI/CD、DBスキーマ、障害履歴、監視、運用手順
• 移行案：聞き取りだけでなくコードと本番環境を照合したうえで比べる、現行保守、段階移行、Sinatra部分置換

Sinatraのシステム開発で選ぶ契約形態

契約形態は、作業そのものを頼むのか、合意した成果物の完成を頼むのかで選びます。変更の扱いも、判断材料になります。

契約書の名称より、成果物や検収条件、責任分界を具体的に決めることが大切です。変更手続と再委託、知的財産と保守の扱いも、文面で明らかにします。

IPAや経済産業省のモデル契約を参考にしながら、法務部門と情報システム部門で確認します。

請負契約の完成範囲と検収条件

請負契約では、完成範囲と検収条件、変更時の扱いを次のとおり定めます。

• 完成範囲：合意したシステムや機能の完成と発注者による検収。画面、API、DB、テスト仕様を契約に紐づける
• 検収条件：納品形式、検収期間、不具合の扱いを定め、「動くもの」だけを基準にしない
• 確認項目：正常系に加え、権限・入力エラー、外部連携停止、性能、バックアップ復元
• 工程の分割：要件未確定なら、要件定義・調査を準委任、仕様確定後の実装・テストを請負にする方法もある
• 納期調整：資料提供や意思決定が遅れた場合の調整を契約に記載する

要件が固まらないまま全工程を請負にすると、変更のたびに追加見積や責任の争いが起きがちです。

準委任契約が向く共同作業の工程

準委任契約を選ぶ場合は、共同作業の範囲と成果物を先に決めておきます。

• 進め方：専門家の支援を受け、発注者と委託先が要件や優先順位を調整する
• 対象工程：アジャイル開発、既存調査、要件定義、技術検証、運用改善で候補になる
• 月次成果物：作業報告、設計書、コード、テスト結果、判断事項、次月計画の定義

成果物を決めておくと、作業時間の報告だけで終わる事態を避けやすくなります。経済産業省のモデル契約では、外部設計などを請負型、要件定義や内部設計などを準委任型とする考え方が示されています（出典: 経済産業省「情報システム・モデル取引・契約書」、2007年公開、2026年確認）。

実際の契約は、プロジェクトの事情によって変わります。そのため、工程ごとの不確実性と成果の測りやすさを見て選びます。

ソースコード・設計書・権利・保守の扱い

Sinatraは自由度が高いぶん、たとえば担当者にしか分からない独自実装が残りやすい技術です。

• 開発資産：ソースコード、Git、README、環境構築手順、Gemfileと依存関係
• 技術資料：API仕様、DB定義、権限表、テスト結果、監視・バックアップ設定、障害対応手順
• 検収と権利：著作権、OSS表示、既存部品の利用範囲の確認
• 情報とアカウント：クラウド名義、秘密情報、再委託先、契約終了時のデータ返却・削除の取り決め
• 保守：障害の定義、受付時間、一次回答、復旧目標、脆弱性・Gem・Ruby更新、追加改修単価を、それぞれ分けて定める

第三者がローカル環境を再現できるかどうかを、検収条件に含める方法も有効です。

Sinatraのシステム開発費用相場とコストの内訳

Sinatra単体の国内公式な開発費の統計は、確認できません。そのため、ここに示すのは、業務システムの一般的な相場と、2026年7月更新の受託開発の公開情報をもとにした推定レンジです。

ここでの金額は、税別の初期開発費です。クラウド利用料や決済、メール、SMSなどの従量費は別で、運用保守やデータ移行の追加作業も別になる場合があります。

費用は、Sinatraを選ぶかどうかより、画面数、API数、連携数、品質要件で大きく上下します。

規模別の費用と期間の目安

規模別の費用と期間は、次の推定レンジを目安にします。

• 小規模APIなど：100万〜300万円、1〜3か月
• 部門向けポータル：300万〜800万円、3〜6か月程度
• 複数部門・顧客向けSaaS：500万〜1,500万円、6〜12か月程度
• 大規模開発：1,000万円〜数千万円以上になる可能性

小規模の目安には、5〜15エンドポイント、簡易認証、1〜2種類の外部連携、基本テストを含みます。部門向けの目安は、ロール別の権限や検索、CSVに加えて、通知や監査ログ、既存DB・API連携まで含む場合のものです。

複数部門の業務システムや顧客向けSaaSは、複雑な業務ルールや複数の連携に加えて、データ移行、負荷試験、障害試験、運用設計まで含みます。大規模開発になる条件は、基幹連携、可用性・災害対策、段階移行などです。実際の見積では、要件と体制を確認します。

見積に含まれる工数と別途費用

見積では、工程ごとの工数や人月に加えて、管理費と品質管理費、発注者側の作業を分けて確認します。

• 企画・設計：要件定義、基本設計、画面・API設計、DB設計
• 実装・検証：実装、単体・結合・総合テスト、インフラ構築
• 導入：データ移行、受入支援、マニュアル作成、リリース

SIA株式会社の公開目安（2026年7月更新）では、画面数20以下の小規模案件の人月単価が100万〜180万円とされています。総額は500万〜1,200万円など、規模や体制による幅が示されています（出典: SIA株式会社「受託開発の費用相場」、2026年7月更新）。

小規模APIでも、認証や外部API、データ移行、監視、24時間運用を加えると、費用は上限側に寄ります。一方で、POCやSaaS連携で範囲を絞れば、初期費用を抑えられる可能性があります。

保守費は初期開発費の15〜20%程度が目安とされています。対応時間や監視、脆弱性診断、追加改修の有無で変わるため、年額で比べます。

初期費用以外のランニングコスト

稼働後にかかる費用は、見積区分ごとに分けて確認します。

• インフラ：AWSなどのクラウド、DB、ロードバランサー、WAF、監視、ログ、バックアップ
• 外部サービス：メール、SMS、ファイル保存、外部APIの利用料
• 見積区分：初期費用、月額固定費、従量費、年額ライセンス、障害時の追加費用

アクセスが少なくても、冗長構成や長いログ保持期間によって、固定費が増える場合があります。

Ruby公式の保守状況では、2026年8月時点でRuby 4.0と3.4は通常メンテナンス、3.3はセキュリティメンテナンスです。3.2以下はEOLです（出典: Ruby公式「Ruby Maintenance Branches」、2026年確認）。

既存システムがEOLのRubyや古いRackに依存する場合は、機能追加の前に、更新調査と互換性検証を見積に含めます。

Sinatraの委託先選定と見積比較のポイント

委託先は、Sinatraと書かれているかどうかだけでなく、本番運用まで含むRuby案件を任せられるかで見ます。担当者や保守体制は、公開情報からは分からない場合があります。

最新バージョンへの対応、設計・テストの実績、保守窓口、再委託の有無を確かめます。そのうえで、同じRFPを渡し、同じ評価表で比べます。

技術名ではなく質問で見るSinatraの実績

候補企業には、使える技術名を聞くだけでなく、本番運用と保守の実態を質問します。

• 実績と体制：本番案件の規模・稼働年数、API・管理画面・DB・AWSの担当範囲、担当者の経験
• 事例資料：開示できない場合の代わりに、匿名構成図、成果物サンプル、テスト観点、引き継ぎ方法の確認
• 方式提案：Rails併用や段階移行も提案できるかの確認
• 技術管理：Ruby・Gem更新、依存関係、脆弱性スキャン、CI/CD、レビュー、ログ・監視、DB復旧テスト
• 担当者の理解：設計・開発・保守の担当者が、RFPの業務フローを説明できるかの確認

質問への回答が抽象的で、担当者や納品物が決まらない場合は、リスクが高まります。

見積書の前提条件と抜け漏れの比較

総額だけでなく、見積範囲、前提、評価軸を揃えて比較します。

• 工程の範囲：要件定義、設計、実装、テスト、移行、導入支援、管理、保守の有無
• 見積前提：画面・API・連携先・利用者・データ・環境の数、ブラウザ、テスト範囲、リリース回数
• 評価項目：費用、業務理解、技術適合性、体制、納期、成果物、セキュリティ、保守、契約条件
• 配点例：価格30%、提案25%、体制15%、技術・セキュリティ15%、保守・契約15%。重要度に応じて調整

前提が見積書に書かれていないと、後から増額しやすくなります。あらかじめ配点を決めておくと、担当者の印象だけで選ばずに済みます。

赤信号になる提案と追加費用の条件

提案の根拠と、追加費用が発生する条件は、契約前に確かめます。

• 説明の根拠：「Sinatraなので短期間で安い」という提案は、要件・運用・セキュリティの説明を確認する
• 方式の制約：Sinatra単独、Rails併用、SaaS連携の長所と制約、方式変更の条件
• 発注側のリスク：発注者作業、仕様変更、連携先遅延、データ品質、クラウド費用増加の扱い
• 追加費用：画面・API・帳票・連携の追加、要件変更、データ不備、診断、負荷試験、ストア・休日対応、24時間監視
• 変更手順：変更受付から影響分析、見積承認、納期変更、リリースまでの流れ

外注時に確認するセキュリティと保守運用

Sinatraでは、認証・認可とCSRF、入力値検証を個別に設計します。SQLインジェクションやファイルアップロードの対策も、設計の対象になります。Cookie、秘密情報、ログ、依存Gemも対象に含めます。

個人情報や業務データを扱う場合は、委託元として、アクセス範囲、再委託、事故時の連絡を契約に含めます。監査についても、契約で取り決めておきます。開発会社に任せきりにしないことが大切です。

権限・依存Gem・ログの要件

権限と依存Gemの管理では、次の項目を要件に含めます。なかでも、Cookieには Secure・HttpOnly・SameSite の属性を設定します。

• 権限範囲：画面、APIのGET・POST・PUT・DELETE、レコード・テナント単位、管理者操作
• 操作テスト：未ログイン、一般・部門・全体管理者、保守担当の操作表を作り、許可と拒否を確認
• Gem管理：Gemfileとロックファイルの納品、脆弱性確認の担当者と期限の設定
• 通信・入力対策：TLSと秘密情報の環境を分け、CSRF、レート制限、エラー内容を定める
• 記録と通知：監査ログを残し、管理者操作を通知する

OWASP Top 10:2025では、アクセス制御の不備がA01で第1位です。そのため、認証後にURLやIDを変えて、他人のデータが見えないかを確かめます（出典: OWASP Top 10:2025、2025年）。

個人情報保護委員会は、委託先の選定と安全管理措置、取扱状況、再委託の確認を、監督の例として挙げています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

障害・バックアップ・更新の責任分界

保守運用では、障害対応やバックアップ、更新、資産管理の責任者を決めておきます。

• 障害対応：監視担当、障害の定義、一次回答までの時間、復旧範囲
• バックアップ：取得頻度、保管期間、暗号化、別リージョン、復元テストの担当、RTO・RPOの数値化
• 保守対象：Ruby・Sinatra・Rack・OS・ミドルウェアの更新、脆弱性、クラウド障害、外部API変更
• 費用区分：データ修正、軽微な追加、月額保守内の作業、別途見積の開発を分けて扱う
• 資産管理：アカウント、ソース、設計書、ログ、バックアップを自社管理下に置き、移管に備える

復旧目標が曖昧だと、バックアップがあっても事業再開を判断できません。さらに、資産を自社管理下に置いておけば、ベンダーロックインを抑えられます。

Sinatraのシステム発注・外注でよくある質問

発注時によくある疑問を、費用、委託先、契約の観点から答えます。ここでの数字は、そのまま予算に組み込まず、RFPの前提と提案範囲に置き換えて確認してください。

Sinatraならシステム開発費用を安くできますか？

Sinatraはコード量が少なく済むため、初期構成や小さなAPIの開発効率が高まります。ただし、費用が自動的に安くなるわけではありません。

要件定義や認証、権限の設計は、Sinatraでも必要です。データ移行やテスト、監視、保守が加われば、その分の工数が発生します。

MVP（Minimum Viable Product）で範囲を絞る案と、SaaS連携や段階導入の案を比べます。不要な機能を先送りする方法も有効です。

Sinatraに対応できる開発会社はどう探しますか？

RubyやSinatraと書かれているかだけでなく、同規模の本番運用、AWSやDocker、DB、API連携、テストの経験を確認します。既存システムの引き継ぎ経験も、見ておきたい項目です。

公開情報で分からない点は、直接質問します。担当エンジニアや保守体制、再委託の有無、設計書とソースコードの納品、障害時の連絡が、主な質問項目です。

候補を2〜4社程度に絞り、同じRFPで提案と見積を受けると、比べやすくなります。

請負と準委任はどちらを選べばよいですか？

完成条件と範囲が明確な実装・テストは請負、要件定義、技術調査、アジャイルでの共同開発は準委任が候補です。

全工程を一つの契約に固定せず、要件定義は準委任、仕様確定後の開発は請負に分ける方法もあります。

契約形態そのものより、成果物や検収、変更の扱い、作業報告、責任分界が書面で分かることが大切です。

既存のSinatraシステムを別会社へ移管できますか？

移管できますが、その前に、ソースコードのほか、実行環境、GemとRubyのバージョン、DB、外部サービス、インフラアカウントを調べます。

CI/CD、監視、障害履歴、運用手順も確認します。そのうえで、保守継続、段階移行、再構築の三案を比べます。

現行ベンダーからの引き継ぎ期間とアクセス権を、契約に含めます。秘密情報の受け渡しとデータのバックアップも、契約で明確にします。

Sinatraのシステム発注・外注・委託方法まとめ

まず業務の目的と対象範囲を決め、Sinatra単独、Rails併用、SaaS連携、別フレームワークを比べます。

次に、画面・API・利用者・連携先・データ量・非機能要件をRFPに落とし込み、同じ条件で提案と見積を受けます。

推定レンジは、小規模APIで100万〜300万円、部門向け業務ポータルで300万〜800万円です。金額は、機能、品質、移行、運用の範囲によって変わります。

発注前に確認する五つのポイント

発注前には、方式、業務、品質、契約、運用の五つの観点を、順に確かめます。

• 方式：Sinatraで作る理由と作らない範囲
• 業務：業務フローとMUST機能
• 品質：非機能要件とセキュリティ
• 契約：契約形態、検収条件、納品物
• 運用：保守、更新、障害対応

ソースコードや設計書の受け取り、Gemの更新、クラウドアカウント、再委託、データ返却を曖昧にしないことが大切です。これらを明確にしておくと、委託先を変える場合にも、安全な運用を続ける場合にも役立ちます。

RFPと評価表の作成

続いてRFPと評価表を作り、要件、候補企業、長期運用を同じ基準で確かめます。

• RFP作成：業務フローと課題を整理し、機能・非機能要件、時期、予算、成果物、保守条件をRFPに記載する
• 候補企業への依頼：Sinatra実績、Ruby・Gem保守、AWS運用、テスト、既存移管、契約形態の提案を求める
• 選定：価格だけでなく長期運用も含めて委託先を選び、事業で使い続ける体制を整える

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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