MENU
  1. ホーム
  2. 未分類
  3. 【開発効率】AutoCADコアコンソールでプラグイン開発を回す

【開発効率】AutoCADコアコンソールでプラグイン開発を回す

未分類
【開発効率】AutoCADコアコンソールでプラグイン開発を回す

こんにちは。土木設計歴30年、AI土木研究室です。

最近、業務で使う自作のAutoCADプラグイン（.NETで書いたDLL）を開発しています。コードを書くのはAIに任せる時間が増えましたが、そうなると今度は別のところが詰まります。書かせたコードが正しく動くかを確認する工程です。

従来はここで毎回AutoCADを起動し、DLLを読み込み、コマンドを打って画面を見ていました。1回数分。これが試行のたびに発生します。

今回、この確認工程にAutoCADの「コアコンソール」を使ってみました。結論から言うと、全部が自動になったわけではありません。人が画面を見て判断すべき部分は今も残っています。ただ、機械に任せられる範囲が広がり、そのぶん試行回数を増やせるようになりました。この記事は、その線引きがどこにあったかという実体験の記録です。

目次

従来の開発サイクル｜確認のたびにCADを起動していた

まず、これまでどう回していたかを書きます。

  1. AIにコードを書かせる／直させる
  2. ビルドしてDLLを作る
  3. 自分でAutoCADを起動する
  4. DLLを読み込む
  5. コマンドを打って手で動作を確認する
  6. 不具合があれば1に戻る

問題は3〜5です。ここが毎回発生し、労力の大半を持っていかれていました。AutoCADの起動だけでも待たされますし、確認したいのは「線が1本正しい位置に引けているか」だけでも、そこに至るまでの手数がかかります。

そして、これには目に見えにくい副作用がありました。1回の確認が高くつくと、試行回数が自然と絞られるのです。「まあ動いているから、これでいいか」で止めてしまう。実装が粗いまま残る。設計の成果品づくりで言えば、照査に手間がかかるほど照査が甘くなるのと同じ構図です。

つまりここで削りたかったのは、単なる作業時間ではありませんでした。確認のコストそのものです。

AutoCADコアコンソール（accoreconsole.exe）とは

AutoCADには、画面（GUI）を持たないコマンドラインだけの実行ファイルが同梱されています。accoreconsole.exe、通称コアコンソールです。AutoCAD 2013で追加されたもので、AutoCADのインストールフォルダーの中にあります。

AutoCADの機能は、GUIの部分と、図面データを扱う中核部分（Windowsでは AcCore.dll）に分かれています。コアコンソールは、この中核部分だけをコマンドプロンプトから動かすための小さな入り口です。描画ウィンドウを表示しないぶん、起動が速く、バッチ処理に向いています。

基本の使い方

コアコンソールは、処理対象の図面（DWG）とスクリプトファイル（.scr）を指定して起動します。

accoreconsole.exe /i "C:\work\test.dwg" /s "C:\work\test.scr" /l en-US

主なコマンドラインスイッチは次のとおりです。

  • /i：スクリプトを実行する対象の図面ファイルのパス
  • /s：スクリプトファイル（.scr）のパス
  • /l：言語パックが入っている場合に、どの言語版で起動するかの指定
  • /isolate：システム変数の変更が通常のAutoCADに影響しないように隔離する

スクリプトファイル（.scr）は、コマンドプロンプトに打つ内容を上から順に並べただけのテキストファイルです。特別な文法はありません。ただし空行がEnterキーとして解釈されるため、余計な空行や行末の空白が入ると、コマンドの応答がずれて処理が止まります。ここは最初につまずきやすいところです。

自作の.NETコマンドを呼ぶ場合は、スクリプトの先頭でDLLを読み込んでから、自分のコマンド名を書きます。

NETLOAD
"C:\work\MyPlugin.dll"
MYCOMMAND

なお、コアコンソールはAutodeskが正式にドキュメント化・サポートしている機能ではありません。Autodeskの開発者ブログにも「このユーティリティの使用はAutodeskの公式サポート対象ではない」と明記されています。業務の本番フローに組み込む前に、お使いのバージョンで想定どおり動くかを必ず確認してください。

コアコンソールで確認できること・できないこと

ここがこの記事の中心です。導入して最初にやるべきなのは、機能を覚えることではなく境界線を引くことでした。

確認できるもの

  • 図形の作成・変更（線や図形が意図した位置・形で作られているか）
  • 計算結果（数量や座標などの計算が合っているか）
  • 保存された属性（図面に書き込んだ属性値やデータが正しく保持されているか）

要するに、「図面データがどうなったか」で判定できるものは、ほぼコアコンソールで確認できます。土木設計の自作ツールは数量計算や図形の自動生成が中心になりがちなので、この範囲だけでもかなりの割合を占めます。

確認できないもの

  • リボンの見え方、ダイアログの配置
  • 実際のマウス操作、図面上の選択やドラッグ
  • Jigの追従表示（カーソルに合わせて図形がリアルタイムに動く表示）

