フォト

ウェブページ

無料ブログはココログ

携帯URL

ケータイ用アドレス
携帯にURLを送る

MyList

よしなしごと

2026年4月18日 (土)

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

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

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

Gemini_copilot_notebooklm_

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

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

とおっしゃる。

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

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

閑話休題

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

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

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

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

蛇足だが

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

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

2026年4月18日 (土) よしなしごと, ほぼ1人情シス, AI | | コメント (0)

2026年4月15日 (水)

「技術者でいたい」は甘えか? <管理者と技術者、どちらも現状に甘えることはできない>

技術者を管理職に出世させる愚かな日本企業、タコツボ組織がDXを阻む 木村岳史 日経 XTECH (2026.03.30)

木村岳史氏の名物コラム「極限暴論」としては、いつもの切れ味がないように感じた。

結論を先に、
管理者になるにしても、技術者でいるにしても、現状に甘えることはできない。
Photo_20260406132301

「『技術者でいたい。だから管理職にはならない』というのはプロの技術者として当然の思いだが、その希望を上司に伝えると『向上心が無い』と評価されるのではないか、との声あり。残念ながら、それは事実。他の仕事でも全く同じで、日本企業に共通する根深い問題」

という投稿は普通過ぎて面白くないと思っていたら、「ディスリ」が多く届いたらしい。

「管理職になりたくないというのは甘え」や「マネジメント適性がないので逃げているだけ」というコメントが多いらしい。

木村岳史氏は、
管理職は技術職とは別の能力が必要な仕事だが、日本の組織に根強く存在する、年功序列や歪んだ実力主義の影響で「努力すれば誰でもできる仕事」という認識があることを指摘している。

そして最後に、

「技術者でいたい。だから管理職にはならない」に強く賛同してくれた人にも言っておくよ。
あなたが技術者ならば、現状に甘えていては駄目だな。最後まで読んでくれたのだから、その意味は分かるよね。

とある。ここが、最も言いたいことだろう。
冒頭で切れ味が悪いと思ったと書いたが、、最後に白刃を突き付けられるような鋭さがあった。

「管理職になりたくない」と「甘え」
「管理職になりたくない」を「甘え」と批判されないためには、技術者としての能力を維持し続ける必要がある。
また、最低でもセルフマネジメント、そして、チームやプロジェクトがマネジメントできる能力が必要だ。
それができなければ、終身雇用を利用した「甘え」という批判はやむを得ない。

つまり、管理職にならず、技術者でい続けるためには、「技術者としての能力を維持し続けること」「マネジメント能力を持つこと」が必要だ。
「管理職になりたくない」 が批判されるのは、「甘え」や「マネジメント能力」がない「技術者くずれ」が多いのかもしれない。

結論
管理者になるにしても、技術者でいるにしても、現状に甘えることはできない。

「技術者くずれ」
「技術者くずれ」になる原因は以下の特徴がある。

  • 技術の進歩について行けなくなった者
  • 「マネジメントで食っていく」決心がない者
  • 客観視（技術の翻訳）ができない者

については過去の記事を参照されたい。

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

2026年4月15日 (水) よしなしごと | | コメント (0)

2026年4月11日 (土)

エンジニアの想像力のなさに落胆　＜歴史は繰り返す＞

正直、エンジニアの想像力のなさにちょっと落胆してる

ちょっと刺激的なタイトルだ。
投稿主は、情報科学系の方らしい。
この投稿に対して、技術系の人たちは概ね否定的だ。

【プログラミング】
未だに「プログラミング」≒「プログラミング言語」と考えている人は多く、エンジニアも例外ではないのだろう。
現在、.md + Claude　を使用してシステムを開発した場合、仕様が満足できなかったり、製品の保守性が維持できないという指摘はある。
特にシステムを開発の現場にいるエンジニアは、そう感じるのだろう。
しかし、多くの問題は、時間が解決することは歴史が証明している。

昔々、高級言語だけでは解決できないから、アセンブラ(機械語)の理解は必要だよねという議論があった。
デバイスドライバーなど低レイヤを扱う場合はアセンブラが必要だった、と言っても信じられない人も多いだろう。

【抽象化してみる】
技術系の人の反対投稿を読むと、「.md」や「Claude(生成AI)」など、今目に見える物に反応しているように感じる。

