【ITニュース解説】Wiring genoffice CLI into Cursor MCP: Real Office Document Generation from AI Context

システムエンジニアを目指す皆さんにとって、日々の業務で効率化は非常に重要なテーマです。特に、最新の人工知能（AI）、具体的には大規模言語モデル（LLM）が注目される中で、その能力を最大限に引き出し、実用的な成果物に変える方法は常に探求されている。

現在、多くの大規模言語モデルは、文章の生成やデータの構造化、例えばMarkdown形式のドキュメントやJSON形式のデータ出力には非常に優れている。しかし、ビジネスの現場で頻繁に利用されるWord（.docx）の報告書やExcel（.xlsx）のデータシート、PowerPoint（.pptx）のプレゼンテーション資料といった、いわゆるOffice形式のドキュメントを直接生成することは、これまでのところ苦手な領域であった。AIが生成したMarkdownやJSONをOffice形式に変換するには、手動でPythonスクリプトを記述したり、生成された内容をGoogleドキュメントなどにコピー＆ペーストしたりする手間がかかり、これは開発の効率性を大きく損なう「摩擦点」となっていた。

このような課題を解決するために登場したのが、「genoffice」というプロジェクトである。genofficeは、Office形式のファイルをローカル環境で直接作成・編集できる統一的なコマンドラインインターフェース（CLI）を提供する。これにより、外部のドキュメント生成サービスにAPIキーを設定したり、クラウドサービスに依存したりすることなく、手元のコンピューターでOfficeドキュメントの生成や編集ができるようになる。genofficeは、Word、Excel、PowerPointといったOfficeファイルだけでなく、PDF、Markdown、HTMLのエディター機能も内蔵しており、さらにAIエージェントと連携するための機能も備えている。

genofficeは大きく分けて二つの方法で実行できる。一つは「インタラクティブGUI（グラフィカルユーザーインターフェース）」モードである。これは、私たちが普段使うアプリケーションのように、画面上で操作できるエディターのセットを起動するモードだ。もう一つは「ヘッドレスCLI」モードで、これは画面を表示せずに、コマンド（命令）を文字で入力することでファイル生成や編集を行うモードである。例えば、「genoffice create-doc --template report.docx --output quarterly.docx」というコマンドを実行するだけで、指定したテンプレートに基づいて四半期報告書のWordファイルを生成するといった、自動化されたワークフローに組み込むことができる。特にこのヘッドレスCLIモードは、システム開発における自動化において非常に重要な役割を果たす。

genofficeの真価が発揮されるのは、AIを活用した開発ツール「Cursor」との連携である。Cursorは「MCP（Model Context Protocol）」という仕組みを通じて、外部のツールと連携する能力を持っている。genofficeをこのMCPに「スキル」として登録することで、CursorのAIエージェントが、私たちが自然言語（普段の言葉）で指示するだけで、genofficeのコマンドを直接呼び出し、ドキュメントの作成やスプレッドシートの編集、スライドの生成といったタスクを実行できるようになる。具体的には、.cursor/mcp_settings.json という設定ファイルにgenofficeの情報を記述することで、CursorのAIエージェントが、まるでgenofficeの機能を知っているかのように振る舞い、私たちの指示を解釈してOfficeドキュメントを生成する能力を獲得するのだ。

genofficeのAIエージェントは、デフォルトではOpenAIが提供するAIモデルを利用する設定になっている。しかし、実際の開発や運用では、コストを最適化したり、特定のAIモデルが利用できない場合に別のモデルに切り替えたりする「フェイルオーバー」の仕組みが必要になる。この課題に対しては、「リレーゲートウェイ」という仕組みが有効である。これは、AIモデルへのリクエストを直接送るのではなく、一度中継サーバーを経由させることで、裏側で利用するAIモデルを柔軟に切り替えられるようにするものである。例えば、OPENAI_BASE_URLという環境変数をリレーゲートウェイのアドレスに設定することで、genofficeの設定を変更することなく、GPT-4からClaude、Geminiといった様々なAIモデルをシームレスに利用できるようになる。実際に、このリレーゲートウェイを経由させることで、ドキュメントのフォーマットといった定型的なタスクにおいて、より安価なAIモデルが自動選択され、平均トークンコスト（AIの利用料金）を約22%削減できたという事例も報告されている。

