バランスって大事だね

Transcript

1. バランスって大事だね 株式会社スリーシェイク Sreake事業部 赤川 大空 Copyright © 3-shake, Inc. All Rights Reserved.
2. 自己紹介 - 赤川大空（Akasan） - 株式会社スリーシェイク Sreake事業部 アプリチームの中で、特にML領域を担当 - - MLOpsの構築支援や生成AIアプリケーションの実装 - NVIDIA Inceptionパートナーとしての活動のリード 最近の興味 - MLOps - ML/AI - クラウド（Google Cloudを中心） 2
3. アジェンダ 1. 業務での生成AIの利用状況 2. 減らすことができた業務 3. 逆に増えてしまった業務 4. 増えては減って、減っては増えて 5. 量 vs 質 3
4. 01 業務での生成AIの利用状況 Copyright © 3-shake, Inc. All Rights Reserved. 4
5. 私のAIの使い方 業務では主に以下の使い方をしてます • プログラムの実装：アプリケーションの実装からIaCまで • 技術調査：新しい記述だったり公式ドキュメントの調査まで • ドキュメント作成：新しい実装に対するものや設計など • 壁打ち：考え事をしたいときに壁打ち相手になってもらう • ブログレビュー：ブログの内容の一次レビュー • カレンダー調整：対象メンバーが多い時の予定のアレンジ 5
6. AIに任せてないこと 以下の点については、基本的にAIに任せず自分で対応してます ※ 基本的に手動でやっているだけで、サポートなどはAIにしてもらってます！ • スライドの作成：自分で書かないと頭の中の整理ができない • 要件定義・仕様検討：一部任せていはいるが、手戻りが大きくなるリスクがある • 勉強のアウトプット：アウトプットを自分でやらないと身につかない 6
7. AIに任せるために取り組んでいること AIに活動を委任するための仕組みづくりを紹介します！ よく使っているのは Slackに投稿されたことをZapierが検知し、 連携先のGitHubに投稿するという仕組みです https://akasan-ml.tech/blog/connect_slack_github 7
8. Zapier連携で実現していること！ Zapierとの連携では以下をできるようにしています • 投稿されたURLについて調査しイシューにまとめる • 投稿された技術用語について 学習するためのコンテンツをMarkdownで生成する 調査しイシューにまとめる 8
9. 02 減らすことができた業務 Copyright © 3-shake, Inc. All Rights Reserved. 9
10. 業務時間改善できたこと 以下の内容は準備を含め工数が逆にかかっていると感じます • プログラムの実装：ちゃんと仕様を明確にしておけばかなり早い • 技術調査・学習 手動で調べるより圧倒的にはやい 個別のニーズにあった学習コンテンツも作れる • 壁打ち：AIと最初に壁打ちしておくことで対「人」との壁打ちの時間が減っている • ロードマップの策定：今後のアクションを検討・提案してもらう • ブログレビュー：ブログの正誤やタイポチェックなどがかなり爆速になっている • カレンダー調整：メンバーの予定が空いてるところを爆速で見つけられる • 議事録：議事録を書くことではなく議論に集中できる • ドキュメント作成：常に新しい情報で更新し続けてくれる 10
11. どうやって達成した？ それぞれ以下のようにして実現しています • プログラムの実装：cursor等のIDEで利用できるAgentを主に利用 • 技術調査・学習：Deep Researchやエージェントを用いたコンテンツの作成 • 壁打ち：claudeやGemini、gptなどとCLIやWebUIを通してやりとり • ロードマップの策定：壁打ちと同じく、AIと単純なやり取りで事足りている • ブログレビュー：原稿をclaude等に確認してもらっている • カレンダー調整：GeminiでGoogle Calenderとの連携を用いて実現 • 議事録：TeamsやGoogle Meetなどのデフォルト機能で実現 • ドキュメント作成：プログラムの実装をするときに合わせてしてもらうことが多い 11
12. 03 逆に増えてしまった業務 Copyright © 3-shake, Inc. All Rights Reserved. 12
13. 業務時間改善できていないこと 業務を進める上で、以下のような状況が発生すると改めてフローを見直して 状況改善が必要だなと感じています・・・ • ドキュメントの陳腐化 大量にAIがドキュメントを作るようになっており、陳腐化が激しい どれが古いドキュメントか判断するだけでもかなりの時間がかかる • レビュー依頼の増加 AIの生成物が冗長な場合も結構あり、それをレビューするのが結構大変 時間を切り分けてみるようにしないとコンテキストスイッチが大量発生 • 生成AIありきのフローになっていて使えなくなったときに止まってしまう レートリミットなどで使えなくなったときに仕組みが破綻する 利用できるモデルに制限がある環境ではかなりのボトルネックに・・・ 13
14. 04 増えては減って、減っては増えて Copyright © 3-shake, Inc. All Rights Reserved. 14
15. 改善時のトレードオフ 多くの活動においてメリットだけということは少ないと思うので、 バランスを考えて調整する必要があります 減らせること 増えてしまうもの 自動でドキュメントを更新 実装と照らし合わせながら ドキュメント を書く負担が軽減される もはや最新の情報ではない古い情 報を含んだ大量のドキュメント の アーカイブ対応 議事録を自動生成させる 話に徹することができ 、議事録を書く という作業に気を削がれない 間違った内容の記録による認識齟 齬の発生など 一部の性能が高いモデルに依存 関係者間で成果物の一貫性が取り やすく、仕組み化しやすい レートリミットに達する、モデルが 廃止されるなどの影響 により活動 が止まってしまう 15
16. 05 量 vs 質 Copyright © 3-shake, Inc. All Rights Reserved. 16
17. 量 VS 質 AI時代に大事なのはAIが生成する成果物の 量と質のバランス だと思います 17
18. 量 VS 質 ~品質大事~ 多量 低品質 業務を増やし かねない 業務改善に 適している 少量 高品質 18 ※ ここでの議論はコーディングを例にしています
19. 量 VS 質 ~各象限について~ 多量 一番避けるべき レビュアーにも負担をかけ るし無駄な利用コストがか かるだけ 一番理想的 レビュアーに負担をかけて でも価値がある 低品質 高品質 できれば避けたいが 活動初期はここで進めるこ とになる 実際の業務で言うと この辺りを目指すのがいい 気がします 少量 19 ※ ここでの議論はコーディングを例にしています
20. 量 VS 質 ~コーディング~ 多量 増：レビュー、 AIコスト 減：レビュアーのモチベ 増：レビュー、 AIコスト 減：手戻り 低品質 高品質 増：高品質を目指すための 改善 減：手戻り 増：より高速な開発を するための改善 減：スピード感 少量 20 ※ ここでの議論はコーディングを例にしています
21. 量 VS 質 ~改善の流れ？~ 多量 仕組みが固まってきて 大量に動作チェック ブラッシュアップした ものを本格運用 低品質 高品質 動作チェック結果を元に 高品質になるよう ブラッシュアップ 仕組みづくりを開始 少量 21
22. 量 VS 質 低品質かつ多量の生成は避けるべき • 低品質なものを量産するために高額のAI使用料が発生する • 低品質なもののレビューは高品質なものと比較して時間がかかりがち • 低品質なものばかりをレビューしているとモチベーションも上がらない • 低品質なものは業務を改善できず手間を増やすだけ • 活動し始めは低品質なものが発生する可能性は 十分あるので、まずは少量から試してみること 効果測定は少量から！ 22
23. 量 VS 質 ⭕低品質少量生産を通して改善 ❌低品質大量生産を通る場合 多量 多量 仕組みが固まってきて 大量に動作チェック スピード感を持って効果検 証したいなら避けたい ブラッシュアップした ものを本格運用 低品質 高品質 動作チェック結果を元に 高品質になるよう ブラッシュアップ 仕組みづくりを開始 少量 ブラッシュアップした ものを本格運用 低品質 高品質 仕組みづくりを開始 小さく段階的に改善してい く 動作チェック結果を元に 高品質になるよう ブラッシュアップ 少量 23
24. まとめ Copyright © 3-shake, Inc. All Rights Reserved. 24
25. まとめ • AIを使って業務改善するときは増えてしまう業務がないか予想してみる 増えてしまうことが「悪」かどうかはケースバイケース 最終的には工数・コストが改善できるようにシフトしていこう！ • 量と質を意識して対応順序を決めましょう 高品質を大量に生み出すのは時間もかかります 低品質なものを大量に生産しないようにだけ気をつけましょう 25