Sanicのシステム開発の完全ガイド - ブログ

Sanicは、業務APIやリアルタイム連携、外部サービスの集約に分けて考え、要件と運用体制に合う範囲で使うと効果を活かせます。

作れるシステムの種類、他フレームワークとの使い分け、開発の進め方、費用の目安、セキュリティ、開発会社の選び方を、発注前に知っておきたい順に見ていきます。

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

Sanicの概要

APIの周囲に業務システムの各要素が並びます。

Sanicは、Pythonのasync/await構文を使って、外部APIやデータベースの待ち時間を扱えるフレームワーク兼Webサーバーです。公式ドキュメントでは、Python 3.10以上に対応した高速・スケーラブルなWebアプリケーション基盤と説明されています。一方で、画面、データ、認証、運用監視を単独で提供する業務パッケージではない点に注意が必要です。

非同期I/Oによる待ち時間の活用

非同期I/Oの効果は、待ち時間をどう活かすか、処理をどこに置くかによって変わります。

I/O待ち：応答を待つ間に、別のリクエストを進めやすい点
活用場面：大量通信、複数サービスからの情報収集、リアルタイム通知などの場面

ただし、同期型ライブラリや重いCPU処理はイベントループを止めてしまい、期待する性能が出ない場合があります。そのため、非同期ドライバー、接続プール、バックグラウンドワーカー、処理分割の設計が性能を左右します。

業務システムに必要な周辺コンポーネントとの組み合わせ

業務システムとして成り立たせるには、API以外の構成と採用条件も見ておく必要があります。

構成：APIと、画面、RDB、キャッシュ・キュー、認証、監視、実行環境の組み合わせ
業務機能：受発注や在庫のルールに加えて、帳票、権限、マスタ、移行、バックアップも含む範囲
採用判断：ピーク接続数、1件の処理で発生する外部I/O回数、許容応答時間の確認

既存のPython資産や社内の保守人材も踏まえて、Sanicを必要な部分に使うかを決めることが重要です。

Sanicで作れる業務システムの種類

用途ごとに、Sanicを使う範囲を考えられます。

Sanicは画面型の業務にも使えますが、利用者やサービスが同時に使うバックエンドに向いています。一方で、定型入力が中心の業務であれば、別の基盤や既製サービスのほうが開発と保守をより簡単に進められる場合もあります。

販売・顧客・予約などの業務API

業務APIの設計では、利用する業務の内容と、外部連携の応答を踏まえる必要があります。

業務API：販売、顧客、予約、在庫照会、勤怠申請を、ブラウザやアプリから使うAPI
在庫照会：商品マスタ、倉庫在庫、引当状況を集めて、画面向けに返す処理
安全な利用：認証・認可・入力検証・監査ログによる、部門や役割ごとの範囲の管理
外部連携：決済などの応答を画面と同期するか、キューで後処理するかの区分

特に、決済、配送、会計、通知、本人確認との連携では、タイムアウトや再試行が起きやすくなります。そのため、再試行の扱いはAPI設計の段階で決めておくことが大切です。

リアルタイム連携・IoT・データ集約基盤

データが集まるシステムでは、応答条件と処理の分担を決めておく必要があります。

データ収集：センサー、店舗端末、業務アプリから短時間にデータが集まり、接続とI/Oが増える点
処理分担：Sanicをゲートウェイ等に置き、重い集計やファイル生成は別ワーカーへ移す分担
要件判断：許容遅延を100ミリ秒か数秒か、欠損や通知の二重送信を許容するかの決定

まず計測値と業務ルールを定め、そのうえでSanicを使う範囲を決めます。

管理画面とバッチを含む業務システム

画面や定時処理を含む場合は、APIの範囲とジョブの扱いを分けて考えます。

管理画面：別フロントエンドからAPIを使い、マスタ、申請・承認、権限、エラー再処理を扱う画面
バッチ：集計、請求データ作成、ファイル取込をジョブ化し、実行履歴と再実行条件を持たせる方法
基盤の選択：複雑な帳票やワークフローでは別基盤も検討し、Sanicは性能が必要なAPIや連携に使う方針

このため、保守性と費用のバランスを取りやすい場合があります。

ポイント

