文章を書かないモデルJevの検証記事が国内3サービスの上位を占め、AnthropicはClaudeが自社の研究開発の26%を主導していると公表

閲覧したWebページと手元のファイルを自前でインデックス化し、あとから全文検索できるようにするOSSの検索エンジン。ブラウザ拡張からページを登録でき、HNでは少し前にも話題になっていた。

コメントでは、Google Chromeが2008年に閲覧ページのオフライン全文検索を目玉機能として搭載し、2013年ごろに削除したことを惜しむ声が上がっている。前回の投稿以降使い続けているという人は、全ページではなく拡張で指定したページだけを登録しており、インデックスが育つほど役立つと報告している。

ほかに、Histreから名称について書簡が届き改名が必要になったとDiscordで見たという情報、Linkwardenと連携してブックマークも検索対象にしたいという要望、最近はChatGPTに尋ねれば以前読んだ記事がかなりの確率で見つかるという声も出ている。

イタリアの非営利ホスティング集団A/I（Autistici/Inventati）が、取引銀行Banca Eticaに口座を閉じられ、サービス終了を告知した件。発表ページ自体には口座閉鎖の詳細が乏しく、別の告知やイタリア語の記事で経緯が補足されている。

コメントでは米国務省のプレスリリースが示され、口座閉鎖（デバンキング）の枠組みは9.11直後から存在し、2000年代半ばには無害なハワラ業者も巻き込まれたという背景説明が出ている。対象になった理由を、米国の現政権が敵視する国内の活動団体へのサービス提供に求める見方もある。

欧州の決済ネットワークで働く立場からは、USD建ての取引はすべて米国の枠組みを通るため、銀行も自発的にやっているわけではないという説明がある。EUが欧州の裁判所で有罪になっていない相手の口座閉鎖を禁じる法律を作った場合、次に何が起きるのかという問いも投げかけられている。

GNOME 51のリリース告知。新しいアプリとしてSQLiteデータベースを閲覧する「Bobby」が加わったほか、旧来のNVIDIAドライバインターフェースへの対応終了や、WEP無線セキュリティのサポート完全削除などが含まれる。

コメントでは、Bobbyという名前がSQLインジェクションを題材にしたxkcdの回にちなむ冗談だと気づいた反応があり、アプリページにもイースターエッグがあると補足されている。NVIDIAの件は、GTX 10xx世代が切り捨てられると受け取った書き込みに対し、ここでの「レガシー」はEGLStreams方式を指し、旧世代カードのドライバもGBMに対応済みだという訂正が入り、元の投稿者も納得している。

WEPに続いてWPA1も外してほしいという声や、以前バグトラッカーで要望していた可視署名のサポートが入ったことを喜ぶ書き込みも出ている。

ドメインハックとして.ruを使っていた個人サイトが、そのドメインを手放すことになった経緯を書いた記事。

コメントでは、他国のccTLDを取ればその国の裁量に従うしかないという指摘が出ている。かつてGoogleのマルウェア判定チームが、配下にマルウェアの多いサブドメインを抱える親ドメインをまとめて判定する仕組みを作ったところ、.ru全体をマルウェア扱いしかけたという昔話も紹介されている。

自分のサイトのURLを不安げに見るという反応が続き、Lobsters自身がセルビアのccTLDである.rsを使っていることから、予備のlobsters.devがあることや、セルビアのレジストリがドメインハックに友好的だという話題へ広がっている。.horseを長年使って満足しているという書き込みもある。

個人のブログ記事にDOIを割り当てる方法を紹介した記事。クールURIがあるのにDOIで何が変わるのか、という問いから議論が始まっている。

答えとして挙がっているのは、曖昧さの解消における主キーであることを意思表示する意味があり、TLDが一貫性を保つと信頼できない世界ではとくにそうだ、という点。著者本人も応じており、自分のURLがずっと使えることを願ってはいるが、いつかドメインの更新を忘れる、データを失う、.mobiが新所有者に値上げされるといったことが起こり得るため、信頼できる第三者がdoi.orgのIDを新サイトへリダイレクトしてくれる可能性に価値がある、と説明している。

