DataRobot とは

DataRobotは、データ前処理からモデル構築、デプロイ、モデル運用までを自動化するエンタープライズ向けAIプラットフォームです。DataRobotは、多様なデータソースからデータを簡単に取り込み、さまざまな機械学習アルゴリズムを使用して、ビジネスニーズに合った高精度なモデルを迅速に構築します。さらに、モデルの稼働状況や精度・データドリフト・バイアスと公平性など様々な観点でモデルのパフォーマンスを監視し、持続可能なモデル運用を実現します。

Apache Airflow とは

Apache Airflowは、オープンソースのワークフローオーケストレーションツールです。データ取得、ETLジョブ、機械学習タスクなど、さまざまなタスクをスケジュールして実行するために使用できます。スケーラブルで信頼性の高いワークフローを構築するための強力なフレームワークを提供します。

Apache AirflowとDataRobotを連携するメリット

DataRobotとApache Airflowを連携するとMLOpsワークフローを強化できます。これにより次のようなメリットが享受できます。

メリット１：モデルトレーニングとデプロイの自動化

機械学習のビジネス利用ではモデルトレーニング、デプロイ、予測を定義したMLOpsワークフローが必要となるケースがあります。特に定期的にモデルを再トレーニングするケースや、頻繁にデータドリフトが起こりその都度再トレーニングが必要となるケースではMLOpsワークフローの構築は必須です。MLOpsワークフローを事前に作成することで、外部環境の変化に迅速に対応し、モデルの品質とパフォーマンスを維持できます。

DAG (Directed Acyclic Graph)構築

DataRobotとApache Airflowを連携することで、たとえば図1のようなMLOpsワークフローを構築できます。この例では、Apache Airflowを使用して、DataRobotのジョブ（モデルトレーニング、デプロイ、予測）をスケジュールして実行しています。

なおDataRobot単独でも再トレーニングの自動化機能があり、再トレーニングのスケジュール実行や異常時の実行が可能です。それに対し、DataRobotとApache Airflowを連携することのメリットは、データ取得、ETLジョブまで含めたパイプラインをより柔軟にカスタマイズできる点にあるといえます。

メリット２：MLOpsワークフローの可視化とデバッグ

図1のようにApache Airflowは、MLOpsワークフローの実行状況を可視化するための強力なダッシュボードを提供します。また、ワークフローの進行状況をリアルタイムに確認でき、問題が発生した場合にはログを解析できます（図2）。これにより、ワークフローを監視し、問題をデバッグします。

そして2020年7月からは、SHAP を用いた「特徴量のインパクト」および「予測の説明」が実装されました。この記事では SHAP の概念や計算原理、DataRobot での確認方法を解説するとともに、従来の Permutation Importance や XEMP との使い分けについて考察したいと思います。

メリット３：マルチクラウドへの対応

近年、企業におけるクラウド利用において、単一のクラウドベンダーに依存するのではなく、複数のクラウドサービスを組み合わせる「マルチクラウド」を採用するケースがあります。「マルチクラウド」には主に以下のようなメリットがあります。

• ベンダーロックインの回避
• 可用性の向上
• 柔軟性の向上

一方で、複数のクラウドに分散したデータやモデルを管理するためには、適切なガバナンス体制を構築したりスキル人材を獲得したりする必要があります。これは、特に大規模な組織においては大きな課題となります。

その課題に対して、Apache Airflowは各クラウドと接続することができるため、データが複数のクラウドに分散していてもワークフローを構築できます。

これはApache Airflowを利用すればデータのサイロ化を解決できると言っているわけではありません。マルチクラウド環境でも、機械学習に用いるデータは1つのデータウェアハウスやデータレイクに集約することがマルチクラウドの複雑さを解決する直接的な方法です。

1つのデータウェアハウスやデータレイクにデータを集約しておけば、データの管理コストを減らせるだけでなくチーム内外でのコラボレーションが加速するからです。

Apache AirflowとDataRobotを連携する方法

DataRobotとApache Airflowを連携するには、次の手順を実行します。詳細はApache Airflow用のDataRobot プロバイダーをご覧ください。

• Apache AirflowとDataRobotを連携する際の前提条件

DataRobotプロバイダーを使用するには、以下の依存関係をインストールした環境が必要です。

• Apache AirflowとDataRobotの連携手順

　（手順1） DataRobot APIキーを取得し、Apache Airflow上で接続設定を行います（図3）。

　（手順2）Apache Airflow環境にDataRobotプロバイダーをインストールします。Apache Airflow DAGページにインストールしたDataRobotプロバイダーが表示されます（図4）。

Apache Airflow用のDataRobotプロバイダーは、公開されているGitHubレポジトリからダウンロードできます。

DataRobotプロバイダーのモジュールには、DataRobot MLパイプラインのステップを自動化する複数のDataRobotオペレータとセンサーがあります。以下に代表的なオペレーターやセンサーを示します。各オペレータは特定のジョブを実行し、各センサーは事前に設定された動作が完了するのを待ちます。

オペレータ

• CreateProjectOperator: DataRobotプロジェクトを作成し、そのIDを返します。
• TrainModelsOperator: DataRobotのオートパイロットを実行し、モデルをトレーニングします。
• DeployModelOperator: 特定のモデルをデプロイし、デプロイIDを返します。
• DeployRecommendedModelOperator: 推奨モデルをデプロイし、デプロイIDを返します。
• ScorePredictionsOperator: デプロイしたモデルに対して予測を行い、バッチ予測ジョブ ID を返します。

センサー

• AutopilotCompleteSensor: Autopilotが完了したかどうかをチェックします。
• ScoringCompleteSensor: バッチスコアリングが完了したかどうかをチェックします。

　（手順3）Apache Airflow DAGを用いて、DataRobotジョブをスケジュールします。

Apache AirflowとDataRobotの連携でMLOpsワークフロー強化を実現

DataRobotとApache Airflowを連携することで、機械学習パイプラインを自動化しMLOpsワークフローを強化できます。これにより、データからより多くの価値を引き出すことができます。ぜひ、DataRobotとApache Airflowの組み合わせでMLOpsの可能性を広げてください。

機械学習プロジェクトの効率化を図るなら「DataRobot」

DataRobotでは、トライアル環境を提供しています。以下のURLから、アカウントを作成することができます。

https://www.datarobot.com/jp/trial/

トライアル環境では、DataRobotの主要な機能を使用することができます。機械学習モデルの開発や運用に興味がある方やすでに携わっている方も、ぜひこの機会にDataRobotを体験してみてください。

投稿 Apache AirflowとDataRobotを連携してMLOpsワークフローを強化する方法 は DataRobot に最初に表示されました。

AIプラットフォームでは機微なデータを扱うこともあるため、使いやすさとセキュリティのバランスは重要です。DataRobotではマネージドサービス(いわゆる「クラウド版」)とセルフマネージド型(いわゆる「オンプレミス版」)に加え、近年では専有環境のマネージドサービスであるシングルテナント版も提供しており、セキュリティ要件に応じて選ぶことができます。
[参考] DataRobot AI Platform のデプロイインフラストラクチャ

セルフマネージド型(「オンプレミス版」)をお使いで、なかなかバージョンアップの時間が取れない！という場合、二世代前のバージョン8(あるいはそれ以前)を使っているユーザーの方もいらっしゃるのではないでしょうか。

このブログではそうしたユーザーの方向けに最新世代のDataRobotをご紹介します。

「自分が使っているDataRobotのバージョンがわからない」という方は、ログイン画面などで確認することができます：

なおマネージドサービス(「クラウド版」)にはこうしたバージョン番号はなく、ほぼ毎週アップデートされています。

DataRobot AI Platform バージョン9、そして10へ

DataRobotバージョン9は2023年3月にリリースされました。AutoMLの「ツール」から、組織のAIニーズをトータルで支える「プラットフォーム」へと進化すべく、機能の大幅な拡充に加え製品アーキテクチャも大きく進化しました。バージョン10は2024年4月にリリースされ、生成AI関連開発機能のほか、それを支えるGPU対応、エコシステム連携の深化など、最新の変化を取り入れています。

[参考] バージョン10.0.xリリースノート

DataRobotの生成AIと予測AI

DataRobotは2012年の創業以来、機械学習の自動化を通じた予測型AIの開発、運用プラットフォームのリーダーであり続けていますが、近年では生成AIを利用したモデルの開発・運用機能も統合し、単一プラットフォームで生成AIと予測AIの両方に対応することができるようになっています。

[参考] RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術

コーディングベースの開発と運用

DataRobotは従来から、マウス操作だけで数多くの予測モデルを自動開発できる使いやすいGUIを提供してきました。しかしDataRobotの操作自体やDataRobot以外のエコシステムとの連携をAPIを使ってもっと自動化したい、といったニーズも高まっていました。そこでDataRobotにはノートブック機能が追加され、コーディングを通じた自動化ニーズにも対応できるプラットフォームとなっています。またDataRobot外でコーディングベースで開発されたモデル(カスタムモデル)の運用管理にも対応しています。

[参考] DataRobot Notebooks, デプロイ用のカスタムモデルの準備

新世代のUI

このように「生成AIと予測AI」、「GUI操作とコーディング」といった新たなAI開発・運用ニーズに対応するため、UIも一新されました。

これまでのUIは個人作業、1つのデータ、1つのプロジェクト(予測AI)を中心に設計されたものでしたが、新世代のUI「NextGen」では、チーム作業を通じたより大規模な開発、複数のデータやモデリング設定を使った試行錯誤の一元管理、生成AI開発と予測AI開発の統合、GUI開発とコーディングの統合、などを実現しています。

[参考] NextGenエクスペリエンス

モデルガバナンス

