Grayrecord Technow

会社のメールボックスに届いたメールを見ていて、おかしなものを見つけてしまいました。Vivaldiの表示を見ると一年後になってる。そして、それ以外にもいろいろとおかしなところがある。 「 見どころ 」ポイント Dateヘッダーの怪 : 未来(2027年)からの送信と言う、メーラのソート順をかき乱す禁じ手。 alt属性の罠: 画像ブロック機能によって、隠していた「 2年前の使い回し 」が露呈する恐怖。 Vivaldiのプライバシー保護機能（画像読み込みブロック）が、図らずも企業の怠慢を暴き出すデバッガーとして機能してしまった瞬間です。 タイムトラベルするDateヘッダー まず、Date ヘッダーが 2027年 になっている点です。現在は2026年1月。 これをやられると、常にメーラーのリスト最上部にこのメールが居座ることになります。スパム業者がよくやる手口ですが、まさかテック企業を名乗る会社のニュースレターでこれを見るとは思いませんでした。 送信サーバーの設定ミスなのか、テンプレートの更新忘れなのかは不明ですが、受信者の体験を著しく損ねています。 alt属性に刻まれた「2024」の真実 そしてさらに衝撃的だったのが、画像の alt 属性（代替テキスト）です。 画像が表示されない状態でそこにあったのは、「 2024年賀状 」という文字。 2026年の正月に、2027年の日付で、2024年の挨拶が届く。 これが意味することは単純です。 「2年前のHTMLメールのテンプレートをコピーして、画像だけ差し替えて送信した」ということです。 画像のリンク先や src は変えたものの、目に見えない alt 属性の書き換えを怠ったのでしょう。 表面しか見ない「テック」企業 こういうことをやってしまうと、信頼性に大きな傷がつきます。 アクセシビリティの軽視: alt 属性は画像が見えない人（視覚障害者や、通信環境が悪い人、画像をブロックしている人）のための重要な情報です。そこに嘘（2年前の情報）を書くということは、そういったユーザーを切り捨てていると言っても過言ではありません。 技術力の欠如: 自動化されたテストや、送信前の基本的なQA（品質保証）プロセスが存在しない、あるいは機能していないことを露呈しています。 ブランドへのダメージ: 「表面の見た目（HTML画像）さえ整えれば中身（Dateやalt）はどうでもいい」という姿勢は、製品やサービスの品質そのものを疑わせます。 正直、がっくり来ました。営業メールだとしても、技術を売りにする企業からこんなものが届くと、武士の情けで社名は出しませんが、その会社の技術力もお里が知れるというものです。正月早々に開いた口がふさがりません。 教訓: メールの送信ボタンを押す前に、必ずテキストのみのモードや画像オフのモードでプレビューしましょう。そこには、あなたが隠したつもりの「恥」が残っているかもしれません。

図書館から、『Gemini完全マニュアル』を借りてきました。前から、予約リストに放り込んであったのですが、順番が来たので。そして、借りてきて秀和システムのロゴを見た瞬間に思いました。あ、これ、秀和システムの遺品だって。 基本的には、「できる」のような類の普通の解説本ですね。 3章までの目次は以下のようになっています。 1章 Geminiとは 2章 Geminiをはじめる 3章文章を編集する 文章を要約する 長い文章を箇条書きにする 文章からQ&Aを作成する 長い文章を表にまとめる 箇条書きのメモから議事録を作成する -文章の難易度を変える など その意味では、割と普通の本です。JulesとかNotebook LMとかにも特に触れていません。しいて言うと、Gemini Advancedとなっているのが、時の流れを感じますね。 今となっては、歴史書というか、Gemini 1.0というのがもう時間がたっていますね。 そういえば、こんなだったねという感じですね。

AIモデルの性能評価や、新しいアルゴリズム（例えば以前取り上げたSVG: Support Vector Generationなど）の実験において、適切なデータセットの選定は極めて重要です。今回は、私がソフトウェアエンジニアリング領域の自然言語処理（NLP）タスクでベンチマークとして愛用している「PROMISE Dataset」について、その構造とAIモデルでの活用実験の経験を交えて紹介します。 PROMISE Datasetとは 私がよく利用しているのは、Software-Requirements-Classification リポジトリに含まれている PROMISE.CSV です。 元々は PROMISE Software Engineering Repository で公開されていたもので、ソフトウェア要件定義書のテキストデータと、それが「機能要件」か「非機能要件」か、さらに細かい分類ラベルが付与されたデータセットです。 データの構造とクラス定義 このデータセットは主に以下の構成になっています。 Project ID: プロジェクトの識別子 Requirement Text: 要件のテキスト（例: “The system shall refresh the display every 60 seconds."） Class: 要件の分類クラス クラス分類は以下の4つが主要なラベルとして使用されています。これらは要件エンジニアリングにおける古典的な分類に基づいています。 F (Functional Requirement): 機能要件。システムが「何を」するか。 PE (Performance): 性能要件。非機能要件の一種。 LF (Look-and-Feel): 外観・操作感。UI/UXに関わる非機能要件。 US (Usability): 使用性。使いやすさに関わる非機能要件。 graph TD Req[Software Requirement] Req --> F[Functional (F)] Req --> NF[Non-Functional] NF --> PE[Performance (PE)] NF --> LF[Look-and-Feel (LF)] NF --> US[Usability (US)] NF --> Other[Other NFRs...] AIモデルによる実験：LLM vs SVG 私はこのデータセットを用いて、いくつかのAIモデルのアプローチを試みてきました。 ...

