今回は「Copilot for Microsoft 365 (以下「Copilot for M365」という)」の中でも特徴的な機能である Office アプリによる文書作成に関してお届けしたいと思います。

以前の回 Copilot for Microsoft 365 について (2) でお伝えした通り、この仕組みに関してはマイクロソフトの研究者たちによって既に論文として発表されております。
その機能に関して少し詳しくご説明差し上げたいと思います。

何故、Office 文書を作成する仕組みが必要か？

皆さんもご存じの通り、生成 AI はプログラムコードを生成する能力を有しており、GitHub 社の GitHub Copilot を始めとしてコードの生成を補助する仕組みとして使われております。
そのコード生成の中には Office で使用される VBA や JavaScript なども含まれており、実際にそれらのコード生成を行うことが可能です。

では、何故以前お話したような「Office Domain Specific Language (ODSL) 」が生み出されたのでしょうか？
では、以下のコードを見てください。

このコードは、生成 AI によって Office JavaScript を生成させた例です。
一見正しそうで何ら問題ないように見えます。
ただ、このコードをよく見るといくつかの課題が見えてきます。

まず、非同期や例外処理など非常にローレベルで冗長なコードが書かれています。
次に「このスライドをフォーマルに見せる」という命令を表示用のテキストに設定するという誤った理解がされています。
また、コンソールにエラーを出力するといった動きをしようとしています (例えば、突然ファイルをクローズするといった情報を失う可能性があるメソッドを生成する可能性もあるでしょう)。

通常、生成 AI から得られるレスポンスはテキスト情報であっても、その内容を人間が確認して修正などを行う可能性が高いものです。
ましてや、プログラムコードは開発者がデバッグなどを通して、コード中の問題点を解消して動作するプログラムへと近付けていきます。
そうしたことから、いきなり Office に文書を生成させるなどの命令を実行するためのコードを生成させるのは、非常にハードルが高い行為となります。

そのため、マイクロソフトはこうした目的に沿った安全な形で利用することができる仕組みを新たに開発したのです。
それが ODSL を始めとする次項の仕組みとなります。

Office 文書作成へのチャレンジ

前項でご説明した通り、通常の生成 AI の機能だけで Office 文書を作成しようとすると様々な問題に直面します。
そこで、以下のような仕組みを用意することで、それらを回避しようと考えた訳です。

まず、一番左の「入力」ブロックから見ていきましょう。
ここでは、自然言語 (NL) によるプロンプトが入力されています。
併せて、ドキュメントのコンテキスト (文脈・背景) が渡されています。

次に「分析」のブロックです。
ここでは以下のような形で処理が行われています。

前述の入力された情報を元にして、Office 文書内のどのエンティティに対して処理を行うかの判断をしています。
この例では PowerPoint のエンティティを例にして、対象が「スライド」、もしくは「図形」、はたまた「テキスト」なのかと言った分類を行っています。
次に処理をするにあたって、コンテキスト情報が必要か否かを分類しています。
これによってエンティティの現在の情報を取ってくる必要があるか否かなどを判断しています。

次に「構築と合成」のブロックです。

分類器で処理された情報を元に ODSL という中間言語が生成されます。
ここでは、ODSL サンプルバンクというところに格納された情報を参照しながら ODSL 構文に則ったプログラム合成が行われます。
その際、コンテキストが必要な場合にはその情報も併せて処理が行われます。
そのことによって、上記右に記載されているようなプログラムコードが生成されます。

最後に「解釈と実行」のブロックです。

ここでは、ODSL 構文で記載されたプログラムコードを一度 AST (Abstract Syntax Tree：抽象構文木) と呼ばれる木構造に変換することで、構造のチェックを行いエラーが発生しづらい状態を作り出しています。
また、内部でプログラムの実行検証をした際にアンドゥしやすい内容に制限しています。
こうすることで、例えプロンプト通りの成果が得られなかったとしてもエラーでアプリケーションが落ちるなどのデータを失う可能性を下げることができるようになっています。

それらの処理を経て、安全なことが確認された ODSL のコードは Office 用のネイティブ API のコードに変換 (トランスパイルレーション) され、実行されることとなります。

Word や PowerPoint 等の Microsoft 365 Apps 内で Copilot を使った際にエラーとはならなくても処理が途中で終わってしまう、何も動かなかったなどの状況になった際には、上記のいずれかの内部処理でエラーになっていることが想定されます。
こうした事象も ODSL やサンプルバンクの改修、中間処理の向上によって改善していくことが期待できます。
是非、継続的に Copilot for M365 を活用頂き、フィードバックの仕組みを使って問題点をご報告頂ければと思います。

まとめ

今回は Office 文書生成の裏側を少し詳しくご説明させて頂きました。
内部構造かつ技術的に細かい情報が含まれていたために分かりづらい部分があったかと思います。
この内容が皆さんの Copilot for M365 への理解と愛着につながることを願っております。