第一部:AIコンサルを支えるデータ基盤

tameFTPシステム自作:AI向けデータ供給の信頼性を確保

株式会社QUEST

データ自動化の第一歩:FTPデータ収集

データ駆動型ECコンサルを実現するため、最初に取り組んだのが各ECモールからのデータ自動収集でした。

楽天、Amazon、auPAYマーケット、それぞれが異なる方法でデータを提供しています。このデータを自動的に、確実に、リアルタイムで取得する仕組みが必要でした。

市販のFTPツールを試した結果

最初は、既存のFTPクライアントやデータ連携ツールを検討しました。

検討した市販ツール

  • FileZilla等のFTPクライアント:手動操作が前提、自動化が困難
  • データ連携SaaS:楽天専用、Amazon専用など、単一モール対応のみ
  • 統合管理ツール:高額(月額数万円〜)で、カスタマイズ性が低い
  • RPAツール:不安定で、エラー時の復旧が難しい

市販ツールの限界

どのツールも、私たちの要件を完全には満たせませんでした。

1. 複数モール統合の難しさ

楽天、Amazon、auPAYの3モールを一元管理できるツールが存在しない

  • 各モール専用ツールを3つ契約 → コストが3倍
  • それぞれのツールで操作方法が異なる → 運用が複雑
  • データ形式の統一機能がない → 結局手作業が必要

2. カスタマイズ性の欠如

独自のデータ処理ルールが適用できない

  • データ検証ルールを追加できない
  • エラー時の処理をカスタマイズできない
  • AIに最適なフォーマットに変換できない

3. 信頼性とエラーハンドリング

商用ツールでも、エラー時の対応が不十分

  • FTP接続エラー時に再試行しない
  • データ欠損を検知できない
  • エラーが発生しても通知されない
  • ログが不十分で、原因調査が困難

4. コストの問題

月額サブスクが継続的に発生

  • 3モール対応で月額5万円〜10万円
  • 年間60万円〜120万円のコスト
  • 長期的には自社開発の方が安い

自作を決めた理由

「完全に自分たちの要件に合ったシステムを作る」

この決断には、以下の理由がありました。

1. 技術的な実現可能性

FTPプロトコルは標準化されており、実装可能

  • PythonやNode.jsに豊富なライブラリが存在
  • FTPの仕様は公開されており、実装は難しくない
  • 開発リソースは限られているが、実現できる範囲

2. 長期的なコスト削減

初期開発コストはかかるが、ランニングコストはゼロ

  • サブスク費用:年間60万円〜120万円
  • 開発費用(自社):初回のみ、実質人件費のみ
  • 3年で数百万円の削減

3. 完全なカスタマイズ性

独自のニーズに100%対応できる

  • データ検証ルールを自由に追加
  • エラーハンドリングを細かく制御
  • AIとの連携を最適化
  • 将来の機能追加が容易

4. ノウハウの蓄積

システムを自作することで、深い理解が得られる

  • データの流れを完全に把握
  • トラブルシューティングが迅速
  • 将来的な改善が容易
  • 技術的な資産として蓄積

tameFTPシステムの設計思想

自作するFTPシステムに、以下の設計思想を組み込みました。

1. 確実性:絶対にデータを取りこぼさない

リトライ機構の実装

  • FTP接続エラー時、最大5回まで自動リトライ
  • 指数バックオフで待機時間を調整(1秒、2秒、4秒、8秒、16秒)
  • すべて失敗した場合のみ、管理者に通知

データ整合性の検証

  • ダウンロード後、ファイルサイズとチェックサムを検証
  • 破損したファイルは自動的に再ダウンロード
  • データベース保存前に必須フィールドをチェック

冪等性の保証

  • 同じデータを複数回処理しても結果が同じ
  • 重複データは自動的にスキップ
  • 処理履歴を記録し、再実行時に考慮

2. リアルタイム性:最新データを常に取得

定時実行とトリガー実行

  • 定時実行:毎日深夜2時に全データを取得
  • トリガー実行:在庫変動時、即座にデータ更新
  • 差分取得:全データではなく、更新分のみ取得で高速化

処理の並列化

  • 楽天、Amazon、auPAYを並列処理
  • ファイルダウンロードとデータ変換を並列実行
  • 処理時間を1/3に短縮

3. 可観測性:何が起きているか常に把握

詳細なログ記録

  • すべての処理をログに記録
  • エラー発生時のスタックトレース
  • 処理時間とリソース使用状況

リアルタイム通知

  • エラー発生時、Slackに即座に通知
  • 1日1回、処理結果のサマリーを報告
  • 異常なデータを検知したら警告

ダッシュボード

  • データ取得状況の可視化
  • 過去の処理履歴の表示
  • エラー率とパフォーマンスの監視

4. 拡張性:将来的な機能追加を容易に

モジュラー設計

  • モールごとに独立したモジュール
  • データ変換ロジックを分離
  • 新しいモール追加が容易

プラグイン機構

  • カスタムデータ処理を追加可能
  • サードパーティ連携を柔軟に実装
  • AIモデルとの接続も容易

開発の実際

技術スタック

