ども。
「あの続きを楽しみにしている」と数人から言われている担当ちゅんです。

本日は、その「あの続き」です。まずは前回のあらすじから。
　・消防本部で利用してきたHTAアプリが実質的な寿命を迎えた
　・生成AIに相談したらアプリ化（Electron）を提案された
　・ノースキルの自分でも、生成AIを使えばアプリを作れるのか興味がわいた

生成AIの指示どおりに、まずは環境構築。ElectronとNode.js、さらにはVSCodeをインストールせよとのこと。あっさりと環境ができあがり、しばし眺めます。こちらは一介の公務員事務職ですから、まったく馴染みのない画面周り。しかし、VSCodeに関しては「なぜ今まで使っていなかったのか」と思うほどの便利さに驚愕。なにせ、これまでHTMLやCSSはWindows付属の「メモ帳」を使ってきた人間です。この段階ですっかり気をよくして、次の瞬間には生成AIに「次の手順を教えてほしい」と聞いていました。

ずらずらとコードが出力され、それをこちらはせっせとコピー。ある程度、アプリが動くベースが出来上がったら、これまでHTAとして運用してきたメインのコードを投入。画面上にはいつも見慣れたアプリがあっさりと立ち上がってきて、どうやら大きな躓きはなく作業は進行している様子です。
ここまで来たら、本番で使うかどうかは別として、最後まで仕上げてみたい気持ちになりました。次に生成AIに指示をしたのは、「これまでメールの送信部分はVB6で作られた仕組みだったのですが、これも今風に置き換えたい」。すると、その回答としては「nodemailerというモジュールを組み込むことが一般的」とのこと。これについても指示どおりに対応していると、あっさり動作してしまいました。

しかし、このあたりで急にかなりの恐怖を覚え始めました。今回はあえて「実験」としてやってみていますが、プログラミングの知識がない者が生成AIから出力されたコードのみをコピペで仕上げていくことは、情報セキュリティ上の重大なリスクをはらむこと。また、本来は商用利用が禁止されているコードが含まれていたら、意図せず著作権法違反を犯す可能性があること。なにより、今後トラブルがあっても自力では解決することが不可能なこと。個人的に実験してみている範疇であれば許されることも、これを「実際の業務に投入できるか」と問われれば、かなり大きなクエスチョンが付くなと。よって、今回の実験はここまでとしました。

ですが、目の前には実行ファイル形式（.exe）になった「新・一斉メール配信システム」がもたらされました。私がテストした限り、動作は完璧。心の隅に「もったいないな」という気持ちが湧いてくるのも事実です。プログラミングの知識のある方に一度見てもらって、「問題ない」というジャッジが下ったら、その時は現場に投入してみたいと思います。
今回の実験で得られた教訓としては「生成AIがプログラマーの仕事を奪うというのは本当かもしれない」ということ。ズブの素人でも、出力されたコードをコピペするだけでexeファイルが作れる時代になっているという事実に、改めて色々と考えさせられた体験でした。

まだHTAは動きますので、その間にこのアプリを投入できるよう準備を進めます。

（投稿者：ちゅん）

てんちょです。ちゅん氏が出張のため連投です。ブログのネタに困っていたところちょうどいい？トラブルに遭遇。

先日、ある施設から「複合機のスキャナフォルダにアクセスできなくなった」という連絡がありました。役場内の各課のスキャナフォルダは以前Boxへ完全移行していましたが、この施設に関しては諸事情があって、複合機の内蔵メモリ領域へ直接端末からアクセスする従来の運用をそのまま残していました。
さっそくリモートで確認してみると、なぜか「資格情報マネージャー」が立ち上がり、ユーザー名とパスワードを求められる状態になっています。もともとそんな設定はしていなかったはずなのに…。

こうなったらBoxへ移行してしまおうと思い、ブラウザの管理画面からBoxへの宛先を設定して登録してみました。翌朝、説明を兼ねて電話をして複合機を操作してもらいましたが、設定したはずの宛先が出てきていないと…。再度ブラウザから確認してみましたが、設定上は問題なく見えます。このメーカーの複合機、うちの庁内だとここにしか設置されていないレア機種ということもあり、画面越しではこれ以上ピンときません。

他に気になっていたこともあったので、現地に行くことにしました。

