はてなブックマーク

こんにちは、プロダクトAI開発の宮後(miya10kei)です。最近はMakuakeで変わったガジェットを探すのにハマっています🛠️ 昨年、ニーリーで社内AIチャットボットのPoC開発をし、今年の4月から全社で本格的な利用を開始しました。現在は知識領域毎に特化した4つのチャットボットを運用しています。 チャットボット 説明 AI Park Direct Park Directのドメイン知識を回答してくれるチャットボット AI Park Direct for Business Park Direct for Businessのドメイン知識を回答してくれるチャットボット AI 労務 労務関連の社内規定に関して回答してくれるチャットボット AI Analytics BIツールのクエリー検索/解説、NL2SQLなどを回答してくれるチャットボット 今回は、最近新たに社内公開し評判の良かったデータ活

こんにちは、プロダクトAI開発の宮後(@miya10kei)です。 最近は暑さにやられて、自宅に引きこもっている今日この頃です💦 今回はコールセンターの通話内容を通話終了後に、ニアリアルタイムで要約する仕組みを構築したので紹介します。 はじめに ニーリーでは月間数万件の通話が発生する社内コールセンターを運営しています。カスタマー(駐車場の借主様)とクライアント(不動産管理会社様)からの問い合わせに対応する中で、オペレーターの業務効率化が課題となっていました。 オペレーターは通話が終わるたびに内容をテキストでチケット管理システムに記録する必要があります。 慣れた方なら通話しながらメモを取って、電話を切ると同時に記録も完成させられますが、そうでない方は、通話内容をまとめるのに数分かかってしまうこともあります。 その間、次の電話を受けることができないため、あまり長引いてしまうと受電率にも影響が

はじめに こんにちは、プラットフォーム開発グループの菊地(@_tinoji)です。 この度、ニーリーがFindy Team+ 利用企業の中で特に開発生産性が優れた企業として「Organization Award Medium Division」を受賞いたしました。 prtimes.jp 表彰式でトロフィーを受け取るCTO三宅(写真左) ニーリーがFindy Team+を導入したのは今年の3月のため、導入から5ヶ月で表彰していただいたことになります。 まだ利用期間も短く、多くの取り組みができたわけではないのですが、これから開発生産性に力を入れていきたい企業・チームの知見となればと思い、本記事では行った施策の一部を紹介させていただきます。表彰の基準となったのは「開発生産性スコア」というもので、おそらくそれに大きく寄与しているであろうデプロイ頻度と変更リードタイムの2つについて取り上げてみます。

はじめに こんにちは、ARCH チームの立川です。 最近、Axios のリリースノートをチェックしていて 1.8.0 で Breaking Changes が入っていたので(ただし、メジャーバージョンが上がっているわけではない)、今回はその内容について書こうと思います。具体的には、 allowAbsoluteUrls というオプションが追加されたのでそちらに関する説明となります。allowAbsoluteUrls について触れている記事が見当たらなかったので、この記事が皆様のバージョンアップ対応の一助となれば幸いです。 github.com 1.8.0 より前の仕様 allowAbsoluteUrls オプションの設定は、baseURL オプションを利用したリクエスト URL 指定について影響を及ぼします。まずは、1.7.9 での baseURL オプションを使用した例について見ていきます

はじめに こんにちは、SREチームの森原(@daichi_morihara)です。 今回はAmazon ConnectのIaC化および開発体験向上に関する取り組みを共有していきたいと思います。Amazon ConnectはGUIのドラッグ&ドロップによる手作業で簡単にリソースを作成・変更できる利便性が特徴的です。その一方で本番環境でのリソース変更を手作業で行うのはオペミスのリスクが伴うため避けたいものです。 しかし通常リソースのようにAmazon Connectを完全にIaCで管理するのも、必ずしも適切ではありません。なぜならAmazon Connectの長所である直感的なGUIでのリソース作成・変更ができなくなってしまうからです。 そこでAmazon ConnectのGUIベースの開発を維持しつつ、Terraformでリソースを管理し安全にリリースできる仕組みを整えた事例を紹介したいと思

