はてなブックマーク

こんにちは、技術広報のyayawowoです。 私たち株式会社ラクス開発本部では、Missionである 「顧客の成長を支援する、圧倒的に使いやすいクラウドサービスを創り提供する」 を念頭に、日々プロダクト開発に励んでいます。 現在、ラクスでは歴史あるロングセラーのプロダクトから、近年立ち上がった新規プロダクトまで、多くの開発プロジェクトが並行して動いています。このように古いものから新しいものまで多くのプロダクト開発に深く携われるからこそ、エンジニアやデザイナーが触れられる技術の機会が非常に多い点が、私たちの組織の大きな特徴であり魅力です。 本記事では、各プロダクトの「技術スタック」を改めて整理し、皆様に最新情報をお届けしたいと思います！自社開発に携わるエンジニア、デザイナーだけでなく、これから携わりたい！という方にも必見の内容です。 現場のリアルな最新データから見えてきたのは、単なるツールの

こんにちは！AIエージェント開発課です。 近年、生成AIの進化スピードは凄まじく、単なるテキストの要約やドラフト生成の枠を超え、自律的に判断してタスクを実行する「AIエージェント」が大きなトレンドとなっています。 このような技術的な潮流の中、私たちのチームは2025年5月に「AIエージェント開発課」として産声を上げました。累計導入社数 約20,000社以上の顧客基盤と、16年以上にわたって蓄積された膨大な業務データ（ドメイン知識）というラクスの強みを活かし、バックオフィス業務の「完全自動化」という未来へ向けて、日々泥臭く開発を続けています。 私たちがメインで取り組んでいるのは、主力プロダクトである「楽楽精算」へのAIエージェント機能の実装です。 この記事では、私たちが直面した「3つの壁」とそれを突破した設計原則、そしてそこで得られた知見を社内の他プロダクトへ共通LLM基盤として還元していく

こんにちは、ラクスでバックエンドエンジニアをしている斉田真也（GitHub: shinya / X: @saita_shinya）と申します。業務のかたわら、Markdownエディタ Bokuchi を個人で開発していて、仕事でも個人開発でも、いまやClaude Codeはすっかり相棒になっています。 先日大阪の梅田で開催された Claude Code Meetup Osaka に参加し、LT枠でも登壇してきました。AIは失敗する。でもその失敗を"使い捨て"にせず記録して次に読ませれば、二度目から同じつまずきを繰り返しにくくなる ── 私が登壇で話したのは、そんな「Claude Codeの育て方」でした。 この記事では当日の様子と学びを、この会ならではの空気感とあわせてレポートします。 TL;DR 大阪・梅田で開催された Claude Code Meetup Osaka に参加し、LT枠で

「自分が時間をかけて作った機能、ちゃんと使われていますか？」 エンジニアだったら、たぶん一度は胸の奥に刺さる問いだと思います。仕様書通りに作って、テストも通って、リリースして。でも数か月後にログを見るとあまり利用されていない。そういった経験があるかと思います。 この記事では、冒頭の問いに対して「ちゃんと使われている」と言える機能を開発できた事例を紹介します。AIを活用することで2週間でベータ版提供までこぎつけ、楽楽自動応対の翻訳機能が最終的に「この機能の導入前にはもう戻れない」と顧客に言ってもらえるまでの裏側です。 実際の業務フローをヒアリングすることで機能への解像度を上げた 社内の認識合わせを動くものを見ながら行った ベータ版は"きれいな設計"より"速く出せる"を優先した 出す前と出した後、2回顧客に見てもらうことでブラッシュアップした 裏側でログを取っておくことで、定量的な観測が出来る

