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

Bottleのシステム開発を発注・外注するなら、Bottle本体の利用料ではなく、要件定義、認証・権限、データ移行、本番運用まで含めた総額と保守体制で委託先を選ぶことが重要です。

「Bottleなら軽量だから安く作れるのではないか」「既存のBottleアプリを引き継げる会社が見つからない」と悩む担当者に向けて、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の費用相場、見積比較、受入れまでの進め方を解説します。Bottleのシステム開発の完全ガイドで全体像を確認したうえで、この記事では発注・外注・委託の実務に絞って整理します。

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

Bottleのシステム開発を外注する前に知っておきたい全体像

Bottleは、Pythonで動く高速・シンプル・軽量なWSGIマイクロWebフレームワークです。単一ファイルで配布でき、Python標準ライブラリ以外のハード依存がないことが公式ドキュメントで説明されています（出典: Bottle公式ドキュメント、2026年確認）。ただし、業務システムの完成品ではないため、画面、データベース、認証、権限、帳票、監視などは別途設計して組み合わせます。

Bottleはオープンソースソフトウェアのため、通常はフレームワークのライセンス利用料を予算の中心に置きません。費用が発生するのは、業務を聞き取って仕様にする作業、画面とデータベースの設計、プログラム実装、テスト、既存データの移行、クラウド環境の構築、公開後の問い合わせ対応です。Bottleを採用したからといって、認証や監査ログまで自動的に用意されるわけではありません。

たとえば、CSVを取り込んで在庫を検索する社内ツールと、顧客情報や請求情報を扱う多拠点システムでは、同じBottleでも必要な工数が大きく違います。前者は小さく始めやすい一方、後者ではアクセス権、操作履歴、バックアップ、障害復旧、個人情報の扱いまで要件に含める必要があります。

Bottleは、既存のPython処理をWeb画面にしたい案件、部署内の申請・承認や日報を管理したい案件、CSVや外部APIとの連携を薄く実装したい案件、小規模な管理画面や機器操作APIを作りたい案件に向いています。機能を絞って試作し、利用者の反応を見ながら拡張する進め方とも相性がよいです。

一方で、全社の基幹業務を一から統合する場合や、複雑な権限・承認・帳票・非同期処理を短期間で大量に実装する場合は、Django、FastAPI、既存パッケージ、SaaSなども比較します。Bottleを使うことを先に決めるのではなく、必要な機能と将来の保守担当を見たうえで技術選択を委託先と相談することが大切です。

発注形態はどの方法を選ぶべきですか？

発注形態は、完成後の機能が明確か、利用部門の協力を得られるか、発注者側にプロジェクト管理者がいるかで選びます。候補は、要件を固めて一括で依頼する請負型、作業時間と役割を合意して進める準委任型、まず小さな検証だけを依頼するPoC型の三つに整理できます。最初から一つに固定せず、要件定義だけ準委任で依頼し、その後に本開発の契約へ移る方法もあります。

請負型は、委託する範囲と完成物が比較的明確で、納品物を確認して受け入れる案件に向いています。たとえば、利用者、画面一覧、帳票、API、データ移行件数、テスト条件を確定したうえで、特定バージョンのBottleアプリを納品してもらうケースです。発注者は予算を立てやすくなりますが、契約後に要件を追加すると変更費用や納期延長が生じやすい点に注意します。

請負型で失敗しやすいのは、見積書に「システム一式」とだけ書かれている場合です。画面数、権限ロール、CSVのエラー処理、外部連携の異常時動作、ソースコードと設計書の有無を明記し、何をもって完成とするかを受入条件に落とし込みます。

準委任型は、発注者と開発会社が一定期間チームになり、調査、設計、実装、改善を順番に進める案件に適しています。現場で使って初めて分かる入力項目や承認ルールが多い場合、月単位または工程単位で優先順位を見直せます。既存Bottleアプリのコード調査、Python 3対応、依存パッケージの棚卸しなど、作業量が事前に読みにくい保守案件にも向きます。

ただし、準委任だから成果物が曖昧でよいわけではありません。毎月の稼働時間、担当者、定例会、成果物、レビュー方法、課題管理、終了時の引継ぎ条件を合意します。発注者側にも意思決定者を置き、確認が止まって開発期間だけが延びる状態を防ぎます。

PoC型では、いきなり本番システムを作らず、代表的な一画面、API連携、既存データの読み込み、認証方式などを小さく検証します。Bottleで実装を続けるべきか、FlaskやDjangoへ寄せるべきか、既存コードを修復して使えるかを判断する材料になります。検証期間と確認項目を限定し、PoCの成果物を本開発へ再利用できる構成にすることがポイントです。

