Ai Workforce Engineering Hiring Deck

Ai Workforce事業部のエンジニア組織紹介資料です。AIエージェントを中核としたプロダクト思想、アーキテクチャ、開発体制、意思決定プロセス、そして各ポジションの役割までを網羅。エンタープライズの複雑な業務に挑む、私たちの技術と組織の全体像を紹介します。

Transcript

1. Ai Workforce事業部 エンジニア組織 紹介資料
2. Contents Why Ai Workforce Ai Workforceとは 01 Product & Approach Ai Workforceはなにをどう解くのか 02 Architecture & Technology 技術設計 03 Use Cases ユースケース 04 05 06 07 08 Decision Making 技術選定と意思決定のプロセス Engineering Team エンジニア組織 Work Style エンジニアの働き方 Join The Team 採用ポジション
3. 01.Ai Workforceとは 01 Why Ai Workforce Ai Workforceとは
4. 01.Ai Workforceとは 企業と成長を共にする AIプラットフォーム Ai Workforceは、エンタープライズ企業がAIエージェントを“毎日の 仕事”に組み込むための汎用AIプラットフォームです。 社内に点在するナレッジや業務ルールを整備し、検索・ワークフロー・ AIエージェントを通じて業務とつなぎます。 使われるほどにデータが蓄積され、AIもプロダクトも継続的に進化し ていきます。 どうやってAIに学ばせる？ 指示 （プロンプト） ファイルなど 指示の背景・前提 オンボーディング 業務ルールや過去事例 人間の修正指示 アウトプット
5. 01.Ai Workforceとは AI活用が求められる 一方で、進まない現実 日本企業は今、 「労働人口の減少」 「業務の高度化・複雑化」 「属人化した 知識・判断への依存」 といった構造的な課題を抱えています。 AIへの期待が高まる一方で、 「業務に組み込めない」 「現場で使われない」 というギャップが、 依然として存在しているのが課題です。 ルール固有度 高 人が働き カバーしている領域 既存 ソフトウェア 労働人口減少で 失われる仕事 全世界共通 業務固有性 高
6. 01.Ai Workforceとは SaaSでは解けない課題が残り続けている あらかじめ定義された業務・データ構造を前提に最適化されている既存のSaaS。 しかし、 実際の業務は 「例外処理が多い」 「判断基準が暗黙知に依存して いる」 「部署や業務ごとに文脈が異なる」 といった特性を持っています。 その結果、 人がAIやシステムの隙間を埋め続ける構造が残り、 AI活用のスケールが 阻害されています。 ルール固有度 高 未着手／受託 バーティカルSaaS 既存ソフトウェアの制約 固有性が高い業務ほど適応しにくい 一部のみ製品化 S&M/HR/ バックオフィス等 全世界共通 業務固有性 高
7. 01.Ai Workforceとは 進化し続けるPlatformだからこそできる SaaS （既存ソフトウェア） 受託開発 ✖️ ✖️ 個別セットアップ 個別システム SaaS プラットフォーム Ai Workforceは、 受託開発のように一品物を作るのでもなく、 SaaSのように業務を型にはめるのでもありません。 共通プラットフォームの上に、 業務ご と・組織ごとにAIエージェントをセットアップし、 変化に合わせて育て続けることが可能です。 この 「Platform × AIエージェント」 という構造が、 継続的な 業務進化を可能にします。
8. 01.Ai Workforceとは AIオンボーディングで、 すぐに業務へ ユースケースマップ（業務 × 部署） ストラクチャード ファイナンス 契約管理 レビュー 稟議書 ファンド管理 営業 提案書生成 マスキング ヘルプデスク 事業投資 コーポレート 調達 M&A 開発 与信 稟議書 見積書 台帳作成 提案書シェア 法規文書 ビジネスナレッジ 貿易 技術文書 データ活用 内部監査 リスク管理 Ai Workforceでは、 業務に必要な知識・ルール・文脈をAIに段階的に教える 「AIオンボーディング」 を前提としています。 これにより、 「見積・契約・請求」 「ヘルプデスク・営業支援」 「管理部門・専門業務」 といった多様なユースケースを、 短期間で実運用に乗せることが可能。 AIは単なるツールではなく、 業務 を理解し、 共に働く存在へと進化していきます。
9. 02.Ai Workforceはなにをどう解くのか 02 Product & Approach Ai Workforceはなにをどう解くのか
10. 02.Ai Workforceはなにをどう解くのか 数百〜数千のエージェントを活用し、 分散・非同期で働く姿 初期状態 初期のAIエージェントはドメイン知識、 業務知識等に乏しく、業務性能が高くない状態 AIオンボーディング後 オンボーディングを施すことにより、AIエージェントに ドメイン知識、業務知識等が備わり業務性能が高くなる Ai Workforceでは、 AIを単体の機能やボットとして扱うのではなく、 複数のAIエージェントが同時並行で業務を進める前提で設計されています。 初期状態 では、 AIは業務文脈をほとんど持っていません。 しかし、 AIオンボーディングを通じて社内ルール・業務知識・判断基準を段階的に学習することで、 実務に 耐えるエージェントへと成長していきます。
11. 02.Ai Workforceはなにをどう解くのか 業務は、 直列ではなく並列で進む 複数の エージェントを 同時に利用可能 エージェントはユーザーとは非同期に必要な処理をすすめ、 処理が完了したらユーザーに完了通知を行う DONE DONE USER DONE オンボーディングされていないエージェントは起動時や指示を出す時、 結果に対するフィードバックを与えることでオンボーディングを進める ユーザーはエージェントの処理結果を確認し レビュー等を行う 実際の業務は、 一つの判断が終わってから次に進む 「直列処理」 ではなく、 複数の確認・調査・判断が同時並行で進行しています。 Ai Workforceでは、 「エージェント ごとの独立した実行」 「非同期処理を前提とした状態管理」 「人による確認・差し戻しを自然に組み込める設計」 によって、 現実の業務フローに近い実行モデルを実 現しています。
12. 02.Ai Workforceはなにをどう解くのか エージェント プラットフォームの Ai Workforce Ai Workforceでは、 Agentic Workflowの開発により、複数のAIエー ジェントを前提としたPlatform構造を採用しています。 このPlatform は、 「高い拡張性」 「安定した実行基盤」 「ユースケースごとの柔軟な構 成」 を備えており、 従来の 「単一ワークフロー中心」 の設計から、 エージェ ント中心の設計へと進化しています。 Agent Agent Agent Platform Agent
13. 02.Ai Workforceはなにをどう解くのか エージェントは、 都度作らず組み立てる Ai WorkforceのAgentは、 ゼロから都度実装するものではありません。 AIエージェントは、 Tool （検索・生成・操作） 、 「UI （ユースケース毎に設計 された画面） 」 の組み合わせによって構成されます。 この設計により、ToolやUIなどをInventoryでまとめて管理でき、再利 用性を高め、 スケールしやすいエージェント開発が可能になります。 USER Tool Inventory slide search object generate Workroom Agent AI WF UI Inventory spreadsheet searchresult
14. 02.Ai Workforceはなにをどう解くのか ファイルだけでなく、 データベースも前提 workroomX Agent AI WF Tool Inventory DB lookup Database USER Internet Data Lake ETL 多くの業務では、 判断に必要な情報はファイルだけで完結しません。 Ai Workforceでは、 社内DB、 マスターデータ、 外部データソースをAIエージェントか ら直接参照できるよう設計されています。 これにより、 「文書を読むAI」 から 「業務データを理解して判断するAI」 へと進化します。
15. 03.技術設計 03 Architecture & Technology 技術設計
16. 03.技術設計 AIエージェント基盤のアーキテクチャ Architecture 「実行」から「思考」へ。エージェントの進化 Ai Workforceはエンタープライズと成長をともにするAIエージェントの基盤です。多様なユースケースや業務、ドキュメントを網羅 するため、お客様の業務や指示、データからAIエージェントをオンボーディングしていく基盤を提供します。 事例蓄積による自動化精度向上 分析結果の蓄積 実行 思考 業務自動化 帳票処理 契約書処理 など 複雑業務支援 与信・稟議評価 経営戦略立案 など データ蓄積 処理結果の蓄積 データの分析活用
17. 03.技術設計 ワークフローエンジン ドキュメントワークを自動化 ワークフローエンジンは、手順の決まった処理を実行するためのLLM ワークフローのプラットフォームです。AIエージェントのような柔軟 性は不要な業務向けに設計されています。 LLMワークフローでは、各種ドキュメント処理をLLMやPythonスク リプトで自動化することにフォーカスしており、ワークフロービル ダー（Web UI）で設計した手順をそのまま実行します。 ワークフローの結果は、DBやストレージにデータとして記録され、 ユーザーによる承認確認が可能です。この承認確認は、LLMの処理結 果を人間の業務成果物と同様に扱い、実際の業務における「確認・承 認プロセス」を再現するために用意されています。 入力ノード LLM実行（ファイル入力あり） LLM実行（ファイル入力あり） LLM実行（情報抽出） Pythonスクリプト実行 出力ノード 金額（税抜） 金額（税込） 数量 単価 勘定科目 補助科目 資産区分 管理番号 支払日 支払先 取引内容 明細 申請日 申請者 利用期間 備考 連携ノード
18. 03.技術設計 AIエージェントエンジン自社開発の思想 AIエージェントのエンジン・基盤を自社開発 他社ツールを使わずにエンジンを自作 AIコーディングによる最適化 AIエージェントに今後大きな変化や イノベーションが発生しても、 独自のタイミングで導入可能 最新技術や方法論を第三者に依存せずに開発 AIコーディングをフル活用し、 自社に最適な設計・開発を推進 開発だけでなく、コードレビューやQAにも AIコーディングツールをフル活用
19. 03.技術設計 AIエージェント実行を司るオーケストレーター Orchestrator AIエージェントを安定して安全に動かすことを目指す 役割 制御フロー管理 状態管理 ローカル思考状態（ス テップ・タスク単位） と、 エージェント全体のグ ローバル記憶を分離す ることで、副作用や競 合を防止し、安定的な エージェント実行を実 現します。 エージェントを短期・単 発実行ではなく、 長時間・ 状態持続型を前提に、
 エージェントの思考・行 動・状態遷移を統合的に 制御します。 グローバルProgram Counterにより、 すべて の処理ステップを平等 に評価・実行します。
 条件分岐・ループ・早期 終了を明示的に表現可 能です。 オーケストレーター 順序・遷移・責務分離を管理 エージェント（LLM） 判断・生成・推論に専念
