五里霧中｜こぶりー

五里霧中

blog.ast.moe

YubiKeyの仕組みを調べた

ふと思ったのですが、YubiKeyってどういう原理で認証しているのでしょうか。 2023年にYubiKey 5C NFCを使い始めて、その後USB-Aのモデルも買い足しました。当時は1Passwordのアカウントを守るために導入し、持ち歩く用と家に置いておく予備を登録する、という使い方を考えていました。 USBに挿して、必要なときに触れる。スマートフォンならNFCでかざす。使う側の操作はかなり少ないのですが、その裏で何をやっているのかは、ちゃんと整理したことがありませんでした。あの金色の部分は指紋を見ているのか。そもそも電池がないのに、どうやって動いているのか。今回はYubicoの公式資料と認証の仕様を読みながら、この辺りを調べてみました。手元のキーを分解したり、暗号処理を実測したりした記事ではありません。普段のログイン操作を、仕組みの側から見直した記録です。 YubiKeyの対応方式 YubiKeyはハードウェアの名前で、内部では複数の認証方式を扱えます。そのときに何を使ったかで、やり取りする情報も安全性の性質も変わります。私が買ったYubiKey 5シリーズには、FIDO2、FIDO U2F、OATH、Yubico OTP、PIV、OpenPGPといった機能があります。全部が同じ暗号処理をしているわけではありません。公式の機能一覧を見ると、小さな本体の中に用途の違うアプリケーションが入っている、と考える方が近そうです。代表的な違いを並べると、こうなります。方式何を使って確かめるか利用時に外へ出るもの FIDO2 / U2F 公開鍵と対になる秘密鍵で署名する認証要求に対する署名など OATH-TOTP / HOTP サーバーと共有した秘密からコードを計算する 6桁や8桁などの認証コード Yubico OTP 共通鍵で暗号化した、カウンターなどを含むデータ長い文字列のワンタイムパスワード PIV / OpenPGP 保管した秘密鍵を使って暗号処理をする署名や復号結果など、操作に応じた応答ブラウザに「触れてください」と言われるときと、認証アプリで6桁の数字を表示するときは別の仕組みです。ここを混ぜると、サーバーに秘密を渡すのか、という問いの答えまで変わります。なお、Security Keyシリーズのように、FIDOに機能を絞った製品もあります。まずは、Webのセキュリティキーやパスキーで使うFIDO2を中心に見ていきます。公開鍵と秘密鍵 FIDO系の認証で中心になるのは、公開鍵暗号を使った電子署名です。公開鍵と秘密鍵は、対になる二つの鍵です。秘密鍵を使ってデータに署名し、サービスに渡した公開鍵を使ってその署名が正しいかを検証します。電子署名は、相手だけに内容を読ませる暗号化とは目的が違います。確認したいのは、対象のデータについて、対応する秘密鍵を使える側が署名したかどうかです。 YubiKeyをFIDOの認証器として使う場合、サービスには公開鍵を登録し、秘密鍵を使う処理はキーの内部で行います。サービスはログインのたびに署名を確認することで、登録した鍵を今使える相手なのかを確かめます。YubicoのFIDO2開発者向けガイドでは、この構成と各参加者の役割が説明されています。パスワードとの大きな違いは、ログインの際に、繰り返し使える秘密そのものをサービスへ渡さなくてよいことです。公開鍵だけを見て同じように署名することはできません。公開鍵から秘密鍵を求めるのが現実的な計算量では困難になるよう、暗号方式と鍵の大きさが選ばれています。メールアドレスなどの漏えいや、サーバー自体の侵害は別の問題です。ここで減らせるのは、保存していた公開鍵の漏えいが、そのまま本人として署名できる能力の漏えいになる危険です。キーの登録ログインの前には、キーの登録が必要です。サービスの設定画面で「セキュリティキーを追加する」といった操作をする部分ですね。登録では、サービスからブラウザへ、ランダムな値やサービスの識別情報、アカウントに関する情報、利用できる暗号方式などが渡されます。ブラウザやOSはそれを認証器へ伝え、キーが認証用の鍵を生成します。返ってきた公開鍵やcredential IDなどを、サービスがそのアカウントに関連付けて保存します。登録の流れは、Yubicoの資料にも載っています。 credential IDは、使う認証資格情報を識別する値です。同じ物理キーで複数のサイトに登録できるのは、このような資格情報をサイトごと、登録ごとに扱っているからです。このときサービス側がしているのは、「このアカウントには、この公開鍵で検証できる認証を許可する」という登録です。YubiKeyの製品名だけを見て本人扱いするわけではありません。同じモデルのキーをもう一つ買ってきても、登録していなければログインできません。登録する時点で、アカウントの持ち主も確認する必要があります。認証器は、誰のアカウントなのかを最初から知っているわけではありません。サービスが本人を確認してから、今後使う鍵を結び付けます。だから、鍵の追加を許す操作も大事ですね。ログイン時のやり取り登録が終わると、ログイン時にはサービスが新しいランダムな値を用意します。これはchallenge、チャレンジと呼ばれます。「この値を含むデータに、登録した鍵で署名してください」という問いを出して、正しい署名が返ってくるか確かめるわけです。毎回違う問いを出すので、以前の正解をそのまま持ってきても、今回の問いへの答えにはなりません。Yubicoの認証処理の説明には、チャレンジと返される情報が整理されています。たとえば、昨日のログインでは「A」という値に対する署名が正しかったとします。今日サービスが出した値が「B」なら、昨日の「A」への署名を送っても、今日の認証には使えません。署名を検証するときには、鍵が合うことに加えて、今回発行したチャレンジが応答に含まれていることも確認します。新しい問いに答えられることが、その時点で鍵を使える証拠になります。コピーした過去の通信だけでは、新しい応答を作れません。サービスは十分に予測しにくいチャレンジを生成し、どの認証操作に発行したのかを管理し、使用済みや期限切れの応答を受け付けないようにします。操作の流れをかなり省略すると、こうなります。 sequenceDiagram participant S as サービス participant B as ブラウザ・OS participant Y as YubiKey participant U as 利用者 S->>B: 今回のチャレンジと認証条件 B->>B: 呼び出し元と認証先を検査 B->>Y: 認証先のIDと署名対象の情報 Y-->>U: 操作を要求 U->>Y: タッチ・必要ならPIN等で確認 Y->>Y: 秘密鍵で署名 Y-->>B: 署名と認証器の情報 B-->>S: 認証応答 S->>S: 公開鍵で署名と各条件を検証署名するデータここまで「チャレンジに署名する」と書きましたが、実際のWebAuthnの認証応答はもう少し情報を持っています。

