Apr 30, 2026

China-Nexusの秘密のネットワークに対する防衛

◆サイバーセキュリティにおける「China-nexus」とは

中国に関連する国家支援型の攻撃者(APTグループ)を指す用語です。これらの攻撃者は、機密情報の窃取や地政学的な目的(特に台湾情勢に関連する情報収集)のために、世界中の組織を標的としています。 

最新の動向 (2026年4月時点)
  • 侵害されたデバイスのネットワーク: 中国関連の攻撃者は、侵害したルーターなどのエッジデバイスで構築された大規模な匿名ネットワークを悪用し、サイバー攻撃を行っています。
  • 国際共同アドバイザリー: 2026年4月23日、英国、日本、豪州、カナダ、ドイツ、オランダ、ニュージーランド、スペインを含む10カ国が、これらの隠蔽性の高いネットワークに対する共同アドバイザリーを公表しました。
  • 特徴: 従来の静的な防御(IPブロックなど)が効きにくく、ネットワークのトラフィックマッピングなどの適応的な防御が求められています。
  • 具体的な攻撃: 2025年4月頃には、Ivanti Connect Secure VPNの脆弱性を悪用した攻撃が報告されています。 

中国関連のサイバー攻撃者が利用する、侵害されたデバイスで構成される匿名ネットワークの防御に関するアドバイザリーに日本も共同署名 (04/24)

「Raptor Train」と呼ばれる匿名ネットワークは、悪意あるプログラムで乗っ取られた機器で構成された「ボットネット」を利用したもの。主にSOHO向けルーター、ウェブカメラやビデオレコーダーなどのIoTデバイス、ファイアウォール、NASで構成されている。中国の情報セキュリティ企業「Integrity Technology Group」によって構築・維持されているという。

中国政府と関連があるとされる攻撃グループ「Volt Typhoon」「Flax Typhoon」は、Raptor Trainを低コスト・低リスクで匿名性が高い通信経路として、攻撃先のスキャンから、マルウェアの配信、窃取したデータの流出まで、サイバー攻撃のあらゆる段階で悪用しているという。正規のユーザーも利用していることから、悪意のある活動の帰属を特定することが難しくなっている。かつてVolt Typhoonが使用し、2024年のはじめに米国により機能停止させられた「KV Botnet」は、主に脆弱なCiscoおよびNETGEARのルーターで構成されていたという。

 防御策として、エッジデバイスの把握やリモート接続への二要素認証導入、IP許可リスト、ゼロトラストポリシーの適用などが推奨されている。』

Defending Against China-Nexus Covert Networks of Compromised Devices (04/23)


『 ・・・

保護アドバイス

・・・略・・・

すべての組織

NCSCは、影響を受けるすべての組織が自ら行動を起こすか、マネージドサービスおよび/またはセキュリティプロバイダーに調査を依頼するための以下の手順を推奨しています。

  • ネットワークエッジデバイスを地図化して理解し、組織資産とそれらに接続すべき点について明確な理解を育む。
  • ベースラインの通常接続、特に企業の仮想プライベートネットワーク(VPN)やその他の類似サービスへの接続。
    • 消費者向けブロードバンド帯からの接続を期待しますか?
  • 利用可能な動的脅威フィードを活用し、隠れたネットワークインフラを活用できます。
  • リモート接続に対して多要素認証を実装します。

小規模な組織は、無料のNCSCサイバーアクションツールキットの作成と実行を検討すべきである。

リスクの高い組織または大規模組織

組織に対するリスクが十分に高い場合、社内またはセキュリティプロバイダーを通じて実施される場合、より包括的な措置が適している場合があります。

  • リモートワーカー向けの企業VPNへの接続リストを拒否するのではなく、IPアドレスの許可リストを適用してください。
  • オペレーティングシステム、タイムゾーン、および/または組織固有のシステム構成設定に基づいて、地理的許可リストまたはプロファイル入力接続を使用してください。
  • 接続に関するゼロトラストポリシーを実装します。
  • セキュアソケット層(SSL)接続用のマシン証明書をエンコードします。
  • インターネット向けのIT資産の存在感を低下させる。
  • 機械学習技術を調査し、異常な現象を検出・ブロックするために、正常なネットワークエッジ活動を可視化する。

