既存プログラムのWeb化開発｜計算・分析ツールを残して画面・権限・照合を足す範囲と費用

既存の計算・分析プログラムをWeb化するときは、正しく動いている計算を書き直さずにそのまま残し、周りに入力チェック・画面・権限・実行の管理・結果の保存を足すのが基本です。費用は、既にあるWebシステムに呼び出しを足すだけなら小規模な既存改修（30万円〜・税別）、使えるかを先に試すならPoC（300万円〜・税別。本番システムの完成価格ではありません）、社外公開や管理画面まで作るなら本開発（個別見積）に当たる可能性が高くなります。そして、「元のプログラムと同じ結果が出るか」の確認を開発範囲に入れておくことが大切です。架空の計算プログラムで試したところ、一般的な乱数のテストでは見つからない1円のずれが、端数を狙ったテストで見つかりました（後述）。

この記事は、Python・Excel/VBA・社内ツールなどで作った計算や分析の処理を持っていて、「動くけれど実行できる人が限られている。他部署や顧客がブラウザから使えるようにしたい」と考えている事業責任者・分析部門の責任者に向けた内容です。

この進め方が合う場合・合わない場合

出典：Streamlit公式サイト

「計算は残して周りを作る」進め方がすべての会社に合うわけではありません。まず自社が下の表のどの状況に近いかを確かめてください。

状況	この記事の進め方	別の選択肢
計算結果は業務で使われていて、正しさに大きな不安はない	合う。計算は残し、入口と運用を足す	—
使う人が社内の数人で、権限や操作記録も要らない	合わないことが多い	自社で（AIを使いながら）簡易な画面を作る、共有フォルダとExcelのまま運用する
計算そのものを大きく変える予定がある、または今の結果に誤りの疑いがある	先に計算の仕様を決め直す必要がある	計算仕様の整理から始める（Web化はその後）
手作業のExcel業務全体を置き換えたい（計算は一部にすぎない）	一部だけ合う	Excel業務をシステム化するときの判断
計算プログラムを元に新しいサービスを小さく始めたい	一部合う	MVP開発の費用と進め方
既にWebシステムがあり、そこへ計算を呼び出す機能を足したい	合う（小規模な改修で済む可能性）	システムの小規模改修の費用

社内の少人数で使うだけなら、自作の簡易公開で足りることもあります。たとえば Python 製の画面を手軽に公開できる Streamlit Community Cloud は、2026年10月時点の公式説明では、公開・非公開の設定を GitHub のリポジトリから引き継ぎます。非公開アプリは同時に1つまでで、見られるのは開発者と招待した人だけです（Streamlit 公式ドキュメント）。社外の顧客に使わせる、会社ごとに見える結果を分ける、操作を記録する、といった要件が出てきた段階で、開発として考えるのが現実的です。

Web化の4つの方式と選び方

計算プログラムの前にWebの受付口を作るPythonの仕組みFastAPIのロゴ

出典：FastAPI（GitHub公式リポジトリ）

「Web化」には大きく4つのやり方があります。どれを選ぶかで、費用も、結果がずれる危険も変わります。

方式	中身	合う状況	注意点
そのまま包む	計算プログラムには手を入れず、ブラウザからの受付口と画面を前に置く	計算が正しく動いていて、当面変える予定がない	元のプログラムが動く環境（言語・部品）をサーバー側に用意する必要がある
画面を転送する	Windowsアプリなどの画面を、改修せずにブラウザへ配信する製品を使う	社内の決まった人が、今と同じ操作をリモートで続けたい	顧客に入力させる・結果をダウンロードさせる用途には向きにくい
一部を移す・作り直す	計算を別の言語で書き直し、サーバーや画面上で動かす	元の環境が古くて動かせない、計算を大きく変える	丸め方・小数の扱いで結果がずれる。照合の手間が最も大きい
自作・既製の道具で足りる	簡易な画面を自作する、共有スプレッドシートを使う	社内の少人数、権限や記録が不要	公開範囲・権限の管理が弱くなりやすい

選ぶときに見るのは次の5点です。

