はじめに
株式会社ノベルワークスで大学生アルバイトとして働いているザワッチです！
今回は、Azure OpenAI Service Dev DayというAI系のテクノロジーカンファレンスに参加しました。
本イベントの参加目的は以下の通りです。
-
今後のAI開発における効果的な開発手法を学ぶ
-
最新AIトレンドのキャッチアップ
午前中のセッションは1つの場所で聞く形でしたが、午後から２つの場所で同時に行われたため、聞けなかったセッションもあります。
なので、個人的に印象に残ったセッションをピックアップし、その内容と学んだことについてまとめます。
Multi-model, multimodal, and multi-agent innovations in Azure AI (Microsoft Corporation Vice President Of Products, Azure AI Marco Casalainaさん)
一番最初のプレゼンターは、Azure AIのプロダクト最高責任者であるMarcoさんでした。
その内容は、Azure AIの今と次に何がくるのかというのをデモ形式で紹介していくものでした。
リアルタイム動画翻訳
最初に、Sharepointに保存されている？と思われるMarcoさんが英語で何か話している動画が流れました。
ぼーっとしていると、なんとその後、日本語で声の質を変えることなく、しかも口も日本語を話すのに合わせるようになめらかに動いている動画を見せられました。この時、会場から歓声が巻き起こり、一気に観客の心が掴まれたように感じました。
phi-3モデルのローカルブラウザ推論
その後、Azure AIが用意しているモデルの主要モデルをかいつまんで紹介され、特にその中でもphi-3モデルを特に推しているようでした。
phi-3はMicrosoft社が開発しているローカルLLMで、高品質なデータセットが学習しているがために、少ないパラメータ数でもパフォーマンスを発揮していて、とても注目されています。
最近では、ファミリーモデルとして画像入力にも対応しているphi-3-visionやコンテキストが128kに対応している&より小さいパラメータ数のphi-3-mini-128kなど進化が目覚ましいです。
phi-3-mini-128kモデルはiPhone15での動作も確認されているようで、ローカルブラウザでの推論デモを見たときに、これからは一家に一台というレベル感で、より誰でも簡単に扱えるようなUXに整えることでPC、スマホ上でLLMが使用されていく未来を感じました。
実際に上記のブラウザにアクセスして、ローカルで推論することもできました🤩
リアルタイム音声認識による商品追加
他にもたくさんデモを見せつけられて、情報量多すぎてあたふたしていたのですが、音声認識をリアルタイムで行い、アプリ上のUIが勝手に動作し、ほんの数秒で商品が追加されるというデモには圧倒されました。
噂のgpt-4oのリアルタイム音声認識処理が組み込まれているらしく、ますますAIエージェントの活躍の幅が広がりそうです。
これを見て、目の不自由な方にも需要がありそうだなと感じました。
マルチエージェント
「セマンティック・カーネル」というマルチエージェントフレームワークの紹介がありました。
Marcoさんによると、マルチエージェントフレームワークでは、セマンティック・カーネル・マルチエージェントが勝者になるとの見通しがあるそうです。
以下セマンティック・カーネルの概要です。
セマンティック・カーネルの概要
まず、カーネルと呼ばれるアプリケーションコンテナーを作成します。
以下カーネル内の主要機能です。
-
エージェント
カーネルの中にエージェントを作成して、エージェントAはこのモデル、エージェントBはあのモデルという風に自由に外部のAIモデルを使用するよう設定することができます。エージェント間で出力結果を共有することができます。 -
プラグイン
エージェントそれぞれにプラグイン、いわゆる関数を作成することでタスクを実行する手足をつけることが可能です。 -
プラン
ユーザからの要求があったときにどのプラグインを使用すべきかを自動で判断します。 -
ペルソナ
エージェントに専門性の高い人材であると自覚させることもできます。（実際はシステムメッセージのプロンプトチューニングですが）
カーネルは上記の機能をいい感じに動かす役割を果たしてて、エージェントを管理するマネージャみたいな立場？を担うのかなと思います。
本来のカーネルの意味的にOSの中枢機能としてコンピュータの資源管理をすると考えると、ここでのカーネルの文脈は
- CPU
エージェントの実行命令を出す - メモリ
エージェントの実行結果を記憶する - デバイス
データベースやファイルシステムへのアクセス許可を出す？
と考えました。
LLMによるDXのビジョンと今から何をやるべきか(株式会社LayerX 部門執行役員 AI・LLM事業部長 中村 龍矢さん)
一般企業にLLMを導入して、DXを行っていくために取り組んでいること・考えていることに絞ってお話しされていました。
AI-OCR製品の課題と取り組み
LayerXさんのLLMの主な活用製品として、AI-OCRによるバクラク事業を挙げられました。
AI-OCRをする上での課題として、請求書・領収書の帳票に記載された項目は多種多様ですべてに対応し、項目を抽出することが難しいということが挙げられます。
そこで、AI-OCRで読み取れる部分は自動で読み取り、それ以外の項目に関しては、それまでに蓄積している関連情報をもとに自動抽出することで、AI-OCRが不得意な部分をLLMで補っているという情報抽出設計には驚きました。
また、抽出された情報を人が見て判断する箇所を色塗りすることで、AIが間違った際に気づきやすくするような設計もよく考えられているなと思いました。
確かに、帳票が手書きであったり、汚れていたりとあるゆる状態で読み取られる可能性があり、それをAIが判断するならば全然間違ったり読み取ることができないことは容易に想像できます。
なので、人が普段行う業務を変えることなく、AI側がたまに間違えることもあるけれども、人に寄り添い、サポートする形（＝AI-UX）で製品を開発しているということが如実に伝わってきました。
現状のLLMの能力感とチューニング範囲
LLMにどのようなタスクを行わせるべきかというお話もありました。
現状のLLMは、マニュアルやOJTが与えられれば、人間と同じくらいの仕事を遂行するポテンシャルがあるとおっしゃっていました。
LLMは事前学習によって、膨大な一般知識がインプットされています。
つまりLLMには常識があるので、あとは時と場合に応じたやり方を与えることで、新入社員レベルのアウトプットを期待できるということです。
AIはちゃんと指示を与えれば、結構いいアウトプット出してくれます。何をしたいのか、それをするためにどんな手順が必要なのか言語化し、指示することがとても大事です（自身の体験に基づく）
LLMに足りない部分として、
- 器用さ・安定感の根本的な性能
言われたとおりにやる力が乏しく、処理のたびに生成内容が変化する点や人間には不可解なミスを行ってしまう点 - やり方を自分で見出す能力
インプットとアウトプットに加え、ゴールまでのプロセスを細かく教えないといけない - 人間とのインタラクション
適宜作業（タスク）の進捗状況を人が見てレビューしないと、ゴールまでたどり着く可能性はかなり低くなる
を挙げられていました。
この3つの要素には全く同感で、特にLLMにはゴールまでのプロセスをプロンプトという形で人が与えてあげないと、見当違いのアウトプットを出すケースはざらにあります。
しかしながら、AIはミスをするためどんなタスクもさせるべきではないという考えではなく、ミスが許されないタスクであっても人間の確認・レビューが挟まれる前提でシステムを設計すれば、リスクを抑えられるという考え方だそうです。
確かにこのような考え方がなければ、世の中にいつまでたってもLLMが普及しないですし、人もミスをするのになぜAIのミスは一切許されないのかという思いもあります。
最後に特に印象に残ったのが、どこまでLLMのチューニングを行うべきかという課題です。
チューニングを行えば行うほど、効果が上がるわけではなくいつか停滞するポイントが来るため、上り幅が大きいところまで行うべきだという考え方です。
チューニングも開発工程の一部であるので、チューニングをすればするほど開発費用がかさばり、最終的にはやっても意味ないところまで行ってしまうのは避けたいと感じました。
チューニングで得られる最大限の効果領域を感じ取るセンスは開発しながら、学んでいきたいと思っています。
GitHub Copilotを用いたアプリケーション開発の未来(Microsoft Corporation Developer Global Black Belt 柳原 伸弥さん)
GitHub製品の下流工程へのアプローチを話されていました。
ソフトウェア開発のサイクルに対するGitHub Copilotの適用範囲
コードの作成、テスト、デプロイ、フィードバックまでの開発プロセスにGitHub Copilotが組み込み可能であるという現状に驚きました。
コードを書き終えると、テストコードも作成されていれば、開発体験爆上がり間違いないです。
現在、アルファ版ですが、プルリクエストでマージ対象のコードのレビューをCopilotが行う機能はレビュアーの負担減にもつながり、需要のある機能であると感じました。
GitHub Workplaceでコード生成版RAG
Copilotの生成時に開発プロセスの各工程における必要なナレッジを与えることで、新人ソフトウェアエンジニアレベルのタスクは担えるのではないかと感じました。
柳原さんが始まりからおっしゃっていた「開発者の幸福感を最大化すること」は、すなわち、「開発がワクワクしながら製品を作ること」であり、その手助けに「GitHub Copilot」は必要不可欠だと考えました。
まとめ
AIの進化、とくに生成AIの進化により、それを使用するユーザーだけではなく、製品・サービスを提供する者にも多大な影響を与えているということを実感しました。
提供する側目線では、ある製品・サービスをどのようにつくるのかという部分に関しては、AIに任せればいいのではないかと考えました。
というのも、結局作り方の部分がどれだけ進歩していっても、何を作りたいのかという部分(初期構想)は結局人間が考え、トリガーが引かれるのも人間によるものだからです。
だからこそ、世の中に存在する課題をうまく言語して、その解決策をAIに指示を出して作らせるのが上手い人が今後の提供する側に求められる能力なのではないかと考えました。
「人間の人間による人間のためのAI」から「人間のAIによる人間のためのAI」にシフトチェンジしていく未来を実感したイベントになりました。