コアコンソールにはそもそも画面がありません。ダイアログやファイル選択ボックスを必要とする処理は動きません。つまり「人が画面を見て、触って、操作感を確かめる」部分は最後まで残ります。ここを自動化できたと考えるのは間違いです。

コードの書き方に制約が出る点

もう1つ、開発側で知っておくべき制約があります。コアコンソールに読み込める.NETのDLLは、GUI側のライブラリ（acmgd.dll）ではなく、コア側のライブラリ（accoremgd.dll）を参照してビルドされている必要があります。図面データを扱う acdbmgd.dll はどちらでも共通です。

これは制約であると同時に、設計の指針にもなります。処理の本体（計算・図形操作）はコア側だけで完結するように書き、GUIはその薄い上まわりに置く。こう分けておけば、本体は機械で検証でき、GUIは通常のAutoCADで動かせます。土木の設計で「計算部分」と「表現部分」を分けて管理するのと同じ発想です。

図面側の自動化を初めて触る方は、まずAutoLISPで土木設計を自動化する方法から入るほうが敷居は低いと思います。コアコンソール＋.NETは、その先の話です。

今回どこまで確認したか｜プログラムで検証できた範囲

実績と一般論を混ぜないために、今回の検証で実際にやったことだけを書きます。

確認したのは次の2つです。

  1. コアコンソールでの処理結果（図形・計算値・保存された属性）
  2. プログラムによるデータ・イベントの検証

2つ目は少し補足が要ります。GUI部分を完全にあきらめるのではなく、WPFで作ったダイアログをテストコードから生成し、コピー・貼り付けやダブルクリックに相当するイベントを実行して、内部の状態が期待どおりに変わるかを確かめるところまではやりました。画面を出さずに、画面の裏側のロジックだけを叩いたわけです。

ただし、はっきり書いておきます。これは「人が画面上で操作できること」まで確認した実機テストではありません。イベントが発火して内部状態が変わることと、実際にマウスでその操作ができて、意図した表示になることは別の話です。ここを混同すると、通ったテストを根拠に「動く」と言ってしまうことになります。

なお、画面を見て結果を判断させる仕組み（画面操作を機械に実行させて表示を確認する類のもの）は、今回の開発では使っていません。実績としては書けません。

「エラーが出ないだけ」ではOKと判定できない

これは今回いちばん強く感じたことなので、一節を割きます。

自動テストの落とし穴は、「コマンドラインにエラーが出なかった」を合格と読み替えてしまうことです。処理は最後まで走った。例外も出ていない。しかし出来上がったものが実務で使えるかは、まったく別の問題です。

たとえば、こういう項目はエラーの有無では判定できません。

  • エラー一覧をダブルクリックしたとき、該当するスパンがきちんと選択されるか
  • ステップ（段差）を貼り付けたあとも、管径が表示されたまま残っているか
  • 図面に描かれた矢印が、意図した開矢印になっているか

どれも「実際に操作して、期待した表示と結果になっているか」でしか判定できません。処理は成功しているのに、結果が設計者の意図とずれている——設計照査で拾うべきものと、性質は同じです。設計照査のチェックリストを作るときの考え方がそのまま当てはまります。

そこで、この記事の見通しとして書いておきたい分担があります。全ケースを機械に回させるのではなく、人が「ここが怪しい」と勘所を押さえ、その一点だけを機械に見に行かせるという形です。常時回す自動テストではなく、気になったところを指定して確認させる使い方。30年やっていると、変更を入れたときに「ここが崩れそうだ」という当たりはつきます。その当たりをつける部分こそ人がやるべきで、確認しに行く手間のほうを機械に渡す——これが自然な分担だと考えています。

DLLの更新はスクリプトで｜バックアップ→コピー→ハッシュ照合→ロールバック

もう1つ、地味ですが効いたのがDLLの入れ替えです。

AutoCADには、プラグインを所定のフォルダーに置いておけば起動時に自動で読み込む仕組み（オートローダー）があります。.bundle という拡張子のフォルダーを作り、その直下に PackageContents.xml という定義ファイルを置く形式です。置き場所はAutodeskのドキュメントで次の3か所が示されています。

  • %PROGRAMFILES%\Autodesk\ApplicationPlugins（全体のインストール先）
  • %ALLUSERSPROFILE%\Autodesk\ApplicationPlugins（全ユーザー）
  • %APPDATA%\Autodesk\ApplicationPlugins（ユーザーごと）

今回は3つ目のユーザーごとのフォルダーを使っています。PackageContents.xml には RuntimeRequirements という要素があり、対応するAutoCADのバージョン範囲（SeriesMin／SeriesMax）と読み込むDLLを定義できます。ここを書いておくことで、AutoCADのバージョンに応じて適切なDLLが次回起動時に読み込まれます。

