AI DevEx Conference 2026 AI時代における エンジニアの新たな役割 ── FDEとクオリアの探究 2026年07月23日 ｜ 戸井田（Hacobu CTO） Confidential 

自己紹介 戸井田 裕貴 略歴 株式会社Hacobu 執行役員CTO。ソーシャルゲーム新規 立ち上げ・運用。ライブコマース立ち上げなど、一貫してWeb ／BtoC・BtoB領域でプロダクト開発に従事。2019年 Hacobu入社、現在はCTOとして技術統括。 趣味 ゴルフ・映画・麻雀・サッカー。 特にゴルフは奥が深く、練習してもなかなか上達しない のに、それが楽しくてやめられない…完全に沼っています。 Copyright Hacobu, Inc. 2 

会社紹介 「運ぶを最適化する」ための4つの事業 物流プラットフォーム事業 Copyright Hacobu, Inc. 物流DXコンサルティング システムインテグレー ション・AI導入支援 物流特化 転職エージェント 3 

物流倉庫 Copyright Hacobu, Inc. 4 

物流倉庫 Copyright Hacobu, Inc. 5 

MOVO導入企業 小売 メーカー 食品・飲料 日雑・製紙 建設・建材 自動車・重工業 卸 電機 化学・医薬品 アパレル 物流・倉庫 Copyright Hacobu, Inc. 6 

物流インフラとしての実績 安心の運用体制とセキュリティ 広がるMOVOのネットワーク 利用事業所数 利用継続率 4万5000 カ所 ※利用 事業所 数とは 、MOVO 導入 拠点に 加えて 、MOVO を利 用する 事業所 のIDを合 計した 数字 % ※2025年5月時点。MOVO Berthのソフトウェアサブスクリプション部分の月次収益ベースで算出 ドライバー 利用ID数 システム稼働率 80万 99.99 件 ※ 累計 登録ド ライバ ー数。 利用者 が「MOVO B erth」を 利用す る際に 登録す るドラ イバー 電話番 号の累 計ID数 Copyright Hacobu, Inc. 99.8 % 物流の現場を止めない、24時間365日の安定稼働 7 

01 二つのズレ 作るのが速くなった今、価値はどこにあるのか 

出典：Tree swing cartoon（作者・初出不詳／1970年代〜） 参考：BusinessBalls・projectcartoon.com 

01 ｜ 二つのズレ ひとつは、伝言ゲームで生まれる「要望と実装」のズレ。 もうひとつは、「要望と本当に必要だった物」のズレ。 Copyright Hacobu, Inc. 10 

01 ｜ AIだけでは解決出来ない 「ズレたら作り直せばいい」は、通用しづらい。 作り直すたびに現場検証が発生し、業務を変えるコストが積み上がる。 作るコスト 業務を変えるコスト — AIで劇的に下がる — — 作り直すたびに繰り返し発生 — • 仕様を書く • 手順を変える • プロトタイプをつくる • 現場へ説明する • 画面をつくる • 社内調整する • コードを書く • 協力会社・ドライバーへ周知する • テストする • 安全や例外に配慮する • リリースする • 心理的負担が生じる Copyright Hacobu, Inc. 11 

01 ｜ 要望と実装のズレを減らす 伝言ゲームで、要望は欠け、変形していく。 作り手である開発者が顧客に近づくほど、ズレは生まれにくい。 顧客の言葉 PMの理解 仕様 開発者 現場適用 背景・意図・制約が 含まれる 優先順位として整理 される 作れる形に変わる 高速に作る 業務変更として顧客 に返る 再話研究では事実の欠落・変形が、要求工学ではコミュニケーション経路や組織構造による要件理解の障壁が指摘されている。 Breithaupt et al., 2018 / Al-Rawas & Easterbrook, 1996 Copyright Hacobu, Inc. 12 

01 ｜ 要望と本当に必要だった物のズレを減らす どうやったら「ブランコ」ではなく、「タイヤ」に辿り着けるのか。 現場で感づくことで、本当に解くべき課題が見えてくる。 顧客の言葉 問いを立てる（感づく） 見えてくるもの（感づく） 「木にブランコがほしい」 「なぜ、ブランコなのか？」 「吊るしたタイヤで十分」 • 顧客が言語化したもの • 目に見える要望 • 解決策のひとつ • 何を実現したかったのか • 何を避けたかったのか • 誰にとって価値があるのか Copyright Hacobu, Inc. そのまま 作らない 顧客との 対話 • 要望が生まれた背景 • 現場の負担や制約 • 本当に解くべき課題 13 

