Bottleのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Bottleのシステム開発は、業務整理、発注先の選定、設計開発、テスト、移行、運用の順に進めると、現場で使い続けやすくなります。

各段階で決めることと発注側の確認点を、費用相場とあわせて説明します。全体像はBottleのシステム開発の完全ガイドでも扱っています。

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

Bottleのシステムの全体像

機能の範囲をつかむと、別途設計する運用要件も整理しやすくなります。

Bottleは、PythonでWeb画面やAPIを作る軽量なWSGIマイクロWebフレームワークです。

Bottleには、ルーティングやテンプレート、フォーム入力が備わっています。加えて、ファイルアップロードやCookie、JSONレスポンスにも対応しています。

一方で、認証や権限、監査ログは別途設計が必要です。データ移行やバックアップも、設計の対象として別に考える必要があります。

Bottleの特徴：軽量さと自由度

Bottleの軽さが活きる用途と、本番運用で追加する構成を分けて見ると、必要な準備の違いがつかみやすくなります。

配布と依存：単一ファイルで配布でき、標準外ライブラリへのハード依存はありません（出典：Bottle公式ドキュメント、2026年8月確認）。
活用先：既存Python処理のWeb化、社内申請、在庫照会、作業日報
連携：CSVの入出力と、外部サービスとの薄いAPI連携
試作：画面と処理を絞ると動くものを早く作れ、現場の意見も集めやすい
本番構成：開発環境と本番環境を分ける

業務用のDBには、PostgreSQLやMySQLなどを使います。そのうえで、ORMとSQLの扱いを決めておきます。

認証・認可とCSRF対策は、別途設計が必要です。さらに、ログや監視、バックアップの設計も加わり、障害復旧まで含めて考えます。

本番では、開発用サーバーを公開せず、GunicornなどのWSGIサーバーとリバースプロキシを組み合わせます。

向いている業務と慎重に判断したい業務

適性は、どう拡張していくか、必要な権限や処理、画面がどの規模かで比べます。

段階的な拡張：1部署の案件管理から始め、CSV連携や承認経路を追加
既存資産の活用：Python資産や外部APIを活かせる業務に向く
変更への備え：画面、業務ロジック、DBアクセスを分けておくと、将来FlaskやDjangoへ移行する選択肢が残る
慎重な比較：複雑な権限、組織横断マスタ、厳格な監査証跡が必要な場合
別案の検討：大量処理や標準管理画面にはDjangoや業務パッケージも比較し、独自APIだけBottleで補う方法もある

ポイント

Bottleは軽量ですが、認証や権限、監査ログは別途設計が必要です。小規模な社内業務や既存Python処理のWeb化に向く一方、複雑な権限が求められる業務では慎重な比較が要ります。

Bottleのシステム開発の進め方と6つのフェーズ

フレームワークは先に固定せず、業務の流れと受入条件をもとに決めていきます。

6つのフェーズを順に進めながら、試作画面は早めに現場へ見せ、認識の違いを修正していきます。

フェーズ1：業務と非機能要件の整理

業務の実態と運用条件をそろえて、仕様と受入基準に反映します。

業務フロー：入力者、入力する時点、承認者、出力する帳票やデータを記録
現状と例外：Excel、紙帳票、メール、既存CSVを集めます。手作業や重複、差し戻し、取消、締め後の修正も拾い出します。
非機能条件：利用者・同時アクセス数、稼働・応答時間、保存期間、バックアップ頻度、復旧目標、個人情報の有無
受入基準：対象業務と対象外、利用者・拠点・権限を定め、入力・検索・出力項目や外部連携、移行データ、障害時の業務継続、受入テストの合格条件も含めます。
作成する資料：業務フロー、機能一覧、非機能要件、データ項目表、優先順位表

フェーズ2：Bottleと発注先の選定

既存環境の引き継ぎ条件と、本番運用を担う発注先の対応力をそろえて比べます。

既存環境：Bottle・Pythonの版、依存物、WSGI、DBスキーマ、定期処理、秘密情報の管理
旧コード対応：Python 2が残る場合、Python 3対応とテスト追加を別タスクで見積もる
運用技術：認証・権限、DB、クラウド、監視、脆弱性対応の扱いを、同じ要件書で比べます。移行や保守についても、各社の対応をそろえて聞きます。
実績の確認：Python対応の公開情報だけでBottle対応と見なさず、既存コードを読んだ診断レポートを出せるかを尋ねます
選択肢と納品：Bottle継続とFlask・Django移行を要件で比べられるか、設計書とソースを納品できるか