業務APIか、リアルタイム連携か、管理画面とバッチを含むかによって、Sanicを使う範囲と、別基盤との組み合わせの要否が変わります。

Django・FastAPI・Flaskとの使い分け

技術面と運用面の観点をそろえて判断できます。

採用時は、処理速度に加えて、業務機能の量、チーム経験、拡張機能、運用体制を比べます。要件に合う設計思想を選ぶと、長期の費用も抑えやすくなります。

SanicとFastAPIの性能と周辺設計の比較

性能と開発後の運用を公平に比べるには、まず確認する観点を揃えておく必要があります。

比較軸：OpenAPI、入力検証、依存性管理、認証、DB、テスト性、本番経験の比較
実測条件：認証・DB・外部API・再試行を含む、実際のAPIに近い処理
評価指標：p95・p99、エラー率、CPU・メモリ、同時接続数の確認

管理機能が多い場合の別基盤との併用

業務機能の量と、分割後の運用負荷を踏まえて、基盤ごとの役割を決めます。

機能量：管理画面、認証、ORM、権限、フォームが多い場合の、別基盤の検討
Sanicの範囲：高速API、外部連携、イベント処理など、非同期性が価値になる部分
分割時の設計：データ整合性、認証共通化、再処理、相関IDの定義

技術を分けると、デプロイ、監視、脆弱性対応の対象も増えます。そのため、運用できる範囲に収める必要があります。

採用判断の4つの観点

Sanicを採用するかは、性能課題、必要機能、保守体制、投資対効果の4点で判断します。

性能課題：非同期I/Oで解決できるかの確認
必要機能：認証、データ連携、監視を実装できるかどうか
保守体制：社内か委託先で継続して保守できる体制
投資対効果：性能向上の効果と、設計・運用費の比較

ポイント

処理速度だけでなく、業務機能の量、チーム経験、拡張機能、運用体制を同じ条件で並べると、要件に合う設計思想を見極めやすくなります。

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

開発では、まず業務課題と非機能要件を整理し、そのあとで技術を決めます。要件定義でデータの鮮度、完了時期、再実行、重複防止を定めておかないと、後工程で手戻りの原因になります。

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

企画・要件定義での業務と性能の数値化

要件定義では、まず業務の流れを押さえ、そのうえで性能条件を具体的に書き起こします。

業務フロー：誰がいつどのデータを使い、何を完了とするかの整理
要件の詳細：機能名だけでは分からない画面・API数、権限、例外処理
性能条件：利用者数、ピーク時間、同時接続数、1日あたりの処理件数、応答時間、復旧目標の書面化
処理区分：注文確定は同期、数万件の帳票や外部データの一括取得はキュー処理にする例
完了条件：業務側との完了条件の合意

PoCでは、代表的なAPIを実データに近い条件で測定します。

設計・実装での責任範囲と失敗時の動き

設計・実装では、正常に動く場合に加えて、構成と失敗時の動きを定めておく必要があります。

構成設計：フロント、Sanic API、DB、キャッシュ、キュー、ワーカー、外部サービスの関係の図示
API設計：入出力、認証認可、タイムアウト、再試行、冪等性、ログ項目の定義
失敗時の設計・検証：遅延・無応答・重複への対応と、競合、接続上限、停止、滞留、部分失敗の検証

設計書、API仕様、データ定義、テスト仕様、運用手順を成果物に含めておくと、担当者が変わっても保守を続けやすくなります。特に、後任者が仕様や運用方法を確認できるよう、資料を納品対象に含めることが大切です。

テスト・移行・リリースでの本番条件の再現

本番移行までを見通し、テスト、リリース、データ移行を順番に計画します。

単体、API間の結合、画面を含む総合、負荷、障害復旧の各テストの区分
負荷試験で見る指標はp95・p99、エラー率、キュー滞留、DB接続数。止められない操作がある場合は、段階リリースや並行稼働を計画します。
移行時の名寄せ、欠損・重複、履歴範囲、リハーサル、ロールバック条件の決定
データ整備・仕様凍結の分担と期限、教育、問い合わせ窓口を含めた本番移行の設計

ポイント

要件定義で業務と性能条件を具体的に決め、設計・実装では失敗時の動きまで定めておくと、テストや移行での手戻りを減らせます。

