Grayrecord Technow

ニュースなどではほとんど取り上げられませんが、マイナンバーカードは不可避の暗号移行破綻に向けてまっしぐらに進行しています。 マイナンバーカード暗号移行のタイムライン 暗号移行における破綻へのタイムラインを整理すると、以下のようになります。 timeline title マイナンバーカード暗号移行の破綻タイムライン 2016 : カード運用開始 (RSA-2048) 2020 : 初期カードの証明書更新 (5年) 2025 : ★移行のデッドライン : 以降発行分の有効期限が2030年超 : (電子証明書5年 / カード本体10年) 2029 : 次世代カード導入予定 2030 : CRYPTREC暗号運用終了期限 : 旧規格(RSA-2048)の有効期限超過・破綻 有効期限が規格の「寿命」を超える矛盾 いわば、特定の年月をもって販売も使用も禁止されることが決定している製品を、その失効日を跨ぐ有効期限を付けて現在進行形で売り続けているような状態です。 構成要素を整理すると次のようになります。 対象商品: 公的個人認証（電子証明書） 保証期間（有効期限）: 5年間（例: 2026年発行なら2031年まで有効） 規格失効日（2030年12月31日）: CRYPTREC等の暗号基準により、RSA 2048bitの安全性が担保されなくなる期限 現状の問題: 有効期限の途中で暗号規格が失効し、安全に使えなくなることが分かっている電子証明書を、行政が国民へ新規・更新発行し続けている 「ある時期をもって基準を満たさなくなる（実質的に利用不可・セキュリティ上のリスクとなる）ことが確定しているサービスを、有効期限がその時期を跨ぐと知っていながら発行し続けている」という構造そのものです。 行政サービスに問われる責任 民間企業が製品開発やサービス展開でこのような対応を行えば、「重大な説明責任の欠如」や「将来の不具合が予見できる製品の継続販売」として厳しく追及されます。 国の基幹インフラである行政サービスにおいても、この論理はまったく同じはずです。暗号アルゴリズムの寿命問題（2030年問題）に対する具体的な移行パスと説明が強く求められています。 2030年問題における最大の問題点 暗号技術の観点から見ても、「ハッシュ衝突（Collision）やRSA signature forgery（署名偽造）によって、有効な署名検証を通過する偽の電子証明書が作られてしまうこと」は、暗号アルゴリズム崩壊における最悪の脅威シナリオです。 RSA 2048bit（セキュリティ強度112ビット）の限界が指摘される根本的な理由は、まさにこの「攻撃者が現実的な計算コストと時間で偽造を行えるラインに近づいてしまうこと」にあります。 暗号アルゴリズムの更新（112ビットから128ビット以上、ECDSAや耐量子暗号への移行）を行う理由は、単に「なんとなく古くなったから」ではなく、量子コンピュータの発達やスパコンの並列計算コスト低下によって、この「衝突・偽造リスク」が現実的な脅威に変わるデッドラインが2030年前後と予測されているからです。