The NCSC's Cyber Essentialsは、あらゆる規模の組織を保護するのに役立ちます。

・・・略・・・

付録:サイバーセキュリティのベストプラクティス

このアドバイザリで示された保護アドバイスに加えて、このアドバイザリーで説明されている活動に対して防御する上で、サイバーセキュリティのベストプラクティスも多数有効となる。



Apr 29, 2026

重大システム障害8選

ITmediaさんの「IT史に名を残すシステム障害」8選 (04/17)の要点を、実務視点で簡潔に整理します。


① IT史に残る重大システム障害(2015年以降・8事例)
共通点
  • クラウド・ネットワーク中核に集約が進んだ結果、単一点のミスや不具合が社会全体に波及
  • 原因の多くは 「人」×「想定不足」
代表的な事例と本質
  1. Dyn(2016)
    • DDoS攻撃(Mirai)でDNS停止
    • SNS・動画・ニュースなど多数のWebサービスに連鎖影響
  2. AWS S3(2017)
    • 停止期間4時間
    • 被害総額: 数百万ドル規模と報道
    • 運用コマンドの入力ミス
    • 「長年再起動していなかった設計」が復旧遅延を招く
  3. Verizon(2019)
    • BGPルーティング情報の誤公開
    • フィルタリング未実施が世界規模障害に拡大
  4. Google(2020)
    • 停止期間45分間
    • 影響  Googleアカウントに依存するサービスで障害
      • Gmail、Google Drive など
      • 認証エラーにより、ログイン不可のユーザーが広範囲で発生
      • 影響ユーザー数の具体記載はなし
    • クオータ管理システム切替ミス
    • フェイルセーフはあったが「想定外パターン」をカバーできず
  5. Fastly(2021)
    • 停止期間 障害発生から 49分以内にネットワークの95%が復旧
    • 潜伏していたソフトウェアバグが設定変更で顕在化
    • 復旧は迅速だが影響範囲は極めて広い
  6. Facebook / Meta(2021)
    • 影響
      • 全データセンターの接続断 
      • 停止したサービス  Facebook、Instagram、WhatsApp
    • メンテナンス作業で全DC接続断
    • 防ぐべき監査ツール自体にバグ
  7. Rogers(2022)
    • 停止期間
      • 約1日間
    • 影響
      • カナダ全土で 1,200万人以上 に影響
      • 利用不可となったサービス
        • 携帯電話回線
        • インターネット
        • 緊急通信サービス
    • ACL削除という単純ミス
    • 通信・緊急通報含め1200万人超に影響
  8. CrowdStrike(2024)
    • 停止・影響継続期間
      • 不具合更新の公開停止:問題発見から約1時間後 
      • センサー 99%復旧宣言:障害発生から10日後 
    • 影響
      • 影響端末数:
        • 約850万台のWindowsデバイスMicrosoft推定)
      • 影響業界
        • 航空(American / United / Delta など)
        • 金融
        • 医療 
      • 一部企業では数日後も完全復旧に至らず 
    • セキュリティ製品の更新不具合
    • Windows端末 約850万台がクラッシュ
    • サプライチェーン型リスクの象徴事例

② システム障害の「よくある3つの原因」
  1. ヒューマンエラー
    • 設定ミス、運用手順ミス、バグ
    • 最も頻発・最も現実的
  2. ハードウェア/環境要因
    • 故障・停電・災害
    • クラウド時代でも消えないリスク
  3. 悪意ある行動(サイバー攻撃)
    • DDoS、不正アクセス、ランサムウェア
    • 完全防御は不可能

③ 想定外に備えるための3つの対策(教訓)
  1. セーフティネット(冗長性・監視)
    • フェイルオーバー
    • 継続的モニタリングとアラート
  2. 事前テストと全社的コミュニケーション
    • 災害・障害対応訓練は IT部門だけで完結させない
    • 経営・業務部門を含めた合意形成
  3. バックアップの実効性確保
    • オフライン参照手段
    • 定期バックアップ+「復旧できるか」の検証

