はじめに 「LayerXって正社員しか採用していないのでは？」「バクラクの開発はハードルが高そう」 そんな印象を持つ方もいるかもしれません。 ただ実際には、LayerX バクラク事業部ではこれまでも 副業・業務委託のソフトウェアエンジニアを受け入れ、プロダクト開発を一緒に進めてきた実績があります。 最近SNSでこの話題に触れた際にも反響があり、「興味はあるけれど、実態が分からない」という方が一定数いることを実感しました。 バクラク事業部で副業・業務委託のソフトウェアエンジニアも受け入れていること、もしや世の中に全然知られていないのでは？？という話を同僚としていたのですが、 これって本当ですか…？ 興味ある方、お気軽にDMください！お話しましょう！！！— serima | LayerX (@serima) 2026年1月8日 本記事では、候補者にとっての不安が大きい どのくらい稼働できるのか

こんにちは、バクラク事業部AI・機械学習部の飯田 (@frkake) です。 こちらはLayerXアドベントカレンダー1日目の記事です。初日は @izumin5210 さんの記事との二本立てです。 最近、DeepSeek-OCRの登場など、OCR界隈がにわかに活気づいていますね。LLMやVLMの進化に伴い、OCRも単なる「文字起こし」から「構造の読み取り」、さらには「内容の理解」へと進化しているのを感じます。 そこで本記事では、改めてOCR技術の変遷を振り返りつつ、各モデルを自作のサンプルデータを使って検証してみたいと思います。 本記事での用語の整理をあらかじめしておきます。 テキスト認識：それがなんの文字であるのかを特定すること。文字起こしを行うこと テキスト検出：文字の位置を検出すること レイアウト認識：画像中の要素の位置や配置を認識すること OCR：画像から文字を書き起こすこと ドキ

LayerX AIエージェント ブログリレー 40日目の記事です。 昨日は ＠yuya_presto さんの「Chrome拡張だけでVercel AI SDKからブラウザを操作する browser-agent-bridge」でした！ こんにちは。すべての経済活動をデジタル化したいmichiru_daです。 私はコーディング未経験の営業上がりのプロダクトマネージャーで、普段自分でコードを書くことはありません。 ですが今回は大エージェント時代に乗っかり、Claude Agent SDKを利用して自分の業務を効率化するAIエージェントを作ってみました。 本記事では、普段エンジニアリングを行わない非エンジニアの目線で、実際の業務ユースケースに沿ってAIエージェントを実装した学びを共有します。エージェント実装そのものの有益なtipsなどは含まれないので、ご了承ください。 この記事の対象読者 自チーム

こんにちは、すべての経済活動をデジタル化したい、@serima です。 先日、CTOの松本（@y_matsuwitter）がエンジニアチームの希望者向けにClaude Maxのアカウント提供を決定し、その内容をポストしたところ、大きな反響がありました。 claude 4 + claude codeが良く出来ていると思い、エンジニアチームの希望者に対してClaude MAXのアカウントを用意することにしました。私も日々使ってるし、社内で既に使っている人は1日で$200分くらい使っており生産性的にも良さそうな印象。— 松本 勇気 (Yuki Matsumoto) | LayerX CTO (@y_matsuwitter) 2025年6月3日 今回は、この意思決定がいかにスピーディーに実現されたかの舞台裏をお話ししたいと思います。 導入の背景と課題 LayerXでは一部のエンジニアがClaude

はじめに こんにちは、LayerX バクラク事業部で請求書発行を担当している QAエンジニアの genny です！ 最近、API の自動テストを実装する中で、プロダクトコードの処理フローを追う必要に迫られました。Cursor を活用することでスムーズに理解を深めることができたので、その過程で得た知見を共有できればと思います。 なぜプロダクションコードを読む必要があったのか 以前のチームでは Ruby on Rails のシステムに携わっており、その時はある程度コードを読めるようになっていましたが、バクラクのバックエンドで採用されている GraphQL や Go で実装されたシステムに携わった経験がありませんでした。 さらに、入社後半年が経過しても、業務の優先度の関係で十分なコードリーディングの時間を確保できていませんでした。 そんな中、自動テストを実装する際、複数のステップを経て API

