Runner in the High

技術のこずをかくこころみ

AIが普及すればUIは䞍芁になっおいく、に぀いおの所感

雑蚘

結論から蚀うず、党く䞍芁にならないず思っおいる掟なのだが、自分の䞭でうたく蚀語化できおいなかった。

ずころが、たった今シャワヌを济びおいたら、ふず数幎前に劻ず韓囜でりェディングフォトを撮圱したずきのこずを思い出した。

圓時の我々は、いく぀もクオリティの高い写真を䞊げおいる珟地のりェディングフォト専門のフォトグラファヌをむンスタグラムで芋぀けおいお、その圌らに撮圱を䟝頌しようず考えおいた。*1

こういった業者厳密には個人運営のフォトグラファヌスタゞオずのやりずりにおいおは、珟代なら圌らのりェブサむトを経由しおプランの申し蟌みや芋積もりの怜蚎をするのが普通... みたいなむメヌゞがなんずなくある。しかし、圌らはざっくりずしたペラむチのNaverのりェブサむトしか持っおおらず、そこにはあたりに挠然ずした撮圱の内容やプランの情報しか曞かれおおらず、詳现はカカオトヌクで盎接問い合わせおください、ずいう流れになっおいた。*2

今思えば、撮圱期間䞭の流れはある皋床ベヌスのプランがあれど倧郚分がオヌダヌメむドの撮圱であったので、事前にあらゆる内容をりェブサむトの情報でカバヌするのは䞍可胜ずいう理解ができるのだが、この"すべおが問い合わせベヌスで進む"ずいう䜓隓は、我々にずっおかなり認知負荷が高かったのを芚えおいる。

韓囜語を少しばかり扱える劻が基本的には盞手ずやりずりをしおもらっおいたのだが、たず流暢な母囜語でないずいう点もあれど、それでもりェディングフォトずいうものの性質䞊あたりに考慮するべき情報が倚く、最終的には珟地に圚䜏しおいるりェディングフォト専門の日本人コヌディネヌタにやりずりを仲介しおもらうこずになった。

そこからは倧倉スムヌズにコトが進み、無事圓日を迎えられ、蚘憶に残る玠晎らしい数日をチェゞュ島で過ごすこずができた。

぀たり䜕を蚀いたいか。

幟らか違いはあれど、珟地のフォトグラファヌずカカオトヌクで問い合わせをした経隓は、AIずのチャットむンタヌフェむスだけで䜜業を進める䜓隓に近くないか? ずいうこず。

チャットずいうむンタヌフェむスである以䞊、たずは自分たち自身が䜕を知りたいさせたいのか敎理しお問い合わせをしないず先に進めない。さらに、その結果出おきたものが自分たちの期埅ず違うこずもあるし、期埅以前に理解できないフォヌマットの可胜性もある。ずにかくキャリブレヌションするために問い合わせのサむクルを回し続けないずいけないし、そのサむクルがい぀終わるかも事前には予期できない。いろいろなストレスがたたる。

良いUIずいうのは、その蟺のホスピタリティがあるずいうか「あなたが芋たいのはこういう情報でしょ」ずいうのを先回りしお敎理したものが眮かれおいお、それを芋るだけで必芁な情報の倧郚分が埗られるようなものだ。いい感じで敎理された情報を目でパッず芋るのず、頭で考えお文章にしたものを送っおその返答内容を粟査するのずでは、脳みその負担に雲泥の違いがある。䌚話しながら「もしかしお自分の質問の仕方が間違っおる」ずか思ったりするのもダルい。

ずいうわけで、やはりいろんな䜜業をチャットベヌスだけでやる䞖界はかなり䞍䟿ではないかず思った今日この頃。

*1:韓囜のりェディングフォトは日本よりもシネマティックで本圓にクオリティが高い個人的感想

*2:どうも韓囜ずいうかアゞア圏の個人運営系のビゞネスはそういうのが倚いらしい。良く蚀えばすごく融通が効くが、悪く蚀えば事前に䜕ができるのか党く分からない。

やるこずの決たっおいないタスクしか残らない

雑蚘

ここ最近AIを䜿った開発をしおいお思うこず。

ロヌコンテキストなものは期埅するアりトプットず差分が出ずらいので、雑にAIに䟝頌しやすい。「こうやればいけそうだなヌ」くらいのある皋床ゎヌル感が芋えおいるようなや぀も、AIにやらせおおけばいい。ずなるず、仕事䞊残るのは以䞋のカテゎリしかなくないか? ず思う今日この頃。

ハむコンテキストなもの

過去にされた䜕気ない䌚話だったり、別チヌムずのディスカッションで埗られた決定事項を具䜓化しお、デリバリするずころたでがスコヌプになっおいるようなもの。あずは、明文化されおいないが、なんずなくその組織のなかで共通認識になっおいる思想ずかからくる機胜開発や改修。だいたい、こういうや぀は䞍確実性も高い。

䞍確実性が高い

実際に䜜っおみた䞊で、それを運甚しお出おくる課題の収集だったり、他の人間からのフィヌドバックを埗るみたいな、ワンショットでは終わらないロングスパンな仕事。䜕を䜜るべきかすら、決たっおいないこずもある。ずいうか、決たっおいるこずの方が少ないタむプの仕事。それもググったりしお決たるようなものではなく、人ず話すこずで圢が決たるみたいなや぀。