コンピュータに対する指示を、

人間の指示 → I/F → コンピュータ

とすると、これまで、長い期間、

プログラミング言語 → 処理系 → コンピュータ

という構成だった。

「処理系」は、　アセンブラ、コンパイラ、インタプリタ、フレームワークなど変化している。
「プログラミング言語」も変化しているが、人間が話す自然言語ではなく、制約が強い形式言語を使用している。

ところが、AI技術の向上で、

自然言語 → AI → コンピュータ

という構成が可能になった。

自然言語と形式言語では大きな差がある。自然言語は習得しなくて良いのだ。(論理的思考は必要だ)
つまり、形式言語(プログラミング言語)の習得が障壁だった人でも、コンピュータに指示が与えられるようになるという意味で、革命的だ。

【論理的思考】
当面、論理的思考は必要だが、
自然言語で論理的思考ができて、論理的な文章で指示を与えられるならば、形式言語は不要だろう。

しかし、今現在では、多くの人が、自然言語による指示は困難だ。
そこで、習得が容易なMarkdown記法を使用して、指示することが効率が良いということだろう。

Markdown記法の使用が、論理的思考を助けるという効果もある。

今後、AIの性能が向上したり、AIに代わるI/Fが登場すれば、Markdown記法より習得が簡単な言語になったり、自然言語で指示が与えられるようになるのだろう。

【創造力】
論理的思考能力で解決できる課題は多いが、創造力が必要な課題もある。
AIが自然言語で指示できるようになった。
そこで重要な能力は、創造性を言語にする能力だ。
例えば、頭の中でイメージした「もの」「こと」「感覚」を自然言語に変換できれば、AIに入力できるようになる。
この能力を持っている人はいると思うのだが、効果的な方法論は無いようだ。

###
自称技術屋だけど、事務処理でも .md + 生成AI は最強だと思う。

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

2026年4月11日 (土) よしなしごと, AI | | コメント (0)

2026年4月 8日 (水)

BSOD　＜SSDが原因のようだ＞

6年くらい使っているPC(HP Pavilion 15-cu1013tx)が、1年くらい前からBSOD(Blue Screen of Death )が発生するようになっていた。
修復コマンドで修復しても効果はなく、騙し騙し使っていた。
Ssd

【原因究明】
このPCは6年前に買って、
Windows7 32bit → Windows7 64bit → Windows10 → Windows 11にアップデートしてきた。
4年前に、SSDを128GB→500GBに、 メモリを16GB→32GBに換装している。

1か月前くらいから、BSODが頻繁に発生するようになったので、MinidumpをAIに分析させて、要因を1つずつ潰していったが、それでも、BSODの発生は止まらなかった。

アップデートを重ねているから、古いドライバーや不要なドライバーがインストールされていた。

【 Windows再インストール】
AIもとうとう諦めて、Windowsの再インストールを勧めてきたので、しかたなく、Windowsを再インストールした。
HPのサイトにあるドライバーは古いので、チップメーカーを回ってドライバーをダウンロードした。

これで安定すると思っていたら。
Windowsを再インストールする前と変わらない頻度でBSODが発生する。
最近のエラー画面は青ではなく黒だ。

【SMART】
SSDメーカーのツールでSSDを調べたら、ファームウェアは最新でSMARTも正常だったが、エラーがたくさん記録されていたので、SSDを交換することにした。
今のところエラーは発生していない。

CrystalDiskInfoで、SMART レポートを取得してみた。

----------------------------------------------------------------------------
(03) CT500P2SSD8
----------------------------------------------------------------------------
Model : CT500P2SSD8
Firmware : P2CR033
Serial Number : 2116E597845A
Disk Size : 500.1 GB
Interface : UASP (NVM Express)
Standard : NVM Express 1.3
Transfer Mode : ---- | ----
Power On Hours : 9165 時間
Power On Count : 4995 回
Host Reads : 17359 GB
Host Writes : 29032 GB
Temperature : 48 C (118 F)
Health Status : 正常 (84 %)
Features : S.M.A.R.T., TRIM, VolatileWriteCache
Drive Letter : F:
-- S.M.A.R.T. --------------------------------------------------------------
ID RawValues(6) Attribute Name
01 000000000000 クリティカルワーニング
02 00000000013C 温度
03 000000000064 予備領域
04 000000000005 予備領域 (しきい値)
05 000000000010 使用率
06 0000022B8002 総読み込み量 (ホスト)
07 000003A10727 総書き込み量 (ホスト)
08 0000208E82D0 リードコマンド数 (ホスト)
09 00004817B4CE ライトコマンド数 (ホスト)
0A 000000002A21 コントローラービジー時間
0B 000000001383 電源投入回数
0C 0000000023CD 使用時間
0D 000000000204 アンセーフシャットダウン回数
0E 000000000000 データエラー回数
0F 000000003061 エラーログエントリー数