LayerX QAマネージャーの 中野@naoです。 アジャイル開発のスピード感とあるべき品質保証の両立、悩みますよね。私たちLayerXのQAチームも、日々試行錯誤を重ねています。今回は、その中でも『テストプラン』に焦点を当て、私たちがどのように考え、実践しているのかをご紹介します。 概要 私が所属するバクラク事業部では2週間サイクルでリリースを行なっており、リリース前の3営業日がテスト期間です。QAエンジニアはインプロセスQAとして、各プロダクト開発チームに入ってテストや品質に関わる活動をしています。 従来のテストプランは、テスト戦略、環境、データ、スケジュール、リソース、タスク、リスク管理といった多岐にわたる要素を詳細に網羅していましたが、プロダクトの開発プロセスやクリティカル度合いに応じ、記載項目や内容を柔軟に変化させる必要性が高まっています。 軽量型テストプランから『蓄積型』テス

こんにちは、LayerX AI・LLM事業部でプロダクトマネージャー（PdM）をやっている稲生です。普段は生成AIを企業に導入するためのAi WorkforceというSaaSプロダクトの開発に携わっています。 getaiworkforce.com サマリ 今回は、不具合のハンドリングをする中で活用できそうなAIエージェントを作ってみた、というご紹介です。運用者側の体験や実用性もよく、お客様に価値を届けるスピードも爆速になるのではと感じています。 外部の方にお使いいただくプロダクションレベルではなく、プロトタイプレベルになりますが、社内利用レベルなら少し手直しすれば導入できそうと考えています。 （まだ実践投入しているわけではないので、話半分で読んでいただけると幸いです） 作ったもの Slack上での不具合報告をサポートしてくれるAIエージェントを構築しました。 ここで扱うのは、我々のサービス

こんにちは、LayerXプロダクトマネージャーの野畑(@isseinohata)です。 LayerXで生成AIプラットフォーム Ai Workforceの開発に従事しています。 getaiworkforce.com 2月3日にOpenAIが発表したAIエージェント「deep research」が大きな話題を呼んでいます。 openai.com 生成AIの領域では日々さまざまなプロダクトや新しい技術が登場していますが、その中でもdeep researchは単なるサービス自体の性能の高さに加え、それを実現する技術（人間のリサーチプロセスに近い思考を実現する技術）に対して、未来への大きなインパクトを感じさせる体験でした。 実際、deep researchの調査ログを眺めていると、あたかも人間が試行錯誤するように、自律的に計画→検索→読み込み→発見→方針変更を進めているような姿が見て取れます。 左

こんにちは、バクラク事業部のMLチームでソフトウェアエンジニアをしているTomoakiです。 今回はMLチームのスプリント管理におけるタスク・プロジェクト管理にNotionの新概念であるProjectを導入してみたら嬉しいことがたくさんあったので、それらを紹介したいと思います。 イントロダクション Notionの2.30リリースでプロジェクトという概念が登場し、プロジェクトの管理のテンプレートが公開されるなど大きなアップデートがありました。 www.notion.so 本記事でも紹介しますが、このリリースで紹介されているテンプレートが優秀すぎるので、まだみてない方は是非見てみてください。 MLチームでは5月末ごろから、ちょうどスプリント管理に課題感を感じており、早速NotionのProjectを取り入れて6月中に運用してみましたかなり良かったので、本記事では我々目線でのその効果を紹介したい

