Web Browser Engineering

Chrome の中の人が書いたブラウザの本。Python でブラウザを作っていく構成で 500 ページくらいに短く収まっている。

短いので、CSS のレイアウトという自分がブラウザのメインだと思っていたことは全然やらない。一方で CSS をパースして簡単な selector をあててフォントの色や大きさを変えたりはする。あとレンダリングだけでなくタブもスクロールバーも実装する。HTTP も requests でさっと済ましたりはせず、自分で実装している (HTTP/1.1)。JS 自体はさすがに実装しないが、Python につなぎやすい JS 処理系を持ってきてくっつける。

Python なので性能もクソもないな・・・とおもいきや、なぜかレンダリングを別スレッドに押し出てみたり、途中まで TK で進んでいたレンダリングを途中で GPU 使うぞ！とかいって SDL+Skia (python binding) に置き換えレイヤでスクロールを高速化してみたり、性能分析のために Systrace / Perfetto 互換の JSON を生成してみたり、話題の選び方が興味深い。60fps は大変だから 30fps で許して、とかいってて笑ってしまった。

世の中の人が「ブラウザ」と聞いて想像する話題ではなく、ブラウザの中の人が関心を寄せている部分に重きを置くという意図なのだろう。細部よりアーキテクチャを伝えようとしている。コードも、機能の割にはちょっとばかりオーバーエンジニアリングに感じる瞬間がある。たとえばかなり序盤から dispaly list というものを導入しており、なんて？という感じはする。後半にその伏線が回収される。

意図は伝わってきたし、この著者でないと書けない内容だろうなとも思った。面白い本です。あと細々読まなくても Python のコードをパラパラ眺めるだけでけっこう雰囲気がわかり、それもいい。Python は偉大。

実際に動くコードを書きながら章が進んでいく構成はある意味で Physically Based Rendering: From Theory to Implementation を連想される。が、出来上がるものはだいぶちがう。PBRT はわりかし完結した C++ のレンダラが完成し、実際このコードから派生したレンダラというのも世の中にはあるらしい。一方 WBE のウェブブラウザは、ここから派生したウェブブラウザ・・・ができないのは仕方ないとしても、自己完結感は薄い。Python で色々なライブラリを寄せ集めている。

まあ Chrome だと JS(V8) も HTTP(quiche) も描画(Skia) も結局自分で全部持っているので「寄せ集め」よわばりはフェアでないかもしれないけれど、ブラウザというのはなにか一つの完結したテクノロジではなくて、グラフィクスからネットワークから言語処理系からデータベースまで、色々なテクノロジをつなぎ合わせ得て coherent な何かを提供するプラットフォームなのだよね。

そんななかウェブ固有の技術というのは何だろう。というと結局 HTTP と CSS と HTML (JS を数えてもいいかもしれない？でもウェブというより言語処理系だよな) だと思うけれど、世の中 HTTP (少なくとも pre-2.0) は比較的よく理解されており、HTML は単体では何も面白くない。CSS のレンダリングモデルやレイアウトアルゴリズムの教科書があればいいのになー。標準読めという話なのかもしれない。

そういえばウェブ標準・インターネット標準という莫大な「仕様」が存在するのもレイトレーシングとは趣が違うところかもね。レイトレもシーンデータとかあるけど、そのファイルフォーマット仕様を読んでレイトレの理解が進むとは思えないからね。

こないだ Per-Bug Pages を書いたら Nagae 氏から反応があり, 我々メモ取り世代だなと思う。いや、べつにどの世代の皆さんも note taking してると思うんですけど、世代ごとに特徴あると思うんだよね。なんとなく。

そういえば以前 Blogging Platform 遍歴四半世紀 を書いたと思い出し、これのメモ版も書いてみる。自分はさほど熱心な note taker ではないので参考にはならない。でも他人がこの手の話題で時間を無駄にしているの見る楽しさってあるじゃない？こないだ NYT の Hard Fork podcast でも、ホストが「俺は生産性ツールで時間を無駄にしすぎているので、今年はツールを乗り換えず Capacities でがんばってみようと思う」と一年の抱負を述べており苦笑いしてしまった。