2026/10/08 06:588時間ぶり

搭乗しちゃった……

10月6日は北海道を離れる日です。昨日のジンギスカンを600gくらい食べたせいか、朝から若干胃もたれしています。もう若くないのか。小樽を離れて、新千歳空港へ向かいます。またいつか！花梨先輩、またいつか！とりあえずミクさんに会いに空港では、まずミクさんのご尊顔を拝みに行きました。ミクさんにご挨拶店内を眺めていたら、テトさんのグッズを目撃しました。31回くらい見返した。雪ミクのお店へその後はラウンジへ。帰りたくないでござる、という小樽への未練を朝からビールで薄めています。足立レイとテトさんのぬいと、朝のビールソフトクリームもいただきます。搭乗前にソフトクリーム北海道を離れますまずは羽田行きに乗ります。東京行きの搭乗口搭乗しちゃった……。名残惜しそうに外を眺める足立レイ窓の外には海岸線が見えます。飛行機から眺める海岸線茨城県のあたりで太平洋の方を見ていたら、雲が境目のように並んでいました。もしかして前線の境界面？雲の境目のような景色富士山も見えました。南アルプスも、空から見ると高いですね。窓の外に富士山羽田で端から端へ羽田では65番あたりから47番まで歩くことになりました。端から端やないか。羽田の搭乗口の案内図高松行きは、A320ではなくB737でした。珍しい。 14時20分ごろ、高松に着きました。高松に到着小樽行きたい。移動疲れしたので、筋トレに行ってリセットすることにしました。夜はエースコンバット8をやろうとしたのですが、ダウンロードが終わらないので7をやっていました。

2026/10/07 22:1921分ぶり

北海道で仕事の日

昨日は札幌マラソンを走りましたが、10月5日は北海道でリモートワークです。ハーフを走った翌日ですが、特に筋肉痛はありませんでした。今日は風が強い。小樽では、部屋にこもって仕事をしていました。お昼のザンギお昼に小樽から千歳へ移動しました。昼食はザンギとラーメンをいただきます。普通の唐揚げくらいのサイズを想像してザンギを2個頼んだら、北海道の大地のように巨大な揚げ物が出てきました。想像していたサイズと違うザンギこれで2個なのか……。ラーメンも頼んでいるので、なかなかの量になってしまいました。お昼のラーメン夜は新千歳空港へ仕事を終えて、お土産を買いに新千歳空港へ。晩御飯は空港でジンギスカンをいただきました。とりあえずビールを一杯。ジンギスカンの前に一杯お土産を買って晩御飯を食べたら、また小樽に戻ります。小樽に戻ってからは帰り支度です。荷物を鞄にしまうたびに、旅が終わるのを実感してしまいます。とはいえ、すでに次の新千歳行きの航空券も手元にあります。また来ます。

2026/10/07 21:572日ぶり

札幌マラソンの日

