フォト

ウェブページ

無料ブログはココログ

MyList

« 2025年11月 | トップページ | 2026年1月 »

2025年12月

2025年12月31日 (水)

2025年の反省

今年も一人反省会。

2025年の目標

  • できることよりやりたいこと
  • 100%にしない
  • CPUを使ってみる

だった。
20251231

【できることよりやりたいこと】
AI技術の進歩が速い。
自分の作業の省力化だけでなく、興味の赴くままに、業務の効率化に使ってみた。

AIを使用することで、作業の省力化、高度化できることが分った。
そして、AIを業務の効率化に使用することの難しさも痛感した。

【100%にしない】
今年は、考える余裕があった。
「ほぼ1人情シス」として4年を経過して気が付いたのは、保守やヘルプデスク業務に必要なマインドの重要性だ。同じ仕事を長くやっていると、当然のことになっていたようだ。

保守やヘルプデスク業務経験のない人に、「マインド」を求めるのは無理だと思うようになった。
知識や技術は比較的容易に獲得できる。しかし、「マインド」の獲得は容易ではない。
情シスの後継者不足が顕在化しているが、技術だけでは解決できないだけに難しい。

【CPUを使ってみる】
CH559picoに豊四季BASICを実装してみた。楽しい

CH559picoでTOYOSHIKI-BASIC
CH559picoでTOYOSHIKI-BASIC (2)


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

2025年12月23日 (火)

ランサムウェア被害

ランサムウェア被害が相次ぐ日本企業 アスクル、無印良品、アサヒ、そしてトヨタが示した「初動対応の差」【いづも巳之助の一株コラム】
 セブツー 2025/10/22

ランサムウェア被害を受けた企業の株を持っていたら、どう「心配」すればいいのか、という株主目線のお話。

いづも巳之助氏は、3段階で評価すべきとおっしゃる。

■第1段階:24時間は「誠実さ」を見る
■第2段階:72時間で「仕組みの強さ」を測る
■第3段階:1週間で「信頼」を勝ち取れるか

組織の危機管理の観点で読むと非常に参考になる。
しかし、「ウチは大丈夫👌」と言える組織は少ないのではないかと思う。

これらの情報は、「危機管理」「BCP」「コンテンジェンシープラン」などで調べると、たくさん見つけることができる。
重要なことは、自分たちの組織で実際に運用できるか、という観点だろう。

Photo_20251216182001
システム管理の観点から考えてみた。
組織の危機管理は経営課題だが、ランサムウェア被害のように情報システムのインシデントは組織にとっても重大なインシデントになる。

■第1段階:24時間は「誠実さ」を見る
経営者が誠実であっても、責任者(経営者)がインシデントを把握し、公表する情報を整理する時間が必要だ。

セキュリティー製品が、異常を検知すると自動的にアラートが出る。
担当者がアラートを受信して、インシデントを確認してから、判断できる責任者までエスカレーションする必要がある。
エスカレーションができなかったり、時間がかかる組織は多い。
原因は
・マニュアルに、エスカレーションの基準、手順が明文化されていない
・エスカレーションの訓練を実施していない
・エスカレーションしたときに責任者の機嫌が悪かった...
など

責任者(経営者)は「なぜ早く報告しないのだ」ということが多いが、報告が遅れるのは理由がある。
インシデントが発生しないと気が付かないものだ。

★第1段階が最も厳しいかも。

■第2段階:72時間で「仕組みの強さ」を測る

BCPやコンテンジェンシープランがあれば粛々と実行するだけなので、情報システムについても粛々と実行するだけのはず...だ。
しかし、定期的に訓練しておかないと、切り替えでトラブルが発生する可能性が高いし、システムが切り替わっても、運用を切り替えることができないこともある。
BCPやコンテンジェンシープランの不備は、訓練を実施して、その結果を評価しなければ改善できない。 

★BCPやコンテンジェンシープランがあって、定期的に訓練されていれば可能かも。

■第3段階:1週間で「信頼」を勝ち取れるか

 短期間で、原因を特定して対応と再発防止対策まで考えられるのは、規模の小さいインシデントか、規模が小さい組織か、限定的な対応でよい場合だろう。
ランサムウェア被害のような場合は、原因特定に時間がかかるため1週間はハードルが高いと思う。
被害を受けていない部分から、段階的に稼働再開させるなど、全面的に業務が止まらないような構成にしておくことが必要で、
デススターのように、一撃で崩壊するシステムにしないことが需要だ。

