こんにちは！レバレジーズでリードエンジニアのゲンシュンと申します！ レバレジーズにデータエンジニアとして転職して、ちょうどまる2年が経ちました。今はデータエンジニアチームのリーダーとして、メンバーのマネジメント評価育成、全社横断のデータ分析基盤やETLの構築、データ系職種の組織づくりといったデータエンジニアのお仕事をしつつ、全社の技術力の底上げや文化醸成を担うリードエンジニアとして、アプリケーションエンジニアとDDD勉強会を開いたり、技術広報、社外イベントの企画・登壇、さらには社内エンジニアイベントの運営まで、かなり幅広いお仕事をしています。 社内にはリードエンジニアがあんまり多くないので、 レバレジーズのリードエンジニアってこんなことやってるよ！ の紹介も兼ねて、この2年目にチャレンジしたことを振り返ります。 データエンジニアとしてのお仕事 データ環境について レバレジーズはレバテック、レバウェル、キャリアチケットなどたくさんの事業を展開していて、日々大量のデータが生まれ、使われています。入社して最初に驚いたのが、 営業の方1000人以上が毎日各自でSQLを書いて勝手にデータを利活用していることです。 「データ利活用を推進しましょう！」みたいなフェーズはとっくに過ぎていて、現場で当たり前のようにデータで意思決定しているんですよね。 それ自体はすごく良いことなんですが、「みんなが自由にデータを触っている」からこその大変さもあります。データの品質担保やガバナンス、基盤の安定稼働やコスト削減など、利活用が進んでいるからこそやらなきゃいけないことがたくさんあります。 データ系組織については、大きく2つの組織に分かれています。自分が所属するシステム本部テクノロジー戦略室は、ETL処理の安定稼働などデータの生成側に近いエンジニア組織です。一方マーケティング部のデータ戦略室は、DWH以降のデータ整備やBI接続、分析・利活用など事業部に近い組織で、データアーキテクトと呼ばれるメンバーが在籍しています。エンジニアではなくマーケターなんですよね。 つまり、 レバレジーズのデータ系職種はエンジニアとマーケターの混合チームで構成されていて、全員がエンジニアではない。 これが後で話す技術選定や組織の話にも大きく関わってきます。この2つの組織が協業しながら、さらに各事業部とも日々やりとりしてデータ基盤を支えているので、関わる人が本当に多い環境です。直近やったことは 2025年のレバレジーズのデータ活用基盤 にまとまっているので、興味のある方はぜひ。 2年目でやったこと データ基盤周りのお仕事の概要だけざっくり紹介します。 Dataform Assertionの全事業導入 データ分析基盤のデータ品質が担保されていないという課題に対して、Dataformのassertion機能を使った品質チェックを全事業に導入しました。1事業について成功パターンを作り、データアーキテクトの皆さんの力を借りて全事業へ横展開できましたね！展開中、約半数のテーブルでエラーが検知されるという修羅場もありましたが。。。笑、AIを活用してエラー分析を効率化しながら全事業への導入を無事完遂！一緒に進めたメンバーが Dataformでのデータ品質担保の運用の工夫 を記事にしてくれています。 Salesforce周りのデータ連携 Salesforceの連携周りは、データエンジニアにとって悩みの種かと思います。2025年はデータ量とカラムの急増で、Cloud Run Jobsなどの性能限界を超えるリスクがあったんですが、Cloud ComposerのDeferrable機能を検証・導入したり、メモリ不足やタイムアウトを検知できる体制を整え、結果として大規模データ連携も安定稼働しております。Data Engineering Summitの前夜祭でこのあたりの話をしたので、気になる方は CloudComposerによる大規模ETL 「制御と実行の分離」の実践 をぜひ。 担当事業の課題解決に深入り 自分は全社横断に関するデータ分析基盤の設計に加えて、いくつか担当事業も持っております。データ系組織がすべての事業を見ているわけではなく、現場メンバーが各々で回してきた基盤を途中からデータ系組織が引き取り、事業担当として担うこともあります。 自分が引き継いだ基盤は、いつどこで何で更新されているのか誰も全体像を把握できておらず、見る場所によって数値が微妙に違う状態。クエリの精査と、1000行超えSQLの考古学を繰り返しながらデータモデリングを見直しつつ、新規にデータマートを作り直しました。巨大SQLの考古学については、自分なりに意識していることを 巨大SQLに対する解読術 でまとめたので、気になる方はぜひ・・、昨今だとAIに全部聞けば解決しちゃいそうですけど・・笑。 また考古学だけでなく、その部署の各職種の業務のお困りごとや何がしたいのか？何が出来ると嬉しいのか？を事業部長に毎週ヒアリングしながら、業務支援に繋がるStreamlitで作ったツールの提供などチームで課題解決に取り組んでいます。 他にも全社のクラウドコスト削減の旗振り役、全社マスターデータマネジメントの基盤立ち上げ、AI Readyな基盤作りに向けた方向性決めなど、データに関わることは大体なんでもやっていますね！！ 技術選定について データ分析基盤ではdbtやディメンショナルモデリングがデファクトになりつつありますが、レバレジーズでは意図的に今は採用していません。 さきほどデータ環境の紹介で書いた通り、レバレジーズのデータ基盤はデータエンジニアとデータアーキテクトが支えています。事業に入り込めているデータアーキテクトと、SQLを書ける現場という圧倒的な強みがあり、一足飛びの技術選定はこの強みを壊しかねないと思っています。 そもそも 「dbtを使ってない」「ディメンショナルモデリングを使ってない」こと自体が課題解決につながるわけではないんですよね。 じゃあ何が課題なのか。いろいろヒアリングした結果、開発環境が良くないことだったり、事業課題に向き合う時間がさけていなかったり、そっちの方が本質的な課題だったりします。dbtを採用することでしか解決できない課題で今苦しんでいるわけではない。技術はあくまでも手段なので、まずは手前の課題から段階的に解いて、「最強の戦略を採用できる状態」を目指している最中です。 この「最新技術を"今は選ばない"」という話は、 みんなの考えた最強のデータ基盤アーキテクチャ で 登壇 した際にも話しているので、詳しくはそちらをどうぞ。 組織のあり方について リードエンジニアというと「技術で引っ張る人」というイメージを持たれがちなんですが、組織設計にもかなり向き合いました。 さっき紹介した通りレバレジーズのデータ組織は、データエンジニア（システム本部）とデータアーキテクト（マーケティング部）という機能軸で分かれています。それぞれに強みがある一方で、組織の分業がそのまま開発体験に現れる、いわゆるコンウェイの法則も見えてきました。データエンジニアは事業から遠く、依頼を受けて作る受発注の関係になりがち。データアーキテクトは事業に入り込めている反面、エンジニアリングの支えがないと生産性が頭打ちになる。などなど。 機能軸の組織はそのままに、事業軸の動きを重ねることから始めました。データアーキテクトとエンジニアの壁打ち枠を作ったり、マーケティング部のプロジェクトにエンジニアが入る体制を作ったり、事業ドメインを軸にデータの入り口から出口まで一気通貫で見る動きを増やしたり。正確に言うと、もともと事業に入り込めているデータアーキテクトの側に、事業から遠かったデータエンジニアを引き込んでいった形です。 AIの登場で、この動きは更に重要になっていると感じています。今は 「AI Readyなデータ基盤」をテーマに、AIがデータを使える状態と、人がAIを使って分析できる状態の2軸で取り組みを進めています。 例えば、マーケターがClaudeからMCP経由で直接BigQueryを触れるようにするPoCでは、権限やコストのガードレールを設計した上で開放しました。AI向けに設計方針やドメイン知識を集約したリポジトリを整備してチームに配布したりも。 地道な人間関係づくり データエンジニアのお仕事って、依頼ベースのものがどうしても多いんですよね。「データが出ない」「ダッシュボード壊れた」「このデータ連携したいんだけど」みたいな要望が各事業部から日々やってきます。 前職は社員数が100人前後、自分の在籍期間も長かったので、人間関係のコンテキストが解像度高く働きやすかったんですよね。一方レバレジーズはオフィスは複数あるし、事業もたくさんあるし、社員数は4000人超え。データ系は俺に任せろぉ！と叫びたい所ですが「お前誰だよ」状態なんですね笑。 本当に地味なんですが、依頼をくれた人との関係をまず丁寧に広げていきました。定期的に本社や他のオフィスに足を運んで、依頼をかけてくれた人の座席に行っておしゃべりしたり、ランチ行ったあとに「俺に合いそうな人つなげてください！」と無茶振りしたり、一時期はこんな感じで「Gランチ募集！」と1〜2ヶ月でマーケティング部の人40人くらいとランチに行った時期もあります笑。 この画像貼りまくってランチ募集してました 他にも社内にはたくさんの部活動がありまして、ボードゲーム部などを通じて色々輪を広げたり。自分はお仕事で絡んだことある人とボドゲお誘いしたり、自己紹介ページなどで共通の趣味がありそうな人を見つけては声をかける、みたいなことを地道にやってましたね・・！ ボードゲーム部のクリスマス会 地道ですけどこうやって 「こいつに聞けば、誰かにつなげてもらえるかも」という認知をちょっとずつ獲得していって、現場の課題感を生の声で聞けるようになったり、自分が困った時に相談できる人が増えていきました。 さっき書いた「組織をどう動かすか」みたいなお仕事も後述する技術広報のお仕事も、色んな人にたくさん相談の上成り立っているので、この土台がなかったら絶対に出来ていないと思います。 組織内の技術の底上げ データ組織向けにも、事業横断のアプリケーションエンジニア向けにも、いろんな場を作ってきました！ ディメンショナルモデリング輪読会 アーキテクトと合同で、アジャイルデータモデリング本の輪読会をしました。一通り読み終えた後に参加者にヒアリングしたら「ある程度理解はしたけど、具体的にどう実務に活きるのかわからない」という声が多かったので、実際の事業のデータソースを使ってdim/factを実装する実践ワークショップを開催しました！詳しくは 記事にまとめています 。 VSCode × GitHub Copilotワークショップ データアーキテクトの皆さんは基本的にDataformをコンソール上で開発しております。非エンジニアでも開発出来るメリットはありつつも、AIが普及した今、コンソールでの開発は恩恵を受けられないので、開発効率が高くない状態でした。VSCodeエディタの導入からGitHub Copilotによるコード生成、ローカルからのDataformコンパイルまで、段階的に取り組めるワークショップを設計して、みんなで取り組みました。結果としてコンソールを使わずローカルで開発が完結する状態を体験してもらうところまで持っていけました！ アプリケーションのリファクタ予備校 AIでWebアプリやツールがサクッと作れる時代になりました。とはいえ、出てきたコードをちゃんと理解して、設計判断を自分の言葉で説明できる力は欲しいよね？ということで、TypeScriptでゼロからアプリを作るお題を自分で用意して、それを叩き台にコードの言語化を徹底的にやってもらう育成業務（通称「予備校」）をメンバー向けに開講しております。AI時代にとってこれが意味がない可能性もありますが。。笑 他にも最近はAIエージェントをみんなで作ってみる連載型ワークショップも走らせています！横串で色んな事業のエンジニアを巻き込んで、みんなのできることを少しずつ増やしていく。こうやって組織全体で土台を作っていくプロセスが大事だと思ってます！ DDD勉強会 レバレジーズには色んな開発部があるのですが、開発部横断で何か勉強会や技術の取り組みがそんなになくて、非常に勿体ないと感じてました。いろんな開発部でTypeScript採用しているので、TypeScriptを使った技術力底上げ施策を色々やりました。 その中でも一番濃かったのがDDD(ドメイン駆動設計)の勉強会です。なんでデータエンジニアがやってんのって話なんですが、前職アプリケーションエンジニアで、設計の議論に学びが多かったので、レバレジーズでもやりたいなと。 「自分の考える設計意図を、自分の言葉で相手に納得させる力をつける」をゴールに 、複数事業のエンジニアを集めて勉強会を主催しました。よくあるECサイトをお題として用意し、普段の業務では関わらない各事業のアプリケーションエンジニアと色んなディスカッションができました。 社内イベントから社外発信まで 社内エンジニアイベントの企画・運営 年に2回、全エンジニアが集まる「テックフェス」という社内イベントがあるのですが、それの運営委員として参加しました。 夏はAIハッカソンの企画をしたのですが、テーマ、評価項目、体験設計、当日の進行、とにかく細部までこだわった企画でした。そのおかげもあり非常に盛り上がったイベントとなり、満足度は驚異の96%！笑。 YouTubeでも動画化 されてます。 冬はセキュリティがテーマで、自分はハッキングされた体の広報サイトを企画しました。 当日の様子は テックフェス2025 夏レポート や テックフェス2026 冬レポート のレポートをどうぞ。 テックフェス運営委員会の皆さん 社外登壇・イベント企画・モデレーター 社外にもいろいろ出ております！レバテックLabやレバテックMeetupでは、モデレーターや登壇を平均すると月1回ぐらいやらせてもらいました。領域はデータエンジニアだけでなく、フロントエンド、React、AI駆動開発など多岐にわたるテーマに関わらせていただきました。登壇者選定もやらせてもらってます。特定の人だけが出るのではなく、色んな事業部、若手に登壇してほしいな〜と思って、色々声をかけていますね！ レバレジーズ外だと、データエンジニアコミュニティであるdatatech-jpという所で「みん強」というデータ系イベントを企画、運営しています。直近1年間の取り組みだと、オフィスをお借りしてオフラインイベントを開いたり、SnowflakeというAIデータクラウドの会社の日本支社オフィスをお借りしてコミュニティイベントを開いたり、データエンジニア界隈の盛り上げを様々な切り口でチャレンジしてます！ 技術広報 こうした社外活動が多かったこともあり、2026年からはレバレジーズ全体の技術広報も始めました！自分が掲げるミッションは 「発信を当たり前にする文化を作る」と「レバレジーズのエンジニア組織をもっと皆さんに知ってもらう」 の2つです。 自分だけじゃなくて色んなエンジニアをとにかく外に出すこと、登壇や執筆をお願いしたり、イベントの企画や運営を体験してもらったり、EMConf2026やTSKaigi 2026などのブース出展を手伝ってもらったり。ブース出展では、展示内容や導線などをみんなで議論しましたね。この辺りの活動は 技術活動レポート に四半期ごとにまとまっています。 今年のEMConfとTSKaigiは、agile effect事業部の皆さんと各事業部のエンジニア合同でブース出展しました。 agile effect事業部と合同でTSKaigiに参加 とはいえ、いきなり社外に登壇ってまぁまぁハードルは高いと思うので、まずは社内で気軽にアウトプットできる場を作りたいよね〜ということで社内テックブログ「ぷれぽす」を自作するプロジェクトに参加しました。自作でテックブログを作る取り組みで、設計から実装も自分たちでやっています。詳しくは この記事 。 アウトプットって特別なイベントじゃなくて日常であってほしいんですよね。 勉強会で話したことが記事になり、記事が登壇になり、登壇を見た誰かが入社してくれる。そういう「発信が当たり前」の文化を醸成していきたいなと思っています。いろんなイベントに出ていくので、見かけたらぜひ声かけてください！！ まとめ 改めて1年間振り返ったんですが、お仕事の幅が想像以上に広がった2年目でした！ リードエンジニアの役割は、技術実装だけでなく組織全体の技術力向上や事業横断での課題解決、社外発信など幅広い役割を担うポジションです。お仕事の幅が広がったのはこの肩書のおかげではなく、 色んな事業部のいろんな職種のメンバーがお互いに関心を持って関わり合っているからだと思ってます。 データ基盤も、チームも、組織の動き方も、社外への発信も、課題を見つけたら全部お仕事にできて、色んな人を巻き込める、毎日が刺激的な環境です。 データエンジニアとして転職して、データエンジニアだけじゃなかった2年でした。3年目はもっとおもしろくなりそうなので、これからも楽しくやっていきます！

はじめに 「AIがちゃんと仕事をしているか」を、そもそも測る手段がありませんでした レバレジーズが運営する「レバテック」は、ITエンジニアやクリエイター向けの転職・フリーランス支援サービスです。レバテックブランドの一部である「レバテックキャリア」では、キャリアアドバイザー（CA）が求職者の方と面談し、その内容をもとに求人や案件を提案しています。 このレバテックキャリアでは、CAと求職者の方のやり取りが記載されたテキストデータからLLMを使って求職者の技術スキルを自動で抽出し、求人のレコメンドに試験的に活用しています。人が自由に書いた文章を、機械が扱えるデータに変える仕組みです。この仕組み自体はすでに動いていました。 一方で、「抜き出したスキルが本当に合っているのか」を自動でチェックする仕組みは、これから実装するところでした。 3週間（実働9日間）の就業型インターンで私が取り組んだのは、この抽出結果を自動で採点する評価の仕組み—— LLM as a judge をゼロからつくること です。さらに、つくった評価の仕組みそのものが信用できるのかを検証し、プロンプトを改善して採点の精度を高めていきました。 はじめまして。早稲田大学 基幹理工学研究科 情報理工・情報通信専攻 修士1年のASと申します。大学院では、脳波や心拍といった生体情報から人の「興味」を推定する研究に取り組んでいます。人の関心をデータから捉えるという点で、今回扱った「推薦」や「その評価」とも通じるテーマかもしれません。趣味は旅行・テニス・スキー・お笑い、そしてAIを触ることも好きなことの一つです。 この記事では、9日間で何を考え、どこでつまずいたのかを、できるだけそのまま書いてみます。 背景: 非構造化データを「使える形」にした、その先にある課題 もう少し詳しく仕組みを説明します。CAと求職者のやり取りを記載したテキストデータから、LLMで技術スキルを抽出する。抽出されたスキルは、対応するスキルのマスタデータに名寄せされた上で、特徴量としてデータベースに保存され、レコメンドの精度向上に使われています 。 図1: テキストデータから特徴量ができるまで これは、 これまで人の目でしか読めなかった非構造化データを、機械が扱える形に変換する 取り組みです。インターンでは、この周辺システムの暫定版のリリース作業も担当させていただきました。学生の立場で本番環境に乗せるところまで経験できたのは、大きな財産です。 一方で、抽出結果を眺めていくと、気になる出力も見つかりました。同じスキルを延々と繰り返す「ループによる異常抽出」や、数十文字の短いテキストから大量のスキルを吐き出す「短文への過剰出力」です。こうした出力を人の目だけで拾い続けるのには限界があります。 非構造化データを構造化できたことがゴールではなく、その変換品質を測り続けられて初めて、安心して運用に乗せられる。 ここが今回のスタート地点でした。 まず現状を疑う: 実データ分析でわかった3つの事実 いきなり評価システムを作りたくなる気持ちを抑えて、最初の数日は実データと向き合いました。設計の前に、現場で語られている前提が本当に正しいかを自分の手で確かめたかったからです。実際、当時のメモには「"1人あたりのスキルは1〜5件がほとんど"って、本当にそう？」などと書き殴っていました笑。 全件を集計した結果、3つの事実が見えてきました。 ① 入力の性質が、極端に二極化していた テキストデータの文字数は平均775文字に対し、中央値は146文字。500文字以下の短文と1,000文字以上の長文にくっきり分かれ、中間がほとんどありません。原因は、テンプレートを使って書かれたテキスト（全体の約25%・平均2,709文字）と、使わずに書かれたテキスト（約75%・平均139文字）の混在でした。 性質の異なる入力が同居していることは、評価の設計を考えるうえで前提として押さえておく必要があります。 図2: テキストデータの文字数は「短文」と「長文」に二極化していた ② 異常出力は、統計的にはっきり検出できた 1人あたりの抽出スキル数は平均5.4個。95%が16個以下、99%が39個以下に収まる一方、最大では676個というデータが存在しました。そもそも676個という出力は名寄せ対象のマスタデータの件数を超えており、その時点で明らかにおかしいと判断できます。 ③ マスタとの整合が、半分しか取れていなかった 抽出結果のうちマスタに合致したのは45.3%で、残る54.7%はマスタ外。原因は表記ゆれ・英語表記・資格名の部分不全などです。抽出そのものはできていても、 そのままではマスタと突き合わせられないデータが半数以上ある という状態でした。 余談ですが、オフィスでの時間そのものが刺激的でした。作業していると、近くで進んでいるミーティングの話し声が自然と耳に入ってきます。AIエージェントの設計の話だったり、出たばかりのAIモデルをどう使うかという話だったり。手を動かしながらそういう会話が聞こえてくる環境は、学生の自分にとってかなり贅沢な時間でした。 設計: なぜ「2層構造」にしたのか 分析を踏まえ、評価パイプラインは 2層構造 に落ち着きました。狙いは、計算コストと検知精度の両立です。 図3: 評価パイプラインの2層構造 第一層は、プログラムによる決定論的な形式監査です。 LLMを使わず、機械的に落とせるものを落とします。JSONの構造チェックに加え、「出力スキル数が上限を超えたら0点」という足切りを設けました。上限の設定は悩みどころで、統計上は99%が39個以下に収まります。しかし39個ちょうどでは目視でまだ異常が残る一方、ごく稀にいる"超優秀層"の正常データまで切り捨てたくない。機会損失を防ぐため、安全を取って 上限は50件 としました（51件以上は全体のわずか0.86%です）。ここでNGなら、コストの高いLLM評価に回さず即終了します。 第二層は、LLMによる意味監査です。 第一層を通過したデータについて、評価用LLMがテキストデータの原文と抽出結果を突き合わせ、文脈から抽出の過不足を判定します。つまりここでやっているのは、 LLMの出力を、別のLLMに採点させる ということです（これが「LLM as a judge」と呼ばれる手法です）。「未経験と書かれているのに拾ってしまった」といった文脈の読み違いは、決まったルールでは判定しきれません。同じく言葉の意味を扱えるモデルに任せるのが現実的でした。 4分類は、見た目以上に悩んだ 判定にあたっては、スキル1件ごとにエラーを4種類へ分類する決定木を設計しました。 エラー種別 原点 設定理由 マスタ外 -15点 DB連携が不可能になる致命的エラー 過剰（無根拠） -10点 原文に根拠がないハルシネーション 過剰（文脈誤認） -8点 「未経験」などの文脈の読み飛ばし 不足 -5点 網羅性は下がるがリカバリ可能 並べてしまえば単純な4分類ですが、ここに至るまでがいちばん頭を使ったところでした。 分類の切り口も粒度も、選択肢は無数にあります。細かく分ければ分析はしやすくなる一方、判定はブレやすくなる。粗くまとめれば安定はしますが、改善のヒントが得られません。 意識したのは、 説明可能であることと、論理的にMECEであること の2点でした。最終的には「まずマスタに存在するか」で切り、存在するものについて「不足か・過剰か・正常か」を判定し、過剰をさらに「原文に根拠がない（無根拠）」と「原文の文脈を読み違えた（文脈誤認）」に分ける、という決定木に落ち着きました。この構造なら、どのエラーがどこに分類されるかを人に説明できますし、原因の切り分けにも直結します。 図4: 抽出されたスキル1件ごとに、エラーを4種類へ分類する決定木 減点の幅は、業務影響度（システムへの実害の大きさ）に応じてグラデーションをつけました。ここで効いてきたのが、先ほどの実データ分析です。 1人あたりの平均スキル数は約5個しかないため、1件あたりの減点を大きくしすぎると、数件の誤りですぐ0点に張り付いてしまい、精度の"差"が測れなくなります。 マスタ外を−15点、不足を−5点としたのは、影響度の順序を保ちつつ、スコアが飽和しない幅に収めるためでした。 「まず単純な形で動かす」という判断 じつは当初、もっと複雑な指標を構想していました。減点方式そのものに弱点があるからです。 スキル数が多い人ほど減点される機会が増えて不利になり、逆にスキル数が少ない人の1件の間違いは、相対的に軽く扱われてしまう。 これを補正するために、1件の誤りが重く効くF1スコアと掛け合わせた合成指標を組み立てられないか、と考えていました。 しかし現場の社員の方に相談したところ、返ってきたのは「いきなり複雑にする必要はない」という助言でした。 まず単純な形で動かし、必要になったら足していく。 実際、F1スコアの算出には「完全に正しい正解データ」を大量に用意する必要があり、正解づくり自体が難しい今回のケースでは、そこで手が止まってしまう可能性も高いものでした。結果として「まずは自前の減点スコアで、素直に差分を見られる形から始める」と割り切りました。 この判断は、9日間で得た学びの中でもかなり大きいものでした。設計として"正しそう"なものと、限られた時間の中で"前に進むもの"は、必ずしも一致しない。 「なぜこの配点なのか」を自分の言葉で説明できる状態を保ちながら、まず動かす ことを優先しました。 評価者は、正しく評価できているのか ここも大きな山場でした。評価基盤を作っても、 その評価者であるLLMが信用できなければ意味がありません。 そこで用いたのが、 答えを先に仕込んでおく という手法です。たとえば「正解率80%になるよう意図的に崩したデータ」を評価者にかけ、本当に80%前後を返してくるかを見る。返ってくれば、その評価者はある程度信用できると判断できます。実際、100%・80%・20%相当に作ったデータに対し、評価スコアは100%・83%・21%と狙いに近い挙動を示しました。 この考え方を土台に、 ゴールデンデータ100件 を用意しました。内訳は、実データから目視で正解を定義したもの25件と、文字数の偏りやマスタ表記のばらつきといった実データの特徴を踏まえて作成した合成データ75件です。 プロンプト改善で、評価の誤りは102件から67件へ あとは、ひたすら試行錯誤です。ゴールデンデータ100件に対して評価LLMを走らせ、正解との食い違いを数え、プロンプトを書き換えてはまた回す。文言レベルの調整を何度も繰り返し、その中から 方針として大きく異なる3つのバージョン を比較しました。結果、食い違いの総数は 102件 → 75件 → 67件 と着実に減っていきました。 図5: 3回の試行で、評価の誤りは102件から67件へ ここで数えている「エラー」は、抽出LLMのミスではなく、 評価者であるLLMが正解と違う判定をしてしまった件数 です。そもそも評価の仕組みがなかったので、この102件という数字自体、物差しを作って初めて見えるようになったものでした。正解スコアとの差分（Delta Score）の分布も、試行を重ねるごとに「差ゼロ＝完全一致」の山が高くなり、評価が正解に寄っていく様子が数字で見えたときは素直に嬉しかったです。 図6: プロンプト改善で、評価が「正解との一致」に寄っていった 一方で、すべてがうまくいったわけではありません。内訳を見ると、文脈誤認（19→0→2件）や無根拠の過剰抽出（11→1→5件）は大きく改善したのに、 「取りこぼし（不足）」だけは69→71→57件となかなか減らない。 ここは最後まで残った宿題です。 学びと今後 技術面での最大の学びは、 「LLMを評価すること」は「LLMを使うこと」と同じくらい難しい という実感でした。正解の定義、評価者の妥当性検証、指標選び——そのどれもが、決まった正解のない設計判断の連続です。 そしてそれ以上に大きかったのが、 「なぜその数字なのか」を説明できることの重要性 です。「閾値が妥当かどうかは、最後は現場の肌感でしか判断できないドメインもある」ということも学びました。数字を出して終わりではなく、その理由を言葉にして初めて他の人と議論できる。当たり前のようで、実務の現場で強く実感したことでした。 やり残した課題も明確です。プロンプトのさらなる改善（トークン効率、長文・短文を分けた処理）、評価対象である抽出プロンプトやマスタデータそのものの改善、そして評価基盤をダッシュボードとして常時監視できる形につなげること。ここから先は、ぜひ挑戦してみたい領域です。 おわりに 非構造化データを構造化できたことはゴールではなく、その品質を測り続けられて初めて運用に乗る。 これが9日間で得たいちばんの結論です。 LLMをプロダクトに組み込む事例が増えるほど、「その出力が正しいかをどう測るか」という問題は必ずついて回ります。LLM as a judge という手法に、実際のプロダクトのデータを使って取り組めたことは、とても良い経験になりました。モデルを作って終わりではなく、運用しながら品質を測り続ける——いわゆるLLMOpsの入口にあたる部分を、実務として体験できたのも大きな収穫です。 チームの雰囲気も印象的でした。方針に迷って相談すると、一緒に考えたうえで「まずは単純な形から始めてみよう」と具体的な指針をもらえる。学生の自分に対しても、判断の理由まで含めて丁寧に議論してもらえたことが、最もありがたく感じた点でした。 ランチにもよく連れて行っていただきました。毎日違う社員さん4人ほどと、渋谷のいろいろなお店へ。中でも釜飯のお店は強く印象に残っています笑。日替わりでいろいろな方とお話しできたので、単純に楽しかったですし、キャリアの選び方や仕事の進め方についても興味深い話をたくさん聞けました。 短い期間でしたが、"答えのない問題"に現場の方と一緒に向き合えたことは、大きな財産です。