20. 03.技術設計 エンタープライズグレードの堅牢性と整合性 エージェントの状態を第一級として扱い、副作用の隔離・再実行を安定化 すべての状態遷移は永続化される クラッシュ後も同一ポイントから決定的に再開 部分更新・メモリ依存状態を排除 堅牢性 Durability 前提 業務フローは長時間・非同期・ 再実行前提 障害・再起動・並列実行は、 例外ではなく通常系 状態変更は原子的・順序保証 並列実行は楽観ロック／バージョン管理で収束 冪等性：再試行しても結果が変わらない 整合性 Consistency
21. 03.技術設計 AIエージェントを拡張する各種インベントリ ツールインベントリ Inventory UIインベントリ AIエージェントは、 多様なツール （データ分析やグラフ生成、 マ スキング等） を活用します。 ツールを登録して利用する仕組みが ツールインベントリです。 インベントリに登録するツールはGitHubリポジトリで管理し、 CI/CDを通じてツールインベントリにデプロイ。 従来のソフト ウェア開発プロセスに沿った開発を行います。 Chat UIだけでなく、 AIエージェントの業務要件や用途に合 わせて差し替え可能なUIインベントリを提供します。
22. 03.技術設計 業務とエージェントをつなぐデータシステム ビジネスドキュメントに沿ったハイブリッド検索サービス+各データ基盤（SPO等） と自動連携 スライド検索はPowerPointのスライド内容を、 LLM／VLMを使ってマルチモーダルなドキュメントとして解析し、 検索インデックスに登録。
 ユーザーからのリクエストをAIエージェントで理解・最適化し、 ユーザーの意図に沿った検索を実現します。 LLM VLM Search Index マルチモーダルな ドキュメントを解析 検索インデックスに登録 AIエージェントで 理解・最適化
