正解なきAI開発で、PdMはどう意思決定するか――「Embedded AI vs AI Agent」という判断の裏側

AI機能を既存SaaSに組み込むか、独立したAI Agentとして切り出すか。正解がまだないAI機能開発、あなたのチームはこのアーキテクチャの問いにどう答えますか？ TOKIUMはSaaSをエージェントが叩くAPIと再定義し、半年で9つのAgentをリリース。この決断が、単なる機能追加ではなく「業務丸投げ体験」の爆速検証を可能にしました。 重要なのは、間違えないことより「低コストで撤退できる構造」の設計です。元エンジニアPdMの視点から、攻めの意思決定を支える判断軸と、泥臭い失敗のリアルをお話しします。

Transcript

1. 　 正解なきAI開発で、PdMはどう意思決定するか ――「Embedded AI vs AI Agent」という判断の裏側 株式会社TOKIUM プロダクト本部インボイス製品開発部 村上 雅⼀
2. @massann_1010 2 ⾃⼰紹介 • 名前 ◦ 村上 雅⼀ / Masakazu Murakami • 所属 ◦ 株式会社TOKIUM プロダクトマネージャー • 経歴 ◦ 2024.04 TOKIUM⼊社 ▪ ⽇系ITコンサルティングファーム にてエンジニア歴7年 ▪ PdMはTOKIUM⼊ってから • ひとこと ◦ 好きな法則はコンウェイの法則 https://zenn.dev/mura_massann
3. TOKIUM紹介 3
4. 4 TOKIUMのこれまで 経理業務の効率化を実現してきた道のり 創業 家計簿アプリ提供開始 経費精算サービス提供開始 ポストで領収書の原本回収開始 請求書の受け取り代行開始 支出管理領域へ拡張 経理AIエージェント元年 2012 「時を生む」 を志に、 個人向けの支出管理アプリでスタート。 2016 2019 2020 2025 2013 人のオペレーションと機械を融合した 独自モデル を確立。 ツールではなくサービス。 ユーザーが作業から解放される 「丸投げUX」のアプローチ で圧倒的効率化。 AIを核とした社会インフラとして 長期目線を持ちつつ革新を続ける 。 経理の作業そのものをなくす 新しいインフラを築く。
5. 5 経理AIエージェント 経費申請の不備・誤りのチェックを含めた一次承認作業を、AI とプロスタッフが代行。 社内規程やルールに基づいた申請内容の目視チェックや、 頻発する内容不備による差し戻し対応の手間をなくします。 移動経路の検索・宿泊先の手配、出張申請…。 出張手配の「探して、予約して、申請して」をAIエージェン トが代わりに実行します。
6. 意思決定の裏側にあった現場のカオス 6
7. 2025年4⽉ そろそろSaaSにAI機能を組み 込むためのロードマップを考 えなくては。 7 予測不能な1年をかけぬけた GW明けに全社⽅針が変わり、正解なきまま⾛り出した 2025年夏 世に正解ない中で開発をして、 多くの選択ミスを経験した。 2025年GW明け AIエージェントに開発⼈員のほとんどを 投下する会社の決定。 検討していたロードマップを⽩紙に。
8. 8 なぜ、急いでAIエージェントをリリースしたか？ 正解のないAIエージェント開発 構想の精度より試⾏の回数が勝敗を決めると考えた 競合が多い環境 Move Fastというカルチャー 速く 出す 速く 失敗 速く 学ぶ Move Fast
9. 9 この1年、TOKIUMがやったこと 各AIエージェントにPdM1名、エンジニア2〜3名程度 新⼈も多くベテラン揃いでもないが、半年で9つリリースした。 少⼈数でも、構造さえ整えればここまでできる
10. Embedded AI vs AI Agent 10
11. 11 使う側のものを作る 使う側は、使われる側の外にいるべきだ Embedded AI AI Agent Agent SaaS Agent
12. Core 12 プロダクトの4階層 Coreから逆算して、概念駆動でHowを選択すべき。 Why What How 及川卓也ほか『プロダクトマネジメントのすべて 事業戦 略・IT開発・UXデザイン・マーケティングからチーム・組 織運営まで』翔泳社、 2021年、p.54 出典 ミッション ビジョン 事業戦略 ターゲット ユーザ ペインと ゲイン 市場分析 競合分析 メンタル モデル カスタマー ジャーニー コスト 構造 収益モデル コスト 構造 収益モデル ユーザー インターフェース 設計と実装 Go To Market
13. 13 この登壇で伝えたいこと 「何を作っているか」を定義したら、構造は⾃然に決まった。 SaaSとAIエージェントは別概念。 そのため、AIエージェントはSaaSと独⽴して作った。 Core 未来へつながる 時を⽣む What 業務丸投げ体験 How AIエージェント独⽴ Why 判断と作業の負担 から解放する SaaS：使われるツール AIエージェント：使う主体 リターン1 検証速度の最⼤化 リターン2 影響範囲の最⼩化 リターン3 ⼿戻りの最⼩化
14. 14 TOKIUMが⽬指す経理業務の未来 AIエージェントが操作 After ⼈が操作するSaaS Before ⼈がSaaSの操作⼿順やルールを覚えて⼿作業 でUIを操作 ⼿作業によるミスが発⽣ 判断を⼈が⾏うため、判断が必要な業務に時間 を奪われる …… …… 人が操作する SaaSから、AIエージェントが実行する業務へ AIエージェントがSaaSを横断操作 SaaSはAIエージェントが参照‧操作するため のデータベースへと変化 基本的な判断はAIが⾏い、⼈は例外対応‧承 認だけ⾏う
15. AIエージェントがもたらした3つのリターン 15
16. 16 PdM視点でのメリット コンセプトに従ったら、3つのリターンがついてきた リターン① 検証速度の最⼤化 社内ツールが売れた リターン② 影響範囲の最⼩化 ⽌める痛みはあったが 最⼩限に抑えられた リターン③ 軌道修正の軽さ 技術変化にも 素早く対応
17. 17 リターン①：検証速度の最⼤化 AI明細⼊⼒をHITLで回しながら需要を確認。 綺麗なプロダクトではなかったが、それでよかった やったこと 完成前にBPOとセットで売り始めた 裏でTOKIUMの⼈間が操作して納品 1 機能不⾜の多いプロダクト 社内で使い勝⼿の向上 2 引き合いがあるか検証 需要を確認してからユーザー提供 3 外に出していたため、検証しながら開発することができた。
18. HITLを回すのが⼤変なほどに想定以上に売れた。 18 リターン①：検証速度の最⼤化 精度を上げてから出すよりも、⼈が補完する前提で早く出す⽅が結果として速い STEP1 HITLで検証 STEP2 需要を確認 STEP3 さらなる開発投資
19. リリース → 想定以下の需要 → サービス停⽌。 この判断をスピーディーにできたのは構造のおかげだった。 19 リターン②：影響範囲の最⼩化 経費監査と経費承認を 別プロダクトで切り出し 業務領域の重なりが 想定以上に⼤きかった 承認 監査 需要がついてこず 確信に変わる 独⽴したサービスだったため、 依存も少なく適切にサービス停⽌し、経費承認にロジックを移植できた。 経理スタッフ 監査
20. 20 リターン②：影響範囲の最⼩化 ビルドトラップを引きずらず、必要なロジックだけ移植できた。 SaaSに組み込んでいたら、機能の移植や剥がすコストが巨⼤だった
21. 21 リターン③：軌道修正の軽さ 2回の技術選定ミス。 2回とも軌道修正したが、どこよりも早く顧客に価値提供できた。 Case 1 Case 2 ノーコードツール それぞれ独⽴しており間違えた部分だけ差し替えで 軌道修正コストが低かった。 Claude Code
22. まとめ 22
23. コンセプトから逆算したチームの構造がスピードを⽣む 少⼈数のチームが圧倒的にスピードを出せたのは、気合ではなくチーム構造だっ た。レガシーコードからAI開発を切り離すことで開発⽣産性の向上につながった。 捨てる前提のアーキテクチャ 不確実性が極めて⾼い環境では、初期の作りやすさよりの後からの捨てやすさが⼤ 事である。これがビルドトラップを避けるための⼯夫となる。 23 概念駆動開発の三原則 正解なきAI領域において、 PdMが迷わずに価値を⽣み出すための概念駆動開発。 迷ったらCoreに戻る 最新のAIで「何が作れるか？」から出発しない。 「誰をどんな状態にしたいか」というブレないコンセプト（概念）から逆算する。 1 2 3
24. ⼀緒にチャレンジしましょう！ 24 構造さえ作れば、カオスな状況でも意思決定できる。 私たちも同じだけ失敗してきました。 ぜひ皆さんもPdMとして勇気ある⼀歩を踏み出してください。 情報発信中 まずは気軽にお話しませんか？ カジュアル⾯談も受付中です @TOKIUM_Dev 日程調整はこちら 2026年5月限定