Sanicのシステム開発は、要件整理と選定の後、設計・開発に入ります。テスト、稼働、定着へと続く全6段階を順に進めると、性能と業務要件に合う仕組みになります。
進め方に入る前に、Sanicが担う範囲と費用の目安を押さえておくと、各段階で何を決めればよいかが分かりやすくなります。
▼全体ガイドの記事
・Sanicのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Sanicの役割と業務システムの全体像
SanicはWebフレームワーク兼Webサーバーで、業務データを受け付けるAPIや外部サービス連携、リアルタイム通知、バックグラウンド処理を構成できます。ただし、Sanic単体に販売管理や勤怠管理の機能はありません。
業務システムは、画面、データベース、認証、監視、運用ルールを組み合わせて作ります。このため、Sanicがどの部分を受け持つかを先に見極めておく必要があります。
Sanicの担当範囲：APIと非同期処理
Sanicを使う業務システムは、画面、API・データ、非同期処理、実行・運用の4層で組み立てられます。このうちSanicが中心になるのは、APIと非同期処理の層です。
- 画面：利用者の操作を受け付ける部分で、ReactやVueなどを使います。
- API・データ：SanicのREST APIと、PostgreSQLなどのRDBの組み合わせ。
- 非同期処理：Redisなどのキャッシュまたはメッセージブローカーとバックグラウンドワーカーの組み合わせ。
- 実行・運用：Dockerやクラウド、監視・CI/CDの組み合わせ。
APIは入力を検証してデータを保存します。さらに、時間のかかる帳票生成や外部データ取得をキューへ渡すと、画面の応答を保ちやすくなります。
どこまでをSanicに任せ、どの処理を別サービスへ分けるかが設計上の判断になります。
バージョンの確認も必要です。Sanic 25.12は25系のLTSリリースで、Python 3.10以上が必要です（出典: Sanic公式リリースノート、2025年）。PyPIではSanic 25.12.1が2026年5月31日に公開されています（出典: PyPI「sanic」、2026年）。
そのため、既存環境がPython 3.9の場合は、着手前にアップグレードと依存ライブラリの互換性を確認します。また、脆弱性対応の期限も確かめないと、納品直前に環境変更が起きる可能性があります。
向いているシステムと過剰設計になりやすいシステム
採用の是非は、非同期処理の利点と、既製の管理機能をどこまで求めるかを照らし合わせて考えます。
- Sanicを検討：外部APIやDBへのI/O待ちが多いサービスです。
- Sanicを検討：利用者が集中するポータル、リアルタイム連携、短時間に大量のリクエストを受けるAPIゲートウェイです。
- 別案も比較：少人数の社内画面や管理画面、帳票が中心です。
- 別案も比較：認証やワークフローを短期間で一体化したい場合です。
複数の処理を待ち時間の間に進めたいなら、非同期処理の効果を検証できます。一方で、管理機能をまとめて整えたい場合は、Djangoや既製SaaSが適する可能性もあります。
「Sanicは速い」という理由だけで決めるのは危険です。同期ライブラリを非同期関数で呼ぶと、待ち時間がボトルネックになるからです。さらに、DB接続プールや外部APIのタイムアウトが未設計なら、性能を活かせません。
採用前には、同時接続数、p95・p99応答時間、1リクエストあたりのDB回数、外部API待ち時間を測定します。そのうえで、障害時の再実行方針も確かめ、測定結果をもとにフレームワークの採否を判断します。
Sanicのシステム開発の進め方
Sanicの開発は、要件整理から定着までの6段階を順に進めます。各段階の終了条件を決めておくと、技術先行や要望の増加を抑えられます。
フェーズ1：要件整理で決める業務と性能条件
要件整理では、通常の業務の流れに加えて、業務が止まる場面や担当交代時の動きまで押さえます。対象業務から例外、引き継ぎまでを、業務の流れに沿って書き出しておきます。
- 対象業務：販売、在庫、予約、顧客対応、IoTデータ収集など。
- 業務の流れ：誰がいつ何を見て判断し、次に何をするか。
- 例外：取消、重複登録、再実行、外部サービスの遅延など。
- 引き継ぎと整合：担当者交代やデータ不整合への対応。
画面一覧より先に業務フローを作ると、不要な機能を減らしやすくなります。
業務フロー、利用者・権限表、データ項目一覧、外部連携一覧は、要件整理の段階で作っておきます。加えて、機能はMUSTとWANTに分け、非機能要件や移行対象も書き残します。
非機能要件には、同時接続数、目標応答時間、稼働時間を含めます。また、RPO・RTO、ログ保存期間、個人情報の範囲も含めます。
非機能要件は、測定できる条件で書きます。たとえば「ピーク時に同時500接続で、p95を何秒以内にする」のようにします。具体的な目標値は、業務要件に応じて決めます。
フェーズ2：Sanic・既製品・他フレームワークの選定
選定では、業務の標準性と必要な独自機能を基準に、開発方式やフレームワークを比べます。
- SaaS：標準化された業務で独自性が低い場合に優先します。
- Sanicを含む個別開発：独自の外部連携やリアルタイム処理が競争力に直結する場合に検討します。
- Django：管理画面や帳票を短期間で作りたい場合の候補です。
- FastAPI：APIの入力検証やOpenAPI連携を重視する場合の選択肢です。
このほか、パッケージ、クラウド上の個別開発、スクラッチ開発も比較対象に入ります。選定後は、ベンダーの提案をもとに実装範囲と運用条件を具体化します。
提案には、Sanicの実装範囲と非同期処理の境界、DBドライバー、キューやRedisの役割を明記してもらいます。加えて、負荷試験の方法と保守担当者も確認します。
Sanicの本番経験は、「Python対応」の表示よりも、実際の動作で確かめるのが確実です。可能なら、匿名化した自社シナリオでPoCを行い、同期処理を混ぜた場合の性能や再試行を確認します。
ログの追跡性、開発者交代時の引き継ぎやすさ、提案が運用まで具体化されているかも確かめます。
フェーズ3：設計・開発での非同期処理と責任の分け方
設計では、画面、API、データモデルを構成図にまとめます。権限、通知、外部連携、運用監視も、同じ構成図に含めます。
SanicのAPIでは、入力検証、認証・認可、処理の責任を分けます。DBアクセスとレスポンスの扱いも、同じように切り分けて設計します。
外部APIやファイル処理のように時間のかかる処理は、キューへ渡す設計が基本です。
リクエスト中に終わらない処理を待たせると、タイムアウトやワーカーの占有につながります。そのため、受付IDを返して、後から結果を確認する方式も選べます。
非同期処理の仕様では、失敗時の再試行と二重実行の影響を先に洗い出します。
- 失敗時の制御：タイムアウト、リトライ、部分的な失敗。
- 重複防止：冪等性と重複実行への対応。
- キュー運用：キュー詰まりの検知と再実行。
決済や在庫引当を再実行すると、二重計上になる可能性があります。そこで、リクエストIDや処理済み記録を使い、一度だけ反映する仕組みを設けます。
設計書には、正となるデータ、再実行の担当者、手動復旧時の承認者を書いておきます。運用担当への引き継ぎにも使えます。
フェーズ4：テストでの機能・性能・セキュリティの確認
テストは、単体、結合、総合、負荷、受入に分けます。
Sanicでは接続数を増やし、p95・p99応答時間、DB接続プールの枯渇、外部API遅延を確かめます。さらに、ワーカーを止めた場合やキューの再実行も試します。
ベンチマークは参考値にとどめ、実データに近い件数やネットワーク、クラウド構成、自社の代表的なAPIで実測します。
受入前には、外部障害や誤操作が業務データに及ぼす影響も確かめます。
- 重複・中断：注文の二重送信やブラウザの途中終了。
- 外部障害：外部APIが5分間停止する状況。
- 権限・移行：別部門の顧客閲覧や移行データの重複。
IPAの「安全なウェブサイトの作り方」は、SQLインジェクション、XSS、セッション管理、アクセス制御や認可制御の欠落など11種類を扱います（出典: IPA「安全なウェブサイトの作り方」、2021年）。
入力検証や認証は、フレームワーク任せにせず、テストで検証します。そのうえで、診断結果と修正履歴も納品物に含めてもらいます。
フェーズ5：段階稼働での移行と障害対応の検証
いきなり全社へ展開せず、代表部門や一部機能から段階的に切り替えると安全です。
- データ移行：マスターの名寄せ、CSV文字コード、履歴の範囲。
- 切り替え：並行期間、更新の凍結時間、切り戻し条件。
- データの正本：正とするデータと旧システムの参照専用化。
並行稼働が長引くと、二重入力が当たり前になってしまいます。そのため、どのデータを正とし、旧システムをいつ参照専用にするかを、あらかじめ決めておきます。
本番前には、ヘルスチェック、Graceful shutdown、ログとメトリクス、アラート通知先を確認します。加えて、バックアップからの復旧も実際に試します。
リリース当日の責任者、開発会社の待機時間、重大障害の連絡ルート、ロールバック判断者は、事前に決めておきます。決めておけば、障害時に会議だけが続く事態を避けられます。
発注側は、利用者に、日常業務のどの場面で何を入力し、困ったときにどこへ連絡するかを示します。
フェーズ6：定着後のKPI確認とアップデート
定着状況は、ログイン数に加えて、業務成果とシステム品質を月次で確認します。
- 業務成果：入力時間、滞留日数、手作業の削減時間。
- 品質：APIエラー率、外部連携の失敗件数。
- 利用状況：問い合わせ件数、部門ごとの活用度。
数値が改善しないときは、画面を増やす前に原因を切り分けます。ステータスや権限、必須項目を見直し、責任者と教育方法も確認します。
アップデートの対象は、PythonとSanic本体、Sanic Extensionsです。DBドライバーやクラウドのランタイムも対象に入ります。
アップデートの検証と回帰テストを定例化し、リリースとロールバックも同じ流れで回します。
2026年時点では、Python 3.9から3.10以上への移行が必要な構成もあります。そのため、依存パッケージ一覧と更新責任者を納品後も維持します。
要望は、脆弱性、障害、法令、業務効果の優先度をもとに順序を決めます。便利機能の要望も、同じ基準で並べます。
Sanicのシステム開発の費用相場とコストの内訳
Sanic本体はオープンソースのため、ライセンス料だけで開発費が決まるわけではありません。
費用の中心は、業務整理、画面、DB、認証・認可、外部連携の作業です。さらに、テスト、クラウド、移行、教育、保守も費用に含まれます。
Sanic専用の国内料金統計は限られます。そのため、2026年の一般的な業務・Webシステム相場と、SanicのAPI・非同期処理を含む予算取り用レンジを分けて示します。
規模別の初期開発費の幅
必要な機能と非機能要件によって規模が変わるため、予算も条件と合わせて見ます。
- 小規模：100万〜300万円程度。
- 中規模：500万〜1,500万円程度。
- 高負荷基盤：1,000万〜3,000万円程度。
- 全社基幹など：3,000万円〜1億円超の可能性。
小規模の額は、5〜15本程度のAPI、単一DB、認証、簡易管理画面、外部API1〜2本に絞った場合の起点です。
中規模は、顧客・受発注・在庫の一部を扱う規模です。複数権限を備え、帳票、データ移行、テストも含みます。高負荷基盤は、キュー、Redis、監視、負荷試験、冗長化まで含めた場合を指します。
全社基幹の規模で、複数拠点や既存ERP・EDIとの連携、大規模移行、監査・BCPまで含むと、3,000万円〜1億円超となる可能性があります。
上記は、仕様と非機能要件から算出した推定で、Sanic専用の相場ではありません。
一般的な業務系相場は、小規模100万〜300万円、中規模300万〜800万円、大規模800万円〜数千万円です（出典: イー・ジーシステム「システム開発の費用相場と見積書の読み方」、2026年）。
特に、Sanicの非同期ワーカーや負荷試験、運用設計を厚くする案件では、同じ機能数でも上限側に寄ることがあります。
人月と工数で分ける費用の内訳と非同期処理の試験
見積もりは、人月単価に必要工数を掛けたうえで、クラウド、ライセンス、外部サービス、移行、保守などを加えて算出します（出典: SIA「受託開発の費用相場」、2026年7月更新）。工程ごとの配分も、見積もりを比べる材料になります。
- 要件整理・企画：10〜15%。
- 基本・詳細設計：15〜25%。
- 実装・単体テスト：30〜40%。
- 結合・総合・負荷試験：15〜20%。
- 移行・教育・リリース：5〜10%。
この配分は案件の難易度によって変わります。そのため、各割合を固定価格の根拠として使うことはできません。
削ってはいけない工数は、非同期処理の境界、DB接続プール、タイムアウトとリトライ、キュー詰まり、冪等性の検証です。
たとえば、試験を省いて実装費を安く見せると、外部API遅延や大量アクセス時に障害対応費が発生します。
見積書には、API本数だけでなく、負荷試験のシナリオ数、想定データ量、試験環境、再試験回数も記してもらいます。
初期費用と分けて見るランニングコストと保守範囲
保守を含む総額を比べるには、運用基盤と対応サービスの範囲を分けて見ます。
- 基盤：本番・検証環境のクラウド、DB、Redis、ストレージ、ログ保管、バックアップ。
- 運用サービス：監視、メール・SMS送信、ドメイン・証明書、脆弱性診断。
- 保守条件：問い合わせ、対応時間、作業時間、対象外作業。
24時間監視や障害時の即時対応、SLA、個人情報の監査ログを求めるほど、費用は増えます。
月額の総額に加えて、監視時間、対応時間、月間作業時間、対象外の作業も確認します。
保守を初期開発費の年10〜20%程度と仮に置く方法もあります。ただし、これは仮置きで、実際の契約金額を断定する数字ではありません。
バックアップは取得だけでなく、復旧確認の費用も見込みます。個人情報や機密情報を扱う場合は、暗号化やアクセスログも運用計画に含めます。
権限レビュー、退職者アカウントの停止、脆弱性対応、復旧訓練も必要です。そのうえで、保守やクラウド費が別紙になっていないかも確認します。
初期見積もりだけでなく、3年程度の総保有コストで比べると、判断を誤りにくくなります。
Sanicのシステム開発で見積もりを取る際のポイント
相見積もりでは、総額より同じ要件を同じ粒度で比べられるかを重視します。依頼書には、業務フロー、ユーザー、APIや画面、既存データ、外部連携を記します。
性能目標、セキュリティ条件、納期、納品物、保守の前提も記載します。要件が曖昧だと、各社の想定範囲が食い違い、金額だけで比べることになります。
要件定義書に入れる業務・性能・運用のチェック項目
業務範囲や性能の抜けは追加費用につながるため、発注前に前提をそろえます。
- 業務・機能：業務フロー、画面/API、データ、権限、受入条件。
- 連携・移行：外部連携、エラー時の業務、移行対象。
- 非同期処理：同期との境界、タイムアウト、リトライ、重複防止。
- 性能検証：キュー保持期間、p95・p99目標、負荷試験のデータ量。
個人情報や決済情報を扱う場合は、認証・認可、監査ログ、暗号化、秘密情報の管理も要件に含めます。
さらに、脆弱性診断、バックアップ、インシデント報告、データ削除、委託先の再委託も対象に含めます。IPA資料のSQLインジェクションやアクセス制御の観点を、チェックリストに入れます。
テスト仕様と対応結果は、納品物に含めてもらいます。「対応します」と書くなら、誰が何をいつ確認するかまで決めておくことが重要です。
複数社を比べるときに聞くSanicの実務経験
候補各社の経験を比べるには、本番での担当範囲と運用条件を確認します。
- 開発経験：本番利用範囲、バージョン、Python対応。
- 技術構成：非同期DBドライバーや他技術との分担。
- 運用経験：負荷試験、障害対応、保守の方法。
公開事例では、どの機能をSanicで作り、どの機能をDjangoやNode.jsへ分けたかを見ます。経験がはっきりしない場合は、PoCや技術レビューで確かめます。
たとえば、SunscrapersのVelvetは、モノリスと複数のマイクロサービスを組み合わせています。性能や独立したスケールが必要な部分にSanicやNode.jsを使い、最大1日1,000万リクエストを扱う構成です（出典: Sunscrapers「Velvet」導入事例、2026年確認）。
この事例は、性能要件のある境界にSanicを使う考え方を示しています。そのため、見積もりにもSanicの範囲と既存システムに残す範囲を明記してもらいます。
契約・納品・保守の責任範囲と見積書・契約書への記載
開発会社が替わっても保守を続けられるよう、納品物と管理責任を契約前に決めます。
- 設計・開発：ソース、要件、構成図、API仕様、DB定義。
- 検証・運用：環境手順、テスト、負荷試験、診断、移行・障害手順。
- 利用・権利：マニュアル、リポジトリ、OSS、CI/CD、クラウドの所有。
秘密情報の保管場所と、第三者ライブラリの更新責任も、あわせて決めておきます。
契約では、仕様変更、追加費用、受入基準、瑕疵対応期間、重大障害の対応時間を定めます。情報漏えいの報告や再委託、終了時の引き継ぎも記載します。
「一式」とまとめた見積もりでは、要件定義、試験、教育、保守の範囲が分かりません。そのため、工程別や納品物別に分けてもらいます。
2026年の見積もり解説でも、工程別の工数と保守費用を明確にすることの重要性が示されています（出典: イー・ジーシステム、2026年）。
Sanicのシステム開発でよくある質問
発注前に迷いやすい点を、技術の優劣に加えて、業務、性能、データ、運用体制の面から見ていきます。
Sanicで販売管理や顧客管理などの業務システムを作れますか？
作れます。ただし、Sanicは業務パッケージではなく、APIやバックエンドを作る技術です。
業務システムにするには、画面やDB、認証、帳票を組み合わせます。権限、データ移行、監視も必要です。そのため、必要に応じて既製サービスや別フレームワークと分担します。
SanicとFastAPIやDjangoはどのように使い分けますか？
高い同時接続や外部I/Oの並行処理を重視する場合は、Sanicが候補になります。APIの型定義やOpenAPI連携を重視する場合は、FastAPIと比べます。
管理画面や認証・管理機能をまとめたい場合は、Djangoと比べます。選ぶときは、性能要件、チームのPython経験、周辺機能、保守人材も含めて考えます。
このため、同じ業務シナリオをPoCで測ると、印象だけの比較を避けられます。
Sanicのシステム開発にはいくらかかりますか？
小規模PoCやAPIは100万〜300万円程度、中規模業務システムは500万〜1,500万円程度が目安です。
高負荷の連携基盤は1,000万〜3,000万円程度です。いずれも、Sanic専用の統計ではなく、業務機能、画面、連携、試験、移行、保守を含む推定レンジです。
要件や非機能条件で変わるため、複数社から工程別の見積もりを取ります。
開発会社へSanicの経験を確認するときは何を聞けばよいですか？
本番利用範囲、バージョン、Python対応を質問します。非同期DBやキュー、負荷試験、障害対応についても聞きます。コードレビューや設計書・ソースの納品実績も確かめます。
公開事例が少ない場合は、匿名化した業務のPoCで、タイムアウト、リトライ、冪等性、権限、ログ追跡を確認します。
Sanicを使わない場合の代替案も説明できる会社なら、技術を目的化していないかを判断しやすくなります。
まとめ
Sanicの開発では、業務課題と性能要件を先に整理し、そのうえで必要な範囲にSanicを適用します。6段階ごとに終了条件を置くと、機能追加や技術選定を事業成果に結びつけやすくなります。
着手前に確認する性能・データ・運用の観点
着手前には、同時接続数と目標応答時間、外部I/O待ち、DB・キュー構成、認証・認可を確認します。
監査ログ、バックアップ、RPO・RTO、データ移行、保守担当者も確認します。見積もりでは、試験、再実行、脆弱性対応、教育、クラウド費を分けて書いてもらいます。
Sanic 25.12 LTSとPython 3.10以上を前提にできるかも、既存環境で確認する項目です。
次の一歩は業務シナリオ1つを対象にしたPoCか要件整理
まずは、負荷が高い、または外部連携が複雑な業務シナリオを一つ選びます。全機能を一度に発注する前に、匿名化データを使ってPoCか要件整理を行います。実測性能、使いやすさ、障害時の復旧、見積もり内訳を確認してから、本開発へ進みます。この確認を経れば、Sanicを採用するかどうかにかかわらず、納得できる判断につながります。
▼全体ガイドの記事
・Sanicのシステム開発の完全ガイド
▼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を創業。