howm: Hitori Otegaru Wiki Modoki (2003 - 2013)

というわけで 15-25 年前は Emacs で動く howm というのを使っていました。Emacs ならなぜ org-mdoe じゃないんだと思うかもしれないけれど howm の方が古いんだよ…まあ org-mode のことは知りませんでしたね当時。たぶん。howm も当時同僚（先輩）だった karino2 に教わったんだと思う。

黒歴史アーカイブを確認したところ 2003 年から 2013 年くらいまで howm を使っている。長い。

HOWM は、自分の不確かな記憶が確かなら ChangeLog メモ という Emacs の ChangeLog mode でメモをとるライフハックから派生したと理解している。そういえば自分も HOWM の前に一時期 ChangeLog メモしていた気がする。だた早々と howm に乗り換えた。

黒歴史アーカイブでは Emacs 内でメモを取る試みとして Muse を 2008-2010 あたりにつかっていた形跡もあった。たぶん HOWM ちょっとダサい、飽きた、ゴミに汚染されがち、みたいな気分があったのだろう。

Evernote (2013 - 2015)

なんらかのきっかけで howm をやめ Evernote に以降した。さすがに Emacs はナシかな・・・という思いがあったのかもしれない。

HOWM の頃のメモはほとんどが時系列の作業メモ、あとはブログの草稿くらいだったが Evernote ではもっと色々書いていた。（逆に作業メモには HOWM も併用していたかもしれない。）

Evernote はネイティブアプリの出来が良かった。しかしあるとき Macbook を破損し Linux laptop に宗旨変えした結果アプリがなくなり、Web 版はイマイチなため段々と使わなくなった。ちょうどこの頃 Evernote は Web アプリを刷新し、シュッとした見た目と引き換えにめちゃ使いにくくなったのだった。

Google Docs (2015 - 2025)

仕事のメモは 2015 くらいから Google Docs で取るようになった: Work Log on Google Docs

オープンソースな Chrome のしごとからプロプリエタリな Android アプリの仕事に鞍替えした結果として社内の資料やコードを参照するようになり、サードパーティのサービスにデータを預けられなくなったのが一番の動機だった。

全く好きではないが、選択肢がなかった。ファイルを開いたり作ったりは激烈に遅いが、編集はわりかし軽快。あと決してコンフリクトしないのは強み。

ファイルをわける、単一の巨大な docs にダラダラ書いていく方式は冒頭の ChangeLog memo 影響された、のかもしれない。

WordPress (2016 - 2021)

Evernote から足を洗ったのち、しばらく私用のメモ行き先がなかった。一方でブログは WordPress(.com) でそこそこ書いていた。ブログがメモの役割を果たしていた面はある。

ブログに公開した記事だけでなく、 公開ブログののドラフトを使ったり非公開のブログをたてたりしてメモ・日記のかわりにしていた。

WordPress はダッシュボードは遅いけれどブログだけあって閲覧のしやすさは突出しており、気に入っていた。しかしあるとき導入された Gutenbergというエディタが壊滅的に使いにくく、脱落した。

(ブログは一時的に Hugo に移動したのち、多少編集がダルくてもホストされてる方がラクだなと WP.com に戻ったが、去年のオープンソース騒動のきな臭さに嫌気がさし再び Hugo に戻った。)

Notion (2022 - 2024)

WordPress からの脱落にあわせ、ブログは Hugo+VS Code, 私用のノートは Notion に避難した。Notion は WordPress のような閲覧のしやすさはなかったが、新しいページを作るのはだいぶ速く、それはよかった。ウェブ中心のデザインは、ブログでメモをとっていた Linux ユーザの自分にとっては馴染みがよかった。

ただ機能が多すぎ、やりたいことを実現するのにどの機能を使えばいいのかなどの戸惑いはなくならなかった。適応できたとはいえない。

Obsidian (2025 -)

登場当初から気になってはいたが、仕事のラップトップが Linux どころか Chromebook であるという事実が邪魔していた。

あるとき調べると Chromebook 上の Linux VM (Crostini) で使えること、そして Crostini の社内データアクセスが改善されていることがわかった。そこで重い腰をあげ乗り換えてみた。

