AIのローコード（ノーコード）開発と開発自動化への期待と懸念

今後、AIのビジネス活用があらゆる業界での検討事項になることは間違いありません。AIが、インターネットのようなビジネスの前提となる時代がやってきます。そうなるとAIを導入するという話になるのですが、自社開発するか、開発を外部委託することになります。

ローコード（ノーコード）開発への期待

AIのニーズが高まるにつれて、自社開発をサポートするローコード（ノーコード）ツールが登場し始めています。AIを開発するためにはプログラミングが必須ですが、ローコード（ノーコード）ツールは「プログラミングなしでのAI開発」を可能とするものです。

このローコード（ノーコード）の流れはAIに限ったものではなく、さまざまなプログラミング不要のローコード開発ツールが提供され始めています。たとえば、これまで人間が担っていたパソコンの単純定型作業を自動化するRPA（Robotic Process Automation）がそうです。RPAはプログラミングなしにパソコンの作業を自動化できます。RPAが多くの組織で導入されている主な理由は、「IT部門ではなく現場の人間が作業自動化ロボットを開発できる」からです。

「プログラミングが決してできるようにならない」人は多数いる

筆者はビジネスパーソンを対象に、Excelを使った統計学の研修なども行っているのですが、その際に驚いたことがあります。それは、Excelを使いこなせている人が非常に少ないことです。そもそもExcel関数の入力方法でつまづく人がかなりいます。しかもそれらの人は、「普段仕事でExcelを使っている」と答えていたのです。圧倒的に普及しており、普段Excelを使っている人ですら、Excelの扱いに苦労している現状があります。

そう考えると、現場の人たちにプログラミングの能力を期待するのは酷ではないだろうかと筆者は考えています。だからこそ、プログラミング能力を求めないローコード（ノーコード開発）の必要性は十分に理解できます。マウスでポチポチとクリックしながら操作できるGUI（グラフィカルユーザーインターフェース）の有用性はまったく否定しませんし、筆者も極めて有用だと感じています。

ローコード（ノーコード）開発の懸念点

ただ、そんなローコード開発ツールですが、やはり懸念点があります。それらツールへの期待を込めて、今後ぜひ突破してほしい壁を以下に記載します。

AI開発で難しいことは、プログラミングなのか？

ローコード（ノーコード）開発のニーズが高まっているとしても、結果的に実用的なAIを開発できなければ意味がありません。「プログラミング不要でAIを開発できます！」というツールがあったとしても、AIの理論をしっかりと理解していなければ良いAIを作成することはできません。

AI開発において、プログラミングとAIの理論理解のどちらがより重要かつ困難かということに注目しましょう。あなたはどちらだと思いますか？

結論を述べると、圧倒的に後者のAIの理論理解です。AI開発の現場で「プログラミング能力」の問題で悩んでいる人は少ないです。AI開発のプログラミング言語としてPythonがよく用いられますが、少ないコードでAI開発を行えるscikit-lernなどのライブラリがあり、AI開発におけるプログラミング面を難しいと考える開発者は少ないです。

AI開発者が頭を使うのはAI理論の現場応用に関してです。AIにより画像や動画を生成するGANという技術が注目されています。GANは「実在しない人間の画像」を作成でき、雑誌やアパレル業界のモデルという仕事のあり方を大きく変化させる可能性があります。また、GANはニセ映像を作りだすことも可能で、それはディープフェイク動画と呼ばれて問題視されています。ただ、技術自体は非常に有用であり、亡くなった人が動いている新たな動画を作り出すことなどができます。

開発の際に障害となるのはプログラミングではなくGANという技術への理解です。そしてその理論をどうやって製品やサービスに落とし込むかというところに注力するのです。

プログラミングすらできない開発者がまともなAIを開発できるのか？

AI開発において、「プログラミングスキル」というのは一つの前提条件に過ぎません。そのため、「プログラミングすらできない人に、まともなAIの開発ができるのか？」という疑問を筆者は抱いてしまいます。

プログラミングは不要でも、「プログラミング的発想」が必要

さらに、「プログラミングが不要」であったとしても、結果的に「プログラミング的発想」を求められることが多いです。

実はRPAでも同様の問題が生じています。RPAは「プログラミング不要でパソコン作業を自動化できる」ということでIT部門ではなく現場の職員が開発することを想定しています。