こんにちは。プロダクトAI開発の宮後(@miya10kei)です。 7/31に株式会社find様、株式会社ALGO ARTIS様と共催で「生成AI、実際どう? 〜現場エンジニアたちのぶっちゃけトークミートアップ〜」というイベントを開催させていただきました。 find.connpass.com 「ニーリーにおける生成AI活用の進め方と活用事例」というタイトルで登壇しましたので、今回はその内容をスライドを抜粋しながら紹介します。 speakerdeck.com 生成AIの活用事情 これまで ニーリーで本格的に生成AIの利用を開始したのは2024年下期(7~12月)からになります。きっかけはこちらのブログにある登壇駆動開発です。社内向けのAIチャットボットのPoCを開始し、そこから生成AI活用のテーマを発掘し始めました。2025年上期には事業部門/開発部門ともに業務で生成AIを本格的に活用するよ

はじめに こんにちは、SREチームの森原(@daichi_morihara)です。 今回はDatadogのログのコスト削減に関して最近行った取り組みを共有していきたいと思います。AWSやGCPなどのクラウドに関してはコスト削減・最適化に積極的に取り組んでいる一方で、Datadogに関してはあまりできていない、、というケースは多いのではないでしょうか? (Datadogを使用している場合に限りますが。) 弊社でもDatadogのコスト最適化はあまり行えておらず、提供するサービスのスケールに伴ってDatadogのログコストが着々と増加してきたため、コスト削減に取り組むに至りました。 Datadogログコストの構造 Datadogのログコストは主に2つの要素によって構成されます。 ログの取り込み(Log Ingestion):Datadogに送信されたログの収集・処理・パースするのに発生するコス

yuru-sre.connpass.com お疲れ様です。SREの大木 ( @2357gi ) です。本日は 『ゆるSRE勉強会 #12 SRE乗り越え体験まつり 〜聞いてくれ俺の武勇伝〜』の参加レポです💪 ゆるSRE自体は『ゆるい雰囲気で肩肘張らずにSRE関連のトピックについて話す勉強会』と銘打っており、その通りにゆるくワイワイできるコミュニティです。 今回で12回目、そして2周年だそうです!めでたい 👏👏👏 今回の会場はLINEヤフーさんのLODGEです! 広くてオシャレなオフィス、素敵ですね〜 フードスポンサーは株式会社スタディストさん、ドリンクスポンサーはリブセンスさんです🍻 会場スポンサーLT『オブザーバビリティコミュニティの近況報告』@msksgm speakerdeck.com o11yの公式ドキュメント ja-docs-approver の @msksgm さんの

こんにちは!QAチームの関井(@ysekii_)です。 先日、札幌で開催されたソフトウェアテストシンポジウム JaSST'25 Hokkaido に参加してきました!オフラインでのJaSST参加は6年ぶり、そしてJaSST Hokkaidoへの参加は今回が初めてです。 さて、本記事ではJaSST'25 Hokkaidoの中でも、私が最も楽しみにしていたワークショップ「技法を探せ!2 〜生成AIで進化するテスト設計の実践〜」を中心に、その学びや気づきをレポートします! ......なお、せっかく「生成AIで進化するテスト設計」をテーマにした内容なので、この記事自体も生成AIと一緒に書いています(笑) 実践あるのみ、ということで、AIとペアライティングしながら当日の空気感や気づきをまとめてみました。 JaSST'25 Hokkaidoとは? JaSST Hokkaidoは、ソフトウェアテストに関する知

