portal shit!

Claude Code のせいで SaaS バブルが崩壊した言われるけど、 SaaS に限らす CMS のようなものもありがたみが薄れるというか、価値が落ちてしまう気がする。 WordPress とか使わんでも、コンテンツを用意したら都度都度 AI に HTML を生成させてウェブページとして公開する作業をさせたらよいわけで。抽象度の高いソフトウェアやライブラリへのニーズは生成 AI 時代も残り続けるだろうけど、具体性の高いソフトウェア（ WordPress やこのブログのベースになっている Lokka も）は相対的に価値が落ちるだろう。 WordPress とか使わなくても生成 AI が低コストであなた専用の CMS なりウェブシステムをカスタムメイドしてくれるからだ。

同じように生成 AI の興隆でジュニアレベルのソフトウェアエンジニアの仕事が失われると言われるけど、そもそもソフトウェア自体の価値が相対的に落ちると思う。

ソフトウェア開発はプログラミング言語、ライブラリ、汎用的なフレームワークを作る仕事と、それを組み合わせて特定のドメインにマッチするシステムを作る仕事に二分される。

前者は AI ではなかなか代替できないだろう。少なくともいま Claude Code を使う限りでは自分はそういう感覚を持てない。

一方で後者の仕事（ありものの技術を組み合わせてシステムを作る仕事、普通の会社に勤めるソフトウェアエンジニアはこの部分を仕事としている）は AI で代替できるだろう。すでにある技術を組み合わせてカスタマイズするところは AI が得意な領域だ。

自分の感覚としては、いまプログラミングで飯を食っている人はジュニアだろうかシニアだろうが、遅かれ早かれ生成 AI と仕事の奪い合いをしなければならない時代になると思う。ジュニアだけが割を食うわけではない。

この先生き残るには、ソフトウェア開発のなかでもより抽象度が高い部分の技術を身につけていかなければならないのではないか。社会に必要なソフトウェアエンジニアの数はずいぶん減るのではないかと思う。

Claude Code を使い始めた。いろいろやってみたことをメモ的に書いておく。

Nginx のログを集計して、日ごと、時間ごとのリクエストタイムと HTTP ステータスコードを集計するようにした。こんな感じ。

アクセスランキングとかリファラーランキングとかを集計するシェルスクリプトは以前自分で書いていて、それらのコードを参考にして Claude Code に書かせてみたらほんの 10 分くらいでいいのができあがるのでびっくりする。特にリクエストタイムの集計は中央値も出すようにしたので、自分でやってたら awk の学習で 2 ~ 3 日時間を使ったと思うので、こういうのをサクッとやれるのはマジですごい。

リクエストタイムに関して、 15 年くらい前のクックパッド社は Rails アプリでトップページのレスポンスが 200ms を切るのが目標だと言っていた。それ以来、自分のウェブサイトでもそのくらいのパフォーマンスを目指していたが、こうやったあらためて集計してみると全然 200ms を切れていないことがわかった。リクエストログのうち時間がかかっているものを抽出し、これまた Claude Code に読ませて対策を考えさせた。 Cache を適切に設定したり、コードを読んで N+1 クエリになってるところやメソッド呼び出しを変数にメモ化できていないところを見つけてきて直してもらった。おかげで平均レスポンスタイムが 1/2 ~ 1/3 になっている。

HTTP ステータスコードにもちゃんと確認したことがなかったが、集計してみると結構 500 エラーがあることがわかった。エラーログを Claude Code に与えるとサクッと直してくれた。以前は 1 日 40 ~ 50 件くらいあった 500 エラーがいまはほぼなくなった。

500 エラーの次に問題だったのが 404 エラーだ。存在しないパスへボットが絨毯爆撃のようなクローリングをしかけている。 Claude Code 先生によるとこういうアクセスは 444 ステータスコードを返して接続を切るのがサーバーに負荷をかけないということだったのでそうすることにした。 1 時間あたり 3 桁あることもあった 404 エラーが 1 桁になり、無駄に puma にリクエストが到達することがなくなった。

一昔前なら、こういうチューニングとかは専門のコンサルタント的な人を雇わないとできなかったかもしれない。そういうところに頼むと 50 万円とか 100 万円とか費用がかかっただろう。個人の趣味のブログでそういう費用を払うのは割に合わないけど、 Claude Code なら 100 ドルでそれをやってくれる。マジですごい世の中になってしまった。

このブログを動かしている Ruby を 3.1 系から 3.2 系にアップデートした。

ネックになっていたのが tantiny で、オリジナル開発者の baygeldin 氏が自分でこの gem を使わなくなったようでメンテナンスされなくなっており、 fork してなんとか Ruby 3.1 対応までできていたが、 tantiny が依存する rutie が Ruby 3.2 以上に対応できておらず、にっちもさっちもいかなくて困っていた。