Sanicのシステム開発費用相場

Sanicはオープンソースで、ライセンス購入費よりも開発作業のほうに費用がかかります。費用の多くは、業務整理や設計、実装、テストに発生します。加えて、クラウド、移行、保守にも費用がかかります。

以下の金額は、2026年の業務・Webシステム相場をもとにした、予算検討用の目安です。非同期APIや負荷試験を含めて考えていますが、Sanic専用の公的統計ではありません。

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

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

規模別の初期開発費と期間の目安

機能範囲を規模ごとに揃えると、初期費用と期間の目安を比べられます。

小規模PoC・API：5〜15本、単一DB、認証、簡易画面、連携1〜2本の規模。費用は100万〜300万円、期間は1〜3か月
中規模：API20〜60本、複数権限、業務機能の一部、帳票、移行を含む規模。費用は500万〜1,500万円、期間は4〜9か月
高負荷SaaS等：複数サービス、キュー、キャッシュ、監視、冗長化、負荷試験を含む規模
大規模連携：基幹等との広範な連携、移行、監査、BCPを含む規模。費用は3,000万円〜1億円超、期間は1〜3年となる場合があります

なお、同規模の案件の費用は1,000万〜3,000万円、期間は6〜12か月程度が目安です。また、民間調査の2026年版相場では、人月単価は60万〜200万円程度とされています（出典：「システム開発の費用・相場 2026年版」、2026年）。総額を比べるには、人月単価に加えて、要件の明確さ、再利用資産、品質保証、運用範囲も見ます。

費用の内訳とSanic特有の追加工数

見積もりでは、工程配分とあわせて、機能条件と非同期処理の工数も確かめます。

費用配分：要件定義10〜15%、設計15〜25%、実装等30〜40%、試験15〜20%、移行等5〜10%が目安
見積条件：画面・API数、権限、外部連携、例外処理、帳票、移行データの品質
Sanicの工数：非同期境界、同期ライブラリ回避、接続プール、タイムアウト、再試行、冪等性、キュー、ワーカー検証に関わる部分

「高速化」だけを目的にすると、過剰な構成になる可能性があります。そのため、何秒以内に何件処理できれば十分かを先に決めておきます。

クラウド・保守・更新の費用

初期開発後の支出は、初期費用とは別に、利用環境と保守契約を分けて見積もります。

クラウド費用：計算資源、DB、保存・通信、ログ、監視、バックアップ、診断の費用。初期費用とは別
月額の条件：自動拡張の最低料金、ログ保存期間、用意する環境数を含めた試算
保守費用：初期費用の年10〜20%程度を仮置きできますが、受付や障害・更新対応の範囲によって変わります

Sanic 25.12はLTSです。そのうえで、公式のリリース方針と依存パッケージを確認し、Pythonのサポート期限に合わせた更新計画を契約に含めます。

ポイント

費用は、規模ごとの目安、工程配分、クラウド・保守の月額を初期費用と分けて見積もると、提案ごとの比較の土台が揃います。単価だけで比べると、総額を読み違えやすい点にも注意が必要です。

セキュリティ・法令・運用の確認事項

Sanicを使えば、セキュリティ要件が自動で満たされるわけではありません。そのため、API入力、認証認可、DBの各面で脅威と対策を決めます。秘密情報、ログ、バックアップは、同じ考え方で扱います。運用担当者も対象に含めます。個人情報や機密情報を扱う場合は、フレームワークの設定にとどまらず、組織的・人的・物理的・技術的な安全管理も設計します。

APIの認証・認可・入力検証の設計

APIを守るには、利用者の確認と、送受信データの検証を分けて考える必要があります。

認証・認可：利用者・部署・役職・操作別の権限表の作成と、テナント分離・管理者操作の設計
認証情報：APIキーやトークンの期限、失効、保管、漏えい時の停止手順の定義
入力検証：型、桁数、形式、範囲、業務整合性の確認。エラーに内部情報は含めない

SQLインジェクション対策については、IPAがプレースホルダーとDB接続アカウントの最小権限を示しています（出典：IPA「安全なウェブサイトの作り方」、改訂第7版）。また、画面に出す値には、XSS対策として文脈に応じたエスケープと安全な出力設計が必要です。

