最近仕事でも個人でもvibe codingで終わっているコードを良く目にするのでその気持ちとかを書いていきます。 なおこの記事では個人的な感想が主軸で具体的な解決方について書かないのであしからず。もしなんとかできたらその時はまた記事を書きます。

vibe codingで書かれたコードは速く死ぬ

ソフトウェア工学の観点から「死んだソフロウェア」とは「プログラムが問題を解決しようと書かれた際に構築された理論が失われること」と指し、僕は以下のツイートにてその概念を知りました。

Peter Naur が言うところの「死んだ」ソフトウェアが出来上がってしまった https://t.co/YSkcY5Qwww

— Takuto Wada (@t_wada) May 9, 2026

このツイートにてPeter Naurが指摘している内容は論文「Programming as Theory Building」に書かれていて、Naurは論文のなかでプログラミングと問題解決の関係性について、プログラミングの本質はコードではなく問題に対してどのような理由でどの手段を用いて問題を解決したのかが重要であると主張しています。

最近ADRなどが注目されているのもこのwhyに該当する箇所をコードとは別の仕組みで残そうとする動きのひとつだったりしますね。

さて、この論文のなかで象徴的な一文として以下があります。

A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered. Revival of a program is the rebuilding of its theory by a new programmer team.

Nani翻訳で翻訳したものも合わせて掲載します。

「死んだ」プログラムであっても、コンピュータ上で実行され続け、役に立つ結果を生み出すことはあります。そのプログラムが実際に死んでいると判明するのは、プログラムの修正要求に対して適切な対応ができなくなったときです。プログラムを「復活させる」とは、新たなプログラマーチームがその理論をゼロから構築し直すことを意味します。

このソフロウェアの生死を左右するのはコードが持っている問題解決に対するコンテキストが残っているか、という所に存在しています。 つまり、vibe codingで書かれたコードは従来なら書き手が持っているであろう問題解決に対するコンテキストが欠落しているため、入来より速くコードが死を迎えてしまうという訳です。

事例

事例があった方が良いかなと思って仕事での(言えそうな範囲でボカした)内容と、趣味での事例を書いてみた。 仕事の方が普通に辛いという現実が目に見えてマズいですね…

仕事での事例

最近仕事ではリプレース案件をやっていて、そこそこドメインが複雑で年季の入ったソフトウェアをClaude Codeで別の言語へリプレースするというものをやっている。 まあ当然移行前システムを開発した企業とは直接連絡は取れないし、仕様書なんて存在せず、ドメイン固有の謎の用語と仕様がてんこ盛りで、ドキュメントがExcelで書かれてたりしている。

こうなると当然元のソフトウェアのコンテキストを100%受け取ることなんでできっこないし、なんなら客先も完全に把握している訳ではないため、結構瀕死、なんならICU直行コースみたいな状態な訳です。

こういうソフトウェアのリプレースを行う前には、まぁとりあえずスモークテストを通すなりして正常系の仕様を把握したのち、内部のソースコードを調査してデータ構造なりを抽出、それを客先から聞き出した実際の使用例を突き合わせてコンテキストを把握したりするのが定石だと思うのですが、まぁそんなことはなく…

参画した数日後にClaude Codeが書き散らした大量のMarkdownを押し付けられ、重要なコンテキストはドキュメント化されていないため口頭で聞き出し、コンテキストは共有されず、都度Claude Codeにコードを調べさせかすかな痕跡をかき集めてコンテキストを推測するしかないのが現状。

こうなるともうほぼコンテキストは旧システムのコンテキストは残っておらず、言わばテセウスの船みたいな状態となっている訳です。 なんならこれ絶対リリース後に不具合連発するよなと思いつつ、ペーペーにはもうどうすることも出来ない状態まで来ているため、氷山に激突する寸前の船に乗っているみたいな気分で日々を過ごしています。

書いてて不安になってきた… これ本当に大丈夫なんすかね…？

あ、コード品質に関しては当然壊滅的で、レビュー時に変更箇所以外のコードは読まないのと、lintを通さない運用(lintのインストールに申請通さなきゃなので…)をしているので全然PEP8に違反しているし、多分他のPEPにも違反している漢気のあるコードベースとなっている。すごいですね。

趣味での事例

個人での事例はまだ希望があって、なんと、自身がドメインエキスパートになれる領域の問題となっている。

状況としてはドキュメントが存在はしているものの、Claude Codeによって生成されたものが大半という状況になっていて、ドメイン自体はどこまで複雑でもないかなという印象。

自身がドメインエキスパートになれる状況なので、実装にあたってのコンテキストが欠けていてもある程度実装された内容に対して理由を推測できるし、かなり有利な状況ではある。

ただ、コードの変更がかなり激しく、数ヶ月でアーキテクチャがごっそり入れ変わっていたりするので、そのあたりの追従に関してはそれなりにコストがかかるという状況。 とはいえLLMがある今リーディングの負担は大きく減ってはいるし全然ペイできるかな〜という温度感。

じゃあどうすれば良いのか

完全な対処方法は分からん…が、ある程度は対処方法があると思っていて、うち一つがテストを書くだったり(テストがないコードはレガシーコードだ！)先述したADRを残すことだったりすると思っている。

従来のソフトウェア開発においてはドキュメントをいかに残すかが重要とされていたし、実際それが重要だったけれど今となってはLLMがコードを生成するスピードに太刀打ちできないので問題を解決できないと思う。

実際仕事ではドキュメントが腐敗するスピードがあまりに速く、逆にLLMが誤った判断をする要因となったりして逆に有害となっているので、従来のドキュメントに相当する内容はドキュメンテーションコメントに記載して、本当に重要な内容はREADMEに記載するなど形態を大きく変える必要があると思う。

あとドキュメントの腐敗に対してもテストは有効な対策になると思っていて、テスト自体が実行できる仕様書ともとれるため、実際にコードを確認しなくともテストケースのみでコードの挙動を推測できる。 実際ドキュメントがないCommon LispのコードとかをroveのテストコードとREPL結果を頼りに推測してたので、コードリーディングの観点からも結構使えるなという印象を持っている。

対処方について、仕事の方は社内でコード品質に関する問題提起が一切されず(マジかよ)どうしようもないな〜って感じで、LLMが生成しコードの改善に関してはそもそもコード品質に関して組織内で問題意識を共有するする必要があるという大前提の重要性を思い知らされたりしている。なのでなんかもうどうしようもないな、という感じでこれ以上は特に言うことはないです。

