VBA コードの管理方法について：msaccess-vcs-addin 編

こちらの記事では vbac.wsf を使って VBA を管理する話をまとめました。ここでは、 Access 用のソースコード管理を可能にするアドイン msaccess-vcs-addin についてまとめてます。

なお、今回試した際の環境は下記の通りです。

• OS: Windows 11 Pro, 64 bit 24H2
• Access: Microsoft 365, version 2010 (build 13328.20408)
• msaccess-vsc-addin: 5.0.1

msaccess-vsc-addin

このアドインを見つけたきっかけは、こちらの記事で書いたように Codex で遊んでいた時に、改めて VBA の開発で Codex を使えないものかと思って、いろいろと調べたことでした。

その時、 Access には SaveAsText / LoadFromText というメソッドがあることに気がつきました。 これを使えば、 Access でもソースコード管理ができそうですよね。いい具合に、マイクロソフトの記事などもあったのでこれなどを参考に自分で作ろうかとも思ったのですが、さらに調べてみると既にオープンソースのアドインがあることがわかりました。

GitHub - joyfullservice/msaccess-vcs-addin: Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system. · GitHub

既に紹介しているブログもあったんですね。

Accessのバージョン管理どうしてる？運用の工夫 - なかぜんのPC &副業ラボ

これは使えそうです。ということで早速試してみます。

インストール

msaccess-vcs-addin の git リポジトリをみると Quick Start があるので、こちらの手順に従います。

1. Releases のページから最新版の zip ファイルをダウンロードします
2. 解凍します
3. 解凍したフォルダにある Version Control.accda をダブルクリックして開きます（Access が立ち上がります）
4. もし、オプションを変更したい場合は、こちらのページから設定できる内容をご確認ください
5. Install Add-In ボタンを押します
6. アドインのインストール先が『信頼できるフォルダ』に入っている必要があり、追加してよいか確認画面が表示されるので、OKを押します
7. インストールに成功すると下記画面が表示されて、Accessが自動的に閉じられます

デフォルトでは %AppData%\Roaming\MSAccessVCS\ にアドインがインストールされます。

なお、アドイン追加後、Accessを起動して、『オプション』->『トラストセンター』->『信頼できる場所』を表示すると、

のように、先ほどインストールしたフォルダが追加されていることがわかります。

使い方

アドインを追加後、Accessを起動すると、メニューに

『Version Control』が追加されています。ここを開くと

こんな感じにアイコンがたくさん表示されます。

エクスポート

既存の Access ファイルを開いて、『Version Control』の『Export Source Files』を選択します。

デフォルトだと『ファイル名.src』フォルダが作られて、そこにエクスポートされたファイル一式が作成されます。

リンクテーブルを使っている場合、認証情報は .env ファイルが作られてそちらに出力されます。なお、 .env ファイルについてはこちらに詳しく説明されています。

あと、やってみて気づいたのですが、テキストインポートの定義などもちゃんとエクスポートされていました。

エクスポートが完了したらこれらのファイル一式を git に登録すれば、ソースコード管理ができます。なお、 .gitignore も参考となるひな形がリポジトリにあるので、そちらをベースにして自分用に修正してください。

ビルド

エクスポートしたファイルから再度 Access ファイルを構成するには『Version Control』の『Build From Source』を選択します。

もし、既存のファイルを開いてる場合は

のように、 source ファイルからビルドしてよいか確認されます。この場合も、既存のファイル（いま開いているファイル）は、リネームして保存されるとあります。なので、『はい』を押すと、

こんな感じのログ画面が表示されて、処理が進行します。途中で信頼できるファイルか確認されますが、 OK を押して処理を進めます（sourceからビルドしたファイルを開きなおしているためだと思います）。問題なく最後まで進むと、

このような感じでダイアログが表示されて完了です。この時点で、ビルドされた Access ファイルが開かれた状態になっています。改めて、このファイルを操作してみていろいろと試してみても、元のファイルと遜色ないようです。いやー、すごいですね。

オプション

エクスポート時にソースファイルを保存するフォルダが『ファイル名.src』だと何かと不便です。これに対しては、リボンの『View Options』よりオプション設定を開いて、

