ども。
電動除雪機を購入しようか真剣に考えている担当ちゅんです。

本日はてんちょが出張につき不在。以前であれば私の不在時に限って色々なトラブルが起きたものなんですが、最近はそれが逆になってしまい・・・。彼がいないタイミングでなぜか対応の難しい案件が飛び込んでくるようになりました。実質的な管理者が誰なのかを機器やシステムが理解しているようにしか思えません。

今日の案件はタイトルのとおり。職員から「共有メールボックス内のメールが大量に消えてしまった」という連絡を受けて対処を行いました。当町のメールはMicrosoft Exchange Onlineで運用していますが、職員はアプリ版のOutlookで閲覧しています。共有メールボックスのメールが消えたということで、当初は「アクセス権を持つユーザーの誰かが削除したのでは」と疑いを持ち、調査を開始。M365にはMicrosoft Purviewというセキュリティ監査を行うことができるサービスがあるので、そのメールボックスから誰かがメールを削除していないかを確認。しかし、意図的には誰も削除を行った形跡はありませんでした。
次に予想したのは「誰かがメッセージの削除に関係するルールを作ったのでは？」ということで、その共有メールボックスにアクセスできる職員の権限でルールを確認。ですが、こちらについてもルールは1件も作成されておらず空振りとなります。

以前まではこういう状況になると「お手上げ」となったのですが、今は違います。おもむろにChatGPTにアクセスし「こういう状況なんだけど原因は何だと思う？」と尋ねると、即座に「共有メールボックスをExchangeキャッシュモードで使っている場合はそういう動きをすることが非常に多いです」と。色々と調べてみると、どうやらOutlookは既定でキャッシュモードがONの状態になっていて、常にサーバにアクセスするのではなく、送受信されたメールはPCのローカルにキャッシュ（OST）を持つようなのです。これを複数人で運用している共有メールボックスで有効にしていたため、何らかの要因によりサーバのデータとキャッシュとの間に不整合が生じ、その結果として受信メールが消えた（ように見えた）というのが今回の現象の原因だと突き止めました。

ついでに、特に頼んでもいないのに解決策までが提示され、本当に生成AIは優秀ですね。消えたと思われていたメールも全て元に戻り、一件落着となりました。
それにしても、ワンオペの日に限ってこんなことが起きるとは。でも、大丈夫。私には今やChatGPTという優秀な壁打ち相手がいますので。こういう風にして仕事を進められるような時代がやってきたという意味で、本当に技術の進化を身近に感じられています。

でも、出力された情報が常に正しいとは限らないので、そこは要注意です。

（投稿者：ちゅん）

てんちょです。年明けから急激に積雪が増え始め、朝晩の雪かきで疲弊しています。春が待ち遠しいですね…。

とあるシステムの操作説明会を実施するにあたり、画面キャプチャを行うことになりました。自分の端末はすでにテスト用として稼働しており、各種設定も済んでいるため、一から設定を行うには少し不向きです。ちょうど使っていない端末があったので、自分のアカウントでログインしてみたところ、なぜかサインインできませんでした。

キッティング直後の端末で、特に何かした覚えはないのですが、「サインインできませんでした」という謎のメッセージが表示されます。デスクトップ自体は表示されるものの、アプリが起動しないなど、どうにも挙動がおかしい状態。
サインインできないということでユーザープロファイルを確認してみると、そこに自分のアカウントは見当たりません。デスクトップは表示されているのに、ユーザープロファイルが作成されていない、という不思議な状態でした。

おそらく、キッティング用のイメージを作成した際に、試しにログインした自分のアカウントを削除したのだと思いますが、何かが残っていたのでしょう。こういう時は大体レジストリだろう、ということで「ユーザーアカウント 削除 レジストリ」と検索してみると、検索結果のAIが以下の場所を削除するよう教えてくれました。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows　NT\CurrentVersion\ProfileList

実際に確認してみると、システムのプロパティ内のユーザープロファイル一覧には表示されていなかった自分のアカウントが、しっかり残っていました。ということで、該当するキーを削除。サインアウトして再度ログインしてみると、今度は問題なく通常通りログインできました。
ということは、配備済みの端末すべて、私のアカウントではログインできない状態になっている、ということになりますね。自分のアカウントで他の端末にログインする機会はほとんどないので、実害はなさそうですが、念のため備忘録としてブログに残しておこうと思います。

ということで謎レジストリだけ残っていたのが原因でした。

（投稿者：てんちょ）

ども。
道民なのに寒さが苦手な担当ちゅんです。

昨年末からひっそりと開始していたミッションがあります。タイトルのとおりではありますが、現在「オンプレのファイルサーバをクラウド化する」という大仕事に取り掛かっていて、例年であれば全ての事業が完了し次年度の準備などを進める時期であるはずの（行政的には）第4四半期に、まだ事業を動かしている状況です。
（まあ、それがなくても標準化が・・・）

具体的に何のサービスに移行するのか等については、その時期が来たら改めてご報告するとして、本日は既存のファイルサーバについて。これまで、長年にわたって使い続けてきたサーバ。もちろん、ハードウェアの更新は幾度も行ってきていますが、保存されているデータそのものは都度フルコピーしているため、いわば老舗料理店の「創業以来継ぎ足しのタレ」のような状況となっております。それでも、これまでは容量が圧迫する都度、古いデータは削除するなど整理をお願いしながらのやりくりをしていました。