PoCを安価な試作品として終わらせないために、検証結果、残課題、推奨構成、概算工数、運用上の注意を報告書に残します。本開発を同じ会社に発注しない可能性も含め、リポジトリ、設定、データ形式、手順書を受け取れる契約にしておくと比較の公平性を保てます。

RFPと要件整理はどこまで準備してから依頼しますか？

RFPは、開発会社に提案と見積を依頼するための資料です。完成した仕様書である必要はありませんが、背景、解決したい業務課題、対象利用者、必須機能、希望時期、予算の考え方、既存環境、セキュリティ条件、納品物を一枚の資料に集約すると、会社ごとの提案を比較しやすくなります。

最初に、業務の開始条件、担当者、入力情報、承認者、完了条件、後続処理を時系列で整理します。通常の流れだけでなく、差戻し、取消し、重複登録、期限切れ、担当者不在、CSVの不正値、外部APIの停止も書き出します。Bottleで画面を作る前に業務の例外を洗い出すと、後から追加する高額な改修を減らせます。

既存のExcel、CSV、紙帳票、メール通知、基幹システムとの二重入力も一覧化します。マスタの管理者、データの正本、保存年数、削除ルール、移行対象件数が決まっていないと、開発会社は安全側の工数を見積もるため、見積金額の幅が大きくなります。

機能要件には、ログイン、利用者・組織管理、権限、申請・承認、検索、登録・編集・削除、CSV入出力、帳票、通知、外部API連携を記載します。「管理画面が必要」と書くのではなく、誰が何を見られ、誰が変更でき、変更前の値を残すかまで定義すると、Bottleの追加ライブラリやデータ設計を適切に選べます。

非機能要件には、同時利用者数、応答時間の目標、稼働時間、バックアップ頻度、復旧目標、ログの保存期間、暗号化、脆弱性対応、監視、障害時の連絡先を記載します。IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」は、情報漏えいだけでなく事業活動の停止やサプライチェーンのリスクも重視しています（出典: IPA、2026年確認）。発注前に技術担当だけでなく、経営、法務、現場、情報システムの関係者を巻き込むことが重要です。

候補会社には、BottleのバージョンとPythonの対応方針、既存コードの調査方法、Bottleを継続する条件とFlask・Django・FastAPIへ移行する条件、データベース、認証・認可、クラウド、CI/CD、監視、脆弱性対応の経験を同じ形式で回答してもらいます。Bottle専門の公開実績が少ないため、Pythonの業務Web開発経験だけで判断せず、WSGIアプリの本番運用と引継ぎまで確認することが大切です。

提案書には、前提条件、対象外の範囲、発注者側の作業、工程ごとの成果物、体制、リスク、追加費用が発生する条件を含めてもらいます。質問への回答が具体的で、できないことや追加確認が必要なことも説明する会社ほど、実際のプロジェクトで認識齟齬が起きにくい傾向があります。

Bottleのシステム開発はどの順番で進めますか？

発注後は、要件定義、基本設計、実装、テスト、移行、リリース、保守の順に進めます。ただし、工程を一度きりで直線的に進めるのではなく、小さな画面やAPIを試作して利用者に確認し、要件へ戻る短い反復を入れると、Bottleの採用判断や業務ルールの漏れを早期に見つけられます。

要件定義では、業務フロー、画面一覧、権限マトリクス、データ項目、状態遷移、外部連携、非機能要件を確定します。設計では、Bottleのルーティングとテンプレートだけでなく、業務ロジック、DBアクセス、画面表示を分離し、将来の保守やフレームワーク移行に備えます。小規模なアプリでも、設定値や秘密情報をソースコードへ直接書かない方針を決めます。

既存アプリの外注では、いきなり機能追加へ入らず、Pythonのバージョン、Bottleのバージョン、依存パッケージ、実行方法、DBスキーマ、定期処理、外部サービス、ログ、テストの有無を調査します。調査結果を現状診断書にまとめ、再現できる開発環境と本番環境の差を確認してから見積を更新してもらいます。

実装中は、画面単位で進捗を確認するだけでなく、「担当者が申請し、上長が承認し、差戻し後に修正し、履歴を検索する」といった業務シナリオで確認します。入力値検証、認証・認可、同時更新、二重送信、CSVの文字コード、外部APIのタイムアウトなど、正常系以外のテストを早い段階から組み込みます。