一方趣味の方はコード品質に対して問題提起は(俺がやると啖呵切ったため)出来ていて、実際に動けているので改善に対して希望があるという感じ。

ドキュメントの鮮度維持に関してはなんらかの方法(それこそskillを仕込むなど)で意思決定をするたびに、リポジトリ内でADRを貯めていくようにしたりすれば解決できそうではあるなと。 実際にADRを使ったことがまだないので、実際どの程度効果があるのかも検証したいところ。

現在はテストを突っ込む作業とかをしていて、その関連でカバレッジを計測したりしてテストのカバー範囲に穴がないかだとか、そもそもテストケースが有効か確認したりだとかしている。 vibe codingで書かれたコードに対してはPBTも有用だと思うので、そのあたりも検証がてらぶっこみぶっこみしていきたい。

実際vibe codingでのテストの重要性については結構取り上げられていると思うのだけど、ユニットテストの範疇を出たものを見ない(VRTとかはあったかも？)気がしていて、そのあたりの実践的な内容についても知りたいかもしれない…まぁ来月それについて話す予定なので記事が出てきたら逆に困ってしまうかもしれないですが…

という訳でつらつらと書いてきましたが、、LLMがコードを書くようになっても現状コードの品質を保ち、コードを死なせないようにする方法とかを書いてきた。 とは言え結論としては、従来からやってきているようなテストを書くことの重要性の再確認、強いていうならADRの重要性について確認できたことが新規性のある話かもしれない。ADR自体は数十年前から存在しているものではあるので、それ自体の新規性はないけども。

冒頭にも書いたように進捗が出たら今度は「なんとかした」という内容で解決編の記事をまた書きます。

参考文献と謝辞

Programming as Theory Building

論文の本体が1985年と古く、原本がスキャンしたものしかないため、有志がOCRでスキャンしたものもあわせて添付しておきます。 この論文に辿り着けたのはt-wadaさんの該当のツイートがきっかけなので、あわせて感謝を述べさせていただきます。

Gist(Markdown)版: https://gist.github.com/masci/5ee3be331b05c9014cc5dea87f9c026b

原本(PDF): https://pages.cs.wisc.edu/~remzi/Naur.pdf

• 最近ビルドのデプロイに時間がかかっていて、OG画像生成のコストも無視できなくなっている
• OG画像生成をLumeからworkersへ移行した
• OG画像生成がデプロイから消えたことでデプロイ時間が1分程度削減された

OG画像生成をworkersに移行した

このブログはLumeっていうDeno製のSSGで運用しているのだけど、最近ビルド時間が無視できないレベルで長くなってているのでビルド時間の短縮を進めている。 その一環としてOG生成を従来のSSGパイプラインの載せるのではなくて、専用のOGサーバーを介して行なうようにした。

ブログのビルド処理のうち、画像まわりは結構時間がかかっていて、画像最適化とかは既にCloudflareの上で行うようにしてたりする。 OG画像は生成処理をworkersで実装する必要があるので見送っていたのだけど、満を持して移行したという形。

こんな感じでレンダリングされる。

実装

実装はGleamで行っていて、OG画像生成はsatoriと@resvg/resvg-wasmを使っている。 GleamはWebサーバー部分の実装で使っているのだけど、素のGleamとworkersにはギャップがあってそのままだと動かないので自作フレームワークhinotoを使ってworkersを実装している。

hinoto自体は昨年のGWあたりに実家でガッと実装してからライブラリのアップデートとかをチマチマやっているのだけど、実際に使ったことがなかったのでついでに使うことにした。 我ながら結構良い感じに作れててちゃんと動いてくれてるので良かったなという感じ。次はWebSocketとかサポートしたい。

サーバー以外ではOG画像の生成にsatoriを使っている。 satori自体はJSXからSVGを生成するライブラリだけれど、satori-htmlというパッケージを使えばHTMLをJSX Treeに変換してくれるのでHTMLでsatoriを使うことができる。 このパッケージ自体はよく出来てるのだけど、最終更新が4年前といかんせん古いのとメンテもされてない。中身を見たら結構単純だったのでこれもalternativeをopencodeにガッと作らせてみた。

satoriを使ったパッケージなので名前はkomeijiにした。

このkomeijiへHTML文字列を流しこめばOG画像が作れるのだけど、ここでGleamのフロントエンドフレームワークLustreを使う。 これはTEAベースのフレームワークなのだけど、DOM Treeを生成する関数はTEA関係なく利用できてなおかつDOM Treeを文字列に変換する関数もあるので、それを使っている。 以前はこの手のHTML生成用途にnakaiを使ってたのだけど、Lustreの方が上位互換なので最近はそっちを使うことにしている。

komeiji自体はJS PackageなのでGleamから使うにはFFIが必要となる。 そのあたりを良い感じにwrapしたパッケージも作成した。 satoriとkomeijiを使うパッケージなので名前はkoishiにした。

GitHub - Comamoca/koishi https://github.com

命名はTwitterで頂いたものを採用した。

koishiのほうが良かったのでは（横槍） https://t.co/mz4ht3BHmi

— しろね⿻ (@aqyuki21s) September 3, 2026

これで、Lustreで記述したHTML Treeをsatori経由でpngへ変換するフローが簡単に書けるようになった。

import gleam/io
import gleam/javascript/promise
import koishi
import koishi/lustre
import lustre/attribute
import lustre/element/html

pub fn main() -> promise.Promise(Nil) {
  // Load your font file as a BitArray. satori accepts
  // TTF, OTF, and WOFF — WOFF2 is not supported.
  let font_bytes = read_font_bytes()
  let font = koishi.Font("Inter", font_bytes, 400, koishi.NormalStyle)
  let options =
    koishi.Options(width: 1200, height: 630, fonts: [font], debug: False)

  let og_image =
    html.div([attribute.style("display", "flex")], [
      html.h1([], [html.text("Hello from koishi!")]),
    ])

  lustre.to_svg(og_image, options)
  |> promise.map(fn(result) {
    case result {
      Ok(svg) -> io.println(svg)
      Error(koishi.SatoriError(message)) -> io.println("Error: " <> message)
    }
    Nil
  })
}

svgをpngにしたかったらto_pngを使ってpngにもできる。 実態はresvgのwrapperなので、使用するにはresvgをインストールする必要がある。