実際の利用場面として、Wikipediaの記事に出典を追加するときにDOIを好むという書き込みがある。プレプリント、著者サイトのPDF、ジャーナル版のどれを指すべきか判断せずに済み、正規の掲載先へ案内される点が理由に挙がっている。自分のブログ記事が論文に引用されたときDOIがあればよかった、という声も出ている。

画像の来歴を証明する規格C2PAについて、Pixel 10上で署名を偽造できることを示した検証記事。端末側で署名する方式の前提が崩れる点が論点になっている。

コメントでは、AI生成でないことを証明するために署名が必要になるという発想そのものへの抵抗感が示される一方、C2PAの出発点はAIではなく、報道機関が扱う画像が加工されていないことを確認する統一手段だったという補足が入っている。

技術面では、イメージセンサが生画像をCPUへ渡す前に署名しない限り、root権限を持つ者による署名は防げないという指摘がある。AppleのReference Imageとの違いを問う声や、これを機にPlay Integrityのような端末認証が強まりGrapheneOSのような環境が不利になる懸念、企業が気に入らない画像への署名を拒む可能性を問題視する意見も出ている。

OpenAIのAIがナビエ–ストークス方程式の問題を解いたと報じられた後でも、LLMに弱気な見方を保つ理由を論じた記事。厳密な仕様を書く労力は、非形式的な仕様をそのまま実装する労力を大きく上回り得る、ハードウェア設計の世界がその好例だ、という一節がコメントで引用されている。

コメントでは、この論点が自分の経験に合うという声に続き、COBOL、AppleScript、Informなど「英語のような言語で誰でもプログラムが書ける」とうたった過去の試みが並べられている。SQLも元はビジネスパーソン向けに設計されたという指摘には、設計者自身の回想が引用される一方、金融の同僚は今もSQLを大量に書いており、最近はLLMに頼っているという反論も付いている。

UnicodeコンソーシアムがUnicode 18.0.0を公開した。r/programmingでは新しい絵文字の一覧が最初に共有されており、ひび割れた顔、左向き・右向きのサムズアップ、オオカバマダラ、ピクルス、灯台、流星、消しゴム、柄付きの網が挙がっている。

コメントでは、流星と灯台は技術系で人気になりそうだという予想に対し、以前からあったのではという反応が出ている。彗星は既存で、灯台は地図記号の ⛯（U+26EF）しかなかったという補足が付いている。

壁や柵の絵文字がまだないという不満には、レンガの絵文字で代用できるという返答があり、Android以外ではただのレンガにしか見えないという反論が続く。汎用的な名前だと表示がプラットフォームごとにずれるため、新しい絵文字ほど「横に振る頭」「縦に振る頭」のように説明的な名前が付けられている、という説明も出ている。

Cloudflareが公開した、コーディングエージェント向けのセキュリティ監査スキル。偵察、カバレッジ主導の探索、候補の検証、構造化出力、独立した記録検証、ターゲット中立な報告という一連の流れを、分離されたエージェントに実行させる。同社のブログ「Build your own vulnerability harness」で紹介された脆弱性発見ハーネスの出発点にあたる単一リポジトリ版である。

6フェーズの内訳は、まずアーキテクチャ、信頼境界、入力面、既存の証跡、決定的なカバレッジを `architecture.md` と `coverage-ledger.json` に整理する偵察。次に台帳の単位から分離されたハンターを割り当ててチェックを記録し、カバレッジ批評役に漏れを探させる。

続いて、重複を除いた候補ごとに新しい検証役を立て、それを反証しようと試みる。結果は `confirmed` / `needs_validation` / `rejected` として `findings.json` に書き出し、`report-schema.json` で検証する。最後に新しいエージェントが最終的なソース上の主張を独立に検証し、実質的な差し替えが起きた場合はさらに別の検証役を通す構成になっている。

