調査系の LLM スキルを改良している
最近はエゴサスキル、競合調査スキルをチマチマと改良している。それぞれの存在意義は、以下のとおりだ。最近は、Weekly Limit に引っかからないように、利用モデルをスキル内で必ず明示している(それでも上限まで直ぐに達する)。
- エゴサスキル:ブログへの反応、OSS への隠れた貢献やライブラリ利用者の把握
- 競合調査スキル:類似ツールの特徴把握、Moatの有無、ポジションの取り方を把握
エゴサに関しては、昔であれば X を見て「反応があるじゃん。嬉しいわ」ぐらいのレベル感だった。最近は「gup が知らない間にパッケージマネージャに組み込まれたぞ」や「markdown が有名な OSS に利用され始めたから、互換性を維持しないとマズイぞ」のように、作者が把握しておかなければ不都合がありそうなイベントが増えた。1ヶ月に一度、スキルを使ってエゴサをして、状況を把握するようにしている。X(旧 Twitter)を見なくなった都合上、昔の知人情報も近況把握がてらにエゴサしている。ストーカーである。
競合調査スキルは、仕事でも使えるが、もっぱら私の思いつきをバッサリと切り捨てるために使っている。私が作る OSS は、基本的に類似品がある。私は思いついたことをガッと実装してしまう癖があり、リリースや紹介記事を書くタイミングで差別化に困るのだ。sqly, atago, jsonize は、まさにその典型例だ。LLM 登場前は実装力の証左として OSS リリースには一定の意味があったが、今は LLM が実装を担うので OSS を形にすることの価値は下がっただろう。OSS であっても Moat(持続的な競争優位性)は必要と考え、最近は一部のコード(例:漫画作成 CLI、ゲームエンジン、複数のゲーム)を隠している。ゲームエンジンは汎用性が高まったら、公開する可能性がある。

競合調査スキルの出力例(2026年10月17日の sqly 調査レポート)
別に OSS なんて自由に公開してもいい。しかし、私は割と作り込むし、紹介記事を何だかんだで書いてしまう。そうすると残るのは、微妙な反応を得た OSS だ。そんなものを保守するのは、結構辛い。例えば、Gleam パッケージを1ヶ月で18個作ったが、何を考えて次から次へと連作したのかが自分でも分からない。単純に、存在しないパッケージを見つけたら、実装してしまった。やはり、OSS を開発したからには皆に利用してもらいたい。このような心境の変化があって、競合調査スキルで公開可否を決めている。公開しないだけで、開発はずっと続けている。どの OSS が好意的に受け止められるかは正直読めないので、暫くすると「気にせず公開してしまえよ」というスタンスに戻すかもしれない。
開発で使うSSDの追加購入を諦めた
Go, Rust, Node, Python、Docker あたりで開発していると、ビルド時のキャッシュやゴミが溜まる。明示的に掃除していかないと、メインストレージの空きが無くなる。最近は、100% 近くストレージを使い、システムが安定稼働できない状態になる。私の環境は、SSD 2TB 2枚の併用だが、開発に使っているのは SSD 1枚分(2TB)だけである。この2TBに、Android Studio や Steam のゲームもインストールしている。そんな状態で Claude に並行開発させると、Go と Rust だけで 1TB 近くの不要データが溜まることがある。そして、システムが身動き取れなくなる。
定期的にゴミを消す仕組みを作ったり、ストレージ分散すれば、この問題は解決できる。しかし、私にとって2枚目の SSD はバックアップ用途なので、普段使いしたくない。SSD は、書き込めば書き込むほど劣化する。となると、ストレージ自体を強化したい。
Amazon で値段をチラ見したところ、Samsung 990 PRO 4TB PCIe Gen 4.0 x4 が168,667円。手が出せない金額帯だった。GPU みたいな値段をしている。1TB ですら34,980円。私の知っている価格帯から2〜3倍以上高くなっている。今の PC で使っている KIOXIA SSD 2TB が2025年11月時点では24,280円だった。さらに言えば、私が使っている PC は2025年11月時点で295,490円だったが、2026年10月時点で598,000円に値上がりしていた。

Samsung 990 PRO 4TB
出典:公式サイト(2026年10月31日取得)
円安と AI 需要が落ち着いてくれないと、庶民は PC 関係の買い物ができない。AI 需要は数年続き、半導体の生産量が需要に追いついていない状況なので、下手すると5年ぐらいは高価格帯を維持するかもしれない。もっと性能がいい PC を選択すべきだった。
コーヒーよりコーヒー飲料のカフェイン量が丁度よい
UCC ゴールドスペシャル アイスコーヒー 1000mlを1日1本ぐらいのペースで飲んでいる。以前は薄いインスタントコーヒーを飲んでいたが、UCC 製品に切り替えていた。切り替えてから寝付きが悪く、最初は「転職して無意識下でストレスを受けているのか?」と考えていた。真面目に原因を考えた結果、コーヒーのカフェインに負けているのだろうと結論づけた。

UCC ゴールドスペシャル 無糖 1000ml
出典:公式サイト(2026年10月31日取得)
UCC はディズニーランド・ディズニーシーのスポンサーらしく(紙パックに書いてあった)、パークチケットが当たるキャンペーンを展開している。応募にはレシートが必要であり、ここに食品メーカーキャンペーンの嫌な部分が全て詰まっている。レシート、商品の外箱の一部、応募シール……この辺を食品メーカーは要求する。「昭和か?」と感じてしまう。この仕組みは、敷居が高い。敷居が高いと言いつつ、同じ仕組みの丸美屋キャンペーンをせっせと応募したりするぐらいにはマメである。でも、スマホアプリで完結するような仕組みを提供していただきたい。
任天堂のゲームデバッグ方法を真似
LLM を用いて、複数のゲーム(例:ブラックジャック)を作り、どの程度の RPG が開発できるかを探っている。結論としては、ドラクエスタイル、疑似3D(例:ウィザードリィ)は満足行くレベルで再現できた。会話もアドベンチャー方式なら成立する。画像を生成 AI に作らせる場合は、ADV + 疑似3D が納得感のあるグラフィックになる。その一方で、ドット絵やアニメーションは厳しい。
LLM を使って、定性的・定量的にゲームをデバッグさせても、なかなかゲームは面白くならない。基本的に開発できる時間が限られているので、LLM エージェント同士が協調開発できるようなシステムで作り込んでおり、勝率やプレイ時間、ユーザーが面白さを感じるであろう要素(例:レアアイテムの出現頻度)をデータで出せるようにしている。ゲームエンジンも予め作成してあり、YAML でゲーム要素を制御するようにし、実装で LLM トークンを消費しないようにした。
夜中に LLM が OK 出したものをテストプレイするが、プロンプトを書くのは面倒である。そこで、任天堂のゼルダエディタを参考にして、デバッグプレイ中にバグや意見の記録を残せるようにして LLM が後日改善していく仕組みを整えた。LLM が修正を加えると、YAML をホットリロードして変更が反映される。この状態であれば、快適に修正できる。今までゲーム開発はやり方が分からなかったが、4本目となると「あぁ、こうすれば楽に開発できるんだな」というポイントが分かってきた。ただし、面白さの見極め方はまだ掴めていない。
