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

Bottleは、画面、API、データ処理をPythonで組み立てる軽量なフレームワークです。

業務に合うかどうかは、向いている業務の種類、要件に応じた開発手順、導入後の運用体制を分けて見ると判断しやすくなります。

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

Bottleのシステムの全体像

Bottleは、マイクロWebフレームワークで、業務システム製品ではありません。そのため、利用者管理や承認ルールなどは、開発の中で別途設計します。

Bottleの基本機能と構造

Bottle公式ドキュメントは、Bottleを高速でシンプル、軽量なWSGIマイクロWebフレームワークと説明しています。単一ファイルで配布でき、Python標準ライブラリ以外の強い依存関係を持たないのが特徴です。

2026年8月時点で、公式ドキュメントに掲載されている安定版は0.13.4系です。

Bottleは、0.13からは、保守されているPythonバージョンを中心に対応する方針に変わっています（出典: Bottle公式ドキュメント、2026年確認）。

ルーティング：URLとPython関数の結び付け。
テンプレートとリクエスト処理：HTMLの生成と、フォーム値やファイルの受け取り。
レスポンスと連携：Cookie、ヘッダー、JSON、静的ファイル、プラグイン、WSGIサーバーの扱い。

小さなアプリなら、少ないファイルで動かし始められます。また、既存のPython処理をWeb画面に置き換える場合も、扱いやすい構成です。

フレームワークと業務システムの違い

顧客管理や在庫管理などの業務機能は、Bottleを導入した時点では用意されていません。そのため、業務ルール、テーブル設計、権限は、開発の中で決める対象になります。さらに、帳票や通知の出し方、監査ログ、障害復旧も、利用する業務に合わせて決めます。

例えば在庫システムでは、商品登録と入庫、出庫が業務要件になります。また、棚卸や在庫数の確定、CSV入出力も業務要件になります。担当者ごとの権限と変更履歴は、誰がいつ操作できるかに関わるため、利用部門と設計者が定義します。

この違いを押さえておけば、「軽量だから数十万円で全機能を作れる」という誤解を避けられます。

Bottleで構築できるシステムの種類と適性

Bottleは、処理や画面を必要な分だけ組み合わせる設計に向いています。

小規模な業務のWeb化、Python資産の再利用、外部サービスとのAPI連携は、小さく始めやすい分野です。一方で、大規模な業務基盤では、追加の設計と保守体制を確認する必要があります。

Bottleと相性がよいシステム

社内の定型業務や既存資産を活かす業務では、最小機能から始められる点が役立ちます。具体的には、次のようなシステムが候補になります。

社内業務：申請・承認、作業日報、案件や顧客の照会。
データ業務：在庫・入出庫の登録、CSV集計、帳票表示。
連携機能：機器やIoTの操作API、複数サービスをつなぐ連携層。

Bottleは、最初から全社を対象にせず、1部署の定型作業を最小機能でWeb化する進め方と相性がよいです。そのうえで、利用者の反応を見ながら、権限や例外処理を増やしていけます。

既存のPythonスクリプトやバッチ処理があれば、そのロジックを活かして画面やAPIを追加できる可能性があります。

画面表示、データアクセス、業務ルールが一つのファイルに混在すると、後から変更しにくくなります。そのため、試作の段階から役割を分け、テストできる構造にしておくと、段階的に拡張しやすくなります。

慎重な判断が必要なシステム

基幹業務や高い可用性が必要な場合は、Bottleという理由だけで採用を決めず、設計の負担を見積もる必要があります。特に次のような要件があるシステムでは、ほかの方法との比較が欠かせません。

複雑な業務：複数拠点、複雑な会計や在庫評価、厳格な監査証跡。
高い処理・稼働要件：24時間の高可用性、大量データ分析、複雑なバックグラウンド処理。

Bottleで実現することは可能です。ただし、認証や権限、ORMの追加に加えて、管理画面やジョブ、非同期処理も設計する必要があります。監視などを含めると、設計の負担はさらに大きくなります。