ところが、現場の人間が精度の高いロボットを作れているかというと、なかなか難しい状況です。プログラミング不要であっても、まともなロボットを作るにはプログラミング的思考が要求されるからです。つまり、元々プログラミングできる人はRPAを使いこなせますが、プログラミングが出来ない人がRPAを使いこなすことは難しいということが起きています。したがって、現場での開発を想定してRPAを導入したにもかかわらず、IT部門がロボットの開発を行っている組織も多いです。ただ、IT部門が開発を担当するなら、「RPAではなくプログラミングしたほうがいい」となってしまいます。

ローコード（ノーコード）AI開発ツールへの期待

ここまで、「AI開発の困難はプログラミングではない」という点、そして「プログラミングは不要でもプログラミング的発想が要求される」ということを述べてきました。したがって、ローコードAI開発ツールに期待したいことは、まさに「AIの理論面の困難さを覆い隠すこと」、「プログラミング的発想が求められないこと」の2つです。

AI開発には「Garbage in garbage out」という鉄則があります。これは、「ゴミ（のようなデータ）からはゴミ（のような結果）しか出てこない」という意味です。ローコード開発ツールには、ゴミのように汚い（整っていない）データを入力しても、Gold（金）が出てくるようなものをぜひ期待したいと考えています。

たとえば、とにかくデータと目的を入力すれば、自動的にデータを適切な形に修正し、アルゴリズムが自動適用され、素晴らしいアウトプットが出るような製品です。開発者が行うことは、「データと目的を入力する」という作業までです。確かにこのような製品であればローコード（ノーコード）開発ツールとして非常に優秀だと思います。

それでもまだ実用的なAIを開発できない

それでは、プログラミングとAIの理論に習熟していれば、素晴らしいAIを開発できるかというと、実際はそうではありません。最終的に有効なAIを開発できるかは、職人芸とも呼ばれるセンスが必要となります。そこがAI開発の面白い側面でもあります。

前回の記事で、ワイン好きの経済学者者オーリー・アッシェンフェルター氏によるワインの質を予測する式を提示しました。それは以下のようなものでした。

ワインの質 = 12.145＋0.00117×冬の降雨量＋0.0614×育成期平均気温－0.00386×収穫期降雨量

そして、予測のために用いる降雨量や育成気平均気温、収穫期降雨量などを特徴量と呼びます。特徴量とは、予測のために用いる重要な要素と考えてください。つまり、ワインの質は、冬の降雨量、育成期平均気温、収穫期降雨量という3つの特徴量で精度高く予測できるとなります。

誰が特徴量を選ぶのか？

確かに、データをAIにインプットすると、アウトプットとして予測式が出てきます。それでは、「冬の降雨量、収穫期降雨量という特徴量が重要だ」と誰が判断しているのでしょうか？それは、データベースの設計者やAI開発者です。そして、データベース設計者やAI開発者は誰から助言を得ているかというと、ワインの専門家です。「ワインの質を予測するには降雨量が重要だ」という知見があらかじめあるからこそ、「降雨量のデータをインプットしてみよう」という発想に至るわけです。

AI開発に必要な職人芸

上記のように、プログラミングやAI理論に習熟しているだけではAIを開発することはできません。その分野に関連する知識が不可欠なのです。AI開発に必要なデータが何かを見極めることは、AIの理論だけでは不十分です。ビジネス知識を持った人とAI開発者が連携して初めて有効なAIが誕生するのです。AIにどんなデータをインプットするかは、試行錯誤と職人芸的な発想が求められることになります。
この点において、「自分は文系だからAIとは縁遠い」と考えている人がAI開発に貢献できることは多くあります。。AI開発は、開発者と現場の人間の両方の知識が不可欠なのです。

たとえば、農作業を自動化するために、きゅうりの質を自動判定するAIを開発した農家の方が以前話題となりました。その方がなぜそのようなAIを開発できたかというと、きゅうりの質を判断できる目を持っていたからです。

まとめ

ここまで、ローコード（ノーコード）開発と開発自動化に関して述べてきました。プログラミング不要の素晴らしいローコード（ノーコード）ツールが誕生したとしても、AI理論の理解がなければ良いAIを開発することはできません。

そして、仮にプログラミングとAI理論の両方に習熟していたとしても、その業界におけるビジネス知識が必要となります。ビジネス知識がなければ、どのようなデータを集めればよいかわからないからです。そして、この「どんなデータを集めるか」に関しては自動化することが難しく、今後しばらくは人間の判断が必要となるはずです。

今後、これらの壁を突破できる製品やサービスが出るかについて、筆者も注視していきます。