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のレッテル一枚で、不当な配置転換や冷遇が行われるかもしれない。しかも、本人はその理由を知る由もない。「匿名」という嘘でプロセスが隠蔽されているからだ。 決定の適切性も、異議申し立ての機会も、全てが闇の中だ。 ...

2023年にリリースされた書籍「実践Julia入門」は、科学技術計算の領域で注目を集めるプログラミング言語 Julia の包括的な解説書です。本記事では、この書籍のレビューを通じて、Juliaがなぜ「 貪欲な言語 」と称されるのか、その魅力と強力な機能について探っていきます。 なぜ今、Juliaなのか？ Pythonの 手軽さ とC言語のような 実行速度 を両立させることを目指して開発されたJuliaは、特にデータサイエンス、機械学習、数値計算の分野でその真価を発揮します。動的言語でありながら、JIT (Just-In-Time) コンパイラによって高いパフォーマンスを実現。それでいて、数学的な記法に近い直感的な構文は、研究者やエンジニアがアイデアを素早くコードに落とし込むことを可能にします。 本書は、そんなJuliaのポテンシャルを最大限に引き出すための知識が凝縮された一冊です。 書籍「実践Julia入門」の概要 本書は「入門編」「基本編」「実践編」の3部構成となっており、初学者から実務でJuliaを活用したい中〜上級者まで、幅広い層を対象としています。以下にその広範な内容を示す目次を掲載します。 【入門編】 第1章 Juliaのインストールと開発: Juliaの基本的な特徴から、REPL、JupyterLab、各種エディタでの開発環境構築までをカバーします。 第2章 Juliaの基本文法: 変数、演算子、関数、制御構文といったプログラミングの基礎を学びます。 【基本編】 第3章 Juliaの標準ライブラリ関数: 豊富な標準関数やライブラリの使い方を解説します。 第4章 型システム: Juliaの柔軟かつ強力な型システムの概要、パラメトリック型、ユーザ定義型などを掘り下げます。 第5章 多重ディスパッチ: Juliaの最たる特徴である多重ディスパッチの概念と、ポリモーフィズムや演算子オーバーロードといった実用例を詳解します。 第6章 イテレーション: Juliaにおけるイテレーションの仕組みと、カスタムイテレータの実装方法を学びます。 第7章 ブロードキャスティング: . 構文を用いた効率的な要素ごとの演算（ブロードキャスティング）の仕組みと応用を解説します。 第8章 メタプログラミング: マクロや生成関数など、コードを生成するコードを書くための高度なテクニックを紹介します。 第9章 並行・並列処理: タスク、スレッド、マルチプロセスを活用したハイパフォーマンスコンピューティングへの道筋を示します。 第10章 パッケージマネージャ: 依存関係の管理や環境の再現性を保つためのパッケージマネージャの利用法を解説します。 【実践編】 第11章 数値計算: NLsolve.jl や DifferentialEquations.jl を用いた、非線形方程式や常微分方程式の解法を実践します。 第12章 データ解析: CSVやDataFrames.jlを使ったデータの読み込みから、基本的な統計処理までの一連の流れを追体験します。 第13章 機械学習: MLJ.jl や Flux.jl といったフレームワークを使い、Juliaでの機械学習パイプライン構築を学びます。 Juliaの”貪欲さ”を支える核心機能 本書の白眉は、単なる文法解説に留まらず、Juliaを特徴づける核心的な概念に深く踏み込んでいる点です。特に「基本編」で解説される以下の機能は、Juliaの”貪欲さ”、すなわち 表現力とパフォーマンスの両立 を理解する上で欠かせません。 ...

