Tech Deepdive Tokyo / IT技術ニュース

[Claude Code Studio @ClaudeCode_love]

【事件】
Claude Codeで“デザイン賞レベル”のWebサイ��を作る全手順を、18分で丸ごと見せてる動画を発見😳
https://t.co/pxnznJ01CA
・使うのはClaude Codeと最新モデルSonnet 5の組み合わせ
・指示の出し方から見た目の仕上げまで通しで実��
・完成形は海外で“賞レベル”と話題のクオリティ
・18分で最初から最後まで流れを追える構成
登録なし・無料・しかも実際の制作画面をそのまま収録。市販のWeb制作講座を10本ハシゴするより、この18分1本のほうが密度が高い。Claude Codeでサイトを作ったことがある人ほど、序盤だけで「自分の作り方ぬるかった」ってなるレベル。本気で見た目を変えたいなら、これは見ない理由がない。
これは紹介動画じゃない。
制作画面を丸ごと収めた実演教材です🤐
この“見た目を仕上げる”考え方をテキストで体系化したのが、HTMLファースト思考術。
賞レベルの見た目を作るHTMLの考え方は、この記事が一番早い👇

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

Quake を Web ブラウザで、WebGL や canvas を使わず HTML/CSS の 3D DOM として再現した移植プロジェクト

・`pnpm install` のあとに `QUAKE_SHAREWARE_URL` か `QUAKE_PAK_PATH` を入れて `pnpm prepare:quake` を回し、最後に `pnpm dev` で起動する。Quake 1.06 の shareware archive か手元の `pak0.pak` を前提にしている。
・準備段階で `resource.1` を検証し��`ID1/PAK0.PAK` を抜き出して、BSP / WAD / MDL / LMP / entity / visibility / collision / HUD / menu / pickup / weapon / QuakeC までブラウザ向け資産に変換する。���行時に元データを読み直さない設計が肝。
・描画は PolyCSS の 3D DOM で、地形の面を CSS `matrix3d(...)` と背景画像で組み立てる。ゲームループ、移動、当たり判定、敵、武器、UI、音は TypeScript が持つので、見た目とロジックを分けやすい。
・`map=e1m1` や `view=480,-192,72,0,90,0` で場面をそのまま再現できる。`debugPolys=1` や `zoom=...` も分離されていて、`roll` はまだ 0 限定。こういう URL 共有は、デバッグにもスクリーンショットにもかなり向いている。
・ライブ画面には Single Player / Multiplayer / Select Level / Help / Options / Debug があり、Multiplayer では Name / Color / Map / Fraglimit / Timelimit / Max Players を指定して Create / Join / Copy Link できる。Debug では Show outlines / stats / FPS と Record / Capture / Visible / DOM / Enemies / Pickups まで見られる。
・iframe 埋め込みでは `relayKeys=1` でゲーム入力だけを親へ渡せるが、親側は `event.origin` の確認が必要。こういう作りは、重い変換を build 時に寄せて、実行時は状態遷移だけに絞れるのが強い。

https://t.co/RgVHTpuiYB

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

favicon の RGB 値に HTML を埋め込み、ブラウザ自身で復元できるかを試した実験記事。

・HTML を `TextEncoder` でバイト列にして、末尾の未使用ピクセルに備えるために長さを示す 4 バイトを先頭に足し、各ピクセルの RGB に順番に入れている。favicon は画像として扱い、canvas からピクセルを読む前提。
・埋め込んだ HTML は 208 バイトで、ヘッダー込みの合計は 212 バイト。1 ピクセルに 3 バイト入るので 71 ピクセル必要���なり、最小の正方形は 9x9 ピクセルだった。著者の計算では容量は 239 バイトで、使用率は 87% だった。
・読み戻しは逆順で、favicon を画像として読み込み、canvas に描画して RGB を回収し、先頭 4 バイトで長さを取り、UTF-8 として復号している。これで元の HTML をそのまま戻している。
・成立した理由は、ブラウザにはただの色でも、作者には HTML のバイト列として見えるから。favicon は見た目がアイコンでも、実体は PNG のバイト列にすぎないので、意味と見た目をずらせる。
・埋めているのはサイト全体ではなく、ページの HTML コンテンツだけ。表示には JavaScript の起動処理が必要で、記事内の Render Website ボタンがその役を担っている。
・著者も、容量が小さくて実用的ではないと結論している。実務向きというより、画像をどこまでストレージとし��扱えるかを確かめる境界テストの例として見るのがよさそう。

