Zenn
EVERSTEEL Tech BlogPublicationへの投稿
🌱

「鉄ナビ検収AI」のアーキテクチャを紹介します！

knagi
に公開
TypeScript
NestJS
architecture
backend
tech

はじめに

こんにちは、株式会社EVERSTEELでエンジニアをしている片桐です。

弊社では鉄スクラップの画像解析を行う「鉄ナビ検収AI」というプロダクトを開発しており、鉄リサイクルの効率化・品質向上に取り組んでいます。東大発のスタートアップとして、より良いソリューションを追求しながらプロダクト開発を進めています。

この記事では、「鉄ナビ検収AI」のバックエンドアーキテクチャについて、いくつかピックアップして紹介します。

  • 「鉄ナビ検収AI」というプロダクトの概要
  • TypeScript + Nest.jsを選択と背景
  • システム全体のアーキテクチャ構成とモジュール設計
  • クリーンアーキテクチャと型安全性へのアプローチ
  • チーム拡大に伴う課題と取り組み

スタートアップでのバックエンド開発やアーキテクチャ設計に興味のある方に、EVERSTEELでの開発現場の現状・雰囲気を感じてもらえればと思います。

「鉄ナビ検収AI」とは

「鉄ナビ検収AI」は、鉄スクラップの画像解析を通じて鉄リサイクル業界の効率化・品質向上を目指すプロダクトです。

「鉄ナビ検収AI」概要

プロダクトの背景

鉄リサイクル業界では、持ち込まれた鉄スクラップの品質判定が重要な工程となっています。従来は人の目による判定が中心でしたが、判定者の経験や知識に依存する部分が多く、品質のばらつきや判定時間の課題がありました。

「鉄ナビ検収AI」では、AI技術を活用して鉄スクラップの画像から品質を自動で判定することで、これらの課題解決を図っています。

なぜバックエンドアーキテクチャが重要なのか

「鉄ナビ検収AI」のバックエンドは、様々なシステムとの連携が求められる複雑な役割を担っています。

  • カメラシステムとの連携: 鉄スクラップを撮影するカメラからの画像データを効率的に処理
  • AI解析システムとの連携: 画像をAIモデルに送信し、解析結果を適切に処理
  • 工場基幹システムとの連携: 各工場で異なる既存の基幹システムとのデータ連携
  • リアルタイム処理: 判定結果を即座にフロントエンドや外部システムに提供

これらの多様な連携を安定して処理しながら、データの整合性を保ち、システム全体のスケーラビリティを確保することが、バックエンドアーキテクチャ設計の重要な課題となっています。

技術スタック

「鉄ナビ検収AI」のバックエンドでは、TypeScript + Nest.js を採用しています。この組み合わせには以下のメリットを感じています。

システム連携の安全性と保守性の確保

  • 型を静的に検証するTypeScriptの型システムや zod などのバリデーションライブラリ
  • Nest.jsの依存性注入により、外部システム（基幹システム、AI解析システム、カメラシステム）との連携部分を保守しやすい形で実装可能

チーム開発の効率化と開発言語の統一

  • スタートアップという環境で多様なバックグラウンドを持つメンバーが協働する中、TypeScriptは比較的普及しており技術情報も豊富
  • 少人数チームで機能開発時にフロントエンド/バックエンドを同じ開発者が担当することが多く、フロントエンドとバックエンドで開発言語が統一されていることによる開発効率の向上

この技術スタックの選択より、バックエンド開発における安全性と拡張性を確保しながら、効率的に開発することができていると感じています。

アーキテクチャの紹介

前章で紹介した技術要素を、実際のシステムアーキテクチャの中でどのように活用しているかを紹介します。

システム構成の概要

「鉄ナビ検収AI」のシステムは、クラウド側とオンプレミス（工場内）のコンポーネントから構成されています。

「鉄ナビ検収AI」システム構成図