23. 03.技術設計 AIエージェントのインフラ 共通基盤としてのAi Workforceだけでなく、個社ごとの独自デプロイメントをサポート。 マルチテナントとシングルテナントで、共通基盤と個社基盤の両方に提供。 独自デプロイメント Management Compute &Data Foundation エンタープライズ領域に強 いMicrosoft Azureを採用。 Azure OpenAIをフル活用。 Container Appsのような汎用的なコンテナオー ケストレーターとPostgreSQLを活用。 クラウド ベンダーロックインを避けるように技術選定。 インフラ管理やOperationにはTerraform （IaC） やOpenTelemetry + Datadog （Observability） を採用。 Observabilityは開発環境か ら導入し本番環境リリース前に監視アラートを含めてテスト。
24. 03.技術設計 Development 開発体制とツール AI駆動の開発体制と品質保証 Coding AIコーディングツールをいち早く導入、 実験し、 生産性向上。 使 い勝手や作り方の思想を学びAi Workforceに取り入れていく。 コードレビューでは評価しきれないUIテストやE2Eテストを、 Claude CodeのSkillとしてQAガイド生成Skillを定 義。 PRを作るときに同時に変更内容からQAガイドを生成し、 PRレビューの一貫としてQAを実施する開発プロセス。 GreptileやGithub Copilot、 Devin Review等の各種コードレ ビューツールを導入して、 コードレビューのヌケモレを防止。 ADR駆動開発により、 事前に設計をレ ビュー。 AIコーディングで自動開発。 Review Pull Request Test
25. 03.技術設計 AIエージェントを飛躍させるR&D 自己進化するワークフロー 最新の技術をキャッチアップし、プロダクトとお客様の課題を深く解決するためのApplied R&Dチームです。 プロンプト自動生成 LLMを活用するためのプロンプトを入力ドキュメントや目的に応じて自動的に生成 ワークフロー自動生成 業務を自動化するためのワークフローを自動的に生成 マルチモーダルドキュメント認識・生成 ビジネスドキュメントに特化した情報認識 Agentic Workflow Generator LLM Workflow Executor LLM & Code Predictions Evaluator ワークフロー自動生成の流れ Meta Prompt Context Feedback 自動生成
26. 04.ユースケース 04 Use Cases ユースケース
27. 04.ユースケース 固有ルール × 固有業務をAI再設計、 何が難しい？ 業務の全体像 技術的な課題 Input 営業資料／見積書／業務マニュアル ／契約書／法規・行政文書 Word / Excel / PowerPoint / PDF / 画像 手動アップロード、 SPO・Box、 メール添付、 基幹システム Process 情報抽出・構造化 ナレッジ付与（タグ・メタデータ） リスク分析・不正検知 人の判断を前提にした分岐・確認 フォーマット・データソースが多様 社内マスタとの突合が必要 数千ページ、 数千回のLLM呼び出し Basics ナレッジ検索 アクセスコントロール 判断ログ・監査証跡 Output 個社独自フォーマット 他部署・他社連携ドキュメント 運用管理資料・業務マニュアル 個社独自ルールによるエッジケース
 WF / Agent を都度組むと工数が膨大 多くの企業業務は、 業務ごとに前提・判断基準・書式が異なり、 非定型・例外が多く、 人の判断を前提に設計されています。 こうした業務は、 SaaSでは対応 が限定的で、 個別開発では高コスト・長期化しがちです。 Ai Workforceでは、 まずこの 「難しさ」 を分解するところから始めます。