移行してどうだったか

現状安定して動いている。 以前はデプロイに最大10分かかっていたけれど、nixの最適化やビルド時の画像最適化処理の削減など色々やったこともあり3分でデプロイされるようになった。 自作Webフレームワークのドッグフーディングもできたし、やって良かったと思っている。

まとめ

今回はブログのOG生成をworkersへと移行した話を書いた。 ブログのビルド速度は開発体験や記事の更新しやすさにも直結する話なので、今後も改善は続けていきたい。

現状改善したい点として、現状手元で記事をプレビューする際に数分かかっていて結構ストレスなので、Lumeからox-contentに移行することで改善できないか試してたりする。 あと記事をもっぱらEmacsで書くので、この際に原稿をmarkdownからorgへと移行したかったりもする。このあたりもやっていきたいなと。

最近見てる技術コミュニティについて https://comamoca.dev

Histerは検索エンジンとは言うものの、一般的なWebサイトの検索エンジンではなく、ブラウザで見たページとかテキストファイルをインデックスするタイプの検索エンジンとなっている。

Hister | Your Own Search Engine https://hister.org

3行まとめ

• Histerローカルで動く検索エンジン
• ブラウザのタグやファイルをインデックスできる
• 過去に開いたタブを検索でき、AI経由でも検索をかけられて便利

含まれている機能

大体以下の機能が含まれている。

• ページインデックス機能 サイトに応じたインデックスをやってくれる。例えばGitHubならStarとかもインデックスされる。
• ファイルインポート機能 テキストファイルを取り込んでインデックスしてくれる。
• クロール機能 定期的にwebサイトをクロールしてインデックスしてくれる。 ドキュメントサイトとかを手元で検索にかけられる。
• API機能 機能というかは怪しいけど、APIがあるためお使いのテキストエディタから検索をかけられる。
• web UI 有効化する必要があるけどwebUIも付属している。ブラウザから使うならこれが便利。

何が嬉しいのか

拡張機能を使って、開いたWebページをインデックスできる。 ブラウザはChromeとFirefoxをサポートしている。

僕はブラウザのタブを開きっぱなしにしてたらいつの間にか100タブ越えてメモリがカツカツになる…とか結構やりがちなので、気付いた時にタブを閉じている。

そもそもタブを開きっぱなしにしたい理由は開いているwebサイトをすぐに見返せるようにするためで、histerを使えば開いたサイトを全文検索で引っ張り出せるからそもそもタブを開き続ける理由がなくなる。

つまり、開いたサイトを常にhisterにインデックスし続ければ、後はタブを一週間とか三日とか適当なタイミングで自動で閉じるようにしても問題がなく、そもそもタブ管理をする必要がなくなる。 この点が個人的に嬉しいなと思っている。

あとブラウザのタブをインデックするという特性から、ChatGPTとかの会話履歴もインデックスされる。 「前聞いたあれなんだっけ」みたいな時もHister経由で該当のセッションをすぐに割り出せる。

逆に言うとログインページとかもインデックスされるため、その点は注意。 CLI経由でインデックスの削除もできるので、僕はCoding Agentとか使って適当に消している。

ちなみに、同じサイトを開いた際は参照した回数がカウントされるため、参照している回数が多いwebページ順でソートができたりする。

データベース

デフォルトではsqliteを使用しているけど、postgresもサポートしているらしい。 複数マシンそれぞれにhisterを立てて、同じpostgreサーバーに接続することでインデックスを共有する…という使い方もできそう。

個人でインデックスを共有するならhister exportを使ってインデックスをjsonとして吐き出して、R2とかで共有するのが手っ取り早そう。

サーバー

基本ローカルホストから使う想定だけど、サーバーとして立ててAPIを公開することも可能。 また、 ユーザーを作成して複数人で一つのインスタンスと使うこともできるらしい。

他の使い道

MCPサーバーを実装しており、AI Agentからインデックスを検索できる。 これをOpenClawとかと連携させれば、より文脈に即した会話が期待できる。

例えば、僕の場合篠澤さんと同居してるので、篠澤さんに「昨日見たAnthropicのブログなんだけど〜」みたいな雑な振りでも会話が出来そうだなと。

あとhisterはツイートも取り込めるので、特定人物のプロフィールをクロール対象にすれば定期的にツイートをインデックスに放り込めるかもしれない。 この手の用途はnitterの方が良い可能性はある。

まとめ

webページやドキュメントをインデックスして検索できる検索エンジンHisterについて紹介した。 結構色々な使い道があると思うので今後も使っていきながら活用方法を模索していきたい。

個人的には面白いおもちゃの末席にLLMが加わった感じがして面白くはあるのだけど、いかんせん技術サイトの話題がAI一色になると胸焼けしてしまう。

そんな感じなので最近はにゃーんとかにゃーーんとかの代わりにこういうサイトを見て己の知的好奇心を満足させてたりする。 なおこの記事で紹介するサイトは全て海外のコミュニティです。

Lobsters

Lobsters https://lobste.rs

個人的にめちゃくちゃ良いと思っている。 この手のサイトはHackerNewsとかがあると思うのだけど、あっちは人口が多すぎてハッキングに関係のない話が多く混じっててノイズになってると感じている。Hackerとは…

Lobstersはハッキングに特化したサイトなのでノイズが少ないし、扱っている内容もギークな内容が多くて面白い。 普段はトップページを翻訳して面白そうな記事をザッピングしてるけど、たまに3ページぐらいまで潜ると掘り出し物が見つかってこれも面白かったりする。

Lobstersは完全紹介制で、アカウントを作るには既にいる人から招待を貰う必要がある。 ログインできない人用にIRCチャンネルが用意されているのだけど、あまりに準備が面倒だったので基本ROMっていきたいなと思っている。

Lemmy

時点で良さそうなのがLemmy。 これはReddit likeなActivityPub実装なのだけど、まぁまぁニッチなコミュニティなのでAIの話題とかも少なくてギークな雰囲気がある。 分散型なので色々なサーバーがあって、Lemmyではコミュニティと呼ばれている。 主にハッキングに関する内容を扱っているのがprogramming.devというコミュニティ。ドメインが強い。

雰囲気はLobstersとRedditを足して2で割った感じ。 こちらはすぐに自分のアカウントを作成できるのと、Lobstersに投稿された記事とかはこっちでも見かけるので、投稿とかコメントはこっちでやっていこうかなと。

