Posts

不安しかない au IDや、「dアカウント」にログインしようとしたら、なぜか回線認証で詰んで先に進めない。機種変更したら、これまで使えていたサービスに紐付けられたdアカウントの再設定で地獄を見た──。そんな経験、ありませんか？ なぜなら、その背後には 「回線を持っているがゆえに、不便を強いられる」という、キャリア認証システムの根本的な問題 がちらついていたからです。 「dアカウント」にせよ、「au ID」にせよ、その 「King of ゴミ」 とも言うべき、回線認証の強要は、我々のデジタルライフを大きく阻害しています。ITmediaでも報じられたように、なぜdアカウントのUI/UXはこれほどまでに悪い評価で衆目の一致する所となっているのか。今回は、その根深い問題点、特に回線認証という 時代錯誤な仕組みが引き起こす弊害 に焦点を当て、なぜ我々がこれほどまでに不満を抱えているのかを徹底的に掘り下げていきます。 先ごろ、発表されたSBI住信の買収で不安を漏らす声が噴出しています。実際、ITmediaでも以下のような記事が書かれています。 なぜ、「dアカウント」は嫌われているのか　住信SBIネット銀行買収で、不安の声が上がるワケ 終わってるUser eXaust：キャリア認証の「糞」っぷり 私は家計簿アプリMoney Forwardでau PAYを含む複数の金融サービスを集約して管理していますが、その連携方法がユーザーに多大な「苦痛」をもたらしています。 Money Forward連携と「糞」なキャリア認証 まず、Money Forwardはau ID側からの適切なAPI提供がないため、不安定な「スクレイピング」でデータを収集せざるを得ません。これにより、au IDの認証が頻繁に切れてしまい、再認証の度に地獄を見ます。 この再認証プロセスが、まさに「User eXhaust」の極致です。 痛みしかないフロー Money Forwardでau Payからの認証切れを発見する おもむろに再認証を始める 認証しようとしたら、最初の壁、パスワード認証できないにぶつかる スマートフォンからパスワード認証を有効化しようとする スマートフォンアプリからは該当操作が見つからない wifiからは設定できない、回線認証の強制 糞そのもののキャリア認証 パスワード認証の無意味化と強制的なSMS認証: au IDのパスワード認証は、わずか15分で自動的に無効化されます。さらに、パスワードを有効にしようとすると「悪用に関する警告」が表示された上に、時代遅れのSMS認証が強制されます。安全で便利な時間ベースの二段階認証（TOTP）は選択肢にすらありません。 回線認証の強制とWi-Fi切断の強要: パスワード認証が無効化されると、次に強制されるのは「Wi-Fiを切って、VPNをオフにしろ」という「愚劣な回線認証」です。安定したWi-Fiを切り、特定のモバイル回線で接続し直すという不必要な手間は、ユーザーに計り知れないストレスを与えます。 設定変更の困難さ: これらのパスワード認証に関する設定は、My auアプリには存在せず、Webブラウザからしかアクセスできません。しかも、そのWeb設定もスマートフォンからしか行えないという多重の制約があり、スマートフォンが手元にない状況では完全に「詰み」ます。 PayPay連携も「アホすぎる」 PayPayの連携方法も同様にユーザーを疲弊させます。Money ForwardとPayPayを連携させる際、API連携ではなく、スマートフォンアプリ間で「インテント」を飛ばすという、極めて非効率で不安定な方法を強いてきます。この理解しづらい手間は、金銭管理という重要なタスクにおいて、ユーザーに「アホすぎる」苦痛を与えています。 信頼性と安定性の問題: アプリ間の連携は、アプリのバージョン、OSのバージョン、端末の設定など、様々な要因で不安定になる可能性があります。 バッテリー切れやアプリの不具合など、何らかの理由でPayPayアプリが使えない場合、連携自体ができなくなるリスクもあります。 テックジャイアントとキャリア認証の雲泥の差 GoogleやMicrosoftといった世界のテックジャイアントは、現在、パスキー、TOTP（時間ベースワンタイムパスワード）、フォールバックとしてのSMS、そして最終手段としての事前配布解除コードを組み合わせた認証基盤を標準としています。 これらの企業は、ユーザーがどのデバイス、どのネットワークからでも安全かつシームレスにサービスを利用できるよう、以下の点を重視しています。 フィッシング耐性の高いパスキーを基幹とする。 オフラインでも利用可能なTOTPを次点とする。 利便性とセキュリティを両立させる。 「回線認証」などという愚劣な認証を主要な手段として導入することはありません。 信用性が無い理由 古い技術への固執: 時代遅れで脆弱性が指摘されているSMS認証を主軸にしたり、利便性を著しく損なう回線認証に固執したりする時点で、最新のセキュリティ脅威に対する認識が甘いか、対応能力が低いと見なされます。 利便性の犠牲とユーザーへの負担: ユーザーに多大な手間やストレスを強いる認証システムは、結果的にユーザーがセキュリティ対策を回避しようとする行動を誘発しかねません。例えば、不便な設定を避けたり、パスワードを使い回したりするリスクを高めます。 「技術的腐敗」: 認証基盤が「技術的腐敗」の状態にあるということは、システム全体の整合性や信頼性が低いことを意味します。このような基盤の上で金銭取引が行われているとなると、潜在的な脆弱性や予期せぬトラブルのリスクが懸念されます。 ...

