個人開発のAI株取引アプリを本番運用する前に見直す可用性設計5点

React.jsとNode.jsでAI機能付きのWebアプリを個人で作り、AWS（Amazon Web Services）にデプロイしようとしているエンジニアに向けた内容です。金融データを扱うアプリをローカル開発からクラウド本番環境に移す際、SRE（サイト信頼性エンジニアリング）の観点で何を確認すべきか整理しました。

個人開発でよく見かける構成として、フロントエンドにReact.js、バックエンドにNode.jsとExpress.js、データベースにMongoDB、そしてGoogle Cloud AI PlatformやTensorFlow（Googleが開発する機械学習ライブラリ）で予測モデルを組み込むパターンがあります。株価データを分析してユーザーに売買のヒントを出すAIアシスタント機能を持つアプリがその一例です。機能面では動いていても、可用性やコストの設計が抜けたまま公開すると、思わぬ障害やクラウド費用の急増につながります。

AI機能付きアプリが抱えやすい可用性リスク

株価分析のようなリアルタイム性が求められるサービスでは、まずAPI呼び出しの依存関係を整理する必要があります。

フロントエンドのReactアプリが自社のExpressバックエンドを呼び、そのバックエンドがさらにGoogle Cloud AI PlatformのAPIを呼ぶという多段構成は珍しくありません。この場合、外部APIのレイテンシ（応答までの遅延時間）や一時的な障害が、そのままユーザー体験の遅延に直結します。

たとえばTensorFlowで学習させた予測モデルをGoogle Cloud上のエンドポイントとして公開している場合、そのエンドポイントが数秒応答しないだけでも、フロントエンドの画面が固まったように見えてしまいます。ここで重要なのが、外部依存に対するタイムアウト設定とフォールバック（代替処理）の有無です。Expressのミドルウェアでタイムアウトを明示的に設定しているか、AI推論が失敗した場合に「過去のキャッシュ結果を返す」「エラーメッセージを表示する」といった代替パスを用意しているか、コードを見直す価値があります。

SLO設計という考え方をどう当てはめるか

SLO（Service Level Objective、サービスレベル目標）とは、「このサービスは99.9%の時間正常に応答する」といった形で可用性の目標値を数値で定めるSREの基本的な手法です。

個人開発やMVP（実用最小限の製品）段階では大げさに聞こえるかもしれませんが、株取引に関わるアプリでは最低限の目標設定が有効です。たとえば「AI推論APIの応答は95パーセンタイルで3秒以内」「ログイン機能は月間99.5%以上稼働」のように、機能ごとに異なる目標を置くやり方があります。

すべての機能に同じ目標を課す必要はありません。ユーザー認証やポートフォリオ表示のような基本機能は高い可用性目標を、AIによる予測提案のような付加価値機能はやや緩い目標を設定するのが現実的です。この切り分けができていると、障害発生時にどこから復旧すべきかの優先順位も自然に決まります。

IaCで環境差異をなくす

ローカルのGit管理からAWSへのデプロイに移る際、手作業でEC2インスタンスやRDSを構築すると、開発環境と本番環境の差異が生まれやすくなります。

ここで有効なのがIaC（Infrastructure as Code、インフラをコードで管理する手法）です。TerraformやAWS CDK（Cloud Development Kit）を使えば、VPC、EC2、MongoDB Atlasとの接続設定、IAMロールなどをコードとして記述し、バージョン管理できます。

たとえばTerraformであれば、以下のような最小構成から始められます。

resource "aws_instance" "app_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.small"
  tags = {
    Name = "stock-trading-app"
  }
}

こうしたコードをGitHubリポジトリに含めておけば、GitHub Actionsなどのパイプラインからterraform planとterraform applyを自動実行でき、環境構築の再現性が高まります。個人開発でもリポジトリにinfraディレクトリを切って最小限の定義を書いておくと、後からチーム開発に移行する際の摩擦が減ります。

オブザーバビリティとコストの見落としやすいポイント

MongoDBやGoogle Cloud AI Platformのような外部サービスを組み合わせる構成では、障害の原因がどこにあるか切り分けにくくなります。

オブザーバビリティ（システム内部の状態を外部から観測できるようにする設計）の基本は、ログ・メトリクス・トレースの3点を揃えることです。ExpressアプリであればWinstonやPinoでログを構造化し、CloudWatch LogsやDatadogのようなツールに集約すると、AI呼び出しの失敗とDB接続の失敗を区別しやすくなります。

コスト面では、TensorFlowモデルの推論をGoogle Cloud AI Platformで動かす場合、リクエスト数に応じた従量課金が発生します。負荷テストをせずに公開すると、想定外のアクセス増加で課金が跳ね上がるリスクがあります。デプロイ前にはAWSやGoogle Cloudの予算アラート機能を設定し、閾値を超えたら通知が来るようにしておく確認が有効です。

今日確認できること

すでにローカルでアプリが動いている場合、以下の点を順に確認してみてください。

Expressのルートごとにタイムアウト値が設定されているか（デフォルトのままだと無制限になっているケースがあります）
外部AI APIの呼び出し部分にtry-catchとリトライ処理があるか
インフラ構築の手順がコード化されているか、それとも手作業のメモだけか
MongoDBの接続文字列やAPIキーが環境変数として管理され、リポジトリに含まれていないか
AWSまたはGoogle Cloudの予算アラートが設定済みか

観点	確認するもの	使えるツールの例
可用性	APIタイムアウトとフォールバック	Express middleware, axios timeout
再現性	インフラのコード化	Terraform, AWS CDK
観測性	ログとメトリクスの集約	CloudWatch, Datadog
コスト	従量課金の上限監視	AWS Budgets, GCP Billing Alerts

AI機能を組み込んだアプリほど外部API依存が増えるため、タイムアウトとフォールバックの設計を先に固めておく判断が後の障害対応を大きく楽にします。

まとめ

個人開発のAI株取引アプリをAWSなどの本番環境に載せる際は、機能実装だけでなく可用性の設計にも目を向ける必要があります。

まずはSLOという考え方で機能ごとの目標値を仮でもいいので決めてみること。次にTerraformなどのIaCツールでインフラ構築を再現可能にすること。そしてログとメトリクスを揃えて障害の切り分けができる状態を作ること。最後にクラウドの予算アラートを設定してコスト面の想定外を防ぐこと。

これら4点は、今すぐリポジトリとAWSコンソールを開いて確認できる項目です。金融データを扱うサービスだからこそ、公開前の小さな確認が後の大きな障害を防ぎます。