テスト仕様書には、テスト項目、前提データ、操作、期待結果、実施結果、証跡の保存場所を定めます。受入テストを発注者だけの最後の確認にせず、開発会社の単体・結合・総合テストの後に、現場代表者が業務シナリオを確認する二段階にすると、リリース後の混乱を抑えられます。

データ移行では、元データの項目定義、重複や欠損の扱い、変換ルール、件数確認、移行リハーサル、切替時の凍結期間を決めます。発注者側の業務担当者がデータの正しさを確認し、開発会社が変換と検証を担当するなど、役割分担を明確にします。移行後に間違いが見つかった場合の戻し方も、リリース計画に含めます。

本番環境では、Bottleの開発用サーバーをそのまま外部公開しません。公式ドキュメントは、負荷が増える場合にGunicornやCherootなどのWSGIサーバーを使い、必要に応じてリバースプロキシなどを組み合わせる運用を案内しています（出典: Bottle公式Deployment、2026年確認）。監視、バックアップ、復元テスト、障害連絡、依存パッケージ更新、脆弱性対応の担当も保守契約に記載します。

契約形態と納品物は何を決めればよいですか？

契約書では、作業範囲だけでなく、成果物の権利、秘密保持、個人情報の取扱い、再委託、脆弱性が見つかった場合の対応、検収、瑕疵や不具合への対応、保守の範囲、契約終了時の引継ぎを確認します。法律上の契約判断は自社の法務または専門家へ相談し、開発会社のひな形をそのまま採用しないことが安全です。

最低限、要件定義書、画面・API一覧、データベース定義、権限一覧、構成図、環境構築手順、テスト仕様書と結果、データ移行手順、運用手順、障害対応手順、ソースコード、依存パッケージ一覧を納品物として明示します。Bottleのアプリは小さく始められる反面、設計がコードの中だけに残ると、担当者が退職したときや別会社へ保守を移すときに調査費用が膨らみます。

ソースコードを受け取るだけでは不十分です。リポジトリの履歴、ビルド方法、環境変数の一覧、テストデータ、デプロイ手順、クラウドアカウントの所有者、証明書やドメインの更新担当まで確認します。秘密鍵や本番パスワードは納品物へ平文で含めず、発注者が管理する保管場所と権限移管の手順を決めます。

保守費用には、問い合わせ対応、障害調査、軽微な修正、OSやPython・Bottle・依存パッケージの更新、脆弱性確認、バックアップ確認、監視、定例報告などが含まれます。すべてを一つの月額にまとめるのではなく、月次の定常作業と、追加見積が必要な機能改修を分けると、予算管理がしやすくなります。

障害の重要度ごとに、受付時間、一次回答、復旧目標、連絡手段、休日対応、再発防止報告の有無を合意します。個人情報や取引情報を扱う場合は、ログの確認権限、委託先の再委託、事故発生時の報告期限、データ返却・削除の条件も契約に含めることが重要です。

Bottleのシステム開発費用相場はいくらですか？

Bottleのシステム開発費は、試作・社内ミニツールなら50万〜150万円、小規模な業務Webなら100万〜650万円、部署横断のシステムなら500万〜1,500万円、基幹・多拠点システムなら1,000万〜3,000万円超が目安です。これはBottle専用の公的統計ではなく、2025〜2026年に公開された業務システム相場とPython人材単価をもとにした推定レンジで、要件、データ量、セキュリティ、開発体制で変わります。

50万〜150万円の試作・社内ミニツールは、1部署、数画面、簡易認証、CSV入出力、既存DBまたはAPIとの限定的な連携を想定したレンジです。100万〜650万円の小規模業務Webになると、顧客・案件・在庫などの登録と検索、ロール別権限、エラー処理、テスト、クラウド公開が加わります。複数部署をまたぐ500万〜1,500万円の案件では、複雑な承認、データ移行、外部連携、監査ログ、運用設計の比重が高くなります。

2026年の公開相場でも、単一業務のカスタムシステムは100万〜500万円、複数業務を統合する基幹システムは1,000万〜3,000万円以上という整理があります（出典: Cataly Design「業務システム開発の費用相場」、2026年確認）。Bottleを使うことで初期の実装を軽くできる可能性はありますが、認証、監査、データ移行、障害対応を削って価格だけを合わせるのは危険です。

公開されている2026年前半のPython案件では、実務2〜3年のWeb・自動化系が月55万〜70万円、3〜5年でWebアプリを扱う層が月70万〜85万円、5年以上でAI・データも扱う層が月85万〜100万円程度という目安があります（出典: フリコン公開案件集計、2026年前半）。これはフリーランス案件の月額指標であり、請負会社の見積金額そのものではありませんが、設計者、実装者、インフラ担当、テスト担当が必要になる理由を理解する補助材料になります。

