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

先日、無慈悲にもクレジットの全消費により動かなくなってしまったスキャンファイルの自動リネームフロー。
月が替わってクレジットが回復するまでの間、代替手段を検討しました。当初は「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クレジットでどの程度の処理ができるのか、原因が私がテストで使い過ぎたからなのか、いろいろわからないこともあるので、ひとまず対策も考えつつ、クレジットが復活してからの動きを見ながら今後の運用について考えていこうと思います。

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

（投稿者：てんちょ）

ども。
疲労が蓄積している感じがするので、週末は無になろうと思っている担当ちゅんです。

本日は久しぶりにサーバ室での業務。サーバが1台追加となり、それをラックに収める作業のお手伝いです。
それにしても、いまどきのサーバ（というか結構前からですが）は、とにかく設置が楽でびっくりします。サーバラックに設置するときは、まずはレールの取り付けを行うのですが、今のレールってネジを一切使わない構造なんです。ラックの穴にレールを嵌め込み、前後で「カチッ」と固定して終わり。サーバ本体もレールの溝にピンを合わせてスライドさせるだけ。すべてのメーカーがこの仕組みではないと思いますが、本当に便利になったな～としみじみ。

ところが。感心して作業を眺めていたのですが、どうも雲行きが怪しい。作業していた業者さんに「どうかしたんですか？」と聞いてみると、「レールがラックからはみ出して収まらない」と。「もしかして、サーバに適合しないレールを調達してしまったんじゃ・・・」と、現場は一気に困惑モード。念のため私もサーバとレールの型番を調べ、生成AIに「これ、合いますか？」と聞いてみましたが、AIは「問題ない」との返答。ですが、目の前で物理的に収まりきっていないサーバがあるのも事実。さて、どうしたものでしょう。

私と業者さんは「仕方がない、今日はレールにつけずに仮置きですね・・・」とすっかり諦めムードだったのですが、こういう時に粘り強いのが「てんちょ」です。しげしげとレールを眺めながら、「構造的に、もっと奥に行くはずだ」と言い始めます。確かに、レール単体を見ると想定した場所よりも一段階奥まで押し込めるクリアランスがあるように見えます。最初は「いやいや、そんなわけないでしょ」という雰囲気だった業者さんも、「・・・ちょっともう一度やってみますか」と。

結果、サーバをグッと力を込めて押し込むと、何の問題もなく「カチッ」と取り付けができることが判明。要するに、「ちょっとビビって、押し込む力が足りていなかっただけ」というオチがつきました。「何をやってるんだ」と思われるかもしれませんが、ラックに押し込もうとしていたのは数百万もする精密機械。それは慎重にもなるというものです。
何はともあれ、無事に業務を完了できて一安心。やっぱりサーバ室で実機を触っているのは楽しいな、と感じた一日でした。最近はデスクワークばかりで目が疲れ、肩も凝ってばかりですからね。

ネジを使わない構造のレール。見るたびに毎回感心しています。

（投稿者：ちゅん）

てんちょです。つい先日は暑いといっていたような気がしますが、八雲は寒いです。

先月から少しずつ改良と修正を重ねてきた自作のPDF結合ツールがついに完成？を迎えました。動作テストの参加者を徐々に増やしながらブラッシュアップを続けてきましたが、ありがたいことに現場からの不具合報告もようやく落ち着いてきました。

実は、最後まで「追記した文字の位置がズレる」という致命的な問題を抱えていました。原因を掘り下げてみたところ、プレビュー画面上の表示フォントと、出力されたPDFファイルを開いたときのフォントが異なっていることに気が付きました。ここを合わせるように修正を重ねた結果、まだズレはあるものの、実務上は妥協できる精度にまで仕上げることができました。

そのほかにも、「ページを回転させてから文字を追記して出力すると、文字まで一緒に回転してしまう」「一度文字を追記したファイルを再度読み込んでさらに追記すると、文字が『□（トーフ）』に文字化けする」など、テキスト追記まわりで致命的なバグが多々ありましたが、これらもどうにか修正。最終的なバージョンは「v0.54.2」となりました。

「こんなツールを、一から自分の手で作成できた」という感動もあります。が、最初は「HTMLで簡易的なものが作れたらいいな」くらいの安易な気持ちで始めたことが、まさかここまで本格的な開発に化けるとは、自分でも全く思っていませんでした。

しかし、今回の試みは非常に有意義な実験になったと感じています。
このノウハウがあれば、例えば施設内に設置されているカメラの視聴用アプリや、これまで共有Excelで入力管理していた各種記録簿なども、同じように自前で作れてしまうのではないか…。さらに一歩進めて、公用スマホ上で動くアプリへと応用していけば、便利なシステムが他にも色々と生み出せそうな気がしてきます。

あまり色々と手を広げすぎると、後々の運用や保守で自分の首を絞めるという、情シス特有の「厄介な地雷」を踏みそうなので一旦自重しておきますが、生成AIを活用することで、地方自治体の現場でもこれだけの可能性を形にできるんだという、とても貴重な体験ができました。

というわけで全職員向けに近日公開予定。利用者数が増えれば不具合の報告がまたくると思いますが、気が向いたら修正しようと思います。

いっそコードごと外部公開するのも面白そうですね

（投稿者：てんちょ）