今のところ気に入って使っている。Notion や Google Docs とちがい、Obsidian のことは好きだと言っていい。コアの機能はシンプルだし、速いし、使っていて満足感がある。Obsidian を使ったあと、Notion のもっさりした感じは微妙にストレスだったと気づいた。Linux 版のアプリがあるのも素晴らしい。

なお Crostini 上では日本語が入力できない (Ubuntu では問題なし)。仕事は別に日本語なくてもいいんだけど私用はブログも書けないし困るので Crostini のかわりに ARC (Android Runtime for ChromeOS) で Android アプリを併用している。ぶっちゃけ Crostini 版より安定して動く気がする。ただし少し機能が削られている。

DayOne (2015, 2024 -)

十年前 Evernote を使っていた頃、同時に DayOne も使っていた。メモというより日記アプリ。これも Linux への移行にともない使わなくなっていたが、WordPress からの脱落にあわせまた使い始めた。Automattic 製品である WordPress から逃げ出して別の Automattic 製品を使っているのは皮肉。

作業ログや保存しておきたい記録を書くのは Notion/Obsidian を使い、DayOne は心の声を吐き出す場所になっている。

次点

試しはしたものの長続きしなかったものたち:

• (Puki)wiki: 働き始めての数年は Wiki の全盛期…は過ぎていたかもしれないけれど、まだまだ人気があった。入社した会社に Wiki がないときは、なんらかのサーバに Pukiwiki をインストールして使うムーブを二回ぐらいやった気がする。仕事メモにはよかった。その後 Redmine や Trac などの BTS に Wiki が付属するようになり、それらが用意されている会社では Wiki に仕事メモを書いていた。
• 自作 Wiki 一時期自作の Wiki でメモをとろうとしていたことがあった。しかしウェブプログラミング力が皆無だったため出来が悪く、半年くらいで捨てた。
• Confluence Cloud - 数年前、人間には Wiki がいるんだよ！と使ってみた。あまりに遅すぎて数ヶ月で挫折。Free tier だから不当に遅かった可能性はある。
• Foam, VSCode Journal - Emacs でメモをとるノリで VS Code を使えないかと試したが、しっくりこなかった。VS Code はそういうものじゃないんだろうな。

A quote from Ben Werdmuller

a real split in the tech industry (and everywhere code is written) between people who are outcome-driven and are excited to get to the part where they can test their work with users faster, and people who are process-driven and get their meaning from the engineering itself and are upset about having that taken away.

休み明けの朝、またバグを直している。

去年後半は、ひたすら同じ類のバグを押し付けられ、しかもそれはなぜかいつも締め切り直前で、仕方なく理想を捨てブランチにあてやすい秘孔パッチを書くことを強いられ続けた。苦痛だった。

新年からまた似たようなバグがやってきてトラウマが蘇りかかったが、今はまだリリースブランチが遠いのを思い出し真面目に直そうと考える。レガシーコードの構造の歪みを嗅ぎ分け、それがすこし良くなるようにリファクタリングして、それをすこし拡張して、いい感じのコードに直す。テストも書く。

こういう仕事は満足感がある。すっかり忘れていた、やんわりとした幸福を感じる。バグを直すのは嫌いでない。でもバグを直す以外の仕事もしないといけなくて、というか「以外」がメインという建前になっていて、時間のなさに胃を痛めて、押し付けられたバグを本来の持ち主に渡したのに言い訳つきで押し返されるのにうんざりして、バグなんてエーアイに調べさせ直させればいいみたいな空気に息が詰まり、そのうち何も楽しくなくなってしまう。

自分はいわゆる「成果」を「ユーザに届ける」ことにあまり興味がない。昔からなく今もない。成果をユーザに届けないと金にならないので気にはしているが、内的な動機づけにはなってない。いい感じのコードをかける方がよほど満足がある。

