業界が違えば、障害モードも違う

エンジニアリング課題

バッチでしか連携できない基幹システム

勘定系や保険契約管理のプラットフォームは夜間ファイルでデータを公開することが多い一方、デジタルチャネルは最新の残高や契約状況をミリ秒単位で求めます。この両者をつなぐには、変更データキャプチャ（CDC）とAPI層、そしてバッチ実行の合間にどちらを正とするかの明確なルールが必要です。

時間に追われる日次締め処理

決済、利息計上、規制当局向けデータ抽出は決められた時間枠の中で完了させなければならず、ジョブが1本失敗するだけで後続すべてが遅延しかねません。ジョブはチェックポイントから再開でき、かつ冪等である必要があります。そうすれば、再実行しても仕訳が二重に計上されることはありません。

商品と法人をまたぐ権限管理

誰が取引を参照・承認できるかは、ロール、デスク、法人、顧客との関係、限度額によって決まります。こうしたルールが各アプリケーションに散在していると、アクセス権の棚卸しは推測頼みになり、職務分掌を証明できません。

規制報告のためのデータリネージ

規制報告に記載した数値は、その元になった取引まで遡れなければなりません。文書化されていない変換処理やスプレッドシートでの手作業で組まれたパイプラインでは、その追跡を再現できません。

構築するもの

• 勘定系・保険契約管理システムの前段に置くAPI層とイベント層
• 再開可能なバッチ処理と決済処理
• 権限管理と承認の集中管理サービス
• カラム単位のリネージを備えた報告用データプラットフォーム
• 顧客オンボーディングとケース管理のワークフロー

• バックエンドエンジニアリング
• データエンジニアリング
• サイバーセキュリティ
• クラウド・インフラ

エンジニアリング課題

リトライによる二重の資金移動

自社サービスと決済プロバイダーの間でタイムアウトが起きると結果は不明のままとなり、無条件にリトライすれば顧客に再度請求してしまうおそれがあります。状態を変更する呼び出しにはすべて、その効果とアトミックに保存される冪等キーが必要です。

遅延・重複・順序の乱れを伴うWebhook

プロバイダーはステータス更新を少なくとも1回（at-least-once）で配信し、順序は保証しません。そのため、返金通知が対象の売上確定より先に届くこともあります。決済の状態は永続化されたステートマシンとして持ち、不正な遷移を拒否し、重複を許容できなければなりません。

裏付けとなる仕訳のない残高

ウォレット残高を書き換え可能な1つの数値として保持すると、監査ができず、同時利用時に競合状態を起こしやすくなります。残高は追記専用の複式簿記の台帳から導出し、金額は最小通貨単位の整数と明示的な通貨で扱うべきです。

数週間後に見つかる照合の不一致

社内の記録、プロバイダーの精算レポート、銀行取引明細は、タイミング、手数料、参照番号の点で食い違います。日次の自動照合がなければ、小さな差異が積み重なり、やがて原因を特定できなくなります。

構築するもの

• 複式簿記の台帳とウォレットサービス
• プロバイダーアダプターを備えた決済オーケストレーション
• 融資の実行（オリジネーション）と返済スケジュール
• KYC、スクリーニング、取引モニタリングの連携
• 自動照合（リコンサイル）と例外処理

• バックエンドエンジニアリング
• サイバーセキュリティ
• データエンジニアリング
• DevOps・DevSecOps

エンジニアリング課題

攻撃者の手が届くホットウォレットの鍵

アプリケーションサーバー上に置かれた署名鍵は、そのサーバーを侵害した者なら誰でも手にでき、しかもオンチェーンの送金は取り消せません。鍵はHSM（ハードウェアセキュリティモジュール）またはMPC（マルチパーティ計算）で保持し、すべての署名をポリシーに照らして検査する必要があります。

ファイナリティ前に反映される入金

直近のブロックで確認されたトランザクションは、ユーザーがすでにそれを元に取引した後で、チェーンの再編成（リオーグ）によって消えることがあります。確認数のしきい値はネットワークごとに設定し、インデクサーは分岐点までロールバックして再処理できなければなりません。

滞留する出金とnonceの欠番

手数料が低すぎるトランザクションはmempoolに滞留し、同じアカウントからの後続トランザクションをすべて止めてしまうことがあります。出金パイプラインには、明示的なnonce管理、手数料の差し替えルール、そして1リクエストにつき送金1件という保証が必要です。

