このユニットの結論
API は、システムどうしが決まった窓口を通して、その場でデータをやり取りする便利な方法です。しかし、どんな連携にも向くわけではありません。
大量のデータを運ぶこと、相手が止まっていても動き続けること、相手と意味をそろえることは、API を使うだけでは解決しません。連携ごとに、API の向き・不向きを確かめて方式を選びます。
1. 何の話か
このユニットは、API の限界の話です。
「今どきは API でつなげば何でもできる」と聞くことがあります。たしかに API は、画面で入力した結果をすぐに別のシステムへ渡したり、必要なときに相手の最新の情報を問い合わせたりするのに向いています。一方で、使い方を誤ると、業務の画面が遅くなったり、相手の不調に巻き込まれたりします。
2. なぜ必要か
API の限界を知らずに方式を決めると、
- 大量のデータを1件ずつ送り、処理が終わらない
- 相手のシステムが止まったとたん、自分たちの業務の画面まで使えなくなる
- データは届いているのに、受け取った側で意味を取り違える
ということが起きます。どれも、つないだ直後の少ないデータでのテストでは気づきにくい問題です。
3. このユニットで分かること
- API の得意なことと、苦手なこと
- API を選ぶ前に確かめること
- 「つながる」と「意味が合う」の違い
- 方式の選択で、AIに任せてよいことと人間が決めること
4. API の得意なこと
API（エーピーアイ）は、システムが相手に「この顧客の情報をください」「この登録をしてください」と頼むための、決まった窓口です。
- その場で結果が分かる（登録できたか、情報は何か）
- 最新の情報を、必要なときに取りに行ける
- 1件ずつの小さなやり取りに向いている
画面の操作の中で「今すぐ相手の情報がほしい」「今すぐ相手に知らせたい」場面では、有力な選択肢です。
5. API の苦手なこと
| 苦手なこと | 何が起きるか（一般的な説明） |
|---|---|
| 大量のデータ | 1件ずつの往復を何万回もくり返すことになり、1回の往復は短くても、全体では長い時間がかかる。まとめて渡す方法（07-03）の方が向いていることが多い |
| 相手の停止 | その場でやり取りするので、相手が止まっていれば、こちらの処理もその場で止まる（止まったときの判断は 07-04） |
| 待ち時間 | 相手の返事を待つ間、利用者の画面も待たされる。API を順に何本も呼ぶと、待ち時間が積み重なる |
| 同時に扱える量 | 相手が一度に受けられる件数や回数には上限がある。上限を超えると、断られたり、遅くなったりする |
大切なのは、こうした限界が、つないだ直後の少ないデータのテストでは表に出にくいことです。本番の量と、利用が重なる場面（06-02）を想定して確かめます。
6. 「つながる」と「意味が合う」は別
API でデータが届いても、受け取った側が同じ意味で使えるとは限りません。
（教材上の例）送る側のシステムの「案件の状態：完了」は「作業が終わった」を意味し、受け取る側では「請求まで終わった」と読まれていたとします。データは形式どおりに届きます。しかし、受け取る側では、まだ請求していない案件を請求済みとして扱ってしまいます。
API は、データを運ぶ窓口です。そのデータが何を意味するかは、API の外で、業務の担当どうしが確かめてそろえる必要があります。連携の処理の流れを図にするとき（ARC-005）、受け渡すデータが業務上何を表すかも書いておきます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 約36本のシステム連携。正本で個別に定義されているのは IF-01〜IF-12
- SYS-06 システム連携基盤があり、IF-04〜IF-07 は連携基盤を経由する
- Vendor B / クラウドブリッジの担当範囲に連携が含まれる
アステリア案件の各連携が API を使うか、まとめて渡す方式を使うかは、正本に記載がありません。未確定 このユニットの例は教材上の例で、アステリア案件の連携の設計ではありません。
7. THINK — 「全部 API にすれば、夜間処理は要らない」
（教材上の例）連携の方式を決める打ち合わせで、次の提案が出ました。
「夜間にまとめて処理するのは古いやり方です。全部の連携を API にして、その場で渡しましょう。そうすれば夜間処理はなくせます。」
問題
この提案で、すべての連携の方式を決めてよいでしょうか。
判断例を開く
判断
連携ごとに確かめてから決めます。
確認すること:
- その連携で運ぶデータは、1日にどのくらいの量か。1件ずつの往復で運びきれるか
- 受け取る側は、その場で受け取る必要があるか。少し遅れても業務に困らないか
- 相手が止まっているとき、こちらの業務の画面まで止まってよいか
- 相手が一度に受けられる量に、上限はないか
その場で渡すことが業務に必要な連携には API が向き、大量のデータをまとめて渡す連携には一括処理が向くことがあります。1つの方式に全部をそろえるより、連携ごとに向いた方式を選び、その理由を記録します。
8. よくある失敗
- 新しい方式だからという理由で、すべての連携を API にする
- 少ないデータのテストだけで、本番の量での動きを確かめない
- 相手の返事を待つ間、利用者の画面が待たされることを考えない
- データが届いたことを確かめただけで、受け取った側での意味を確かめない
9. 成果物との接続
- ARC-004 システム連携一覧：連携ごとの方式と、その方式を選んだ理由を書く
- ARC-005 システム連携処理図：処理の流れと、受け渡すデータが業務上何を表すかを図にする
10. AI WORKFLOW — 方式の向き・不向きを整理させる
指示例:
「次の連携の一覧について、連携ごとに、①1日に運ぶデータの量（記載がなければ『記載なし』）、②受け取る側がその場で必要とするか、③相手が止まったときにこちらの業務が止まるか、を表にしてください。どの方式にするかは決めないでください。」
11. REVIEW — AIの整理を確認する
- AIが、データの量や必要な速さを推測で書いていないか
- 「その場で必要か」を、業務の担当に確かめたか
- 表の内容が、連携の一覧の元の記載と合っているか
12. 人間が判断すること
- 連携ごとの方式（その場で渡すか、まとめて渡すか）
- 相手が止まったとき、こちらの業務をどこまで止めてよいか
- 受け渡すデータの意味を、業務の担当どうしでそろえた結果の承認
13. 判断演習
次の2つの連携（どちらも教材上の例）について、API が向いているか、まとめて渡す方法が向いているかを考え、そう考えた理由を書いてください。
- 営業の担当が画面で見積もりを作るときに、別のシステムから顧客の最新の取引条件を確かめる
- 前日に社内で申請された全部の経費の記録を、集計用のシステムへ渡す
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
API は、その場で小さなやり取りをするのに向いた窓口です。万能ではありません。
大量のデータ、相手の停止、待ち時間、同時に扱える量の上限、そしてデータの意味。連携ごとにこれらを確かめて、方式を選びます。