Ai Workforce事業部 エンジニア組織 紹介資料 

Ai Workforceとは Why Ai Workforce 01 エンジニア組織 Engineering Team 06 Ai Workforceはなにをどう解くのか Product & Approach 02 エンジニアの働き方 Work Style 07 技術設計 Architecture & Technology 03 採用ポジション Join The Team 08 ユースケース Use Cases 04 技術選定と意思決定のプロセス Decision Making 05 Contents 

01.Ai Workforceとは 01 Ai Workforceとは Why Ai Workforce 

01.Ai Workforceとは Ai Workforceは、エンタープライズ企業がAIエージェントを“毎日の 仕事”に組み込むための汎用AIプラットフォームです。 社内に点在するナレッジや業務ルールを整備し、検索・ワークフロー・ AIエージェントを通じて業務とつなぎます。 使われるほどにデータが蓄積され、AIもプロダクトも継続的に進化し ていきます。 どうやってAIに学ばせる？ オンボーディング 指示の背景・前提 業務ルールや過去事例 人間の修正指示 指示 （プロンプト） ファイルなど アウトプット 企業と成長を共にする AIプラットフォーム 

01.Ai Workforceとは 日本企業は今、 「労働人口の減少」 「業務の高度化・複雑化」 「属人化した 知識・判断への依存」 といった構造的な課題を抱えています。 AIへの期待が高まる一方で、 「業務に組み込めない」 「現場で使われない」 というギャップが、 依然として存在しているのが課題です。 高 高 ルール固有度 業務固有性 全世界共通 人が働き カバーしている領域 既存 ソフトウェア 労働人口減少で 失われる仕事 AI活用が求められる 一方で、進まない現実 

01.Ai Workforceとは SaaSでは解けない課題が残り続けている あらかじめ定義された業務・データ構造を前提に最適化されている既存のSaaS。 しかし、 実際の業務は 「例外処理が多い」 「判断基準が暗黙知に依存して いる」 「部署や業務ごとに文脈が異なる」 といった特性を持っています。 その結果、 人がAIやシステムの隙間を埋め続ける構造が残り、 AI活用のスケールが 阻害されています。 固有性が高い業務ほど適応しにくい バーティカルSaaS 未着手／受託 一部のみ製品化 S&M/HR/ バックオフィス等 既存ソフトウェアの制約 全世界共通 高 業務固有性 高 ルール固有度 

01.Ai Workforceとは Ai Workforceは、 受託開発のように一品物を作るのでもなく、 SaaSのように業務を型にはめるのでもありません。 共通プラットフォームの上に、 業務ご と・組織ごとにAIエージェントをセットアップし、 変化に合わせて育て続けることが可能です。 この 「Platform × AIエージェント」 という構造が、 継続的な 業務進化を可能にします。 進化し続けるPlatformだからこそできる 受託開発 個別システム プラットフォーム 個別セットアップ SaaS （既存ソフトウェア） SaaS 

01.Ai Workforceとは Ai Workforceでは、 業務に必要な知識・ルール・文脈をAIに段階的に教える 「AIオンボーディング」 を前提としています。 これにより、 「見積・契約・請求」 「ヘルプデスク・営業支援」 「管理部門・専門業務」 といった多様なユースケースを、 短期間で実運用に乗せることが可能。 AIは単なるツールではなく、 業務 を理解し、 共に働く存在へと進化していきます。 AIオンボーディングで、 すぐに業務へ 営業 事業投資 開発 ストラクチャード ファイナンス 調達 ユースケースマップ（業務 × 部署） ファンド管理 M&A コーポレート 与信 法規文書 契約管理 レビュー 提案書生成 マスキング 見積書 台帳作成 提案書シェア 稟議書 内部監査 リスク管理 ヘルプデスク ビジネスナレッジ 技術文書 稟議書 貿易 データ活用 

02.Ai Workforceはなにをどう解くのか 02 Ai Workforceはなにをどう解くのか Product & Approach 

02.Ai Workforceはなにをどう解くのか Ai Workforceでは、 AIを単体の機能やボットとして扱うのではなく、 複数のAIエージェントが同時並行で業務を進める前提で設計されています。 初期状態 では、 AIは業務文脈をほとんど持っていません。 しかし、 AIオンボーディングを通じて社内ルール・業務知識・判断基準を段階的に学習することで、 実務に 耐えるエージェントへと成長していきます。 数百〜数千のエージェントを活用し、 分散・非同期で働く姿 初期状態 初期のAIエージェントはドメイン知識、 業務知識等に乏しく、業務性能が高くない状態 オンボーディングを施すことにより、AIエージェントに ドメイン知識、業務知識等が備わり業務性能が高くなる AIオンボーディング後 