具体的な応用例として、毎週の「スプリントレポート」を自動生成するパイプラインが挙げられる。まず、プロジェクト管理ツールであるJiraから、特定のスプリント（開発期間）のデータをJSON形式でエクスポートする。次に、CursorのAIエージェントに対して、「@genoffice sprint.jsonからWord文書を作成し、完了したストーリー、ブロック、ベロシティチャート（プレースホルダー画像）のセクションを含めて、sprint_42_report.docxとして出力して」のような指示を与える。すると、CursorのエージェントがJSONデータを解析し、genofficeのドキュメント作成コマンドを呼び出し、わずか8秒で整形されたWordドキュメントが生成される。この時点では、グラフの部分は手動で挿入する必要があるが、テーブルやテキストのフォーマットは実用レベルで完成する。さらに、生成されたドキュメントに対して、GUIを開くことなく、「genoffice edit-doc sprint_42_report.docx --append "## Action Items" --insert-table "blockers.csv" --style "Heading 2"」のようなCLIコマンドを使って、後からアクションアイテムのセクションを追加したり、CSVファイルからテーブルを挿入したりといった微調整を行うことも可能である。

この便利なgenofficeを実運用で使う際には、いくつかの「運用上の境界と失敗モード」を理解しておく必要がある。まず「パフォーマンス」についてだが、ドキュメントの作成速度はコンテンツのサイズに比例する。例えば、50ページで20個のテーブルを含むWordドキュメントの生成には、M2 MacBook Airで約15秒かかる。これは、CI/CDパイプライン（ソフトウェア開発の自動化プロセス）のような用途では許容できる時間だが、リアルタイムでプレビューを確認するような用途には向いていない。次に「フォーマットの忠実性」だが、genofficeはOffice Open XML形式（.docx, .xlsx, .pptx）を読み書きできるが、複雑なPowerPointのアニメーションやExcelのマクロ（VBA）などは保持されない。また、画像以外の埋め込みメディアも削除されることに注意が必要だ。

「並行処理」に関して、MCPサーバーはリクエストごとにgenofficeのプロセスを一つ起動する。もし5つのドキュメント生成を同時に実行すると、CPU使用率が340%に達し、コンピューターのリソースを枯渇させてしまう可能性がある。このような大量のバッチ処理を行う際には、xargs -P 2 のように並行処理の数を制限する工夫が必要である。最後に「エラー伝播」だが、AIエージェントが不正なOffice XMLを生成した場合（これはまれに発生するが、入力が不適切なJSONだった場合に起こりえる）、genofficeはエラー終了コード（1）を返し、部分的に生成されたドキュメントも失われてしまう。そのため、CLIコマンドを呼び出す前に、入力データのスキーマ（構造）が正しいかどうかを必ず検証することが重要である。

Cursorエージェントの利用にあたっては、「コンテキストの構成」も重要である。デフォルトのMCPスキルは、プロンプトごとに8KBというコンテキストサイズ（AIに与えられる情報の量）の制限がある。そのため、500行のCSVデータのような大規模なデータからドキュメントを生成しようとすると、入力が途中で切り捨てられてしまう可能性がある。このような場合は、.cursor/mcp_settings.json ファイル内で maxContextTokens の値を 32768 のように増やし、AIが処理できる情報量を増やす必要がある。また、GENOFFICE_TEMP_DIRという環境変数を設定することで、処理が失敗した場合に、一時的に作成されたXMLの断片ファイルがコンピューターの一時フォルダ（/tmpなど）に散乱するのを防ぐことができる。

genofficeを開発環境に導入する際には、「ネイティブ実行」と「コンテナ化」という二つの方法のどちらを選ぶかという「オープンなトレードオフ」が存在する。macOS、Windows、LinuxといったOSに直接インストールして実行する「ネイティブバイナリ」は、Homebrewなどのパッケージマネージャーを使えば簡単にインストールできる。しかし、genofficeが依存しているNode.jsのライブラリと、システム全体で利用されるElectronバンドル（Web技術でデスクトップアプリを作るための基盤）との間で、バージョン競合が発生し、ソフトウェアが予期せず終了する「セグメンテーションフォールト」という問題が起こるリスクがある。

もう一つの方法として、Dockerのような「コンテナ」技術を使ってgenofficeを分離された環境で実行することも考えられる。この場合、genofficeの実行環境が他のシステムから完全に切り離されるため、依存関係の競合リスクは低減する。しかし、Dockerイメージ自体のサイズが約200MBと大きくなり、またMCP連携で利用されるソケット通信がコンテナ環境ではそのままでは機能しないため、Unixドメインソケットを公開するなどの追加設定が必要になる。もしCI/CD環境のように、複数の開発者が共通の環境を使うことを前提とするならば、コンテナ化が有利である。しかし、個人のローカル開発環境で使う場合は、ネイティブバイナリのわずかな脆弱性を受け入れ、package.jsonやbrew pinを使ってバージョンを固定する方が手軽かもしれない。

genofficeのようなツールは、AIの力を借りてOfficeドキュメント生成という面倒な作業を自動化し、システムエンジニアの作業効率を大きく向上させる可能性を秘めている。しかし、その導入には、技術的なトレードオフや運用上の考慮点が存在することを理解し、プロジェクトの特性やチームの開発文化に合わせて最適な選択をすることが求められる。