この投稿は、私が所属するKDDIテクノロジーで行っているアドベントカレンダーの第13日目の12月13日の記事となります。
今年の私のアドベントカレンダーでは「生成AIアプリの進化について考えてみる」として、次の投稿行ってきました。

「生成AIアプリの進化について考えてみる　その1「アプリの要件」【←1日目】
「生成AIアプリの進化について考えてみる　その2「生成AIアプリの実行環境とミライ」【←今回!】

本エントリーは「生成AIアプリ」をテーマに、アプリ提供形態の現在の姿と将来の進化について、予測する試みの第二回目です。また、この本記事は今年の6月に幕張メッセで開催されたInterop2024Tokyoにおいて、「進化するアプリイマ×ミライ～生成AIアプリへ続く道と新時代のアプリとは～」の登壇資料をベースに、最新動向を取り入れてアップデートした読み物となっています。
https://forest.f2ff.jp/introduction/9177?project_id=20240601
なお、本エントリーは嶋是一個人の見解と妄想に基づく記事としており、属する団体やその組織の総意にはなりえないことを、ご了承ください。

現在の生成AIアプリとは

現在の「生成AIアプリ」と呼ばれているものは、カスタマイズされたチャットボットのことを指します。例えば、構築して公開するサービスとしては、次のようなものがあります。

生成AIアプリの例

OpenAIのChatGPTが提供している「GPTs」
GoogleのGeminiが提供している「Gems」
LangGenius,Incが提供している「Dify」

いずれも、Web上でLLMのチャット動作をカスタマイズして、特定の目的に対した回答を返すようにできる対話ボットを作成するサービスです。たとえばGPTsやGemsなどを用いて、料理に関する情報を追加して対話できようにした「料理対話ボット」や、地域のごみ分別情報を追加して作成した「分別ごみボツト」などを構築することができます。
いずれもWeb上で構築し、それをWeb上で広く公開することができます。これら一つ一つが生成AIアプリとなります。
また、このようなカスタムチャットボットはローコード/ノーコードの如くプログラムなしでも構築することができます。チャットの中で扱うデータ群をWeb画面からファイルを指定するだけで追加することもできます。またチャットの応答指示もプログラムを書くことなく、LLMへのプロンプト(テキスト文での指示)でできてしまいますので、とてもハードルが低くなっています。

ChatGPTのGPTsの提供画面

なにより、作成したカスタマイズチャットを公開して、多くの人に使ってもらう事もできます。なぜならば、ブラウザ上で利用できますので、OSや環境関係なく、どこからでも利用可能です。また、ChatGPTのページでは、様々な人が開発したGPTsが一覧となって公開されており、多くの人がここから選ぶことができ、利用することができます。まさに、生成AIアプリのマーケットプレイスの機能が提供されています。
なお、GPTsは当初有償プランに入っていないと、アプリ作成も、アプリ利用も利用できませんでしたが、今年の2024年8月からは、アプリの利用については無料版可能となりました。しかし、無料版とはいえChatGPTの無料登録が必要であることと、アプリ作成は有償版でないと使えないことは注意が必要です。

アプリ要件

第一回目で紹介しました、アプリのエコシステムが成立する要件は次の3つがありました。

①ハードウェアリソースがあること
実行環境を提供するための、十分な速度で処理できる計算資源があること
②実行環境があること
端末ごとの差分を吸収し、同一アプリがどこでも動く環境を提供されること
③配信環境があること
アプリのマーケットプレイスのような流通が存在し、アプリの集約公開(アグリゲーション)とともに、有償ダウンロードなどのマネタイズできる環境が存在すること

特に②の実行環境については、デバイスやOSなどのプラットフォームの「縛り」を、進化とともに順次解放し続けてきました。例えばWindowsのアプリケーションはWindows上でしか動けない縛りがありましたが、Webアプリならば、AndroidでもiOSでもMacでも動かすことができて、OSの縛りが「越境」できています。このように、アプリからみて「1つのアプリケーションが動作できる範囲」が広くなることが、一つのあるべき姿とされています。
このように下回りの縛りを解放することを、「下回りの越境」としてを紹介しす。

デバイスの越境

