DandoriAIと基幹システムの連携方法｜大企業導入で選ぶ2つのアーキテクチャ

はじめに

DandoriAIは、シンシアが開発したAI見積もりエージェントです。商談メモや議事録、メールから自動で見積もりを生成し、サプライヤーとのやり取りを一元管理できる仕組みを提供しています。

中小企業での活用はもちろんですが、最近は大企業・上場企業からの引き合いも増えてきました。そこで必ず話題になるのが「既存の基幹システムとどうつなぐか」という問いです。この記事では、私たちが実際に採用している2つの連携アーキテクチャと、それぞれのセキュリティ設計の考え方を整理します。

なぜ基幹システムとの連携が必要なのか

DandoriAIは、見積もり→発注→請求というフローを自動化します。しかし、大企業の現場では見積もりデータがSAP・OBIC・勘定奉行などの基幹システム（ERP）に集約されており、DandoriAIが単独で動くだけでは業務は完結しません。

具体的には以下のようなデータを基幹システムと同期する必要があります。

仕入先マスタ・単価マスタ
発注実績・受注実績
在庫情報
会計仕訳データ

これらを手動でコピペしていては、AIで自動化した意味が薄れます。基幹システムとの連携設計が、DandoriAI導入の成否を左右すると私は考えています。

2つの連携アーキテクチャ

シンシアでは、顧客のセキュリティ要件・IT環境・運用体制に応じて、主に2つのアーキテクチャを使い分けています。

アーキテクチャ1：API直接連携

基幹システムがAPIを公開している、またはAPIを追加開発できる場合に採用します。DandoriAIと基幹システムをリアルタイムで繋ぎ、マスタデータや実績データを即時同期します。

【API直接連携の構成】

┌────────────────────────────────────────────┐
│                  AWS VPC                   │
│                                            │
│  ┌──────────────┐    API    ┌───────────┐  │
│  │  DandoriAI   │◄────────►│  API GW   │  │
│  │  (ECS)       │  HTTPS   │ (Lambda)  │  │
│  └──────────────┘          └─────┬─────┘  │
│                                  │        │
│                         PrivateLink/      │
│                         VPC Peering       │
│                                  │        │
└──────────────────────────────────┼────────┘
                                   │
               ┌───────────────────▼──────────────┐
               │        顧客の基幹システム           │
               │  (SAP / OBIC / 勘定奉行 / 独自ERP) │
               └────────────────────────────────────┘

メリット： データがリアルタイムで同期される。見積もり作成時に最新の単価・在庫情報を参照できる。

適用条件： 基幹システム側にAPIが存在する（またはシンシアが開発できる）こと。ネットワークレベルでの接続が許可されていること。

シンシアの役割： 基幹システム側のAPIを設計・実装し、DandoriAI側のコネクタも開発します。認証はOAuth 2.0またはAPIキー＋IP制限の組み合わせが標準です。

アーキテクチャ2：CSVバッチ同期（セキュリティ重視）

「外部サービスとの常時接続は認められない」「基幹システムをネットワークに開放できない」という大企業・金融・製造業では、このアーキテクチャが現実解です。

【CSVバッチ同期の構成】

┌───────────────────────────────────────────────────┐
│                     AWS VPC                        │
│                                                    │
│  ┌──────────────┐        ┌──────────────────────┐  │
│  │  DandoriAI   │        │  S3（暗号化バケット）  │  │
│  │  (ECS)       │◄──────►│  KMS暗号化 / WORM     │  │
│  └──────────────┘ Import │  バケットポリシー     │  │
│                   Export └──────────┬────────────┘  │
│                                     │               │
│  ┌──────────────────────────────┐   │ S3イベント    │
│  │  Lambda バッチ処理           │◄──┘               │
│  │  （CSV検証・変換・取込）      │                   │
│  └──────────────────────────────┘                   │
└───────────────────────────────────────────────────┘
                          ▲
           CSV転送（SFTP / AWS Transfer Family）
                          │
         ┌────────────────┴──────────────────────┐
         │          顧客の社内ネットワーク          │
         │  基幹システム → 定期CSVエクスポートバッチ │
         │  （夜間バッチ / 1時間ごと など）         │
         └───────────────────────────────────────┘

メリット： 基幹システムをネットワークに開放しない。CSV転送のみなのでセキュリティ審査を通りやすい。既存の夜間バッチに相乗りできる。

適用条件： 多少のデータ鮮度の遅延（数時間〜翌日）が許容できること。

シンシアの役割： AWS Transfer Family（SFTP）またはAWS DataSyncを使ったCSV取込パイプラインを構築します。CSVのフォーマット変換・バリデーション・エラーハンドリングをLambdaで実装し、CloudWatch Alarmsで異常を監視します。

セキュリティ設計：ISMSを見据えた構成

どちらのアーキテクチャを採用するにしても、大企業との契約ではセキュリティ要件が必ず論点になります。

シンシアは現在、ISMS（ISO/IEC 27001）の認証取得に向けて準備を進めています。認証取得を前提に、以下のセキュリティ対策をDandoriAIのインフラ標準として実装しています。

AWSインフラのセキュリティ標準

対策項目	実装内容
通信暗号化	すべての通信をTLS 1.2以上で保護
データ暗号化	S3・RDS・EBSをAWS KMSで暗号化
ネットワーク分離	VPC・プライベートサブネット・セキュリティグループで最小権限アクセス
アクセス管理	IAMロールによる最小権限原則、MFA必須
監査ログ	AWS CloudTrail・VPCフローログを有効化、S3に長期保管
脆弱性管理	Amazon Inspectorによる定期スキャン
バックアップ	RDS自動バックアップ、S3クロスリージョンレプリケーション

API連携時の認証・認可

API直接連携の場合は、以下を標準とします。

OAuth 2.0 Client Credentials（サービス間認証）
IPホワイトリスト（AWS Elastic IPで固定）
リクエスト署名（AWS Signature V4またはHMAC）
レート制限（API Gateway + WAFで実装）

CSV連携時のセキュリティ

CSVバッチ同期の場合は、以下を標準とします。

SFTP認証：公開鍵認証のみ（パスワード認証は無効）
転送後の検証：ハッシュ値（SHA-256）で改ざん検知
保管期間制御：S3ライフサイクルポリシーで自動削除
アクセスログ：S3サーバーアクセスログ＋CloudTrailで全操作を記録

API連携とCSVバッチ、どちらを選ぶか

私がお客様に説明するときの判断軸をまとめます。

観点	API直接連携	CSVバッチ同期
データ鮮度	リアルタイム	数時間〜翌日
基幹システムへの影響	APIが必要	変更不要（CSV出力のみ）
セキュリティ審査	ネットワーク開放が必要	通りやすい
開発工数	中〜大	中
向いている業種	SaaS・EC・小売	製造・金融・官公庁系