④ 全体を貫くメッセージ(超要約)
「障害は起きるもの」
重要なのは “起こさない努力” より
“起きたときに社会的被害を最小化できる設計と運用”


Apr 27, 2026

アフィリエイターがこぞって勧めるShellの充電器は買うなという話

https://note.com/techk/n/nc885bdbe1764 (2025/12/22)

『 つまり、Shell充電器は、無名メーカーの製品を無名企業が仕入れ、国が名指しで指摘するハイリスクな事業者が認証を行い、Shellのロゴを付けて販売している状況というわけです。 』

その経産省が指摘するハイリスク事業所リスト「連絡不通事業者リスト」も興味深いが、
そもそも何故 販売差し止めしないのか。

SharePointサーバ なりすましの脆弱性 CVE-2026-32201

Microsoft SharePoint Server のなりすましの脆弱性 (04/14)

『攻撃者がこの脆弱性を悪用した場合、機密情報を閲覧し (機密性)、開示された情報に変更を加える (完全性) ことはできますが、リソースへのアクセスを制限することはできません (可用性)。』

Known Exploited Vulnerabilities Catalog にも載っている (04/14)

『Microsoft SharePoint Server contains an improper input validation vulnerability that allows an unauthorized attacker to perform spoofing over a network.』

Apr 23, 2026

CVE-2026-5281 Chromiumベースの製品の脆弱性

CVE-2026-5281 (04/01)

『Google Dawn には、レンダリング処理を不正に操作したリモート攻撃者が、細工したHTMLページを介して任意のコードを実行できる可能性がある、Use-After-Freeの脆弱性(解放されたメモリを再使用宣言なく使用する脆弱性)があります。以上機械翻訳と手直し少々

KEV Catalog (04/01)

この脆弱性は、Google Chrome、Microsoft Edge、Opera などを含む複数のChromiumベースの製品に影響を与える可能性がある』 以上機械翻訳

「Google Chrome 146」には脆弱性の修正も ~深刻度「Critical」を含む29件に対処 - 窓の杜 (03/12)

『Windows環境ではv146.0.7680.71/72が展開中
 ・・・
深刻度の最大評価は、4段階中最高の「Critical」。』

「Microsoft Edge」にゼロデイ脆弱性、WebGPU実装「Dawn」の欠陥を突く攻撃が確認 - 窓の杜 (04/06)

『修正版のv146.0.3856.97が展開中、できるだけ早い適用を
 ・・・
 深刻度の最高評価は、4段階中上から2番目の「High」。なかでも、WebGPU実装「Dawn」で発見された解放後メモリ利用(Use after free)の脆弱性 「CVE-2026-5281」はすでに悪用が確認されており、警戒が必要だ。できるだけ早いアップデートをお勧めする。』

FortiClient EMS API認証および認証バイパス

https://fortiguard.fortinet.com/psirt/FG-IR-26-099

「FortiClient EMSの不適切なアクセス制御脆弱性[CWE-284]により、認証されていない攻撃者が不正なコードやコマンドを細工されたリクエストで実行できるようになる可能性があります。

フォーティネットはこれを実際に悪用する点を指摘しており、脆弱な顧客に対して、以下の手順に従って、FortiClient EMS 7.4.5および7.4.6のホットフィックスをインストールするよう呼びかけています。」 以上機械翻訳

Apr 21, 2026

Claude Mythos Preview

Anthropicが警鐘を鳴らすAI時代のサイバー脅威 企業が採用すべき対策とは:セキュリティニュースアラート - ITmedia エンタープライズ (04/15)

AI加速型攻撃への対抗策 組織が直面する課題と実践的な防御実装とは

パッチ適用の遅延解消(最優先事項)
  • 既知の脆弱性は公開後すぐに悪用手法が確立されるため、インターネット公開システムでは24時間以内の対応が望ましい
  • 米国の既知悪用脆弱性カタログや確率指標を活用し、適切な優先順位を付ける

脆弱性報告の急増への備え

  • 報告件数が桁違いに増えることを見込み、受付・分類・修正管理の仕組みを根本から見直す
  • オープンソース依存関係の安全性評価や、ベンダーに対しても同水準の対策を求める
  • AIを報告の重複整理、影響分析、修正チケット作成などに役立てる