見積は「エンジニア一人分の月額」だけで判断せず、要件定義、UI・DB設計、開発、コードレビュー、テスト、プロジェクト管理、移行、リリース、保守準備の工数に分けてもらいます。2名が4か月関わるのか、3名が6か月関わるのかで総額は変わり、Bottleの利用料が無料でも上流と品質保証の費用は必要です。

公開後は、クラウドのコンピュート、データベース、ストレージ、通信、ログ・監視、バックアップ、メール送信などの利用料が発生します。利用者数やデータ量、可用性、バックアップ世代数で変わるため、開発会社には想定条件と月額の計算根拠を示してもらいます。クラウド費用を最安値で固定するのではなく、増加条件と上限監視も決めます。

保守費用は、問い合わせ、障害対応、依存パッケージ更新、脆弱性確認、軽微な修正、監視、定例報告のどこまでを含むかで変わります。一般的な業務システムの保守は初期開発費の年間10〜20%または15〜20%程度とされることがありますが、これは契約内容による目安であり、Bottle案件に自動適用できる固定率ではありません。見積では月額の内訳と、機能追加が別料金になる条件を確認します。

委託先の選び方と見積比較のポイントは何ですか？

委託先は、会社名や価格の安さではなく、BottleまたはPythonの実績、業務理解、上流工程、セキュリティ、クラウド運用、データ移行、引継ぎの七つの軸で比較します。Bottleの公開実績を明確に掲げる会社が多くないため、「Bottle専門」と断定せず、既存アプリのコード診断と本番運用をどのように進めるかを聞くことが重要です。

実績確認では、PythonやBottleの文字が掲載されているかだけでなく、社内申請、案件管理、在庫、受発注、顧客管理など自社に近い業務を扱ったかを聞きます。公開できない案件でも、匿名化した画面、開発体制、利用者数、データ移行の有無、リリース後の保守方法を説明できる会社なら、実務能力を判断しやすくなります。

既存Bottleアプリを外注する場合は、古いPythonや依存パッケージを安全に更新できるか、テストがないコードをどう調査するか、障害時に誰がログを確認するかを確認します。新規開発の場合は、Bottleを継続する条件だけでなく、将来Flask・Django・FastAPIへ移行しやすい設計や、移行しない方がよい条件も提案できる会社を選びます。

見積比較では、要件定義、設計、実装、テスト、移行、インフラ、保守準備の項目が各社に含まれているかをそろえます。一社だけ安い場合、テスト、セキュリティ、データ移行、管理画面、操作説明、リリース支援が対象外になっていないかを確認します。反対に高い提案でも、将来の運用や変更に必要な設計が含まれていれば、総保有コストでは合理的な場合があります。

各社に「必須」「できれば」「将来」の三段階で機能を分けて提案してもらうと、初期リリースの範囲を調整できます。追加機能の単価、変更管理の方法、仕様変更の承認者、納期に影響する条件も確認し、比較表の各行を同じ定義で埋めます。営業担当だけでなく、実際に設計と保守を担当するメンバーが打ち合わせに参加するかも大切な判断材料です。

発注前に、Bottleのバージョンが古い、テストコードがない、DBの所有者が不明、秘密情報がコードへ残っている、開発用サーバーを本番で使っている、担当者が一人しかいないといったリスクを洗い出します。リスクがある場合は、開発費に含める改善と、運用開始後に段階対応する改善を分けて計画します。

発注者側の作業も見積に影響します。現場ヒアリングへの参加、データの提供とクレンジング、権限者の決定、テストユーザーの確保、受入れ、社内教育、リリース告知、問い合わせ窓口の設置を誰が担当するかを明記します。発注者側の確認が遅れると、外注費だけでなく利用開始時期も後ろへずれるためです。

受入れとセキュリティのチェックは何をしますか？

受入れは、見た目の確認だけでなく、業務が安全に続けられるかを確認する工程です。受入条件として、必須機能、権限、入力値検証、エラー表示、処理速度、同時利用、ログ、バックアップ、復元、データ移行件数、手順書、教育、未解決不具合の扱いを定め、証跡を残します。

認証では、パスワード方針、多要素認証の要否、セッションの有効期限、退職者アカウントの停止を決めます。権限では、部署・役職・拠点ごとに閲覧、登録、承認、削除を分け、管理者権限を必要最小限にします。監査ログでは、誰がいつ何を見たか、何を変更したか、変更前後の値をどこまで残すかを業務要件として定義します。

