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

先日、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を活用することで、地方自治体の現場でもこれだけの可能性を形にできるんだという、とても貴重な体験ができました。

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

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

（投稿者：てんちょ）

ども。
出張ラッシュは一段落しましたが、職場は事業が山積している担当ちゅんです。

先週東京から帰ってきたばかりではありましたが、数日経ってまた東京・・・。昨年度から当町が利用を開始しているオンラインストレージの「Box社」が開催したBox Works Tokyoというイベントでの事例発表の機会を頂きました。

我々がBoxを選んだ理由はシンプルで、クラウドサービスでありながらストレージ容量が無制限である点。次いで、公式アプリを活用することでオンプレのファイルサーバとほとんど同じ動きをする（Windowsエクスプローラーが使える）という点。その点だけでサービスを選定したといっても過言ではないのですが、イベントに参加してみて若干恥ずかしくなりました。いつの間にか、BoxはAIサービスに変貌していたのですね。

簡単に言ってしまえば、自社のファイルサーバ内を参照して答えてくれるAIが使えると。RAG（Retrieval-Augmented Generation：検索拡張生成）と呼ばれるものですね。一般的な生成AIを利用していると、情報はインターネット上から検索して持ってくるものが多いですが、RAGは情報の参照先を特定させられるので、自分たちの組織にしかない固有の情報などもAIが利用できると。そういう意味で、オンラインストレージとはかなり相性がいいのは言うまでもないことかも知れません。イベントでは、このAI機能を活用した事例が多数報告されており、進んでいる自治体との距離がどんどん離れていっているなと焦りを感じる場面も多かったです。

一番印象的だったのは、講演の中で「生成AIはもうWeb上にある全てに近い情報を収集しきってしまった」というフレーズでした。そうなると、これから先もAIが進化していくとして、やはり重要なのは組織が保有しているデータということになっていくのでしょう。そういう意味で、どのようなデータをどのような形で保有しておけばいいのか、という話になっていくのですが、私としては最低限「データが無い」という状況にはなってはいけないと思っています。どのような状態になれば「AI-Ready」と言えるのかは、私自身が勉強不足なため理解は不十分ですが、来る将来に向けデータに着目して業務を進められるか否かが、その先の大きな差になっていくのだろうということを学んだ1日でした。

夜はまたランニング。毎回ですが、皇居外周を走っている人の多さに驚きます。

（投稿者：ちゅん）

てんちょです。ちゅん氏は再び旅に出ました。出張が多くて大変そうです。

先日から動き出した「スキャンファイルの自動リネーム」の続きです。まずは2カ所の部署でテスト展開を実施していましたが、これが想像以上に好評。手応えを感じたので、希望する部署へ追加で導入を進めることにしました。

業務チャットで「導入希望があれば連絡をください」とアナウンスしてみたところ、こちらの予想を上回るペースで次々と手が挙がりました。普段、自分自身はそこまで頻繁にスキャナを使わないため、「みんな思っていた以上にスキャン機能を使っているんだな」と、現場の隠れたニーズを再発見するきっかけになりました。

追加方法はいたってシンプル。すでに安定して動いているテスト用のフローを別名で保存してコピー。あとは、各部署の「Box内のスキャンフォルダ」の場所と、処理後の出力先を書き換えるだけです。念のためテストファイルをフォルダに放り込み、正常にリネームされるのを確認して完了。一度ベースとなる仕組みを作ってしまえば、その後の横展開が非常に楽なのもPower Automateの大きな強みですね。

こうして順調にほとんどの部署で自動リネームが動き始めたのですが、運用が本格化したところで、ある職員から「同じPDFをスキャンしたら、先にあったファイルに上書きされて消えてしまった」という報告が…。

現在のファイル名は「yyMMdd（スキャンした日付）_生成ファイル名.pdf」というルールで出力されるように設定していました。しかし、同じ部署で同日に似たような内容の書類をスキャンすると、AIがまったく同じファイル名を出力してしまうケースがある。その結果、同一ファイル名と判定されて上書きされてしまう…なるほど、これは盲点でした。

試しに同じPDFを4つ同時にスキャンフォルダに放り込んで実験してみました。すると、実際に出力されたのはなぜか2つだけ。Power Automateのログを確認すると、4つとも「成功」と記録されています。おそらく、AIのその時の「気分」で、1つだけ別のファイル名が生成され、残りの2つはまったく同じ名前になって上書き消滅してしまったのでしょう。上書きの挙動がはっきりと確認できたので、対策として日付の後に「時間（HHmmss）」も追加するようフローの設定を変更。

先日の自作PDF結合ツールのときもそうでしたが、やはりテストに参加する人数が増えると、こちらが一人で検証していたときには到底想定していなかった「生の問題」がすぐに出てくるので非常に面白いですし、勉強になりますね。

そして、早くも次の課題が見えてきました。それは「画像や写真」を取り込んだときのファイル名。現在はスキャンデータから文字（OCR）をテキスト化して名前を抽出しているため、文字情報のない写真などを取り込むと、ファイル名が「不明」になってしまいます。プロンプトの書き方を工夫するか、あるいは画像そのものの内容を認識できる別のAIアクションを組み合わせれば、写真でも「何が写っているか」を判断してリネームできるようになるはず。さらに精度を上げて、より使い勝手の良いツールに育てていきたいと思います。

スキャンしたデータをテキスト化して保存とかも需要ありそう

（投稿者：てんちょ）