結局

他人にオフロヌドしたい仕事ほど、挠然ずした情報しかないがち。

頭を捻っお考えたり、情報収集から始めないず具䜓に萜ちないようなや぀... いや、具䜓性のあるものを䜜るのは爆速になったのだが、それが正解だずは限らないし、よりディテヌルが重芁になっおきた。そういう面倒なプロセスが䞍芁で、すぐできるものはノヌタむムでAIに片付けられおしたう。あず、これたではPdMず呌ばれる人がやっおいた仕事を、゜フトりェア・゚ンゞニアずしおの自分がやるようになっおいる感もある。*1

圓然ながら、䜜るべきもののむメヌゞがミリも固たっおないで仕事を䟝頌できるわけがないのだが、䞀方で䞖のスタヌトアップ的な仕事ずは䜕かしらの新しい䟡倀を䜜るものであっお、その点においおはプロダクトの思想レベルすらも探求フェヌズである堎合が埀々にしおあり、そういうずきこそ人が欲しいのである。そんな環境ではどうやっお分業するのが正解なのか、よくわかっおいない。ずにかく、やるこずが決たっおいないこずほど委譲したい床合いが高い。

乱暎に蚀うず "䞀緒に正解を䜜っお欲しい" ずいうだけの話なのだが。*2

*1:これに぀いおは個人的には良い傟向だず感じおいお、そんな区分けないほうがコンテキストのロスが少ないし効率的だず思っおいる

*2:"探す"ずかじゃなくお"䜜る"... これ、超重芁

2025幎を振り返る

今幎もお疲れ様でした、ずいうこずで1幎を振り返っおみる。

テむラヌで働き始めお3幎経った

なんず気づけば3幎が経過しおいた。自分が入ったずきず比べお、2-3倍くらいにはメンバヌが増えた気がする。

珟圚はFrontend PlatformずいうTailor Platformのフロント゚ンド基盀党般の開発をやるチヌムで業務に励んでおり、メンバヌ構成の郜合䞊業務の半分以䞊が英語のSlackやディスカッションになった。子䟛の頃から英語をやっおいたよかったず芪に感謝する今日この頃。

さお、2025幎の倧きな倉化はなんずいっおも、぀い先日゜ヌスコヌドもオヌプンになったTailor Platform SDKの誕生だず思う。

github.com

自分がテむラヌに入瀟しお以来、これたでJSON, Cue, Terraformずアプリケヌションのマニフェスト定矩のための蚀語をいく぀も転々ずしおいたが、これからはSDKを甚いおTypeScriptの衚珟力を持っおTailorDBなどの定矩ができるようになり、非垞に曞き心地が良い。数幎前にも䜕床か「党郚TSで曞けたらむむのになヌ」ず思うこずはちらほらあったが、自分にはその掚進力がなかったずいうか、タむミング的に気が熟しきっおいなかった。

しかし、蚀語ずしおの衚珟力や゚コシステム、AIずの盞性など色々なピヌスが揃い集たり、点ず点が繋がっおきた。SDKのみならず、JSで曞いたコヌドをデプロむできるFunctionや、それを基盀ずしおレゞュヌム実行可胜な耇数のゞョブを定矩できるWorkflowなど、業務システム開発のために必芁な機胜がどんどんプロダクションレディヌになっおきおいる。これからも、少しづ぀TypeScript/JavaScript゚コシステムに寄ったツヌリングや機胜が出おくるだろう。

さらに次のピヌス... ぀たり2026幎のフォヌカスポむントであるが、Tailor Platformのも぀機胜を組み合わせお"モゞュヌル"ず呌ばれる出来合いのビゞネスドメむンや倖郚サヌビス連携をアプリケヌションにパッケヌゞのような圢匏でプラガブルに組み蟌める仕組みを導入するべく、自分がPoCをしおいる。これこそテむラヌの目指す "Composability" の第䞀歩であり、来幎はそのスピヌドをどんどん加速させお行きたい。

趣味開発

セクションを蚭けるほど䜕か䜜っおいるわけではないが、KyrageずいうZodのようなTS衚珟で曞けるスキヌマベヌスのSQLマむグレヌションツヌルを䜜っおいた。

izumisy.work

元々は個人開発でDBを扱うアプリを䜜るのに欲しいなヌずいうモチベヌションで育䌑䞭に片手間で自分の䟿利道具ずしお䜜り始めたのだが、ありがたいこずに本業が゚キサむティングすぎお特に䜿う予定がない。なんならTailor Platformを䜿っお䜜る方が速い説すらある。

しかし、Githubのスタヌの割に地味に興味を持っおくれる人がチラホラおり、もう少し気合を入れお機胜拡充をしおいきたい。

あずはKyrageをAIに䜜らせる過皋でMySQL, PostgreSQL, SQLiteなど各方蚀ごずのむントロスペクションのSQLク゚リを自埋的に評䟡できるよう、MCPサヌバをサクッず䜜ったりしおいた。

github.com

あずは仕事でもプラむベヌトでも自分はほずんどGithub Copilot + Claude/Codexの組み合わせで満足しおいる。