到着後、複合機本体を直接操作してアドレス帳にBoxの宛先を登録。今度は画面にしっかり表示されました。しかし、いざテスト送信してみると、入力したアカウントが弾かれてしまい、何をやっても送信エラー。
これはもう元の内蔵メモリ領域に端末からアクセスさせるほうが早そうだと判断し、今度は資格情報マネージャーが出てくる原因を探ることにしました。

端末側の入力画面をよーく観察してみると、下の方に小さく「非認証のゲストアクセスがブロックされているため」という見慣れない一文が表示されていることに気が付きました。
内蔵メモリへのアクセスにSMBが使われていることは先ほどの試行錯誤で分かっていたので、スマホで調べてみると、案の定同じようなサポートページが山ほどヒット。24H2が原因だったようです。ポリシー設定を変更してみたところ、すぐにこれまでどおりアクセスできるようになりました。

最近この資格情報マネージャーが様々な場面で出現していて困ってます。

（投稿者：てんちょ）

てんちょです。色々やりたいことがあるのになかなか手付かず。

先日、無慈悲にもクレジットの全消費により動かなくなってしまったスキャンファイルの自動リネームフロー。
月が替わってクレジットが回復するまでの間、代替手段を検討しました。当初は「AIを使わず、通常のOCR機能だけでリネームさせる方法」も検討しましたが、現場の雑多な書類を文字データだけで正確に分類・リネームさせるのは、どう考えても困難です。

「クラウドのAIが駄目なら、いっそ自前の環境にローカルLLMを構築してしまえばいいのでは？」

そんな突然の思い付きに突き動かされ、新たな実験を始めてみることにしました。調べてみると、最近は個人でも驚くほど簡単にローカル環境へLLMをセットアップできることが分かりました。

問題は動かすためのハードウェアです。テスト機にいい端末はないかと周辺を見渡してみると、自席の後ろに転がっていた小型のデスクトップPCを発見。CPUはCore i3-7100T、初期メモリはわずか8GBという、ちょっと物足りないスペック。これではさすがに心もとなかったので、これまた机の上に落ちていた（？）8GBのメモリを勝手に増設し、合計16GBの環境を急造しました。

OSと必要なドライバーをクリーンインストールし、満を持してセットアップ。まずはネットワークを介さず、完全にローカル環境だけで完結する「プロンプト入りの自動化スクリプト」を作成し、テスト用のPDFを読み込ませて実行しました。

結果は…リネームが完了するまでに、なんと約5分。

その間、小型PCのファンはこれまでに聞いたことがないほどの爆音で回り続け、タスクマネージャーのCPU使用率は見事なまでに100%に張り付いたままでした。
たった1つのPDFを処理させるだけで、端末が文字通り命を削るような大負荷。やはり8年落ちの省電力オフィスPCに、生身のAIを背負わせるのにはこれが限界のようです。

現在のPower Automateの利用状況をログで見ていると、現場の職員たちはかなりの頻度でスキャナを利用しています。1件につき5分の待ち時間が発生してしまうので実運用には耐えられそうにないですね。

ローカルLLMを実用レベルで動かすには、強力なGPUや最新のハードウェア性能が絶対に不可欠であることは、知識としては分かっていました。
しかし、「理屈はともかく、自分の手でちょっとやってみたかった」というのが本音です。結果としては実用化見送りとなりましたが、自席のジャンクパーツからAIサーバーが立ち上がる瞬間を見られただけでも、面白い実験でした。

こんな環境で動くほど甘くはないですよね。

（投稿者：てんちょ）

ども。
仕事でPCを触りすぎて、自宅PCの保守がおざなりになっている担当ちゅんです。

消防本部で利用している「電子メールの一斉配信システム」があります。地図上から地点を選択すると、自動的に文章が作成され、登録アドレス宛にメールを送信できるシステムです。これは「HTA（HTML Application）」という仕組みを使い、Windows用のデスクトップアプリとして我々が一から作ったもの。機能追加のリクエストが来るたびに、保守を行いながら大切に育ててきました。

このたび、そのシステムに対して「こういう機能を追加できないか」「ここを修正したい」とリクエストがあったので、修正に着手。HTAは結局のところHTMLとCSSによるウェブサイトと同じ原理で動いているので、Windowsのメモ帳を使ってコードを書き足すだけ。所定の修正を完了し、現場に新バージョンのアプリを配布、あっさり業務完了。
・・・なのですが。今回作業をしていてふと「HTAっていつまで動くのかな」と心配になりました。

