Microsoft 365のExcelでGPT連携の自動化を設計する
ExcelとGPTを橋渡しする前提を確認する
大規模言語モデルはテキストやJSONを生成できると資料は述べているが、Excelのブックを直接編集する手は示していない。 したがって、Excel側の自動化機構に出力を渡す設計が必要になる。 資料にあるExcel側の経路は、ExcelのOfficeスクリプトと、Microsoft GraphのExcel REST APIの二つに整理できる。 どちらも役割が異なり、設計段階で選び分ける前提を固めておく。
Officeスクリプトは、Excelで日常のタスクを自動化できるとしている。 エディターとレコーダーがあり、ボタンからの実行やPower Automateとの統合も見出しに挙がっている。 ユーザー操作に近い形での自動化に向き、ワークブックの中から開始できる点が強みになる。 ただし、どの環境で動かすかや外部呼び出しの設計は最初に決めておく。
Excel REST APIは、OneDrive for BusinessやSharePointにあるブックに対して、ワークシートやテーブルなどをRESTでCRUDできるとしている。 ファイルの場所はDrive APIのURLで特定し、ワークシートの一覧取得など標準的な操作が可能と記されている。 サポート範囲について、.xlsx形式のみ対応とされ、.xlsは対象外である。 また、個人向けのOneDrive上のブックは対象外と注記されている。 この二点は設計の可否に直結するため、早期に確認する。
OpenAIのResponses APIは、プロンプトからテキストや構造化JSON、コードなどを生成できるとしている。 ここから得た出力を、OfficeスクリプトやExcel REST APIの入力に変換する橋渡しを用意すれば、自然文の指示からExcelの操作に到達できる。 モデル自体は外部ファイルへのCRUDを提供しないため、操作は常にExcel側のAPIに委ねる。
公式ドキュメントから引ける実装パスを並べる
一次資料に基づく三つの役割を表にする。
| 経路 | 役割 | できること | 主な制約 |
|---|---|---|---|
| Officeスクリプト | Excel内の実行 | レコーダーとエディターで操作を自動化し、ボタン実行やPower Automateとの統合 | 実行環境の前提を満たす必要がある |
| Excel REST API (Graph) | 外部からのCRUD | OneDrive for Business/SharePoint上の.xlsxをAPIで読み書き | .xlsは非対応、個人向けOneDriveは非対応 |
| OpenAI Responses API | 指示の生成 | テキストやJSON、コードを生成 | ファイルCRUDは提供しない |
この対応関係から、GPTの出力をExcelに適用するには、OfficeスクリプトかExcel REST APIのどちらかを実行器として選ぶのが筋になる。 選択は運用の開始点と自動化の範囲で決める。 以下にパターンを二つ示す。
- パターンA: Officeスクリプトを実行器にする設計
- スクリプトで対象範囲を読み取り、適用可能な更新単位を決める。
- 外部の中間サービスがOpenAI Responses APIを呼び、構造化JSONなどの適用指示を得る。
- スクリプトは受け取った指示をもとにセルやテーブルを書き換える。
- 実行はボタンから行うか、Power Automateとの統合でフローから起動する。
- パターンB: Excel REST APIを実行器にする設計
- 中間サービスがGraph経由でブックの範囲を取得する。
- OpenAI Responses APIで変換方針や生成結果を得る。
- Graphのエンドポイントで同じブックに書き戻す。
- ファイルの場所はDrive APIのURLで特定し、形式は.xlsxに統一する。
どちらのパターンでも、指示の表現はLLMにJSONで出させると後段の適用が単純になる。 資料にはJSON生成の記述があるため、エラー時の分岐や差分適用も設計しやすい。
制約が引き起こす落とし穴と回避策
設計と現実の差が最初に出るのは保管場所である。 Excel REST APIは業務向けプラットフォームのブックだけを対象としており、個人向けOneDriveのファイルでは同じAPIが使えないと資料にある。 部署横断の自動化では、対象ブックをOneDrive for BusinessかSharePointに移す移行計画が必要になる。 移行前の参照が混在すると、更新できるブックとできないブックが生じる。
次に、ファイル形式の差が適用可否を分ける。 .xlxsは対応だが、.xlsは非対応と明記されているため、古い台帳が残っている場合は変換手順を先に回す。 形式変換を後回しにすると、自動化が一部のファイルで停止し、例外処理が常態化する。 形式統一は機能要件というより前提条件である。
権限設計も初手で詰める余地がある。 資料は認可とスコープの設定が必要と述べており、最小権限での読み取りと書き込みに分けると監査しやすい。 個人トークンで開始しやすい一方、運用ではアプリ登録や管理者承認の順序を決め、のちの引き継ぎ不能を避ける。
OpenAI Responses APIの出力は確率的である。 適用前に検証の関門を置き、セル番地の範囲外アクセスや型の不一致を弾くと、Excel側の失敗を抑えられる。 JSONスキーマを先に提示し、許容しない値域を明示するだけでも再現性が上がる。
どの経路を選ぶかの判断基準
運用の開始点がExcelの画面内にあるなら、Officeスクリプトを第一候補に置く。 レコーダーで雛形を作り、エディターで堅くする流れが取りやすく、Power Automateとの統合で段階的に外部化できる。 人が最終確認してから適用する運用にも合わせやすい。
ファイルを横断して無人で動かすなら、Excel REST APIと中間サービスの組み合わせが合う。 OneDrive for BusinessやSharePointへの配備、権限とスコープの整理、.xlsxへの統一が前提として成立していることを条件にする。 モデルの出力はJSON固定にして、差分適用の失敗時に安全にロールバックできる道筋を確保する。
OpenAI Responses APIの役割は一貫して指示の生成である。 生成物はOfficeスクリプトやGraph APIでのみ適用できるため、両者のAPIが受け入れやすい粒度に指示を刻む。 セルの更新、テーブル行の追加、書式の設定など、Excel側が保証する操作単位に分解すると失敗時の切り分けが容易になる。