そんななかリポジトリを覗いてみると、 2025 年の 11 月に新しいメンテナーが見つかって Ruby 3.x に対応したバージョンがリリースされていた。

Unicorn! · GitHub

github.com

tantiny | RubyGems.org | your community gem host

rubygems.org

最新バージョンの 0.4.2 を入れてみたところ、 Ruby と Rust のブリッジは rutie ではなく magnus を使うようになっており、問題なく動くようになった。

tantiny の新しいメンテナーが現れているのを知らずに tantiny を捨てて MySQL の FULLTEXT インデックスで代替しようかと試みたが、検索精度が低いのとパフォーマンスも劣化してしまって途方に暮れていた。このブログに書いていることは自分の脳みその 30% くらいの領域を占めているので、精度が高く高速にレスポンスを返す全文検索が使えなくなってしまうとだいぶ困る。新しいメンテナーは会社のようなので tantiny はちゃんとメンテナンスされそうだ（元 Algoria のスタッフがやってる会社みたい）。ありがたや。

Strava クローンのような機能を Claude Code と Codex を使って二日で作った。 Garmin や COROS や Apple Watch でとった FIT ファイルや GPX ファイルをアップロードすると軌跡とペースを表示してくれるやつ。ソーシャル機能やセグメント、心拍数ゾーン分析などがない簡易的な Strava みたいなやつ。ブログ記事に埋め込める機能もつけた。

アクティビティ埋め込みテスト