要件によっては、DjangoやFastAPIも候補に入ります。既製パッケージやSaaS、複数のフレームワークを組み合わせる構成も、比較の対象です。

個人情報や取引情報を扱う場合は、権限の変更やログの保管期間を確認する必要があります。バックアップの復元や、障害時の連絡と復旧時間も、あわせて見ておきます。

ポイント

業務の規模や連携の多さで、Bottleが向くかは変わります。小規模な業務Webや既存Python資産の活用は候補になりやすく、基幹や高い可用性が求められる場合は、追加の設計負担を前提に比べます。

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

業務条件から移行まで、確認する内容が段階ごとに変わります。

Bottleの開発では、業務課題と非機能要件を整理してから、フレームワークや構成を選びます。

小さな試作でも、利用者数やデータ保持年数、外部連携を初期に確認すると、後半の作り直しを抑えられます。さらに、障害時の復旧も早い段階で見ておく必要があります。

要件定義・企画フェーズ

発注側と開発会社は、業務要件とシステムの品質条件を、担当者へのヒアリングと実データから整理します。

業務フロー：入力から承認、差し戻し、例外、締め処理までの流れを洗い出す。CSVやExcelとのやり取りも含める。
改善目標：「誰の作業を何分減らすか」「誤入力をどこで防ぐか」を言葉にする。
品質条件：利用者と拠点、同時アクセス数、処理速度を決める。バックアップ頻度、保管期間、復旧目標、個人情報の有無も決めておく。

画面から作り始めると、後から承認ルートや権限を足したときにデータ設計が変わり、見積もりと納期が膨らみがちです。

設計・開発フェーズ

小規模な構成では、BottleとPostgreSQLやMySQLなどのデータベースを組み合わせます。

必要に応じて、データアクセスライブラリやHTML/JavaScriptを使います。Docker、クラウド環境を使うこともあります。

既存のPython処理があれば、業務ロジック、DBアクセス、画面やAPIを分けて扱います。

最重要業務を一連の流れで動かす、縦切りの試作から始めます。
申請登録から承認、検索、履歴確認までを先に通し、現場で確かめてから帳票や検索条件を足します。
エラー表示、入力値の検証、権限外アクセスの拒否も、早い段階で押さえておきます。

ロジックを分けて作っておけば、将来ほかのフレームワークへ移行するときも、既存の資産を残しやすくなります。

テスト・データ移行・リリースフェーズ

テストは、単体と結合の段階から、業務を想定した総合、利用部門による受入へと進めます。正常系に加えて、必須項目の欠落や重複登録、権限のない操作も確かめます。さらに、同時更新や外部API停止、DB接続障害への対応も見ておきます。

移行では、既存のExcelやCSVの項目をどう対応させるかを決めます。重複の扱い、日付やコードの変換、過去履歴の保持範囲も、あらかじめ定めておきます。そのうえで、リハーサルで件数と合計値を照合してから、本番へ切り替えます。

設計書やテスト仕様書、操作手順を納品物に含めると、担当者が変わっても保守を続けやすくなります。ソースコードや依存パッケージ一覧、復旧手順も、受け取る範囲に含めておきます。

ポイント

業務要件と品質条件を先に決め、最重要業務の試作から現場の確認を重ねるのが基本です。移行の範囲は、早い段階で決めておくと判断がぶれにくくなります。

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

規模区分が上がるほど、費用レンジも大きく広がります。

Bottleはオープンソースのため、フレームワークの利用料は原則かかりません。開発費の中心は人件費で、要件定義、設計、実装を含めて考えます。テストと移行、インフラ設定、運用準備も、人件費の対象に含まれます。

2026年に公開された相場では、人月単価はスキルや地域によっておおむね60万〜200万円です。

規模別に見ると、小規模は100万〜300万円、中規模は500万〜1,000万円、大規模は1,000万円から数千万円以上とされています（出典: 2026年公開のシステム開発費用相場資料、2026年）。

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