フェーズ3：将来の変更に備えた設計開発

実装者によって構成が変わらないよう、変更や運用に備える設計項目をまとめておきます。

基本設計：画面遷移、API仕様、権限表、データモデル、外部連携、エラー表示
共通ルール：ディレクトリ、命名、ログ、例外、設定値、依存パッケージの固定方法を文書にまとめる
分離構成：画面・業務ロジック・データアクセスを分け、特定のテンプレートやDB接続に強く依存しないようにする
小規模の構成例：Bottle、PostgreSQLまたはMySQL、SQLAlchemyなどのDB層の組み合わせ
安全な公開：利用環境に応じた防御策を用意し、検証も行う

小規模の構成では、画面をHTMLとJavaScriptで作り、実行環境にはDockerやクラウドを使います。

外部に公開する場合は、TLSとWAFを加えます。さらに、リバースプロキシやレート制限、監視も組み合わせます。

社内だけで使う場合も、VPNや端末管理を確認します。また、本番ではdebug=Trueを無効にします。

テストでは、SQLインジェクションとCSRFの検証を行います。権限逸脱やファイルアップロードの検証も、テストに含めます。

処理どうしを疎結合にしておくと、将来の保守やフレームワーク移行を検討しやすくなります。

フェーズ4：業務シナリオと安全性のテスト

正常時と例外時の業務を流し、受入条件に照らして品質を判定します。

例外シナリオ：未入力、権限外アクセス、重複登録、締め後変更を含みます。通信切断、APIタイムアウト、不正CSV、同時更新も試します。
テスト記録：前提データ、操作、期待結果、実績、証跡、判定を仕様書に残す
受入操作：現場代表者が実データに近いサンプルで、主要業務を操作する
確認項目：権限別の表示、CSVの文字コード、帳票の合計、検索条件、操作ログ、バックアップの復元

画面が表示されるかどうかよりも、業務を最初から最後まで通せるかで評価します。

不具合が仕様変更として追加請求されないよう、要件書の範囲と、受入後に追加する改善を分けて管理します。

フェーズ5：稼働時の移行とロールバックの管理

稼働の前に、データ確認の進め方や切替体制、復旧条件を決めておきます。発注者側の確認作業も、担当を決めて割り当てます。

移行準備：対象データ、重複・欠損の扱い、変換ルール、リハーサルを決める
並行運用：旧システムとの期間を定め、マスタと履歴は発注者側でも確かめる
切替体制：日時、担当、問い合わせ窓口、初日の確認項目、旧運用へ戻す条件を文書で示す
情報保護：環境変数や秘密鍵をリポジトリに置かず、ログに個人情報を出さない

Bottle公式ドキュメントは、本番で開発用の設定やdebugモードに頼らない運用を案内しています（出典：Bottle公式チュートリアル・デプロイ解説、2026年8月確認）。

稼働の判定では、サーバーが起動したことだけでなく、主要業務と権限を確かめます。そのうえで、バックアップや監視、復旧手順も確認します。

フェーズ6：定着と利用率・保守性の向上

操作支援と利用状況の確認を組み合わせて、改善を続けられる運用にしていきます。

利用案内：業務別の短い手順、問い合わせ先、よくあるエラーの対処を用意
初期確認：最初の1〜2か月は、ログや入力ミス、差し戻し、手作業への逆戻りを見て、現場のつまずきを改善
権限管理：利用者を増やす前に権限を一覧にして見直し、不要なアカウントを止める
保守条件：障害対応の時間帯、初動の時間、復旧目標、軽微な改修の範囲を決める
定期対応：脆弱性への対応、Bottle・Pythonの更新、バックアップの確認、月次レポートを決めておく

IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版は、ランサムウェア、サプライチェーン、人材不足を踏まえています（出典：IPA、2026年）。

同ガイドラインは経営と実践の両面から対策を整理しています。担当者や教育、連絡体制も、運用要件に含めて考えます。

ポイント

フレームワークを先に固定せず、業務の流れと受入条件から決めることが出発点です。試作画面を現場に早く見せて認識違いを直しながら、6つのフェーズを順に進めます。

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

区分が大きくなるほど費用レンジも広がり、運用要件が見積もりに影響します。

Bottleのライセンス利用料は原則かかりません。ただし、初期費用が無料になるわけではありません。