エラーログエントリー数と安全でないシャットダウンが多数記録されている。
このSSDはSMART的には、今のところ正常だが、今後エラーが多発する可能性がある状態という診断結果だ。
SSDを交換して以来、BSODは発生してないので、SSDが原因だろう。

【学び】
AIの診断は、可能性が高い順に要因を出力するけれど、可能性が低い要因が原因だった。
SMARTの「正常」という文字に惑わされず、エラーログの数値を見極めることの難しさを痛感した。

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

2026年4月 8日 (水) よしなしごと, AI | | コメント (0)

2026年4月 5日 (日)

読めない専門用語

Xでこんな投稿が流れてきた。

 

1. あしんく
2. あいとりぷるいー
3. えんじんえっくす
4. ??
5. くーばねてぃす
6. しーえっちおうん/ちぇんじおうん
7. ざっしゅ
8. あじゅーる
9. すーどぅー(すどー)
10. らむだ

※ちなみに、Linux は「りぬくす」

「a11y」
が読めなかった。
「a11y」や「k8s」のような略し方を見たのは、30年くらい前に、「l9n」や「i10n」で知った。
当時、アプリのローカライズやそれを発展させたインターナショナリゼーションが話題になっていたので、ざっしの記事で見かけた。
堅い記事では「現地化」とか「国際化」と記述されていたが、柔らかい記事では、「l9n(Localization)」「i18n(internationalization)」などと記述されていていたように記憶している。

「chown」

は、はファイルの所有者を変更するUNIXのコマンドで、「しーえっちおうん」とか「ちぇんじおうん」と読んでいる。
UNIXはコマンドやシステムコールを短縮してあるしてあるので、初見では読めないことがよくある。
読めなくても、適当に読んでいるから、方言がたくさんある。

「cd」

10選にはないが、cd(しーでぃー) はカレントディレクトリを変更するコマンドで、Change Directory を省略している。
MS-DOSやWindowsでも同じコマンドが実装されていて、コンソールを使用する場合は、必須のコマンドだ。

cd を動詞的に使用することがある。
「zipを解凍して、そのディレクトリに、しーでぃーして」などと使うことがある。

前提として、
・ファイルシステムのツリー構造
・ワーキングディレクトリ
・絶対パス/相対パス
の知識が必要だ。
この操作を、普段CLIを使わない人向けの説明書で説明しようとすると面倒だ。
最近は、画面キャプチャを貼って、説明を減らしている。

【初心者でも読めばわかる】

「初心者でも読めばわかるような(ニワトリでもわかる)手順書を」要望されることは多いのだが、極めて難しい。
要望する人は、理解していれば、それをニワトリでもわかるように説明することができると思っているのだ。
これらに必要な能力は、まったく別物だと説明するのだが、なかなか理解してもらえない。

フリーソフトを配布していたころに、この問題で困っていた。
詳しく書けば分かりやすいとは限らないし、文字数が増えると、そもそも読んでもらえない。
そこで、分からなくても、手順書のとおりに入力したら最低限使える説明と、ソースを読む際に参考になる解説に分て、解説は、自分と同じくらいの知識がある人を対象に、ちょっと丁寧に書いていた。

【本当の問題】
ニワトリでもわかる手順書は、本当の問題にならない。
ニワトリでもわかる手順書が必要な人は、ちょっとしたトラブルに対応できないことが多いからだ。

職業プログラマーではなく、「ほぼ1人情シス」だから、現場で作業を効率化するくらいのツールを作ることが多い。
そのツールを他の人が使えるようにと、ニワトリでもわかる手順書を書いたとしても、トラブル対応が減らないとしたら、自分の仕事は効率化できていない。

