シンガポールのデジタル銀行トラスト銀行（Trust Bank）は、障害が起きたときの初動の切り分けを、人工知能のエージェントで短くしています。コンピュータ・ウィークリー（Computer Weekly）が2026年9月30日付で、最高技術責任者（CTO）のスリニバス・パティル（Srinivas Patil）氏への取材を伝えました。以前は15〜20分かかっていた初動が、約2分になったとします。手順は運用手順書（ランブック）で進め、分析はエージェントが行い、チケットへ出すのは勧告だけです。本番への変更は人が確かめてから行います。
トラスト銀行は、スタンダードチャータード（Standard Chartered）とフェアプライス・グループ（FairPrice Group）が出資するデジタル銀行で、2022年9月に開業しました。窓口はアプリが中心のため、一部の利用者でも止まる体験は銀行が止まったのと同じ重みを持ちます。測る指標の中心は、障害が起きてから直るまでの平均時間（MTTR）です。
開業当初は小さな単位に分けたサービス（マイクロサービス）がおよそ50本でしたが、いまは180本を超え、週に100件を超える変更を流します。以前は呼び出し当番の技術者（オンコール）が、基盤側かサービス側かを見極め、原因分析（RCA）をしてから緩和策を決めていました。手順を自動実行するランブックは、変更が速くて古くなり更新が追いつきませんでした。データをまとめてモデルへ渡す試作も、結果を一貫して信頼できず、より危ういと判断しました。
いまの形はハイブリッドです。ランブックが決めた手順でログやデータを取り、モデルが分析して原因の仮説と根拠を障害チケットへ書きます。通話が始まる前に、仮説と根拠の投稿が揃う想定です。エージェントは勧告だけを出し、実行は人が検証したあとです。ランブックは、正しい信号と手順を拾えるかを確かめる基準データ（ゴールデンデータセット）で検査します。エージェントが出す原因分析のうち、およそ65%はすぐ行動に移せ、残りおよそ35%は端のケースで人の専門知が必要だ、とします。
基盤はほぼアマゾン ウェブ サービス（AWS）上のアマゾン・ベッドロック・エージェントコア（Amazon Bedrock AgentCore）を借ります。サイト信頼性エンジニアリング（SRE）は3人で、自前のエージェント基盤は持たない方針です。障害連絡にはページャーデューティ（PagerDuty）、ログにはスモー・ロジック（Sumo Logic）も使い、各ツールのデータを横断して仮説を整える点に価値があります。障害の分析では、アンソロピック（Anthropic）のクロード・オーパス（Claude Opus）を推論に、クロード・ハイク（Claude Haiku）を軽い作業に使い分けます。
| 公表されている説明 | こちらで確認できていないこと |
|---|---|
| 2026-09-30、コンピュータ・ウィークリーがCTOインタビューを公開 | トラスト銀行公式サイトでの同数字の一次掲載 |
| 障害の初動切り分けが15〜20分から約2分（同） | 測定期間・件数分布・第三者による再測定 |
| ランブックで手順実行、AIが分析し根拠つき仮説をチケットへ（同） | ランブックの公開テンプレートと対象サービスの一覧 |
| AIは勧告のみ。実行は人が検証してから（同） | 誤勧告の件数と重大度の社内定義 |
| RCAの約65%が行動可能。残り約35%は端ケース（同） | 「行動可能」の判定基準と監査期間 |
| ランブックをゴールデンデータセットで検証（同） | データセットの規模と更新頻度 |
| マイクロサービス180超・週100件超の変更（同） | 変更失敗率とエージェント導入前後の比較表 |
| エージェントコアを採用。SREは3人で自前基盤を避けたい（同） | エージェントコア利用料とトークン費用の内訳 |
| クロード・オーパス／ハイクを役割分担。設計を確認する審査会（アーキ審査会）へ提出（同） | モデル切替の成功率と却下理由の一覧 |
| 変更レビュー用エージェントと本番後4週間監視の実験（同） | 本番導入の範囲と効果の定量 |
| 「AIの問題」のおよそ80%は普通の工学、AIが効くのはおよそ20%との見立て（同） | 見立ての根拠データと対象範囲の定義 |
約2分や約65%は、取材でのトラスト側の説明です。独立した第三者の再測定は、本稿執筆時点では見つかっていません。
従業員100〜200人規模の部品メーカーでは、生産ラインの警報時に確認手順をスクリプトで回し、ログ要約と疑わしい工程だけをエージェントに書かせ、現場責任者が止める・流すを決めます。接骨院や整形外科の予約システムでは、再現手順と直近の設定変更をチケットへ自動で添え、夜間当番が電話に出る前に仮説を揃えます。ビジネスホテルや旅館では、予約連携の停止時に外部接続・料金表・在庫の順で調べるランブックを固定し、分析だけを短くします。商店街の共同サイトでは、決済や在庫の障害で店舗への連絡文案まで勧告に含め、公開操作は管理者が押します。
障害の初動では、手順をランブックで固定し、分析をエージェントに任せ、チケットへ根拠つきの勧告だけを出します。初動の短縮や行動可能な割合は発表側の数字として残し、実行は人が確かめてから行います。変更が速い現場ほど、古くなった手順だけに頼らず、検査用のデータでランブックを保ちながら広げます。