DataRobotはモデルの開発プラットフォームであるだけでなく、モデル運用プラットフォームでもあります。デプロイ、モニタリング、チャレンジャーモデルの分析、再トレーニングとモデル置換、といったライフサイクル管理のほか、DataRobot以外で開発したカスタムモデルの運用や、外部予測環境にホストされているモデルのリモート監視にも対応しています。カスタムモデルの開発自体はDataRobotのノートブック機能でも可能です。加えて生成AIの文脈では、ガードモデルを簡単に利用できるようにするなど、モデルガバナンスに力を入れています。

エコシステムインテグレーション

学習・予測データはどこに保存されていますか？SnowflakeやDatabricks、あるいはAWS、Azure、GCPなどのデータウェアハウスやデータレイクをご活用でしょうか？また、AWSやAzure、GCPにモデルをデプロイしていますか？DataRobotはこうしたデータやAIに関するクラウドのプレイヤーとの連携を深めており、データ準備やモデルデプロイ、運用などをシームレスに行えるようになっています。

(例：Snowflake連携の概要)

新しい利用形態 – 専有型のマネージドサービス

冒頭にも述べた通り、DataRobotはマネージドサービス(「クラウド」)とセルフマネージド型(「オンプレミス」)の両方を提供しており、今この記事をお読みの方はセキュリティ上の理由から自社の専用ネットワークにインストールできるセルフマネージド型をお使いなのではないでしょうか。

しかしセキュリティを確保したいからといって、必ずしもすべて自社で管理したいとは限りません。運用管理にはコストと時間がかかり、バージョンアップを通じて新機能を利用可能になるサイクルもどうしても遅くなりがちです。

DataRobotでは新しい利用形態として「DataRobotシングルテナント」という専有型のマネージドサービスを展開しています。お客様はプライベートなネットワークに自社専用のDataRobot環境を持つというセキュリティ上の特徴を維持しつつ、マネージドサービスによりインフラの運用管理から完全に解放されることができ、新機能もタイムリーに利用することができるようになります。

DataRobotシングルテナントの詳細については当社または各代理店様までお問い合わせください。

新アーキテクチャ – 進化し続けるAIワークロードをコスト効率よく実行

自社固有のDataRobot構成が必要、といった場合は引き続きDataRobotのセルフマネージド型を使い自社管理で運用することができます。この時やはり気になるのは運用に伴うコストでしょう。

AIは一般に計算量の大きいワークロードであるため、AI製品の進化にともないコンピュートリソースの使用量は増していきます。これは、従量課金が一般的であるクラウドサービス(AWS、Azure、GCPなど)でワークロードを実行する際には特に気をつけるべき点です。

DataRobotは2012年の創業時点でコンテナを利用したマイクロサービスアークテクチャを採用した先進的なプラットフォームでしたが、進化し続けるAIワークロードを支える上で限界を迎えていました。コンテナの動的配置にまでは対応しておらず、また使いたい機能を支えるための最大限のコンピュートリソースを起動し続けておく必要があったのです。コスト削減のために、特定の機能の使用をあきらめて構成を意図的に小さくしているケースもありました。

バージョン8.xまでのアーキテクチャーの主な課題

そこでDataRobotはバージョン9からアーキテクチャを変更し、 Kubernetesアプリケーション化されました。Kubernetesはコンテナの自動オーケストレーションのフレームワークです。これによりすべてのコンテナをどのサーバーにでも動的配置できるようになってコスト効率が上がり、さらにオートスケール機能を活用してワークロードに応じたスケールアップ、スケールダウンを自動化できるようになりました。「AI機能を使わなくてもコンピュートにコストがかかる」アーキテクチャから「AI機能を使ったぶんのみコンピュートリソースを使う」アーキテクチャになったのです。

Kubernetesアプリケーション化によるリソース自動制御

新アーキテクチャによるコスト最適化により、新たに利用が可能になったり、利用しやすくなった機能をいくつかご紹介します。

GPU利用の拡大

機械学習モデルにおけるディープラーニングアルゴリズムの活用のほか、生成AIの文脈ではGPUの利用がますます欠かせないものとなっています。DataRobotではGPUを利用して生成AI関連機能を加速しているほか、NVIDIA社との協業によりLLMのローカルホスティング、ガードレールモデルの利用など、生成AIを企業で本格的に利用するための能力を拡大しています(参考：DataRobot Spring ‘24 Launch Event)。DataRobotの新アーキテクチャは、プレミアムなハードウェアであるGPUをコスト効率よく利用することを可能にしています。

カスタムモデルの運用管理

DataRobotでは、カスタムPython環境で開発したモデルや他社製品で開発したモデルをデプロイし運用管理することも可能です。これにより開発環境に関わらずモデル運用の統合的なビューを持つことができます。これはインフラ観点ではモデルごとにランタイム環境とそれを動かすコンピュートリソースを用意することを意味します。

カスタムアプリケーション(ノーコード、ローコード)

DataRobotでは生成AIや予測AIを利用したアプリケーションを実行することもでき、GUI操作だけで利用可能なノーコードアプリや、Streamlitなどのローコードフレームワークを使ってモデルを利用するインターフェースをユーザーに提供できます。このような機能にも一時的なコンピュートリソースが必要であり、新世代のDataRobotではこうしたAI用アプリケーションを簡単にかつコスト効率よく提供することができます。

DataRobot Notebooks

ノートブック機能は、そのインスタンスごとに一時的なコンピュートリソースを必要とします。こうした機能は、動的なリソース割り当てができるインフラなしには極めてコストが高いものになります。バージョン9以降のアーキテクチャでは、DataRobot内でノートブック/コーディングのニーズにも応えつつ、そのリソース使用を最適化することができます。

学習に利用可能なデータサイズ

モデルの学習に大きなデータを使おうとするほど、それに対応したメモリを確保するためより大きなコンピュートインスタンスが必要になります。バージョン8までのアーキテクチャでもモデル作成用のコンテナ、ノードはオートスケールの構成が可能でしたが、それを選択しない場合は小さいインスタンスを選択してコスト削減するかわりに利用可能なデータサイズを制限(5GBなど)するケースがありました。

バージョン9以降ではこうしたことを検討する必要はなく、各DataRobot環境で利用可能な最大サイズを利用することができるようになります。

おわりに：DataRobot AI Platformとそれを支えるアーキテクチャ

DataRobotは「AutoMLツール」から「AIプラットフォーム」へと進化しました。つまり、生成AIと予測AI、GUI操作とコーディング、モデル開発とモデル運用、など組織のAIニーズをトータルで提供する共通基盤となっています。モデル開発をカスタムPythonコードや他社のMLツールで行っていたとしても、DataRobotはそれらと連携し、モデル運用などその先のニーズを幅広くカバーしていきます。

そして、そのようなプラットフォーム機能を実際にコスト効率よく実現するためのアーキテクチャを導入し、継続的に革新しています。これからの発展にもどうぞご注目ください。

5/15(水) 15:00〜開催！【オンプレミス版ご利用の方必見】DataRobot 最新バージョンで実現する生成AIほか最新機能とそれを支える新たなアーキテクチャ

本ウェビナーではDataRobotセルフマネージド版(“オンプレミス版”)をご利用中のユーザー様、運用管理している管理者様向けに、DataRobot最新バージョンのv9、そして発表されたばかりのv10のハイライトをご紹介するとともに、GPUなどを含む多様なAIニーズをコスト効率よく実行できる新たなアーキテクチャや、新しい利用形態である専有型のマネージドサービスなどを解説します。

参考

バージョン10.0.xリリースノート

RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術

DataRobot Notebooks

デプロイ用のカスタムモデルの準備

NextGenエクスペリエンス

DataRobot Spring ‘24 Launch Event

投稿 DataRobot 最新バージョンで実現する生成AIほか最新機能とそれを支える新たなアーキテクチャ は DataRobot に最初に表示されました。

　このパートナーシップでは、ミッションクリティカルなビジネスデータを含むSAPソフトウェアのデータをDataRobot AI Platformに接続する事で、AI利用の拡大を促進するだけでなく、SAPのビジネスアプリケーションの更なる有効活用に貢献する事が可能になります。

SAPユーザー企業のAI活用を拡大する

従来、SAPユーザー企業は、機械学習モデルを利用する際、SAPデータからSAP Datasphere（旧SAP HANA Cloud上）でモデルを構築し、SAP上のモデルを展開しビジネス活用を行っていました。今回のDataRobotとの戦略アライアンスによって、SAPデータだけでなく、SAP以外のデータを活用する事で、より高度な予測AIの利用が可能になるだけでなく、より高度なモデルの運用管理が可能です。また、従来よりも扱えるデータの種類が増える事で、より多くのAI課題を解決する事ができます。

• SAPのみで予測モデルを構築する従来の方式（パターン1）:
  SAP Datasphere（旧SAP HANA Cloud）において、SAP環境で予測モデルの構築からモデルの展開まで一元管理する事が可能です。
• SAP & DataRobot連携（パターン２）方式：
  DataRobotのJDBCコネクタを活用することで、SAPユーザーはDataRobotからSAP Datasphere（旧SAP HANA Cloud）に存在するデータを活用して機械学習モデルをトレーニングすることができます。

生成した機械学習モデルを、SAP AI Core およびSAP AI Launchpadを活用してデプロイすることができます。

SAPユーザー企業がDataRobotを利用する理由

それでは、SAPユーザー企業がDataRobotを活用するメリットについてご紹介します。

1. SAPデータ&サードパーティーデータの活用
   SAP Datasphereとそれ以外のデータソースをDataRobotに収集/統合してAIモデルを構築できるようになります。SAPデータ以外を活用した予測モデルの構築が可能になる事で、より多くのAI課題に取り組めるだけでなく、従来の予測モデルの精度向上にも期待できます。
2. AIモデル構築環境
   データサイエンティストだけでなく、非データサイエンティストでもDataRobotを活用する事で、様々なデータソースの統合と探索、自動化された特徴量エンジニアリング、複数のMLモデルのトレーニングと評価、要因分析などが可能になります。これにより高精度なモデル構築/検証を短期間に行う事が可能です。