28. 04.ユースケース これらの課題を どう分解するか？ APP ロジック・ インベントリ エージェント ビルダー エージェント エンジン 推論 Deep Research ワークフロー ビルダー ナレッジ ポータル 出力レビュー・ フィードバック アクセスコントロール AIワークフロー エンジン ツール インベントリ UI インベントリ OCR マスキング 入力フォーム チャット チャンキング データ加工 ファイル ビューア Python実行 グラフ生成 テンプレート 出力 スライド一覧 精度評価 自動生成・ チューニング プロンプト ワークフロー プロセス マイニング Ai Workforceは、業務を一度きりのAI処理として 扱うのではなく、 再利用可能な構成要素の組み合わ せとして設計しています。 ナレッジグラフ 検索エンジン 検索 データ・ 外部連携 データベース テーブル ファイル API連携 SPO BOX Copilot カスタマイズ連携 テーブル連携
29. 04.ユースケース リース見積書の明細抽出・分類・コード付与 課題 Use Case 01 での処理 明細が多く、整理・分類に時間がかかる 紙をスキャンしたPDFのためコピーできない マスタとの突合・コード付与が煩雑 数百件を超える明細を全て手動転記 非定型見積書から明細を抽出・構造化 資産マスタと突合し、 項目・コードを補完 自動分類 Excelテンプレートに沿って柔軟に出力 既存の資産管理台帳へそのまま連携 マスタデータと 自動紐付け 業務内容に合わせてカスタマイズした テンプレートに自動転記 技術的ポイント LLMが計算しながら抽出・自己補正 出力フォーマットを固定しない設計 例外を前提とした抽出ロジック
30. 04.ユースケース 融資契約書から管理表を自動作成する 課題 Use Case 02 での処理 数十〜数百ページに及ぶ長文 稟議書・覚書など関連文書が後から追加 契約期間中の管理義務を正確に把握する必 要がある 契約書から顧客名・利率・条件を抽出 semantic chunking による条項単位の分割 稟議書・覚書と紐づけ、 後から検索可能に 管理義務を独自フォーマットの管理表へ転記 コベナンツ抽出条件は 柔軟に設定可能 コベナンツの期限を 企業独自のフォーマットで出力 技術的ポイント 契約書条番号の階層構造を抽出 意味構造を踏まえた長文分割処理 Excelテンプレート前提の出力
31. 04.ユースケース 課題 営業資料のナレッジ化・再利用 Use Case 03 での処理 テキストだけでなく図表に意味がある 部署・案件ごとに形式が異なる 探すことが大変 テキストと図表の両方が検索対象 社内テンプレートに沿ったスライド生成 SPO等のコネクタ経由で社内データを活用 pptx形式で出力し、 追加で修正可能 複雑な図表やグラフ操作に対応。 データ収集・分析も同じ画面で手軽に。 社内資料から 「テキスト」 「ビジュアル」 で 検索可能 e e Text PDF PDF 図表・グラフの意味をメタデータ化 スライド毎の 図表や意味を 理解して検索 技術的ポイント 複雑なテンプレート・1枚完結スライドに対応／AIが作り切らない前提の設計
32. 05.技術選定と意思決定のプロセス 05 Decision Making 技術選定と意思決定のプロセス
33. 05.技術選定と意思決定のプロセス プロセスとツール 大きめの開発に入る前の「標準化」 本格的な実装フェーズに入る前に、 以下のドキュメントを作成し、 設計と意思決定の品質を標準化したうえでレビューを行います。
 各ドキュメントには、 Notionテンプレートを用意しています。 Architecture Decision Record（ADR） Design Doc 比較的大きな機能開発や、 後戻りできない設計判断に利用。 複数の選択肢が存在する技術選定や設計判断に利用。