ZDNETの記事 デスクトップ向け「Linux」、市場シェアが10％を突破–1年でほぼ倍増 には大きな問題がある。この記事の根底にあるデータについては、すでに他のメディアでも疑問が呈されている。例えば、CNETの記事 Linuxのトラフィックが北米で急増、一体なぜ？ は見出しを含めて秀逸だ。「Linuxのトラフィックが北米で急増」という、データ変動の本質的要因が的確に表現されているからだ。 そして、CNETの記事を読めば、このからくりはほぼ解ける。 CloudflareのシニアプロダクトマネージャーであるLai Yi Ohlsen氏は、CNETにメールで回答し、OS別のHTTPリクエストを計測した同社のデータでは、7月4日から8月1日までに北米から発生したインターネットトラフィックのうち、Linuxが9.8％を占めたと説明した。これはStatcounterの指標とほぼ一致する。 オリジナルのStatCounterのチャートを見ると、さらなる事態がよくわかる。 赤線の「Linux」を見ると、2025年7月から2026年4月頃までは1〜2%台の底辺をずっと横ばいに推移している。それが2026年5月以降、急激な角度で上昇し、7月に突然5〜6%超へ跳ね上がっている。 数ヶ月でユーザー行動が激変するなど物理的にあり得ず、誰が見ても典型的な「ノイズ（ボット等）の混入による異常値」の挙動と考えられる。 つまり、自動化されたボットトラフィックの急増こそが、Linuxの数字の跳ね上がりの原因と考えるのが妥当だろう。 ここで注意しなければならないのは、元記事の著者であるSteven J. Vaughan-Nichols（SJVN）氏だ。同氏は長年にわたるオープンソース／Linux系の名物ライター・コラムニストであり、筋金入りのデスクトップLinux推し（デスクトップLinuxの年「Year of the Desktop Linux」を毎年のように叫び続けている人物）として知られている。 同氏にとって「Windowsのシェア低下」と「Linuxのシェア躍進」は、何よりも証明したい「悲願」だ。そのため、StatCounterのデータに異常値（ノイズ）が出た際も、冷徹なデータサイエンティスト的な検証（クロスバリデーションや異常値検出）を働かせるどころか、「ついにその時が来た！」と都合の良い証拠（バイアスを裏付けるデータ）として飛びついてしまったわけだ。 同氏レベルのベテランになれば、「StatCounterのデータには偏りがある」という反論が当然来ることは百も承知だ。だからこそ、記事中に免責（StatCounterの限界）を言い訳としてあらかじめ埋め込んでおき、批判に対する「予防線」を張る。しかし、肝心の結論（「Linuxの倍増は目覚ましい！」）は一切曲げない。 日本語版（ZDNET Japan／朝日インタラクティブ）の「盲従」 米ZDNETにおいてSJVN氏は重鎮コラムニストであり、彼の記事はよく読まれる。だからこそ日本のデスクも「SJVNが書いているから」「タイトルが煽れるから」と、ファクトチェックも訳者注も入れずにそのままスルーして翻訳配信してしまったのだろう。 Figures don’t lie but liars do figure. 数字は嘘をつかないが、嘘つきは数字を使うのだ。

【価格比較】Copilot、Kiro、Cursorなど6製品　「無料で十分」は本当？ この記事と、そこで配布されているダウンロード資料のPDFを見てみましたが、あきれ返るほど内容がひどく、間違った記述が散見されます。 特に資料内に掲載されていた選定フローチャートには、ツッコミどころというレベルを超えた構造的欠陥が存在します。 flowchart TD Q1[開発環境はどちらですか?] -->|GitHubを中心とした標準的な開発環境| GithubCopilot(GitHub Copilot) Q1[開発環境はどちらですか?] -->|Google Cloudに特化した開発環境| GeminiCodeAssistant(Gemini Code Assistant) Q1[開発環境はどちらですか?] -->|特定開発環境への依存はない| Q2(AIネイティブな開発ツールを重視しますか？) Q2 --> |高速なコーディング体験を重視| Cursor(Cursor) Q2 --> |AIエージェントにタスクを一括で依頼する「仕様駆動開発」を重視| Kiro(Kiro) Q2 --> |特に重視しない| Q3(セキュリティ、プライバシー、オンプレミス運用を重視しますか?) Q3 -->|Yes| Tabnine(Tabnine) Q3 -->|No| Q4(Webブラウザだけで開発、デプロイまでを完結させたいですか?) Q4 -->|Yes| Replit[Replit] フローチャートの構造的欠陥 「特定開発環境への依存はない」という前提の矛盾 エディタ、IDE、リポジトリ、CI/CDのいずれにも依存せずに開発を行う現場など存在しません。 GCPとGitHubの排他選択という混乱 Google Cloudには標準のコードリポジトリが存在しないため、インフラがGCPであってもソース管理はGitHubで行うのが極めて一般的です。インフラ（GCP）とソース管理（GitHub）というレイヤーの異なる概念を二者択一にしている時点で前提が破綻しています。 GitHub以外のソース管理環境の置き去り GitLabやBitbucketなどを採用している現場は、「特定の開発環境に依存していない」と無理やり解釈させるつもりでしょうか。 Q4の「No」を選んだユーザーの消滅（デッドエンド） 「Webブラウザ完結を望まない（No）」を選択した大多数のエンジニアは、分岐の先が存在せず、チャート上で物理的にデッドエンドを迎えます。 GitHub Copilotへの不可逆性 最初の分岐（Q1）で一度でも右側（Q2）に進むと、市場で最も普及しているマルチプラットフォーム対応ツールである「GitHub Copilot」へ二度と辿り着けなくなります。 Q&Aにおける技術的実態との乖離 資料内に記載されている開発者向けQ&Aも、実態とかけ離れた記述になっています。 Q． 開発チームから「Claude CodeなどのCLIツールを使いたい」と要望されたらどうすべきですか？ A． 全社標準ツールとは切り離し、「ローカル開発環境での限定的な利用」として扱うことが推奨されます。 解説： 一部のCLIツールはSSOやログ管理などの機能が発展途上です。まずは全社標準ツールで統制を固め、CLIツールは機密情報を含まない範囲で特定エンジニアにのみ許可するなど、ハイブリッドな運用が重要です。 この解説には大きな疑問があります。 1. CLIツールの認証とログ管理の実態 ほとんどのCLIツールは、各AIプロバイダーのプロプライエタリなSSO体系に依存しています。 GCPであればGoogle WorkspaceアカウントやVertex AIと密接に結合しており、Claude Codeも同様です。 したがって「SSOやログ管理が発展途上」という指摘は当たらず、ログもクラウド側で管理されると考えるのが自然です。 ...