02 感づく力 2目のズレを起こさないために。 

No content

02 ｜ AIは言葉にできる AIは絵画を言葉で説明できる。 でも、人が受け取るものは言葉だけではない。 AIが返す言葉 「弟子は3人ずつ、4組に分かれています」 「ユダは、右手で銀貨の袋を握っています」 「キリストだけが、静かに中央にいます」 Copyright Hacobu, Inc. 16 

02 ｜ クオリア 感動も、違和感も、言葉になる前に感じている。 「体験の質感」が、クオリア。 AIは、観測できる情報から言葉を生成する。 でも、その言葉に“体験の質感”は乗っていない 質感は、体験した人にしか現れない “what it is like” ＝ 体験がどんな質感で現れているか 出典：Thomas Nagel / Stanford Encyclopedia of Philosophy “Qualia” Copyright Hacobu, Inc. 17 

02 ｜ 物流現場のクオリア 物流現場にも、言葉になる前の「体験の質感」がある。 “不安”や“緊張感”が、ユーザーの行動となって表現される。 音 温度 身体の動き 装備 エンジン音 / フォークリフト 音 / ガントリークレーン音 / 電炉稼働音 冷凍冷蔵倉庫 / 屋外の 暑さ / 雨風 立ち止まれない / 片手がふ さがる / 歩きながら確認す る 手袋 / マスク / ヘルメット / 耳栓 / 防寒着 → 声が届かない不安 → 呼び出しを見落とす 緊張感 Copyright Hacobu, Inc. → 手がかじかむ → 端末を扱う煩わしさ → 操作する余裕がない → 確認を後回しにする 不安 → タップしづらいストレス → 視界が狭い中で業 務する緊張感 18 

02 ｜ 物流ドメイン知識 物流現場のクオリアを捉え、 物流ドメイン知識で、解くべき“問い”に変える。 現場で感じること 感じたままだと 物流ドメイン知識があると ドライバーが長く待っている トラックでの移動をコント ロール出来ない問題 予約運用がされてない？有責待機 例：鉄鋼メーカーで到着順運用を廃止し、15分単位の予約制へ。荷待ちは29分（ 73.6%減）に 予約枠が守られない トラックでの移動をコント ロール出来ない問題 入荷バース？出荷バース？ステージングの処理能力は？出荷確定はいつ？当日？ 例：フォークリフトをキャパシティに見立てて枠を再設計。当日枠・緊急枠で急な出荷にも対 応 現場の習慣の問題 リファックスによる押印が必要？手書きの方が早い？システムが対応できていない？ 例：配車1件にFAX・電話のやり取りが6回。受注→手書きメモ→Excel転記→FAXが常態 化していた 現場の要領の問題 受付の情報が庫内に伝わっている？到着時間と荷役開始は同時刻？ 例：「着車＝入場」と「荷役開始」を分けて記録する設計へ。受付→入場→作業開始→退 場を状態で管理 紙・FAX・メモが残る 到着しても荷役が始まらない Copyright Hacobu, Inc. 19 

02 ｜ 顧客との対話 “問い”を起点に、顧客と対話する。 背景が語られ、本質的な課題が見えてくる。 ① クオリアを捉える ② 問いを立てる 顧客「そういえば、何でこ のやり方してるんだっけ？」 ③ 顧客と対話する • 顧客に問いを投げかける 音・温度・装備・身体の動き 現場の人はどう感じているか 物流ドメイン知識 言語化されていない負担・迷い 感じたことを “問い”に変える • 要望の“背景”が語られる • 解くべき課題が“解ける問 題”になる 言葉にしきれない違和感 Copyright Hacobu, Inc. 20 