https://t.co/gJ2d0kMAtF

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

データ圧縮の仕組みを、予測の精度とサイズ・速度・メモリの3軸で整理した本。

・圧縮は万能ではなく、どんな n bit 文字列も全部は縮められない。ランダムかどうかを判定する一般手順もなく、1 byte 短くできる文字列は全体の 0.4% 未満なので、圧縮は結局 予測の精度で決まる。
・圧縮率は bpc で見て、8 bpc は無圧縮。Calgary corpus は 1987年作成の 14 files / 合計 3,141,622 bytes で、size / speed / memory を同時に比べる前提が置かれている。
・ZPAQ の比較では、LIMIT を 4 から 1020 まで振ると order 2 モデルは Calgary corpus を 1,153,855 bytes から 1,150,737 bytes まで少し改善した一方、order 2 だけで 134 MB のメモリを使う。円周率の数字列では高次化の効きが弱く、単純な表引きは order 2 くらいまでが現実的だと分かる。
・Calgary corpus を file-by-file で見���と、block size 900 KB で bzip2 -9 は 828,347 bytes / 圧縮 0.68秒 / 解凍 0.42秒、BBB の fast mode は 785,672 bytes / 圧縮 10.33秒 / 解凍 1.46秒、slow mode だと 13.74秒 / 5.54秒 まで伸びる。
・理由もはっきりしていて、BBB は PIC の長い 0 の連続で圧縮時間をかなり取られ、bzip2 のような長い文字列比較への保護もない。
・私は、圧縮器の評価ではファイル本体だけでなく展開側の辞書やプログラム込みで見るのが大事だと思った。静的辞書は large text benchmark の上位3本と Hutter Prize の全優勝作で使われていて、ここを外すと見かけの圧縮率だけが良くなる。さらに、同じデータを tar でまとめると圧縮が悪化するので、混在データには BWT が合わない。

https://t.co/3mXPihdUjB

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

独裁者の専属料理人5人の証言を通じて、食卓が権力を見せる場所だったことを描く95分のドキュメンタリー。

・対象はポル・ポト、金正日、イディ・アミン、サダム・フセイン、ピノチェトに仕えた5人の元専属料理人で、原作は2020年のポーランド人記者ウィトルト・シャブウォフスキの本。作品はTribeca Film Festivalで初上映された。
・金正日はペパロニピザ、サダム・フセインは魚のバーベキュー、イディ・アミンは丸焼きのヤギ級の食欲で描かれ、食卓そのものが権力を見せる場所になっている。
・金正日の厨房で働いたエルマンノ・フルラニスは、監視下で仕事をし、パスポートも預けられ、ピザのオリーブの位置まで国家側が確認しに来たと振り返る。独裁の内輪に入るには深い信頼が必要で、そのぶん外からの距離も生まれる。
・イディ・アミンの元料理人チャールズ・オトンデ・オ��ラは、貧しい村人からメルセデスを運転し、8人の妻を支える立場に変わった一方で、アミンの2人目の妻ケイが車のトランクで遺体で見つかってから、ようやくその取引の重さを考え直した。富や安定があるほど、暴力との距離は見えにくくなる。
・ポル・ポトの元料理人ケオ・サムアンは、結婚や結婚式を任された相手が、4年で推定150万〜300万人の犠牲を出したポル・ポトだったことを切り分けられず、最後は涙を見せる。近くにいた人ほど、加害と恩義を同時に抱えてしまう。
・サダム・フセインの元料理人は匿名で、黒いシルエットのまま登場し、声や体も変えてAIで身元を特定されないようにしていた。顔を隠すだけでは足りなくて、音声や輪郭まで含めた保護が必要だと分かる。
・私は、こういう題材は権力者本人よりも、周囲の実務担当者の証言を積み上げ��ほうが、独裁が日常の仕事をどう歪めるかが見えやすいと思った。取材や記録をする側は、��を撮るかだけでなく、誰をどう守るかまで先に決めたほうがいい。

https://t.co/pe5uNC2zMB

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

若手エンジニアの評価を、完了件数ではなくB/C/Aのシグナルで見分けるKent Beckのエッセイ。

