LayerX のエンジニアブログで、AI時代の新規プロダクト立ち上げ 〜バクラク給与の開発で見えたこと〜 を読んだ。自分も同じ立場でコーディングエージェントや生成AIを使いながら開発を進めるときに感じていることと重なる部分が大きかったので、整理して残しておく。
エージェントが理解しにくいもの
仕様書やコード上の正常系は、ある程度形になっていればAIも手伝いになってくれる。見えている範囲の整理や、既に決まっているルールの実装イメージの具体化などは、特に立ち上げが進んだあとでは効いてくる。
一方で、業務ドメインそのものや、現場で実際に手を動かしている人の実務の温度感までは、エージェントにそのまま渡せない。どの作業が本当に負荷が高いか、どこを間違えると誰にどれだけ影響が出るか、なぜ一見回りくどい確認が必要なのか。こういう文脈は、法令や一般的な解説だけでは足りない。
給与の例のように、計算結果が生活に直結する領域では、そのギャップが特に危ない。画面上は問題なく見えて、特定の条件だけ金額がズレる。動いてしまうこと自体がリスクになりうる。
大切な部分は人とプロセスで固める
だから自分の整理としては、次の二つがセットで必要だと思っている。
- 重要なロジックや正しさの核は、人が責任を持って書く・レビューできる形で残す
- 設計の早い段階からドメインエキスパートをプロセスに組み込み、議論して言語化した仕様に落とし込む
言語化と合意が先にないと、あとから「どこが原因だったか」を掴みにくくなる。仕様が頭の中や会話のまま、あるいはAIの出力が前提になりすぎていると、不具合や要望が出たときに、設計判断と運用実態のどちらが効いているのか切り分けづらくなる。
給与でいえば、なぜその計算になるのかを説明できる土台がないと、拠り所がブレやすい。計算式が書けても、端数・締め・入退社・チェックの仕方まで含めた「納得できる一貫性」が土台になる。
「コードを書く」から「何を作るか決める」へ
記事でも触れられているように、コーディングエージェントで実装が速くなると、律速は「形にすること」ではなく何を形にするかに移っていく。
自分の経験でも、コードをほとんど書かない半年ほどの期間があったが、やっていたのは実質ずっと何を作るかを決める作業だった。仕様の曖昧さを減らすこと、作るものと作らないものの線引き、ドメイン上の正しさや優先順位の整理。手を動かす比重が下がるぶん、ここに時間と注意が寄っていく感覚を、そのまま体験として理解できた。
AIでプロダクトを作る文脈では、「作る」こと自体が速くなったからこそ、何を作るべきかと曖昧さをなくしていく工程の比重がさらに大きくなる。記事で言語化されている構造と、現場での感覚がかなり一致していた。
そのうえで、こうした整理をブログとして明快にまとめ、実際にプロダクトまでローンチしているLayerX（バクラク給与）の話には、正直すごいと思った。言葉にした理解と、成果物の両方がある。
上っ面だけでは足りない
AIを走らせること自体は、開発の速度や試行錯誤の回転には効く。ただ、ドメインと実務の解像度を上げる工程を飛ばしたままAIに寄せると、返ってくるのは上っ面の解決に寄りやすい。
バクラク給与の記事でも書かれていたように、速くできる場所と人が引き受ける場所の線引きがはっきりしているかどうかが、AI時代の開発の実感に近いと思う。実装が速いほど上流の「何を・なぜ・どう作るか」の質がプロダクトを決める、という話も、半分はコードから離れていた期間の手応えとして納得できる。自分のメモとしても、同じ線で考え続けたい。