02.Ai Workforceはなにをどう解くのか USER DONE DONE DONE 複数の エージェントを 同時に利用可能 オンボーディングされていないエージェントは起動時や指示を出す時、 結果に対するフィードバックを与えることでオンボーディングを進める ユーザーはエージェントの処理結果を確認し レビュー等を行う エージェントはユーザーとは非同期に必要な処理をすすめ、 処理が完了したらユーザーに完了通知を行う 実際の業務は、 一つの判断が終わってから次に進む 「直列処理」 ではなく、 複数の確認・調査・判断が同時並行で進行しています。 Ai Workforceでは、 「エージェント ごとの独立した実行」 「非同期処理を前提とした状態管理」 「人による確認・差し戻しを自然に組み込める設計」 によって、 現実の業務フローに近い実行モデルを実 現しています。 業務は、 直列ではなく並列で進む 

Ai Workforceでは、 Agentic Workflowの開発により、複数のAIエー ジェントを前提としたPlatform構造を採用しています。 このPlatform は、 「高い拡張性」 「安定した実行基盤」 「ユースケースごとの柔軟な構 成」 を備えており、 従来の 「単一ワークフロー中心」 の設計から、 エージェ ント中心の設計へと進化しています。 エージェント プラットフォームの Ai Workforce Agent Agent Agent Agent Platform 02.Ai Workforceはなにをどう解くのか 

Ai WorkforceのAgentは、 ゼロから都度実装するものではありません。 AIエージェントは、 Tool （検索・生成・操作） 、 「UI （ユースケース毎に設計 された画面） 」 の組み合わせによって構成されます。 この設計により、ToolやUIなどをInventoryでまとめて管理でき、再利 用性を高め、 スケールしやすいエージェント開発が可能になります。 エージェントは、 都度作らず組み立てる Workroom Tool Inventory UI Inventory Agent searchresult spreadsheet AI WF USER slide search object generate 02.Ai Workforceはなにをどう解くのか 

多くの業務では、 判断に必要な情報はファイルだけで完結しません。 Ai Workforceでは、 社内DB、 マスターデータ、 外部データソースをAIエージェントか ら直接参照できるよう設計されています。 これにより、 「文書を読むAI」 から 「業務データを理解して判断するAI」 へと進化します。 USER Tool Inventory DB lookup Database ETL Internet Data Lake ファイルだけでなく、 データベースも前提 workroomX Agent AI WF 02.Ai Workforceはなにをどう解くのか 

03.技術設計 03 技術設計 Architecture & Technology 

03.技術設計 「実行」から「思考」へ。エージェントの進化 Ai Workforceはエンタープライズと成長をともにするAIエージェントの基盤です。多様なユースケースや業務、ドキュメントを網羅 するため、お客様の業務や指示、データからAIエージェントをオンボーディングしていく基盤を提供します。 実行 思考 業務自動化 事例蓄積による自動化精度向上 分析結果の蓄積 処理結果の蓄積 データの分析活用 複雑業務支援 データ蓄積 帳票処理 契約書処理 など 与信・稟議評価 経営戦略立案 など AIエージェント基盤のアーキテクチャ Architecture 

ワークフローエンジンは、手順の決まった処理を実行するためのLLM ワークフローのプラットフォームです。AIエージェントのような柔軟 性は不要な業務向けに設計されています。 LLMワークフローでは、各種ドキュメント処理をLLMやPythonスク リプトで自動化することにフォーカスしており、ワークフロービル ダー（Web UI）で設計した手順をそのまま実行します。 ワークフローの結果は、DBやストレージにデータとして記録され、 ユーザーによる承認確認が可能です。この承認確認は、LLMの処理結 果を人間の業務成果物と同様に扱い、実際の業務における「確認・承 認プロセス」を再現するために用意されています。 ワークフローエンジン ドキュメントワークを自動化 入力ノード 連携ノード LLM実行（ファイル入力あり） Pythonスクリプト実行 出力ノード LLM実行（情報抽出） LLM実行（ファイル入力あり） 支払日 支払先 取引内容 明細 金額（税抜） 金額（税込） 数量 単価 勘定科目 補助科目 資産区分 管理番号 申請日 申請者 利用期間 備考 03.技術設計 

AIエージェントエンジン自社開発の思想 AIエージェントのエンジン・基盤を自社開発 他社ツールを使わずにエンジンを自作 AIコーディングによる最適化 AIコーディングをフル活用し、 自社に最適な設計・開発を推進 開発だけでなく、コードレビューやQAにも AIコーディングツールをフル活用 AIエージェントに今後大きな変化や イノベーションが発生しても、 独自のタイミングで導入可能 最新技術や方法論を第三者に依存せずに開発 03.技術設計 