デバイスや部品やメーカが異なっても、その上で同一のアプリケーションが同じような動作を果たせる状態のことを意味します。ここは歴史的な背景があります。
組込装置などのデバイス(エアコン等)は、現在採用されている部品(A社製の温度センサー等)だけを動作させればよいのですが、ひとたび部品を変更してしまうと、ソフトウェアを作り替える必要が出てしまいます。そこで、変更せずに済むように、各社の違いを吸収できるデバイスドライバーを作成できるようにHAL(ハードウェアアブストラクションレイヤー)を定義して、その機能をOSに持たせるようにしてきました。これでハードウェアの越境ができるようになりました。アプリケーションはハードウェアごとに作成することがなくなり、OS上のアプリケーションを開発すれば、どの部品でも同じような動作ができるようになります。このおかげで、アプリケーションを開発するときに、部品の縛りを越境できるようになりました。また利用者目線では、同じOSならば異なる機種、異なるメーカーのいずれのPCでも自由に選べるようになりました(40年前くらいの話ですが)。

OSの越境

次に、当たり前ですがアプリケーションはOSを越境できません。つまり、Windows上でMacのアプリが動作しないのと同じように、Android上ではiOSアプリは動作しません。OSで動作するアプリケーションは、自身のOSの仕様で作られたアプリケーションのみです。そのため、ゲームなどアプリケーションでサービスを展開する際には、各々のOSに対応したアプリケーションを開発する必要がありました。二つ折り携帯に代表されるようなフィーチャーフォン(ガラケー)は、このOSが移動体通信事業者(携帯電話会社)ごとにOSが決められており、キャリアが異なるとアプリを作り直す必要がありました(30年前くらいの話ですが)。そこにスマートフォンが登場し、フューチャーフォンが一掃されて、AndroidアプリとiOSアプリが普及しました。各キャリアごとのアプリはなくなり、スマートフォンでは電話会社を越境し、事実上AndroidとiOSの二つのアプリで開発されることとなりました。

マーケットプレイスの越境

そこに、スマートフォンの世界だと、アプリケーションを配信するマーケットプレイスがあり、そこに登録するアプリの種類や仕様をAppleやGoogleが制限を付けるようになります。また有償配信する際には、マーケットプレイス提供者(Google、Apple)に1～3割の手数料を払う必要があります。そこで、このOSを越境するために編み出された技が、HTML5のWebアプリでした。ブラウザが動作していれば、OSに関係なく越境してWebアプリが動作できるため、AppleとGoogleの縛りをスキップすることができます。
つまりアプリマーケットプレイスのビジネスモデルを壊すこのモデルは、AppleやGoogleにとっては、快くないものでしょう。現在はWebアプリをよりネイティブアプリ(Androidアプリ、iOSアプリ)に近く動作させる技術であるPWA(プログレッシブ・ウェブ・アプリ)についても、Appleの対応状況は一進一退を繰り返しており、業界的な本格的な普及には至っていません。
このような「下回りの越境」環境は、ビジネス環境とも密接に紐づきながら実行環境として進化してきています。これらの動向を一つずつアプリの歴史から振り返ってみましょう。

アプリの歴史

パーソナルコンピュータ　1970年～

いきなり昔話になってしまい恐縮ですが、パーソナルコンピュータ(PC)と、PC向けOS(Operating System)の普及は、密接な関係があります。
なぜならばアプリケーションの実行環境が、PC向けOSの上に構築されるからです。
マイクロソフト社のWindowsや、Apple社のMac、そしてオープンソースのLinux含めて、これらのOSの登場により実行環境より下位にある、部品などのデバイスの差異を越境することができるようになりました。アプリケーションを動かすという目的においては、OSが同一ならばPCの機種の違い(例えばMacintosh SE/30とMacintosh LCⅡ)を越境して、いずれのパソコンでも同一のアプリケーションを動作させることができるようになったからです。そして、WindowsならばPCのメーカーも越境(例えば、東芝とパナソニックのPC)できるようになりました。これにより飛躍的にPCの選択幅が広がり、市場が大きくなったことで普及が進みました。
図の中でパーソナルコンピュータが越境しているのは、デバイス、機種、メーカーの差異です。実行環境はWindowsやMacなどのOS上に構築され、その上でアプリが実行されます。ただし、アプリケーションはOSを越境することができないため、OSの部分は×印で示しています。
これらのアプリケーションの開発環境は、OSの提供元から入手可能であり、基本的に誰でもアプリを開発できます。ソフトウェア自体は、過去は店頭などでパッケージソフトとして販売・流通していました。

携帯電話　 1995年～