こんにちは、ニーリーの佐古です。 現在開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 Celeryの"接ぎ木" もともと弊社プロダクトではバッチの実行などにCeleryを利用していた経緯もあり、 高速化のために処理の並列化を考えると あるCelery TaskからべつのCelery Taskに処理を逃がすことが起きます。 これ自体は発想として割と自然なのですが、以下の問題があります。 単純に実装しづらい(特にWeb側) Webリクエストなどバッチ以外のエントリポイントから、 気軽に並列処理を書こうとするとCeleryの構成や制約が邪魔になるのです。 非同期実行を行うには明示的なTask定義とapply_async()が必要で、 依存関係やエラーフローの扱いも暗黙的です。 エラーハンドリングというかエラー検知自体が困難 Task間の例外伝播がされず、モニタリングやトレース

はじめに さて今回はBigQueryで自由記述形式のデータを分類するPart 2ということで、予告通りVector Search を利用したテキスト分類を手軽にできるのか検証していきたいと思います。 (前回のブログでVector Search Indexと述べてますが、Vector Searchを利用するという部分が趣旨になります。) 利用するデータはPart 1と同じ駐車場申し込みのキャンセル理由となりますがインデックスの作成なども検証したかったので前回よりもデータが多めです。 検索対象となるデータが5000件に満たない場合はそもそもインデックスを作成する意味がないため、Vector Search Indexは利用できないのでご注意ください。 なお、結論から言うと前回実施したgeminiIを利用した手法よりは精度が劣っており今回は70%程度の正答率でした。 前回のブログはこちら neal

はじめに こんにちは、ARCHチームの野呂です。 本当は近所の美味しいラーメン屋についてのテック(?)ブログを書こうと思っていたのですが、社内で行われている「LTL会*1」というイベントで共有するために作ったスライドがあったので、先にそれをブログにしたためました。 近所の美味しいラーメン屋は永久に不滅*2ですが、LLMの話題は賞味期限が短いからです。 コーディングエージェントなどのLLMに効率よく追加の情報を渡すためのTipsと、そのための基礎知識について書いておりますので、興味あれば是非ご一読ください。 でも、近所の美味しいラーメン屋についても後で絶対に書きますからね。 たとえ上司や同僚の反対にあったとしても、この情熱は止められないので。 LLMについて 最近LLMがすごいですね。AIAIって、それはもう持て囃されています。 LLMなんて聞いたことないぜ!という方はあんまりいらっしゃらな

SREの大木 (@2357gi)です。最近スノボのオフトレにトランポリンに行ったら、初めてスノボした時ぐらい体がバキバキの筋肉痛になりました。オススメです。 すでにAWS WAFを導入し、スクレイピング対策としてレートリミットも設定しているものの、GoogleBotなどをブロックしたくないため緩い閾値しか設けることができない状態だったのですが、「厳しめのレート制限でスクレイピングを遮断しつつ、Bot Control のラベリングを用いて必要な Bot を許可する」ことを実現したので、記事にしておきます。 背景 弊社はインターネット上で月極駐車場の検索から契約まで行えるwebサービスである「Park Direct」を開発・運営しています。 Park Directにはたびたびスクレイピングと思われるアクセスが来ており、サービスの信頼性にも悪影響が出ることもありました。 一方で、当然ながらSEO

はじめに SREチームの森原(@daichi_morihara)です。今日はバッチの監視周りの取り組みについて共有していこうと思います。 これまではバッチのモニタリングに関して、エラーログの検知・対応のみの最低限の監視を行っている状態でした。そこでバッチ関連のオブザーバビリティの強化およびトイル削減のために以下の3つに取り組みました。 バッチ失敗時の自動再実行の設定 バッチ毎の実行時間や実行結果・インフラレイヤーのメトリクスをまとめたDatadogのダッシュボード作成 DatadogのAPM導入 それぞれの実装において得た学びや注意点を紹介していきたいと思います。 バッチのインフラ構成図 ニーリーでは以下の構成図の通りEventBridgeでStep Functionsを発火し、そのStep Functions内でECSタスクを起動させバッチを実行するという構成をとっています。Step F

