この記事は約26分で読めます。
クラウドとSaaSの利用が広がった現在、守るべきログはオンプレミスと複数のクラウド、そして手元の端末にまで分散しています。
その結果、社内にログが集まることを前提にした従来型の監視は成り立たなくなり、増え続けるログとアラートにセキュリティ運用が追いつかない状況が生まれています。
この課題を解決するのが、クラウドネイティブのSIEMおよびSOARであるMicrosoft Sentinelです。収集から検知、調査、自動対応までを一つのセキュリティ運用基盤に束ねられます。
本記事では、データコネクタの設計、KQLによる検知、Playbookによる自動化、Defender XDRとの統合、そして2027年に予定されるDefenderポータルへの移行までを、SOC運用の設計視点で解説します。
こちらもオススメ！
オンプレSIEMはなぜ限界を迎えたのか？クラウドネイティブSOCが必要な理由
社内にすべてのログが集まることを前提にした従来型のSIEMは、監視対象が分散した環境では前提そのものが崩れています。まずはSOCという言葉を整理し、オンプレミス型SIEMが直面した限界と、クラウドネイティブへ移行が進む背景を見ていきます。
SOCとは
SOC（Security Operation Center）とは、組織内外のログを集約し、脅威を検知して対応する、セキュリティ運用の中核となる組織や機能のことです。24時間体制でシステムを監視し、攻撃の兆候をいち早く見つけて被害を最小化する役割を担います。
このSOCが脅威を検知するために使う道具の一つがSIEMです。SIEM（Security Information and Event Management）とは、さまざまな機器やサービスのログを一元的に集めて相関分析し、脅威を検知する仕組みのことです。
SOCが運用の司令塔なら、SIEMはその司令塔が状況を把握するための計器盤にあたります。
オンプレSIEMの3つの限界
オンプレミス型のSIEMが行き詰まる要因は、大きく3つに整理できます。ログ量の増大とアラートの過多、そしてマルチクラウドへの対応の難しさです。
第一に、ログ量の増大です。クラウドやSaaSの利用が広がるほど、収集すべきログの量は増え続けます。オンプレミス型では、ログを保管するサーバーやストレージを自前で増設し続ける必要があり、スケールが追いつかなくなります。
第二に、アラートの過多です。ログが増えれば検知されるアラートも増え、その多くが誤検知を含みます。
たとえば、情シス担当が一人か二人という体制で、毎朝数百件のアラートを人手で仕分ける現場を想像してみてください。本当に危険な兆候を見落としてしまうこの状態は、アラート疲れと呼ばれ、多くの現場が抱える悩みです。
第三に、マルチクラウドやSaaSへの対応です。AWSやGCP、Microsoft 365など、社外に置かれたサービスのログを社内のSIEMに集約するのは、構成が複雑になりがちです。
クラウドネイティブSIEMへの移行が進む背景
こうした限界を受けて、SIEMそのものをクラウド上のサービスとして使うクラウドネイティブSIEMへの移行が進んでいます。サーバーの自前構築が不要で、ログ量の増減にそのまま対応できる柔軟さが背景にあります。
前提となる考え方も変わりました。すべての侵入を完全に防ぎきることは難しいという前提に立ち、侵害が起きても早く検知して被害を抑えるという、検知と対応に重心を置く発想です。
これは、すべてのアクセスを信頼せず常に検証するゼロトラストの考え方とも重なります。
防御側の設計思想については、Azureゼロトラストとは？仕組み・6つの構成要素・段階的導入手順を解説で詳しく解説しています。本記事は、その先にある検知と対応の運用、すなわちSOCの構築を扱っていきます。
Microsoft Sentinelとは
クラウドネイティブSOCの中核を担うのがMicrosoft Sentinelです。ログを集めるだけのツールではなく、収集から検知、調査、そして対応の自動化までをカバーする、SIEMとSOARを一体で提供するサービスです。まずは、その定義から押さえていきます。
Microsoft Sentinelの定義（旧Azure Sentinel）
Microsoft Sentinelとは、Azure上で動作するクラウドネイティブのSIEMおよびSOARサービスです。
Microsoft Learnの公式ドキュメントでは、マルチクラウドおよびマルチプラットフォーム環境全体でスケーラブルなセキュリティを提供するSIEMソリューションであり、AIと自動化、脅威インテリジェンスを組み合わせて脅威の検出や調査、対応をサポートすると説明されています。
かつてはAzure Sentinelという名称で提供されていました。技術的には、ログの保管と分析の基盤としてAzure MonitorのLog Analyticsワークスペース上で動作します。
SentinelはAzure Monitorの改ざん防止と不変性のプラクティスを継承しており、収集したログの信頼性が保たれる設計です。
SIEMとSOARの違い
Sentinelを理解するうえで欠かせないのが、SIEMとSOARという2つの機能の違いです。
SIEMがログを集めて脅威を検知する仕組みであるのに対し、SOAR（Security Orchestration, Automation and Response）は、検知した後の対応手順を自動化して連携させる仕組みのことです。この異なる役割を一つのサービスで担える点が、Sentinelの強みです。
| 機能 | 役割 | 担うこと |
| SIEM | 検知する仕組み | 各種ログを集約し、相関分析して脅威やインシデントを見つける |
| SOAR | 対応を自動化する仕組み | 検知したインシデントに対し、通知や封じ込めなどの対応手順を自動で実行する |
SIEMだけでは、脅威を見つけたあとの対応は人手に頼ることになります。SOARを組み合わせることで、検知から対応までを一続きの運用として設計できます。
クラウドネイティブであることの強み
Sentinelがクラウドネイティブであることは、SOCを運用する担当者にとってメリットにつながります。サーバーを自前で構築せずに監視を始められ、ログ量が増えても従量課金でそのまま拡張できるためです。
AIを活用したMicrosoftの分析と脅威インテリジェンスを使い、誤検知を最小限に抑えながら以前は検出されなかった脅威を見つけ出せると公式ドキュメントでも説明されています。
対応範囲の広さも強みです。
AzureやMicrosoft 365だけでなく、AWSやGCPといった他社クラウド、さらにサードパーティのセキュリティ製品のログまで、オンプレミスと複数のクラウドをまたいで一元的に収集できます。分散してしまった監視対象を、一つの基盤に集約できるわけです。
データコネクタ設計：SOCの土台となるログ収集
SOCがどれだけ正確に脅威を検知できるかは、どのログを、どこまで集めるかで決まります。集めていないログからは、何も検知できません。ログ収集の入り口となるデータコネクタの役割から、まず何を接続すべきかを設計していきます。
ここでは、データコネクタ設計について詳しく解説します。
データコネクタとは
データコネクタとは、各種のログソースとMicrosoft Sentinelを接続し、ログを取り込む仕組みのことです。
公式ドキュメントによれば、SentinelにはMicrosoftサービス向けの多くのすぐに使えるコネクタが用意されており、リアルタイムで統合します。標準のコネクタを有効にするだけで、主要なログソースからの取り込みを始められます。
標準コネクタでカバーできないログソースについても、Syslog、Common Event Format（CEF）、REST APIを使って接続できるほか、独自のカスタムコネクタを作成することも可能です。オンプレミスの機器の多くは、SyslogやCEF形式での連携でSentinelに接続します。
まず接続すべき主要ログソース
SOCを立ち上げる際は、検知価値の高いログソースから優先して接続していきましょう。とくにIDとエンドポイント、クラウド基盤のログは、攻撃の起点や横展開を捉えるうえで欠かせません。
| ログソース | 主に得られる検知 |
| Microsoft Entra IDのサインインログ | 不審なログインや認証情報の悪用 |
| Microsoft 365（監査ログ） | メールやSharePoint、Teams上の不正なアクティビティ |
| Microsoft Defender XDR | エンドポイントやID、メールにまたがる脅威 |
| Microsoft Defender for Cloud | クラウドリソースの設定ミスやワークロードへの攻撃 |
| Azureアクティビティログ | Azureリソースへの構成変更や操作 |
| AWS、GCP | 他社クラウド上のリソースやアカウントの不審な操作 |
| ファイアウォールやプロキシ | 外部との不審な通信 |
なお、Azureアクティビティログ、Microsoft 365の監査ログ、Microsoft Defender各製品のセキュリティアラートなどは、Sentinelに無料で取り込めるデータソースとして公式に案内されています。
まずはこうした無料のログソースから可視化を始めると、コストを抑えながらSOCの土台を作れます。
クラウドリソースの保護状態を管理するMicrosoft Defender for Cloudは、そのアラートをSentinelへ供給する重要なログソースの一つです。
ログの取り込みは全部入れれば良いわけではない
ログは多く集めるほど良い、とは限りません。Sentinelはログの取り込み量に応じて課金されるため、検知にほとんど関与しないログまで大量に取り込むと、コストだけが膨らみます。
集めるログは、検知価値とコストのバランスで設計するのが基本です。
公式の課金ドキュメントでは、料金の仕組みとしてAnalyticsレベルに従量課金制とコミットメントレベルの2つが用意されています。
従量課金制は、格納した実際のデータ量にもとづく既定のモデルです。一方コミットメントレベルは、1日あたり100GBから始まる階層を選んで容量をコミットすることで、従量課金制と比べて割引が受けられる仕組みです。
ログ量が一定規模に達したら、コミットメントレベルへ切り替えることでコストを抑えられます。
さらに、検知に直接使うログはAnalyticsレベルで取り込み、主に長期保管が目的のログはより安価な階層で扱う、という使い分けも可能です。
従来Basicログや補助（Auxiliary）ログと呼ばれてきた低コストの階層は、現在はデータレイク階層への再編が進んでおり、価値の低い大量のログをLakeレベルに切り替えることで、低価格で格納しつつクエリ機能を維持できます。
なお、階層の名称や構成は再編の途上にあり、GBあたりの具体的な単価も変動するため、最新の内容はMicrosoft Sentinelの価格ページで確認してください。
まず小さく可視化を試す段階では、Analyticsログプランで取り込んだ最初の10GB/日が31日間無料になる試用版も活用できます。
KQLによる脅威検知
集めたログの中から脅威を見つけ出すのが、分析ルールの役割です。そして、そのルールがログをどう検索するかを記述する言語がKQLです。まず両者の関係を整理し、テンプレートの活用から誤検知との向き合い方まで見ていきましょう。
分析ルールとKQLとは
分析ルールとは、収集したログを定期的に検索し、条件に合致したらアラートを生成する検知ロジックのことです。
公式ドキュメントによれば、Sentinelはデータを常に調査して脅威を検出するために、定期的に実行される脅威検出ルールを提供しており、これらを総称して分析ルールと呼びます。
このルールが、ログを検索するために使うのがKQLという言語です。
KQL（Kusto Query Language）とは、Azure MonitorやSentinelでログを検索し集計するための問い合わせ言語のことです。最も一般的な分析ルールであるスケジュールされたルールは、一定間隔で実行され、定義した期間のログを調べるKustoクエリにもとづいて構成されます。
クエリの結果件数が、あらかじめ設定したしきい値を超えるとアラートが生成される仕組みです。
組み込みルールテンプレートを起点にする
検知ルールは、必ずしもゼロから書く必要はありません。むしろ、Microsoftが提供する分析ルールテンプレートを起点にするのが現実的な進め方です。
公式ドキュメントでも、コンテンツハブで提供される多くのソリューションを通じて分析ルールテンプレートを利用することが強く推奨されています。
これらは、既知の脅威や一般的な攻撃手法に関する知識にもとづき、セキュリティの専門家が設計した検知ロジックです。まず有効化し、必要に応じて自組織の環境に合わせて調整していくことで、はじめから網羅性の高い検知を用意できます。
KQLで検知ルールを作る具体例
テンプレートに加えて、自組織固有の脅威を検知するルールをKQLで定義することもできます。
たとえば、短時間に何度もサインインに失敗しているアカウントを検知したい場合、Microsoft Entra IDのサインインログ（SigninLogsテーブル）を対象に、次のようなクエリを書けます。
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != “0”
| summarize FailedCount = count() by UserPrincipalName, bin(TimeGenerated, 10m)
| where FailedCount > 10
このクエリは、直近1時間のサインインログのうち、認証に失敗したもの（ResultTypeが0以外）を対象に、ユーザーごと10分単位で失敗回数を数え、10回を超えたものを抽出します。パスワードの総当たり攻撃のような兆候を捉えるための、シンプルな検知の一例です。
また、スケジュールされたルールとして運用する場合は、クエリ内の対象期間（ago(1h)）とルール側で設定する照会間隔をそろえておくと、検知の重複や漏れを防げます。
しきい値や集計単位を変えることで、自組織の運用に合った検知ルールを定義できます。
誤検知（フォールスポジティブ）との付き合い方
検知ルールの運用では、誤検知との付き合い方が課題になります。誤検知（フォールスポジティブ）とは、実際には脅威ではないのにアラートとして上がってしまうもののことです。
しきい値を厳しくしすぎるとアラートが増えてアラート疲れを招き、逆に緩めすぎると本当の脅威を見逃します。
現実的な運用は、しきい値の調整と除外リストの整備を続けることです。
正規の業務で発生する既知のパターンを除外条件に加え、検知の精度を少しずつ高めていきましょう。検知ルールは一度作って終わりではなく、運用しながら調整し続けるものです。
Playbookによる対応の自動化（SOAR）
脅威を検知できても、その後の対応を毎回人手で行っていては時間がかかり、被害が広がります。検知したインシデントへの対応を自動化するのがPlaybookで、SOARの中核を担う機能です。その定義と具体的な自動化シナリオから見ていきます。
Playbookとは
Playbookとは、アラートやインシデントをきっかけに、定型の対応手順を自動で実行するワークフローのことです。
公式ドキュメントによれば、SentinelのPlaybookはAzure Logic Appsに組み込まれたワークフローにもとづいて構築されます。なおAzure Logic Appsとは、さまざまなサービスやシステムをつないでタスクを自動化できるクラウドサービスです。
Playbookは修復アクションの集まりであり、特定のアラートやインシデントに応じて自動的に実行するか、必要に応じて手動で実行できます。ServiceNowやJiraをはじめ、多数のサービス向けのコネクタが用意されており、対応手順の中で外部システムとも連携できます。
自動化の具体シナリオ
Playbookがどのように作動するのかは、具体的なシナリオで捉えると分かりやすくなります。
たとえば、ある海外拠点からの不審なサインインが検知された場面を想定しましょう。
まず分析ルールが不審サインインを検知してインシデントを生成します。それをきっかけにPlaybookが起動し、該当するアカウントの認証を一時的に無効化します。同時に、SOCの担当者にTeamsとメールで通知を送り、対応の記録としてServiceNowにチケットを自動で記録します。
人が気づく前に初動の封じ込めと共有が完了するため、対応にかかる時間を大幅に短縮できます。
自動化のレベル設計（完全自動と承認つき）
対応を自動化する際は、すべてを完全自動にすればよいわけではありません。対応の影響の大きさに応じて、自動化のレベルを設計することが大切です。
たとえば、担当者への通知やチケットの記録のように、業務に支障が出にくい対応は完全自動にできます。一方、アカウントの停止やサーバーの隔離のように、誤って実行すると正規の業務を止めてしまう恐れがある対応は、Playbookの途中に承認ステップを挟み、担当者が確認してから実行する設計が安全です。
こうした自動化を整えることで、インシデントを検知してから対応を完了するまでの時間、いわゆるMTTR（平均対応時間）の短縮が期待できます。
ただし、短縮できる度合いは組織の体制や自動化の範囲によって大きく異なるため、具体的な短縮率を一律に断定することはできません。まずは頻度の高い対応から自動化し、効果を測りながら範囲を広げていく進め方が現実的です。
Defender XDRとの統合
ここまで見てきたように、Microsoft Sentinelは単体でもSOCの基盤として機能します。そのうえでMicrosoft Defender XDRと統合すると、検知の質とSOC運用の一体感が大きく変わります。
ここが本記事の主題である統合SOCのポイントです。以下では、Defender XDRの役割とSentinelとの分担から、統合SOCの運用イメージまでを掘り下げます。
Defender XDRとは
Microsoft Defender XDRとは、エンドポイントやID、メール、SaaSアプリなど、Microsoftの各領域のシグナルを相関させて脅威を検知し、対応する統合防御基盤のことです。XDRはExtended Detection and Responseの略で、複数の領域をまたいで拡張された検知と対応を意味します。
公式ドキュメントによれば、Defender XDRはMicrosoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Office 365、Microsoft Defender for Cloud Appsといった複数の製品からのアラートを強化してグループ化し、SOCのインシデントキューを縮小して解決までの時間を短縮します。
SentinelがSIEMとしてマルチクラウドや長期保持、カスタム検知、対応の自動化を担うのに対し、Defender XDRはMicrosoft資産の深い相関を担う、という役割分担で整理できます。
| 観点 | Microsoft Sentinel（SIEM/SOAR） | Microsoft Defender XDR |
| 得意領域 | マルチクラウドや長期のログ保持、カスタム検知、対応の自動化 | エンドポイントやID、メールなどMicrosoft資産の深い相関 |
| データの範囲 | AWSやGCP、サードパーティを含む横断的な収集 | Microsoftの各セキュリティ製品のシグナル |
| 役割 | 組織全体のログを束ねる司令塔 | Microsoft領域の脅威を自動で検知し防ぐ実働部隊 |
統合で何が変わるか
SentinelとDefender XDRを統合する最大の価値は、インシデントの一元化です。統合によってDefender XDRのインシデントをSentinel内から表示および管理でき、組織全体にわたるプライマリインシデントキューが提供されます。
これにより、Defender XDRが検知したインシデントを、他のクラウドやオンプレミスのシステムからのインシデントと同じ画面で並べて確認し、関連づけられます。インシデントは双方向に同期されるため、片方のポータルで状態を更新すればもう片方にも反映され、二重管理から解放されます。
調査とハンティングを一つのキューで完結でき、複数の管理画面を行き来する手間がなくなるのです。
統合SOCの運用イメージ
統合SOCは、両者の補完関係で捉えると分かりやすくなります。
まずエンドポイントやメールへの攻撃に対しては、Defender XDRが深い相関で脅威を検知し、多くを自動で封じ込めます。そのうえでSentinelが、AWSやGCPを含むマルチクラウド全体の文脈を付け足し、必要なログを長期に保持します。
たとえば、あるメールアカウントの侵害をDefender XDRが検知して初動対応を行った際、そのアカウントが他社クラウド上のリソースにもアクセスしていたとします。Sentinelがマルチクラウドのログを束ねているため、攻撃者がどこまで到達したかという全体像を一つの画面で追跡できます。
Microsoft領域はDefender XDRが深く守り、その外側までをSentinelが広く見渡す、という補完関係が統合SOCの姿です。
2027年以降のSOC運用はDefenderポータルへ
Microsoft Sentinelを操作する画面そのものが大きく変わろうとしています。従来のAzureポータルから、Defenderポータルへと操作の中心が移りつつあり、SOCの運用画面が一本化されていきます。
情報が更新され続けている領域のため、最新の公式アナウンスにもとづいて、集約の背景と移行スケジュールの現状、そして準備の要点を整理します。
なぜDefenderポータルに集約されるのか
背景にあるのは、MicrosoftがSIEM（Sentinel）とXDR（Defender）を一つの統合セキュリティ運用（Unified SecOps）に束ねる戦略です。先に見たインシデントの一元化を、運用画面のレベルでも実現する動きだといえます。
これまでSentinelはAzureポータルで、Defender XDRはDefenderポータルで、それぞれ別の画面から操作するのが基本でした。これがDefenderポータルに集約されると、SOCのアナリストは複数のポータルを切り替える必要がなくなり、検知から調査、対応までを一箇所で完結できます。
移行スケジュールの現状（2027年3月末）
移行のスケジュールは繰り返し更新されてきましたが、本記事の執筆時点（2026年7月）で確認できる公式の最新情報は次のとおりです。
Microsoft Learnの公式ドキュメントには、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされなくなり、Microsoft Defenderポータルでのみ使用できるようになると明記されています。同じ案内は、データコネクタや課金の公式ドキュメントにも重要事項として掲載されています。
当初、AzureポータルでのSentinelの提供終了は2026年7月1日と案内されていましたが、大規模な環境を運用する顧客やパートナーからのフィードバックを受け、2026年1月の公式アナウンスで2027年3月31日へ延長されました。
すでに新規のお客様には変化が始まっています。2025年7月1日以降に必要な権限を持って初めてSentinelにオンボードした新規顧客は、ワークスペースが自動的にDefenderポータルにオンボードされ、DefenderポータルでのみSentinelを使用します。
既存顧客も、Defenderポータルへの移行手順を解説した公式ドキュメントに沿って、計画的に移行を進めることが推奨されています。
なお、こうした日付は今後さらに更新される可能性があります。導入や移行を判断する際は、必ずSentinelの新着情報や上記の公式ドキュメントで、その時点の最新のスケジュールを確認してください。
いま準備しておくべきこと
移行の期限が定まっている以上、いまから準備を進めておくことで、慌てずに移行できます。準備の要点は2つあります。
第一に、新規に構築するSOCは、はじめからDefenderポータルを前提に設計することです。前述のとおり新規顧客は自動的にDefenderポータルにオンボードされるため、最新の統合運用に沿った形で始められます。
第二に、既存のSentinel環境をAzureポータルで運用している場合は、Defenderポータルへの接続（オンボード）計画を早めに立てることです。移行時にはアクセス許可の考え方が新しい統合ロールベースアクセス制御に変わるため、誰がどの範囲を操作できるかを、統合後の体制に合わせて見直しておきます。
いずれも、一度にすべてを終える必要はありません。まずは現状の可視化から着実に進め、移行はスモールスタートで段階的に整えていく姿勢が現実的です。
SOC構築の進め方
ここまで解説してきた要素を、どの順番で実行するかを整理します。一度に完璧なSOCを作ろうとすると、設計の複雑さと運用負荷で頓挫しがちです。まずログの可視化から始め、検知、自動化、統合へと段階的に育てていくのが現実的な進め方です。
ゼロトラストの導入と同じく、小さく始めて成果を確認しながら広げる姿勢が定着への近道となります。
STEP1：ログの可視化
最初のステップは、ログの可視化です。まずMicrosoft Entra IDのサインインログやMicrosoft 365の監査ログ、Defender各製品のアラートなど、無料で取り込める主要なログソースをデータコネクタで接続します。
この段階の狙いは、自組織で何が起きているかを見えるようにすることです。あわせて取り込むログの量と料金の見通しを立てます。
実際の構築では、可視化を始めてから想定を上回るログ量が判明し、料金設計の見直しが必要になる場面も少なくありません。無料試用版や無料のデータソースを活用すれば、追加投資をほとんどかけずに踏み出せます。
STEP2：検知ルールの整備
可視化の土台ができたら、検知ルールを整備します。まずコンテンツハブで提供される組み込みの分析ルールテンプレートを有効化し、はじめから網羅性の高い検知を用意しましょう。
そのうえで、自組織固有の脅威に対しては、KQLでカスタムの検知ルールを定義します。運用しながら誤検知を減らすチューニングを続け、しきい値や除外条件を調整して検知の精度を高めていきます。
この段階で、アラート疲れを招かないバランスを探ることが重要です。
STEP3：対応の自動化と統合SOC化
最後のステップで、対応の自動化と統合SOC化を進めます。頻度の高い対応をPlaybookとして自動化し、通知やチケット起票から段階的に封じ込めまでを自動で回せるようにします。
そしてDefender XDRと統合し、Defenderポータルでの一元運用へと移していきます。可視化から検知、自動化、統合へと積み上げていく連続した運用として設計することが、クラウドネイティブSOCを機能させるポイントです。
クラウドネイティブSOCは収集・検知・対応・統合の連続運用で育てる
Microsoft SentinelによるSOCは、一度構築して終わりではなく、データコネクタでログを集め、KQLで脅威を検知し、Playbookで対応を自動化し、Defender XDRと統合してDefenderポータルで一元運用する、という流れを回し続ける連続した運用です。
とはいえ、いきなりすべてを揃える必要はありません。まずは無料で取り込める主要なログの可視化から小さく始め、成果を確認しながら検知と自動化、統合へと範囲を広げていくのが、現実的なスタートです。
2027年3月末に予定されるDefenderポータルへの移行も見据え、新規はDefenderポータルを前提に、既存は計画的な移行を進めておくことで、慌てずに統合運用へ移れます。
Microsoft SentinelによるSOC構築やSIEM/SOAR統合運用、Defenderポータルへの移行の設計と運用支援については、ジードのAzureサービスページへお気軽にご相談ください。
お客様が運営するクラウドの監視・保守・運用業務を、ジードが代行いたします。
お客様のご要望に沿って、適切なクラウド選定から設計・構築までを行います。
Azure上で、AI ＋ 機械学習、分析、ブロックチェーン、IoTを開発します。