ClaudeでVBAをOffice Scriptsへ移行 — 移せる処理と残す処理

VBAマクロを丸ごとOffice Scriptsに書き換えようとすると、途中で必ず詰まります。移せない処理が混ざっているからです。先にマクロを手続きごとに仕分け、移せる分だけをClaude Codeに変換させるほうが早く終わります。

この記事は、仕分けの基準とClaude Codeへの頼み方をまとめたものです。VBAを新しく書く側の話はClaude CodeでExcel VBAマクロを書く手順に分けてあり、ここでは移行の判断だけを扱います。

移行できるかは「どこで動くか」で決まる

Office Scriptsは、Excel on the web、Excel for Windows、Excel for Macで動きます。iOSとほかのOffice製品では動きません。Power Automateから呼べるのもOffice Scriptsだけです。

Microsoft Learnの比較表を並べると、次のようになります。

VBAはデスクトップ向けに作られた仕組みで、COMやOLEを通じてPCの環境に触れます。Office Scriptsは、クラウドで安全に動くことを狙った別の設計です。移行とは言語の書き換えではなく、動かす場所を変える作業になります。

使うには、企業向けか教育機関向けのライセンスが要ります。VBAはデスクトップ版Excelに組み込まれていて、特別なライセンスは不要です。Power AutomateでOffice Scriptsを使う場合は、Microsoft 365のビジネスライセンスが必要になります。

仕分け表 — 移せる処理と残す処理

マクロの中身を機能ごとに見て、次の3つに振り分けます。

そのまま移せる処理

Excelの中だけで完結する処理です。Range操作、表への行追加、列の合計といった定番の作業が当たります。Office Scriptsはブラウザ版Excelで想定される操作をほぼ網羅していて、新機能もWeb版から順に対応していく方針だと説明されています。

一方、VBAのほうがデスクトップ版の機能の網羅性では上です。デスクトップ版にしかない機能を使っているマクロは、Office Scripts側のAPIに対応があるかを個別に確かめます。

呼び出し方を変える処理

Office Scriptsは、Excelのイベントに反応しません。スクリプトが動くのは、ユーザーが手動で実行したときか、Power Automateのフローが呼んだときだけです。

そのため、Workbook_Open や Worksheet_Change に仕込んだ処理は、そのままでは移せません。処理の中身はスクリプトにして、起動のきっかけをフロー側に移します。

• 毎朝の更新は、Power Automateのスケジュールで呼ぶ
• メール受信やフォーム回答のようなきっかけは、フローのトリガーで受ける
• 人が押す処理は、ブック内のボタンに割り当てる

Office Scripts自体のスケジュール機能は、現在一時的に無効です。既存のスケジュールは動き続けますが、新しく組むならPower Automateでフローを作ります。

移せない処理

3つが残ります。

ファイル操作。VBAはPCのファイルシステムに触れます。Office Scriptsが触れるのはブックだけで、そのブックがあるマシンには触れません。ファイルを開く・消すといった操作は、スクリプトの外のフローで受ける設計に変えます。

COM・OLE連携。デスクトップ連携の仕組みは、Office Scriptsの側にありません。Outlookなど他のアプリを操作していた処理は、Power Automateのコネクタで受ける形に組み替えます。

UserForm。比較ページの一覧に、UserFormに当たる部品は載っていません。入力画面が必要な処理は、main の引数をフローから渡すか、シートのセルに入力させてボタンで実行する形に組み替えます。

外部APIを呼ぶマクロは前提が変わる

VBAからインターネットを呼ぶ処理は、移せる場合があります。Office Scriptsは fetch を使えますが、制約が多いので設計から見直します。

• main を async にして Promise を返す
• サインインやOAuth2の認証フローは使えず、キーや認証情報はスクリプトに直接書くか別の場所から読む
• 認証情報を保管する仕組みがない
• 取得したJSONは、スクリプト内の interface で型を決める。any 型は使えない

もう一つ重い制約があります。外部APIの呼び出しは、通常はExcelアプリ経由でしか行えず、Power Automateから実行するスクリプトでは使えません。SharePointに保存したスクリプトからの外部呼び出しも対象外です。

つまり、夜間にフローで動かしたいマクロが外部APIを呼んでいる場合は、API呼び出しをフロー側のアクションに分け、スクリプトにはデータの受け渡しだけをさせる構成になります。

Claude Codeへの頼み方 — 仕分けを先、変換を後に

仕分けを済ませる前に変換を頼むと、移せない処理まで無理に書き換えたコードが返ってきます。順番を分けます。

手順1 plan modeで棚卸しする

編集を許さないplan modeで、モジュール全体を読ませます。plan modeでは、Claudeはファイルを読んで計画を出すだけで、承認するまで何も編集しません。

claude --permission-mode plan

最初の依頼文は、仕分けの基準ごと渡します。

modules/ のVBAを手続きごとに読み、次の3分類で表にして。
1. Excel内の読み書きだけで完結する
2. イベントや定期実行で起動している(起動条件を書く)
3. ファイル操作・COM・UserFormに依存する(該当行を引用する)
変換はまだしない。

