< WindowsライブラリのWebアプリ化 - ArtLogic
ArtLogic - 画像処理・図形処理・最適化技術

WindowsライブラリのWebアプリ化

ソフト資産（ソフトウェア・データ）を、全端末（スマホ、タブレット、PC）で世界展開

Windows用のライブラリ資産をWebアプリ化することで、ライブラリの機能を利用できる環境を一気に広げることができます。
LinuxやmacOS、ChromeOSからも呼び出すことができますし、スマホやタブレットのブラウザから呼び出すこともできます。
API化することで、あらゆるOSのあらゆる言語からライブラリの機能を呼び出す事もできます。
Web版アプリケーション化
Web版アプリケーション化

Webアプリケーション開発フレームワークにはPython言語上のFlaskを使っています。
FlaskはPHP上のLaravelやJavascript上のReact/Next.jsのような万人向けの、とっつきやすいフレームワークではありませんが、
悪意ある攻撃者に対しては、PHPより狙われにくく、たとえ攻撃されても堅牢なフレームワークです。

悪意あるハッカーからの攻撃への対抗力
脆弱<----------　　　　　　　　------------->堅牢
　PHP　JavaScriptPhthon/Ruby/C#　Go　
Webアプリケーションの作りやすさ
易<----------　　　　　　　　------------->難
　PHP　JavaScriptPhthon/Ruby/C#　Go　
乗り物にたとえると、PHPはバイク、JavaScriptはハイテク乗用車、Python/Ruby/C#は装甲車、Goは戦車です。
PHPは手に入りやすい手頃な乗り物ですが、中身が外にむき出しで攻撃を受けるとすぐに傷つきます。

Windows専用ライブラリをWebアプリとして公開するまでの道筋を以下に示します。
Google Cloud Run/Microsoft Azure App Service/Amazon ECS Express Modeといった三大クラウドでデプロイするまでにかかった日数は実質一ヶ月です。
集中すれば2週間程度でも可能だと思います。もちろん2026年なので「生成AI」の利用が前提となります。
生成AIを使うことで
  • クラウドの資格不要
  • 解説記事（QiitaやZenn）・書籍・公式マニュアル不要
  • 経験（者）不要
で主要クラウド(この記事ではGoogle/Microsoft/Amazon)向けのWebアプリ化が可能です。