はじめに 　レバレジーズ株式会社 テクノロジー戦略室 SRE チームの中野です。レバレジーズでは「SRE 化を通して、Developer Experience の改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する」をミッションとして、サービス改善の文化的土俵の構築や開発生産性の向上を進めています。 　過去記事 (= Terraform による IaC の標準化を通じた、全社規模の開発体験の向上への取り組み ) では、社内標準となる IaC ツールの選定と、IaC 化の作業負荷の軽減を狙ったライブラリ・テンプレートの作成についてご紹介しました。 　今回はその続編として、これらの製品を Template as a Service として提供する中で見えてきたユーザペインと、AI Agent Skills によるペインの解消・製品強化の取り組み、そして今後の展望についてご紹介します。 　現在、SRE・Platform Engineering の取り組みで Template as a Service を社内展開しているが、製品を使いこなすまでのハードルが高く製品普及が思う様に進まない。この様なペインを抱える開発組織の参考になれば幸いです。 　なお、本記事で紹介する取り組みは、2026年4月開催の AWS Container Platform Engineering Meetup のパネルディスカッションでご紹介した話の詳細版です。当日話し切れなかった部分を本記事でお伝え出来ればと思います。 背景 　現在は、下表の Template as a Service を提供中です。初めにインフラ作業の効率化・省力化を狙って Terraform Modules、GitHub Composite Actions、GitHub Repository Template を作成し、学習による知識強化も狙って Terraform Handson というハンズオン形式の学習教材も作成しました。これらの製品により、IaC 化推進の環境を整えてきました。 提供製品 概要 Terraform Modules (AWS Provider 向け) ELB・ECS・RDS 等の単体リソースに対応する Component Modules、CloudFront・WAF 等の複数のリソース群を組み合わせた Catalog Modules の2種類がある GitHub Composite Actions Terraform 用の CI/CD、アプリ用の CI/CD 等の共通処理をパッケージ化したものが多い GitHub Repository Template (Terraform 向け) Terraform Backend の環境構築、CI/CD 用の IAM リソース設定、Slack 関連設定、アラート用のリソース設定等の手順・設定を同梱しており、IaC 導入時の初期作業を低工数で済ませられる Terraform Handson Terraform 用のハンズオン教材であり、Terraform の基礎から発展までを短期間で学習出来る 　一方、製品利用が進むにつれて、製品の改善点が見え始めました。以下は、ヒアリングやフィードバックを通して得られた代表的なペインです。 　当初は Embedded SRE 等の手慣れたエンジニアを対象に製品のファンを増やすことを目的としていましたが、今後のユーザ拡大を考えると、ペインを解消して製品の使い勝手を強化することを優先すべきだと考えました。 Terraform Modules モジュールの使い方や必要な変数の組み合わせが、仕様や利用例だけでは判断しにくい モジュール毎の使い分け基準は書かれているが、どのモジュールを使うかの判断が難しい GitHub Repository Template 初期整備の手順資料・作業工程が多く、作業全体の流れや進捗を把握しにくい 設定項目が多く、必須なものが分からないため、何を埋めるべきか判断しにくい AI の活用方針の検討 　社内では AI Agent の利用が広がっており、これを活用すれば作成コストを抑えながらペインを十分に解消可能だと考えました。実際、社内要件・命名規則やクラウドのベストプラクティスに沿って提供製品が作り込まれており、AI による代行が十分に可能でした。そこで、AI Agent Skills の作成を決めました。 　次に、先述のペインを起点に Skill で解決可能なことを整理して製品案を考え出し、次の基準をもとに作成優先度を決めました。その結果、下表の「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」を高優先で作成すべきだと判断し、これらの作成から始めることにしました。 作成優先度の決定基準 ペインの程度や発生頻度 負荷・コスト等の削減効果 直近の利用予定、社内要望 作成候補の優先度一覧 作成候補 優先度 対象者 判断理由 コード生成 Skill 高 ユーザ Terraform コードの実装・修正が他の作業よりも高頻度である 初期整備 Skill (GitHub Repository Template 用) 高 ユーザ IaC 関連の初期作業のみの利用だが、自動化の効果が大きい スタイルガイド Skill、 製品仕様ガイド Skill 中 ユーザ 運用フェーズでの実装・仕様把握の負荷を継続的に下げられる モジュール開発 Skill、 コードレビュー Skill 中 メンテナー 開発・レビューの作業負荷を下げ、省力化・体制分散に繋がる Terraform Ops Skill、 コスト試算 Skill、 インフラ構成図 Skill 低 ユーザ、メンテナー 発生頻度・現在の負荷が比較的小さく、将来の開発対象とする AI Agent Skills の作成 　ここでは、高優先で作成した「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」の概要・ワークフローや設計・工夫についてご紹介します。 　前者は Terraform Modules の「使い方・使い分けの判断が難しい」というペインに、後者は GitHub Repository Template の「初期整備の工程が多く進捗や設定値の判断が難しい」というペインに、それぞれ対応するものです。 Terraform コード生成 Skill (AWS / Google Cloud) 概要・ワークフロー 　Terraform コード生成 Skill とは、ユーザへのヒアリングに基づいて Terraform コードを生成する Skill です。AWS・Google Cloud の Provider 毎に Remote Skill (= terraform-codegen-aws / terraform-codegen-google ) として提供しており、EC2・RDS 等の単体サービスから、静的サイト (CloudFront・WAF・S3) や Web システム (ALB・ECS・RDS 等) といったインフラ構成のコードまで生成出来ます。処理フローは次の通りです。 No ステップ 概要 1 ユーザへのヒアリング サービス名・環境名・リージョン等の要件情報を聞き出し、必要なインフラリソースを洗い出した上でリソース設定の追加確認を行う 2 Terraform コードの生成 ヒアリング結果に基づき、必要なインフラリソースに関する Terraform コードを生成し、実行場所にコードを書き込む 3 Terraform コードの検証 生成したコードに対して terraform fmt/validate のコマンドを実行し、エラーが無くなるまで検証・修正のサイクルを繰り返す 4 完了報告と追加確認 設定の判断理由を含めて作業結果を報告し、コードの追加・修正の要望を確認する 　ヒアリングでは、推測可能な情報は聞かないことを原則として、要件等の推測が難しい情報だけを AI Agent がユーザへ確認します。また、どのリソース・モジュールを用いるか、変数設定をどう組み合わせるか等のコード生成に必要な判断を AI Agent が担います。この様な設計により、ユーザの確認負荷を抑えています。 　コード生成では、下記の優先順位で生成方法を選択します。terraform-codegen-aws は、該当する社内向け Terraform Modules があれば必ず利用し、無い場合はモジュールを用いずに生成します。一方、terraform-codegen-google は、社内向け Terraform Modules を提供していないため、モジュールを用いない生成を基本としています。 　なお、Public Modules の利用については、両方の Skill に共通で、バージョン更新時の追従負荷を考慮して要望があった場合のみ利用可能なオプションとしています。 terraform-codegen-aws の生成方法の優先度 (a) 社内向け Terraform Modules を利用する (b) モジュールを用いずにコードを生成する (c) Public Modules を利用する (要望時のみ) terraform-codegen-google の生成方法の優先度 (a) モジュールを用いずにコードを生成する (b) Public Modules を利用する (要望時のみ) 　この優先順位には、社内標準の資産を AI のコード生成経路そのものに組み込む狙いがあります。ユーザが社内モジュールの存在や使い分けを知らなくても、生成されるコードは自然と社内標準に沿ったものになり、個々のエンジニアの習熟度に依存していた社内標準への準拠を仕組みの側で担保出来ます。 設計・管理のポイント 　各々の Terraform コード生成 Skill に共通する設計・方針の枠組み (= SSoT の管理方針、検証の実施方針等) を定めており、これに基づいて各 Skill が作り込まれています。 　まず、Skill では SSoT の管理方針を明確に決めています。モジュールの仕様・バージョン等は外部情報として Skill 内で持たずに CLI コマンドで取得し、ヒアリングの進め方・コーディング規約・組織固有の情報等は Skill 内で参照情報やテンプレートとして管理します。この方針で外部情報の更新への Skill の追従が最小限になり、Skill の管理・運用のコストを抑えられました。 　また、参照情報を取得出来なかった場合に AI が推測で値を埋めることを禁止しており、ユーザへの確認に基づくコード修正かプレースホルダの残置に必ず倒す設計としています。 　コード検証では、 terraform plan の実行を意図的にスコープ外としています。コード生成の段階では静的なコード検証さえパスすれば問題無く、クラウド上での検証までスコープを広げると検証が複雑になり、副作用のリスクが生まれると考えたからです。そのため、 terraform fmt/validate の実行によるコード検証として設計しています。 動作検証時の挙動改善 　動作検証で、簡単なコード生成でも一律に時間・トークンを大きく消費するという挙動面の課題が判明しました。実測したところ、主な原因は「参照情報を何度も取得しに行っていること」及び「簡単なコード生成でも複雑な手順で処理していること」にあり、次の改善を行いました。 　これらを「修正、検証、品質チェック」の処理サイクルで適用したところ、ユーザの入力・待機等を除いた処理自体の所要時間やトークン消費を、改善前よりも 30% 〜 40% 程度削減出来ました。 参照情報の取得方法の見直し 参照の度に発生していた取得処理を、最初に一括で取得・保存する方式に変更した 参照情報の取得の繰り返しを防ぎつつ、必要な情報を適切・十分に参照可能にした 生成内容に応じた処理の使い分け コード生成の進め方に応じた処理群のパターン分けを、生成モードとは別に設けた 生成処理の複雑さに応じて処理パターンを当てはめ、適切な処理をさせる様にした 機械的なチェックへの移行 文章ルールに基づくチェックを、スクリプトを用いたチェック処理に置き換え、照合のやり取りを削減した チェックルールは機械可読な一覧表で管理し、ルールの追加・変更が表の編集だけで済む様にした AI モデルの能力や実行毎のばらつきに品質が左右されにくくなり、安定化に繋がった GitHub Repository Template の初期整備 Skill 概要・ワークフロー 　初期整備 Skill は、Terraform 向け GitHub Repository Template から作成した GitHub Repository の初期整備を AI Agent が代行する Skill です。現在提供中の4種類の Repository Template に Local Skill (= terraform-repo-init ) として導入しており、Repository の作成後に Skill を発動するだけで初期整備を簡単に進められます。 　この Skill により、人間が対応すべき箇所は「ヒアリングへの応答、残りの限られた手動作業の消化」だけに絞られ、その他の作業を AI Agent が代行してくれます。手順書に沿った作業で起きがちなミスも、スクリプトを用いた機械的なチェックにより極力発生しない様にしています。処理フローは次の通りです。 No ステップ 概要 1 ユーザへのヒアリング 構成・仕組みの要否 (= 開発環境、定期チェック、通知設定) や設定値等の初期整備で決めるべき情報を冒頭で一括して確認する 2 クラウド認証の確認・実施 実行環境やクラウド認証の状態を確認し、未認証だった場合に認証コマンドを実行する 3 初期整備の自動実行 雛形の削除、テンプレート情報の置換、Terraform Backend の環境構築、GitHub Repository Secrets の登録、CI/CD の有効化、作業のセルフチェック等の自動化可能な作業を実行し、GitHub PR の作成まで進める 4 残作業リストの出力 実行するだけで済む様な文面・スクリプト等を用意した上で、残りの手動作業に関するチェックリストを出力して終了する 設計・管理のポイント 　Repository の初期整備には、自動化が難しい作業 (= 外部への依頼・承認等) や、統制の観点から人間が担うべき作業 (= 秘匿情報の設定、PR のマージ判断等) が含まれます。そこでまず、AI Agent とユーザの作業分担を明確に定めました。 　具体的には、環境検証・テンプレート置換・Backend 構築・Secrets 登録・PR 作成までを AI Agent が実行し、それ以外の作業は意図的に人間側に残しています。この線引きが、AI による作業代行を安心して組織展開するための前提だと考えています。 　この分担を前提に、自動化可能な作業を先に進めて手動作業を最後にまとめる形へ作業全体の流れ・手順資料を再整理し、初期整備の自動実行とユーザへの残作業の提示を AI Agent に行わせる Skill を作りました。どの工程でも開始時に完了状態・前提条件・スキップ条件等を確認してから進行させる様になっており、途中で中断した場合でも安全に再開出来ます。 　なお、コード生成 Skill と同様に SSoT の管理方針も定めています。手順・コマンド等の具体値は Repository Template の資料・スクリプトを SSoT として参照し、Skill 自体は判断ロジックと工程の順序のみを持つ構成としています。 Skills の管理・配布 　Terraform コード生成 Skill は、特定の GitHub Repository に依存しない用途のため、Skill 専用の GitHub Repository で Remote Skill として管理しています。一方、GitHub Repository Template 用の初期整備 Skill は、Template 内の手順資料・スクリプトと一体で動く用途のため、Template 内で Local Skill として管理しています。 　配布についても、管理方式に合わせて分けています。Terraform コード生成 Skill は GitHub CLI コマンド ( gh skill install ) で利用可能にしており、GitHub Copilot・Claude Code 等の AI Agent 間の仕様差異を GitHub CLI が吸収してくれるため、統一的な手順で配布出来ます。初期整備 Skill は、Template から Repository を作成した時点でそのまま利用可能なため、配布作業が不要です。 今後の展望 　今後は、作成候補の優先度一覧で中優先以下とした Skill を順次作成し、ユーザ向けのインフラ作業のペイン解消だけでなく、製品メンテナーの開発・改善における作業負荷の軽減にも AI を活用していく予定です。これにより、Template as a Service の提供サイクルを現在の開発体制でも十分に回せる様に強化したいと考えています。 　過去記事では「Template as a Service を作り、IaC 化を推進する」をご紹介しました。今回は「AI Agent が Template as a Service を使いこなし、エンジニアの代わりに作業する」への進化をご紹介しました。Template as a Service × AI の組み合わせで、AI を前提としたゴールデンパスを引き続き提供し、利用の障壁の無いプラットフォームへと育てていきます。 最後に 　レバレジーズでは、全社の SRE・プラットフォームエンジニアリングの推進に向けて、開発生産性の向上に一緒に取り組んでいただけるエンジニアを募集しています。 　SRE の文化・体制に興味があったり創っていきたい方や、プラットフォームエンジニアリングの実践による開発生産性の向上に興味がある方は、是非ともご応募をお待ちしております。

レバレジーズで AWS AI-DLC Unicorn Gym を実施しました レバレジーズでは、開発プロセスにAIをより深く組み込む取り組みの一つとして、AWS AI-DLC Unicorn Gymを実施しました。 これまでAI活用というと、実装補助やコード生成、ドキュメント作成など、個人の生産性向上に寄った使い方が中心でした。 一方で、実際のプロダクト開発では、要件定義、仕様のすり合わせ、デザイン、実装方針の決定など、チームで意思決定する場面が多くあります。 今回のAI-DLCでは、AIを単なる作業補助ではなく、チーム開発のプロセスそのものに組み込むことを目的に、PdM、デザイナー、エンジニアが一緒に参加し、実際のプロダクト課題を題材に3日間取り組みました。 この記事では、AI-DLCの概要、当日の進め方、参加チームの感想、そして推進者として感じた手応えを紹介します。 AI-DLCとは AI-DLCは、AWSが提唱するAI駆動開発ライフサイクルです。※1　AIを単なるコード生成ツールとして使うのではなく、要件整理、作業計画、仕様検討、実装、レビューといった開発ライフサイクル全体に組み込み、人間が重要な判断を行いながらAIと協働して開発を進める考え方です。 ※1：Amazon Web Services,Inc.：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築（ https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/?utm_source=chatgpt.com ） 今回のイベントでは、各チームが実際のプロダクト課題を持ち寄り、AIとの壁打ちを通じて要件や仕様を整理しながら、最終的な成果物の作成を目指しました。 当日の流れ 1日目 1日目の午前中は、AI-DLCの考え方や進め方を学ぶ時間でした。 午後からは各チームに分かれ、実際のプロダクト課題を題材にしながら、ユーザーストーリーの作成を進めました。 最初は、AI-DLCとしてどのように進めればよいのかを掴みきれておらず、これまでの開発と同じように人間中心で議論を進めてしまう場面もありました。 ただ、AWSの皆さまからAI-DLCとしての動き方や、AIをどのタイミングでどう活用していくかをアドバイスいただくことで、少しずつAIを開発サイクルの中に組み込んだ進め方に変わっていきました。 この日のゴールは、AI-DLCの進め方を理解したうえで、各チームが扱うテーマをユーザーストーリーとして整理することでした。 2日目 2日目は、1日目に作成したユーザーストーリーをもとに、開発対象を具体的な作業単位に落とし込む Unit of Work の作成を進めました。 また、14時からは中間報告会を実施しました。各チームがどこまで進んでいるのか、どこで詰まっているのか、どのようにAI-DLCを進めているのかを共有し、チーム間でナレッジを交換する時間になりました。 2日目になると、各チームともAI-DLCの進め方に少しずつ慣れてきました。1日目は人間が考えた内容をAIに補助してもらうような使い方が中心でしたが、徐々にAIに問いかけてもらいながら論点を整理したり、AIに案を出してもらったうえでチームで判断したりする動きが増えていきました。 この日のゴールは、ユーザーストーリーをさらに具体化し、実装に着手できる状態まで進めることでした。 3日目 3日目は、17時からの成果発表会に向けて、各チームが成果物の作成を進めました。 最終日ということもあり、限られた時間の中で成果物を形にしなければならないプレッシャーもありました。その中で各チームは、要件整理や実装方針の確認だけでなく、実装や発表準備にもAIを積極的に活用しながら開発を進めていました。 1日目と比べると、AIを「必要なときに使うツール」としてではなく、開発を前に進めるためのチームメンバーのように扱う場面が増えていたように感じます。 最後に成果発表会を行い、各チームが作成したユーザーストーリー、Unit of Work、プロトタイプ、AI-DLCを通じて得られた学びを共有しました。 感想 ここからは、実際にAI-DLCに参加した各チームの感想を紹介します。チームごとに題材や進め方は異なりましたが、それぞれの立場からAI-DLCを通じて感じたことをまとめています。 teratail teratailでは、以前から仕様駆動開発を試した経験がありました。そのときは、人間が仕様を考え、AIが実装するというスタイルでした。 一方で、AI-DLCでは仕様を作成する段階からAIが質問を投げかけ、PdM・デザイナー・開発者が全員で意思決定していく点に新しさを感じました。 AI-DLCのよかった点は、議論の過程と意思決定が自然とドキュメントに残っていくことです。フェーズが進んでも、なぜその設計にしたのかを辿れる安心感がありました。 一方で、今回はUI/UXの刷新という大きなテーマだったため、意思決定の量が膨大になり、判断が追いつかない場面もありました。今後は、ドキュメントをHTML/CSSで整形したり、図式化したりして読みやすくすることや、レビュー観点自体をAIに整理させることなど、人間が判断しやすくする工夫が必要になりそうだと感じました。 レバテックプラットフォーム レバテックプラットフォームチームでは、今回はUX改善も含めたシステムリプレイスを題材にAI-DLCを行いました。 これまでの開発では、ディレクターや開発PMなど一部のメンバーで要件を決め、それを他メンバーに共有する進め方が中心でした。 AI-DLCでは、Inceptionフェーズにメンバー全員で要件定義を実施することで、要件の認識合わせにかかるリードタイムが短くなり、認識齟齬による手戻りも減らせたように感じます。 一方で、既存のレガシーシステムの仕様を明らかにするのに時間がかかりました。新規機能開発と比較すると、既存システムのコンテキストを事前に整備しておくことが重要だと感じました。今後チームでAI-DLCに取り組むうえでも、コンテキスト整備は重要になりそうです。 レバテックダイレクト レバテックダイレクトチームでは、チーム一丸となって取り組んでいる感覚が強く、メンバー全員で楽しく実施することができました。また、議論や意思決定の内容がドキュメントとして自然に残っていく点もよいと感じました。 一方で、今回は完成まで至らなかったため、結果としてうまくいったと言い切るのは難しい部分もあります。ただ、普段よりも細かく合意形成を行えたことで、常にチーム内の認識を揃えながら進められた点はよかったです。 うまくいかなかった点としては、モック作成後に後追いでデザインを作成したため、手戻りが発生してしまったことがあります。また、役割によって忙しい時間と待ち時間に差が出てしまう場面もありました。 チームとして取り入れる場合、要件を詰め、デザインが固まった後にAIにコードを書かせる進め方がよいのか、それとも要件やデザインが完全に固まっていない状態でも、まずAIにコードを書かせ始める進め方がよいのかは、まだ判断が難しいと感じています。前者が正しい進め方であれば、AI-DLCは非常に有効に使えると思いました。 レバテックルーキー レバテックルーキーチームでは、当初は抽象的なアイデアからのスタートでしたが、AIにチェックリストの作成や問いかけを促すことで、今までにないアプローチを試すことができました。 AIとの壁打ちを通じて、イメージが徐々に具体化し、思考がクリアになっていくプロセスの有用性に驚きました。 開発面では、モバイルアプリチームが先行してAI-DLCを導入していたため、その知見を活かすことで非常にスムーズに進めることができました。一方で、「どのフェーズで、どこまで具体的な指示を出すべきか」「どのタイミングで既存のリポジトリやコード情報をAIにインプットさせるべきか」といった、コンテキスト共有の粒度とタイミングのコントロールには課題が残りました。 現在、当チームでは開発スタイルの刷新を進めています。具体的には、ストーリーワークショップ、PBR、タスク分解、プランニングポーカーの進め方を見直し、AI-DLCを実践するための枠組みへ移行しています。 なお、デイリー、プランニング、レトロスペクティブなどの各種スクラムイベントは継続します。これにより、継続的なコミュニケーション、優先度の決定、成果物報告、振り返りのプロセスは維持していく方針です。 AI推進者: 苑田 AI-DLCを通して、チームメンバーがAIを前提に開発を進めている感覚を共有でき、個人的にも実施してよかったと感じました。 私は推進者なので実際には手を動かしていないのですが、PdM、エンジニア、デザイナーの3職種のチームを横で見ていて、ものすごく手応えを感じました。論点の洗い出しや初期案の作成をAIに任せることで、人間はゼロから考える時間よりも、選択・判断・修正に時間を使えるようになりました。その結果、議論の立ち上がりが早くなり、開発スピードが上がった感覚があります。 特に、長時間席を離れる際も、「AIにタスクを渡してからご飯行こうか」というやり取りが見られたのは、AI推進者としてもすごく印象的でした。 AI-DLCは単に開発サイクルを良くするだけではなく、AIに対する認識自体を変えるすごくいい方針だなと思ったので、これからも推進していきたいです！ 推進者: 山川 全チームで AI を使う範囲を広げようとする行動が多くなり、推進者としてとても嬉しく思います。 参加したチームからは、1つのイベント参加に留めず、今後も継続して取り組んでいこうとする動きも生まれてきました。例えば、開発プロセスやスクラムイベントの見直し、チーム関係者との業務調整、他チームへのコーチング、リモートワークでどうやって導入するか、などを自律的に検討しながら進められており、AI-DLCへの大きな期待を感じます。 今回の AWS AI-DLC Unicorn Gym 実施に向けて、推進者として調整や準備などは大変だったものの、チームや組織に大きな動きが生まれて開催してよかったと思います。今後は、より多くのチームが AI-DLC を体験して導入していけるように、社内イベントの開催といった推進活動にも注力していければと思います。 まとめ 今回のAI-DLCは、単に新しい開発手法を試すイベントというより、レバレジーズとしてAIを開発プロセスにどう組み込んでいくかを考える良い機会になりました。 実際に複数のチームで取り組んでみることで、AI-DLCは「決まった手順をそのまま導入すれば終わり」というものではなく、チームの体制、扱うプロダクト、既存システムの複雑さ、関わる職種によって、最適な進め方を調整していく必要があることも分かりました。 一方で、AIを開発の一部として自然に使う体験をチームで共有できたことは、今後のAI活用を広げていくうえで大きな意味があったと感じています。個人の作業効率化にとどまらず、チームでの認識合わせや意思決定、開発プロセスの見直しにまでAI活用の範囲を広げられる可能性が見えてきました。 今回得られた学びをもとに、今後は各チームの開発スタイルに合わせたAI-DLCの取り入れ方を整理し、より実践しやすい形で社内に展開していきたいです。 We are hiring! 最後までお読みいただき、ありがとうございました。レバレジーズでは、AIを個人の作業支援にとどめず、チームの開発プロセスに取り入れる取り組みを進めています。こうした取り組みに興味を持っていただけた方は、ぜひ採用情報もご覧ください。 HRMOS求人ページ 会社説明資料