1995年頃の第二世代(2G)の携帯電話は、組み込み装置として開発されていました。そのため、アプリケーションが実行するための、誰でも利用できる公開された実行環境というものはありませんでした。携帯電話の中には組込向けリアルタイムOSである、iTron、QualcommのRexなどが用いられていましたが、いずれも開発環境は各メーカーごとに独自のものを用いていたため、汎用性はありませんでした。また当時のCPUはクロックが数MHzにも満たず、メモリも単位がキロバイトの時代でした。そのため、プログラムに冗長な構成を持たせる余裕がなく、実行環境自体を搭載することが困難でした。そのため、図にあるように越境は基本的にできません。
しかし、この当時、携帯電話の利用目的は通話だけでなく、多機能の電話帳やメモ帳、文字メッセージなどができるようになるなど、機能が増大しており、開発自体が困難になり始めていました。

フィーチャーフォン/ガラケー　2005年～

1999年と2000年に、EZweb/EZaccessとiモードが発表され、その文字のブラウザベースの端末が二つ折り端末となり、いわゆるフィーチャーフォン（または、日本独自に進化しすぎた仕様を皮肉ってガラケーと呼んだりします）という携帯電話が登場しました。この時期の携帯電話は、通話から、メールやブラウザなどを用いた通信や、アプリなどのダウンロードの仕組みが提供され始めたタイミングでもありました。
この時期のフィーチャーフォンには、キャリア提供の実行環境が用意されています。そのため、電話会社ごとに異なるアプリ形態があり、異なるアプリ配信の仕組みが、キャリア提供のマーケットプレイスとして提供されていました。
ただこの当時はまだCPUの速度が数100MHzの時代であり、実行環境と言っても十分な保護機能などまでは搭載することができません。または十分な保護機能を持った実行環境を搭載したならば、逆にCPUの処理が間に合わず、アプリ動作が実用に耐えられなくなってしまいます。

そこで図の通り、キャリアである通信事業者ごとに、二つの実行環境を持つデザインとなっていました。
一つは「ネイティブアプリ実行環境」であり、ハードウェアに比較的近いAPIでアプリケーションを開発するため、アプリは軽快に動作できます。主に、端末内部の電話帳や待ち受けなどの内部機能を開発するために用いられており、ダウンロードなどの配信環境には対応していない開発レイヤーです。例えばNTTドコモのフィーチャフォンはMOAPが、KDDIのフィーチャーフォンではKCP/KCP+が搭載されていました。
もう一つが「配信用アプリ実行環境」であり、ネイティブアプリ実行環境の上にJavaなどのVM(仮想機械)などを定義し、その上でアプリが安全に動作することができる環境です。ただし、ネイティブアプリ実行環境に比べると、処理量が多くなるため、アプリケーションの動作速度は遅くなってしまいます。この安全な環境上で、フィーチャーフォン時代のiアプリやEZアプリ(Java)などはアプリ配信を行っていました。
今考えれば双方の実行環境を一つの端末に搭載するのは力業と感じてしまいますが、当時は「全部入り携帯」が強く求められていた時代であったことから考えると、これが最適解だったのです。
さて、このフィーチャーフォンは可能がどんどん増えていきます。そして平行して、端末のCPUも進化し、どんどん高速なものが搭載されるようになります。

この図は横軸が時間軸で、縦軸がCPUで採用されているクロックです。具体的なチップ名は伏せています。ピンク色の右上に伸びる雲の中に、携帯電話やスマートフォンのCPUが含まれます。当初は数百MHzしかなかったCPUが2010年ごろに、1GHzを超えるまでに進化していることが分かります。同じように、PCでも持ち歩くために省電力が必要となるネットPCのCPUをプロットすると緑色の雲の中に含まれます。タブレット(昔はPDA)クラスをプロットすると黄色の雲の中に含まれます。
ここで、2010年ごろを見てみてください(赤い点線)。いずれの雲が重なっています。
つまり、ケータイとPCとタブレットが、CPUの性能として同等となり、いずれのデバイスごとにできることが同じになることが分かります。
そもそも論で、ケータイは組込装置の延長として遅いCPU上でもしっかり動くように、独自のリアルタイムOSを搭載し、独自の実行環境を搭載し、独自のWebページの表記方法を創り出していました。それが、CPUがPCと同じとなってしまうとどうなるでしょうか? 携帯電話独自の仕組みを、独自に作り出す必要がなくなり、PCと同じもの、またはPCと同じ開発手法やOSの仕組みを搭載すれば良いということとなります。
そうです。その時に出た携帯電話こそが、iPhoneやAndroid端末などのスマートフォンなのです。従来のガラケーが一掃されてしまったように見えたのは、単なる流行でなくて、デバイスの進化からすると必然であったと言えます。