規模別の初期費用と開発期間

次の目安は、公開相場とBottle案件の構成要素をもとにした推定です。この目安は、Bottleのライセンス価格ではなく、業務システム全体の費用です。

試作・社内ミニツール：50万〜150万円、1〜2か月。
小規模な業務Web：100万〜650万円、2〜5か月。
部署横断システム：500万〜1,500万円、6〜12か月。
基幹・多拠点システム：1,000万〜3,000万円超、1〜2年。

1部署の申請画面と数種類の帳票に加えて、簡易認証や既存DB連携までの範囲なら、試作から始めて50万〜150万円に収まる可能性があります。

複数部署の承認や個人情報の扱いを含めると、費用は100万〜650万円以上へ広がります。監査ログや移行、外部連携、障害監視が加わると、さらに対応範囲が増えます。

利用者数や画面数だけでなく、例外処理と運用責任の有無も、見積もりを左右します。

初期費用以外にかかるコスト

運用費は、クラウド環境の費用と保守対応の範囲に分けて確認します。

運用費の項目：サーバーとDB、ログと監視、バックアップ。ドメインやTLS証明書、脆弱性対応、問い合わせ、軽微な改修も含みます。
保守の範囲：障害対応、時間外連絡、定期更新、脆弱性診断、機能追加、データ修正のうち、契約に含まれる作業。

小規模なら、月額数万円から始められる場合があります。ただし、可用性や監視時間、データ量、バックアップ世代数が増えるほど、費用も上がります。

保守費用は、初期開発費の年10〜20%または年15〜20%程度を参考にする資料があります。ただし、契約範囲によって変わります。なお、Bottleの依存が少なくても、古いPythonや独自コードを安全に保つ作業は必要です。

ポイント

費用の中心は人件費で、規模や例外処理、運用責任の範囲によって大きく変わります。見積もりを比べるときは、初期費用と運用費、保守の範囲を同じ前提で並べて見ます。

パッケージ・SaaS・Bottle開発の選び方

既製品の標準機能に業務が合うなら、パッケージやSaaSを検討します。独自のルールや既存のPython資産を活かしたい場合は、Bottleを含む個別開発が候補になります。

比べるときは、初期費用だけでなく期間や月額料金も見ます。データの所有権やカスタマイズの範囲、乗り換えのしやすさも、あわせて確認します。

パッケージ・SaaSが向くケース

勤怠や経費、顧客管理、販売管理など、業務フローを標準化できる場合は、パッケージやSaaSの方が早く安定稼働しやすいです。

サービス側が更新、バックアップ、障害対応を担うため、社内に運用担当者を置きにくい場合にも適します。

独自の承認ルートや特殊な計算、細かな帳票を無理に合わせると、追加費用や運用上の妥協が増えます。既存機器との連携でも、同じことが起きがちです。また、契約終了時のデータ出力、公開API、利用者や権限の移行方法も確認します。

Flask・Django・FastAPIとの使い分け

必要な標準機能や開発体制に合わせて、各フレームワークを比べます。

Flask：Bottleと同じく小さく始めやすいWSGI系。拡張機能や採用情報を重視する場合に候補になります。
Django：認証、管理画面、ORM、フォームを一体で備え、業務Webを一式で作る場合に合います。
FastAPI：型ヒントを活かしたAPI開発や、非同期処理を含む構成を検討する際の選択肢です。

Bottleから移行しても、安全性や保守費用が必ず改善するとは限りません。

既存の業務ロジックとデータを活かせるなら、Bottleを保守しつつ、Pythonや依存関係を更新するほうが合理的な場合もあります。

移行時は、画面とAPI、DB、認証を一度に変えないようにします。機能単位で段階的に切り替えると、リスクを抑えられます。

ポイント