調べてみると、HTAは「いつ使えなくなってもおかしくない、実質的な寿命を迎えている技術」だと。予想はしていましたが、やっぱり・・・。理由はいくつかあるのですが、「レンダリングエンジンがInternet Explorer（IE）のまま」という一文を見ただけで、「あ、これはダメだ」となりました。
かといって、HTAに代わる新しい手法を見つけてシステムを刷新するなんて、私のスキルでは到底無理。どうしたものだろうかと考えていて、ふと、同僚の「てんちょ」が最近、生成AIに手伝ってもらいながら自作のPDF編集ツールを作っていたことを思い出しました。「すごいなー、自分には無理だなー」と他人事のように眺めていたのですが、心の隅には「もしかして俺にもできるのかな」という思いもあり。

ひとまず、聞くだけならタダです。生成AIに「こういうアプリを運用している。自分ができるのはHTML、CSS、ちょっとだけJavaScript。何か代替手段はある？」と相談してみました。すると、生成AI特有のあのポジティブなノリで「もちろんです！そんなあなたにはElectronとNode.jsによるアプリ化がおすすめです！しっかり最後までサポートするので、一緒にやってみませんか？HTAを作れたあなたなら、きっとできます！」と。なるほど・・・。きっとできる、と。ならば、ちょっとだけ、ほんのさわりのとこだけやってみて、雰囲気だけでも見てみるかという気分になってきました。

さて、かなりの長文になりました。この話は前後編、いや、三話構成くらいでお届けすることになると思います。マニアックな内容が続きますが、次回もお付き合いいただければ幸いです！

これはこれで気に入っていたけど、使えなくなっては困りますからね。

（投稿者：ちゅん）

てんちょです。気温の変動についていけず今日は暑さにやられております。

先日、Power AutomateのAI機能（AI Builder）を使って作成した「スキャンファイルの自動リネーム」。運用開始から現場ではかなり好評で、利用を希望する部署も順調に増えていました。しかし、実は作成した当初から、頭の片隅でずっと気になっていたことがありました。

「この便利なAI機能、無制限に使えるわけじゃないよな…？」

その嫌な予感の答えは、ある日突然、何の前触れもなく突きつけられることになります。『この環境の Copilot クレジットと AI Builder クレジットはすべて消費されました。』画面に表示された、あまりにも非情な警告メールが着弾。「やっぱりそうか」と思いつつ調べてみると、AI Builderはやはり完全な「クレジット制」でした。

八雲町（組織全体）で所有している既存のライセンス上、この環境に割り当てられていたのは、「6,500クレジット」。これまではリネーム以外でこのAI機能を使っていなかったため、完全に油断していました。そもそも「1回の実行でどの程度クレジットが消費されるのか」という検証すらしていなかったのです。 加えて、写真から中身を推測させるような重たいプロンプトのテストを、自分が裏で回しすぎたことも確実に響いたのでしょう。AI Builderのクレジットは月単位でカウントされ、毎月1日にリセットされる仕様です。つまり、開始から2週間経たずに上限を突破してしまった私の自動リネームフローは、「来月1日まで強制停止」。 「便利だ！」と喜んで使い始めてくれた現場の職員には、本当に申し訳ない限りです…。

「上限があるなら、それに応じた代替方法を考えておかなければならない」のではということでちょっと考えてみました。例えば、クレジット消費の激しい「AIによる文脈の読み取り（プロンプト抽出）」は諦めて、標準の「OCR（テキスト認識）」アクションだけで文字データだけを引っこ抜く方法。そこから特定の規則性(〇〇株式会社とか）をVBAやPower Automateの通常の関数で処理すれば、リネームの精度は落ちるかもしれませんが、クレジットをほぼ消費せずに運用を維持できるはず。

6,500クレジットでどの程度の処理ができるのか、原因が私がテストで使い過ぎたからなのか、いろいろわからないこともあるので、ひとまず対策も考えつつ、クレジットが復活してからの動きを見ながら今後の運用について考えていこうと思います。

まぁ無制限なわけないですよね。

（投稿者：てんちょ）