日本のデジタルトランスフォーメーション（DX）やデータ活用が進む中で、企業倫理やプライバシー保護の観点が欠落し、社会的な批判を浴びる事例が繰り返されています。 ここでは、過去に日本で発生した象徴的な「データ活用における企業の暴走・失敗」事例を振り返り、その本質的な問題点を整理します。 1. JR東日本 Suicaデータ販売事件（2013年） 事案 JR東日本が、氏名などを削除した（と称する）Suicaの乗降履歴データを、利用者への十分な説明や明確な同意プロセスを経ずに社外（日立製作所）に販売しようとした事例です。 失敗の本質 JRはSuicaの履歴を個人情報とは考えておらず、これは、統計的に見れば誤った認識であり、3か所のロケーションとそこを通った時間を特定できれば9割以上の確率で個人を特定できることが示唆されています。Suicaの番号や氏名がなくても、IDだけが個人情報ではないという認識が欠如していました。移動履歴は個人の行動パターンを詳細に記録した極めてプライバシー性の高い情報（強い識別子）です。特定の個人を追跡したり、ストーカーなどの犯罪に悪用されたりするリスクに対する想像力が欠如していました。また、利用者に黙ってデータを収益化しようとした「不誠実な企業姿勢」が強い反発を招きました。 結果 世論の猛反発と有識者からの集中砲火を受け、計画は撤回されました。この事件は、その後の個人情報保護法の改正（匿名加工情報の規定など、規制強化）を招く大きなきっかけとなりました。 2. 武雄市図書館・CCC選書事件（2013年〜） 事案 佐賀県武雄市が公共施設である図書館の運営にTSUTAYA（カルチュア・コンビニエンス・クラブ：CCC）を指定管理者として導入し、Tポイントカードと図書の貸出履歴を連携させようとした事例です。 失敗の本質 図書館界で長年守られてきた「図書館の自由に関する宣言」（読書事実の秘密を守る）という倫理規定を軽視し、図書館を「商業的なマーケティングデータ収集の場」と化そうとしました。市民の思想・信条や知的関心が追跡・プロファイリングされることへの、生理的な拒絶反応を読み誤りました。 結果 政治的な大ハレーションを引き起こし、反対運動が展開されました。当時の市長が後に政界から退く要因の一つともなりました。「公共空間×データビジネス」の典型的な失敗例として記憶されています。 3. リクルート（リクナビ）内定辞退率予測モデル事件（2019年） 事案 リクルートキャリアが運営する就職情報サイト「リクナビ」において、就活生のWeb閲覧履歴などをAIで分析して「内定辞退率」を算出・スコアリングし、それを採用企業側に有償で販売していた事例です。 失敗の本質 圧倒的に立場の弱い就活生を食い物にする、倫理観の欠如が指摘されました。学生は「就職活動を支援してくれるツール」と信じて利用していたにもかかわらず、裏では自分たちを「選別・切り捨て」するための道具としてデータが利用されていたという、明白な信義則違反がありました。また、リクルートは内定辞退率のモデル化が、就活生に対する新たな差別や不利益に繋がる可能性について十分に考慮していませんでした。 結果 事業は廃止され、政府からの行政指導が行われました。この事件は「AIによるプロファイリング」や「HRテック」に対する社会的な不信感を決定づけ、データの扱いに関する企業の責任が厳しく問われる転換点となりました。 4. セブン・ペイ（7pay）不正アクセス事件（2019年） 事案 セブン＆アイ・ホールディングスが鳴り物入りで開始したバーコード決済サービス「7pay」において、サービス開始直後からセキュリティの脆弱性を突かれた第三者による不正アクセスとチャージ被害が多発。わずか3ヶ月でサービス終了に追い込まれました。 失敗の本質 当時の経営陣が二段階認証の概念すら理解していなかった点（記者会見での「2段階認証？」発言が象徴）は、サービス提供における基本的なセキュリティ意識と想像力の欠如を浮き彫りにしました。既存の決済手段（nanaco）があるにも関わらず、グループID統合という「企業都合」を最優先し、セキュリティ検証を軽視して納期ありきでリリースを急いだ結果です。 結果 サービスは廃止され、被害総額は約3800万円に上りました。何より、巨大流通グループであるセブン＆アイHDのデジタル戦略全体への信頼が失墜するという、計り知れないダメージを残しました。 結論：信頼なきデータ活用に未来はない これらの事例に共通するのは、**「ユーザー（生活者）の視点の欠落」と「企業都合の優先」**です。 「データは石油である」といった言葉に踊らされ、そこにあるのが「生身の人間のプライバシー」であることを忘れた時、企業は手痛いしっぺ返しを受けます。 技術的に可能であることと、倫理的に許容されることはイコールではありません。法的な整合性だけでなく、「それはユーザーにとって気持ち悪いことではないか？」「裏切られたと感じないか？」という倫理的な問いを常に立て続けることが、データ活用社会における企業の最低限の責務と言えるでしょう。 端的に言えば、全ての例が物語っているのは、「ぼくのかんがえたさいきょうの〇〇」が足元を見ていなかったということです。