AI_Dev_Day_製造業領域でのAI活用から見た活用の罠と成功に導く実践知.pdf

Transcript

1. AI Dev Day 2026 製造業領域でのAI活用から見た、 活用の罠と成功に導く実践知 登壇者 野村 宏樹 所属 KINTOテクノロジーズ株式会社 枠 12:30–12:55（25分） KINTO Technologies
2. 会社紹介と自己紹介
3. 04 / 27 CHAPTER 1 KINTOテクノロジーズ株式会社について（グループ組織） トヨタ自動車株式会社 トヨタファイナンシャルサービス株式会社 海外販売金融会社 トヨタファイナンス 株式会社 世界40以上の国と地域で サービスを展開 販売金融・クレジットカード など KINTOテクノロジーズ 株式会社 株式会社KINTO
4. 04 / 27 CHAPTER 1 KINTOテクノロジーズ株式会社について（グループ組織） 室町オフィス 東京都中央区日本橋室町2-3-1 室町古河三井ビルディング（COREDO Osaka Tech Lab 室町2） 大阪府大阪市北区梅田3丁目1番3号 ノースゲートビルディング 神保町オフィス 東京都千代田区神田錦町3丁目22番地 テラススクエア Fukuoka Tech Lab 福岡県福岡市中央区大名2丁目6-50 福岡大名ガーデンシティ 名古屋オフィス 名古屋市中村区名駅4丁目8番18号 名古屋三井ビルディング北館
5. 04 / 27 CHAPTER 1 · SPEAKER 自己紹介 GROUP AI First TEAM AI Engineering MVP Microsoft MVP for Microsoft Foundry 略歴・バックグラウンド 野村 宏樹 HIROKI NOMURA 前職では、自動車制御設計領域への生成AI活用案件の開発リードを経験。 2025年8月にKINTOテクノロジーズ入社。AIファーストG所属。 KTCでは生成AIアプリエンジニアを従事。 販売店向けAIプロダクト、社内生成AIツール、生成AI研修などを実施 コアスキル / CORE STRENGTHS 技術スタック / TECH STACK 01 生成AIを含むプロダクト開発 Azure（インフラ・アプリ全般） Claude Code / GitHub Copilot Agent Framework / LangChain 02 Azure Infra / PaaS 03 車両開発ドメイン知識
6. 05 / 27 CHAPTER 1 · COMPANY KINTOテクノロジーズについて トヨタグループのエンジニア内製組織 1 モビリティサービスの開発・運用 KINTOをはじめとするモビリティサービスを、自ら開発し運 用する。 2 トヨタグループ各社との協働 AI・クラウド領域で、グループ各社の現場を支援する。 今日の話はこちら側。
7. CHAPTER 1 · OUR APPROACH AI活用の支援内容 06 / 27
8. 前半 AI導入が従来のシステム導入と異なる性質
9. 08 / 27 AIによる業務効率化、価値は出ていますか？ コストだけが上がっていないですか？
10. 08 / 27 CHAPTER 2 · THREE TRAITS AI案件が普通のシステム導入と違う3つの性質 1 2 3 挙動が現場で決まる 非決定性 デモ→本番の崖 設定メニューではなく、その現場のデ ータと業務の癖で挙動が決まる。既 製品の設定では片づかない。 同じ入力でも出力が揺れる。厄介な のは、間違った出力が 一見正しく見 える こと。静かに業務に紛れ込む。 デモは"うまくいく場面"のお膳立て。 本番では想定外の入力・膨らむコスト ・運用の手間・つなぎ込みが一気に来 る。
11. 09 / 27 CHAPTER 2 · PATTERN 01 失敗パターン① 求める価値が人によって違う そもそも何の価値を出すかが、組織で合意されていない。 例：「業務文書の作成を支援するエージェント」 何が起きるか 「書類を自動で生成してくれるんですよね」 LLMは柔軟すぎて「何でもできそう」に見える 人ごとに違う期待を背負い込む 期待値とズレた瞬間、 使われなくなる 「多角的にレビューしてくれるんですよね」
12. 10 / 27 CHAPTER 2 · PATTERN 02 失敗パターン② 業務を変えずに、AIだけを乗せる 業務の設計を変えていないから、組織の数字が変わらない。 既存のフロー・帳票・承認手順（そのまま） 何が起きるか 「AIを入れたのに、楽にならない」 個人がAIを使う分には速くなった気がする その上にAIを乗せる 出力を人が全部チェック ＝ 二重作業 業務全体のリードタイムは1日も縮まらない
13. 11 / 27 CHAPTER 2 · PATTERN 03 失敗パターン③ 重厚なAI基盤から作り始める 価値が出る前に、一番大きなコストを払ってしまう。 「全社で使うから、まず立派な共通基盤を」 何が起きるか 出来上がる頃、業務側はまだ使い道を見つけていない 現場の使い勝手と異なる基盤は敬遠される 現場は勝手に別の道具を使い始める 管理外のエージェントが乱立、ガバナンスが効かない
14. 「AIを作る」から「業務を動かす」へ
15. 13 / 27 CHAPTER 3 · REFRAME 発想の転換 —「AIを作る」から「業務を動かすシステムの設計」へ 企業が欲しいのは業務の自動化。AIエージェントは、その部品の1つにすぎない。 賢いチャットを作る → 業務を動かすシステムを設計する モデルの精度を追いかける → 責任の分界と成功の基準を定義する → 改善のループで育てていく PoCで精度を判定して終わり ＝ループエンジニアリング
16. 14 / 27 CHAPTER 3 · THE MAP 進め方の地図 — 4つの問い × 七つ道具 自動で回す層（ハーネス／Harness） — 道具のループを、エージェント自身に回させる プロンプト・ツール・コンテキスト方針・評価・回復経路——モデルの周りに巻き付けるこの一式が"ハーネス"。 普通のモデル×良いハーネスは、最強のモデル×悪いハーネスに勝つ Q1 Q2 Q3 Q4 本当に やるべきか 何を 作るか どう 作るか どう改善し 続けるか AsIs＆ToBe業務フロー 人とAIの協働設計 判断シート PRD AIとツールの分担設計 評価セット 資産化・横展開
17. 20 / 27 CHAPTER 3 · IN PRACTICE AT KTC 実践例 KTCが実践しているAIエージェント導入時のノウハウ 01 02 03 業務フロー 可視化AI ナレッジ 継続運用 AIエージェント 評価 現場の業務をヒアリングしてフロー図に 起こす作業をSkill化。第1章の「業務フロ ーの整理」はこれで回る。 渡す情報は作って終わりだと腐る。レビ ューで見えた「情報不足」をナレッジに反 映し、仕組みループの入力源にする。 正しさだけでなく、途中でどのツールを どう使ったかという「ふるまい」を評価し 、Skillの改善につなげる。
18. CHAPTER 3 · LOOP ENGINEERING それぞれに共通するループエンジニアリング 品質を上げる × 仕組み改善のループ＝学びを蓄積し、エージェントへの委任を広げる 19 / 27
19. CHAPTER 3 · IN PRACTICE AT KTC 業務フロー 可視化AI AIと人との協働のために、AIエージェントを含めた業務フローを設計すべき 業務設計に AIエージェントも含める 20 / 27
20. 20 / 27 1 2 3 挙動が現場で決まる 非決定性 デモ→本番の崖 設定メニューではなく、その現場のデ ータと業務の癖で挙動が決まる。既 製品の設定では片づかない。 同じ入力でも出力が揺れる。厄介な のは、間違った出力が 一見正しく見 える こと。静かに業務に紛れ込む。 デモは"うまくいく場面"のお膳立て。 本番では想定外の入力・膨らむコスト ・運用の手間・つなぎ込みが一気に来 る。 作って終わりではなく、 現場で使い続けられるような 業務フローとAIの仕組みを用意しましょう。
21. 20 / 27 興味を持っていただいた方、 ぜひKINTOテクノロジーズの ブースにお立ち寄りください！ 紹介しきれなかった事例やAI活 用ツールを展示しております。
22. 後半 どの基盤で作るか — Microsoft版 エージェント開発サービスの使い分け
23. 22 / 27 CHAPTER 4 · WHO BUILDS IT どれを使う？ ― 「誰が作るか」で決まる どれが一番すごいか、では決まらない。作る人で決まる。 非開発者（業務部門） ノーコード M365 Copilot エージェントビルダー 開発者 プロコード Microsoft Foundry ＋ Azure Functions ローコード Copilot Studio 社内ナレッジに答えるQ&Aを、使う本人 複数ステップの業務フロー・基幹連携・部 がその場で作る。 門/全社展開。 開発者がフルに作り込む世界。 モデルを選び、オーケストレーションを設 自分や小さいチームで使うならこれで十 環境分離・接続統制・権限管理など、組織 計し、ワークロードごとに実行基盤を選 分。 運用のガバナンスが揃う。 ぶ。
24. 23 / 27 CHAPTER 4 · FOR DEVELOPERS 開発者が作るなら ― FoundryとFunctionsに揃っているもの Microsoft Foundry Azure Functions マネージドのエージェント基盤 サーバーレスのエージェント実行基盤 ・ Hosted Agent ― エージェントをマネージドでホスト。サー バー運用なしで本番に置ける ・ エージェント評価 ― 評価・トレース・監視が同じ場所に揃う。 評価の仕組みを自前で組まずに始められる ・ モデルが選べる ― GPT系もClaude系も同じ場所で使える ・ Durable Agent ― 会話状態を永続化。承認待ちで何日も 止まる長時間ワークフローが組める ・ イベント駆動 ― キュー・スケジュールをきっかけに動く ・ スケールゼロ ― 使わないときは課金も止まる。動いた分だ け払う
25. CHAPTER 4 · REAL EXAMPLE 実例（個人開発） ― 新規アイデア企画サポート 課題 AIで「作る」は速く安くなった。次に詰まるのは「何を作るか」を決める段階 ― 発想・調査・部門をまたぐレビューが人に依存して遅い。過去案件の知見も残らず、毎回ゼロから。 考え方 新規事業検討の組織図を、そのままAIと人に割り当てる。 調査・分析はAIエージェント（リーダー1＋専門調査4＋独立採点1）、方針と最終判断は人（企画・知財・法務・経営の4か所）。 何がうれしいか • 発想が毎日届く ― AIが事業のタネを外部情報から拾ってくる • 検討が並列で速い ― 4領域を同時調査、独立採点で客観評価 • 人は要所だけ ― 判断4か所。14日待ってもコストほぼゼロ • 組織が学習する ― 案件の知見が蓄積され、次回が賢くなる
26. CHAPTER 4 · REAL EXAMPLE 実例（個人開発） ― 新規アイデア企画サポート エージェントは Foundry Hosted Agent • 市場・競合・知財・社内資産の4調査エージェント＋独立採点 役をマネージドでホスト • 採点役は別モデル・別スレッドで分離 ― 自己採点させない • 評価・トレースはFoundryで確認 ― ふるまいが追える ワークフローとHITLは Durable Functions • 「調査→採点→人のレビュー→統合→決裁」の流れを Durableオーケストレーションで定義 • 人の判断を4か所に組み込み、承認待ちは最大14日 ― 待機 中は退避してコストほぼゼロ • 共通の書き方は Microsoft Agent Framework （Magentic Workflow）
27. 新規アイデア企画サポートの構成
28. ご清聴ありがとうございました