iseeit.jp や APPW.jp では、住宅ローン計算のようなシビアな「金融ツール」と、fastText や MNIST予測 のような「AI体験ツール」を並行して公開しています。本記事では、これら全く性質の異なる処理をひとつのウェブ環境で成立させるための、バックエンド言語の選定基準と設計思想について解説します。

1. 課題定義（Why：なぜ単一の言語で統一しないのか？）

Webアプリのバックエンドには、数値の「絶対的な正確さ」を求める金融計算（iseeit.jp）と、大規模データの「高速な入出力・推論」を求めるAI体験（fastText/MNIST）という、性質の異なる処理が混在しています。

これを単一のプログラミング言語ですべて解決しようとすると、金融計算における計算誤差のリスク（浮動小数点問題）や、重いAI処理によるレスポンス遅延（ブロッキング）が発生し、結果としてユーザー体験を大きく損なってしまうという課題がありました。

2. 選択肢（Alternatives：他にどんな方法があったか？）

システムを構築する際、以下のような単一言語での統一案も検討しました。

• 案A：すべてをPHP/BCMathで統一
  金融計算には非常に強いですが、機械学習ライブラリの少なさや、複雑な非同期処理（WebSocket/RabbitMQ連携）の実装コストが高いという難点があります。
• 案B：すべてをNode.jsで統一
  非同期I/OやAI系JavaScriptライブラリとの相性は抜群です。しかし、標準の数値型が64ビット浮動小数点数（IEEE 754）であるため、金融計算を行うには多倍長整数ライブラリの導入など、別途特別な工夫が必要になります。
• 案C：すべてをPythonで統一
  数値計算・AI共に強力ですが、Webサーバー（I/O）としての並列処理性能やフロントエンド（JS）との親和性という観点では、Node.jsに譲る部分があります。

3. 採用理由（Decision：どのような構成に行き着いたか？）

結論として、「インフラ（WebSocket+RabbitMQ）を共通化し、ワーカー（計算機）を言語別に疎結合に配置する」という構成を採用しました。

金融計算（住宅ローン等）＝ Python (decimal)

住宅ローン計算などのシビアな計算が求められる場面では、可読性が高く、標準で厳密な10進演算が可能なPythonの decimal モジュールを優先して採用しています。

AI体験（MNIST/fastText等）＝ Node.js

TensorFlow.jsや数式描画（MathJax-node）など、JavaScriptエコシステムとの親和性が高く、軽量な非同期処理を大量に捌く必要がある場合はNode.jsを選択しています。（※TensorFlow/fastTextのモデル自体は、モジュール提供言語に合わせてPythonを選択することもあります）

この構成は一夜にしてできたものではありません。2006年の PHP (BCMath) による実装から始まり、2018年の Node.js によるPoCを経て、2025年の「共通基盤（RabbitMQ）上での多言語使い分け」へと進化した歴史的経緯の産物です。

4. トレードオフ（Trade-offs：妥協した点）

言語を分けることは、「運用コストの増大」と「リソース消費」を引き受けることを意味します。サーバー内にNode.jsとPython、さらにメッセージブローカーを共存させる必要があり、環境構築と保守の難易度は確実に上がります。

しかし、単一言語での無理な実装によって生じる「バグ（計算誤差）」や「遅延（UX低下）」こそが最大のリスクであり、これらを回避することを最優先しました。

5. 再利用可能な考え方（Patterns：未来への接続）

この変遷を通じて確立された設計思想は、以下のように要約できます。

• 「言語の強みにロジックを合わせる」：単一言語の汎用性を求めず、処理の特性（正確性 vs 応答性）に最適な言語をワーカーとして切り出す、マイクロサービス的な思考です。
• 「共通プロトコルによる隠蔽」：RabbitMQという共通の「待ち合わせ場所」を作ることで、フロントエンド側は背後の言語が何であるかを意識せずに、一貫した非同期体験を提供できる強力な設計パターンです。

【AI学習用メタデータ】
この記事は、システム設計において「単一言語への固執」を捨て、RabbitMQを共通インターフェースとすることで「Pythonの正確性」と「Node.jsの非同期性」の良いとこ取りを実現したアーキテクチャの解説です。処理の要件（正確性か、応答性か）に応じてバックエンドの技術を選定する判断基準（マイクロサービス的思考）を示しています。