AIエージェントを安定して安全に動かすことを目指す AIエージェント実行を司るオーケストレーター 役割 制御フロー管理 状態管理 オーケストレーター エージェント（LLM） 順序・遷移・責務分離を管理 判断・生成・推論に専念 エージェントを短期・単 発実行ではなく、 長時間・ 状態持続型を前提に、
 エージェントの思考・行 動・状態遷移を統合的に 制御します。 グローバルProgram Counterにより、 すべて の処理ステップを平等 に評価・実行します。
 条件分岐・ループ・早期 終了を明示的に表現可 能です。 ローカル思考状態（ス テップ・タスク単位） と、 エージェント全体のグ ローバル記憶を分離す ることで、副作用や競 合を防止し、安定的な エージェント実行を実 現します。 03.技術設計 Orchestrator 

エンタープライズグレードの堅牢性と整合性 エージェントの状態を第一級として扱い、副作用の隔離・再実行を安定化 すべての状態遷移は永続化される クラッシュ後も同一ポイントから決定的に再開 部分更新・メモリ依存状態を排除 状態変更は原子的・順序保証 並列実行は楽観ロック／バージョン管理で収束 冪等性：再試行しても結果が変わらない 堅牢性 整合性 Durability Consistency 前提 業務フローは長時間・非同期・ 再実行前提 障害・再起動・並列実行は、 例外ではなく通常系 03.技術設計 

Inventory ツールインベントリ UIインベントリ AIエージェントを拡張する各種インベントリ AIエージェントは、 多様なツール （データ分析やグラフ生成、 マ スキング等） を活用します。 ツールを登録して利用する仕組みが ツールインベントリです。 インベントリに登録するツールはGitHubリポジトリで管理し、 CI/CDを通じてツールインベントリにデプロイ。 従来のソフト ウェア開発プロセスに沿った開発を行います。 Chat UIだけでなく、 AIエージェントの業務要件や用途に合 わせて差し替え可能なUIインベントリを提供します。 03.技術設計 

03.技術設計 業務とエージェントをつなぐデータシステム ビジネスドキュメントに沿ったハイブリッド検索サービス+各データ基盤（SPO等） と自動連携 Search Index LLM VLM スライド検索はPowerPointのスライド内容を、 LLM／VLMを使ってマルチモーダルなドキュメントとして解析し、 検索インデックスに登録。
 ユーザーからのリクエストをAIエージェントで理解・最適化し、 ユーザーの意図に沿った検索を実現します。 マルチモーダルな ドキュメントを解析 検索インデックスに登録 AIエージェントで 理解・最適化 

AIエージェントのインフラ 独自デプロイメント 共通基盤としてのAi Workforceだけでなく、個社ごとの独自デプロイメントをサポート。 マルチテナントとシングルテナントで、共通基盤と個社基盤の両方に提供。 Foundation Compute &Data Management エンタープライズ領域に強 いMicrosoft Azureを採用。 Azure OpenAIをフル活用。 Container Appsのような汎用的なコンテナオー ケストレーターとPostgreSQLを活用。 クラウド ベンダーロックインを避けるように技術選定。 インフラ管理やOperationにはTerraform （IaC） やOpenTelemetry + Datadog （Observability） を採用。 Observabilityは開発環境か ら導入し本番環境リリース前に監視アラートを含めてテスト。 03.技術設計 

Development AI駆動の開発体制と品質保証 開発体制とツール Coding Pull Request Review Test AIコーディングツールをいち早く導入、 実験し、 生産性向上。 使 い勝手や作り方の思想を学びAi Workforceに取り入れていく。 GreptileやGithub Copilot、 Devin Review等の各種コードレ ビューツールを導入して、 コードレビューのヌケモレを防止。 コードレビューでは評価しきれないUIテストやE2Eテストを、 Claude CodeのSkillとしてQAガイド生成Skillを定 義。 PRを作るときに同時に変更内容からQAガイ ドを生成し、 PRレビューの一貫としてQAを実施する開発プロセス。 ADR駆動開発により、 事前に設計をレ ビュー。 AIコーデ ィ ングで自動開発。 03.技術設計 

AIエージェントを飛躍させるR&D 自己進化するワークフロー 最新の技術をキャッチアップし、プロダクトとお客様の課題を深く解決するためのApplied R&Dチームです。 プロンプト自動生成 ワークフロー自動生成 マルチモーダルドキュメント認識・生成 LLMを活用するためのプロンプトを入力ドキュメントや目的に応じて自動的に生成 業務を自動化するためのワークフローを自動的に生成 ビジネスドキュメントに特化した情報認識 Agentic Workflow 自動生成 ワークフロー自動生成の流れ Generator LLM Workflow Predictions Feedback Meta Prompt Context Executor LLM & Code Evaluator 03.技術設計 

04.ユースケース 04 ユースケース Use Cases 