公開までの道筋

  1. 32bit版であれば64bit版へ
    2. 32bit版のままでも、一部のクラウドでWebアプリは作ることはできますが制限が多くなります。64bitに移植しましょう。
  2. Linuxへ移植
    3. Windows専用でもWebアプリ化することは可能ですが、デプロイとその後の保守の難易度が上がり、レスポンスが悪くなり、運用コストも高くなるとデメリットが多いので極力避けましょう。可能であれば、Linuxへの移植を行います。
    詳細はクリック Linuxへ移植するためには以下の条件が必要となります。
    • Windows APIへの依存がない。
      • C/C++の標準ライブラリを使っているだけなら問題はない。
      どうしてもWindows APIを外せないときは、運用コストのデメリットを勘案しながらWindows版のままでデプロイしましょう。
    • 他のライブラリ(たとえばOpenCVやlibjpeg等)への依存が少ない。依存先のライブラリのLinux版があればなんとかなる。
      • たとえば画像の読み込みや簡単な画像処理は、フレームワーク側のPython上のPillowモジュールで行うことでOpenCVやlibjpegは不要となります。
      Pythonのモジュールで代替できなくて、Linux版のライブラリも無い場合は、運用コストのデメリットを勘案しながらWindows版のままでデプロイしましょう。
    • WindowsとLinuxでのsizeof(型)が異なる型を使っていない。
      • long/unsigned long/wchar_t、などのサイズが異なっているので、int/int32_t/int64_tなどに変更する。
    必要に応じて、生成AIに変更点を生成してもらったり、代替案を提案してもらいながら移植しましょう。
  3. 多（他）言語から呼び出すことができる共有ライブラリ（動的リンクライブラリ）にする
    4. 詳細はクリック Webアプリケーションを開発するためのフレームワークがC/C++であるならば問題はありません。
    しかし、PythonやJavaScript、PHP等から呼び出すには、ライブラリを共有ライブラリ（Windowsにおける動的リンクライブラリ） とする必要があります。 方法はAPIとする関数を指定して、Windowsの動的リンクライブラリ・Linuxの共有ライブラリにするためのラッピング関数を 生成AIに生成してもらうと良いでしょう。ラッピング関数のソースコードは、簡単にWindows/Linux共通にすることができますので、 生成AIプロンプトに、「Windows/Linux共通で」と指定するようにしましょう。
  4. Visual Studio 2022/2026でクロスプラットフォーム開発
    5. 詳細はクリック WSL（Windows Subsystem for Linux）で、Windows上でLinux環境を直接実行できるようにする。
    Visual Studioで"CMakeLists.txt""を生成してWindowsの動的リンクライブラリ".dll"に相当するLinuxの共有ライブラリ".so"を作る。 手順については、ChatGPT等の生成AIに投げれば丁寧に教えてくれる。トラブルが発生したときの質問も同様。
  5. Webアプリ開発用フレームワークを選択
    6. 詳細はクリック フレームワークを使わずに作ることもできます。その場合、セキュリティに関しては狙われにくくなりますが、開発時間増大・開発コスト高騰といったデメリットがあります。
    フレームワークの選択肢はたくさんあります。それぞれの特徴を比較して（生成AIに比較表をつくってもらえば短時間で可能）好きなものを使いましょう。

    当社ではPythonのFlaskを使っています。
    Python言語だとFlask以外にDjangoやStreamlitなどのフレームワークがあります。
    Python言語以外にもC++/Java/JavaScript/C#/Go/Rust/Ruby/PHPなど各言語上に、多くの種類のフレームワークがあります。
    使い方は生成AIに聞けばドキュメント・経験不要ですが、レビューは必要です。自分が知っている言語のフレームワークを選択してください。
  6. セキュリティ・悪意あるアクセス対策・認証
    7. 詳細はクリック DDos攻撃は、クラウド側でも対応することができますが有料です。
    Webアプリケーション開発フレームワークにも、同一IPからの集中アクセスを避けたり、ファイルサイズのチェックなどを組み込むことができます。
    無償アプリケーションでは認証は不要です。
    有償アプリケーションでは認証したり利用の数量をカウントする機能がフレームワークやクラウドの追加機能があるので組み込むことができます。
    パスワードの誤りが何度か繰り返されたらアカウントを停止するようなこともフレームワークで実現できます。

    また、アップロードしたデータは、ユーザーの保護のためにも処理後に消去することが望ましいです。
    サーバーの処理が失敗した場合でも、アップロードしたデータは消去するようにしましょう。

    パラメータ等の値のチェックも、クライアント側でやっていたとしてもサーバー側で重ねて実行するようにしましょう。
    "index.html"といったブラウザ経由ではない、サーバーの呼び出しコマンド(curl等)もあるので、値の重複チェックが必要となります。
  7. ローカルでテスト
    8. 詳細はクリック 実際の商用クラウドでデプロイすることが目標ですが、動作確認はPC一台上で行うことができます。
    「生成AI」で、以下の要素を入れたプロンプトを作って、ローカルでテストするまでの「手順書」を作ってもらいましょう
    • 公開するライブラリのAPI関数仕様やパラメータの仕様
    • ホームページのデザイン
    • フォームの名前(テキストエリアやチェックボックス・ラジオボタンの名前)
    • ホームページのおおよそのデザインをテキストあるいはアスキーアートで
    手順書通りでやっても、必ず数回のトラブルが発生します。
    トラブルが発生したら、状況を説明するテキストやスクリーンショットを使って生成AIに質問すれば、通常一回のやりとりで、最悪でも3回のやりとりで原因確認・修正することができます。
  8. Google Cloud Runでデプロイ
    9. 詳細はクリック 最初にターゲットとするクラウドサービスは、Google Cloud Run一択です。
    理由は、他のクラウドサービスと比べて、桁違いに簡単にデプロイできるからです。
    ローカルでテストが成功していれば、1日もかからずにGoogle Cloud Runでデプロイすることができます。

    さらに、Google Cloud Runでデプロイが成功していれば、ほぼ確実にMicrosoft Azure App ServiceやAmazon ECS Express Modeでもデプロイできる見通しが立ちます。
  9. Microsoft Azure AppやAmazon ECS Express Modeへ移植
    10. 詳細はクリック Google Cloud Runへのデプロイの難易度を"1"とすると、Microsoft Azure App Serviceへのデプロイの難易度は"3"、Amazon ECS Express Modeの難易度は"10"です。
    ユーザー数～数万人レベルの小規模Webアプリの場合は、Google Cloud Runだけをターゲットにしても良いと思います。
    ユーザー数～数十万人レベルの中規模Webアプリの場合は、Microsoft Azure AppやAmazon ECS Express Modeを最終ターゲットにしましょう。
    中規模アプリの場合でも、Google Cloud Runをテスト運用環境としてAzureやAWS(Amazon)に移植するという方法を推奨します。

    補足：当初、Amazonのクラウドサービスとして"AWS App Runner"という比較的簡単な操作でデプロイできるサービスを使おうとしていましたが、 2026年4月末をもって新規受付停止となってしまいました。
    代替手段としてAmazon ECS Express Modeが提供されていますが、デプロイまでの手順はかなり複雑になっています。