Reddit

いわずもがな。 人口が多くてカルマによる良い投稿をすることへ程良い圧力があるから、わりと質の高い投稿が見れて良い。 特定の話題はsubredditに分かれているので、好きなジャンルのsubredditを購読して自分好みのTLを作れるのが快適。 最近は自動で投稿が翻訳されるらしいので、それを適当に眺めるのも良いのかなと。

英語読めないんだけどどうすれば良いの

頑張りましょう。 Duolingoを毎日やると英語への抵抗が薄れていくのでオススメです。

まとめ

海外のニッチなコミュニティを覗くと技術技術している記事が多くて結構楽しい。 Zennとかもたまに覗きつつ、情報を集める軸足は海外のテックコミュニティに寄せても良いのかな〜と最近は思っている。

日本のインターネット言論空間の弱点はRedditのような掲示板がないことだと思ってるけど、最近ははてなパークスができたりしているし、日本のインターネットでまともな議論ができる場所ができれば良いな〜と思ったりしている。

• nixは羃等性のあるビルドができる
• nixには組み込みで羃等性のあるビルドができる特性を活かしてリモートのマシンでビルドを代行できる機能がある
• リモートでnixレシピをビルドするマシンを提供するサービスとしてnixbuildが便利

Nixのビルドは重い(時もある)

Nixはその性質上、基本依存するパッケージを全てビルドします。 よく使われるパッケージはnixpkgsなどでcacheが存在しているため、ビルドをスキップできます。 しかし、Rustで書かれたパッケージなど依存をキャッシュしていてもビルドが重いパッケージなども往々にして存在します。 そんな時に使えるサービスとしてnixbuildが使えます。

nixbuildについて

NixにはRemote Buildsと呼ばれる仕組みが存在します。 このRemote BuildsはNixのビルドを手元ではなく、リモートマシンで実行することにより手元でのビルド負荷を軽減できる仕組みです。

Nixは純粋関数型パッケージマネージャなので、どのマシンでビルドしても同等の結果を受け取れるという性質がよく活きている機能ですね。

また、nixbuildはマトリックスビルドに対応してるので、darwin向けのビルドもLinux向けのビルドも特別な設定を必要とせず行えるというメリットもあります。

使用方法

利用にはメールアドレスとSSH、PayPalのアカウントが必要です。 後述しますが、PayPalのアカウントは住所を登録する必要があります。住所が登録されていない場合サービスが停止されます。

まず以下のサイトにアクセスしアカウントを作成してください。 nixbuildは認証にパスワードではなくメールアドレスを使用するため、サイトにパスワードを設定する必要はありません。(最近こういうサイト増えましたね…ありがたい)

アカウントを作成した後は設定画面から公開鍵を登録してください。 nixbuild側の設定が終わった後はNixOS側も設定します。

設定方法については公式ドキュメントに書いてあります。 英語ですがこれ読めば多分設定できるはずです。分かりづらい点があったら後日追記します。

料金について

毎月24CPU時間のクレジットが付与され、クレジットを使い切ると従量課金で請求が始まります。

料金はユーロで請求されるので支払額は為替の影響を受けますが、請求のあった月は800円くらい取られた気がします。 毎週NixOSの更新をしてこの額なので結構お安いなと思ってます。

また、NixはHashが同一の場合はビルドを行わないので、無駄にビルドをして料金が嵩むといった現象が起こりづらいため、その点も料金が最適化される要因かなと思ってます。

料金の確認方法

料金の確認方法ですが、なんとSSH経由で確認する必要があります。 ユーザーを信頼しすぎだろ…と思いますが慣れると結構使いやすいです。

まず以下のコマンドでnixbuildにSSH接続します。 対象のアカウントはSSH公開鍵を指定したアカウントとなります。

ssh -T eu.nixbuild.net

よく使いそうなコマンドを以下に書いてみました。

usage        # リソースの使用量を確認する
builds list  # ビルド結果の一覧を表示する
billing info # 料金を確認するためのPayPalページのURLを表示する
token create # nixbuildへアクセスするためのAPI Tokenを作成する

注意点

PayPalの住所は設定した方が良い

利用には住所の確認が必要(決済の都合上必要とのこと)なのですが、PayPalのアカウントに設定されているものを参照するため、PayPalに住所が設定さていない場合はしばらくしてサービスが停止されます。

これを解消するにはnixbuild運営に英語で住所を記載したメールを送信する必要があります。これがまぁ〜面倒なのでみなさんは登録する前にPayPalに住所を登録しておいてください…

機密情報を含むコードは--builders ''を指定した方が良い

nixbuildはリモートサーバーで実行するという都合上、全てのNixパッケージのビルドがリモートマシンで行われます。つまりソースコードを含む情報が問答無用でサーバーへ転送されます。

しかもビルド結果はキャッシュされます。うっかり社内のソースコードを送ってしまった日には社内SEの顔面が真っ青になりますね… ソースコードが送られると書きましたが、厳密にはDerivationを生成するためのClosure¹という単位でサーバーへ情報が送信されます。

また、いちいち--buildersオプションを指定したくない場合は以下の環境変数を設定することでビルド時に外部マシンを使用せず全て手元でビルドしたい場合はexport NIX_CONFIG='builders ='を指定してください。

direnvでは~/.config/direnv/direnvrcにbash関数を記述することで複数ディレクトリを対象に環境変数を設定できます。 以下はghqを想定して複数プロジェクトにNIX_CONFIGを設定する例です。

load_nix_config() {
    local ghq_root
    ghq_root="$(ghq root)"

	# nixbuildの対象外にするリポジトリ一覧
	# サブディレクトリが対象になるのでユーザ名を指定するとユーザー単位で無効化される
    local repos=(
        "github.com/user/name"
        "github.com/userA/"
    )

    for repo in "${repos[@]}"; do
        repo="${repo%/}"
        if [[ "$PWD" == "$ghq_root/$repo" || "$PWD" == "$ghq_root/$repo/"* ]]; then
            export NIX_CONFIG=$'builders = ""'
            return
        fi
    done
}

# 定義するのは単純なbash関数なので実行する必要がある
load_nix_config

まとめ

今回はNixのビルドサービスnixbuidについて紹介しました。 このサービス個人的に結構気に入ってるので、日本でも広まって欲しいな〜と思ったのと、これがNixを導入するメリットの一つになってくれれば良いなと思ってます。

