空論ジェネリックプロセス～テスト資産とAIで紡ぐ、再現可能なパフォーマンスチューニングの話～

JAWS-UG KYUSHU QUEST 2026 in Fukuoka
サポーターセッション登壇
https://jawsug-fukuoka.connpass.com/event/403616/

Transcript

1. 空論ジェネリックプロセス ～テスト資産とAIで紡ぐ、 再現可能なパフォーマンスチューニングの話～ @tosite / 手島 尚人 2026年9月26日（土） JAWS-UG KYUSHU QUEST 2026 in Fukuoka マネーフォワード 福岡開発拠点
2. はじめまして
3. はじめまして 株式会社マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループ リーダー 兼 エンジニアリング戦略室 エンジニアエンゲージメントグループ Fukuoka TechPR（技術広報） 手島 尚人 ／ tosite
4. はじめまして 趣味 キャンプ・登山・旅行・ ドライブ・車中泊・料理・ サウナ・温泉・かっちゃん
5. はじめまして 趣味 キャンプ・登山・旅行・ ドライブ・車中泊・料理・ サウナ・温泉・かっちゃん
6. はじめまして 趣味 キャンプ・登山・旅行・ ドライブ・車中泊・料理・ サウナ・温泉・かっちゃん
7. はじめまして 副業でダイニングバーの 趣味 キャンプ・登山・旅行・ シェフ的なことも ドライブ・車中泊・料理・ サウナ・温泉・かっちゃん やったりしています
8. はじめまして 趣味 キャンプ・登山・旅行・ ドライブ・車中泊 ・料理・ サウナ・温泉・かっちゃん
9. ここ最近の出来事 シルバーウィーク〜車中泊旅〜 9/18 9/19 9/20 福岡→山口→広島 広島→岡山→香川 香川→徳島→兵庫 →岡山→広島 9/21 9/22 9/23 広島→愛媛 愛媛→高知 高知→愛媛→大分 →福岡
10. ここ最近の出来事 シルバーウィーク編 9/18 9/19 9/20 福岡→山口→広島 広島→岡山→香川 香川→徳島→兵庫 →岡山→広島 9/21 9/22 9/23 広島→愛媛 愛媛→高知 高知→愛媛→大分 →福岡
11. ここ最近の出来事 金曜日に福岡を出発し尾道手前で車中泊。翌朝は尾道ラーメンと千光寺観光を シルバーウィーク編 経て、倉敷で絶品の生桃ジュースを堪能し香川へ。うどんと一本鶏を味わい 友人のライブへ。2日目は友人夫妻と朝うどんやカフェ「茶恋路」を楽しみ、 9/18 9/19 9/20 淡路島で堀井雄二生家巡り、絶品淡路牛バーガー、ニジゲンノモリの シン・ゴジラを満喫。明石でたこめしと穴子を食べ、岡山経由で広島に戻り 香川→徳島→兵庫 福岡→山口→広島 広島→岡山→香川 友人と解散。3日目は尾道ラーメン再訪後、愛媛へ。道後温泉、行きつけの →岡山→広島 焼き物屋、別の天然温泉と居酒屋を楽しみつつ、洗濯中にインシデント対応を こなす。4日目は四国カルストや昭和のドライブインを経て、混雑する仁淀川 にこ淵へ。夜は土佐あかうしの焼肉と高知の商店街を堪能。最終日はカツオの 9/21 9/22 9/23 たたき3店を食べ比べ後、四万十町方面で苦労の末に栗をゲット。海洋堂 高知→愛媛→大分 ホビー館と閉館間際の水族館を爆速で観覧し、CoCo壱を食べてフェリーで 広島→愛媛 愛媛→高知 →福岡 大分へ。睡魔と闘いながらも福岡へと無事帰還した。
12. はじめまして 趣味 キャンプ・登山・旅行・ ドライブ・車中泊・料理・ サウナ・温泉・かっちゃん
13. What is かっちゃん？
14. はじめまして
15. はじめまして 洞窟探検家・写真家 クレイジージャーニー 出演歴あり
16. はじめまして 何気なく見始めた YouTubeの動画で ドハマりしてしまい ファンに♡
18. かっちゃんに会いたすぎて 自分でイベント 企画しちゃいました♡
19. 推しに会いに行くのはもう古い！ これが次世代の推し活や！
20. 興味ある方は11/28に お待ちしています
21. 閑話休題
22. はじめまして 株式会社マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループ リーダー 兼 エンジニアリング戦略室 エンジニアエンゲージメントグループ Fukuoka TechPR（技術広報） 手島 尚人 ／ tosite
23. はじめまして 株式会社マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループ リーダー 兼 エンジニアリング戦略室 エンジニアエンゲージメントグループ Fukuoka TechPR（技術広報） 手島 尚人 ／ tosite
24. って何？
25. 端的に言うと 保守運用エンジニア 今風に言うとCREです
26. Guardianグループって何？ 攻めと守りの運用の定義 🛡守りの運用 問い合わせ・インシデント対応などの 「当たり前品質」を守るための対応 ⚔攻めの運用 運用改善やプロダクトの価値向上に つながる、将来お客様や運用を楽に するための改善 最高速で守りの運用を対応し 空いた時間で機能改善を行う！ NEXT CREへ 横断組織化？ ・CREとして「正しく守る」ためには SREのマインドが必要だと気づく ・事前検知を強化して先回りして 対応したい ・そのための検知する体制を攻めの 運用で構築していきたい ・CSと連携して顧客要望を収集、 PdMと連携して改善策を議論する ・QAと連携してテスト自動化などの 品質を高める活動を推進する ・SREと連携してSWEの観点から アプリケーションの監視を行う ・開発者のコストを下げるべく CI/CDの整備を行う etc... 「守って攻める」から 「守りながら攻める」へ！ 改善と予防を広げていく 組織へと進化中！
27. Guardianグループって何？ 攻めと守りの運用の定義 🛡守りの運用 問い合わせ・インシデント対応などの 「当たり前品質」を守るための対応 ⚔攻めの運用 運用改善やプロダクトの価値向上に つながる、将来お客様や運用を楽に するための改善 最高速で守りの運用を対応し 空いた時間で機能改善を行う！ NEXT CREへ Guardianとして生まれ変わっ た俺は攻めと守りの運用で無 双する 〜守りの天才が考え る、攻めの運用術〜で登壇し ・CREとして「正しく守る」ためには ました！ SREのマインドが必要だと気づく ・事前検知を強化して先回りして 対応したい ・そのための検知する体制を攻めの 運用で構築していきたい 「守って攻める」から 「守りながら攻める」へ！ 横断組織化？ ・CSと連携して顧客要望を収集、 PdMと連携して改善策を議論する ・QAと連携してテスト自動化などの 品質を高める活動を推進する ・SREと連携してSWEの観点から アプリケーションの監視を行う ・開発者のコストを下げるべく CI/CDの整備を行う etc... 改善と予防を広げていく 組織へと進化中！
28. Guardianグループって何？ 攻めと守りの運用の定義 🛡守りの運用 問い合わせ・インシデント対応などの 「当たり前品質」を守るための対応 ⚔攻めの運用 運用改善やプロダクトの価値向上に つながる、将来お客様や運用を楽に するための改善 最高速で守りの運用を対応し 空いた時間で機能改善を行う！ NEXT CREへ ・CREとして「正しく守る」ためには SREのマインドが必要だと気づく ・事前検知を強化して先回りして 対応したい ・そのための検知する体制を攻めの 運用で構築していきたい 「守って攻める」から 「守りながら攻める」へ！ 横断組織化？ SREは誰のもの？運用エンジ ニアが始める 「SRE領域への 越境」とチームの進化の軌跡 〜Road to NEXT CREで登壇 ・CSと連携して顧客要望を収集、 PdMと連携して改善策を議論する しました！ ・QAと連携してテスト自動化などの 品質を高める活動を推進する ・SREと連携してSWEの観点から アプリケーションの監視を行う ・開発者のコストを下げるべく CI/CDの整備を行う etc... 改善と予防を広げていく 組織へと進化中！
29. 閑話休題
30. 九龍ジェネリック ロマンス お好きなんですか？
31. はい
32. いい作品なので みんなも読んでね
33. いい作品なので ブログ書きました みんなも読んでね
34. 序：空論 パフォーマンス 改善における課題
35. 皆さんは パフォーマンス チューニングは お好きですか？
36. では、 チューニングに 自信はありますか？
37. 僕はありません・・・
38. 序：空論 パフォーマンス改善における課題 パフォーマンスチューニングを行う動機は様々ですが 基本的にはUXの向上やモニタリングツールを眺めることで 改善を行うことが多いと思います
39. 序：空論 パフォーマンス改善における課題 「何を」改善すればいいかは大体わかる
40. 序：空論 パフォーマンス改善における課題 でも、どうすれば「安全に」 改善できるかはわからない
41. 序：空論 パフォーマンス改善における課題 どんな影響があるのか 何をどう見れば「改善された」と言えるのか 瞬時に判断できる人は少ないと思います
42. 序：空論 パフォーマンス改善における課題 あるいは他人のパフォーマンスチューニングの プルリクエストをレビューすることに 苦手意識がある方もいるのではないでしょうか
43. わたしです＾ｑ＾
44. パフォーマンス劣化が 起きたとしたら誰が 責任取るんだ？
45. CREのワイやんけ！
46. これは困った・・・
47. 序：空論 パフォーマンス改善における課題 それを防ぐためには計測が大事です 改善したとしても無計測で デプロイするわけにはいかないので 計測をする必要があります
48. 序：空論 パフォーマンス改善における課題 測定するにも大量のデータが必要です ローカルで分析するにも相応のデータ量が必要なので そのことがパフォーマンスチューニングの 妨げとなる場合もあります
49. 序：空論 パフォーマンス改善における課題 その結果、パフォーマンスチューニングは属人化が進み 選ばれしものだけの作業になりがち・・・
50. 序：空論 パフォーマンス改善における課題 「推測するな、計測せよ」という言葉があるが ついついパフォーマンスチューニングのレビューについては 経験に基づいた推測に頼りがちになってしまう
51. 全ては机上の空論
52. どげんか せんといかん！
53. 序：空論 パフォーマンス改善における課題 自分なりに課題を整理してみたところ 以下のようになりました
54. 序：空論 パフォーマンス改善における課題 リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 分析の属人化 パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい
55. 序：空論 パフォーマンス改善における課題 リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
56. いい感じに測定できて それを分析できて 本番影響が想像 できればいいのに・・・
57. 破：ジェネリックプロセス
58. 破：ジェネリックプロセス リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 ここに対する アプローチについて パフォーマンス分析に 考えてみる 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
59. 破：ジェネリックプロセス 実は分析に必要なデータを 低コストで準備する方法を すでに私たちは手に入れています
60. 破：ジェネリックプロセス それは「テストコード」です
61. 破：ジェネリックプロセス クラウド経費は大規模な Railsアプリケーションなので RSpecを介することで大量のデータを 作成することができます
62. 破：ジェネリックプロセス 大量のテストデータを作成するための 教師データはすでにFactoryや テストコードとして存在しています
63. 破：ジェネリックプロセス 以降、このテストデータのことを便宜上 「ベンチマークSpec」と呼びます
64. 破：ジェネリックプロセス ベンチマークSpecをAIに 書かせることができれば 分析に必要な準備コストは ほぼゼロにすることができます
65. 破：ジェネリックプロセス そして、このベンチマークSpecは エンドツーエンドに近ければ近いほど 実測値に近いログデータを集めることができます
66. 破：ジェネリックプロセス なぜなら、Railsのアプリケーションは before_actionなどの処理がパフォーマンスに 影響を与えることもあるからです
67. 破：ジェネリックプロセス そこでまず、次のようなプロンプトを作成しました
68. 破：ジェネリックプロセス PRの変更内容を分析してベンチマーク対象や データ量を確認し、その結果を元に 実行・検証可能なベンチマークSpecを生成する
69. 破：ジェネリックプロセス PRの変更内容を分析してベンチマーク対象や データ量を確認し、その結果を元に 実行・検証可能なベンチマークSpecを生成する
70. 破：ジェネリックプロセス ちなみに事前に実行時にログを取得するための ヘルパーメソッドを作成しておいて ベンチマークSpec内に組み込むようにしています
71. 破：ジェネリックプロセス
72. 破：ジェネリックプロセス 大量のデータを作成する このブロックで囲われた 部分のパフォーマンスを 計測できる
73. 破：ジェネリックプロセス リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
74. 破：ジェネリックプロセス リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
75. 破：ジェネリックプロセス リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 これで課題 「測定準備コスト」に ついてはクリアできました パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
76. 破：ジェネリックプロセス リリース後に問題が発覚 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 測定コストが高い 次はここに対する アプローチについて パフォーマンス検証のための 考えてみる 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
77. 破：ジェネリックプロセス の前に計測データの集計から
78. 破：ジェネリックプロセス 集計するメトリクスは 「クエリログ」 「メモリ使用量ログ」 「EXPLAINログ」 の3つにしました
79. 破：ジェネリックプロセス 先ほど作成した ベンチマークSpecを 変更前・後それぞれの ブランチで実行する PRの変更内容を分析してベンチマーク対象や データ量を確認し、その結果を元に 実行・検証可能なベンチマークSpecを生成する
80. 破：ジェネリックプロセス 出力されるログは以下の通り
81. 破：ジェネリックプロセス クエリログ ActiveRecord実行時のSQLを全てキャプチャする バインド変数やキャッシュ情報も記録している
82. 破：ジェネリックプロセス クエリログ 主にDBへのリクエスト回数や実行時間を集計する N+1やスロークエリを特定できる
83. 破：ジェネリックプロセス
84. 破：ジェネリックプロセス メモリ使用量ログ 実行時間やメモリ使用量の測定を行う 割り当てられたオブジェクト数・ 解放されたオブジェクト数なども計測可能
85. 破：ジェネリックプロセス メモリ使用量ログ リソースの浪費を監視することができる 大量データの読み込みなど、OOMの予兆なども検知することが可能
86. 破：ジェネリックプロセス
87. 破：ジェネリックプロセス EXPLAINログ 実際に発行されるSQLからEXPLAINログを取得する 実行計画が効率的かを評価することができる
88. 破：ジェネリックプロセス EXPLAINログ インデックスが正しく利用されているかを特定可能 その他、フルテーブルスキャンが 発生していないかも特定できる
89. 破：ジェネリックプロセス
90. テスト環境を本番環境の ジェネリックとして使用する ことで簡単に計測が行える ようになりました
91. 破：ジェネリックプロセス データが揃ったのでいよいよ分析です
92. 破：ジェネリックプロセス 出力したログをベースに 分析とレポートの作成を 行う PRの変更内容を分析してベンチマーク対象や データ量を確認し、その結果を元に 実行・検証可能なベンチマークSpecを生成する
93. 破：ジェネリックプロセス 出力イメージ
94. 破：ジェネリックプロセス
95. 破：ジェネリックプロセス 実行時間 メモリ使用量 クエリ数 といった主要メトリクスの 前後対比を出してくれる
96. 破：ジェネリックプロセス データに基づいた分析を 行ってくれるので誰でも レビューしやすい！
97. 破：ジェネリックプロセス リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
98. 破：ジェネリックプロセス リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析の属人化を排除しつつ 低コストで事前にリスクを 洗い出すことができた 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
99. 破：ジェネリックプロセス リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
100. 破：ジェネリックプロセス リリース後に問題が発覚 測定コストが高い 修正後のパフォーマンス劣化を レビュー段階で検知できない という課題 パフォーマンス検証のための 事前準備に時間がかかる という課題 特にメモリ使用率やパフォーマンスの 変化を定量的に測定できない レビュアーがコードを見ただけでは パフォーマンス影響を測定しづらい 状況によっては本番でないと 測定できないこともある 測定手順に再現性がないことも 事前に分析できない ことが原因 分析の準備にコストが かかることが原因 分析の属人化 その結果、リリース後に 起きうる問題を事前に 検知できるようになった！ パフォーマンス分析に 高度な知識が必要で 属人化するという課題 分析作業そのものが担当者の スキルに依存する 分析プロセスやフォーマット、 ナレッジが標準化されておらず 見落としが発生しやすい そもそも分析が 難しいことが原因
101. 空論を計測によって 排除することで ジェネリックなプロセスで あっても本番とほぼ同じ 分析を行うことが可能に！
102. 急：テストコードに ついてつらつらと
103. 急：テストコードについてつらつらと 定量データを用いて分析できるようになったことで 知識量に依存することなく一定の品質で 事前にレビューすることができるようになりました
104. 急：テストコードについてつらつらと それだけでなく、事実に基づいた分析を標準化することが できるようになったため、今まで気づけなかったような 懸念にも気づくことができるようになりました
105. 急：テストコードについてつらつらと このAI時代において、テストコードとは ただ品質を担保するためのものだけでは なくなってきているように思います
106. 急：テストコードについてつらつらと 今回のようにテストケースを パフォーマンス分析に使えば 低コストで諸々の分析が行なえます
107. 急：テストコードについてつらつらと CREらしく、問い合わせや調査の仮説検証を 行うためにテストファーストで AIにテストコードを書かせて 検証や修正に使うこともできるでしょう
108. 急：テストコードについてつらつらと 一例ですが ①ある機能で問い合わせが発生する ②条件をまとめてAIに再現テストを書かせる ③テストで確認ができたら通るように修正 ④リリース みたいなことができると思っています
109. 急：テストコードについてつらつらと 現に、とある問い合わせに対してこの方法を用いて 2時間程度で特定〜修正まで終わらせることができました
110. 急：テストコードについてつらつらと テストコードはAIと相性がよすぎるので 今後活用されるシーンが多くなっていくんじゃ ないかなあと勝手に思っております
111. 急：テストコードについてつらつらと 低コストで色んなことが試せるので 皆さんもぜひテストコードを インターフェースとして 様々な取り組みに使ってみては？
112. 急：テストコードについてつらつらと 逆に「こういう使い方あるよ！」というアイデアを お持ちの方がいれば教えてください！
113. 急：テストコードについてつらつらと あらゆるものを用いて 信頼性を高めていくための活動を 今後とも続けていければと思っております
114. ご清聴 ありがとう ございました