ICTで効率化したいならば、そもそも、トラブル対策が必要なツールと「ニワトリでも分かる説明書」で一時しのぎせず、システムを外注すれば良いと思う。

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

2026年4月 5日 (日) よしなしごと, ほぼ1人情シス | | コメント (0)

2026年4月 2日 (木)

Azki 香川県警交通安全アンバサダー就任 ＜開拓者の目の付け所＞

香川県警察交通安全アンバサダーに VTuberのAzkiさんが任命されたそうだ。

Azkiさんの配信で就任の経緯を聞いたら、香川県警察本部交通規制課に「開拓者(Azkiさんのファンの総称)」がいて、Azkiさんの起用を企画したらしい。
役人は新しことに消極的な人が多いが、運よく「開拓者」の上司の課長が「アニオタ」で理解が得られたらしい。

【開拓者の目付け所】
この「開拓者」は目の付け所が良いと思う。
最近は、観光大使や、VTuberを起用することが多くなったが

Azkiさんのイメージは、

  • 知的
  • 落ち着いた雰囲気
  • 親しみやすいビジュアル
  • 人型モデル
  • 大手事務所所属

つまり

  • ★炎上しそうにない
  • ★広い年齢層に受け入れられそう
  • ★役所の事務手続ができそう

見た目は尖っていないが、知名度があり、不安要素が無く、役所との契約ができそうなところが起用しやすかったのではないだろうか。

・VTuberになじみがない人は、獣耳のモデルに違和感がある人もいるかもしれないが、Azkiさんは初期から人型モデルだった。
・第1世代、第2世代の衣装は、露出が多く尖ったアーティストという雰囲気があったが。第3世代のアイドルっぽい衣装を経て、現在の衣装になり、活動も歌だけでなく、「地図のお姉さん」「魔王」など知的なイメージが定着してきた。
・大手VTuber事務所所属だから、マネジメント部門がある。

結果的には、VTuber界隈での知名度により、ネットのニュースにも取り上げられていたので、広報としては成功だろう。

それはさておき、企画した「開拓者」は役得だなぁ

警察関係のでは、根間ういさんが、2025/1/29に沖縄県警のバーチャル広報官に任命されている。

最近の投稿

2026年4月 2日 (木) よしなしごと, Vtuber | | コメント (0)

2026年3月30日 (月)

ちゅむステ　＜ChumuNoteの大きな1歩＞

VTuberのChumuNoteさんが企画主宰する音楽番組「ちゅむステ Page1」と振り返り配信を見た。
「ちゅむステ」は ChumuNoteさんが、会社(MOLA STUDIO)を設立する前に、活動の1つとして挙げていたので楽しみにしていた。