クラウド側コンポーネント:

  • AI検収管理: AI解析結果の処理と管理を担当
  • 撮影セッション管理: カメラからの画像取得と撮影フローの制御
  • 検収情報管理: 基幹システムとの連携や検収データの統合管理

推論処理サービス: AIチームが担当する、撮影画像のAI解析を実行するコンポーネント

オンプレミス側コンポーネント:

  • 基幹システム: 顧客管理の既存システムとの連携
  • EVERSTEELオンプレサーバ: HWチームが担当するカメラ機器との接続基盤。複数のソフトウェアコンポーネントが動作し、画像データの前処理や転送を行います。

クラウドの処理能力を活用しながら、各工場の現場環境に柔軟に対応できる構成を目指しています。

モジュール設計の概要

「鉄ナビ検収AI」では、以下のような機能モジュール構成で実装しています。

現在のディレクトリ構造

src/
  ai_assessment/    # AI検収管理
    application/
    domain/
    infrastructure/
    presentation/
  capture_session/  # 撮影セッション管理
    application/
    domain/
    infrastructure/
    presentation/
  ...

「AI検収管理」「撮影セッション管理」といった機能領域ごとにモジュールを分割し、それぞれが独立して開発・テスト可能になるよう設計しています。モジュール間は明確なインターフェースを通じて連携し、疎結合を保つことで、変更の影響範囲を最小限に抑えています。

開発スピードとコードの整理のバランスを取りながら、撮影機能の改善やAI解析ロジックの変更などが独立して進められる構造を目指しています。

ドメインモデルの型安全性

ドメイン層では型システムを活用してドメインの概念を安全に表現するように設計しています。
例えば、文字列型で表現される様々なIDには Branded Type パターンを適用し、それぞれ異なる型として定義することで、異なる種類のIDを誤って混同することを防いでいます。

// Branded Typeの基本実装
declare const __brand: unique symbol;
type Brand<B> = { readonly [__brand]: B };
type Branded<T, B> = T & Brand<B>;

// IDの型定義例
type UserId = Branded<string, 'UserId'>;
type CameraId = Branded<string, 'CameraId'>;

また、ドメインエンティティの作成時には、バリデーションロジックを一元化し、データの整合性を確保するようなパターンを採用しています。エラーハンドリングには Neverthrow などのライブラリを活用し、型安全な方法でエラーを処理できるようにしています。

このアプローチにより、ドメインオブジェクトの整合性を型レベルで保証し、実行時エラーの削減を図っています。

これらの型安全性に関する詳細な実装方法については、今後の記事で詳しく紹介する予定です。

将来のアーキテクチャ設計の展望

「鉄ナビ検収AI」のアーキテクチャは、プロダクトの成長とともに進化を続けています。現在社内で議論が進んでいる検討項目は以下の三つです。

コード構造とドメイン分離の検討

ディレクトリ構造について、以下のような案を議論しています。

src/
  presentation/     # 統合されたAPI層
    auth
    control
    admin
  domain/          # ドメイン別の分離
    ai_assessment/
      application/
      domain/
      infrastructure/
    assessment_manager/

これはプレゼンテーション層を統合し、各ドメインのビジネスロジックをより明確に分離することを目指した検討案です。
型安全性についても、ドメイン固有型の導入と型レベルでのバリデーション手法、各ドメイン間での定義の整合性確保について議論が始まっています。

クラウドとエッジのバランスに関する探索

クラウドとオンプレミス（エッジ）の処理バランスの再検討も議論が進んでいます。映像処理・推論のエッジ化によるリアルタイム性の向上や、ネットワーク切断時の対応など、現場環境における課題を考慮したアーキテクチャを模索しています。

モジュール間依存関係と抽象化レベルの検討

コードベースの成長に伴い、ドメイン層間の依存関係やモジュールインターフェースのあり方を検討しています。特にインフラストラクチャ層においては、適切な抽象化レベルを見いだすための試行錯誤を続けています。