・40タスクと20タスクを比べても、難易度が同じか分からない限り判断できないので、まずは件数ではなく中身を見る前提になっている。
・BかCかの判定では、コードが動くこと、周囲に進捗を伝えること、初回見積もりの3倍以内くらいで終えること、レビュー担当やオンコールに余計な手間を出さないことを重視している。Cのシグナルは一度は出ても、同じ失敗を繰り返さないのが大事。
・AかBかの判定では、何件閉じたかではなく、1つの仕事からどれだけ学びを増やせたかを見る。著者は、ここで見るべきなのは仕事の速さではなく、その伸びだと言っている。
・Aのサインは���不要な仕事だと示すこと、10%の作業で90%の効果を見つけること、別��を複数試すこと、設計をよくして小さな差分を重ねること、内製ツールを作ること、自分のチーム以外にも役立つ差分を出すこと、鋭いレビューや単体テストを書くこと。どれも、最短で1件を閉じるより時間がかかる。
・この考え方の芯は、今の速度より未来の伸びを見ていることにある。給料は未来のエンジニアへの前払いだという見方なので、速さより、あとで周りを楽にする改善が効く。
・私は、ここが地味に大事だと思う。空いた時間は、進捗共有やレビューしやすさ、単体テストの厚さに回したい。B を崩さずに A を足すほうが、長く効く。

https://t.co/5GVKOQmzWL

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

ネット上の偽装や不正を減らすために、実名連動のデジタルIDで全通信を署名しようとする構想を提案した記事。

・SNS投稿 / レビュー / 銀行ログイン / メール送信までを対象に、実名登録された Digital ID で認証する前提を��いている。アプリ層では Google / Facebook のログインボタンに近い形で、単一ログインにも寄せている。
・背景として、広告詐欺は2018年に190億ドル、Webトラフィックの半分超はボット、Facebookは2018年Q1だけで5.83億件の偽アカウントを削除し、Twitterも数千万件を削除して、報道ではユーザー基盤の約6%に当たるとされた。
・提案の中核は、SIMやUSBドングルのような専用IDデバイスに署名だけを任せ、ネットワーク機器側で署名のないパケットを止めること。デジタルID層と実名レジストリ層を分けるので、匿名IDのまま運べる設計になっている。単機能のデバイスの方が複雑なPCより監査しやすいので、外付け firewall に近い役割も持たせられる、という考え方が土台にある。
・著者は、IDの発行コストを数ドルにしても偽アカウントや偽レビューの採算を崩せる��考えている。つまり、詐欺を検出するより、作るコストを上げて潰す発想。
・私は実務で見るなら、��利な本人確認基盤というより、「誰が発行するか」「紛失時にどう戻すか」「どの通信を署名対象にするか」を先に決める設計課題として読むのがよさそう。著者は、2FAより復旧しやすいとし、端末を失くしたら対面で再登録する流れや、米国 / EU / 中国のような大市場がハード仕様を義務化する普及ルートを想定している。

https://t.co/9z6sOmqVRk

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

Amazon MGMが、OpenAIとの大型提携を進める中で、サム・アルトマン伝記映画Artificialを配給から外した話。

・映画はルカ・グァダニーノ監督、アンドリュー・ガーフィールド主演で、ほぼ完成済みだった。公開予定は当初2027年初頭で、配給から外れた今は時期が未定になっている。
・その直前にAmazonは、OpenAIのシステムをAWS上で動かす7年の380億ドル契約を結び、OpenAIへ500億ドルを投資し、2��ガワット分のTrainium容量を使う計画も出している。AI基盤の提携が、同じ会社のコンテンツ判断に重なった形。
・Amazonは「別のスタジオのほうが適している」と説明し、制作チームと新しい配給先を探している。試写はすでに好意的だったので、完成度よりも関係整理を優先したように見える。
・初期の視聴者は、アルトマンとイーロン・マスクの描写が観客に最も受けにくいと見ていた。しかもAmazonは、監督起用前から脚本の初期版を確認していたと報じられている。
・私なら、AI企業の広報や制作では「投資」「インフラ契約」「作品の承認」を別の判断軸で管理する。相手企業を題材にした発信は、内容の良し悪しより先に利害関係が公開判断を左右しやすいから。これは今回のケースからの私の読み。

https://t.co/dlkEqUjnjw

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

私は、HyundaiがBoston Dynamicsを完全子会社化して、Atlasを工場で使うための土台を固めたニュースだと読んだ。