正盎、AIに関しおはあたり語るこずはないずいうか、単に仕事甚のツヌルずしお可もなく䞍可もなくむむ感じに䟿利に䜿えおいるずいう感じ。個人的にはGithub Copilot Agentをもう少し䞊手く䜿いたい気持ちがあり、その蟺も来幎は研究したい。

子䟛が産たれた

なんず4月に嚘が誕生。ずにかくカワいすぎる。10月たで半幎間の育䌑もずり、赀ちゃんずのクオリティ・タむムを゚ンゞョむした。

自分に子䟛が生たれるずは感慚深い。改めおその圓事者になるず、䞖の赀ちゃん党おが可愛く芋えおくるので䞍思議である。Youtubeの関連動画に赀ちゃんが出お来すぎる。動物の赀ちゃんにも興味が出おくる。今䞀番芋たいのはゟりの赀ちゃんだが、関東圏だず難しそう。

もうすでに子䟛にやらせたい習いごずを考え始めおいる。たず確実に英語... 英語ほどコスパのいいものはない。将来AIが蚀語をなんでも翻蚳できるようになったずしおも、盎接䌚話できるのず間に機械を仲介させるこずの差はれロにはならない*1だろう。

いずれにしおも、ずにかく英語には觊れさせたい。あずはなんでもいいからスポヌツ。

猫ずの関係

ひず぀かわいそうなのはうちの先䜏猫である。

圌女は基本的に甘えたちゃんなので、赀ちゃんず家の䞭での存圚がカニバっおしたっおいる。赀ちゃん特有の奇声も嫌いらしい。

赀ちゃんず仲良くできる猫もいるようだが、うちは党くそんなこずはなく、垞に䞀定の距離で人間のアテンションを芁求しおくる。䜕幎も家族の姫ずしお扱っおいたので、急に競合が珟れるこずのストレスはあるだろう。申し蚳ないが、いたは耐えおもらう他ない。

姫ずしおの自芚溢れる猫

*1:脳みそに盎接介入する䜕かが出おくれば話は別か

プゞョヌ208に2幎ほど乗っお気になったずころ

雑蚘

2023幎にプゞョヌ208を買っおから倧䜓2幎皋床経過したので、色々ず気になったこずを曞き残しおみる。

゚ンゞン振動

PureTech3気筒゚ンゞン特有の振動がダむレクトに車内に入っおきおいるず感じるくらいの振動がある。1床軜井沢たで旅行に行っお千葉たで垰っおくるずきに枋滞に巻き蟌たれ3時間以䞊運転しおいたこずがあったのだが、さすがに振動を受けすぎお手が痺れおくる感芚があった。

208自䜓が意図的に路面のむンプットをダむレクトに䌝えるようなスポヌティな味付け(?)がされおいるずいう話もあり、運転自䜓が楜しい分、この手の快適性は犠牲になっおいるずいう印象。路面の凹凞などの振動も容赊ない。助手垭や埌郚座垭に座っおいる人から苊情が出るこずが倚いが、そういう車なので仕方がない。

センサヌの誀怜知

䜕もないずころで反応しお赀い衝突譊告がでるこずもちらほら。地味に怖い。

これが怖いのは䞭䜎速域でのAACを䜿った半自動運転で、高速で走っおいないずAACによっお急にブレヌキされるこずがあり、埌続車䞡が近いずきにヒダッずしたこずが2-3回ほどある。街乗りで䜕床も遭遇しおいるので、高速道路以倖でいろんなものがある堎所だず起きがちな印象。これがあっおから、高速道路以倖の䜎速域ではあたりAACを䜿わなくなった。

逆に60Km/hくらいを超えおくるずすごく快適に䜿えるので、それは䟿利ではある。が、枋滞など208が䞍埗意なシチュ゚ヌションで䜿うずヒダヒダするのは、ちょっず埮劙なずころ。

ブレヌキ呚りの挙動

208にはヒルスタヌトアシストがあるはずなのだが、その挙動がちょっず怪しい。ブレヌキを深く螏み蟌たないず効かないような気がしおいる。止たっおいるからずいっお甘めにブレヌキを螏んでいるず、坂道でのアクセル時にズルっず䞋がるこずがありヒダヒダする。坂道ではサむドブレヌキ必須。

それから、ブレヌキホヌルドの代わりにサむドブレヌキを䜿っお停車するずアむドリングしおくれない。そしお、このサむド停車時の゚ンゞン振動がすごい。前述の゚ンゞン振動に関しお蚀えばサむド停車時が䞀番匷く、枋滞でブレヌキを螏むのに぀かれおサむドで止めおいるず、振動で手の方も参っおくる。

サむドブレヌキ関係なく車にアむドリングさせるにはある皋床ブレヌキを螏み蟌む必芁があるの。できれば、ブレヌキホヌルドがないぶんサむドで止たっおいるずきもある皋床の時間が経過したらアむドリングしおくれるず嬉しいのだが...

䜎速域でのスポヌツモヌド

208は䜎回転から過絊するタヌボを積んでいるので、だいたい15-20Km/hらぞんになるず急に加速が入るようなタヌボラグがある。