顧客に対する負債とオンチェーン保有高の乖離

内部台帳とプラットフォームのアドレス残高は、入金の検知漏れ、未記録のネットワーク手数料、スイープの失敗によって乖離していきます。アセットごとの照合を継続的に実行し、不足が生じた時点でアラートを上げる必要があります。

構築するもの

• カストディとポリシー制御された署名サービス
• 入金検知パイプラインと出金パイプライン
• マッチングエンジンと内部決済台帳
• オンチェーンモニタリングとアドレスリスクのスクリーニング
• トレジャリー管理と保有証明のための照合ツール

• ブロックチェーン・Web3
• サイバーセキュリティ
• バックエンドエンジニアリング
• クラウド・インフラ

エンジニアリング課題

モデルの挙動に対する回帰テストの不在

プロンプトの微調整やモデルのアップグレードは、1件を直して10件を壊すことがあります。評価セットがなければ、その不具合を見つけるのはユーザーです。品質を保つには、デリバリーパイプラインで実行されリリースの可否を判定する、スコア付きのデータセットが必要です。

売上より速く増える推論コスト

長いコンテキスト、些細なタスクへの大型モデルの利用、キャッシュされない同一クエリの繰り返しは、利用量の伸びを利益率の低下に変えてしまいます。タスクの難易度に応じたルーティング、キャッシュ、コンテキストの削減、バッチ処理を、サービング経路に組み込んで設計する必要があります。

遊休か枯渇かのGPUキャパシティ

セルフホストのモデルに必要なアクセラレーターは、遊ばせておくには高価で、スパイクが来てから調達するには時間がかかります。サービングには、リクエストのバッチ化、キューの深さに基づくオートスケーリング、キャパシティが尽きた場合のフォールバック経路が必要です。

ツール呼び出しモデルに届く信頼できない入力

ドキュメントやWebから取得したコンテンツには、モデルがユーザーからの指示であるかのように従ってしまう命令が含まれていることがあります。ツールの権限は呼び出し元のユーザーの範囲に限定し、取得したコンテンツは決して命令としてではなく、データとして扱わなければなりません。

構築するもの

• AIプロダクト向けの検索（リトリーバル）・オーケストレーションのバックエンド
• 評価ハーネスと品質ゲート
• ルーティング、キャッシュ、コスト配賦を備えたモデルゲートウェイ
• GPUオートスケーリングを備えたKubernetes上のモデルサービング
• ガードレールとプロンプトインジェクション対策

• AIエンジニアリング
• データエンジニアリング
• クラウド・インフラ
• サイバーセキュリティ

エンジニアリング課題

全チームが同時にリリースせざるを得ないモノリス

1つのコードベースと1つのデータベースがすべての機能を支えていると、小さな変更でも全体の回帰テストを待つことになり、あるチームの不具合が他の全チームを止めます。サービスを切り出す前に、モジュール境界とデータの所有権を確立しておく必要があります。

顧客ごとのフォーク

大口顧客向けの個別対応は長寿命のブランチとして残り、それぞれに個別のパッチ適用とテストが必要になります。顧客ごとの差異は、単一のコードベース上の設定、拡張ポイント、フィーチャーフラグとして表現すべきです。

顧客側のアップグレードで壊れる連携

エンタープライズの顧客は、連携先システムのバージョンをそれぞれ異なるスケジュールで運用しています。バージョン管理されたAPIコントラクトとアダプターによる分離がなければ、顧客がアップグレードするたびにインシデントになります。

単一コードベースでのオンプレミスとクラウドの両対応

顧客によっては自社環境へのデプロイを求めますが、そこでは提供側がシステムを直接監視することも、パッチを当てることもできません。パッケージング、アップグレード、診断の仕組みは、自社のクラウドコントロールプレーンを前提とせずに機能する必要があります。

構築するもの

• ドメイン境界を強制するモジュラー構成のバックエンド
• 拡張機構とプラグインフレームワーク
• バージョン管理された公開APIとSDK
• 顧客ホスト環境向けのインストーラーとアップグレードツール
• 監査ログとエンタープライズ向けアクセス制御

• ソフトウェアエンジニアリング
• バックエンドエンジニアリング
• DevOps・DevSecOps
• フロントエンドエンジニアリング

エンジニアリング課題

テナントフィルターの付け忘れ

