生成AI活用の実践解説 (速報版)

産総研主催の 6th Grand Canvas 登壇時の資料です https://www.digiarc.aist.go.jp/event/6th_grand_canvas/

1. 生成AI活用の実践解説 (速報版) Asei Sugiyama
2. 自己紹介 杉山 阿聖 (@K_Ryuichirou) Software Engineer @ Citadel AI Google Developer Expert @ Cloud AI MLSE GenAIOps WG 機械学習図鑑 共著 事例でわかる MLOps 共著
3. TOC 背景 <- 継続的評価による継続的改善 AI セーフティ AI ガバナンス 発展的な話題
4. 背景 AI ネイティブカンパニー Agent の流行 評価に基づく LLMOps 市場調査: NEDO AI セーフティ強化に関する研究開発プロジェクト LLMOps の取り組み
6. AI ネイティブカンパニー DeNAが挑む「AIネイティブカンパニー」への全社的取り組み。人をエンパワーし、イノベーションを創出する─ 南場智子 | フルスイング by DeNA https://fullswing.dena.com/archives/100169/ メルカリが本気で始めた「AI-Native」化。100名規模のタスクフォースが立ち上がるまで | mercan (メルカン) https://careers.mercari.com/mercan/articles/53708/
7. AI Agent がビジネスに Algomatic: アポドリ、リクルタAI などエージェントを利用したサー ビスを次々展開 LayerX: バクラクシリーズに加え、 生成AIプラットフォーム Ai Workforce を展開 複数 AI エージェント同時立ち上げで「打席数」を重視——DMM が用意した20億円でスター トアップスタジオ展開する Algomatic #取材会 - BRIDGE（ブリッジ） https://thebridge.jp/2025/06/algomatic-launches-startup-studio-with-¥2-billion- investment-from-dmm LayerX、総額150億円の資金を調達。エンジニアを中心とした人材採用強化やさらなる事業 拡大へ https://aismiley.co.jp/ai_news/layerx-ai-saas-fintech/
8. Demo hell デモまでは行き着くもの の、本番化が著しく困難 品質を評価し、担保する ことが極めて困難 Escaping AI Demo Hell: Why Eval-Driven Development Is Your Path To Production https://www.forbes.com/councils/forbestechcouncil/2025/04/04/escaping- ai-demo-hell-why-eval-driven-development-is-your-path-to-production/
9. 評価に基づく LLMOps 最近の潮流 不確実性の高い分野に対 する開発のノウハウ集 MLOps というよりは「高 速 DevOps」 How to Solve the #1 Blocker for Getting AI Agents in Production | LangChain Interrupt https://interrupt.langchain.com/videos/building-reliable-agents- agent-evaluations
10. AI セーフティ強化に関する研究 開発プロジェクト Citadel AI で「企業向け実装解 説」としてベストプラクティ ス集・事例集の作成を担当 「デモは簡単にできるものの サービス化や本番化は難しい」 というテーマでヒアリング 似たような課題・対策を行っ ていることが見えてきた
11. LLMOps の取り組み 継続的評価による継続的改善 AI セーフティ AI ガバナンス
12. TOC 背景 継続的評価による継続的改善 <- AI セーフティ AI ガバナンス 発展的な話題
13. 継続的評価による継続的改善 評価は難しい Who Validates the Validators? プロンプトエンジニアリング LLM-as-a-Judge 継続的な評価 ハッカソン エージェント トレース
14. 評価は難しい システムの正しい振る舞 いを、誰も明確に記述で きない 品質評価の観点を事前に 列挙することは困難で、 出力から事後的に得られ ることが大半 機械学習による言語パフォーマンスの評価 - Speaker Deck https://speakerdeck.com/langstat/ji-jie-xue-xi-niyoruyan-yu- pahuomansunoping-jia
15. Criteria Drift Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences LLM の出力に対する評価基準 が、評価を進めるにつれてユ ーザー自身によって変化また は洗練されていく [2404.12272] Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences https://arxiv.org/abs/2404.12272
16. 発想の逆転: 高速プロトタイ ピング 専門家も自分の行ってい ること・やりたいことを 明確にできない 評価を繰り返すことで専 門家の知識を明文化する 手戻りを恐れるのではな くイテレーションを回す AIエージェントの地上戦 〜開発計画と運用実践 / 2025/04/08 Findy ランチ セッション #19 https://speakerdeck.com/smiyawaki0820/08-findy-w-and- bmitoatupu-number-19
17. プロンプトエンジニアリング 入力文章を調整して、言語モ デルを効率的に使おうとする 手法群 指示文を人が見たときにわか りやすくなるよう、明確に記 述することが基本 Gemini の記事が参考になる Gemini から欲しい回答を引き出すプロンプト術｜Gemini - Google の AI https://note.com/google_gemini/n/n60a9c426694e
18. LLM-as-a-Judge プロンプトを用いて LLM に出力の良さを評価させ る手法 新たな評価観点が得られ た場合、その評価観点に 基づく評価方法の手順書 を書くと、その観点に基 づく評価が LLM で可能 LLMによるLLMの評価「LLM-as-a-Judge」入門〜基礎から運用まで徹底解 説 https://zenn.dev/pharmax/articles/2d07bf0498e212
19. 継続的な評価による継続的な改善
20. ハッカソン: デジタル庁 ハッカソンは専門家を巻 き込むために有効 ハッカソンにより「5時間 という短い開発時間の中 で、38個のプロトタイプ」 ハッカソンの成果物を OSS として公開 第三弾： 「法令」×「デジタル」ハッカソンを開催しました｜デジタル庁 https://www.digital.go.jp/news/9fb5ef8e-c631-4974-96d9-0b145304c553 法令 Deep Research ツール Lawsy を OSS として公開しました｜Tatsuya Shirakawa https://note.com/tatsuyashirakawa/n/nbda706503902
21. Agent チューニングにより「1つ のこと(ドメイン)をうまく やる」ものができる 各ドメインを協調させる 取り組みがエージェント Microservices Architecture の再発見 メルカリにおけるデータアナリティクス AI エージェント「Socrates」と ADK 活用事例 https://speakerdeck.com/na0/merukariniokerudetaanariteikusu-ai-eziento- socrates-to-adk-huo-yong-shi-li
22. トレース Agent はさまざまなシステムを組 み合わせて使うため、望ましくな い結果が得られたときにその原因 追及が困難 最終結果を生成するまでの途中で 何が起きているのかを記録し、分 析できるようにする LangSmith や Langfuse は Trace 機 能を実装している LangSmithによるLLMアプリケーションのトレーシング入門 https://zenn.dev/pharmax/articles/61edc477e4de17
23. TOC 背景 継続的評価による継続的改善 AI セーフティ <- AI ガバナンス 発展的な話題
24. AI セーフティ AI セーフティとは 実践 AI セーフティ リスクと効果を考慮し小さく始める リスクに対策する 独自のデータを定義し評価データを育てる 専門家を開発チームの一員にする 本番環境でテストする
25. AI セーフティとは 定義自体の議論が進行中 AI 事業者ガイドラインで は「安全性」を定義 AISI UK の Research Agenda では 6 種類のリス クを定義 Research Agenda https://www.aisi.gov.uk/research-agenda
26. AI セーフティに関する評価観点ガイド AIセーフティに関する評価観点ガイドの公開 - AISI Japan https://aisi.go.jp/output/output_information/240918_2/
27. 実践 AI セーフティ リスクマネジメントの手法を応用 1. ユースケースを列挙 2. ユースケースごとにリスクを分析 3. ユースケースごとに対応 (回避・低減・移転・受容) を決定 4. 安全だと判断できるユースケースに限ってサービスを提供 5. サービスの利用状況をモニタリング
28. 事例: PharmaX (YOJO) LINE でユーザーが OTC 薬 を購入できるオンライン 薬局 問い合わせをルールと LLM で分類 ワークフローで安全に対 応できるユースケースのみ を対応 AIエージェントの継続的改善のためオブザーバビリティ https://speakerdeck.com/pharma_x_tech/aiezientonoji-sok-de-gai-shan- notameobuzababiritei
29. リスクと効果を考慮し小さく始める ユースケースを安全性と効果の2軸で分類 安全性: サービス提供、人にフォールバック、対応不可 効果: システム化が進んでいない、人の経験や勘に頼ってい る、などで判断 安全かつ効果の高いユースケースを特定し推進する ユースケースを特定し、ホワイトリスト形式で安全なユースケース のみサービス提供
30. OpenAI: AI 活用ユースケースの発見と展開 ビジネス向けガイドとリソース | OpenAI https://openai.com/ja-JP/business/guides-and-resources/
31. リスクに対策する (1/2) Human-in-the-Loop エンドユーザー向けではなく、社内の専門家向けにサービス提供 出力結果を直接提供することを禁止し、一度人手で編集して提供 安全な環境を用意 第三者に社内情報が漏洩しないように、オプトアウト セキュリティや監査に堪え、安全に使える環境を用意して展開
32. リスクに対策する (2/2) 小規模に始めて徐々に拡大 リスクを特定して徹底的に検証し、小規模にリリース 全面的には利用を禁止し、小規模にパイロットとして導入しテスト 社内の体制整備 ガイドラインやチェックリストを用意し、安全な利用方法を推進
33. 独自のデータを定義し評価 データを育てる 「自分の業務」というベ ンチマークはない 生成 AI に対するユニット テストのように扱う 専門家によるレビュー結 果を評価データに追加す る AIエージェントの継続的改善のためオブザーバビリティ https://speakerdeck.com/pharma_x_tech/aiezientonoji-sok-de-gai-shan- notameobuzababiritei
34. 事例: ダイキン工業 独自のマルチモーダルデ ータセットを構築 インターネット上には存 在しないデータを用い て、自社の業務知識を持 つモデルを作成 ダイキンがサービス支援AIを内製、活用進めた4度の「偶然の出会い」 | 日 経クロステック（xTECH） https://xtech.nikkei.com/atcl/nxt/column/18/00001/10313/
35. 専門家を開発チームの一員 にする 専門家によるレビューや 議論の結果をプロンプト に反映 専門家もいきなりは自分 のノウハウを言語化でき ないので、イテレーショ ンを回して徐々に言語化 AIエージェントの地上戦 〜開発計画と運用実践 / 2025/04/08 Findy ランチ セッション #19 - Speaker Deck https://speakerdeck.com/smiyawaki0820/08-findy-w-and-bmitoatupu- number-19
36. 本番環境でテストする どうしても「やってみな いとわからない」 限定的にリリースして想 定外の事象が発生しない か確認する モニタリングでリスクと 効果を確認 ペアーズにおける評価ドリブンな AI Agent 開発のご紹介 https://speakerdeck.com/fukubaka0825/heasuniokeruping-jia-torihunna-ai- agent-kai-fa-nokoshao-jie
37. TOC 背景 継続的評価による継続的改善 AI セーフティ AI ガバナンス <- 発展的な話題
38. AI ガバナンス AI ガバナンスとは 代表的なガイドライン AI ガバナンスにおける典型的な方法論と課題 実践 AI ガバナンス
39. AI ガバナンス リスク管理 + 提供価値の最大化 アジャイルガバナンス: 組織として 学習し続けることを求める リスクマネジメントに関するISO 標準 (ISO 31000:2018) でもアジャ イルの考え方を取り入れている AI事業者ガイドライン（METI/経済産業省） https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html
40. AI 事業者ガイドライン AI の利活用によって生じるリスクをステークホルダーにとって受 容可能な水準で管理しつつ、そこからもたらされる正のインパク ト（便益）を最大化することを目的とする、ステークホルダーに よる技術的、組織的、及び社会的システムの設計並びに運用。 AI事業者ガイドライン（METI/経済産業省）https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html
41. AI ガバナンスにおける典型的な方法論と課題 ガイドラインの整備 組織体制の構築 典型的な課題
42. ガイドラインの整備 AI の活用にあたって遵守すべき事項をまとめたドキュメントを作成 組織全体に適用する活用指針をもとに、実業務に適用するためのガ イドライン、具体的なチェックリストといった階層構造をもたせる ことが一般的 活用指針は透明性のために外部公開することも
43. リクルートAI活用指針 1. ユーザーの機会拡大や社会の発展 に繋がるAIの活用 2. 公平性・公正性の追求 3. プライバシー保護とセキュリティ 強化 4. アカウンタビリティの向上 5. ステークホルダーや有識者との対 話 リクルートAI活用指針 | 株式会社リクルート https://www.recruit.co.jp/privacy/ai_policy/
44. インテージグループAI利活用指針 1. 安全性の重視・セキュリティの強 化 2. 公平性の確保 3. プライバシー保護・コンプライア ンス順守 4. 透明性の追求 5. 品質の追求 インテージグループAI利活用指針　|　企業情報　|　インテージホールディングス https://www.intageholdings.co.jp/company/ai_policy/
45. PFN 規定・ガイドライン体系 階層的なドキュメントを用 意し、段階的に個々のプロ ジェクトにあわせて具体化 最終的には「プロジェクト 開発方針」を個々のプロジ ェクトで策定 Preferred Networksにおける大規模言語モデル開発と活用での AI安全性の考え 方 https://www.digiarc.aist.go.jp/event/4th_grand_canvas/pdf/20250304-4th- grand-canvas-03-ohno.pdf
46. 組織体制の構築 AI ガバナンスを推進するための体制構築 推進するための専門チームを設けることが多い
47. 株式会社リクルートの例 AIガバナンスの取り組み | 株式会社リクルート https://www.recruit.co.jp/privacy/ai_policy/ai_governance/
48. LINEヤフー株式会社の例 責任あるAIへの取組み｜LINEヤフー株式会社 https://www.lycorp.co.jp/ja/sustainability/esg/social/responsible-ai/
49. 典型的な課題 リソース不足 AI ガバナンス専門のチームが組織に1つなので忙しい AI という変化の激しい分野で全方位に目を配る必要がある ルールの周知と徹底 AI ガバナンス専門のチームはタイムリーにガイドラインを書き換え るものの、すべてのチームが見てくれるわけではない 誰もが取り組めるようになった結果、リスクを知らずに企画立案し て推進してしまうことも
50. 実践 AI ガバナンス うまくいく/うまくいかないチームの違い AI ガバナンスのミッション AI ガバナンスの提供する機能
51. うまくいく/うまくいかないチームの違い AI ガバナンスのミッション AI ガバナンスの提供する機能
52. AI ガバナンスのミッション どんな使い方をしても大丈夫なAIを用意して展開しようとすると失 敗する (実現できない) AI セーフティについては組織内の各チームに任せる AI ガバナンスを専門で行うチームでのみ低減できるリスクは「AI を 活用しない機会損失リスク」 うまくいっている AI ガバナンスチームのミッションは「AI の組織 的な活用」
53. セガでの AI ガバナンス CEDEC 2025 講演資料よ り引用 (pp.11-12) もはや AI を使うのが当た り前で気がついたら誰も が使っているという前提 「AIを使わないことはあ りえない」 安心安全に生成AIを使おう！社内で運用中の生成AIのガバナンスをご紹介 https://cedil.cesa.or.jp/cedil_sessions/view/3147
54. AI ガバナンスの提供する機能 1. 統合的なAI相談窓口 2. AI 活用支援 3. 教育
55. 1. 統合的なAI相談窓口 CEDEC 2025 講演資料よ り引用 (pp.17, p.19) AI ガバナンス担当チーム は、組織の中でもっとも 活用事例に詳しいチーム どんな問い合わせにも答 えることで信頼を勝ち取 る 安心安全に生成AIを使おう！社内で運用中の生成AIのガバナンスをご紹介 https://cedil.cesa.or.jp/cedil_sessions/view/3147
56. 2. AI 活用支援 AI ガバナンス担当の持つ 専門知識は、組織内の別 チームは持っていない チームトポロジーの「イ ネイブリングチーム」 短期間の密なコラボレー ションで組織内のチーム が AI 活用できるよう支援 マシュー・スケルトン, マニュエル・パイス 著 原田　騎郎, 永瀬　美穂, 吉羽　 龍太郎 訳「チームトポロジー」日本能率協会マネジメントセンター 2021年
57. プロンプトキッチン 「生成AIの活用スキルを 従業員に定着させるため の実践的な研修プログラ ム」 各部署に行ってニーズを 掴み、業務で活用できる プロンプトを一緒に書く セガサミーG、生成AI徹底活用の仕掛け人・石森拓郎氏に訊く 〜IT部門統合 から”攻め”への転換、感動体験を創る技術戦略〜 | データで越境者に寄り添 うメディア データのじかん https://data.wingarc.com/sega-sammy- ishimoritakuro-80385
58. PFN のガバナンス体制 AI リスクを評価する「リスク 評価委員会」 プロジェクトにおける AI 活用 を推進できるよう「AIガバナ ンス推進チーム」が支援 AIベンダーにおけるAIセキュリティ・ガバナンスへの取組 - Speaker Deck https://speakerdeck.com/pfn/20250717-awt-2025-tokyo-pfn-ai-governance
59. 3. 教育 AI セーフティを組織内の全チームに実施してもらう必要がある 権利侵害などのリスク感度を組織的に向上させる必要がある 全組織に対して教育プログラムを提供し、リテラシーを向上させる
60. LINEヤフーでの取り組み 生成AIの利用に伴うリスクを把握するため、全従業員に研修を実施 社内のAIアシスタントを使うためには必ず受講しなければならない
61. TOC 背景 継続的評価による継続的改善 AI セーフティ AI ガバナンス 発展的な話題 <-
62. 発展的な話題 ソフトウェアエンジニアリングの再発見 Vibe Coding / Spec Driven Development KISS (Keep It Simple Stupid) & リーンソフトウェア開発 コンウェイの法則
63. ソフトウェアエンジニアリングの再発見 Agent 開発手法 ソフトウェア開発手法 小さくはじめて育てる リーンスタートアップ 高速プロトタイピング アジャイルソフトウェア開発宣言 独自データセット定義 テスト駆動開発 領域特化エージェント ドメイン駆動開発 本番環境でのテスト DevOps のカナリアリリース
64. Vibe Coding 自然言語で指示するだけ でコーディングを行わな いスタイル 非専門家がアプリケーシ ョン開発可能に プロトタイピングのため の試行錯誤が容易に Andrej Karpathy / X https://x.com/karpathy/status/1886192184808149383
65. Spec Driven Development AWS が開発した Kiro で導 入された開発手法 プロンプトからまずは要 件を記述 要件に基づきコード生成 (Plan first, then build.) GitHub からも Spec Kit が 発表された Kiro: The AI IDE for prototype to production https://kiro.dev/ github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development https://github.com/github/spec-kit
66. ウォーターフォール Winston W. Royce による開発 プロセスの整理 オリジナルは反復とフィード バックを含む SDD という新たな名前でその ように再定義できるか Managing the development of large software systems: concepts and techniques | Proceedings of the 9th international conference on Software Engineering https://dl.acm.org/doi/10.5555/41765.41801
67. KISS (Keep It Simple Stupid) & リーンソフトウェア開発 エージェント構築実践ガイド https://openai.com/ja-JP/business/guides-and-resources/
68. コンウェイの法則 チューニングにより「1つ のこと(ドメイン)をうまく やる」ものができる 「システムを設計する組 織は、そのコミュニケー ション構造をそっくりま ねた構造の設計を生み出 してしまう」 メルカリにおけるデータアナリティクス AI エージェント「Socrates」と ADK 活用事例 https://speakerdeck.com/na0/merukariniokerudetaanariteikusu-ai-eziento- socrates-to-adk-huo-yong-shi-li
69. まとめ LLMOps では評価を中心とした継続的な改善により、高速に改善サ イクルを回すことで提供したい価値を発見する AIセーフティとは、リスクと効果を考慮して安全なユースケースか ら小さく始め、専門家を巻き込みながら継続的にテスト・改善して いく実践的なリスクマネジメント AI ガバナンスがうまくいっている組織では AI ガバナンスのミッシ ョンを「AI の組織的な活用」としている 生成 AI の活用における Software Engineering の再発見が散見される ようになってきた、歴史から未来予測ができるかもしれない