AI本体はAIソリューション全体からみると一部でしかない
ARISE analyticsは2017年にKDDIとアクセンチュアによって設立された、データアナリティクスに特化した合弁会社である。KDDIの保有する4000万を超える契約データとアクセンチュアが持つアナリティクススキルを生かして、KDDI事業におけるデータ活用の推進、法人のお客様へのデータやAIの活用支援、KDDIグループのDX推進支援などを行っている。
坂本氏は同社サービスデザインユニットでソリューションインテグレーションチームのリードを務めている。坂本氏の役割はAIエンジニアと相対して、ソリューションに落とし込むこと。「AIのプロではなく、AIをソリューションに組み込むプロ」と坂本氏は言う。
ChatGPTが2022年11月にリリースされて以来、今はAIソリューションというと猫も杓子も生成AIと言われるようになっている。確かに生成AIは世界中で使われており、リアルタイムで回答もしてくれ、アップデートもそれなりにあり、課金すれば追加でサービスが受けられ、目立ったバグもない。
それだけにAIソリューションを作ろうとなると、「MLOpsは作れるのか」「学習コストはどうなのか」「推論時間はどのくらいかかるのか」「正答率は本当によいのか」ということに、気を取られてしまうエンジニアも多い。
だが、AIソリューション全体からするとAI本体の話は、ほんの一部でしかない。つまりAI以外のチューニングがカギを握る。AI以外のチューニングとは「システムとして当たり前のチューニングにAIを巻き込むこと」と坂本氏は語る。そのためには「疎結合」「同期、非同期、イベント駆動」「再現性」をしっかり考えることが不可欠だと坂本氏は言う。
AIモデルは「検証」「開発」「運用」というステップを経て商用化に至る。検証時は1％でも高く精度向上を目指すことが重要になる。その理由について坂本氏は、「そもそも成果が出ないと次の開発に進めないため」と明かす。例えば正答率50％のAIだと、システムとしては使いにくい。つまりAIの精度を高めることが、AIの価値につながるからだ。
その一方で、開発のステップに入ると、AIは推論部分だけなので、それ以外の各種チューニングが欠かせない。例えばユーザーが入力するデータにバリデーションをかけたり、データ加工したりする必要がある。そのような加工が施されたデータはDBに集められ、そこでAIによる推論を行う。後はデータ整形をし、レスポンスを返す。こういういろいろな処理に加え、「エラーハンドリングについても考慮することが求められる」と坂本氏。「開発フェーズでは検証フェーズとは異なり、一気にチューニングするものが増える」（坂本氏）という。
技術のブレイクスルーに対応するため変更容易な疎結合で設計
どんなアーキテクチャを採用して作ったとしても、大事なことはもはや研究フェーズではなく、開発フェーズであること。そして人が入れ替わったとしても、長く運用できるようなシステムであること。そのためには「疎結合化して、エンジニアが普遍的に扱えるような作法に則ってチューニングする必要がある」と坂本氏は力強く語る。つまり変更が容易で、障害に強いシステムの実現を目指すというわけだ。
とはいえそう簡単なことではない。生成AIは特に変化が激しく急にモデルが使えなくなったり、爆発的なブレイクスルーが起こり互換性のないまったく新しい考え方が出てきたりすることもある。そのようなときに、前処理と後処理が推論（実処理）と密結合していると、「システム自体が作り直しになる可能性がある」と坂本氏。そこで実処理だけを入れ替えるようにすることで、「新しいブレイクスルーが起きたとしても、いち早くその新しい考え方をシステムに組み込めるようになる」と坂本氏は言う。そのためにも疎結合な仕組みにすることが欠かせないのだ。
では具体的にどうやって疎結合の仕組みにすればよいのか。生成AI周りではAPIサーバを簡単に作成できるSaaSが増えている。例えばAzure Machine Learningを使えば、簡単にRESTのAPIサーバを立てることができる。一方のクライアント側はWebアプリケーションならVuie.js、モバイルならFlutter、Amazonに強いエンジニアが多いのなら、Amazon ECSからでもAPIからでもAPIで問い合わせさせることもできる。このように、生成AIの部分だけ切り離した形にすれば、Azure AI Studioのように新たなサービスが出てきたとしても、容易に乗り換えることができるようになる。「生成AIも入れ替えを前提にした普段のシステムの中の1モジュールでしかありません」（坂本氏）
モデルの考え方が古くなればそれを捨てて、新しいものを取り込む。それができる環境が疎結合化である。
価値を優位にシステムとして当たり前のチューニングをする
次に考えるべきことは、要件である。システムは何らかの価値を提供するもの。つまり要件は価値と言い換えることができる。
ではシステムで実現したい価値とは何か。ユーザーに回答する速度なのか、確実性のある回答なのか、利用しやすいことなのか、これらいずれについても「目指したいUXが存在するはず。その価値を損なってはいけない」と坂本氏は言う。
だがその一方で、その価値を損なわないために、妥協しなければならない他のものもある。つまり何を妥協できて、何が妥協できないのかをしっかり判断する必要があるというわけだ。
その例として坂本氏が取り上げたのは速度。まず考えるべきことの一つが、同期か非同期か。同期処理は対話型生成AIや機械学習を用いた監視などのアラート、不正検知、コールセンターの自動化などで求められる。一方、購入履歴からのレコメンドや議事録作成、紙書類の電子化、需要予測などは非同期処理でも十分だが、「人は同期処理に越したことはないと思ってしまいがち」と坂本氏は指摘する。だが同期処理すればするほど、考えることは増える。例えば、RDBMSだと要求の速度を満たせないから、インメモリーDBにしたとする。「インメモリーDBにした瞬間に、RDBMSより考えなくてはいけないことが出てくる」（坂本氏）
言語もPythonにすればAIエンジニアが書いたコードがそのまま流用できるかもしれないが、Cで書くと書き直さないといけなくなる。また推論をユーザーの手元でさせるのであれば、エッジ推論を選択するのも一つの手だが、スマートフォンのスペックで足りるのかなど、考慮する必要がある。一方、サーバで推論させるのであればスペックには不安はなくなるものの、バースト的なトラフィックに対しては考慮が必要になる。「このように同期処理にすればするほど、実装コストや難易度は上がっていく」（坂本氏）
非同期のバッチ処理以外の選択肢として最近注目されているのが、半同期処理のイベント駆動である。AWSであれば図のような構成が考えられる。
一方はAWS LambdaからAmazon SQSという昔ながらのキューイングサービスにデータを送る。Amazon SQSはコンポーネント間で任意の量のメッセージを送信、保存、受信することができるというサービス。例えば1秒間に10人処理するようにしたとすると、1秒間に100人アクセスが来ても、処理できるのは10人のみなので、バーストしてエラーになることはない。もう一方はイベント駆動の仕組みとしてAmazon DynamoDBを用意。DynamoDBへの書き込み処理をトリガーにLambdaを起動する。「この仕組みの良さは、問い合わせに対して受け付けたというレスポンスを返し、実際の処理は後続で行うことができること。サーバ負荷を考慮したシステムにできます」（坂本氏）
このような半同期処理の仕組みは金融など、信頼性が必要かつトラフィック量が読めないところに使用されているという。
では具体的にどうやって使うのか。坂本氏は実際にARISE analyticsのプロジェクトでAWSのイベント駆動を組み合わせた使った例を紹介。大量に送られてくる写真の中から、特徴的な写真をAIで検出するための仕組みを構築するというもの。「1度に1万枚の写真が送られてくると同期処理は難しいので、非同期とイベント駆動を組み合わせた仕組みにした」と坂本氏は話す。
すべてをリアルタイムで即時結果を出せるのなら良いが、現実はそうではない。「UXと共に、このシステムにとって優先すべきことは何か。ユーザーへの価値を最大化するためにどの要件が捨てることができるのかを考える。それが我々エンジニアとしての価値」だと坂本氏は言う。
開発が終わると運用が始まる。開発中に運用まで気を回すことはなかなか難しいが、「そこにも目を向けないといけない」と坂本氏は言う。
AIソリューションにおいては、再現性がカギを握る。なぜならAIは生成のたびに答えが変わるからだ。問い合わせを考えると生成した結果に再現性がないのは問題である。「お宅のAIに暴言を吐かれた」というクレームがあっても、それを再現できなければ対応が難しい。しかもユーザーは想定外の使い方をすることもある。システムは運用フェーズに入ると想定外なことが起こるので再現性が大事なるのだ。再現性を担保するにはどうすればよいか。
「システムであればリクエストに使用されたパラメーターを取得し、ライブラリなどあらゆるバージョンは商用と合わせる。AIであれば、シード値を乱数などで使用している場合は可能な限り固定する。コミットIDであればどのコミットでデプロイされているかを管理すること。そしてこれらすべてを管理し、ロギングを実施することで再現性を担保できる」（坂本氏）
だが、それでも再現できないことも起こりうる。その場合は「ロールバックできるようにすること」と坂本氏はアドバイスする。ロールバックは、1つ前のバージョンに戻すという意味の再現性と考えれば良いという。
最後に坂本氏は「システムは柔軟に変更ができるように開発すること。本当の価値を見極め、捨てられるもの、捨てられないものを把握し、再現できるものを準備すること。これがAIソリューションを開発するうえでは重要だ」と語り、セッションを締めた。