むかしある時までリファクタリングばかりしていた時期があり、けれどあるとき「本当にリファクタリング『しか』しない人」の存在を目撃し、これは個人にとってもチームによっても良くないと考えを改め、コードの綺麗さの追求を過大評価しがちなインフラ・ライブラリ・フレームワークなどの仕事を避けるようになった。「ユーザの価値」を自分に突きつけた方がいいと、アプリのしごとをするようになった。それでも結局あまり興味は湧かなくて、性能の仕事ばかりするようになった。まあ速いというのは程度の差はあれ価値じゃないですか。

性能の仕事がコードをいい感じにすることは少ない。（たまにある。でもそれは「たまに」なので話題になるんだよ。）悪くする程度を最小化することはできるが、良いコードだと思える瞬間は稀で、そもそもアプリのコード以前に telemetry のデータ相手に SQL を書いてる時間が一番多いような有り様。データ分析とか SQL にも面白さはあるけれど、いいかんじのコードとか、あんまりないんだよね。SQL のせいではなく、仕事が探索的なのでコードを積み重る機会が少ない。

結果として、チーム内のテニュアのせいで回ってくる本業とは関係なく成果に数えられることもないレガシーコードのバグ修正に、リリース三日前の火消しでなければ、一番満足を感じる。あるいは出世と同時に他所の部署にいってしまった誰かが捨ていったゴミコードの保守を押し付けられる理不尽の中に、リファクタリングの愉悦を見出す。

上司の視線が冷たい、給料はあがらない。

それでも、バグを直しながらコードを綺麗にしていく仕事だけやらせてくれないかなと思う。高速化が頭打ちになったコードの最後の一滴を搾り取るために壊れやすいショートカットを足して再現不能エッジケースバグを埋め込むとか、そういうのもう疲れた。やりたくない。チームをまたいて解決策が曖昧な性能問題の解決のため提案調整尻叩きとか、そういうのもやりたくない。叩かれるのも嫌。やらないと給料上がらないのわかってるけど、もういいです。ダメですかね。

自分は outcome に興味がなく process を楽しむ人間で、これはエーアイ以前から仕事に向かない性格だった。エーアイは単にそれを加速し、ごまかしや曖昧さを消し去っただけ。

そんなエーアイの書いたイマイチなコードをチマチマ直して綺麗にする仕事はあり得るだろうか。今はあることになっているが、コードの生産量を考えると持続性は無さそうに思える。残るのは、それこそリリース前に秘孔をつくバグ修正を繰り返すような火消し仕事ではないのかな。でも火消しばっかりやってると肺がんになっちゃうぜ。

澄んだ空気の静かな朝に綺麗なコードを書くだけの仕事がしたい。それは仕事ではなさそうだけれど。

slog | RandomThoughts

karino2 が作業ログの取り方を変えたというのを聞いて、そういえば自分も去年からすこし変えたのを思い出した。具体的には Work Log on Google Docs で書いた巨大な gdocs にダラダラ書いていく方式をやめ、Obsidian の Daily notes と作業(バグ)単位の書き捨てファイルを使うようになった。

具体的には、一日の作業の計画などは Daily notes に書く。セクションなどをテンプレートで用意しておく。そして作業をする際にはバグの ID とキーワードで wiki link をつくり、そのリンクを開いて作業固有の記録をとっていく。[[PerBug/b12345-crash-on-launch]] みたいなかんじ。このバグページからは、まず冒頭に bug tracker へのリンクを貼り、その下に時系列で記録をつけていく。

バグ単位でファイルを分ける利点は、メインの daily notes がゴミで汚染されないこと。バグページは、たとえばログのコピペとかがあって割と S/N 比が低い。それが daily notes に入り込むと可読性が著しく落ち、特に複数の作業を同日にやる場合にキツイ。

現代的なイメージとしては人間の context window を溢れさせないために subagent の context window にゴミを閉じ込めるかんじ。コンテクストを切り離すとニュアンスが失われるトレードオフがある、という議論が agentic coding には存在するが、ここにそうした問題はない。なぜなら人間には脳があるからです！すごいな人類！

LLM に summarize とかさせてるとかっこいいわけですが、させてません。

今年は去年に続いて低調な年だった。表立って愚痴を書くような年齢でもないが、他に書くこともない。そもそも、精神が低調だと物事を考えられないのだよね。目先の日常生活に支障はないが、精神世界が構築できない。ボケるというのはこういうかんじなのかもしれない。