はじめに 本記事は、前回の記事「Playwrightへの移行 〜ノーコードツールから乗り換えた理由と、その裏側〜」 nealle-dev.hatenablog.com の続編です。 前回は、私がノーコードツールからPlaywrightへの移行を決断した背景や、準備・設計段階での工夫についてお話ししました。 今回はその続きとして、移行プロジェクトの現場で実際に直面したリアルな課題や、それをどう乗り越えてきたのか、そしてその過程で得られた実践的な運用ノウハウやTipsをご紹介します。 この記事が、すでにE2E自動化やPlaywrightを使い始めている方、そして実装や運用で壁にぶつかっている方にとって、私の失敗や成功の記録が、次の一歩を踏み出すためのヒントになれば嬉しいです。 私が直面した、3つの大きな壁 移行プロジェクトの道のりは、決して平坦ではありませんでした。ここでは、特に印象に残ってい

こんにちは。最近は湿気にやられ気味のSREチームの高 (@nogtk) です。 先日、アプリケーションのエラー監視改善の一環として、Datadog ErrorTracking を導入しました。 厳密には、エラーログをデータソースとして扱う ErrorTracking for Logs を導入しております。長いので、以降本記事では ErrorTracking と呼んでいきます。 実際に導入するまでにやったことをご紹介したいと思います。 ErrorTracking 導入前のアプリケーション監視のやり方 導入前のアプリケーションのエラー監視としては、開発チーム単位で分担しながら以下のように行っていました。 ログレベルが Error あるいは "error" という文言が入っているエラーログが発生した場合にそのエラーログを Slack に通知する 通知されたエラーログを確認し、適宜トリアージする

はじめに ソース定義ファイルとは? ソース定義ファイルはなぜ作る? yamlの生成 テーブル説明・カラム説明の追加 やってほしいこと 追記対象 カラム説明 おわりに はじめに こんにちは、Analyticsチームの清水です。 ガーゴイルゲッコーというヤモリ(8歳)とサイベリアン(1歳4ヶ月)を飼っています。とってもかわいいです。 バナナを食べています(左)ビーズクッション占領猫(右) 前回のブログでは、dbtのデータカタログ機能を使ってみた話を書かせていただきました。 nealle-dev.hatenablog.com その後、社内でよく参照されているトップ50テーブルのソース定義ファイルを作成し、無事にデータカタログを公開できました🙌 今回は、前回さらっと触れた「50テーブルのソース定義ファイルをどうやって迅速に作成したか」についてご紹介します。 同じようにデータカタログの整備を進めて

こんにちは、ニーリーでSET(Software Engineer in Test)を担当している宮内です。 本記事では、私が入社して最初に取り組んだ「E2Eテスト自動化ツールの移行」について、特に「なぜ移行を決断したのか」という背景と、「移行の準備・設計で工夫したこと」を中心に、その舞台裏を書きます。 E2E自動化ツールの移行は、単にツールを置き換えるだけではありません。現場の運用や開発体制にも大きな影響を与える、重要な取り組みです。 「ノーコードツールからコードベースへの移行を検討している」 「E2Eテスト自動化の体制づくりに、まさに今悩んでいる」 そんな方々にとって、私が歩んできた道のりが、少しでも参考になれば幸いです。 1. なぜ移行を決めたのか 壁1:コストと実行回数のジレンマ 移行を検討する最初のきっかけは、コストの問題でした。もともと使っていたノーコードツールは従量課金制であっ

はじめに こんにちは。SREチームの森原(@daichi_morihara)です。最近はゴルフにはまっており、先日初めてラウンドをまわりました。スコアは138😇😇😇、伸び代ですね。 今回はAmazon Auroraのクロスアカウントバックアップの実装と、その際に生じたAmazon AuroraのKMSキーの差し替え作業で得た学びを共有しようと思います。 前提 AWS Backupというサービスを利用してAmazon Auroraのクロスアカウントバックアップを実装しました。AWS BackupはAmazon Auroraに限らず、RDSやDynamoDBなどの多くのサービスのバックアップを簡単に作成・管理することのできる便利なサービスです。 docs.aws.amazon.com このAWS Backupを使用してクロスアカウントバックアップを実装するにあたり、いくつかの制約が存在し