ここで大事なのは、「ビルドすれば自動で配布される仕組み」ではないという点です。あくまでビルドしたあとに更新スクリプト（PowerShell）を実行する方式です。手順は次のとおりです。

  1. AutoCADが終了していることを確認する（起動中はDLLがロックされて置き換えられません）
  2. 既存のDLLをバックアップする
  3. ユーザーの ApplicationPlugins 内にある .bundle フォルダーへ、新しいDLLをコピーする
  4. コピー元とコピー先のハッシュを比較して一致を確認する。失敗していれば元に戻す（ロールバック）

やっていることは単純ですが、この4段構えが効きます。バックアップを取り、置き換え、照合し、駄目なら戻す。成果品を扱うときの手順そのものです。図面や計算書を差し替えるときに、旧版を残し、差し替え、内容を照合し、おかしければ戻す——それと同じ形をプログラムの更新にも当てはめただけです。

ハッシュ照合を入れているのは、コピーが「成功した」と報告されても中身が古いままだった、という事故を防ぐためです。「成功しました」という報告を信用せず、成果物そのものを突き合わせる。これも設計の現場で身についた習慣がそのまま役に立った部分です。

置き場所についての注意

Autodeskのドキュメントでは、プラグインは %PROGRAMFILES%\Autodesk\ApplicationPlugins に置くことが推奨されています。この場所は信頼された場所として扱われ、デジタル署名の確認が行われないためです。それ以外のフォルダーに置く場合は、アプリケーション側で信頼された場所として設定し、デジタル署名を付けることが推奨されています。社内配布まで考えるなら、ここは早めに方針を決めておいたほうがよい部分です。

何が変わったか｜労力より「質」

効果は2つに分けて書きます。

1. 労力が減った

確認のたびにAutoCADを起動して手で動かす工程が減りました。図形と計算値の確認は、コマンド1行で済みます。これは分かりやすい効果です。

2. プログラムの質が上がった

こちらのほうが本質だと思っています。

確認が安くなると、試行回数を増やせるようになります。「もう1パターン試してみるか」の心理的ハードルが下がる。すると、「とりあえず動いたから良しとする」で止まらなくなります。粗い実装が残らない。書き直しに躊躇しなくなる。

逆に言えば、確認が高いままAIにコードを書かせても、生産性はそれほど上がりません。書く速さが10倍になっても、確認が10倍にならなければ、確認が律速になるだけです。AIに書かせる前提が整いつつある今、効いてくるのは「確認をどれだけ安くできるか」のほうです。

これはツールを自作している人だけの話ではありません。AIに作業をさせるすべての場面に当てはまります。AIプロンプトの活用法を工夫して出力の精度を上げるのも大事ですが、それと同じくらい、出てきたものを安く確認できる仕組みを持っているかが結果を分けます。

まとめ｜自動化の価値は時間短縮ではなく品質

今回の内容を整理します。

  • コアコンソール（accoreconsole.exe）は、AutoCADに同梱されている画面なしのコマンドライン版。/i で図面、/s でスクリプトを指定して実行する
  • 確認できるもの：図形の作成・変更、計算結果、保存された属性
  • 確認できないもの：リボンやダイアログの見え方、実際のマウス操作、Jigの追従表示
  • コードの分け方：処理の本体はコア側（accoremgd.dll参照）だけで完結させ、GUIは薄い上まわりに置く
  • 今回やったのは2つ：コアコンソールでの処理結果の確認と、プログラムによるデータ・イベントの検証。人が画面上で操作できることまで確認した実機テストではない
  • 「エラーが出ないだけ」では合格にできない。操作して期待した表示になるかは別の話
  • DLL更新は手順を決める：AutoCAD終了の確認 → バックアップ → .bundle へコピー → ハッシュ照合 → 失敗時ロールバック
  • 置き場所は要検討：ユーザーごとのフォルダーは手軽だが、Autodeskは PROGRAM FILES 配下を推奨。それ以外は信頼設定と署名が推奨される

最後に、いちばん書きたかったことを繰り返します。

この取り組みで「人の手が要らなくなった」わけではありません。画面を見て判断する部分は残っていますし、そこを機械に渡す検証は今回やっていません。機械に任せられる範囲が広がり、そのぶん試行回数を増やせるようになった——実態はそこまでです。

それでも、この効果は小さくないと思っています。自動化の本当の価値は、時間が短くなることではなく、確認が安くなった結果として品質が上がることです。設計の仕事も同じで、照査が楽になれば照査の回数が増え、成果品の質が上がります。順番はいつもこちらです。

自作ツールをお持ちの方は、まず「自分の確認作業のうち、図面データを見れば判定できるものはどれか」を書き出してみてください。そこが機械に渡せる範囲です。

出典

※記載した動作・パス・スイッチはAutoCADのバージョンによって異なる場合があります。実行前にお使いのバージョンでご確認ください。

著者：AI土木研究室 / 土木設計歴30年。建設コンサルタントとしてインフラ整備に携わりながら、AI・自動化ツールの研究開発を行う。AI土木研究室（doboku-ai.jp）運営。

未分類
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

ai_dobokuのアバター ai_doboku

関連記事

コメント

コメントする

目次