・Hyundai Motor GroupはSoftBankの残り9.65%を3億2500万ドルで買い取り、6月22日に承認予定だ。2021年に80%を約8.8億ドルで取得していたので、Boston Dynamicsを完全子会社化する流れになる。
・Atlasは2026年1月のCESで公開されたが、デモは遠隔操縦だった。2028年にジョージア州サバンナ近郊のHyundaiの電気自動車工場で稼働する予定で、最初は部品の順番をそろえる作業から始めて、2030年には部品組み立てまで広げる。
・Boston Dynamics側は、新しい工場タスクを1〜2日で学べて、99.9%の信頼性に届かないと現場投入は難しいと見ている。だから、ロボットは「動く」だけでは足りなくて、再現性が本番になる。
・Atlasは人間サイズの手に触覚センサーを持ち、50kgを持ち上げられて、-20〜40℃の工場環境を想定してい���。Boston Dynamics自身も、Atlasを産業現場向けの人型ロボットと位置づけ、学習した動きを複数台へ再展開しながら、新しいタスクを1日未満で展開できる設計だとしている。
・私なら、この話は「四脚ロボットのSpotで商用化できても、Atlasは別物」と読む。ロボット導入は、見せ場よりも先にタスクの切り方と稼働率で決まるし、Hyundaiは自社工場と車両プログラムを持っていて、最初の顧客を自社で持てる上に、Hyundai Mobisのアクチュエータ生産まで握っている。だから、Atlasを段階的に育てやすい。

https://t.co/5TsqbuX7XE

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

atprotoにはインスタンスがなく、ホスティングとアプリを切り分ける分散設計を説明した記事。

・RSSとGoogle Readerの例で、ブログの置き場と読むアプリは別物だと整理している。投稿はGoogle Readerの中に保存されるわけではなく、アプリは集約するだけ。
・Facebook型のSNSは、全体を1つの箱に入れて広告と単一アプリを前提にする。一方、Mastodonの��ンスタンスは、その箱をコミュニティごとに複製して、投稿を相互に送り合う形になる。
・この形だと、ユーザーはインスタンスに属し、別インスタンスの友人を見るには、相手の投稿を届け合う仕組みが必要になる。接続数は O(n²) で増えるので、規模が大きいほど重くなりやすい。
・atprotoは箱を消して、ホスティングとアプリをネットワークの層で分離する。アプリは全体を集約して見せる側なので、ホストの乗り換えと新しいアプリ作りがしやすい。
・著者は実際にその日のうちにホスティングを切り替え、3〜4個のUXのつまずきはあったが自動でできたと書いている。自前ホストにも広げられる。
・私は、分散SNSを見るときは「インスタンスを何個置いたか」より、「ホスティングをどれだけ動かしやすいか」と「新しいアプリをどれだけ試しやすいか」を見る方が、設計の本質に近いと思った。データはアプリの外に置くのが大事。

https://t.co/SHwolPhgtL

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

Tom Di Minoが、AI支援で青銅器時代のミノア文字Linear Aを解読したと主張し、専門家レビュー中だと伝える記事。

・比較対象は1952年にMichael Ventrisが解読したLinear Bで、どちらも文字ではなく音節を使う体系。Linear Bは��料が多かった一方、Linear Aは紀元前1800年ごろから紀元前1450年ごろまで使われ、交易品の目録が多くて言語の手がかりが薄い。両者は60個の共通音節を持っている。
・Di Minoは今年1月に着手し、5月22日の着想をきっかけに、定型の祈祷文を並べて先頭語の差分を見た。各行の先頭語は同じ動詞で、活用だけが違うので、そこが解読の入口になった。
・鍵になったのは、既知のLinear B記号5個とLinear A固有記号 *301、さらに na をつないで、語根 nawaya を引き出した点。そこから「住む / 建てる」に関わるセム語系の語根だと見て、祈祷文をヘブライ語系の祈りに近いものとして読んでいる。
・Di Minoの主張としては、102個の記号のうち37個の読みを提案し、Linear A専用の13記号すべても含めた。さらに383語の語彙一覧と、9ページの草稿まで作っている。
・ただし確��ではなく、Rutgers大学とケンブリッジ大学の言語学者がレビュー中。1957年にもCyrus Gordonがセム語説を出したが広く受け入れられなかったので、今回は別の史料でも同じ読みが出るかが重要。
・Claude Codeを使って記号を系統的に整理し、仮説を試す仕組みを作ったのが面白い。私は、未解読文字ではAIに正解を一発で出させるより、候補を並べて検証を回すほうが実用的だと感じた。