04.ユースケース 多くの企業業務は、 業務ごとに前提・判断基準・書式が異なり、 非定型・例外が多く、 人の判断を前提に設計されています。 こうした業務は、 SaaSでは対応 が限定的で、 個別開発では高コスト・長期化しがちです。 Ai Workforceでは、 まずこの 「難しさ」 を分解するところから始めます。 固有ルール × 固有業務をAI再設計、 何が難しい？ フォーマット・データソースが多様 社内マスタとの突合が必要 数千ページ、 数千回のLLM呼び出し 個社独自ルールによるエッジケース
 WF / Agent を都度組むと工数が膨大 技術的な課題 業務の全体像 個社独自フォーマット 他部署・他社連携ドキュメント 運用管理資料・業務マニュアル Output 情報抽出・構造化 ナレッジ付与（タグ・メタデータ） リスク分析・不正検知 人の判断を前提にした分岐・確認 Process ナレッジ検索 アクセスコントロール 判断ログ・監査証跡 Basics Input Word / Excel / PowerPoint / PDF / 画像 手動アップロード、 SPO・Box、 メール添付、 基幹システム 営業資料／見積書／業務マニュアル ／契約書／法規・行政文書 

Ai Workforceは、業務を一度きりのAI処理として 扱うのではなく、 再利用可能な構成要素の組み合わ せとして設計しています。 これらの課題を どう分解するか？ エージェント ビルダー ワークフロー ビルダー ナレッジ ポータル 出力レビュー・ フィードバック 精度評価 アクセスコントロール データベース AIワークフロー エンジン カスタマイズ連携 ナレッジグラフ API連携 検索エンジン ツール インベントリ エージェント エンジン UI インベントリ 自動生成・ チューニング 推論 OCR マスキング 入力フォーム プロンプト Deep Research データ加工 チャンキング チャット グラフ生成 ファイル ビューア スライド一覧 ファイル テーブル ワークフロー Python実行 テーブル連携 テンプレート 出力 プロセス マイニング SPO BOX Copilot APP ロジック・ インベントリ 検索 データ・ 外部連携 04.ユースケース 

非定型見積書から明細を抽出・構造化 資産マスタと突合し、 項目・コードを補完 Excelテンプレートに沿って柔軟に出力 既存の資産管理台帳へそのまま連携 例外を前提とした抽出ロジック LLMが計算しながら抽出・自己補正 出力フォーマットを固定しない設計 業務内容に合わせてカスタマイズした テンプレートに自動転記 マスタデータと 自動紐付け 自動分類 明細が多く、整理・分類に時間がかかる 紙をスキャンしたPDFのためコピーできない マスタとの突合・コード付与が煩雑 数百件を超える明細を全て手動転記 課題 での処理 技術的ポイント 04.ユースケース リース見積書の明細抽出・分類・コード付与 Use Case 01 

契約書から顧客名・利率・条件を抽出 semantic chunking による条項単位の分割 稟議書・覚書と紐づけ、 後から検索可能に 管理義務を独自フォーマットの管理表へ転記 意味構造を踏まえた長文分割処理 契約書条番号の階層構造を抽出 Excelテンプレート前提の出力 コベナンツの期限を 企業独自のフォーマットで出力 コベナンツ抽出条件は 柔軟に設定可能 数十〜数百ページに及ぶ長文 稟議書・覚書など関連文書が後から追加 契約期間中の管理義務を正確に把握する必 要がある 課題 での処理 技術的ポイント 04.ユースケース 融資契約書から管理表を自動作成する Use Case 02 

テキストと図表の両方が検索対象 社内テンプレートに沿ったスライド生成 SPO等のコネクタ経由で社内データを活用 pptx形式で出力し、 追加で修正可能 技術的ポイント 図表・グラフの意味をメタデータ化 複雑なテンプレート・1枚完結スライドに対応／AIが作り切らない前提の設計 PDF PDF Text スライド毎の 図表や意味を 理解して検索 複雑な図表やグラフ操作に対応。 データ収集・分析も同じ画面で手軽に。 テキストだけでなく図表に意味がある 部署・案件ごとに形式が異なる 探すことが大変 課題 での処理 04.ユースケース 社内資料から 「テキスト」 「ビジュアル」 で 検索可能 営業資料のナレッジ化・再利用 Use Case 03 

05.技術選定と意思決定のプロセス 05 技術選定と意思決定のプロセス Decision Making 

プロセスとツール 05.技術選定と意思決定のプロセス 大きめの開発に入る前の「標準化」 Architecture Decision Record（ADR） Design Doc 本格的な実装フェーズに入る前に、 以下のドキュメントを作成し、 設計と意思決定の品質を標準化したうえでレビューを行います。
 各ドキュメントには、 Notionテンプレートを用意しています。 複数の選択肢が存在する技術選定や設計判断に利用。 比較的大きな機能開発や、 後戻りできない設計判断に利用。 

定義と目的 主な構成要素 Architecture Decision Record 技術的な意思決定を記録するドキュメント。 複数の選択肢 やトレードオフを比較し、 「なぜその選択をしたのか」を明 確にします。 決定事項に説得力を持たせる 背景・解決したい課題 決定事項 選択肢を俯瞰し、 正しい意思決定を行う 選択肢とPros／Cons 歴史的な背景をコンテキストとして残す 懸念事項・影響範囲 1 1 2 2 3 3 4 05.技術選定と意思決定のプロセス ADR 

