メールが届かない ＜DMARC理想と現実＞

職場の人が、元のメールが届いていないのに、催促メールが来たと憤慨していた。

情シス的には、この手のトラブルは障害の前兆だから、調査が必要だ。
調べてみると、元のメールはDKIMの設定にミスがあり、さらに、DMARCがquarantine(隔離)になっていたので隔離され、メールボックスに届いていなかった。

送信者に苦情が殺到して困っているだろうと思った。
DKIMの設定ミスは技術的な内容だから、送信者に伝えても困るだろうと考え、
隔離されたメールのメールヘッダーを添付して、システム管理者に見せるように返信した。

後日、送信者から対応に苦労した内容の返信があった。
簡単にまとめると。

• 送信者はメール配送システムの知識がない。
• メール配送システムは外注、DNSの管理は別業者に外注している。
• メール配送業者にDNSの設定を依頼したら断られた。
• 別の業者にDNSの設定を依頼した。

「大変でしたね」と言いたいところだが、この対応で良いか、組織的な見解がほしいとおっしゃる。
さらに、アドバイスや、対応してくれる業者を紹介してほしいと。

 「システム管理者としての見解」ならば答えることはできるけれど、組織としての見解を答える立場ではないので、エスカレーションしておいた。

考えた。ほぼ愚痴だけど．．．

【情シス】
送信者の組織の「情シス」の存在が見えない。
情シスに相談すれば、直接解決できなくても、解決するための方法や、対応できる業者を知っているだろう。
送信者の眼中に情シスは存在しないのだろう。 

【DMARC】
quarantine(隔離) で運用するのは良いのだが、最初は none(何もしない) の方が良いと思う。
レポートを確認する体制が無いのに quarantine(隔離) は無謀だ。

迷惑メール対策推進協議会や政府は quarantine(隔離) やreject(拒否)を推奨するけれど、現場は理想通りにはならないことを知るべきだ。

【ちょっと教えて】
メールは水や空気のように使えて当然の存在になっている。
しかし、使えて当然だからと言って、配送システムの構築やトラブル対応が簡単というわけではない。
むしろ、トラブル対応は面倒だから、専門的な知識や技能が必要になり、技術者が稼働すれば安くない賃金が発生する。

普段、意識せずメールを使用している人が、悪気なく「ちょっと教えてよ」と言うのはわからなくもない。
でもね、技術者は、その「ちょっと教えてよ」とか「ちょっとやってよ」の知識や技能でおまんま食っているのですよ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

Copilot Coworkの従量課金 ＜RPAを使うとタダだけど．．．＞

Copilot Coworkを従量課金で使っている。
課金は青天井では心配なので、全体と個人で月間使用量の上限を設定している。
先日、短期間で個人使用量の上限に達したユーザがいた。

• 大量のファイルを定型処理
• 大量のファイルの分析
• 分析結果から資料作成

を実行したらしい。

いかにも、Copilotクレジット(課金単位)を消費しそうな重い処理だが、いずれのタスクもM365 Copilotライセンスで実行できるから、課金せずに実行することも可能だ。

定期的に実行したり、データが変化したときに自動的に実行するタスクは、従量課金されることになるから、M365 Copilotライセンスで実行可能でも無駄というわけではない。

ほぼ1人情シス的には、これまで、RPAスクリプトを作成して業務を効率化してきたので、もう少しクレジットが節約できるのではないかと思ってしまう...

つい貧乏根性が出てしまったので、効率化、費用対効果、上限の設定の観点で考えてみた。

【業務の効率化】
業務効率化の観点では効率化の効果は大きい。
今回の処理は、処理対象のファイルが大量にあるからAIを使用することで、作業時間は大幅に短縮される。
また、定型処理→ファイル作成、分析→資料化など、連続して処理できるため、業務を効率化できる。

【費用対効果】
短期間で個人の上限までクレジットを使用しているが、使用者の賃金(年収/稼働日数)と比較すると高額ではない。
一方で、処理時間は短縮されているから、費用対効果は悪くない。

【クレジットの節約】
RPAやスクリプトの作成能力があれば、クレジットを節約することは可能だ。
しかし、これらの作成能力を習得するにはコストが必要である。
つまり、コストをかけてこれらの能力を習得しなくても、AIを使用することで、業務が効率化できる時代になったということだ。