計算を今後変える予定があるか（変えないなら「包む」が第一候補）
使う人が社外か社内か（社外なら権限・入力チェック・記録が必須）
1回の計算にかかる時間（数分を超えるなら「待たせない仕組み」が必要。後述）
同時に使う人数（現状の処理時間を測ってから決める）
元のプログラムが動く環境をサーバーに置けるか（置けないなら移植を検討）

計算は残し、周りに足すもの

「そのまま包む」場合でも、Web化で新しく作る部分はかなりあります。社内の担当者が手元で実行していたときは、正しい値を入れること、結果を自分で保存すること、失敗したらやり直すことを人が引き受けていたからです。

部分	残すもの・足すもの	発注側が決めること
計算そのもの	残す（変えない）	正しい計算の仕様と、それを承認する人
入力画面と入力チェック	足す	受け付ける値の範囲、単位、桁数、必須項目
実行の管理	足す（受付・順番待ち・再実行・失敗時の扱い）	何分までなら画面で待たせるか、失敗時に誰へ知らせるか
結果の表示・ダウンロード	足す	見せる項目、出力形式（CSV・PDF・Excel）、保存期間
ログインと権限	足す	誰が何を見られるか（会社ごと・部署ごと）
操作の記録	足す	誰がいつ何を入力し、どの結果を出したかをどこまで残すか
管理画面	必要なら足す	利用者の追加・停止、設定値の変更を誰が行うか
他システムとの連携	必要なら足す	入力や結果をCSVやAPIで他のシステムと受け渡すか（CSV連携の開発）

依頼前に確認しておく7項目

開発会社に相談する前に、次のことを社内で確認しておくと、見積の前提がぶれにくくなります。分からない項目は「不明」のままで構いません。

確認項目	記入例（説明用）
今の実行方法	分析担当1名のPCで、毎回コマンドを打って実行
入力と出力	入力：顧客から受け取るCSV。出力：集計表のExcel
使っている部品（ライブラリ）	Python と表計算・数値計算の部品数種類。版は不明
部品やコードの権利	社内で作成。外部から取り込んだ部品のライセンスは未確認
1回の処理時間	通常3分、大きいファイルで20分程度（担当者の体感。未計測）
同時に使う人数の見込み	最初は社内10名、将来は顧客企業20社
計算の責任者	計算式を決めたのは前任者（退職）。現在の承認者は未定

最後の「計算の責任者」は、空欄のまま見積に進んでしまうこともあります。ここが決まっていないと、後の照合で「どちらの結果が正しいか」を誰も判断できなくなります。

時間のかかる計算は「受付・待機・完了・失敗」を決める

出典：Google Cloud公式サイト

数分以上かかる計算を、利用者がボタンを押してから画面の前で待ち続ける作りにすると、使いにくいうえにクラウドの時間上限にもかかります。2026年10月時点の公式仕様では、Google Cloud Run の1回の要求は既定5分・最大60分で打ち切られます。Google Cloud は、15分を超える場合は接続が切れたときのやり直しに備え、同じ依頼を二重に処理しない作りか途中から再開できる作りにするよう推奨しています（Google Cloud）。AWS Lambda も、通常の関数の実行時間の上限は15分です（AWS）。Python で Web の受付口を作る仕組みの一つである FastAPI の公式説明でも、重い計算には、作業の順番待ちの列を持ち複数のサーバーで動かせる専用のツール（Celery など）が向く場合があるとしています（FastAPI）。

そのため、時間のかかる計算では、次の4つの状態を画面と運用の両方で決めます。

状態	利用者に見せるもの	決めること
受付	受付番号、入力内容の控え	同じ依頼を二重に送ったときに二重計算しないか
待機・実行中	順番や進み具合	待ち時間の目安を出すか（出すなら実測してから）
完了	結果画面、ダウンロード、通知	画面で知らせるか、メールでも知らせるか
失敗	失敗の理由、やり直しの方法	自動で再実行するか、担当者が確認するか。誰に知らせるか

「同時に何人まで使えるか」は、実際のデータで処理時間を測ってからでないと言えません。依頼の段階では「小さい・普通・最大のデータでそれぞれ何分かかるか」と「想定する同時利用人数」を伝え、開発の中で実測して決める進め方が確実です。