精神の低調さを補うため運動はよくやった。ウェイトトレーニングをはじめかけたがこれは定着せず、ランニングは前より距離を伸ばし走るようになった。これは脳内麻薬で低調さをマスクするだけでなく、ストレス過食による体重増加を緩和する助けにもなっている。

運動でやる気を出す足しにと Pixel Watch (4) を買ってみたら、なかなかよかった。純粋に fitness tracker として出来が良い。

運動や睡眠は足りているが免疫が弱っているらしく、COVID x1, Flu x1, 風邪 x3 くらいで病欠がちでもあった。精神の低調さに引きずられている面はあるが、できることはやっておこうと Vitamin D を摂取することにした。

家庭は、特筆することはないです。あっても書かないと思うけれども。

あとはなんだろうな。精神の低調さを増幅しがちなのでソーシャルメディア (bluesky) をやらなくなった。そのぶんブログでも書こうと思ったがロジスティクスに問題があり捗らなかった。

精神の低調さをマスクするため音声・ビデオの消化が増えた。Podcast 聞きすぎ問題とは常に戦っている。YouTube は、ビデオ部門で働いていた頃は見すぎる傾向があったが、最近は程々にできている。あと日本のポップスを聞くようになった。仕事中は英語、通勤中・運動中は日本語と聞き分けることで、仕事を生活の他の部分から isolate する助けになっている。

よいお年を。

DWARF support for macOS and Linux by joelreymont · Pull Request #14369 · ocaml/ocaml via HN

LLM / ユーザがたまたま十分にずる賢くないせいでコピペもとの copyright ヘッダが生成ファイルにコピーされ出典が明らかになったものの、もうちょっと悪意(?)のあるユーザだったらダマサれかねないところである。

AI coding には未来を感じるが、結局は盗作なのだよなあ。

子に漢字の復習をさせるプリントがほしい、ということで claude code にやらせてみるか・・・と例文を作らせるところからスタート。が、ダメだな。

たぶん一つ一つの漢字ごとに shot すればいけそうだが、三年生の漢字 200 個をまとめてやらせるとダメ。例題生成とか LLM ちょー得意そうだけど、やりたいのはプリントに使う HTML を作るところ。例題作らせるのが一番難しい（相対的に）なので、下手にここで頑張るより手元にある教科書なりの教材からコピペするほうが早そう。というわけで LLM あそびはあとにしてささっと do thing that don’t scale させていただきます。しかし眠いのでまた明日。

Android Developers Blog: Android developer verification: Early access starts now as we continue to build with your feedback

少し前に sideload を署名必須にする と発表し大反発を買っていた Android, 条件付きで sideload を許す方向に方向転換すると発表したらしい。その方向がなんなのかはこの記事からはよくわからないが、Apple の Scare Screen みたいなものになるのだろうか。

去年くらいから Android/AOSP はオープンソース愛好家である自分のやる気を削ぐような発表を続けてきた。

• AOSP への直接のコミットを廃止し、社外からのパッチは社員が手動で見えない開発中ブランチにマージするようになった
• Pixel の AOSP blob がなくなった

この２つは、残念ではあるがエンジニアリング的な決断として理解できる部分もあった。

非公開ブランチで新バージョンを開発すると同時に公開 AOSP にもコミットできるという事実はパッチのマージ戦略やリファクタリングを激しく複雑にしており Android のリリース頻度改善を邪魔していた。この two-way merge をやめるのは、オープンソースプロジェクトの AOSP にとっては害かもしれないが非公開ブランチの開発者にとっては改善と見ることもできた。じっさい、この変更にともない 非公開 Android のブランチ戦略は大幅に簡略化された。

Pixel の blob がなくなるのも、新しい開発中の SoC と発売済 SoC のドライバを、従来のようにコピペフォークで使い捨てるのをやめコードベースを共通化した結果、未発売 SoC の非公開情報をバイナリから隠すのが難しくなったのかもしれないなと想像できる。8 以降の Pixel は 7 年サポートする と決めた対価だと思えば、AOSP Mod 勢はともかくカネを払って電話を買ってくれたユーザ的には一定程度納得できるのではないか。