★インシデントが発生する前が重要。インシデントが発生した後の対応では難しいかも。

【結論】
記事にあるように、「単なるITトラブルのように見えて、実は経営レベルが露呈する」という指摘は正しいと思う。
情報セキュリティを経営課題としてとらえていない経営層も多い。
セキュリティレベルは、そのシステムの中で最も弱い部分で規定されるから、弱いのは、たいていは人の意識や体制だったりする。
と考えると、情報セキュリティに金を使わないという経営者の判断はバランスが取れていたりする。きっと自分に合わせているのだろう。(^^;


※「ほぼ1人情シス」業務をやっているのだが、自サイトのことを書くと生々しいので一般論にした。


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




2025年12月19日 (金)

添付ファイル <.jtdファイルがやってきた>

.jtdファイルが添付された、見積り依頼メールが来た。
一太郎はまだ使われているんだ...
Ichitaro_kayo

一太郎が悪いわけではない。
組織には組織の文化があるから、どのアプリを使うのも自由だけれど、外部とやり取りする際には、互いにストレスがない方法やファイル形式にすればよいのにと思う。

世界中のどのPCでも .dotファイルが見られると思っているのはいかがなものかと思う。
昔は、いきなり.docで送ったら顰蹙ものだった。(.docの拡張子を使っていいのは readme.doc だけだ!!)
もっとも、エンコード方式もカオスで、Mac村の人はBinHexでUNIX村の人はuuencodeで、遅れて使い始めた人たちはBASE64だったので、いきなりファイルを添付すると、デコードできないことが多かった。(ってインターネット老人会だ)

最近はアプリが賢くなって、低レイヤーの違いを吸収してくれるので、意識しなくなった。
しかし、SNSでのやり取りを見ていると、価値観まで同じことを前提にしている人が多くなったような感がある。

はみ出し者としては、世の中の多くの人が、自分と同じ価値観だったら、キモチワルイ。

蛇足
.dotファイルを開くために、わざわざ一太郎ビューワーをインストールした。
内容は、本文に書いたら十分じゃネ!!


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

これまで書いた記事

これまで書いた記事は、「Yoshiのブログ」にあります。

Yoshiのよしなしごと】【Yoshiのブログ

 

2025年12月16日 (火)

Copilotで思考を深められるか <それは人間の仕事!>

Copilotを2年くらい使っている。
最初の頃は、アプリに組み込まれた生成AIという認識で、ともすれば、ちょっと賢い検索エンジンぐらいの使い方が多かったから、無償版で良いと思うこともあった。

Aivss

Copilotは単体の生成AIというよりも、M365やWindowsとの連携を売りにして、他の生成AIと差別化する戦略だろう。

使っているうちに、過去に作成したファイルを読んでくれるようになったので、自分の考えに沿った出力を出すようになってきた。
便利になった反面、新しい観点が欲しい時には、鬱陶しいと感じることもある。
リサーチツールでちゃんと調べろということだろう。

【思考を深める】
人間は、同じテーマでドキュメントを作っていると、考えた時間が増えるにつれて、思考が深まる感じがある。
しかし、Copilotの出力は思考が深まらない。

Copilotは、過去に作成したOneDriveのデータは参照するから、いつも昔の自分の思考結果を出力する。
Copilotに思考を深める機能は無いから、当然なのだが、少し物足りない感じがする。

物足りなさは、思考を深めた自分と、思考を深める前の、過去の自分との差なのだろう。
思考を深めるのは人間の仕事ということだ。


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

2025年12月13日 (土)

衣食足りて・・・ <まだ貧しいのか>

国家的イベントでセキュリティ業務に従事された方の、SNSへの投稿を見た。

「セキュリティ、何もなければ、評価されず。」

らしい。
セキュリティに携わっている人なら、十人中十人が「そうだ!」と言うだろう。

Photo_20251202100301
【セキュリティ業務は評価されない】

多くのコメントが寄せられていて、情報セキュリティ分野だけではなく、システム保守、警備、法務などの分野の人も、「ウチも同じです」のようなコメントが多く寄せられていた。
いずれも、間接部門で、所謂裏方業務だ。
長く通信インフラの保守、デジタル・フォレンジックの技術サポート部門を経験して退職し、今は「ほぼ1人情シス」をやっているが、同じことを思う。

【衣食足りて・・・】
「衣食りて礼節を知る」という諺がある。
 生活の基本である、衣食が足りて初めて、礼節を考える余裕が生まれる。
くらいの意味だ。
経営的に、セキュリティや保守は重要だが、それより優先しなければいけないこともあるだろう。
だから、セキュリティや保守を、全てに優先すべきと思ってはいない。
セキュリティや保守など間接業務を重視しない組織は、衣食が足りていないのだと思っている。

社会生活において礼節を欠く人は、一人前とは認識されないように、セキュリティや保守を蔑ろにする組織は、一人前の組織として認識されない。
冒頭の投稿に、多くのコメントが寄せられたところを見ると、日本の多くの企業は、衣食が足りていないのかもしれない。


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

2025年12月10日 (水)

無償版Copilotで十分 <有償版が使える環境になっていない?>

Microsoft 365 Copilot の有償版と無償版の違いを検索とナレッジマネージメントの観点で読み解く
SharePoint Technical Note (2025/11/26)

記事を投稿された平野愛氏は

無償版で十分という場合は、組織内の情報をうまく再利用するという土壌が醸成されていないか、そういったことを必要とする業務スタイルにないのかもしれません。全体最適化の話の一部で、部分最適化ではないので。

とおっしゃる。
Copilotを2年くらい使っているが、最近の地味なアップデートや機能追加を見ると良く分かる。
S_20251205151901

【昔話】
20年くらい前に、全文検索システムが流行った時に、導入してみたが、期待した効果は無かった。
インデックスでストレージを消費して、CPU使用率が上がっただけだった。

原因は、ゴミデータが大量に含まれていたこと。
全文検索システムを使用すると、非定型フォーマットのドキュメントを検索できるけれど、ゴミデータを避けて検索してくれるわけではないのだ。

【組織が持つ情報】
CopilotはSharepointで共有された情報を参照してくれる。

共有された情報は、客観的なデータや組織の思考の積重ねが含まれているので、組織の財産だ。
自分が担当していない業務に関する資料でも、共有された情報を、探して生成してくれるので、情報を探す手間が省ける。
SharePointのCopilotは、全文検索システムを導入したときに抱いていた、融通が利く検索だと感じる。

当然だが、共有された情報は、保守されていることが前提だ。
不完全な情報、誤った情報などが共有されていると、不完全な内容が出力される。(あたりまえ)
Copilotはドヤ顏で、ボツネタを生成する。

【情報の保守】
30年くらい前に、ファイルサーバーでファイルを共有できるようになったときに、データベースを作らなくて良くなったので、便利になったと思った。
しかし、共有されるゴミデータが増えるに従い、財産ではなく負債になった。

当時の感覚のまま、SharePointをファイルサーバーとして使っている、職場例は多いのではないだろうか?
つまり、ゴミデータと貴重な情報が整理されず、保存されている。

生成AIが登場するまでは、情報を活用するためには、保存するデータのフォーマットの制限が厳しく、保守しなければ使えなかった。
しかし、生成AIを使用することで、データのフォーマットが厳密に統一されていなくても、活用できるようになった。

「AI」に過大な希望を抱いている人は多いようだが、今も昔も、情報の保守は必須だ。

既に情報が保守されていて、活用されているなら、Copilotを使用することで、活用できる用途が広がり、業務の効率が上がる。
しかし、情報が保守されていないならば、Copilotはごみデータを排除する機能を持っていないので、使用しても効果は上がらない。
つまり、組織の情報が保守されていないから、有料版を使用して効果がなく、無料版でよい、ということだろう。

これは、一朝一夕に解決できる問題ではないので、厄介な問題だ。
組織的な情報の蓄積は、一個人ではできないし、蓄積された情報は財産という意識に変えることも難しい。


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

2025年12月 7日 (日)

grep考(2) <Excelで検索してみた>

grep考 <認識をアップデートする> (2025/12/1)
(https://yoshi-s.cocolog-nifty.com/YoshiNashi/2025/11/post-f2a0df.html)

で、「認識とスキルを現状に合わせてアップデートしなければならない」と書いた。
ログを解析する際に、従来から使われている grep より、今時は、Excelの方が良いのではないか、という趣旨だが、
憶測はよくないと思い、本当にExcelで検索してみた。
Grepvsexcelvspowershell

【結論を先に】
・検索対象が1048576行以下のファイル、読み込み時に1048576行以下に絞り込めるなら、Excelは便利
・grepをインストールするくらいなら、PowerShellで良くネ?

【サンプルデータ】
 ApacheのAccesslog 4837202レコード(1.1GB)
【PC】
 Windows11 RAM32GB (起動時に約18GB使用)
【Excel】
 Microsoft 365 Apps for enterprise
 Ver 2510(Build 19328.20190)

【手順】
「データ」→「テキストまたはCSVから」
「元ファイル:区切り記号」→「スペース」
 ・""で括られたデータは分割されない
 ・[]で括られたデータは分割されるので、時刻が日時とタイムゾーンに分割される

【制限】
・1シートの最大行は1048576行しか読み込めない
 読込む際にPowerQueryで日付などで絞り込んで 1048576行以下にすることは可能

【その他】
・PowerQueryのMコードで、タイムスタンプをExcelのシリアル値に変換することはできるが、テキストで読み込んでから関数で変換した方が簡単。
・自動的にテーブルに変換されるので、フィールド名(列名)を変更し、テーブル名を分かりやすい名前に変更する(access_log,access_log)と関数で参照する際に分かりやすくなる。

【抽出】
別シートで、抽出先の左上のセルに FILTER関数を入力することで、レコードが抽出される。
例: status列が200のデータを抽出、 2025/6/30 23:59:00~2025/7/1 00:00:59までのデータを抽出する例は、

=FILTER(access_log,access_log[status]=200) 
=FILTER(access_log, REGEXTEST(access_log[time], "(30/Jun/2025:23:59)|(1/Jul/2025:00:00)")) 

【メリット】
時間当たりのページごとのアクセス数の推移などの表やグラフが、Excelの機能を使用すると簡単に作成できる。

ところで、
ファイル内の文字列を正規表現で検索して出力するコマンドレットはPowerShellにもある。

【PowerShell】

Select-String -Pattern '<regex>'  -Path '<File path>'
[-CaseSensitive]
[-NoMatch]
[-Recurse]

PowerShellの正規表現はREPC2だから grep -E '<regex>' と同等の機能だ。
規定値で、Select-Stringは大文字小文字を同一文字として扱い、grepは異なる文字として扱う。
また、grepでよく使用するオプションと同じ機能のオプションスイッチがある。

-CaseSensitive → grep --no-ignore-case
-NoMatch       → grep -v
-Recurse       → grep -r

【オンメモリ処理】
PowerShellでオブジェクトとしてすべてのログをメモリーに読込こんでおくと、検索が速くなるのではないかと考えた。
PowerShellの正規表現で -matchを使用すると、名前付きキャプチャが使えるので、レコードをオブジェクトに変換できる。

$pattern ='^(?<host>\S+)\s+(?<ident>\S+)\s+(?<user>\S+)\s+\[(?<time>[^\]]+)\]\s+"(?<request>[^"]*)"\s+(?<status>\d{3})\s+(?<size>\S+)\s+"(?<referer>[^"]*)"\s+"(?<agent>[^"]*)"\s+"(?<extra>[^"]*)"'

で変数 $logに全てのデータを読み込むと、

$log | where {$_.status -eq "200"}
$log | where {$_.time -match "(Jun/2025:23:59)|(Jul/2025/00:00)"}

で検索・抽出できる。

一旦すべてのデータをメモリに読み込むので、検索は速くなる…と思いきや、速くならない。
タスクマネージャーでメモリ使用量を見ると、実メモリが足りずスワップしているようだ。
スワップしていると、select-stringでログファイルを毎回検索する方法と時間は変わらない。
(スワップしなければ速いはず)

【結論】
・検索対象が1048576行以下のファイル、読み込み時に1048576行以下に絞り込めるなら、Excelは便利
・grepをインストールするくらいなら、PowerShellで良くネ?



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

2025年12月 4日 (木)

さかなクン化 <儒烏風亭らでんの影響力>

【1日のPVが200超?】
Google Search Console Team から、直近28日間のPVが800を超えたというメールが来たので調べてみたら、
検索キーワード「らでん クラファン」の検索結果から、
東京国立博物館がクラウドファンディング <儒烏風亭らでんの目標> (2025/11/06)
へのアクセスが多いことが分かった。
20251202-101455

このページへのアクセス数の推移を見たら、1日のページビューが200を超えた日がある。
こんなにアクセスが増えたのは、googleさんのロボットが全ての記事を持っていったとき以来だ。

実際にこのキーワードで検索してみると、アクセスが増えたページが上位に表示されている。
インフルエンサーやgoogle 恐るべしである。
ログを見ると、平均滞在時間は4分だから、表示した人は読んでくれているようだ。(ちょっと嬉しい)

【儒烏風亭らでん氏の活動スタイル】
この記事の基となった、儒烏風亭らでん氏を知ったきっかけは、
儒烏風亭らでん 文化・美術への愛と知識があふれるV系噺家”. 日経クロストレンド. 日経BP.
で、記事を読んだ後に
新人VTuber 儒烏風亭らでん (2024/02/22)

「うまく売れると、さかなクン氏のようになるかもしれない。」
と書いた。
専門的な内容を易しく伝え、更に親しみやすい存在になれば、さかなクン氏のように唯一無二の存在になれると思ったのだが、予想を超えたインフルエンサーになった。

儒烏風亭らでん氏は、従来のVTuberのファン層以外の視聴者層もターゲットとした戦略が成功している。
専門分野は美術だが、分野を超えて、他の学術系VTuberとの交流も広いことが、ファンの拡大に成功しているようだ。

また、活動スタイルが、
「自分を好きになって💛」ではなく「美術を好きになって」のように感じることも、多くのファンを獲得している要因だと思う。
今回の東京国立博物館のクラウドファンディングでも、影響力を考えると、配信で協力を呼び掛けるだけでも、十分効果はあったのだろう。

しかし、自らも少なくない金額を寄付しているのを聞くと、年寄はつい、自分も一肌脱ごうと思うよねぇ。



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

2025年12月 1日 (月)

grep考 <認識をアップデートする>

結論を先に。
・認識とスキルを現状に合わせてアップデートしなければならない。
・正規表現は今でも重要だ。

Grepvsexcel

【ログ解析とgrep】
デジタルフォレンジックの現場において、ログを分析するためのツールとして、高機能な製品も増えてきた。
オヤジ世代にとって、欠かせないツールはgrepだった。
今でも、ログ解析の文脈でgrepの使い方を教えているのを見かける。

なぜ昔は、grepを使っていたかというと、調査対象のOSはUNIXが多く、grepが標準でインストールされていたし、
また、1行1レコードのログが多く、行志向のツールの方が使いやすかった、
という事情があったからだ。

【今時のログ解析】
今時は、大量のメモリを搭載した、WindowsPCで解析することが多くなったが、標準でgrepはインストールされていないので、grep.exeやgrep機能があるエディタをインストールしているようだ。

よく見ると、grepコマンド(機能)は使うけれど、多くは固定文字列の一致にしか使われていないようだ。
昔だったら「fgrepを使え!」と言われたところだ。

【正規表現】
grepの真髄はいうまでもなく、正規表現によるマッチなのだが、正規表現を学習していないのだろう。
研修で教える人も正規表現を教えないようだ。

正規表現が使えると便利な場面は、タイムスタンプが開始時刻と終了時刻に含まれる行を検索する場合だ。
(例えば、2025/6/30 23:59:00~2025/7/1 00:01:00)

昔の解析環境は搭載しているメモリが少なく、メモリ容量より大きなログファイルを検索する際に、複数回に分けて検索すると、時間がかかるし、テンポラリファイルを作るとストレージを圧迫するという問題があった。
だから、正規表現を使用して1回の検索で終わらせるテクニックは重要だった。

【今時の環境】
今時のPCは、多くのメモリ、大きなストレージを搭載しているので、ログをメモリに読み込んでから検索すると、複数回検索しても、それほど時間はかからなくなった。

デジタルフォレンジックの現場では、専用ツールが使用できないことがある。
そのような場合に、専用ツールを使わず、汎用的なアプリでログを解析するならば、Excelはかなり便利だ。

理由は、
・読み込めるデータ量が増えたので、ログを一度に読み込むことができる。(行数制限あり)
・テーブルに変換するとソート・フィルタ機能が使える。
・FILTER関数やXLOOKUP関数など検索・参照系関数を使うと、1つの式で複数のセルや行を返してくれるようになった。
・ログファイルを読み込む際にPowerQueryを使用すると時刻を文字列→シリアル値に変換できる。
・M365のExcelは正規表現関数を使用することができる
・M365のExcelはPY関数が使用できる(無敵だ!!)

ログを解析する場合は、検索機能は重要だが、ソートや重複排除、集計機能が必要で、grepコマンド(機能)を使っても、最後はExcelに読み込んで印刷することが多いなら、最初からExcelでやってしまえばよいと思う。

【結論】
20年くらい前は、ログ解析と言えばgrepだったけど、ハードウェアもソフトウェアも変わったから、現状で、何が最適かアップデートしなければならない。

20年前も今も重要な知識は正規表現だと思う。


fgrep:今時のPCではfgrepを使用してもあまり早くならない


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

« 2025年11月 | トップページ | 2026年1月 »