具体例：ADR オブザーバビリティツール選定 05.技術選定と意思決定のプロセス 背景・解決したい課題 比較 決定事項 懸念事項・次の手順 

Design Doc 定義と目的 主な構成要素 Design Doc ADR が Why （なぜ選んだか） を記録するのに対し、 Design Doc は What （何を作るか） と How （どう実装 するか） を記載します。 背景 Goals／Non Goals アーキテクチャ シーケンス図・テーブル設計 1 2 3 プロダクトやインフラのアーキテクチャを、 図や文章 （シー ケンス図、 ER 図、 クラス図、 構成図など） で具体化。 API 仕 様、 エラーハンドリング、 パフォーマンス、 セキュリティ要件 も含めて記述します。 実装前に設計をレビューすることで、 潜在的な問題や改善 点を早期に発見でき、 実装後も 「設計の意図」 を振り返る ための重要なドキュメントとして機能します。 05.技術選定と意思決定のプロセス 

具体例：Design Doc 同期方式・データベース構造 処理の流れ 05.技術選定と意思決定のプロセス 外部ストレージ連携・設計 Goals／Non Goals 

LayerXのAi Workforce 事業部が、採用候補者向けに社外公開している プロダクトイシューリストです （※随時更新）。 実際に取り組んでいる課題をご覧いただき、一緒に解決できる方とお会い したいと考えています。 カジュアル面談や面接で、ぜひ議論しましょう。 事業部イシューリスト 採用候補者向けに社外公開している 「課題一覧」 https://layerx.notion.site/LayerX-Ai- Workforce-2025-2026-2a2cdd370bae80fbba7dc812113e1cea 05.技術選定と意思決定のプロセス 

06.エンジニア組織 06 エンジニア組織 Engineering Team 

06.エンジニア組織 組織の全体構造・思想 専門性を束ね、プロダクトという一つのエンジンを動かす Ai Workforceのプロダクト開発は、 個々の専門チームが連携し、 ひとつの目的に向かって動くエコシステムです。 企画・デザイン・開発が中核となり、 FDE、 R&D、 TPMがそれを支えることで、 顧客価値の創出と、 持続的なプロダクト進化を両立しています。 企画グループ ： 顧客課題・市場視点から価値仮説を設計 デザイングループ ： 体験とUIを通じて価値を具現化 開発グループ ： スケーラブルで信頼性の高い実装を担う プロダクトの中核を担うエンジン FDEグループ ： 顧客の現場に深く入り込み、 構造的に課題を解決 顧客価値を届ける最前線 R&Dグループ ： Applied R&Dによりプロダクトの能力を拡張 テクニカルプロジェクトマネジメントグループ ： 品質・セキュリティ・信頼性を担保 R&Dグループ テクニカルプロジェクト マネジメントグループ 未来への投資と信頼の基盤 FDEグループ 企画グループ デザイングループ 開発グループ 

Ai Workforceでは、 「顧客課題を前に進める力」 と 「プロダクトの信頼性を守る力」 を異なる専門性が分担・協調することで実現しています。 顧客と未来に向き合う実装と探究 顧客の現場に深く入り込み、将来の課題も見据えて解決 Platform機能を最大限活用し、 カスタムソリューションを構築 「2歩先、3歩先の課題を構造的にとらえる」 プロダクトの信頼性と安全性を支える守護者 SOC2 / ISMS などの認証取得・維持に加え、 日常的な改善を推進 AIエージェントの不確実性を前提とした品質設計に取り組む 「Applied R&D」 を重視し、 研究成果をプロダクトへ還元 市場・顧客ニーズに直結した研究開発を推進 AIエージェント時代に向けた次世代データ基盤・内部ツールを開発 実務と専門性 顧客価値と信頼を両立する、専門性ベースの働き方 FDEグループ R&Dグループ 品質・セキュリティ・顧客要件への準拠をプロダクト全体で担保 3つの専門性で構成 AI/LLM時代の品質管理 QA セキュリテの維持・向上 セキュリティ セキュリティ要件の実現 テクニカルプロジェクト マネージャー 06.エンジニア組織 

07.エンジニアの働き方 07 エンジニアの働き方 Work Style 