すべてのクエリにテナント条件を含めることを前提にした分離では、1か所の漏れである顧客に別の顧客のデータが見えてしまいます。分離は、行レベルセキュリティやテナント別のデータストアによって、アプリケーションより下の層で強制する必要があります。

1テナントが全体を劣化させる問題

ある1社による大量インポートや高負荷のレポートが、共有のデータベース接続やキューを飽和させることがあります。テナント単位のレート制限、クォータ、ワークロード分離によって、1テナントの負荷がプラットフォーム全体のインシデントになるのを防ぎます。

誤って集計される利用イベント

負荷時に欠落したり、リトライで重複したりした計測イベントは、顧客から異議が出る請求書につながります。イベントには冪等キーと耐久性のある転送経路、そして再実行と説明が可能な集計処理が必要です。

テーブルをロックするスキーママイグレーション

大きなテーブルを書き換えるマイグレーションは、全テナントの書き込みを一斉に止めてしまいます。変更はexpand and contractの手順に従い、新旧のアプリケーションバージョンが同じスキーマに対して動作できるようにする必要があります。

構築するもの

• テナントのコントロールプレーンと自動プロビジョニング
• SSO、SCIM、ロールベースアクセス制御の連携
• 利用量メータリングと課金のパイプライン
• エンタイトルメントとフィーチャーフラグのサービス
• ゼロダウンタイムのリリース・マイグレーションパイプライン

• ソフトウェアエンジニアリング
• クラウド・インフラ
• DevOps・DevSecOps
• バックエンドエンジニアリング

エンジニアリング課題

フラッシュセール時の売り越し

多数の購入者が残りわずかな在庫を同時に決済しようとすると、読み取ってから書き込む方式の在庫確認では複数の注文が通ってしまいます。在庫には有効期限付きのアトミックな引当と、ピーク時にデータベースを保護するキューまたはレート制限が必要です。

中途半端に完了するチェックアウト

決済は成功したのに注文の書き込みが失敗する、あるいはその逆が起きると、請求だけされて注文が存在しない顧客が生まれます。チェックアウトは、各ステップに補償処理を備えた冪等なSagaとして実装し、その背後に照合ジョブを置く必要があります。

遅い、または古いカタログページ

すべての商品ページをリクエストごとにレンダリングすると高負荷時に遅くなり、積極的にキャッシュすれば古い価格や在庫が表示されます。解決策は、商品と価格の変更イベントに連動したレンダリング戦略とキャッシュ無効化戦略です。

役に立つ結果を返さない検索

買い物客は綴りを間違え、同義語を使い、カタログ上で表記が統一されていない属性で絞り込みます。検索には、専用のインデックス、正規化された属性、そして実際のクエリに基づいて計測する関連度チューニングが必要です。

構築するもの

• エッジキャッシュを備えたヘッドレスストアフロント
• 在庫引当と受注管理のサービス
• 冪等なチェックアウトと決済連携
• 商品検索とレコメンデーションのバックエンド
• マーケットプレイスの出店者オンボーディングと支払いシステム

• フロントエンドエンジニアリング
• バックエンドエンジニアリング
• モバイルエンジニアリング
• クラウド・インフラ

エンジニアリング課題

データモデルを共有しない臨床システム

記録はHL7 v2メッセージ、FHIRリソース、DICOMスタディ、独自形式のエクスポートとして届き、それぞれコード体系に施設ごとの差異があります。連携には、これらを正準モデルへマッピングして検証し、マッピングできないものを明示するエンジンが必要です。

重複・不一致のある患者ID

同じ患者が施設ごとに異なる識別子や表記で登録されており、誤った記録を統合することは安全上のリスクになります。名寄せには決定論的ルールと確率的ルールの両方が必要で、判断のつかないケースは人によるレビューに回します。

誰も説明できない記録へのアクセス

臨床医には緊急時の例外アクセスを含む迅速なアクセスが必要ですが、記録の閲覧はすべて誰によるものか特定できなければなりません。そのためには、きめ細かな認可、ブレークグラス手順、改ざんできないアクセスログが求められます。

オフラインでも動き続ける必要があるソフトウェア

病棟、診療所、訪問先では通信が途切れることがあり、医療は回線の復旧を待てません。アプリケーションには、ローカルストレージ、競合を考慮した同期、そして未送信の内容を明確に示す表示が必要です。

構築するもの