結果を顧客にダウンロードさせる場合に決めること

分析結果を顧客に返している会社では、分析そのものより「ファイルを受け取る」「結果を送る」手間が負担になっていることがあります。顧客がWebから入力して結果を取りに来る形にする場合、次の表の項目が開発範囲に入ります。

項目	決めること
公開範囲	顧客企業ごとに、自社の結果だけが見えるようにする。担当者の追加・削除を誰が行うか
保存期間と削除	入力ファイルと結果を何日残すか。期限後に自動で消すか
再実行	同じ入力でやり直せるか。計算式を変えた後、過去の結果をどう扱うか（どの版の計算で出した結果かを残す）
出力形式	CSV・Excel・PDFのどれか。顧客ごとに形式を変えるか
結果の注記	結果の前提や使い方の注意を、どこに表示するか

金融や医療の助言・診断に当たるような結果を出す場合は、表示の仕方や責任範囲について、Web化とは別の専門的な確認が必要になります。

架空の計算プログラムで試した結果

ここからは、記事のために用意した架空の計算プログラム（実案件のコード・データではありません）で、2026年10月8日に実際に試した結果です。

題材は「単価×数量。数量100以上で5%引き、500以上で10%引き。税10%を加え、円未満は四捨五入（0.5円は0から遠い側へ。ExcelのROUND関数と同じ）」という見積計算です。これを「正しく動いている既存プログラム」とみなし、Web化の方式による違いを比べました。

#	試したこと	結果
a	元のプログラムを一切変えずに、Webの受付口から呼び出せるようにした。乱数で作った通常の入力300件と、割引の切り替わる数量（99・100・101・499・500・501）の境目48件で、直接実行した結果と比べた	348件すべて一致
b	同じ計算を Python の標準の丸め（`round()`）と通常の小数で書き直した	上の348件ではずれ0件。しかし、単価0.01〜1,000.00円（1銭刻み）×数量11種類の110万通りから、税込金額の端数がちょうど0.5円になる8,365件を抜き出して試すと、1,768件で1円ずれた
c	同じ計算を画面側で動かす想定で JavaScript（`Math.round`）で書き直した	プラスの金額では上の8,365件でもずれ0件。返品・値引きを想定してマイナスの金額で0.5円ちょうどになる3件を試すと、3件とも1円ずれた
d	入力チェックの有無で比べた。異常な入力8種類（単価がマイナス、単価が文字、数量0、数量が文字、単価が小数3桁、単価なし、単価10億円×数量10万、数量に真偽値）を送った	チェックなし：3種類はサーバーのエラー、残り5種類はエラーにならず金額を返した（単価-100円→-1,100円、数量0→0円、単価100.123円→1,101円、10億円×10万→99兆円、数量に真偽値→110円）。チェックあり：8種類すべてを理由付きで入力エラーとして返した

ずれた例を2つ挙げます（架空データ）。

入力	元のプログラム	書き直した版	書き直しの方式
単価1.50円×10個	17円	16円	Python の標準の丸め
単価-1.50円×10個	-17円	-16円	JavaScript の Math.round

ずれの原因は言語ごとの丸め方の違いです。公式の説明でも、Python の round() はちょうど中間の値を偶数側へ丸め（Python 公式）、JavaScript の Math.round は0.5をプラス方向へ丸める（MDN）と書かれています。一方、Excel の ROUND は0から遠い側へ丸めます（Microsoft）。

この結果から言えるのは次の3点です。合成した1種類の計算での結果なので、実際の案件で同じ割合のずれが出るという意味ではありません。

書き直さずに包めば、合成例では結果は全件一致した。 計算を変えないこと自体が、ずれを防ぐ手段になります
書き直した場合のずれは、普段どおりの入力では見つからなかった。 見つけたのは「端数がちょうど0.5円」「マイナスの金額」を狙って作った入力です。照合用のデータは意図して作る必要があります
Web化で増える作業の中心は、計算より入口側にある。 社内の担当者が正しい値を入れる前提で作られたプログラムは、チェックなしで公開すると、異常な値をそのまま金額にして返します