スマートフォン　2010年～

CPUの進化もあり、PCとできることが同じレベルに達した時代の携帯電話として、スマートフォンが2010年ごろに普及し始めます。AppleのiOSと、GoogleのAndroidがOSとして用いられ、各々それらのOS上で動作するアプリケーションを、マーケットプレイスからダウンロードできるようになりました。
AndroidやiOSはキャリアに依存しないため、これらのOS上に設けられたアプリ実行環境は、キャリアの違いを越境でき、キャリア独自アプリを開発する必要がなくなります。一度作成したアプリケーションは、マーケットプレイスが公開されているいずれの国のいずれの端末でも動作可能となっています。

図中の左側が先ほどの図でもありましたフィーチャーフォンOSの実行環境と開発レイヤーであり、右側がスマートフォンOSの実行環境と開発レイヤーです。スマートフォン時代ではCPUが高速になり、フィーチャーフォン時代の配信用アプリ実行環境でアプリを動作させても、サクサクと動作できるようになりました。そのため、二つの実行環境を設けておく必要は無くなったため、スマートフォンでは、開発レイヤーは1本化されました。
フィーチャーフォンのネイティブアプリ開発レイヤーは、携帯電話を開発しているメーカーにしか公開されていませんでした。配信用アプリ開発レイヤーは広く公開されていましたが、APIを用いて操作できる範囲が制限されており、携帯電話の機能をフル活用したアプリを開発ができなかった事情があります(Bluetoothやセンサーなどの機能)。それがスマートフォンになり、開発レイヤーが1本化されることで、(既得権のように隠された)APIはなくなり、誰でもフルの機能を用いたアプリの開発ができるようになりました。しかも、PCと同じような開発環境で携帯電話のアプリが開発できるということもあり、スマートフォン向けのアプリが大量に流通することとなりました。
さて、このアプリケーションを公開して配信するためには、AndroidアプリならばGoogle Playへ、iOSならばAppStoreのマーケットプレイスに登録して審査を受ける必要があります。そこで、マーケットプレイスに登録せずに(いろんな意味で煩わしいので)アプリを公開したいと考える人たちがでてきました。
2010年以降このようなアプリ配信がされている間もスマートフォンのCPUは進化を続けます。

スマートフォンアプリの時には、メーカーやキャリアを越境するための実行環境のためにCPUパワーを費やしました。それではその次に進化したCPUパワーはどこで使えばよいでしょうか?

図の右上の青い線の開発レイヤーです。答えはWebプラットフォームです。Webアプリの時代の幕開けです。

Webアプリ/PWA　2015年～

ブラウザの上でアプリのように動作できるWebページのことを「Webアプリ」と呼びます。このWebアプリの実行環境であるブラウザは、HTML5の技術を用いて構築されており、標準の言語としてJavaScriptを、標準のスタイルシートとしてCSS3が用いられており、Webプラットフォームと呼ばれています。つまり、ブラウザをアプリ実行環境とすることで、ブラウザが動作する環境ならば、どこでもWebアプリの実行ができるようになります。その結果、AndroidやiOS、はたまたWindowsやMacなどのOSを越境して、アプリケーションを動作させることになります。一つのWebアプリを作成すれば、いずれの環境でも動作することができるので、OS個別にアプリケーションを開発する必要もなくなります。このような、クロスプラットフォーム開発を実現しています。
なお、Webアプリの課題としては、待ち受けやアプリケーションランチャーにアイコンを登録することができない点や、ブラウザがフロントに出ていないと動作できないので、PUSHを受けた時のバックグラウンドでの受信対応ができないなどの課題がありました。この課題を解決して、Webアプリをより「ネイティブアプリ」に近く動作させるための技術がPWA(Progressive Web Apps)です。これを用いると、バックグラウンドで動作できるService Workerが利用できることで、Pushが可能となり、かつ待ち受けへのアプリアイコン登録を可能にするなどの機能が提供されます。ただ、現状ブラウザやスマートフォンOSの対応状況にむらがあり(対応したと思ったら辞めてしまったり)、PWAの普及の阻害になっています。