3. AIモデル運用環境
   開発したモデルをSAP上にデプロイし、監視、管理までのプロセスを自動化、効率化する事が可能です。自動化されたワークフローやツールを活用し、またSAPのアプリケーション上で予測データを活用した意思決定が可能になる事で、より多くのユーザーに展開できるプラットフォームを提供します。

適用可能なSAPユーザー企業向けユースケース

SAPユーザー企業はDataRobotを活用する事により、様々な成功事例のあるAIユースケースに取り組む事が可能になります。製造業や小売業・流通業におけるSCM(調達、製造、物流、販売、需給、アフターマーケットサービス）といったプロセスにおいて、サプライチェーンの最適化、きめ細かな需要予測、価格の最適化、タイムリーな予知保全などの様々なユースケースでご利用いただけます。これらの課題は、日本国内でも様々なお客様で成功事例がございますので、詳細のユースケースを知りたい方はこちらのPath Finderにアクセスください。

どのように進めるべきか？

SAPをお使いの方で、DataRobotの利用について詳細を確認されたい場合は、こちらにアクセスください。また、実際にトライアルでの利用も可能ですので、SAPとの連携検証もご体験いただけます。

投稿 DataRobotとSAPの連携から創出されるビジネス価値 は DataRobot に最初に表示されました。

今日のビジネスは、かつてないほどの大きなプレッシャーと不確実性の下で運営されています。 不確かな地政学的情勢、予測の難しい脆弱なサプライチェーン、進化し続けるパンデミックへの対応の長期化、世界各地に分散した従業員の原動力の変化などのあらゆる要因が重なり、さまざまな業種のビジネスが前例のない課題に直面しています。

DataRobot はこの度、ミッションクリティカルなイノベーションである DataRobot AI Cloud 8.0 をリリースしました。このリリースでは、 より多くのデータから信頼できるインサイトをタイムリーかつ継続的に提供するノーコード開発ソリューションにより、あらゆる企業が極めて予測が困難な市場にもインテリジェントに対応することを可能にします。DataRobot AI Cloud 8.0 は、40 を超える新機能と強化された機能を市場にもたらし、世界で最も信頼され、広く展開されている AI プラットフォーム をさらに拡充します。提供される機能は、以下のとおりです。

1. 時系列機能と AI アプリケーションビルダーの統合
2. オンプレミス環境を含むマルチクラウドアーキテクチャー全体に拡張された Continuous AI
3. Microsoft Active Directory を利用した Azure Synapse SQL との接続と Snowflake でのスコアリングコードの実行に対応する接続性の強化

これらの新機能を組み合わせることで、あらゆる企業が、極めて予測が困難な市場にもインテリジェントに対応できるようになります。

AI ドリブンビジネスのための DataRobot: より多くのデータから信頼できるインサイトをタイムリーかつ継続的に提供するノーコード開発のソリューションでビジネスを強化

コロナ禍の経済では、迅速で正確な意思決定が多くの組織にとって重大な差を生む可能性があります。このようなプレッシャーに直面する中、予測を自動化して現場の意思決定者に実用的なインサイトをもたらす方法を模索する企業がますます増えています。

​DataRobot AI Cloud 8.0 を利用すれば、組織内のすべてのユーザーが、ノーコード開発ツールを使って時系列対応のアプリケーションを構築し、実用的な予測をわずか数分で活用できるようになります​。AI アプリケーションビルダーに時系列機能を導入することで、需要予測、セグメントモデリング上に構築された極めて精度の高い大規模予測、ナウキャスティング、DataRobot の最先端コールドスタート予測モデルなどのあらゆるモデルから、市場環境の変化に強く、極めて予測が困難な環境にも適応できるインテリジェントなアプリケーションを作成できます。

​DataRobot は、お客様がビジネスアプリケーションを利用し、インサイトに基づいて迅速に行動できるのは、モデルの基盤となるデータが信頼できる場合だけであると考えます。このパンデミックで、私たちは成熟した​機械学習モデル​が一夜にして機能しなくなることを目の当たりにしました。なぜなら、2019 年のデータでトレーニングしたモデルを使用しても、2021 年の市場状況を把握して対応することができなかったからです。つまり、多くの AI システムが意思決定者に誤った提案を行い、そのせいでリスクが高く、失敗につながる経営判断が促されたのです。

​DataRobot 8.0 のリリースに伴い、DataRobot 独自の​ ​MLOps​​ 機能である ​​Continuous AI​​ をすべてのオンプレミスユーザーにご利用いただけるようになりました。これにより、DataRobot MLOps を利用するすべてのお客様が、Automated Machine Learning（AutoML）と Machine Learning Operations（MLOps）の両方の強みを活かしつつ、人間参加型（Human-in-the-loop）のアプローチをとることで AI/​ML のライフサイクル全体にわたって継続的にモデルを改善できるようになります。Continuous AI により、市場、顧客、標準の進化に合わせて、すべての実稼働モデルを最適化し、パフォーマンス、信頼性、倫理を確保できます。

ここで、ビジネスの基本的な考え方である「価値の実現」に立ち戻りたいと思います。データがなければ、インサイトやモデルを業務に利用することはできません。データは、従来のエンタープライズシステム、オンプレミス環境、データクラウドなどに幅広く分散させることができます。しかし、そのようなデータへのアクセスは複雑で困難な場合があります。統合された環境ですべてのデータに接続することは、これまで以上に重要です。

DataRobot AI Cloud 8.0 では、Snowflake を含む一般的なクラウドデータストアへの書き戻し機能を備えた構築済みの包括的な統合機能を提供します。この機能を利用することで、価値実現までの時間を短縮し、データへの障壁を取り除きながら、より多くの種類のモデルを扱えるようになります。また、DataRobot のスコアリングコードを Snowflake から直接実行できるようになったことで、データの抽出やロードが不要になり、大規模なデータセットのスコアリングをはるかに高速に実行できるようになりました。データが Azure に保存されている場合は、Azure Synapse Analytics に接続してライブラリーのインポートやエクスポートを実行することもできます。AI Cloud のお客様は、DataRobot のトップレベルの接続性を誇る AI Cloud 8.0 を使用することで、プラットフォームのエコシステムを継続的に向上させることができます。

DataRobot AI Cloud の拡張

DataRobot AI Cloud は、約 10 年にわたる先駆的な AI イノベーションの集大成です。このソリューションを市場に投入するために開発に 150 万時間を費やし、800 万行以上のコーディングを行っています。数百人のデータサイエンティストからなる DataRobot チームは、幅広いお客様に対応し、100 万件近いプロジェクトをサポートしています。DataRobot AI Cloud 8.0 を導入すれば、世界で最も信頼され、広く展開されている AI プラットフォームをさらに強化できます。

新機能および強化機能の一覧については、DataRobot ドキュメンテーションのリリースセンター​​をご覧いただくか、​​DataRobot コミュニティ​をご確認ください。

投稿 AIドリブンビジネスのための最新リリース DataRobot 8.0 は DataRobot に最初に表示されました。

今日、AI の価値を否定する人はいません。その一方、変化の激しいビジネス環境では、適切なタイミングで意思決定を行えるかどうかが企業の命運を左右します。収集できるデータの種類は多様化の一途をたどっていますが、私たちは、このデータをどのようにして本当の価値に変えることができるのか、常に確信が持てるわけではありません。時には、価値の高いインサイトを得るために、実験に何時間もあるいは何日も費やします。また、問題をよく理解していたとしても、プロジェクトを成功させ、ビジネスにインパクトを与えるには十分なデータがない場合もあります。

画像認識は機械学習の最も重要な分野の 1 つです。ディープラーニングでこのプロセスの効率を改善できます。​Tensorflow​（英語）、​​Keras​​、Pytorch などのフレームワークを利用すれば、精度の高い堅牢な画像認識アルゴリズムを構築できます。とはいえ、ディープラーニング​のスキルを持っている人材は多くなく、ビジネスに対する価値が実証されなければ GPU に投資できる予算の余裕がない場合もあります。

視覚的なデータからメリットを得られるのは誰でしょうか？

簡単に言えば「だれでも」です。e コマース、セキュリティ、医療画像解析、産業オートメーションなど、さまざまな分野が挙げられます。画像認識は、産業やビジネスにおいて多くの用途があります。AI テクノロジーは第 4 次産業革命で大きな役割を果たしており、すでにほとんどの企業に普及しています。

DataRobot Visual Artificial Intelligence（AI）

​DataRobot は 2020 年に ​DataRobot Visual Artificial Intelligence（AI）​​を発表しました。ベストプラクティスやさまざまなディープラーニングモデルを組み込むことで画像データに対応しています。私たちの最初のステップは、教師あり機械学習パイプラインに画像を含めることでした。DataRobot の他のプロジェクトと同様に、Visual Artificial Intelligence（AI）プロジェクトでは、デプロイ可能なモデルとそれに関連するモデルインサイトが実現しました。インサイトが組み込まれていると、良好か不良かの判別の際にモデルで入力画像のどの側面が重視されているかがわかります。

Visual Artificial Intelligence（AI）の新機能

Visual Artificial Intelligence（AI）を次のレベルに引き上げるために努力した結果、ここ数回のリリースでいくつかのすばらしい新機能をリリースしましたので、ご紹介します。

 1. 画像オーグメンテーション

データセットに十分な数の画像がなくても、もはやそれは問題になりません。​画像オーグメンテーション​を使うと、既存の画像をランダムに変換して、データセットから新しいトレーニング画像を作成できます。つまり、オーグメンテーションによってトレーニングデータのサイズが大きくなります。

2. クラスタリング

クラスタリング​​は、画像を含むあらゆるデータを対象としたクラスタリングモデルの構築とデプロイをワンクリックまたは 1 行のコードで実現する機能です。さらに、新しいクラスターインサイト可視化機能で、画像と他のあらゆるデータ型を組み合わせて、どのモデルのクラスターの理解、命名、説明も容易に行えます。

3. Visual Artificial Intelligence（AI）異常検知

これは、リリース 7.3 で発表された最も注目度の高い機能の 1 つです。Visual Artificial Intelligence（AI）異常検知により、ワンクリックまたは 1 行のコードで、より多くのユースケースに完全に対応できるようになりました。DataRobot AI Cloud プラットフォームでドラッグアンドドロップするだけで、すぐに使い始めることができます。

ユーザーエクスペリエンスも改善されています。darknetpruned、efficientnet-b0-pruned、mobiletetv3-small-pruned など、効率を高めた新しい画像特徴量抽出器が追加されています。

Visual Artificial Intelligence（AI）を試してみましょう

新しいタイプのデータとなると、どこから手をつけていいかわからないことが多いものです。画像を使用したプロジェクトの例で、どれほど簡単に処理できるかを詳しく見ていきます。このプロジェクトでは、表面の亀裂の画像を集めた公開データセット​公開ソース（英語）を使用します

コンクリート表面の亀裂は土木構造物の重大な欠陥であり、建物検査では剛性や引張強度が診断されます。ひび割れを発見したり、建物の健全性を判定したりする亀裂検出は、建物検査で大きな役割を担っています。

ステップ 1. データを送信する

他のプロジェクトと同様に、画像を含むフォルダーをドラッグアンドドロップするか、AI カタログに追加または共有されている事前ロード済みのファイルを使用するだけです。​探索的データ解析​​が完了したら、データが表示されます。

これで「良好」と「不良」の 2 つのクラスに分類された、38,402 枚もの画像を手に入れたことになります。

ステップ 2. 必要な設定を行う

ターゲット特徴量を選択して［開始］ボタンをクリックすると、膨大な種類の最先端ディープラーニングモデルの準備、選択、​トレーニング​が自動で実行されます。このプロジェクトでは、最近​リリース 7.3 で発表された、教師なしモードで実行することにしました。

ステップ 3. オートパイロットを実行する

［開始］ボタンをクリックすれば、あとは DataRobot AI Cloud プラットフォームが自動的に処理を実行します。他のプロジェクトと同様に、DataRobot は検定および交差検定のスコアを使用してトレーニングパイプラインやモデルを生成し、パフォーマンス指標に基づいてそれらを評価します。

モデリングプロセスが完了したら、高度なチューニングに進み、特徴量抽出機能や画像オーグメンテーションに設定を追加して、モデルをさらに調整することもできます。

ステップ 4. インサイトを得る

Visual Artificial Intelligence（AI）には、画像データ型に特化したツールが追加されています。それらツールは、モデルのインサイトを強化するために開発されました。

• 画像アクティベーションマップ​では、モデルが決定を下す際に使用している画像中のサンプル箇所を確認できます（アクティベーションの高低を表す色付きの領域に注目してください）。

画像埋め込み​では、画像のサンプルを元の N 次元特徴量空間から新たな 2 次元特徴量空間に投影して視覚化することができます。この機能により、どの画像が類似していると判断されているのかが簡単にわかります。

ステップ 5. モデルをデプロイして予測を行う

予測の実行と選択した環境へのモデルのデプロイは、他のモデルと同じくきわめて柔軟に行えます。わずか数回のクリックで、画像モデルを運用化できます。API エンドポイントや​ポータブル予測サーバー​（1 つ以上の実稼働モデルをホストできる Docker コンテナ）へのデプロイが可能です。プラットフォームの UI を利用すれば、最高クラスの柔軟性を持つバッチ予測が実現します。すべてのモデルのサービスの正常性と精度を監視し、サービスを中断することなく更新できます。​

今すぐ Visual Artificial Intelligence（AI）を使い始めましょう

これまでの説明からわかるように、膨大な数のユースケースの実現につながるプロセスは、思ったより簡単に始められます。もっと詳しくお知りになりたい場合は、Visual Artificial Intelligence（AI）ページをご確認ください。

投稿 視覚的なデータから最大の価値を引き出す は DataRobot に最初に表示されました。

2022 年も、はや 2 ヶ月が過ぎようとしています。2021 年は、​AI Cloud や​主要業界向けの新しいソリューション​の導入から、顧客向けに数百もの新機能をオンラインで提供し、複数の新たなテクノロジーやチームを連携して、顧客向けのアクティブな AI プロジェクトの数が 100 万を超えるという信じられないようなマイルストーンを達成するなど、あらゆる面で飛躍的な 1 年となりました。​

しかし、私たちが歩みを緩めることはありません。DataRobot は 2022 年も引き続きお客様にフォーカスした取り組みを続け、その一環として、コアコミュニティを対象とした ​​AI Cloud​ の機能強化と、​リリース 7.3 プラットフォームおける画期的な新機能の導入を行いました。

上級データサイエンティスト向け DataRobot Core：コーディング中心の作業で迅速な構築と大規模な導入を実現

DataRobot Core​​ は、目的に応じたテクノロジーをデータサイエンティストに提供する包括的な製品で、データサイエンティストがコーディング中心の作業で強力な​ AI ソリューションをすばやく組織に導入できるようにします。また、優れたテクノロジーを提供するだけでなく、包括的なリソースとして、ドキュメンテーションやサードパーティーとの連携機能を提供するほか、DataRobot の数百人の先駆的なデータサイエンティスト、および世界中の顧客企業やコミュニティに属する数千人のデータサイエンティストが持つ比類のない専門知識を活用できる独自の機会を提供しています。

​AI​ を民主化してあらゆるユーザーが利用できるようにするというビジョンは、DataRobot の DNA の中核を成しています。DataRobot Core では、コーディング中心の作業を好むデータサイエンティストに、それぞれのスキルや能力に適した世界トップレベルのソリューションを提供していますが、分析チーム、ビジネスアナリスト、IT 部門などが、今後もチームスポーツのように一丸となって AI を活用することも可能です。​

DataRobot Core は、きわめて重要な時期に市場に登場しました。今日の AI は紛れもなくミッションクリティカルです。収益の拡大を促し、ビジネスオペレーションのコストと非効率性を削減し、リスクを最小限に抑えることができます。こうした実績により、AI の需要が急増しています。それに伴って、データサイエンスチームには、明確なビジネス成果をもたらす AI を迅速に本番環境に提供することが求められています。

しかし同時に、企業の中核的な要件を満たす必要性が高まっており、安全で信頼性が高く、適切に管理および監視された強力で拡張性の高い AI の実現が欠かせない状況となっています。そのため、AI を構築するチームへの要求は高まるばかりです。チームが人材の採用を増やしているにもかかわらず、デプロイまでの時間を短縮できないのはこれが理由です。私たちが​最近行った調査​​（英語）によれば、きわめて高度なトレーニングを受け、高い専門性を持ったチームでさえ、いまだに労働時間の 50% をデプロイに費やしているケースが見られました。彼らは、付加価値を高めたり、データサイエンスの複雑な問題に取り組んだり、ビジネスに成果をもたらしたりするために費やすべきリソースを奪われているのです。

DataRobot は、こうした状況をすべて変えようとしています。世界トップレベルのデータサイエンティストチームを抱える企業として、私たちはデータサイエンティストが日々直面する課題を十分に理解しています。DataRobot Core は、データサイエンティストのために、次のような世界トップレベルの機能やサービスを提供することで、AI Cloud を強化しています。

プラットフォーム

• 多言語に対応し操作性がトップクラスの組み込みノートブック
• コーディング中心のモデル生成とモデルの自動生成をシームレスに組み合わせた Composable ML
• コードを駆使したパイプラインを Apache Spark で構築
• プログラムによる AI Cloud プラットフォーム全体へのアクセスを可能にする、Python および R クライアントによるオープン REST API
• 今日の企業が求める信頼性、ガバナンス、コンプライアンス、スケールの要件に対応

リソース

• アクセラレーター、サードパーティーとの連携、ライブラリの豊富な組み合わせにより、AI の導入を促進して効率を向上
• データサイエンスのスキルを向上させ、データサイエンティストが最先端で活躍するために進化する教育リソース

コミュニティ

• DataRobot の数百人のデータサイエンティストを活用
• データサイエンティストに特化した独自のインサイトと専門知識
• ピアコミュニティで、世界で最も成功した AI プログラムから得られた知識を共有​
• DataRobot のイベントでエキスパートレベルの専用プログラムを提供

私たちは、データサイエンティストが必要なツールや言語を柔軟に利用できる環境を提供することで、彼らがすばやく行動し、実験を行い、独自のスキルと創造性を業界が直面する困難な問題の解決に活かせるようにしています。また、ガバナンスが効いている安全なエンタープライズ向けプラットフォーム内で、シームレスな運用ができるようにしています。私たちは、コンプライアンスとガバナンスの機能が組み込まれたシームレスな製品を提供し、既存の IT プロセスやツールで運用や管理ができるようにして、データサイエンティストへの負担をなくすことを目指しています。

同時に、私たちはこの製品をより大きなチームのためのプラットフォームの一部にしたいと考えています。データサイエンティストは独自のニーズを抱えていますが、共通の目標を追いかける多様で幅広いチームの一員であることに変わりはありません。だからこそ、私たちはすべての機能を 1 つのプラットフォーム上に構築しました。また、データサイエンティスト、ビジネスユーザー、ステークホルダー間のコラボレーションを基本コンセプトとしています。

DataRobot Core​ のプラットフォーム、リソース、コミュニティをぜひお試しください。データサイエンティストがより成功し、ビジネスに素晴らしい結果をもたらすための支援をしたいと考えています

AI クラウドを進化させるリリース 7.3 の新機能

DataRobot Core に加えて、​​AI Cloud プラットフォーム​の最新版である DataRobot 7.3 もリリースされています。リリース 7.3 では、あらゆるユーザーを対象とした機能強化を行い、全社的かつ AI ドリブンな意思決定を 1 つのプラットフォームから行えるようになりました。

優れたコーディング機能

​共同作業が可能な多言語対応ノートブック、​​Composable ML、DataRobot パイプラインにより、さまざまなオプションを使ってデータをインポートし、そのデータを Spark SQL で変換して、カスタムブループリントを作成できるようになりました。これらの強力なツールにより、データサイエンティストは、本番環境への明確な道筋を立てて、迅速に実験を行うことができます。

さらに多様なユースケースに対応

DataRobot ではさらに高度なモデリングが可能になりました。画像異常検知でのネイティブサポートや、複数言語に対応する次世代の Text AI によって、より多くのAIユースケースにすぐに取り組めるようになりました。また、​​クラスタリング、​​セグメントモデリング​​、​マルチラベル分類などの新機能を利用すれば、データから最大限の情報を簡単に引き出すことができます。どのユースケースでも、開始前にコードを書く必要は一切ありません。​

パフォーマンス監視、コンプライアンス、規制対応機能の強化

コンプライアンスドキュメントの自動作成​​が DataRobot 以外で構築されたモデルにも適用され、すべてのユーザーが規制対応を効率的に行えるようになりました。本番環境にあるすべてのモデルを利用して、チャレンジャーモデルを実稼働モデルと簡単に比較および評価し、ビジネスのピークパフォーマンスを維持するためにモデルを置き換えるべきかどうかを明確に判断できます。

そのほか、バイアスと公平性の監視​​が強化され、AI ライフサイクルのあらゆる段階で各モデルの公平性を確保できるようになりました。

また、​アプリケーションビルダー​に時系列のサポートが追加されました。シンプルなドラッグアンドドロップウィジェットを使うだけで、自在にカスタマイズされた AI アプリケーションを時系列モデル上にすばやく構築してデプロイし、時系列の予測値と実測値を比較して各予測の理由を分析できます。

その他の新機能および機能強化

DataRobot リリース 7.3 では、多クラス分類の対応クラス数制限撤廃、スコアリングコードの​「予測の説明」への対応​、​MLOps エージェント​​の強化、および 80 を超える新機能によって、あらゆる組織が AI の可能性を最大限に引き出すことができます。
新機能および強化機能の一覧については、プラットフォームドキュメントのリリースセンター​をご覧いただくか、​DataRobot コミュニティ​​にご参加ください。

投稿 上級データサイエンティスト向け DataRobot Core およびリリース 7.3 の詳細 は DataRobot に最初に表示されました。

原則１－ガバナンス：取締役会等及び上級管理職は、モデル・リスクを包括的に管理するための態勢を構築すべきである。

AI 推進のための組織構築は多くの企業が検討してきたが、管理運用のための組織構築はまだ未着手という企業がほとんどであろう。本原則によって指針は示されたものの、実際に具体への落とし込みをする際にその難しさが顕在化するであろう。特に Part 1で述べたことの再強調になるが、AI モデル・リスクの管理を特定の個人のみに依存するのは限界がある。膨大なデータを扱い、複雑な処理を実施する AI モデル全てを人の頭脳によって把握・記憶することは困難であり、また例えできたとしてもそれは個別の力量の高い者に頼った結果であり、それらの者のリテンション問題が不安定要素として常に付き纏う。運用するAIモデルが多ければ多いほど、その限界は顕在化し、ツールをも活用した管理態勢が検討の俎上に上がってくるであろう。

原則２－モデルの特定、インベントリー管理及びリスク格付：金融機関は、管理すべきモデルを特定し、モデル・インベントリーに記録した上で、各モデルに対してリスク格付を付与するべきである。

昨今の AI プロジェクトは複数メンバーが担う傾向が高く、また人材の流動性が高くなっている観点からインベントリー管理の重要性は以前より高まっている。
気をつけるべきことは AI モデルはデータとコードから生成されるバイナリファイルに過ぎない点である。手元の AI モデルがなんのために生成されたものなのか、どういったデータとコードから作成されたものなのか、を正しく記録しておかないと再現性を満たすことができない。さらにコードとデータだけでなく、リスク格付など作成手順には含まれない情報も管理することが AI モデルの構築・運用におけるリソースをどこに割くのか判断する上で重要となる。

DataRobot はユースケース（AI 活用プロジェクト情報）登録機能を有している。AI モデルを生成するために利用したデータ、AI モデル生成過程が記録された AI モデル構築プロジェクト、運用に利用している AI モデルと IT アセットを登録するだけでなく、AI モデルが何の業務のために利用したものなのかや、AI モデルのビジネスにおける重要性（リスク格付）などの情報を登録・保持することができる。またユースケース登録機能で作成された各ユースケースは他のユーザーやグループに共有することが可能である。第1線がAIモデル作成まで完了した上で、ユースケースを第2線に共有すれば、それに紐づくデータやAIモデル構築プロジェクト、AIモデルへの参照を一元的に渡すことができる。
また、ユースケースへの更新はアクティビティとして全て記録されているため、第2線はどのような手順で第1線が AI モデルを構築していったのかを辿ることができ、そしてそこにコメントを残して再度第1線に返すこともできる。

原則３－モデル開発：金融機関は、適切なモデル開発プロセスを整備すべきである。 モデル開発においては、モデル記述書を適切に作成し、モデル・テストを実施すべきである。

AI モデルは、入力に対して確率値を返す動作は誤った AI モデルでも同じであるため、従来の IT 的なテストだけでなく生成元のデータとコード自体をチェックする必要がある。特に AI モデル生成には乱数が利用されるものも多いため、その再現性が可能な形で開発プロセスを整備する必要がある。さらに特定のツールで作成された AI モデルにおいては、そのツールが仮に利用できない状態になった場合での AI モデルの利用や再現を考慮することも重要である。そして AI モデルの限界を把握するためには、AI モデルの性質を可視化できるようにしておくべきであり、具体的には学習時に存在しない値や欠損データに対してどのように振る舞うのかなどを把握しておく必要がある。
精度面での検証では、ホールドアウト（= 学習に利用していないデータ）を利用する。これは学習時のデータだけではなく、未知のデータに対してもパフォーマンスを発揮する（= 過学習していない）AI モデルになっているかを確かめるために重要である。そしてホールドアウトそのものに過学習した AI モデルとなる可能性を防ぐ上でも、第1線からはホールドアウトが閲覧できない形で AI モデル構築を行える仕組みがあることが望ましい。

DataRobot は、AI モデル構築ステージにおいて、ブループリントと呼ばれるデータ前処理とアルゴリズム、ハイパーパラメータのチューニングが組み合わさったテンプレートが自動的に多数実行され、精度順にリスト化される仕組みとなっている。その上で、AI モデルが構築する上での学習データと検証、ホールドアウトデータの分割や全ての AI モデルに共通なモデル可視化機能も自動で実行される。また AI モデルの差別も海外では頻繁に問題として取り沙汰されているが、DataRobot は AI モデルが差別的な判定をしていないか、様々な尺度から構築段階で検知する仕組みを有している。
またベンダーロックインを防ぐ上で、より包括的なモデル記述書として、SR11-7に対応したAI モデル構築に関するモデルコンプライアンスレポートを自動で生成することも可能である。

原則４－モデル承認：金融機関は、モデル・ライフサイクルのステージ（モデルの 使用開始時、重要な変更の発生時、再検証時等）に応じたモデルの内部承認プロセスを有するべきである。

シャドウ IT という言葉が一時期話題になったが、AI モデルが誰にでも手軽に作成できるようになった今、「シャドウ AI モデル」が社内に氾濫する可能性がある。そのため、AI モデルを安全に正しく使う上でも、第2線からの独立的なチェック体制及び、稼働開始フローをシステム的にも整備することが重要となる。また AI モデルは導入後にも時間とともに精度が劣化する性質から、定期的な再学習を必要とする。すなわち、AI モデルにおいては使用開始時のみに気を配るのではなく、再学習という変更の発生が従来の IT システムに比べて頻繁に起こることを考慮した内部承認プロセスを構築する必要がある。

DataRobot では AI モデル・ライフサイクルのステージに合わせたタスク、またそのタスクへの関わり方に応じて権限分掌を行うことができる。そして、権限分掌を行った上で、AI モデル・ライフサイクルのステージ変更及びその AI モデルの重要度に応じて、設定した承認ポリシーに従った承認ワークフローを設定することが可能である。これにより、第1線と第2線での内部承認プロセスをシステムとして構築することができるようになる。

原則５－継続モニタリング：モデルの使用開始後は、モデルが意図したとおりに機能していることを確認するために、第１線によって継続的にモニタリングされるべきである。

AI モデルは時間とともに当初想定していた性能を発揮しなくなる。また急激な市場の状況やその他の環境の変化等によって AI モデルの性能が大幅に劣化することは少なくない。実際、本稿執筆時（2022年3月）、新型コロナウイルスの蔓延に伴い、過去に作成された多くの AI モデルが再作成を余儀なくされている。このような AI モデルの性能変化を適切な間隔でモニタリングすることで、モデルを再作成するべきタイミングを適切に検知し、劣化したモデルの使用によってもたらされる経済的損失を未然に防ぐことができる。AI モデルにおけるモニタリングポイントは、従来のシステム的な「サービス正常性」と AI モデル特有の「データドリフト」と「精度変化」の三点となる。
「サービス正常性」とは、運用に利用している AI モデルがシステムとして正常に稼働しているかを確認するものである。未知の入力が来た場合のエラーハンドリングをできているかなども含まれている。また従来の統計モデルに対して複雑化した AI モデルは推論時においても処理時間がかかるものもあるため、想定時間内に計算が完了しているかなどもチェックは必須となる。
「データドリフト」とは、AI モデルの運用にとって非常に重要な概念となる。学習時と推論時の各特徴量（説明変数）の分布が変化したことを表現する言葉で、データドリフトが発生していると AI モデルが学習時と同等の性能を発揮しない可能性が高い。データドリフトが発生する要因はいくつかあるが、代表的なカテゴリとしては以下の2つとなる。

• 時間経過とともに全体のトレンドがドリフトするもの
• 学習時と推論時の条件違いによって発生するもの

「時間経過とともに発生するデータドリフト」も、緩やかに発生するものや急激に発生するもの、周期的に発生するものがあるため、データドリフトが発生するサイクルに合わせて AI モデルの再学習を計画することが重要である。これらのドリフトは世の中のトレンドに影響を受けて起こるため、AIモデル作成者自身もその発生タイミングで感覚的に気づける場合が多い。
もう一つの学習時と推論時の条件違いによるデータドリフトは、データ変換処理上の違いが原因で発生する。同一の変換処理を利用しない理由として、例えば”学習時にはバッチで学習データを準備したが、運用時はオンライン推論だったため、それぞれの処理で通るデータパイプラインが違った”などが存在する。
変換処理の違いで実際に起こりうるものには以下のようなものがある。

• 学習時にだけ表記ゆれを修正し、推論時には表記ゆれ修正を行っていない
• 学習時と推論時でエンコーディングが違い一部の値が別の値として認識されている
• SQL の処理系の中で学習と推論時で欠損値の扱い方が違う

これらはそもそもがミスが起点で発生しているため、AI モデル作成者が捉えることは難しい。ただし、データドリフト検知を実施することによってミスに気付くことができるため、中長期的な AI モデル運用だけでなく、短期的なモニタリングにおいてもデータドリフト検知は重要となる。
「精度変化」はそのまま AI モデルの最終パフォーマンスを見るものだが、注意すべきは、精度が変化したことに気づくまで推論時点からはラグがあるということである。仮に AI モデルが3ヶ月後のデフォルトを予測しているものだった場合、その正解データは3ヶ月後にならないと収集することができない。この点からも AI モデル運用では精度変化を検知することも重要だが、精度変化だけでなく、先に上げたデータドリフトをモニタリングし、未然にリスクを検知することが重要となる。

DataRobot 内で作成した AI モデル及び Python、R、SAS などで作成した AI モデルを DataRobot に取り込んだ場合には自動的に「サービス正常性」「データドリフト」「精度変化」を時間および特定のセグメントごとにモニタリングできる。また DataRobot から外部に書き出された AI モデルでも、エージェント機能によって「データドリフト」「精度劣化」を同様にモニタリングできる。そして、運用状況をデプロイレポートとしてスケジュールされたタイミングで自動発行する機能も有しているため、AI モデルが増えた場合においてもスケールする運用体制を構築することができる。

原則６－モデル検証：第２線が担う重要なけん制機能として、金融機関はモデルの独立検証を実施すべきである。独立検証には、モデルの正式な使用開始前の検証、重要な変更時の検証及びモデル使用開始後の再検証が含まれる。

第2線に関する議論、特に体制面での議論に落とし込むと、一つ大きな課題が見えて来る。本原則の3つの防衛線ルールでの第2線は、原則1.4においてそれが第1線から独立すべき監督部門となるべき、とされている。第3線が管理態勢全般への監督を役割とする以上、実質的な管理監督の要はこの第2線であるため、その役割は極めて重大だ。ただ、”この役割に付きたい人はいるのだろうか？”
AI モデル分析は現在最も先進性/将来性の高い領域の一つだ、データサイエンティストを志す者が、膨大な時間をかけてスキルを身につけてきたのも、その最前線で挑戦を続け、更なる高みとリターンを目指すためであり、「管理監督」という一歩引いた役割を望む者は少ないであろう。一方でAIモデルリスク発生時のインパクトを考えれば、企業としてはこの役割に最先端の知識を持つ者を配置したい。米国での AI 普及の初期を振り返ってみると、多くの企業でこのギャップが見落とされていた。例を挙げると第2線に引退間近の人員を配置し、管理態勢が形骸化し、リスクへの防衛が疎かになってしまった。この課題を解決し、強固な第2線体制を構築するには3つの方法があり得る

①    系列企業の第1線同士が検証し合う体制の構築
②    第2線ポジションの魅力向上
③    牽制役ではなく、第1線と共闘する第1.5線の設計

①   
ごく自然に思いつく打ち手だが、系列各社の第1線が他社の第1線の AI モデルを検証することができれば、上記の課題にはなりうる。金融庁の質疑回答を確認する限り、この対策は推奨されているとまでは言えないが、明確な否定もなく、その妥当性はどちらかと言うと、企業ごとの実務的な有効性次第であろう。系列企業とは言え、業務を異にする以上、他社の AI モデルをどれだけ理解し、有効な検証ができるかは各社が慎重に判断すべきであろう。

②     
上記の打ち手が現実的でない日本企業には、米国企業の反省を踏まえると、ぜひ第2線のポジションの強化、そしてそのための人材キャリアパス設計を進言したい。端的に言えば、第2線での役割でも十分な報酬を期待でき、社内的にも将来性のあるキャリアパスが見えれば、スキルの高い人材にも十分魅力的なポジションとなる。
このような管理監督ポジションはどうしても軽視されがちだが、今一度AIモデルリスクのインパクトを概算して頂きたい。その数字を見れば、このポジションにいくらのコストをかけるべきか、自ずと見えて来るはずだ。

③     
また、そもそもの役割として第2線を単なる第1線に対する牽制役とすべきではなく、もっと第1線と共闘する役割と考えても良いのではないか。第2線のポジションはある意味、ガードレール的な役割だが、現在 AI モデルリスク管理においては絶対的に正しいガードレールは存在しない。ならば、第2線は第1線がやろうとすることの本質を正確に捉え、リスクを抑止しつつ、その実現をサポートする、いわば「第1.5線」の役割である方がより現実的である。それにより第1線はより積極的に第2線の協力を仰ぐようになり、“守り”だけではなく、“攻め”をも兼ねた AI モデル検証体制が構築できるはずだ。

原則７－ベンダー・モデル及び外部リソースの活用：金融機関がベンダー・モデル等や外部リソースを活用する場合、それらのモデル等や外部リソースの活用に対して適切な統制を行うべきである。

ベンダー・モデルのデータやパラメーター等が不透明な場合に生じるリスクとしては、以下の2つが存在する。

• ベンダーがサービスを停止した際に再現性が保てなくなるリスク
• モデルの特性や限界を正しく把握できないリスク

1つ目のリスクはベンダー・サービスより API 経由で AI モデルを利用している場合などにおいて、その API が使えなくなることを意味する。このリスクを回避するためには、AI モデルをベンダー・サービスと切り離せる何らかの仕組みをそのベンダーが提示できるかどうか確認する必要がある。
2つ目のリスクはベンダー・サービスの AI モデルに予期しないバイアスが含まれていることやどのようなパターンで精度が劣化するか把握できていないことを意味する。リスク回避手段の一つは、AI モデルの性質を調べるためベンダーに学習用データとコードの開示を要求することだが、学習データやコードの開示はそのベンダーの知的財産にも関わるため現実的ではない。現実的には、AI モデルのリスク格付けが高いものに関しては、ベンダー・モデルの利用を停止するという手段も選択肢にいれるべきである。補足となるが、近年の AI モデルは複雑化しており、ベンダー・モデルが一部処理のみで使われている場合も存在し、一見手元のデータからゼロベースで学習させたと思っていても潜在的にベンダー・モデルが紛れている可能性もある。そのため、AI モデルの透明性を求めた上でその内容を注意深く確認する必要がある。

DataRobot は、基本的には企業内での AI モデルの内製化を目指したプラットフォームであり、ベンダー・モデルに該当するケースは多くはない。ただし、一部の高度な分析テンプレートにおいては、事前学習済みのモデル（高度な自然言語処理や画像データの前処理）を含んだものが存在する。DataRobot では、これらの処理が使われた AI モデルかどうかを確認することができるため、該当処理を含まない AI モデルを選択することもできる。また、他の処理は残したまま、該当処理だけを除きたいという要望に対しては、自動生成された分析テンプレートを編集する ComposableML 機能も備えている。
そして内製化を目的としてDataRobotを導入しても、その利用者をすべて外部リソースに頼っている場合には、活動の結果を理解し、適切に評価することは難しい。外部リソースの活用をリスク管理を実施した上で実現できるためにも、ツールの導入だけでなく、人材育成は重要なウェイトを占めることになる。

原則８－内部監査：内部監査部門は、第３線として、モデル・リスク管理態勢の全体的な有効性を評価すべきである。

第3線の論点も多々あるが、一つ絞るなら、“今ではなく、これから”を見据えた管理監督が求められる。監督対象として企業が“今”どんな AI モデル・リスク管理態勢にあるのか、は当たり前として、第3線は企業の AI 戦略、つまり“これから”やろうとすることまで、助言し監督すべきである。さらにその前提として、常に最新のトレンドと情報を踏まえたアドバイスを求められる。前述のように AI モデルリスクがどんどん進化する以上、管理監督の論点も変化し続けているため、それらをいち早くキャッチアップし、社内での検証・改善に落とし込める機能が第3線に求められる。しかし、そこまで行くとやはり管理監督体制は一朝一夕で構築できるものではない。したがって企業によっては一定の外部支援を初期は求めるのも一つの手であろう。

まとめ

本稿ではあくまで AI モデルに注視して記述したが、モデル・リスク管理の原則では、モデルの定義は統計モデルやルールベースモデルなど、様々な手法をカバーするものと回答されており、AI モデルに限定されるものではない点には注意が必要となる。
リスク管理では、組織的な体制、人材の育成、またそれらをサポートするシステムが重要となる。AI モデル活用が金融機関において拡大中のいま、本ブログ及び弊社ソリューションが参考になれば幸いである。

参照文献

金融庁：モデル・リスク管理に関する原則
金融庁：コメントの概要及びコメントに対する金融庁の考え方
COSO──ガバナンスと内部統制３つのディフェンスライン全体でのCOSOの活用
三つの防衛線（3つのディフェンスライン）によるリスクマネジメント
Machine Learning in Production: Why You Should Care About Data and Concept Drift

投稿 モデル・リスク管理の原則におけるAIモデルの対応について Part 2 は DataRobot に最初に表示されました。

本稿は二部構成をとっている。Part1 では金融庁の示すモデル・リスク管理における8原則への対処を思案する上での重要論点を整理し、Part2 では各原則について個別に DataRobot を利用した対処案を説明する。（AI モデル・リスク管理は金融業界だけでなく全ての業界で遅かれ早かれ具体的対処が必要になる重要項目であると考えられるため、金融業界とは直接関わりがなくてもDataRobot が提唱する対処法・機能についてご興味のある読者はぜひ Part2 だけでもお読みいただければ幸いである）

今回、本原則の発表は金融業界にとって青天の霹靂では無いはずだ。元々モデルの管理を規定する SR 11-7 は米国で早くから導入されており、日本にもいずれ類似の業界ルールが規定されることは予見できた。それでも、本原則の正式発表は、今まで各社が企業単位で独自努力と理解の範囲で行って来たモデルリスク管理がとうとう、業界単位でのルール規定の下に、チェックされることを意味している。それは、モデルリスク管理が金融機関にとって最重要アジェンダである時代の到来を告げている。

DataRobot は米国で、SR 11-7 が登場した黎明期から、AI モデルガバナンスの支援を AI 活用をリードする金融機関に対して実施して来た。その経験は本原則への対応でも参考価値があると考えられる。

本原則を議論する上での論点は下記のように大まかに整理できる：

①    本原則の対象となる企業はどれか？
②    管理対象となるモデルはどこまでか？
③    管理すべきリスクとは何か？
④    ガバナンス（管理体制・社内ルール）をどのように設計すべきか？

本稿は主に上記論点④の範疇にあるが、論点①、②、③における要点をまず述べさせて頂きたい。端的に要点をいうならば、

①　本原則対象は今後将来的に拡大する可能性は高い。
現状、G-SIBs、D-SIBs、FSB により選定された G-SIBs（本邦 G-SIBs を除く。）の本邦子会社であって、金融庁によるモデルの承認を受けている金融機関が対象となっているが、SR11-7 のトレンドを見ても、日本では今後対象範囲が拡大することは必至だ。
また、原則の対象外になっているからと言って、例えば現対象の子会社がモデルリスク管理をしていない訳ではない、子会社ごとに方向性の異なる管理アプローチが進むと、いざ対象範囲内に入った時に、親会社を含めたグループ全体の管理方針に齟齬が生まれてしまう。現時点から先取って、子会社をも検討の範囲内に含めることは長い目で見れば間違い無く多くのコストを節約することができる

②　本原則の発表により、管理すべき対象はより広義のものとなった。
恐らく、直近ではまずこれが各対象企業にとっての一番の頭痛であろう。本原則では、明確な線引きはされていないが、質疑応答などをも含めて読み解くならば、広義にモデルを解釈する方向性は確かだ。各業界/企業ごとの事情によるため、一概に論じることは難しいが、ガバナンス体制を検討する上でも影響は出てくる。
*本稿においては、より精緻な議論のため、広義のモデルの中でもあえて AI モデルに範囲を制限していきたい。AI は近年金融業界で業務利用が急拡大する一方で、運用管理について悩まれている企業がまだ大多数であり、議論の価値が高い領域と認識している。

③　AI モデルリスクは絶えず変化/進化しており、現状特定できていないリスクにも備える必要がある。
これは本原則というよりも、近年の AI モデルの進化とそれに伴う事件を見れば、AI モデルリスクというもの自体、まだ我々が把握しているのはほんのわずかであり、今後AIモデル活用が本格化するに連れて、どんどん新しいリスクも発生する。例えば、AI モデルのバイアスによる不公平性のリスクは、凡そ今まで予見が難しいリスクであった。そのような新しいリスクをいかに早くキャッチアップし、自社における対策を講じることができるのか、これもガバナンス体制に問われるポイントの一つとなりうる。

④　構成においては、他のリスク管理と同様に、実効的なけん制を確保する基本的な枠組みとして、「3つの防衛線（3線モデル）」の概念の下で整理する。
この中で、「第1の防衛線（第1線）は、モデルを所管する又はモデルの開発・使用に直接関係する部門・個人で構成される（モデル・オーナー、モデル開発者、モデル使用者等）。」を想定と書かれているので、実際に AI モデルを構築するデータサイエンティストが含まれることになる。そして「第2の防衛線（第2線）は、第2線に対するけん制を通じてモデル・リスクを管理する部門・個人で構成され、モデル・リスク管理態勢の維持、規程等の遵守状況及びモデル・リスク全体に対する独立した立場からの監視、モデルの独立検証等の役割を担う。」を想定と書かれていることから普段業務においては、AI モデル構築は行わないながらも、監視や独立検証ができるレベルということで、第1線以上のデータサイエンススキルを求められることになる。最後に、「第3の防衛線（第3線）は、内部監査部門で構成され、金融機関のモデル・リスク管理態勢の全体的な有効性を評価する。」となることから、単純なデータサイエンススキルだけでなく、企業の AI 戦略を見据えることができる人材を必要とする。これらの構成を満たした上で、さらに理想とするガバナンス体制は、透明性、継続性、効率性の3つのキーポイントを実現できるものであるべきである。

AI モデルリスク管理のガバナンスにおける絶対的な正解はまだ無いが、米国の金融機関の先端的な取り組みを支援して来た DataRobot の経験から見えてきたキーポイントの中で、特に重要な3つのキーポイントがあると考えている。そして、DataRobot は下記の3つを満たすガバナンス体制の構築には、人にだけ依存するのではなく、ツールをも活用することを提言している。

・    透明性
・    継続性
・    効率性

上記で論じたように、AI モデルリスクはまだ絶えず進化しているものである。世界中で膨大な数のAIモデルが運用されており、今まで想定していなかったリスクが突如現れる。ここ数年、これらのニュースは幾度も金融業界を騒がせてきた。新しいリスクの発現において、企業がまず実施すべきは、自社での類似の運用状況の把握である。そこにおいて、人に依存しない透明性が重要となる。”うちには優秀なデータサイエンティストがいて、その人に聞けば状況把握は全てわかる！”、と安心している企業は多いのかもしれない。ただ、それは盲信・過信の危険性があり、ガバナンスの思想ではない。どのようなデータを持ち、どのように分析し、どのように運用されているかの状況は理想として、人の頭にではなく、全てツールとして記録され、誰もがすぐに、明確に把握できるようにすべきだ。

継続性も上記議論から生じるものだ。人への依存には、転職・各種事由による勤務不能、パフォーマンスの不安定などのリスクが付き纏う。第1線、第2線のキーマンが離職したばかりの時期に、AI モデルリスク側が空気を読んで発生を控える、ということが望めない以上、ガバナンスの根幹として人への依存は可能な限り抑えるべきである。

最後に効率性も見落としてはならない重要なポイントである。ガバナンスの目指す姿を今一度お考え頂きたいが、リスク回避だけがガバナンスの目的では無いはずだ。”リスクを抑制しつつ、業務効率をも維持すること”が理想像のはずである。恐らく、AI モデルリスク管理を具体的に検討した企業はすぐにこの難題にぶつかるであろう。本原則1.3で求められる、”文書化”、は実務者から見れば、”言うは易し・・”の典型である。AI モデル活用は今最も進化が活発な技術領域であり、第1線のデータサイエンティストは日々トライアンドエラーを繰り返しており、また扱うデータの種類・量も膨大である。それらを管理監督の実効性を維持できるレベルで記録する手段は、具体的にどう設計すれば良いか？AI モデル構築・運用を行いつつ、横手で一つ一つのアクションをエクセルなどにでも記録するのか？それは現場を無視し、効率低下を招く非現実的な管理手法に他ならない。AI モデルの構築・運用、そして記録、それらが自動的に、シームレスに、一つのプラットフォーム上で行われるべきである。記録という行為で人への依存をできる限り抑止する、それは、効率性のみならず、正確性の観点からもガバナンスの理想像と言える。

”人への依存の抑止”、は DataRobot が提供する重要な付加価値の一つであり、それは Part2 でより具体的に、技術的に解説していく。その根幹をなす思想として、上記3つのキーポイントの観点があることを覚えて頂きたい。

各原則については、Part2 にて DataRobot としての対処案をより具体的に論じていくが、その概要を下記に提示する：

Part 2に続く。

投稿 モデル・リスク管理の原則におけるAIモデルの対応について Part 1 は DataRobot に最初に表示されました。

さらに進化した Text AI

組織が持つ情報の80%がテキストで保存されていると言われています。テキストデータは蓄積が容易な一方、人間の言語のあいまいさにより、分析は非常に困難な場合があります。大量かつ複雑な非構造化データを扱うからこそ、DataRobot はユーザーがテキストからインサイトを引き出す手助けをすることに注力してきました。DataRobot のインテリジェントな AutoML​ を、テキストデータに対して教師ありモードまたは教師なしモードで使用し（他のデータ型と組み合わせることもできます！）、ボタンを 1 回クリックするだけでモデルをトレーニングできます。さらに、上級ユーザーであれば、パラメーターをチューニングすることや、​​DataRobot​ がどのようにデータを処理し、どのようにモデルを構築するかを​ Composable ML​ で自由に設定することも可能です。データ、モデル​、ブループリントに関する説明はプラットフォーム全体で充実しており、いつでも結果を理解できます。テキストデータに DataRobot を使用することで、モデルの可能性を最大限に引き出しましょう。

7.3 の新機能でテキストデータの価値を引き出す

多様な言語とデータ型

DataRobot では、各言語のテキストに制限や注意点を設けることは考えていません。そのため、プラットフォーム全体を通じて言語に依存しない技術を使用するようにしており、プラットフォームのパワーを常に最大限に活用できます。DataRobot に取り込む言語に関係なく、同様の優れた結果を常に期待できます。

多くの場合、テキストデータだけで十分とは限らず、他のデータ型と組み合わせて使用したい場合もあると思います。Text AI では、データセットに含まれている他の特徴量型のデータとテキストデータを自由に組み合わせることができます。数値、カテゴリー、日付、画像、地理空間、時系列、リレーショナルなど、DataRobot がサポートするすべての特徴量型のデータとテキストデータの組み合わせが可能です。多様な特徴量型を使用することで、AI モデルをより広い視野で見ることができます。

より少ない労力でより多くの価値を生み出す

DataRobot の幅広いオプションを利用して実験してみましょう。​DataRobot の AutoML​​ や​ AutoTS​ を使用して、分類、予測、連続値などさまざまなデータサイエンスの問題に取り組みましょう。膨大なテキストデータのどこから手をつけていいかわからない場合は、DataRobot の教師なしモードを起動し、クラスタリングや異常検知を利用すれば、データのパターンとインサイトを見つけることができます。何よりも、ノーコード、ローコード、フルコードのいずれで進める場合でも、これらの手法はテキストに対してすぐに使用できます。中間技術的なテキスト特徴量の抽出手法から解放され、組織のビジネス問題の解決に集中できます。インフラストラクチャとディープラーニング技術への対応は​​プラットフォームに任せ、組織に価値をもたらすことに最大限の力を注ぐことが可能です。

より高度な作業が可能

DataRobot の Text AI では、さまざまなテキストおよび​ NLP​（英語）手法 （”bag-of-words” モデル、tf-idf、コサイン類似度、FastText、TinyBert、NLTK、spaCy、ストップワードの除去、語幹処理、レンマ化など）をテストできます。これらの手法はすべてプラットフォームに組み込まれており、特定のニーズに合わせて容易に利用および設定できます。

説明可能性と信頼の向上

Text AI により、お客様のテキストデータを ​​DataRobot プラットフォームがどのように利用し、その結果どのような洞察が得られたかが簡単に理解できるようになりました。テキストによる説明は、プラットフォーム全体、およびモデルの構築と評価のプロセス全体に組み込まれており、以下の内容が含まれます。​

• ​探索的データ解析​ – 頻出値と特徴量の値​
• モデリング – テキスト特徴量の抽出手法とそのパラメーター、高度なチューニングで利用可能な前処理のための手動オプションやパラメーター、特徴量のインパクト​、​特徴量ごとの作用​、​​クラスターインサイト、ワードクラウド

DataRobot は、お客様がテキスト特徴量について理解し、それを他の特徴量と組み合わせるとどのように機能するかがわかるように、あらゆる段階でサポートします。テキストによる説明（およびプラットフォーム全体での説明可能性）は常に更新しています。今後、さらにエキサイティングな説明機能が追加される予定です。

さまざまな業界でさらに価値を創出

DataRobot は多くの業界のさまざまな​​ユースケース（活用方法）​に対応しています。個人的に非常に興味深いと感じたユースケースをいくつか紹介します。​​

採用候補者の推薦 ​​– DataRobot モデルは、ラベル付きの履歴書（採用または不採用）をテキストデータとして使用することで、過去の採用傾向を学習し、採用候補者を予測・推薦することができます。DataRobot は、td-idf と固有表現抽出技術を組み合わせることで、採用担当者による応募者評価方法を理解するためのモデルを構築し、それを予測で再現することができます。

サポートチケットのルーティング ​​– ラベル付きのサポートチケットに基づいて構築された DataRobot モデルは、組織がトピックを特定し、解決に適したサポートアシスタントへ正しくルーティングするのに役立ちます。サポートチケットの説明に基づくトピックモデリング（テキストによるクラスタリングを使用）をラベルなしのサポートチケットで使用して全般的な傾向を見つけ、サポートチームが新しい問題や新たに発生したテーマを特定できるよう支援することもできます。

Text AI を今すぐ始めましょう

​AI Cloud プラットフォームを導入済みなら、すぐに Text AI の使用を開始できます。新しいリリース 7.3 に含まれており、すべてのエディション、オンプレミスとクラウドのすべてのデプロイオプションで利用可能です。Text AI を使用するためにライセンスの追加は必要ありません。

Text AI の詳細はこちらからご確認いだけます。

投稿 AI Cloud プラットフォーム向けの次世代の Text AI のご紹介 は DataRobot に最初に表示されました。

今こそ、単なる予測から脱却する

AI といえば、予測​をするというイメージがありますが、世の中に影響を与えるのは、予測よりも意思決定です。​

たとえば、食料品店の店主が、ある店舗で次の出荷までに 2,700 個のマンゴーが売れると予測したとします。これは説得力のある情報ですが、最終的に店主がその店舗用に注文するマンゴーの個数を決める必要があり、予測の情報では何をすべきかまでは正確にはわかりません。

予測で需要を過小評価していた場合、マンゴーの仕入数が 2,700 個ちょうどだと、在庫がなくなり、お客様をがっかりさせることになります。そこで需要計画担当者は、お客様に満足していただくために予測された量を超える「安全在庫」を抱えます。

しかし、どれだけの安全在庫を確保すべきなのか、最終的な決定を下さねばなりません。

AI を最も効果的に活用している組織は、このような意思決定に熟考を重ねています。そこで、予測モデルの出力に従うビジネスルールや「意思決定ルール」を作成して、ビジネスのベストプラクティスを追加し、組織全体の意思決定を標準化します。食料品店の例でいうと、「予測された売上よりも常に 10% 多く在庫を持つ」というような単純な意思決定ルールです。

DataRobot​ は、さまざまな企業がこのようなシンプルな意思決定ルールの作成から着手するのを目にしてきました。企業では、時間の経過とともに、インテリジェンスが蓄積されます。これにより、たとえば、2 つ目の予測モデルでは、将来の卸売原価の変化を予測し、価格が高騰する前に食料品店の店主が適切な仕入れを行うといった、よりスマートな意思決定ルールを作成できるようになると考えられます。​

意思決定ルールは、需要予測や在庫管理に限ったものではありません。​業界を問わず、​機械学習のさまざまなユースケース（活用方法）で使用されています。​

以下にその他のユースケースの例をご紹介します。また、各意思決定について、意思決定ルールに影響を与える追加の考慮事項を記載しています。

意思決定ルールの導入は簡単ではありません。

モデルを作成しても、意思決定に関する必要なインフラが整っていないため、本稼働環境にデプロイしない企業もあります。一方で、意思決定ルールを実装していても、実装のために Python や Java、SQL で独自にコーディングしている企業もあります。コーディングは人手を要し、複雑で、維持コストもかかります。これに加えて、非技術系の関係者から、意思決定の方法が透明性に欠けているという不満の声が上がっていることも重要な点です。

また、企業によっては専用のビジネスルールエンジンを使用していますが、このようなルールエンジンの多くは、機械学習との連携を想定していません。

多くの企業が Excel や Visual Basic を使って予測を意思決定に変換しています。しかし、意思決定を行う際に依然として手作業が多く、時間がかかることにたびたび不満を感じていることが多いようです。

最終的に、こうした企業は、意思決定に多くの人手と時間に加え、コーディングが必要であることに、頻繁に不満を感じています。

企業が求める意思決定とは、簡単かつ柔軟でありながら透明性の高いものであると DataRobot は考えます。​新リリース 7.2​ のディシジョンインテリジェンスフローは、このような目標に直接対応します。

DataRobot のディシジョンインテリジェンスフローのご紹介

ディシジョンインテリジェンスフロー*を導入すると、複雑なルールを迅速かつ視覚的に作成し、予測の評価や意思決定プロセスの自動化を大規模に行うことができます。

ディシジョンインテリジェンスフローには、次の 3 つの大きなメリットがあります。

1. 非常に複雑なルールを簡単に作成​​:​​ 意思決定ロジックは、簡単に作成、理解、更新できることが必要です。DataRobot の意思決定フローエディターは直感的に使用できる GUI であり、クリック操作でルールを簡単に作成し、ビジネス上の知識と AI モデルの両方を組み込んだ意思決定フローチャートでデータの流れを確認できます。​

2. 意思決定のスピードと規模を向上​​:​ 意思決定フローを作成した後は、ドラッグアンドドロップのインターフェイスを使用して大小のデータセットに適用したり、REST エンドポイントにデプロイしたりできます。これにより、新しい意思決定をリアルタイムまたはバッチ処理で行い、毎日何百万もの意思決定を行うことが可能になります。​

3. 透明性が高く信頼できる意思決定: ​どの意思決定にどの意思決定フローが使用されたかを正確に確認できます。意思決定に影響する​機械学習モデル​​は​ ​DataRobot MLOps​ 内で追跡されるため、入力データが時系列でどのように変化するかを確認できます。DataRobot のインターフェイスは、非技術系の関係者から​経験豊富なデータサイエンティスト​まで、すべての人に透明性を提供できるように特別に設計されています。

*ディシジョンインテリジェンスフローはプレビュー機能です。

詳細について

ディシジョンインテリジェンスフローは DataRobot の​ ​MLOps プラットフォームにリリース 7.2 で新たに追加されました。モデルの構築には​ ​DataRobot Automated Machine Learning（AutoML）​を活用することも、TensorFlow、Scikit-learn、XGBoost、PyTorch などのツールを使用して自分でコーディングすることも可能です。構築したモデルを ​MLOps プラットフォームにデプロイし、ディシジョンインテリジェンスフローを定義することで、予測をビジネスで重視する最終的な結果に結びつけることができます。

ディシジョンインテリジェンスフローの Web ページ​にて詳細をご確認ください。

メンバー募集

DataRobot では AI の民主化をさらに加速させ、金融、ヘルスケア、流通、製造業など様々な分野のお客様の課題解決貢献を志すメンバーを募集しています。AI サクセスマネージャ、データサイエンティスト、AI エンジニアからマーケティング、営業まで多くのポジションを募集していますので、興味を持たれた方はご連絡ください。

投稿 DataRobot の<br>ディシジョンインテリジェンスフローのご紹介 は DataRobot に最初に表示されました。