なお、a の「包む」部分のコードは、入力チェックを含めても標準の部品だけで30行ほどでした。この程度の作業は、AIに頼めば社内でも短時間で書けます。時間がかかるのは書くことより、どの入力を受け付けるか、どちらの結果を正解とするか、失敗したら誰がどうするかを決めることです。

納品をどう確認するか（元のExcel・プログラムとの照合）

見た目は動いていても、金額や結果が正しいかは画面だけでは分かりません。納品時の確認は「元のプログラム（またはExcel）と同じ結果が出るか」を照合表で確かめるのが確実です。

照合データの作り方

種類	中身	架空の計算プログラムでの例
通常	実際の業務でよく使う入力	単価・数量の典型的な組み合わせ
境目	条件が切り替わる値の前後	数量99・100・101、499・500・501
端数	丸めの影響が出る値	税込金額の端数がちょうど0.5円になる入力
マイナス・ゼロ	返品・値引き・空の入力	単価がマイナス、数量0
異常	受け付けてはいけない入力	文字、桁数超過、極端に大きい値
最大量	想定する上限のデータ量	一番大きいファイル（処理時間の確認も兼ねる）

通常・境目・端数・マイナスは「元と同じ結果」になるかを、異常は「正しく入力エラーになるか」を確かめます。

照合表の記入例（説明用・架空データ）

No	種類	入力（単価×数量）	元のプログラム	新しいWeb版	差	判定	判定者
1	通常	382.98円×93	39,179円	39,179円	0	一致	業務責任者
2	境目	12.35円×99	1,345円	1,345円	0	一致	業務責任者
3	境目	12.35円×100	1,291円	1,291円	0	一致	業務責任者
4	端数	1.50円×10	17円	16円	-1	不一致→Web版を修正	業務責任者
5	異常	数量0	0円	入力エラー	—	仕様どおり	業務責任者

確認の前に決めておくこと

許容差：金額なら1円の差も不一致として扱うのが安全です。分析の数値（小数の多い統計量など）は、小数第何位まで一致すればよいかを先に決めます
正しい計算の承認者：照合で不一致が出たとき、「新しい版の誤り」「元のプログラムの誤り」「仕様が決まっていない」のどれかを判断する人です。業務のルールを持つ部門の人が担います
元のプログラムに誤りが見つかった場合：照合は「元と同じか」を確かめるもので、元の計算が正しいことまでは保証しません。元の誤りをそのまま正解として固定しないよう、承認者が正しい仕様を決め、照合の正解を差し替えます。直す範囲と費用は改めて合意します
AIによる自己採点だけで終えない：開発側がAIで作ったテストに、同じAIが作った期待値で合格しても、照合したことにはなりません。正解は元のプログラムの出力か、承認者が認めた値にします

納品物や検収全般の考え方はシステム開発の納品物でも整理しています。

費用の目安と依頼の形

AI革命の受託開発では、次の公開価格を基準にしています（すべて税別）。どこに当たるかは、上の「足すもの」の範囲で決まります。

依頼の形	価格（税別）	含むもの	Web化で当たりそうな状況（目安）
小規模な既存改修	30万円〜	画面の追加・修正、帳票やCSV出力の追加、軽微な外部連携など	既にあるWebシステムに、計算の呼び出しと結果の出力を足すだけ
PoC	300万円〜	検証内容の整理、PoCの設計・開発、評価結果のまとめまで	処理時間・結果の一致・利用者の使い勝手を、本番前に確かめたい（本番システムの完成価格ではありません）
本開発	個別見積	機能、利用者数、外部連携、データ移行、安全要件を確認して見積	社外の顧客に公開する、ログインと権限、長時間の計算の管理、管理画面まで作る

含まないもの：クラウド利用料、外部サービスの利用料、ソフトウェアのライセンスなどの実費は別途かかります
成果物、保守、権利の扱い、追加変更の扱いは、見積と契約で明確にします
費用が増えやすいのは、計算を書き直す場合（照合の手間が増える）、社外公開で権限を細かく分ける場合、長時間の計算で待ち行列や再実行が要る場合、照合用の正解データを一から作る必要がある場合です