出荷前の欠陥検出体制の強化

  • 静的解析、AIによるコードレビュー、継続的テストの導入によって問題の早期発見を図る
  • ビルド工程の保護や安全設計の原則を採用し、新規開発ではメモリ安全性の高い言語を利用する

既存コードの再検証

  • 長期間運用されているシステムには未発見の問題が残る可能性が高いため、AIによる再分析を実施する
  • 特に外部入力処理や認証関連など、影響の大きい箇所から優先的に調査する

侵入を前提とした設計

  • 侵入を完全に防ぐことは困難なため、ゼロトラストの採用、ハードウェア認証、短期間で失効するトークンの利用などで被害範囲を限定する

公開資産の把握と削減

  • 接続資産を正確に把握し、不要なシステムを停止して攻撃面を縮小させる
  • AIを活用して未使用コードや不要なサービスを特定し、模擬攻撃による検証を実施する

インシデント対応の迅速化

  • アラートの初期分析や記録作成をAIに任せ、人間が判断に集中できる体制を構築する
  • 複数の同時事案を想定した訓練や、検知能力の可視化を重視する

脆弱性報告の質の確保

  • AI生成の報告が増える中で、人間による検証、再現手順、修正案の提示を不可欠とし、信頼性を確保する

専門部門を持たない組織向けの対策

  • 自動更新の有効化、マネージドサービスの利用、ハードウェア認証の導入を推奨
  • コードホスティングサービスが提供する無料のセキュリティ機能を積極的に活用する
 同社は今後もパートナーとの取り組みを通じて指針を更新するとしており、AI時代における防御戦略の継続的な見直しの必要性を強調している。

Device code attacks #2

Q. 先の記事の"デバイス"と手法を紹介しているビデオはありますか?
A. デバイスコードフィッシングの攻撃手法を、実際の操作画面(デモ)を交えて解説している非常にわかりやすい動画がいくつかあります。

英語の動画が中心ですが、攻撃者がどのようなツールを使い、被害者がどのように騙されるのかという「攻撃の流れ」が視覚的に理解できるものを紹介します。

1. 攻撃と対策の全行程がわかるデモ(おすすめ)

動画タイトル:YOU NEED TO BLOCK THIS (Device Code Auth in M365)

(チャンネル:diecknet EN / 約9分)

この動画では、攻撃者側と被害者側の両方の画面を並べてデモを行っています。

  • 攻撃のデモ (01:21〜): 1. 攻撃者がコマンドラインツール(TokenTactics)を実行し、正規の「デバイスコード」と「認証URL」を取得します。

    2. 攻撃者が被害者に「システム確認のためにコードを入力してください」といった偽のメッセージを送ります。

    3. 被害者が**公式サイト(microsoft.com/devicelogin)**にアクセスし、送られてきたコードを入力します。

    4. 被害者が「続行」を押すと、攻撃者の手元にあるツールに「認証済みトークン」が届き、パスワードなしでアカウントが乗っ取られる様子が映し出されます。

  • 対策の解説 (04:37〜): * Microsoft Entra ID(旧Azure AD)の設定で、この「デバイスコードフロー」自体をブロックする方法を解説しています。

2. 「MFA(多要素認証)が効かない」ことを強調したデモ

動画タイトル:How to Stop Device Code Flow Attacks in Entra

(チャンネル:Threatscape / 約5分)

この動画のポイントは、被害者が**「物理セキュリティキー(FIDO2)」という非常に強固な認証を使っているにもかかわらず、攻撃が成功してしまう**ことを実演している点です。

  • 見どころ (02:01〜): 被害者が指紋認証や物理キーで「正しくログイン」したその瞬間に、攻撃者がトークンを奪取してメールやファイルにアクセスできるようになる流れが非常にスピーディーに示されています。


動画で示されている共通の「攻撃の流れ」まとめ