https://t.co/TxGMwsSNMj

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

100語を5段階で測って語彙量を推定するWebクイズ。

・Core Basics / Intermediate / Advanced / Expert / Grandmaster の5段階で、後ろほど珍しい語を出す構成。コメントでは各帯20問の形でスコアが並んでいて、100語を層ごとに見る設計だと分かる。
・実際の投稿では、20/20/20/20/17で79,000語、20/20/18/18/15で71,500語、20/20/15/15/11で58,250語、19/19/16/19/11で63,250語と出ていた。後半の帯が少し崩れるだけで、総語数がかなり動く。
・番組側のまとめでは、英語の現用語数は約171,476語で、一般の語彙は15,000〜35,000語が目安。そこでこのクイズでは、ハンナが72,000語、マイケルが73,000語超と出ていた。
・差がつく理由は、最終帯に古語やかなり特殊な語が混ざるからだと思う。実際に zenzizenzizenzic や zinnzizinnzinnick のような語が出てきて、非ネイティブの参加者も「知っている」と「実際に使える」は別だと感じていた。
・私は、このタイプのテストは、日常で使う語彙の広さよりも、珍しい語をどこまで認識できるかを測るのに向いていると読んだ。学習で使うなら、総点よりも、どの帯で崩れるかを見るほうが弱点を見つけやすい。

https://t.co/6MlaQoteCL

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

Java の Project Valhalla が JDK 28 で最初の preview に入るまでの経緯と、value class / value object で同一性を外して配列を密にする狙いを整理した解説記事。

・Valhalla は 2014年に始まり、途中で 5 つのプロトタイプを試したうえで、今回の��合 PR が 197,000 行超 / 1,816 ファイルになった。記事ではメインの OpenJDK リポジトリへの統合を 2026年7月ごろ、JDK 28 のリリースを 2027年3月ごろと見ていて、preview なので既定では無効。

・JEP 401 の value class は `value` 修飾子で宣言し、全フィールドが実質 final、`synchronized` を試すと IdentityException になる。`==` は同一性ではなく同じ値かどうかを見るので、同一性が必要な場面だけ `Objects.requireIdentity` / `Objects.hasIdentity` を使う。JDK 28 では null はまだ許されるので、非 null 型は別 JEP に切り出されている。

・速くなる理由は、Java が 1995年以来、ほぼすべてを参照型と同一性前提で扱ってきて、配列がポインタの束になりやすかったから。escape analysis みたいに JIT の出来に賭けるのでなく、JVM が scalarization と heap flattening を使えると、その箱とポインタを外せて、ポインタ追跡と cache miss を減らせる。記事の 100万要素の Point[] では、1つあたり 8 byte 級の連続配置�� 64 byte cache line の恩恵が出る。

・昔は Point.val / Point.ref の��重モデルまであったけれど、使う側の認知負荷が重かったので捨てられた。今は「同一性があるか」と「null を許すか」を分ける方に寄せていて、ユーザーには単純さを、JVM には密な配置を渡す形になっている。

・私は、まず不変なドメイン値や配列が多い処理に当てるのがよさそうだと思った。`Object` や型消去されたジェネリクスでは平坦化しづらく、`ArrayList<Point>` はまだ平坦化されない。特殊化ジェネリクスは Valhalla の後半戦で、JDK 28 には入らない。`Integer` などのボックス化された基本型は preview 有効時に value class 化されるので、`Integer[]` が `int[]` に近づく流れはここから見える。

https://t.co/plgH41u8gx

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

私は、WebのWell-Known URIはサイト全体を1か所で知らせたいときに向く設計ガイドだと読んだ。