【上限の見直し】
現状で処理できないくらいのデータがあるならば、AIの使用は有効だ。
そうでない場合は、処理時間を短縮すると、余剰時間が生まれる。
問題は、発生した余剰時間を使用して、効果のない作業をやってしまうことだろう。

例えば、必要のないデータを処理したり、処理を複雑にしたり、求められていない出力を生成してしまう。
時間短縮は目に見える効率化だから、処理することが楽しくなり、手法が目的化してしまう。

これを防ぐために、個人の上限は大きく変えず、上限に達したときに、処理を見直すきっかけにしよう。
処理しているタスクにより、

• 個人の上限を引き上げる
• 組織的に処理するタスクとして別管理にする
• 他の作業の効率化を検討する

などだ。

【まとめ】
M365 Copilotライセンスがあっても多くの人は、Coworkを使用して業務の効率化に活用していない。
クレジット使用量が個人の上限に達する人は、業務を効率化しようとしている人だから応援したい。
また、情シスも現場が必要としている処理について情報を得ることができる。

データ量と処理時間と結果(出来ばえ)を、経験値として持っておくことは重要だ。
今後、一般論ではなく説得力がある説明ができたり、効果的な使い方ができるようになることを期待している。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

チャットツール ＜不便なことも我慢すると不便でなくなる＞

Slackで「頼むから守ってくれ」と思う5つのこと（ガチ） もとやま note (2026/5/20)

タイトルはSlackだが、チャットツール全般に言えることだ。
もとやま氏が言う5つある原則の中で、

原則1：すべての仕事はパブリックチャンネルでやる

理由1：情報格差をなくせる
理由2：依頼が雑になりづらくなる
理由3：誰に何のボールが飛んでいるかが見える

に引っかかってしまった。
因みに、原則３以降は有料(500円)だ。

Slackではなく、Teamsのチーム内の「チャネル」へのメッセージ投稿と個別の「チャット」の2種類について考えてみた。
この2種類はよく似ているが、

• チャットはスレッド形式で投稿できない。
• チャットは添付ファイルがOneDriveに保存される。
• チャットの参加メンバーは組織的に管理されない。

という点で、大きく異なる。
この差を考えず、便利だからとチャットばかり使用すると、

• 同じような話題を扱うグループがたくさんある。
• グループチャットで合意形成されている。
• 全員に周知すべき情報がやり取りされている。

という問題が発生する。
どのような問題が考えられるか、いろいろな観点から考えてみた。

【情シスの観点】

・スレッド形式
チャットはスレッド形式の投稿がサポートされていない。
大勢が参加するグループチャットで、複数の話題が流れている場合は、話題を追うのが大変だ。
引用はできるのだが、引用が増えると鬱陶しい。しかし、まったく引用が無いと会話の流れが追えない。

・添付ファイル
チャットにファイルを添付すると、投稿したユーザのOneDriveに添付ファイルが保存される。
そのユーザがいる間は添付ファイルを開くことができるが、異動などでアカウントを削除するとOneDriveの領域も削除されるから、添付ファイルも開けなくなる。

・参加メンバーの管理
誰が管理しているかわからない。
参加してほしい人は、誰かがその都度追加するが、削除はしないので、参加メンバーが増え続け、管理できなくなる。

【組織内コミュニケーションの観点】

・グループの乱立
同じ話題を扱うグループがたくさんあるので、どこに投稿したらよいか分からない。
チームはユーザを管理する人がいるので意識しなくても良いが、チャットグループは誰が管理しているのかわからないので、参加が難しい。
そもそも、どのようなグループがあるのかわからない。

・合意形成
グループチャットで合意形成している場合は、参加していない人は認識できないし、合意形成の経緯を見ることもできない。
グループチャットに参加していない人は完全に蚊帳の外になる。
昔、重要なことが喫煙室で決まっていた、あの仕組みと同じだ。

・全員に周知すべき情報
グループチャットに参加している人は、参加していない人がいることを認識していないので、全員に周知すべき情報を投稿する。
当人は、全員に周知しているつもりだから始末がわるい。

【ナレッジマネジメントの観点】