エクスポート先として src サブフォルダを使うように指定することで解決できます。

なおオプション設定にはいろいろな機能があるようなので、詳しくはこちらをご覧ください。

その他

バックアップではなく、スキーマとアプリケーションが対象なので、テーブルのデータは出力されません。

あと、実際に git に登録するときは .gitignore と .gitattributes を整えておくとよいかと思います。それぞれリポジトリに .default と最後についたひな形があるので、これを元にプロジェクト用に調整すればよいと思います。

トラブル

さて、これで問題なく使えるかと思って、実際に仕事で使っている Access ファイルを対象にエクスポートとビルドを試しました。すると、ビルド後のファイルを確認すると、テーブル、フォーム、クエリ、レポートなど、どれもこれも一部が復元されていないものがあります。

どういうことだろうか？と思って何度も試していると、これらのオブジェクトの名前に一部のカタカナが含まれていると、エクスポートはできるけど、ビルドで読み込まれない、という現象になるようです。

具体的には、元の Access ファイルに

のようなテーブルとフォームが含まれているとします。 Export Source Files を実行すると

のように、ファイルが作成されています。

この状態で Build From Source を実行すると

のように、一部のテーブルやフォームが復元されないことがわかりました。

今回試した範囲だと

• インポート
• エクスポート
• サブ
• ダイアログ
• レポート
• パス
• パターン
• ヘッダ

などの名前が含まれているオブジェクトがビルド時に正しく復元されていませんでした。ただし、カタカナを含むすべてのオブジェクトが問題になっているわけではないのと、ひらがなと漢字の名称でも復元されていないものがあったところが悩ましいところです。

対応方法

さて、元の Access ファイルを復元できないとなるとせっかくのアドインを使うことができません。いろいろと試行錯誤した結果、少なくとも手元の環境の場合は、ソースからビルドしたアドインを使ったところ、問題なくビルドできるようになりました。このバージョン 5.0.1 だけの問題なのかなんなのか、真の原因は不明なのが気持ち悪いところですが・・・

具体的な手順としては Build the add-in from source （Editting and Contributing にあります）の手順に従って、次のようにしました。

1. zip からアドインをインストールします
2. git からリポジトリをクローンします
3. クローンしたリポジトリのルートに適当な Database1.accdb を作ります
4. Database1.accdb を開きます
5. Version Control メニューから Build from Source を選択します
6. ソースフォルダを選択するように求められるのでクローンしたリポジトリ配下の Version Control.accda.src を選択します
7. いま開いているファイルとソースフォルダのファイルが異なるため、下記のような警告が表示されますがそのまま OK を押します
8. 正常にビルドが完了し Version Control.accda が作成されます
9. 一度 Access を閉じます
10. 上記の作成された Version Control.accda を開きます
11. アドインのインストール画面が表示されます
12. 下記のように installed と表示されますが、そのまま『Install Add-in』ボタンをクリックして再インストールします（アンインストールは不要です）
13. インストールに成功した旨のメッセージが表示されます
14. Access を閉じます

これで、zip ファイルからインストールしたインストール済みのアドインが、ローカルでビルドしたものに入れ替わります。

次回から Access を開くとローカルでビルドしたアドインが呼ばれるようになり、このアドインを使うと上記の問題が出なくなります。

なお、Issue#741 にも上記の経緯を上げてます。

まとめ

これを使えば、大規模な Access のファイルもソースコード管理下におけそうです。これで少しは Access の仕事が楽になるかな？

VBA コードの管理方法について：vbac 編

仕事の関係上、 Excel や Access で VBA を使ってマクロを組むことがまだまだ絶えません。 VBA エディタが使いにくいとか、言語仕様がどうなん？って思うところもいろいろありますが、なんとか誤魔化してやってます。

とはいえ、この手の作業をやってる方は皆さん同意してくれると思うのですが、バージョン管理ができないことに結構悩まされるんですよね。巣のままだと git などのソースコード管理が使えないのはなかなか厳しいです。