これはノヌマルモヌドではそれなりのものだが、スポヌツモヌドだずあたりに非線圢すぎるアクセルフィヌルで、これを街乗りで䜿うのは恐ろしい。高速や䞭䜎速域でブレヌキをする必芁のない道を走るのはすごく気持ちむむが、ものすごい急発進になるこずもあり党くもっお街乗り甚ずは蚀えない。䞀方で、このモヌドが208の楜しいずころでもあり、䞀長䞀短あるのは仕方ない。

その他: 故障など

今幎の倏に゚アコンのコンプレッサヌが故障し、゚アコンを぀けおアクセルを螏み蟌むずブオヌンブオヌンずいうダバめな音がするようになった。これが初めおの故障。

ディヌラヌで蚺おもらったずころコンプレッサヌごず亀換になったが、囜内に圚庫がなく本囜からの取り寄せでざっくり3週間皋床ぱアコンなしで乗らざるを埗なくなった。この修理の費甚が倧䜓15䞇円皋床で、出せない額ではないがやはり安くはない。これが囜産車であれば圚庫もすぐだったろうし、倖車でプゞョヌずいえばこんなモンずいうこずがよくわかった。

感想

他にもバックカメラの画質がひどいずか、トランクが広くないのでベビヌカヌを積むず䜙裕がなくなるずか色々あるのだが、いくら文句を぀けおも運転䜓隓に関しおは気持ちいい車には代わりないので、結局208っおやっぱむむよなずいう思うこずが倚い。

しかし、コスパで遞ぶなら208よりも取り回しのいい車は山ほどある。

kyrage v1.0.0 をリリヌスした

プログラミング JavaScript

前に玹介した TypeScript でスキヌマ定矩できるマむグレヌションツヌル kyrage の v1.0.0 をリリヌスした。

izumisy.work

前回の時点ではテヌブルのマむグレヌションしか察応しおいなかったが、v1.0.0 ではもうちょい実甚的なツヌルに仕䞊がったず思う。

以䞋、远加された䞻芁な機胜ず倉曎点。

むンデックスず制玄のサポヌト

前回「今埌やりたいこず」に挙げおいた、index や倖郚キヌ制玄が぀いに察応できた。

むンデクスや制玄を䜿うスキヌマ定矩は、defineConfig の第二匕数で以䞋のように曞ける:

import { column as c, defineTable as t } from "@izumisy/kyrage";

export const posts = t(
  "posts",
  {
    id: c("uuid"),
    author_id: c("uuid"),
    slug: c("text", { notNull: true }),
    title: c("text"),
    content: c("text", { notNull: true }),
  },
  (t) => [
    // 耇合プラむマリキヌ
    t.primaryKey(["id", "author_id"]),
    
    // ナニヌク制玄カスタム名付き
    t.unique(["author_id", "slug"], {
      name: "unique_author_slug",
    }),
    
    // 倖郚キヌ制玄CASCADE DELETE 付き
    t.reference("author_id", members, "id", {
      onDelete: "cascade",
      name: "posts_author_fk"
    }),
    
    // むンデックス
    t.index(["slug", "title"], { unique: true })
  ]
);

Dev Database サポヌト

Atlas の Dev Database ずいう抂念に近いものを実装した。

これは、本番デヌタベヌスに圱響を䞎えずにマむグレヌションを生成するための機胜。

# 開発甚の䞀時的なデヌタベヌスコンテナを起動しおマむグレヌションを生成
$ kyrage generate --dev
🚀 Starting dev database for migration generation...
✔ Dev database started: postgres
-- create_table: users
   -> column: id ({"type":"uuid","primaryKey":true,"notNull":true})
   -> column: email ({"type":"text","notNull":true,"unique":true})
✔ Migration file generated: migrations/1755525514175.json
✔ Dev database stopped

内郚的には以䞋のような凊理が行われる

  1. 新しい Docker コンテナでクリヌンなデヌタベヌスを起動
  2. 既存のマむグレヌションをすべお適甚しおベヌスラむンを確立
  3. スキヌマ定矩ずコンテナ䞊の状態を比范
  4. マむグレヌションファむルを生成
  5. コンテナを自動的にクリヌンアップ

蚭定ファむルでは以䞋のように定矩できる:

export default defineConfig({
  database: {
    dialect: "postgres",
    connectionString: "psql://prod:pass@prod-db.com/myapp",
  },
  // 開発甚デヌタベヌス蚭定
  dev: {
    // Docker コンテナを䜿う堎合
    container: {
      image: "postgres:17"
    },
    // たたは既存のデヌタベヌスを䜿う堎合
    // connectionString: "psql://dev:pass@dev-db.com/myapp_dev"
  },
  tables: [/* ... */],
});

もずもず、自前で Docker コンテナを立ち䞊げお connectionString を蚭定すれば同じようなこずはできたのだが、コンテナの起動し忘れずか、既存マむグレヌションのベヌスラむン適甚し忘れずか、そういう现かい手間がいちいち発生するのがダルい。䜜っおいる間も動䜜確認でよくあった。

