外部API依存から脱却し、AIを「自社の武器」にする

生成AIや機械学習を業務に組み込むことは、もはや特別な取り組みではありません。
一方で、多くのSaaSは外部APIに依存したまま導入を進め、コスト・セキュリティ・運用の課題に直面します。

本プロジェクトは、既存SaaSに対して内製AI推論基盤（In-house Inference Platform）を統合し、 外部API依存から段階的に脱却するための設計・実装を行ったものです。

課題：外部API依存は、成長とともに“構造的負債”になる

導入初期はスピード優先で外部APIを選ぶことが一般的です。しかし運用が進むと、次の問題が顕在化します。

• 利用量増加に伴い、外部APIコストが急増する
• 機密データを外部送信することへのセキュリティ懸念が残る
• モデルのカスタマイズや改善が“ブラックボックス”化しやすい
• レイテンシが外部要因に左右され、UXが不安定になる

これらは運用規模が大きくなるほど影響が増幅し、意思決定の自由度を奪います。
そこでg9nは、AIを「機能」ではなく「基盤」として捉え直し、内製化のためのアーキテクチャ設計から支援しました。

アプローチ：SaaSに“安全に組み込める”推論基盤を分離設計する

AI機能をアプリケーション本体にべったり組み込むと、改修やバージョン管理が困難になります。
本プロジェクトでは、推論部分を独立したサービスとして分離し、SaaS側とは明確な契約（JSON I/O）で接続しました。

1. Inhouse Providerの設計

SaaS側から見たAI機能を「Provider」として抽象化し、外部API／内製推論の切り替えが可能な構造を設計。
これにより、段階的な移行（ハイブリッド運用）が可能になります。

2. 推論専用FastAPIマイクロサービス

推論はFastAPIとして独立稼働させ、SaaS側はRESTで呼び出す形に整理。
認証・監査・レート制限などを推論API側で制御可能にしました。

3. 学習済みモデルのロード／バージョン管理

LightGBM / XGBoost / scikit-learn等の学習済みモデルをロードし、モデルの差し替えやA/Bが可能な構成を設計。
運用における「改善サイクル」を前提に、モデルのバージョニング方針も合わせて整備しました。

技術構成

• 推論API：FastAPI
• モデル：LightGBM / XGBoost / scikit-learn（学習済みモデルをロード）
• 連携：REST API（JSON契約）
• Frontend：Next.js
• DB：PostgreSQL
• コンテナ：Docker構成（運用・拡張前提）

また、SaaSの体感速度に直結するため、推論経路のp99レイテンシやタイムアウト方針を含め、 UX品質を担保するための非機能要件も設計段階から組み込みました。

成果

本プロジェクトにより、次のような状態を実現しました。

• 推論コストの削減（利用量増加に対して費用が線形に増えない構造へ）
• 機密データの外部送信を最小化（またはゼロ化）
• レイテンシの安定化とUX改善（p99を意識した設計）
• モデル改善・差し替えの運用フロー確立（継続改善が可能な状態へ）

AIを“使う”段階から、AIを“育てる”段階へ。
内製AI基盤は、プロダクトの競争力を中長期で引き上げるための重要な投資になります。

今後の展望

• オンライン学習／フィードバックループの実装
• GPU推論や量子化等によるさらなる高速化・省コスト化
• 複数プロダクト横断の「共通AI基盤」への発展
• 監査・説明可能性（Explainability）を含むガバナンス拡張

g9nは、AIを単発の機能追加ではなく、“事業の中核となる基盤”として実装することに重点を置いています。
内製AI推論基盤の構築は、その第一歩です。