why-the-former-cto-is-now-fde

ログラス共同創業者・坂本龍太の登壇資料。元CTOがFDE（Forward Deployed Engineer）として顧客現場に出た理由を語る。

要旨は以下。エンタープライズの意思決定課題は、散在データ・システム乱立・固有プロセスゆえにSaaSの標準機能だけでは解けない。「AIは確率で動き、組織は責任で動く」——この異質な二つを接合するのが設計問題であり、FDEの仕事だと位置づける。

実績として、ある顧客のFP&A領域で月次レポート作成を96時間→24時間（約75%削減）、実績集計を約80%削減。AIエージェント「ALICE」が社内外データを自律収集し、予実差異分析からSlack/Teams配信まで一気通貫させた。

学びは二つ。将来業績を「当てに行った」試みは1ヶ月で頓挫し、"当てるAI"ではなく"判断材料のAI"へ路線変更したこと。技術的可能性と組織の受容力は別変数だということ。確率的出力を組織に流通させる仕組みとして、確信度スコア・権限連動・トレーサビリティ（根拠リンク）を実装し、「信じてください」ではなく「検証できます」を担保する。

日本でFDEが必然なのは、ユーザー企業にエンジニアが不足し、ドメイン知識×大規模実装×セキュリティ運用の3点を揃えた人材が他にいないため。10年後に職種名やワークフローは消えても、未言語化の課題を発見する力、本番稼働まで実装し切る力、組織の信頼を積む力、価値の出る場所へ自己を再配置する力は残る、と締める。

Transcript