・著者は Well-Known URI 仕様の作者の1人で、registry の Designated Expert として、現場で受ける相談をもとに使いどころを整理している。登録の必須条件というより、著者が考える実務上の良い作法をまとめた内容。
・robots.txt は典型例で、クローラがサイト全体のアクセス方針を毎回見に行くより、1か所に置いたほうが速くて壊れにくい。 change-password のような、サイト全体で使う機能も同じ発想で使える。
・逆に、登録すると公式っぽく見えるから使うのは違う。registry はお墨付きではなく、サイト全体を知る必要が本当にあるときだけ意味がある。
・URL短縮の代わりにすると、サービスとサイトが 1:1 に縛られる。後でサービスが増えると別サイトに分け直す必要が出るので、フル URL を使えるなら well-known に寄せないほうがいい。ホスト名しか運べないなら、そのときだけ考える余地がある。
・落とし穴は discovery と metadata で、https://t.co/r6caCeWFuN から https://t.co/FzAJZ1WTVt を見に行くのか、リダイレクトを追うのか、ドメインの頂点に���くのかが曖昧だと相互運用が崩れる。複数の発信者がいるサイト、たとえば /~username/ みたいな構成では、1か所に寄せた metadata が重くな��ので、HTTP ヘッダや本文側の別メカニズムも前提にしたほうがいい。
・実務では、既存の /robots.txt から移すなら移行計画を先に作ること、http/https 以外の scheme も明示すること、そして site は scheme / host / port の組み合わせで、ドメイン名だけの話ではないと意識することが大事。まず「本当に site 全体の発見が必要か」を確認してから登録するのが安全。

https://t.co/vfGpwO5p5D

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

DuckDBが速い理由を、SQLの受け取りから列指向ストレージまで分解した第1回の記事。

・この回は3部作の1本目で、6GBのParquetをノートPCで1秒未満に返す例を出しながら、クラスターも設定も移行もテーブル作成もいらない前提で読める。SnowflakeやPostgresのようなサーバー型データベースとは違い、アプリに組み込む分析用SQLデータベースだと整理している。20MB未満の単一バイナリで配れるの���、持ち込みやすさも強い。
・速さの大きな理由は、ODBCやJDBCみたいな行ごとのシリアライズを避けられること。1億行規模の結果だと、変換や関数呼び出しが積み上がって、計算より転送のほうが重くなりやすい。DuckDBはDataChunksを流すベクトル化した実行モデルなので、1値ずつ処理する方式よりオーバーヘッドが小さい。
・実行前の流れはparse / bind / optimize / physical planで、Binderがテーブル名と列名、型を解決し、optimizerがfilter pushdownやjoin順序を詰める。6テーブルのjoinでは30,240通りの木があり、DuckDBはdynamic programmingで候補を絞るので、最適化全体がだいたい1msで終わる。
・物理実行は1本の木をそのままたどらず、pipelineに分ける。WHEREやprojectionやhash joinのprobe側は流しやすい一方、ORDER BYやGROUP BYやhash joinのbuild側は全部見ないと結果を確定できないのでsinkになる。DuckDBは2048行のchunkを各threadのlocal stateに書かせ��ので、共有ロ��クを避けながら並列化できる。
・ストレージは256KBブロック / 最大122,880行のrow group / zone mapで回る。row groupは並列の単位なので、8スレッドで回すなら少なくとも8つのrow groupが欲しい。row groupごとにmin/maxがあるので、`WHERE event_date > '2026-01-01'`なら古いrow groupを丸ごと飛ばせるし、列が時系列で並んでいるほど効きやすい。DuckDB公式docsでも、zonemapは自動で作られ、順序が整った列ほど有利とされている。
・Parquetでも同じで、フッターでスキーマとrow groupの統計を先に見て、必要なcolumn chunkだけを取りにいく。リモートファイルでも全体を落とさずに済むので、フィルタが効くクエリほど速くなる。
・実務では、フィルタに使う列を先に整列する / 必要な列だけを読む / Parquetをそのまま読む / スレッド数に足りるrow groupを用意する、ここを先にやるだけで効きやすい。私は、DuckDBを「小さいデータベース」ではなく「分析用の実行エンジン」として見るほうが、使い方を外しにくいと思った。

https://t.co/hPOVDQODj2

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

Let's Encrypt の本番 API とポータルで、2つの高信頼データセンター間のネットワーク問題による性能低下が続いている障害情報ページ。

・対象は https://t.co/SdZxIx4LfY と https://t.co/b2L67zSMTU の本番系で、ステージング側や .c.lencr.org、CT ログは正常だった
・初回告知は 2026年6月18日 16:04 UTC で、本番 API は性能低下し、クライアントは 400 / 500 エラーを受ける可能性があるとされた
・16:35 UTC には 2つの高信頼データセンター間のネットワーク問題に対して安定化策を入れ、19:40 UTC と 23:59 UTC でも調査を続けていると更新された
・原因候補は上流 ISP と 2拠点間の接続で、私はアプリ改修より先に回線や経路を疑うタイプの障害だと見る
・私は、証明書の自動更新を回しているなら、本番だけ落ちているのか、ステージングまで巻き込んでいるのかを先に切り分ける��、待つべき障害か自分側の設定かが見えやすいと思う