既製品で業務が回るなら、パッケージやSaaSを優先します。独自ルールや既存Python資産を活かす場合は、Bottleを含む個別開発を、同じ条件の選択肢と比べて判断します。

Bottleのシステム開発会社・ベンダーの選び方

Bottle専門をうたう公開情報は限られるため、「Bottleを使える」と書かれているかだけで決めないようにします。

まず、PythonでのWeb開発や既存アプリの引き継ぎ、DBと認証の扱いを確認します。本番運用、監視、データ移行まで扱えるかも見ておきます。

実績と技術力の確認方法

技術力と提案内容は、具体的な実績や確認項目をもとに判断します。

実績：業務Webの規模、利用者数、データ量、外部連携について質問。運用期間と担当範囲も含める。
既存Bottleの診断：BottleとPythonのバージョン、依存パッケージ、テスト、本番WSGI構成を確認できるかどうか。
提案の比較：Bottle継続、別フレームワーク、パッケージやSaaSを同じ要件で比べてもらう。
説明内容：費用、期間、保守性、セキュリティ、将来の採用難易度について、相手が説明できるか。

これらを説明できる相手であれば、長期的な判断をしやすくなります。

見積もり・契約・納品物のチェック

見積もりから受入まで、作業範囲と判断条件を書面で揃えておきます。「開発一式」とまとめられた見積もりでは、何が追加費用になるのかが見えにくくなります。

見積項目：要件定義や基本設計、画面/API、DB、認証・権限を分けて示す。テスト、移行、インフラ、教育、保守も、それぞれ別に書いてもらう。
前提資料：利用者数や画面数、帳票数、連携先を添える。データ移行件数や想定同時アクセスも、あわせて示す。
納品物：設計書、テスト仕様書、ソースコード、リポジトリを定義する。依存一覧、環境構築、バックアップ・復元手順、操作マニュアルも含める。
受入条件：権限テスト、ログ確認、バックアップ復元、障害連絡、未解決の不具合の扱い。
引き継ぎ：将来、別の担当者へ引き継げるかを、価格と同じ重さで評価する。

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

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

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

ポイント

Bottleを使えるかどうかより、本番運用の実績や既存コードの診断に答えられるかで判断します。見積もりは、作業範囲と納品物、受入条件を書面で揃えられるかで比べます。

Bottleの本番運用・セキュリティ・保守での注意点

開発用サーバーと本番向けの構成は分けて考えます。

Bottleの開発用サーバーは、インターネットへ公開してはいけません。

本番では、WSGI対応のアプリケーションサーバーやリバースプロキシを組み合わせます。あわせて、TLS、ネットワーク制御、監視も用意し、debugモードを無効にします。

Bottle公式のサンプルも、入力検証やデータベース保護などを追加する前提で説明されています。

認証・権限・ログ・バックアップ

開発会社と発注側は、利用者と扱う情報に応じて、ログイン後の操作管理から障害時の復旧までを設計します。

認証とアカウント：パスワード保護、Cookie属性、多要素認証の要否、退職者の停止。
操作権限：画面の表示を隠すだけでなく、APIやDBの操作単位でも権限を確認する。
ログとバックアップ：変更履歴、保存期間、閲覧権限、アラート、復元テスト。

管理者や承認者、入力担当、閲覧者などの役割を業務フローに対応させると、権限の漏れを見つけやすくなります。ログの中で個人情報をどう扱うかにも、注意が必要です。

情報セキュリティ対策ガイドライン第4.0版も、バックアップや安全なWeb運用を重視しています（出典: 独立行政法人情報処理推進機構、2026年3月公開）。

Python更新・脆弱性対応・移行計画

PyPIで確認できるBottle 0.13.4は、2025年6月15日に公開されています（出典: PyPIのBottleプロジェクトページ、2026年確認）。

古いBottleやPython 2系に依存する場合は、次の更新作業が必要です。