まあ、世の中の立派な先人のおかげで、この不便さをある程度リカバーしてくれるツール ( vbac.wsf ) などもあります。Excelの場合はこれを使うことである程度対応していたのですが、 Access に対しては（自分のやってる範囲だと）うまく機能できていませんでした。

しかし、最近になって Access で使えるオープンソースのソースコード管理用のアドインがあることがわかったので、 vbac.wsf も含めて、いろいろとまとめておきたいと思います。まずは vbac についてです。

vbac.wsf

ariawase というライブラリに同梱されているツールです。なお、以前は作者と思われる方のブログ

http://igeta-diary.blogspot.com/2014/03/what-is-vbac.html

があり、ここで説明されていたのですが、閉鎖されてしまったようです（wayback machine で追いかけると 2021 年時点のものが残ってましたので、参考までリンクしておきます）。

インストール

インストールというほどのこともなく、 github の vbac.wsf を開いて、ファイルをダウンロードして、使いたいフォルダにおけば終わりです。

使い方

残念ながら上述したように公式のドキュメント（ブログ）が見えなくなってしまったので、覚えている範囲の簡単な使い方を書いておきます。例として、マクロ付きExcelファイル（.xlsm）を取り上げます（ Word でも Access でも基本的には同じです）。

なお、以下のように vbac.wsf について紹介している記事もいくつかあるので、気になる方はそれらも参考にしてみてください。

• vbacを使ってExcel VBAのソースコードを保守しやすくしよう #AdventCalendar - Qiita
• Excel VBAの開発環境に絶望したので2021年のモダンな環境を構築する | MoreCuriosity
• vbacでエクセルVBAのソースコードをGitバージョン管理する方法 | 隣IT

まず、vbac.wsf を使うにあたりフォルダ構成を次のようにします。

.
│  vbac.wsf
│
└─bin
        Book1.xlsm

vbac.wsf があるフォルダ（以下、プロジェクトルートと呼びます）の下に、 bin フォルダを作成します。そして bin フォルダ内にソースコード管理をしたい .xlsm ファイルを置いておきます。

あと、Excel を開いて、『オプション』->『トラストセンター』->『トラストセンターの設定』->『マクロの設定』から『VBA プロジェクト オブジェクト モデルへのアクセスを信頼する』にチェックをつけておきます。

（オプションの位置は、Officeのバージョンで若干変わるかもしれません）

分解（コードのエクスポート）

準備ができたら、プロジェクトルートに移動して、以下のコマンドを実行します。

PS D:\work\tmp\vbac_test\sample1> cscript.exe .\vbac.wsf decombine /vbaproj

こんな感じに出力がされて

Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

begin decombine

> Target: Book1.xlsm
- Export: App.vbaproj
- Export: ThisWorkbook.dcm
- Export: Sheet1.dcm
- Export: Module1.bas
- Export: UserForm1.frm
- Export: UserForm1.frx

end

完了後の状態を確認すると、

.
│  vbac.wsf
│
├─bin
│      Book1.xlsm
│
└─src
    └─Book1.xlsm
            App.vbaproj
            Module1.bas
            Sheet1.dcm
            ThisWorkbook.dcm
            UserForm1.frm
            UserForm1.frx

のように、プロジェクトルートの下に『src\ファイル名』のフォルダが作成され、この内部にマクロ付ファイル内の各モジュールがファイルとして出力されます。なお、出力されたファイルの拡張子は

• 標準モジュール： .bas
• クラスモジュール： .cls
• シート、ThisWorkbook： .dcm
• ユーザーフォーム： .frm（コード）, .fmx（バイナリデータ）

となっています。ファイル名が日本語を含んでいてもちゃんと動作しました。

また、上記の例の場合 /vbaproj オプションをつけています。このオプションをつけると VBA の開発環境の下記のメニュー当たりで設定する

プロジェクトプロパティや参照設定等の情報が App.vbaproj ファイルに出力されます。

合成（コードのインポート）

マクロ付ファイルを作成する場合は、プロジェクトルートにて、

PS D:\work\tmp\vbac_test\sample1> cscript.exe .\vbac.wsf combine /vbaproj

とするとこんな感じに出力がされて

Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

begin combine