保守性と拡張性が高く、成長するビジネスニーズに柔軟に対応できるようなアーキテクチャを目指し、改善を続けていく予定です。

チーム拡大で見えてきた課題と取り組み

前章まででバックエンドアーキテクチャの技術的な詳細について紹介しましたが、実際のプロダクト開発では技術選択だけでなく、運用面や開発プロセスの課題にも取り組む必要があります。

「鉄ナビ検収AI」では、チームの拡大とプロダクトの成長に伴い、新たな課題が見えてきており、現在も継続的な改善を進めています。

運用におけるオブザーバビリティの課題

システム状態把握の困難さ

システムが複雑化する中で、最も重要な課題の一つが「システムの状態を簡単に把握できていない」という点でした。問題が発生した際の原因特定や解決に時間がかかってしまう状況があり、運用効率の改善が急務となっていました。

オブザーバビリティ強化への取り組み

この課題に対して、ログ改善、メトリクス収集、アラート最適化などを含むオブザーバビリティの強化を段階的に進めています。「まず必要なデータを記録し、その後で可視化・分析機能を拡充する」という実用性を重視したアプローチで取り組んでいます。

オブザーバビリティの詳細な実装方法については別の記事で紹介する予定です。

事業拡大に伴う新たな挑戦

工場オンボーディングの簡易化

「鉄ナビ検収AI」の導入工場が増える中で、新規工場でのシステム導入プロセスの簡易化が重要な課題となっています。各工場で異なる基幹システムとの連携をスムーズに行うための仕組み作りを進めています。

データ整合性とコスト最適化

システム規模の拡大に伴い、データ整合性の確保とコスト最適化への取り組みも並行して進めています。特に画像データの処理量増加に対応するため、効率的なデータ管理とインフラ利用の最適化を図っています。

ドキュメント不足とチーム知識共有の課題

新規参画メンバーのキャッチアップ負荷

チーム拡大に伴い、新規参画メンバーのキャッチアップ負荷が増大するという課題が顕在化してきました。複雑な技術スタックや業務ドメインの理解には多くの暗黙知が必要であり、効率的な知識共有の仕組みが不可欠となっています。

ドキュメント整備への取り組み

この課題に対応するため、以下のような具体的な取り組みを進めています。

  1. アーキテクチャドキュメントの体系化: ドメインモデルや主要コンポーネントの関係性を視覚的に整理
  2. コード内ドキュメントの充実: 型定義や関数コメントを通じた自己説明的なコードベースの構築
  3. AI活用開発の導入: 充実したドキュメントを基にしたLLMによる理解支援・コード生成の精度向上

テスト戦略と品質向上

システムの複雑化に伴い、テスト実装の重要度がより一層高まっています。単体テストだけでなく、統合テストやE2Eテストを体系的に整備し、コードの変更に対する安全性を高める取り組みを進めています。
自動化されたCI/CDパイプラインにより、テストの実行からデプロイまでのプロセスを効率化しています。

各取り組みの詳細な内容や具体的な実装については、今後の記事で個別に紹介予定です。

おわりに

この記事では、「鉄ナビ検収AI」のバックエンドアーキテクチャについて、プロダクトの概要から技術スタック、アーキテクチャ、そして現在直面している課題まで幅広く紹介しました。

今後は型安全性の実装手法やオブザーバビリティ強化の具体策などについて、より詳細な記事を通じて紹介していく予定です。スタートアップにおける実践的な開発現場の雰囲気を感じていただければ幸いです。

「鉄ナビ検収AI」では、技術的な挑戦と実用性のバランスを取りながら日々改善を続けています。今後も実践的な知見を紹介していきますので、ぜひフィードバックをお寄せください！

GitHubで編集を提案
EVERSTEEL Tech Blog
EVERSTEEL Tech BlogPublication

株式会社EVERSTEELの技術ブログです。 2025年6月に開設いたしました。EVERSTEEL各チームの開発内容についてお届けしていきます。ぜひご覧ください。

Discussion