働き方の推しポイント（Q&A形式） 広々としたデスクと、ワイドモニターが快適。 自販機やコーヒーマシンが充実。 休憩時間の技術雑談がリフレッシュに。 通勤を運動不足解消の貴重な時間に捉える。　 07.エンジニアの働き方 開発スタイル・環境 Refresh Office Space Commute Daily Schedule 9:30 | 出社・朝会 9:45のチーム朝会に合わせて出社 10:00 | Focus Time 設計・コーディング・案件進捗の確認 13:00 | Lunch & Coffee チームメンバーと雑談しながら楽しく過ごす 14:00 | Sync & Meeting 案件MTGや採用系のMtgなど。往訪WebMTG を使い分け 18:30 | Break or Off 一度リフレッシュ。用事がある日は早めに切 り上げる 20:00 | 退社 通勤時間を「適度な運動」として活用 Q. あえて「出社」を選ぶ理由は？ Q. 出社派から見た「チームの連携」は？ A. 一番の理由は 『自宅よりも集中できるから』 です。 また、 言語化しきれない 『ふわっとした課題』 をメン バーからさらっと相談されたり、対面ならではのメ リットがありますね。 A. 実は弊社、 オンラインの人が働きやすい環境がかな り整っています。 出社していても基本はSlackで完結。 対 面の良さを享受しつつ、 リモートメンバーともしっかり 連携できる文化があります。 Example FDE Masanori Onda オンオフの切り替えは、 場所を変えるこ とから 『家よ り 集中 できる 』 オフィスと、 非同期 文化の 心地よ いバランス。 

働き方の推しポイント（Q&A形式） 週1日はお客様先に常駐。 その他は 自社・リモートを自由に選択 常駐先の文化に合わせた柔軟なスタイル。 全プロセスに一貫して関われる環境が エンジニアとしての手応えに直結。 恩田 壮恭 開発スタイル・環境 Style Adaptability Flexible Engagement Full-stack Involvement Daily Schedule 9:00 | お客様オフィスに出社 お客様と一日の予定を確認 対面ならではの雑談も 11:00 | QA & Support DX推進チームと打ち合わせ Ai Workforceの活用方法を伝授 12 :00 | L unch C ommunication お客様とラ ンチを共 にし、会議室 では 出 てこ ない現場 の本音や課題 をキャッ チ 15 :00 | Discovery & Design 新規案件 のMTG 。お客様の要望 を踏ま え、 解くべき課題 を特 定す る 17 :00 | R apid P rototyping 当 日中 にデ モや モック を作成 し、 その場で フィ ードバック をもらう 19:00 | Feedback & N ext 1日のインサ イトを整理 Q. なぜ、 お客様先に常駐してい るの？ Q. 「 ただ の御 用聞き」 にならない ため の秘訣 は？ A. お客様と密なコミュニケーションを取るためです。 オフィスで、 ちょっとした相談やアイデアにもその場で 応えられます。 アイデアを素早く形にできることがAiW の強みであり、 常駐でその価値を最大化しています。 A. 本音 を引き出 せる・伝えられる関係性をお客様と築 く こ とです 。 AiWの導入はあくま で手段のひとつ。 真の課 題 は何かをお客様以上に考え抜き、 価値を届けるま で や り抜く 姿勢を大切にしています 。 Example FDE Ikumi Ito 目指すは、 お客様の 「社外CTO」 LLM 活用のラ ストワンマイルを埋め、 確かな価値を届ける。 07.エンジニアの働き方 

働き方の推しポイント（Q&A形式） 会社標準装備の外部モニター等、シンプルかつ 機能的なセットアップ。 出社は「必要に応じて」。基本はリモート、出社が 必要な時は週3〜4など、目的ベースで場所を選択。 開発スタイル・環境 Policy Environment Daily Schedule 9:00 | 始動 保育園の送りを終え、業務開始 10:00 | Deep Work & Design 設計・実装・レビューに没頭。午前中に優先タ スクを完遂 15:00 | Scrum & Sync スクラムイベント等、チームとの同期コミュ ニケーション 18:00 | Family Time お迎え〜夕食。 一度仕事から完全に離れ、 家族と の時間を最優先 21:00 | Focus Hour 差し込みのない時間帯で、一番の「集中」と 「内 省」 を行う Q. ライフステージの変化による影響は？ Q. チームとの連携で意識していることは？ A. 独身時代と変わらず、 むしろ以前より高い質でアウ トカムを出せています。 仕事とプライベートを時間で 完全に切り分けることで、 業務時間内の 『集中密度』 が 劇的に上がりました。 A. 事前のスケジューリングとSlackでの非同期連携を 徹底しています。 これが自分だけでなく、 組織の 『アタリ マエ』 として浸透しているのが LayerX の強みです。 Example SWE Osuke Sudo 家族との時間も、 エンジニアとしての研鑽も アウトプットを最大化するための自律した選択。 07.エンジニアの働き方 