「勉強のため」から「持ち帰るため」に変わった アウトカムを意識するようになった 将来の自分たちが楽になるかどうかで見ている レベル300のセッションが「ちょうどいい」と感じた AI一色、そしてフィジカルAIの存在感 まとめ AWS Summit Japan 2026に参加してきました。kazuki kanekoです。 今回で人生2回目のAWS Summit Japanです。 昨年はSIerとして参加していましたが、この1年で自社開発の会社に転職し、今はAIエージェントの開発に関わるチームで働いています。 同じイベントなのに、見え方がかなり変わっていて、自分でも驚きました。 振り返ってみると、変わった理由は「転職したから」というよりも、「自分たちのプロダクトを自分たちで作り、運用し続ける立場になったから」だと思います。特にAIエージェントという、設計判断がそのまま精度や運用コストに跳ね返って

1. はじめに この記事で書くこと この記事で書かないこと 前提 2. バージョンアップ作業フロー Step 1：メジャーバージョンアップによる影響調査 Devin の Playbook を作成する Devin の Playbook を実行して一覧化する Step 2：対応が必要かどうかの判断と方針検討 Step 3：更新作業 3. AI 活用の所感 影響度判定の精度評価 良かった点 微妙だった点・反省 4. まとめ 5. 今後の展望 参考文献 1. はじめに ラクスが開発する請求書受領システム「楽楽請求」では、Web アプリケーションフレームワークとして Spring Boot を使用しています。 当時使用していた Spring Boot の 3 系 が2026年6月で EOL になるため、バージョンアップ（3系 → 4系）を実施しました。 バージョンアップに関する影響調査を AI（De

はじめに 私が開発ツールに求めることをZedは満たしていた すぐに開けること コードが追いやすいこと 複数画面を上下左右に開けること ディレクトリがツリーで開けること Git関連機能にアクセスしやすいこと VSCode、Ghostty、Zedを比較する Zedの使用感 Zedの微妙なところ ACP経由のエージェント体験はCLIより遅く感じる ファイルパスクリックで開けない VSCode拡張に依存している人は移行しづらい まとめ はじめに 4月にラクスに入社しました。kazuki kanekoです。 研修を受けつつ、開発環境を立ち上げようとVSCodeをセットアップしていました。 すると、AIエージェント開発課のメンバーから「Zedいいですよ」とおすすめしていただきました。 これが、私がZedを知ったきっかけでした。 今は紆余曲折ありながら、Zedに落ち着いています。 以前はVSCodeを中

まず「測る」ことを設計した 「使わない」には、それぞれの理由があった AI活用は確かに進んだ。でも、浸透しきってはいない 顧客に届けるための、AI活用標準化 今期進める4つの取り組み 「エンジニア非稼働時間帯でも開発が進む」を目指して こんにちは、ラクス技術広報です。 AIツールが開発現場に届いたあと、何が起きているのか。ChatGPT EnterpriseやGitHub Copilotが展開されてしばらく経ったころ、ラクスの開発本部横断組織「開発管理課」はある問いに詰まっていました。ツールは使えている。使っているエンジニアもいる。でも組織として本当に生産性が上がっているのか、確かめる手段がなかった。 実際に声を集めてみると、大きく個人差が開いている状況でした。AIを使いこなしてどんどん先へ進む人と、今まで通りのやり方を続ける人。「チームによって開発スピードに差が出てきている。個人の問題と

はじめに 楽楽シリーズUI統一プロジェクトとは フェーズ1: AIに任せられない領域 フェーズ2: 規模がもたらした新たな課題 AI活用の勘所: 実装ルールをAIに翻訳する なぜ「セルフチェック」だったか Cursor Rulesという仕組み 運用してみての手応え 振り返って見えたパターン 作業の性質とAI活用の相性 AI活用は、人間の作業との連携で成立する おわりに はじめに こんにちは。楽楽販売の開発を担当しているn-chocolatteです。 「AIを活用しよう」とはよく言われますが、いざ自分の現場に当てはめようとすると、「結局、どの作業に使えばいいのか」で手が止まってしまう。そんな経験のある開発者の方は、少なくないのではないでしょうか。 先にお伝えしておくと、今回私たちがAIを使ったのは実装そのものではなく、実装後のセルフチェック工程でした。 なぜそこに使ったのか——その判断の過程