はじめに こんにちは。レバレジーズ株式会社で研究員をしている永安です。普段は人材領域の推薦システムやLLMによる自動評価に関する研究開発に取り組んでいます。 2026年6月8日〜12日にGメッセ群馬で開催された、第40回人工知能学会全国大会（JSAI2026）に参加し、「人材領域における反実仮想機械学習を用いた相互推薦システムの説明手法」というテーマで発表してきました。 この記事では、JSAI2026全体の雰囲気と、私が個人的に面白いと感じた研究のトレンドを紹介します。事業会社の研究員の目線から見たJSAIの空気感が、これから参加を考えている方に少しでも伝われば嬉しいです。 ブースの様子 JSAI2026の全体の雰囲気 JSAI（人工知能学会全国大会）は、国内のAI研究者が一堂に会する最大級の学会です。今年は第40回・40周年の節目の大会で、Gメッセ群馬を会場に5日間のハイブリッド開催。前回のJSAI2025（大阪）が約5,000名規模だったこともあり、今年も国内最大級の盛り上がりでした。 参加して最初に感じたのは、企業のプレゼンスの大きさです。アカデミアの発表だけでなく、インダストリアルセッションでの企業発表や、展示ホールに並ぶ企業ブースが目を引きました。ブースでは各社のデータ活用やプロダクトの裏側が紹介されていて、休憩時間やレセプションでは企業関係者同士の交流もかなり活発でした。 個人的に大きかったのは、自分が研究している推薦（レコメンド）について、実際に業務で使っている方や、アカデミアで研究している方と密に話す機会を多く持てたことです。昨年参加したときは、チームが立ち上がったばかりで外に出せる成果がまだなく、話を聞いて回るのが中心でした。それが今年は、自分たちの取り組みとして話せるものを持って臨めたぶん、レコメンドを開発しているエンジニア、研究者と、一歩踏み込んだやり取りができたように思います。同じ推薦という土俵でも、事業側の制約や評価のリアルと、研究側の理論的な関心とでは見えている景色が違っていて、ブースや発表後の立ち話から得られる視点がとても多かったです。発表できるネタを持っていることが、こうした密度の高い会話の入り口になるのだと実感しました。 今年の大会全体を通して前面に出ていたのが、AIエージェントとPhysical AIです。LLMを核としたエージェント関連の発表・議論はあちこちで見られましたし、Physical AI（現実世界で身体を持って動くAI）も、スポンサー展示やチュートリアル講演を含めて大きな存在感を放っていました。 発表紹介：人材推薦の「希望の求人に行くには何を習得すると良いか?」に反実仮想で答える 人材領域の推薦は、「求職者→企業」と「企業→求職者」の双方向の好みを考える相互推薦（Reciprocal Recommendation）で、両者の嗜好の間には暗黙のトレードオフがあります。今回提案したのは、このトレードオフに説明性の観点から踏み込む反実仮想的な手法です。 コアは、「求職者自身は気に入っているのに、企業側のスコアが低くて推薦されない求人」に対して、求職者側のスコアを下げないという制約のもとで、企業側のスコアを押し上げるには何を変えればよいかを探索するという点にあります。これにより「あと何があれば、この求人に届いたのか」を提示でき、相互推薦のトレードオフを部分的に可視化できます。 このフレームワークで推薦結果を説明することにより、現時点でのユーザーに対する推薦だけでなく、ユーザーの将来のキャリアへのデータドリブンな助言をサービスに組み込むことが期待できます。 speakerdeck.com 気になった発表 大規模言語モデルエージェント間の社会的学習における文脈依存的パラメータ調整と相転移的振る舞い（堀部和也ほか／理化学研究所 環境が途中で変化する多腕バンディット課題をLLMエージェントの集団に適用し、各モデルの挙動に強化学習モデル（学習率・逆温度・社会的重み・同調指数など）を階層ベイズで当てはめた研究です。同質集団では、GPT-5.2は早期に探索をやめて多数派に同調し環境変化に固着する一方、Claude-Sonnet-4.5は探索を維持し、集団が大きいほど適応が良くなりました。さらに両者を混ぜると、GPT:Claudeが3:2→2:3になる一点で集団の適応可否がガラッと切り替わる、相転移のような閾値効果が現れます。Claudeが過半数になるとその探索が新しい社会的シグナルとなり、同調傾向の強いGPTが一斉に追従する、というモデルごとの傾向の違いが見られました。 感想 エージェントを使った調査ではLLMのコストが無視できず「どのモデルをどう分担させるか」が実務課題になりつつあります。その一般化された問いを綺麗な実験設定で示していた点が非常に良かったです。 Top-k方策分解に基づくランキング方策の効率的なオフ方策学習（R-POD）（岸本廉・田中滉一ほか／東京工業大学・慶應義塾大学) ログデータからランキング方策をオフ方策学習する問題で、従来は方策ベース（IPS）がランキング全体の重要度重みで分散が爆発し、回帰ベースは全ランキングの報酬推定が難しくバイアスが大きい、というジレンマがありました。R-PODは、ランキング方策を「上位k件を選ぶ第一段階方策」と「残りの下位を条件付きで選ぶ第二段階方策」に分解することでこれに対処します。第一段階は方策ベースの重要度重み付けを“ずっと小さいtop-kの行動空間”だけに適用して分散を大幅に抑え、第二段階はtop-kを条件とした残りの空間にのみ回帰を当ててバイアスを小さくする、という役割分担です。人工データ実験では、特にデータが少なく行動数が多い設定で、IPS-PGやDR-PGなどのベースラインを明確に上回りました。 感想 レコメンドではランキング全体を考慮することが重要で、上位と下位を分けてバイアスと分散を同時に抑えるという発想がとても綺麗でした。ランキングを考慮した最適化は自分の研究とも問題意識が重なり、特に学ぶところの多いポスターでした。 おまけ ホテル予約が遅れた 敗北者 研究員3人はAirbnbで民泊しましたが、焼肉パーティーで勝ちました。 研究員の作った漢料理 We are hiring! 最後までお読みいただきありがとうございました。会期を通して、推薦に関わる実務家・研究者の方々と密に交流でき、自分の研究を見つめ直すうえでも大きな刺激になりました。 レバレジーズでは、レバテックキャリアをはじめとする実サービスの現場課題を起点に、まだ方法論が固まっていない領域へ新しい手法を提案するような研究に取り組んでいます。実データ・実サービスと地続きでありながら、今回のように学会発表まで踏み込めるのは、事業会社の研究としては恵まれた環境だと感じています。 推薦システムや機械学習を専門に、「実データへのインパクト」と「研究としての新規性」の両方を追いたいという方は、ぜひ一度カジュアルにお話しできれば嬉しいです。 recruit.leverages.jp

はじめに こんにちは！26卒エンジニアで、2025年9月からレバレジーズで内定者インターンをしている谷口功樹です！ この記事を通して、 内定者インターンとしてTQCチームで活躍してきた 中で、僕がどのようにエンジニアとしての視点を広げていったのかを振り返ります。 突然ですが、皆さんは歩いている時、普段どこを見ていますか？ 転ばないように地面を見ていますか？ それとも、誰かとぶつからないように真っ直ぐ前を見ていますか？ 僕は、意識的に空を見上げるようにしています。かつて下ばかり向いていた自分が、いかに小さな世界に閉じこもっていたかに気づいてしまったからです。 空を眺めていると、自分の可能性も無限にあるような、そんな気がしてきます。 …と、いきなりこんな抽象的なことを語ったのには理由が当然あります。 今回のインターンで僕が感じた、まさにそんな自分の意思での 「視界と可能性の広がり」 をお伝えできればと思います！ 自己紹介 改めて自己紹介をさせていただきます。谷口功樹です。こんな普通の名前ですが、 実はアメリカ生まれのアメリカ育ちです！ 日本生活歴は、留学と夏休みの旅行を含めて合計2年くらいです。 大学ではコンピューターサイエンスを専攻し、主にAIや統計学を学んでいました。同時に、日本語と日本文化の授業も頻繁に履修していました。その縁もあり、2024年の春には京都大学へ留学していました。 なぜ日本で就職？なぜレバレジーズ？ その京都での留学が、僕にとって大きな転換点となりました。実際に日本で生活してみた中、自分のライフスタイルは日本に合っていると確信し、卒業後は 日本でキャリアを築きたい と考えるようになりました。 その上、就活を通して、アメリカと日本のソフトウェアエンジニア業界の違いを痛感したことも理由の一つです。現在のアメリカでは、AIの台頭もあって、新卒エンジニアの枠が爆速で縮まり、実際に僕もアメリカの企業から面接の案内をいただくことは一度もありませんでした。 アメリカの企業にとっての新卒は、将来への投資ではなく、単なる安価な労働力に過ぎなかったのではないかと、勝手ながらそんな風に感じてしまいました。一方で、日本の企業には、まだ若芽の可能性を信じて、ポテンシャルを育てようとする文化が残っているように見えました。 そんな中参加した 2024年11月のBoston Career Forumで出会ったのがレバレジーズでした。 面接で一番印象に残ったのは、会社側が「僕がどれほどの価値を提供できるか」だけでなく、「会社が僕にどんな経験を提供できるか」を真剣に考えてくれたことです。一方的な採用ではなく、お互いの成長を模索するその姿勢に惹かれ、2025年5月に卒業した直後、内定をいただき即承諾、そして9月から内定者インターンとして参加することを決めました。 インターン中の配属はTQCチーム！てかTQCって何？ インターン開始前の面談で、こんな質問をされました。 「将来正社員になった時にやるような業務（つまりサービス開発）、それともあえてやらなさそうなこと、どっちを経験してみたい？」 思わぬ質問に数秒間迷いましたが、今回のインターンにおける僕の目標はすでに明確でした。 日本での生活に慣れる 日本のビジネスカルチャーを知る とにかく新しいことを学ぶ そしてやはり、僕は「やらなさそうなこと」を選択しました。そうして配属されたのが、テクノロジー戦略室のTQCチームでした。 「...でTQCって何？」 と思われるかもしれません。少なくとも僕は思いました。TQCはTotal Quality Controlの略で、開発されているサービスやアプリの品質管理を行っており、現在はセキュリティと負荷・パフォーマンス領域に注力しております。ただバグを見つけるだけでなく、開発工数削減や顧客の信頼獲得、そしてビジネス面での損失回避など、会社を影から支える重要な役割を担っています。 品質向上への道 レバレジーズの内定者インターンとは、インターンっていうより、ほぼ正社員である。 もちろん正式な立場は「インターン」ですが、任される業務は周りのエンジニアとあまり変わりません。TQCチームの一員として、主に以下の3つの実務に取り組みました。 ペネトレーションテスト 攻撃者の視点に立ち、社内サービスの脆弱性を探りました。具体的には、Burp Suiteを使ってHTTPリクエストを解析・改ざんしたり、Pythonやシェルスクリプトを書いてテストを自動化したりしました。おまけで、各サービスの技術スタックを横断的に知る良い機会にもなりました。 やってみて一番驚いたのは、大手企業の開発チームが作ったプロダクトでも、完全に脆弱性を無くすことはできないと言うことです。もちろんTQCチームの充実したテスト項目のマニュアルがあったからこそ見つけられた面もありますが、最初は「初心者の自分でもこんなに簡単に見つけてしまえるのか」と驚くと同時に、この作業の重要性を強く実感しました。 負荷試験 負荷試験は2回しか実施しませんでしたが、その2回だけでも色々知識は得られました。 詳しくは 僕の上司が書いた記事 に全てありますが、流れをざっくり説明すると、ブラウザ操作を.harファイルとして保存し、JavaScriptで試験シナリオを記述できる負荷試験ツールである k6 が読み込める形式にhar-to-k6というライブラリで変換して実行するというものです。監視にはGrafana、Prometheus、AWS CloudWatchを活用し、ダッシュボードを自作するためにPromQLを、負荷がスケーリングにどう影響するか理解するためにKubernetesも少し学習しました。 特定の脆弱性を突くペネトレーションテストとは違い、負荷試験はサービス全体を俯瞰して捉えることが重要だと学びました。 自作のGrafanaダッシュボード インフラ構築 「とにかく新しいことを学ぶ」ため、未経験だったクラウドインフラ、Terraform、GitHub Actions（CI/CD）をセットで扱える課題を上司に頼みました。 具体的には、GitHub ActionsとTerraformを連携させてAWS上にApacheサーバーを立ち上げ、任意のDockerコンテナを稼働できる環境を構築しました。そして運用性を考慮し、CloudWatch Logsで簡単にログを確認できる仕組みも併せて実装しました。 この構築作業はインフラの基礎を体系的に学ぶ良い機会となっただけでなく、後述するAIエージェントの検証環境としても、重要な役割を果たすことになりました。 いよいよ実践！ペネトレーションテスト自動化エージェントの開発 そして、今回のインターン期間の集大成は、PythonとGoogle ADK（Agent Development Kit）を駆使した、 ペネトレーションテスト自動化エージェントの開発 でした！ 簡単にいうと、AIにぺネトレーションテストを自律的に行ってもらうツールなのですが、単にプロンプトを投げて暴れてもらうだけではありません。エージェントがただ闇雲に動くのではなく、論理的に動くための設計に、力を入れました。 大学でAIや統計学を履修していたとはいえ、AIの数学的な理論や基礎的なアルゴリズムの学習が中心だったので、LLMやエージェントの実装は、 僕にとって全く新しい挑戦でした。 開発に着手して真っ先に直面したのが実行基盤の選定で、Google Cloudの利用を前提としつつ、ネイティブな管理環境ながら10分でタイムアウトしてしまうVertex AI Agent Engineや、1時間制限のCloud Run Serviceでは長時間のスキャン要件を満たせないことが分かりました。最終的には、最大1週間の実行が可能なCloud Run Jobsを採用するという判断を経て、ようやくエージェント本体の開発へと進むことができました。 1. 有向二部グラフで構造化する まず、エージェントの思考プロセスを、「タスク」と「発見」という2種類のノードで構成される有向二部グラフとして定義しました。 ToolAgent（実行役） : 割り振られた「タスク」を実行し、その出力結果から脆弱性の手がかりとなる「発見」を抽出します。 PlanningAgent（計画役） : 得られた「発見」を分析し、次に行うべき「タスク」を新しく生成します。 キューやスタックは実行順序を管理するための一時的なものですが、グラフは調査の論理そのものを蓄積するために存在します。木構造ではなくグラフを採用することで、複数の調査経路が同じ結論に辿り着いた際に情報を集約し、後続タスクの重複発生を抑えられるようになりました。さらに、ノードをタスクと発見に分ける二部グラフの制約を設けることで、実行と計画という役割を分離し、事実に基づかない計画を防いでいます。これらを有向の依存関係で結ぶことで、どの発見がどのタスクに起因したのかという因果関係を正確に記録し、診断の履歴を遡れる仕組みを整えました。 この 「タスク → 発見 → タスク」 という再帰的なサイクルをグラフ構造に落とし込むことで、複雑な攻撃ルートを論理的に切り開いていく仕組みを構築しました。 2. 評価関数で枝刈り 無限に広がる探索ルートを制御するため、評価関数を実装しました。 f(n) = h(n) - g(n) h(n) = 目標とする脆弱性の深刻度 g(n) = (1 - 親発見のスコア) * 親の累積コスト + 当タスクのコスト g(n)は、親ノードである「発見」の重要度を反映します。親の重要度が低いほどコストが跳ね上がる設計になっており、計算結果が閾値を下回ったタスクは実行価値なしとして破棄されます。 これにより、重要なルートのみを効率よく辿ることができます。 3. コールバック関数を用いたLLMのトークン管理 ペネトレーションテストの実行は数時間に及ぶことを想定 していたため、情報の取捨選択をしなければ一回のセッションで消費される入力トークン数は数百万規模に膨れ上がり、 コストの増大やコンテキストの上限超過を招くことを確認しました。 この課題を解決するために、 Google ADKのコールバック関数を活用しました。 コールバック関数とは、LLMの推論やツールの実行の前後のタイミングで、あらかじめ指定しておいた独自のプログラムを自動的に実行させる仕組みのことです。 これを用いることで、LLMに送る情報やメタデータをプログラム側で編集できるだけでなく、出力される情報の検証や加工も可能になります。 まずモデルへリクエストを送る直前に、過去のタスクのメッセージ履歴を全て削除する処理を実装し、エージェントが外部の情報に惑わされず、現在の作業のみに集中できる環境を作りました。 また、ツールの呼び出し回数が上限に達した際には、モデルからツール定義自体を剥奪して強制的に結果報告へ移行させる制御も行っています。 出力側では、ツールから返ってくる実行結果を外部ストレージに保存し、LLMに先頭の2000文字のみを渡すことでトークン消費を大幅に抑制しました。 そして、例えば何もツールを使わずに回答しようとしたりした場合には、空のリストを強制的に返却させて実行を正常に終了させるガードレールも設けています。 こうした 入出力管理が、エージェントを実用的なコストと精度で長時間稼働させるための鍵 となりました。 トークン費用の比較 4. フロントエンド フロントエンドは、Pythonでwebアプリを構築できるフレームワークである Streamlit を採用し、スキャン設定管理や進捗確認が可能な管理画面を構築しました。 上記で話したグラフを可視化するため、StreamlitのReactコンポーネントとしてD3.jsと React Flowを組み込み、エージェントの思考が広がっていく様子をリアルタイムで描画できるようにしました。 5. 動作確認 前章で構築したAWS環境に、わざと多数の脆弱性を含ませたセキュリティ学習用のデモアプリである OWASP Juice Shop をデプロイし、エージェントを走らせました。可視化したグラフが広がっていく様子を眺めていて、 インターン期間中に取り組んできたすべてが、この一つの完成したプロジェクトへと繋がっていて 、すごい達成感を感じました。 終わりに インターン開始時に挙げた3つの目標 について、達成できたか振り返ってみます。 日本での生活には、この半年でかなり慣れました。 TQCチームでの業務を通して、**新しいことも存分に学びました。 では、日本のビジネスカルチャーについては…？ まあ、上司や同僚との接し方は学びましたが、完璧にこなせたかと言われると微妙かもしれません。でもその代わりに、 レバレジーズのエンジニアは皆自由である という、この会社ならではの最高の文化を肌で感じることができました。 よく他の記事でも語られていることですが、 レバレジーズは本人が望みさえすれば、どこまでも成長できる場所です。 来月からは、いよいよ正社員としてのスタートです。さらに成長し続け、レバレジーズを盛り上げていく僕のこれからの活動に、ぜひ注目してください！ それではまたいつか！ We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、以下のサイトからご応募ください。 HRMOS求人ページ hrmos.co 会社説明資料 speakerdeck.com