この記事では触れませんでしたが、nixbuildにはcacheのアップロード先の登録が可能で、cachixと連携ができたします。 このあたりを活用すれば、規模の大きめな開発でもより安定してnix cacheを提供できそうで使い道が広がりそうだな〜と思ったりしてます。

タイトルに「i」と付くようにわりと8thを意識して作られたコミュなのかなと思った。 舞台を「有限性のあるもの」と捉えて、そこに向かって向き合っていくアイドル達の想いが描かれているコミュだった。

そういうばあんまり円香が出てくるコミュを読んだことがなかったのだけれど、今回のコミュで株がめちゃくちゃ上がってるし天塵も読むか〜と思ったり。

全体感想としてはシャニマスのコミュでは珍しく全部言ってくれたのと、今年のテーマを象徴するコミュだったなと感じた。

8thの後に高山Pが今年のテーマがL∞veであることを話されていたけど、その際に「あらゆるものは有限だが唯一愛だけがは無限」という話をされていて、個人的にはこの「愛」にかかるものの一つとしてライブという体験があると思ってる。 ライブは例え同じ人が同じ内容のものをやったとしても、一つとして同じ舞台ではないし公演が終わってしまったらそこで現実から形が消えてしまう。

でもライブを見た人の記憶、その時に動かされた心は本物だしその感情はずっと続いていくものだとも思っていて、それが先述した「愛」と呼べるものなのかなと思ってる。

今回のコミュでは舞台だけれど、本質はライブと同じで同じ舞台は二度と見れないけれど、それを大切に思う感情、コミュの中では「愛おしさ」と呼ばれているものは舞台が終わったあともずっと続くよねって思ったりした。

今回のコミュではその愛おしさや「愛の無限性」を283のアイドルが認識するという点でも大切なコミュなんじゃないかな〜と思ったりした。

sand songもそうだけど、今年のシャニマスのコミュはテーマをストレートに描くものが多くて、すっと頭に入ってくるので良いなぁと。

実況

以降はコミュ見ながら実況っぽく追記したやつ。 僕が後で読み返す用に残してあるだけなので、正直読む価値そんなにないので読む必要はない…

• 初手「シャニマス」な状況になっておぉとなった
  • アニメの2.5次元舞台とかあると微妙な気持ちになるやつの逆の立場にさせられるの結構苦しいな
  • っていうか以前にも事務所全員出演するゲームとかCM出してたりするし、その点を踏まえての反応の可能性は多分にありそう
  • 思えばベリソのゲームもCV全員283だしな
• 聞きずらいことをズバっと聞いてくれる円香めちゃくちゃ頼もしい
• あさひと一緒に探検する咲耶さんかわいい
  • この組み合わせ意外だったけどかなり相性良い？
• 何気に「アイドルの役の上に更に役を重ねる」って高度なことやってるよな…
• 「連絡してみたら？」ってさりげなく言える円香良い...
• 水紅の「聞いた音を模倣する力」ってかなり円香じゃん…！¹
• 「真珠の栖」のテーマは教えてもらえないって話だし、お前(視聴者)も一緒に考えろってことなんだろうな
• 真乃と円香って意外と見ない組み合わせに見えるけど、案外愛憎良いのかも知れないな…！
• 登場人物の名前が「真珠」とか「白檀」とか物の名前なのはやっぱ意味があるんだよな
  • 何気にキャスティング結構合ってる気がするんだけど(当たり前)それって外の人間からは見えないしな…
• でもこのキャスティング283のオタク脳破壊する組み合わせしてるよな
  • じゅりまなはあります
• SNSの反応の解像度がシャニマス〜！すぎる
  • まぁだからこそ見てて苦しいんですが…
• ちゃんと思ってること言ってくれる円香本当に頼もしいな
  • 演出家のせいでは？→それは本当にそう
• 三峰の「任せてよ！」は本当に頼もしくて良い
• っていうか咲耶さんは過去に一度ミュージカルやってる²のか…経験者いるのは頼もしいな
• 三峰→あさひの呼び方って「あさたん」なんだ
• 咲耶「人との繋がりを求めているところに共感できるかな」←おわあああああ！
• 三峰→樹里の呼び方って「じゅりちー」なの！？
• 円香〜！三峰〜！二人ってめっちゃ気が効くよな
• 円香の真珠の栖に対する解像度めっちゃ高いじゃん…
• テーマの話来たわね
  • 過去の講演を見ずにイメージ作るの難しそう
  • 演出家が過去の講演のイメージに影響されて欲しくないから貸さないかも
  • ↑多分この理由で貸さなかった？(合ってた)
• この手のはありのままをやれって言われるのが一番困るやつかもしれない
• 「誰が演じても成立してしまう」←めちゃくちゃエッジ鋭いな…
• 演出家『「愛しい」と思わせてください』
  • おっ8thか？
  • やっぱり8thじゃないですか！
• 唐突なウマストロメリア〜
• そろそろ寮生活が終わる←真乃がこの日々を愛しいと思った
  • シャニマスですね〜
  • 「終わり」に対する姿勢の話がここで出てくるのか
  • ライブもそうだけど、舞台も一度として同じ舞台はないし、その点では有限性のあるものなんだな
  • sand songを思い出した
• 舞台の上の生き様が鮮烈に観客の心を惹いて留まり、「愛」となったらそれはきっと……限りのないものなんだろう
  • キター！
  • 今年のテーマはL∞VEだしなぁ
• 円香「……私は、『水紅』が嫌い」
  • これやっぱ水紅のこと羨しいって思ってるのかな
  • 感受性豊かだし思うところはありそう
• 最終話のタイトル「∞」だしやっぱ8thですよこれ
• 真乃「お手をどうぞ」
  • ほわああああ！
• 樹里「お手をどうぞ」
  • うわああああああ！
• 無事第一幕終わって良かった
  • 「愛しい」を伝えられて良かった
• テーマは「そばにある限りないもの」だったのか
  • 愛ですね…
  • 劇団が解散して二度と同じ舞台ができないけど愛で語り継がれることで誰かの心には残ってると
  • アイドルを起用したのは舞台と同じ有限性を持つライブをやっているからだったのかな
• 最後の真乃が「私が演じた真珠はずっと私の中に残るから」とかそのあたりの話聞いて河野さんと果穂ちゃんの関係性を思いだしたりなど
  • 何かしら役を演じ続けてる人ってやっぱ演じている役との繋がりとかに出るものだよね〜