> Target: Book1.xlsm
! Warning: can not 'VBProject.HelpContextID = "0"'. probably 64-bit Office have a bug.
- Import: App.vbaproj
- Import: Module1.bas
- Import: Sheet1.dcm
- Import: ThisWorkbook.dcm
- Import: UserForm1.frm
- Import: UserForm1.frx

end
PS D:\work\tmp\vbac_test\sample1>

『src\マクロ付ファイル名』フォルダにある各ファイルを元にして、binフォルダ内に、 .xlsm ファイルを再構成することができます。既存のファイルがあれば、コードが置き換わります。もし、ファイルがなければ、新規に作成されます。

ただし、この時、 Excel のシートそのものは復元されません。あくまでもコードが復元されるだけです。Sheet1.dcm などがあっても、シート本体の内容は復元されずコード部分のみが復元されます。なので、実用的には Excel ファイルそのものも git 管理下に置いておかないとなかなか厳しいものがあります。

なお、 64bit 版の Office の場合、上記の例のように合成時に警告メッセージが出ますが、特に問題はないようです。

Access の場合の制限

vbac 優秀ですね。Access の場合も同様にコードのテキストファイルへの分解と合成ができます。

しかし、Accessの場合、 Excel でシートが出力されないのに対応するようにテーブル定義が出力されません。あと、クエリも素の vbac.wsf のままだと出力されません。

テーブル定義のない Access だとコード部分だけ管理しても微妙だなと思います。一方、このテーブルに関する制約のため、 Access を管理しようとすると結局 Accessファイルごと git 管理下に入れる必要が生じます。ただ、残念ながら私の場合は対象としている Access ファイルの場合、かなりファイルサイズが大きいため、実際問題として git へ追加するのをためらってしまうというのもあります。

まあ、Excel でもシートへの変更を管理しないといけないので結局 git へ追加するのは同じなんですが、そこまでファイルサイズが大きくないため、 git 管理下に入れても実用上問題ないという感じです。

クエリの出力

ちなみに、上記で指摘したクエリについては vbac.wsf 内で無効にされている /incquery オプションを有効にするように修正をおこなえば使えるようです（修正方法は下記 1137 行目をコメントアウトします）。

ただ、こちらのオプションは実際に試していないので、自己責任でお願いします。

まとめ

ということで、 Excel の VBA については上記で紹介したように vbac.wsf で管理するようにしています。ですが、いままでは Access に関してはあきらめていました。

そんなときに見つけたのが、 msaccess-vcs-addin です。次はこのアドインについてまとめてみます。

Codex を使ってアプリを作ってみました

日常業務に追われて、なかなか AI エージェントを使ったコーディングというものに手が出せなかったのですが、多少まとまった時間が取れたのでどんな風に使えるのか試してみました。

作るもの

なにを作ろうか考えてみたのですが、今回は新規で Flutter のアプリを試しに作ってみます。

作ってみるのは、自分が飲んだコーヒーを記録していくアプリとします。

できたものはこんな感じです。

開発環境

さて、いざ AI エージェントを使ってコーディングしてみようと思ったら、どこから手を付けたらいいんでしょうか？

とりあえず、身近に使えるものを考えてみると、 Flutter の開発なら AndroidStudio か VisualStudioCode があります。一応調べてみると Google 的には Antigravity を押しているっぽいですが、とりあえずは手を出さないことにします。

コーディングエージェント（AI エージェント）はどうするのか？という点ですが、 ChatGPT の契約があるので取り急ぎ Codex なら追加の料金（契約）なしに試せそうなのでこれを使うことにします。となると、 VSCode には Codex を使うための拡張機能があるので、まずは VSCode + Codex拡張機能 で始めてみることにします。

Codex 拡張機能のインストール

さて、 VSCode を立ち上げてみると既に Flutter と Dart の拡張機能はインストール済みでした。Ctrl + Shift + P でコマンドパレットを開くと、

『Flutter: new Project』があるので、これを選択して必要事項を入力して、新規プロジェクトを立ち上げます。起動後、デバッグ実行ができるところまで確認しておきます。

次に拡張機能タブを開いて、codexで検索すると Codex 拡張機能が見つかります。