https://t.co/0Pc99ZXTNC

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

私は、Apple M1 の分岐予測器を、ノイズの少ない専用OS Fractal で逆解析した MIT の研究が面白かったです。

・Fractal はベアメタルで起動する自作カーネルで、x86_64 / ARM64 / RISC-V に対応。outer kernel thread はユーザープロセスのメモリに置きつつカーネル権限で動かせて、multi-privilege concurrency で同じ命令列のまま権限レベルだけを変える実験を可能にしている。実装はアセンブリ / C / C++ で 31,000 行超。
・評価は 2020年の M1 Mac mini 8GB 上で実施し、Fractal を他のコードなしでベアメタル起動している。IBP（間接分岐予測器）実験では���128 回の constant branch で PHR をフラッシュし、送信側が 128 回訓練してから受信側が測る流れを使い、各 data point は 1 回だけ測定している。遅延分布は 5000 サンプルで見ている。
・IBP では、ユーザー側が入れたターゲットはカーネルでは実行されない一方、投機的フェッチはカーネル側でも通った。著者は、実行可否を判定する前にフェッチが走るパイプライン競合を仮説にしていて、ユーザーとカーネルが同じ IBP エントリを共有している可能性を示している。
・CBP（条件分岐予測器）はもっとゆるくて、p-core / e-core の両方で権限レベルと ASID をまたいだ誤学習ができた。前の研究で見えた「e-core だけ違う」という見方は、macOS 側の core pinning が素直に効いていなかった影響かもしれない、と著者は見ている。
・Phantom の実験では、dispatch branch を nop に置き換えてもフェッチだけが再現し、実行は一度も通らなかった。Apple Silicon で Phantom speculation の痕跡を示したのは初めてで、M1 でも権限境界をまたぐ投機的フェッチが起きうることが分かった。
・実務的には、ハードのふるまいを詰めたいなら、一般OS 上で手を動かすより、再現性を優先した実験基盤を先に作るほうが強い。Fractal は POSIX 互換 API や vim / GCC / dash まで備えていて、既存の実験コードを移しやすい共通基盤を狙っている。

https://t.co/O6ek8rJrwU

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

GLM-5.2 という公開重みモデルの性能とローカル実行の重さを、具体的な数値で整理した記事です

・https://t.co/72u3HvIuyB の GLM-5.2 は、MoE という必要な部分だけを動かす方式で、全7530億パラメータのうち約400億だけを1トークンごとに使う。公開は 2026年6月16日で、MIT ライセンス、100万トークン文脈、Hugging Face 配布という条件。
・独立指標の Artificial Analysis Intelligence Index v4.1 では 51 で首位。MiniMax-M3 と DeepSeek V4 Pro はどちらも 44、Kimi K2.6 は 43 で、Code Arena WebDev の対戦表では Claude Fable 5 に次��2位だった。
・新しい仕組みは IndexShare で、4層ごとに1回だけ軽い indexer を走らせ、その上位トークン選択を次の3層で使い回す。https://t.co/72u3HvIuyB 側は、これで 100万トークン時の1トークンあたりの計算量を 2.9倍下げ、MTP（先読み生成）の調整で受理されるトークン長を最大20%伸ばせるとしている。後付けではなく、学習の途中からこの設計で育てたのがポイント。
・33分のコーディングセッションでは、ブラウザ上のOS風アプリやゲーム構築はかなり強かった一方、1回のビルドに約15分、タスクあたり約4.3万出力トークンを使うので、処理はかなり重い。GLM-5.1 の約2.6万トークンより増えている。
・MoE で計算は軽く見えても、ローカルで厳しいのは、BF16 の重みが 1.51TB あるから。4-bit の Q4_K_M でも約476GBで、2×A100 80GB か 4×RTX 6000 Ada 級の多GPUサーバー前提��2-bit dynamic でも約241GB、1-bit dynamic でも約176GB 必要で、実用上は 256GB 以上の統合メモリを積んだ Mac Studio か、複数 GPU サーバーが必要になる。Mac Studio でも速度は 3〜9トークン/秒くらいなので、チャットより非同期のエージェント向き。128GB の Strix Halo や 24GB GPU では足りない。
・私なら、ここは最強を入れるかではなく、自分の用途で回るかで考える。256GB+ Mac Studio M3 Ultra は約9,500ドルの初期費用で、API は出力100万トークンあたり約4.40ドル、クラウドレンタルは数ドル/時。長文コードや長時間エージェントなら価値があるけれど、ふだんのローカルチャットなら 30B 級のほうが速くて現実的。プライバシーを重視するなら自前運用、回転数を重視するなら API かレンタルが自然。