今日は札幌マラソンを走ります。一昨日北海道にやってきたのは、このためでした。朝は寒い。四国から来ると気温差が堪えますね。真駒内へ向かう途中で「真駒内」が「猫まみれ」に聞こえたので、走る前から疲れているのかもしれません。天気はよく、木も色づいていました。秋じゃん。朝の紅葉朝の会場寝坊せず、無事に会場へ着きました。まずは第0関門を突破です。参加者のおっちゃんと世間話をしていて、どこから来たのかと聞かれました。「おt……香川県です」危うく小樽から来たことにするところでした。朝は寒かったのに、日が当たると今度は暑い。とりあえず2時間は死守したハーフの記録速報は、ネットで1時間55分38秒でした。ネットタイムは1時間55分38秒長距離を走る練習をしていなかったので、心拍数を上げて誤魔化していたのですが、18kmで普通にばてました。時計のスプリットを見ても、19km、20kmとペースが落ちています。心拍数は上がっているのに足がついてこない。時計で記録した後半の1kmごとのスプリット来年に向けた課題も見つかったので、次もエントリーしなきゃ。次の小樽運河ロードレースまでに精進します。走り終わって真駒内の競技場の広いところに座って休んでいたら、思ったより寒い。汗冷えもあって、このままだと低体温症になるんじゃないかと思うくらいでした。思わずストームクルーザーを着込みました。走っている間は暑かったのに、止まるとこうも違うのか……。さて、小樽へ手荷物を受け取って、赤い上着を着て80Lのザックを背負い、小樽へ向かいました。リスポーンしました。小樽で小春六花のパネルに再会お昼は回る寿司。小樽ビールもいただきます。回転寿司で小樽ビール隣にいた台湾から来た人が、この後どこへ行こうかと話していたので、日没まで時間があるなら天狗山がおすすめですよと伝えておきました。たくさん食べたので、軽い運動に商科大へ行ってきます。軽い運動のつもりだった地獄坂を登ります。小樽商科大学へ続く地獄坂午前中にハーフを走ったとはいえ、この坂を走るほどの体力はありません。登るのに結構時間がかかってしまいました。小樽にいたら軟弱な足腰も強くなりそうです。何人ものオタクの心をへし折った坂を登って、小樽潮風高校までやってきました。小樽商科大学前でテトさん、花梨先輩、足立レイとついでに天狗山へ行くことにしました。天狗山、こんなに遠かったか？着いたら花梨先輩がお出迎えです。天狗山の花梨先輩花梨先輩と夕方の小樽を眺めるさっき寿司屋で話した台湾の人も来ていたので、今度は写真を撮る係をしていました。札幌マラソンの後に15kgくらいのザックを背負って歩き回ったら、ランニングシューズがキュッキュッと鳴るようになりました。壊れたかもしれません。軽い運動とは。

2026/10/04 23:341日ぶり

小樽で過ごすマラソン前日

昨日は小樽にやってきました。今日は小樽をうろうろします。まずは荷物を預けて朝食へ。雨でなければ鱗友朝市に行くのもありだったのですが、石と鉄さんへ向かいました。ところが、今日はモーニングがお休みで11時からとのこと。oh……。お昼に出直します。とりあえず余市へそれまでに余市へ燃料を買いに行きます。ウイスキーのほうです。小樽駅で余市行きのバスを待っていたら、貴賓館行きのバスを聞かれる実績を解除しました。無事に仕入れを済ませました。余市でウイスキーの仕入れウイスキーを購入したら、またバスで小樽に戻ります。工場の売店の開店直後にバスで乗りつけて、ちょうど買い物が終わったころに戻りのバスがある。酒カス仕様のダイヤになっていて、とても助かりますね。小樽と余市で天気が違う。朝から空の様子が落ち着きません。石と鉄さんでお昼 11時を過ぎたので、石と鉄さんに戻ってきました。お仕事姿の千冬ちゃんにも会えました。石と鉄さんのお仕事姿の千冬ちゃん明日に向けてカーボローディングをしていきます。石と鉄さんでパスタをいただきます食べ終わるころには雨もやんでいました。街を歩きながら、花梨先輩、千冬ちゃん、六花ちゃんのパネルを巡ります。今回も親指を立てて記念撮影。ノルマ達成です。岩永時計店の花梨先輩と千冬ちゃんと記念撮影六花ちゃんとも記念撮影かま栄ではちくわを買いました。小松島の竹ちくわくらいのつもりで買ったら、思ったよりデカい。かま栄の焼きちくわ年パスを使いに水族館へ午後はおたる水族館へ。年パスを使いに来ました。トド岩のあたりは波が高い。朝は雨だったのに、今は青空も見えています。花梨先輩とトド岩を眺める館内の花梨先輩とも、自作のアクスタを並べて記念撮影です。おたる水族館の花梨先輩と、自作の花梨先輩そして、ほっけパーカーを買ってしまいました。買ってしまったほっけパーカー明日に備えます水族館の後は、明日のマラソンの無事を祈りに行きました。お参り先で六花ちゃんがお出迎え小樽で過ごした日数を全部足したら、そろそろ30日くらいになりそうです。住んだことはないのですが、来るたびに滞在日数だけは増えていく。夜は明日の準備。ジップロックを忘れていたので、コンビニへ買いに行きました。明日は花梨先輩のTシャツで走ります。小樽潮風高校陸上部、やるぞ。明日はこの花梨先輩Tシャツで 22時過ぎには寝ることにしました。まずは寝坊せず会場に着かなくては。

2026/10/03 23:001日ぶり

6月以来の小樽へ

