SaaSとAI、比べて見えた 価値を生むAIプロダクト開発のコツ

約10年のSaaS開発と、経理AIエージェント量産の現場で得た実践知を凝縮。
① 非定型データから生まれる新たな価値を探る、② 実データで仕様を育てる、③ 自動デバッグで開発を高速化 ――を、出張手配エージェントの実例や開発で実際に発生した問題とともに解説します。ハッカソンのテーマ設定・開発にも直結する、明日から使えるコツを提供します。

1. 　 SaaSとAI、比べて見えた 価値を生むAIプロダクト開発のコツ 東京AI祭ハッカソン キックオフイベント 2025年08月23日 株式会社TOKIUM 取締役CTO 兼 プロダクト本部長 西平 基志
2. 話すこと 2 約10年のSaaS開発の経験 ＋ AIエージェント量産への挑戦で見えた AIプロダクトで価値・成果を生み出すための要素を学びとして共有
3. “ AIプロダクト開発のTipsの共有と “ ハッカソンの説明、チームづくりにも使える “ 懇親会を予定しております “ 開発への熱い想いを持つ仲間と出会い、 “ 最高のスタートを切りましょう！ 🚀 話すこと 3 約10年のSaaS開発の経験 ＋ AIエージェント量産への挑戦で見えた AIプロダクトで価値・成果を生み出すための要素を学びとして共有
4. 話すこと 4 “ AIプロダクト開発のTipsの共有と “ ハッカソンの説明、チームづくりにも使える “ 懇親会を予定しております “ 開発への熱い想いを持つ仲間と出会い、 “ 最高のスタートを切りましょう！ 🚀 約10年のSaaS開発の経験 ＋ AIエージェント量産への挑戦で見えた AIプロダクトで価値・成果を生み出すための要素を学びとして共有
5. 5 自己紹介 & 会社概要
6. 株式会社TOKIUM 取締役 CTO 西平 基志 Motoshi Nishihira 自己紹介 2012年、筑波大学在学中に株式会社TOKIUMを共同創業。 以来、すべてのWebサービスの設計・開発を統括し、 経理領域のアナログな業務のクラウド化を推進。 直近2年間はLLMチームを立ち上げ、OCRへのLLM組み込みを 主導。現在は、「Mastra」を活用した経理AIエージェントの 開発基盤と組織づくりを進めています。 X(Twitter): @snomof 6
7. 会社概要 会社名 設立日 所在地 従業員数 代表取締役 株式会社TOKIUM 2012年 6月 26日 東京都中央区銀座6-18-2 野村不動産銀座ビル 12F 約240名 (2025年6月、正社員のみ) 黒﨑 賢一 7 TOKIUMの志 未来へつながる時を生む
8. 創業以来、10年以上一貫して支出にまつわるサービスを提供。 TOKIUMシリーズは直近5年間で導入社数が6倍以上増加し、2024年7月に2,500社を超えました。 TOKIUMのプロダクト｜創業以来、支出にまつわるサービスを提供 累計導入社数 2,500社を突破 ※24/07末時点 製造 IT・情報通信 外食・食品 製造 建設・不動産 コンサルティング 金融・保険 法人サービス 小売 インフラ・物流 商社・流通 広告 広告・エンタメ 医薬・化学 2012年6月 　創業 2016年2月 「TOKIUM経費精算」 2020年9月 「TOKIUMインボイス」 2024年6月 「TOKIUM契約管理」 2022年1月 「TOKIUM電子帳簿保存」 2025年1月 「TOKIUM請求書発行」 8
9. TOKIUMのプロダクト｜経理AIエージェント 経理AIエージェント AIとプロスタッフが連携し、あらゆる経理”作業”から人々を解放 経理業務の自動運転を実現 日常的な言葉の指示で 経理作業を代行 TOKIUMの既存サービス (SaaS)との連携 人間のオペレーターによる ヒューマンインザループ AX(AI Transformation)を 実現するためのサポート 4体のエージェントをリリース 翌5月までに、20体以上のエージェントの提供を目指す 9
10. 現在の業務 10 “ 2025年の5月上旬、私は上長、開発部の部長、 “ CTOの4人でモック開発を行いました。 “ まさにゼロからの状態で、「チャットで “ 話しかけるだけで出張の手配が全部できたら “ 面白いんじゃない？」というアイデアから “ 始まりました。 ― 『経理AIエージェント開発のプロジェクト立ち上げから関わったインターン生の話』 TOKIUM公式noteより 長らく開発業務からは離れていたが 出張手配エージェントのモック開発を皮切りに commit量が急増 ※画像は7月のContribution activity
11. プロダクトのデモ: 出張手配エージェント 11 動画リンク: youtu.be/jooarcZCuwo?si=rKCD72SSe4fWZl4k
12. 現在の業務を通して見えた、AIプロダクト開発のポイント 12 実際にAIエージェントの開発に携わることで見えた、3つのポイント
13. 現在の業務を通して見えた、AIプロダクト開発のポイント 13 1. 非定型データから生まれる 3. 新たな価値を探る 2. 実データで仕様を育てる 3. 自動デバッグで開発を高速化 実際にAIエージェントの開発に携わることで見えた、3つのポイント 課題設定 課題解決 実装
14. 14 1. 非定型データから生まれる 3. 新たな価値を探る
15. コード×コンテキストが価値を生む 15 これまでのWebサービス AIエージェント - コードが動作を規定する - システムに入力するデータは基本的に 定型データ（構造化・安定）である - ルールを事前に決められるプロセスで 大きな価値を生み出すが、 ルールが決まらない・変わりやすい プロセスの課題解決は苦手 1. 非定型データから生まれる新たな価値を探る - コード×コンテキスト(データ)が 動作を規定する - 自然言語のドキュメントなど 非定型データ（非構造・変動）を 入力できる - コンテキストで動作を変えられるため 非定型なプロセスでも柔軟に対応
16. コード×コンテキストが価値を生む 16 AIエージェント 1. 非定型データから生まれる新たな価値を探る 非定型データも扱えるため これまでになかった課題解決ができる 例: 社内規定を自然言語のまま読み込み ユーザーの質問に自動で回答する - コード×コンテキスト(データ)が 動作を規定する - 自然言語のドキュメントなど 非定型データ（非構造・変動）を 入力できる - コンテキストで動作を変えられるため 非定型なプロセスでも柔軟に対応
17. コード×コンテキストが価値を生む 17 AIエージェント 1. 非定型データから生まれる新たな価値を探る コードだけでは扱うことが難しい ユーザーごとに異なる要望にも柔軟に 応えることができる 例: 個別ユーザーの希望を取り入れながら 出張の計画を立てる - コード×コンテキスト(データ)が 動作を規定する - 自然言語のドキュメントなど 非定型データ（非構造・変動）を 入力できる - コンテキストで動作を変えられるため 非定型なプロセスでも柔軟に対応
18. コード×コンテキストが価値を生む 18 AIエージェント 1. 非定型データから生まれる新たな価値を探る AIプロダクトを作るなら、前例のない価値を 生み出せるか、とことん追求すべき ただし、闇雲にデータを読み込ませても 得たい価値は得られない 適切にデータを選ぶ・読み込ませる必要がある 社内規定を自然言語のまま読み込み ユーザーの質問に自動で回答する 個別ユーザーの希望を取り入れながら 出張の計画を立てる - コード×コンテキスト(データ)が 動作を規定する - 自然言語のドキュメントなど 非定型データ（非構造・変動）を 入力できる - コンテキストで動作を変えられるため 非定型なプロセスでも柔軟に対応
19. 19 2. 実データで仕様を育てる
20. 出張手配エージェントの開発で、ぶつかった壁 20 🚄 AIとのチャットで、新幹線の便を検索 - リリース前のチェックでは、特に問題なく動作した機能 - リリース後、以下のようなフィードバックが… 2. 実データで仕様を育てる
21. 出張手配エージェントの開発で、ぶつかった壁 21 🚄 AIとのチャットで、新幹線の便を検索 - リリース前のチェックでは、特に問題なく動作した機能 - リリース後、以下のようなフィードバックが… 列車を選んだ後に、S Work車両でお願いとすると処理が成功するんですが、 最初からS Work車両ありきで指示すると、列車が見つからないとなります。 プロンプトの入力方法などにコツがあるのでしょうか？ 2. 実データで仕様を育てる
22. 出張手配エージェントの開発で、ぶつかった壁 22 🚄 AIとのチャットで、新幹線の便を検索 - S Work車両 = 移動中に仕事を進めたい乗客の利用を想定した車両 S Work車両 = のぞみ・ひかり・こだまの7号車が該当 - 条件指定の順番によって、結果が変わる原因 - 利用している乗り換え検索APIに「S Work車両か否か」のパラメーターが存在しない - 先に「S Work車両」を指定すると、仕様上存在しないパラメーターを無理やり 利用しようとしてしまい、意図した結果が返ってこない 2. 実データで仕様を育てる
23. 出張手配エージェントの開発で、ぶつかった壁 23 これまでのWebサービス AIエージェント S Work車両の条件が暗黙的に排除 → ユーザーの期待値と提供価値が揃う S Work車両の条件に対応しているか不明 → ユーザーの期待値と提供価値が揃わず 意図しない結果が返ってしまう 2. 実データで仕様を育てる
24. 出張手配エージェントの開発で、ぶつかった壁 24 AIエージェント ユーザー 期待した結果が返ってこなかった 思ったより役に立たないな… サービス提供者 ユーザーの入力が予想できない 想定通り課題は解決できたのだろうか…？ S Work車両の条件に対応しているか不明 → ユーザーの期待値と提供価値が揃わず 意図しない結果が返ってしまう 2. 実データで仕様を育てる
25. 出張手配エージェントの開発で、ぶつかった壁 25 これまでのWebサービス AIエージェント UI/UXの仕様を適切に定めることで 入力値を限られたパターンに絞れる 自然言語で入力 = パターンが無数に存在 「何を依頼するか」だけでなく、 「順番」や「言い回し」への考慮も必要 2. 実データで仕様を育てる
26. 対策 26 ★ AIエージェントは、入力の自由度が高く結果が定まらない ➔ ユーザーがどのようにデータを入力するのか、 入力の分布を予測することで仕様が定まっていく ➔ 入力の分布のカバレッジを上げることで、仕様を育てる ★ 分布の予測には、実際のデータが不可欠 ➔ 具体的なユースケースのヒアリングや、ユーザーから 実際のデータで試してもらうことが、確実な課題解決につながる 2. 実データで仕様を育てる
27. 27 3. 自動デバッグで開発を高速化
28. 28 3. 自動デバッグで開発を高速化 「自動テスト」ではないのか…？🤔
29. 用語の整理: 「テスト」と「デバッグ」の定義 29 3. 自動デバッグで開発を高速化 出典: ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 “ 1.1.2 テストとデバッグ “ テストとデバッグは別の活動である。 “ テストをすることで、ソフトウェアの欠陥によって引き起こされる故障を発生させたり、 “ テスト対象の欠陥を直接発見したりすることができる。 “ 一方で、デバッグの関心ごとは、故障の原因(欠陥)を発見し、その原因を解析し、 “ 原因を取り除くことにある。
30. 用語の整理: 「テスト」と「デバッグ」の定義 30 出典: ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 テスト → ソフトウェアに存在する故障を発見するための作業 “ 1.1.2 テストとデバッグ “ テストとデバッグは別の活動である。 “ テストをすることで、ソフトウェアの欠陥によって引き起こされる故障を発生させたり、 “ テスト対象の欠陥を直接発見したりすることができる。 “ 一方で、デバッグの関心ごとは、故障の原因(欠陥)を発見し、その原因を解析し、 “ 原因を取り除くことにある。 3. 自動デバッグで開発を高速化
31. 用語の整理: 「テスト」と「デバッグ」の定義 31 出典: ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 デバッグ → ソフトウェアの故障を発見し、その原因となる欠陥を特定、 デバッグ → そして欠陥を取り除いて故障を修正する、一連のサイクル “ 1.1.2 テストとデバッグ “ テストとデバッグは別の活動である。 “ テストをすることで、ソフトウェアの欠陥によって引き起こされる故障を発生させたり、 “ テスト対象の欠陥を直接発見したりすることができる。 “ 一方で、デバッグの関心ごとは、故障の原因(欠陥)を発見し、その原因を解析し、 “ 原因を取り除くことにある。 3. 自動デバッグで開発を高速化
32. デバッグの自動化 = PDCAサイクルの自動化 32 これまでのデバッグ AI時代のデバッグ - テストで発見された不具合の 原因を探り、修正する - 自動化できるのは、 あくまでテストの実行のみ - 「不具合の発見」は自動化されるが 「原因の特定」と「修正」は 人間にしかできない - テストの実行だけでなく、 不具合の原因の特定、 コードや仕様の修正まで、 全て自動かつ自律的に行われる - テストケースが コーディングエージェントの 自律的な試行錯誤の指針となる - 実装に閉じた小さなPDCAが自動化 大局的なPDCAに人間が集中できる 3. 自動デバッグで開発を高速化
33. デバッグの自動化 = PDCAサイクルの自動化 33 AI時代のデバッグ - テストの実行だけでなく、 不具合の原因の特定、 コードや仕様の修正提案まで、 全て自動かつ自律的に行われる - ソフトウェアの仕様を テストケースとして与えることで コーディングエージェントの 自律的な試行錯誤の指針となる - 実装に閉じた小さなPDCAが自動化 大局的なPDCAに人間が集中できる 自動化させるのは、テストではなくデバッグ 適切なテストコード・テストケースの存在が 実装のPDCAの自動化・高度化を推し進める テストケース = AIの実装指針であり、 その作成コストも劇的に小さくなっている 開発の初期から、粒度の大きなテスト(E2E)を 気軽に書いてしまってよいのでは？ 3. 自動デバッグで開発を高速化
34. 34 ハッカソンに向けて、明日からできること
35. 明日からできること 35 1. 非定型データから生まれる 3. 新たな価値を探る 2. 実データで仕様を育てる 3. 自動デバッグで開発を高速化 課題設定 課題解決 実装
36. おわりに: スポンサー賞の紹介 36 今日から約3週間、開発頑張ってください！応援しています！ 全国約108施設のペア宿泊券を選べる！ 2部贈呈するので、3〜4名チームも全員楽しめる！