• HL7およびFHIRの連携サービス
• 患者・臨床医向けのWebおよびモバイルアプリケーション
• 同意管理、アクセス制御、監査ログ
• 匿名化パイプラインを備えた臨床データプラットフォーム
• 臨床文書と保険請求書類のドキュメントインテリジェンス

• バックエンドエンジニアリング
• データエンジニアリング
• サイバーセキュリティ
• モバイルエンジニアリング

エンジニアリング課題

遅延・重複・順序の乱れを伴う運送会社イベント

追跡情報の更新は、多数の運送会社からAPI、EDIファイル、メールを通じて届き、配達完了のスキャンが持ち出しのスキャンより先に届くこともあります。出荷のタイムラインは、重複排除と遅延到着の許容を組み込んだうえで、イベント発生時刻から再構築しなければなりません。

高頻度の位置情報データ

数千台の車両が数秒ごとに位置を報告すると、書き込み中心のストリームとなり、トランザクション型データベースでは扱いきれません。テレメトリーはストリーミングパイプラインと時系列ストアで受け、業務用のテーブルには導出した状態だけを書き込みます。

電波の届かないドライバーアプリ

配達証明は、地下、エレベーター内、地方部といったネットワークのない場所で取得されます。モバイルアプリはオフラインで動作し、署名や写真をキューに保持し、重複を生まずに同期できなければなりません。

現実によって崩れる配送ルート計画

渋滞、配達の失敗、新規注文によって、朝の計画は昼には使えなくなります。再最適化は数秒以内に差分で実行でき、配達時間帯、積載容量、ドライバーの労働時間を守る必要があります。

構築するもの

• 出荷イベントの取り込みと追跡のプラットフォーム
• 運送会社連携とEDI連携のレイヤー
• オフラインファーストのドライバー向け・倉庫向けモバイルアプリ
• テレメトリーパイプラインと到着予定時刻の算出サービス
• 配車、ルーティング、例外管理のツール

• バックエンドエンジニアリング
• データエンジニアリング
• モバイルエンジニアリング
• クラウド・インフラ

エンジニアリング課題

障害時にも営業を続けなければならない店舗

本部との常時接続に依存するPOS端末は、回線が切れた時点で販売できなくなります。レジには、取引のローカル保存と、接続回復時に競合を解決する遅延同期が必要です。

チャネルごとに異なる在庫数

店舗システム、倉庫、Webサイトはそれぞれ独自の在庫数を持ち、異なるタイミングで更新されます。店舗受け取りや店舗出荷は、ほぼリアルタイムの在庫イベントを取り込む単一の在庫照会サービスに依存します。

多店舗にまたがる価格・販促の変更

販促は、レジ、棚札、オンラインで同時に開始しなければならず、重複する特典はどこでも同じ結果に解決される必要があります。そのためには、単一の価格エンジンと、各店舗が変更を適用したことを確認できる配信の仕組みが必要です。

1人の顧客に複数のプロファイル

ロイヤルティ、Eコマース、店舗の各システムは、顧客をそれぞれ異なる方法で識別しています。これらを統合するには、同意の追跡を伴うID解決が必要です。それによって、パーソナライズと本人からの開示・削除等の請求への対応を、1つのレコードから行えるようになります。

構築するもの

• オフライン対応のPOSバックエンド
• 統合在庫・在庫照会サービス
• 価格と販促の集中管理エンジン
• ロイヤルティプラットフォームと顧客データパイプライン
• 店舗運営と補充のアプリケーション

• バックエンドエンジニアリング
• データエンジニアリング
• モバイルエンジニアリング
• フロントエンドエンジニアリング

エンジニアリング課題

アプリケーションの速度でのチェーン状態の読み取り

過去のイベントや集計済みの残高をノードに直接問い合わせる方法は、ユーザーインターフェースには遅すぎます。インデクサーがブロックを取り込み、チェーンの再編成に対応し、クエリに最適化されたストアからデータを提供する必要があります。

パッチを当てられないコントラクト

デプロイ済みのコントラクトは、アップグレード経路を設計に組み込んでいない限り変更できず、その経路自体が特権的な統制手段になります。アップグレード可能性、一時停止の仕組み、それらのガバナンスは、デプロイ前に決定しテストしておかなければなりません。

単一障害点となるRPCエンドポイント

