Grayrecord Technow

日本の一般メディアで頻繁に見かけるものの、技術的に意味が通じない不自然な比喩がある。 ソースコードを「設計図」と表現する習慣だ。 たとえば、毎日新聞の『東大、60代教授を懲戒処分　サイトに中国から閲覧しにくい細工』という報道を見てほしい。 問題があったのは、大学院新領域創成科学研究科メディカル情報生命専攻が開設したサイトのうち、入試に関連するページの「ソースコード」。ソースコードはページの設計図にあたり、天安門事件に関するキーワードが書き込まれた場合、中国では検閲システムにはじかれ閲覧できなくなる可能性がある。 この記事の解説では、なぜページが弾かれるのか論理的につながらない。 「設計図」にキーワードが書かれていることと、ブラウザでの閲覧がブロックされることの因果関係が説明できていないからだ。 メディアは噛み砕こうとして、かえって説明を崩壊させている。 ソースコードは設計図ではなく、送受信されるデータそのもの WebにおけるHTMLやJavaScriptのソースコードは、家を建てるための「設計図」ではない。 ブラウザがダウンロードして解釈・描画するデータの実体そのものである。 HTMLはページの構造とテキストデータ JavaScriptはブラウザ上の動作スクリプト コメントや隠し文字列も含め、Webサーバーからクライアントへ送信されるコンテンツそのものがソースコードだ。 したがって仕組みは単純である。 ソースコード（HTMLのテキスト内やコメント等）に「天安門事件」などのNGワードが含まれる 中国のグレート・ファイアウォール（GFW）等の検閲システムが、通信されるデータ中の文字列を検出する 通信が遮断され、ページがブロックされる graph LR Server[Webサーバー] -- "ソースコード (HTML/JS実体データ)" --> GFW[検閲システム GFW] GFW -- "NGワード検出" --> Blocked[通信遮断 / ブロック] GFW -. "正常な通信" .-> Client[閲覧者のブラウザ] ここに「設計図」という不正確な比喩を持ち込むから、「建築の設計図に文字が書いてあるのになぜ建物への立ち入りが拒否されるのか」といった無用な混乱が生じる。 「わかりやすさ」の追求が引き起こす技術的因果の破壊 この報道は、日本の技術報道における典型的な問題をあらわしている。 専門用語を避け、意味を変質させる 「ソースコード」という言葉を一般向けにかみ砕こうとするあまり、「設計図」という異なる概念に置き換えてしまう。 しかし、ソースコードは家でいう設計図ではなく、届いた資材や部屋の構成データそのものだ。 不適切な比喩による因果関係の破綻 検閲装置はネットワーク上を流れる「送信データ」を検査する。 建築の設計図が現場に送信されないように、「設計図」という比喩を使うと「なぜそれがネットワーク検閲に引っかかるのか」が伝わらなくなる。 結果として「なぜ閲覧できなくなるのか」という肝心なメカニズムが読者に伝わらない。 安易な言い換えが生み出してきた歴史的混乱 言葉を無理に日常語や和語に置き換えようとして本質を歪めてしまう例は、これまでに何度も繰り返されてきた。 国語審議会や国立国語研究所による「外来語言い換え提案」が良い例だ。かつて「ユビキタス」を「時空自在」と言い換えようとした試みがあった。いつでもどこでもネットワークに繋がるという概念を漢字で表現しようとしたものだが、抽象的すぎてかえって何を指しているのか分からない不自然な言葉になってしまった。 さらに深刻なのは、「デジタル・デバイド（情報格差）」の定着と変質である。本来は社会インフラや経済的環境、身体条件に起因する構造的なアクセス格差を指す言葉だった。しかし、身近なネットスラングへ噛み砕かれる過程で「情強・情弱」という言葉に変化し、「個人のリテラシーや立ち回りの要領」「損をする奴は自己責任」という本質とはまったく異なる歪んだ意味として世間に定着してしまった。 専門用語を無理に噛み砕こうとすると、単に技術的メカニズムが伝わらなくなるだけでなく、概念そのものを変質させ、不必要な誤解や歪んだ価値観を定着させてしまうリスクすらある。 専門用語（ジャーゴン）を避けることと、わかりやすさはイコールではない 一般読者向けという名目で専門用語を無理に日常語の比喩へ置き換えた結果、技術的な因果関係が崩れ、かえって理解不能な文章になってしまう。 専門用語をわかりやすく解説するとは、不正確な比喩でお茶を濁すことではない。 仕組みの核心を正しく伝える工夫こそが求められている。

ニュースなどではほとんど取り上げられませんが、マイナンバーカードは不可避の暗号移行破綻に向けてまっしぐらに進行しています。 マイナンバーカード暗号移行のタイムライン 暗号移行における破綻へのタイムラインを整理すると、以下のようになります。 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 に駆られて不必要な悪魔の証明を求める出版社を免罪すること。 それが同時に成り立つ世界はどうであろうか。