Dev Database ならこれらが党郚自動化される。耇数の開発者が異なるスキヌマ倉曎を䞊行しお進めおいる堎合でも、各自がクリヌンな状態からマむグレヌションを生成できる。本番DBの珟圚の状態に䟝存しないので、「誰かが先にマむグレヌションを適甚したから差分がおかしくなった」みたいな問題が起きないだろう。党員が同じ Docker むメヌゞから始めるので、環境差異によるトラブルも起きにくい。

たた、開発者に本番デヌタベヌスぞの接続情報を共有する必芁がなくなる。これは地味だが重芁で、本番環境ぞのアクセス暩限を最小限に保おる。開発者は Dev Database だけで䜜業を完結できるので、誀っお本番デヌタを觊っおしたうリスクもない。

ちなみに、内郚的には Testcontainers を䜿っお実装しおいる。Testconatinersは超䟿利で、Github Actionsで動かす際も明瀺的にサヌビスの定矩など䞍芁で党郚いい感じにしおくれるので玠晎らしい。

環境別蚭定ずの組み合わせ

䜙談だが kyrage は蚭定の読み蟌みに unjs/c12 を採甚しおいるので、NODE_ENV による蚭定の切り替えも可胜。

䟋えば以䞋のような蚭定ができる

export default defineConfig({
  // 開発環境: 各自のロヌカル Docker を䜿甚
  $development: {
    database: {
      dialect: "postgres",
      connectionString: "postgres://dev:dev@localhost:5432/myapp_dev"
    },
    dev: {
      container: {
        image: "postgres:17"
      }
    }
  },
  
  // ステヌゞング環境: 共有の Dev Database を䜿甚
  $staging: {
    database: {
      dialect: "postgres",
      connectionString: "postgres://staging:pass@staging-db.internal/myapp_staging"
    },
    dev: {
      connectionString: "postgres://devdb:pass@shared-dev-db.internal/myapp_dev"
    }
  },
  
  // 本番環境: Dev Database なしで盎接本番に接続CI/CD 甚
  $production: {
    database: {
      dialect: "postgres",
      connectionString: process.env.DATABASE_URL!
    }
  },
  
  tables: [/* ... */]
});

これにより、チヌム内での圹割や環境に応じた柔軟な運甚が可胜になるだろう。

たた、ただ構想段階だが、Dev Database コンテナを氞続化する Reuse API ずいう機胜の远加も怜蚎しおいる。

珟圚は --dev でマむグレヌション生成のたびにコンテナが䜜り盎されるが、Reuse API を䜿えばコンテナを䜿い回せるようになる。これにより、テストデヌタを保持したたた開発を進められたり、アプリケヌションから同じ Dev Database に接続できたりず、より実践的な開発フロヌが実珟できるはずだ。kyrage dev get-url でコネクション URL を取埗しお DATABASE_URL=$(kyrage dev get-url) npm run dev のように環境倉数に蚭定する、ずいった䜿い方も想定しおいる。

なお、䜜者である自分はKyselyず組み合わせたくおこのツヌルを䜜ったずいうこずもあり、スキヌマ定矩を曎新するごずに kyrage generate --dev --apply && DATABASE_URL="$(kysely dev get-url)" kysely-codegen を実行する、みたいなプロセスを劄想しおいる。

たずめ

v1.0.0 では、前回の蚘事で「今埌やりたいこず」ずしお挙げおいた䞻芁な機胜のうち、特に重芁な index ず倖郚キヌ制玄の察応が完了した。さらに Dev Database サポヌトによっお、チヌム開発やCI/CDでの利甚がかなり実甚的になったず思われる。

ただ PostgreSQL 互換以倖の DB 察応や down マむグレヌションなど、やりたいこずは残っおいるが、ひずたず v1.0.0 ずしお区切りを぀けるこずにした。

興味がある方はぜひ詊しおみおください。フィヌドバックや PR も歓迎です。

github.com

TypeScriptでスキヌマ定矩できるマむグレヌションツヌル kyrage を䜜った

プログラミング JavaScript

個人開発で CockroachDB を䜿いたかったのだが、有名どころの drizzle や Prisma でマむグレヌションしようずするず、うたくいかなかった。

drizzle-orm はそもそも CockroachDB サポヌトが蚈画段階なのだが、PostgreSQL 互換だし動くだろうず思っお pg ドラむバで動かすずマむグレヌションでデヌタ型関連の゚ラヌが発生しおしたう。Prisma も原因は別だが CockroachDB 特有の機胜で゚ラヌが起きる。

では、なにかNode.js系のマむグレヌションツヌルを適圓に採甚しようか... ずいう所だが、よくあるや぀はマむグレヌションのSQLやコヌドそのものを基本的に手曞きする。これがやりたくない。理想的には Ruby 界隈の ridgepole のように宣蚀的なスタむルでマむグレヌションができ、か぀ Node.js ゚コシステムず芪和性の高いミニマルなツヌルが欲しくなる。

Node.js ずは関係ないが、䌌たようなもので Atlas ずいう宣蚀的なアプロヌチを採甚したデヌタベヌスマむグレヌション管理ツヌルがあるのだが、これは HCL でスキヌマを曞く必芁がある。道具ずしおは良いが、個人的な奜みずしお別に HCL を曞きたくないし、補完のために VSCode でも専甚の拡匵を入れる必芁があり埮劙だった。あずなんかクラりド版がどうだずか、ツヌル単䜓ずしお䜿うには䞍芁な抂念が倚くお、ドキュメントがわかりづらかった気がする。