はじめに JJUG CCCとは 登壇スライド 外部発信のモチベーション 登壇を通じて得られた気付き 振り返り はじめに 登壇直前に地元バスケクラブが準優勝し、かなりのダメージを負っていた楽楽債権管理チームの冨澤です。 2026年5月30日に行われたJJUG CCC 2026 Springで初登壇してきました。 本記事は、そのレポートとなります。 JJUG CCCとは JJUG CCCは、日本最大のJavaコミュニティイベントです。 日本Javaユーザグループ（JJUG） / Japan Java User Group (JJUG)が主催しており、今回は春に開催されたカンファレンスです。 （秋にもあります！2026年11月28日開催予定） ccc2026spring.java-users.jp 登壇スライド speakerdeck.com 外部発信のモチベーション なぜCIを速くしたいかは登

はじめに 給与計算オプションの開発で最初に困ったこと なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか まず、初心者向けの課題図書を選んだ MVP開発に必要な知識に絞って、学習コンテンツを作った 仕様説明では、「なぜその機能が必要なのか」まで説明した リリースまで進めるうえで大事だったこと 1. 自分だけが詳しい状態にしない 2. 開発部・事業部が必要な知識を持てるようにする 3. すべてを学ぶのではなく、今回必要な範囲に絞る 4. 仕様の背景や目的まで伝える まとめ はじめに 楽楽勤怠のプロダクトマネジメントをしている @k0First です。 2026年4月に、楽楽勤怠から給与計算オプションをリリースしました。 www.rakus.co.jp 給与計算オプションの開発で難しかったことの一つが、給与計算というドメインの理解でした。 私は前職で給与計算システムの開発経験があり、

1. はじめに なぜ改善が必要だったか どんな改善をした？ 2. バージョンアップ運用フロー 2-1. CIによる機械的チェック（GitHub Actions） ①helm templateコマンドによるレンダリングチェック 実装詳細 ②PlutoによるKubernetes API互換性チェック 実装詳細 ③HelmChart展開後のマニフェスト差分把握 実装詳細 2-2. AIによる影響調査 AIレビューコメント例 なぜラベル起動にしたか プロンプト なぜDevinを選定したのか 3. 導入後の効果 4. 今後の展望 5. まとめ 参考文献 1. はじめに こんにちは！SRE課のモリモトです。 本記事では、CIとAIでKubernetesエコシステムのバージョンアップ運用を改善した事例をご紹介します。 なぜ改善が必要だったか SREチームでは、Kubernetesエコシステムの多数のOS

はじめに 開発部と事業部では、見ているものが少し違う 開発観点だけで判断を閉じると、議論が進みにくくなる 議論が噛み合わなくなるのは、「必要性」と「実現性」が混ざるとき 要望をそのまま受け取らず、課題として整理する 「やるか・やらないか」ではなく、スコープを分ける 仕様だけでなく、届け方まで含めて考える まとめ はじめに 楽楽勤怠のプロダクトマネジメントをしている @k0First です。 PdMとして仕事をしていると、開発部と事業部の相談MTGで、同じテーマについて話しているはずなのに、少し議論が噛み合わないと感じることがあります。 もちろん、どちらかが間違っているわけではありません。 ただ、議論がうまく前に進まないときは、見ている論点や重視している判断軸が少しずれていることが多いように思います。 そこで、開発部と事業部の相談MTGで扱ってきた相談ごとと、その顛末をまとめたシートをもとに

2026年1月、株式会社ラクスに技術広報として入社した髙須賀（たかすか）と申します。 早いもので入社から3か月が経過しました。新年度という区切りを迎え、これまでの振り返りと、これから私たちが目指す姿についてお伝えできればと思います。 1. 自己紹介 2. ラクスの開発組織の魅力について 3. 入社後の取り組みについて ヒアリングと施策立案 顧客志向表彰の実施 ブログの執筆 社内向け記事の執筆 商談動画のまとめ その他 4. 今後の展望：発信を楽にする環境づくり 5. おわりに 1. 自己紹介 私自身はエンジニアとしての経験はありませんが、前職ではITエンジニア向けの技術イベントの企画・運営に従事していました。 当時から大切にしているのは、「ITエンジニアの皆さんと共通言語で会話ができるようにすること」です。 IPA試験の受験、技術書、社外の技術イベントへの参加などを通して技術への理解を深め