今日は飛行機に乗って遠出をしたいと思います。というわけで、まずはガソリンを補給していきます。搭乗前のガソリン補給無事すんなりと搭乗しました。花梨先輩のアクスタも一緒です。機内の窓辺で花梨先輩と高松空港から羽田に飛んで、羽田から新千歳に飛んでと。やはり北上すると日没が早いのを感じます。まだ17時過ぎですが、夜が追いかけてきているような空の色をしていますね。夜が追いかけてくるような、17時過ぎの空 6月以来の小樽 20時ごろに小樽にやってきました。 6月以来ですが、なんか帰省でもしたような気持ちになります。住んだこともないのに「ただいま」と言いそうになるし、存在しない幼馴染の記憶まで蘇ってくる。故郷より先に思い出のほうを捏造してしまっている。前回の旅をきっかけに「夏草のレール feat.夏色花梨」を作ったりもしました。 20時ごろの小樽駅周りを見ると、みんな寒そうな格好をしています。こちらは半袖なのですが。小樽は21時閉店のお店が多く、20時くらいに到着すると晩御飯難民になるのです。なぜ毎回同じ過ちを繰り返してしまうのか……。いつもお世話になっているSAKEバルMARUMOTOさんで夕食をとりました。とりあえず駆け付け一杯の小樽ビールを。 SAKEバルMARUMOTOさんで小樽ビールつくねを食べつつ、続けてワイン、日本酒を嗜む程度にいただきました。 HALF TONEさんへお店を後にして、HALF TONEさんに向かいました。 HALF TONEさんの花梨先輩の立ちパネルマスターに挨拶して、この立ちパネルと同じ意匠のアクスタを購入。持ってきた自作の花梨先輩と並べて記念撮影をするのが、今回ここに来た目的でした。自作の花梨先輩と、HALF TONEさんで購入した花梨先輩のアクスタ無事目的を達成です。カクテルを嗜んで、マスターとお話をして、今日の日は終わりです。ちなみに、今回北海道に来たのは日曜日の札幌マラソンに出走するためです。

2026/10/02 23:001日ぶり

文章を作るわけじゃない。Jevは何をするAIなのか

概要 Jevという名前を見かけても、チャットで質問するAIなのか、検索用のモデルなのか、既存のLLMを小さくしたものなのかは分かりにくい。自分もJevを使うMCPサーバーを作ったが、APIの呼び方を知ることと、その返り値をどう理解すればよいかは別の問題だった。 TypeSafe AIのJev は、渡された情報に対して、あらかじめ定義した質問へ判断を返すモデルである。返ってくるのは自由な説明文ではなく、Yesの確率、候補ごとの確率、段階評価など、プログラムで扱うための値だ。例えば問い合わせの文章を渡し、「請求の相談か」「配送の相談か」「担当者へ回す必要があるか」を評価する。回答を読んで会話を続けるというより、回答を受け取ったコードが次の処理を決める使い方になる。このような仕事はLLMでもできる。実際、多くのシステムがLLMへ分類や採点を依頼している。しかし、文章として答えを生成すること、指定した形の値を返すこと、正しい確率を返すこと、返された判断から行動を決めることは、それぞれ違う問題だ。出力がJSONとして正しくても、判断の中身は間違う。回答に0.9と書かれていても、その数値が実際の正解率を表しているとは限らない。この記事では、まずLLMを判断処理へ組み込むときに何が難しいのかを考える。その後、Jevの公開された入出力と処理方式を確認し、確率予測、校正、適正スコアリング則、意思決定、判断の保留という基礎理論へ進む。最後には、それらを問い合わせ分類のシステムへ戻し、何をモデルへ任せ、何をコードで決めるかを考える。対象は2026年10月1日に確認した公式資料と公開研究である。Jevのネットワーク構造、重み、具体的な学習レシピを再現した記事ではない。公開情報から確認できる仕様、理解するための一般理論、自分が考えた設計例を分けて扱う。以下の問い合わせ、確率、料金計算、評価表は、特に出典を付けた箇所以外は説明用に作った例であり、Jevへ送信して測定した結果ではない。 1. Jevを初めて聞いた人へ 1.1 文章を読んで、決めた範囲の答えを返す例えばネットショップに、次の問い合わせが届いたとする。商品は届いたのですが、カードの明細に同じ金額が二つあります。片方を取り消してほしいです。人間なら、請求に関する話で、取り消しを求めていると読み取れる。ところが、コードで同じ処理を作ろうとすると、どの語を条件にするかが問題になる。「二重請求」という語があれば請求担当へ回す、と決めても、この文章にはその語がない。「カード」がある文章を全部請求へ回せば、商品に付属するカードの話まで混ざるかもしれない。こうした、表現はばらばらだが意味で判定したい部分にモデルを使う。ただし、担当部署を選ぶだけなら、毎回丁寧な回答文を書いてもらう必要はない。システムが必要としているのは、例えばbilling、delivery、product、unknownのどれに近いかという情報だ。 Jevは、このような入力と回答範囲を与える形式で使う。資料の本文や顧客の文章をstateへ入れ、何を判断するかを質問として定義する。モデルが返した候補や確率を、呼び出し側のコードが受け取る。問い合わせを送る、担当者へ通知する、追加情報を聞くといった行動は、その後のシステムに残る。 flowchart TD A["問い合わせの文章"] --> B["状態を用意する注文情報・必要な履歴"] B --> C["Jevへ質問する担当分野はどれか"] C --> D["候補と確率を受け取る"] D --> E["コードで取扱いを決める"] E --> F["担当へ回す"] E --> G["情報を追加して確認する"] この図のJevは、問い合わせ対応の全部を実行しているわけではない。カード会社へ連絡したり、実際の請求記録を調べたりするのは、別に用意した処理である。文章だけを見て「二重請求の相談らしい」と分類できても、本当に二重に決済されたかは決済記録を確認しなければ分からない。ここを最初に分けておくと、Jevが何をする道具なのかを理解しやすい。与えた証拠について、決めた問いを評価する。外界の事実を調べることと、証拠の意味を判断することは、システムの中で別々の仕事になる。 1.2 名前とSystem Oneという呼び方 TypeSafeはJevをSystem One modelと呼んでいる。この名前を理解するために、先に心理学で使われているSystem 1とSystem 2を説明しておきたい。Jev独自の用語でも、コンピューターの規格名でもない。人間の考え方を、素早く自動的な処理と、注意を向けて考える処理に分けて説明するための呼び方だ。 System 1は、あまり意識して手順を組み立てなくても進む、直感的な処理を指す。例えば、よく知っている人の顔を見て誰なのかが分かるとき、顔の特徴を一つずつ文章へ書き出し、候補を順番に比較しているわけではない。簡単な例として「2足す2はいくつか」と聞かれたときも、多くの人は計算の手順を意識せず、すぐ4と答えられる。一方、System 2は、注意を向け、途中の結果を保持しながら進めるような、熟考を伴う処理を指す。例えば「17掛ける24」を暗算するとき、17掛ける20と17掛ける4に分け、二つの結果を足す、といった手順を考えるかもしれない。見慣れない契約の条件を読み、例外と適用範囲を確認する作業も、こちらのイメージに近い。この呼び方はKeith StanovichとRichard Westが用い、Daniel Kahnemanが広めた。Kahnemanの A Perspective on Judgment and Choice でも、二つの処理の特徴と名称の出所が説明されている。脳の中に「System 1という部品」と「System 2という部品」が、二台のコンピューターのように独立して存在するという意味ではない。ここでは、思考の進み方を区別するための枠組みとして読めばよい。また、「直感は間違いで、熟考は正解」という区別でもない。慣れた仕事なら、経験を積んだ人が素早く適切に判断できることもある。反対に、時間をかけて考えても、使った情報や前提が間違っていれば答えは間違う。速さの違いと、正しさの違いを一緒にしないほうがよい。この話をJevへ戻すと、公式の説明では、System Oneという名前を、この素早い判断と熟考の対比から取っている。必要な材料と質問を与え、限定された答えを返す使い方を、人間の直感的な判断になぞらえた名前だ。人間の脳の仕組みをそのまま再現しているという意味ではない。

