サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Google I/O
tech.layerx.co.jp
はじめに LayerX Ai Workforce事業部でApplied R&D をしているtyoyoです。 AI Agentの長期記憶に関して様々な手法が提案されていますが、そのどれもが実際に長期間で運用されたことはほとんどないはずです。なぜなら、それらが台頭したのが最近だからです。 個人的に長期記憶についての肌感覚がなかったので、実験として「1年分のAIニュースの長期記憶」を作ってみることにしました。 最大6並列で約20時間、607回のセッション、4,552個のmemoryファイル ー 動かしてみないと分からない「長期記憶の課題」にぶつかるため、今回はこういった規模でシミュレーションを行いました。 Claude Codeを参考にした簡易的な長期記憶システムの作成 基本的にはClaude CodeのMemoryを参考に、以下のような frontmatter(ファイル先頭のメタデータ記述部分
こんにちは。バクラク事業部 BizOps部 データグループの@civitaspoです。 この記事では、Snowflake と dbt を使ったデータ基盤で、意図しないデータ参照を防ぐために作った dbt package、dbt-authorized-models を紹介します。 github.com はじめに LayerX のデータ基盤では、dbt を使って、データの用途や加工段階に応じてモデルを階層化して管理しています。たとえば、生データに近い層、分析しやすい形に整えた層、業務やプロダクトで使いやすい形に集約した層、というように責務を分けています。 この構造は Medallion Architecture の亜種だと考えてもらえるとわかりやすいと思います。以降では説明のために Bronze / Silver / Gold という呼び方を使いますが、staging / intermedia
こんにちは、Ai Workforce事業部でAI検索エンジニアをしている鷹取です。 AIエージェントにドキュメントを探させる方法として、最近は検索ツールを使わせるアプローチに関心があります。検索APIを直接呼ばせる方法もありますが、ディレクトリを見たり、候補文書を読んだり、検索語を変えたりできる探索的なインターフェースも相性が良さそうです。 その方法として面白いのが、Agent向けの仮想ファイルシステムです。Agentには ls, cat, grep のようなファイル操作を見せつつ、実体は検索エンジン上のデータにします。これなら、Agentはファイルを探索しているように振る舞えますが、システム側では検索エンジンのindexingや権限制御を使えます。 今回は、この仮想ファイルシステムをOpenSearch上に作り、さらに自然文で探せる semantic_search も同じ探索面に追加して
機械学習エンジニアの吉田です。バクラクヘルプデスクエージェントの開発を担当しています。この記事では、バクラクヘルプデスクエージェントにおけるナレッジ更新の同時実行制御を Temporal を活用してどのように実現したか紹介します。 背景 バクラクヘルプデスクエージェントとは バクラクヘルプデスクエージェントは、社内の問い合わせ対応を自動化するAIエージェントで、社内規程や業務マニュアルを元にSlackで多様な質問に自動で回答します。AIで解決できない場合は適切な担当者へシームレスに取り次ぎ、問い合わせをきっかけとしたマニュアルの更新も支援します。 bakuraku.jp AIが正確に回答するには、根拠となる社内ドキュメント群 (ナレッジ) の品質が重要です。ナレッジの元になるのは Notion や Google Drive 上の社内規程・業務マニュアルで、これらのソースと同期し、常に最新の
こんにちは。バクラク給与の開発を担当しているakahaneです。 新規プロダクトとしてバクラク給与を立ち上げ、2026年3月にリリースしました。その開発の進め方について振り返ります。 はじめに バクラク給与の立ち上げでは、Claude CodeやCodexなどのコーディングエージェントを積極的に活用しました。 ただし、これは「AIにコードを書かせたら速かった」という話ではありません。 給与計算は、間違いが許されない領域です。計算結果が1円ズレれば、それは従業員の生活に直結する。「それっぽく動くコード」が最も危険な領域とも言えます。 一方で、新規プロダクトの立ち上げは変化の連続です。仕様も設計もプロダクトの形も日々変わる。このフェーズでは、試作・修正・検証のサイクルをどれだけ速く回せるかが勝負になります。 「間違えてはいけない」と「速く試行錯誤したい」。この一見矛盾する要求の中で、コーディン
こんにちは。バクラク事業部で機械学習エンジニアをしている伊藤(@sbrf248)です。最近はオンライン上で日々流れてくる情報が膨大なので、頭の整理のため紙とペンをよく使うようになりました。GWには(手の届く範囲で)少し高価なボールペンを買ってみました。 さて、近頃はAI・LLMを組み込んだプロダクトやシステムが当たり前になってきています。 私の携わる「バクラク」でも様々なAIエージェントをプロダクトに組み込み、あらゆるバックオフィス業務の自動化を進めています。 bakuraku.jp AI・LLMを組み込む場合、最初に作ったものがそのまま完成ということはあまりなく、継続的な性能の改善が求められるケースが多くあります。特に、ユーザーごとに体験を最適化するパーソナライズされたシステムの場合は、ユーザーのフィードバックをいかにして収集し活用するかが重要です。 日々重要性が高まってきている「ユーザ
LayerX QAエンジニアの小山です。 昨今、AIコーディングアシスタント(特にClaude Code等)の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか? 今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。 ソフトウェアテストの原則「早期テストで時間とコストを節約する」 筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として7つの原則があります。その中の1つとして「早
はじめに こんにちは、バクラクビジネスカード開発チームの @budougumi0617 です。 先月まではテックリードでしたが、4月からエンジニアリングマネージャになりました。 バクラクビジネスカードは2022年からサービスを提供している法人様向けクレジットカードのサービスです。昨年2025年からはETCカードのサービス提供も開始しました。 prtimes.jp 本記事では、もともとクレジットカードの決済データを受け取ることのみを前提に設計されていたバクラクビジネスカードのデータベースに対して新しくETCカードの決済データも受け入れられるようにマイグレーションを行なったときに考えたことをまとめます。 要点を先に書くと、次の3つです。 約3年分の決済レコードが蓄積された本番DBに対して、サービス無停止でスキーマ変更を完了した テーブルごとに許容できるマイグレーション時間も考慮しながらマイグレ
はじめに ケース1: 決済実行時の保存失敗 — 仕様は「ユーザー体験を壊さない」 課題と仕様 設計の考え方 ケース2: 送金結果不明 — 仕様は「統制・監査上の説明可能性」 課題と仕様 設計の考え方 おわりに はじめに こんにちは。LayerX でソフトウェアエンジニアをしている @ysakura_ です。バクラク請求書発行のカード決済機能の新規開発を担当しました。発行した請求書に対してクレジットカードでの決済を受け付けられるようにする機能です。取引先がクレジットカードで支払うと、バクラク請求書発行の利用者には銀行振込で請求書の代金が入金されます。カード決済の受付から銀行振込での入金まで、一連の処理を担う基盤です。 bakuraku.jp この決済機能は外部の決済サービスプロバイダ(以下、PSP)や銀行 API と連携して動いています。決済が成功したのに自システムの保存が失敗した、送金 A
LayerX BizOps 部データグループのさえない (@saeeeeru) です。最近は娘と『名探偵プリキュア!』にハマっています。「自分で見て、感じて、考えて、"本当"の答えを出す」。AI 時代だからこそ刺さるメッセージです(推理パートをちゃんと解けるようになりたい)。 前回の記事では、dbt Python model から外部 API を呼び出す実装パターンを紹介しました。今回はその応用として、LLM の Web Search 機能を使って公開情報を取得し、それをデータパイプラインに組み込む実践例を書きます。 この記事では、まず LLM の Web Search 機能をどう使うとデータパイプラインに載せやすい形になるのか を説明し、そのうえで Snowflake / dbt にどう載せたのか、そして本番運用の中でどんな品質課題が見えてきたのか、という順に整理します。 Web Sea
こんにちは!Ai Workforce事業部FDEの恩田(さいぺ)です。 AIエージェントの進化も凄まじく、どんどん長時間のタスクをこなせるようになっています。この分野のベンチマークの第一人者であるMETRでも、最新のClaude Opus 4.6で10時間のタスクが50%の確率で完了できることが示されています(80%だと1時間)。 (出典: https://metr.org/ , 2026/4/7アクセス) とはいえ、長時間に渡るタスクは、ステップ数も膨大です。各ステップの成功確率を上げたり、リトライや失敗の原因を考え、失敗しても復帰できるような仕組みが必要になりそうです。この分野をいくつか読んだので、その中でもおもしろかった論文をピックアップし、紹介します。 100万ステップのタスクをノーミスで解く 最初に紹介するのは2025年11月に公開された Solving a Million-St
はじめに LayerX バクラク事業部 Platform Engineering 部 Enabling グループの shibutani です。 CIのテストが落ちたとき、開発者がやることは意外と多いです。ログを読み、原因を特定し、担当者を探し修正依頼 or 自分で修正する。これがrace conditionやflaky testのように再現しにくいものだと、対応はさらに後回しにされがちです。 今回、Go testの失敗を検知したらClaudeが自動でログを分析し、担当チームに通知し、修正PRまで作成する仕組みを構築しました。本記事ではその設計と実装を紹介します。 -race フラグの分離と、その先の課題 出発点はPull Request作成時のCIの速度改善でした。これまではPull Request作成時のCIで -race フラグ付きの go test を実行していましたが、-race
宣伝 LayerXでは2026/04/11~26開催の技術書典20でLayerX TeckBook 2を発売します。そちらにも記事を寄稿していますので、もし良ければご一読いただけると幸いです。 techbookfest.org はじめに LayerX Ai Workforce事業部R&Dチームマネージャーの澁井(しぶい)と申します。 本記事はAIエージェントのHuman-in-the-loopを定量評価するための手法やビジネス価値を検討します。 AIエージェントによる業務効率化やソフトウェア開発自動化が進むに従って、AIエージェントのアウトプットを人間が確認してアクションすることが増えていると思います。こうしたAIエージェントに対する人間の確認や行動、承認をHuman-in-the-loopと言います。 Human-in-the-loop(以下HITL)はAIエージェントを安定稼働させるた
こんにちは。fjm2uです。昨年の11月からAi Workforce事業部のFDE(Forward Deployed Engineer)チームでインターンさせていただいております。 この記事では、Ai Workforce事業部のFDEチームへの応募を検討している方向けに、FDEという仕事の特徴と、インターンとして実際に経験した「現場での課題解決がプロダクト改善につながる」流れを紹介します。 FDEの業務 FDEの詳細は以下の記事でも紹介されていますので、そちらをご参照ください。 note.com blog.allstarsaas.com note.layerx.co.jp 私が理解しているFDEとは、お客様の業務を理解しながら、プロダクトをテコとして短期間で顧客課題の根本解決を行い、その経験で得た知見をプロダクトの改善に繋げる職種です。 そして、そのプロダクト改善がはずみ車となり、次回はも
こんにちは。LayerX Ai Workforce事業部でSWEとしてインターンをしているYuです。 本記事では、AIの提案をそのまま実装してうまくいかなかった経験や、フレームワークのソースコードを読んで解決に至ったプロセス、そしてその過程で感じたことについてお話しします。 はじめに みなさんは、普段開発をするときに、Coding Agentを使っていますか? Claude Codeがリリースされてから、Coding Agentの流れが加速したように感じており、最近では自分自身でコードを書くこともかなり減ってきています。自分はソフトウェア開発を始めて2年ほどなのですが、自分の成長スピードを遥かに超える速度で進化するCoding Agentを見ていると、自分が学ぶ意味とは?と思ってしまうことが時々あります。 そんな中、自分なりに学ぶことの楽しさや重要性を感じたタスクがあるので、そのお話につい
はじめに こんにちは!LayerXのバクラク事業部で機械学習エンジニアをしている宇都(@kuto_bopro)です。最近エージェントに関する論文を読んでいると「Self-Evolving」というキーワードを持つ論文をよく目にします。Self-Evolvingは自己進化・自己改善を意味しており、自動で性能が上がっていくAIエージェントの文脈で使われます。 A Survey of Self-Evolving Agents, Figure3より引用 arxiv.org 上記のサーベイ論文で、 Self-Evolving Agentに関して整理されており、エージェントの進化対象(What)はコンテキスト、モデル、ツール、エージェントアーキテクチャと多岐に渡っています。 従来の機械学習では更新対象はモデルパラメータのみでしたが、LLMに対してはそれ以外の選択肢があるのが特徴的です。特にコンテキストに
こんにちは。LayerX Ai Workforce事業部でSREをしています @shinyorke(しんよーく)と申します。 最近はAi Workforceのデータ周りの基盤を作る仕事をしながら、個人としては野球解説AI Agentの開発を頑張っています。 本ブログでは、Ai Workforceのデータ周りの基盤のコンポーネントの一部であるELTの選定をどうしたかについて執筆します。 特に今回は、 マネージドサービス(Azure Data Factory、通称ADF)での構築・実装を検討していたが なぜ断念したのか ADF の代替として dlt + Container App Job を選んだ経緯と、実際どうだったか Azure Cosmos DB for PostgreSQL の Read Replica を相手にしたときに ハマった点と対策 を中心に共有できればと思います。 なお、以下
0. はじめに LayerX Ai Workforce事業部でR&Dチームマネージャーの澁井(しぶい)と申します。 実業務でLLMやAIエージェントを活用するときに頻繁に課題になることとして、作ったLLM/AIエージェントシステムを評価するデータが足りない、ということがあります。こうした課題に対処するため、LLMやAIエージェントを用いて合成データを作ることは一般的なプラクティスと言えます。しかし、必要な品質の合成データを大量かつ多様に作ることは相応に難しく、エンジニアリングが伴います。 本テックブログでは、合成データの作り方に関するTips集を紹介します。このTipsが読者の合成データ作成に貢献できると幸いです。 1. 合成データとは何か? AIエージェント時代に注目される理由 合成データ(Synthetic Data)とは、実データの統計的特性や意味構造を保ちながら、プログラムやモデル
データ検索基盤チームの立ち上げ LayerX Ai Workforce事業部でデータ検索基盤チームのマネージャーを務めている澁井(しぶい)です。先日、R&Dチームを立ち上げた際のエピソードを執筆しましたが、今回はそれに続く第2弾として、新たに「データ検索基盤チーム」を立ち上げた経緯についてお話しします。 tech.layerx.co.jp 生成AIはデータの時代 生成AI時代に差別化を生むのはデータです。 もちろん技術やビジネスモデル、営業力等々、多様な要素も重要ですし、生成AIがなくてもデータは重要です。生成AIが登場し広まったからこそ、なぜデータがクリティカルに重要となるのか、そして生成AIによってデータエンジニアリングがどう変わるのかを説明します。 数多あるLLM/VLMの革新的な能力の一つに、LLM/VLMが多様なモダリティのデータを理解できること、そして推論を構造化して出力できる
こんにちは。バクラク事業部BizOps部データグループのJagaです。 2026年1月にLayerXに入社し、最初のミッションとしてData Enablingチームの立ち上げ*1を担当してきました。1ヶ月が経ってチームの方向性が見えてきたので、考えてきたことや取り組んできたことを紹介します。 LayerXのデータ活用の「今」 バクラク事業部では、プロダクトの利用ログ、営業やカスタマーサポートのデータなど、日々多様なデータが蓄積されています。データ基盤の整備も進んでおり、分析環境はある程度整ってきたと言えそうです。 また、LayerXは行動指針に「Bet AI」を掲げており、全社的にAI活用が盛んです。セールスやコーポレート部門のメンバーがClaude Codeを活用してデータ分析を行ったり、業務を効率化するような事例も珍しくありません。 一方で、課題もあります。「データ基盤と各部門の橋渡し
こんにちは!すべての経済活動を、デジタル化したい @serima です。 この度、技術評論社さんの「Software Design 2026年3月号」より、LayerXによる新連載「実録 AI ネイティブプロダクト開発」がスタートします! 本連載は、AIエージェントをただ動く状態から「実際にプロダクションで価値を生む」状態にするための実践知を、全10回にわたって体系的に公開するものです。 gihyo.jp 全10回の連載テーマ 本連載では、体験設計からバックエンド、運用監視までを網羅する予定です。 Ambient Agent - ユーザー体験に自然に溶け込むAIエージェントの概念とアーキテクチャの紹介 既存システムとの連携 - 既存システムやAPIとの統合手法 Durable Agent設計 - Temporalなどを活用した長時間実行・再開可能なエージェント構築 評価とハルシネーション対
はじめに LayerX Fintech 事業部から、三井物産デジタル・アセットマネジメント(以下、MDM) に出向している piroshi です。 AI 活用や業務自動化が当たり前になってきた今、データや処理はプラットフォームをまたいで動くことが増えています。特に「システム基盤はAWSで動かしつつ、社内業務は Google Workspace 前提」といった構成では、AWS 上のワークロードから Google Cloud(以下、GCP) や Google Workspace の API へ安全にアクセスしたい場面が自然に出てきます。 MDM でもそのニーズが顕在化しました。具体的には、共有ドライブの構成情報を定期的に取得して監査(権限・設定の棚卸し)を自動化したい、という要件があります。加えて、別のチームでは Google Drive 上のリソースにアクセスする業務ツール開発も並行して進ん
こんにちは。LayerX Ai Workforce事業部でSREをしています@shinyorke(しんよーく)と申します。 最近入社1年を迎えました。社内外の皆様の応援とフォローのおかげです、いつもありがとうございます。 1年前は「事業部1人目のSRE」として、プロダクトや事業部のキャッチアップ、採用といった所に奔走していました(詳細はこちらのブログを参照)。 そして現在は新たにJoinしたSREメンバーとともにサイト信頼性エンジニアリングの実現に奔走しています。 本ブログでは、 現在のAi Workforce SREチームの紹介 今後どうしていきたいか(どういうSREと働きたいか) 以上2つのテーマでお送りいたします。 TL;DR Ai WorkforceのSREはチームとして奔走しています、Embedded SREとして楽しみたい方のJoinお待ちしております! 目次 TL;DR 目次
こんにちは、LayerX Ai Workforce 事業部でテクニカルプロジェクトマネージャーをしている joe です。 この記事は LayerX Tech Advent Calendar 2025、18日目の記事です。 今回は異なる処理に関係性を持たせる、Span Links を使った分散トレースの実装について紹介します。 前提条件 本記事では OpenTelemetry の Span Links について紹介をしますが、各用語に対しての説明を省略していることをご了承ください。 なるべく複雑な知識を要しない形での紹介ができるようにしておりますが、不安だという場合は以下のOpenTelemetry の公式ドキュメントにあるトレーシングの項目を参照してから本記事を読み進めることをおすすめします。 https://opentelemetry.io/docs/specs/otel/overvie
はじめに 「LayerXって正社員しか採用していないのでは?」「バクラクの開発はハードルが高そう」 そんな印象を持つ方もいるかもしれません。 ただ実際には、LayerX バクラク事業部ではこれまでも 副業・業務委託のソフトウェアエンジニアを受け入れ、プロダクト開発を一緒に進めてきた実績があります。 最近SNSでこの話題に触れた際にも反響があり、「興味はあるけれど、実態が分からない」という方が一定数いることを実感しました。 バクラク事業部で副業・業務委託のソフトウェアエンジニアも受け入れていること、もしや世の中に全然知られていないのでは??という話を同僚としていたのですが、 これって本当ですか…? 興味ある方、お気軽にDMください!お話しましょう!!!— serima | LayerX (@serima) 2026年1月8日 本記事では、候補者にとっての不安が大きい どのくらい稼働できるのか
こんにちは。Ai Workforce事業部 FDEグループエンジニアのkoseiと申します。 以下本文は、以前インターンとして一緒にプロジェクトを進めてくれた @kimu さんが在籍中に執筆したものです(冒頭のみkoseiが追記しています)。 本ブログで紹介したアルゴリズムにより精度が向上し、お客様に高い価値を提供することができました。(本手法については特許出願済み) そこに至るまでの開発の様々な学びが詰まっているので、是非じっくりとお読みください! はじめに こんにちは!LayerX Ai Workforce 事業部 FDEグループで2025年3月から11月まで約8ヶ月間インターンをしていた@kimuです。インターンでは主にFDE(Forward Deployed Engineer。顧客課題に密着してプロダクト実装まで担うエンジニア)として、生成AIプラットフォーム「Ai Workfor
こんにちは、LayerXのバクラク事業部 AI BPOチームでエンジニアをしているikehara (@ikehara_dev)です。 この記事は LayerX Tech Advent Calendar 2025 19日目の記事です。 本記事では、推論(Reasoning)モデルgpt-5-miniを本番投入した際の事例を紹介します。 当初は推論レイテンシが想定上限に達し、運用が厳しい状態でした。そこから「推論パラメータ調整」と「プロンプトエンジニアリング」を行い、精度を落とさずにレイテンシを改善した方法を、試行錯誤の過程を交えて解説します。 TL;DR gpt-5-mini を本番投入したらレイテンシが厳しくなったため、推論パラメータとプロンプトを見直した reasoning_effort をmedium→low にするだけで40%高速化(15.4秒→9.2秒) プロンプトは 「手順(Ho
こんにちは!Ai Workforce事業部FDEの恩田(さいぺ)です。 7月にFDE(Forward Deployed Engineer)の募集を開始し、早半年が経過しようとしています。本記事では、FDE組織の募集を開始してから現在までをふりかえりつつ、2026年のFDEやLLMについて、組織・技術の両面から綴ってみたいと思います。 tech.layerx.co.jp FDEの募集を始めたのは今年7月なのですが、この半年で突然生まれた職種というわけでなく、その原型はLayerXの創業当時まで遡ります。LayerXでは祖業のBlockchain時代から当時のCTOがお客さまのところに足繁く通ってきました。また、三井物産さまとのジョイントベンチャーである三井物産デジタル・アセットマネジメントにはCTOクラスのメンバーをはじめ、複数のメンバーがフルコミットしています。私自身、LayerXでBlo
この記事は、LayerX Tech Advent Calendar 2025 の 23 日目の記事です。 tech.layerx.co.jp こんにちは。バクラク事業部 BizOps部 データグループの@civitaspoです。今年は子どもたちが入手困難なものをサンタさんにお願いしなかったので、心穏やかな気持ちでサンタさんを家に迎え入れることができそうです。 はじめに 今年も本日を入れて残り9日となりました。本記事では、データ基盤の2025年を締めくくるために、この1年でデータ基盤に起こった変化を振り返ります。 2023年の振り返りは以下の記事でまとめました。 tech.layerx.co.jp 一方で、2024年のまとめはなぜか書き忘れていました…😢 そのため本記事では、2024年後半から2025年にかけて起きたイベントやシステムの変化を軸に、データ基盤がどのような前提のもとで使われる
次のページ
このページを最初にブックマークしてみませんか?
『LayerX エンジニアブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く