はじめに こんにちは、ARCH チームの立川です。 先日、Angular v20 がリリースされましたね。 https://blog.angular.dev/announcing-angular-v20-b5c9c06cf301 今回のリリースで v18 から Experimental であった Zoneless(Zone.js に依存しない変更検知) が Developer Preview に昇格しました。新しくアプリケーションを作成される方はインストール時に Zoneless を選択するかどうかの確認が入ります。まだまだ先の話かと思いますが、現在 Zone.js を使用しているアプリケーションは Zoneless 化を検討していかなければならなくなると思います。そろそろ対応を考え始めなければならないと思いつつも、まだ全然準備を始めておらず何をすれば良いのか皆目見当もついていない状態だっ

はじめに Park Directでは利用者が駐車場契約の申し込みをキャンセルする時に理由を自由記述形式で入力してもらっています。なぜなら、サービスの改善や顧客満足度向上に不可欠な情報だからです。 また、 キャンセル理由をカテゴリに分類することで、 傾向の把握: どんな理由でキャンセルが多いのか具体的な傾向を数字で把握する 課題の特定: サービスやプロダクトの改善点、顧客サポートの強化すべき点を明確にする 優先順位付け: 影響の大きいキャンセル理由から優先的に施策を講じる 施策の効果測定: 改善施策がキャンセル率にどう影響したか、カテゴリ別に測定できる が行いやすくなります。 しかし、自由記述形式で記録された大量のキャンセル理由を一つ一つ手作業で分類するのは大変な労力ですよね。 今回はBigQueryでこの課題を効率的に解決する方法について考えていきます。 生成AIに分類させる 今回ご紹介す

プラットフォーム開発グループの菊地(@_tinoji)です。自グループのマネジメントをする傍ら、採用と技術広報でもミッションを持って活動しています。 この度ニーリーはDevHRのポジションを新設し、募集を開始したので宣伝です! 求人票はこちら! まずは結論からってことで求人票を貼ります。 herp.careers ↑はすでにDevHR的な経験がある方向けですが、未経験歓迎な求人も作りました。理由については後述します。 herp.careers まずは話だけ聞いてみたい方はカジュ面へ! youtrust.jp 応募ボタンはポチっていただけましたか??? ポチらなかった方は続きをお読みください^^ 求人票はこちら! ニーリーにおけるDevHRとは? なぜ今DevHRが必要になったのか? 特に採用と技術広報に強い人 welcome! 「HR未経験歓迎」とは? 何人募集するの?どういう組織構造にな

プラットフォーム開発グループの菊地(@_tinoji)です。 先日、LAPRASさんのYouTubeチャンネルのシリーズ LAPRAS Engineer Talk にCTOの三宅と一緒に出演させていただき、動画が公開されたのでぜひご覧ください。 先日と言いつつ4月公開なのは許してください。いつの間にか夏が来ていた、、、 ニーリーのプロダクト組織の「染み出す」カルチャー 動画の中では、お客様に郵送する書類を封入する作業にエンジニアが積極的にヘルプに入るエピソードや、カルチャーを維持していくためには継続的な発信や採用で妥協しないことが必要といったお話をしました。 今回お話ししたのは主に「事業への」染み出しが多かった気がしますが、別に事業に限ったことではなく自分の隣接領域に染み出すことを重視しています。すごく簡単な例で言うと、バックエンドとフロントエンドができるエンジニアがさらに自分でインフラも