早速、これをインストールしておきます。

設定

正しい手順は覚えてないのですが、適当なファイルを開くと OpenAI のロゴのアイコンがでてきたので、これをクリックすると codex 用のサイドバーが開いたと思います。

ここの『ChatGPT を使用してサインイン』を押すとブラウザで認証用の画面が表示されるので、ログイン情報を入力すれば OK です。

AGENTS.md

さて、コーディングエージェントを使う場合、このように開発してほしいというルールをまとめて書いておくという話があるようです。で、いくつかサンプルを見たのですが、なかなかこれを作るのも面倒そうです。

というわけで、 ChatGPT を使って『一般的な flutter アプリの開発に使える agents.md を日本語で示してください』とお願いして AGENTS.md を作らせてみました。出来上がったものをみると対象となるプラットフォームに関する記述が、

2. プロジェクト概要

このリポジトリは、FlutterおよびDartで開発するモバイルアプリケーションです。

主な対象プラットフォームは次のとおりです。

* Android
* iOS

必要に応じて、次のプラットフォームも対象にする可能性があります。

* Web
* Windows
* macOS
* Linux

作業を始める前に、必ず `pubspec.yaml`、`analysis_options.yaml`、`lib`、`test` および対象機能に関係するファイルを確認してください。

プロジェクト内に既存の設計方針、ディレクトリ構成、命名規則、状態管理方法がある場合は、それらを優先してください。

となっていたので、この部分を

## 2. プロジェクト概要

このリポジトリは、FlutterおよびDartで開発するモバイルアプリケーションです。

対象プラットフォームは次のとおりです。

* Android
* iOS

指示がない限りその他のプラットフォームは含みません。

作業を始める前に、必ず `pubspec.yaml`、`analysis_options.yaml`、`lib`、`test` および対象機能に関係するファイルを確認してください。

プロジェクト内に既存の設計方針、ディレクトリ構成、命名規則、状態管理方法がある場合は、それらを優先してください。

とだけ修正して、スタートすることにしました。あとは、必要に応じておいおい手直ししていくことにしました。

コーディング作業

今回は原則としてコーディング作業はすべてAIエージェントに任せたいと思います。 なので、自分自身でやる作業としては、

• 作成したいものについての指示
• 修正指示

を出していくという形になります。また、 AI エージェントによる作業でコードの変更が行われることから、変更点が明確になるように git を使うのは必須ですね。

さて、実際に作業していきます。『CODEX』の名前のウィンドウを開いて、ここに指示を入力していきます。

こんな感じでプロジェクトの状態についての報告を求めると、チャットの形式で返答してくれます。

毎度おなじみの flutter のサンプルアプリにリセットボタンをつけるように指示すれば、

のように実際にコードの修正も行ってくれます。

また、 codex の場合は入力画面で /plan と入れれば実際の変更は行わずに作業の計画だけ示してくれます。なので、これを利用して何度か指示を重ねて、良さそうな実装用の計画がまとまったら、『実装してください』と伝えてコードに変更を加えていくこともできます。修正したものに対して動作確認を行って、問題がなさそうならコミットします。

これを何度か繰り返して、形作っていきました。

注意点

一点だけ注意点があります。現状、 Codex の権限として外部ファイルの修正を行う場合には承認を求めるようにしています。

Windows 上の flutter / dart の場合、ロックファイルを SDK フォルダ内の cache フォルダに作ります。このため、使い始めた際は操作のたびに承認を求めてきていたのですが、ある日を境に承認を求めずに、タイムアウトするようになってしまいました（理由はわかりません）。

このため、 AGENTS.md に

なお、 dart/flutter のコマンド実行時に SDK の cache 領域への書き込みの権限が必要になる場合があります。必要に応じて承認を求めてから実行してください。

の一文を追加して、承認を求めるようにしました。

結果

拡張機能インストールから始めましたが、わずか数日で動くものができました。アイデアさえあればすぐに形にできるのはすごいですね。

今回は実際に Google Play や AppStore でリリースはしませんでしたが、この作業も多分簡単にできるんだろうな、と予想しています。