個人情報の取扱いと漏えい対応の計画

個人データの安全管理では、取扱いの全段階と事故対応をあわせて考えます。

取扱い管理：取得から廃棄まで、責任者、アクセス権、保存場所・期間、委託先の整理
技術対策：通信・保存データの暗号化、アクセスログ、管理者監査、暗号化バックアップ
テスト・漏えい対応：テストデータの匿名化と、検知、遮断、調査の担当の決定

個人情報保護委員会の指針は、リスクに応じた適切な安全管理措置を示しています（出典：同委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年）。漏えいが起きた場合は、委託先への連絡に加えて、本人通知や関係機関への報告も担う人を決めておきます。

監視・バックアップ・障害復旧の試験

運用では、異常を見つけたあとに復旧できることまで確かめます。

監視：応答時間、エラー率、ワーカー、DB接続、キュー滞留、外部サービス失敗率の確認
通知・復旧：異常値、通知先、切り分け、エスカレーションの決定と、RPO・RTOおよび復元可否の確認
障害演習：切り替え、キュー再処理、重複防止、ロールバックの試行。更新は検証後に反映

Sanicのシステム開発で起きやすい失敗と対策

失敗は、フレームワークの性能そのものより、性能の測り方や業務設計の不足から起きます。たとえば、「速い」という印象だけで採用すると、DBや外部サービスがボトルネックになり、期待した効果が出ません。

単純なベンチマークだけで性能を判断する失敗

性能を判断するには、実際の処理を再現した試験と、原因の切り分けが必要です。

実業務に近い負荷：認証、DB、外部連携、権限、ログ、JSON変換を含めた、平常時とピーク時の測定
評価指標：平均に加えてp95・p99を見る。一部の利用者で待ち時間が長くなる場合があるためです
原因別対策：同期・CPU処理の確認、重い処理のワーカーへの移動、DBが原因の場合の接続プール等の改善

画像変換や大規模集計を専用ワーカーへ分けたあとは、キュー長と処理時間の監視が欠かせません。

Sanicだけで全機能を作ろうとして複雑化する失敗

Sanicの適用範囲とサービス間の境界を決めておくと、構成の複雑化を抑えやすくなります。

役割分担：画面、帳票、ワークフロー、マスタ、認証、移行、保守を一つの技術で解決しなくてよい点
基盤の併用：性能が必要な部分にSanicを置き、標準機能は既製サービス等に任せる形。負担を抑えられる場合がある
境界設計：データの正本、同期範囲、失敗イベントの戻し先、API仕様の管理者の決定

ただし、細かく分けすぎると監視やリリースが難しくなります。そのため、運用できる単位で分割することが大切です。

担当者交代や保守移管を想定しない失敗

担当者が変わっても調査や変更を続けられるよう、引き継ぎ方法と契約条件を整えておきます。

引き継ぎ資料：処理意図や再実行条件が分かる設計書、API、データ、環境手順、テスト、監視、障害事例の納品
契約・体制：権利、ライセンス、リポジトリ、引き継ぎ、脆弱性修正を確認。海外体制では保管場所なども対象

担当者の異動や退職のあとに処理の意図や再実行条件が分からないと、障害対応に時間がかかります。

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

会社を選ぶときは、Web開発やPython対応といった一般的な記載を見るだけでなく、Sanicの本番利用範囲、非同期処理のテストや負荷試験の担当、業務要件・移行・運用の責任範囲を確認します。公開実績が少ない場合も、実績があると推測せず、回答と証跡で比べます。

Sanicの経験と業務理解

技術実績に加えて、業務を理解し、運用設計まで担えるかを確認します。

技術経験：Sanic・Pythonの版、更新対応、非同期ドライバー、接続プール、ワーカー数の決め方
証跡：匿名化した構成図、負荷試験指標、再実行設計、コードレビュー体制
業務理解：業務ルール、権限、締め・例外処理を整理できるかの確認と、仕様責任者・意思決定経路の明確化

見積もりと開発体制の同条件での比較

提案を公平に比べるには、作業範囲、追加費用、体制の条件を揃えておく必要があります。

