この記事は弥生 Advent Calendar 2024 (シリーズ1) の5日目の記事です。
こんにちは。弥生でエンジニアをしています、大内 (@houchiey) です。好きな勘定科目は・・・まずは簿記3級に早く合格します。
さて、昨日12/04（水）はkurokiさんが「Microsoft Developer Dayに参加して、何を始めるか」というエントリーを投稿しておりますが、私も社内の生成AI活用を検討するワーキンググループの一員として活動をしており、先日行われたMicrosoft Developer Dayに参加し刺激を受けてきた一人です。
こちらのバトンを受け取り、本日12/05（木）と明日12/06（金）にかけて実際にどんなセッションが行われたのかご紹介していこうと思います。
今回は前半のセッションのうち、私が参加したセッションについてお届けしてまいります。
Openning
Roan Kang氏によるOpenningトークで幕を開けました。
日本におけるAI活用の現状・未来について、Microsoftが担う社会的な意義についてのプレゼンテーションでした。
かつて、コンピューターを民主化したMicrosoftが、今はAIの民主化に取り組んでいる。
というフレーズは実に印象的でした。
Keynote: Era of Generative AI for Developer ~ 生成AI時代のアプリ開発者の生きる道
基調講演は、現在の生成AIトレンドについての解説とMicrosoft関連製品の最新アップデートの紹介でした。
エージェントオーケストレーション
昨今の生成AIのトレンドとして、多様な言語モデルが選択可能になっており、GPT-4などのLLMのみならずSLMと言われる、対応する分野を絞ることでより少ないリソースで構築できる言語モデルも登場してきています。 その中でこれからのAI開発として「エージェントオーケストレーション」という考え方の必要性について説いていました。 これは、適材適所にAI（エージェント）を配置して複数のAIが協力しながらユーザーの課題を解決する、という考え方です。
ソフトウェアエンジニアとしては、AIも目的ごとにクラス化する時代に突入したんだな、と感じました。 「LLMを使ってどう課題を解決するか」ではなく、 「この課題にはこのモデル、この課題にはこのモデル、そんでもってそれらをこのモデルで制御する」というような、 言わばAI設計がこれからのAIアプリケーション開発では求められてくるのではないでしょうか。
エージェント構築の3つのポイント
そんなエージェントを構築する際のポイントとして、以下の3つのレイヤーを紹介していました。
- インターフェース（マルチモーダルモデル）
- メモリ・コンテキスト（RAG（GraphRAG）、Fine-Tune）
- リーゾニング・プランニング（Reasoning推論、ReAct）
この中から、「マルチモーダルモデル」と「GraphRAG」について、ここでは紹介しようと思います。
マルチモーダルモデル
恥ずかしながら「マルチモーダル」という言葉を知らず、Keynote中に急いでGeminiに聞いて調べました・・・(汗) テキスト・画像・音声など異なる種類のデータを処理・統合して、より高度なタスクを実行する技術のことでした。
実例として、ugoというロボットの紹介がありました。
人型の警備ロボットや点検ロボットを開発されているみたいです。 カメラから取得した画像データやマイクで取得した音声データを始め、ロボットに実装された様々なセンサーデータをインターフェースとして、業務ルールや過去の対応事例をチューニングしたLLMによってロボットの行動を決定しているそうです。
このように、さまざまなインターフェースを取り入れることでより高度なエージェントを構築できるよ、ということだと理解しました。
GraphRAG
また、新たなRAGとして「GraphRAG」の紹介がありました。
その前に、RAGについて簡単にご説明します。
自社のドメイン知識を組み合わせたり、解決したい課題の背景情報を追加情報として与えることで、LLMからより精度の高い回答や生成物を得られることが期待できます。
例えばChatGPTのチャットで北海道のおすすめ観光スポットを質問するときに「あなたは一流のツアーコンダクターです」といった役割を与えたり、「旅行に行くのは1月上旬です」といった文脈情報を与えることで、より目的に沿った回答を得ることができます。これはプロンプトエンジニアリングと呼ばれる手法です。
一方で、自社のデータベースなどの外部ソースを組み合わせてより正確でコンテキストに沿った回答を生成する技術をRAG（Retrieval-Augmented Generation）と言います。
すなわち、良質なデータソースをRAGとして用意することでLLMの回答精度を向上することができる、と言えます。
そんな中、今回のKeynoteで紹介されたのがGraphRAGです。
これはグラフデータをRAGとして与えることを紹介していたのですが、従来のFull-Textデータやベクトルデータとは異なり、グラフデータはデータやドキュメント間の類似度・関連度・相互性といったものを表しているので、より文脈を認識した回答が期待できるというものでした。
漫画ゴールデンカムイの人物相関を表したグラフデータをRAGとして食わせることで、より物語の文脈を理解した回答が得られるよ、というデモをしていました。 （残念ながら私は内容を知らなかったので、実際どうなのかは分かりませんでした・・・）
MLOpsからLLMOpsへ
最後に、MLOpsからLLMOpsへのパラダイムシフトについて説明がありました。
これまでは、MLエンジニアとデータサイエンティストが中心となってデータからモデルを強化していく、いわゆるMLOpsがAI活用としては一般的でしたが、時代はLLMOpsへと移り変わっているというお話でした。 いかに精度の高いモデルをスクラッチで開発するか？というフェーズではなく、既に学習済みのLLMをいかに活用していくか？というフェーズに入ってきており、APIやプラグインで接続可能となったLLMをプロンプトやRAGといった技術を駆使しながらアプリケーションにどう組み込んでいくかということが重要な価値になってきています。 つまり、これからの主体はMLエンジニアとアプリケーションエンジニアなんだということです。
Microsoft関連製品のアップデート情報
ベンダー系カンファレンスのKeynoteですからね。
Azure AI StudioやらGitHub Copilotやらいろいろありましたが、ここではUFOについてご紹介します。
UI-Focused multi-agent framework for Windows OS
（無理あるやろーと思った人は私だけじゃなかったはず・・・）
ネーミングは置いておいて、自然言語で与えた指示に従ってAIが実際に画面を操作しながらいろいろやってくれるそうです。 デモをしてくれましたが、本当に人が操作する代わりに、カーソルが勝手に動いてウインドウを切り替えながら処理をしていってくれていました。
陳腐な物言いですが、未来感が半端なかったです。
まじめな話をすると、我々のワーキンググループで検討しているテーマとして開発効率化・生産性向上に結構ダイレクトに刺さるツールだなと思いました。実開発周辺の単純作業を、これまではスクリプトといったツールを作成していたのが、自然言語の指示一発で済むようになるかもしれませんから。
ただ、この手の話は、夢を見せつつ使ってみたらなんだかイマイチということも多いので、期待しすぎずに検証してみたいと思います。
Azure OpenAI を活用した実開発 基本のキ
こちらのセッションでは、生成AIを利用したアプリケーションの開発や運用における各フェーズでの考慮事項を紹介しつつ、それらに対する解として本イベント（Microsoft Developer Day）の各セッションが紹介されるといったものでした。言わば、イベントの入り口的なセッションとなっていました。
肝心なところは、「この後の〇〇というセッションで詳しくお話されるので是非聞いてください」という形で踏み込んだ解説がそれほど多くはなかったのですが、生成AIとのゲートウェイとしてAzure API Managementに関して踏み込んだ説明がありましたのでご紹介します。
AIアプリケーションにおけるAPI Management活用のメリット
テーマとしては、AIアプリケーションとそのクライアントとなるアプリケーションとの通信や、マルチエージェントなAIアプリケーションの運用を想定した場合はAIエージェント間の通信について、どのように最適化していこうか？という課題に対するアプローチのお話です。
従来のアプリケーションであれば、マイクロサービス化が進んだこともあり、サービス間通信を共通化したりサービスメッシュを効率よく運用するためのソリューションは数多く出てきています。セッションではIstioやEnvoyを挙げていましたが、私の知ってる範囲だとAWSのAppMeshなどが近しい存在かなと思います。
AIアプリケーションにおける通信においては、効率よく運用するための一つの策としてAPIゲートウェイ層による抽象化レイヤーの構築をしてはどうでしょう？という提案で、その具体策としてAPI Managementを紹介していました。
デモとして、API Managementが持つキャッシュ機能を活用してセマンティックキャッシュを構築した例を紹介していました。 ベクトル化した質問文とLLMの回答をそれぞれキャッシュしておき、類似する質問が投げられた場合はキャッシュから回答するというキャッシュポリシーを設定します。 こうすることで、パフォーマンス面はもちろんのこと、LLMに対して必要最低限のトークンしか投げないのでコスト面でも有利になります。
セッション中では、「ん？API Management関係なくない？」と思っていましたが、よく調べたらきちんとAPI Managementのパワーを活用したアーキテクチャでした。
この他にも、生成AIとのゲートウェイについて、登壇者の方（Microsoftの社員さんです）が様々なアーキテクチャパターンを研究されていて、GitHubでラボが公開されています。
金融事業会社におけるGitHub Copilot導入の道のり - JCBのPoC〜活用
クレジットカード事業などで有名なJCBにおけるGitHub Copilot導入の事例紹介セッションです。 私が所属しているワーキンググループでもGitHub Copilotの導入を推進しているので先人の知恵をお聞きできる貴重な場でした。
リスク評価の3本柱について（主に知財リスク）
一番気づきがあったのは、GitHub Copilotのリスク評価として「正確性」「機密性」「知財」の3つの観点から行われていたところです。 特に「知財」に関しては自分にとって新しい切り口でした。 具体的には、GitHub Copilotで生成されたコードをプロダクション利用することで以下のようなリスクがないよね？を評価することです。
- 自社の知的財産権を主張できないリスク
- 他者の知的財産権を侵すリスク（第三者請求を行われるリスク）
これについては、一応はGitHub公式の規約に明言はされているようですが、 それに加えてJCBでは「リスクの低いところで使用する」方針としたとのことでした。
画面UIなどはリスクが高いので、サーバーサイドロジックやテストコードの自動生成から活用をしている
ガイドライン
リスク評価について全体的な方針を定めたとはいえ、最終的にツールを使用する開発者の判断に委ねる部分も出てきてしまいます。 また、一般論ではカバーしきれないため、開発するアプリケーション特性も踏まえて各チームにてガイドライン（利用ルール）を策定しているとのことです。
利用状況の計測・可視化（ガバナンス、利用促進の観点）
GitHub Copilotの利用状況はGitHubからAPIが提供されています。 これを使うことで利用状況を可視化し、ルールから逸脱した使用（ガバナンス）やあまり活用していないユーザーを特定（利用促進）に活用ができそうだと思いました。
OSSもあるよ、とのことだったので、イベント終了後に少し調べてみました。
JCBはGCPのサービスを活用して実現しているようです。
OSSでも使えそうなツールがありそうでした。
.NET・Python・Javaで学ぶ！SDKを使ったAI開発のはじめの一歩
フリ役AI、ボケ役AI、ツッコミ役AIによるトリオ漫才アプリをライブコーディングしながら、 Azure OpenAIのSDKを様々な言語で実装する方法について学べるセッションでした。
基本的な使い方
私は.NET（C#）を使うことが最も多いので、.NET（C#）での実装の流れを。
- クライアントインスタンスを作る
- SystemMessage（振る舞いや前提など、共通コンテキスト）を作る
- UserMessage（指示）を作る
- クライアントに渡して実行
- 回答を取得する
ソースコードにするとこんな感じです。 実際に登壇された方のソースコードを参考にしています。
ChatClient chatClient = _openAIClient.GetChatClient(Environment.GetEnvironmentVariable("MODEL_DEPLOYMENT_NAME"));
ChatCompletion completion = await chatClient.CompleteChatAsync(
[
new SystemChatMessage(Prompts.SystemMessage),
new UserChatMessage(promptText)
]);
var response = new { text = completion.Content[0].Text };
登壇された方がソースコード全量をGitHubで公開してくれています。 ライブコーディングで使用したコードをご覧になりたい方はこちらからどうぞ。
Java（フリ）
GitHub - mahya8585/huriGenerator
C# （ボケ）
GitHub - tenjoufire/mangzai-cs-isolated
Python（ツッコミ）
GitHub - KoheiYamamoto/ms-dev-day-py: python codes for Microsoft Dev Day 2024 session (THE MANZAI)
感想など
実装するまでの準備がいろいろ必要だとは思いますが、実装自体は非常にシンプルでよくあるSDKの使い方のイメージでした。 各言語の設計思想に合わせてSDKが作られているので、違和感なく実装が進められそうだという感覚を得ました。
また、SDKのセッションなのにGitHub Copilotの凄さを改めて感じることができました。 と言うのも、ライブコーディングと言いつつほとんどGitHub CopilotがサジェストしたコードをほぼそのままAcceptしてたからです笑
まとめ
今回は前半戦ということで半分、しかも私が参加したセッションのみなので、全体の約4分の1程度のご紹介しかできませんでしたが、いかがだったでしょうか？ 前半戦のセッションを通して私が最も印象に残ったこととしては、
1つの生成AIを使うというフェーズが終わり、さまざまな生成AIを組み合わせることで価値を生み出すことが大切
ということでした。
特に、Microsoft社員の方が登壇されたセッションでは、一貫してマルチエージェントを意識した内容だったと感じますし、 以前はAIと言えばChatGPT！という感じでしたが、今では「GitHub Copilot」はエンジニアでは知らない人の方が少なくなってきていますし、 「Gemini」や「Microsoft Copilot」なんかは一般的にも浸透してきているサービスだと思います。 これからAIを活用していく上では、さまざまなAIアプリケーションを組み合わせる視点を持たなければならないなと強く感じました。
さて、今回は前半戦をお届けしてまいりましたが、明日12/06（金）は後半戦となります。
ぜひ明日のAdvent Calendar も楽しんで読んでいただけたらと思います。
社員募集
弥生では一緒に働く仲間を募集しています！ リモートワーク＆フレックスという柔軟性のある働き方ができる企業です。オフィスワークとリモートワークを組み合わせる「ハイブリッドワーク」も、社員の意思で選択可能です。
私も、茨城県からフルリモートで働いています！
弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。