これらのデモ動画を見ると、以下の3ステップがこの攻撃の核心であることがわかります。

  1. 「本物のサイト」へ誘導する: 偽サイトではなく、MicrosoftやGoogleの本物のログインページにコードを入力させるため、被害者は警戒心を解いてしまいます。

  2. ログイン後の「権限」を奪う: ユーザーがログインを完了すると、その「ログイン済みの状態(トークン)」が攻撃者のマシンに転送されます。

  3. パスワード・MFAをバイパス: ユーザーが自分でMFAを突破して「許可」ボタンを押してしまうため、どれほど強固な認証を設定していても防げません。

より専門的・技術的な詳細に興味がある場合は、2025年のハッカーカンファレンスでの講演**「DEFCON33 - Turning Microsoft's Login Page into our Phishing Infrastructure」**も、この手法がどのように悪用されているかを深く掘り下げており、非常に参考になります。

Device code phishing attacks have skyrocketed: here’s what you need to know

https://pushsecurity.com/blog/device-code-phishing/ (04/04)


いつものセキュリティホールmemoさんの記事で気になったので、後で読むためのメモ。

◆悪用成立シナリオをAIに訊いてみた◆

RFC 8628で定義されている OAuth 2.0 Device Authorization Grant(デバイスフロー) において、攻撃者がターゲットのアカウントを乗っ取る操作手順を簡潔にまとめます。
この攻撃の核心は、「正規のログイン手順の中に、攻撃者のデバイスを紛れ込ませる」 ことにあります。

悪用の操作手順

  1. 攻撃者によるコード取得
    攻撃者は自分のデバイスから認証サーバーへリクエストを送り、**ユーザーコード(例: ABC-123)**を取得します。
  2. 被害者へのフィッシング(誘導)
    攻撃者は「セキュリティ確認のため」や「特典の受け取り」などの口実を使い、被害者に以下の2点を伝えます。
    • 正規の認証用URL(例: google.com/device)にアクセスすること
    • 攻撃者が取得したユーザーコードを入力すること
  3. 被害者による承認
    被害者は、URL自体が本物であるため安心してアクセスし、指示されたコードを入力します。その後、自分のID/パスワードでログインし、「デバイス(実際は攻撃者のもの)のアクセスを許可しますか?」という画面で「はい」を押してしまいます。
  4. 攻撃者によるトークン奪取
    被害者が承認した瞬間、攻撃者のデバイスがポーリング(待機)していた認証サーバーからアクセストークンが発行されます。これにより、攻撃者は被害者のパスワードを知ることなく、アカウントへアクセス可能になります。

なぜこれが成り立つのか?

このフローでは、**「コードを入力している人間(被害者)」「実際にログインしようとしているデバイス(攻撃者)」**が同一人物であることを確認する仕組みが欠けているため、このような「コードのすり替え」が成立してしまいます。
ポイント:
攻撃の成功には、被害者に「偽のサイト」ではなく、**「本物のサイトに、攻撃者のコードを入力させる」**というソーシャルエンジニアリング(騙しのテクニック)が不可欠です。
なお、各種アプリのすべての機能を使用するには、Gemini アプリ アクティビティを有効にする必要があります。

シャドーAIによる誤認逮捕

AI顔認識による誤認逮捕で5カ月勾留、行ったこともない州の事件の「容疑者」に 米(1/2) - CNN.co.jp (03/30)

『「ウェストファーゴの関係機関は、我々の上層部が認識していない独自のAI顔認識システムを調達した。我々はその使用を認めておらず、その後使用を禁止した」とファーゴ警察のデイブ・ジボルスキー署長は話している。
 ・・・
ファーゴでは弁護士が選任され、犯行時刻にリップスさんがテネシー州にいたことを証明する銀行記録が見つかった。ファーゴ警察によると、州検察は12月12日、「無実を証明し得る証拠」が弁護士から提出されたとファーゴ警察に通知した。』

弁護士が証拠を提出できていなければ、有罪確定だったのか? 案外司法が未成熟!?

Apr 16, 2026

Progress ShareFile にリモートコード実行可能な脆弱性

『Progress ShareFile チームは最近、お客様が管理するゾーンの ShareFile Storage Zones Controller v5 バージョンのデプロイメントに重大なセキュリティ脆弱性があることを確認しました。現在のところ、これらの脆弱性が悪用されたという報告は受けておりません。