02 ｜ 顧客事例：後藤回漕店様（港湾物流・配車） 物流ドメイン知識が“問い”を生み、顧客との対話で実運用につなげた。 現場を見ただけでは、解決は難しい: 他ベンダー • 丸一日、現場見学を行い、業務を説明 • 1年弱かけて開発するも、実運用に至らず 問いを起点に、対話し、課題を解決: Hacobu 「何が、配車判断の優先順位を変えるのか？」 船の遅延、シャーシ交換の有無やタイミング、急なキャンセル。 物流ドメイン知識をもとに、判断の背景にせまり、課題を特定。 成果 Copyright Hacobu, Inc. Hacobu公開導入事例：後藤回漕店 / MOVO Vista（2026年3月取材） MOVO Vista × 基幹システム連携 ⇒ 発注工数 約40%削減 21 

03 フルサイクルエンジニア 感づいた課題を、チームで解決する 

03 ｜ フルサイクルエンジニアとは 顧客課題の最前線に立つ思想は、FDEと同じ。 Hacobuでは、チームとして最前線に立つ。 “FDSEs work side by side with our customers, rapidly understanding their toughest issues” — Palantir, FDSE Job Description FDE フルサイクルエンジニア Forward Deployed Engineer 思想は同じ。課題発見から、設計・実 世界のAI企業で広がる役割、少数精鋭 装・提供まで、顧客課題を技術で解く で顧客の最前線に立ち、技術で解く。 サイクル全体に関わる。非常駐。自社チ ※ 定義は会社ごとに幅が広い（常駐型もある） ームに所属し、自社PF上で開発する。 Copyright Hacobu, Inc. 23 

03 ｜ フルサイクルを支える、チーム設計 役割は明確に。境界は、あえて重ねる。顧客課題はチームで持つ。 Copyright Hacobu, Inc. 24 

03 ｜ よくある質問 顧客には深く入る。だが、SESでも、プリセールスでも、何でも屋でもない。 顧客先に常駐するの？ プリセールス・コンサルでは？ 折衝も1人で担うの？ いいえ。社内の開発チームに所 属し、必要なときに現場を訪ね る体制。 いいえ。設計と実装が主業務。 自社プラットフォーム上で、開発 し、実運用されるコードを書く。 いいえ。Solution Architect や Solution Salesが、折衝・ PMを担っているので、基本行わ ない。 言われたものを作るの？ 顧客ごとにフルスクラッチ？ 物流未経験でも平気？ いいえ。顧客の要望は、解決策 のひとつ。本質的な課題を解決 するのが役割。 いいえ。自社プラットフォーム上 で、開発する。個社機能と再利 用出来る資産が共存している。 平気。開発者のほとんどが物流 未経験。社内に物流ドメインエ キスパート在籍。現場訪問でド メイン知識獲得可。 Copyright Hacobu, Inc. 25 

03 ｜ 課題と実装を往復する 「言われた通りに作ったのに、使われない」をなくす。 2つのズレを起こさず、チームで課題と実装を往復する。 従来：情報が渡るたびにズレが発生する 顧客の要望・課題 → 要件定義 → 仕様 → 実装 フルサイクルエンジニア：現場の課題と実装・検証を往復し、ズレを抑止する 顧客の要望・課題 Copyright Hacobu, Inc. ⇄ 実装と検証 フルサイクルエンジニア 26 

03 ｜ フルサイクルエンジニアの武器としてのプラットフォーム 案件で得た知識を、次の物流課題に使える共通資産へ変える。 再利用するたびに、解決が速くなる。 プラットフォームなし： 現場の課題 ゼロから開発 個別解が乱立 プラットフォームあり： 学びを基盤へ還元 現場の課題 複利が働く 基盤の上に構築 Copyright Hacobu, Inc. 保守で疲弊 資産を再利用 27 

04 プラットフォーム 現場で得た物流業務の知識を、確実に動くプロダクトへ変換する 

04 ｜ 物流業務を、実行可能な共通言語へ 物流業務の 「対象・関係・操作・制約」 を共通言語で表す。 プラットフォームの中核は、Ontology。 Platform Layer Data Layer Ontology Layer 環境・企業・利用者のアクセス境界 をそろえる。 入力事実・現在状態・実行履歴を 、信頼できる形で持つ。 物流業務の対象・関係・操作を、 制約や権限まで含めて宣言的に表 す。全レイヤーが従う共通言語。 Analytical Layer AI Agent Layer Application Layer Ontologyに依存する形で、KPI・ 集計・予測を、判断に使える根拠へ 変える。 根拠と権限に基づき、次の行動を 判断・実行する。 業務画面と、定型プロセスを提供す る。 Copyright Hacobu, Inc. 29 