34. 05.技術選定と意思決定のプロセス Architecture Decision Record ADR 定義と目的 主な構成要素 1 2 3 技術的な意思決定を記録するドキュメント。 複数の選択肢 やトレードオフを比較し、 「なぜその選択をしたのか」を明 確にします。 背景・解決したい課題 1 2決定事項に説得力を持たせる 決定事項 3選択肢を俯瞰し、 正しい意思決定を行う 歴史的な背景をコンテキストとして残す 4選択肢とPros／Cons 懸念事項・影響範囲
35. 05.技術選定と意思決定のプロセス 具体例：ADR 背景・解決したい課題 決定事項 比較 懸念事項・次の手順 オブザーバビリティツール選定
36. 05.技術選定と意思決定のプロセス 定義と目的 Design Doc Design Doc 主な構成要素 1 2 3 ADR が Why （なぜ選んだか） を記録するのに対し、 Design Doc は What （何を作るか） と How （どう実装 するか） を記載します。 プロダクトやインフラのアーキテクチャを、 図や文章 （シー ケンス図、 ER 図、 クラス図、 構成図など） で具体化。 API 仕 様、 エラーハンドリング、 パフォーマンス、 セキュリティ要件 も含めて記述します。 実装前に設計をレビューすることで、 潜在的な問題や改善 点を早期に発見でき、 実装後も 「設計の意図」 を振り返る ための重要なドキュメントとして機能します。 背景 Goals／Non Goals アーキテクチャ シーケンス図・テーブル設計
37. 05.技術選定と意思決定のプロセス 具体例：Design Doc Goals／Non Goals 処理の流れ 同期方式・データベース構造 外部ストレージ連携・設計
38. 05.技術選定と意思決定のプロセス 事業部イシューリスト 採用候補者向けに社外公開している 「課題一覧」 LayerXのAi Workforce 事業部が、採用候補者向けに社外公開している プロダクトイシューリストです （※随時更新）。 実際に取り組んでいる課題をご覧いただき、一緒に解決できる方とお会い したいと考えています。 カジュアル面談や面接で、ぜひ議論しましょう。 https://layerx.notion.site/LayerX-Ai- Workforce-2025-2026-2a2cdd370bae80fbba7dc812113e1cea
39. 06.エンジニア組織 06 Engineering Team エンジニア組織
40. 06.エンジニア組織 組織の全体構造・思想 専門性を束ね、プロダクトという一つのエンジンを動かす Ai Workforceのプロダクト開発は、 個々の専門チームが連携し、 ひとつの目的に向かって動くエコシステムです。 企画・デザイン・開発が中核となり、 FDE、 R&D、 TPMがそれを支えることで、 顧客価値の創出と、 持続的なプロダクト進化を両立しています。 プロダクトの中核を担うエンジン 企画グループ ： 顧客課題・市場視点から価値仮説を設計 デザイングループ ： 体験とUIを通じて価値を具現化 開発グループ ： スケーラブルで信頼性の高い実装を担う 顧客価値を届ける最前線 FDEグループ ： 顧客の現場に深く入り込み、 構造的に課題を解決 未来への投資と信頼の基盤 R&Dグループ ： Applied R&Dによりプロダクトの能力を拡張 テクニカルプロジェクトマネジメントグループ ： 品質・セキュリティ・信頼性を担保 FDEグループ 企画グループ デザイングループ 開発グループ R&Dグループ テクニカルプロジェクト マネジメントグループ
41. 06.エンジニア組織 実務と専門性 顧客価値と信頼を両立する、専門性ベースの働き方 Ai Workforceでは、 「顧客課題を前に進める力」 と 「プロダクトの信頼性を守る力」 を異なる専門性が分担・協調することで実現しています。 顧客と未来に向き合う実装と探究 FDEグループ 顧客の現場に深く入り込み、将来の課題も見据えて解決 Platform機能を最大限活用し、 カスタムソリューションを構築 「2歩先、3歩先の課題を構造的にとらえる」 プロダクトの信頼性と安全性を支える守護者 品質・セキュリティ・顧客要件への準拠をプロダクト全体で担保 3つの専門性で構成 テクニカルプロジェクト マネージャー QA セキュリティ セキュリティ要件の実現 セキュリテの維持・向上 AI/LLM時代の品質管理 SOC2 / ISMS などの認証取得・維持に加え、 日常的な改善を推進 AIエージェントの不確実性を前提とした品質設計に取り組む R&Dグループ 「Applied R&D」 を重視し、 研究成果をプロダクトへ還元 市場・顧客ニーズに直結した研究開発を推進 AIエージェント時代に向けた次世代データ基盤・内部ツールを開発
42. 07.エンジニアの働き方 07 Work Style エンジニアの働き方
43. 07.エンジニアの働き方 Example FDE Masanori Onda オンオフの切り替えは、 場所を変えることから 『家より集中できる』 オフィスと、 非同期文化の心地よいバランス。 働き方の推しポイント（Q&A形式） Q. あえて「出社」を選ぶ理由は？ Q. 出社派から見た「チームの連携」は？ A. 一番の理由は 『自宅よりも集中できるから』 です。 また、 言語化しきれない 『ふわっとした課題』 をメン バーからさらっと相談されたり、対面ならではのメ リットがありますね。 A. 実は弊社、 オンラインの人が働きやすい環境がかな り整っています。 出社していても基本はSlackで完結。 対 面の良さを享受しつつ、 リモートメンバーともしっかり 連携できる文化があります。 広々としたデスクと、ワイドモニターが快適。 Office Space 自販機やコーヒーマシンが充実。 休憩時間の技術雑談がリフレッシュに。 Refresh 通勤を運動不足解消の貴重な時間に捉える。　 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 | 退社 通勤時間を「適度な運動」として活用
44. 07.エンジニアの働き方 Example FDE 恩田 壮恭 Ikumi Ito 目指すは、 お客様の 「社外CTO」 LLM活用のラストワンマイルを埋め、 確かな価値を届ける。 働き方の推しポイント（Q&A形式） Q. なぜ、お客様先に常駐しているの？ Q. 「ただの御用聞き」にならないための秘訣は？ A.お客様と密なコミュニケーションを取るためです。 オフィスで、 ちょっとした相談やアイデアにもその場で 応えられます。 アイデアを素早く形にできることがAiW の強みであり、 常駐でその価値を最大化しています。 A. 本音を引き出せる・伝えられる関係性をお客様と築 くことです。 AiWの導入はあくまで手段のひとつ。 真の課 題は何かをお客様以上に考え抜き、 価値を届けるまで やり抜く姿勢を大切にしています。 週1日はお客様先に常駐。 その他は 自社・リモートを自由に選択 Flexible Engagement 常駐先の文化に合わせた柔軟なスタイル。 Style Adaptability 全プロセスに一貫して関われる環境が エンジニアとしての手応えに直結。 Full-stack Involvement 開発スタイル・環境 Daily Schedule 9:00 | お客様オフィスに出社 お客様と一日の予定を確認 対面ならではの雑談も 11:00 | QA & Support DX推進チームと打ち合わせ Ai Workforceの活用方法を伝授 12:00 | Lunch Communication お客様とランチを共にし、会議室では 出てこない現場の本音や課題をキャッチ 15:00 | Discovery & Design 新規案件のMTG。お客様の要望を踏まえ、 解くべき課題を特定する 17:00 | Rapid Prototyping 当日中にデモやモックを作成し、 その場で フィードバックをもらう 19:00 | Feedback & Next 1日のインサイトを整理
45. 07.エンジニアの働き方 Example SWE Osuke Sudo 家族との時間も、 エンジニアとしての研鑽も アウトプットを最大化するための自律した選択。 働き方の推しポイント（Q&A形式） Q. ライフステージの変化による影響は？ Q. チームとの連携で意識していることは？ A. 独身時代と変わらず、 むしろ以前より高い質でアウ トカムを出せています。 仕事とプライベートを時間で 完全に切り分けることで、 業務時間内の 『集中密度』 が 劇的に上がりました。 A. 事前のスケジューリングとSlackでの非同期連携を 徹底しています。 これが自分だけでなく、 組織の 『アタリ マエ』 として浸透しているのが LayerX の強みです。 Environment Policy 会社標準装備の外部モニター等、シンプルかつ 機能的なセットアップ。 出社は「必要に応じて」。基本はリモート、出社が 必要な時は週3〜4など、目的ベースで場所を選択。 開発スタイル・環境 Daily Schedule 9:00 | 始動 保育園の送りを終え、業務開始 10:00 | Deep Work & Design 設計・実装・レビューに没頭。午前中に優先タ スクを完遂 15:00 | Scrum & Sync スクラムイベント等、チームとの同期コミュ ニケーション 18:00 | Family Time お迎え〜夕食。 一度仕事から完全に離れ、 家族と の時間を最優先 21:00 | Focus Hour 差し込みのない時間帯で、一番の「集中」と 「内 省」 を行う
46. 07.エンジニアの働き方 Example TMP 恩田 壮恭 Yuzuru Ohira QOLとアウトカムを最大化する オンラインとオフラインを 「目的」 で使い分けるプロの流儀。 働き方の推しポイント（Q&A形式） Q. リモートワークで一番変わったことは？ Q. 「出社」をどう捉えていますか？ A. 週末の充実度とプライベートの幸福度が高まりま した。 東京を離れても、 仕事の質やチーム連携に差は 感じません。 リモートでも成果を出せる仕組みが整っ ており、 安定したアウトカムを出せています。 A. 登壇や採用、 顧客MTGに合わせて2泊3日程度で出 社します。 出社時は、 メンバーとの対話やオフラインだ からこそ深められるコミュニケーションを中心に、 関係 構築の時間を大切にしています。 基本はフルリモート。出社は目的がある時のみに 絞り移動。 Remote Policy Communication オンライン／オフラインの差異を感じさせない連携。 住環境の整備がパフォーマンスを支える基盤。 QOL Focus 開発スタイル・環境 Daily Schedule 8:30 | 稼働 定時より少し早めにスタート。静かな時間帯に その日のタスクを一気に進める 9:30 | Daily Sync チームでの進捗共有。 それ以外は 基本「最初から全力」 でタスクを消化 12:00 | Lunch & Cook 妻が昼食を作ってくれて、一緒に食べる。 夫婦でリモートワークなので、共に過ごす時間 が増えた。 リモートならではの 「家庭の充実」。 食後は愛犬と至福のひととき 13:00 | Flexible Focus 午後の業務。 根を詰めすぎず、 あえて余裕を持つことでアウトカムの質を維持 18:00 | Off & Weekend 週末の充実を見据え、 メリハリを持って 業務終了。 東京在住時より高いQOLを実現
47. 08.採用ポジション 08 Join The Team 採用ポジション
48. 08.採用ポジション FDE（Forward Deployed Engineer） 顧客業務に深く入り込み、 プロダクトを本番で届けきる 役割 Ai Workforce事業部では、 日本を代表する大手企業に対して生成 AIプラットフォーム「Ai Workforce」の導入を推進し、企業の生産 性向上に貢献しています。 エンタープライズ企業のドキュメントワー クをターゲットとし、PDFやWord／Excel／PowerPointといっ た、長年の事業活動で蓄積されたMicrosoft Officeドキュメント のナレッジを、生成AIを活用した最適な業務プロセスへ、安全かつ 滑らかにつなぐプラットフォームです。 FDEグループは、 企画グループ・開発グループ・事業開発＆コンサル ティンググループと密接に連携しながら、お客さまの業務に深く入 り込みます。Ai Workforceの本番稼働・デリバリーに技術的な責 任を持ち、 重要なビジネス課題の解決を担います。 期待される働き方 FDEは、業界・会社・部署ごとに異なるエンタープライズ業務に対 し、 お客さまと直接連携しながら深く入り込み、 業務ドメインを迅速 にキャッチアップします。 そのうえで、業務課題を構造的に整理し、 Ai Workforceを用いたソリューションの設計・実装を行います。 主 に事業開発＆コンサルティンググループと小規模なチームで活動 し、 プロジェクトの技術責任者として、本質的なビジネス課題に向 き合うチームです。 具体的には、 以下の業務を一貫して担います。 顧客ヒアリング・業務理解 ドキュメントの構造化 AIワークフロー／エージェントの構築 LLMアルゴリズムのチューニングおよび精度評価 導入判断のサポート、顧客環境での本番導入支援 グレード MG3〜
49. 08.採用ポジション リサーチエンジニア 新技術を実用に落とし込み、 プロダクトを進化させる 役割 現在、 ワークフローやAIエージェントを、 より高い品質と効率性で開 発・実行・評価することが求められています。 Ai Workforce事業部 のR&Dリサーチエンジニアは、AIやLLM、AIエージェントなどの新 技術を、 プロダクトやビジネスの現場で実践的に有効活用するた めに技術にDeep Diveし課題を解くことを目的としたロールです。 各種ワークフローやデータの自動生成、AI Agentの精度改善と評 価基盤の構築、 複雑なマルチモーダルドキュメント処理、 オンデマン ドなAIエージェント体験など、事業部が直面する課題を、研究と実 装の両面から実用的に解決することを目指します。 期待される働き方 R&Dリサーチエンジニアは、AIやLLM、AIエージェントをプロダク トに組み込み、実用化するための応用技術を研究・検証し、 ツール として形にします。 単なる技術検証に留まらず、最新技術をプロダ クトへ接続し、 ビジネス価値を生み出すR&Dであることを重視。 また、R&Dの成果を通じてLayerX全体の技術的ケイパビリティを 底上げし、 プロダクト開発における技術選択の幅を広げる役割も 担います。 グレード MG4〜
50. 08.採用ポジション AI検索エンジニア ビジネスドキュメントを 「使える知識」に変える 役割 AIエージェントが能力を発揮するには、適切なコンテキストの 提供が不可欠です。そのため、契約書・提案書・決算書などの ビジネスドキュメントを整理し、正確に検索・活用したいニー ズが急速に高まっています。 データを加工し、検索しやすい状態に整備しておくことが重要 です。 AI検索エンジニアはこの課題を解決し、Ai Workforceのプ ラットフォーム基盤を強化する役割です。多様なドキュメント と検索ニーズに対応し、人とAIエージェントの双方が使いやす い情報基盤を構築します。 期待される働き方 AI検索エンジニアは、 フォーマットや目的の異なる大規模なビジネ スドキュメントを対象に、全文検索およびセマンティック検索機能 の設計・実装・運用を担います。 検索機能のAi Workforceへの組み込み・改善
 ドキュメント特性やユーザー要件に応じた検索インデックス設計
 検索アルゴリズムおよび検索基盤インフラの設計・最適化
 パフォーマンスチューニング、監視・運用
 Azure AI Searchなどクラウド検索サービスの導入・運用
 社内外ステークホルダーとの要件定義・技術ディスカッション グレード MG4〜