Alibaba Groupの社内公式AIコードレビューアシスタントとして2年間で数万人の開発者に使われ、数百万件の欠陥を検出した実績を経てOSS化されたCLIツール。モデルのエンドポイントを設定するだけで動き始める。

動作は、Gitのdiffを読み、ツール利用が可能なエージェント経由で変更ファイルをLLMへ送り、行単位の構造化されたレビューコメントを生成するというもの。エージェントはファイル全体の読み取り、コードベースの検索、他の変更ファイルの参照ができるため、差分表面だけでない深いレビューを出せるとしている。`ocr scan` はdiffのないディレクトリや未知のコードベースの監査向けに、ファイル全体をレビューする。

ベンチマークとして示されているのは、Claude Codeのような汎用エージェントとの比較。同じモデルを使った場合にPrecisionとF1が明確に高く、消費トークンは約1/9でレビューも速い。一方でRecallは汎用エージェントより低く、これは意図的なトレードオフだと明記されている。

エージェントハーネスの性能最適化システムとして、スキル、instincts、記憶、セキュリティ、調査優先の開発を提供する。Claude Code、Codex、Opencode、Cursorなど7つのハーネスへ週次で出荷していると説明されている。

READMEの冒頭には警告が置かれており、インストールは公式チャネルに限るよう求めている。GitHubリポジトリ、npmパッケージの `ecc-universal` と `ecc-agentshield`、GitHub App、プラグインスラッグ `ecc@ecc`、プロジェクトサイトecc.toolsが正規で、第三者による再アップロードや非公式ミラーは保守も審査もされておらずマルウェアを含む可能性がある、としている。

Claude Codeへの導入は、ガイド付きセットアップかネイティブのプラグインコマンドのどちらかで、いずれも同じ `ecc@ecc` プラグインを入れる。両方を重ねて入れないよう注意書きがある。ライセンスはMITで、OSS部分は無料のまま、私有リポジトリ向けのホスト型GitHub AppであるECC Proとスポンサーが開発を支えるモデルを取っている。

企業向けの文書理解、意味検索、自律推論を想定したLLMベースのOSS知識フレームワーク。日常的な参照用のRAG即答、検索やMCPツール、テナント単位のスキルカタログ、セッション永続のDocker / E2B / Cubeサンドボックス、Web検索を自律的に組み合わせて多段タスクを処理するReActエージェント、という2つの軸を持つ。

新たに加わったWikiモードでは、エージェントが生の文書を、相互リンクされ自動で維持されるMarkdownの知識ベースへ蒸留する。対話的なナレッジグラフを備え、手動編集、改訂履歴、ワンクリックのロールバックにも対応する。

セッションをまたいだ長期記憶により、利用者が誰で何を繰り返し尋ねているかを保持する。知識の整備面では、アップロードしたディレクトリ構造を保つツリー型のフォルダビューや、チャンク単位の操作が用意されている。

コーディングエージェントを研究エージェントとして使うためのローカルファーストなワークスペース。文献レビュー、仮説の構築、実験の実行、研究成果物の作成までを対象とする。macOS 11以降に対応し、WindowsはベータでGit for Windowsを必要とする。

導入はmacOSまたはLinuxでCLIをインストールし、`orx up` を実行するとローカルダッシュボードが `http://127.0.0.1:4791` で開く。LM Studio、oMLX、Ollama、独自エンドポイントをOpenCode経由で接続してローカルモデルを使うこともできる。

提供される機能として挙がっているのは、研究の方向ごとに独立したエージェントセッションと分離されたgit worktreeを与える並列探索、gitネイティブな実験ツリーでバリアントを追跡し各実行に記録したコミットの不変アーカイブを残す再現性、ログ・差分・ファイル・結果・成果物を生成元の作業に紐づけて保持する証跡管理、セッション単位でハーネスとモデルを選べる点である。

米国国家安全保障局の研究部門が作成・維持しているソフトウェアリバースエンジニアリング（SRE）フレームワーク。Windows、macOS、Linuxを含む複数プラットフォームのコンパイル済みコードを解析するための高機能なツール群を含む。

