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