1. AIソリューション本部 10年後、FDEさえ要らないかもしれない。 それでも今、元CTOが現場に出る理由 坂本 ⿓太 株式会社ログラス 共同創業者 / AIソリューション事業本部 開発部 部⻑ / FDE 2026年 8⽉ 26⽇
2. ⾃⼰紹介 株式会社ログラス 共同創業者 / AIソリューション事業本部 開発部 部⻑ / FDE さかもと りゅうた 坂本 ⿓太 ⿃取県境港市出⾝ 中央⼤学商学部会計学科で4年間公認会計⼠を⽬指すも、撤退 60名程度であったビズリーチ（現ビジョナル）の初代新卒⼊社 同社が1200⼈まで急成⻑する中、求⼈検索エンジン、採⽤管理 SaaS、新規SaaS事業の開発責任者を経験 サイバーエージェントに転職し、AIチャットボットの基盤を開発 ログラスを共同創業し、取締役CTOに就任 初代CTOとしてプロダクト組織を牽引したのち、CTOを退任 現在：FDEとして、AIソリューション事業の⽴ち上げと顧客現場で の実装を推進 ⼀児の⽗、保護猫2匹 🐈🐈 スタートアップ CTO of the year 2022オーディエンス賞 x.comは、 @http204
3. ログラス社について
4. ⾃⼰紹介
5. 公開情報から筆者作成 https://ja.wikipedia.org/wiki/KDD グループ 例えば：連結⼦会社193社、共同⽀配企業46社
6. 03 ─ 設計 海外を含め膨⼤なデータを集め、分析し、資料化し、経営と事業部をつなぐ仕事
7. Q: LLMが『この事業は撤退すべき』と出⼒。これ、経営会議に出せますか？ Q：LLMが「この事業は撤退すべき」と出⼒。これ、経営会議に出せますか？ AIは確率で動く。 組織は責任で動く。 ‧同じ⼊⼒でも毎回異なる出⼒ ‧決裁権限と会議体による合意形成 ‧ハルシネーションのリスク ‧「誰が責任を取るか」が前提 ‧根拠を100%完全には説明できない ‧確率的な出⼒をそのまま受け⼊れる仕組みがない AIを組織に実装するとは、この異質な2つを接合する設計問題 AIをエンタープライズに実装するとは、モデルの賢さを競うことではない。この異質な2つの原理を接合する「設計問題」
8. 01 ─ 現在地 FDEとして、 “指⽰された実装だけで終わるのでもなく、顧客の 「現場」に深く潜り込み、事業の結果そのものに コミットする” エンジニアとして、熱中できる瞬間があります ⽉次リポート作成‧レビュー 約75%削減（毎⽉約100ページ） 96時間 → 24時間 経営実績の集計 出典：⽇本経済新聞 2026/8/7 約80%削減 出典：https://bizzine.jp/article/detail/13003 今⽇はこの数字の「裏側」と「その先」を話します
9. 01 ─ 現在地 出典：⽇本経済新聞 2025/11/11 25年11⽉11⽇の記事 出典：⽇本経済新聞 2026/8/7 26年8⽉7⽇の記事
10. 02 ─ 決断 なぜ、SaaSだけでは届かなかったのか 私たちがこれまでに信じてきた構図 エンタープライズの現実 ‧SaaSこそ、レバレッジが効く ‧意思決定の課題そのものは、標準機能だけでは解けない ‧ノーコンサルであるべき ‧散在データ‧システム乱⽴‧固有プロセス‧不⽂律 ‧vs SIerでの優位性 ‧整っていない場所に、⾃動⾞は決して⾛らない 批判：この事業は、レバレッジが効かないのでは？ エンタープライズの深い課題を解くしかない 「今再び創業する。この事業をログラス社よりも⼤きくするぞ！」でやってます
12. 03 ─ 結果 Loglass 経営管理を基盤に、AIエージェント「ALICE」を実装
14. 03 ─ 結果 実際の機能をもう少し丁寧に
15. 03 ─ 設計 短評から、事業別の要因、根拠になる表とグラフまでを、その場で返す 膨⼤なExcel 膨⼤な議事録 社内の規定 ※質問も回答もダミー 「各セグメントで⼤きな予実差異がある事業を調べ、それぞれ要因を教えて」 のような⾮常に網羅的かつ深いリサーチが可能
16. 03 ─ 設計 毎⽉100以上ある事業の予実差異を⾃動⽣成（これまでは⼿⼊⼒だった） ※回答はダミー 初期は全てレビューをもらっていましたが、現在はほぼ⾃動チェックだけで済んでいる
17. 05 ─ カレーライスのBOM（Bill Of Materials、部品構成表） ログラスのFDEは、経営の意思決定の⾼度化だけに取り組んでいる これはカレーライスの部品構成表 正しく⾃社製品の原価を把握出来ている 製造メーカーは⾮常に少ない 撤退するべき製品 値上げするべき製品 の判断が⾮常に難しい ⼟台を整え、経営管理を可能にする 数⼗万の部品、完全ではないデータ、ERPに⼊った超巨⼤データ（数⼗TB）を扱う
18. 05 ─ カレーライスのBOM（Bill Of Materials、部品構成表） ログラスのFDEは、経営の意思決定の⾼度化だけに取り組んでいる グローバル企業での業績把握は⾮常に難しい。早期に検知し、正しいデータで意思決定を
19. 05 ─ 学び ｜ 事件簿 顧客の定例報告会での実演で、Agentが沈黙した 起きたこと 本当の問題 設計に戻す Research Agentの実演 問題は、ただ落ちたことで 「ここまでは分かった」 の最中に、応答が⽌まる はない を返せるように コストを抑えるため、試⾏回数の 上限を下げていた。答えに辿り着 ＞ 「途中まで」 ＞ 「分かったところまで」 けないまま停⽌。 → 久しぶりに、⼤量の汗を出すはめに を返さなかった 今重要なのは、コストか、スピードか、正確性か 上限とタイムボックスはハード に管理。確度が低くても、途中 までは必ず返す。
20. 05 ─ 学び 技術的にできることと、その組織が受け取れることは、全く別の変数 先⾛り 順番を戻す 現在 将来の業績を"当てに⾏った" 効率化と判断材料づくりへ 経営陣が、⾃ら使い始める 事業部には既に⾼精度の⾒込みが 細かいチューニング∕デー "当てるAI"ではなく"判断 あり、後追いの価値は⼩さい。 → 1ヶ⽉で頓挫 ＞ ＞ タソースの順次拡充∕アク 材料のAI"として、意思決 セスしやすさの圧倒的改善 定の場へ ⸺信頼を積む 信頼を積み上げ、業務に浸透させ、業務を変えるまでがFDEの責務
21. 05 ─ 道筋 Loglass FDEが貢献している価値は、「本番稼働とその先」 問われるのは「機能するか」ではなく、「お客様の本番環境で動かし、運⽤し続けられるか」。 その上で、確率的な出⼒を組織に流通させる3つの仕組み 1 確信度スコア 2 権限 3 トレーサビリティ 全出⼒に確信度スコアを付与。 Agentが参照可能な範囲 ＝ Loglassにおけ 全回答に根拠リンク： レビューを「なくす」のではなく、 るユーザーの権限 元ファイル∕Loglass 経営管理のレポート 低確信度の出⼒にフォーカスさせる。 議事録についても、どの部署に⾔及してい ∕外部情報∕DWHをソースとするBIダッ 数多くのレビューで、 るか？を全⾃動でタグ付けして守る シュボードや、セルレベルのリンク ※要承認 「AIを信じてください」ではなく、「AIの⾔うことは、いつでも検証できます」を実現する
22. 05 ─ 回答 基盤と事業に還元するプロダクト 個社で⽣まれた汎⽤パターンは、 サービスレイヤー プラットフォームへ還流 FP&Aエージェント 特定業界向けエージェント Loglass 経営管理∕⼈員計画∕設備投資 FDEによる追加開発 現場から実際に還ってきたもの ‧巨⼤なExcel∕スプレッドシートに⽴ち向かうためのシ セマンティックレイヤー 意味定義‧メタデータ ステム ‧経営企画のユーザーがResearch Agentに投げる問いと、 データ処理基盤レイヤー 集計CORE‧バッチ フィードバックのレコード ‧ダッシュボード類をAI Agentが読めるようにするメタ 共通基盤レイヤー 認可‧セキュリティ‧ガバナンス データ管理など、権限管理の共通プラットフォーム ※ セマンティック∕データ処理基盤∕共通基盤 ＝ 既存Loglassシリーズ 派⼿なAIは、⼀つもない。それでも次の顧客に、この部品を持って⼊れる
23. 06 ─ 必然 なぜ⽇本で、FDEが必然なのか？ 事実 本質 結論 ユーザー企業に、 ドメイン知識がなければ 3点が揃う⼈間だけが、 エンジニアが全然いない 実装できない 真の味⽅になれる いても、本業に貢献している もちろん、経営管理‧FP&Aの専⾨知 ＞ 配賦、連結消去、 ＞ 経営管理のドメイン知識 予算Noのマッチング、、、、 × ⼤規模システムの実装 識までは持たない ⸺業務の意味が分からなければ、 × セキュリティ 安定運⽤ コードにならない ドメイン知識 × Claude Codeでも、数億件のデータをセキュアに安定的には処理できない。 情シス、セキュリティ部⾨とは話せない。FDEの価値はここにもある。
24. 06 ─ キャリア 10年後、FDEは要らないかもしれない 寿命が短いもの 10年後も残るもの ‧職種の名前 ‧⾔語化されていない課題を、発⾒する⼒ ‧今⽇のワークフロー ‧本番稼働まで実装し切り、安定運⽤させる⼒ ‧今⽇のモデルの弱点を埋める技 ‧組織を代表し、組織の信頼を積み上げる⼒ ‧価値の出る場所へ、⾃分をまた再配置する⼒ もう⾊々Skillに書いてきた 会社の名前を背負える総合⼒ FDEは、どこで最も貢献出来るか？の嗅覚が⽇々最前線で磨かれる
25. 05 ─ 学び ｜ 現場でしか聞けなかった⼀⾔ 「もう以前には戻れない。」 ⸺ 毎⽉、⼤量のExcelとスプレッドシートを扱ってきた経営企画の⽅ 効率化ではなく、仕事の中⾝が変わったということ。