Via HN
VIDEO
話題になっていたので冷やかす。
コードを書いていないのみならず読んでいない (だから文法の醜い Rust でも大丈夫) と豪語。メールサービス Hey のフロントエンドをネイティブ (vibed) アプリにした結果バックエンドが小さくなったので Rails を捨てて Rust に(vibe で)書き換えたらちょう性能あがってやったぜ、などという。ほんとに…?
DHH Linux たる Omarchy も “素敵な計算機アプリが欲しいから ChatGPT にスクショ作らせてそれを Qt C++ で vibe したのちアップロードしたぜ. 読まないなら C++ サイコーだぜ” と豪語. Omarchy, Slop app が降ってくる distro とは予想の斜め上である。もともと興味なかったけど使わない積極的な理由ができてしまった。
「エーアイは祭りだ踊らにゃソンソン」というメインの主張は個人的には同意しているけれども、それを権力で他人に押し付けているように見られてしまうのが反感を買った理由なのだろうね。そもそも Rails の親分が Rails のイベントで Rails の話をしないという。ただ The post-Trump Era のこの人はずっとこんなかんじの zero empathy personality なので驚きはない。
ところでこの pill をキメて別人格になってしまった系 keynote の古典として個人的には Hack PHP に async/await を入れるべく Facebook と働いていた頃の Erik Meijer による “One Hacker Way” を推したい。
VIDEO
今見ると平和なものです。
腰や首に悪いのでラップトップを素のまま使いたくない。デスクトップを使えるなら使いたいが、夫婦会話環境維持等の都合で寝室に閉じこもらずキッチンテーブルでコンピュータを使うのが望ましいため、ラップトップスタンドを使い始めた。
Amazon.com: Roost V3 Plus
これにキーボードとマウスと電源を繋いで使う。ちょー嵩張る。そしてキーボードとタッチパッド、すなわちラップトップの下半身が無駄（バッテリーと基盤が入っているわけだが）。
なんでこんな選択肢しかないのだろう。エルゴノミクスの意識が高まりスタンディング・デスクなどの普及すら進みつつある昨今「腰と首に優しいラップトップ」というものがあってもいいはずだが、ない。キーボードと画面が切り離されつつ有線で給電はされる、どこからともなく画面に脚が生える、みたいなラップトップ。
一部の detachable laptop, 特に特定世代の Surface Pro と特別なアクセサリキーボードはこの条件を満たしているらしい(ただし接続は無線)。でもわたくし Windows の世界には住んでいないのだよねー・・・。
自分が生息する環境で選ぶとしたら Android Tablet と BT Keyboard が近そうだが Android Tablet 気乗りしない・・・と思っていたら Googlebook というキーボード付き Android Tablet みたいなものが発表され OS も開発元サポートで長く更新されることになっており、それのキーボード取れるやつをくれ！と思いました。ただあまりに新鮮すぎてやや地雷感。そもそも Android Tablet をメインの作業環境にするというアイデアが気の迷いに思える。
腰と首に優しいラップトップたのむ。高齢者にも売れると思います。あと Roost v3 は XPS 17 を載せてもびくともしなくて立派。
The load-bearing smoking gun · Andrew Loutfi
You’re right to push back here, and I want to acknowledge that directly rather than papering over the underlying issue with a superficially confident answer.
…
That is where the load-bearing seams become decisive.
…
今年に入った頃から Claude Code の語調が苛立ちと笑いの種になっており、興味深いなと思う。1-2 年前は ChatGPT (4o) の “glazing” が嘲笑の的で、Claude は対称的な “誠実さ” が AI pilled な人々に評価されていた。もはやその面影はない。
個人的には coding agent の口調に Claude 臭さ、エーアイ臭さがあるのはいいことだと思っている。一目でエーアイ/Claude だとわかるので。あまりに自由自在だと疑心暗鬼になってしまい人間とのコミュニケーションに支障が出る。Fable 5.1 / Opus 5.5 は口調も改善されたことになってますが、どうなのかな。
仕事で使っている Gemini はどうかというと・・・あまり自然言語の回答を読んでいない。なるべくコードだけ見て、コードレビューツール上で指示・操作することにしている。このやり方はもはや前時代的で software factory しないといけない時代なのだろうけれど、まあいいです。
ところで冒頭の load-bearing smoking gun いいインターネットだと思わない？誰か日本語でもやってほしいな。
以前からの腰痛が慢性化し、のみならず微妙に脚もしびれっぽいのがあるな・・・と医者に行ったら Stenosis (脊柱管狭窄) ですねーと言われてしまった。MRI を取ってみたり（狭窄してた）、理学療法士に筋トレを習ったりしている。基本的には治らないので痛みを最小化する付き合い方を身につけるという類の障害。だいたい年寄りがなるものならしいが、一足早く年寄りになったということらしい（脊椎が）。ただ手術がいるほど悪くはない。
腰痛だけでなく、理学療法士に走りを止められているのも困る。もう何年もラン通勤をしており、有酸素運動およびカロリー消費を通勤に重ねてきた。水泳とバイクならできるとはいえベイエリア、あまり公共プールが充実してない。近所にバイクで走りやすい道もない。この暮らしではカロリーが燃えない。
カロリーが燃えないと飯が食えない。というか飯を食うとあっという間に脂肪になってしまう。好きなものを食べられないストレスがある。手軽にカロリーを燃やせる Fitbit Premium の guided program や縄跳びも走り同様のインパクトがあるので敬遠しており、文字通り不完全燃焼状態。
更に心臓に負担をかけられないため、脳内麻薬も不足。当方脳内麻薬ジャンキーなのでヤクを放出のうえキメないと鬱になってしまう。
理学療法士の筋トレは、筋肉はつくが心拍数は全然上がらない。なお指導をうけコアトレをやりまくってるため腹筋は過去にないほど固くなった。これを 20 年前からやればよかったのか。そんな人間ではないが。
会社のジムに stationary bike があったので漕いでみる。自転車用の脚の筋肉が発達しておらず、かつ stenosis は脚の力が弱りがち、なので心拍が上がる前に脚が疲れてしまう。イマイチ。だが無いよりはマシ。渋々何度か昼休みに漕いでみたが、盛り上がらない。
Nordic Walking
徒歩も、走りほどではないにせよ負担はあるらしく、長く歩くと脚と腰に怪しい感触がある。歩きすらダメだとハイクも街歩きもダメで家族の外出全滅なのでは・・・と途方にくれた。
縋る思いで素人向け stenosis 対策の本を数冊買って眺めてみると、歩きは血行・バランス改善や筋力維持のため stenosis 患者にも勧められている。ただ stenosis 勢は（メインストリームが年寄りなせいもあり）足腰が弱い。そこで歩行器や杖を使い歩くことを勧められている。無理のない範囲で頑張って歩くほうが良いらしい。
歩行器はともかく杖はありかもな・・・と調べてみると Nordic Walking という杖つき歩行の手法というかスポーツというかがあることがわかった。
VIDEO
もともと北欧の雪国でクロカンの選手が夏場のトレーニングとして始めたものらしい。杖もスキーのストックぽい形をしている。今日では足腰弱めの年寄りむけ健康プログラムとして一部で人気を博している模様。日本でもそのままノルディックウォーキング として、やはり主に年寄りの運動としてとりくむ人が一定数いるらしい。国産のポールすら売っている 。
自分に必要なのはこれでは？ということで早速専用のポール を買い、インターネットの入門ビデオを何本か見て付け焼き刃の知識を仕入れ、近所の散歩や通勤ウォークを半月ほど試してみた。たしかに足腰への負担が、ゼロにはならないにせよ、軽減される。重力をある程度腕と杖に逃せる。そして杖のデザインが早歩きを誘導するせいか、まあまあ心拍数があがる。腕を動かすぶん上半身の筋肉が活性化される影響もあるらしい。スマートウォッチのカロリー計測結果も良好な脂肪燃焼を示している。ノルディックウォーキング推薦記事では単位時間あたりの消費カロリーが 2-6 割増えることになっている。体感としても 2 割くらいは増えてる印象。真面目には測ってない。
通勤ウォークは片道一時間前後。歩き終わるとしびれ気味の脚に疲労感はあるし腰の緊張感は高まるが、痛みは増さない。のみならず、血行がよくなるせいかウォークのあと理学療法士推薦筋トレを被せるとむしろ腰痛が一時的に軽減する。いいじゃん。そしてなにより、これでメシが食える！
欠点もある。
まず杖が路面を突くカツカツという音。これはまあ、受け入れている。幸い通勤経路は特別静寂に溢れてもいないので目立つほどではない。あと歩きよりは他人との間隔が必要。東京の細くて人口密度の高い歩道では厳しいだろうと思う。が、幸い人口密度低めの車社会で生活しているので困らない。たまに譲り合いの精神を発揮すれば乗り切れる。
あとランと比べ心拍数が振り切らず、息切れするような心臓への負荷をかけれないのは課題。まあそれはおいおい。
不向きなケース
通勤ウォークでの成功に味をしめ、先週末は家族旅行のハイクと街歩きに持って行ってみた。が、これはいまいちだった。まずハイクは（森田家の場合）歩き続けるより立ち止まって野山などを愛でる時間がながい。しかしノルディックウォーキング用のポールはスタスタ歩き続ける前提なので立ち止まり中は体重を逃しにくい（普通の杖と比べて寄りかかりにくい）。あと狭いボコボコした山道とかは、やや苦手。
街歩きも似たような性格がある上に、通勤経路より人口密度が高めのダウンタウンだったのでポールウォークの望ましい速度や姿勢を保つのが難しかった。あとノルディックウォークのポールは付属グローブで手に固定されるので着脱がややだるいのも難。
そのせいかハイク＋街歩きの旅行から戻った日はやや腰の調子が悪かった。次回のハイクまでには普通のトレッキングポールを買いたい。ただ普段の通勤や近所の散歩ではノルディックウォークのポールを使い続ける予定。
というわけで一足先に杖で歩くステージに進ませていただきます。
先月とそんなに変わってないが、いちおう月次で記録。
完全にコードレビューがボトルネック。バカスカ送りつけるのも気が引けるが、他にどうしたらいいのかもわからない。むかし WebKit やってたときの「レビューされなくてヒマだなー」という感覚を思い出す。あれよりは 10x 以上マシだが。相手が良心的なだけに心苦しさがある。
コードレビューといえば、コードレビューエージェントみたいな社内ツールが登場したので試している。SQL のように自分が素人なジャンルでは有効だが、Kotlin のように言われなくてもマシなコードが書ける言語だと効果薄。たぶんガチガチにチーム向けのカスタマイズをすべきなのだろうが、そういう標準化が一切ないのだよねーこのチーム・・・。
Antigravity, Best-of-N というモードで２つ(以上)のスレを同時進行していい方を選ぶ、というオプションを勧めてくるが、最近はそんな小細工しなくていいかな・・・という気分。Gemini 3.x Flash, Claude 的空気を読む能力はゼロだが、それなりに付き合い方がわかってきた感。あるいは実際に 3.5 -> 6 -> 7 と賢くなっているのかもしれない。いつも微妙な snapshot を使わされているのでよくわからないが・・。
モデルの賢さを活かし長時間なんか作業させる、みたいのはやってない。今の仕事に必要ない。書かせたコードは結局レビューする必要があり、そしてレビューしてもらう必要もあり、あまり一度に大量のコードを書かれても困る。それがきちんと小さいコミットに別れているにせよ、序盤のコードで直しが発生したら以降は全部やりなおしで、そういうやり直し作業はコンテクストを汚染する。コミット積むのは３つくらいが現実的かなという印象。
もちろん探索的な性格のコードは結果がでるまでより多くのコミットを積む必要があるが、それにしたって他人へのレビューはともかく自分ではコードを見る必要があり、そうなると、まあ 3 つよりは多くてもいいけどせいぜい倍くらいじゃね？
結果として、一つのコードをバーっと速くするのではなく並列度を上げてスループットを上げる方向にながれがち。だが、どのみちレビューを頼める相手は限られており、そこで律速される。それに、そんなにたくさん並列化できるほど依存関係フリーな仕事ないのよ。
もっとハンズフリーでバーンと頼みたい仕事はあるのだろうか？いまいち思いつかない。ただ社内のチャットとかをみてるとわりかしバーンとやっていると主張する人々がいる。自分のエーアイネイティブ度が足りていないのか・・・しらね・・・。
コードがはかどる結果、人と話して相談する系の仕事が残りがちで、それらの procrastination をエーアイは解決してくれない。いや、少しはしてくれるが、俺の procrastination を甘く見るなよ、みたいなかんじです。尻たたきエージェントの登場が望まれる。いや望みませぬ。
3.5 Pro こないかなーと待っていたが来ないまま７月が終わろうとしているのでいちおう月次感想文を書いておく。主に仕事。なお仕事では社内生贄モードを使っているので裏にいるモデルは不明。たぶんなんらかの Flash だと想像している。
一瞬ヒマがあったので前に挑んで失敗した作業 (ListenableFuture を coroutine で使う)に再挑戦してみたところ、できた。モデル使いのスキルが上がってきたと感じた瞬間。そのスキルがいるのかというと、まあ目先の仕事では有効。
相変わらず第三者のコードレビュー依頼前にめちゃ何周も自己レビューしている。もう良いかなーとおもった瞬間ゴミコードをブチ込んでくるので油断できない。作業の細分化は、相変わらず必須。自分がやるだろうという粒度でやっている。
それでも段々と仕事の並列度を上げている結果、レビュー依頼量が増えて相手に負担してそうだなー・・・という葛藤がある。ひとりすごい良いプログラマがいてほんとはその人にいつもレビューしてほしいんだけど、迷惑なのでチーム内にランダムで散らすようにしている。
その一方、エーアイの書いたコードを送り付けたらエーアイのレビューが返ってきたのでエーアイに直させて終了、という事態がついに発生した。何かに近づいている。自分は今のところエーアイレビューは(他人相手には)使っていない。方針が合わないのと、幸いあまり量がないので。
レビューといえば、アプリのコードはちゃんと見るんだけど自動テストの Python とかパイプラインの SQL とかどうしても雑になりがちで、もうわけない感。
Antigravity が worktree 的なやつ (の jj 版) をバカスカ作るようになった結果、いよいよ普通の IDE を使わなくなってきた。なぜならどこにコードの実態があるかわからないからである。ターミナルも開かない。
エーアイのせいでコードが汚くなるかというと、今のところ先送りしていたクリーンアップが捗った結果あまり問題は感じていない。ただこれは自分の管理下にあり自分が書いたコードの話で、たまに飛んでくるコードにはしばしばすごいゴミが混じっている。ただ前も書いたけど、これはエーアイ以前からの現象である。
そういえば jj を使うのは、ビミョーに下手。もっとも jj が下手なせいのか jj と社内バックエンドのインテグレーションを正しく理解していないせいなかは不明。濡れ衣かもしれない。
あと開かないといえば Obsidian でのメモを全然とらなくなった。なぜなら作業工程がほぼすべて conversation/trajectory に残されているからである。翌日作業に復帰する脳の負荷がゼロ。まあもともとコード書いてないのでニアゼロなのだが。しかしこれはいいのか・・・？
“Loop Engineering” は、してない。マイクロマネッジが必要で、勝手に任せる感じになってない。ただ作業の要求は prompt に直書きではなく issue tracker などに書き、バグ ID をわたして「これやるよ」と言うようにしている。コードレビューも、従来どおり人間向けレビューアプリの上でやっている。そもそも Antigravity は loop engineering できなそうじゃない？できる？
Skills は、一時期いっぱいつくったが使わずゴミになっているものが多い。整理したほうが良いな。（-> した)
scheduled task を使い、毎朝「昨日のレビューで指摘されたことをまとめてレビューチェックリストに追記して」と頼んでいる。8 割くらいゴミなので消しているが、それでも何かは残っている。効果は、不明。
Subagent 活用モードみたいのがあったので使ってみたが、恩恵を感じない割に問題は色々あるので使うのをやめた。たとえばコードをレビューして直させる時毎回 fresh な subagent を作る結果、前々回くらいの指摘事項を忘れて同じゴミを生成してくることがある。たぶん自分のようなマイクロマネッジ勢ではなくもっと丸投げする使い方に向いているのだろうな。このモデル相手に丸投げ可能な仕事がなんなのか自分にはわかっていないが・・・。
ただ Subagent 的に計画を立てるスレと個々のコミットをたてるスレをわけることで context の枯渇を防げると良さそうなので、なんとか AG の機能の範囲で模倣できないかなーとはぼんやりおもっている。
課外活動:
ちょっとした watch (WearOS) app を CC に作らせてみる。悪くはないが、当然自分好みのコードは出てこない。のでそこそこマイクロマネッジしているが、根本的にコードが単純なのとモデルが賢いのとで、往復の量は多くない。
とはいえまえ React+Electron でアプリを作ってた時と比べると、ダメさが目に付きやすい。自分がわりかし Android 詳しいということなのでしょう。そりゃ React と比べたら詳しいですわよ・・・。
ただ $20 の Pro Plan だとわりかし token が枯渇しがち。仕事は自分の使い方の範囲だと無限に使えるかんじなので、それはいいなと思う。
こういうときは Pi+DS4 でなくつい CC を使ってしまう。仕事が堅いのだよなー Claude・・・。
The scariest part to me is that we become dependent on these new machines in new ways. Software has always depended on tools. I remember the time when I had to pay for compilers. These new tools are a flashback to times where creating software came with real costs. But now it’s no longer a one-time payment, it’s a constant dependency. Not just a dependency on a filled wallet, but also a cognitive dependency.
Pi Coding Agent を開発する Armin Ronacher が agent 依存の高まるコードベースへの不安を語っている。なんとなく既視感を感じた。
昔々 WebKit/Blink の仕事をしていたころ, fuzzing によって見つかったクラッシュバグを毎週のように直していた。GCP 上のクラスで動く Fuzzer は半ランダムに DOM を操作する JS のコードを生成しては実行し、継続的にクラッシュバグを見つけてくるのだった。
ブラウザのコードを触ればバグは埋め込まれる。その不都合な事実を fuzzer によって叩き込まれると同時に「これクラスタ代を払うカネが無くなったらどうなるんだろう」と不安も覚えた。カネがないとバグが直らない。Mythos がないとバグを見つけられない昨今の風潮に通じるものがある。百倍くらい価格差ありそうだけど。
相対的にカネがないブラウザはどうするのだろう。そう思って Firefox に目をやると、彼らはクラッシュしない言語たる Rust をつくり、それでブラウザを書き直していた . もっというと DOM は JavaScript に乗せメモリ管理を GC に任せていた。計算資源を燃やすかわりに知恵を使う。クールじゃん。そう当時は思った。(Chrome の名誉のために補足しておくと、Blink の DOM もその後何らかの GC を導入してある種のメモリ安全性を達成したらしい。)
エーアイ時代にも、カネと計算機の力でねじ伏せるコードと知恵と勇気(友情でも愛でもなんでもいいよ)で切り抜けるコードがあってよい。
上でリンクした記事は、来たるべき時代の予兆として Curl 開発者の burnout 寸前事例を挙げている。が・・・これはどのくらい一般化できるのだろう。世界一人気のあるネットワーク・プロトコルの世界一メジャーな実装として世界一攻撃に晒されているというのによりによって C で書かれているこのライブラリ、ソフトウェア開発の未来として一般化するより人類の限界をベンチマークする事例と見たほうが適切ではなかろうか。
ソフトウェアのバグは一般に直すより見つける方が難しい。Ronacher が恐れるような「攻撃にエーアイを使われたら防御にもエーアイが必要」というとき、別にエーアイにコードを書かせる必要はない。むしろ Ronacher がいうような、ヒトが慎重で硬いデザインを詰めていくほうが妥当なことは多いと思う。防御のためのエーアイは、攻撃者より先にバグを見つけるのに使えば良い。
やがてエーアイが人間より硬いコードを書くようになり、しかし人間にはそれが理解できない日がくる可能性はある。たとえば formal method をエーアイに書かせるぞ と息巻く Jane Street はそうした世界にむかい先陣を切っている。ただ個人的には先の話・ニッチな話に感じられる。
どういう形をとるにせよ、計算機の力で人智を超えたコードを生成しまくる世界も、計算資源の嵐を知恵と努力と友情で乗り切る未来も、それぞれの趣や面白さがある。
エーアイ絡みの心配は自分も色々あるとはいえ、重要なソフトウェアがゴミコードに埋もれて窒息する不安は今のところあまり大きくない。ただし前提がある: エーアイ業者はその泡銭で CS 研究者をやとって遊ばせておいてほしい。CS 研究者もそれに便乗しコード環境問題への取り組みを頑張って欲しい。問題は起こるし、もう起きている。でもそういうボヘミアン研究者がきっとなんらかのブレイクスルーを見つけ出すと思うんだよね。それがなんだかは知らないけれど。自分の楽観は、人類が産んだ賢い人々への楽観なのかもしれない。
今日もまた仕事のコードレビューでイラッとしたコメントを書いてしまい余計な手間を増やしてしまった。反省。
交通事故も、交通規制を守らないひとが一人いるだけでは起きないが二人いると起こる。仕事の議論もイラッとしたひとが二人いると揉める。そのうちの一人になってはいけないが、人間ができてないので時折なってしまう。
少しまえ、エーアイに語感を和らげてもらう社会性フィルタ について書いた。今回も社会性フィルタの適応をサボったのがいけなかったかな・・・と一瞬考えたが、マジレスとして社会的フィルタは本質的には風刺であり、そのラインを超えてはダメである。要するに microaggression ですからね。ただ現実問題としてイラッとした時に microaggression を発動させる一番表面的には無害な方法なのも事実で、フロドの指輪に似た禁断の誘惑がある。
COVID 末期に Quiet Quitting という現象が流行った。これは、今思えば COVID 的というか WFH 的な現象で、社会性フィルタに通じるところがある。仕事がオンラインになればなるほど社会性フィルタや Quiet Quitting はやりやすくなる。人間性への敬意を書いたコミュニケーションは画面越しのほうがやりやすい。脊髄反射や本音を画面のこちら側に隠しておけるから。
ただ人間性を軽視するとコミュニティへの所属感、チームの結束感や相手との親密さは失われる。仕事のやる気もさがる。なので眼の前の仕事をそれなりに持続性をもってやりたいなら、これらは望ましい態度ではない。Quiet Quitting は quit してるので持続性は期待してないから仕方ないとして、社会性フィルタはダメ。わかってる。
ただしょうじき、エーアイの指輪はいちどつけたら外すのめんどくさいよね。AI チャットのせいで若者ちゃんと人間関係鍛えられないのでは という懸念を多くの年寄が感じているが、若者に限った話じゃない。仕事のめんどくさいコミュニケーションしたくない。肌のあわない苦手なひとと話したくない。にこやかにイチからきちんと説明して説得して協調とかしたくない。そんな気分があるからこそ Workslop が生まれる。社会性フィルタとか呼んだところで slop に違いはない。自分は話したくないんですよそもそも。
ここで踏みとどまって真人間として振る舞い社会的筋力を鍛えるのが会社員の仕草であり、出世パスであり、大人になるということだった。しかしエーアイや画面や大人気ない国家首脳の皆さんなど今日的な現象の数々がこうした筋トレへの意欲を過去にないほど削いでいる。
“Bowling Alone ” (邦題: “孤独なボウリング ”) という昔書かれた超有名な社会学の本があり「アメリカ人最近孤独らしいんですけどなんでですかねー、調べたけどテレビくらいしか原因はなさそうですねー」と書いていた。しかし四半世紀前は平和なもんだったね。 すくなくとも職場というリアルワールド社会性強制ギプスは完全に健在だった。アンチ社会性筋トレマンガ Dilbert に面白さを感じられるのも、リアルワールドでの社会性をある程度は強制されているからである。
つまり: めんどくさい人間関係を生産的に乗り切る社会性筋力はかつては雇用を通じ強制的に鍛えられたが、時代の流れがその強制力 (“friction”) を流し去ってしまった。だからかなりやる気を出さないと社会性筋トレができない。しかし社会性を鍛えられていない人間から構成された社会は果たして望ましいものなのだろうか。
この反語にはしかし、安易に頷くことはできない。先のコードレビューで起きたような衝突（レースコンディションによるクラッシュを無駄な動機を挟むことで性能劣化の問題に転化するコード書くんじゃねーお前のバグがこっちに来るじゃねーか！みたいな揉め事）を、ソフトウェアエンジニア的に解こうとすると 1) テストを強化しましょう 2) プロセスを強化しましょう 3) ベストプラクティスを文書化しましょう 4) ベストプラクティスをフレームワークにエンコードしましょうみたいな話になり、これらはさほど社会的な解決でなくはないか。いやプロセスは社会的かもしれないが、一番ダメなやつじゃん？ 社会的じゃないほど望ましいじゃん。
そのようにして出来上がったチームやコードベースは衝突/friction のすくないなめらかなシステムに違いはないが、必ずしも社会的・人間的でない。他人の社会性（のなさ）を補ってくれるシステムは自分の社会性（のなさを見逃して欲しい気持ち）も抑圧される。個人的にはちょっと衝突リスクがあってもゆるいコードベースの方が働きやすい。しかし時々今日のようにイラッとしてやる気を損なう欠点がある。うまい話はない。結局、抑圧的システム化と人間的余白と苦手な同僚との付き合いのバランスをとるゲームのスキル獲得がソフトウェア開発者の社会性筋トレだということだろう。
エーアイはこのバランスを破壊した。そして workslop のような従来の社会性を損なう営みを産んだ。こういうのは目の当たりにすると腹が立つ一方、自分も誘惑に負けてやりがち。エーアイを火山のマグマに投げ捨てることは出来ないから、何らかの形で新しい秩序を作り出す必要がある。今日はイラッとしてすまなかったけど指輪は使わず痛みを感じることが出来た。やる気が回復したらなんか生産的な施策を考えます。はい。
読んだ: Amazon.co.jp: 半導体 尖端覇権の興亡 eBook : 大鹿靖明: Kindleストア
日本の半導体周辺産業凋落の歴史。なんとなく 20 世紀で敗北していたと思っていたがメモリとかフラッシュなどは 21 世紀でも序盤は頑張っていて、しかしこの 20 年で負けてしまったねという話。Chip War " (邦訳 “半導体戦争 ”) や “Apple in China ” を読むと、日本はチラっと出てきたあとすぐ敗北退場してしまう。この本は退場したあとどうなったという話で興味深い。自分は、何も知らなかったね。関心も払っていなかったし。
日本はいわゆるメーカーが垂直統合なせい半導体産業が分散しており、規模で戦う局面についていけなかったのが敗北の主要な原因だと著者は分析している。政府が介入してデフラグを試み、ルネサスだのエルピーダなどがあったがあまり上手く行かず、ルネサスはまだあるがエルピーダは消滅（買収）。あとキオクシア（なんかゴタゴタしてたが最近はエーアイ景気で復活）などなど、色々あったのだねーと勉強になった。そうした産業構造の問題ではなく、サブプライム直後の円高（当時は日本の銀行が手堅かったのでドルが逃げてきた）で価格競争に負けて滅びたり、地震のせいで工場が壊れてそのまま破滅したり、踏んだり蹴ったりの様相。
赤字やらなんやらで国内産業が中国にどんどん買い取られていく様は Apple in China の日本版というかんじで趣深い。仮想敵国にこんなにバンバン国内技術を売り渡して全然ブロックされないとは、昔は平和だったのだね世界は。完全シフト済の現代 Overton Window から見るとドン引きしてしまう。
前半八割くらいがそんな凋落の話で、あとの一割が TSMC 熊本進出の話。そして最後の一割がラピタスの話。ラピタス、こないだ北海道旅行をしたときに話をきいてへーと思いつつスルーしていたが、IBMの技術をベースに税金投入してファブを作る、客はこれから探す、みたいなめちゃ掛け金高くて歩の悪い博打を打っていると知りビビった。日本で 2nm? ほんとに? ASML の機械が搬入される下りとかもう読んでいて胃が痛い。
「覇権」やら「戦争」やらの表現が示すように、TSMC もラピタスも金稼ぎではなく保安上の施策なのだよね。アメリカ政府が CHIPS Act で Intel や TSMC に出資したようなもので。なので分が悪いのはある程度織り込み済みと言えるが、こんなカードしか残っていないとは・・・と悲壮な気持ちになる。空前のエーアイ景気の勢いで客を掴んで起動に乗せられるといいですね、ほんとに。Intel も Apple や Google から fab として発注を受けるという前代未聞の展開が続いており、政府の圧力もあったろうけれどそれ以上に TSMC だけじゃ帯域が足らんという話なわけで、全てエーアイのおかげ。日本も恩恵受けてほしい。
少し前に Substack あそびとして Noah Smith を購読していたら “ウィーブが日本を救う ” という本の抜粋 がアーカイブにあったので目を通した。Noah Smith は TSMC 誘致みたいな FDI (Foreign Direct Investment) で中国がやったみたいに発展途上国プレイをして経済復活だ、みたいな話をしており、日本そんなキャラじゃくね・・・と思っていたが、今となっては妥当 (less worse) なカードなのかもしれない。この本を読んでふと思い出した。
Statement on the US government directive to suspend access to Fable 5 and Mythos 5 \ Anthropic
エーアイコーディング、安い/公開ウェイトの中国モデルを弱いやつなりに上手に使うスキルは、思ったより守備範囲が広くなるのかもしれない。
以前はそんなの過渡期のスキルでモデルが強くなれば解決するから、せいぜいクラウドの free tier タダ乗りスキルみたいな貧乏余暇プロジェクト勢のニッチスキル止まりだろうと思っていた。これは自分個人にとっては重要だがエンタープライズ的にはどうでもいい。金を払って強いモデルを使うほうが手っ取り早いので。
ただトークン価格の高騰や上記のような言動に代表される地政学的リスクを考えると、強いアメリカモデルから距離をおきたいと感じる勢は、特に国外では増えそうである。少し前から Sovereign Cloud みたいな動向も盛り上がり始めているし。
もちろんリスクというのは確率的な事象であり、「結局プロプリエタリアメリカモデルに乗っておくのが正解でした」となる線が今も一番太いとは思う。ただ不測の事態に備えたい人々が性能を犠牲に柔軟性や自己所有を優先するのも珍しいことではない。危険というのは、一度見えてしまうと忘れることは出来ないのである。
安いモデルたち、強いモデルに比べると大したことないのは確かだけれど、一方でまだまだ周辺技術およびモデル本体のチューニングで良くなる伸びしろはありそうに感じる。安いモデルでがんばるひと以外が Reddit のローカルモデル動かす勢と中国人以外にも増えてくると、裾野も広がるのになと思います。いま世の中の skill とかも Claude や GPT みたいな強いモデル前提なのが多い。弱いモデルに必要なアグレッシブな steering は、一年くらい前に流行りかけたけどモデルの高性能化で影を潜めてしまった。安弱モデル活用チップス、また復活してほしいもんです。
3.5 Flash が実用の閾値を超えたのと、潤沢にトークンが使えるのもあり、世間から一年遅れくらいで AI pilled ぽく仕事をしている。
4 つウィンドウを並べるのをやってみている。気が散る。並列度は最大が 4 だが、４つ埋めきることはなかなかできない（そんなに並列の仕事がないし、やりたくもない。）エーアイ相手にティーエルごっこ乙・・・という気持ち。
社内謎 DSL で書くちょーニッチな A/B テストの一部部門固有 ACL に使われている infra-as-code ペーパーワーク、という全然わからん代物をいじる必要があり、わからん助けてーといったらバーっと社内サーチを駆使して正解を見つけてコードを書いてくれた。あたしより仕事できるじゃん・・・この deep research 的なスキルとコードの組み合わせは純粋なコーディング仕事よりエーアイの恩恵を受けやすい。
こまめにスキルを作る、というのを試している。こういうの、チームでシェアした方がいいんだろうなと以前は思っていたが、$HOME/local/bin のシェルスクリプトみたいなもんだと思うと別にシェアしなくていいかな、という気がしてきた。めんどくせーし。一方、諸事情から社内共通 skill のひとつにパッチを送ったところ unit test (というか eval) があって感心した。こうやって品質管理すんのね。
とかなんとかやっていたら、アプリチーム内のエーアイリーダーボードで三位につけていた。tokenmaxxer じゃん。(いちおう勤務先の名誉のために書いておくとリーダーボードの上を目指すことを勧められてはいない。存在すら社内 pilled チャットで聞くまで知らなかった。)
手でコード書いてない。というか Android Studio 起動してない。
そういえば「メモリリーク見つけて」と java heap dump の入ったトレースを渡したらちょーデタラメな数字をよこしたので根拠を問いただしたところゴミ Perfetto SQL を書いていた。これを直したときは手で SQL 書きました・・・。しかし Perfetto SQL 一応知ってるんだな・・・。
しばしばエーアイが勝手にコードをアップロードする (PR みたいなもんです) ため、あるとき修正でレビューアプリ上でレビューしてしまった。やむなく「レビューしといたから見て直して」といったら直しつつ返事をしてきた。Antigravity のチャットでレビューするより無駄に人間味があり、不気味。ただ他人から見た透明度が高い利点もあることに気づいたので、しばらくはこのフローでやってみようかな。ややターンアラウンドが遅くなるが。
金曜。エーアイ氏には手の負えないコードがあり、諦めて AS 起動し半月ぶりに手書き。すると、動く動かない以前にアブストラクションがダメだな・・・などと色々発見があり進展する。手で書く大事さを肌で感じる。全てを手で書く必要はないと思うが、手で書いた方が良いものはある、しかしその判断基準はいまいち不明。これはエーアイ時代のスキルの一つなのかもしれない・・・し、過渡期の現象なのかもしれない。
最近会社のラップトップで Obsidian Android が動かなくなってしまったため、この日記（特に脊髄反射ダンプ）をかけなくなってしまった。息抜きにインターネットして見つけたものを書く場所がないとソーシャルメディアで失言したりしがちなので、失言をバッファする場所がほしい。
ということでマークダウンエディタ的なものを適当につくって Cloud Run に置く。漢字プリントアプリと違い機能強化する気がほぼゼロなのでコードもろくに読んでいない。Claude Code Opus に比べると DS4 Pro は若干危なげあるが、この手の CRUD を作るだけなら許容範囲に思える。ただし毎ターン監視する前提。AGENTS.md とかスキルを強化すればいいのでしょうが、まあおいおいやってきます。
結局 Opus のような真の frontier model が必要かどうかは、どのくらい手放しで仕事できるか、すなわちしょうもない凡ミスをしないか＋ミスに気づいて復帰できるかが重要で、それは仕事でめちゃマルチタスクさせるときには大事だが個人がマイクロマネッジする分にはそこまで重要でない。コードの質以前に、インクリメンタルに作らせながら開発中の画面を見てほしいものを考えるので、手放しにはできない。自分の開発スタイルがぜんぜん oneshot/waterfall になってない。
とか書いていてコードをあまりに見てないことを反省し、ちょっとレビューすっかという気になった。直します・・・。
直してながら思うこととして、コード (TS/JS まわりの細々した選択)は DS4 (on Pi) より Opus (on CC) が良い気がするな。素人判断だが。
あと “best practice” 類を知らない素人 (=自分) のレビューは限度があるね。特に JS だとサードパーティライブラリ持ってきて終了〜みたいのが多いが、DS4 は自分で書きがちである。Opus/CC の判断がこなれている理由の一つはおそらく裏でウェブ検索をしていることで、DS4 にはそれがない。せっかくコマンド 作ったんだから使って調べていいのよ、と背中を押すと調べるが、板についていない。
Vibe Stack とはつまり Hobby Stack のことで、私用小物アプリをホストする要素技術の意。最近はしょーもない自分専用実用品を一瞬で作れるようになったので必要性が増した。下手なスタックを選ぶと Ops が重荷になってしまう。
で、わたくし Vibe Stack は Cloud Run + Firestore + TS Server(Hono) + TS Web (Vanilla React) で行くことにしました。
ここ十年くらいは Cloud Run + Firestore + Python (Flask) + oauth-proxy + Vanilla JS だった。何がいいかというと別に良くはないが個人の都合による:
Cloud Run = Pay as you go なので個人アプリだとほぼタダ.
Firestore = 同じく Pas as you go.
Python + Flask = ウェブ素人に優しい。
oauth-proxy: 素人なのでログイン画面すら作れないんだよ!!
Vanilla JS: 素人なので React とかわかんねーんだよ! だいたい plain HTML で足りてますからッ
という状態だったのが、エーアイの力により以下のようになった:
TS (Hono): なんかいい具合に書いてくれる。ログイン画面も作ってくれる。Firestore も SDK で普通に使える。
TS (Vanilla React): なんかいい具合に同上。SSR とか必要ないのとエーアイ頼みでもなお難しすぎるので Next.js はパス。
TS は普通に JS よりいいが、以前はビルド環境とかを作るのが無理だった。今はお任せできる。言語としては static-typed python より 10x マシ。
大きな不満は Firestore で、できれば Postgres 的な SQL を書ける RDB がいいなーと思っているのだが、GCP には pay-as-you-go で安心して使える RDB がないのだった。AWS の Aurora DSQL が羨ましい。Spanner でも AlloyDB でもいいのでがんばって追従して scale-to-zero 課金のサービス作ってくださいたのむ。Cloud Run + SQLite のハックも何種類か試したが、いまいち心許せるアプローチに出会えず諦めた。
Firestore, ロックインなのはイヤだけど、単一プロジェクト内に複数データベースをつくる機能 が三年くらい前に百年の時を経て実装され、私用零細アプリ乱立用途ではかなり使えるものになった。SQL ないのは、いいです。諦めます。(いつかたのむ！)