04 ｜ 共通と専用の境界 共通部分は、共有Ontologyへ。 個社・業界固有の違いを分け、再利用性と柔軟性を両立する。 Application A Application B Application C 業界｜Ontology 専用｜Ontology 業界の理解のみ 個社特有の理解のみ 共有｜Shared Ontology 物流の共通業務理解・制約・権限が、すべての Application から再利用される。載るほど、複利が効く。 同じ言葉が、個社や業界で別概念になりうる（境界づけられたコンテキスト）。違いは業界・専用Ontologyで表現する。 Copyright Hacobu, Inc. 30 

04 ｜ 業務の実行主体 人・AI Agent・Workflowが、Ontologyの業務操作を行う。 顧客に合わせて、どこを誰が担うかを設計する。 実行する主体 実行の境界 業務の変更 Ontology ・業務の状態を更新 人 ｜ Application UI AI Agent ｜ Tool 呼び出し 業務操作 Permission → Validation → Apply ・History に記録 ・Webhook で外部連携 ・同じ業務ルールで実行 Workflow ｜ 定義済み Step Copyright Hacobu, Inc. 31 

04 ｜ 宣言から実装を生成する Ontologyの宣言から、型付きSDK・権限・検証を生成する。 AIの判断範囲を制御し、決められたルールの中で実装する。 model.yaml ─ 宣言(正本・手書き) targets: truck: displayName: トラック primaryKey: id properties: truckNumber: { dataType: { string: {} } } arrivalDate: { dataType: { date: {} } } maxLoadKg: { dataType: { decimal: {} } } operations: dispatchTruck: displayName: 配車する functionKind: ontology_edit parameters: dispatchId: { required: true } truck: { objectTypeApiName: truck } edits: { objectTypes: [dispatchOrder] } Copyright Hacobu, Inc. sdk.ts ─ 型付き SDK(生成物) // Code generated; DO NOT EDIT. export type DispatchStatusCodeValue = "planned" | "assigned" | "completed"; 生成 export interface DispatchTruckActionParameters { dispatchId: string; truck: string; items: Array<{ [key: string]: unknown }>; } export const DispatchTruckAction = defineActionType( "dispatchTruck", { displayName: "配車する" }, ); 32 

04 ｜ AI Agent の強化 最新データを根拠に実行し、人が確定した正解で精度を高める。 評価は共通資産になり、次の実行につながる。 ① 実行時 ─ 必要な根拠を渡す ② 改善時 ─ 人の評価を反映する 実行履歴・業務データ 10,000件 実行ログ ＋ 人が確定した業務データ ↓ semantic search で絞る ↓ 確定値を評価基準に 関連する N件 だけを取得 現行版と候補版を比較・評価 ↓ ↓ 必要なN件だけを LLM context へ 人がレビューし、次の version を公開 データが蓄積するほど、根拠を見つけやすくなる Copyright Hacobu, Inc. 実行ログを、人の評価で改善データに変える。 33 

04 ｜ フライホイール 検証結果をOntologyへ、データをAI Agentへ戻す。 この循環を重ねるほど、次の物流課題を速く解ける。 Copyright Hacobu, Inc. 34 

05 まとめ 

05 ｜ AI時代の新たなエンジニアの役割 速く作ることより、顧客の本当の課題を解くこと。フルサイクルエンジニアがチー ムで課題を捉え、プラットフォームという武器で速く解く。 01 二つのズレ AIで実装が速くなっても、二つのズレは残る 02 感づく力 現場のクオリアに感づき、ドメイン知識で“問い”に変える 03 フルサイクルエンジニア チームで最前線に立ち、現場の課題と実装を往復する 04 プラットフォーム Copyright Hacobu, Inc. 業務知識とデータを蓄積し、次の物流課題を速く解く 36 

最後に • コードを書く楽しさは、そのままに。 • 課題の近くで、発見の面白さを味わえる。 • エンジニアリングを手段に、解決も楽しめる。 • ドメイン知識が深まるほど、見える世界が拡がり。 • 課題は社会インフラに根付き、解く意義も大きい。 • 企業間業務×物理×産業横断、課題寿命も長い。 物流面白いですよ Copyright Hacobu, Inc. 37 

No content

No content