最終更新日：
ノーコードAIプラットフォームは世界各地でさまざまなものがリリースされ、ブームとなる機運が高まっています。こうしたなか、同氏はノーコードAIプラットフォームを試用したうえで、その効用と限界を考察しました。
同プラットフォームを使うことによる最大の効用は、AIの非専門家に初歩的な開発能力を提供して、彼らを簡単なAIモデルを開発する「市民開発者」にすることです。AIの市民開発者が増えると、AIの専門家たるデータサイエンティストは難易度の高い仕事に集中できるようになります。また、同プラットフォームで簡単なAIモデルを開発することで企業内の一部の業務を自動化することもできます。
もっとも、同プラットフォームはあらゆる種類のAIモデル開発に向いているわけではありません。要求機能が比較的単純なモデルを開発できるに過ぎず、複雑かつ大規模なモデルの開発には不向きなこともわかりました。
同氏によれば、ノーコードAIプラットフォームの限界はさらに以下のように要約することができます。
- ハイパーパラメータの調整といった柔軟な開発ができない。
- 市民開発者が開発に参加することにより、アルゴリズムにバイアスが混入する可能性が高まる。
- 開発されたAIモデルの管理を徹底しないと、データサイエンティストの仕事が増えてしまう。
- AIモデルの理論的背景を知るには、やはりデータサイエンティストが必要。
- 体系化されたデータ収集の実行にも、データサイエンティストが必要。
- AIモデルをPoCから本番環境にスケールする際にも、データサイエンティストが必要。
さまざまな限界があるものも、近い将来、管理職にはノーコードAIプラットフォームを使って簡単なモデルを開発する能力が必須とされるのではないか、と同氏は予想しています。
ノーコードAIプラットフォームに関してはいまだ業界標準的なものがないものも、いずれMicrosoftのWordやExcelのようにビジネスマンであれば誰でも使えるものが誕生するかも知れません。
なお、以下の記事本文はAlexandre Gonfalonieri氏に直接コンタクトをとり、翻訳許可を頂いたうえで翻訳したものです。
目次
ノーコードAIソリューションを導入して得た教訓
画像出典：UnsplashのStudio Republicより
AIプロジェクトの大半がいまだに製品化に至っていないなか、ノーコードAIプラットフォームへの関心は高まり続けている。実際、「使いやすい」機械学習プラットフォームを提案するスタートアップや大手テック系企業が増えている。
データサイエンティストがいなくても機械学習に基づいたソリューションを構築して使用できるというアイデアは、、複雑な機械学習プロジェクトに多くのリソースを割いている現状では、従業員の能力を向上させようとしている大企業と中小企業の両方にとって非常に興味深いものだ。
この記事では、ノーコードAIソリューションのひとつを実装し、この業界に関連するいくつかのスタートアップを分析した後、私が学んだことを共有する。AIコンサルタントとしての私の目標は、ノーコードAIプラットフォームというソリューションによって、より多くのプロジェクトが概念実証（PoC）からスケーラブルで関連性の高い効率的なAIソリューションへと移行する可能性を高めることができるかどうかを判断することだ。
ノーコードAIプラットフォームを使用する理由
運用面から見ると、1年の間にいくつかの部署で複数のAIプロジェクトを開発しているものだ。そのほとんどは、データ、投資、およびリーダーシップの不足、あるいは単に現状の機械学習の成熟度が低いためにPoCにとどまっている。
取り組まれているプロジェクトに関して言えば、複雑さのレベルは決して同じではない。実際、いくつかのプロジェクトは「最近の」アルゴリズムに関連しているが、他のプロジェクトは線形回帰、k-means、ナイーブベイズなどのよく知られたアルゴリズム（※訳註1）を単純に使用している。私たちがノーコードAIプラットフォームを使う目的は、これらのソリューションが協力者の一部を市民開発者に変え、より多くのデータサイエンティストを「複雑な」ユースケースに割り当てるのに役立つかどうかを判断することであった。
プロダクトマネージャーのような人材が社内の市民開発者になるように推進しても、データサイエンティストの需要がなくなるわけではないことを理解しておくことが重要だ。市民開発者を増やすというアイデアは、データサイエンティストが関わる雑務の負担を軽減して、彼らがより大規模で複雑なプロジェクトに集中できるようにしよう、という意図がある。
もちろん、従来の機械学習ワークフローに関する仕事を「より少なくして」、特定のユースケースの開発を加速させることも、ノーコードAIプラットフォームの魅力だろう。管理者がアイデアを持ってきて、それを構築し、ノーコードAIプラットフォームを使ってプロジェクトを実行できるような未来を想像することは可能ではなかろうか。
「k-means」は教師なし学習のひとつで、データをk個のグループに分ける時に用いられる。各データから算出される重心と、その重心から各データまでの距離を繰り返し測定することで、似たような特徴をもつデータをクラスタに分ける。
「ナイーブベイズ」はベイズの定理を応用した分類方法。スパムフィルタ等に使われている。
従来の機械学習とノーコード機械学習のプロセス的対比
今日、ほとんどのAIプロジェクトは、多かれ少なかれ同じステップをたどっている。実際、ユースケースを特定することから始め、データを収集し、モデルを構築し、訓練し、改善するといったことが行われる。ノーコードAIプラットフォームが本当に役立つかどうかを判断するためには、まず「従来の」機械学習とノーコードのそれの違いを理解する必要がある。
画像出典：Teachable Machine
伝統的な機械学習開発では、以下のようなステップを実行する。
- タスクの定義
- データ収集
- モデルの探査と洗練
- テストと評価
- 実装と統合
- モデルの監視と維持
ノーコードAIプラットフォームにおけるステップは以下の通り
- タスクの定義
- データ収集
- データのドラッグ＆ドロップ
- モデルの訓練と訓練における（エポック、バッチサイズ、学習率等の）設定
- 学習結果の評価
- モデルのエクスポート
以上の図を見るとわかるように、「伝統的な」AIプロジェクトのいくつかのステップは、ノーコードAIプロジェクトではドラッグ・アンド・ドロップ・ツールを使って自動化され、簡単にできるようになっている。このような観点から、私はノーコードAIプラットフォームの使用を、プロトタイプやデモ開発をスピードアップする時間効率の良い方法と考えている。
ユースケース
私が思うにノーコードAIプラットフォームは特定のプロジェクトに適している。例えば、サービスの解約、顧客のライフタイムバリュー、ダイナミックプライシング（※訳註3）などに関する指標を予測したい場合や、複数の契約にまたがるデータを分析して、より良い交渉の手助けを得たい場合に適している。また、これらのツールは、いくつかの社内プロセスの自動化にも役立つと考えられる。
「ダイナミックプライシング」とは、商品やサービスの価格を需要と供給の状況に合わせて変動させる価格戦略を指す。
新しいスキル
ノーコードAIプラットフォームの台頭により、新たなスキルに対する期待も生まれてくると考えてよいだろう。近い将来、プロダクトマネージャーは少なくとも1つのノーコードAIツールに精通し、データセット管理についての知識を持っていなければならない、となっても何ら不思議ではない。これらのツールに関連したオンライントレーニングがますます増えていくことも期待される。
特化した市場
ノーコードAIはまだ成長している市場である。この市場におけるプレイヤーのほとんどは、（自然言語処理、コンピュータビジョン等の）技術の類型、あるいは（CRM管理等の）特定のユースケースを何よりも重視しているようだ。
近い将来、ほぼすべての用途をカバーできる完全なツールが登場し、複数のツールに投資したり、特別な知識を活用したりする必要がなくなることが期待される。
この業界は、スタートアップと大手テック系企業の両方が独自のツールを開発することで構成されている。明らかな理由から、スタートアップ企業はいくつかのオプションを提供するのではなく、特定のユースケースに焦点を当てているようだ。
ロックイン戦略とビジネスモデル
ノーコードAIプラットフォームの業界で最も興味深い側面は、大手テック系企業がロックイン戦略を用いながら、新規顧客を獲得してユーザーへのリーチを増やそうとしているところだ。
私はよく、ノーコードAIツールを開発するスタートアップは特化していなければ、長期的には生き残れないのではないか、と疑問に思うことがある。実際、大手テック系企業の利点は、そのベンダーのプラットフォームやロードマップを維持するために、顧客に無理のないアプローチを提供できることだ。
理想的には、（GoogleやMicrosoftのような）大手テック系企業は、顧客企業が自社のソフトウェア開発ツールとデータ管理に関連するサービスを含んだより広いエコシステムを利用できるようにしたいと考えている。
こうした大手テック系企業が提供するソリューションのいくつかは、無料またはサブスクリプションモデルに基づいている。とは言うものも、こうしたソリューションを使い続けるには、大手テック系企業が顧客企業に対してユーザーのトレーニングやクラウド環境をバックエンドに接続する技術支援を実行するために、コンサルタントや開発者の介入が必要になるかもしれない。
ノーコードAIソリューションを導入してみた感想
以上の考察をふまえて数ヶ月前から、ノーコードAIプラットフォームの有効性をテストすることにした。私の考えでは、ノーコードAIの効率性と有用性は神話ではない。
最大のメリットは、データサイエンティストがノーコードAIプラットフォームを使って迅速なPoCを作成したおかげで、マーケティング部門が持っていた不完全なアイデアを評価することをよって役立ったことだ。実際、データサイエンティストはマーケティング部門責任者に対して、まずはアイデアをノーコードによるPoCで試してみて、そのアイデアに対するニーズが安定してきたら再検討するようにアドバイスすることもできる。
しかし、ノーコードAIプラットフォームの仕様に関しては、いくつかの譲歩をしなければならない。実際に開発業務なしで迅速にモデルを作りたいのであれば、そのモデルに関する期待値を下げることができなければならない。
ノーコードソリューションを通じた機械学習に基づくプロジェクトの成功は、機能的なニーズに大きく依存する。ニーズが非常に具体的な場合には、実装のスピードと機能性に関連した期待値のあいだの適切なバランスを見つける必要がある。
- 「実装要求が低く、実装スピードも遅くてよい」図表右下のユースケースでは、「現在のノーコードAIソリューションが完全に適している」。理想的には、市民開発者個人によるプロジェクトとなるのが望ましい。
- 「実装要求が低いが、早い実装スピードが要求される」図表左下のユースケースでも、「現在のノーコードAIソリューションが完全に適している」。
- 「実装要求が高く、早い実装スピードが要求される」図表左上のユースケースでは、「ほとんどのノーコードAIソリューションが適していない」。
- 「実装要求が高いが、実装スピードも遅くてよい」図表右上のユースケースでは、「伝統的な機械学習開発のステップがより相応しい」。
実装機能に対する要求と期待される開発スピードの組み合わせにもとづいた上図のような4つのソリューションは、使われるツールの設計に由来する限界線を持っている。実際、モデル開発ツールは開発するモデルにもとづいて設計されている。例えば実装機能に対する要求が低いソリューションに使われるツールは、理解しやすく使いやすい単純なモデルを提案するようなエディターが採用されている。しかし、万時を簡単にしている代償として、そうしたツールで作られたモデルは柔軟性を欠いている。というのも、簡単なフレームワークの範囲内でしかモデルを開発できないからだ。
反対に、実装機能に対する要求が高いプラットフォームでは、コーディングによるアプリケーション開発に匹敵する柔軟性を可能にするより精巧なモデルを選択できる。その反面、プラットフォームを使いこなすまでの学習曲線と要求スキルははるかに高くなる。
ノーコードAIプラットフォームを採用する際の要因。左には「モデルの複雑性」とあり、右には「柔軟性」とある。ノーコードAIプラットフォームは、複雑なAIモデル、あるいは柔軟性が求められるAIモデルの開発には向いていない
必要とされる使いやすさと柔軟性のあいだのバランスに応じてツールを選ぶことが、強く推奨される。いくつかのケースでは、任意のプラットフォーム上で一度でもアプリケーションを開発すると、そのアプリケーションが実行されている限り、そのプラットフォームにリンクされていることを覚えておくことが重要だ。PoCのコンテキストでは、こうしたことは問題ではない。しかし、アプリケーションを継続利用することが期待されるコンテキストでは、状況は異なることがある。
実際、ノーコードAIプラットフォームを使用して、プロジェクトに必要なスケーラビリティを実現できるかどうかを確認しなければならない。「複雑な」ユースケースに対してノーコードAIプラットフォームを使ってスケーラブルなソリューションを実現することは不可能、と私は考えている。
さらに言えば、（データの所有権をはじめとする）契約関係については、コストや可逆性の観点から慎重に検討する必要がある。
もう一つの重要な要素は保守性だ。モデルを構築する目的が単にアイデアに関連した事項をテストすることなのか、それとも長期的なアプリケーションを構築することなのかを最初の段階から判断することを私は強く推奨する。最初のケースでは、可能であれば、ノーコードAIソリューションを使用して使い捨てのPoCを素早く作成する方が良いだろう。そうでなければ、伝統的な機械学習開発のアプローチを使い、安定的かつ保守可能なバージョンを構築することを推奨する。
もしノーコードAIサプライヤーが（ユースケースによっては可能な）スケーラビリティを保証してくれるのであれば、長期的な保守性を確保するために、スケール時のライセンス費用をトータルで評価することも推奨される。
最悪なのは「手っ取り早くて汚い」アプローチを使ってPoCを作成し、同じPoCをスケーリングして本番環境に臨もうとことだ。
制限
私の考えでは、（すべてではないにしても）ほとんどのノーコードAIプラットフォームの現状における限界は、以下の通りである。
パーソナライゼーションの程度
ほとんどの人が思っていることだろうが、機械学習モデルを構築することの難しさはコーディングではなく、自由に使えるデータ、特徴量に関わるエンジニアリング、アーキテクチャ、テストに由来するのだ。いくつかのノーコードソリューションでは、様々なパラメータを微調整したり、変更したりする機能がない。
もう一つの欠点はデータに関連している。実際、データのバイアスについてはよく知られていることだろう。ユースケースにもよるのだが、ノーコードAIプラットフォームで構築したモデルは、潜在的に誰もが構築に関わり、エクスポートすることができる。そのため、バイアスを含んだアルゴリズムを生成する危険性が高まるのだ（※訳註5）。
明らかに、機械学習のエンジニアもバイアスを含んだソリューションを作成する可能性がある…。
熟練したデータサイエンティストであれば、アルゴリズムにバイアスが混入しないように公平なデータを収集しようと努めるが、非専門家である市民開発者がデータ収集に関わるとバイアスが生じる危険性が高まる。
アルゴリズムのバイアスとAIによる差別の詳細については、AINOW記事『「AIによる差別」の現状とは？事例、原因、世界各地の取り組みを紹介』を参照。
正確な内部プロセスの必要性
前述したように、ノーコードAIツールはポジティブなものになりえるが、そうなるためにも特定のガバナンスが必要なのだ。実際、ガバナンスが徹底されている管理された方法でノーコードAIツールを統合しなければ、より多くのシャドーITを導入し、より多くの問題を引き起こすことになる。
ノーコードAIツールの管理体制が整備されていないと、データサイエンティストは自身の仕事に費やすのと同じかそれ以上の時間を、同僚のために費やす羽目になるかも知れない。
依存性
ノーコードAIツールの開発に関する私のもう一つの懸念は、依存関係に関連している。確かに、ソリューションのなかにはデータサイエンティストは必要ないものがあるかも知れない。しかし、顧客が機械学習の理解を深めたり、ソリューションを拡張性のあるものにしたりするために、将来的にもコンサルタントが必要になるだろう。このように、技術的に熟達した専門家への依存がなくなるわけではないのだ。
データの必要性
すべての機械学習プロジェクトに必要なものは同じだ：それはデータである。機械学習プロジェクトの成功は、データセットを収集、管理、維持する能力に大きく依存している。しかし、一連のデータ関連業務は通常データサイエンティストの仕事であり、「市民開発者」がこれらのタスクをうまくこなせるかどうかはわからないのだ。
スケーラビリティ
私が最後に懸念しているのは，スケーラビリティに関することだ。実際、多くの成功したPoCが本番環境で失敗しているのは、PoC段階で作成した機械学習モデルをスケーラブルなかたちで提供できるようにシステムを再構築できなかったからだ。医療や銀行のように機密性の高いデータを大量に使用する業界では、スケーラビリティの実現はさらに困難になる。
他にも実装、安全性、レガシーシステムとの統合などに関する潜在的な問題を挙げることもできる。とは言うものも、私は依然としてノーコードAIプラットフォームの有用性を信じている。ノーコードAIを使ったプロジェクトが成功するかどうかは、プロジェクトのユースケースとデータ管理に関する成熟度に強く依存する。
私たちはノーコードAIプラットフォームのトレンドの始まりにいるに過ぎず、今後ますます多くの企業（特に中小企業）がこれらのツールを活用したいと思うようになる、と私は確信しているのだ。
原文
『Should You Use A No-Code AI Platform? Limits and Opportunities』
著者
Alexandre Gonfalonieri
翻訳
吉本幸記（フリーライター、JDLA Deep Learning for GENERAL 2019 #1取得）
編集
おざけん