本日、スーパーレジェンド級の詐欺と思われるメールが着弾しました。 Apple Card（アップルカード）は2025年現在発行できる？現状や特徴を紹介 Appleが提供するクレジットカード「Apple Card」は、2025年4月現在、日本では利用できません。 そう、まだ、発行されていないカードです。私も、まだ、発行されていないカード で詐欺メールが来たのは初めてです。 では、メールを晒しますね。 本文としては以下の内容です。 カード情報の速やかなご確認 2025年5月26日にご登録のカードにおいて異常な使用が確認されました。現在、ご利用は一時的に制限されております。 Apple Cardのご利用を継続するため、2日以内に認証手続きを完了してください。情報は暗号化され保護されます。 残念ですが、この文面は100%、信頼不可能です。この種のメールは個人情報を詐取する目的で作られており、リンク先のサイトで情報を入力してしまうと、その情報は悪用される可能性が高いです。 まず、詐欺メールの基本技術として、緊急性を煽るなどが利用されています。これは、詐欺メールのもう、基本技術としてありふれていますね。 現在、ご利用は一時的に制限されております。 などは典型例です。 ある意味、未発行のカードを騙るという手口は盲点かもしれません。特に、Appleユーザはもしかすると騙されるかもしれません。この種のパターンは要注意かもしれません。しかし、未発行のカードという原点を忘れなければ騙されようがありません。 もし、このようなメールを受信しても、慌ててリンクをクリックしたり、情報を入力したりしないでください。まずはAppleの公式サイトにアクセスし、ご自身のApple IDでログインして状況を確認するようにしましょう。不審なメールは、Appleに報告することも可能です。この時、メール上のリンクの使用は厳禁です。アカウント情報を登用される恐れがあります。

