Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AIエージェントを現場で使う / 2025.08.07 著者陣に聞く!現場で活用するためのAI...

AIエージェントを現場で使う / 2025.08.07 著者陣に聞く!現場で活用するためのAIエージェント実践入門(Findyランチセッション)

こちらのイベントでの登壇資料になります。
https://findy.connpass.com/event/363543/

現場で活用するためのAIエージェント実践入門(講談社)
https://www.amazon.co.jp/dp/4065401402

Avatar for Shumpei Miyawaki

Shumpei Miyawaki

August 07, 2025
Tweet

More Decks by Shumpei Miyawaki

Other Decks in Technology

Transcript

  1. 8章 AIエージェントの評価 9章 AIエージェントの活用 10章 各社のAIエージェントの実用化に向けた取り組み     8.1. AIエージェントの評価とは

        8.2. 評価指標     8.3. 評価の準備     8.4. エラー分析     9.1. AIエージェントとUX     9.2. AIエージェントのリスク     9.3. AIエージェントのモニタリング     9.4. AIエージェント運用における継続的な精度改善方法     10.1. プロジェクトの進め方(電通総研)     10.2. AIエージェントの開発(Algomatic)     10.3. AIエージェントと協働するためにはどうしたら良いか
       (ジェネラティブエージェンツ) ‰ˆ 評価する前に行うこと •ˆ 設計段階で考えること 本日は「現場で使う」をテーマに、執筆できなかった部分の話をします! もし本編が気になる方は電子版も公開予定なのでぜひご購入いただけると嬉しいです!
  2. 4 (1/2) AIプロダクトのデザインパターン -『AAAA』モデル ①ユーザとのタッチポイント ②タスクの実行主体 の2軸で考える: ※ ここでの Agent

    ⁨ ⁩ は「AIエージェント」ではなく「代行者」という意図 ‹‚ 高橋氏, AI時代のユーザ体験は「AAAA」モデルで考えよう (2024), https://note.com/dory111111/n/n03eac77e519y €‚ 武舎氏ら, ツールからエージェントへ。弱いAIのデザイン - 人工知能時代のインターフェース設計論 (2018), BNN, https://bnn.co.jp/products/9784802510684 タッチポイントでは、 情報の伝達、軌道修正、 進行の確認が行われる
  3. 5 (2/2) AIプロダクトのデザインパターン - 自動運転レベル iu 国土交通省, 自動運転のレベル分けについて, https://www.mlit.go.jp/common/001226541.pdd wu

    Shimakoshi氏, LayerXにおける業務の完全自動化に向けたAI技術活用事例 (2025), 人工知能学会, https://speakerdeck.com/shimacos/layerx-ai-jsai2025 Lv5. 完全自動化 Lv4. 高度自動化 Lv3. 条件付自動化 Lv2. 部分自動化 Lv1. 支援 システムからの要請時にユーザが介入 システムがより広範なタスク補助を実施 システムが一部のタスク補助を実施 システムによる作業継続が困難な場合にユーザが介入 システムが無制限に全てのタスクを実行 自動運転のレベル分けを「業務代行」に落とし込んで考える
  4. 6 時間・量的ボトルネックが発生するタスクの代行はインパクトが大きい X 任意のトリガT X 24-365 体W X 非同期実V X

    観測・制御可能 X 環境の知覚と作 X 知識拡„ X 行動記x X アルゴリズム実V X パーソナライ‘ X タスク連携 LLM 外部リソース インフラ X 言語運用能‚ X 専門的知識の運 X 高速な文字列生s X 第三者視p X 構造化出‚ X 量質転化 見込み顧客のWebフォーム回答からの時間と連絡成功数の関係 e.g. インサイドセールスでは即レスが連絡成功率に繋がる 5分 10分 15分 20分 25分 30分 35分 40分 45分 50分 24時間365日の監視、魅力ある文章を高速に生成可能な AIエージェントは成果創出のカギとなる AIエージェントが享受するメリット *AIに高い品質が求められる場合もある 返信に時間がかかると 連絡成功率は大幅に下がる ™• L.R.M, The Lead Response Management Study (2007), https://www.leadresponsemanagement.org/lrm_study/ 多くの場合、 は人間、 は AI* にある [「」 業務効率化より、人がさばけない量・対応できない時間での代行はインパクトが大きい 時間・量的ボトルネック 質的ボトルネック
  5. 7 業務のスケールにおいても人間が律速要因となる P… Renieris氏ら, AI Explainability: How to Avoid Rubber-Stamping

    Recommendations (2025),
 https://sloanreview.mit.edu/article/ai-explainability-how-to-avoid-rubber-stamping-recommendations/ t 人間が承認できる数には限界があg t 代行しても別のタスクが増える
 (ジェボンズの逆説) t AIへの信頼によるラバースタンプƒ t 結局属人化してしまう 運用体制の問題 スケールの問題 システム運用と併せて人間の育成も行う 介入が不要な高度自動化のオプション 将来的に 将来的に ユーザによる意思決定やプロンプト設定は、ユーザへの負荷を強いることになる ゆえに ユーザによる介入が発生すると業務のスケールが難しくなる
  6. 8 ユーザ・タスク・データ特性にあわせて適切な手段を選択する 量的施策 質的施策 ビギナー向け プロ向け 達成率 安全性 汎用業務 特定業務

    プロアクティブ リアクティブ Advice, Augment 型 部分・条件付き自動化(~Lv.3) 高度・完全自動化(Lv.4~) 決定論的アプローチ 確率論+決定論の複合アプローチ 自律型エージェント エージェント型ワークフロー タスク依頼型 アンビエント Automation, Agent 型 AIエージェントはあくまで手段であり、必ずしも最適な解決策とはいいきれない [「」 業務が回る、ユーザにとって使いやすい、業務がスケール可能 を満たす別の選択肢も考える
  7. 9 プロダクト開発の前にやるべきこと ŽŠ 安野氏, Lean AI 開発論: コードを書く前に機械学習プロジェクトを評価する方法 (2021), https://note.com/takahiroanno/n/ncb7d77bfd9fo

    DŠ 安宅氏, イシューからはじめよ ―― 知的生産の「シンプルな本質」(2010), 英治出版, https://eijipress.co.jp/products/2356 価値が出る領域の探索のほか、まずは人間が望ましい出力を生成可能であるか判断する バリュー 出力品質 許容品質 ② AIへの入力データを受け取った専門家の出力が 許容品質ラインを超えない場合は諦める 人間の品質 マックスバリューは高いが 出力品質が高くならないと価値が出ない (事業リスクは高い) ① 出力品質が100%でも 価値が出る領域を探索する 価値が出やすい リーンな開発がしやすい
  8. i” Shankar氏, Who Validates the Validators? Aligning LLM-Assisted Evaluation of

    LLM Outputs with Human Preferences (20245 3” 松浦氏, ChatGPTでの業務効率化を“断念” ─ 正答率94%でも「ごみ出し案内」をAIに託せなかったワケ 三豊市と松尾研の半年間 (2023), ITmedia AI+ 評価の値が「参考値」以上の価値を見出せない 正答率を算出しても事業化の可能性に直結しない 11 Ÿ コールドスタート問• Ÿ 評価時と運用時のデータシフトやデータドリフ– Ÿ 基準ドリフ– Ÿ 想定外の悪い出力を見つけると基準を追加したくな© Ÿ 既存の基準を出力から再解釈することがある Ÿ 正答率 94% でも回らない事業もあるÊ Ÿ 正答率 70% でも事業を回す方法はある 短期でみると LLM システムの定量的な性能評価の優先度は高くない 開発初期段階でのシステムの評価はとても難しく、技術不確実性の解消 に結びつきづらい
  9. 12 技術不確実性の解消と仕様定義を行うまで「定量評価」はあと回し 障壁の解体 定性評価・エラー分析 定量評価 正常系・異常系テスト 検証 開発 運用 開発初期では早期のタイミングで

    チームメンバー間で方針をすり合わせ€ d AIによって何ができる’ d 何を苦手とするの’ d 人はどこを補助すべき’ d どうなれば仕様通りである’ d 発生しうるリスクはあるか 技術不確実性の解消、仕様定義が終わってから 評価に取り掛かる
  10. LLM プロジェクトの初期段階では 評価以上に「障壁の解体」にこだわる 13 障壁の解体 - よいプロダクトは「開発者」だけでは作れない {• まずやってみるw ‚•

    カバレッジが低くとも、精度感やリスク・改善方針の共 通認識をチーム全体でもつw s• 早期からチーム間で品質に向き合う体制を醸成する。 プロジェクト初期段階においては「情報の偏在・非対称性」によって 各メンバー間に障壁が発生しやすい [1] 情報の偏在・非対称性 価値ナラティブ 責任ナラティブ テストナラティブ 品質に投資した場合の見返り について語られている 誰が品質・リスクに責任を持つか について語られている 品質向上につながるテスト技法 について語られている {• 鷲崎氏ら, QA to AQ:アジャイル品質パターンによる、伝統的な品質保証からアジャイル品質への変革 (2022), 翔泳社, https://www.shoeisha.co.jp/book/detail/978479817932D ‚• John氏ら, LEADING QUALITY (2023), KADOKAWA, https://www.kadokawa.co.jp/product/302309001510/