本番環境では、debugモードを無効にし、TLS、入力値検証、CSRF対策、SQLインジェクション対策、Cookie属性、レート制限、秘密情報の環境分離を確認します。ログを保存するだけでなく、異常を誰が確認し、何分以内に連絡し、どのバックアップから復旧するかまで決めます。セキュリティ対策はBottleに任せるものではなく、アプリ、インフラ、運用体制を含めた委託範囲です。

開発会社が保守を続ける場合でも、第三者が理解できる資料を受け取ります。ソースコード、依存関係、環境構築、デプロイ、DBバックアップ、復元、監視、障害対応、定期更新の手順を実際に実行してもらい、発注者側が確認します。手順書が存在するだけでなく、別の担当者が再現できることが重要です。

既存Bottleアプリを外注する場合は、引継ぎ前後の責任分界を明確にします。保守開始日、未修正の既知不具合、緊急対応の窓口、ソースコードの更新場所、クラウドアカウントの管理者、ライセンス、外部サービスの契約者を一覧にします。これにより、担当会社が変わってもシステムを止めずに運用しやすくなります。

よくある質問（FAQ）

Bottleのシステム開発を発注する際に寄せられやすい疑問へ回答します。フレームワークの採用判断と、外注先・費用・保守の判断を混同しないことがポイントです。

数画面の試作や限定的な社内ツールであれば、50万〜150万円程度のレンジに収まる可能性があります。ただし、認証、複数権限、帳票、データ移行、監査ログ、外部連携、保守を含めると、100万〜650万円以上の小規模業務Webの相場を参考にする必要があります。金額は要件と契約範囲で変わるため、Bottleの利用料が無料という理由だけで総額を断定できません。

必ず移行してから発注する必要はありません。既存資産が小さく、業務要件も単純で、保守できる会社が見つかるならBottleを継続する選択肢があります。一方、認証・管理画面・複雑なデータモデル・非同期処理などが増える場合は、Flask、Django、FastAPIを含めた比較検証を先に行い、移行費用と移行しない場合の保守費用を並べて判断します。

引き継げますが、最初に現状診断を依頼することをおすすめします。PythonとBottleのバージョン、依存パッケージ、DB、実行環境、外部連携、テスト、ログ、バックアップ、既知の不具合を調査し、保守開始後の優先順位を整理します。コードだけでなく、リポジトリ、環境構築手順、アカウントの所有権、データ移行履歴もそろえると、引継ぎの見積精度が上がります。

依頼できますが、RFPがない場合は、ヒアリングや要件定義にかかる費用と期間を別途見積してもらうと安全です。業務の背景、現場の困りごと、対象利用者、既存データ、希望時期だけでも整理して渡すと、提案の前提がそろいます。最終的な見積を比較する段階では、機能、非機能、納品物、発注者側の作業、対象外の範囲を文書化します。

まとめ

Bottleのシステム開発を発注・外注するときは、Bottleを使うこと自体を目的にせず、解決したい業務課題、利用者、データ、権限、性能、バックアップ、保守体制から要件を整理します。発注形態は、完成物を固めやすい請負型、要件変化や保守引継ぎに向く準委任型、技術選択を確かめるPoC型を使い分けます。

発注前は、業務フローと例外処理、必須機能、非機能要件、受入条件、納品物、発注者側の作業をRFPへまとめます。Bottleのバージョン、Pythonの対応方針、保守担当、データ移行、クラウドと監視の責任分界まで候補会社へ同じ条件で質問すると、見積の前提を比較しやすくなります。

委託先を選ぶときは、提案時の印象だけでなく、設計書・テスト仕様書・ソースコード・依存関係一覧・運用手順を残せるかを確認します。将来の機能追加や別会社への保守移管まで見据え、業務を止めずに改善できる体制を持つ会社へ相談することが、Bottleの軽量さを長期的な価値につなげる方法です。

費用は、試作・社内ミニツールで50万〜150万円、小規模業務Webで100万〜650万円、部署横断で500万〜1,500万円、基幹・多拠点で1,000万〜3,000万円超が参考レンジです。これらは公開相場とPython人材単価からの推定であり、要件定義、セキュリティ、移行、テスト、運用を含む範囲をそろえて比較する必要があります。

候補会社には、BottleやPythonの実績だけでなく、既存コードの診断、本番WSGI運用、認証・権限、監査ログ、バックアップ復元、依存パッケージ更新、ソースコードと設計書の納品、保守移管の方法を確認します。RFPと受入条件を具体化してから複数社へ依頼し、最安値ではなく、業務を止めずに運用できる提案を選ぶことが、発注後の追加費用と属人化を抑える近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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