費用の中心は、要件定義や設計、実装です。テストやデータ移行、インフラ構築も費用に含まれます。運用設計や教育も、費用の内訳に入ります。

Bottle専用の公開統計は確認できません。そこで、この目安は、リサーチノートと2026年公開の業務システム相場、Python人材単価をもとにしています。

規模別の初期費用の目安（50万〜3,000万円超）

公開相場をもとにした推定の幅です。Bottleを採用したからといって、必ず下限になるとは限りません。

試作・社内ツール：数画面、1部署、CSVか既存API、簡易認証なら50万〜150万円程度
小規模Webシステム：100万〜650万円程度です。顧客・案件・在庫のCRUD、複数権限、帳票、テスト、クラウド公開を含むと、上限に近づきます。
部署横断：承認、外部連携、データ移行、運用設計を含む場合は500万〜1,500万円程度
基幹・多拠点：可用性や監査を強く求める場合は、1,000万〜3,000万円超も視野に入ります（出典：2026年公開の業務システム開発相場資料、複数社）

比較資料では、小規模は50万〜300万円、中規模は300万〜1,500万円、大規模は1,000万〜3,000万円以上という整理もあります。

規模の区切りは、利用者の数や連携、データの量で変わります。運用要件も影響し、画面数はその一部にすぎません。

人件費、インフラ、保守の内訳

人月単価と月額インフラ費、保守範囲を分けて見ると、見積もりの前提を比べやすくなります。

人材単価：実務2〜3年は月55万〜70万円、3〜5年は月70万〜85万円、5年以上は月85万〜100万円程度（出典：フリコン、2026年前半の公開案件集計）
人月の例：2名が4か月稼働すると、おおよそ440万〜680万円
月額インフラ：コンピュート、DB、ストレージ、ログ、監視の費用がかかります。バックアップやWAF、ドメインも加わり、利用量で変わります。
保守範囲：問い合わせのみか、監視・脆弱性対応・軽微改修・定期更新まで含むか
年間保守の目安：初期開発費の10〜20%または15〜20%程度とする場合がある

人件費は、業務整理や設計、実装の作業に、テストとプロジェクト管理を加えた合計です。

公開されている人材単価は、請負見積の金額とは同じではありません。さらに、Bottle本体が無料でも、上流工程や品質管理には費用がかかります。

初期構築費と月額インフラ費は分けて確認し、保守費は契約範囲をもとに個別の見積もりで決めます。

ポイント

費用は規模と運用要件で大きく変わります。Bottleのライセンス料がかからなくても、作業費や月額インフラ費、保守費を分けて比べると、見積もりの前提がそろいます。

Bottleのシステム開発で見積もりを取るポイント

依頼時の範囲から納品後の受入まで、比較条件を一続きで確認できます。

金額だけで比べると、安い提案から重要な作業が抜けていることがあります。

各社の見積もりは、要件と成果物、検収条件をそろえて比べます。保守範囲も、同じ前提で示してもらいます。そのうえで、Bottleの利点と、追加ライブラリや運用に必要な作業を分けて確認します。

見積依頼書に書く業務、データ、受入条件

依頼書と納品条件を具体的にしておくと、各社が同じ範囲を見積もれます。

依頼条件：目的、部署、利用者数、画面、帳票を示します。権限、連携、移行、アクセス、セキュリティ、希望時期も含めます。
業務シナリオ：申請者が登録し、上長が差し戻し、再申請後に管理者が確定し、月次帳票を出す例
設計・テストの資料：要件定義書、画面・API仕様、DB設計、テスト仕様と結果
引き継ぎの資料：移行・運用手順、ソースコード、依存パッケージ一覧、環境構築手順
受入条件：主要シナリオ完了、重大不具合ゼロ、権限テスト合格、バックアップ復元確認

別の会社でも保守できる内容で納品されるかを見ると、文書の不足や属人化に気づけます。

会社選び：Bottle経験と業務対応力

開発経験と業務を支える力の両方を確かめ、導入後の選択肢も比べます。

技術対応：Bottle・Python 3、WSGI、DB、認証・認可の実務経験
運用対応：ログ・監視、クラウド、移行、テスト、保守SLA
実績と診断：Bottle実績が少なくても、Python Webや業務システムの実績、既存コード診断、移行判断を確認
構成案：Bottle継続、Flask・Django移行、SaaSやパッケージとの組み合わせを比べる
総コスト：3年程度の保守、追加開発、教育、障害復旧、採用難も含めて評価