こんにちは、全ての経済活動をデジタル化したいTomoakiです。 今回はバクラクで内製しているアノテーション基盤を紹介します。 バクラクのOCR バクラクでは請求書や領収書をはじめ、国税関係書類に対してOCRを実行し入力のサジェストを行うことで、ユーザーが書類の内容を手入力する手間を省いています。例えばこちらの領収書、日付、金額、支払先を自動で読み取ってユーザーにサジェストをしています。 チームでランチに行った時のレシート なぜアノテーション基盤が必要なのか バクラクのOCRでは自前で機械学習モデルを作成しているため、学習用・検証用のデータセットが必要になります。 OCRの処理の概要 OCRに必要なこれらのデータセットはどのようにして作るのが良いでしょうか。 お客様が最終的に入力した値を正解ラベルとするのはどうでしょうか？ 例えば冒頭のレシートの場合、私は7010円として経費精算を申請した

こんにちは。松本(@y_matsuwitter)です。GWはカレーを沢山作っていました。スパイスから作るカレー、思ったよりも手間が掛からないですね。インド料理にハマる波が数年置きにやってきます。 本日は、最近いくつかのイベントでの議論を通じて感じた、開発組織づくりにおいて見られる共通のパターンについて触れつつ、LayerXが意識している取り組みを書いてみようと思います。 最近toBなスタートアップ各社と会った中で、組織の指向性に色々と共通の傾向が見られる気がする。 ・透明性への狂気的な取り組み、公開だけでなく情報整理とチャネル整備 ・採用は技術力そのものよりもカルチャーフィットと学習意欲（もちろん両立が理想だけども） ・開発では速度を最も意識— 松本 勇気 | LayerXはSaaSとFintechの会社です (@y_matsuwitter) 2021年4月22日 各社で見られる最近の組織

ご挨拶 毎々お世話になっております、LayerXから三井物産デジタル・アセットマネジメント（以下、MDM）に出向中の片桐（@akinama3）と申します。 普段は象のアイコンで活動しつつ、ねぎしを世の中に広める仕事をしています。 MDMの概要については、昨日@peroyuki_ がご紹介しているので、ぜひご覧ください。 tech.layerx.co.jp さて、世の中には「銀の弾丸」と思しきデジタル化のバズワードが溢れかえっておりますが、 実際には「業務とはなにか」をひたすら考えぬき、徹底的にSaaSを活用したり泥臭く自分でシステムを作ったりして改善するしか幸せになる道はありません。 というわけで、MDMで徹底的に拘って取り組んだ社内業務効率化の事例として、「意思決定機関である稟議」と「稟議に基づく業務の自動執行」について、ご紹介したいと思います。 実はこのときの実装経験がMDMで進めてい

こんにちは、LayerXでデザインを担当しています森です。 今回は、爆速と呼ばれるDX事業部での開発の様子をお話ししたいと思います。 デザインをしない 以前に @yyoshiki41 がお話ししたように、開発チームは横断的で、エンジニアはフロントエンド、バックエンドを問わず、機能単位で担当し開発しています。その中で私も、フロントエンド、主に表示まわりの開発に関わっています。 tech.layerx.co.jp 事業責任者の @mosa_siru が、「デザインプロセスを挟まない開発」と呼んでいますが、仕様が相談された後、詳細なワイヤーや画面デザインを待つことなく開発が進んでいきます。 機能が実装された後、デザイナーがレイアウトの調整や、少し手間のかかる表示まわりの実装を行っていきます。 デザインをしない、は言い過ぎですが、SketchやFigmaを使う代わりに、IDEを使ってデザインと実装

こんにちは！LayerXの mosa_siru (榎本) です。 LayerX インボイスでは、もともと github.com/go-swagger/go-swagger を利用してREST APIを開発していましたが、最近開発したワークフロー機能 のコンポーネントではGraphQLを取り入れました。 GraphQLには様々なメリットがあり、RESTとの比較記事は多くありますが、なぜ僕らは移行したのか、その結果どうなったのかを紹介していきます。 GraphQLのメリット GraphQLのメリットは、様々な箇所で語られています。例えばこの記事によれば、 強力に型付けされたスキーマであること アンダーフェッチとオーバーフェッチがないこと（後述） Apollo, Relayなどの、クライアントライブラリにより、フロントエンド開発が迅速になること 複数のGraphQL APIからの統合が可能 強力