機能には逆アセンブル、アセンブル、逆コンパイル、グラフ表示、スクリプティングのほか数百の項目があり、幅広いプロセッサ命令セットと実行形式に対応する。対話的な利用と自動実行の両方が可能で、利用者はJavaまたはPythonで独自の拡張コンポーネントやスクリプトを開発できる。

開発の背景として、複雑なSRE作業におけるスケールとチーム連携の課題を解くため、またカスタマイズ可能で拡張性のあるSRE研究基盤を提供するために作られたと説明されている。NSAはこの機能を悪意あるコードの解析や、ネットワークとシステムの潜在的脆弱性の把握に適用してきたとしている。

コンシューマ向けやヘテロジニアスな環境で、744Bから2.8Tパラメータのフロンティア級MoEモデルを動かすことを狙った推論エンジン。エンジン側の依存をゼロにした純Cで書かれ、ストレージ・RAM・VRAMをひと続きのメモリ階層（AIメモリ多段化）として扱う。

現在動作する系列として、GLM-5.2/5.3（744B）、GLM-5.3-Flash（321B、ビジョン対応）、Inkling（975B）、Kimi K3（2.8T）、DeepSeek V4 Flash（284B）、DeepSeek V4.1 Flash（552B、ビジョン対応）、Qwen3.8-Flash-Next（125B + 51B n-gram）、Qwen3.6（35B-A3B）、OLMoE（7B）の9ファミリーが挙げられている。いずれもモデルごとに1つのCファイルで、`coli chat` / `coli serve` / `coli web` という共通のフロントエンドを持つ。

プロジェクトは実用エンジンであると同時にオープンな研究基盤という位置づけで、モデル形式、メモリ階層、ストレージI/O、配置、スケジューリング、カーネル、投機実行、CPU/GPUのオーバーラップまで含めて推論性能を追う。速度についてのSLAはなく、意味論の保証は厳格、実験は再現可能なエンドツーエンド計測で価値を示す、という方針を掲げている。

1つのホットキーで日常的に使うものへ到達できる、メモリ100MB未満のmacOSネイティブランチャー。SwiftUIとAppKitで書かれ、サードパーティ依存はゼロ、Electronもテレメトリも使わない。実際のRaycast拡張機能をネイティブのSwiftUIとして描画して実行できる点を特徴に挙げている。無料かつオープンソースで、今後もそのままだとしている。

機能はアプリランチャー（あいまい検索での起動、お気に入りのピン留め、起動中アプリの確認、個別または一括の終了）、どこからでも呼び出せるグローバルホットキー、アプリごとにキーを割り当ててフォーカスと非表示を切り替えるアプリ別ホットキー。

ファイル検索は独自インデックスを持たず、指定したフォルダをSpotlight経由で検索する。ほかにテキストと画像を対象とする検索可能なクリップボード履歴（元のアプリへ貼り戻せる）、計算・単位・為替の変換をパレット内で行う電卓、URLや検索、ファイル、ディープリンクをコマンド化し入力・クリップボード・日付をプレースホルダとして使えるQuicklinksを備える。

シニアエンジニアが使うワークフロー、品質ゲート、ベストプラクティスをスキルとして符号化し、AIエージェントが開発の各フェーズで一貫して従えるようパッケージしたもの。DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP という流れに沿って構成されている。

用意されているのは開発ライフサイクルに対応する9つのスラッシュコマンドで、各コマンドが適切なスキルを自動的に有効化する。`/spec`（コードの前に仕様）、`/plan`（小さく原子的なタスク）、`/build`（一度に1スライス）、`/test`（テストは証明）、`/constraints`（一度決めてどこでも強制）、`/review`（マージ前にコードの健全性を上げる）が挙げられている。

このほか `/webperf`（最適化の前に計測するWebパフォーマンス監査）、`/code-simplify`（賢さより明快さ）、`/ship` が並ぶ。各コマンドに「何をしているとき」「どのコマンド」「鍵となる原則」を対応づけた表が示されている。