環境の更新：現行Pythonへの移行と依存パッケージの固定。
安全性の確認：脆弱性を洗い出し、テスト環境を組み直す。
動作確認：バージョン更新の前に、主要画面とAPIの回帰テストを用意する。

保守担当者が一人だけの状態は、Bottleの軽量さとは別のリスクです。そのため、コード構成や環境変数、DB接続は文書にまとめ、デプロイと障害時の切り戻しも含めて、少なくとも二人以上が確認できる状態にします。

将来移行する可能性があるなら、業務ロジックを分けておき、APIやデータモデルの変更履歴を残しておきます。

よくある質問

発注側は、業務の複雑さやセキュリティ要件、既存資産、保守体制を組み合わせて、Bottleの採用可否を判断します。

Bottleは本番の業務システムに使えますか？

使えます。ただし、開発用サーバーではなく、WSGIアプリケーションサーバーやリバースプロキシを含む構成が必要です。認証や入力検証、監視、バックアップも、あわせて組み込みます。

小規模な社内業務やAPI連携には適性があります。特に基幹システムでは、追加機能と運用体制を含めて比べる必要があります。

Bottleなら開発費を大幅に下げられますか？

フレームワークの利用料を抑えられる可能性はあります。ただし、開発費全体が自動的に安くなるわけではありません。要件定義や認証、権限、テストの工数は必要です。移行や監視、保守にかかる工数も残ります。

小さく始め、標準機能を絞り、既存データを整理して渡すと、不要な工数を減らせます。

既存のBottleシステムを別のフレームワークへ移行すべきですか？

古さを理由に移行を決める前に、まず、PythonとBottleのバージョンや依存関係、テストの状況を診断します。そのうえで、障害履歴や担当者、今後の機能要件も踏まえ、保守継続と段階移行の費用を比べます。

移行する場合は、業務ロジックとデータを分けたうえで、機能単位に切り替えると、全面刷新による停止のリスクを抑えられます。

開発会社やベンダーには何を質問すればよいですか？

実装経験だけでなく、既存コードの診断やPython 3への対応を聞きます。さらに、認証・権限やDB、本番WSGI運用について質問します。クラウド監視、バックアップ復元、データ移行も、あわせて聞いておきます。

ソースコードや設計書の納品範囲、保守時の対応時間も確認します。回答を提案書や見積書、契約書、受入条件に反映すると、認識の違いを防げます。

まとめ

Bottleは、Python標準ライブラリ以外の依存が少なく、画面やAPIを小さく作り始めやすいフレームワークです。

社内申請や作業日報、在庫照会などの社内業務に適するほか、CSV処理やPython資産のWeb化、外部連携でも活かせます。

Bottleを採用する判断基準

採用時は軽量さだけでなく、業務の独自性や既存のPython資産を見ます。あわせて、利用者数、認証・監査の水準、将来の保守担当者も確認します。

追加機能を設計できる体制で小さく始め、段階的に広げる場合に、Bottleの利点を活かしやすくなります。

発注前に準備するもの

発注側は、発注前の情報をまとめ、選択肢や費用を同じ前提で比べられる状態にします。

要件資料：業務フロー、画面一覧、利用者と権限、既存データ形式を整理する。外部連携、非機能要件、予算、希望時期も、あわせてまとめる。
費用の前提：要件定義から保守まで、認証・権限やDB、テスト、移行を含めて考える。インフラや監視も対象です。
比較資料：Bottle、Flask、Django、FastAPI、パッケージ、SaaSを同じ条件で比べる。適合性や保守性、見積前提、提案内容を確認する。
既存システム：バージョン、依存関係、テスト、セキュリティ、引き継ぎ可能性の診断。
新規開発：最小機能から段階的にリリースする計画づくり。

Bottleの利用料が無料でも、開発費は別途かかります。2026年時点の目安は、試作が50万〜150万円、小規模な業務Webが100万〜650万円です。

部署横断のシステムは500万〜1,500万円、基幹・多拠点のシステムは1,000万〜3,000万円超です。

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