これは憶測であって、本当の理由は誰にも知るよしはない。それでも上記二点は落胆しつつギリギリ我慢できると個人的には感じていた。（自分は雇用バイアスがあるので、世の中の人が我慢できないと言っても不当とは思わない。）

そんな自分にとっても、アプリの署名必須化はスリーストライクアウトの gut feeling があった。やはり本当の動機は知りようがなく、強欲から政府の圧力まで陰謀論が渦巻いている。ただ自分にとってもはや動機はどうでもよく、そんな不自由でダサい環境には付き合えねーわと匙を投げたくなった。エンドユーザとしてではなく、プログラマとして。

エンドユーザとしては、電話機というのは不自由なデバイスだという事実を受け入れ使い続けることはできる。昔のガラケーはもっと不自由で、それでも使っていたのだから。

ただプログラマとしてスキルやコードを積み重ねたい気持ちは失せた。iOS プログラマじゃなくて Android プログラマやってるの、別に Objective-C が嫌いだったとか雇用の都合とかだけじゃないんですよ。いちおう微かにでもオープンソースに隣接していたいからなんだよ。cs.android.com が内心の支えななんだよ。これと署名必須化は、自分のなかでは共存できないですよ。

自分が職業 Android アプリプログラマである事実はもはや変えられない。だから仕事として Android 関係の開発をするのは、会社員としてカネを稼ぐために受け入れている。ただ余暇・課外活動で Android するのはナシにしようと、署名必須化のアナウンスを見て考えていた。プログラマとしての自分を大きく毀損するそんな判断を強いられるのは本当に悲しかったが、スリーストライクアウトは無視できなかった。

そんな致命的判断が見直される。嬉しいニュースである。ただ実際にどんな形で決着するのかは実装を見ないとわからないので、デザートの神様に祈りを捧げながら成り行きを見届けたい。

This CL attempts to fix the runtime error that happens when: · bazelbuild/rules_android@a9d529f

久しぶりに OSS 活動、と呼ぶと語弊があるが仕事で書いたコードが GitHub に sync されていったぜ…

こういうの、昔だったらがんばって GitHub 経由でコミットするところだけど、ガッツがありませんでした。ビルドの仕方すらわからない。一方 monorepo なら手元のファイルをいじるだけである。

下手にいじると社内の Android ビルドを全滅させたりできるのでコミットのバーが高く、無理そうだったら捨てて feature request してやろうとおもっていたが、いちおうちゃんと見てくれてコミットに至れた。よかったね。こういうランダムなコードを書きランダムなバグを直し暮らしていきたいものだが、最近は世知辛いのでそうもいかないのだった。

最近まったくブログを書いていなかったことに気づいた。なにをしていたかというと、筋トレしたりランニングしたりしていた。夏に減量したのをきっかけに筋肉量の低下が気になりだして筋トレをはじめ、ジムでトレーナーに barbell の使い方を教わったりしたが「今の力だとまだ bench press は危ないですね」といわれ dumbbell を渡され、筋トレ盛り上がらねーな・・・とランニングの量を増やし、などと試行錯誤をしていると他の時間が完全に失われてしまった。運動、時間がかかる。

そして何も考えずに走る量を増やし、それまで一日三十分くらいだったランの時間を一時間くらいまで伸ばしたところ、スネの筋肉が痛みだしてしまった。Shin Splits というらしく、いきなり走る量を増やすと起こる典型的な症状なのだとか。というわけで一時停止中。やれやれ。

少し前から Foldable の電話機を使っている。去年同僚が使っているのを見て羨ましくなり、上司にゴネて会社支給の電話機を foldable にしてもらった。

前提として、自分はスマホのヘビーユーザーではない。どちらかというと意図的にスマホ利用を制限しているデバイス中毒警戒派である。という前置きをした上で以下感想。