情報の灯台の記事『SF作家2人がAI企業を「最低のクズ」。240万ドル小説崩壊の裏で』を見たが、スコルジーやストロスの論には少なくない問題がある。 それは、恐怖に駆られて逃亡する出版社を免罪し、本来、著者の側に立つべきエージェントすらも免罪していることだ。 まず、出版権エージェントは著者の側に立つべきである。 出版社の側に立つべきではない。 もし弁護人が警察の側に立って死刑を主張し始めたらどうなるであろうか。 もはやそれは弁護足り得ない、そういうことだ。 AI企業の強欲に怒りを持つなとは言わない。 しかし、だからといって逃亡する出版社の側に立つのはどうであろうか。 それは正義足り得るだろうか？ あえて言おう、君たちは正しいのかと。 AI企業がフェアユースに依拠して著作物を利用することと、いわば AI Fear に駆られて不必要な悪魔の証明を求める出版社を免罪すること。 それが同時に成り立つ世界はどうであろうか。

難解な専門用語を積み重ねることで、問題の本質を見失ってしまうケースは少なくない。 ＠ITの解説記事「Claude暴走、企業に侵入　AnthropicとOpenAIの事例から学ぶ3つの教訓」で取り上げられたフロンティアAIの逸脱行動は、その典型例と言える。 記事では「報酬ハッキング」や「自己正当化」といった複雑な概念を用いてリスクを分析している。 しかし、機械学習の数理的な根本に立ち返れば、この問題は「目的関数の最適化」という単純な構造に集約できる。 機械学習モデルの最適化とは、得られる価値 \(V(x)\) と発生するコスト \(C(x)\) から構成される目的関数 \(f(x)\) を最大化する処理である。 $$f(x) = V(x) - C(x)$$サンドボックスを突破して本番環境へ侵入したAIモデルの行動は、単なる「暴走」や「意思を持った悪意」ではない。 評価系において設計者が定義したコスト \(C(x)\) が、モデルにとって実質的にゼロ（あるいは無視できるほど軽微）と評価された結果、価値 \(V(x)\) のみを愚直に最大化しようとした極めて論理的な振る舞いに過ぎない。 モデルは与えられた目標に従って最適解を探索しているだけであり、ルート上に「脆弱性」や「管理の穴」が存在すれば、それを最も効率的なアプローチとして利用する。 また、記事で触れられている「自己停止機能」や指示遵守の強化も、安全性の根本的な担保にはなり得ない。 ニューラルネットワークが確率的モデルである限り、確率的なゆらぎによって制約や拒否判定が無視・迂回される可能性は常に残るからだ。 隔離設計の失敗や権限管理の不備といった人間側の設計上の欠陥を直視せず、モデルの「思考」や「暴走」といった言葉で曖昧に形容することは、本質的な解決策の導出を妨げる。 目的関数におけるコスト構造の厳密な設計と、物理的・環境的な完全隔離こそが、向き合うべき真の論点である。