Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
外部IF ファイル連携仕様
外部システムとのファイル連携仕様を標準化し、データの確実な授受と整合性を保証します。ファイル形式、転送方式、エラーハンドリングを体系的に定義します。
🎯 概要
- 目的: 外部システムとのファイル連携における仕様を明確に定義し、データの確実な授受と整合性を保証する。ファイル形式、転送方式、エラーハンドリングを標準化することで、安定した連携を実現する
- スコープ: 外部システムとの間で行われるファイルベースのデータ連携(CSV、XML、JSON等)の仕様をカバーする。API連携やデータベース直接連携は対象外
- 推奨する実施タイミング: 外部インターフェース設計の段階で、連携先システムと合意形成しながら実施する
- 関連するステークホルダー: システムアーキテクト、連携先システムの担当者、インフラチーム、運用チーム
📥 重要な前提知識・インプット
- 前提知識: ファイル転送プロトコル(SFTP、FTP、HTTP等)、文字エンコーディング、ファイル形式(CSV、XML、JSON等)の仕様、バッチ処理の基礎知識
- インプット: 外部インターフェース一覧、連携先システムの既存仕様書、ファイル連携要件、非機能要件(性能・可用性・セキュリティ)
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]外部IF ファイル連携仕様
- 必須要素: ファイル連携仕様書(インターフェースID、連携方式、ファイル形式、データ項目定義、処理フロー、エラーハンドリング、ファイル保管ルール)
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| ファイル形式の明確性 | 文字コード、区切り文字、改行コード、BOM有無が明記されているか |
| データ項目の網羅性 | 全ての項目について型・桁数・必須/任意・制約が定義されているか |
| エラーハンドリング | 想定されるエラーケースと対処方法が定義されているか |
| セキュリティ | 転送時の暗号化、認証方式、アクセス制御が考慮されているか |
| 運用考慮 | ファイル保管期間、リトライ方針、監視項目が明確か |
👁️🗨️ レビュー観点:
- 連携先との合意: ファイル仕様について連携先システムの担当者と合意が取れているか
- データ整合性: データの重複、欠損、不整合を検出・防止する仕組みがあるか
- 性能要件: ファイルサイズ、処理時間、連携頻度が要件を満たしているか
- 障害時の対応: ファイル転送失敗時のリトライ、エスカレーション、復旧手順が明確か
- テスト容易性: 正常系・異常系のテストケースが定義可能な仕様になっているか
🧪成果物のサンプル
# IF-003: マスタデータ取込
**概要:**
マスタ管理システムから商品マスタや分類マスタ等の基礎データをCSVファイル形式で日次バッチ処理により取り込むファイル連携インターフェース。毎日深夜に最新のマスタデータを取得し、本システムのデータベースを更新することで、マスタデータの同期を実現する。
**連携方式:**
- プロトコル: SFTP
- 連携頻度: 日次(毎日 AM 2:00)
- ファイル形式: CSV(UTF-8、BOM無し)
**ファイル配置:**
```
/data/import/master_YYYYMMDD.csv
```
**ファイル命名規則:**
```
{ファイル種別}_{YYYYMMDD}.csv
例: master_20251120.csv
```
**CSV仕様:**
```csv
product_id,product_name,category,price,stock
P001,商品A,カテゴリ1,1000,50
P002,商品B,カテゴリ2,2000,30
```
**列定義:**
| 列No | 項目名 | 型 | 桁数 | 必須 | 備考 |
|------|-------|-----|-----|-----|------|
| 1 | product_id | 文字列 | 10 | ○ | 商品ID |
| 2 | product_name | 文字列 | 100 | ○ | 商品名 |
| 3 | category | 文字列 | 50 | ○ | カテゴリ |
| 4 | price | 数値 | 10 | ○ | 価格 |
| 5 | stock | 数値 | 5 | ○ | 在庫数 |
**処理フロー:**
1. ファイル取得
2. バリデーション(形式チェック、必須チェック)
3. データ取込(トランザクション処理)
4. 処理結果ログ出力
5. 完了ファイル作成(`master_YYYYMMDD.done`)
**エラーハンドリング:**
- バリデーションエラー: エラーログ出力、管理者通知
- ファイル不存在: リトライ(最大3回、10分間隔)
- 取込エラー: ロールバック、エラーファイル出力
**ファイル保管:**
- 処理済みファイルは7日間保管後削除
- エラーファイルは30日間保管
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: ファイル連携の全体像と基本仕様の定義
設計対象:
外部システムとのファイル連携の全体像を整理し、各連携の基本仕様(プロトコル、頻度、方向性)を定義する。
具体例:
- どの外部システムとどのようなデータをやり取りするのか(マスタデータ、トランザクションデータなど)
- 連携の方向性(送信のみ、受信のみ、双方向)
- 連携のタイミング(リアルタイム、日次、週次、月次など)
- ファイル転送プロトコル(SFTP、FTP、HTTP/HTTPS、共有フォルダなど)
- 連携先システムとの責任分界点(どこまでが自システムの責任範囲か)
設計原則:
- 連携先との早期合意: 仕様策定の初期段階から連携先システムの担当者を巻き込み、双方で合意形成を進める
- 標準化の推進: 複数の連携がある場合、可能な限りファイル形式や命名規則を統一し、保守性を高める
- セキュリティの確保: 転送時の暗号化、認証方式、アクセス制御を適切に設計する
- 監視可能性: ファイル転送の成功/失敗、処理状況を監視できる仕組みを計画する
- トレーサビリティ: いつ、誰が、どのファイルを送受信したかを記録し、追跡可能にする
文書化の推奨表現:
- インターフェース一覧表の作成: 全てのファイル連携を一覧化し、IF-ID、連携先、データ種別、方向、頻度、プロトコルを整理する
- 連携フロー図の作成: システム間のファイル連携の流れを視覚的に表現する
- 責任分界点の明記: 自システムと連携先システムの責任範囲を明確に文書化する
🏗️ プロセス2: ファイル形式とデータ項目の詳細定義
設計対象:
各ファイル連携のファイル形式、データ構造、データ項目を詳細に定義する。
具体例:
- ファイル形式の選定(CSV、TSV、固定長、XML、JSON、Excel等)
- 文字エンコーディング(UTF-8、Shift_JIS等)、BOM有無、改行コード(LF、CRLF等)
- CSVの場合:区切り文字、囲み文字、エスケープ方法、ヘッダー行の有無
- 各データ項目の定義:項目名、データ型、桁数、必須/任意、制約条件、デフォルト値
- ファイル命名規則(タイムスタンプの形式、識別子の付与ルール等)
- ファイル配置場所(ディレクトリパス、完了ファイルの有無等)
設計原則:
- 明確性の確保: 実装者が迷わないよう、全ての仕様を明確に定義し、曖昧さを排除する
- バリデーションの設計: データ型、桁数、必須チェック、相関チェックなどのバリデーションルールを明確にする
- 将来の拡張性: 項目の追加や変更に柔軟に対応できる設計とする(例:予備項目の確保、バージョン管理)
- 文字化け対策: 文字エンコーディングを明確に定義し、連携先と合意する
- テスト容易性: サンプルファイルを作成し、正常系・異常系のテストパターンを用意する
文書化の推奨表現:
- ファイルレイアウト定義書: 項目番号、項目名、データ型、桁数、必須/任意、備考を表形式で整理する
- サンプルファイルの提供: 実際のデータ例を示し、連携先との認識合わせに活用する
- バリデーションルール一覧: 各項目のチェックルールを明記する
- 文字エンコーディング・改行コードの明示: 実装時のトラブルを防ぐため、技術的な詳細を明記する
🏗️ プロセス3: 処理フローとエラーハンドリングの設計
設計対象:
ファイルの送受信処理、データ取込処理、エラー発生時の対処方法を設計する。
具体例:
- 処理フローの定義(ファイル取得→バリデーション→データ取込→完了通知→ファイル保管)
- エラーケースの洗い出し(ファイル不存在、形式エラー、データ不整合、ネットワーク障害等)
- エラー発生時の対処(リトライ、エラーログ出力、管理者通知、エラーファイル出力、ロールバック等)
- リトライ方針(リトライ回数、間隔、リトライ対象のエラー種別)
- ファイル保管ルール(処理済みファイルの保管期間、削除ルール、バックアップ方針)
- 完了ファイルや制御ファイルの使用(ファイル転送完了を示すマーカーファイル等)
設計原則:
- 冪等性の確保: 同じファイルを複数回処理しても結果が変わらないよう設計する
- トランザクション管理: データ取込処理は原子性を保ち、エラー時は確実にロールバックする
- エラー通知の迅速性: 重要な連携の失敗は即座に検知し、担当者に通知する
- ログの充実: 処理の開始/終了、処理件数、エラー内容を詳細にログに記録する
- 運用負荷の軽減: 自動リトライや自動復旧により、運用担当者の手動介入を最小化する
文書化の推奨表現:
- 処理フロー図の作成: シーケンス図やフローチャートで処理の流れを視覚化する
- エラーケース一覧表: 想定されるエラーとその対処方法を表形式で整理する
- リトライ仕様の明記: リトライ回数、間隔、対象エラーを具体的に記載する
- ファイル保管ルールの明示: 保管場所、保管期間、削除タイミングを明確にする
- 監視項目の定義: 運用監視で確認すべき項目(処理成功/失敗、処理時間、ファイルサイズ等)を列挙する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: RFC 4180(CSV形式の仕様)、RFC 959(FTPプロトコル)、各種ファイル形式の公式仕様書
- 関連する他のガイド: システムアーキテクチャ設計ガイド、セキュリティ設計ガイド、バッチ処理設計ガイド、運用設計ガイド
- ツール・テンプレート: draw.io、Mermaid(シーケンス図)、CSV Lintツール、文字コード変換ツール
テンプレートサイト: 📄テンプレート集