返ってきた表のうち、1番だけを次の手順に進めます。2番は起動条件を、3番は残す理由を表に残しておくと、後で誰が見ても判断を追えます。

手順2変換の規約をCLAUDE.mdに置く

変換の規約を毎回プロンプトに書くと抜けます。プロジェクトのCLAUDE.mdに置きます。次はOffice Scriptsのドキュメントに出てくる制約を、そのまま規約にした例です。

## Office Scripts変換の規約
- エントリは `function main(workbook: ExcelScript.Workbook)` にする
- 外部APIを呼ぶときだけ `async` と `Promise` を使う
- `any` 型は使えない。JSONはinterfaceを定義して受ける
- Power Automateから値を受けるときは `main` の引数を増やす
- ファイル操作・UserFormに当たる処理は変換せず、TODOコメントで残す

最後の一行が肝です。規約に書いておけば、変換できない処理を黙って落とされずに済みます。

手順3 1手続きずつ変換して比べる

たとえば、フォーム回答を表に追加するVBAがあるとします。

Sub AddAnswer(newData As String)
    Dim tbl As ListObject
    Set tbl = ThisWorkbook.Worksheets("Sheet1").ListObjects("SurveyTable")
    tbl.ListRows.Add.Range.Cells(1, 1).Value = newData
End Sub

Power Automateのフローから呼ぶ前提で変換すると、次のような形になります。これは、Microsoft Learnのフロー連携の例に沿った形です。

function main(workbook: ExcelScript.Workbook, newData: string) {
  const table = workbook.getTable("SurveyTable");
  table.addRow(-1, [newData]);
}

引数 newData は、フローが渡す値を受ける口になります。フォームの値は、アクションが返す型の都合で string になる点も、例の側に注記があります。VBAでは Sub の引数だったものが、スクリプトでは「フローとの境界」になります。

動作確認はExcel側のコードエディターで行う

Claude Codeは、Office Scriptsを実行できません。実行と検証は、Excelのコードエディターで人が行い、結果をClaude Codeに返す反復になります。

エラーは2種類あります。コンパイル時のエラーはエディター上に赤い波線で出て、実行前に直します。実行時のエラーは、ブックに存在しないシート名を指定したときなどに出ます。

function main(workbook: ExcelScript.Workbook) {
  let mySheet = workbook.getWorksheet('TestSheet');
  // TestSheetが無いと、ここで実行時エラーになる
  mySheet.getRange("A1");
}

エラーメッセージには行番号が付きます。ただし、原因が指された行とは別の場所にあることもあるため、エラー文だけでなくスクリプト全体をClaude Codeに貼ります。値の確認には console.log を挟みます。ログはエディターのOutputタブに出るだけで、ブックには影響しません。

Automateタブが出ないときは、Microsoft 365のライセンスに含まれているか、管理者が無効にしていないかを順に確かめます。TeamsではWeb版でのみ対応します。

置き場所で呼び出しのアクションが変わる

VBAはブックの中に入っていましたが、Office Scriptsは保存先を選びます。既定ではOneDriveに保存され、ブックに関連付けると、そのブックにアクセスできるチームメンバーも見て実行できます。

Power AutomateのExcel Online (Business)コネクタには、スクリプトを呼ぶアクションが2つあります。

• Run script: OneDriveの既定の場所にあるスクリプト用
• Run script from SharePoint library: チームのSharePointサイトにあるスクリプト用。ブックとスクリプトの場所を別々に指定する

マクロを共有ブックの機能として使っていたチームは、この置き場所の選択が設計の一部になります。SharePointに置くと、先に述べた外部API呼び出しは使えなくなります。

Run scriptアクションは、コネクタを使う人にブックとデータへの大きなアクセスを与えます。機密性の高いブックでは、管理者がコネクタやOffice Scriptsの利用を制限できます。移行の際は、誰がフローを編集できるかも併せて見直します。

多数のマクロを一括で仕分けるとき

マクロが数十個ある場合は、1つずつ対話せず、非対話モードで流します。標準入力にモジュールを渡し、標準出力で結果を受ける使い方です。

for f in modules/*.bas; do
  echo "## $f"
  cat "$f" | claude -p "Office Scriptsに移せるか、移せない処理があるか。\
理由を3行で"
done > triage.md

出力は、手順1の表の下書きとして使います。判定が割れたモジュールだけを対話で見直せば、全部を読む手間が省けます。

移行の前に決めておくこと

最後に、移行そのものの要否を考えます。VBAを残すほうが合理的なケースも少なくありません。

• 利用者がデスクトップ版Excelだけで、ブラウザ版もPower Automateも使わない
• マクロの大半がファイル操作やUserFormで、移せる部分が少ない
• ライセンスがOffice Scriptsの対象外である

逆に、複数人でブックを共有している、フローで自動更新したい、PCに依存しない形にしたい、といった事情があるなら移行の価値があります。段階的に進める考え方は、データベースの移行でも同じです。MySQLからPostgreSQLへの移行や主キーのbigint化も、先に調べて仕分けてから小さく切り替えています。

まず1本、Range操作だけで完結する短いマクロを選び、変換して動かしてみてください。そこで得た規約をCLAUDE.mdに足していけば、残りの変換は同じ型で進められます。