言語や作りを理由にお断りはしていません。Python・Excel/VBA・その他の言語で書かれた計算でも、他社や前任者が作ったプログラムでも、まず中身を調べてから「包む・移す・作り直す」を一緒に決めます。調べるだけの依頼も、調査から改修までの依頼もご相談いただけます。社内でAIを使って開発を続けたい場合は、権限・照合・運用の設計だけを任せるといった分け方もできます。料金と対応範囲は受託開発のページにまとめています。

今動いている計算プログラムを活かしてWeb化できるか相談する（初回相談は無料・30分・オンライン。要件が決まっていなくても大丈夫です）

近い取り組みの公開事例

既存の計算プログラムをWeb化した事例そのものは、現在公開できるものがありません。近い取り組みとして、通信事業の会社で「数万件の請求情報をまとめて計算する仕組み」を作った事例があります。件数の多い請求情報の集計を担当者の手作業に頼らずに行うことが課題で、集計ルールの整理・要件定義・システム開発を行い、請求情報の取り込み・集計処理と、確認対象を絞り込む管理画面を作りました。計算のルールを仕組みに移し、人が確認する画面を付けるという点で、この記事の内容と重なります（詳細は受託開発のページの事例欄）。

相談前に揃えておくもの

初回相談では、今動いているプログラムと、誰に何を使わせたいかを伺い、自社でAIを使って進められる部分と任せた方がよい部分を切り分けます。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。次のものがあると話が早く進みます。

今の実行方法と、使っている言語・ツールの名前（上の「7項目」の表を埋めたもの）
入力と出力の例（架空の値や加工した値で構いません）
Webで使わせたい人（社内の誰か、顧客企業か）と、おおよその人数
1回の処理にかかる時間の目安
「この入力ならこの結果が正しい」と言える例がいくつかあれば、その例

ソースコード・実際の顧客データ・本番の認証情報は、初回の相談フォームには送らないでください。必要になった段階で、受け渡しの方法を決めてからお預かりします。

よくある質問

プログラムを作った人が退職していて、中身を誰も説明できません。それでも依頼できますか？

依頼できます。まずソースコードと、それを動かす環境（使っている部品の一覧や設定）が手元にあるか、社内で使ってよい権利があるかを確認します。中身の調査だけを先に頼み、その結果を見てWeb化の方式を決める、という順番も選べます（調査は有償で、始める前に範囲と金額を示して合意を取ります）。説明できる人がいない場合は特に、照合用の「正しい入力と結果の組」を業務側で用意しておくと、調査後の判断が速くなります。

Excelの関数やマクロで作った計算表もWeb化できますか？

できます。Excelの計算をそのまま使い続ける方法と、計算を別の言語に移す方法があり、どちらにするかは計算の量・更新の頻度・同時に使う人数で決めます。移す場合は、Excel の ROUND と移し先の言語の丸め方が違うことがあるため、端数の出る入力を照合データに必ず入れてください。

外部から取り込んだ部品のライセンスが分からないのですが、問題になりますか？

社内で手元実行していたときは気にならなくても、顧客にWebで提供すると、部品の利用条件によっては扱いを確認する必要が出てきます。開発の初期に、使っている部品の一覧と利用条件を洗い出す作業を入れておくと安全です。法的な判断が必要な場合は、専門家の確認と組み合わせてください。

Web化した後、計算式の変更は誰が行うのですか？

変更の頻度で決めるのが現実的です。年に1〜2回なら開発会社に改修を頼む形でも回りますが、料金表の単価のように頻繁に変わる値は、管理画面から担当者が変えられるようにしておく方法があります。その場合も、変更前に試算して確認する手順と、誰が承認するかを決めておきます。変更した日以降の結果がどの版の計算によるものかを記録しておくと、過去の結果を問い合わせられたときに説明できます。

計算結果が正しいことまで保証してもらえますか？

Web化で確かめられるのは「元のプログラム（または承認された仕様）と同じ結果が出るか」までです。計算の考え方そのものが業務上正しいか、分析の手法が妥当かは、計算の仕様を持つ発注側の判断になります。照合の途中で元の計算の誤りらしいものが見つかった場合は報告し、正しい仕様を決めていただいたうえで直す範囲を相談します。