2026/10/01 11:3312時間ぶり

Goにおける明示的な純粋性制約の静的検査: mikotoの設計と検証

概要 Goの関数の長さと、明示的に指定した関数の純粋性に関する制約を検査するmikotoを作った。関数宣言へ//mikoto:pureを付けると、値型だけを用いた入出力、パッケージ変数へのアクセス、参照先の変更、ポインタの間接参照、呼び出し先などを検査する。実装にはGoのASTと型情報を使い、検査対象を同一パッケージ内の関数宣言に限定している。背景にあるのは、コードの量が増えたとき、設計上の意図を毎回人間が読み直して確認することの難しさだ。「この関数は入力から結果を計算するだけ」という意図があっても、後から時刻の参照や共有状態の更新が加われば、その前提は変わる。そこで、守りたい制約をソースへ明示し、実装がその制約から外れたときに診断する形にした。初期実装を検証すると、型パラメータを介したmapの走査や、配列ポインタの暗黙の間接参照を見逃す一方、正当なジェネリック呼び出しや括弧付き操作を拒否する問題が見つかった。PR #6ではこれらと行数計算の問題を修正した。この記事では、検査モデル、実装、修正例、検証結果を順に示し、診断がないことから何を言えて、何を言えないかを考える。以下は学術論文のように問題設定と評価を分けた開発記録であり、一般的なGoプログラムの参照透過性を証明した報告ではない。対象は2026年9月30日のmain、commit 2235f226aaである。提案する使い方と、実装で確認できる動作も区別して書く。 1. 背景と問題設定 1.1 実装量と確認量は同じ速度で増えない AI Codingとコードレビューについての記事では、人間がすべてのコードを同じ密度で読み続けることに依存せず、仕様、テスト、静的解析、観測性を強くするという考え方を書いた。mikotoは、そのうち機械的に確認できる設計上の制約を、小さい範囲から検査する試みになる。コードレビューでは、個々の式の正しさだけでなく、関数の役割が変わっていないかも確認する。料金を計算する関数がデータベースを更新していないか。入力を分類する関数が現在時刻を直接読んでいないか。小さな計算のための関数に、通知、ログ出力、共有キャッシュの更新が追加されていないか。どれもコンパイラの型検査だけでは、設計上の問題としては扱われない。こうした変更は必ずしもバグではない。時刻を読むことも、状態を更新することも、システム全体では必要だ。ただ、入力から結果を計算する部分と、外界を読み書きする部分を分けていたなら、その境界を変える判断が必要になる。コードが動くことと、意図していた責務に収まることは、別々に確かめたい。そこで「副作用がありそうか」を都度LLMへ尋ねる前に、明確に禁止したい構文や依存先を解析ツールで調べることを考えた。診断の根拠がソース上の操作に対応していれば、変更した人は、その操作を計算部分から外すのか、関数の責務を変えるのかを判断できる。問題を見つける仕組みと、その問題をどう扱うか決める仕事を分けられる。 1.2 二つの制約を一つのツールで扱う mikotoには、関数の長さの検査と、指定した関数の純粋性制約の検査がある。前者はすべての対象関数に適用し、後者はマーカーを付けた関数だけに適用する。長さの上限は既定で80行、-max-lines=0を指定すると行数検査を無効にできる。両者は関連するが、同じ性質ではない。短い関数でも外部状態を複雑に変更できるし、長い関数でも値の変換だけを行える。関数を短く分割しただけで、依存先が明確になるとも限らない。行数は読む範囲を見直すための指標、純粋性制約は外部状態との関係を制限するルールとして、独立に扱っている。一つの関数を何行までにするかは、プロジェクトの方針で変わる。80行という既定値に品質の普遍的な境界があるわけではない。同様に、すべての関数を純粋にすることも目的ではない。ファイルを開く関数、HTTP要求を送る関数、トランザクションを開始する関数には、外界とのやり取りが本来の責務としてある。この記事で扱う問いは、「Goの任意の関数が純粋かを完全に判定できるか」より狭い。入力に対する計算へ役割を限定したい関数を明示したとき、その境界を破る操作を、どの程度小さく、説明可能なルールで検査できるか。そして、そのルールをGoの構文と型の仕組みに合わせて実装すると、どこで単純な判定が破綻するか、という問いである。 2. 純粋性をどのような性質として扱うか 2.1 外部への変更と外部への依存純粋関数を説明するとき、「副作用がない」という言葉だけでは範囲が曖昧になる。外部状態を書き換えなくても、それを読み取って結果を変える関数は、入力だけから結果が定まらない。現在時刻を返す関数は、自分で時計を変更していなくても、同じ引数で別の値を返せる。例えば次の二つには、異なる問題がある。 var rate = 2 func Multiply(n int) int { return n * rate } func Count(n int) int { rate++ return n * 2 } Multiplyはパッケージ変数の現在値に依存する。Countは戻り値だけ見れば同じ入力で同じ結果になるが、呼び出すことで外部状態を変更する。戻り値の決定性と、外部状態を変えないことは、分けて考える必要がある。mikotoは、指定した関数からパッケージ変数へアクセスすることを、読み書きの両方で診断する。概念的には、引数をx、呼び出し前の外部状態をs、戻り値をy、呼び出し後の外部状態をs'として、関数の実行を次のように書ける。 execute(f, x, s) = (y, s') 外部状態を変えない: s' = s 結果が外部状態に依存しない: y = g(x) これは説明のためのモデルで、mikotoが実際に状態空間を列挙して確認しているわけではない。また、何を外部状態と観測に含めるかで性質の意味が変わる。メモリ割り当てやGCまで含め、機械の状態が一切変わらないことを要求したら、普通の計算もほとんど成立しない。ここで関心があるのは、計算の結果と、呼び出し元や外界から観測する依存・変更の関係だ。 2.2 参照透過性との距離参照透過性は、式をその値で置き換えても観測される振る舞いが変わらない、という考え方で説明できる。ある計算を一度行って結果を再利用することと、必要な場所で毎回実行することが同じなら、計算の置き場所や回数を考えやすくなる。ただし、プログラムでは戻り値だけが観測対象ではない。panic、無限ループ、資源消費、浮動小数点の扱い、実行環境の違いも関わる。さらに、戻り値をGoの==で比較すればよいとも限らない。NaNのように、自分自身との比較が真にならない値もある。意味上の同じ結果と、特定の比較演算の結果を混同したくない。 mikotoのREADMEでも、検査を参照透過性の数学的な証明とはしていない。診断がなかったという結果は、現在のルールに抵触する操作を検出しなかったという結果だ。メモ化や実行順の変更を正当化する証明書が生成されるわけではない。それでも、外部状態を読む経路と変更する経路を減らすことには意味がある。原因が入力へ寄れば、テストの条件を作りやすくなり、失敗したときに再現すべき情報も整理しやすい。普遍的な保証を得る前に、調べる範囲を小さくする効果がある。 2.3 ローカル変数の変更は許可する外部状態を変更しないことと、関数の内部で一切代入しないことは違う。例えば整数の和を計算するとき、ローカル変数を更新して結果を蓄積しても、その変数が外へ共有されていなければ、呼び出し元の状態を変更したことにはならない。 //mikoto:pure func Sum(n int) int { total := 0 for i := range n { total += i } return total } 現在のmikotoはこの関数を受理する。totalとiへの代入があるから拒否する、というルールではない。通常の代入では左辺の括弧を外し、識別子なら許可する。もしその識別子がパッケージ変数なら、別の名前参照の検査で診断する。