1つのノードプロバイダーに依存するフロントエンドやバックエンドは、そのプロバイダーに障害が起きるたびに停止するか、古いデータを返します。リクエストには、独立した複数のソース間でのフェイルオーバーと、同期が遅れたノードの検知が必要です。

ユーザーが離脱するトランザクションフロー

シードフレーズ、ガス用トークン、複数ステップの承認は、専門知識のないユーザーの大半を離脱させます。アカウント抽象化、ガス代の肩代わり（スポンサードトランザクション）、明確なトランザクションシミュレーションは、何に署名しているかを隠すことなく、その摩擦を減らします。

構築するもの

• ファズテストと不変条件テストを備えたスマートコントラクト
• チェーンインデクサーとクエリAPI
• ウォレット連携とアカウント抽象化のフロー
• リレイヤー、キーパー、オフチェーン自動化サービス
• ノードインフラとマルチプロバイダーのRPCゲートウェイ

• ブロックチェーン・Web3
• バックエンドエンジニアリング
• フロントエンドエンジニアリング
• サイバーセキュリティ

エンジニアリング課題

固定予算に対するテレメトリー量

エンドポイント、ネットワーク、クラウドのログは、すべてをインデックス化するには費用が見合わない速度で届きます。パイプラインは取り込み時点でデータをパース、フィルタリング、階層化し、検知ルールが参照するものをホットストレージに、それ以外を低コストのストレージに置く必要があります。

アナリストが無視するようになるアラート

無害な挙動に対して絶えず発報する検知ルールは、本当に重要な1件を埋もれさせます。ルールには、記録済みデータに対するテスト、資産情報とID情報によるコンテキスト付与、そしてコードとして管理されるチューニングが必要です。

100通りのスキーマを持つデータソース

同じイベントでも、製品ごとにフィールド名、形式、タイムスタンプが異なります。相関分析は共通スキーマへの正規化を経て初めて機能します。そのパーサーはバージョン管理し、気づかれないまま壊れていないかを監視する必要があります。

障害を引き起こしかねない自動対応

ホストの隔離やアカウントの無効化を行うプレイブックは高い権限で動作し、誤検知によって起動することもあります。対応アクションには、範囲を絞った認証情報、破壊的なステップに対する承認ゲート、完全な監査証跡が必要です。

構築するもの

• セキュリティデータパイプラインと検知プラットフォーム
• Detection as Codeのリポジトリとテストフレームワーク
• 承認制御を備えた対応の自動化
• ID、シークレット、ポリシー適用のサービス
• エンドポイントとクラウドアカウント向けのエージェントとコレクター

• サイバーセキュリティ
• データエンジニアリング
• DevOps・DevSecOps
• バックエンドエンジニアリング

エンジニアリング課題

途中で止まり、誰にも知らせないスクリプト

スケジュール実行のジョブがあるステップで失敗し、レコードを一部だけ更新した状態で残し、数日後にようやく気づかれます。プロセスには、各ステップを永続化し、一時的な障害をリトライし、滞留したインスタンスを可視化する、耐久性のあるワークフローエンジンが必要です。

数百通りのレイアウトを持つドキュメント

請求書や帳票はスキャン画像やPDFとして届き、その書式は予告なく変わるため、テンプレートベースの抽出は通用しません。抽出には、モデルによる解析、マスターデータとの突合による検証、信頼度の低い項目のレビューが必要です。

メールに埋もれる承認

受信トレイで待たされている依頼には、期限も、エスカレーションも、それが止めているプロセスとの紐づけもありません。承認は、担当者、タイムアウト、代理承認、判断の記録を備えた、追跡可能なタスクでなければなりません。

権限の範囲を超えて動作するAIエージェント

広範な認証情報を持つエージェントは、意図しないアクションを実行するおそれがあります。読み込んだドキュメントに悪意ある指示が含まれている場合はなおさらです。各エージェントには、限定されたツールセット、範囲を絞った権限、そして影響の大きいステップに対する人の承認が必要です。

構築するもの

• 耐久性のあるワークフローとオーケストレーションのプラットフォーム
• ドキュメントの受付と抽出のパイプライン
• ヒューマン・イン・ザ・ループの承認を備えたAIエージェント
• ERP、CRM、財務システムへのコネクター
• プロセス監視と例外キュー

• AIエンジニアリング
• バックエンドエンジニアリング
• ソフトウェアエンジニアリング
• データエンジニアリング