作業範囲：要件定義から保守まで、試験・診断・監視・復元・文書作成の有無
総額：安価に見えても別費用になる項目が多いと、実質総額が変わる
体制・契約：担当と稼働時期、再委託、窓口、レビュー、変更・遅延対応、問い合わせ時間の確認

RFPに書く性能・保守・権利の条件

提案依頼書では、性能目標と本番後の責任範囲を文書にします。

性能要件：ピーク接続、p95・p99、許容エラー率、DB、ワーカー、タイムアウトの記載
運用要件：再試行、冪等性、キュー、RPO・RTO、権限、監査、診断、復元試験を含める内容
保守・権利：更新、脆弱性対応、納品物、リポジトリ、引き継ぎに加え、採用しない場合の代替案の提示

最終的には、本番で安全に運用できる責任範囲を提案できるかで、会社を判断します。

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

ポイント

会社を選ぶ際は、Sanicの本番経験、テストと負荷試験の担当、運用と保守の責任範囲を、同じ条件の提案で比べることが目安になります。

Sanicのシステムに関するよくある質問

性能、画面、費用、保守の疑問は、技術面だけでなく、自社の業務条件に置き換えて考えると分かりやすくなります。

Sanicで管理画面付きの業務システムを作れますか？

作れます。SanicをAPI・バックエンドに置き、別のフロントエンドで管理画面を構築できます。ただし、帳票、権限、ワークフロー、バッチを含む場合は、周辺基盤と運用設計も含めて見積もります。

Sanicを使うと開発費用は安くなりますか？

Sanicはオープンソースですが、採用するだけで総額が下がるとは限りません。非同期設計、負荷試験、監視、運用人材にも費用がかかるためです。そのため、業務に合う範囲でSanicを使い、既製サービスや再利用部品を組み合わせると、投資対効果を高められます。

開発会社へ相談する前に何を用意すればよいですか？

業務フローと利用者・権限、画面やAPIを整理しておきます。既存データ、外部連携、ピーク利用状況も、あわせて書き出しておきます。希望時期と予算上限も伝えられるよう、準備しておきます。ただし、未確定の項目があっても、困っている業務と実現したい状態を伝えれば、要件定義の提案を受けられます。相談時には、Sanicの経験に加えて、負荷試験、セキュリティ、移行、保守の体制も確かめます。

Python 3.9の既存環境でもSanicを使えますか？

Sanic 25.12ではPython 3.9が対象外で、Python 3.10以上が必要です（出典：Sanic公式25.12リリースノート、2025年）。そのため、Python更新、依存パッケージの互換性、テスト環境、本番切り替えを含めて計画します。また、古い環境からの移行が難しい場合は、提案の段階で、Sanicのバージョンとサポート期間を確かめます。

まとめ

Sanicは、async/awaitによる非同期I/Oで高い同時接続を活かせるPythonのWebフレームワーク兼Webサーバーです。複数ワーカーで拡張できる点も特徴です。

販売・顧客・予約のAPI、リアルタイム連携、外部サービスの集約、キューを使うマイクロサービスで候補になります。

業務システムの成否は、採用する技術に加えて、計画全体の作り方で決まります。そのため、業務要件とデータ設計を土台に、認証認可、性能指標、テストを計画に組み込みます。移行と監視、バックアップ、保守も、同じ計画で扱います。

費用の起点は、小規模PoCで100万〜300万円、中規模で500万〜1,500万円、高負荷基盤で1,000万〜3,000万円程度です。実際の金額は、機能と非機能要件によって変わります。

Sanicの採用判断で見るべきポイント

まず、同時接続数とI/O待ちの比率を確認し、実際の業務シナリオで性能を測ります。そのうえで、Sanicと別基盤の担当範囲を分け、開発費に加えて運用、更新、復旧まで含めた総費用で判断します。

発注前に決めておくべき次の一歩

発注相談の前に、提案を比べるための材料を順番に揃えておきます。

業務フロー、利用者・権限、外部連携、ピーク利用、移行、希望時期、予算上限の一枚への整理
資料をもとにした、PoC範囲、性能合格条件、成果物、保守体制の複数社への同条件での確認
非同期設計、試験、セキュリティ、移行、障害対応、文書、引き継ぎの確認と、RFP条件をそろえた提案の比較

▼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を創業。