2026/09/30 22:3814時間ぶり

Boaのgetter返値がinline cache更新中のGCで回収された

OmoikaneのWeb Platform Tests（WPT）で、フォームに関連付けられたCustom Elementのテストを動かすとSIGSEGVになった。最初に見つかったのはJITを含む構成だったので、BoaのJITかGCとの組み合わせを疑った。しかしJITを無効にしても同じクラッシュが再現し、最終的にはgetterの返したオブジェクトをVMのレジスタへ保存するまでの、わずかな区間に原因があった。 PR #1187で修正したのは、BoaのGetPropertyByNameとGetNameGlobalという二つの命令だ。プロパティを読む命令の途中でinline cacheを更新するとGCが走り、まだGCから見える場所に置かれていないgetterの返値を回収していた。この記事では、最初のWPT失敗からそこに至るまでを記録する。以前書いたArray.from()でのGC参照保持漏れと同じく、Rustのローカル変数にJsObjectがあるだけではBoaのGCにとってrootとは限らない。ただし、今回はユーザーコードを呼ぶ前後ではなく、getterの実行が終わった後にVM内部でcacheを更新する順番が問題だった。 Mutation最適化の後にWPTが落ちたきっかけはPR #835で試した追加のMutation最適化だった。queueMutationのinitのcloneを減らす変更と、使っていないlayout observer hookを抑える変更を同時に入れると、Gate4 compatibilityの固定WPTでcustom-elements/form-associated/form-associated-callback.htmlがsignal 11で終了した。Issue #858に最初のCIとローカル再現の結果が残っている。最適化を入れる前のrevisionでは同じ条件を通過し、二つの変更を一つずつ適用した試験もそれぞれ成功した。一方、両方を適用すると落ちる。ひとまず追加変更はrevertして、PR #835の残りを進めた。ただし、「二つの最適化の組み合わせがクラッシュを見せた」ことと、「Mutationの処理に無効な参照を作るバグがある」ことは同じではない。割り当ての回数や順番が変わると、別の場所にあったGCの寿命問題が表面化することもある。このテストの中身を分割すると、五つのtest()は単独では全部通った。二つ、三つ、四つを選ぶ組み合わせも通るのに、元の順序で五つ続けると落ちる。五つ目のformのid更新を外しても再現した。特定の一操作が必ず間違っているというより、それまでに積み上がった実行状態や割り当て量が発火条件になっているように見えた。この段階ではまだ仮説だ。最初に取れたバックトレースには、BoaのJsObject::__get__、VMのGetPropertyByName、JIT trampolineが並んでいた。Gate4のjit-stress,jit-differential構成で発見したこともあり、JIT側の問題に見える。ただ、停止した場所は不正な参照を使った場所であって、その参照を不正にした場所とは限らない。 JITを止めても落ちる調査を進めると、WPT manifestを差し替えるときの相対パスが作業ディレクトリに依存していたことが分かった。そこを合わせて、保存していた旧triggerのバイナリと同じWPTを再実行すると、五つのテストを続けたときのSIGSEGVを安定して再現できた。ここでbaseline JITを明示的に無効にして、同じ入力をインタプリタだけで動かした。それでも3回中3回落ちた。JIT有効時に初めて観測したことは事実だが、この再現条件ではJITの機械語生成やstack mapが必要条件ではない。調査の対象はGCとインタプリタ側の値の扱いに移った。次に、GCの閾値を変えてみた。通常の設定では5回中5回クラッシュし、major GCの閾値だけを1GiBにしても5回中5回クラッシュした。一方、nurseryの閾値だけを1GiBにすると5回中5回通った。これはnursery collectionのタイミングが強く関係するという手掛かりにはなる。しかし、この実験だけで「どのcollectionが、どのオブジェクトを回収したか」までは分からない。閾値を上げるのも根本修正ではなく、クラッシュするタイミングを遠ざけているだけだ。 getterの返値は、まだVMレジスタにいなかった決め手になったのは、旧triggerをValgrindで追った結果だ。PR #1187の調査記録では、最初のinvalid readはGcRefCell::try_borrowで検出され、対象の割り当てはProxyオブジェクトだった。解放したminor collectionは、InlineCache::setがweak shape handleを作る途中で起きていた。ここでGetPropertyByNameのslow pathを見ると、順番はこうなっていた。object.__get__は、通常のデータプロパティならその値を返し、getterのあるプロパティならgetterを実行して結果を返す。getterは新しいオブジェクトを作って返せる。 getterを実行し、返値をRustのローカル変数に受け取る -> inline cacheへプロパティの情報を登録する -> weak shape handleの確保でminor GCが起こり得る -> 返値をVMの宛先レジスタに格納する inline cacheは、次に同じようなプロパティアクセスを行うとき、前回分かったshapeやslotを利用して探索を省くための仕組みだ。cacheそのものの更新が、getterの返値を消したいわけではない。ただ、その更新には割り当てがあり、GCが起こり得る。getterの結果を受け取ってからVMレジスタへ渡すまでに、処理がもう一つ挟まっていた。 getterが返した新しいオブジェクトが、ほかのJSオブジェクトから参照されていない場合を考える。Rustのresultというローカル変数にはJsValueがある。しかしBoaのGCは、そこに値があるというだけで外部rootとして扱わない。VMレジスタに入ればGCがたどれるが、cache更新中はまだそこにいない。cache更新がminor GCを起こすと、返値がfinalizeされてメモリから解放され得る。その後、VMは解放済みオブジェクトを指すedgeをレジスタへ書いてしまう。 getterが返した新しいProxy | v Rustのresultだけが参照する | +---- inline cache更新中にminor GC ----> Proxyを回収 | v VMレジスタへ解放済みのedgeを書き込む | v 後のアクセスでinvalid read / SIGSEGV この図で起きているのは、cacheにProxyを入れたという話ではない。cache更新時の別の割り当てがGCを呼び出し、その時点でrootされていない返値が巻き込まれた、という順番だ。Valgrindが示した解放と最初の不正な読み出しは、この説明と一致した。GetNameGlobalにも、グローバル名のgetterから返値を得てcacheを更新してからレジスタに入れる、同じ空白があった。