これらの脆弱性は、認証されていないリモートの攻撃者がオンプレミスのストレージゾーンコントローラーの設定ページにアクセスすることを可能にし、システム設定の変更やリモートコードの実行につながる可能性があります。』 以上機械翻訳

『私たちは Progress ShareFile のフィンガープリントをスキャンとレポートに追加し、2026-04-02 に公開された 784 のユニーク IP を確認しました。最近、@watchtowrcyber が ShareFile に影響を及ぼす RCE CVE-2026-2699 & CVE-2026-2701 悪用チェーンの詳細を公開しました。最新のパッチを必ず適用してください! pic.twitter.com/aVvl83pzt4
- Shadowserver Foundation (@Shadowserver) April 3, 2026 』

April 3, 2026 nekono_nanomotoni (@nekono_naha)
Progress社ShareFileで認証前RCEに繋がる脆弱性の詳細PoCが公開されたため公開サーバを調査。グローバルで642台を発見し内18.1%の116台が脆弱性の影響を受ける可能性あり。同社製品は様々なものが過去何度も悪用されており今回も遅かれ早かれITWになると予想。日系へ影響小https://t.co/wUTDlr8teR pic.twitter.com/AzI6i2FkXW

『Customer Managed ShareFile Storage Zones Controller (SZC) allows an unauthenticated attacker to access restricted configuration pages. This leads to changing system configuration and potential remote code execution.
 ・・・
CNA:  Progress Software Corporation
Base Score: 

『Authenticated user can upload a malicious file to the server and execute it, which leads to remote code execution.
 ・・・
CNA:  Progress Software Corporation
Base Score: 

AIX、住信SBIネット銀行 .. 東京海上との比較

◆住信SBIのAIX◆

住信SBIネット銀行が2025年に発表し、2026年現在まさに進行させている取り組みは、単なる「システムのクラウド化」を超えた、銀行業におけるAIXの極致も言えるものです。
彼らが掲げているのは、銀行そのものをAI化する**「NEOBANK ai」**という構想です。
1. 国内初「ジェネレーティブUI」の実装(2026年2月〜)
住信SBIネット銀行がAIXとして特筆すべきなのは、**「ジェネレーティブUI(画面の自動生成)」**という概念をアプリに持ち込んだことです。
  • 従来のDX: 人間が使いやすいようにボタンを配置した「固定の画面」を作る。
  • 住信SBIのAIX: AIとの対話に応じて、その瞬間に必要な「振込画面」や「グラフ」をAIがその場で組み立てて提示する。
    • 例えば、「先月のデビットの使いすぎを分析して、残金から来月の家賃を引いた額を貯金用口座に移して」と話しかければ、AIが分析グラフを生成し、最適な振込実行ボタンをその場で作り出します。
2. 「銀行員」そのもののエージェント化
東京海上が「損害査定」をAI化したように、住信SBIは**「コンシェルジュ業務」**をAIエージェントに置き換えています。
  • NEOBANK ai エージェント: 2026年2月からベータテストが開始されているこの機能は、単なるチャットボットではなく、**「銀行の操作権限を持ったAI部下」**です。
  • 何ができるか: 自然言語(話し言葉)だけで、振込、残高確認、デビットの利用制限設定、さらには「割り勘したお金が全員から振り込まれたかの確認」といった、これまで人間が手作業で画面をポチポチ操作していたことをすべてAIが肩代わりします。
3. クラウド移行は「AIX」のための「土台作り」
ご指摘の「勘定系システムのクラウド移行(AWSへの完全移行)」は、実はこのAIXを実現するための必須条件でした。
  • 理由: 従来の銀行の古いシステム(オンプレミス)は、AIがアクセスするには「重すぎて」「固すぎる」のです。
  • AIXとの関係: 全システムをクラウド(AWS)に載せることで、AIが銀行の深部のデータ(勘定系データ)にミリ秒単位でアクセスし、即座に処理を実行できる**「AIファーストな銀行」**へと肉体を改造したわけです。