目次 目次 0. はじめに 1. レビューされる側だった頃の問題点 2. レビューと設計の関係性 2.1 なぜレビューが必要なのか 2.2 なぜ「設計」が関係するのか 3. コードレビュー指摘の傾向から学んだこと 3.1. 様々な設計原則 3.2. 設計指摘を具体的に理解する 3.3. 設計指摘をものにするためには？ 4. before / after で見る設計指摘の具体例 4.1. SRP: 「責務が多い」と言われたケース before: 1つのクラスに複数の責務がある after: 責務ごとに分離する 4.2. OCP: 「将来増えそう」と言われたケース before: 条件分岐で処理を切り替えている after: 振る舞いを分離する 4.3. DRY: 「共通化できそう」と言われたケース before: 同じコードが複数箇所にある after 其ノ壱: 知識を一箇所に集約 afte

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 社内で口癖のように使っている「製品解像度」と「UX志向」について自分の思考の整理もかねて記事にまとめてみました。 はじめに：私たちは「誰」を見ているのか？ 「製品解像度」とは何か？ まず押さえたい：製品解像度が低いと起きる“あるある” なぜ「お客様解像度」だけでは不十分なのか？ 質の高いアウトプットを生む土壌 UX志向を支える「意思決定」の力 「OR」ではなく「AND」を模索する 「架け橋」としての役割 ラクス プロダクト部としての「UX志向」 製品解像度を高めるために 1. 「越境」を恐れない 2. 「なぜ？」を問い続ける 3. プロダクトの「歴史」と「未来」を知る 製品解像度が上がると何が起きるか：アウトプットの質が変わる 1) 要求仕様が“

こんにちは。ラクス フロントエンド開発課 新卒2年目の持永です。 最近AI活用が進み、コードを書く速度は以前とは比較にならないほど上がりました。 そこで私は、 「AIに並列で実装を任せれば、複数の画面/機能を"爆速"で開発できるのでは？」 と考え、複数画面・複数機能を並列で進めるスタイルに挑戦しました。 並列開発の中で、工夫してうまくいった点もありました。 ただ、期待したほどの効率化には至らず、「手戻りの連鎖」と「レビュー負荷の増大」も招きました。 今回は、並列開発で工夫した点と誤算を整理し、そこから得た気づきを共有します。 1. 試したアプローチと結果 2. 工夫した点①：AI向けの仕様書と計画書を用意した 作成の流れ 効果 3. 工夫した点②：ローカル構成の整理 ポイント 効果 4. 誤算①：未確定要素による「手戻りの増加」 何が起きたか なぜ起きたか どうすべきだったか 5. 誤算②