感じたこと

さて、AI エージェント を使ってアプリの作成（コーディング）をしてみて、感じたことをつらつらと書いておきます。

コードは思っていた以上にちゃんと書けてるっぽい

作成されたコードですが、最初のうちこそどんな書き方になっているのかと思って確認していましたが、思ってた以上にちゃんと書けている印象でした。それに、内容を把握するのに時間がかかってしまうため、何度か繰り返すうちにコードを直接見ることもなくなってしまいました。慣れですね。

もっとも、今回作ったものはアプリ単体で動作するものだったので、大きな齟齬もなかったのだろうと思います。仮にこれをリリースしようとなると、データを外部のクラウド等に保存して・・・など、外部システムとの連携などが入るようになるとひょっとしたらそのあたりは人が面倒見てあげないといけないかもしれません（まあ、それも時間の問題で簡単にできるようになると思いますけどね）。

そう考えると、プログラマとして直接コードを触る必要は少なくなるんだろうな、きっと。で、メインの仕事は、設計や仕様の確認などに移っていくんでしょうね。

設計と一口に言っても、単独のシステム（この場合、単一の実行ファイルからなるものを指してます）内の設計というよりも、ある種のシステム間連携のような部分の比重が大きくなるように思えます。どのシステムを利用して、どれと組み合わせるのか・・・って感じでしょうか。

単独のシステム内の設計に関して人手でやることとしては、セキュリティ絡みや効率化（採用するアルゴリズムの選定）などの非機能要件だったかな？これらに関するセンシティブな領域に関するものだけが残っていきそうに思われますね。あ、あとは UX 絡みのものですかね。まあ、正解パターンのようなものができていると AI でもカバーできそうですが。

後者の仕様の確認はテストですね。テストそのものはまず AI に書かせるとしても、このテストがきちんと書かれているかを人手で確認する必要がきっと残るでしょうね。TDD も流行ってくるかもしれませんね。

コミット単位が大きくなりがち

ある程度のまとまりで指示を出すためなのか、自分でコードを書いて・コミットして、という作業を行っている時よりも、コミット単位が大きくなりがちな印象でした。このあたりは指示の出し方の工夫次第で調整はできそうですが、冒頭に書いたようにコードを直接触る必要が薄れてくると、このあたりのコミット単位の考え方も変わってくるかもしれません。

作業指示の残し方

最初使い始めたときは、コーディングエージェントへの指示自体が残らないのがちょっと気になりました。

でも、よくよく考えると、これってエージェントの問題ではなく、いままでの開発作業でもコード書く前に考えていたことや相談したことは、設計書とか検討メモとして残さない限り、どこにも記録が残らないのと一緒だな、ということに気がつきました。 なので、必要に応じて、コミットログやメモに書いていけばいいだけと割り切ると、当初感じた気持ち悪さもなくなりました。

このあたりについてのルールというか標準的なやり方があるのかな？折をみて調べてみようと思います。

簡単につくれるがどう活かすか

あと、今回サンプルでアプリを作ってみましたが、（現時点では）リリースしませんでした。というのも、リリースすると継続的にメンテナンスをしていく必要が生じるためです（Google Play だと定期的に最新の Android に対応させる必要があります）。

個人的には、日常の業務に加えてアプリのメンテナンスを継続的に行うためには、お金か情熱かまたは別のなにかか・・・何かしらの動機がいると思ってます。コーヒーは飲みたいですが、マメに記録とかを取るタイプではないので、作っといてなんですがたぶんこの手のアプリは使わないので、今回はお試しで終わらせました。

以前ならここまで作るのに長い時間もかかったでしょうから、何が何でもリリースした（or そもそも手を出さなかった）と思うのですが、これだけ簡単につくれるとなると却って慎重に考えてしまいます。

このあたりの AI のコーディング力をどう活かすのか？というのは個々人（や組織）の思想によることになりそうですね。

まとめ

わずか数日で、パッとおもいついたアイデアが形になりました。『聞きしに勝る』とはまさにこれですね。さて、せっかく新しい道具が使えるようになったので、次は既存の仕事にもうまく活用して取り入れたいところです。