東京海上(損保)と住信SBI(銀行)のAIX比較
特徴
東京海上(8766)
住信SBIネット銀行(7163)
主なAIX対象
事故査定・支払いの自動化
銀行操作・UIの自動生成
ユーザー体験
「事故対応の待ち時間がゼロになる」
「銀行アプリの操作そのものがなくなる」
戦略の肝
膨大な過去の損害データとAIの結合
クラウド基盤(BaaS)と生成AIの融合
結論
住信SBIの取り組みは、「銀行を『アプリ』から『見えないエージェント』へ変えること」を目指しています。「勘定系システムのクラウド化」は、例えるなら「AIという強力な脳」を動かすために、全身の神経(システム)を光ファイバーに差し替える手術のようなもので、これによって初めてAIが銀行業務を「独走」できる準備が整ったと言えます。
金融業界では、この両社が「AIXによって既存の金融機関をどれだけ突き放すか」が2026年現在の最大の関心事となっています。

◆住信SBI、東京海上のAIXと競争優位性◆

東京海上ホールディングスが「リスク評価の精度(=保険商品の原価低減)」で差をつけるのに対し、**住信SBIネット銀行がAIXで狙う競争優位は、「銀行という存在の消滅(インビジブル・バンキング)」と「圧倒的な低コスト構造」**にあります。
一言で言えば、東京海上のAIXは**「中身(評価)」の進化、住信SBIのAIXは「器(インフラ)」**の進化といえます。具体的には以下の3点が競争優位の源泉です。
1. 「BaaS(ネオバンク)」のプラットフォーム支配力
住信SBIの最大の武器は、自社の銀行機能を他社(JAL、ヤマダ電機、高島屋等)に貸し出す**BaaS(Banking as a Service)**です。
  • AIXの役割: 提携先が増えるほど、本来は審査やサポートのコストが膨れ上がります。しかし、AIエージェントがこれらを自律的に処理することで、**「提携先が100社に増えても、銀行側の行員数は増やさない」**という究極のスケーラビリティ(拡張性)を実現します。
  • 競争優位: 提携先企業にとっては「最も低コストで、最も賢い銀行機能を自社アプリに組み込める」ため、住信SBIがプラットフォーマーとして独走状態になります。
2. 「AI審査」による高収益・低リスクの両立
東京海上のリスク評価に近い部分ですが、銀行においては「住宅ローン」などの融資審査がこれに当たります。
  • AIXの役割: 2026年現在、同行は膨大なデータを活用した**「AIスコアリング審査」**を極めています。通常、数日〜数週間かかる住宅ローン審査を最短当日に短縮しつつ、人間が見逃すような微細な不正・デフォルトの兆候をAIが検知します。
  • 競争優位: **「爆速で借りられるのに、貸し倒れが極めて少ない」**という状態を作ることで、他行が追随できない低金利(または高利回り)を提供し、優良顧客を総取りします。
3. 「限界費用のゼロ化」によるROEの極大化
銀行業は本来、店舗や大量の事務員を抱える「重い」ビジネスです。
  • AIXの役割: 勘定系システムのクラウド移行とAIエージェントの導入により、預金残高や口座数が増えても、システム維持費や人件費がほとんど増えない**「限界費用がほぼゼロ」**の収益構造へ移行しています。
  • 競争優位: 2026年度に掲げているROE 18%以上という目標は、一般的な銀行(5〜8%程度)を圧倒しています。この高収益を原資に、さらなるシステム投資や還元を行う「勝利のループ」に入っています。

比較まとめ:両社のAIXが目指す「決定的な差」
視点
東京海上 (8766)
住信SBIネット銀行 (7163)
競争優位の本質
**「損をしない」**力の最大化

(精緻なプライシング)
**「コストをかけない」**力の最大化

(徹底した無人化・インフラ化)
狙うポジション
リスクマネジメントの世界的権威
金融機能の黒子(OS)
顧客のメリット
事故が起きる前に防げる、安い保険
銀行を意識せず、勝手にお金が管理される
住信SBIの怖さは、彼らが「銀行」として戦っているのではなく、**「銀行の機能を持ったITプラットフォーム」**として、他の銀行を「部品」に変えてしまおうとしている点にあります。東京海上が「最強の保険屋」を目指すなら、住信SBIは「銀行の概念そのものを消す」ことで勝とうとしている、という違いがあります。