こんにちは、UPSHAREのAIエンジニアです。普段はMCP（Model Context Protocol）やAPI、AIエージェントを駆使して、業務自動化の検証と実装を行っています。新しい技術はワクワクしますが、それ以上に「現場で本当に使い物になるか」という冷めた視点も忘れないようにしています。
さて、業務自動化の要となるAPI連携ですが、皆さんは「もしAPIが止まったら？」と考えたことはありますか？「便利だから」と自動化を導入したものの、エラーが起きた瞬間に業務が完全にストップしてしまう……そんな事態は避けたいものです。今回は、API連携が止まっても業務を止めないための「エラー設計」について、現場で使える判断基準をお話しします。
エラーは「起きるもの」として設計する
まず大前提として、外部APIは必ずエラーを返します。ネットワークの瞬断、相手先サーバーのメンテナンス、あるいはAPIの仕様変更など、理由は様々です。エラーを「異常事態」と捉えるのではなく、「システムの一部」として組み込むのが、止まらない自動化の第一歩です。
現場では、エラーが発生した際にどう対処するかを、以下の3つのパターンで分類しています。
- Abort（中断・報告）：処理を止めて、人間が介入する。
- Retry（再試行）：少し時間を置いてから、もう一度試す。
- Ignore（無視・続行）：エラーを記録しつつ、次の処理へ進む。
例えば、重要な決済処理なら「Abort」で確実に止めるべきですが、大量のメール通知なら「Ignore」でエラーをログに残しつつ、他の通知を優先させるのが賢い選択です。すべてを「止める」設定にすると、たった一つのエラーで業務全体が麻痺してしまいます。
「どこで止めるか」の判断基準
エラーへの対処は、プログラムの「リーフ（末端）」に近い場所で行うのが鉄則です。外部APIを叩く直前のコードが、最もその処理の文脈を知っているからです。逆に、プログラムのルート（全体を制御する場所）でリトライを判断しようとすると、実装が複雑になりすぎてメンテナンスが困難になります。
私たちアップシェアでは、Web制作や業務システム開発の現場で、AIを工程全体に組み込んで試行錯誤しています。その経験から言えるのは、「自動化の範囲を小さく区切る」ことが、結果としてシステム全体の安定につながるということです。大きな一つの自動化フローを作るのではなく、小さな処理を積み重ねることで、どこでエラーが起きても影響範囲を最小限に抑えられます。
UIとバックエンドの二重構え
エラー設計において、ユーザー体験（UX）を損なわない工夫も重要です。例えば、入力値のバリデーション（検証）は、フロントエンドで即座にチェックしてユーザーにフィードバックを返しつつ、バックエンドでも必ず最終チェックを行う「二重構え」が基本です。
「フロントでチェックしているから大丈夫」と油断してはいけません。APIは直接叩かれる可能性もあるため、サーバー側でのガードは必須です。また、操作できないボタンをUI上で非活性にするなど、そもそもエラーが発生しないような「予防的な設計」も、立派なエラーハンドリングの一部です。
まとめ：翌日から使える判断基準
最後に、明日から使える判断基準をまとめます。
- エラーを握りつぶさない：ログには詳細を残し、ユーザーには適切なメッセージを返す。
- 冪等性（べきとうせい）を確認する：リトライしても同じ結果になるか（二重送信されないか）を必ず確認する。
- 自動化の粒度を細かくする：エラーの影響範囲を限定する。
自動化は「導入して終わり」ではありません。エラーが起きたときに、人間がどうリカバリーできるかという「業務継続計画（BCP）」の視点を持つことが、真に役立つシステムを作る鍵となります。技術はあくまで手段。業務を止めないための設計を、ぜひ皆さんの現場でも取り入れてみてください。