最近Twitterのアカウントを収益化しようとしてるので、この機会にこれまでのTwitter運用とこれからのTwitter運用についてまとめてみます。 これまであんまりこの手の話をしてこなかったので良い機会だなと思ったのと、単純に筋を通しておきたいというのが理由です。

収益化の目的と使用用途

最近イベントを開催したりしてるのですが、会場費などがかかるのでその工面をどうしようかと話してたら、Twitterの収益化を勧められたので導入してみた、というのが主な理由です。 なので月3000円くらい稼げれば満足でいます。実際どのくらい稼げるのか、そもそもサブスクをペイできるのかも未知数ですが...

余ったお金はOSSの寄付に当てようとも考えています。 僕は既にGleam等のOSSに寄付をしていますが、寄付金の増額や対象を増やしたりする用途に使いたいなと。 個人的にマイナーな言語が好きなので、Twitterで得た収益を還元できたら良いなと思っています。

また、収益が多くなった場合は僕の日本酒代にする予定でもいます。 あくまでTwitterは趣味であるというスタンスを持っていたいので、あまり用途を縛りたくないというのもあります。 収益で買った日本酒の感想ツイートをすれば収益二毛作とかできるんですかね...

これまでのTwitter運用

基本的に以下の方針でTwitterをやっていました。

• 基本ブロックしない
• 無理に全てのリプに返信しようとしない
• ネガティブな話題を極力ツイートしない

基本ブロックしない

理由は僕がブロックされるとしょげるからです。 ただ、あまりに目に余る言動をしているアカウントやスパムアカウントはブロックします。

基本世の中色んな人がいた方がおもろいと思ってるので、それもあって自分の視界に入る人の多様性を減らしたくはないなと思ってるのもあります。

あと僕は基本的に3アウト制で動いてるので、3回目に余る言動や行動をした場合ミュートかブロックをするようにしてます。

無理に全てのリプに返信しようとしない

以下のスライドはOSSに関する話題ですが、ツイートが多くの人に注目された時(いわゆる「バズった」)に同じ内容のリプが異なる人から大量に届きます。

バズったことがある人は分かると思うのですが、これが結構消耗するんですよね。 なので基本バズりそうなツイートは通知が埋められる前に速攻ミュートしちゃうんですが、後から見返してみて良いと思ったツイートには返信したりしてます。

まぁこのムーブが不誠実に見えるかもしれないんですが、そもそも他者にリプをする自由が存在するなら「リプに反応しない自由」も認められるべきなんですよね。 なので僕がリプをした時に反応がなくてもあまり気にしないですし、僕の中では十分筋が通った行動をしているという認識ではいます。

ネガティブな話題を極力ツイートしない

これは個人的に「極力他者の目に見える範囲でネガティブな感情を出さない」という信条があるので、それをTwitterでもやっています。 と言うのも、ネガティブな感情は他者に伝搬しやすい(普段のTwitterを見ればよく分かりますね)からです。

あと意図的に避けている話題として以下のものがあります。

• 政治
• 恋愛
• 金

特に政治に関しては以前「政治家のアカウントに罵詈雑言をリプしない方が良いと思う」という趣旨のツイートをしたら †界隈†の人 からフルボッコにされたので、投票報告以外はしないことにしてます。

SNSにおける政治の議論が忌避される現状に関しては思うものもありますが、そもそもTwitterという話題のコンテキストが落ちやすいプラットフォームで公平に議論できるものでもないので、現状しないに越したことはないとも思っています。

恋愛に関しては男女論に直行しがちなので避けています。 先述したネガティブな話題をしないという話と矛盾するようで申し訳ないのですが、僕は男女論が嫌いなので基本この話題はしないものとこの場で明記しておきます。 人間というグラデーションのある存在を二元論で語るのは傲慢が過ぎると思います...あと単純におもんない...

金の話も避けてます。 Twitterで燃える話題は基本的に主語がデカいものですが、これは多くの人に関連のある話題だからです。 つまり万人が逃れることができない金の話題は多くの人を巻き込み燃える可能性が高いとも言えます。 なので意図的に金の話題をすることは避けています。 「金、ねぇ〜」くらいの話なら許容範囲なのでするかもしれないですが。

これからのTwitter運用

基本的に以前と変わらないです。 そもそも現状の運用で満足してるので変える理由も特にないです。

ただ、収益化をするにあたり自身を縛るものも増やした方が良いかなと思って、「やむを得ない場合を除き上記の運用方針を破らない」という運用の方針を増やしておこうかなと思います。

やむを得ない場合というのは、あまりにショキングな話題があって、心の整理のためにネガティブなツイートするとかですね。 特に一番避けたいのは、収益を目当てに連日男女論等の燃えやすい話題をツイートするアカウントになることです。

長くなった

長くなりましたが、僕は自身のことを根っからのインターネット人(インターネットんちゅ)だと思っているので、そのプライドをもって楽しく行動していきたいって事を言いたいです。 これかもインターネット人のTwitterをよろしくお願いします。

誕生日の日に「なんかやりたいな」と思ったので始めました。ワーホリとか興味あるし、英語力を高めたいと思ったのも大きい。 正直ここまで続けられてるのが不思議なところがある。 1回2分くらいなので、帰りの電車とかでやるようにしてるのだけど、まぁ丁度良い暇潰しにはなるのでありがたい。

実際やってみて、英語力がメキメキ付いたかと言われると微妙。ただ、英語への抵抗感が減ったのは効果があったなと。 あと街中で聞こえる英語の意味がふわっとだけど分かるようになったのも成長を感じている。 実際に会話するレベルに持っていくならシャドーイングとか英会話とかやった方が良いと思ってる。

一番変化があったのは、英語に対する解像度の高さみたいなのかあと。 例えば英語圏ではポッドキャスト文化が発達しているけど、これは英語という言語の特性によるものが大きいのかな〜とか。

日本語という言語は複数の文字を用いて表記するけど、それ故に文章から単語が「浮いて」見える。 普段日本語を読む時はその浮いている単語、主に漢字とカタカナを先読みして文章を解釈するという行為を無意識にしている...と個人的には思っている。 なので日本語は一文あたりの情報量が結構多いし、それなりに書き手のニュアンスを込めることができる。