初期費用が少し高くても、将来の移行余地を設計で残す提案には、合理的な理由がある場合があります。

安すぎる見積もりの作業の抜けと追加費用

「Bottleなので数十万円で完成する」と言われた場合は、認証や権限、テスト、移行が含まれているかを確かめます。

小さな試作でも、本番運用には追加費用が必要になる場合があります。そのため、抜けがないかを項目ごとに確かめます。

認証・権限：本番運用に必要な作業を含むか
テスト・移行：業務シナリオとデータ整備を含むか
基盤・監視：インフラ構築と障害検知を含むか
マニュアル・保守：納品後の支援範囲を区分しているか
見積条件：対象画面、工数、担当、成果物、前提、対象外が明記されているか

要件が変わったときの扱いは、事前に決めておきます。優先度の高い機能から短い単位で開発し、変更を受け付ける期間を区切ります。

追加見積のルールは、あらかじめ合意しておきます。移行データの件数や品質が未確認なら、先に調査を発注することもできます。

調査の結果をもとに本開発の見積もりを更新する進め方は、後半の大きな追加費用を抑えやすくなります。

ポイント

金額は、要件や成果物、検収条件をそろえてから比べます。特に安い見積もりでは、認証やテスト、移行、保守の有無が判断の分かれ目です。

Bottleのシステム開発でよくある質問

採用の可否や費用、保守について、発注前によく寄せられる質問に答えます。

適性は、業務量やデータ、利用者を確かめて判断します。セキュリティや将来の拡張も、あわせて確認します。

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

使えますが、その前提として、Bottle単体を開発用サーバーのまま公開しないことが必要です。

安全対策：認証・認可、入力検証、CSRF対策を設計します。DB保護、ログ、監視、バックアップも設計に含めます。
本番構成：WSGIサーバーとリバースプロキシを使い、業務に応じてテストする
検討しやすい用途：小規模な社内業務、API、既存Python処理のWeb化

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

Bottleのライセンス利用料は抑えられる可能性がありますが、総額が必ず安くなるとは限りません。

必要な工数：認証、権限、業務ロジック、DBの作業があります。テスト、移行、インフラ、保守も工数に含まれます。
小規模業務：構成を絞りやすく、費用を抑えられる場合がある
大規模要件：全社基幹や高い監査要件では、パッケージや別のフレームワークとの総保有コストを比べる

既存のBottleアプリは作り直すべきですか？

最初から作り直すかどうかは、現状診断を行って判断します。

判断材料をそろえたうえで、継続改修や分離、移行のどれが適切かを比べます。

実行環境：Python・Bottleの版、依存パッケージを調べる
品質とデータ：テストの有無、DB構造、脆弱性、障害履歴を確認
運用体制：認証方式と保守担当者を確かめる
改修・移行案：継続改修、段階的な分離、Flask・Django・FastAPIへの移行を比べる
刷新の進め方：画面から業務ロジックを切り離し、APIとDBの取り決めを整理しておくと、既存資産を活かしやすくなります

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

Bottle専門の会社でなくても構いません。Python Web開発や業務システムの実績、APIやクラウド運用の経験を見ます。

質問したいのは、既存コードの診断やPython 3対応、WSGIの本番化です。認証・権限、データ移行についても聞きます。

設計書とソースコードの納品の有無、保守SLAも確かめます。同じ要件書で、提案の範囲と対象外を比べます。

まとめ：要件と運用を中心にした進め方

業務フローと非機能要件をそろえたうえで、Bottle継続、他のフレームワーク、パッケージを比べます。

画面やAPI、DB、セキュリティを設計し、業務シナリオと安全性をテストします。

データ移行とロールバックを準備したうえで、教育と監視、保守まで整えて、現場に定着させます。

Bottleの軽さを判断材料にする前に、使う人と運用担当者が困らない仕組みを先に決めておきます。

費用は、試作・社内ミニツールの50万〜150万円程度から、部署横断の500万〜1,500万円程度まで幅があります。

基幹・多拠点では1,000万〜3,000万円超も視野に入ります。この金額は、Bottleの利用料ではなく、システム全体の目安です。

要件や品質、移行を含めた条件で、複数社から見積もりを取ります。インフラや保守も、同じ条件に含めます。

判断は、将来の保守と移行も含めて行います。

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

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