目次 目次 1. はじめに 解決したかった課題 2. アーキテクチャ 3. プレビュー環境の作成・更新・削除 作成・更新フロー 削除フロー パターンA: PRクローズ or ラベル削除 パターンB: TTLによる定期クリーンアップ プレビュー環境へのアクセス PRコメント例 4. 実装のポイント Pull Request Generator の実装 PRごとに異なるValuesの命名規則 GitHub Actions Argo CD 再コミット時の自動イメージ更新 仕組み 環境数の上限制御 ResourceQuota によるリソース使用量の制御 5. おわりに 参考 1. はじめに こんにちは！SRE課のモリモトです。 今回は、プレビュー環境基盤をKubernetes上に構築した話をご紹介します。 解決したかった課題 弊社のあるサービスでは、フロントエンド開発において以下のような課題があり

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp PdM（プロダクトマネージャー）って、企業によってやることがバラバラですよね。 「仕様書を書く人」みたいになってる会社もあれば、 「戦略を決める人」だったり、「なんでも屋」だったりする。その中で、よく出てくるモヤモヤがこれです。 顧客インタビューをしていないPdMって、本当にPdMなの？ 逆に言えば、 エンジニアやデザイナーでも、顧客理解しながら動いていたらPdM的じゃない？ この記事では、toB SaaS という文脈に絞って、この疑問をカジュアルに掘っていきます。 こんな方が対象： PdMを目指している人 いま PdM をやっているけどあまり顧客に会えていない人 「自分はPdMと言えるのか？」と不安になっている人 ✋ 結論から言うと… 🧩 P

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp おそらくこれが2025年最後の記事になるので、まずはこの一年を振り返ってみようと思います。 🗓 2025年の振り返り ■ 組織・採用まわりの変化 ■ 発信・外部登壇 外部登壇（モデレーター含む） note／ブログ記事 🏛 「文化」を構成するものは何か ハイレイヤーの意思決定の優先順位 なぜ「文化」が重視されるのか 🗣 文化は“言葉”に表れる ■ ラクスのカルチャー 🎁 採用で工夫している「4P」の話 📝 最後に 🗓 2025年の振り返り ラクスに入社して4年半。毎年さまざまな変化がありましたが、2025年は特に大きな転換点の年になりました。 ■ 組織・採用まわりの変化 デザイナー／プロダクトマネージャーが所属する プロダクト部が誕生

はじめに こんにちは。楽楽販売の開発を担当しているuemuraです。 楽楽販売では11月に、初のAI機能をリリースしました。 楽楽販売をご契約いただいたお客様が導入準備をスムーズに進められるように支援する、チャット形式の機能となっています。 プレスリリースはこちら。 本機能の開発PJは楽楽販売にとって（また私自身にとっても） 初のAI機能開発、初のアジャイル×スクラム開発 となっており、新しいこと尽くめでした。 AI機能を開発する難しさもさることながら、アジャイル×スクラム開発にもなかなか苦戦したため、その学びを残しておこうと思います。 目次 体制紹介 どのような流れで開発が進んだか フェーズ1：立ち上がり フェーズ2：仮説ドリブンの機能開発 フェーズ3：品質改善とリリース準備 良くなかった点 自転車操業に陥った インクリメントの品質を担保できていなかった 生成AIによるコーディングとの付

目次 目次 1. はじめに 前提条件 免責 2. Application Controllerの役割 3. Application Controllerのアーキテクチャ Application Controllerの起動処理（ctrl.Run()） App Refresh Processor App Operation Processor 該当箇所 Reconciliation Loop（内部メカニズム） Phase 1: Refresh 該当箇所 Phase 2: Sync Operation 該当箇所 4. Shardingの仕組み Shardingとは？ Shardingのコアメカニズム ArgoCDで選択できるシャーディングアルゴリズム Legacy 特徴 該当箇所 Round Robin 具体例 特徴 該当箇所 Consistent Hashing 特徴 該当箇所 シャードIDの

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 2025年12月4日（木）に当社ラクスの紀井が登壇し、『AI時代の「ジュニア不要論」に異議あり！未経験から戦力PdMを生み出すOJT戦略とは？』 2025.pmconf.jp というテーマで「PdM育成」について登壇しました。 そこで私も、現在、直下で1名のPdMを「再育成」していることもあり、ラクスにおけるPdM育成のリアルを少しフィクションを交えつつお伝えします。 ■ はじめに メンバー概要 ラクスのプロダクトマネージャーの選考プロセス 採用時点の評価 ■ 入社後 → 再育成に至るまで ■ オンボーディングについて バディ体制 ■ PdM担当後に起きた課題 ■ 再育成の進め方 カリキュラム概要 １．課題図書 → レポート作成 → メンターと議

