blog
Claude Code で回す複利エンジンの設計
正直に言うと、しばらく踏み切れずにいた。noteは書けばそれなりに読まれるし、わざわざ自前のドメインを立ててまでやることか、と思っていた。……でも本当にそうか? noteに書いた記事も、別で触っていたWEBゲームも、積み上がった評価はプラットフォーム側に残るだけで、自分の場所には何も貯まっていかない。そう気づいて、そろそろ同じ場所にまとめることにした。
名前は Console Kludge。Kludge は「ガラクタでもとりあえず動くようにした技術ハック」というニュアンスの英語で、Console はゲームの方を指す。ドメインは自前の ckludge.com を使う。ゲームスタジオとして動かしている Una Studios とは、あえて別ブランドにした。同じ自分がやっていることだから一緒にしてもいいんじゃないか、とも一瞬考えたが、記事とゲームでは読みにくる人の温度が違う。無理に混ぜない方が、それぞれの積み上がり方がはっきりする。
理由は単純だ。記事とゲームを同じドメインに置けば、SEOもブランドもオーディエンスも自分の場所に貯まっていく。複利で効かせたいなら、土台は自分の下に置いた方がいいと判断した。
崩さないと決めた4つ
サーバー権威。スコアや残高や勝敗はサーバー側で再計算する。クライアントからの申告はそのまま信じない。
確定時のみ書き込み。途中経過はメモリに置くだけにして、確定したイベントだけを原子的に永続化する。
ランタイムからAI排除。AIを使うのはビルド時、記事やアセットを作る段階だけにする。実行時に叩くAPIはゼロにする。
既製部品に委譲。認証も決済も暗号もレート制限も、自前では作らない。自分で書くのはゲーム固有のロジックだけに絞る。
この4つは、このハブに置くもの全部に適用するつもりでいる。全部きれいに守れているかと聞かれると、今のところはまだ自信がない。土台を作った段階で、これから作り込むものが増えるほど、この4つを崩さずにいられるかが試される。
人がトリガーを引いて、あとは機械に任せる
記事もゲームも、書く・作るところまでは自分がやる。そこから先の検証・採点・コミットは自動で完結させたい。任せきりで大丈夫なのか、という不安がなかったわけではない。だからこそ、Claude Code のハーネスには、失敗している条件を1つ直して再採点してコミットする、というループしか回させないことにした。1回のループで直すのは1箇所だけ。まとめて直さない。範囲を絞れば、機械に任せた結果を後から追いやすい。
最初に置いたゲームはKludge Works。ガラクタを磨いて放置で稼ぐだけの軽いゲームだから、息抜きに触ってみてほしい。