こんにちは。バクラク給与の開発を担当しているakahaneです。
新規プロダクトとしてバクラク給与を立ち上げ、2026年3月にリリースしました。その開発の進め方について振り返ります。
はじめに
バクラク給与の立ち上げでは、Claude CodeやCodexなどのコーディングエージェントを積極的に活用しました。
ただし、これは「AIにコードを書かせたら速かった」という話ではありません。
給与計算は、間違いが許されない領域です。計算結果が1円ズレれば、それは従業員の生活に直結する。「それっぽく動くコード」が最も危険な領域とも言えます。
一方で、新規プロダクトの立ち上げは変化の連続です。仕様も設計もプロダクトの形も日々変わる。このフェーズでは、試作・修正・検証のサイクルをどれだけ速く回せるかが勝負になります。
「間違えてはいけない」と「速く試行錯誤したい」。この一見矛盾する要求の中で、コーディングエージェント時代の新規プロダクト立ち上げが実際どのように進んだのかを紹介します。
フィードバックループを「翌スプリント」から「翌日」に変えた
新規プロダクトの立ち上げでは、最初から正解の仕様・設計は存在しません。
バクラク給与でも、初期は「まず動くものを作る」「実際に触れる形にする」「チームやドメインエキスパートと議論できる材料を作る」ことが最優先でした。仮で作った画面を翌日に作り直す。一度決めたデータ構造を、ドメイン理解が進んだことでゼロから見直す。そうしたことが日常的に起きていました。
ここでコーディングエージェントが大きく効きました。
たとえば、ある日の仕様検討会で「この画面の構成を変えるべき」というフィードバックがありました。一見すると画面上の表示変更に見えますが、実際にはAPIのレスポンス構造やフロントの表示ロジックにも影響するほどの変更です。以前なら次のスプリントに回していたような規模感ですが、コーディングエージェントを使うことで、その日のうちに方針を整理し、翌日にはチームにデモできる状態にできました。
こうしたサイクルは、この一度きりではありませんでした。
立ち上げ期には、毎日のように仕様検討会やレビュー会を実施していました。顧客ヒアリングで得たフィードバックも、翌日の別の顧客のヒアリングで意見を伺う。そこでまた反応を見て改善する。そういう短いループを日々回していました。
実装速度が上がることで、チームや顧客との対話の頻度も上がる。仮説を早く形にし、早くぶつけ、早く直す。結果として、プロダクトの解像度を上げるスピードが変わりました。
ただし、速く作れることは、何でも作ってよいという意味ではありません。作るコストが下がったからこそ、「本当に作るべきか」「使われ続けるものか」「将来の開発速度を落とさないか」を、以前よりも強く意識する必要がありました。新規プロダクトにおいては、作らない判断やシンプルに保つ判断も、同じくらい重要です。
実務の温度感は、コーディングエージェントには判断できない
給与計算領域では、AIにいきなり実装を依頼してもうまくいきませんでした。
コーディングエージェントに聞けば、給与ドメインに関する一般的な情報はある程度得られます。所得税の計算方法、社会保険料の算出ロジック、基本的な用語の説明。しかし、それだけでは足りません。
実際の日々の業務で、その作業がどのくらい大変なのか。労務担当者がどの部分を特に慎重に確認しているのか。間違えたときにどのくらい影響が大きいのか。なぜ一見面倒に見える確認ステップが必要なのか。こうした現場の温度感は、コーディングエージェントには持ちようがありません。
たとえば、社会保険料の控除ひとつとっても、法令上のルールだけを見れば「翌月徴収」で「端数処理は五捨五超入（50銭以下切り捨て、50銭超切り上げ）」とシンプルに見えます。しかし実務では、慣習的に当月徴収を採用している企業や、法令とは異なる端数処理を用いている企業が少なくありません。こうした現場ごとの運用実態は、法令の条文やインターネット上の情報だけでは把握できず、コーディングエージェントに聞いても出てきません。
また、給与計算そのものだけでなく、計算後のチェックをどう行うかも重要でした。労務担当者は計算結果をただ眺めるのではなく、前月との差分を見て異常値を探す、特定の項目を重点的に確認する、といった独自のチェックフローを持っています。どの画面で何を見れば安心して確定ボタンを押せるのか。こうした確認プロセスは法令に書かれているものではなく、ドメインエキスパートとの議論を通じて初めて見えてきた部分でした。
そのため、AIに実装を任せる前に、労務ドメインエキスパートと一緒に仕様を言語化するプロセスが不可欠でした。そして言語化した仕様をもとに議論を重ね、重要度の濃淡を設計判断に落とし込むこと。それがプロダクトの土台になりました。
給与計算ロジックの中心は、あえて人間が書いた
給与計算ロジックの中心部分は、コーディングエージェントの利用をあえて控え、人間が中心となって実装しました。
理由は明確で、この領域ではAIが「それっぽいコード」を書けてしまうこと自体がリスクだからです。
給与計算では、単に数式を書けばよいわけではありません。支給、控除、勤怠、締め日、支給日、月途中入社・退職、休職、端数処理。さまざまな条件が絡む。さらに、「計算結果が合っている」だけでなく、「なぜその金額になったのか」を説明できることも求められます。
コーディングエージェントに正しく実装させようとすると、業務上の前提、計算の意図、例外条件、端数処理、保存すべき計算根拠、将来の拡張可能性を、すべて正確に言語化して渡す必要がある。そして、出てきた実装が正しいかをレビューするには、結局人間がロジックを同じレベルで理解していなければなりません。
であれば、そのコンテキストを作る時間とレビューの時間を考えると、人間が自分で書いたほうが早く、確実でした。
AIが生成するコードの怖さは、エラーになる、動作しないことではなく、それっぽく動作してしまうことにあります。画面上も問題なく見える。しかし、特定の条件で1円ズレている。給与計算では、こうした「動くが正しくない」コードが最も発見しにくく、最もダメージが大きいリスクになります。
テストケースの洗い出しでは、AIが強力なレビュアーになった
一方で、テストケースの作成にはAIを大いに活用しました。
計算ロジックでは、正常系だけでなく、境界値や例外パターンをどれだけ洗い出せるかが品質を左右します。人間だけで考えていると、自分が実装した前提に引っ張られて、どうしても見落としが出る。
そこで、実装したロジックや仕様メモをAIに渡し、「この仕様に対して、漏れやすい境界値や異常系を洗い出して」と依頼しました。「テストコードを書いて」ではなく、テスト観点の網羅性を問う使い方です。
たとえば、月途中入社・退職のテストケースでは、人間が考えた「月初入社」「月末退職」「月途中入社」に対して、AIは「入社日と退職日が同月」「締め日をまたぐ入社」「支給日前日の退職」「休日に重なる場合」といった観点を追加で出してきました。すべてが有効なケースではありませんでしたが、ドメイン上検討すべき観点として有用なものが多くありました。
AIにテスト観点を出させ、人間がドメイン上正しいかを確認し、必要なケースをテストコードに落とし込む。この進め方により、給与計算ロジック周辺でカバレッジ90%以上を達成できました。
AIは実装者としてだけでなく、「自分たちが見落としている観点はないか」を問うレビュアーとして有効でした。
ボトルネックは「コードを書く」から「何を作るか決める」に移った
コーディングエージェントを使うことで、実装速度は確実に上がりました。しかし、実装が速くなると、ボトルネックは別の場所に移ります。
以前は「考えたことを形にする」のに時間がかかっていました。今は、形にすること自体は速い。すると、「何を形にすべきか」を決める部分が律速になる。
何を作るべきか。何を作らないか。仕様の曖昧さをどう解消するか。ドメイン上の正しさをどう判断するか。AIが出したコードをどう評価するか。
コードを書く時間は確かに減りました。しかし、それは「よいコンテキストを作る」「AIに適切に依頼する」「出てきたものを評価する」「ドメイン上正しいかを判断する」という時間に置き換わっています。
言い換えると、コーディングエージェントはエンジニアの仕事をなくすのではなく、エンジニアの仕事の重心を変える。手を動かす比重が減り、判断する比重が増える。新規プロダクトの立ち上げでは、この変化の意味は大きいと感じました。
特に重要なのは、実装の前段にある「何を、なぜ、どう作るか」を整理する力です。ドメインエキスパートとの議論を設計に落とす力、仕様の曖昧さを言語化する力、AIが正しく動けるだけの精度で要件を整理する力。コーディングエージェントが強力になるほど、この上流の質がプロダクトの質を決めるようになります。
まとめ
「間違えてはいけない」と「速く試行錯誤したい」。この二つの要求に対して、バクラク給与の立ち上げでたどり着いた答えはシンプルでした。速く回すべきところはコーディングエージェントで速く回し、間違えてはいけないところは人間が責任を持つ。
結果として、バクラク給与は当初のリリース予定より2ヶ月前倒しでリリースすることができました。これはコーディングエージェントの力だけで実現したものではありません。ドメインエキスパートとの仕様言語化、顧客との高速なフィードバックループ、人間が主導した計算ロジックの実装。それらすべてが噛み合った結果です。
実装が速くなった分、エンジニアの仕事の重心は「コードを書く」から「何を作るかを決め、正しさを判断する」に移っています。バクラク給与の新規プロダクト立ち上げではこの変化がより鮮明に見えました。
LayerXの「すべての経済活動を、デジタル化する。」というミッションに共感いただける方、技術の力で社会課題解決に貢献したい方は、ぜひ以下からご応募ください！