https://t.co/M0gTM5eWH1

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

国鉄の分割民営化で、別会社になっても共通のJRマークを保ったロゴ設計と配色の作り方を追った記事。

・対象は日本国有鉄道の分割で生まれた6社の旅客会社と1社の貨物会社で、各社が独立しながら同じJRマークを使う前提だった。
・デザイナーにはかなり自由があり、条件は社名を Japan Railways か Nippon Railways のどちらかにすることだけだった。100案超から絞り込み、発足の2.5か月前にデザインを固めて、124日でロゴ、色、標準書、プレスキット、切符までそろえた。
・配色は、熱転写の印刷方式に合う15色から決めた。JR北海道は薄緑、JR東日本は濃い緑、JR東海はオレンジ、JR西日本は青、JR四国は水色、JR九州は赤、JR貨物はコンテナブルー。
・漢字の社名ロゴでは、鉄の字が金へんと失でできていて、失う金みたいに見えるので、似た形の別パーツに差し替え、国立国会図書館まで確認して詰めた。
・本番の貼り替えは、最初の少数車両ではなく1万両規模に広がり、3月31日の終電から4月1日の始発まで4〜5時間しかない中で、現場が1両��つ手で貼った。
・40年近く変わらないのは、左��どちらでも読めて、走る車両でも潰れにくい太さがあり、JとRの結合が全国を一本でつなぐ印象を出せるからだと思った。作り手が事実、現実、誠実さを軸にしたことも大きい。
・私は、ロゴやUIは見た目だけでなく、貼る場所、動く速度、印刷方式まで先に決めるほうが長く使えると感じた。

https://t.co/1HOgulVyBM

[Tech Deepdive Tokyo / IT技術ニュース @_tech_deepdive]

Datasette の中で、読み取り SQL と許可済み書き込みを安全に扱う HTML+JavaScript アプリ基盤を作った記事。

・scripts と forms だけを許した `iframe` sandbox と CSP で、子フレームは親 DOM / cookie / localStorage に触れず、外部ホストへの通信も止めている。CSP で弾かれた失敗は親側に返して見えるようにしていて、壊れたときの原因を追いやすい。
・読み取りは SQL をそのまま使える一方、書き込みは Datasette 1.0a31 で強化された stored queries で個別に許可する。親子フレームの通信は最初 `postMessage()` だった���、いまは `MessageChannel()` に寄せて、ページ遷移後にチャネルが自動で閉じるようにしている。
・背景には、Eventbrite 時代に SQLite に集約した文書を Datasette + 自作 HTML/JS 検索 UI で回していた経験がある。クライアント側で SQL を組む構成は冗談みたいだったけれど、実際にはかなり速く試せたので、今回の Apps も「自作 UI をデータベースに近づける」発想で組まれている。
・作成画面には、DB schema を含むコピペ用プロンプトが出る。プラグイン自体は LLM 前提ではないけれど、私は単一ファイルの HTML アプリを AI に投げやすい形だと感じた。外部通信は特定の HTTPS オリジンだけに絞られ、履歴操作は無効、CORS はそのまま残る。
・実装は Claude Code の Claude Opus 4.6 から始まり、その後は Codex Desktop と GPT-5.5 xhigh で詰め、セキュリティ評価では Claude Fable 5 が実���の問題を見つけた。AI 支援を使っても、安全側の確認は別に必要だった。
・見つかった攻撃は、`create-app` 権限の低権限ユーザーが CSP 許可済みホストへデータ��流し込み、管理者を踏ませると管理者権限で私有データを読める、という権限昇格だった。対策は `apps-set-csp` と `allowed_csp_origins` を分け、許可先を信頼できる人だけに閉じること。私は、ここを先に固定してから UI を増やすのが大事だと思う。

https://t.co/sRXmPEGDrx