ミニアプリ/ミニプログラム　2020年～

少し横道にそれますが、Webアプリの派生で、ミニアプリ/ミニプログラムというものがあります。ポータルのような位置づけとされる「スーパーアプリ」が存在し、そのアプリ上に小さいWebアプリとして登録され動作します。このようなアプリ群のことを「ミニアプリ」「ミニプログラム」と呼んでいます。中国系の決裁系のアプリケーションで広く利用されており、スーパーアプリ内アプリとして、機能追加を目的として用いられます。
例えば、チャット、EC、モバイルオーダー、課金、そして位置情報活用など、Webで策定されていない機能をスーパーアプリ側で作成し、それをミニアプリが利用して動作します。そのため、実行環境としては、Webプラットフォーム+スーパーアプリの拡張部分という位置づけです。
スーパーアプリは多くの人が利用するため、ミニアプリを利用してもらうための、強力な配信環境が構築できます。そういう意味では、アプリのアグリゲーションに適した環境です。ただし、特別な越境はしていないと考えられます。

クラウドアプリケーション　2015年～

クラウドアプリケーションというのは、クラウド上でソフトウェア動作を行い、サービスを提供するアプリケーションのことです。クラウド環境と言えば、AWS、Azure、GP(GCP)などがありますが、基本的に特定のクラウド環境に構築したシステムは、他のクラウド環境で稼働(動作)させることはできません。ところが、昨今のコンテナ実行環境の技術であるDockerやオーケストレーションのK8s(Kubernetes)、そしてIaCを活用することで、クラウド環境を越境できるようになっています。

これは私の私見でしかないのですが、クラウド上のシステム環境も「アプリ化」していると感じます。任意の異なるクラウド環境に、コンテナのイメージをデプロイして動作可能ということは、どこでも同じシステムを稼働できてしまうことです。これは、あたかも異なる端末にアプリをダウンロードして、いずれも同じ動作ができている様相と近いと感じるためです。とはいうものの、このクラウドアプリの越境は思想でしかなく、現実はそんなに簡単には越境できないのが現実ではあります。
それでは、どうして端末側からアプリ化が先行してきたのかという点について。クラウドのシステムやサーバーのシステムに比べて、管理対象数となる端末の台数の方が膨大なため、端末側から整備されるのは道理と感じています。しかし昨今は、システム側もデプロイ回数の増大しており、アプリ化の恩恵が必要になってきているのが現状ではないのでしょうか。

生成AIアプリ　イマ×ミライ

生成AIアプリのイマ　2024年

冒頭で紹介した「現在の生成AIアプリとは」でも書きましたが、現在はGPTsやGemsやDifyなどが生成アプリと呼ばれている仕組みです。LLMにカスタマイズを行い、独自ChatUIのサービスを公開するサービスです。
これらはWeb画面から利用できるようになっており、SaaSサービスとして提供されています。つまりクラウド上で動いているのですが、その実行環境自体は非公開であり、そのシステム自体を自身のクラウド環境に持って来たり、オンプレに対してデプロイすることはできません。あくまでもSaaSとして提供されていて、WebUIかWebAPIを経由して利用する形となります。

アプリ要件
-- ①ハードウェアリソースがあること
-- ②実行環境があること
-- ③配信環境があること

アプリ要件の3点のうち、②が無いこととなります。アプリの汎用的な実行環境はなく、この部分はまだ標準化されていません。そのため越境しているものはありません。アプリというには、少し物足りない状況です。
一方、①と③があるために、アプリと呼ばれています。
特にアプリケーションの要件の「③配信環境」を満たしています。GPTsとして開発したアプリは、ChatGPTの「GPTを探す」のメニューから一覧が表示されます。そこでは人気アプリ、最新アプリなどを表示することができるため、一つのマーケットプレイスとなっています。このようなアプリケーションの公開ページがあるため、様々に開発されたアプリケーションが集められて(アグリゲーション)表示され、多くの人に活用してもらうことができるようになっています。
なお、Difyはオープンソースなので自身の環境にデプロイしオンプレでも動作できますが、ここではSaaS利用を想定しています。
生成AIのイマ2024年時点をまとめると次のような対応状況となります。

生成AIアプリ　ミライ　2024年～

現在の生成AIアプリはSaaSの提供形態でしたので、システムが動作する汎用的な実行環境はありませんでした。しかし、着実にこの実行環境が整ってきます。

クラウド環境