・知見の蓄積
チャットは、過去に投稿したメッセージや共有したファイルが分からなくなるから、知見が蓄積されない。
異動してきた人が過去の経緯を知るには、人の記憶に頼らざるを得ない。
40年くらい前、ICTを使っていなかった頃と同じだ。

・AIの使用
最近のAIは、Teamsのメッセージも取得して分析できるようになった。
合意形成の経緯や、やり取りのフェーズなど動的な情報もメッセージから判断できる。
しかし、ユーザが読めない投稿は、AIも読めないから、動的な情報が取れない。
だから、AIを導入しても有効利用できない。　AI-Readyではないのだ。

【改善方法はあるのか】

不便な思いをしている人が多いが改善されないことは多い。
なぜなら、人はすぐに慣れてしまい、そんなものだと思うようになるからだ。
アクセスできない情報があったとしても、その情報の存在を知らなければ、不便と思わない。
たとえば、新幹線の存在を知らない人は、東京～大阪間を在来線で移動しても不便と思わない。そんなもんだ。フゥ．．．

不便な思いをしている人に、改善を提案すれば受入れられるが、不便だと思わない人が大半なので、いつまで経っても改善されない。

システム的な問題ならば、設定やサービスを変更するなどの対応が可能だ。
しかし、設計や使い方の問題の場合は極めて困難だ。

もとやま氏のように、嫌われても徹底的に注意するしか方法はないのだろうか?

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

AIエージェント

【最初は愚痴】
ある人が、特定の業務のマニュアルや、チャットの履歴から、質問に答えてくれるAI Agent (マニュアル・エージェント)を作ってくれた。

ファイル単体やフォルダ内のデータをナレッジソースにするAI Agentの作成は簡単だ。
プロンプトもAIに作らせることができるので、本当に簡単に作ることができる。

作成したマニュアル・エージェントを見て、担当の人は大喜びで「文明開化だ!」と言い出す始末だ。

【ちょっと待て】
1年以上前に、新任者向けに生成AIを使ったFAQ botを作って、同じ人に見せたことがある。
その時の反応は、「へ〜 ?_?)」のような反応だった。
「なんだ、この反応の差は‼︎」である。
エージェントを作ってくれた人曰く「あるあるですね♡」と。


考えてみた。

【立場】
担当さんにとってマニュアル・エージェントは、自分が質問する側だから、有効性がわかるし、何が省力化できるかわかる。

一方、担当さんは、新任者から質問を受ける側だから、FAQ botを使うことはない。
だから、質問する人の便利さがわからないのだろう。

つまり、
AIを使う側は便利と思うし、使わない人は便利とは思わない。

【ナレッジ】
AIを特定用途で使用する場合、用途に応じたデータ(ナレッジ)が必要だ。

マニュアル・エージェントは参照するデータが少ないし、メンテナンスされているから、回答精度も良い。

一方、FAQ botは、 botが参照するデータがまとまっていないし、どのデータが最新かわからない。
さらにPower Pointのスライドが多く検索精度が悪い。

つまり、
AIは使えるデータがあれば、有益な回答を返すし、無ければゴミ回答を返す。

【仕事のやり方】
マニュアル・エージェントを作ってくれた人は、マニュアルの内容についての質問に答える立場の人だ。
これまでに、「マニュアルに書いてあるでしょ!」とか、「勝手に判断しないで聞いてよ!」と思うことがあったらしい。
ひょっとすると、最大の目的はマニュアル・エージェントに「◯◯さんに相談してください。」と答えさせることかもしれない。

FAQ botを作ったときに、 botが答える基になるデータを、メンテナンスしましょうと提案したら
「わからないことがあったら、直接聞いてくれればいいのに」
と言っていた。
そもそも、「新任者は、何を、誰に聞いたらよいのかがわからない」のだけれど．．．

つまり、
質問される人の省力化・脱属人化への動機により、AIを活用する動機は大きく変わる。

【AIが補完した能力】
マニュアルや説明文などは、読む人が知りたい内容を書くべきだ。
しかし、書く人が知らせたい内容を書くことは多い。

読み手を考えて、わかりやすい文章が書けたり、わかりやすい説明ができる人は、少ない。
AIを使用することで、わかりにくい文章や説明でも、AIが質問者に応じて翻訳してくれる。