はじめに こんにちは!Park Direct開発2グループの畠山です。 近年、働き方の選択肢として「フルリモートワーク」が一般的になり、都心から離れた場所で働くことに興味を持つエンジニアの方も増えているのではないでしょうか。 私自身も現在、宮城県仙台市で暮らしながら、フルリモートで開発業務に携わっています。 この記事では私のデスク環境のご紹介から、地方都市でのリモートワーク、そしてそれを支えるニーリーの文化についてご紹介したいと思います。 デスク環境 リモートワークにおいて、仕事のパフォーマンスを左右するといっても過言ではないのが「デスク環境」です。 ウチのメンバーこだわりのデスクたちをご紹介した記事もあるので、よかったらご覧ください👇 nealle-dev.hatenablog.com 私はこんな感じの昇降デスクを使用しています。 デスク周り メインの作業はワイドモニターで行い、Mac

はじめに こんにちは、ARCH チームの立川です。 今回は、Angular Signals を用いて表示フォームとそのバリデーションの切り替えを効率化する方法ついてご紹介します。ユーザーの選択によって入力フィールドが動的に表示・非表示になったり、それに伴ってバリデーションの付け外しが必要になったりするフォームは、コードが複雑になりがちです。この記事では、そうした切替フォームを Angular Signals や Effects を活用して、よりシンプルかつ宣言的に実装する方法を提案します。複雑なフォームのロジックを整理し、保守性の高いコードを書くためのヒントになれば幸いです。 今回のサンプル 今回は「個人」と「法人」のラジオボタンの選択で、入力フィールドが以下のように切り替わるフォームを考えたいと思います。 今回のサンプル 個人選択の場合 表示フォーム 種類 必須 お名前 テキストボックス

こんにちは。 Nintendo Switch 2 の抽選予選に無事コマを進め続けている、SREチームの高 (@nogtk) です。早く当選してこの大会からドロップアウトしたいものです。 今回は、構造化ログのユニットテストを書いたときのプチハマりと、それを解決した方法についてご紹介したいと思います。 なぜログのテストコードを書いたか 前回のブログで、Django アプリケーションが出力するログを構造化したお話をご紹介致しました。 nealle-dev.hatenablog.com ログを構造化するにあたって、出力されるログのエントリを定義しそれに沿ってログが出力されるような実装を追加しています。その中には Datadog APM への連携するためのトレース・スパン情報の付加したり、structlog の contextvars というモジュールを使ってコンテキストをログエントリに含めたりなど

はじめに こんにちは、ARCH チームの立川です。 今回が初めてのテックブログになります。 先日、社内で「条件分岐をスマートに評価する」というテーマで、TypeScript(JavaScript)における条件分岐の書き方について発表する機会がありました。古いコードに触れる中で、見通しの悪い記述を多く見かけることがあったため、発表に至った経緯があります。 この記事では、その発表内容をベースにコードの可読性を高める条件分岐のテクニックをご紹介します。基礎的な内容ではありますが、少しでも役立つヒントがあれば幸いです! 三項演算子をよりスマートに使うためのヒント 三項演算子は非常に便利ですが、状況によってはもっとシンプルで読みやすい代替手段があります。ここでは、等価な三項演算子と比較しながら、それらの方法を紹介します。 null 合体演算子( ?? )を活用する null 合体演算子は、左辺が n

こんにちは、ニーリーの佐古です。 現在開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 事前準備がかさばって本題にフォーカスできない問題 さあ本題です。本題までが長い話は読む気がなくなりますね。 成長期のプロダクトをDjangoで開発していると あまり型情報が信用できなかったりそもそもなかったり 値すら無かったり するケースがあると思います。Pylanceなどのご利益にあずかろうと思うと ガードなりチェックなり書くことになるのですが 有無チェックとデフォルトをやると本題までが長い こういうことになりがちですね。 真面目に読まなくてよいです。 if val0 is None: raise TypeError("val0 must not be None.") if not isinstance(val0, str): raise TypeError(f"val0 must