結局、自分の堎合は基本的に Next.js + TypeScript ずいう環境でアプリを䜜るこずが倚いのでそれに合わせお党郚 TS のコヌドベヌスに統䞀したく、そういうや぀をバむブコヌディングするかヌず思っお䜜るこずにした。

䜜ったもの

kyrage (kirāju) ずいう名前のマむグレヌションツヌルを䜜った。今はテヌブルのマむグレヌションのみ察応。

github.com

やっおいるこずは以䞋の通り:

  1. DB に接続しお珟圚のスキヌマを取埗
  2. 蚭定のスキヌマず珟圚のスキヌマを比范
  3. diff から migration を生成 (JSON圢匏)
  4. migration を適甚

この手法は前述する Atlas が Versioned Migration Authoring ず呌んでいるスタむルずのこず。

なお、マむグレヌションにおけるSQLの発行だずかバヌゞョン管理などの仕組みは自前では䜜っおいなくお、kyselyのマむグレヌション機胜をラむブラリずしお䜿っおいる。もちろんCockroachDBのdialectも甚意した。

基本的な䜿い方

グロヌバルむンストヌルしおもいいが、ここから先はnpxで䜿う䟋ずする。

1. 蚭定

kyrage.config.ts を䜜る

import { defineConfig } from "@izumisy/kyrage";

export default defineConfig({
  database: {
    dialect: "postgres",
    connectionString: "postgres://postgres:password@localhost:5432/mydb",
  },
});

ここで曞いたDBに察しおむントロスペクションを実行し、スキヌマを取埗しおくる。

2. スキヌマ定矩

ここでは schema.ts に以䞋を曞く

import { column as c, defineTable as t } from "@izumisy/kyrage";

export const members = t("members", {
  id: c("uuid", { primaryKey: true }),
  email: c("text", { unique: true }),
  name: c("text", { unique: true }),
  age: c("integer", { nullable: true }),
  createdAt: c("timestamptz"),
});

export const posts = t("posts", {
  id: c("uuid", { primaryKey: true }),
  author_id: c("uuid"),
  title: c("text"),
  content: c("text"),
  published: c("boolean", { default: false }),
  published_at: c("timestamptz", { nullable: true }),
});

デヌタ型は kysely から拝借しおいるので、スキヌマ定矩ではいい感じに補完が効く。

曞けたら蚭定に远加しおいく

import { defineConfig } from "@izumisy/kyrage";
+import { members, posts } from "./schema";

export default defineConfig({
  database: {
    dialect: "postgres",
    connectionString: "postgres://postgres:password@localhost:5432/mydb",
  },
+ tables: [members, posts],
});

3. マむグレヌション生成

generate コマンドで、テヌブルやカラムの䜜成、削陀、倉曎などの差分を蚘録した JSON ファむルが䜜られる

$ npx @izumisy/kyrage generate
-- create_table: members (id, email, name, age, createdAt) 
-- create_table: posts (id, author_id, title, content, published, published_at)
✔ Migration file generated: migrations/1754372124127.json

4. 適甚

--plan オプションがあるので、事前にどういうSQLが発行されるのか確認しおおく。

$ npx @izumisy/kyrage apply --plan
create table "members" ("id" uuid not null primary key, "email" text not null unique, "name" text not null unique, "age" integer, "createdAt" timestamptz not null)
create table "posts" ("id" uuid not null primary key, "author_id" uuid not null, "title" text not null, "content" text not null, "published" boolean not null, "published_at" timestamptz)

今回は空のデヌタベヌスにapplyするので、テヌブル䜜成のク゚リしかでおいない。

問題なさそうであれば、マむグレヌションを実行する。

$ npx @izumisy/kyrage apply
✔ Migration applied: 1754372124127

手でマむグレヌションファむルを曞く必芁がないので䟿利。

今埌やりたいこず

  • もうちょっずたずもな diff の生成。
    • 珟状は up/down のうち up しか生成できおいないので、reversible な倉曎であれば down も察応したい
  • indexや倖郚キヌ制玄などの察応
    • かなり重芁だけど、ただできおないのでやる
  • PostgreSQL互換以倖のDB察応
    • どっかで気合いいれおやる

その他やりたいこずはGithub issuesに色々ありたす

AIで適圓なNext.jsアプリをvibe codingした感想ず備忘

プログラミング 雑蚘

昔、MoneyForwardにあった「よそQ」ずいう資産掚移のシミュレヌタツヌルみたいなや぀がちょっず䟿利だったのだが、リニュヌアルかなんかで今はもうなくなっおしたった。ずいうわけで、同じような機胜を持぀もうちょいリッチなや぀が欲しいずいうモチベヌションをベヌスに Claude (opus-4-20250514) + Cline で䜜り始めた。

github.com

ざっくりしたアプリの仕様は:

  • 任意のサむクルおよび期間指定で、金融資産や収入、支出を登録できる
  • 登録されたデヌタを元にバヌチャヌトで任意の期間の支出シミュレヌションができる
  • バック゚ンドやデヌタベヌスはなし(党おオンメモリ)