VTuberの３D音楽番組を素人がいちから作ってみた感想【MOLA STUDIO】(https://youtu.be/a6cVlsJuAGo)

【振り返り配信】
スケジュール調整や動画編集、カメラマンなど、ChumuNoteさんの負担が大きいようだ。
小さい会社だから、しかたないところではある。
しかし、ChumuNoteさんが多才であっても、時間は有限だから、多くの仕事を兼務するのは難しいかもしれない。

★ とはいえ、会社(MOLA STUDIO)設立当初の目標だった、音楽番組を配信できたことは大きな一歩だと思う。

出演者によるコラボコーナーがあると良いと思う。
実現しようとすると、出演者やスタジオ、スタッフのスケジュール調整や稼働時間が増える。
多くの問題は、金銭的に解決できそうだけど、こればかりは実績を積み重ねるしかないだろう。

【ちゅむステ】
出演者は、主催者ピックアップ枠が2名、公募枠が1名で、出演者が、次にどのような出演者を推薦するかを指定してバトンをつなぐ方法だ。

XIDENさん(RK Music)の出演が公開されたときに、大手事務所に声をかけたのかと思ったら、XIDENさんは公募枠だったらしい。
そして、次の公募枠の指定は、「ダンスができる人」だった。

ダンスといえば、奏みみさんだよな!
と思うけれど、視聴者によるリクエストではなく、演者が応募する決まりだから、なんとかなるものではないけれど。

★ 奏みみさんがTubeout vol3への出演を機にに活動が広がったように、新人VTuberが、実績があるVTuberと共演することで、ブレークするような番組になるればよいと思う。

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

2026年3月30日 (月) よしなしごと, Vtuber | | コメント (0)

2026年3月27日 (金)

再発防止策 ＜弱い組織がわかる＞

エンジニアなら知っておきたい障害報告&再発防止策の考え方 Qiita (2024/11/27)

昔いた職場で、事故防止に取り組んで、2018年から断続的にブログの記事も書いているので、Xで流れてきた記事にひっかかって読んだ。

【先に結論を】
防止対策は事故防止のごく一部だが、防止対策を読むとその企業や組織の風土が透けて見える。

重要なことは次の2点だ。
防止対策を実行すると事故が減るのか
そもそも実行できるのか

事故が減るなら、防止対策がカッコ悪くても良い。
Photo_20260318163101

投稿者の広木大地氏は、悪い再発防止策として、

  1. 責任回避のため稟議、決済経路を追加する策
  2. 他者の努力／忍耐／根性の不足を指摘し改善を求める策
  3. 個人／チームの注意力を原因とし、「より注意深く確認します／させます」といった策
  4. それっぽい言い訳付きのダブルチェック/トリプルチェック体制
  5. ドキュメントにその旨追記します！的な解決策

を挙げておられる。
そして、

「ちゃんと」「しっかり」というフレーズが出てきたら、危険信号です。

とおっしゃる。禿同である。

再発防止策はどの業種でも参考になるだろう。
防止策について書いてみる。

【防止策】
事故防止の研修で教えてもらった効果のない対策は、

  • 周知徹底
  • 教育
  • ダブルチェック
  • チェックリスト

だった。

これらの対策は、「気合と根性」が大好きな人が挙げやすく、現場で本当に実施できるかまで考えられていないことが多い。

事故の報告書を読むときは、後の方に書いてある防止策を最初に読むようにしている。
対策がこの4項目だったら、その報告書は読む価値はないことが多い。
「これくらい書いておけばいいでしょ」という姿勢が透けて見えるのだ。

【NGワード】
次の語句が目立つ防止策は効果がないことが多い。

・「確実に」「徹底的に」
防止対策を書いた人が、そう思っているだけで、具体性のない文言は、実行されない。
政治家が使う、「しっかり」「きっちり」と同じで、実現しないのだ。

・「させる」
例えば、管理部門が現業部門に対して行動を求めるときなどにこの表現になることが多く、原因は自分以外の第三者にあると結論付けていることが多い。
第三者に行動を求めるのは簡単だが、自分が行動するのは難しい。
つまり、防止対策を書いた本人は防止策を実行しないということだ。

・「べき」
行動ではないので論外だ。

【第三者が書いた対策】
原因の分析は第三者でも可能だ。
第三者は、客観的に事実ベースで分析しやすいし、人間関係などのしがらみを排除できる。
一方、当事者は、主観的になりやすく、無意識に責任を回避しようとするから、原因の分析は難しい。
しかし、当事者でなければ、特定できない、本当の原因があるものだ。

第三者が書いた対策案は参考にならないことが多い。
分析や提案内容が的確でも、所詮自分の行動ではないので、綺麗事臭が漂うのだ。
だから、第三者が書いた提案を丸パクリしているような防止対策は、実行されない。

防止対策は、当事者が実行できることが大前提だから、当事者が考えなければならない。

【結論】
防止策は事故防止のごく一部だが、防止策を読むとその企業や組織の風土が透けて見える。

重要なことは次の2点だ。

  • 防止対策を実行すると事故が減るのか
  • そもそも実行できるのか

事故が減るなら、防止策がカッコ悪くても良い。

過去に書いた、事故防止に関する投稿

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

2026年3月27日 (金) よしなしごと | | コメント (0)

2026年3月26日 (木)

アルゴロジック ＜科学的方法とそっくり＞

　アルゴロジックで問題をクリアしていく手順は、実は科学者が新しい発見をしたり問題を解決したりする時に使う「科学的方法」と、そっくりです。

Photo_20260319184201

それぞれのステップを比べてみましょう。

科学的方法のステップ アルゴロジックでの行動

1. 問いを立てる（観察・疑問）

「なぜ？」と疑問を持ち、問題を明らかにします。

問題を理解する

「どうすればロボットが旗を取れるか？（クリアできるか？）」という目的を明らかにします。

2. 仮説を立てる（予想）

「こうすれば解決できるのでは？」と予想します。

やり方（手順）を考える

ロボットをどう動かすか、命令を並べて手順を組み立てます。

3. 実験（確かめる）

仮説(予想)が正しいか、実際に試してみます。

プログラムを実行する

「実行」ボタンを押して、ロボットを動かしてみます。

4. データ収集・観察

実験の結果をありのままに観察し、記録します。

ロボットの動きを見る

ロボットが予想通り動いたか、どこで止まったか、または失敗したかをじっと見ます。

5. 振り返り・良かったか悪かったかを考える（結論）

結果を分析し、仮説(予想)が正しかったか判断します。

原因を考える（間違いを見つける）

失敗した場合、「なぜそこで間違えたのか？」「どの命令が違ったのか？」を考えます。

6. 改善（何度もやり直す）

分析結果にもとづいて、仮説(予想)や計画を直し、もう一度試してみます。

プログラムを修正する

間違っていた命令を入れ替えたり、順番を変えたりして、もう一度実行します。

最も重要なステップは

どちらも、全てのステップが大切ですが、あえて一つ選ぶなら、「仮説を立てる（アルゴロジックでは手順を考える）」ステップが最も重要です。

なぜなら、当てずっぽうにやってみる（実行）のではなく、「こうすればできるはずだ」という予想（仮説）があるから、失敗した時に「なぜ失敗したのか」が分かり、次にやってみるときの改善につながるからです。

このように、アルゴロジックの問題にチャレンジすることで、科学的な考え方のトレーニングになっています。
ぜひチャレンジしてみましょう

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

2026年3月26日 (木) ICT×教育, よしなしごと | | コメント (0)

2026年3月23日 (月)

AI-Ready ＜課題は技術ではなく人的組織的＞

【迷惑メール】
問い合わせ窓口用に公開しているメールアドレスがある。
そのメールアドレスに届くメールの90％は、迷惑メールで、本当の問い合わせ案件のメールが埋もれてしまう。

更に、最近の迷惑メールは巧妙になっていて、一見すると見分けがつかないので、フィッシングメールをつい開いてしまう危険性もある。
Agent

【Agent】
そこで、問い合わせ窓口宛てのメールを判定するAgentを作成してみた。
Agentのお題としてはよくあるお題だ。

メールの着信をトリガーにして、迷惑メールか否かを判定し、SharePointのリストに登録して、共有するようにした。

迷惑メールの定義をざっくり与えたら、
・スパムメール
・フィッシングメール
・DM
を迷惑メールとして判定しているようだ。

ウイルス付きメールや危険なリンクを含むメールはメールシステムがブロックしたり、迷惑メールフォルダに振り分けるので、ユーザーのメールボックスに配送されるメールを対象にしている。

当初、使用していたAIのモデルは、かなり緩い判定をしていた。
同じモデルを使用しているAI-Chatに与えた結果と違うことが多かった。
また、プロンプトで詳細に指示しても反映されないことも多く、回答が得られないこともあった。

GPT-5に変わってから、判定精度が上がって、プロンプトの指示が反映されるようになった。

そこそこの精度になったので、
次のアクションとして、問い合わせメールの場合は、返信の下書きを生成させてみた。
これまでの返信から作成した返信テンプレートと、問い合せメールを与えると、下書きを作成してくれる。

ここまでできたら、
担当者に、下書きと問合せメールの着信を通知して、
・必要であれば、回答する人が下書きを修正して、
・管理者が承認したら、
回答メールを送信するところまで実装できそうだ。


ところがである。
困ったことに、誰に通知すればよいかわからない。
問い合わせを処理する人は、その都度変わるから、自動化できないのだ。

【AI-Ready】
AIを活用するためには、AIが使用できるようなデータが必要と書いた。
AIが使うデータだけでなく、AIが適用できるワークフローも必要だ。
人間が処理することを前提に作成されたExcelや、その都度、指示を受けて人が処理している作業は、AIで効率化できない。

つまり AI-Readyではないのだ。

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

2026年3月23日 (月) よしなしごと, ほぼ1人情シス, AI | | コメント (0)

より以前の記事一覧

その他のカテゴリー

AI DX Excel ICT×教育 Vtuber ほぼ1人情シス よしなしごと 働き方改革 展示会 日記・コラム・つぶやき 映画・テレビ 書籍・雑誌 研修 転職