つまり、AIは、わかりやすい文章を書いたり、わかりやすく説明する能力を、肩代わりしてくれるということだ。

【人間に求められること】
最低限AIが理解できる文章を書こうよ、いやいや、せめてAIが見つけられるところにドキュメントを置こうよ。
AIの性能や、エージェントの作りやすさより、AIｰReadyになっているかが重要だ。

【AI-Ready】
AIに効率化、省力化を求める人は多いし、売る人は、AIで簡単に実現できるとおっしゃる。
しかし、AI-Readyな職場であることが条件であることを言わないようだ。

AI-Readyでない職場は、データの収集、保存、更新などの保守が必要で、情報セキュリティやデータガバナンスの確認が必要だ。
これらの作業は、地味で面倒でコストが必要だが、「AIを売る人」にとっては関係のないことなので、あえて触れることはない。

【まとめ】
今回作った、マニュアル・エージェントは使われるだろう。
しかし、AI-Readyでないことに変わりはないし、AI-Readyを意識していないので、自然にAI-Readyになることはないだろう。
だから、FAQ botは有益な回答を返せないままだ。

それでも、このような小さな一歩を積み重ねるしかないのだろうと思う。

ふぅ．．．

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

rm -rf ＜危険性が理解できない人は使わないこと＞

https://x.com/yonemura2006/status/2059236497254138182

rm -rfでやらかしたというお話が流れてきた。

生成人工知能の「チャットGPT」に相談した結果、不要なファイルを削除する方法として rm -rf というものがありますよ、ただし非常に危険ですので対象を必ず確認してください、という形での説明書きがなされ、それでターミナルに向かわせていただきました。

らしい。

事故防止、AIの利用という観点で考えてみる

【事故防止】
rm -rf のやらかしは、ターミナルでUNIXを触っている経歴が長い人は、経験があるのではないかと思う。
気がついた時の冷汗は、経験した人でないとわからないだろう。
また、Enterを押す直前に間違いに気がついたときの、心臓が縮まる感じも体験した人しかわからないだろう。

批判する人の多くは後知恵だ。
rm -rf が危険なコマンドで、対策はいろいろあることを知っていても、やらかすのだ。
原因は、

• ミスしないという、根拠のない自信
• 失敗時の影響の過小見積
• 慣れ

などが挙げられる。

最終的に辿り着いた対策は、「指差し確認」だ。
もちろん、必要な情報は確認できるようにしておく。
rm -rf の場合は、作業しているディレクトリが重要だから、事前にpwdコマンドを実行しておくとか、プロンプトにCWDを含めるなどの方法でカレントディレクトリが目視確認できるようにしておく。
その後、コマンドを入力して、指差し確認する(コマンド、スイッチ、パラメータ、CWD)
そして、OKならEnterを押す。

重要なことは、コマンドを入力した勢いでEnterを押さないことだ。
rmコマンドをラップするaliasを設定する方法もあるけれど、慣れて何も考えないで、キーを押すようになると、やはり事故は起こる。

知識としての対策を知っているだけでは、効果は限定的だ。
それは、自分が失敗したときに初めてわかる。

影響が少ない環境で失敗を体験することが、最大の学びなのだが、今時、コンソールを使う機会が少なくなったから難しい。

職場に、失敗やヒヤリの体験から学ぶ風土がない場合は、事故は無くならない。
このような風土の職場だと気がついたら、自己防衛しておいた方が良い。
後知恵で散々詰められることになるから。

【AI の回答】
AIを使用した結果は自分が引き受けるしかない。
AIの回答が間違っていたり、AIの回答が理解できなかったりすることはあるだろう。
その回答を使用した結果、誰かに不利益が発生した場合は、使用した者が責を負うことになる。
当然のことだが、AIに責任転嫁することはできない。

投稿の例では、AIの注意書きが理解できず、自分や職場の人に不利益を与えたわけだが、自分で結果責任を引き受けているようなので問題は無いと思う。
不利益を被った職場の人からは責められるだろうが、自分のミスとして受け止めるしかない。

しかし、不利益を被っていないネット民に責められる筋合いではない。