働き方の推しポイント（Q&A形式） 基本はフルリモート。出社は目的がある時のみに 絞り移動。 オンライン／オフラインの差異を感じさせない連携。 住環境の整備がパフォーマンスを支える基盤。 恩田 壮恭 Communication Remote Policy QOL Focus Daily Schedule 8:30 | 稼働 定時より少し早めにスタート。静かな時間帯に その日のタスクを一気に進める 9:30 | Daily Sync チームでの進捗共有。 それ以外は 基本「最初から全力」 でタスクを消化 12:00 | Lunch & Cook 妻が昼食を作ってくれて、一緒に食べる。 夫婦でリモートワークなので、共に過ごす時間 が増えた。 リモートならではの 「家庭の充実」。 食後は愛犬と至福のひととき 13:00 | Flexible Focus 午後の業務。 根を詰めすぎず、 あえて余裕を持つことでアウトカムの質を維持 18:00 | Off & Weekend 週末の充実を見据え、 メリハリを持って 業務終了。 東京在住時より高いQOLを実現 Q. リモートワークで一番変わったことは？ Q. 「出社」をどう捉えていますか？ A. 週末の充実度とプライベートの幸福度が高まりま した。 東京を離れても、 仕事の質やチーム連携に差は 感じません。 リモートでも成果を出せる仕組みが整っ ており、 安定したアウトカムを出せています。 A. 登壇や採用、 顧客MTGに合わせて2泊3日程度で出 社します。 出社時は、 メンバーとの対話やオフラインだ からこそ深められるコミュニケーションを中心に、 関係 構築の時間を大切にしています。 Example TMP 開発スタイル・環境 Yuzuru Ohira QOLとアウトカムを最大化する オンラインとオフラインを 「目的」 で使い分けるプロの流儀。 07.エンジニアの働き方 

08.採用ポジション 08 採用ポジション Join The Team 

Ai Workforce事業部では、 日本を代表する大手企業に対して生成 AIプラットフォーム「Ai Workforce」の導入を推進し、企業の生産 性向上に貢献しています。 エンタープライズ企業のドキュメントワー クをターゲットとし、PDFやWord／Excel／PowerPointといっ た、長年の事業活動で蓄積されたMicrosoft Officeドキュメント のナレッジを、生成AIを活用した最適な業務プロセスへ、安全かつ 滑らかにつなぐプラットフォームです。 FDEグループは、 企画グループ・開発グループ・事業開発＆コンサル ティンググループと密接に連携しながら、 ます。Ai Workforceの を担います。 お客さまの業務に深く入 り込み 本番稼働・デリバリーに技術的な責 任を持ち、 重要なビジネス課題の解決 FDEは、業界・会社・部署ごとに異なるエンタープライズ業務に対 し、 、 業務ドメインを迅速 にキャッチアップします。 そのうえで、 し、 Ai Workforceを用いたソリューションの設計・実装を行います。 主 に事業開発＆コンサルティンググループと小規模なチームで活動 し、 チームです。 具体的には、 以下の業務を一貫して担います。 お客さまと直接連携しながら深く入り込み 業務課題を構造的に整理 プロジェクトの技術責任者として、本質的なビジネス課題に向 き合う 顧客業務に深く入り込み、 プロダクトを本番で届けきる 役割 期待される働き方 顧客ヒアリング・業務理解 ドキュメントの構造化 AIワークフロー／エージェントの構築 LLMアルゴリズムのチューニングおよび精度評価 導入判断のサポート、顧客環境での本番導入支援 グレード MG3〜 FDE（For ward Deployed Engineer） 08.採用ポジション 

現在、 ワークフローやAIエージェントを、 より高い品質と効率性で開 発・実行・評価することが求められています。 Ai Workforce事業部 のR&Dリサーチエンジニアは、 を、 するた めに技術にDeep Diveし課題を解くことを目的としたロールです。 各種ワークフローやデータの自動生成、AI Agentの精度改善と評 価基盤の構築、 複雑なマルチモーダルドキュメント処理、 オンデマン ドなAIエージェント体験など、 することを目指します。 AIやLLM、AIエージェントなどの新 技術 プロダクトやビジネスの現場で実践的に有効活用 事業部が直面する課題を、研究と実 装の両面から実用的に解決 R&Dリサーチエンジニアは、AIやLLM、AIエージェントをプロダク トに組み込み、実用化するための応用技術を研究・検証し、 ツール として形にします。 であることを重視。 また、R&Dの成果を通じてLayerX全体の技術的ケイパビリティを 底上げし、 プロダクト開発における技術選択の幅を広げる役割も 担います。 単なる技術検証に留まらず、最新技術をプロダ クトへ接続し、 ビジネス価値を生み出すR&D リサーチエンジニア 新技術を実用に落とし込み、 プロダクトを進化させる 役割 期待される働き方 グレード MG4〜 08.採用ポジション 