• 画面がでかい事実は活用している。世の中の foldable user は開いて使う時間は短いというけれど、自分はコンテンツを見るときはだいたい開いている。閉じて使うのは、チャットの返信とか音楽再生とか、短時間に操作するときだけ。
• しかし大画面に対応していないアプリが多い。一方ウェブサイトは大画面だと PC 版相当が表示される場合が多く、便利。たとえば TechMeme とか PC 版の方が圧倒的に情報量が多い。
• 開いて使う時間が長い帰結として、バッテリーの持ちが普通の電話より悪い。足りないことはないが、普通の電話の感覚だと 70% くらい残っていて欲しいタイミングで 60% くらいになっている。閉じて使うのがメインならまた違う印象になりそう。
• 複数ウィンドウを使ったマルチタスクは、しない。なぜならユースケースは閉じた電話と変わっていないからである。というか世の中の tablet/ipad ユーザも大半はコンテンツ消化してるだけですよね。
• コンテンツ消化デバイスという点でみると、画面は初代 pixel fold の横長の方が良かったのになと思う。縦長動画を見るには左右がの余白がムダで、横長動画を見るには上下がムダ。活字コンテンツは全画面使えて良い。
• OS 全体の foldable への適応度は、まあまあ。時々ヘンなうごきをするが、それは自分が開発版 OS を使わされているせいかもしれないので、判断は保留。

値段は、電話機とタブレットを足したくらいなので、自腹で買うなら電話機 + タブレットかな。これは自分がめちゃライトユーザーである事実の反映だと思う。通勤も自転車で、外出時に大画面が欲しいことが少ない。いまは、昼休みの食後のダラダラインターネットをひやかす時間が主な活用場面になっている。

ただ画面がでかいのは、ムダではない。老眼年寄り固有の問題かもしれないけど、デカイ画面は圧倒的正義。トレードオフとしての重さはどうかというと、使用頻度が低い身には影響少なめ。なので foldable, tech enthusiast だけでなく年寄りに売るといいんじゃないかと思いました。

エーアイはすごい。それは間違いない。なんか頼むとコード書いてくれる。それがちゃんと動く。計画をたてて順番に進めることすらできる。すごい。Agentic Coding でエーアイが色々なことを「できる」事実には未来感がある。

一方、それが他の手段と比べて優れているかというと、何と比べるか次第である。

あるときエーアイをコードの migration (インフラ移行) に使ったケーススタディーの論文が投稿された。これを読んだ大規模コードベースの専門家は、こう苦情をいった。曰く: 「彼らは大規模リファクタリング自動化のツールを持っているのにそれを使わず手動の変更とエーアイを比べている。おかしい」

同じパターンは身近にもよくある。AI でなんらかのデモが動いた。そんなことができるなんてエーアイすごい！が、まさか実用とかしないですよね？それ他の自動化ツール使っても同じことできるし安いし早いし止まらないですよね？釘を打つのも野暮なので黙っている。

たぶんどこかで何らかの良心が働くであろうと期待はしている。それでもこの手のデモ作成が推奨され筍のように生えてきたら、一割くらいはうっかり滑り出て実用化され悲劇を招きはしないか。エーアイの「できるすごさ」にともなう感激・感動が価値判断を麻痺させないか。そんな不安がある。

仕事におけるエーアイのなかで一番悲しいのは「仕事にエーアイを使え」と言われることだと思う。

「製品にエーアイの機能を入れろ」なら、まだわかる。市場判断は自分の仕事ではないから。でも「仕事にエーアイを使え」はその自分の仕事のやり方を指図されている。嬉しくない。

大企業、仕事の仕方に縛りは色々ある。それは法制上の理由かもしれないし、様々なリスクからビジネスを守るためかもしれないし、局所的な利点でなく大局的な最適化を優先したためかもしれない。こういう縛りは嬉しいものではないが、理由はわかる。「エーアイを使え」には納得の行く理由を感じにくい。理不尽に自分の agency を制限されたように感じる。

「エーアイを使え」は空気であって、文書化された何かではない。行動規範に類する文書は「エーアイを理解しろ」のような言い回しが選ばれている。けれど空気はちがうことを言っているように自分には感じられて、それが息苦しく悲しい。

Workslop は、悪意のあるケースもあるが多くの場合は無邪気なもので、だからこそしんどい。