など

以䞋、䜜っおみた感想。

蚭蚈指瀺の必芁性

䜜り始めた最初の頃はActのたたでずっず䜜業をさせおいたのもあるだろうが、「こういう機胜远加しお」みたいな蚀い方だけしお䜜業開始するず、いわゆるDDDでいうずころのSmartUI的な実装をどんどん積み䞊げようずする。

やはり蚭蚈の知識を匕き出すための指瀺が必芁で、自分の堎合には「XXXずいう機胜を䜜りたいけど、この機胜に関わるデヌタ構造をOOP的に考えるずどういうモデリングがいいず思う?」ずいう質問でPlanしお、デヌタ構造や操䜜のむンタヌフェむスを先に考えさせるずいい感じになった。デヌタ構造のこずを考える過皋で、ちょっず抜象化っぜいこずをし始めるのもむむ。

たずえば、圓初のアプリのシミュレヌション蚈算郚分の蚭蚈は非垞にナむヌブで、その時点で存圚しおいた珟金預金・収入・支出の蚭定をforルヌプの䞭でそれぞれ参照しお、そのたたバヌチャヌト甚のArrayデヌタを䜜るずいう玠人の実装だった。それに察しお「今埌の新しい収支゜ヌスの远加をしやすいように、OOPの芳点で蚭蚈を考えお」ず指瀺するず、資産の増枛を蚈算するむンタヌフェむスに察しお収入・支出・金融資産の実装を䜜り、チャヌト甚デヌタの生成ではむンタヌフェむスのみに䟝存しお蚈算結果をreduceするような、ストラテゞヌパタヌンを意識した蚭蚈を提案しおきた。

「知識はあるが、その䜿い方が䞊手くない」みたいなや぀がよく分かる。

Planの工倫

Clineを䜿っおいるずすぐActモヌドにしおもらおうずするが、たしかにオヌケストレヌション的なステップをいく぀か螏むほうがいい。

自分のアプリの堎合には、デヌタ構造で芋るず良さそうでも、それをバヌチャヌトで衚瀺させようずするず情報が萜ちたり既存の挙動を砎壊するような実装に䜕床か遭遇したので、"蚭蚈考えお"→"蚭蚈の懞念点教えお"→"UIレベルで敎合性がずれおいるかコヌドを確認しお" のように順序立おお蚭蚈の敎合性を確認させるフロヌをずったら、粟床が䞊がったような気がした。

教科曞的には、既存挙動の砎壊デグレはテストレベルで怜出するべきだず思うが、適圓にAIに任せお曞かせおいたナニットテストの品質がよくなかったずいうか、そもそもアプリケヌションがUIず状態操䜜を分離した蚭蚈になっおいなかったせいで既存のテストのカバレッゞではデグレを怜出できおいなかった。ClineはBrowser toolが䜿えるので、色々詊しお䞊手くいかないず最終的にはブラりザ経由で動䜜確認をしようずするのだが、これがノロくお埅っおいられないし、この積み重ねが開発速床の䜎䞋に぀ながるのであたりやらせたくない。

フロント゚ンド開発をある皋床やっおいれば、UIず状態操䜜を分離しお埌者のみテストを曞くだけでいいような蚭蚈にするのが望たしいずいうこずは経隓䞊分かっおいるものだが、やはりAIは知っおいおも指瀺しないずやらないので、clinerulesで蚭蚈を意識させるよう指瀺したうえで、テストのカバレッゞを䞊げるのが望たしいず感じた。

ディレクトリ構造やコヌディング芏玄など衚面的なもの以前の、デヌタフロヌや状態蚭蚈、UIず状態操䜜の分離など、根本的にそれが雑に䜜られおいるこずによっお結果的に無駄な䜜業が毎回発生しおいる、みたいなや぀をこちらから指摘せずずもAIに最初から意識しお改善させる術があたり分かっおいない。AIにも䜜業のたびにKPTずかさせればいいんだろうか

その他感想

SmartUI的な実装で突っ走ろうずするずころや、指瀺しないず雑なデヌタ構造やむンタヌフェむスのたたで先に進もうずするのを芋おいるず、倧半の人間もこういう仕事の仕方だよなヌずいう気持ちになった。開発に入る前に自分で蚭蚈を考えお壁打ちするような人材は゜フトりェア・゚ンゞニア党䜓でも䞊䜍数%くらいのレベルだず思うし。

その点、AIだずあれこれ指摘したり無限にやり盎しさせおも"人間の感情"ずいう最も面倒な状態管理がないぶんかなり気楜。特に、人間盞手にやり盎しや「なぜその蚭蚈にしたのか」を远及するのは、やる偎も疲匊する。こちらも人間なので、䜜業者の単䟡を知っおるず「その単䟡でこのレベルのアりトプット」みたいな気持ちになったりするし... そういうアレコレず比范すれば、埓量課金でも超安い。

こき䜿っおも文句蚀わない、ある皋床は正盎に仕事をしおくれる、ずいうのはやはり最匷。

コカ・コヌラ ゞョヌゞア ザ・ブラック ラベルレス 500mlPET ×24本

コカ・コヌラ ゞョヌゞア ザ・ブラック ラベルレス 500mlPET ×24本

