この記事の要点
- Excelがない環境でも、LibreOfficeを使ってAIでVBAを開発できた
- 約3,000行中、Excelで修正したのは130行だけだった
- ポイントは「環境依存コードを局所化する設計」
- AIを活用するほど、設計の重要性を実感した
対象読者
- 業務ではExcel VBAを開発している、または開発したい
- 業務PCにはソフトウェアを追加でインストールできない
- 自宅にはMicrosoft Officeがない
- AIを活用してVBAを開発したい
この記事で分かること
- Excelがない環境でもAIを活用してVBAを開発する方法
- ExcelとLibreOfficeを両立するための設計方針
- 環境依存コードを分離することで、約95%以上のコードを共通化できた事例
- AIエージェントを利用した開発で得られた設計上の知見
この記事で扱わないこと
- LibreOffice BasicとExcel VBAの文法差異
- LibreOffice固有の制約やハマりどころ
- 移植時に遭遇した技術的な問題
→これらは次回の記事で詳しく紹介します。
はじめに
会社ではExcel VBAを開発しているのに、自宅にはExcelがない。このような環境の方も多いのではないでしょうか。
私も
- 会社PCではExcelが利用できる
- 自宅にはExcelがない
- 会社PCにはソフトウェアをインストールできない
という環境で、約3,000行規模のマクロを開発する必要がありました。
そこで、開発環境としてLibreOffice Calc Basicを採用し、AIを活用しながら開発を進めました。
環境依存コードを局所化する設計を採用した結果、最終的に修正したのは約130行だけ。つまり、95%以上のコードをそのまま利用できました。
この記事では、Excelがない環境でもVBAを開発できた設計と、その経験から得られた「AIを活用するほど設計が重要になる」という知見を紹介します。
最初に決めた設計
開発を始めるにあたり、最初に考えたのは「ExcelとLibreOfficeの差異はどこにあるのか」ということでした。
私の予想では、最も大きな違いはセルの入出力でした。
一方で、ビジネスロジックはどちらの環境でも共通に動作するはずだと考えました。
そこで、保守性やAIによる実装効率を考え、責務ごとにモジュールを分割しました。その中でも、セルへの読み書きなど環境に依存する処理は1つのモジュールへ集約する設計を採用しました。
この設計であれば、環境が変わっても修正の大半はセル入出力モジュールに集約できると考えました。
また、ビジネスロジックはExcelやLibreOfficeを意識する必要がなくなるため、環境の違いを気にせず実装できるようになります。
さらに、責務ごとにモジュールを分割したことで、機能追加やメンテナンスもしやすい構成になりました。
AIに実装を依頼する際も、環境依存コードを書かせないというルールを作りやすくなります。
もちろん、この時点ではExcelとLibreOfficeの差異をすべて把握していたわけではありません。
実際には、配列構造やCOMオブジェクトなど、セルアクセス以外にも環境依存となる箇所が存在しました。
実際どうだったか
開発完了後、LibreOffice向けのコードをExcel VBAへ移植しました。
その際に修正が必要だったのは、約3,000行のコードのうち130行でした。
つまり、95%以上のコードをそのまま利用できました。Excelへの移植時は、セルアクセスモジュール1ファイルを差し替えるだけで対応できました。
最初に立てた「環境依存なのは主にセルアクセス周辺だろう」という仮説は、おおむね正しかったと言えます。
もちろん、設計時には想定していなかった差異もありました。
開発を進める中で、セルアクセス以外にも環境依存となる箇所が見つかりました。特に、Scripting.DictionaryをはじめとするCOMオブジェクトは、LibreOfficeではExcelと同じようには扱えませんでした。そのため、LibreOffice側の制約を基準に設計を見直しました。
その結果、Excelへの移植時に大きな設計変更は不要で、修正はセルアクセスモジュール1ファイルの差し替えだけで済みました。
具体的にどのような差異があり、どのように対応したのかについては、次回の記事で詳しく紹介します。
AIを利用した開発で分かったこと
今回の開発では、仕様整理、設計の相談、実装、テストコードの作成、ドキュメント作成など、多くの工程でAIを活用しました。
特に、Utility関数の作成や変数名の提案といった定型的な作業では非常に有用で、開発速度の向上を実感しました。
一方で、リファクタリングや設計の整理、生成されたコードのレビューは自分で行っています。
AIは実装を高速化してくれました。しかし、設計やレビューまで任せるより、人が確認した方が結果的に効率的・経済的でした。
AIは設計や品質を自動で保証してくれるわけではない
今回の開発では、AIは非常に有用でしたが、次のような点には注意が必要だと感じました。
-
直近の要求を優先しやすい
- 設計ルールや既存仕様よりも、直前の指示に従った実装を提案することがありました。
- 実際に重要な判定処理が削除されたこともあり、Gitで管理していたため復元できました。
-
計算量を考慮しない実装を提案することがある
- 動作するコードは生成できますが、アルゴリズムの効率まで最適化されているとは限りませんでした。
-
保守性が低いコードを提案することがある
- 責務の分割が不十分なコードや、リファクタリングした方が読みやすいコードも見られました。
AIにレビューも依頼できますが、その分トークンを消費します。
そのため、設計や品質を確認する役割は人が担い、AIは実装支援ツールとして活用するのが効率的だと感じました。
設計を先に固めるほどAIを活用しやすい
今回の開発では、最初に責務ごとのモジュール分割や、環境依存コードを局所化する方針を決めていました。
この設計方針があったことで、AIへ実装を依頼する際も対象となるモジュールを限定でき、不要なコードまで参照させる必要がありませんでした。
結果として、トークンの使用量を抑えながら、設計の一貫性も維持しやすくなりました。
今回の開発を通して最も強く感じたのは、AIの性能以上に 設計が重要 だということです。
AIは実装を大きく効率化してくれる一方で、どのような構造で開発するか、生成されたコードが仕様を満たしているかを判断するのは人の役割です。
開発環境に制約がある場合でも、設計を先に固め、人とAIの役割を意識して開発を進めることで、効率よく開発できると感じました。
まとめ
今回の開発では、自宅にExcelがないという制約の中で、LibreOfficeとAIを利用してExcel VBAのマクロを開発しました。
開発前は「ExcelとLibreOfficeはどの程度互換性があるのか」が分からない状態でしたが、環境依存コードを局所化したことで、小さな修正だけでExcelへ移植できました。
開発中には想定外の差異も見つかりましたが、より制約の大きいLibreOffice側に設計を合わせることで、設計全体を大きく変更することなく対応できました。
今回の経験から、Excelがない環境でも、設計を工夫すればLibreOfficeはExcel VBAの開発環境として十分活用できることを実感しました。
この考え方はLibreOfficeに限らず、異なる実行環境へ移植するソフトウェアを開発する際にも応用できると思います。
また、AIを活用した開発では、実装そのものよりも設計の重要性を改めて実感しました。
今回は、Excelがない環境でもAIを活用してVBAを開発するための設計について紹介しました。
次回は、LibreOfficeとExcel VBAの環境差異や、それらをどのように設計で吸収したのかを実例とともに紹介します。
- Class Moduleが利用できない
- Dictionaryへオブジェクトを格納できない
- セル配列の構造の違い
-
NothingとNullの扱い -
Errオブジェクト - デバッガ
- AIを利用した開発で分かったこと
など、実際に遭遇した問題と、その解決方法をまとめる予定です。