数ヶ月前「エーアイが書いてくれたんですよ！」と同僚が送ってきたコードにレビューコメントをしたら「エーアイが直してくれました」と切り替えされ、もうめんどくさいので全部 LGTM でいいわ・・・という気になった。同じ相手のまとまった量のコードをそのあとレビューした記憶がないので、彼がいまどうしているのかはわからない。

あるとき部門の “AI Day” があり、同じ同僚が「仕事のワークフローをエーアイにやらせました！思ったことをバーっと書き出してエーアイにたのむだけでソフトウェア・エンジニアリングに構造ができます！」というプレゼンをしており、その braindump から生成された Design Doc には “Alternatives Considered” というセクションがあった。誰が consider したアイデアなのかい・・・なんていう疑問が頭をかすめたが、深く考えないことにした。

心の健康を保ったまま Workslop を相手にする良い方法を見いだせていないので、今は暫定的に心を無にして LGTM することにしている。たぶんもうすぐレビューもエーアイがやってくれるようになると思う。人間を介在しないほうが平和でいい。

あるとき、agentic coding にそれなりの、とはいえそこまで長くない仕事の時間を費やして、まだ使えないなという結論が出たとする。

そういう話をオンラインですると「使い方が良くない・良い使い方をわかってない・スキルがない」といった類の反応が帰ってきて、ひどく消耗する。

自分は、それなりに agentic coding のやり方に関する議論に目を通し、それを適用したつもりでいる。一方で、時間や道具の制限もあるしやる気もそこまでないので万全を尽くしたとは言えない。だからその反応の真偽はわからない。自分が無能なのかもしれないし、問題に対してモデルやツールの能力が足りていないのかもしれない。

この「モデルが無能かお前が無能か」の議論はオンラインで山ほど繰り返され、あまり生産的には見えない。その不毛さが自分に降りかかるとうんざりしてしまう。

「仕事のバグがとれねーくそったれー」という他人に「デバッガちゃんと使えてます？仮説検証ループ回してます？」とか言わないでしょ。「そうときありますよねー大変ですねー甘い物でもたべてがんばりましょー」とかいうでしょ。エーアイツールもはやくそのステージになってほしいなと思う。でないとオンラインで管巻きもできやしない。わたくし別にエーアイの悪口もあなたの悪口も言ってませんから、楽しくやりましょう？

エーアイの躍進にあわせ、エーアイ・ビリーバーになってしまった人がよく目につく。

一番目立つしわかりやすいのは、エーアイの可能性に賭けてそれまでの職を捨てスタートアップなどに言ってしまった人々。いいですよね。人生賭けてる。リスクとってる。がんばって歴史に名前を残してください。

会社はやめずに、今のしごとのなかでエーアイの旗振り役になってしまった人。けっこう困る。その人が本当の believer なのか、Resume-Driven Development (あるいは大企業バリエーション Promo-Driven Development) なのかの判断に苦しむケースがけっこうある。職場というのは市場経済よりはトップダウンの計画経済なのでこういう局所最適な行動が起こるのだけれど、エーアイのような未知数の多い分野に計画経済は弱く、市場に歪みを肌身に感じやすい。しんどい。

現代の生んだ市場であるアテンション・エコノミーでも、エーアイによる気候変動を目にする。自分にとって気になるのは、ソフトウェア開発のある分野の第一人者だったような人が突然エーアイ・ビリーバーになってしまうケース。こうした転身エーアイ・ビリーバーの発言は、本来の専門分野に関する発言に比べて、なんというか、軽い。あまり裏付けを感じられない。エーアイ分野で裏付けのある発言ができる人はすごく少ないので発言の軽さにも無理はないと思う一方、発言を信頼していた人間の言葉が信じられなくなるのは悲しいものです。

こうした第一人者・インフルエンサーが、エーアイ・ビリーバーに転身する判断はたぶん合理的なもので、そのビリーブしている気持ちにも多くの場合は嘘偽りはないだろうと思う。悪意・他意があるとは思わない。ただこれは、究極的にはサンクスギビングで顔を合わせた親戚が MAGA になっていたのも民主党を不甲斐なさのせいにするのと同じで、なんというか、個人を責める気持ちが無いとは言え悲しみはある。