まずはクラウド環境上での実行環境の整備が進むことが予測されています。
弊社では毎年3月に米国で行われているNVIDIAのGPUカンファレンスである「GTC」へ、毎年視察を行ってその技術情報を社内で共有しています。今年の2024年に行ったときに、まさにこのクラウド環境上で、生成AIのクラウドアプリケーションを、コンテナ技術を用いて、何処でも動かせるようにしたアプリ化の取り組みが発表されていました。

特にNIM（NVIDIA Inference Microservices）と言われる仕組みです。AIの推論(インファレンス)モデルが含まれた形で提供されるコンテナであり、そのまま本番環境へデプロイし、稼働できてしまいます。またこのNIMはLlamaなどのLLMが含まれていますが、それらの推論動作をカスタマイズするために、カスタマイズするためのマイクロサービスとしてNemoがあります。具体的には、RAGの仕組みを提供したり(Nemoリトリーバー)、ファインチューニングや、ガードレールを設置するための仕組みが提供されています。かつ、これらのマイクロサービスは、K8sの技術をもちいており、DGX Cloud上ならばどこでも動作できます。このDGX cloudはNVIDIAが提供のクラウドで以前から提供されており、ここにモデルを配置して推論動作させることができます。しかもCUDA準拠のAWSクラウドやDGX Stationなどのオンプレ環境でも、このマイクロサービスを動作させることができるというのが驚くべきことだと思います。

このNIMの構成は図の通りで、CUDA環境の上にK8sでオーケストレーションされており、LLM含めたモデルがパッケージされている様子が表現されています。

スマートフォン環境

【Andoird】

スマートフォンでLLMをそのまま動作させようとしても、とても推論速度が遅いことを第一回目の記事で紹介しました。そのため、AIに特化したチップを搭載して、推論動作を高速に行える環境が整いつつあります。
Androidのバージョン14から「AI Core」が搭載されています。これは端末上に搭載されている「NPU」と言われる推論な特化したチップを、Androidアプリから利用できるように、システムサービスとして提供されている仕組みです。このAI Coreがまさに、Androidアプリの生成AIの実行環境(推論環境)となります。この仕組みを用いる事で、GoogleのLLMであるGemini nanoをスマートフォンの端末上だけで動作させて(エッジ動作)、推論結果を得る事が出来るようになります。これにより、オフライン動作ができるので、低遅延で電力の節約ができ、個人の情報を送信しない為プライバシー情報が守られます。
現在の難点としては、このNPUが搭載されている端末が、まだ限定的であり、AI Coreの利用がまだ広がっていない点です。

【iOS】

Appleは「Apple Intelligence」を今年の6月のWWDCで発表しました。これはiOS/iPadOS/macOSなどにオンデバイス実行可能な推論環境を提供し、パーソナルインテリジェントシステムとして搭載したというものです。こちらも、AIアプリの実行環境となる環境です。

PC環境【Copilot+PC】

マイクロソフトはCopilot+PCという、AIを搭載したPCを発表しています。これもPC上で生成AIアプリが動作する実行環境となるものです。このPCの要件は次のようなものです。
・Microsoftが独自に承認したSoCでかつ40TOPS以上のNPUを搭載している
・メインメモリ16GB以上
・256GB以上のストレージ(SSDないしはUFS)システムサービスとして搭載
つまり、NPUでLLMなどがサクサク動くアプリの実行環境を提供する、PCの基準を定義し、生成AI対応PCの新しいフォームファクタを創り出したいというのが目的でしょう。

まとめ

以上の事より、生成AIアプリの未来は、クラウド、スマートフォン、PC上での実行環境が準備され、その実行環境が普及した段階で、これらデバイス上で動作する生成AIアプリケーション/アプリが出回り始めるものだと思います。
そこに至る前段階として、イマがあります。今は、SaaSで生成AIアプリとして活用したり、または生成AI機能はアプリからWebAPIでSaaS側に問い合わせて利用する形で、しばらくは生成AIアプリを開発することとなるでしょう。

現在の取り組み

株式会社KDDIテクノロジーでは、AndroidやiOSのアプリを中心に、生成AIやクラウドを用いた開発や、新しい技術を扱う仲間を、積極的に募集しています。ともに開発やPMの仕事をしてみませんか?

興味ある方は是非こちらの採用ページからご相談ください。お待ち申し上げています。
→　https://recruit.kddi-tech.com/