はじめに 請求書の明細表をOCRによって自動で読み取ることができると、経理業務自動化の実現に役立ちます。 ところが実際には、多様なフォーマットの存在や OCR の誤読が積み重なり、AIモデルとルールベース後処理だけでは思った以上に精度が出ない、という壁にぶつかることがあります。 AI モデルそのものの改修となると、学習データの追加やモデル更新など、時間もコストも必要になります。また、ルールベース後処理を増やし続けるのは、将来の保守を重くする心配がつきまといます。 そこで、「大規模言語モデル（LLM）を後処理に加えたら、より柔軟に・より構造的に・まるで人間が行うように誤りを補正できるのではないか」という発想のもと、既存処理に GPT による補正ステップを追加し、精度改善ができるか検証しました。 はじめに LLM による後処理の追加 追加した処理の流れ GPT に与えたプロンプト 検証結果 ま

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 2025年4月、ラクスではプロダクト部が新たに組成され、デザイナーとプロダクトマネージャーが同じ組織に加わりました。 そして2025年10月から、私はこの組織のマネジメントを担うことになりました。 実は7〜8年前にも、兼務という形でデザイナーのファーストラインマネージャーを経験しており、採用も含めて直接マネジメントをしていた時期があります。 その経験があるため、今回デザイン組織が含まれることに対する不安はありません。むしろ プロダクトマネージャーとデザイナーが同じ組織でコラボレーションできることにワクワクしている というのが今の正直な気持ちです。 この記事では、これまでの自分とデザイン／デザイナーとの関わり、そして今回のマネジメントに向き合うにあ

この記事はラクス Advent Calendar 2025 1日目の記事です。 はじめに こんにちは！ エンジニア3年目のTKDSです！ 今回はCodex CLI SDKの入門記事を書きました！ Codex CLI SDKはChatGPTの有料プランに契約していれば、特に追加費用不要で使用可能です。 そのため、さくっとMy AIエージェントを作るのには非常におすすめです。 では早速本題に入っていきたいと思います。 はじめに Codex CLIの概要 Codex CLI SDKについて 環境情報 基本的な操作 お天気エージェントを題材にした解説 シンプルなエージェント 最終版 まとめ Codex CLIの概要 Codex CLI is a coding agent from OpenAI that runs locally on your computer. 翻訳：OpenAIが提供するロー

はじめに こんにちは。楽楽勤怠のバックエンドを担当しているkoyaです。 約二年前、あるきっかけからQiitaに記事投稿を始めました。 最初は毎週書こうと決めていたわけではありませんが、 気づけば毎週投稿するようになり、いつの間にか100週が経っていました。 振り返ってみると、続けてきた中でいろんな気づきがあり、自分自身も少しずつ成長できたように感じます。 この記事では、その間のことを少し振り返りながら、 書くことを続ける中で感じたことをまとめてみようと思います。 はじめに 入社当初の焦り とりあえずで始めた記事投稿 毎週投稿の決意、そのためのルール 記事投稿をする中で得た気づき 1. アウトプットできるかどうかが理解度の物差しとなる 2. 書けない週はインプットが少ない 3. アウトプットを前提に学ぶことの大切さ 記事投稿を継続したいま、思うこと おわりに 入社当初の焦り 2023年7月

こんにちは、id:takaram です。 ラクスでは全社で GitHub を利用しており、大半のプロジェクトが GitHub Actions を CI として利用しています。 GitHub Actions は、テストやデプロイまでを自動化する強力な仕組みである一方、正しく使わなければセキュリティホールとなる危険性もはらんでいます。 今回は、GitHub Actions のセキュリティについて紹介していきます。 GitHub Actions のセキュリティ ありがちな侵害のパターンと対策 1. サードパーティアクションの侵害 問題 対策 2. 過剰な権限設定 問題 対策 3. run 内での OS コマンドインジェクション 問題 脆弱な例 対策 4. curl | bash 型の危険なスクリプト実行 問題 対策 追加の対策 1. actionlint で構文・展開の安全性をチェック 導入例