私が、経験した中でも最低の部類の幻影に遭遇した。 言うまでもなく、2025年1月21日以降はトランプ政権である。しかし、現状、殆どのLLMは2024年前後で歴史が止まっている。しかし、Geminiはどうやら、RAGで最新化するという機能が弱い。そのため、意識的にURIが与えられないと、事実を補正することが出来ない、また、投入される情報もどうやら、Googleとの提携関係などに依存する部分が大きい。 しかし、このように、自信たっぷりに、虚偽の事象を開陳してしまう。 これは、所謂、ハルシネーションの典型的な事例です。 ハルシネーションの原因としては以下のようなものがあります。 情報の不足：モデルが学習データにない情報を推測して補完しようとする。 RAGの限界：適切な情報を取得できない場合、誤った情報がそのまま出力される。 モデルのバイアス：特定のデータソースに依存するため、偏った情報が生成される可能性がある。 今回のは状況として、まず、恐らく、RAGによる情報の最新化が動いていません。恐らく、情報の不足とモデルのバイアスに引きずられた格好です。GeminiはDeep Researchは強力ですが、現時点では、Gemini 2.5 Flashなどではまだ、ハルシネーションがきついようですね。 あと、Geminiでは唐突にロシア語化する問題を確認しています。今のところ、発生はランダムで、前世代のGemini 2.0で頻発しましたが、現行世代のGemini 2.5 Flashでも同様に発生します。この件は、幾つか報告があります。 Geminiの回答にロシア語が混ざる！原因と今すぐできる対処法 Gemini 2.0 がロシア語を混ぜて回答してくる問題 まず、分かっているところを整理すると、特に会話のコンテキストが長くなる、要は会話のキャッチボールが長くなると問題の発生が多くなる。つまり、コンテキスト周りに問題がある可能性がある。さらに、生成されたロシア語っぽい文字列をdeeeplで翻訳すると意味に関しては大きく外れていないようにも見受けられる。 従って、メモリー破壊などのバグによる生成とは考えにくく、プロセスとしては正常動作の可能性が高い。故に、エラーログなどでの調査は不首尾に終わる可能性が高い。 考えられるのはドリフトなどかと思います。あと、状況からして、専門用語などが不具合を起こしているように見受けられるので未知語などの処理、特に埋め込みベクトルの問題が強いように思いました。 まず、学習データの問題の可能性は低いと考えています。理由は、だとすれば初手から表れてもおかしくないからです。むしろ、コンテキストが深くなると発生するということはコンテキストの深化で何らかの異常が発生すると見られます。 現在、Gemma 3で同様の問題が発生するかトライを試みています。新規の更新がありましたら報告します。

“採血データを使った心不全予測"のコンペに参加したので、解法を示します。まず、基本的に、2つの分類の予測問題は元々慣れていたので基本的なフレームとしては以下の通りです。 探索的データ分析 ベースラインモデルの作成 予測モデルの作成 探索的データ分析 まず、最初にデータを一応概観してみました。 発売中の技術同人誌 “Pythonによる探索的データ分析クックブック“でも触れている、ydata-profilingを使用しています。 import os import sys import pandas as pd import polars as pl import pyarrow as pa import numpy as np import matplotlib.pyplot as plt import seaborn as sns from ydata_profiling import ProfileReport train_df = pd.read_csv("../data/train.csv") test_df = pd.read_csv("../data/test.csv") profile = ProfileReport(train_df, title="Heart Failure Report") profile.to_file("../profile/heart_failure_report.html") ベースラインモデルの作成 基本線となるベースラインモデルを作成しました。ベースラインモデルは文字通りベースラインモデルなので、複雑なものは避けるのがセオリーです。今回は二つの分類をするタイプなので、一般化線形回帰でロジスティック回帰に持ち込むのを基本としました。また、stepwiseなどの容易さから、一旦、Rでモデリングを進めました。 コードとしては以下のシンプルきわまるものです。 require(dplyr) require(readr) require(ggplot2) require(pROC) train.df <- read.csv("../data/train.csv") test.df <- read.csv("../data/test.csv") train.df <- train.df %>% mutate( anaemia = as.factor(anaemia), diabetes = as.factor(diabetes), high_blood_pressure = as.factor(high_blood_pressure), sex = as.factor(sex), smoking = as.factor(smoking), target = as.factor(target) ) require(MASS) model <- glm(formula = target ~ age + anaemia + creatinine_phosphokinase + diabetes + ejection_fraction + high_blood_pressure + platelets + serum_creatinine + serum_sodium + sex + smoking + time, data = train.df, family = binomial) model.opt <- stepAIC(model) pred.df <- predict(model.opt, train.df, type = "response") roc_curve <- roc(train.df$target, pred.df) auc_value <- auc(roc_curve) ar_value <- (auc_value - 0.5) * 2 print(paste("AR値:", ar_value)) cat("Length of Cumulative_Percentage:", length(seq(0, 1, length.out = nrow(train.df))), "\n") cat("Length of Predicted_Positive:", length(sort(pred.df, decreasing = TRUE)), "\n") cat("Length of Actual_Positive:", length(sort(as.numeric(train.df$target), decreasing = TRUE)), "\n") sorted_predictions <- sort(pred.df, decreasing = TRUE) # 予測確率を降順に sorted_targets <- sort(as.numeric(as.character(train.df$target)), decreasing = TRUE) # 実ターゲットを降順に n <- min(length(sorted_predictions), length(sorted_targets)) cumulative_data <- data.frame( Cumulative_Percentage = seq(0, 1, length.out = n), Predicted_Positive = cumsum(sorted_predictions[1:n]), Actual_Positive = cumsum(sorted_targets[1:n]) ) ggplot(cumulative_data, aes(x = Cumulative_Percentage)) + geom_line(aes(y = Predicted_Positive, color = "モデル予測")) + geom_line(aes(y = Actual_Positive, color = "実データ")) + scale_y_continuous(name = "累積正例率", limits = c(0, max(cumulative_data$Predicted_Positive, cumulative_data$Actual_Positive))) + scale_x_continuous(name = "累積パーセンテージ", limits = c(0, 1)) + labs(title = "CAP図") + theme_minimal() 最終的には以下のCAP図になりました、 ...