2026/09/30 08:1213時間ぶり

OmoikaneのRealm生成が遅かったので、Boaのscope検索と字句解析を調べた

OmoikaneのCIの待ち時間を調べた記事では、文書だけの変更に重い検証を走らせないことや、ビルドキャッシュを見直した話を書いた。それとは別に、実行する必要のあるテストそのものにも時間がかかっていた。 OmoikaneはJavaScriptの実行にBoaを使っている。ページやiframeのためにJavaScriptのRealmを作るたび、DOM APIを用意する大きなスクリプトを実行する。その処理がテスト時間の相当部分を占めていた。Issue #1154では、テストの数やRealmの数を減らすのではなく、この初期化そのものを調べた。先に結果を書くと、macOSのtest profileでRealm生成時のbootstrap処理は約0.58秒から約0.13秒になった。ただし、これはrelease buildのページ表示時間を測った結果ではない。何を測り、どこを変えたらそうなったのかを順に残しておく。 Realmを作るたびに何が起きていたか RealmはJavaScriptの組み込みオブジェクトやグローバル環境を持つ実行単位で、Omoikaneではページやiframeごとに必要になる。Realm自体については以前の記事に書いた。新しいRealmを作ると、OmoikaneはDOMをJavaScriptから使えるようにするbootstrapを読み込む。dom_bootstrap.js、xpath.js、font_loading.js、find_in_page.jsを連結したソースは約1.1MBある。evaluate_dom_bootstrapはそのソースをmoduleとして解析し、load、link、evaluateまで進める。内部のhost bindingをページのglobalに露出させていないかも、この初期化時に確認している。 Realmを作る ↓ bindings.module_source() 約1ms ↓ Module::parse 約335ms ↓ module.load + link 約240ms ↓ module.evaluate 約10〜25ms これは変更前に一回だけ実行したときの、おおよその内訳である。全体で約0.58秒かかる。特にparseとload・linkが重かった。bootstrapソースは毎回ほぼ同じなのに、Realmごとに解析とコンパイルを繰り返している。一時的な計測コードを入れてlibのユニットテストを全件走らせると、1069件のテストからbootstrapが計1414回呼ばれていた。0.58秒を掛けると約820秒になる。libテストのCPU時間は約1160秒だったので、概算で7割ほどがこの初期化に対応する。一方、実時間は160〜222秒だった。テストが並列に走るため、CPU時間と時計で測った実時間は同じ値にはならない。実際、Realmを25個作るテストは単体で16.1秒、13個作るテストは7.8秒かかっていた。遅いテストを一つだけ削っても、根本の費用は残る。そこで「bootstrapを何度も処理しない」「処理するなら処理自体を速くする」の両方を検討した。最初の案は解析済みmoduleのキャッシュだった最初に立てた子Issue #1155は、解析済みのbootstrap moduleをプロセス内でキャッシュするというものだった。同じソースを何度もModule::parseへ渡すのだから、一回作ったASTを使い回せれば分かりやすい。ただ、Boaの解析結果をそのままスレッド間で共有できるわけではない。ASTのScopeはRcとRefCellを含み、ASTのシンボルはContextごとのInternerにも依存している。libtestはテストごとに別スレッドで動く。測定した1414回のうち、同じスレッドで二回目以降のRealmを作ったのは345回だけだった。残りの大半には、スレッド内だけのキャッシュを置いても効かない。「キャッシュすればよい」という方向で実装を進める前にプロファイルを取ると、別の問題が見えた。解析とコンパイルの上位に、JsStringの比較がいた。呼び出し元は、Boaのscope解析やbytecode生成で行うbindingの名前検索だった。大きなscopeを何度も線形探索していた JavaScriptの変数や関数の名前を解決するとき、パーサーとコンパイラはscopeのbindingを調べる。Boaでは、そのbindingを宣言順のVecに持ち、名前を探すたびに先頭から比較していた。小さな関数のscopeならこれで十分だが、DOM bootstrapのmoduleトップレベルには大量のbindingがある。名前の参照が増えるたびに、長いリストをまた走査する。binding数をB、参照数をRとすれば、この部分の仕事はおおむねR × Bに増える。約1.1MBのソースをRealmごとに処理すると、その費用を毎回払うことになる。 PR #1160では、宣言順のVecは残し、名前からその位置を引けるFxHashMapを追加した。ただし、すべてのscopeに最初からハッシュ表を持たせたわけではない。bindingが16件以下なら従来どおり線形探索し、17件目を追加したときに索引を作る。普通の小さなscopeで索引の確保費用が増えるのを避けるためだ。 bindingは追加されるだけで、削除や改名はしない。そのため索引に入れたVec上の位置は後から無効にならない。宣言順、binding index、外側のscopeからの参照、再宣言、escapeの扱いは変えない。しきい値の前後でこれらが変わらないこともテストした。結果は、単なるparseの短縮にとどまらなかった。名前検索はscope解析だけでなくbytecode生成でも使われるため、load・linkも大きく短くなった。処理・計測範囲変更前 scope索引化後 bootstrapのModule::parse 約335ms 約115ms bootstrapのload + link 約240ms 約25ms libユニットテストのCPU時間 1160秒 427秒 libユニットテストの実時間 160〜222秒 63秒これはmacOS 8コアのtest profileでの測定である。libテストの実時間に幅がある変更前の値を使っているため、単一条件の厳密な倍率として読まない方がよい。ただ、解析だけをキャッシュする案では残っていたはずのコンパイル側まで改善したのは大きい。

2026/09/29 18:258時間ぶり

読み込み中...

Goにおける明示的な純粋性制約の静的検査: mikotoの設計と検証

2026/09/30 22:3814時間ぶり