【VibeCoding】
同様にVibeCodingで作成した、コードを使用した場合、その結果責任は使用者が負うことになる。
当然、問題が発生したときに、詳細が分からないとか修正できないという言い訳は通用しない。

しかし、問題箇所を調査したり修正するために、専門家に頼らざるを得ない人は、責任を負えない可能性が高い。
だから、

責任を負えないものを作るな！
責任が負えないものを使うな！

と言いたい。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

局所最適の先

なぜDXは腐敗の温床となりやすいのか Yuta Zenn (2026/05/23)

現業部門vsIT部門の構図は、どこかで読んだことがあると思ったら、
「シャドーITのススメ」(https://zenn.dev/yuta_enginner/articles/08b775eb6873df)
と同じ人の投稿だった。

【自分の立場】
小さな職場のシス管を2回、大きな職場の情シスを1回やって、今は「1人情シス」をやっている。
その経験のなかで、現場から見たIT部門の対応も、IT部門から見た現場の要求も体験した。
それぞれの立場で課題はあるが、他の立場からその課題は見えない。
だから、多くの人が、自分の課題の根源は他の部署にあると思ってしまう。
それはやむをえないことだと思う。

【IT部門vs他部門】
ITシステムやポリシーは全社で共通に使用するから、全ての現場の要望を網羅することは難しく、全員が満足できず、全員が少しずつ我慢する状態が最適解になる。
だから、全ての部門は、IT部門に対して不満を持っている状態になり、IT部門vs他部門という構図になる。

【経営者・経営層】
Yuta氏の2つの投稿を読んで、気になったのは経営者、経営層に対する追求が弱いことだ。
部門間で利害が相反する場合は、経営者や経営層の判断が必要なのだが、投稿には現場部門とIT部門の関係だけが書いてある。
経営者や経営層を批判した投稿が読まれると、身に危険が及ぶのだろうか?　（^^;

投稿主を知っているわけではないし、ましてや、職場風土を知る由もない。
しかし、言葉の端々から、組織風土に問題があるように感じる。
そして、組織の問題を認識していながら、変えようがないことへの閉そく感がにじみ出ていると感じる。

【実は】
実は、組織風土の改革に取り組んでいたことがある。
誰に指示されたわけでもなく、難しいことはわかっていたし、おそらく達成できないと予想していた。
なぜ、そのような無駄なことに取り組んだかというと、「『全体最適』をやってみたかった」からだ。
案の定、改革はできなかったが、多くの経験知を得た。
最も貴重な知見は、

やってみなければわからないことがある。

ということだ。

---

• やらない限り始まらない (2017-05-21)

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

AIモデルを使用して脆弱性を発見する際に尋ねるべき10の質問

10 questions to ask when using AI models to find vulnerabilities Ruth C NCSC (2026-05-11)

AIモデルを使用して脆弱性を発見する際に尋ねるべき10の質問
(翻訳しました。)

1.  AIを活用することで、どのような成果を目指していますか？
2.  AIを活用することは、セキュリティを向上させる最善の方法でしょうか？
3.  AIが発見した脆弱性を管理するためのプロセスはありますか？
4.  脆弱性の優先順位付けはどのように行うべきですか？
5.  AIを使って脆弱性を発見する際のリスクは何ですか？
6.  どのAIモデルを使用すべきですか？
7. どこから始めればいいですか？
8.  新しいAIモデルに対応するための私の長期的な計画は何ですか？
9. 人材育成において、どこに投資すべきでしょうか？
10.  私たちが開発または使用するすべてのものがどのようにパッチ適用されているかを把握していますか？

AIを使用することで脆弱性を発見する能力は向上したけれど、脆弱性を発見することを目的にすべきではない。
脆弱性は管理しなくてはならないが、管理する能力は、AIを使用して脆弱性を発見するより困難だ。
それは、管理されない脆弱性が増えることを意味する。

重要なことは、

組織のセキュリティを向上させるための最も重要なツールは、基本的なサイバーセキュリティ対策を徹底することです。

当たり前のことを当たり前にやることだ。
これが難しい。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

デジタル・カイゼン

カイゼン活動の亡霊「DTK」、変革を骨抜きにしてDXやAXを滅ぼす　日経クロステック　木村岳史　(2026/05/25)

【デジタル・カイゼン】　
木村岳史氏は、現場主導の改善としてのデジタル化はDXではなくDXを阻害することを、以前から指摘しておられる。

DXに限らず、昔から変わらない構造的な問題だ。
昔々、ペーパーレスが流行ったときに、稟議もFAX、スタンプラリー、ドッチファイルもなくならなかった。
パソコンが使えるようになったが、パソコンでせっせと稟議書を作り、スタンプラリーをして、ドッチファイルに綴じていたのである。

昔も今も、仕事のやり方(業務)を変えず、現状の作業をITで置き換えていた。
例えるなら、最新の建材で竪穴式住居を建てているのである。

【DXは改善?】
「DX」を検索すると、「DXで業務改善」など、改善がヒットする。
経産省によるDXの定義は、

• デジタル技術やツールを導入すること自体ではなく、データやデジタル技術を使って、顧客目線で新たな価値を創出していくこと。
• また、そのためにビジネスモデルや企業文化等の変革に取り組むことが重要となる

だ。(太字は著者による)
改善ではなく改革なのである。

日本の組織は現場のカイゼン運動で成功してきた歴史があるが、局所最適になりがちだ。
自分や、自分の部署の作業は改善できるが、組織的な問題が改善されているわけではない。
とりあえず、目先の不便が解消すれば良いと考えるのは人の性で、それを良しとするのは、組織風土だ。

例えば、組織全体で使用することが多い情報システムを構築、更新しようとすると、情シス部門vsその他の部門という構図が生まれる。
局所最適で改善している部署が抵抗勢力になるからだ。

【トヨタのカイゼン】
木村岳史氏によると、カイゼン活動がDXを阻害すると指摘すると、「だったら、カイゼン活動の元祖であるトヨタ自動車はどうしてあんなに好業績なんだ」という反論があるという。

トヨタ生産方式(TPS)はカイゼン活動がフォーカスされがちだ。
しかし、本当の強みは、問題解決の8ステップを、現場、管理職、経営層それぞれの階層で実行する組織風土があることだろう。
だから、現場だけで問題を解決しているわけではなく、管理職や経営層が局所最適にならないように、カイゼンしている。

「4. 真因を考え抜く」を真面目に実行すれば、業務フローの不備に気が付くはずだし、真因を考え抜く組織風土が無いことに気が付くだろう。
つまり、DXを現場に丸投げしたり、現場で野良マクロや野良RPAを作るだけでは、根本的な問題は解決しないのである。

【1人情シス】
組織が大きくても、小さくてもこの問題はある。
40年間大きな組織で働いていたときに、この問題を痛感していた。
今は、小さな組織で1人情シスをやっているが、やはりこの問題はある。

他の業務が関係する作業は障壁が多く効率化できないのである。
仕方がないので、情シスだけが関係する作業をRPAとAIを使用して効率化した。

結局、局所最適だ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

人が余っているから情シス

AIに代替された人材で、情シスの派遣事業を始めるというアイデア

3月頃からSES会社の社長によく相談を受けます。「今、人が余ってきているので、中小企業のIT支援業務とかやろうと思っているのですが、何したらいいですか？」……そんなに簡単な仕事なら、ひとり情シスの方々はこんなに苦労されていないのですよ。 https://t.co/LHnTYViPfU

— 清水 博 (@Shimizu1manITDX) May 17, 2026

清水博氏は

そんなに簡単な仕事なら、ひとり情シスの方々はこんなに苦労されていないのですよ。

とおっしゃるとおり!　我が意を得たりだ。
世の中の経営者が、「情シス」は誰でもできる程度の仕事と思っているから、情シス不足問題は解決しないのだと思う。

【1人情シスの仕事】
特に1人情シスの仕事は多岐にわたる。
例えば、ICT機器の保守・整備、ヘルプデスク、情報セキュリティ、開発、ユーザ管理、情報資産の管理などが挙げられる。
それぞれの業務は、専門性があって、複数の業務で高い能力を持つ人材は少ない。

大きな企業では、それぞれの業務の作業量が多いから、業務ごとに専門の担当がいる。
一方で、小さな企業や事業所では、それぞれの業務の作業量が少ないから、全ての業務を1人で担当することになる。
これがいわゆる「1人情シス」だ。
つまり、「1人情シス」は、作業量は少ないが専門性が異なる作業を1人で担当している。

全ての分野で、高い専門性を発揮できる人は「スーパー1人情シス」と呼ばれるが、そのような人は、極々稀な存在だ。
ところが、ITを一括りにして、全ての業務に詳しいことを前提にして、作業量が少ないことを理由に低賃金で雇用しようとする。
これが、情シス不足の要因だろう。

【客先常駐の情シス】
業務委託で週3日、客先常駐の情シスをやっていたことがある。
その経験では、最も重要なことは、コミュニケーション能力だと思う。

コミュニケーション能力に難があると、仕事は少なくなるが、何をやっているのかわからないと言われる。
普通のコミュニケーション能力があれば、仕事がふえるが、契約範囲外の依頼がある。
やっている仕事を報告するにも、契約範囲外の仕事を断るにも、コミュニケーション能力は重要だ。

【心がけていたこと】

• 愛想よくする
  自分の、知識・技能は使ってなんぼと考えているから、なるべく愛想良くしていた。
• 作業を報告する
  日報が無かったので、グループチャットに作業を投稿していた。
• 無茶ぶりされたときは、安易に引き受けない
  「それは金で解決する案件ですよ。外注しましょう」と正直に助言していた。

【受注企業】
受注企業は、社員の仕事をサポートするのは当然として、仕事が正当に評価されるよう配慮すべきだ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【ほぼ1人情シス】

コパさんの配慮 ＜フールプルーフが実装されている?＞

「AIを使って、過去の原稿データの整理や、それを元に新たな原稿の作成はできるのか？」仕事歴20年超のベテランライター格闘記 
渥美 志保  mi-mollet  (2026/3/10)

「過去原稿のデータベースから、AIに原稿を書かせてみたい」ところが...。仕事歴20年超のベテランライターが気づいた【AIの使いこなし方】とは？
 渥美 志保  mi-mollet  (2026/3/11)

渥美志保氏は、AIについて、

すごい時代になったと思うけど、この流れはもう止められない。どうにかこうにかついていくか、それとも完全に背を向けた世界に生きるか。選択を迫られているなあ。

とおっしゃる。

冒頭の記事は、渥美志保氏が過去に書いた原稿のファイル名を、AIを使用して一括してリネームしようと奮闘した顛末だ。
渥美志保氏の職業は文筆業だから、この投稿で紹介されているのは、専門分野以外の領域でのAIの使用だ。
だからだろうか、最後の部分は客観的でどこか他人事のようにも感じる。

渥美志保氏が専門分野でAIを使用(評価)した、投稿を読んでみたいと思う。

閑話休題

この投稿では、ファイルを一括してリネームするPowerShellのスクリプトを、Copilot(コパさん)に作成させようと奮闘し、結果的にスクリプトは生成できなかったようだ。
コパさんはフェールセーフを考えているような気がする。

「ほぼ1人情シス」の業務に、M365の管理が含まれている。
作業がGUIで実現できない場合や、手間がかかる場合は、PowerShellのスクリプトを作ることが多い。
使い捨てではなく、他の人が使うスクリプトを作る際には、-Execオプションがない場合は、 -WhatIf オプションを付けて実行するようにしている。
いわゆる、フールプルーフだ。
破壊的なコマンドレットが含まれる場合、いきなり実行してエラーが発生したときの、復旧作業は面倒だから、なるべく事前に防ぎたい。

2年くらい前に、Copilotに簡単な作業のスクリプトを書かせたら、ネットからパクってきたような出力だったが、最近は、時に過剰なコードを出力するくらい賢くなった。

おそらく、渥美志保氏が使ったコパさんも、フールプルーフが実装されていて、危険度のレベルを超えたら、コードを出力しないようにしているのだろう。
相当ヤバいコードになっていた可能性がある。

蛇足だが

ファイル名を規則的に一括リネームするなら、PowerToys に含まれている PowerRenameを使うと目的は達成されるような気がする。
複雑な変換は正規表現を使用しなければならないから、コパさんに教えてもらうことになるけど。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【ほぼ1人情シス】