VSCodeローカルからOrcaへ。AI Office開発環境をサーバ化した話（その2）

前回の記事では、WindowsのVSCodeローカルで動かしていたAI Office開発環境を、Orcaを使ってLinuxサーバ側へ移した話を書きました。

VSCodeローカルからOrcaへ。AI Office開発環境をサーバ化した話（その1）

Claude CodeやCodex、Officeファイルを生成するためのPython処理など、多くの部分はLinux側へ移せました。

ただ、最後までどうしてもLinuxだけでは完結できないものが残りました。

Microsoft Officeそのものです。

PowerPointやWord、Excelのファイルを作るだけなら、Linux上のPythonでもかなりのことができます。

ですが、私がやりたかったのは、

「ファイルが生成できたから完成」

ではありませんでした。

例えばPowerPointなら、

• 文字が途中で切れていないか

• 図形や表が重なっていないか

• 不自然な改行がないか

• 実際にPowerPointで開いたときにレイアウトが崩れていないか

といったところまで確認したい。

Wordでも、目次やフィールドを更新したうえで、実際にWordからPDFを出力し、ページ単位で見た目を確認したい。

今回の環境では、こうしたMicrosoft Office自身を使った実レンダリングや更新処理は、Windows側のQA工程として分離しています。

そこで考えたのが、

「LinuxにOfficeを持ってくるのではなく、Officeが必要なときだけWindowsを呼べばいい」

という構成でした。

Windowsを「Office実行装置」として使う

Windows側に任せる役割は、できるだけ限定しました。

Windowsで行うのは、

• PowerPointを実際に開く

• Wordの目次やフィールドを更新する

• Microsoft Officeでレンダリングする

• PNGやPDFを生成する

• 結果をLinux側へ返す

といった、決められた処理です。

AIによる判断やワークフロー全体の制御は、Linux側に残します。

つまりWindowsは、

「Microsoft Officeを実行するための外部実行エンジン」

という位置付けです。

PowerPointではLinux側からランチャーを起動し、Windows上のOffice COMでスライドを画像化します。Wordも同様に、Windows側でTOC/Fields更新やPDF・ページ画像生成を行う構成です。

構成をざっくり表すと、こんなイメージです。

ここでポイントなのは、Windows側にAIを常駐させていないことです。

実は最初は、Windows側のCodexへ処理を渡してました。

ただ、そこから構成を見直していくうちに、

「この処理、Windows側のCodexで必要なのか？」

という疑問が出てきました。

次は、そのあたりの話を書きます。

～～その３へ～～