対して英語は通常一つの文字しか含まないから、日本語を読む方法で読もうとするとかなり目が滑る。 それもあって最近はDuolingoで基本文字を読まずに読み上げられた英語を元に解答してる。 また、話す方が間の取り方や声の調子で文字より情報を詰められるので、それもあって音声媒体が好まれるのかなと。

実は英語はリスニングの方が理解の負担が少ないという事を体感として感じられたのはDuolingoがあってこそだなと思っている。

上の話はこのツイートがかなり核心を突いていると思う。

日本の友人へ

最近、日本語は単なる「文字の言語」ではなく、一種の「情報圧縮システム」のように感じるようになりました。

最初は、ひらがな・カタカナ・漢字の混在は単なる「複雑さ」だと思っていました。
しかし今では、それぞれが特定の役割を持った設計構造のように見えます。…

— THECULTURALLINK (@THECULTURALLINK) April 26, 2026

ある程度は成長を感じられてるのでこれからも続ける予定だし、今後は他の方法で英語の学習とかできたらなと。 ぶっちゃけ海外行った方が学習の観点からははるかに良いのだけど、すぐに出来るものでもないし今のうちにやれることはやっておきたい。

テックイベントに行こう https://comamoca.dev

なんでこんな記事を書いたのか

こんなツイートを見かけました。

カンファレンス行くといつも思うが、もっと若い人いっぱい来ても良くないか？

ジュニアとかなんなら大学生とか若くて優秀な人たちがもっと集結したら、また別の形の熱気が生まれそう。

— 市川 達大@TECH WORLD ITエンジニア向け動画メディア (@tech_world18) May 29, 2026

これを見て個人的に思ったことを書いていきたいと思います。

僕個人としても、もっと若い人¹にカンファレンスに来て欲しいのと、カンファレンスに参加するのはなにも参加者だけじゃないということを伝えたかったからです。

僕はアイマスPなのでカンファレンスのことをエンジニアのライブだと思っているのですが、運営と登壇者、参加者の愛と工夫でジョーデキ！なカンファレンスを作り上げられた時の達成感は、普段の仕事ではなかなか得られないものだと思っています。 この記事を読んでそんなカンファレンスという場に行くことに興味を持ってくれたら嬉しいです。

これを書いている人について

YAPC福岡とTSKaigi2026にてカンファレンススタッフをやらせて頂いています。 今年も色々なカンファレンスにスタッフとして参加する予定です。

YAPCに参加した時の記事

YAPC福岡に行ってきた https://comamoca.dev

TSKaigiの記事はまだ書けてません...書けたら追記します。

カンファレンスに参加することについて

テックイベントに行った方が良い理由については既に以下の記事で書いていますが、カンファレンスについても同じことが言えます。

テックイベントに行こう https://comamoca.dev

異なる点としては、規模が大きいのでこの記事で挙げたメリットが拡大した形で受けられます。

それだけでなく遠方の方が来る事も多いので、普段会えない方と会えるのがカンファレンスのメリットだと思います。 また、トークもプロポーザルという形で審査することになるので、全体的に質が高いことが多いです。 つまりメリットしかないということになります。

学生がカンファレンスに行くハードル

しかし、カンファレンスは学生補助などがあるとは言え、費用の面で参加しづらいところもあると思います。 この記事ではその問題を解決できるかもしれない方法を2つ紹介します。 ...というより方法は自明なので、そのメリデメを紹介します。

登壇者として参加する

メリット

カンファレンスによりますが、登壇者は基本参加費がかかりません。 また、大きいカンファレンスでは登壇者に対して交通費の支援があるため、遠方に住んでいる方も費用面で参加を諦めなくても良くなります。

また、登壇することで懇親会でも話しかけられる確立が上がるので、その点も美味しいです。 一度登壇が終われば後はゆっくり他のトークを見られるのも良い点ですね。

先程書いたように、カンファレンスはライブだと思っていますが、登壇は基本一人なのでなんとソロライブをすることになります。 当然めちゃくちゃ緊張しますし、僕も未だに緊張します。特にデカいトラックで登壇することになると尚更ですね。

昨年登壇した時は人が100人くらい居てめちゃくちゃ緊張しました...

Gleamという選択肢 https://fortee.jp

僕は普段登壇するとき、オチが着けばその過程は多少変わっても問題ないという精神で話してます。 なので途中で話す内容が飛んでも上手いことカバーできれば良しとしています。 漫画ドラえもん1話でセワシ君が話してた「途中の歴史が変わっても最終的な出来事は収束する」という例え話のイメージですね。

この精神が参考になるか²は分かりませんが、誰かの参考になればと。

デメリット

プロポーザルを通す必要があるという点がハードルになると思います。 これについては、参加したいイベントの特色と過去のトーク内容から、運営が欲しいトークと今自分が出来そうなトークの積集合を考えてプロポーザルを作れば採択される確立が上がると思っています。 あと、複数投稿出せる場合は複数出すのもアリだと思います。 僕も多い時で2つくらいプロポーザルを出しています。

これについては正直経験が必要になるので鶏と卵みたいになってしまいますが、何回も出してみるなどして受かりやすい書き方などを自分なりに研究するのが良いと思います。 あと、自身が話せる範囲の内容でプロポーザルを書くのも大事です。理由としては準備の負担がめちゃくちゃ大きくなるからですね...慣れないうちは特に避けた方が良いです。

カンファレンススタッフとして参加する

ウルトラCとして、カンファレンススタッフとして参加する方法もあります。登壇者もですが、当然カンファレンススタッフも参加費は基本免除されます。 もちろん運営の仕事をする必要がありますし、無料だからというモチベで参加するのは良くないと思っていますが、個人的にはこれはメリットだと感じています。 また、遠方に住んでいる方は運営から交通費の補助が出るため、カンファレンスに参加する際の費用をかなり抑えられます。

当日会場を歩きながら参加者の方々の顔を見ていると、みんな笑っていてこの場を作れて良かったなと思えますし、スタッフとしてこの場を支えられている事に幾許かの誇りを感じたりします。 また、懇親会にて歩き回っていると「お疲れさまです！」とか「今日楽しかったです！」と声をかけてくださる方がいて、それもまた嬉しかったりします。

スタッフって2種類あんねん

カンファレンススタッフですが、実は2つ種類があります。