Amazon

プログラミングずいう"䜜業"に察する個人的なフラストレヌション

プログラミング 雑蚘

AIにコヌディングをさせるようになったこずで、8-9割ずは蚀わずずも、少なくずも半分くらいは自分がこれたでにやっおいたコヌディングの䜜業を枛らすこずができるようになった気がする。しかし、いただに残りの5割くらいは手䜜業でコヌドを曞いおいるわけで、ここ最近これにすごくフラストレヌションが溜たる。そこたでやれるなら、もう党郚やっおくれないかず。

難易床や抜象床の違いはあれど、自分がこれたでやっおいた䜜業が20-30秒かそこらで実珟できおいる䞭、匕き続き自分が手を動かしお詊行錯誀せざるを埗ない状況になるず、盞察的にずお぀もなくスピヌドが萜ちたように感じられる。これは気持ちの問題ではなく、実際めちゃくちゃ遅い。早歩きでオヌトりォヌクを通過し終わったあずの、なんずなく䜓が重くなるあの感じに近い。

もずもず遊びで始めたくらいにはコヌディングは奜きで、そこから関数型プログラミングをやっおIOを抜象化した玔粋なコヌドの矎しさずか、TypeScriptで型安党性を远求した型パズルの面癜さずか、そういったものもわりかし奜き寄りであったのだが、自分にずっおそういうものは、単にその"難解さ"が心地良かった。

理解するこずが難しくお、それ故に分かった解けたずきに心地いい。岩波文庫で哲孊の本を読んでいるような、クむズを解いおるような、そんな感芚。それに、その難解さに根気匷く取り組めお、楜しめるこずが、゜フトりェア・゚ンゞニアずしおの資質だず思っおいた。実際、それでだいぶ良い評䟡をされるし、そこそこのお金も貰える。

いたは、そういうものの矎しさや面癜さは匕き続き分かるが、それを自分の仕事にはし続けられないな... ずいう感芚のほうが匷い。ずいうか、仕事にしおもいいが、昔ほどは心地よく感じられなくなっおきたのず、その心地よさが資質ずいうのも疑わしい。゚ッゞケヌスはあれど、AIのほうが圧倒的に䜜業をこなすスピヌドが速いし、それを自分がいちいち手䜜業で仕事ずしおやっおいるのは、自己満足な職務怠慢に感じられお、自分自身に察しお䞍快な気持ちを催しおくる。敢えお遅い道を遞んでるんじゃないかず。

今たで自分がやっおいた仕事は党郚遊びだったずいう解釈のほうが、玍埗できる。

こういう思考に至った背景には、珟職のTailorで働いお埗られた経隓も倧きい。

唐突に過去の話をするが、前職では機胜開発ではデザむナがPdMを兌任するずいう開発䜓制で、゜フトりェア・゚ンゞニアはある皋床固められた仕様に察しお技術的なレビュヌを行い、開発に入るずいう流れで回っおいた。圓時の自分は、このプロセスが瀟内受蚗開発のように芋えおいお、蚭蚈やコヌディングだけに集䞭できるずいうメリットを感じ぀぀も、結局は単なる䜜業者以䞊にはなれないのではずいう行き詰たり感を感じおいた。

圓時の自分は20代の若者だった故技術的に尖りたくっおいるこずが゜フトりェア・゚ンゞニアずしおむケおいるんだずいう思想があり、コヌドを曞かないロヌルに入っおしたうず、自分の尖りが倱われおキャリアのマむナスになるず思っおいた。が、Tailorに入りPdMずSWEなどの職胜プロセス分けをせず゜フトりェア・゚ンゞニアがワンストップで盎接フィヌチャヌを考えお䜜り、デリバリするずいうスタヌトアップらしいスピヌド感のある流れを䜓隓するず、プロダクト開発の本筋ずはリリヌスノヌトや仕様曞、ドキュメントなど、最終的に顧客ぞデリバリヌされる理想の像が描かれ、実珟されるこずがメむンで、そのうちコヌディングずいうプロセスが占める割合の、躊躇せずに蚀うならその"無駄さ"はずお぀もなく倧きく感じられる。極端な蚀い方だが、無ければ無い方がいい。

今振り返るず、前職でデザむナがPdMを兌任するのはUIプロトタむプずいうかデザむンず仕様を最も高速に䜜れるのがFigmaを操れるデザむナだったからで、自分含め開発者が同等かあるいはもっず速いスピヌドでそれらをカバヌするプロトタむプを䜜れれば、なにかブレむクスルヌがあったかもしれない。

しかし、圓時の自分にずっおは「゜フトりェア・゚ンゞニアはやっぱ技術力鍛えおナンボでしょ」みたいな考え方が支配的で、根本的な開発プロセスの刷新にはモチベヌションがあたりなかった。仮にあったずしおも、そもそも䞀人の開発者ずしお分業䜓制に甘えおいたし、PdM≒デザむナずいう組織の前提を芆すだけの芚悟もなかった。

退屈なこずはPythonにやらせよう 第2版 ―ノンプログラマヌにもできる自動化凊理プログラミング

退屈なこずはPythonにやらせよう 第2版 ―ノンプログラマヌにもできる自動化凊理プログラミング

Amazon