Claude Fable 5.1とGPT 6 Astraを組み合わせてバイブコーディングしたmacOSアプリで、吹き出し・設定画面・詳細画面・アバターが同時に表示されるようになったところ、キーの連打で画面が反応しなくなる、取り消しキーを押さないと戻らない、出るべき画面が出ないといった不具合が続いた。AIに修正を頼んでも直らなかったという。

原因は、各画面が自分で表示・非表示を決め、さらに隣の画面を直接操作していたこと。会話画面が吹き出しを隠したり、設定画面がアバターの表示を変えたりして処理が衝突し、排他制御や待ち時間、リトライを場当たり的に継ぎ足した結果、1つ直すと別の場所が壊れる状態になった。

対策として記事が提示するのは、全コンポーネントをRootの配下に置き、各コンポーネントはMVPのPassive Viewとして描画パラメータだけを扱い、動作はChain of Responsibilityでイベントをバブリングさせ、ステートマシンとして振る舞うMediatorに裁定させる、という指示をそのままAIに渡すプロンプト。

2026年9月にShopify Engineeringが「Native is now the future of mobile at Shopify」を公開した。2020年にReact Nativeへ寄せ、コミュニティへ投資してきた企業の方針転換として受け止められ、クロスプラットフォームには無理があったという反応も出た。

筆者は、Shopify自身は「React Nativeは失敗だった」とは書いていない点を確認する。2020年当時の課題はiOSとAndroidで同じ機能を二度実装して同期させ続けることで、React Nativeはその重複を減らし、Web中心の開発者がモバイルへ参加しやすくなる効果があった。追従コスト、ネイティブ層との境界、外部ライブラリ依存、パフォーマンスといったコストは当時からあり、それでも天秤が釣り合っていた。

2026年に天秤が動いた理由として挙がるのが、ShopifyがCoding Agentを開発プロセスへ深く組み込み、片方の実装を参考にもう片方を実装させ、テストとレビューで挙動を揃える仕組みを整えたこと。ネイティブ2本のコストがゼロになったわけではないが2020年ほど高くなくなった、という構図で整理されている。

3エージェント併用で開発している17万行規模のプロダクトでは、生成されたコードを人間が全部レビューすることは実質不可能で、レビューもトークンを消費する。そこで12GBのGeForce 3060で動く用途を絞ったローカルLLMを試し、Ollamaでqwen2.5-coder:14bを使った。

Issue単位でブランチを切り、規模が大きければスライスに分けて小さく実装を回す進め方を前提に、gitのステージに上がった差分から重大な問題だけを挙げさせる構成を取っている。Modelfileでtemperature 0.05、top_p 0.8、num_ctx 8192を指定し、自分用モデルを生成する。

システムプロンプトでは要約・説明・挨拶・総評の類を禁止し、検出対象をデータ損失リスク、クラッシュリスク、セキュリティ境界の破壊、path traversal、Electron IPC境界の破壊、async / race condition、null・undefined・空状態、off-by-one、ファイルパスやURLエンコード、Unicode処理の重大な不整合に限定している。

毎回同じ流れ（Issueを取る → AIに設計と実装を任せる → 別のAIにレビューさせる → 動作確認 → PR作成）で開発しているのに、その都度指示を出していたため、一連の手順をスキルへまとめた記録。前提としてGitHubでのIssue管理を使うが、AIとやり取りできればNotionでもTrelloでもよいとしている。

役割分担は、Claude Codeが設計・実装と外部（GitHub・Codex・人間）とのやり取りを担当し、Codexはレビューのみ。先入観なくレビューさせる点に注意を払い、人間のレビューにはcritを使うクロスレビュー構成になっている。サブエージェントへの切り出しは、使いこなせていないという理由で採用していない。

スキルは特定リポジトリに閉じないよう `~/.claude/skills/` へ置き、どのリポジトリからも呼べるようにしている。名前は `todays-work` で、descriptionには `/todays-work` で明示的に呼ばれたときだけ使う旨を書いている。