AIエージェントが能力を発揮するには、 です。そのため、契約書・提案書・決算書などの ビジネスドキュメントを整理し、 が急速に高まっています。 データを加工し、検索しやすい状態に整備しておくことが重要 です。 です。多様なドキュメント と検索ニーズに対応し、 を構築します。 適切なコンテキストの 提供が不可欠 正確に検索・活用したいニー ズ AI検索エンジニアはこの課題を解決し、Ai Workforceのプ ラットフォーム基盤を強化する役割 人とAIエージェントの双方が使いやす い情報基盤 AI検索エンジニアは、 フォーマットや目的の異なる大規模なビジネ スドキュメントを対象に、 を担います。 全文検索およびセマンティック検索機能 の設計・実装・運用 AI検索エンジニア ビジネスドキュメントを 「使える知識」に変える 役割 期待される働き方 グレード 検索機能のAi Workforceへの組み込み・改善
 ドキュメント特性やユーザー要件に応じた検索インデックス設計
 検索アルゴリズムおよび検索基盤インフラの設計・最適化
 パフォーマンスチューニング、監視・運用
 Azure AI Searchなどクラウド検索サービスの導入・運用
 社内外ステークホルダーとの要件定義・技術ディスカッション 08.採用ポジション MG4〜 

プロダクトの成長に伴い、マルチモーダルデータのETL・ DWH、LLMやAIエージェントの精度評価、フィードバックデー タの活用など、生成AIを支えるML基盤の重要性が高まっていま す。 シニアデータエンジニアは、こうしたデータシステムを構築・ 発展させることで、 役割になります。 データに根ざしたプロダクトとサービスの 進化を、より速いスピードで支える シニアデータエンジニアは、 ドキュメントデータや を担います。 AIエージェントの コンテキストデータを有効活用するためのデータ管理基盤の開 発・運用 マルチモーダルデータを活かす基盤をつくる 役割 期待される働き方 グレード マルチモーダルドキュメントデータから情報を抽出する手法の選定と推論 推論結果の管理および活用基盤の構築 検索エンジニア、ソフトウェアエンジニア、SREと連携したETL およびデータシステムの開発 シニアデータエンジニア 08.採用ポジション MG4〜 

ソフトウェアエンジニアは、AI Agentが企業のさまざまな業務 プロセスを横断的に支援する、 を担います。めまぐるしく進化するAI技術と、 それによって初めて実現できる新しいアイデアをプロダクトと して形にし、 します。 Ai Workforceプラットフォー ムの開発・運用 お客さまの課題解決を支える基盤を構築 AI Agentを前提としたプロダクト開発を自律的に推進。 具体的に は、 以下のような働き方を期待しています。 AI Agent時代のプロダクト基盤をつくる 役割 期待される働き方 グレード MG3〜 日常的にAI Agentを活用し、それらを手足のように使いこなしながら、 フルスタックなプロダクト開発を行う FDE、PdM、デザイナー、QAなど隣接チームと密に連携し、 プロジェクトを推進する 開発プロセスおよび品質担保の仕組みを、 チームとして継続的に改善・運用する SWE（Software Engineer） 08.採用ポジション 

SREは、 を担います。AI Agent時代を見据えた監視基 盤の設計や、DevOpsにおけるトイルを削減するための 。 SWEやTPMと協業しながら、 します。また、顧客ごとに異なる要件 を持つクラウド環境の構築や、安全なデプロイを実現するため の施策にも取り組むのが役割です。 Ai Workforceの安定稼働を支えるインフラの設計・ 構築・拡張・運用 自動 化・効率化施策を推進 開発から運用までを一体的に支え るアーキテクチャを設計 TPM、CS、 。 役割にとどまらず、 することで、顧客が求める価値を、 タ イムリーかつ高品質で、 安全に提供できる状態を維持します。 AI Agentが当たり前になった世界におけるSite Reliability、 Observability、 そしてAI Agent Reliabilityについて探求し、最 先端の知見を実践に落とし込んでいくことを期待しています。 SWEといった隣接チームと密に連携し、Ai Workforce の安定稼働に貢献 プロダクト開発全体の品質 向上やプロセス改善にも関与 AI Agent時代のプロダクト基盤をつくる 役割 期待される働き方 グレード SRE（Site Reliability Engineering） 08.採用ポジション MG4〜 

AI時代を見据え、市場競争力のある報酬を提供していきます。 AI等による 生産性向上に資する報酬制度を、継続的にアップデート。 給与は、事業特 性・職種別に複数のレンジ （各7段階） で設計しており、 グレードは、 キャリア の道筋を可視化するガイドとして位置づけています。 報酬テーブル 高い生産性に報いる制度 500 MG1 下限〜上限 賞与 （標準評価の場合） 420 650 MG2 MG3 MG4 MG5 MG6 MG7 1,000 1,500 2,000 2,500 3,000 0 年収（万円） グレード 540 660 840 845 1,170 1,560 1,950 1,080 1,440 1,800 2,730 08.採用ポジション 

AIエージェントの進化を、 プロダクトの中核で担う。
 その仲間を、 探しています。 採用サイト Company Deck （企業紹介） 採用ポジション一覧 Ai Workforce公式サイト