言語とフレームワーク

  • Python 3.9:豊富なライブラリ、AI連携が容易
  • ftplib:標準ライブラリのFTPクライアント
  • SQLAlchemy:データベースORM
  • Celery:非同期タスク処理

インフラ

  • PostgreSQL:データ保存
  • Redis:タスクキュー、キャッシュ
  • Docker:環境の再現性確保
  • Prometheus + Grafana:監視

開発期間と工数

フェーズ1:プロトタイプ(1ヶ月)

  • 基本的なFTP接続とファイル取得
  • 楽天RMSとの接続確立
  • データベーススキーマ設計

フェーズ2:本格実装(2ヶ月)

  • Amazon、auPAY対応
  • エラーハンドリング実装
  • リトライ機構、ログ、通知機能

フェーズ3:安定化(2ヶ月)

  • 負荷テスト、障害テスト
  • パフォーマンス最適化
  • ドキュメント整備

合計:約5ヶ月の開発期間

直面した課題と解決策

課題1:楽天RMSのAPI仕様が不明瞭

問題

  • 公式ドキュメントが不足
  • エラーメッセージが分かりにくい
  • API挙動が予測しにくい

解決策

  • 実際にAPIを叩いてレスポンスを確認
  • エラーパターンをドキュメント化
  • リトライとタイムアウトで対処

課題2:Amazonのレート制限

問題

  • APIリクエスト数に厳しい制限
  • 制限を超えるとアカウント停止のリスク

解決策

  • リクエストレート制御の実装
  • バックオフアルゴリズムで調整
  • キャッシュを活用してリクエスト数削減

課題3:データフォーマットの多様性

問題

  • 各モールのデータ形式が全く異なる
  • 同じ項目でもフィールド名が違う

解決策

  • 統一的な内部データモデルを定義
  • モールごとのアダプターパターン実装
  • データマッピング設定を外部ファイル化

運用開始後の成果

定量的な成果

データ取得の自動化率

  • 手動作業:100% → 自動化:100%
  • 処理時間:1日あたり4〜5時間 → 10〜15分
  • 時間削減:約95%

信頼性の向上

  • データ欠損率:月2〜3回 → 月0回(ゼロ)
  • データ整合性エラー:週1〜2回 → ほぼゼロ
  • 可用性:99.9%以上

コスト削減

  • 市販ツール費用:年間60万円〜120万円 → ゼロ
  • 人件費削減:年間約200万円相当
  • ROI:初年度でプラス

定性的な成果

戦略立案の時間確保

  • データ収集に費やしていた時間が完全に解放
  • 経営判断に集中できる環境を実現

AIコンサルへの道を開く

  • 高品質なデータがリアルタイムで蓄積
  • AI分析の土台が完成
  • 次のフェーズ(SKU管理)への準備完了

ノウハウの資産化

  • システムの仕組みを完全に理解
  • トラブル時の対応が迅速
  • 技術的な自信と自立を獲得

学んだこと

自社開発のメリット

  1. 完全なコントロール:すべてを自分たちで決定できる
  2. 柔軟性:要件変更に即座に対応できる
  3. コスト効率:長期的には圧倒的に安い
  4. 技術力向上:開発を通じてスキルアップ

自社開発の難しさ

  1. 初期投資:時間とリソースが必要
  2. 責任:すべての問題を自分たちで解決
  3. 保守運用:継続的なメンテナンスが必須
  4. 技術選定:最適な技術スタックの判断が重要

判断基準

自社開発すべきケース

  • 独自性の高い要件
  • 長期的に使い続ける機能
  • 市販品で満たせない仕様
  • コスト削減の見込みがある

市販品を使うべきケース

  • 汎用的な機能
  • 短期間のみ必要
  • 専門性が高く自社開発が困難
  • 初期コストを抑えたい

次回予告

次回は、「SKU編集アプリ開発:商品コード統一でデータの信頼性を飛躍的に向上」をお届けします。

tameFTPシステムでデータ収集を自動化した後、次なる課題はSKU(商品管理コード)の統一でした。どのようにして混乱していたSKU管理を整理し、AIが分析しやすいデータ構造を実現したのか。その開発ストーリーをご紹介します。


🎯 AI×ECコンサルティングサービスのご案内

現在、株式会社QUESTではAI×ECコンサルティングサービス10社限定で募集しています。

このブログシリーズでご紹介している「データ駆動型ECコンサルティング」を、あなたのビジネスにも適用しませんか?

対象となる企業様

  • 楽天、Amazon、auPAYマーケット等での販売を行っている
  • データ分析や在庫管理に課題を感じている
  • AIを活用した業務効率化に関心がある
  • 売上向上のための戦略的なコンサルティングを求めている

まずは無料相談からお気軽にお問い合わせください。


この記事のポイント

  • ✅ 市販FTPツールは複数モール統合、カスタマイズ性、信頼性に限界
  • ✅ 長期的なコスト削減とノウハウ蓄積のため自作を決断
  • ✅ 確実性、リアルタイム性、可観測性、拡張性を設計思想に
  • ✅ 5ヶ月の開発でデータ取得を100%自動化、時間削減95%達成
  • ✅ 年間60万円〜120万円のコスト削減、初年度でROIプラス
  • ✅ AIコンサルへの道を開く高品質データ基盤が完成