※ この記事は前の記事の続きになります。 AIモデルの裏側を探る：アテンションメカニズムの可視化とは？を参照してください。 先の記事で、LLMのアテンション機構の可視化を実施しました。そこからの続きで別の文について、可視化を試みてみます。モデルをGPT-2系の日本語モデルに変えて、『走れメロス』の冒頭の文に挑戦してみました。使用したのは以下の文になります。「メロスは激怒した。必ず、かの邪智暴虐の王を除かなければならぬと決意した。メロスには政治がわからぬ。メロスは、村の牧人である。笛を吹き、羊と遊んで暮して来た。けれども邪悪に対しては、人一倍に敏感であった。」 基本的なコードは先のコードですが、幾つか変わっています。実験はGoogle Colab上で行っています。 import torch from transformers import GPT2Model, T5Tokenizer, GPT2LMHeadModel import matplotlib.pyplot as plt import seaborn as sns import japanize_matplotlib tokenizer = T5Tokenizer.from_pretrained("rinna/japanese-gpt2-medium") model = GPT2LMHeadModel.from_pretrained("rinna/japanese-gpt2-medium", attn_implementation="eager") text = "メロスは激怒した。必ず、かの邪智暴虐の王を除かなければならぬと決意した。メロスには政治がわからぬ。メロスは、村の牧人である。笛を吹き、羊と遊んで暮して来た。けれども邪悪に対しては、人一倍に敏感であった。" tokens = tokenizer(text, return_tensors="pt") # トークンIDを対応する単語へ変換 tokens_list = tokenizer.convert_ids_to_tokens(tokens["input_ids"][0].tolist()) # 最後の層、最初のAttentionヘッドを取得 layer_idx = -1 head_idx = 0 attention_matrix = attentions[layer_idx][0, head_idx].cpu().numpy() # 左上1/4部分を切り取る quarter_size = attention_matrix.shape[0] // 2 # 行列サイズの1/2を計算 subset_matrix = attention_matrix[:quarter_size, :quarter_size] # 左上1/4部分を抽出 # 対応するトークンのリストも切り取る subset_tokens = tokens_list[:quarter_size] # ヒートマップを描画 plt.figure(figsize=(8, 8)) sns.heatmap(subset_matrix, cmap="viridis", xticklabels=subset_tokens, yticklabels=subset_tokens) plt.xlabel("Attention対象") plt.ylabel("Attention元") plt.title("左斜め上1/4のAttentionマップ拡大表示") plt.xticks(rotation=90, fontsize=8) plt.yticks(fontsize=8) plt.show() 可視化した結果が以下になります。アテンションマップの隅1/4を拡大しています。 ここから言えることは、恐らく、メロスの単語が辞書にないためだと思いますが、メロスの挙動は不安定です。その結果、周囲の文脈から何を意味しているか推測している可能性があります。また、主語「メロス」と「邪」のようなワードに注意が向いているようです。「邪智暴虐」という表現が特徴的ですから、AIがそのフレーズを重要だととらえている可能性があります。また、文のイメージがネガティブというのも影響している可能性があります。また、除にも注意が向いているので、「除かなければならぬ」などの文脈に注意が流れている可能性があります。