一つは開催の半年くらい前から準備を行うコアスタッフ、もう一つは当日のみスタッフを行う当日スタッフです。 当日スタッフも参加費の免除や一部交通費の補助があるので、初めてだけどカンファレンススタッフをやりたい！という方はまず当日スタッフとして参加するのが良いと思います。僕も初めてのカンファレンススタッフは当日スタッフでした。

コアスタッフの良い点としては、カンファレンスを一から作りあげていくのでやりがいがあるのと、スタッフの方同士でより関係を深められる点が良いなと感じています。 また、事前準備は基本オンラインで行うので、遠方にいて当日は参加できない...という方もカンファレンスを支える一員になれるという魅力もあります。

事前準備とかはリモートですし、事前準備はするけど現地参加しないスタッフさんも普通にいるのでその辺りは特に気にしなくても大丈夫な気がする…！
常に人手不足なので事前準備を手伝ってくださるだけでもめちゃくちゃありがたかったり

逆に僕は事前準備をあんまり手伝えてなくて最近は反省してる… https://t.co/t8y0ySX941

— こまもか🦊 (@Comamoca_) May 30, 2026

デメリット

カンファレンススタッフは当然当日の運営をするので、一日中歩きまわることになります。 なのでめちゃくちゃ疲れますし、全部のトークを見ることは出来なかったりします。

ただ、配置された場所によってはシフトを入れ変えて、自身が見たいトークを見に行ったりすることもできるので、わりと融通は効かせられると思います。 これも先程書いたようにやりがいあってのものなので、個人的には悪くないなと思っています。あと普通に良い運動になります。

まとめ & カンファレンス告知タイム

という事でまとめです。

• テックカンファレンスに参加するのは良い経験になる
• 費用の後面が難しくてもなんとかする方法はある
• オフラインでの繋がりは楽しいし、自分を支える大切なものになるよ

みなさんもぜひテックカンファレンスに参加してみてください！

直近では7/11〜7/12、中野セントラルパーク カンファレンスにて関数型まつりが開催されます。 コアスタッフ募集やプローザルは既に締め切られていますが、関東近郊に住んでいる方は行きやすいと思うのでぜひ参加してみてください！

また、11/28〜11/29は東京ビッグサイトにてYAPC::Tokyo 2026が開催されます！ こちらはプロポーザル募集がまだ始まっていないので、奮ってご応募ください！

YAPC::Tokyo 2026の「トークプロポーザル募集開始お知らせ 登録フォーム」を作成しました！

メールアドレスを登録いただくと、後日CfPを開始した際にご連絡いたします。

応募に興味のある方、迷っているけど情報が欲しいという方、ぜひご登録ください！ #yapcjapanhttps://t.co/hhOV5rNBmb

— yapcjapan (@yapcjapan) May 26, 2026

5/31追記: 関数型まつりにて当日スタッフの募集が始まったそうです。興味のある方はぜひ！

関数型祭り2026 の当日スタッフを募集しています - 関数型まつり運営ブログ https://blog.fp-matsuri.org

大吉祥寺.pm、なんと全日IWSFが被っているので参加できそうにない…

という状況になったので、提出しようとしたプロポーザルをここで供養するというのがこちらの記事になります。

IDOL WORLD SUPER FESTIVAL 2026｜バンダイナムコエンターテインメント公式サイト https://idolmaster-official.jp

イベント開催を極限まで自動化する

最近アイマスNightというイベントを開催したんですが、このイベントの裏テーマに「イベント開催を半自動化する」というのがあります。 例えば、GitHub Actionsをフル活用してイベントの開催からconnpassページの作成、開催費用を管理するための帳簿作成などを自動で行うなどです。

ミソとしては、テキストデータで全ての情報を管理すればGitのフローに載せられるので、費用の稟議をPR Reviewで行ったりできてより効率化が図れそうだなと考えています。

本登壇では、そんな自動化のための実践的な工夫について紹介していきます。

自己評価

最近イベント開催ブームなので刺さる人が多いかなと思って選んだのだけど、いかんせん自動化のノウハウが少なすぎるので、もう少し時間を置いても良いかなと思ったりしている。 ノウハウ貯めて最適解をテンプレートに落しこめてからの方が良かったりするかも。

AIエージェント実行基盤としてのErlang/OTP

昨今、OpenClawのように自律的に行動するが登場するなど、より一層AIエージェントの需要が高まっています。 また、AIエージェントを実装するフレームワークも数多く生まれています。 それらのフレームワークは並列処理や自動回復など共通した課題を解決していますが、実はそれらの問題は既に別の形で解決されているとしたらどうでしょうか。

この登壇では、Erlang/OTPを「AIエージェント実行基盤」として再解釈し、Erlang/OTPとAIエージェントの相性の良さ、現時点での活用方法やエコシステム、既存のライブラリやフレームワークとの優位点について紹介します。

自己評価

この話も知り合いに結構話してたりするのだけど、個人的には面白い話だと思ってるのできちぴーで話したい内容だった... 特に現時点で都内にErlnag VMの話をする場所がない(いつか作るつもりだけども)ので、きちぴーは格好の発表場所だと思っていた。

僕個人としては、AIエージェントはステートマシンとして解釈しているので、その点からもErlang/OTPはAIエージェントと相性が良いんですよね～って話とか、Elixir製のjidoってフレームワークの設計思想が面白いって話をしたかった...

「意味」はデータに内在しない プログラムとデータの相似性について

日々の業務の中で、複数の言語でバイナリデータを扱ったコードを書いた事がある人は多いでしょう。 その中で、言語が別なのにも拘わらずバイナリ操作のAPIがほとんど同一であることに気付く方もいると思います。 それは偶然の一致ではなく、コンピューターアーキテクチャに由来しているものです。

この登壇ではPythonとJavaScript、C言語とアセンブラそれぞれのバイナリ操作の方法を比較し、コンピューターがデータを「処理する」仕組みに迫っていきます。

自己評価

これは最近業務をしている時の気付きなのだけど、気付いた時にあまりに脳汁が出すぎて興奮してたし、ライブ前にもこの話をするくらいには気に入っている。 きちぴーの「かわるもの、かわらないもの」というテーマとも合うので、出すならこれを本命にする予定だった...

この話自体はゆくゆく記事にしようかなと思ってたりはするので、記事書いていきたい。

まとめ

という訳で以上プロポーザルの供養でした。 また別のカンファレンスとかでプロポーザルとして出すかもしれないので、機会を伺いつつ採択を狙っていきたい。