はじめに こんにちは！テクノロジー戦略室AIMLチームで半年間内定者インターンをしていたYFです。 「AIエージェントってそんなにプログラム書くわけでもないし、1週間くらいでサクッと作れるでしょ？」 …開発を始める前の私は、正直そう思っていました。 今回は、私が内定者インターンとして開発に携わったクラウドコスト調査AIエージェント「マッコーリー」の開発の裏側をお話しします。 結論から言うと、プロトタイプは３日で動きましたが、そこから実業務に耐えうるレベルまでエージェントを安定稼働させる道のりは決してスマートなものではありませんでした。 全く安定しない応答、データの直接処理によるコンテキスト爆発、ハルシネーションとの戦い、などなど...。 本記事では、最新のAI技術をプロダクトに落とし込む過程で直面した「理想と現実のギャップ」と、それを乗り越えようとした「泥臭い試行錯誤のリアル」を包み隠さずお伝えします！ （ちなみに「マッコーリー」という名前は、オーストラリアで独自の貨幣制度を確立した偉人にあやかっています！） 課題と背景 クラウドインフラ（GCPやAWSなど）のコスト管理は、システム規模が大きくなるほど複雑になります。開発現場では、毎週のミーティングのたびに手動でSQLを叩いてコスト推移を表示し、変動の原因を調べるのに毎回20~30分ほど時間を取られていました。同じような作業が複数のチームで行われており、会社全体で見ると見過ごせない工数になっていました。 「AIエージェントにSQLを叩かせれば、このコスト監視業務を完全に自動化できるのでは？」 マッコーリーは、そんな着想から「人間の手によるコスト監視を不要にする」ことを目標に誕生しました。社内のインフラコストを集約したデータベースを連携させ、AIエージェントが自律的にSQLでデータを取得し、コストの監視や分析を行う仕組みです。フロントエンドは業務で最も使われているSlack との連携を選択しました。 主な技術スタックは以下です。 エージェント Google Agent Development Kit (ADK) データソース BigQuery バックエンド Agent Engine Cloud run functions (slackとAgent Engineの通信を仲介） フロントエンド Slackボット 第一形態：モデルが直接SQLを生成・実行 まずは、1つのAIエージェントからデフォルトのSQL実行ツール（ execute_sql ）を直接呼び出してクエリを実行するシンプルな構成を試しました。 【結果】 構成がシンプルな分、応答速度は非常に早かったです。しかし、複数テーブルの結合や「上位の項目のみ表示させる」といった複雑な処理が苦手でした。特に、存在しない架空のテーブルスキーマをでっち上げてエラーを出してしまう現象が多発し、プロンプトのチューニングだけでは解決できない壁にぶつかりました。 第二形態：マルチエージェントで高度な処理をこなす シングルエージェントの限界を突破するため、Googleが公開している data_scienceエージェント の仕組みを参考に、複数のエージェントが協調して動く マルチエージェント構成 へと舵を切りました。 さらに、コードを実行するためのエージェントも追加したことで、データの取得だけでなく「データの加工」「グラフの生成」「将来コストの予測」まで行えるようになりました。 構成は一気に複雑になりましたが、正確なSQLを実行させるために以下のステップを踏むように設計しています。 親エージェント: ユーザーからのリクエスト（自然言語）を受け取り、データ取得担当の監督エージェントに依頼を送信する。 データ取得監督エージェント: リクエストの意図を解釈し、必要なデータを「SQL生成エージェント」に分かりやすく説明する。 SQL生成エージェント & 実行: 監督からの説明をもとに精緻なSQLを生成し、監督エージェントがツール（ execute_sql ）を使ってそれを実行する。 【結果と技術的なメリット】 この構造の最大のメリットは、 「ユーザーの曖昧な質問を解釈するフェーズ」と「厳密なSQLを生成するフェーズ」を分離できたこと です。 例えば、ユーザーが「今月の〇〇プロジェクトのコストを調べて」とリクエストしたとします。 監督エージェントの思考: 「今月は12月だな。プロジェクトと指定しているからGCPのデータだな…」と、足りない情報を補完して要件を整理します。 SQLエージェントの思考: 「特定のプロジェクトなら project.id でフィルタリングすればいいな」と、データベースの構造（スキーマ）に合わせることに集中できます。 役割を分担させることで、LLMのポテンシャルを最大限に引き出し、精度の高いデータ抽出が可能になりました。 【マルチエージェント化の代償】 できることが大幅に増えた一方で、マルチエージェント化による致命的なデメリットも明らかになりました。現在直面している主な課題は以下の3つです。 エラーの無限ループ: SQLやコードの実行に失敗すると、エージェントが自律的に何度もリトライを繰り返すため、エラーの沼にハマると解決（またはタイムアウト）までに10分以上かかることがありました。 処理のボトルネック: エージェントやツール間のやりとりをデータを含めすべて自然言語で行うため、扱うデータ量が多くなるとLLMが文脈を読み込むのに時間がかかってしまいます。 チューニングの難易度: エージェントが階層化されているため、同じ質問をしても「エージェント間の会話の微妙な揺らぎ」によって最終的な応答が大きく変わることが頻繁にありました。プロンプトの変更がどのエージェントにどう影響するかの把握が難しく、調整が非常に厄介です。 第三形態：サブエージェントを「カスタムツール化」してスリムに マルチエージェント化による「処理の遅さ」と「動作の不安定さ」というボトルネックを解消するため、思い切って一部のサブエージェントを廃止し、 カスタムツール（プログラム化された関数）として実装し直す アプローチをとりました。 コードの記述量は増えてしまいますが、LLM特有の「不確実性」を排除できるのが最大の強みです。また、データの受け渡しを自然言語のやり取りではなく、プログラム上の構造化データとして直接処理できるようになったため、LLMが長文を読み解く負担が一気に減りました。 様々なリクエストに対応させるため、ツールの設計はかなりモリモリです。例えば「SQL生成ツール」は、フィルタ条件、期間、集計単位、内訳の有無など11個もの引数を取ります。しかし、デフォルト値をうまく設定し、LLMが必ず指定すべき必須変数を3つに絞ることで、エージェント側の推論の負担を最小限に抑えています。 【結果】 各ツールの実行はローカル環境で1秒未満で完了するようになり、 当初5分ほどかかっていた複雑な処理が、なんと30秒へと劇的に短縮 されました！ さらに、固定のプログラムツールを通すことでエージェントの応答がブレなくなり、細かい修正も確実に反映できるようになりました。 失敗からの学び：タスクの切り分けは人間と同じ ちなみに、親エージェントとSQLツールの橋渡しをしていた「データ取得監督エージェント」もツールへの統合を試みました。しかし、こちらは逆に処理時間が30秒から40秒へと延びてしまう結果に。 原因は、「SQLを生成して、それを実行する」という一連の密接なフローが、親エージェント側に他のツールと一緒に統合されたことで、LLMにとって作業の文脈が認識しづらくなってしまったためだと考えられます。 「LLMにタスクを振る時は、人間にお願いする時と同じように、適切な粒度でタスクを切り分けることが大切」という貴重な学びを得ました。 デモでデータを捏造しまくる カスタムツール化で動作が高速・安定したため、デプロイして実際に社内で使ってもらいました。ところが、ここで新たな問題が発生します。 作成中は特定のプロジェクト名が指定されることを前提に設計していたのですが、ユーザーから「〇〇事業全体のコストは？」といった粒度の違う想定外の質問が飛んできたのです。 するとエージェントはツールを一切呼び出さず、 平然と架空のコストデータを捏造して回答 してしまいました。 プロンプトで「データの捏造は禁止」と強く指示してはいたのですが、「ツールを使うための前提情報が足りない質問」に対する例外処理をきちんと定義していなかったため、LLMがただの「一般的な質問」として受け取ってしまい、無理やり回答を作ってしまったのが原因でした。 テストを回してゴリ押す この捏造問題を防ぐため、エージェントがハルシネーションを起こしそうな「意地悪な質問」や「情報不足の質問」をパターン分けし、 合計100個のテストケースを作成 しました。 実際に自動テストを回してみると、メインの回答だけでなく、裏側のメタデータやエラー発生時の提案メッセージなど、思わぬところで不適切な応答がちらほら見つかりました。テストと評価を何度も繰り返し、プロンプト（システム指示）に以下の改修を加えました。 対応できる質問・できない質問の境界線を明確に定義する 「ツールを実行する前に、データ取得に必要な情報がすべて与えられているか確認する」という思考ステップを追加する チューニングは泥臭い作業でしたが、このチューニングによって、想定外の質問に対しても「〇〇の情報が足りないため、取得できません」と、期待通りに正しく制御された応答を返せるようになりました。 最終形態：シングルエージェント・大量のカスタムツール エージェントの基本機能は完成しましたが、実用化する上で大きな問題がふたつありました。 ①エラーをツールのせいにする問題 例えば、ユーザーの指示が曖昧で、サブエージェントが生成したSQLに構文エラーが出たとします。本来なら「〇〇の条件が足りないため検索できません」とユーザーに聞き返してほしいのですが、親エージェントは「すみません、ツールの不具合でご期待に沿えませんでした」ととりあえず謝罪してしまうケースが散見されました。 プロンプトで「原因を具体的に説明して」と強く指示しても、結局「ツールの不具合です」と言い張るか、「詳しくは開発チームにお問い合わせください」と放棄してしまうかの二択になってしまい、根本的な解決には至りませんでした。 この責任逃れ問題を解決するため、シングルエージェント構成に戻し、1つのエージェントに全ての行動の責任を持たせるという大きな変更を決断しました。エージェントが扱うツールの種類を最小限にするため、「SQLの生成」と「SQLの実行」という2つのステップも1つのカスタムツールに統合しました。 【結果と技術的なメリット】 このアーキテクチャ変更は、予想以上に大きなメリットがありました。 的確なエラーメッセージ: エージェントが自身の責任として、「ユーザーの指定のどこに問題があったのか」を適切にフィードバックするようになりました。 コンテキスト圧縮と安定性の向上: これまでは親がサブエージェントに自然言語で指示を出していましたが、統合ツールへパラメーターとして条件を渡す構造に変わりました。これにより、エージェントが「システムで何が取得できるか」をより的確に理解するようになり、エージェント間の会話のブレが消え、動作が圧倒的に安定しました。 もちろん代償として、ツール（プログラム）側でSQL作成・実行時のあらゆるエラーパターンを網羅してハンドリングする機能実装が必要になりましたが、結果としてシステム全体の堅牢性は劇的に向上しました。 ②データ処理の最適化 社内で使ってもらううちに、「もっと長期間の、より多くのコストデータを一度に見たい」という要望が出てきました。 以前の構成では、データのでっち上げを防ぐためSQLから取得した生データをそのままエージェントにテキストとして渡し、回答を作らせていました。このため、コンテキストの圧迫や処理落ちを防ぐべく、データの取得上限を最大1000件に制限していました。 そこで今回、 「扱うデータ」と「エージェント（LLM）」を完全に分離させる ように構造を根本から見直しました。 具体的には、エージェントが「SQL生成・実行ツール」を呼び出した後、その結果の生データはLLMに読み込ませず、専用の「データ表示ツール（表の作成など）」へ直接引き渡すフローを義務付けました。これにより、エージェントがデータを間違って表示するリスクもゼロに抑えられます。 この改修中、エージェントが高度なデータ分析を終えた後に、ただ生データを表示するだけの表作成ツールを無駄に呼び出してしまうケースが発生しました。 この問題はツールの名称や変数の名前をLLMが直感的に役割を理解しやすいものにリネームすることで解消できました。関数自体の名前はプロンプトと同様かそれ以上にエージェントの挙動に影響していそうです。 まとめ 技術的な学び：正確性をどう担保するか プロトタイプは1週間、安定運用への道のりは長い LLMを使ったエージェントは、動く原型を作るだけなら1週間程度でサクッとできてしまいます。しかし、そこから実業務に耐えうるレベルまでエージェントの挙動を評価し、エラーを改善し、安定運用させるための泥臭い調整に圧倒的な時間を費やしました。 LLMの「責任範囲」は極小化する 今回のような「正確な数値」が求められるタスクでは、LLMに何でもやらせるのは危険です。マッコーリーでは、LLMの役割を「ユーザーの意図を分析し、必要なデータと表示方法を判断すること」に限定しました。数値の異常判定など、LLMでもできそうな処理であっても、可能な限り固定のプログラム（ツール）に任せることで予期しない回答をするリスクをなくせます。 Text-to-SQLの限界とコンテキストの壁 自然言語からSQLを生成させる際、スキーマやカラム名を全てプロンプトに入れ込めば正確に作ってくれそうに思えますが、現実はそう簡単ではありません。 例えば「期間」ひとつとっても、コストの「利用開始時間」「利用終了時間」「請求月」など複数の解釈があります。これらを正確に判定させるための条件を細かく指定していくと、プロンプトのコンテキスト量が膨大になり、結果的にLLMが混乱して動作が不安定になってしまいました。 ハルシネーションを回避するための2つのアプローチ 文章を生成するAIと違い、データベースから数値を引いてくるAIの場合、ユーザーは「その結果が本当に正しいか」を裏付けられません。そのため100%の信頼性が求められます。前述のText-to-SQLの課題を乗り越えるため、以下の対策を取りました。 データ抽出の完全ツール化: LLMにはSQLを書かせず、リクエストの解釈とパラメータ抽出のみを行わせる。 解釈プロセスの言語化: 出力結果に「〇〇年〇〇月の、〇〇を基準にしたデータを表示しています」と十分な説明を添えさせる。「週の開始日」や「年」など、ユーザーの入力から抜け落ちやすい条件をエージェントがどう補完したかを明示し、ユーザー自身が意図通りか確認できるようにしました。 運用・プロダクトとしての学び：ユーザーの真の課題は何か スコープの拡大とアーキテクチャの限界 当初は「小規模チームが自チームのコストを見る」想定でしたが、いざ公開すると「全社のプロジェクトを横断して監視したい」という大規模な要望も寄せられました。また、今回は特定のデータウェアハウス（BigQuery）に特化して構築したため、「他のメトリクスや外部ツールも繋ぎたい」という要望にはすぐに応えられませんでした。汎用性を上げれば使い勝手は向上しますが、データソースを増やすほどLLMの意図解釈は難しくなります。拡張性を見据えた設計の難しさを痛感しました。 「毎回チャットで対話する」必要はあるのか？ マッコーリーは最終的にSlackと連携し、Slackのワークフローから定型文で呼び出される運用が大半になりました。 ここで思ったのは、「毎回同じ関数の呼び出しを期待するなら、間にLLMを挟む必要はないのではないか？」ということです。毎回AIに解釈させるのではなく、「コスト監視を定期実行するワークフローを生成・設定してくれるAI」へとピボットした方が、APIコストの削減や応答品質の保証に繋がるかもしれません。 技術ベースではなく課題ベースで 「最新のAI技術でこれを使いたい！」という思いに囚われすぎず、解決したい問題とユーザーを明確にすることが何より重要だと学びました。事前のヒアリングはもちろん大切ですが、今回のように「作って使ってもらって初めて分かること（想定外の質問、予想外の使われ方）」も多々あります。事前の設計と、その後の軌道修正のバランスは難しく、これから開発を積んで学びたいです。 いかがだったでしょうか？AIエージェントによる業務の完全自動化のハードルはまだまだ高そうですが、特定の要素に特化して工数を削減するエージェントは今後増えてきそうだと思いました。これから同じようなAIエージェントを開発しようとしている方の参考になれば幸いです！ レバレジーズに少しでも興味を持っていただけた方は、こちらからエントリーをお願いします。 leverages.jp

はじめに こんにちは。 レバレジーズで社内向けの経営管理の基盤システム開発を行っている金栄世(キム・ヨンセ)と申します！ 今回は、2026年の年明けに実施した、完全業務外・有志10名による2泊3日のAI駆動・個人開発合宿についてご紹介します。（日記調でお送りしますが、温かい目で読んでいただけると嬉しいです） レバレジーズには、業務だけでなく「ものづくりそのものを楽しむ」エンジニア文化があります。 この合宿のゴールは、「なんでもいいから、1人1つプロダクトをリリースする」。 そして結果は・・・参加者全員無事リリース達成しました！ このブログではみんなが実際にリリースしたWebアプリ・モバイルアプリ・Chrome拡張機能の紹介もしているのえ、実際にユーザとしても利用して頂けるととても嬉しいです😊 プロダクト紹介は末尾にあるので、お忙しい方はここだけでもご覧ください😊 目次 はじめに 発端と準備 合宿当日 1日目 2日目 3日目 みんなの成果物 おわりに 発端と準備 なぜやろうと思ったのか 2025年10月、レバレジーズではエンジニア向けにAI開発ツール費用を月1.5万円まで会社が補助する制度がスタートしました🔥 特徴は、業務利用に限らず、個人の利用にも活用できること。（ここ重要） 私はこの制度を活用し、Claude Code Max 5xプランを契約。 コーディングエージェントを本格的に使ってみたところ、想像以上に開発がスムーズに進みました。 実装、修正、テスト、リファクタリングまでのサイクルが圧倒的に速い。 触っているうちに、「本気でやれば、2〜3日で企画からリリースまで持っていけるのでは…？🤔」という手応えを感じるようになりました。 せっかく個人利用も可能な制度があるなら、自分だけで試すのはもったいない。 他のエンジニアも巻き込み、自由な発想で好きなプロダクトをつくり、実際にリリースまでやり切る場をつくれないかと考え、今回の合宿を企画しました！ 準備 まずは合宿の前提となる、日程と宿の確定から着手しました。 リリースまでやり切ることを考えると、1泊ではさすがに厳しい。。 最低でも2泊3日は必要だろうと判断し、直近の3連休で実施することにしました。 （全員で一斉に有給を取る案も一瞬よぎりましたが、チームへの影響を考えて見送りました。笑） 宿選びでは、以下の条件を重視しました！ 公共交通機関でアクセスできること（車移動だと運転担当が大変） 10人が滞在でき、最終発表に使えるモニター付きの広いリビングがあること 価格が現実的であること いくつか候補を比較した結果、理想的な物件を発見。 広いリビングに加え、寝室が複数あり、お風呂も2つ😳 開発にも発表にも、そして食事するにも十分な環境でした🙇‍♂️ 次に、タイムスケジュールを設計しました。 ほとんど作業時間をするとはいえ、 一部レクリエーション的な時間も用意しました！ 僕が最近料理にハマっているのと、参加者の大井が元々日常的に料理をしていたことから、晩御飯は僕と大井がメインで料理をすることに笑 最終日の次の日から普通に仕事なので、 疲労が溜まらないように早めの解散としました！ 最後に、スキルレベルがさまざまなメンバー全員がリリースまで到達するためには事前準備が必要と考え、 合宿の2週間程前に、 予めプロダクトの企画を固めておく「企画会」の実施 シンプルなアプリケーションとインフラのテンプレートリポジトリをそれぞれ用意 の2点を行いました。 企画会では、参加者には事前に最低1案を用意してもらい、当日は全員で実現可能性や提供価値を高めていくべく、フィードバックを実施。また、想定より早く完成した場合や、途中で開発が頓挫した場合に備え、予備のプロダクト案もいくつか準備しました。 リポジトリのテンプレについては、アプリケーション用はモバイルクライアント(Flutter)・Webクライアント(Next.js)・バックエンド(Fastify)の三つを持つアプリケーションとし、cc-sddのセットアップや一部SKILLSを用意。インフラ用はGoogleCloudのCloudRunをメインとした構成とし、 それをTerraformで実装したものをテンプレとして用意しました。 合宿当日 1日目 13時過ぎに合宿の開会式を実施しました！ 宿泊先のチェックインが16:00だったため、それまではレンタルスペースを借りて実施。 ここで改めて目的とゴールを共有し、3日間の方向性を揃えました！ 開会式が終わった後は、予め準備しておいたテンプレートを利用した開発環境の確認やAIツールのセットアップを行い、「すぐに開発へ入れる状態」を整えていきました。 (レンタルスペースでの開会式) 16:00に宿へチェックイン。 荷物を置いて少し作業を進めた後、夜はみんなお待ちかねの夕食タイムへ。 金と大井でそれぞれ3品ずつ作り、クッキングバトルとする予定でしたが、結局全部美味しかったので引き分けのノーサイドとなりました😂 10人分の料理なんて作ったことはもちろん無かったので、みんなにたくさん協力してもらいながらとなりましたが、なんとか作り切ることができました笑 (左: 約1kg分の砂肝の下処理をする金, 右: 大井作の海老クリームパスタと金作の砂肝とネギの柚子胡椒炒め) (お酒を飲みながらみんなで料理を楽しみました) 2日目 朝に起きる時間は特に決めておらず、各自散歩に行ったりリフレッシュしていました。 ご飯や中間発表以外は、それぞれが自分のペースで開発に向き合います。 15時頃には全体で中間発表を実施。 各自の進捗共有に加え、最終発表までにどこまで仕上げるかの意気込みも話していました！！ この時点で、すでに一定レベルで動作するプロダクトを形にしているメンバーも多かったですが、 ここからちゃんと提供できる品質に持っていくのはやっぱりだいぶ時間がかかるんですよね...(僕もそのうちの1人です) そうした中、これまでに複数のアプリをリリースしてきた経験を持つメンバーは、この段階で一つ目のプロダクトを完成させ、さらに中間発表後には二つ目の開発に着手していました...！！ (中間発表で進捗を共有してます. 乳酸菌系のドリンクが多いです笑) 開発に集中した一日の締めくくりとして、晩御飯にはすき焼きを作りました！ こうやってみんなで鍋を食べるというのも、合宿の醍醐味の一つですね😊 (みんなで作ったすき焼き) (映画やドラマを見ながら美味しく食べました) 夜は最後の発表やリリースに向けて、 デプロイやAppStoreへの申請、 追加機能の開発、 細部の品質向上など、 各自が着々と作業を進めていきました。 お互いが時には励まし合いながら、最後の最後まで、夜が明けるまで追い込んでやり切りました🔥 (深夜4時くらいですが、 みんなまだまだ開発していました) 3日目 3日目は、最終発表・表彰式・打ち上げのランチというスケジュールでした。 最終日には各自がプロダクトを本番URLやエミュレータ、 スライドを用いてプレゼンをする形式で、 プロダクトの「面白さ」「将来性」「品質」の三項目で評価するアンケートも用意。 ちなみにスペシャルゲストとして我がシステム本部の部長の的場さんもプライベートでお越しくださって、最終発表の視聴と評価も行って頂きました！！ (大井のエキトイレの発表の様子：彼は事前に何十時間もかけて自分の足でJR線の各駅のトイレを調査しました笑) 全員のアンケートの結果、 3位: 山本〜ビジュアルノベル化拡張機能 2位: 大井〜エキトイレ 優勝: 山田〜roguu - 美容記録アプリ となりました！(プロダクトの紹介は下にあるのでお待ちを...) どれも特定のペルソナに深く刺さる設計思想が随所に見られるような良いプロダクトで、 非常に接戦でした✨ 最近ではAIが発展し、個人でも高品質なプロダクトを短期間で形にできる環境が整いつつあります。 そのため、「自分自身を最も解像度高く理解している当事者が、そのままペルソナとなって開発する」スタイルのサービス創出は、今後さらに増えていくだろうと思います！ (左: 第2位の大井, 中央: 優勝の山田, 右: 第3位の山本) 合宿終了後は、打ち上げとして昼に豪華なイタリアン食べにいきました😊 3日間やり切った達成感を共有しながら、昼から飲むお酒は最高すぎましたね✨ これにて合宿は終了しました！！ (打ち上げのイタリアンの様子) みんなの成果物 今回の合宿で各自が開発したプロダクトをこちらに載せていきます！！ 良ければ是非一度利用してみてください！ 美馬: プロ野球雨天中止速報 https://baseballraincheck.jp/ どんなアプリか一言で 「今日のプロ野球、雨で中止になりそうかを“チーム別”にひと目でわかる予報ブラウザアプリ」です。 こだわりポイントは？ 過去10年分の球場ごとの雨天中止データを収集して、回帰モデルで正確なモデルを構築したところです。 ユーザの皆さんに一言 観戦予定を立てる前の「まずこれチェック」に使ってもらえたら嬉しいです。天気が読みにくい日ほど、あなたの予定づくりの味方になります。 大井: エキトイレ https://ekitoilet.com どんなアプリか一言で 駅のトイレ情報を確認できるアプリ こだわりポイントは？ 僕がJRの駅を足で調査して、アプリにしました！ 調査に計24時間くらいかかっています！ ユーザの皆さんに一言 トイレに行きたくなったらぜひ使ってください！ 金: 声で残す日記SNS - Voicelet https://apps.apple.com/jp/app/%E5%A3%B0%E3%81%A7%E6%AE%8B%E3%81%99%E6%97%A5%E8%A8%98sns-voicelet/id6758917404 どんなアプリか一言で 最大30秒の音声で日常をつぶやける, 音声日記SNSサービス こだわりポイントは？ このアプリでは「投稿は24時間で消える」上 に「投稿は一度しか視聴できない」という儚さを持っているところがこだわりです！ 最近のInstagramやXではどんどんコンテンツがリッチになってきており, 些細なことをわざわざ投稿する人は減ってきていると思いますが, Voiceletではこの儚さのおかげで日常の小さなことも気軽に呟けるようにしています. ユーザの皆さんに一言 SNS疲れで自分を出し切れていない人は, 是非Voiceletで「飾らない素の自分」を吐き出してみてほしいです！ 細田: マゴモット （準備中） どんなアプリか一言で いつでもあなたのそばに。「孫AI」と楽しくおしゃべりできるアプリです。 こだわりポイントは？ ターゲットがご年配の方々であるため、入力方法にはテキスト入力ではなく音声入力を採用。また、初めて使う方でも直感的に操作できるよう、シンプルさを追求したデザインにこだわりました。 ユーザの皆さんに一言 孫AIとならいつでも、どこでも楽しくお話ができます！ 室: Luxuary Lunch https://www.lunchluxury.com/ どんなアプリか一言で 現在地から近い高級ランチを調べて問い合わせしてすぐ行ける！を実現 こだわりポイントは？ 普通のサラリーマンだと普段絶対に行かないであろう高級ランチを出力できるようにした ユーザの皆さんに一言 高級ランチは消費ではなく、貴重な体験です 山田: roguu - 美容記録アプリ - https://apps.apple.com/jp/app/roguu-%E7%BE%8E%E5%AE%B9%E8%A8%98%E9%8C%B2%E3%82%A2%E3%83%97%E3%83%AA/id6757976743 どんなアプリか一言で 美容院、ネイル、エステなどつい忘れがちな「美容の履歴」を記録できるアプリ こだわりポイントは？ 記録することが面倒にならないように、直感的に使えるシンプルでモダンなデザインにこだわりました。 ユーザの皆さんに一言 「前回いつ行ったっけ？」「今月美容代にいくら使ったっけ？」「どこのサロンに行ったっけ？」 そんなつい忘れがちな小さなモヤモヤを解消したくて、このアプリを作りました。 記録を頑張るのではなく、必要な時にサッと振り返れる。 美容ライフに、そっと寄り添う「ちょうどいい記録帳」になれたら嬉しいです。 菅野: 悪魔的しりとり https://play.google.com/store/apps/details?id=jp.akumateki.shiritori どんなアプリか一言で “ひらがなを奪い合う” 悪魔的な文字制限により、「大人向けに進化した戦略的しりとり」ゲームです！（for Android） こだわりポイントは？ 2つあります。 1つ目は面白い仕掛けです。例えばガチャから、アニメの有名セリフのパロディを収集できたり、勝率や連勝記録によって名誉称号がゲットできたり...他にも仕掛けが満載です！ 2つ目は語彙リストの納得感ですね。実際のユーザと14日以上ものテストプレイをしたので、かなり仕上がってます！ ユーザの皆さんに一言 悪魔的ルールを巧みに使い、相手（AI、人）を「ぎゃふん」と言わせましょう！！ちょっとしたスキマ時間に悪魔的な言葉遊びを楽しんでください！あなたの語彙力と戦略センスが試されます！！ 平島: Determination Hub https://determination-hub.com/ どんなアプリか一言で 「他者への宣言」と「失敗時のペナルティ（支払い内訳の可視化）」によって自分を追い込み、目標達成を後押しするアプリです。 こだわりポイントは？ 「制約と誓約」がもたらす強制力 です。『HUNTER×HUNTER』の「制約と誓約」のように、人は過酷なリスクを背負ってこそ限界を超えた力を発揮できます。本アプリは仲間への公約と失敗時の罰金を可視化し、「逃げれば金を失う」という状況を作り出すことで、あなたの意志を強制的に研ぎ澄ませます。 技術的には、迅速なリリース・改善を目標に、TerraformによるInfrastructure as Code (IaC)、GitHub Actionsを用いた自動デプロイの仕組みを構築しました。 ユーザの皆さんに一言 お金は大事に使いましょう！ 柳: UpDateMe!! https://updatme-frontend-265789616824.asia-northeast1.run.app/ どんなアプリか一言で 自宅でトレーニング（以下：宅トレ）勢向けに、YouTubeのトレーニング動画で今後のトレーニングカリキュラムを組んでスケジュールに組み込んでくれるカレンダーアプリです。 こだわりポイントは？ どんな体になりたいか、どんな体の不調があるか、トレーニング時間などを自由言語でAIに相談できるところです！ その人に合ったメニューを作って提案してくれて、かつスケジュールにも落とし込んでくれるので宅トレが続かない人にも役に立てるアプリかなと！ ユーザの皆さんに一言 合宿に参加して初めてWebアプリをリリースまでできて、ラブ上等もみれて本当に良かったです！ よんせくんありがとう！ もっと使いやすくブラッシュアップしていくぞ！！！ 山本: ビジュアルノベル化拡張機能 （AIのAPI利用料がとてつもないことになるので一般公開は無し） どんなアプリか一言で 小説サイトのUIをビジュアルノベル風の画面にしてくれるchrome拡張機能です。 こだわりポイントは？ BGMとかバックグラウンドの画像があった方がいいよなと思い、これらの機能をつけたのですが、この際に文章で画面転換したら、BGMやバックグラウンドの画像も切り替わるようにしました。 ユーザの皆さんに一言 00年代の残り香に縋って生きてる。 おわりに 合宿当日の時点でリリースまでいけなかったプロダクトは一部ありましたが、 その後も開発を継続し、最終的には全員がリリースまで到達しました！ エンジニアにとって、自らのプロダクトを世に出し、ユーザーに使ってもらう経験は何よりの成長機会です。今回の合宿を通して、個人としてもそのような経験を積む機会にできて良かったと思います！ また、短期間で自分を追い込み、形あるアウトプットを完成させる経験は、「自分の基準」を引き上げます。自分自身への当たり前基準が上がるとともに、自分の力に自信をつけられるのも良かった点だと思います💪 合宿後は多くのメンバーがプロダクト志向が強くなり、業務後に開発をしたりする人も増え、 運営としては実施をして本当に良かったなと思いました！ 本記事を通じて少しでも関心を持っていただけた方がいらっしゃいましたら、将来レバレジーズの一員として、この挑戦の場に参加いただけると嬉しいです😊

2025年の11月某日、アンケートの通知を受信。差出人はHRテック事業部長。 開くと「AI開発合宿をやります！」というタイトルと、概要、そして選択肢がありました。 ☑️ 1. 絶対に行きたい ☑️ 2. 行きたいけどまだ行けるか分からない ☑️ 3. 行きたいけど予定があり行けない 全部行きたい前提なんだ…と思いつつ、面白そうだったのでとりあえず2を選んで返信し、めくるめくAI開発合宿へのチケットを手に入れました━━━━ はじめに 初めまして！私はHRテック事業部で、NALYSYS労務管理プロダクトチームのリーダーをしている𠮷田と申します。 HRテック事業部では、HR系SaaSプロダクト「NALYSYS（ナリシス）」を開発しています。労務管理だけでなく、モチベーション管理など複数のサービスを展開しています。 本記事では、上記のように始まった1泊2日のAI開発合宿を通して、HRテック事業部でのAI活用状況や、チームで実践した仕様駆動開発の所感についてお話ししていきます！ 対象読者 HRテック事業部内でのAI活用状況が気になる方 開発者が実装に閉じず、プロダクトチーム一丸となったアジャイル開発をしてみたい方 仕様駆動開発の実践に興味がある方 この記事を読むとわかること HRテック事業部がどのようにAI活用の土壌を構築しているのか Figma MCPと仕様駆動開発を組み合わせた開発の進め方 職種を越えたチーム開発でAIが果たした役割 AI開発合宿とは？休日出勤なのか？ 実際AIツールを導入している開発現場ではこんな状態ってありがちじゃないでしょうか？ 各々が自己流でAIを使用していてローカル設定やMCPなどの情報が共有されない 他チームはおろか、自分のチームのメンバーがどうAIを使っているのかも分からない…😔 一度使い始めたツールから乗り換えないため、どのエージェントが良いか比較ができない 新しいAI活用方法に興味があっても、実務に導入する準備や検証をする時間が取れない 不確定性を排除できないAIの性質上、品質に関わる部分へのAI導入には「やってみて」の実績が必要だが、実証実験には時間がかかるジレンマ🫨 これらの悩みを、2日間集中的にAI活用に投資する時間を囲って解決しちゃおう！というのが合宿のコンセプトです。 その2日間も、渋谷にあるオフィスを遠く離れた那須白河のリゾートホテルで、会議室とはいえ日常業務を離れたゴージャスな空間でチームごとに集中して楽しく開発できました。 また、金〜土の日程でしたが 当然 代休あり、交通費支給あり、三食豪華食事ありで、ワークライフバランスを重視する私としても迷いなく参加できて有難い限りでした✌️ 先に結果をチラ見せしてしまうと、最終的にこんな成果が得られました！ AIを使いこなしているメンバーのノウハウを共有 仕様駆動開発の効果と効率性を実感（後述） 今までコーディングをしたことがないデザイナーがレスポンシブデザインを実装！ 普段開発に関わらないPdM２名が新機能を開発！！ AI活用度の最終結果で上記を評価され豪華景品（焼肉） ではそこに至るまで、合宿前日譚から実際どういった内容だったかをお伝えしていきます。 合宿を価値ある時間に！部門全体でコミット AI活用を促進する、HRテック事業部の『組織的な土壌』 いくら経営層が「AIを活用して業務効率を上げよう！」などと言ってその機会を作っても、日頃の積み重ねがないと動き出せませんよね。 その意味でHRテック事業部は備えを怠っていませんでした。 Geminiコーポレートアカウントの全社員提供など、レバレジーズでは全社的にAI活用に投資していくぞ！という姿勢を予算という形で打ち出しています。 エンジニア組織としても、Claude CodeやCursorの有料プラン、FigmaのDev Modeなど希望すれば柔軟に使用できる環境が整っています。 そんな中でHRテック事業部内では広くAI活用を展開しようという動きをエンジニアやデザイナー、QAが主体的に行っており、合宿の実現はそういった活動があってこそでした。 AI推進室 今回合宿の企画をしてくれたチームです。 普段は開発用AIエージェントツールの選定や管理から、自社開発している「NALYSYS AI面接」他、AI機能についてのテックリードとして開発や改善の仕組みの構築・管理まで、部門全体のAI活用の推進をしてくれています。 合宿に際しては事前に仕様駆動開発用のプロンプトの整備や参加者全員にClaude MAXプラン配布など、合宿中参加メンバーがAI駆動開発に集中できるようにセットアップをしてくれました。 NALYSYS デザインシステム HeaRT NALYSYSではマイクロサービスアーキテクチャを採用しており、各プロダクトは別リポジトリで開発しています。またデザイナーも複数人いて一人が全部をレビューするのが難しい規模です。そのため、1年ほど前まではプロダクトごとにコンポーネントを作成したり、微妙なデザインのバラツキがあったのですが、それを解決すべく立ち上がってくれたエンジニア・デザイナーの混成チームにより、NALYSYS デザインシステム HeaRT（ハート）が生まれました。 当初は車輪の再発明やUXのブレを防ぐためという目的が大きかったのですが、デザインシステムというシングル・ソース・オブ・トゥルースが出来たことで、気がつけばAIの恩恵をフルに受けられるという状態になっていたのです。 プロンプト一発でFigmaに作ったデザインが出来上がるという圧倒的な開発体験を得る手法を、今回の合宿で教えてもらいました。 ちなみにHeaRTについて、詳しくはこちらの記事で担当者が話しているのでぜひご覧ください！ tech.leverages.jp QAチーム アジャイルQAという難しいミッションに果敢に挑戦し、プロダクトチームと共に品質改善を牽引してくれるQAチームの方々とも日々AI活用によるQA工数の削減について話し合っています。 その中で具体的な機能に依存しないテスト観点表とデザインや仕様書からフロントエンドのコンポーネントテスト項目を生成できないか？その上で実装箇所のQAテスト工数を削減して、探索的テストに当てられないか？という試みを行っています。 テスト観点表はすでに出来ていたのですが、それを実際新機能に使ってみることがまだ出来ていなかったので、今回の合宿はその実践の場になりました。 【合宿１週間前】チーム分け・準備 そういった素地があって企画が始まったAI開発合宿。 合宿の前週から実質的に参加者はその準備を始めました。 まずチーム分けと「実務のプロダクトに新機能を付ける」というテーマ、「27時間で各グループでAI駆動開発を実践、開発の精度やAI活用度合いを競う」というワーク、そして 優勝者には豪華焼肉という重大な事実が共有されました。 チーム紹介 プロダクトを軸に3つのチームがエントリー。 労務管理チームとして集まった4人は以下のような構成でした！ 労務管理・年末調整PdM UI/UXデザイナー 年末調整担当エンジニア 労務管理担当エンジニア（私） 私とPdM以外は労務管理の開発に関わったことはなく、ましてやデザイナーはほとんどコーディングというものをしたことがない。 どーなっちゃうの？！と言いたいところですが、実際にはこのチーム強いな、と思ってました。 なぜなら年末調整担当のエンジニアは、ほぼ一名でレビューまで全てAIとのタッグで開発を回しているのを日々隣の席で見てましたし、デザイナーも恐るべきキャッチアップ力で新プロダクトのPoCを回したりAIでデザイン業務改善を進めていることを知っていたからです。 そこに3度の飯よりAIが好きなPdMもおりますから、全く不安はなく、 これはイケるぞ焼肉！！ と思いました。 テーマ選定 「合宿後も役立つ成果を」ということで、各チームでプロダクトの未実装企画の中から事前に決めました。 事業部長とどんな機能が実装できたら熱いかなどを話し、事業へのインパクトを考慮してチョイス。 結論的に、私のチームは2つの大きな挑戦をすることにしました。 既存の十数ページ分のレスポンシブ対応 次のフェーズで作る予定の新機能 1つ目は、バックエンドが関わらない一方でデザインの再現性が重要なため、主にデザイナーとPdMが担当。 2つ目は、本来なら労務チームで1ヶ月以上かけて開発する予定だった機能を「2日間で本気出したら（ガチったら）どこまで形にできるか」という大実験！こちらは主にエンジニア2名で担当することにしました。 いざ合宿！ 同僚たちと新幹線に乗って福島県へ。 上でも貼ったような、冬のリゾートホテルに大興奮しながらも、一目散にホテルの会議室に向かいレクチャーを受けました。 以下、スケジュールから実際どういうことをしたのかかいつまんで説明します。 オープニング（AI駆動レクチャー） あらかじめ搬送してもらったモニターとWiFiでPCをセットアップし、まずはAI推進室とデザインシステムチームによるレクチャーからスタート。 内容は大きく2つ。 1つ目は、AI推進室が整備してくれた仕様駆動開発の手法とプロンプト。要件や仕様をAIに読み込ませ、設計から実装までを一貫して駆動させるためのお作法です。 2つ目は、デザインシステムチームによるFigma MCP連携。Figmaのデザインデータをそのままエージェントに読み取らせ、デザインシステムのコンポーネントで再現させるためのプロンプトと手順の解説でした。 どちらも日頃の業務の中で必要性を感じつつも、実務にいきなり導入できずにいたノウハウを丁寧に教えてもらい、早速それを取り入れながらの開発を開始しました。 グループワーク（一日目） まずは開発に着手する前に、AI開発環境のセットアップと試運転。 事前の予想として「AI駆動開発はレビューがボトルネックになるだろう」というものがあったため、その対策を共有し合いました。 日頃からAIをフル活用して開発している年末調整のエンジニアからは、開発やレビューの効率化のために自作していたClaude Code command（あらかじめ作成したプロンプトをスラッシュコマンドで呼び出す機能）をセットアップしてもらいました。 適切な内容でPRを作成してくれるコマンドなども便利でしたが、特に工夫がすごい！と思ったのはレビューコマンドです。 「レビュー観点を与えてチェックさせる」一般的なコマンドの後に、さらに「そのレビュー内容が妥当か」を検証するコマンドを組み合わせました。 AIのレビューは、どうしても内容が冗長になったり、変更点だけを見て誤った指摘（嘘）をしたりすることがあります。しかし、この検証プロセスを通すことで「本当に読むべき箇所」だけを的確に抽出でき、レビューを確認する心理的負荷が驚くほど軽減されました。 もう一つは私が用意してきたもので、QAと検討して作成した機能によらないテスト観点基準とデザインや仕様書をまとめてAIに食わせることで、フロントエンドのコンポーネントテストケースを生成する仕組みでした。このテストケースの良いところは優先順位も合わせて教えてくれるので、その上位の数ケースだけでも自動テストを書けば、最低限の動作は保証されてレビュー負荷もだいぶ下がるだろうという目論見です。 しかしその用途とは別にこの設定をしている時に、この合宿で最大の発見をしてしまいました。 Figma Dev Mode MCP が強すぎる、という事実です。 Figma Dev Mode MCPが強すぎる 半年以上前にもFigma MCP活用は話題になっていましたが、その時話題になったのは Figma-Context-MCP という、オープンソースのMCPサーバーでした。 こちらもFigmaで作成したデザインの内部情報を読み取って、複雑なものでなければそのまま再現してくれました。その時も「おっ、便利だな」というくらいの感想を抱いたのを覚えています。 対して、満を持してFigmaが公式にリリースした Figma Dev Mode MCP 、こちらもやってくれること自体は概ね同じですが、その読み取り精度の高さ、思った以上に大きい範囲のセクションを雑に渡しても読み取ってくれるなど、さすが公式が出しているだけあるパワフルさで感動しました。 ちなみにFigJamも読み取れます。 なのでFigmaのデザインと、FigJam上に作った簡単なモデリング図などを用意すれば、MCP経由でClaude Codeが取得し、バックエンドからフロントエンドまで詳細に仕様書を作成する材料が整うのです。 その上、設計や技術選定など人間が判断しなければいけないことでもAI推進室がセットしてくれたプロンプトによって、考慮漏れしがちな部分はAI側から聞いてくれるので、想像以上のクオリティの仕様書が一発で作成されてチームで深夜に爆沸きしました🙌🙌 話は戻って、初日のグループワークタイム、我々はまずは急がず焦らず仕様の理解や、既存実装のモデリングに時間を使いました。 今回エンジニア二人で作る予定の新機能は、全てゼロからではなく以前作った機能単体のマイクロサービスがあります。しかし提供する機能は同じでも、その時の想定と違う労務管理クライアントから呼び出すためのギャップを埋める再設計とAPI作成が必要でした。 なのでマイクロサービスを読み込ませてER図の作成や提供APIの仕様の洗い出しをClaude Codeにしてもらいつつ、その情報をもとに二人で機能単体のドメインと、労務管理のドメインを繋ぐドメインモデリングを行い、実装が必要なテーブルやAPIの検討を行いました。 今後本当に製品として提供するものなので、合宿だからと言って雑に進めると意味がないと考え、認識統一と設計でほぼ一日目の持ち時間を使い切りました。 並行して、フロントエンド出身のPdMがサポートしながらデザイナーは着々とレスポンシブデザインを完成しており、私も自分のタスクをClaude Codeに調査させている間にそのレビューをしました。 こちらもそのままプロダクトとしてリリースする予定なので妥協したレビューはしませんでしたが、レスポンシブにするロジックなどきっちり作られていました！ 中間発表&夕食 私たちの班からは、レスポンシブ対応の成果と、コマンドによる開発の効率化などを発表。 すでに他のチームは2つほど機能を実装していたり、開発未経験のPdMが新機能を完成させていたりと各々が別のスタイルで着々と進めている様子でした。 その後は待ちに待った夕飯です！結婚式みたいな丸テーブルで、フレンチのコース料理を頂きました。 「本当に、会社のお金でこんなに豪華な食事をいただいて良いんですか！？」と、お昼の豪華な御膳からずっと、驚きと感謝が止まりませんでした。 グループワーク（延長戦） 各々温泉に入った後、寝るまで続きをやろう！と予定してたのですが、気がついたら他メンバーがカラオケルームに吸収されていたため、私も楽しく任意参加カラオケ(※)をして、そこから部屋での延長戦開始となりました。 ※経費で落ちないため事業部長のポケットマネーにより開催 しかしこの時が一番楽しかったですね。 日中に既存実装の調査もあらかた終わり、FigJam上にモデリング図などもできた状態で、上にも書いたFigma MCPが仕様の生成に使えるんじゃない？と気付いて試した時、その生成された仕様をさらにチーム全員で話し合っている時、これは絶対日常業務でも使える新しい開発のあり方を実践できているという確かな手応えがありました。 実際問題、HRテック事業部で2年ほどエンジニアをやってきて、これまでも企画から下の要求定義や基本設計からエンジニアとして関わり、PdMやデザイナーと一緒にプロダクトを設計していくという働き方をしていましたし、ドメインモデリングと実装を連動させて育てていくDDD的なこともしてきました。 だからやっていることは大きく変わらないのですが、このやり方によって、圧倒的にそういう職務横断的なチームプレイをする時に 面倒なことが減る という確信をその夜得たのです。 何しろ、デザイン・要求定義書/仕様書・UML図という各職種がプロダクトを表現するために使っているツールで作った情報を、人の手を介さずに変換・生成できるのですから。 本当のコラボレーションというものがここから始まるんじゃないかと言うワクワク感ですね。 てなわけでワクワクと仕様書と、API設計書を作成して、この日は全くコーディングをしないまま、普段より少し遅めの時間に就寝。 グループワーク（二日目） 翌日爽やかな天気の中目覚め、ゴルフに行く人たちに囲まれて朝食バイキングで美味しいエッグベネディクトを頂き、作業開始です。 （若干数名、飲酒により正常に開始できてない人もいましたが…） この日はフロントエンドとバックエンドに分かれ、とにかく実装あるのみでした。 なので書くことはあまりありません。 強いて言えばやはりFigma MCPが強く、フロントエンド側はデザインURLと期待挙動の仕様書を読ませるだけでどんどんできていくなぁと横目で見ながら、バックエンドは純粋なロジックだけではできない部分（他マイクロサービスとの接続設定など）はそうすんなりとは行かなかったです、正直に言うと。 そんなこんなで各人で黙々と実装をして15時にグループワーク終了。 チームの結果としては、レスポンシブ対応が6画面ほど完了し、新機能はフロントエンド側が9割（スタイル調整以外）、バックエンドが7割（他サービスとの連携部分など意外）が完成しました！ 最終発表 仕様駆動開発に真っ直ぐ向き合って、プロンプトのやり取りだけで仕様書を作ってそのまま実装してみたら、文章量が多くレビューしきれない部分に不具合があって大変だったというチームや、個々が小さい機能を受け持って堅実にいくつも小さい機能を実装したというチームなど、各チームのアプローチに個性があって、発表はとても面白かったです。 我々のチームは、新機能完成こそしなかったものの、フロントエンドはレスポンシブ対応や新機能のUIが完成していたのでそれを見せつつ、MCPやClaude Code commandを活用した開発効率の上げ方と合わせて発表。その結果… ━━━━━見事優勝の座をGET！！🎉🎉🎉 焼肉へのチケットを手に入れ、良い気分で帰路につきました。 〜Happy End〜 祝杯 お肉美味しかったです 合宿で成し遂げたこと・気付き ここまで時系列でお伝えしてきましたが、改めて27時間で私たちのチームが成し遂げたことや気付きを振り返ります。 実装未経験のデザイナーがレスポンシブデザインを実装 コーディングの経験がほとんどなかったデザイナーが、Figma MCPとデザインシステムHeaRTの力を借りて、既存画面のレスポンシブ対応を6画面分完成させました。 Claude Codeと共にデザイナー自身が「自分のデザインを自分で実装する」という体験を実現。しかもそのままプロダクトにリリースできるクオリティでした。 AIがコーディングの壁を取り払い、職種の境界を越えたコラボレーションを可能にした象徴的な成果だったと思います。 ドメインモデリング × Figma MCPで設計から実装へ 新機能の開発では、いきなりコードを書くのではなく以下のステップを踏みました。 既存マイクロサービスのコードをClaude Codeに読み込ませ、ER図やAPI仕様を整理 FigJam上でチームでドメインモデリングを行い、モデリング図を作成 FigmaのデザインとFigJamのモデリング図をFigma MCP経由でClaude Codeに渡し、仕様書を生成 生成された仕様書をチーム全員で議論し、設計の方向性を固める ここで大事だったのは、AIが出力した仕様書が「議論のたたき台」として非常に優秀だったことです。 デザイン・ドメインモデル・要求定義といった各職種のアウトプットを、人手を介さず統合して仕様書という形にしてくれる。それをみんなで囲んで「ここはこうじゃない？」「この仕様だとこのケースは？」と話し合う。 AIが翻訳者となることで、エンジニアもPdMもデザイナーも同じ土俵で会話できたのが画期的でした。 設計書からの網羅的なUI実装 チームで合意した仕様書とFigmaデザインをそのままClaude Codeに渡すことで、フロントエンドの実装が驚くほどスムーズに進みました。 仕様書に記述された画面ごとの期待挙動をそのまま実装指示として使用 Figma MCPでデザインを参照させつつ、デザインシステムのコンポーネントで構築 結果、新機能のフロントエンドUIが9割完成（スタイル微調整を除く） 仕様書の精度が高いと、AIへの指示もブレないし、レビュー時に「これは仕様通りか？」の判断基準も明確になる。 設計に時間を使った初日の判断が、二日目の爆速実装につながりました。 #### 仕様駆動開発で実現する「みんなで話して進める」開発 正直に言うと、合宿前は「仕様駆動開発」を「AIに仕様を食わせたら勝手に作ってくれる手法」くらいに捉えていました。 でも実際にやってみて気づいたのは、 その本質的な価値は仕様を中心軸にして、チーム全員が同じものを見ながら話し合って進められることだということ です。 AIが生成した仕様書は完璧ではない。でもそれをたたき台にチームで議論することで、認識のズレが早期に見つかる デザイン・ドメインモデル・コードという異なる言語で表現されたものを、仕様書という共通言語に変換してくれる 結果として、企画・設計・実装のサイクルが驚くほど速く回る これはAIが主役というよりも、 AIが優秀なファシリテーターとして機能し、人間同士のコミュニケーションを加速してくれた という感覚に近いです。 2年間プロダクトチームで職種横断的に開発してきた自分にとって、「やっていることは同じだけど、面倒なことが圧倒的に減る」——これがこの合宿で得た一番の収穫でした。 まとめ AI開発合宿を通じて実感したのは、AIは魔法の杖ではなく、チームの力を引き出すための道具だということです。 仕様駆動開発もFigma MCPも、結局はそれを使って何を作るか話し合い、出てきたものをレビューし、より良くしていくのは人間です。ただ、その「話し合って、作って、確かめる」というサイクルの中にあった面倒や壁を、AIが驚くほど取り払ってくれる。デザイナーがコードを書き、PdMが機能を実装し、エンジニアがドメインモデルをみんなで囲んで議論できたのは、その証拠だと思います。 そして何より、こうやって部門を挙げてAI活用の素地を作ってくれたAI推進室やデザインシステムチーム、QAチーム、合宿を企画してくれた事業部長、そして一緒に深夜まで仕様書を囲んで盛り上がれるチームメンバーがいるという環境が、本当にありがたいなと改めて感じました。 今もこの時得たMCPやcommandの活用しつつ、仕様駆動開発の実務適用にチャレンジ中です。 こんなふうに、常に新しいノウハウを取り入れながら職種の垣根を越えてプロダクトチーム全員でものづくりをする働き方に興味がある方、HRテック事業部で一緒に働きませんか？ エンジニアに閉じない開発がしたい方、AIを活用したプロダクト開発に本気で取り組みたい方、大歓迎です！ ここまでお読み頂きありがとうございました！ We are hiring! この記事を読んで「レバレジーズ、面白そうだな」「自分もこんな環境で挑戦してみたい」と感じていただけたなら、 ぜひ一度カジュアルにお話ししてみませんか？ 私たちは、この記事で紹介したような課題に、オーナーシップを持って共に挑戦してくれる仲間を募集しています。 あなたからのご応募を、心からお待ちしています。 ■会社説明資料 speakerdeck.com ■採用情報はこちら（HRMOS） hrmos.co ■まずはカジュアル面談から hrmos.co ■開発部の雰囲気がもっとわかる動画はこちら！

はじめに こんにちは、レバレジーズ株式会社で普段はエンジニアをしているスガノです。 今回、 「テックフェス2026冬」運営委員長 を務めさせていただきました。 本記事では、レバレジーズグループ全体のエンジニアが一堂に会した 「テックフェス 2026 冬」 の様子を紹介します。 今回のテックフェスは「 セキュリティ 」 を軸に、 基調講演、総勢100名以上が参加したテックバトル、セキュリティにまつわるハンズオンやセッションなど、さまざまなコンテンツを実施しました。 特にテックバトルやハンズオンは、セキュリティ専門チームが主導し、テックフェス用のオリジナルコンテンツとして作成しました。 この一日を通し、セキュリティへの学び・楽しさはもちろん、横との繋がりを実感できる場となりました！ テックフェスとは テックフェスは、レバレジーズグループに所属するエンジニアを対象に、半年に一度開催される社内最大級の技術イベントです。 エンジニアが新しい技術に興味を持ち、みんなで学び合うことを目的に、 組織全体の技術力と交流を高める “社内の技術祭” として続いています。 このイベントの特徴は、 事業部の垣根を超えて “有志のエンジニアたち” が自ら運営していること 。 普段は異なる開発チームに所属するメンバーが全部署から横断的に集まり、テーマ設計から企画・広報・当日の運営までを自分たちの手で作り上げています。 2026年2月に開催された 「 テックフェス2026 冬 」 のテーマは、 「 急成長のその先へ。セキュリティで信頼と未来を創る 」。 このテーマの背景には、会社として掲げている “1兆円規模の企業を目指す” という大きな目標があります。 その未来を支えるエンジニア組織として、攻めと守りを両軸に、次の2つの側面から進化していく必要があると考えました。 ① 学ぶ機会の創出 なんとなく苦手意識があったり、学ぶ機会が乏しいことのあるセキュリティ。昨今、ニュースでも大規模なインシデントが複数報道されました。 これからのレバレジーズは1兆円規模の企業を目指します。セキュリティの文脈で、狙われる機会も増えてくるでしょう。 今だからこそ、学ぶことが不可欠と捉えました。 ② 楽しみながら学ぶ 「そうは言っても知らないこと多そうだな...」と思う方もいるでしょう。 そこで、守りだけでなく、攻めたり壊したりすることで、攻撃者の目線も学びつつ、アクティビティとしてのめり込める楽しさも必要条件だと考えました。 やらされる学びより、やりたくなる学びを。こんな思いでコンテンツを作ってまいりました。 セキュリティを専門とするエンジニアが中心となった今回のテックフェスは、どのようなものになったのか？ 早速、コンテンツの様子を見ていきましょう！ CTFをモチーフにしたテックバトル テックフェスの目玉コンテンツである テックバトル 。今年は1回戦、2回戦に分けて実施しました。 1回戦 1回戦は 「セキュリティ×謎解き」と呼ばれるCTF を元にした、Webアプリの脆弱性を突く「攻撃者の視点」を体験できるテックバトルをしました。セキュリティを専門とするエンジニア社員らが作ったこのバトルでは、 セキュリティ未経験者を含む約100名が参加し、システムに隠された脆弱性を特定し、制限時間内にどれだけ多くのFlag（答え）を獲得できるかを最終的な合計得点を競うクイズ（Jeopardy）形式で実施しました。 採点には、正解者数に応じて問題の配点がリアルタイムに変動する「ダイナミックスコアリング」を採用。多くの人が解いた問題は価値が下がり、誰も解けない難問は高得点を維持し続ける仕組みにより、どの問題から着手すべきかという戦略性と、刻一刻と順位が入れ替わる緊張感を演出しました。 また、あえて「AIによる自動解答の禁止」をルールとし、代わりにヒント機能を充実させることで、安易な解決ではなく参加者自身の「閃き」と「調査能力」を問う設計にもしました。 この1回戦は、参加者が「攻撃者の視点」を安全な環境で体験できるよう企画・開発を進めました。実際に手を動かしてシステムを攻略する快感を通じ、教科書だけでは学べない「なぜそのコードが危険なのか」という防御の勘所を、楽しみながら肌感覚で習得できる場を目指しました。 2回戦 2回戦のテーマは ハードニング競技会をモチーフにした「システムをぶちこわしてバトル」！ 1回戦の結果を踏まえて分けられたチームに、ECサイトを模したWebサイトのソースコードが配布されます。各チームをスタートアップ企業に見立て、セキュリティインシデントが株価に影響するという緊張感のある設定です。 制限時間内に自チームのECサイトのセキュリティ対策をしたり、他チームのECサイトの脆弱性をつくような攻撃をしたりして、自チームのスコアを稼ぎます。 採点は株価だけでなく、ソーシャルエンジニアリングの考え方を加味した方法で実施しました。具体的には、開始前に配布されたパスワードの紙を、競技中に会場内を歩き回る運営に撮影されたら減点という形です。 このように2回戦は、獲得点数を株価と定義することで、参加者のセキュリティ意識が会社の信用度に直結することを、楽しみながら意識できるルールにしました。 テックバトルの内容は好評で、フェス翌日も、 「セキュリティ面白い！解けていない問題があるし、楽しかったから続きをやらせて！」という問い合わせが相次ぎ、急遽コンテンツの閉鎖を1週間延長するほど でした。 ペネトレーションテストのハンズオン 今回のテックフェスでは、 完全内製の「ペネトレーションテスト・ハンズオン」 を90分の枠で開催しました！ このハンズオンは、今回のために セキュリティ専門チームが作った特製のハンズオン です。 「セキュリティを身近に」をコンセプトに、自社サービスを模した“やられサイト”を用意。セキュリティチームも使用しているテストツール（Burp Suite）を用い、社内事例をベースにした脆弱性攻撃を初心者でも迷わず体験できるよう難易度設計に極限までこだわりました。 ハンズオンが始まるとSlackのスレッドは質問や実況で大変賑わい、「ハッキング体験が楽しい」「リスクを肌で感じた」との声も多く、アンケートでもほとんどの参加者から「大変満足」という回答を頂きました。準備は大変でしたが挑戦して本当に良かったです。 ご参加いただいた皆様、ありがとうございました！ セッション セッションには、セキュリティを専門とするエンジニア社員を中心に、5名の方に登壇いただきました。 ハイレベルな専門的内容もありましたが、とてもわかりやすくお話しいただき、セキュリティ未経験者・経験者に関わらず学びの多い時間となりました。 発表者の社員の皆さん、お忙しい中ありがとうございました！ 「ただの訓練」で終わらせない。標的型攻撃の実態と脅威 （レバレジーズ 情報セキュリティ室 杉本） この if 文を突破できる？TypeScriptで学ぶコードの脆弱性 （レバレジーズ レバテック開発部 松浪） “いくら損する？“を計算する。EDC手法による定量的なリスク評価と対策効果の可視化 （レバレジーズ テクノロジー戦略室 原田） AWSセキュリティインシデント対応実録と教訓 （レバレジーズ ソリューション開発部 橘） 退職者アカウントを削除しても要注意！人的脅威からは簡単に逃れられない… （レバレジーズ 情報システム室 高田） 懇親会 テックフェス終了後は、お待ちかねの懇親会を開催！ 今年は「縦と横との繋がりを作る」を裏テーマに、コミュニケーションを促進させる話しかけやすい雰囲気の場を設計しました。 会場のメインコンテンツは、参加者全員を巻き込んだ「スタンプラリー」。 「出身地が同じのメンバーを探す」「Slackアイコンしか知らない人と交流する」といったミッションをきっかけに、 初対面同士でも自然と会話が弾む仕掛け を用意しました。 結果、アンケートでは参加者の85%が「他事業部の人と交流できた」と回答するなど、まさに事業部の垣根を越えたコラボレーションの種があちこちで芽吹いていました。 もちろん、尽きない会話に華を添えるのは、 寿司やピザなどの豪華な食事たち 。 そこで生まれた、人とのつながりによる化学反応が、組織の結束をより強固なものにし、熱気冷めやらぬまま幕を閉じました。 最後に 今回のテックフェス2026冬は、「 急成長のその先へ。セキュリティで信頼と未来を創る 」というテーマのもと、学びやつながりが各所で萌芽する特別な1日となりました。 セキュリティは難しい、発表機会が少ない分野の1つと言われることも多いですが、今回のフェスではセキュリティ専門チームが中心となり、ハイレベルかつワクワクするような時間を作ることができました。 加えて、この1日は運営・参加者全員の笑顔と熱意があったからこそ成り立ったのだと思っています。 いつの時代も、 “人と人がつながる力” こそが最大のエンジニアリングではないでしょうか。 最後までお読みいただきありがとうございます！ それでは、次回のテックフェスでまたお会いしましょう！ P.S. 今回のテックフェスも、朝から会場がいい香りに包まれていました。 実は 社内エンジニア有志の「コーヒー事業部」 がまたまたコーヒーを提供してくれてました！ コードも書けて、豆も挽ける。そんな “フルスタックな男たち” の奮闘記は こちら ！ レバレジーズでは、社内で技術ノウハウの共有を行うイベントはもちろん、外部から著名な方をお呼びして貴重なお話を聞く機会を積極的に設けております。 レバレジーズに少しでも興味を持っていただけた方は、 こちらからエントリー をお願いします。 ■関連リンク 会社説明資料 ~ 過去のテックフェスレポート ~ - 【1日密着】AIと共に次世代のエンジニアへ/レバレジーズテックフェス/AIハッカソン - テックフェス2025 夏レポート - テックフェス2025 冬レポート - テックフェス2024 夏レポート - テックフェス2024 冬レポート - テックフェス2023 春レポート - テックフェス2022 秋レポート

2025年10〜12月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベント開催や、イベント登壇など多様な関わり方で、合計16件のイベントに参加しました！ AI Builders Dayスポンサーブースの様子 主催・共催技術イベント AIが変えるアジャイル、変えられないアジャイル〈MeetUp#4〉 9/4に、開発組織の拠点であるポーラ渋谷ビルにて、「AIが現場にもたらした変化」と「AIでは変えられないアジャイルの本質」について語るイベントを開催しました。 （イベント詳細は こちら から） 実装の精度を上げる、設計フェーズのAI活用 10/10に、オンラインにて、「設計のどの部分にAIを使っているのか？」「なぜ、AIに任せられると判断したのか？」といった内容についてリアルな事例を深掘りしていくイベントを開催しました。 （イベント詳細は こちら から） AI時代を生きるエンジニアのLT&交流イベント〜うひょ氏・ミノ駆動氏登壇〜 集まっtail 2025 10/23に、「AI時代を生きるエンジニアの学びやキャリア」をテーマに、「これからのAI時代を生きるエンジニア」として考えるきっかけとなるような内容の交流イベントを開催しました。 （イベント詳細は こちら から） AIが変えるアジャイル、変えられないアジャイル 11/6に、アジャイル開発やチーム改善に関心のある方を対象とした、オフライン/オンライン対話＆交流イベントを開催しました。 （イベント詳細は こちら から） 工数・コストを大幅削減！「脆弱性診断の自動化」で実現する持続可能なセキュリティチェック体制 脆弱性診断によるリリースサイクルの遅延やコスト増大、属人化といった課題に焦点を当て、これらを解決するための自動化について、実践事例を交えて紹介するイベントを開催しました。 （イベント詳細は こちら から） Langfuse Night #4 - Langfuse Team 来日記念 - LLMエンジニアリングプラットフォームとして国内外で注目度急成長中の Langfuse についてのノウハウを共有するコミュニティイベントを開催しました。 （イベント詳細は こちら から） 紅白LTセッション & 2025年ラストMeetup#6（agile effect） 12/11に、アジャイル開発やチーム改善に関心のある方を対象とした、オフライン/オンライン対話＆交流イベントを開催しました。 （イベント詳細は こちら から） オフライン開催！【プロダクトトップに聞く】未経験プロダクトマネージャーを育てる方法とその実践 12/17に、「未経験のプロダクトマネージャーを育てる方法」にフォーカスし、各社がどのように試行錯誤しながら育成を行っているのかを紐解くイベントを開催しました。 （イベント詳細は こちら から） レバテックMeetup～2025年のフロントエンド～ 12/23に、各社の「2025年のフロントエンド」の取り組みやトレンドについて語り合うライトニングトークイベントを開催しました。 （イベント詳細は こちら から） イベント登壇 Fivetran Japan - Meet up #2 in TOKYO! テクノロジー戦略室のゲンシュンが、Fivetran Japan - Meet up #2 in TOKYO! に登壇しました。 （イベント詳細は こちら から） speakerdeck.com Data Engineering Summit 前夜祭 テクノロジー戦略室のゲンシュンが、 Data Engineering Summit 前夜祭に登壇しました。 （イベント詳細は こちら から） speakerdeck.com Langfuse Night #4 - Langfuse Team 来日記念 - テクノロジー戦略室の苑田が、JAWS-UG Presents - AI Builders Dayに登壇しました。 （イベント詳細は こちら から） speakerdeck.com アジャイルデータモデリング事例共有会 テクノロジー戦略室のゲンシュンが、アジャイルデータモデリング事例共有会に登壇しました。 （イベント詳細は こちら から） speakerdeck.com JAWS-UG Presents - AI Builders Day テクノロジー戦略室の苑田が、JAWS-UG Presents - AI Builders Dayに登壇しました。 （イベント詳細は こちら から） speakerdeck.com レバテックMeetup～2025年のフロントエンド～ NALYSYS開発部の縄巻が、レバテックMeetupに登壇しました。 （イベント詳細は こちら から） speakerdeck.com カンファレンススポンサー pmconf 2025 ゴールドスポンサー 12/4に行われたpmconf 2025にて、レバレジーズ株式会社がゴールドスポンサーとして協賛しました。 JAWS-UG Presents - AI Builders Day 12/4に行われたJAWS-UG Presents - AI Builders Dayにて、レバレジーズ株式会社がシルバースポンサーとして協賛しました。 会場スポンサー TSKaigi 2026 キックオフ “TSKaigi2026 キックオフ”イベントに、イベントスポンサーとして会場の提供をしました。 （イベント詳細は こちら から） Vercel Meetup #4 - Vercelの内側見せちゃいます special “Vercel Meetup”イベントに、イベントスポンサーとして会場の提供をしました。 We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、以下のサイトからご応募ください。 HRMOS求人ページ 会社説明資料

2025年10〜12月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベント開催や、イベント登壇など多様な関わり方で、合計16件のイベントに参加しました！ AI Builders Dayスポンサーブースの様子 主催・共催技術イベント AIが変えるアジャイル、変えられないアジャイル〈MeetUp#4〉 9/4に、開発組織の拠点であるポーラ渋谷ビルにて、「AIが現場にもたらした変化」と「AIでは変えられないアジャイルの本質」について語るイベントを開催しました。 （イベント詳細は こちら から） 実装の精度を上げる、設計フェーズのAI活用 10/10に、オンラインにて、「設計のどの部分にAIを使っているのか？」「なぜ、AIに任せられると判断したのか？」といった内容についてリアルな事例を深掘りしていくイベントを開催しました。 （イベント詳細は こちら から） AI時代を生きるエンジニアのLT&交流イベント〜うひょ氏・ミノ駆動氏登壇〜 集まっtail 2025 10/23に、「AI時代を生きるエンジニアの学びやキャリア」をテーマに、「これからのAI時代を生きるエンジニア」として考えるきっかけとなるような内容の交流イベントを開催しました。 （イベント詳細は こちら から） AIが変えるアジャイル、変えられないアジャイル 11/6に、アジャイル開発やチーム改善に関心のある方を対象とした、オフライン/オンライン対話＆交流イベントを開催しました。 （イベント詳細は こちら から） 工数・コストを大幅削減！「脆弱性診断の自動化」で実現する持続可能なセキュリティチェック体制 脆弱性診断によるリリースサイクルの遅延やコスト増大、属人化といった課題に焦点を当て、これらを解決するための自動化について、実践事例を交えて紹介するイベントを開催しました。 （イベント詳細は こちら から） Langfuse Night #4 - Langfuse Team 来日記念 - LLMエンジニアリングプラットフォームとして国内外で注目度急成長中の Langfuse についてのノウハウを共有するコミュニティイベントを開催しました。 （イベント詳細は こちら から） 紅白LTセッション & 2025年ラストMeetup#6（agile effect） 12/11に、アジャイル開発やチーム改善に関心のある方を対象とした、オフライン/オンライン対話＆交流イベントを開催しました。 （イベント詳細は こちら から） オフライン開催！【プロダクトトップに聞く】未経験プロダクトマネージャーを育てる方法とその実践 12/17に、「未経験のプロダクトマネージャーを育てる方法」にフォーカスし、各社がどのように試行錯誤しながら育成を行っているのかを紐解くイベントを開催しました。 （イベント詳細は こちら から） レバテックMeetup～2025年のフロントエンド～ 12/23に、各社の「2025年のフロントエンド」の取り組みやトレンドについて語り合うライトニングトークイベントを開催しました。 （イベント詳細は こちら から） イベント登壇 Fivetran Japan - Meet up #2 in TOKYO! テクノロジー戦略室のゲンシュンが、Fivetran Japan - Meet up #2 in TOKYO! に登壇しました。 （イベント詳細は こちら から） speakerdeck.com Data Engineering Summit 前夜祭 テクノロジー戦略室のゲンシュンが、 Data Engineering Summit 前夜祭に登壇しました。 （イベント詳細は こちら から） speakerdeck.com Langfuse Night #4 - Langfuse Team 来日記念 - テクノロジー戦略室の苑田が、JAWS-UG Presents - AI Builders Dayに登壇しました。 （イベント詳細は こちら から） speakerdeck.com アジャイルデータモデリング事例共有会 テクノロジー戦略室のゲンシュンが、アジャイルデータモデリング事例共有会に登壇しました。 （イベント詳細は こちら から） speakerdeck.com JAWS-UG Presents - AI Builders Day テクノロジー戦略室の苑田が、JAWS-UG Presents - AI Builders Dayに登壇しました。 （イベント詳細は こちら から） speakerdeck.com レバテックMeetup～2025年のフロントエンド～ NALYSYS開発部の縄巻が、レバテックMeetupに登壇しました。 （イベント詳細は こちら から） speakerdeck.com カンファレンススポンサー pmconf 2025 ゴールドスポンサー 12/4に行われたpmconf 2025にて、レバレジーズ株式会社がゴールドスポンサーとして協賛しました。 JAWS-UG Presents - AI Builders Day 12/4に行われたJAWS-UG Presents - AI Builders Dayにて、レバレジーズ株式会社がシルバースポンサーとして協賛しました。 会場スポンサー TSKaigi 2026 キックオフ “TSKaigi2026 キックオフ”イベントに、イベントスポンサーとして会場の提供をしました。 （イベント詳細は こちら から） Vercel Meetup #4 - Vercelの内側見せちゃいます special “Vercel Meetup”イベントに、イベントスポンサーとして会場の提供をしました。 We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、以下のサイトからご応募ください。 HRMOS求人ページ 会社説明資料

はじめに プロジェクトの立ち上がりの背景 こだわり①：技術的な「実験場」として遊び尽くす 1. モダンな技術を自由に選ぶ AWSアーキテクチャ 技術スタック 2. 職種の壁を越えた「やりたい」の尊重 こだわり②：運用は「いちプロダクト」として本気で向き合う おわりに We are hiring! はじめに こんにちは。レバレジーズ テクノロジー戦略室 SREチームの横江です。 普段は、事業部横断で他チームのSRE活動をサポートしています。 今回は、私がpdm（プロダクトマネージャー）を務め、有志メンバーと 「サイドプロジェクト」 として開発した社内テックブログ 「prairie post（通称：ぷれぽす）」 についてのお話です。 ぷれぽすのアイコンです 「社内の課題を解決したい」という思いから始まったこのプロジェクトですが、ただのツール作りには留まらないプロジェクトになりました。 そこは、エンジニアとして技術を楽しむ実験場であると同時に、 ユーザーに向き合いサービスを育てる「本気のものづくり」の場 でもあったのです。 技術選定の自由度が高い環境で挑戦したい 職種の枠を超えて、技術領域を広げたい 作ったものを改善し続ける「プロダクト志向」な開発がしたい そんな「技術もプロダクトも好き」なエンジニアの方に、レバレジーズでの開発の雰囲気が少しでも伝われば嬉しいです！ プロジェクトの立ち上がりの背景 「気軽にアウトプットできる場が欲しいから、社内ブログを作りたいな」 プロジェクトが始まったきっかけは、室長からのシンプルな一言でした。 この言葉の裏には、プロジェクト始動のきっかけとなる課題意識がありました。 弊社には多くのエンジニアが在籍していますが、当時はナレッジ共有に「改善余地」があり、横断的に知見を活かせる場づくりが必要だと感じていたのです。 ※ 記載している課題感は、当時の状況を踏まえたプロジェクトメンバー個人の視点であり、組織やプロセスそのものを否定するものではありません。 そこで、「それなら自分たちで作ろう」とテクノロジー戦略室内部で有志を募りました。 データエンジニア、TQC（品質管理）、SRE/プラットフォームエンジニア、AIエンジニア など、多様な職種のメンバーが集結しました！ 私たちは、以下の2つを大きな目的として掲げ、サイドプロジェクトを始動しました。 【課題解決】ナレッジ共有の活性化 事業部を跨いで、エンジニア同士がより活発にナレッジを共有できる最適な場を提供する。 【技術者の成長】スキルアップと挑戦の機会 開発を通じて自分たちのスキルアップを図り、モダンな技術の検証と実践的な挑戦の場として活用する。 こうしてプロジェクトは始まりましたが、メンバーは皆、本業の業務を抱えています。 忙しい中でモチベーションを維持し続けるには、 「開発プロセスそのものを最高に楽しめるものにする」 必要がありました。 そこで私たちは、 「技術は好きに遊ぶ」「でもプロダクトとしては本気で作る」 という2つのこだわりを大切にして開発を進めることにしました。 こだわり①：技術的な「実験場」として遊び尽くす せっかく自分たちで作るなら、開発プロセスそのものを最高に楽しめるものにしたい。 そこで1つ目に大切にしたのが、ここを 技術やキャリアの「実験場」にする ことです。 1. モダンな技術を自由に選ぶ 普段の業務アプリケーション開発では、どうしても「安定稼働」が最優先されるため、最新技術の導入には慎重にならざるを得ません。 そこで、ぷれぽすでは、社内標準言語の TypeScript をベースにしつつ、それ以外は「今、使ってみたい技術」を自由に選びました。 実際に、「 ぷれぽす」での検証を経て、いくつかの技術は本番のプロダクト開発でも採用されるようになりました。 今回はせっかくなので、ぷれぽすを支えるアーキテクチャと技術スタックを少しだけご紹介します！ ※詳しい話は今回の趣旨から外れるため、おまけ程度にご紹介します。 AWSアーキテクチャ ぷれぽす AWSアーキテクチャ 技術スタック SPA構成 フロントエンド React/Vite shadcn/ui, tailwindcss TanStack Router & Query バックエンド Hono インフラ K8s(EKS), Helm Terraform 監視ツール Grafana Prometheus, Grafana Tempo OpenTelemetry 他 2. 職種の壁を越えた「やりたい」の尊重 また、技術選定だけでなく、 誰が何を担当するか についても、あえて「得意領域」ではなく、 メンバーが今チャレンジしたいこと を最優先で決めています。 データエンジニアやSRE が バックエンド 実装を担当 普段k8sを触っているプラットフォームエンジニア が フロントエンド実装を担当 それぞれ専門領域を持ちながら、希望に応じて新領域に挑戦し、最初は不慣れな部分もありましたが、お互いにコードレビューし合い、知見を深めていきました。 その結果、今ではプラットフォームエンジニアがフロントエンドを、SREがバックエンドの実装を、それぞれ自走できるレベルまでスキルアップしています。 こだわり②：運用は「いちプロダクト」として本気で向き合う 2つ目に大切にしたのは、 「本気でプロダクトを作る」 ということです。 技術は「遊び心」を持ちつつも、リリース後の運用や品質には「いちプロダクト」として本気で向き合っています。 どれだけ技術的に面白いものを作っても、ユーザー（社内エンジニア）に使ってもらえなければ意味がありません。 「作って満足」で終わらせないために、チームで以下のような活動を行っています。 知恵を出し合う 定期的にチームで集まり、「どうすれば投稿が増えるか？」「使い続けてもらうには？」を議論しています。 自分たちで目標を立て、リリースする 明確な目標を設定し、自分たちで新機能を企画・開発・デプロイしています。 ただコードを書くだけでなく、限られた時間の中で「使われるもの」を作る難しさと楽しさを味わえるのも、このプロジェクトの醍醐味です。 おわりに 社内の「ナレッジ共有不足」という課題に対し、有志が集まり、自分たちで技術を選び、楽しみながら解決していく。 レバレジーズには、 技術的な挑戦による自律的な成長機会 があり、 プロダクト志向でものづくりができる環境 があります！ そんな環境で一緒に働きたい方や、技術が好きでプロダクト志向がある方、ぜひ採用情報をご覧ください。 We are hiring! この記事を読んで「レバレジーズ、面白そうだな」「自分もこんな環境で挑戦してみたい」と感じていただけたなら、ぜひ一度カジュアルにお話ししてみませんか？ 私たちは、この記事で紹介したような課題に、オーナーシップを持って共に挑戦してくれる仲間を募集しています。 あなたからのご応募を、心からお待ちしています。 会社説明資料 採用情報はこちら（HRMOS） まずはカジュアル面談から

はじめに こんにちは、レバレジーズ株式会社で普段はSREをしている斉藤です。 そして今回は、 「テックフェス2025夏」運営委員長 を務めさせていただきました。 本記事では、レバレジーズグループ全体のエンジニアが一堂に会した 「テックフェス 2025 夏」 の様子を紹介します。 今回のテックフェスでは、 「AI × エンジニア」 を軸に、 御田稔（みのるん）氏によるAIをテーマにした基調講演、総勢80名が参加したAIハッカソン、AWS社をお招きして行われたAIエージェントのハンズオンなど、さまざまなコンテンツを実施しました。 この一日を通して、 「AIをどう活かし、どう学び、どう仲間とつながるか」 を全員で考える場となりました。 当日の雰囲気は動画でも紹介していますので、👇️からぜひご覧ください！ www.youtube.com テックフェスとは テックフェスは、レバレジーズグループに所属するエンジニアを対象に、半年に一度開催される社内最大級の技術イベントです。 エンジニアが新しい技術に興味を持ち、みんなで学び合うことを目的に、 組織全体の技術力と交流を高める“社内の技術祭” として続いています。 このイベントの特徴は、 事業部の垣根を超えて“有志のエンジニアたち”が自ら運営していること。 普段は異なる開発チームに所属するメンバーが横断的に集まり、テーマ設計から企画・広報・当日の運営までを自分たちの手で作り上げています。 2025年8月7日に開催された 「テックフェス2025 夏」 のテーマは、 「Leverages Singularity 〜仲間とつながり、AIとともに歩む未来〜」 。 このテーマを掲げた背景には、会社として掲げている “1兆円規模の企業を目指す” という大きな目標があります。 その未来を支えるエンジニア組織として、AIを軸に次の2つの側面から進化していく必要があると考えました。 ① 既存サービスの成長加速 AIを活用することで、日々の開発生産性を大きく引き上げるだけでなく、サービス自体にAIを組み込むことで価値を何倍にも拡張できる。そうした未来が現実的になってきています。 その第一歩として、 全エンジニアが“AIを使いこなす”きっかけを提供 したいという思いがありました。 ② 新規プロダクトの創出 これからのレバレジーズには、既存の延長線ではない新しい事業を自ら生み出す力が求められます。 AIの登場によって、アイデアを形にするまでのハードルは劇的に下がりました。 「自分でも作れるかもしれない」 「ちょっと試してみようかな」 そう思える文化を根づかせるためにも、AIをテーマにしたフェスを通して、 全員が挑戦できる環境がすでにここにあること を伝えたい、という狙いがありました。 このような背景のもと、「AI × エンジニア」という共通テーマで、全員が同じスタートラインに立ち学べる1日をつくりました。 下記では今年のテックフェスのそれぞれのコンテンツの様子を書いていきます。 基調講演 今回は御田稔（みのるん）氏に 「まだ間に合う！AIエージェントに入門して、LLM時代に生き残れるエンジニアになろう」 という題名で、最新トレンドとAIエージェントの今後の展望についてお話ししていただきました。 登壇者紹介 御田稔（みのるん）氏 KDDIアジャイル開発センター株式会社 テックエバンジェリスト 技術の楽しさを伝える活動を行いながら、クラウドやAI領域の内製開発・プリセールス・技術コンサルティングに従事しています。 AWS Community Hero、AWS Samurai、2025 Japan AWS Top Engineer & All Certs、Qiita 2024 Top Contributor認定 著書： 『Amazon Bedrock 生成AIアプリ開発入門（SBクリエイティブ）』 『やさしいMCP入門（秀和システム）』 『AIエージェント開発／運用入門（SBクリエイティブ）』 学び、感想 今回の基調講演は、まさに「AI × 人間の未来」を体感できる時間でした。 AIエージェントやMCPのような進化の激しいテーマを、AIの進化の流れやトレンドの変化とともに紹介いただき、AIの基礎から最前線までを一気に学べる貴重な2時間でした！ AIの理解が整理され、「実際に触ってみたい」に変わった瞬間 みのるんさんの解説によって、これまで断片的だった AIエージェントやMCPの仕組みが整理され、全体像として理解できた という声が多くありました。「点だった知識が線になった」というイメージに近いと思います。 また、ライブデモでは、Claude Codeを使ったAIコーディング実演を披露していただき、みのるんさんの普段の使い方や、AIコーディングツールを活用する際に意識しているポイントなど、目から鱗の情報が満載でした。 参加後のアンケートでも、「これなら自分も試せそう」「AIエージェントを触ってみたい」など、講演が行動につながったという声が多く寄せられています。 キャリアの話が心に刺さった 30歳を過ぎてからフルスタックに転身したというみのるんさんの言葉に、 「自分もまだ挑戦できる」「AIを家庭教師にして学んでみよう」と勇気をもらった人がたくさん。 特に「手を動かすことが一番の学び」というメッセージは、 多くの参加者の原動力 になったと思います。 運営として感じたこと 今回のテーマ 「Leverages Singularity 〜仲間とつながり、AIとともに歩む未来〜」 を、みのるんさんがまさに体現してくれました。 AIはエンジニアを置き換えるのではなく、 可能性を拡張する存在 。その希望を、会場中が共有できた時間でした。 みのるんさん、心動かされる講演をしてくださり、本当にありがとうございました！ 参加者・運営ともに、忘れられない一日になりました。 AIハッカソン 概要 テックフェスで特に盛り上がったメイン企画が 「AIハッカソン」 です。 当日ランダムに組まれた3人1組のチームが、コードを書かずに自然言語だけでアプリケーションを開発させるバイブコーディング形式で実施しました。 審査については、予選を各ブロックの参加者同士がお互いに発表・評価をし、決勝は各ブロックの1位が全体に対して発表し、参加者全員に加えて決勝用の審査員が評価をする形式で行いました。審査員は、エンジニア職種以外の他部門の方々、基調講演のみのるんさん、AWSハンズオンでいらっしゃったAWS社員の方々にご参加いただきました。 この企画の根底には 「自分の考えを、AIの力を使ってすぐに形にできる」という感動を参加者に体験してもらいたい という思いがありました。この企画を単なるおもしろアプリ開発大会で終わらせないために、運営チームで様々な角度で議論を重ねました。運営チームが拘った2つのポイントを紹介します。 評価軸について どのような観点で、誰が評価するべきか？という点で 当初は「完成度（見た目）」と「アプリの面白さ」の2軸で詰めていたのですが、ウケ狙いを求めたおもしろアプリを作る大会になり得るのが懸念でした。一方、「社会へのインパクト」「マネタイズ」「市場規模」などのビジネス観点を求めてしまうと、参加するエンジニアが評価を適切にできないのが課題でした。 あくまでも社内イベントで事業ハッカソンではないため、今回は 「あたなはその事業に参加したいか？」という主観的な熱量 をもたせた評価軸を設けることにしました。 環境の整備 当初は、既に業務で利用されているGeminiやCopilotで十分だろう、という声が多数ありました。しかし運営メンバーがBolt.newやReplitといった最新のAIツールを実際に使ったところ、アウトプットのクオリティにかなり感動しました。この感動を ぜひ参加者全員にも体験してほしい！ という強い思いから、情シス部門と交渉し、Bolt.newやReplitを利用できる環境を用意しました。 当日の様子 予選から、どのチームも想像を超えるクオリティのアプリケーションを生み出してました。予選を勝ち抜いた4チームによる決勝戦は、M-1グランプリ方式のプレゼンバトルに加え、審査員からの鋭い質問との攻防戦も相まってかなり大盛り上がり！優勝はなんと「ヒエログリフ教育アプリ」でした笑。 また終了後のアンケートでは、 満足度96% を記録。「楽しかった」「Replitが凄かった」等嬉しい声を多数いただきました。 AWSハンズオン 今回は、 AWS社のソリューションアーキテクト（SA） の方を講師にお招きし、 「AIエージェントシステムの開発からAWSデプロイまでを体験できる実践ワークショップ」 を開催しました。 AIエージェントの仕組みを学ぶだけでなく、実際に手を動かして開発からAWSへのデプロイまでを一貫して体験していただきました。 参加してくださった方々から「AIエージェントに触れる良いきっかけとなった」「理解が深まった」というご意見をいただき、大変嬉しく思います☺️ ご登壇いただいたAWS社のソリューションアーキテクトの方、そしてご参加してくださった皆様、本当にありがとうございました！！ セッション・LT セッションには、8名の方に登壇していただきました。 発表者の皆さん、ありがとうございました。 AIエージェント開発組織を構築してみた （レバレジーズ システム人事戦略室 田中瑚大さん） 開発した／開発中製品をGo To Marketするために生成AIをフル活用してみた （レバレジーズ NALYSYS開発部 瀬上真宏さん） 失敗から学ぶAI駆動開発：ハッカソンで直面した課題と打開策 （レバレジーズ テクノロジー戦略室 苑田朝彰さん） コンサルティングサービスの仮想化を通じたAI時代における新しいBPR方法論 （レバテック クオリティアシュアランス事業部 篠塚亮彦さん） Devinとは何だったのか （レバレジーズ NALYSYS開発部 桐生直輝さん） AIで成長を加速させる ─ Obsidian in Cursor 活用 （レバレジーズ ソリューション開発部 斎木克馬さん） AITuberの構築に伴うコンテキスト管理と記憶要約戦略 （レバレジーズ テクノロジー戦略室 原田将貴さん） 「感謝」を「コード」で紡ぐ：LevLetter開発秘話とAI時代のキャリア （レバレジーズ メディアシステム部 阿部倉怜さん） 懇親会 テックフェス終了後には、懇親会も開催。事業部の垣根を越えた交流が生まれていました。 ここでも「仲間とつながる」というテーマのとおり、普段なかなか交流のない 事業部同士のエンジニアたちが垣根を越えて盛り上がる時間 になりました。 会場では、フェスで登壇・体験した内容をもとにしたテックフェスクイズ大会を実施。学びを振り返りながら、自然と会話と笑顔が生まれていました。 さらに、テーブルにはピザ、寿司、お酒など豪華な食事も用意され、「技術×食×人」の三拍子がそろった最高の締めくくりとなりました。 最後まで “お祭り” らしい熱量と笑顔に包まれた夜でした。 最後に 今回のテックフェス2025夏は、 「Leverages Singularity 〜仲間とつながり、AIとともに歩む未来〜」 というテーマのもと、AIを軸に“学び・挑戦・つながり”が交差する特別な1日となりました。 参加者の全体満足度 8.4 / 10 、AI活用への期待値 7.9 / 10 と、過去最高の評価をいただきました。 基調講演・AIハッカソン・ハンズオン・LT・懇親会のすべてが連動し、 「AIが人の創造力を拡張する瞬間」 をみんなで体感できたことが、今回最大の成果です。 運営委員長として迎えた初のテックフェス。 250名近くが参加する大規模イベントということもあり、正直、準備段階からずっと緊張していました。 それでも、当日あの熱気と笑顔に包まれた瞬間、「やってよかった」と心から思えました！ 何より、このテックフェスを支えてくれた13名の運営メンバーに心から感謝しています。 それぞれが本業の合間を縫いながら、企画・広報・司会・映像・装飾・運営と全力で取り組んでくれました。 そして、当日の様子を撮影・編集を担当してくださった採用広報チームの清水さん。 フェスの熱量をそのまま映像に残してくださり、本当にありがとうございました！(動画は こちら ) みんなの笑顔と熱意があったからこそ、このテックフェスは成功しました。 AIの時代になっても、 “人と人がつながる力” こそが最大のエンジニアリングだと思います。 最後までお読みいただきありがとうございます！ それでは、次回のテックフェスでまたお会いしましょう！ レバレジーズでは、社内で技術ノウハウの共有を行うイベントはもちろん、外部から著名な方をお呼びして貴重なお話を聞く機会を積極的に設けております。 レバレジーズに少しでも興味を持っていただけた方は、 こちらからエントリー をお願いします。 会社説明資料 エンジニア職採用｜レバレジーズ株式会社 P.S. 今回のテックフェス、朝から会場がいい香りに包まれていたのをご存じでしょうか？ 実は 社内エンジニア有志の「コーヒー事業部」 がコーヒーを提供してくれてました！ コードも書けて、豆も挽ける。そんな “フルスタックな男たち” の奮闘記は こちら 過去のテックフェスレポート テックフェス2025Winter レポート - Leverages Tech Blog テックフェス2024夏 レポート - Leverages Tech Blog レバレジーズ テックフェス2024冬レポート - Leverages Tech Blog レバレジーズテックフェス 2023 春レポート - Leverages Tech Blog テックフェス2022秋レポート React Suspense ~ v18から見えること ~ - Leverages Tech Blog

こんにちは、レバレジーズの HR テック事業部でフロントエンドエンジニアをしている縄巻です。 「日々の実装タスクをこなすだけじゃ、なんだか物足りない…」 「もっとプロダクトの根幹に関わるような、インパクトの大きな仕事がしたい！」 エンジニアとして少しずつ経験を積んできた今、そんな風に感じている方はいませんか？ この記事では、実務経験 2 年未満だった私が、チームをまたがる大きな課題であったデザインシステムの導入に、オーナーシップを持って挑戦した経験をお話しします。 この記事を読めば、若手であっても自ら課題を発見し、最新技術を駆使しながら事業を前に進めていける、レバレジーズの挑戦的な文化を感じていただけるはずです。 そもそもデザインシステムとは？ 本題に入る前に、少しだけ「デザインシステム」という言葉について説明させてください。 デザインシステムとは、単なる UI コンポーネントのライブラリではありません。それは、一貫したユーザー体験を効率的に提供するための「仕組み」そのものを指します。具体的には、再利用可能な UI コンポーネント、デザインの原則やガイドライン、そしてそれらを運用するためのルールやツール群を体系的にまとめたものです。 デザイナーとエンジニアが共通の言語と思想を持つ ことで、プロダクト全体の品質と開発速度を飛躍的に向上させることを目的としています。 課題：オーナー不在のデザインシステム 私が所属する SaaS プロダクトには、もともと「共通コンポーネント」として管理されている npm パッケージが存在しました。 しかし、専任のメンテナーはおらず、各開発者が必要に応じてコンポーネントを“継ぎ足し”していく運用が続き、体系的な管理がなされていない状態でした。 その結果、開発現場では、次のような数々の問題が起きていました。 Figma と実装の乖離 ：Figma にはないのに、React コンポーネントだけが存在する。 命名の不統一 ：Figma と React でコンポーネント名が異なり、探すだけで一苦労。 巨大モノリスパッケージ ：たった一つのコンポーネントを更新したいだけなのに、パッケージ全体への影響調査が必要になる高い更新コスト。 ドキュメントとテストの不足 ：誰も正確な仕様を把握できない、ドキュメントもテストもないコンポーネントたち。 過剰な依存関係 ：特定のライブラリに依存し、他の場所で再利用できないコンポーネント。 アクセシビリティの欠如 ：キーボードで操作できない、スクリーンリーダーで読み上げられないなど、アクセシビリティへの配慮不足。 これらの課題は、多くのメンバーが「問題だよね」と認識しつつも、日々のサービス開発が優先され、誰も根本的な改善に着手できずにいました。 「誰かがやる」から「自分がやる」へ こうした状況に、私は強い危機感を覚えていました。 最初は、個人として既存コンポーネントのメンテナンスや機能追加といったコントリビュートを始めました。しかし、プロダクトが急成長する中で、一個人の部分的な改善では到底追いつかないことはすぐに明らかになりました。 そこで私は、上長との 1on1 でこの問題の大変さと、抜本的な改善の必要性について話しました。そして、 「誰かがやってくれるのを待つのではなく、自分が主体となってこの状況を解決したい」 と伝え、この課題のオーナーになることを志願しました。 幸いにも、同時期にジョインしたデザイナーも既存の Figma 運用に強い課題意識を持っていました。こうして、エンジニアリングとデザインの両側面からアプローチする「デザインシステム刷新プロジェクト」が、ついに本格始動しました。 そして、このプロジェクトの担当エンジニアは、私一人。もちろん不安はありましたが、それ以上に 「この状況を自分の手で変えられるんだ」 というワクワク感の方が大きかったのを覚えています。 実行：若手の裁量で進めた課題解決 山積する課題を解決するため、技術選定はゼロベースで、その意思決定はすべて私に一任されていました。 若手の提案だからと色眼鏡で見られることは一切なく、ロジックと熱意さえあれば挑戦させてもらえる。そんな文化が、このプロジェクトを前に進める大きな力になりました。 ここでは、導入した主要な技術や、開発を加速させた AI ツールの活用法について解説します。 1. 開発体験の向上を目指した基盤整備とコンポーネント再開発 まず、デザイナーとエンジニア間の連携をスムーズにするため、Figma コンポーネントの再設計と命名規則の統一を行い、React コンポーネントもより使いやすい形に再定義しました。これにより、デザインと実装の間の認識齟齬をなくし、コミュニケーションコストを削減しました。 幸いなことに、レバレジーズにはレバテックの「VoLT」というデザインシステムをリードしたデザイナーが在籍しており、その知見を惜しみなく共有してもらえました。 参考：レバテックのデザインシステム「VoLT」 裁量を持って挑戦できるだけでなく、こういった組織の横の繋がりからノウハウを吸収できるのも、大きく成長している会社ならではの魅力だと思います。 2. 独立したパッケージとして管理 巨大な単一パッケージが引き起こしていた更新コストの問題を解決するため、モノレポ構成への移行を決定しました。 Nx なども候補に上がりましたが、私たちのチーム規模や設定の学習コストを考慮した結果、ビルドキャッシュによる高速な CI/CD とシンプルな設定が魅力の Turborepo を選択しました。また、 pnpm を組み合わせることで、ディスク容量を効率的に利用しつつ、厳密な依存関係管理を実現しています。 これにより、各コンポーネントを独立したパッケージとして管理し、サービスごとに必要なコンポーネントだけを選択的に更新できる、柔軟な運用体制を構築しました。 3. Radix UI でアクセシビリティを当たり前に コンポーネントの品質、特にアクセシビリティを担保するために、ヘッドレス UI ライブラリである Radix UI を採用しました。 MUI や Chakra UI のようなスタイル付きのコンポーネントライブラリも検討しましたが、プロダクト独自の厳密なデザイントークンを適用する必要があったため、スタイリングの自由度が低い点は懸念でした。 Radix UI は、スタイルを持たず、WAI-ARIA に準拠した高品質な振る舞いのみを提供してくれます。 これにより、デザインの制約を受けることなく、アクセシビリティを当たり前の品質として確保することができました。 4. Storybook によるドキュメント管理 ドキュメント不足を解消し、コンポーネントの利用を促進するために Storybook を導入しました。 コンポーネントのカタログツールは他にも存在しますが、業界のデファクトスタンダードであり、アドオンによる拡張性が非常に高い点を評価し採用しました。 特にテストとの連携は強力です。Storybook の play 関数を使って定義したインタラクションテストを、 vitest がテストファイルとして実行する仕組みを導入しました。これにより、 Playwright 経由で実際のブラウザを起動してコンポーネントの操作をテストできるため、より信頼性の高い品質保証体制を構築できています。 また、各コンポーネントの Props、使用例、インタラクティブなデモを Storybook 上で一元管理することで、誰もがコンポーネントの仕様を容易に理解できる仕様書として機能させています。 5. AI は、本質的な仕事に集中するための“相棒” 担当エンジニアは私一人。これらの施策を、通常のサービス開発と並行して進める上で、AI コーディングツール（ Cursor , Claude Code など）の活用は、もはや“選択肢”ではなく“必需品”でした。 これは、単に流行りの技術を使いたかったからではありません。 たった一人のリソースで、最速で価値を届けるための、極めて合理的な戦略 でした。 コンポーネントの雛形作成、Storybook のドキュメント生成、リファクタリング、単体テストの実装……。もしこれら全てを手作業でやっていたら、半年で今の状態に到達することは不可能だったでしょう。 定型的な作業を AI という“相棒”に任せることで、私はより本質的なコンポーネントの設計や、デザイナーとのコミュニケーションに集中できました。 成果：個人の挑戦がもたらしたチームへの好影響 デザインシステムの構築から約半年、その効果を測定するために、利用しているエンジニアを対象としたアンケートを実施しました。 開発体験の向上を裏付けるデータ アンケートでは、デザインシステムの貢献度について 5 段階評価で回答してもらいました。 UI 実装速度の向上 ：4.05 点 UI の一貫性担保 ：4.27 点 総合的な貢献度 ：4.27 点 特に、UI の一貫性担保や総合的な貢献度で高い評価を得られたことは、このプロジェクトの目的を達成できた証だと感じています。 さらに、これらの改善活動により、 フロントエンド全体の UI 実装速度が 30% 向上した こともデータで確認できました。 開発現場からのリアルな声 定性的なフィードバックとして、開発者からは以下のような嬉しいコメントが寄せられています。 「Figma のコンポーネント名と実装名が一致しているので、迷わず実装できるようになった」 「Storybook を見れば使い方が一目でわかるので、コミュニケーションコストが大幅に削減された」 「これまで各サービスで独自実装していた UI が共通化され、無駄な実装がなくなった」 エンジニア歴 2 年目の私の活動が、実際に事業やチームの開発体験にこれだけポジティブな影響を与えられたという事実は、私にとって大きな自信になりました。 今後の展望：AI で開発生産性をさらに高める デザインシステムは作って終わりではありません。むしろ、ここからが本当のスタート。このデザインシステムを、事業の成長をさらに加速させる強力な武器へと育てていくために、短期・長期でこんな野望を抱いています。 短期的な目標：コンポーネントの拡充と適用範囲の拡大 まずは、デザインシステムがカバーする UI パターンを増やし、より多くの開発シーンでその価値を発揮できるようにすることに注力します。 コンポーネントの拡充 ：現在の基盤に加え、より複雑で多くのサービスで必要とされるコンポーネントを拡充していきます。デザイナーと協力して汎用的な仕様を定義し、開発を進めることで、各サービスでの車輪の再発明をなくします。 適用範囲の拡大 ：構築したデザインシステムを、プロダクト内のさらに多くのサービスに展開していきます。そのために、既存 UI からの移行ガイドを整備したり、導入を検討しているチーム向けの勉強会を開催したりと、導入をスムーズにする活動に力を入れていきたいです。 これらの活動を通じて、デザインシステムをプロダクト開発に不可欠な存在へと成長させていきます。 長期的な夢：AI とデザインシステムを融合させ、仮説検証の速度を極限まで高める そして長期的には、AI の力を最大限に活用し、 「デザインと実装の境界線を溶かす」 ことに挑戦したいと考えています。 皆さんも、Figma のデザインを実装に落とし込む際の、ちょっとしたズレや手戻りに悩まされた経験はありませんか？私たちは、その根本的な課題を解決したいのです。 目指すのは、例えばこんな世界です。 デザイナーが Figma でワイヤーフレームを描き、「ここのボタンは、ユーザー登録を促すためのものです」といった意図を AI に伝える AI がその意図を解釈し、デザインシステムに定義されたコンポーネントの中から最適なものを提案。さらに、A/B テストのための複数のデザインパターンを自動で生成してくれる プロダクトマネージャーやデザイナーは、生成された実際に動くプロトタイプを使って、エンジニアが一行もコードを書く前にユーザーテストを実施する この仕組みが実現すれば、アイデアの仮説検証サイクルは、数週間から数時間へと劇的に短縮されるでしょう。エンジニアは「Figma を再現する」作業から解放され、より複雑なロジックの実装やアーキテクチャ設計といった、本質的な課題解決に集中できます。 「自ら課題を見つけ、最新技術を駆使して事業を前に進めていける」—そんなレバレジーズの文化を体現するような、未来の開発生産性を創り出すのが、私の野望です。 まとめ：私がレバレジーズで働く理由 ここまで、エンジニア歴 2 年目の私がデザインシステムという大きな課題に挑戦できた話をしてきました。 なぜ、このような挑戦ができたのか。それは、レバレジーズに根付く 「オーナーシップを尊重する文化」と「挑戦を推奨する風土」 があったからだと思います。 大きな課題に対して、たとえ担当者が一人であっても、「やりたいです！」と手を挙げれば、年次に関係なく「まず、やってみなよ」と背中を押してくれる。たとえ実力不足な面があっても、周りの先輩たちがサポートしてくれます。そして、その挑戦を「いいね！」と称賛してくれる仲間がいます。 また、Cursor や Claude Code といった最新の AI ツールをいち早く全社に導入するなど、世の中の新しい流れを柔軟に取り入れ、 開発体験や品質について妥協せず考え抜く文化 も、私にとって大きな魅力です。「現状維持」ではなく、常により良いプロダクト、より良い組織を目指して本気で議論できる環境が、ここにはあると思います。 もし、この記事を読んでいるあなたが、 「言われたものを作るだけじゃ物足りない」 「もっと主体的に、事業にインパクトを与えるような開発がしたい」 「自分の仕事に責任と誇りを持ち、最高のプロダクトを追求したい」 そう感じているなら、レバレジーズは最高の環境かもしれません。 私たちと一緒に、未来の開発生産性を創りませんか？ 最後までお読みいただき、ありがとうございました！ We are hiring! この記事を読んで「レバレジーズ、面白そうだな」「自分もこんな環境で挑戦してみたい」と感じていただけたなら、 ぜひ一度カジュアルにお話ししてみませんか？ 私たちは、この記事で紹介したような課題に、オーナーシップを持って共に挑戦してくれる仲間を募集しています。 あなたからのご応募を、心からお待ちしています。 ■会社説明資料 speakerdeck.com ■採用情報はこちら（HRMOS） hrmos.co ■まずはカジュアル面談から hrmos.co ■開発部の雰囲気がもっとわかる動画はこちら！

2025年7,8,9月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベント開催や、イベント登壇など多様な関わり方で、合計9件のイベントに参加しました！ ※OctoNihon登壇の様子 主催・共催技術イベント 未来を拓くAI技術〜エージェント開発とAI駆動開発〜 7/8に、オンラインにて、AI駆動開発について実際の運用のノウハウも交えながら、現役エンジニアがこれらの技術の基礎から実践的な内容を解説するイベントを開催しました。 （イベント詳細は こちら から） Agile Effect MeetUp #3 アジャイル実践者の“言えなかったこと”を話す夜 7/10に、開発組織の拠点であるポーラ渋谷ビルにて、アジャイル開発に関心のある方を対象とした、オフラインの対話＆交流イベントを開催しました。 （イベント詳細は こちら から） AI・LLM活用による事業ドライブの実践 7/16に、Sansan株式会社の本社であるサクラステージにて、レバレジーズ、Sansan、Macbee Planetの三社共同主催で、AIを事業に適合させる実践的なプラクティスを共有するLTイベントを開催しました。（イベント詳細は こちら から） Devin/Cursor/Cline全社導入 セキュリティリスクにどう対策した？ 7/23に、オンラインにて、AIコーディングエージェントをスピーディーに全社導入した、DMM .com、エムスリー、freee 3社の実践事例をもとに、具体的なセキュリティ対策とその導入プロセスを語るイベントを開催しました。 （イベント詳細は こちら から） 【Product × AI Night】AI時代のつくりかたを語ろう 8/28に、開発組織の拠点であるポーラ渋谷ビルにて、レバレジーズ、Anotherworksの二社共同主催で、開発とプロダクトの二観点でのAI利用を語るLTイベントを開催しました。 （イベント詳細は こちら から） AIが変えるアジャイル、変えられないアジャイル〈MeetUp#4〉 9/4に、開発組織の拠点であるポーラ渋谷ビルにて、「AIが現場にもたらした変化」と「AIでは変えられないアジャイルの本質」について語るイベントを開催しました。 （イベント詳細は こちら から） イベント登壇 未来を拓くAI技術〜エージェント開発とAI駆動開発〜 テクノロジー戦略室の安藤が、未来を拓くAI技術〜エージェント開発とAI駆動開発〜 に登壇しました。 （イベント詳細は こちら から） https://speakerdeck.com/leveragestech/wei-lai-wotuo-kuaiji-shu-ezientokai-fa-toaiqu-dong-kai-fa OctoNihon テクノロジー戦略室の竹下が、OctoNihonに登壇しました。 （イベント詳細は こちら から） https://speakerdeck.com/leveragestech/speckitdedokomadedekiru-kosutohadorekurai 会場スポンサー CTO協会スナック理事 “CTO協会スナック理事”イベントに、会場の提供をしました。 （イベント詳細は こちら から） React Tokyo ミートアップ #9 “React Tokyo ミートアップ #9”イベントに、イベントスポンサーとして会場の提供をしました。 （イベント詳細は こちら から） We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、以下のサイトからご応募ください。 HRMOS求人ページ 会社説明資料

1.　はじめに：「新卒からでも圧倒的に成長・活躍できる」と謳うレバレジーズ。これはナゼなのか？ 「圧倒的成長・早期活躍」を軸に就活していた私 “スガノ” は、レバレジーズに新卒入社し、2025年9月現在、半年が経ちました。そんな私だから語れる、「新卒からでも圧倒的に成長・活躍できる」のはナゼなのかを、2025年 新卒入社〜半年 で 実際にした体験をベース に、結論→根拠となる2つの事実、という順序で証言します。 レバレジーズで叶う「圧倒的成長環境」とは？どんな「活躍」ができるのか？ このブログにて、その真相をぜひ、あなたの目で確かめていただきたいです。 2.　結論：”新卒研修中”でも仕事を”創れる”！ 成長・活躍ができると言える根拠は、以下の2点です。 1. 入社4ヶ月で、かつ研修中にも関わらず、熱意と挙手によって 仕事を創れた ので、 成長の初速が大きい 。 2. その打席で、役員陣や活躍する優秀先輩社員との交流ができ、 更なる成長・活躍の土台が形成 された。 それを証明する 2つの事例 を、これから具体的にお見せします。 3.1.　事例1：新規事業開発コンテストに参加し、圧倒的行動量を発揮できた！ 7月某日の朝、私はあるマネジャーから次のことを言われました。 「昨日、僕らは岩槻さん（レバレジーズ代表取締役）に、僕らのチームの事業案を壁打ちしたね。そこで頂いたフィードバックを元に、本部長と精査しながら〇〇と△△（商社や物流等、超大手複数社）にヒアリングしようか。スガノ君はアプリ開発も、◻︎◻︎部長と連携頼んだ！試算も含め任せたよ！」 研修中の新卒が、入社4ヶ月目でする会話にしてはかなり濃厚ですが、 事実 です。 では、この前にどのような経緯があったのか。時間を巻き戻してみましょう。 時は4月。入社直後の新卒全体研修の最中、運営側から以下のアナウンスがありました。 「近々、LEGOの参加申し込みが開始されます！熱意のある人は、ぜひ応募してくださいね！」 それを聞いて私は、「なぜここでデンマークのおもちゃの話題になるんだ？」と訝しみました。が、よくよく聞いたら、LEGOとは レバレジーズ社内で行う、新規事業開発コンテストの名称 優秀な社員が集い、5人チームを組んで、2泊3日で社長や役員等と合宿する催し とのことでした。...これは応募するしかない！「圧倒的成長と早期活躍」を軸にしていた私は、溢れる熱意を応募フォームに書き綴り、参加を祈りました (LEGO詳細は、以下をご覧ください)。 www.youtube.com 無事選考を突破し、約3ヶ月、新卒研修と並行して、優秀な方々と共にアツい「 活躍・成長・学び 」の日々を過ごしました。私が行った「活躍」ついて、実例を3つ取り上げます。 ①圧倒的量の案をアウトプット 事業案の業界を定めた後、チームメンバー間で事業案を出すフェーズがありました。他の方が0~2案を出す中、私は40を超える事業案をアウトプットしました。実際に、その中から良いものを追加調査するなど、その後のチームに大きな好影響をもたらすことができました。 ②普段やらない体験で、生の声と先端技術の知見を回収 例えば、自らの意思で地元のボランティアをしたり、朝4時に起床して某市場を視察したり、関連する書籍を10冊ほど購入して読み漁ったりしました。某市場の視察時は、その場の資料や展示物を眺めるだけではなく、サポート窓口係の方や外国人観光客、清掃や交通整理をする方々にも個別に話しかけ、徹底してリアルな声を得ました。これを、何の活動・目的もなしに突然しようとする人は少ないでしょう。この行動を生んだ熱源は、LEGOなのです。 ③モックをvibe coading！ 昨今、動くプロダクトによって、関係者間でイメージを具体的に共有するのは当たり前になっています。開発職がチームで私のみだったので、このプロダクト作成を一手に任されました。 AI OCRを使って多様な見た目の書類のPDFを読み込み、グラフや文章を生成するネイティブアプリを作ったり、それを社員別に管理するため、組織図と対応させたwebアプリを作ったり...。 開発職の私だからこその介在価値を発揮しました。 こうした能動的な活動から、オリジナルの価値提供を重ねていけました。 また、成長・学びについては、例えば以下があります。 経営企画本部長 から事業立案に関する講義を限定受講 他職種の解像度が爆上がりし、 活躍する人の仕事 を文字通り真隣で 体感 役員の方々や活躍社員 と、オン／オフで議論や交流ができ、ビジネスへの熱意と理解が段違いにレベルアップ 何より、滅多にできない新規事業立案を、3ヶ月かけて 実学的に学んで実践 このLEGOを通じて、何段階もビジネスパーソンとして磨き上げられたと胸を張って言えます。 この参加を経て、私と面識がない方からも 「LEGOに参加してるの？ 研修と並行して頑張ってるね！ 」と褒めてもらえたり、 「あ、LEGOに参加してた子でしょ、 社内報とかYoutubeで見たよ！ 」 と声を掛けてもらえたりしました。 これはまさしく「活躍」であり、「圧倒的成長」だと言えると思います。 LEGOには、結果で選ばれた優秀な先輩社員も当然いますし、ポテンシャル選抜もしてくれるおかげで私は打席に立てました。本当に感謝しかないですし、手を挙げて大正解だったと思います。 おまけに、声をかけてくださった方々や一緒にLEGOに参加した有志、役員陣全員に触れ、感じたことがあります。それは、私がレバレジーズへの入社を決めた大きな理由の一つである「一緒に働きたいと思える”良い人”（熱量、スキル、他者への感情貢献力が高い優秀な人）」が多いという面です。改めて、レバレジーズは期待値を超えてくるなぁ、と実感した次第です。 3.2.　事例2：入社4ヶ月目で、プロジェクトマネジャー（PM）になり、全社的プロジェクトを任された！ 7月上旬。新卒研修を行っていた私は、エンジニア組織の本部長から次のことを言われました。 「例のプロジェクトについてだけど、PMになりたい？他の選択肢は、メンバーとして引き続き参画するか、他の人に完全に渡すか、とかだけど。」 （このプロジェクトとは、社内ネットワークを最適化させるプロジェクトの一環で、エンジニア組織の内外の部署や、外部の複数企業とも連携する、全社的なものでした。） これらも新卒研修やLEGOと並行ですが、当然、回答は当然一択ですよね。 「もちろんPMやります。私でよろしければ、ぜひ任命お願いします！」 この事実についても、「他との比較」と「具体的学び」の2点で深掘ってみます。 まず比較として、一般的に大手企業でマネジャー職は入社5~10年目、ベンチャー企業でも3~4年目とかでも珍しくないです。 しかしこれらと比べ、レバレジーズで私はたった4ヶ月でPM職を創り出せました。正直、「自分次第で早期から活躍・成長できる」と聞いて入社はしたものの、ここまでの環境とは予想していませんでした。LEGOの時と同様、 新卒研修中にも関わらず 、熱意と挙手でここまで行えたこと、これら 成長の早さと大きさ には感動と感謝しかないです。このPM経験は「圧倒的成長・早期の活躍」の機会そのものでした。 学びに関しては、マネジャーのやり方を「知る」のと「実行する」のは雲泥の差だと、 実務レベル で学ぶことができました。もちろん、コンピュータサイエンス的なハードスキルのノウハウはとても勉強になりましたが、同時に大きかったのがソフトスキル面の学びです。順に具体を示します。 ハードスキル 例えば「netstat | grep tcp4 | wc -l」というコマンドの存在と、それでどんな情報が入手でき、その情報が何に使えるかを説明できるようになりました。これによって、NAT（NAPT）やセッション数、webアプリへの理解がより深まりました。 ソフトスキル 幅広い学びとして、対人折衝（期待値調整）力、ピープル・タスクマネジメント、リーダーシップやイニシアチブ、巻き込み力などがありました。以前から私は書籍や、学生時代・研修等でのリーダー経験から、ノウハウは持っていたのですが、会社組織でのPMはそれらとは全く異なりました。 例えば、連絡手段や頻度は何が最適で、タスクはどの粒度に分解して誰に割り振るのか、どう割り振るのか（解決策を探るhow的思考だけでなく、そもそも解くべき問を立てるwhy的思考は重要で、ハードルも高い！）、頭で考えるだけなら難しくないとは思います。 しかし、同じ脳みそを共有しているわけではなく、初対面で年齢・スキル・価値観、抱えている仕事もバラバラなメンバーらと協働し、タスクを理想的に実行していくのは、想像以上に難儀しました。 ここでの学びは、学生時代やインターンのそれとはレベルが異なり、大変貴重で実践性に溢れていました。 このPM経験によって、活躍する先輩らからも 「もうPMやってるの？ まだ半年すら経ってないよね？ 早いね！」と認められたり、 外部勉強会でお会いした、外部のITベンチャー企業の方からも 「君と話してて、 本当に新卒とは思えないよ。 え〜、うちに来ない？（笑）」と半ば冗談を言われたりしています（笑）。 ここでの多種多様な経験が、今後の更なる「活躍」の土台となると確信していますし、そのために一層努力する所存です！ 4.　さいごに 客観的事実から見ても「 自分次第で仕事は創れるし、圧倒的に成長・活躍できる！ 」と言えると思います。もしあなたが、学びや成長、活躍を軸にしているなら、レバレジーズという会社はその期待に応えるどころか超えてくる企業の一つだと言えます。これは上記を経験した私が、自信を持って保証します！ ここに”環境”は揃っています。 どう輝くかはあなた次第 。「成長したい！」「活躍したい！」と熱く燃える心をお持ちなら、後述のリンクの参照や、弊社社員とのカジュアル面談、または選考の次のステップへ向かうことをおすすめします。噂レベルではない、本当にレバレジーズで働く人から生まれるモノは熱く、面白いと思いますよ？ このブログが、あなたの企業選び、そして未来への一歩のきっかけになれば、筆者冥利に尽きます。最後までお読みいただき、誠にありがとうございました。 新卒エンジニアの1ヶ月目について知りたい！➡︎レバレジーズの新卒エンジニアって何するの？そんな君に伝えたい、1ヶ月目のリアル。 tech.leverages.jp 開発部全体をもっと知りたい！➡︎ 【密着】レバレジーズで活躍する26歳中途エンジニアの1日 www.youtube.com 会社説明資料： https://speakerdeck.com/leverages/leverages-hui-she-shao-jie-zi-liao-zhong-tu-cai-yong-xiang-ke HRMOS求人ページ： https://hrmos.co/pages/leverages/jobs?jobType=FULL&category=1819634044861276161

読む前に この記事に出てくる「珈琲事業部」というのはNALYSYS開発部というシステム本部内開発部の有志による取り組みのことです。実際の事業部ではありません。 万が一珈琲事業部に入りたくてレバレジーズを志望される場合は、システム開発部のエンジニアとしてご応募ください。 はじめに こんにちは。レバレジーズでHRTech系SaaS NALYSYS の開発チーム、NALYSYS開発部でEMをやっております、下畑と申します。 私個人の珈琲入れてみたいなという気持ちから始まったNALYSYS開発部珈琲事業部という取り組みが、全社のテックイベントにて珈琲スポンサーとしてエンジニアたちに珈琲を振る舞うまでに至った経緯を書いてみました。 レバレジーズの雰囲気や楽しさ、珈琲事業部に対する取り組みへの真剣さが伝わる記事になっておりますので、ぜひ読んでみてください。 読むとわかること レバレジーズシステム本部に入ると美味しい珈琲が飲める レバレジーズシステム本部に入るとさまざまな味の珈琲が飲めて珈琲の魅力に気付ける 会社の人たちに珈琲を淹れると普段エンジニアが得にくい喜びが得られる やりたいことを損得なしに一緒に楽しんでくれる人や応援してくれる人が社内にいること 珈琲事業部の本気度 レバレジーズシステム本部の雰囲気 ことの発端 名古屋に住んでいる私の友人から Golpie Coffee という珈琲ロースターの存在を教えてもらいました。ここの豆を納得いく美味しさで淹れるのに半年かかった、という面白い話も同時に教えてもらったので自分もチャレンジしてみたくなりました。 ただ、珈琲を淹れるための器具を調べてみると、そこそこお金をかけないといけない気がしてきて、始めることを躊躇しておりました。 そんなことを考えていたおり、チームメンバーにも珈琲好きがいることが判明。 自分のためだけに器具を揃えるのではなく、彼らが道具を使って会社で珈琲を淹れてくれるのであればいい投資になるなと思い、購入を決意しました。 Go！珈琲事業部！ どうやって淹れるの？ LIGHTUP COFFEE というお店が三鷹にあります。ここではハンドドリップ講習をやっているので、まずは自分がノウハウを収集するために赴きました。 ここでの体験はとても面白かったです。講師が教えてくれたレシピをもとに生徒が珈琲を淹れるのですが、生徒が淹れた珈琲の味がそれぞれ全然違うことに驚きました。 先生が淹れてくれた珈琲は酸味や甘味などのバランスがちょうどよくカドがない珈琲だったのですが、生徒が淹れたものは酸味が強調されていたり、苦味が強調されていたりと、これはがんばり甲斐がある趣味だなと思いました。 淹れてみよう 講習で教えていただいたレシピと珈琲器具とGolpie Coffeeの豆を引っ提げて出社しました。Golpie Coffeeの豆はちょっと高いものでしたので、各フロアにある全自動コーヒーマシンに入っている豆を拝借し、淹れる練習から始めました。 マシンでいれるより美味しく淹れられて嬉しかったのを覚えています。 いい豆夢気分 Golpie Coffeeの豆を3種類購入しました。 どれも中煎り（通常のお店の浅煎り）のものでしたが、1つとても妖艶な香りのする豆がありました。珈琲の実から豆を取り出す精製という工程がありますが、ダブルアナエロビックという方法で精製されたこの豆は、珈琲とは思えないほどのフルーツ感で、パイナップルみたいな味がしたのを覚えています。 みんなでこの珈琲を飲み、珈琲の可能性を珈琲事業部内で共有できたことで、メンバー各々がいろんなお店で珈琲豆を購入してくるようになります。 豆主制度 自分たちで珈琲豆を購入して、自分たちで飲むのもいいのですが、私たちが所属しているNALYSYS開発部のメンバーたちにも飲んで欲しいなという思いが出てきました。 一方で、美味しい珈琲豆は高価なものが多いため、無償で提供し続けるには無理があると感じてもいました。 そこで、開発部のメンバーから豆を提供してもらい、自分たちは技術を持って飲める状態の珈琲をお返しする、という循環を作ろうと考えました。 豆主制度と名付け、現在もこの方式で運用しています。 珈琲好きな開発部メンバーに最初は辻斬りならぬ辻淹れを行い、胃袋をつかみます。 取り組みを面白がってくれた人や胃袋を掴まれた方達が豆主様になってくれました。 通常エンジニアは顧客との距離が遠かったり、自分1人でやった仕事が顧客から評価されることは多くはありません。 自分が淹れた珈琲を豆主様に直接提供したときに感謝される営みはエンジニアにとっては尊いものだと思えました。同じように、自分達で作ったものを自分達で営業するという取り組みをNALYSYS開発部の一部のチームが行なっていますが、彼らはこの喜びの味を知っているのかもしれません。 認知拡大へ 珈琲事業部の取り組みは口コミでNALYSYS開発部以外にも知られることとなります。 レバレジーズではslackに部活チャンネルというものを作ることができます。事業部メンバーがzc-珈琲という部活チャンネルを作ってくれたため、そこに珈琲を注文するためのワークフローを作りました。 会社に対してオープンな場を提供することによって、NALYSYS開発部だけでなく、システム本部長や別事業部の方からの注文も入るようになりました。 この取り組みによって珈琲事業部の名前が色々なところに広まっていくことになりました。 Go！テックフェス！ テックフェスで珈琲スポンサーもやるぞ レバレジーズでは年に2度テックフェスというシステム本部全員参加型の勉強会があります。 過去のテックフェスの様子についてはこちらをご覧ください。 tech.leverages.jp テックフェスの運営さんと珈琲事業部のメンバーの仲が良かったこともあり、珈琲事業部がテックフェスで珈琲を提供する話が持ち上がりました。 200人規模のイベントでしたので、それなりに準備が大変なんだろうなと思いつつも、面白そうだったので参加を表明しました。 エプロン欲しいなぁ テックフェスで珈琲を淹れる際、本気度と一体感を演出するためにみんなでデザインしたロゴの入ったエプロンを作りました。自腹でしたが、大人の遊び感が出て面白かったです。 制約 200人分の珈琲を提供するとなると、豆が2kg程度必要であると見積もりました。 その豆を自腹で払うのは流石に懐が痛いので、システム本部に予算を出してもらうことにしました。通常購入している豆が1000〜2000円/100g程度でしたが、そうなると20000円以上かかります。 提示された予算が20000円程度という制限の中で、これに紙コップやアイスコーヒー用の氷を用意した場合オーバーしてしまうことになります。豆選びを頑張らなくてはいけなくなりました。 豆選び レバレジーズの開発拠点がある渋谷一丁目支店の近くに Single O というコーヒー店があります。 そこの KILLER BEE というブレンドコーヒーを飲んだ時ハチミツのような甘い香りを感じました。 コーヒーがあまり好きではない人の中には、酸っぱい味が苦手という人が多くいらっしゃいます。ここで飲んだコーヒーは酸味が少なく、苦味もそこそこで、甘い香りが強く感じられる珈琲だったのと、価格も1000円/100g以下と手頃だったため、この豆を採用することに決めました。提供を終えた今となってはニーズをしっかり捉えられていたんじゃないかと思います。 大量抽出用のレシピ開発 200人に対して珈琲を都度都度ハンドドリップで淹れていくためには一度に大量の珈琲を淹れる必要がありました。美味しい珈琲を淹れるためのパラメータとして豆を挽いた際の粉の粒度とお湯の温度が特に重要になってきます。 珈琲の粉にお湯を注いでいき、最終的に2〜3分くらいで抽出が終わると渋みが出にくいと言われております。いつもの1杯取りレシピの場合より高速でお湯を落とす必要があったため、まずはいつもより粗めの挽き目で美味しい珈琲が作れるように調整を行いました。挽き目の調整が終わったら温度を変えながら味を見ていき、美味しく作れるレシピを考案していきました。 退勤後にこれらの作業を行なっていたのですが、夜遅くに大量のカフェインを摂取する羽目になりました。飲みすぎて頭が痛くなったのもいい思い出かもしれません。 オペレーションと前日準備の検討 テックフェスの開催が夏だったこともあり、アイスコーヒーの需要が高いことが予想できました。代々木にある フグレンコーヒー というお店ではアイスコーヒーを頼むと瓶に入ったコーヒーを注ぐだけのオペレーションで手早く客を捌いていきます。これを参考に、事前にアイスコーヒーを仕込んでいくことにしました。 また、テックフェスは著名なエンジニアをお招きしてお話ししていただく基調講演(今回はみのるんさん)やレバレジーズエンジニアのLTを聞く場でもあるので、ミルで豆を挽く音がうるさいだろうと判断し、前日に大量の豆を挽いてから現地に赴くことにしました。 珈琲事業部には電動のミルがないため、コマンダンテという手挽きのミル2台を使ってゴリゴリ挽き続け、傍らで大量のアイスコーヒーを抽出しました。 テックフェス運営による宣伝 テックフェスの運営さんは今回特に気合が入っていて、事前に広報活動を積極的に行なっていました。珈琲事業部が参加することもこのような形で宣伝してくれました。 嬉しい宣伝 いざ当日 エプロン、備品、珈琲の粉、アイスコーヒーの準備を終え、万全の状態で当日を迎えました。 氷は当日コンビニで購入する予定でしたので、メンバーには先に会場に入って準備をしてもらい、自分は氷を購入してから会場に入りました。 すると謎の行列が出来ており、その先頭には珈琲事業部のブースが。運営の方の宣伝効果があったのか、テックフェス開始前に珈琲を飲みたいエンジニアの方達がたくさんいたようです。こちらとしては大興奮で急いで氷を持ってブースに向かいアイスコーヒーを注いでいるメンバーを手伝いました。 すごい行列に慄く 8L用意していた珈琲も開始から2時間程度で無くなってしまったため、ホットコーヒーとアイスコーヒーを現場でたくさん淹れることに。嬉しい悲鳴を上げながらいつものテックフェスをまた違った立場で楽しむことが出来ました。 仕込んだアイスコーヒーを捌くメンバー達 反省など アイスコーヒー需要や宣伝による集客効果を見誤りました。もっとアイスコーヒーを準備してから参加したほうがよかったです。ただ、現場では珈琲事業部メンバーが機転を効かせて給湯室への往復を少なくするための工夫をしてくれたり、珈琲事業部ではないNALYSYS開発部メンバーの自主的な協力のもとなんとか珈琲を淀みなく提供出来たのではないかと思います。 珈琲を飲まれた方からは、「いつもは砂糖を入れているがブラックでも美味しく飲めた」など嬉しい感想をいただきました。運営の方がテックフェス自体のFBを募集していたのですが、そこにも珈琲が美味しかったという旨のコメントがあり嬉しかったです。 新たな挑戦 テックフェスでの取り組みでシステム本部内での認知は広がったと思います。 レバレジーズの全社イベントである「納涼祭」にも参加することとなり、さらに多くの方達に珈琲を提供できる機会を得ました。 最近はカケハシさんが行なっている珈琲スポンサーのように外部イベント等でも珈琲を提供できるような存在に憧れを抱いています。NALYSYSが出展するHR系の展示会であったり、レバレジーズが企画している外部勉強会等で珈琲を振る舞える日がくるといいなと思っています。 最後に 自分の好奇心から始まった珈琲事業部という取り組みですが、珈琲好きなメンバー達がただ集まって珈琲を飲んでいるだけだったのが、活動の場所を広げ色々な方に珈琲を提供する立場になったことが不思議でもあり面白く思っております。 メンバーたちが、珈琲の奥深さや提供する喜びに本気でハマりつつあるので、社内でのプレゼンスを高めて本当の事業部になる日がくるといいなぁなんてことを半分本気で考えています。 NALYSYS開発部やシステム本部の皆さんがどういう気持ちで我々を見ているのかはわからないのですが、こんな取り組みを続けさせてくれていることに感謝しています。 私は他にも以下の2つのエントリーをこのブログに書いておりますが、記事を書くときはいつも、人に恵まれたいい会社だなと感じております。 tech.leverages.jp tech.leverages.jp 改めて、取り組みに関わったり、温かい目で見守ってくれている皆様、豆主様へこの場を借りて感謝いたします。 一緒に珈琲を淹れてみませんか？ 毎度宣伝いたしますが、この会社楽しそうだなと思ってくれた方おりましたら、ぜひ採用のご応募お待ちしております！ 一緒に珈琲を淹れてくれるエンジニアの方達を心よりお待ちしております。 会社説明資料 HRMOS求人ページ カジュアル面談はこちら NALYSYS開発部の雰囲気がもっとわかる動画 www.youtube.com

2025年4,5,6月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベント開催やイベント登壇など多様な関わり方で、合計14件のイベントに参加しました！ ※TSKaigi2025スポンサーの様子 主催・共催技術イベント バックエンドTypeScript勉強会 ~Macbee Planet x レバレジーズの事例大公開~ 4/8に、本社渋谷スクランブルスクエアにて、バックエンドTypeScriptについて実際の運用のノウハウも交えながら、実践で役立つ内容を語る、ライトニングトーク形式のイベントを開催しました。 （イベント詳細は こちら から） ドキュメントの鮮度を維持する「しくみ化」の方法　CADDi、DMM.com、IVRyの実践例から 4/23に、オンラインにて、組織体制や運用ルールによる「仕組化」、AI技術による「自動化」の両側面から再現可能な解決策を語る、ライトニングトーク形式のイベントを開催しました。 （イベント詳細は こちら から） AI ×フロントエンド開発のリアル 5/15に、開発組織の拠点であるポーラ渋谷ビルにて、開発現場での事例をもとにAIを活用したフロントエンド開発をテーマにした、ライトニングトーク形式のイベントを開催しました。 （イベント詳細は こちら から） Tech-QA Meetup ～品質で未来を拓く最前線～ 5/15に、オンラインにて、各社の現場でのチャレンジや、実務にすぐ活かせる知見、そしてこれからのQAの在り方について、ライトニングトーク形式で語るイベントを開催しました。 （イベント詳細は こちら から） 技術的負債へのアプローチを考えよう 5/21に、開発組織の拠点であるポーラ渋谷ビルにて、TypeScript好きな若手エンジニアを対象にしたライトニングトーク形式のイベントを開催しました。 （イベント詳細は こちら から） はじめてのLT - TypeScript好き若手エンジニアのためのゆる懇親ナイト 5/21に、トグルホールディングス株式会社様の会場にて、システム・インフラ・プロダクト戦略の3視点から学ぶ負債解消をテーマに、ライトニングトーク形式のイベントを開催しました。 （イベント詳細は こちら から） 開発チームでどう活かす？ MCPでできたこと・できなかったこと 5/28に、オンラインにて、エス・エム・エス、Ubie、SmartHR、クローバの4社から、開発現場でのMCP活用事例について語る、ライトニングトーク形式のイベントを開催しました。 （イベント詳細は こちら から） ビズリーチ社合同勉強会 6/12に、オンラインにて、株式会社ビズリーチの開発組織の方々と合同勉強会を開催しました。 AIの出力の質を上げる。チームの集合知をAIに注入する方法 6/25に、オンラインにて、AIエージェントにチームの集合知を効率的に注入するための工夫について語る、ライトニングトーク形式のイベントを開催しました。 （イベント詳細は こちら から） イベント登壇 バックエンドTypeScript勉強会 ~Macbee Planet x レバレジーズの事例大公開~ レバテック開発部の大内が、バックエンドTypeScript勉強会に登壇しました。 （イベント詳細は こちら から） https://speakerdeck.com/leveragestech/rihuakutaringuituyaruno-yi-cun-nozheng-li PHPカンファレンス小田原2025 レバテック開発部の檜垣が、PHPカンファレンス小田原2025に登壇しました。 （イベント詳細は こちら から） https://speakerdeck.com/leveragestech/gu-kiliang-ki-laravel-nosisutemuha-guan-shu-xing-sutairuderihuakutadekirunoka イベントスポンサー PHPカンファレンス小田原2025 松スポンサー 4/12に行われたPHPカンファレンス小田原2025にて、レバテック株式会社が松スポンサーとして協賛しました。 TSKaigi2025 ゴールドスポンサー 5/23,24に行われたTSKaigi2025にて、レバレジーズ株式会社がゴールドスポンサーとして協賛しました。 会場スポンサー 技術書とお金の話 “技術書とお金の話”イベントに、会場の提供をしました。 （イベント詳細は こちら から） 酒とゲームとインフラとGCP@レバレジーズ ～新緑に乾杯！初夏のクラウド談義〜 “酒とゲームとインフラとGCP”イベントに、会場の提供をしました。 （イベント詳細は こちら から） GitHubCopilotとAI時代のデータ管理方法 ~開発生産性向上やデータ管理・MCPまで~ “GitHubCopilotとAI時代のデータ管理方法”イベントに、会場の提供をしました。 （イベント詳細は こちら から） We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、以下のサイトからご応募ください。 HRMOS求人ページ 会社説明資料

こんにちは！テクノロジー戦略室AI推進チームの苑田です！ AWS Summit 2025 生成AIハッカソンがあり、全部で150チームほど参加した中、 準優勝 することができました！その時に試したAI駆動開発を時系列順でまとめました！ 作成したアプリに関しては別のメンバーが記事を書いてくれたので、一緒にみてもらえるとイメージしやすいと思います！ AWS Summit 生成AIハッカソンで準優勝しました！ AI駆動開発で使用したツール GitHub Copilot GitHub Copilot Coding Agent GitHub v0 担当範囲 苑田：AI Agent(Strands Agents)周り、Backend メンバーA：Backend、スライド作成 メンバーB：Backend、デモ動画作成 メンバーC：Frontend 開発までのスケジュール 生成AIハッカソンの流れ 6月25日に予選があり、作ったアプリケーションを披露する必要があります。 スケジュール は上記の通りですが、通常業務や諸々の対応をしていると、実際の構築期間は ３週間 となりました。当然、通常業務もあるので、メンテ性と可読性の品質を担保する開発ではなく、 スピード重視のVibe Coding で進めることにしました。 Vibe Coding 人間がコードを書かずに自然言語でLLMアプリに指示して開発することを Vibe Coding といいます。とはいえ、適当に開発すると変なコードが出来上がるので、以下の順番でコーディングするようにしました。 作りたいものをAIと壁打ちして要件を決める AIに詳細設計を作成してもらう 何をすべきかTODOリストを作成してもらう どのAIでもタスクを処理できるように、GitHub IssuesにTODOを登録する Issueを元にAIがコードを書く AIがPRを作成する PRをレビューして問題なければマージ できるかぎり人間の動作を減らすために、Issueの登録やPRの作成は GitHub MCP を使って自動化しました。 下記のように copilot-instructions.md にOrganizationとリポジトリの詳細を記載することで、エンターキーを押すだけで開発が進んでいきます。 <!-- I want to review in Japanese. --> # リポジトリ - Organization: "現在の組織" - repository: "現在のリポジトリ" <!-- I want to review in Japanese. --> また、「なぜGitHub issuesを使うのか」という話は後で出てきます。 AIの書いたコードを全て許可する Vibe Codingをしていると、AIの開発スピードが早すぎてレビュワーの負荷がかかり、人間がボトルネックになってしまいます。なので、基本的にAIが書いたコードは全て許可する方針で開発を進めました。 これは実験的な部分もあったのですが、今後AIが賢くなって行った時に、 全部AIが開発、運用、テスト、レビュー、修正をやってくれるといいよね！ とチーム内で会話になったのがきっかけです。 設計は人間が行い、 開発、修正に関してはAIに任せる というスタイルで開発を進めました。 黒☆魔☆術コードができてしまった 基本的にレビューせずに即マージすることはまずあり得ないので、とても気持ちが良くポチポチマージしていました。このタイミングではもうすでに人間が読めるコードではなくなっており、 これが本当のVibe Coding と意味不明なことを言ってました。しかし、 発表１週間前 に大問題が発生しました。 これAPIから取ったデータを表示してないんじゃね？ どういうことかというと、 APIからデータを取得してフロントに表示するはずが、毎回同じデータを返してくる という問題が発生しました。 調査した結果、AIエージェントが処理を失敗した時に返す値をそれっぽい固定値で設定しており、APIと連携できていなくとも、きちんとした値を返すようにしていたのが原因でした。 例： def analyze_sentiment(self, text): try: # 実際のAPI呼び出し response = self.sentiment_api.analyze(text) return response['sentiment'] except: # API失敗時の固定値フォールバック return "neutral" 例のように、API呼び出しが失敗したとしても、「neutral」が返ってくるので、フロントエンドではエラーが発生しません。 よくよく考えると、AIエージェントは目的を達成するためにタスク分解して処理をするので、最終的なゴールがフロントに表示することであれば、こういうコードを書いてしまうのは当然でした。 「なるほどな〜」と思いながらリファクタリングをしようとしたのですが、人間の介入はしない前提で開発を進めていたため、ここからが地獄の始まりでした。 人間によるリファクタリング 発表１週間前に黒魔術コードが完成 してしまったので、以下の内容でリファクタリングを行うことにしました。 過剰なtry-exceptを削除 エラーが発生した時に文字列ではなく、エラーコードを返すように修正 人間が確認しやすいように、ディレクトリ構成を整理 APIの疎通ができていない箇所を修正 先ほど記載した通り、AIエージェントは目的を達成するためにコーディングするので、大量の try-except を生成します。なので、不必要な try-except は削除し、エラーが発生した場合、すぐ検出できるように変更しました。 また、とてつもない量のファイルやコードを生成するので、 人間が全部確認するのは不可能 と判断し、人間が確認しやすいようにディレクトリ構成を整理しました。この時はわかりませんでしたが、ディレクトリ構成や内容を README.md に記載すると、AIの迷いが少なくなった気がします。 APIの疎通に関しても、Mockを大量に生成していたので、全て削除しました。 これらの作業に丸3日かかりましたが、なんとかBackendだけリファクタリングを終えることができました。 Frontendは私の担当ではないのでなんとかしてもらおう という魂胆です。当然担当は地獄を見ていました。 AIが開発しやすいような開発環境の作成 発表まで残り4日 。リファクタリングが終わり、AI駆動開発がなかなかうまくいかないなぁと思いながら開発していたのですが、1つの仮説が浮かびました。それは、 AIが開発しやすいような開発環境を用意すれば、AI駆動開発がもっと楽になるのではないか ということです。 今まではAIが好き勝手にコードを書いていたのですが、AIが必要な情報を取得できないと関連する箇所を次々と調査してしまい、本来の目的を見失ってループに入ってしまいます。したがって、AIが効率的に必要な情報へ辿り着けるよう、専用ツールを作成しました。 docker-compose関連のコマンドを叩くシェル ワンコマンドでAIが使用できる MCPの活用 GitHub MCPを駆使して、AIが自動でIssueやPRの確認、作成できるようにする Strands AgentsのDocs MCPを使用することで、最新の情報でもドキュメントを参照できるようにする git worktreeの活用 複数のブランチを同時に開発できるようにする(これは長いので下で書く) 作成したツールをAIに使用してもらうために、 copilot-instructions.md で以下のような指示を書きました。 # 利用可能なスクリプト - `./scripts/run-dev.sh` - 開発環境の起動（自動ポート割り当て） - `./scripts/status-dev.sh` - 全worktreeの状況確認 - `./scripts/stop-dev.sh` - 環境停止 - `./scripts/create-worktree.sh` - 新worktree作成 - `./scripts/remove-worktree.sh` - worktree削除 # AIエージェント向け指示 - `docker-compose logs` などの標準コマンドは使用禁止 - 環境の状況確認は `./scripts/status-dev.sh` を使用 - ポート競合やログ確認が必要な場合は上記スクリプトの出力を参照 これにより、人間がやることを極限まで減らし、AIが開発しやすい環境を整えることができました。以下の画像は、AIが実際に叩くシェルの例で、今このプロジェクトでどのコンテナが動いているかを確認できます。 このようなツールを用意してルールに記載しておくと、ツールを使った結果をAIが確認し、それを元に修正をするようになります。 例えば、エラーが発生した時に以下の手順でAIは修正します。 ステータス確認シェルでコンテナの状況を確認する 確認したコンテナ名やステータスを元に、ログ確認シェルを使用し、ログを確認する 対象箇所を調査する 修正する 動作確認し、エラーが無くなれば終了 このように、適切なツールを渡すことで、変なことをする回数が減りました。 git worktreeによる並列開発 AIが開発しやすい環境を作ってうまく開発ができてきました。しかし、待ち時間が暇なんですよね。 Twitterを見ると怒られるし、どうしようかなと考えていたら、 AIがコードを書いている間に、別のブランチで開発を進めることができるかもしれない と思いつきました。 そこで、git worktreeを使って、複数のブランチを同時に開発できるようにしました。 git worktreeの説明は以下のブログが参考になります。 AIエージェントで並列実装なら必須技術！ Git Worktree を理解する git worktreeを使うと、AIが開発する環境を簡単に作成できます。 私はworktreeを作成、削除するシェル(script以下)を用意しており、以下の構成で使用していました。 親は基本的にworktreeを作成、削除、本番環境のデプロイを行う場所で、子はAIが実際に開発する場所と定義していました。 ここで必要なのが、AIが動作確認するための環境です。 docker-composeを使用しているため、並列で開発しているとportが枯渇する問題が発生しました。なので、portを動的に割り当てて docker-compose up するシェルを作りました。 これにより、AIが簡単に動作確認できます。 また、git worktreeを使用することで、以下のメリットがありました。 AIがコードを書いている間に、別のブランチで別のIssueを進めることができる 同じIssueを複数のAIに処理させ、一番いいものを採用できる 1つ目はそのままですが、2つ目が結構便利でした。 AIは同じプロンプトでも生成する内容が異なるため、２〜4並列でAIに同じプロンプトで生成させ、その中でいいものを選択していました。私たちはこの開発を リセマラ駆動開発 と呼んでいます。 完成！ 無事予選前日の深夜12時にアプリケーションが完成 しました。なんとか完成したのでワイワイしていると、スライド作成していないことに気づき、予選当日の開始１時間前にスライドが完成しました。ここら辺の話は色々あったので、また別のタイミングで話せたらなと思います。 実際にAI駆動開発やってみた結果 今回色々な仮説をもとに検証を行なっていましたが、 AIが開発しやすい環境を作成した途端、爆発的に開発が進みました 。 AIが指示通りに動いてくれない理由は、 考えることが多すぎて変な方向に進んでいく からという結論になりました。AI駆動開発はコーディングしてもらうだけだと思っていたので、タスクを処理しやすいように環境を整えてるのは新鮮で面白かったです。 また、ある程度コードを人間が読めるようにする必要があると感じました。今回はハッカソンだったので最悪全部壊せばいいですが、本番稼働しているアプリだと必ず人間がリファクタリングする必要があります。したがって、 ある程度人間が読めるようにドキュメントを整備したり、コーディング規約を言語化しておく ことで、最悪の事態は避けられると思います。 どうすればもっと開発が楽になるか考えてみた ひとまずアプリをリリースできましたが、今後組織に普及していくために、チーム内でどうすればもっと開発が楽になるかを考えました。話題として上がったのが AIが暴走してしまい、人間が対応するのが大変だった という点です。実際に試したわけではないので話半ばで聞いて欲しいですが、チーム内で結論付けたことを記載しておきます。 テストを書く 今回スピード重視で開発していたため、テストを書かずに構築していました。しかし、AIは目的を達成するために、モックを作ったり、都合のいい処理を書いたりします。明確なテストを用意しておくことで、ある程度この暴走は抑えられるのではないかと考えました。 また、AIがすごいスピードでリファクタリングするので、いきなりコードが動かなくなることも多々ありました。その観点でも、テストがあると人間は安心でき、AIもテストが失敗したら修正を行なってくれるので、チーム内では必須だと結論付けました。 しかし、テストを書いたとしても、そのテストが通るようにコードを生成したりするので、ある程度人間がレビューする必要があります。 プロンプトを使い分ける copilot-instructions.md に守って欲しいことや設計手法など全部記載しても、AIは完全にそれ通りに動くわけではないことを学びました。 したがって、TODO作成プロンプト、構築プロンプト、テストプロンプトのように、プロンプトを分けることで役割分担するのもいいのではないかと考えました。 今回のハッカソンでは、各専門エージェントを使用したマルチエージェントで構築しており、1つのエージェントで構築するより精度が向上しました。 この要領でプロンプトを分ける(claude codeだとカスタムスラッシュコマンド)と、AIが暴走することは少なくなると思います。 まとめ Copilotのプレミアムリクエストが１週間で無くなった時はどうなるかと思いましたが、なんとか乗り切ることができました。 期限内に構築完了し、準優勝できたのは、間違いなくAI駆動開発のおかげだと思っています。 次の目標としては、このAI駆動開発をもっと楽にするような仕組みを開発して、他のチームに展開していきたいです。 おまけ 引き継ぎコンシェルジュ ko☆shi で出しましたが、 引☆継☆王 ko☆shi の可能性もありました。 この命名を考えるのに、冗談抜きで数時間かかったので、もっとマシな会話をしたらよかったなと反省しています。 最後に 最後まで読んでいただきありがとうございます！AI推進チームでは一緒にAI推進を行うメンバーを募集しています！もっとAI推進チームやレバレジーズについて知りたい方は会社説明資料をご覧いただき、ぜひこちらからご応募ください！ AIソリューションアーキテクト（AIエンジニア） AI/機械学習系 研究員