拡張の対象は、Lambda Managed Instances (LMI) 上で動く関数であること、かつ非同期呼び出しまたはESM（イベントソースマッピング）経由の呼び出しであること、という2条件を両方満たす場合に限られる。同期呼び出し（RequestResponse）は従来どおり15分のままで、API Gatewayや関数URLの背後にある関数はTimeoutに5400を設定しても15分でタイムアウトする。

変更点は表で整理されている。非同期呼び出しとSQS / Kinesis / DynamoDB StreamsのESMが15分から90分（LMIのみ）になり、Amazon MQ / DocumentDBのESMとInitフェーズは15分のまま。設定は従来のTimeoutプロパティのままで、上限が900秒から5,400秒に上がっただけとされている。

筆者はCDKで検証環境を組み、S3にファイルが置かれたら重い変換処理を回すという王道パターンが、15分の壁を気にせず1関数で組めることを実測で確認している。durable functionsと組み合わせた場合に何が変わるかも検証対象に含めている。

筆者は数学者ではなく、システム開発目的で毎月数十万円分のトークンを使う立場で、AI自体には肯定的だと前置きしている。そのうえで、数学者の都合という見方を避けるため、数学理論の発展という軸で議論を立てている。

数学の理論は天才がゼロから作ったものではなく、問題を解き洞察を重ねて何世代も積み上げたものだという整理から始まる。定義の言葉遣いや、どの定理から何を証明するかといった選択には文学的な構築の側面がある一方、内省だけでは許されず、誰が考えてもその順序なら確かにそうなる、という論理的な正しさを前提にする点が文学とは異なるとする。

数学理論の結果を使うには最終的に何らかの計算をすればよく、AIは計算能力の面で人間業では不可能な領域へ届き得る。ただし計算力のない人間は、問題を観察して見方を変え、新しい理論を作って解いてきた。その理論が計算をスマートにし、統一的な説明を与え、新しい対象を生む。今のAIは理論を作る部分に届いていない、という論の運びになっている。

ソニックムーブのフロントエンドエンジニアによる記事。E2Eテストは運用を続けるほどテストケースの作成・実装・修正の工数が膨らみ、AIで開発が速くなった今は大きなボトルネックになると筆者は見ており、ノーコードでAIが自律的にテストを実行する仕組みを試している。

テストケースの記述にはBDDで使われるgherkin記法を採用した。YAMLやMarkdownも検討したが、Given / When / Thenという自然言語ベースの構造がそのままAI向けプロンプトに流用しやすく、エンジニア以外も読めてテスト観点のレビューがしやすいことが決め手になった。記法には厳密に従わず、プロンプトとして緩く借用している。

サンプルでは、TODOアプリを対象にFeatureの下へビューポート指定やログイン情報、Backgroundでの前提データ作成を置き、ログイン、ワークスペース一覧の閲覧、名前での検索、新規作成といったシナリオを日本語のステップで書いている。記事はこの仕組みに加え、バグを仕込んだ検証まで扱うとしている。

筆者は週1回チームメンバー全員と1on1をしていたが、質問は毎回「最近どう?」「困ってることある?」だけだった。一番期待していたメンバーから退職の相談を受け、抽象的な質問では当たり障りのない返事しか返らず、限界に近づいていたシグナルを拾えなかったと振り返る。『How Google Works』の、抽象的な感情の質問は抽象的な答えしか生まないという一節を引いている。

立て直した質問は3層構造。まず「今週一番時間を溶かした作業は何か」のように観察可能な事実を聞き、次にその事実に紐づけて「進めていたときどんな気持ちだったか」と感情を聞く。感情を単独で聞くと抽象化されるため順番が重要だとし、『HIGH OUTPUT MANAGEMENT』が1on1の目的を情報交換と定義している点も挙げる。