現行のファイルサーバは仮想サーバになっていて、仮想化基盤（HCI）で動いています。この環境になってからストレージには若干の余裕が生まれたため、思い起こしてみるとここ数年は「消してください」という依頼をしていなかったなぁと思い、サーバの移行前に現行の状況を確認。すると、3年ほど前までは4TBの容量で苦労しながら運用してきたものが、放置した結果、なんと9TBにまで膨らんでいました。ファイル数にして900万ファイル。なんと倍以上に膨らんでいるということで、これは率直に驚きました。

ですが、これに関して言えば、自分の中で何が正解かわかっていません。9TBというのは職員が日々業務を行っている結果としての数字。決して不要なデータをいたずらに保存しているわけではありません。かといって、ストレージは無尽蔵に使っていいのかと言えばそれも違うわけであり、ここに担当者としての葛藤があります。ただ、自信を持って言えることは「データは今後も加速度的に増える」ということ。そして、「AIの進歩に伴いその重要性も増していくであろう」と。これまでは単なるファイル保管だったものが、そのデータをAIが読み込むことで新しい価値が生まれていく時代が到来しています。
では、こういう一見矛盾している要素を解決する方法があるのでしょうか・・・と、まだ話は続きますが本日はここまでにしておきます。ファイルサーバの移行はとても緊張しますが、やりがいのあるミッションだと思っています。頑張ります！

創業以来継ぎ足しのタレを失うことは何があっても許されません

（投稿者：ちゅん）

てんちょです。新年あけましておめでとうございます。本年もどうぞよろしくお願いいたします。

年末の休みに入って3日目、職員から電話がありました。
「役場に電話すると、留守番電話のガイダンスが流れるんですが…」
この一言で、正直ちょっとドキッとしました。

すぐにテレワーク用端末を起動し、クラウドPBXのコントロール画面を確認。年末年始期間（12/29～）に入ってすぐの出来事だったため、年末年始用のスケジュール転送設定が原因だろうとは予想がつきました。着信グループの設定を確認したところ、案の定、年末年始期間中の転送先がガラホではなく音声ガイダンスになっていました。原因は間違いなくこれです。各代表番号の転送先をガラホに変更し、ガイダンスが流れてしまう状態は無事に解消できました。

これで通常どおり電話が鳴るようになりました。休み前に年末年始の設定は一通り確認したつもりでしたが、まさかこんな設定ミスが残っていたとは…。やはり実際に使われてみないと気付かないこともありますね。

転送設定については、通常の時間外は「ガラホが3～5コール鳴ってから転送する」設定にしており、時間外でも職員が直接応答できるようにしています。ただ、今回改めて設定を行った際に年末年始期間にもこの設定が本当に必要なのか？という疑問が浮かびました。同様に、土日祝日や平日の深夜帯についても、もう少し細かく設定を分けてもいいのではないかと。運用にもだいぶ慣れてきたので、そろそろこのあたりの設定についても本格的に見直していく必要があるのかもしれません。

スケジュール設定については細かく設定しすぎると管理も大変になりそうな予感も。

（投稿者：てんちょ）

ども。
新年あけましておめでとうございます。担当ちゅんです。

本日から2026年の業務が始まりました。とはいえ、行政の職場は4月～3月の「年度」が区切りとなるため、実際のところは、文書に日付を書くときに2025と書かないように気をつける程度の変化ではあります。

そんな仕事始めの業務ですが、年末年始の休み中に、とあるメーカーさんからWebカメラのデモ機が届いており、本日は休み明けのリハビリも兼ねてカメラの検証からスタート。ここでは名前は伏せておきますが、本件カメラは昨今話題の「AI機能搭載」。以前、オンラインで製品紹介を受けた際、例えば「黒い服を着た男性」と検索すると、録画データの中からそれに該当するシーンだけを抜き出して一覧表示するといった機能が利用できると知り、これはぜひ一度試してみたいと熱烈にオファーを送ったのでした。

今回、そのオファーが叶い、カメラ本体をお借りすることができました。早速試してみようと思いましたが、電源供給にはPoEによる電源供給が必要とのことで、職場に転がっていたPoEスイッチを準備。LANケーブルを接続すると電源が入りましたが、今後は設定のためDHCPによるIPアドレス付与が必要とわかり、これまた職場に転がっていた適当なルータを接続。設定を進めましたが、今回のカメラはクラウドから管理するものなのでインターネット接続も必要となり、適当なルータのWANに、これまた適当な回線を接続。傍から見たら、絶対に役場とは思えないような光景になってしまいましたが、実に我々らしい新年の幕開けになったと思います。

肝心のカメラについては、数日間動画を撮りためてみてから、AIの機能を試してみたいと思います。これは想像ですが、例えば全国的な問題となっている「熊」の対策として使えないか。また、このラインよりも上まで雪が積もる・水位が上がったら通報するといった防災での使い方はどうか。医療機関や保育園、学校などでの安全確認としてはどうか・・・などなど、行政部門ならではの課題をAIカメラで解決できるのでは？と考えているところです。

AIカメラには無限の可能性を感じています

（投稿者：ちゅん）