朝ランニング 8.9km 山700m Trail Running ・8.95 km ・2:41:28 (funct...

portalshit.net

AI エージェントやばい、 AI すごい、エンジニアいらなくなるみたいなことが盛んに言われてるけど、自分が直接開発しなくなったのであまりピンと来てなかった。本腰を入れて使ってみて AI 開発の何たるかがわかった気がする。やり方を知っているけどとにかく作業が面倒くさくてできないこと、やり方があることは知っているがやり方自体は知らないこと（勉強しないとできないこと）が、 AI があればどんどん簡単にできるようになった。時間のなさとかやる気のなさ、学習意欲のなさを補ってくれる感じ。

AI エージェント時代のエンジニア、「やり方があることは知っているがやり方自体は知らない」領域がいっぱいある人が強いと思う。「やり方があることは知っているがやり方自体は知らない」と「やり方があるかどうかもわからない」は隣り合っていて、経験が多い人ほど「やり方があるかどうかもわからない」を「やり方があることは知っているがやり方自体は知らない」領域に移してきているので AI を使った開発で有利になる。つまりおっさんエンジニアほど有利になる。

実装力は AI で差別化ポイントではなくなるので、 AI が出してくるものの善し悪しを判断できるセンスとか、これまでこれまでソフトウェア開発でハマった経験とか、そういうのも重要になる。やっぱりおっさんの方が有利。

News Picks の週刊ジョーホーで、若手ほど新しいテクノロジーで不利になるこれまでになかった時代がやってくると言ってたけど（22:11〜）、その通りだと思った。

週刊ジョーホー番組 | 【AI天才が断言】若手の仕事、もうすぐ半分が消失します - NewsPicks

加熱するAI界のトップ争い、勝ち組はどこなのか。注目すべきは、今週のダボス会議で「事実上の勝利宣言」をしたGeminiの「Google」、そしてClaudeの「アンソロピック」です。怒涛のアップデートで界隈を賑わせる両社は、なぜ勝利を確信できたのか。これまで最前線を走り続けてきたOpenAIやサム・アルトマンの立ち位置とは。ホワイトカラーの仕事を大きく変え始めた両社トップの発言から、今後の勢力図、そして私たちの仕事の変容を探ります。 ▼目次 00:00 オープニング 04:46 AIトップ2が語った「勝利の条件」 10:45 「研究者プライド」で意気投合 15:01 新卒の仕事が、遂に奪われる 20:30 Claude使いエンジニアの本音 23:31 10分でウェブサイトを自作してみた 26:07 SaaSづくりにも挑戦 29:41 AI界重鎮が、2026年を衝撃大予言 37:27 ブルーワーカー最強説は本当？ 38:52 エンディング 👆の「フォロー」ボタンを押すと番組更新時に通知が届きます ▼出演 森川潤（NewsPicks NY支局長） 後藤直義（NewsPicks編集委員／NY支局） ▼制作 デザイン：國弘朋佳／バナー・図版デザイン・撮影：狩野史帆／編集：瀧澤めぐみ、伊藤大地／制作管理：齋藤薫、井上茉優／プロデューサー：森川潤、後藤直義

npx.me

アメリカで若手エンジニアの採用を減らしているというのはむべなるかな。

ただしおっさんなら無条件で安泰というわけではなくて、「やり方があるかどうかもわからない」を「やり方があることは知っているがやり方自体は知らない」領域に移していける力は問われつづけると思うので、おっさんになっても「やり方があることは知っているがやり方自体は知らない」領域が狭い人や、この領域を広げる努力を怠っている人は市場価値がなくなっていくと思う。

2 年くらい前に ChatGPT がエンジニアなどの間で使われるようになったときに、自分のブログの記事などを突っ込んで ChatGPT と対話できるようにするのがはやった。

Scrapbox でやる例。多分一番最初の例。

自分のScrapboxをChatGPTにつないだ - 西尾泰和の外部脳

2023-03-08 ChatGPTに対する質問がこのScrapboxを参照するようにした ScrapboxのデータからOpenAI Embedding APIで埋め込みベクトルを作る クエリー文章に関連のある文書をベクトル検索で見つける その文書をOpenAI ChatGPT APIへのプロンプトに埋め込む Scrapboxを参照していない場合 >>> Kozanebaって何？ 回答できません。

scrapbox.io

はてなブログの記事でやる例。ヒトデさんの記事。

自分のはてなブログをChat GPTにつないだ - hitode909の日記

id:nishiohirokazuさん作のScrapboxの情報をChat GPTに流し込んで対話するスクリプトがおもしろそうだったので動かして遊んでみていた。 自分のScrapboxをChatGPTにつないだ - 西尾泰和のScrapbox自分のScrapboxからおすすめサウナを案内してもらえた。おもしろい。自分のはてなブログとも対話したい。 https://t.co/7L51YPVURe pic.twitter.com/ijVXEFDXGl— 趣味はマリンスポーツです (@hitode909) 2023年3月10日 自分はScrapboxよりはてなブログのほうをよく書いてるので、当然はて…

blog.sushi.money

自分も真似してやってみたかったのだけど、 embedding の方法を調べていて面倒くさくなってやめた。

最近は Dify でそういうことができるのを知ってはいたので、三連休の暇つぶしにやってみたところまぁまぁ面白いのができた。 Dify で作っているので公開もできるけど、どのくらいお金がかかるかわからないのでまずは一人で遊ぶ用にする。ChatGPT の利用料金があまり上がらないようなら一般公開してもいいかもと思ってる。

やり方をまとめるとこんな感じ。

1. 自分の ChatGPT の API トークンを入力する（すぐにメッセージクレジットが足りなくなるので）
2. 質問回答テンプレートを選んでワークフローを作る
3. ナレッジベースを作る
4. 年次に記事をまとめてナレッジベースにドキュメントとしてアップロードする

プログラミングが必要なのは 4 のステップで、このステップも ChatGPT に聞くとコードを用意してくれる（コードはとても汚い）。めっちゃ速くチャットボットが作れた。すごい世の中になってきてると思う。

自分との対話面白いのでいっぱいブログに記事を書いて、自分が死んだら子どもがこのボットに相談できるようにしておきたい。

※追記 あまりお金かからないような気がしたので公開してみる。

いろいろあって手元で docker build が通らなくなってしまったので ChatGPT に相談したら Alpine Linux はビルドが遅くなるので Debian Slim に変えた方がよいと言われてガチャガチャやった。BuildKit を使ってキャッシュせよとも言われたけど、逆にビルドにめっちゃ時間かかるようになったので BuildKit は使わずに普通にビルドしてる。 Apple Silicon の Mac で Linux で動かすように linux/arm64 でビルドしてたけどこれが遅い原因だと散々言われた。クロスプラットフォームで BuildKit のキャッシュを使うとめっちゃ遅くなるらしいので逆効果だった（半日以上ビルドしても終わらないてことがざらだった）。

Docker 、これまで Alpine ベースのイメージを使ってたせいで自前でいろいろコンパイルしたりインストールしたりしてたけど、ビルド済みのものをダウンロードしてくる運用はやっぱり楽。 Alpine 使っても最終的なイメージサイズは膨大になってたし、もっと早めに Debian ベースに変えればよかった。

ちなみにビルドが通らなくなったのは tantiny が依存する rayon という Rust のライブラリが Rust 1.8 以降でしか動かなくなったため。 tantiny は Rust 1.77 までしかサポートしてないので Rust のバージョンを 1.77 で固定していたが、このせいでビルドにこけるようになった。なので tantiny をフォークして rayon と rayon-core のバージョンを古いバージョンに固定した。

tantiny および tantivy は楽に運用できる非常に優れた全文検索ライブラリだと思うけど、 tantiny のメンテナーの人が仕事で使わなくなったそうでメンテナンスされてないのが悲しい。自分でできるならやりたいが、職業プログラマーではないし Rust わからんちんなのでどうしたもんか…。