最後に「3か月後どんな仕事をしていたいか」「このチームに1年後もいると想像してしっくりくるか」と将来を聞く。退職を相談してきたメンバーからは、1年後もいると思うかと聞かれていれば正直に話せていたと言われたという。

筆者は、AIによってエンジニアのスキルが均一化し、1年目のコード、AIで作ったコード、ベテランのコードの差がほとんどなくなると見ている。そのため採用の最終判断ではスキルをほとんど見ず、3つの点だけを見ているという。

1つ目は人間力で、「一緒に働きたい」と思えるか。産業革命が人間をパワーから解放したように、AI革命はスキルから解放するとし、シュートが100%入るロボットがいるバスケで最後に残るのはリバウンドを取りに行く姿勢やチームを鼓舞する力だと喩える。態度やマナーの悪さ、「この会社は自分に何をしてくれるのか」というスタンスはその場で不採用にするとしている。

2つ目は当事者意識で、会社を一緒に作ろうとしてくれるか。3つ目は実直さ・素直さで、成長に最も大事な要素として、先輩の指摘を素直に受け止めてコツコツ取り組めるかを挙げる。同社のエンジニアの95%以上は未経験からの採用だと記している。

筆者の社内システムでは、暗号化・ハッシュ、アーカイブ生成、QRコード処理、画像メタデータ除去をブラウザ側で行っている。元のJS実装は数GBから100GB規模のデータでブラウザのメモリ制限を超えてタブがクラッシュし、GCやJITのオーバーヘッドでUIが固まる問題を抱えていた。

標準GoでWasm化すると4モジュール合計で約9.1MBになりPWAの初回ロードには重く、TinyGoも言語仕様の制約や大容量ストリーミング時のGCの挙動に懸念が残った。そこで数KB級の軽さをうたう新言語Hikeを試した。Wasm未対応ブラウザや不具合時には wasm_loader.js で従来のJS実装へ自動で切り替える仕組みを用意している。

HikeはGoに近い構文で移植しやすく、hikecに -g を渡すとDWARF情報が出力され、VS CodeからGDBやLLDBでソースレベルのデバッグができる。4モジュールを元のJS、標準Go Wasm、Hike Wasmの3世代で比較し、バイナリサイズ99.8%以上の削減を報告している。

仕事・家事・育児で自由時間が少ないなか、残った時間までスマホで溶かしていたと筆者は振り返る。問題はスマホを触る数分そのものより、その割り込みで集中に必要なまとまった時間の連続性が失われることだとし、見ないと決意する方法は再現性が低いため、意志ではなく仕組みで制約をかける方針を取った。

要件は、特定のアプリだけを平日9:00〜17:59に利用可能とし、それ以外の時間帯と土日祝日は使えなくすること。他のアプリには影響させず、通知は確認でき、必要なら制限を解除できることも条件にしている。

スクリーンタイムでも曜日ごとの制限や休止時間は設定できるが、祝日を平日から除外する条件まではそのまま表現できなかった。ChatGPTに相談した結果、ショートカットの「オートメーション」を使う方法にたどり着いたとしている。

UUIDは、どこで生成しても事実上重複しないとみなせる128ビットの識別子で、RFC 4122（2024年にRFC 9562へ更新）で標準化されている。GUIDはMicrosoftの呼称で実質的に同じもの。文字列では8-4-4-4-12桁のハイフン区切りで表し、3番目のグループの先頭1桁にバージョン、4番目のグループの先頭ビットにバリアントが入る。

v4では128ビットのうち6ビットがバージョンとバリアントに使われ、ランダムな部分は122ビットになる。特定の1つのUUIDと偶然一致する確率は約5.3×10³⁶分の1で、絶対に重複しないのではなく、確率が天文学的に低いので重複しないとみなせるという統計的な保証だと説明している。

v1はタイムスタンプとMACアドレスから生成するため順序がある程度わかる一方、MACアドレスから生成元のマシンが特定される懸念があり、現在はあまり使われないとしている。記事は、理由がなければv4、データベースの主キーに使うなら順序性のあるv7を検討するという結論を冒頭に置いている。