Exploring Engineering in Workflow Development

『ワークフロー開発でエンジニアリングを模索する』

TypeScript with LLMs
2025-10-28 19:00〜
https://lymo.connpass.com/event/369456/

Transcript

1. ワークフロー開発で エンジニアリングを模索する 2025/10/28 TypeScript with LLMs LT
2. whoami • Hiroki Inoue • Software Engineer • 株式会社スマートラウンド 2
3. はじめに 手触り感のある経験、悩みの共有 （教科書的な話は教科書を読めばよい） 3
4. 前提 • MastraのWorkflowsを利用。 • 社内向けシステムとして提供。 • 書類から所望の情報を抽出して報告書を作成するみたいな。 ◦ 報告書には数種類のフォーマットを想定。 ◦ 抽出対象を動的に判断し、表記揺れをならしたり計算したりも。 • 書類はpdfで、標準的なフォーマットがあるものの標準に従っているとは限らない。かつ、自由記 述なので何を読み取るか予測できない。 4
5. アジェンダ • 開発における不都合 • 設計の論点・工夫 • ソフトスキルの重要性 5
6. 開発における不都合 6
7. 開発における不都合 non-LLMのシステムと比べて • 処理速度が遅い • コストがかかる • 非決定的 7
8. 開発における不都合 non-LLMのシステムと比べて • 処理速度が遅い • コストがかかる • 非決定的→予測可能性が低い 8
9. 開発における不都合 non-LLMのシステムと比べて • 処理速度が遅い • コストがかかる • 非決定的→予測可能性が低い→品質保証が難しい 9
10. 開発における不都合 非決定的→予測可能性が低い→品質保証が難しい • flakyなテスト 10
11. 開発における不都合 非決定的→予測可能性が低い→品質保証が難しい • flakyなテスト • ロジックの妥当性という観点で評価しづらい（レビューしづらい） 11
12. 開発における不都合 非決定的→予測可能性が低い→品質保証が難しい • flakyなテスト • ロジックの妥当性という観点で評価しづらい（レビューしづらい） • プロンプトの改訂による影響が予見しづらい 12
13. 開発における不都合 13 果たしてほんとうに 要件を満たせたのか？
14. 開発における不都合 14 果たしてほんとうに デグレしてないか？
15. 設計の論点・工夫 15
16. 設計の論点・工夫 Vertex AIのパラメータで決定論に寄せてみる 16
17. 設計の論点・工夫 Vertex AIのパラメータで決定論に寄せてみる • Temperature: 0 - 最も決定的な回答を生成 • Top-K: 1 - 候補を1つに絞り込み • Candidate Count: 1 - 生成候補数を1つに固定 • etc. 17
18. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ 18
19. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [課題] • 入力には無限の可能性がある 19
20. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [課題] • 入力には無限の可能性がある • テストデータは有限 20
21. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [課題] • プロンプトのどのフレーズが何を想定したものなのか？ 21
22. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [課題] • プロンプトのどのフレーズが何を想定したものなのか？ • どこをいじると何に影響があるのか？ 22
23. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [課題] • プロンプトのどのフレーズが何を想定したものなのか？ • どこをいじると何に影響があるのか？ • どこをいじると何が進化・退化するのか？ 23
24. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [対策] • インテグレーションテスト（保護弱め） 24
25. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [対策] • インテグレーションテスト（保護弱め） • データバリエーションのカタログ（手間かかる） 25
26. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [対策] • インテグレーションテスト（保護弱め） • データバリエーションのカタログ（手間かかる） • 開発経緯を辿れるようにする 26
27. 設計の論点・工夫 開発経緯を辿れるようにする • ADR？ • プロンプトに履歴をつける？ • Issueと紐づける？ • コミットメッセージをしっかり書く？ 27
28. 設計の論点・工夫 開発経緯を辿れるようにする • ADR？ • プロンプトに履歴をつける？ • Issueと紐づける？ • コミットメッセージをしっかり書く？ ⇨AIに辿ってまとめてもらう 28
29. 設計の論点・工夫 デグレ（退行）から如何に保護するか？ [対策] • インテグレーションテスト（保護弱め） • データバリエーションのカタログ（手間かかる） • 開発経緯を辿れるようにする • 保護の難しさを受け入れる 29
30. 設計の論点・工夫 保護の難しさを受け入れる • 壊れたことに気づけるようにする 30
31. 設計の論点・工夫 保護の難しさを受け入れる • 壊れたことに気づけるようにする → 継続的モニタリング・フィードバック 31
32. 設計の論点・工夫 保護の難しさを受け入れる • 壊れたことに気づけるようにする → 継続的モニタリング・フィードバック ◦ 人から ◦ システムから 32
33. 設計の論点・工夫 フィードバックを得る • ユーザーによる採点 33
34. 設計の論点・工夫 フィードバックを得る • ユーザーによる採点 ◦ ウェルカムを示す。 ◦ お礼する。返事する。 ◦ フィードバックをシステムに反映する。 34
35. 設計の論点・工夫 35 し続ける。
36. 設計の論点・工夫 フィードバックを得る • ユーザーによる採点 ◦ ウェルカムを示す。 ◦ お礼する。返事する。 ◦ フィードバックをシステムに反映する。 ⇨フィードバックする意味があることを実感してもらう 36
37. 設計の論点・工夫 フィードバックを得る • ユーザーによる採点 • 自身もユーザーとなる 37
38. 設計の論点・工夫 フィードバックを得る • ユーザーによる採点 • 自身もユーザーとなる • （Langfuse etc.） • エラーをユーザーないしエンジニアに伝える 38
39. 設計の論点・工夫 フィードバックを得る • ユーザーによる採点 • 自身もユーザーとなる • （Langfuse etc.） • エラーをユーザーないしエンジニアに伝える • LLMの判断根拠を出力させる 39
40. 設計の論点・工夫 保護の難しさを受け入れる • 壊れたことに気づけるようにする → 継続的モニタリング・フィードバック • すぐに戻せるようにする 40
41. 設計の論点・工夫 ここまでのまとめ • デグレ（退行）から如何に保護するか？ • 保護の難しさを受け入れる ◦ 欠陥に気づけるようにする（ためにフィードバックを得る） ◦ すぐに戻せるようにする 41
42. 設計の論点・工夫 LLMに苦手なことをさせない 42
43. 設計の論点・工夫 LLMに苦手なことをさせない • 算数？ • 禁止事項を遵守すること？ • （雑な？）マルチタスク？ • ルールの再構築？ 他なにかある？ 43
44. 設計の論点・工夫 LLMに苦手なことをさせない • 算数 → 算数させない。抽出に専念させる。 • 禁止事項を遵守すること → 伝え方を工夫する（ガードレール etc.）。 • （雑な？）マルチタスク → 構造化する。順序立てる。 • ルールの再構築 → Human in the Loop。フィードバック。 44
45. 設計の論点・工夫 45 色々工夫したとて 本質的に 非決定性は扱いが難しい
46. 設計の論点・工夫 非決定性を極力薄くする 46
47. 設計の論点・工夫 47 非決定性を極力薄くする
48. 設計の論点・工夫 48 その処理、本当に LLMで実装する必要ある？ 自問する
49. 設計の論点・工夫 例えば、表を読み取りテストの平均点を求めたいとする。 49 名前 点数 かーず 1000 えしでぃし 90 わむう 120 さんたな 5
50. 設計の論点・工夫 ？？？「pdfから表を読み取り平均点を算出してください！」 50
51. 設計の論点・工夫 51 その処理、本当に LLMで実装する必要ある？
52. 設計の論点・工夫 ？？？「pdfから表を読み取り平均点を算出してください！」 52
53. 設計の論点・工夫 ？？？「pdfから表を抽出してください」 53
54. 設計の論点・工夫 処理を分解する 1. 表を抽出する 2. 合計する 3. 割る 54
55. 設計の論点・工夫 処理を分解する 1. 表を抽出する 2. 合計する ← 決定論的に導出できる 3. 割る ← 決定論的に導出できる 55
56. 設計の論点・工夫 非決定性を極力薄くすることはコストや処理速度にも効く 56
57. 設計の論点・工夫 非決定性を極力薄くするためにキャッシュも有効 • コンテクストのキャッシュ • 処理結果のキャッシュ（開発用途） 57
58. 設計の論点・工夫 レビューでは • （コードの評価が難しいので）想定する入力と実行結果で評価する • その処理、本当にLLMで実装する必要ある？を問う • プロンプトのグッド・バッドプラクティスと照らし合わせる • あとはnon-LLM開発と類似かも 58
59. 設計の論点・工夫 プロンプトのグッド・バッドプラクティス • 体系化されたプラクティスを参考にする 59
60. 設計の論点・工夫 模索中のプロンプトのグッド・バッドプラクティス • 具体と抽象のバランスをとる • 個別化ではなく汎化を目指す ⇨外形的にはif文が増えるような書き方を避けることを目安に • （認識している範囲の）入力全体に普遍的な構造を捉えたい 60
61. 設計の論点・工夫 模索中のプロンプトのグッド・バッドプラクティス • 具体と抽象のバランスをとる • 個別化ではなく汎化を目指す ⇨外形的にはif文が増えるような書き方を避けることを目安に • （認識している範囲の）入力全体に普遍的な構造を捉えたい • ベクトル会話ビリティを高める ◦ ベクトルの差を際立たせる、指示精度を高める 61
62. 設計の論点・工夫 まとめ • デグレ（退行）からの保護 • 継続的モニタリング・フィードバック • LLMに苦手なことをさせない • 非決定性を薄くする • レビューの観点 62
63. ソフトスキルの重要性 63
64. ソフトスキルの重要性 ソフトスキル成分強めじゃないですか？ 64
65. ソフトスキルの重要性 • ドメインにディープダイブする • 構造化、言語化する 65
66. ソフトスキルの重要性 • ドメインにディープダイブする • 構造化、言語化する → LLMとの対話は人とのそれに似てる 66
67. ソフトスキルの重要性 ドメインにディープダイブする • カウンターパートとのコミュニケーション • 意思疎通 • 協力体制 • 業務理解 • 課題理解 • etc. 67
68. ソフトスキルの重要性 構造化、言語化する → LLMとの対話は人とのそれに似てる • 伝え方を追求する ◦ 相手に伝わりやすい構造や順序を模索する ◦ 説明しづらいことには例を示す ◦ 日本語の持つ曖昧さを自覚する？英語的な発想に近づける？ ◦ ローコンテクストを目指す • 解析対象の特徴、構造を捉えてプロンプトに落とし込む • 非決定性の制約を織り込みつつ最終的なアウトプットが満足の閾値を超えるようにやりくりする 68
69. おまけ 69
70. 開発Tips • 待ちが発生しがちなので、並列処理できるタスクや読み物をストックしておく • LLMのことはLLMに聞く • 観察した現象に対して原理の裏付けを取る • 責務を分ける vs 1つのリクエストに詰め込む 70
71. スマートラウンドでは新しいメンバーを募集中です 私たちと一緒に、スタートアップが可能性を最大限に発揮できる世界をつくりませんか？
72. ご清聴ありがとうございました