はじめに
先日、100ファイル以上のExcelに対して、一括修正とデータ集約を行う仕事がありました。
今回、私はプログラムの実装をAIに任せ、PowerShellを使って処理しました。
Excelの自動化といえばVBA、最近であればPythonを選ぶことも多いと思います。
しかし、今回私が選んだのはPowerShellでした。
理由は、対象がWindows上のExcelファイルであり、追加の実行環境を準備せずに処理できると考えたためです。
また、AIにコードを書かせた一方で、実行とエラー確認は自分で担当しました。
この記事では、今回の業務内容と技術選定の考え方、AIを利用した開発の役割分担について紹介します。
※実際の業務用コードは掲載していません。記事中のコードは、Excel COM操作の仕組みを説明するための参考例です。
1. 今回の業務要件
今回の仕事は、大きく2つのタスクに分かれていました。
タスク①：100ファイル以上のExcelを一括修正する
対象のExcelファイルには、それぞれ複数のワークシートがありました。
実施する処理は以下のとおりです。
- Excelブックのシート構成に関する保護を解除
- 1枚目の表紙シートを、ファイルごとに指定された名前に変更
- 2枚目のシートを、正しいサンプルシートに差し替え
- 3枚目のシートも同様に差し替え
- 最後にシート構成の保護を再設定
- 保存して終了
ここでいう保護は、Excelの「ブックの構成を保護する」機能です。
ワークシート内のセル編集を制限するシート保護とは異なります。
この処理を100ファイル以上に対して行う必要がありました。
タスク②：100ファイル以上の明細を1つに集約する
もう一つは、各Excelファイルの4枚目に存在する一覧表から明細データを取得し、1つのExcelファイルに集約する作業です。
処理イメージは以下のとおりです。
入力フォルダ
│
├─ File001.xlsx
│ └─ 4枚目のシート → 明細取得
│
├─ File002.xlsx
│ └─ 4枚目のシート → 明細取得
│
├─ File003.xlsx
│ └─ 4枚目のシート → 明細取得
│
│ ...
│
└─ File100.xlsx
└─ 4枚目のシート → 明細取得
│
▼
PowerShellで集約
│
▼
Summary.xlsx
各ファイルを開いてコピー＆ペーストするだけでも実現できますが、100ファイル以上となると現実的ではありません。
また、処理結果の確認や作業の再実行も考慮する必要があります。
2. なぜVBAではなかったのか
Excelの自動化であれば、VBAは有力な選択肢です。
Excelのオブジェクトモデルを直接利用でき、シートのコピーや削除、ブック保護の設定なども実現できます。
しかし今回のような複数ファイルの一括処理では、マクロの管理や実行方法も考える必要があります。
例えば、処理用のExcelファイルを用意し、そこから100以上のファイルを順番に開いて操作する方法が考えられます。
もちろん、技術的には問題ありません。
ただ、今回の処理はExcelの画面上で操作する必要がなく、ファイルシステムから対象ファイルを取得して、順番に処理すれば十分です。
そのため、Excelブックの外側から処理を制御できる方法を選びたいと考えました。
3. なぜPythonではなかったのか
PythonでExcelを操作するなら、openpyxlなどが候補になります。
from openpyxl import load_workbook
wb = load_workbook("sample.xlsx")
ws = wb.worksheets[0]
ws.title = "新しいシート名"
wb.save("sample.xlsx")
このような処理を比較的簡単に記述できます。
大量のExcelファイルを扱うのであれば、Pythonは十分に合理的な選択です。
ただし、今回の環境ではPythonを導入する必要がありました。
Python本体やライブラリのインストール、利用するバージョンの確認など、実行環境の準備が必要になります。
また、既存のExcelファイルを編集する場合は、書式、図形、マクロ、外部リンクなどの保持についても確認が必要です。
openpyxlは便利ですが、Excelアプリケーションそのものを操作するわけではありません。
今回のようにシートを別のブックから差し替える作業では、Excel本体の機能を利用したほうが扱いやすいと判断しました。
なお、Pythonでもpywin32などを使えばExcel COM操作は可能です。
つまり、PythonでできないからPowerShellを選んだわけではありません。
今回の環境で、最も準備の少ない方法を選んだということです。
4. PowerShellによるExcel COM操作
PowerShellでは、COMオブジェクトを利用してExcelを操作できます。
ExcelがインストールされているWindows環境であれば、以下のようにExcelアプリケーションを生成できます。
$excel = New-Object -ComObject Excel.Application
$excel.Visible = $false
$excel.DisplayAlerts = $false
その後、Workbookを開いて操作できます。
$path = "C:\Work\sample.xlsx"
$workbook = $excel.Workbooks.Open($path)
# 1枚目のシートを取得
$sheet = $workbook.Worksheets.Item(1)
# シート名を変更
$sheet.Name = "新しい表紙名"
# 保存
$workbook.Save()
このように、Excel VBAと似たオブジェクトモデルを利用できます。
私がPowerShellを選んだ理由の一つが、この操作性です。
VB.NETやC#からExcelを操作するのと同じように、COM経由でWorkbookやWorksheetを制御できます。
ブックの保護解除と再設定
ブックの構成保護を解除する場合は、次のような処理になります。
$workbook.Unprotect("password")
# シートの変更処理
$workbook.Protect(
"password",
$true,
$false
)
これはパスワードが分かっているブックの保護設定を解除・再設定する例です。
引数の$trueはブック構成の保護、$falseはウィンドウ保護を指定しています。
実際には、パスワードをコードに直書きしない方法や、保護状態を確認する処理も検討すべきでしょう。
シートの差し替え
Excel COMでは、別のブックからワークシートをコピーすることもできます。
例えば、サンプルブックのシートを処理対象ブックへコピーする場合です。
$sourceBook = $excel.Workbooks.Open(
"C:\Work\template.xlsx"
)
$targetBook = $excel.Workbooks.Open(
"C:\Work\target.xlsx"
)
$sourceSheet = $sourceBook.Worksheets.Item(2)
$sourceSheet.Copy(
[System.Type]::Missing,
$targetBook.Worksheets.Item(1)
)
この例では、サンプルブックの2枚目のシートを、対象ブックの1枚目のシートの後ろにコピーします。
実際の差し替え処理では、既存シートの削除、シート名の重複、コピー後のシート順序なども制御する必要があります。
特に、シートを削除するとインデックスが変わるという点には注意が必要です。
また、他のシートから参照されているワークシートを削除すると、数式が#REF!になる可能性もあります。
シートの差し替えは、単に削除してコピーすればよいというものではありません。
5. 100ファイル以上の処理では、エラー管理が重要
単一ファイルで正常に動作するコードでも、100ファイル以上で実行すると、想定外のエラーが発生する可能性があります。
例えば、以下のようなケースです。
- 対象ファイルが別のプロセスで開かれている
- 想定した枚数のシートが存在しない
- シート名が重複する
- ブックの保護状態が想定と異なる
- 一部のファイルだけ構造が違う
- 保存時にエラーが発生する
そのため、大量処理ではファイル単位の例外処理が重要になります。
PowerShellであれば、次のような構成が考えられます。
$files = Get-ChildItem `
-Path "C:\Work\Input" `
-Filter "*.xlsx" `
-File
foreach ($file in $files) {
try {
Write-Host "Processing: $($file.Name)"
# Excelファイルを開く
# ブック保護解除
# シート変更
# ブック保護再設定
# 保存
Write-Host "Success: $($file.Name)"
}
catch {
Write-Warning "Failed: $($file.Name)"
Write-Warning $_.Exception.Message
}
}
これは処理構造を示す参考コードです。実際には、失敗時に開いたブックを閉じるfinally処理などが必要です。
また、Get-ChildItemで取得したファイルの中から、Excelの一時ロックファイル（~$で始まるファイル）を除外するなどの工夫も必要になります。
実務では、処理対象ファイルごとの成功・失敗、処理時刻、エラー内容をCSVなどに記録しておくと、後から確認しやすくなります。
Excel COM操作ではプロセス管理にも注意する
PowerShellによるExcel COM操作では、Excelプロセスの終了処理にも注意が必要です。
単にPowerShellの処理が終了しただけでは、EXCEL.EXEが残ってしまうことがあります。
そのため、WorkbookのClose()、ExcelアプリケーションのQuit()、COMオブジェクトの解放などを適切に実装する必要があります。
大量のファイルを扱う場合は、途中でエラーが発生しても、Excelの終了処理が実行される設計が望ましいでしょう。
6. AIにコードを書かせ、実行は自分で行った
今回の開発方法についても触れておきます。
私は、PowerShellのコードを自分で一から書くことはしませんでした。
実現したい処理をAIに伝え、コードを生成してもらいました。
その後、生成されたコードを自分で実行し、エラーが発生した場合は内容を確認して、AIに修正を依頼しました。
役割分担は次のようになります。
| 工程 | 担当 |
|---|---|
| 業務要件の整理 | 人間 |
| 実装方式の検討 | 人間 |
| プログラミング言語の選定 | 人間 |
| PowerShellコード生成 | AI |
| 実行 | 人間 |
| エラー確認 | 人間 |
| コード修正案の生成 | AI |
| 結果の確認 | 人間 |
このような開発スタイルは、AIを活用したプログラミングの一つの形だと思います。
ここで意識したのは、AIに任せる範囲と、人間が責任を持つ範囲を分けることです。
今回のように実際の業務ファイルを操作する処理では、コードが誤っていた場合、100ファイル以上を一度に破損させる可能性もあります。
そのため、AIが作成したコードを無条件に実行するのではなく、自分で確認してから実行しました。
この判断は、単に慎重だったというだけではありません。
AIを利用した業務自動化では、実行権限をどこまで与えるかが設計上の重要な要素になると考えているためです。
7. AI時代のエンジニアは、コードを書くことより技術選択が重要になる？
今回の経験で興味深かったのは、プログラミング言語の選び方です。
従来なら、自分が習熟している言語を選ぶことも重要な判断基準でした。
例えば、Pythonに詳しいエンジニアならPython、VBAに詳しいエンジニアならVBAを選ぶことが多いと思います。
しかし、AIがコードを生成できるようになると、少し事情が変わってきます。
人間がその言語の構文をすべて覚えていなくても、コードを作成しやすくなりました。
一方で、実行環境の制約やシステムとの相性を判断する必要性は変わりません。
今回の場合は、
- Windows環境である
- Excelがインストールされている
- 対象は100ファイル以上
- Excelブックの構造を変更する必要がある
- 追加の実行環境をなるべく導入したくない
という条件からPowerShellを選択しました。
私自身、これは適切な判断だったと思っています。
もちろん、対象が数万ファイルに増えたり、Linux環境で動かしたり、サーバー上で継続運用したりするのであれば、別の方法を検討します。
Excel COMはデスクトップ環境での操作には便利ですが、MicrosoftもOfficeの無人・サーバーサイド自動化を推奨していません。
用途が変われば、最適な技術も変わります。
重要なのは、特定の言語にこだわることではなく、目的と実行環境に適した技術を選択することだと思います。
8. 今回の処理を製品化するなら
今回は単発の業務処理でした。
そのため、PowerShellのスクリプトで十分でした。
しかし、同じ処理を定期的に行うのであれば、もう少し設計を考える必要があります。
例えば、以下のような機能です。
| 機能 | 目的 |
|---|---|
| 設定ファイル | フォルダやシート名などを外部指定する |
| ドライラン | 実ファイルを変更する前に対象を確認する |
| バックアップ | 変更前のファイルを保持する |
| ログ出力 | 成功・失敗・変更内容を記録する |
| リトライ | 一時的なエラーから回復する |
| 入力検証 | シート構造や必須項目を確認する |
| 結果照合 | 処理前後の件数や内容を確認する |
また、データ集約では、どのファイルから取得したデータなのかを記録しておくと、後から追跡しやすくなります。
処理結果を再現できるようにすることも重要です。
このような仕組みを整備すれば、単発のスクリプトから、繰り返し利用できる業務自動化ツールへ発展させることもできます。
まとめ
今回、100ファイル以上のExcelの修正とデータ集約を、AIが生成したPowerShellコードを使って処理しました。
この経験から感じたことは3つあります。
1. AIを使うからといって、最新技術が最適とは限らない
既存のWindows環境を利用するなら、PowerShellが合理的な選択になる場合があります。
2. AIにコードを書かせても、技術的な判断は必要
何を実現するか、どの技術を選ぶか、どこまで自動化するかは、依然として重要な設計判断です。
3. AIと人間の責任範囲を明確にする
今回はAIにコードを生成させ、実行とエラー確認は自分で行いました。
将来、AIエージェントが実行から検証まで行うようになっても、どこまで権限を与えるかという判断は必要でしょう。
AIの発展によって、エンジニアがコードを書く時間は減っていくかもしれません。
しかし、業務を理解し、システムを設計し、適切な技術を選び、結果を判断するという仕事がなくなるわけではありません。
コードを書かないことと、技術を理解しなくてよいことは違う。
今回の仕事は、それを改めて感じる機会になりました。