このユニットの結論
システム同士をつなぐ（連携する）ときは、「何のデータを、どこからどこへ、いつ、どの方法で、失敗したらどうするか」を1本ずつ決めます。
連携は、2つのシステムの間の約束です。約束があいまいだと、片方の変更や停止が、もう片方の業務を止めます。
1. 何の話か
このユニットは、システム連携の設計の話です。
アステリア案件では、新基幹システムの前後に、営業・人事・勤怠・会計・分析・認証・監視のシステムがつながっています。連携は、それらの間でデータを受け渡す仕組みです。
2. なぜ必要か
連携がうまく設計されていないと、
- 相手のシステムが止まったとき、データが消えたり二重に届いたりする
- どちらのシステムの担当者が直すのか分からない
- 片方がデータの形を変え、もう片方が読めなくなる
ということが起きます。
3. このユニットで分かること
- 連携ごとに決めること
- 連携の代表的な方法
- アステリア案件の連携の全体像
4. 連携ごとに決めること
一般的には、連携1本ごとに少なくとも次を決めます。
| 決めること | 例（一般的な説明） |
|---|---|
| 何のデータか | 顧客、仕訳など |
| どこからどこへ | 送る側と受け取る側 |
| いつ | 発生のたびに、1日1回の夜間など |
| どの方法で | API、ファイル、一括処理など |
| 失敗したら | 再送するか、誰に知らせるか |
| 誰が担当するか | 送る側・受け取る側・途中の基盤 |
5. 連携の代表的な方法
- API：システムが相手に問い合わせたり、データを送ったりするための決まった窓口。すぐに結果が分かる反面、相手が止まっているとつながらない
- ファイル連携：データをファイルにまとめて受け渡す。大量のデータに向くが、届くまでに時間差がある
- 夜間などの一括処理（バッチ）：決まった時刻にまとめて処理する
- 連携基盤（ハブ）を経由する：システム同士を直接つながず、間に連携専用の仕組みを置く。つなぐ相手が多いときに、管理しやすくなる
どの方法がよいかは、データの量・急ぎ具合・相手の仕組みで決めます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の連携（正本で個別に定義されている12本）
- IF-01 顧客マスター連携：営業管理 → 新基幹
- IF-02 契約情報連携：営業管理 → 新基幹
- IF-03 社員・組織マスター連携：人事 → 新基幹
- IF-04 工数連携：勤怠・工数SaaS → 連携基盤 → 新基幹
- IF-05 売上仕訳連携：新基幹 → 連携基盤 → FIN-CORE
- IF-06：新基幹 → 連携基盤 → FIN-CORE
- IF-07 原価仕訳連携：新基幹 → 連携基盤 → FIN-CORE
- IF-08：新基幹 → BI
- IF-09：FIN-CORE → BI
- IF-10：認証・ID → 新基幹
- IF-11：新基幹 → 監視・ログ
- IF-12：連携基盤 → 監視・ログ
プロジェクト全体の連携は約36本です。
各連携の方法（API・ファイル・一括処理など）、時刻、失敗時の扱いは、正本に記載がありません。未確定 連携の名称・経路の全件は システム・連携 で確認できます。
6. 読み取れること（CASE FACTの読み方）
- 会計（FIN-CORE）への仕訳の連携と、勤怠・工数SaaSからの連携は、システム連携基盤を経由する
- 営業管理・人事から新基幹への連携は、正本では連携基盤を経由しない経路として書かれている
- 監視・ログ基盤は、新基幹と連携基盤の両方から情報を受け取る
経路が違えば、止まったときに調べる場所も、担当する会社も変わります。
7. THINK — 連携基盤が止まった
ある日の朝、システム連携基盤が止まっていることが分かりました。
問題
影響を受ける連携はどれでしょうか。上の CASE FACT から考えてください。
判断例を開く
判断
正本の経路から、連携基盤を経由する IF-04・IF-05・IF-06・IF-07 は影響を受けると考えられます。連携基盤から監視・ログへの IF-12 も影響を受けます。
確認すること:
- 止まっている間のデータが、あとで届くのか、失われるのか
- 同じデータが二重に届く心配はないか
- 業務側で、どの作業が止まるか
- 誰に知らせ、誰が復旧を判断するか
失敗時の扱いが決まっていないと、この判断はできません。
8. よくある失敗
- 連携の方法だけ決め、失敗時の扱いを決めない
- 連携の途中の基盤を、誰が担当するか決めない
- 一覧にない連携が、個別の取り決めで増えていく
- 相手のシステムの変更予定を、連携の担当に知らせない
9. 成果物との接続
- ARC-004 システム連携一覧：連携を1本ずつ一覧にする
- ARC-005 システム連携処理図：連携の処理の流れを図にする
- ARC-001 システム全体構成図：連携を全体の中で見る
相手のシステムが止まったときの考え方は、07-04 相手システムが止まっていたらどうするか で学びます。
10. AI WORKFLOW — 連携の決めごとの抜けを探させる
指示例:
「次の連携一覧を確認し、連携ごとに、データ・送る側・受け取る側・時刻・方法・失敗時の扱い・担当のうち、空欄の項目を挙げてください。空欄を推測で埋めないでください。」
11. REVIEW — AIの結果を確認する
- 空欄とされた項目が、別の設計書で決まっていないか
- AIが連携の方法や時刻を、一般的な例で埋めていないか
- 連携の番号と名称を取り違えていないか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 同期と非同期、時間切れと再試行の予算
返事を待つか、渡して進むか
相手の返事を待ってから次へ進むのが同期、渡して先へ進むのが非同期です。選ぶときの問いは 3 つです。相手の返事がないと業務が進まないか。少しの遅れを許せるか。相手が止まっているとき、自分は動き続けるべきか。たとえば画面からの検索は同期、夜間の集計の受け渡しは非同期が向くことが多いですが、業務の都合で決めます。
時間切れと再試行の予算を決める
相手の返事を待つ時間の上限（時間切れ）と、失敗したときに何回・どの間隔でやり直すか（再試行）を、連携ごとに決めます。待ちすぎると自分も止まり、やり直しすぎると相手をさらに苦しめます。再試行をするなら、同じ処理が 2 回届いても大丈夫な設計（07-05）が前提です。
失敗が続いたら、しばらく呼ばない
相手の失敗が続いているとき、呼び続けると障害が自分にも広がります。一定の回数失敗したら、一定時間は呼ばずに「相手が止まっている」として業務を進める仕組みがあります。世界で共有されている考え方では、サーキットブレーカー（電気の遮断器）にたとえられます。
連携ごとの決めごと表
方式（同期・非同期）、待ち時間の上限、再試行の回数と間隔、相手が止まっているときの業務の動き。この 4 つを連携ごとに表にしておくと、障害のときに「どう動くはずか」をすぐ確かめられます。
現場で確かめる問い
- 連携ごとに、同期か非同期かと、その理由が書かれているか
- 待ち時間の上限と再試行の回数・間隔が、連携ごとに決まっているか。決めていない連携はどれか
- 再試行をする連携で、同じ処理が 2 回届いても大丈夫な設計になっているか
- 相手が止まっているとき、自分の業務はどう続けるか。業務部門と合意した文書があるか
アステリア案件の約36本の連携について、方式や待ち時間がどう決められたかは、正本に記録がありません。記録なし
12. 人間が判断すること
- 連携ごとの方法・時刻・失敗時の扱い
- 連携の途中の基盤を含めた担当の分け方
- 連携を追加・変更するとき、誰が承認するか
13. 判断演習
IF-07 原価仕訳連携（新基幹 → 連携基盤 → FIN-CORE）について、決める必要がある項目を、上の表に沿って書き出してください。
正本に記載がない項目は「未確定」と書き、推測で埋めないでください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
連携は、2つのシステムの間の約束です。
何を、どこからどこへ、いつ、どの方法で送り、失敗したらどうするかを、1本ずつ決めます。