51. 08.採用ポジション シニアデータエンジニア マルチモーダルデータを活かす基盤をつくる 役割 プロダクトの成長に伴い、マルチモーダルデータのETL・ DWH、LLMやAIエージェントの精度評価、フィードバックデー タの活用など、生成AIを支えるML基盤の重要性が高まっていま す。 シニアデータエンジニアは、こうしたデータシステムを構築・ 発展させることで、データに根ざしたプロダクトとサービスの 進化を、より速いスピードで支える役割になります。 期待される働き方 シニアデータエンジニアは、 ドキュメントデータやAIエージェントの コンテキストデータを有効活用するためのデータ管理基盤の開 発・運用を担います。 マルチモーダルドキュメントデータから情報を抽出する手法の選定と推論 推論結果の管理および活用基盤の構築 検索エンジニア、ソフトウェアエンジニア、SREと連携したETL およびデータシステムの開発 グレード MG4〜
52. 08.採用ポジション SWE（Software Engineer） AI Agent時代のプロダクト基盤をつくる 役割 ソフトウェアエンジニアは、AI Agentが企業のさまざまな業務 プロセスを横断的に支援する、Ai Workforceプラットフォー ムの開発・運用を担います。めまぐるしく進化するAI技術と、 それによって初めて実現できる新しいアイデアをプロダクトと して形にし、お客さまの課題解決を支える基盤を構築します。 期待される働き方 AI Agentを前提としたプロダクト開発を自律的に推進。 具体的に は、 以下のような働き方を期待しています。 日常的にAI Agentを活用し、それらを手足のように使いこなしながら、 フルスタックなプロダクト開発を行う FDE、PdM、デザイナー、QAなど隣接チームと密に連携し、 プロジェクトを推進する 開発プロセスおよび品質担保の仕組みを、 チームとして継続的に改善・運用する グレード MG3〜
53. 08.採用ポジション SRE（Site Reliability Engineering） AI Agent時代のプロダクト基盤をつくる 役割 SREは、Ai Workforceの安定稼働を支えるインフラの設計・ 構築・拡張・運用を担います。AI Agent時代を見据えた監視基 盤の設計や、DevOpsにおけるトイルを削減するための自動 化・効率化施策を推進。 SWEやTPMと協業しながら、開発から運用までを一体的に支え るアーキテクチャを設計します。また、顧客ごとに異なる要件 を持つクラウド環境の構築や、安全なデプロイを実現するため の施策にも取り組むのが役割です。 期待される働き方 TPM、CS、SWEといった隣接チームと密に連携し、Ai Workforce の安定稼働に貢献。 役割にとどまらず、 プロダクト開発全体の品質 向上やプロセス改善にも関与することで、顧客が求める価値を、 タ イムリーかつ高品質で、 安全に提供できる状態を維持します。 AI Agentが当たり前になった世界におけるSite Reliability、 Observability、 そしてAI Agent Reliabilityについて探求し、最 先端の知見を実践に落とし込んでいくことを期待しています。 グレード MG4〜
54. 08.採用ポジション 報酬テーブル 高い生産性に報いる制度 AI時代を見据え、市場競争力のある報酬を提供していきます。 AI等による 生産性向上に資する報酬制度を、継続的にアップデート。 給与は、事業特 性・職種別に複数のレンジ （各7段階） で設計しており、 グレードは、 キャリア の道筋を可視化するガイドとして位置づけています。 賞与 （標準評価の場合） 年収（万円） 3,000 下限〜上限 個別 設定 2,500 2,405 2,000 1,820 1,998 1,500 1,000 500 0 780 480 MG1 1,040 642 MG2 1,365 1,122 840 MG3 MG4 グレード 1,482 MG5 MG6 MG7
55. AIエージェントの進化を、 プロダクトの中核で担う。
 その仲間を、 探しています。 採用サイト Company Deck （企業紹介） 採用ポジション一覧 Ai Workforce公式サイト