BLOGのアーティクルにOGPイメージは必要と思えたので、Hugo の OGP 画像を自動生成できる「tcardgen」を試したを参考にしています。実際、yamlの設定などは全く同じですし。違うとすれば、Windows環境なのでスクリプトをCMDのバッチファイルにしているくらいですね。 使用しているスクリプトはcovergen.batいう名前で内容は以下の通りの簡単なものです。 tcardgen -f tcardgen\fonts\ -o static\images\ogp\ -t tcardgen\template.png %1 OGP画像の配置先とか、そんなくらいですね、違うのは。テンプレートの画像は適当に作ったものです。

なか2656氏のブログ記事「AIで離職予兆を可視化するFreeeサーベイを個情法・AI事業者ガイドライン等から考えた」を読んだ。 これはなかなかに酷い。頭の中でサムライスピリッツの覇王丸の「あったまきたぜ」が響き渡るくらいに。 これは、新たなリクナビ事件だ。いや、雇用関係という逃げ場のない檻の中で行われる分、さらに悪質と言っていい。 正直、少し考えただけでも、 個情法には明白に抵触 OECDの原則には明白に背信 ISMSに抵触 労働契約法への抵触 と、論点がボロボロと出てくる。これは単なる「不備」ではない。「背信」だ。 怒りの根源：法的・倫理的な4つの背信 1. 個人情報保護法（APPI）：騙し討ちのデータ収集 最も許しがたいのは、その「欺瞞」だ。 第20条（適正な取得）: 「偽りその他不正の手段」による取得は禁止されている。「匿名です」「安心してください」と従業員を信じ込ませて本音を引き出し、裏ではしっかり個人識別子（従業員ID等）と紐付けて離職リスクを算出している。これを「不正の手段」と呼ばずして何と呼ぶのか。詐欺的行為そのものだ。 第18条（利用目的の通知等）: 「組織改善のため」という美辞麗句の裏で、「危険分子の特定」を行っている。目的外利用（第16条）であり、明確なルール違反だ。 2. OECD AI原則：国際的価値観への冒涜 世界が必死に守ろうとしている「人間中心」の価値観に対し、このシステムは泥を塗っている。 原則1.2（人間中心の価値観と公平性）: 人権と自律性の尊重？ 笑わせる。「匿名」と嘘をついて内心を探る行為のどこに「尊重」があるのか。 原則1.3（透明性と説明可能性）: 従業員は「自分のどの回答が『離職予備軍』というレッテル貼りに使われたのか」を知らされない。完全なるブラックボックスによる密室裁判だ。 3. ISMS（情報セキュリティ）：セキュリティの自殺 ISMS（ISO/IEC 27001）の観点から見ても、これは「セキュリティ事故」レベルの欠陥だ。 機密性（Confidentiality）とは、「認可されていない人間に情報を見せない」ことだ。 認可の不一致: 従業員は「統計データ」としての利用には同意したかもしれない。だが、「生殺与奪の権を握る上司への密告」には同意していない。 アクセス制御の無効化: 本来、「匿名化」という不可逆な壁があるべき場所に、意図的な「バックドア」を設置している。セキュリティポリシーをシステム自らが破っている。これは技術的な欠陥ではなく、設計思想の腐敗だ。 4. 労働契約法：信義則違反 第3条第4項（信義誠実の原則）: 「労働者及び使用者は、信義に従い誠実に…義務を履行しなければならない」。 従業員の「匿名だから言える」という信頼を逆手に取り、監視と選別の道具にする。これが「信義誠実」なわけがない。これは明白な裏切り行為だ。 リクナビ事件の「本質」との不気味な一致 2019年、リクナビ事件で個人情報保護委員会が断罪したのは何だったか。 「本人が予期しない目的で、個人の不利益になり得るスコアリングを行い、それを売り飛ばした」 ことだ。 今回のケースも、構造は全く同じだ。 項目 リクナビ事件 freeeサーベイ（懸念） 表向きの顔 就職活動の支援 従業員のSOS検知・ケア 裏の顔 内定辞退の予知（企業防衛） 離職予兆の検知（企業防衛） 手口 Web閲覧履歴からのスコアリング アンケート回答からのスコアリング 罪深さ 学生（まだ入社していない） 従業員（生殺与奪の権を握られている） リクナビ事件は「まだ逃げられる」学生が対象だった。今回は「逃げ場のない」従業員が対象だ。権力勾配を利用している分、こちらの方が遥かにタチが悪い。 freeeサーベイは「処遇AI」の本丸である 高木浩光氏の指摘通り、これは間違いなく 「処遇AI（Treatment AI）」 だ。 生成AIの著作権問題なんて、極論すれば「金」の話だ。解決策はある。 だが、処遇AIは「人の人生」を扱う。 「あいつは辞めそうだ」というAIのレッテル一枚で、不当な配置転換や冷遇が行われるかもしれない。しかも、本人はその理由を知る由もない。「匿名」という嘘でプロセスが隠蔽されているからだ。 決定の適切性も、異議申し立ての機会も、全てが闇の中だ。 ...