openpyxlで挫折した私が、Claude in ExcelでPT仕様書を作った話

はじめに

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90％、年休124日以上 etc.　　詳細はこちらから＞

案件でPT（プログラムテスト）仕様書の作成と改修を担当しました。同じ観点の修正を大量のセルへ反映する必要があり、最初はopenpyxlなどのPythonスクリプトを試しました。しかし書式や内部の算式を潰すケースが多く、直した分より壊した分の確認に時間がかかり断念しました。代わりに使ったのがClaude in Excelです。

自分の運用フロー

以下の流れに落ち着きました。

１．機能定義書などの詳細資料とソースコードをAIに読み込ませる

２．AIと相談しながら、まずタスクの大項目（方向性）を自分で決める

３．細かい小項目の展開はAIに任せ、Claude in Excel用のプロンプトを出力させる

４．そのプロンプトをExcelファイル上で実行し、最後に必ず結果集計を返させる

５．VS Code上のClaudeのレビューと、自分の目視チェックを入れる

ポイントは、Excelを直接触らせる前に「プロンプトを作る工程」を分けたことです。方向性を固めてから流し込むので、後戻りが小さくなります。

使ってわかった利点と不足

利点は二つです。大量のセル操作をまとめて効率化できること、そして元のフォーマットが維持されることです。スクリプトで諦めた書式・算式の破壊が起きないのは大きな利点でした。

不足は精度です。脱字や半角・全角の混在といったミスが混ざっていました。結果集計を返させても、その集計自体が正しいとは限らないので、必ず自分で読んでチェックする必要があります。

反省点：ツールより先に「テスト視点」

今回はPT仕様書を作るのが初めてでもあり、ツールよりも内容面での反省が大きいです。テスト視点ではなく開発視点で書いてしまい、画面上の具体的な表現ではなく一部ソースコードの話が混ざり、テスト操作の記述も抽象的で具体さが足りませんでした。

対策として、プロンプトの時点でテスト対象を画面操作とAPI操作に限定するようにしました。制約を書かないと、AIは「ソースコード調査」のようなテストとは言えない項目まで追加してしまいます。実際にPT担当者への対応でこの方針を採用してからは、作成する説明文書が大分分かりやすくなり、担当者からの再確認はほぼなくなりました。

AIは指示した方向にきれいに大量生産するので、方向性が誤れば誤ったものが大量にできあがります。大項目を人間が決める工程は、効率化のためではなく品質を守るために必要だと実感しました。

まとめ

Claude in Excelは、書式や算式を保ったままExcelを一括で直せる点でスクリプトより実用的でした。一方で、AIに渡す「観点」の質と最後の目視チェックは人間の仕事として残ります。

【エンジニア募集中】フルリモートも◎(リモート率85.7％)、平均残業8時間、年休124日以上、有給取得率90％ etc.　詳細はこちらから＞