Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AIに「任せない」という選択
Search
Ryu-nakayama
July 31, 2026
Programming
0
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AIに「任せない」という選択
手羽先プロンプト #1 オープニングLT
Ryu-nakayama
July 31, 2026
More Decks by Ryu-nakayama
See All by Ryu-nakayama
iOS機能開発のAI環境と起きた変化
ryunakayama
0
240
日本だけで解禁されているアプリ起動の方法
ryunakayama
0
430
iOSアプリでフロントエンドと仲良くする
ryunakayama
0
160
「ジェン文字」使ってますか?
ryunakayama
0
83
Health Kit × Foundation Models でAIコーチを作ってみた
ryunakayama
0
360
iOSの画面の状態のアレコレを調査してみた
ryunakayama
0
110
作文ツール(Writing Tools)をアプリから制御する
ryunakayama
0
67
iOSアプリで測る!名古屋駅までの 方向と距離
ryunakayama
0
320
「ジェン文字」をアプリ内で使ってみよう
ryunakayama
0
210
Other Decks in Programming
See All in Programming
Terraform標準の組織で AWS CDKをどう使うか
mu7889yoon
1
420
メールのエイリアス機能を履き違えない
isshinfunada
0
150
<title><a id="</title>君はこのHTMLをパースできるか"></a></title> #雑LT_study
pizzacat83
0
110
エンジニアにデザインハーネスを 〜デザインプロセスを規定するためのハーネス〜 / Design harness from an engineer's perspective
rkaga
2
1.8k
komatsuna「分散システムにおけるバグ分析手法」
komatsunaqa
0
130
【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ
panda728
PRO
2
290
テーブルをDELETEした
yuzneri
0
120
광주소프트웨어마이스터고등학교 DevFest 특강 - 바이브 코딩 시대에서 주니어 개발자로 살아남는 방법
utilforever
1
160
音楽のための関数型プログラミング言語mimiumにおける多段階計算の活用
tomoyanonymous
1
360
【やさしく解説 設計編・中級 #4】ルールの寿命と、システムの年輪
panda728
PRO
2
170
地域 SRE コミュニティ最前線 - ホンマでっかSRE勉強会
tk3fftk
0
290
FDEが実現するAI駆動経営の現在地
gonta
2
240
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.3k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
Mind Mapping
helmedeiros
PRO
1
290
Producing Creativity
orderedlist
PRO
348
40k
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
270
Claude Code のすすめ
schroneko
67
230k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
From π to Pie charts
rasagy
0
240
ラッコキーワード サービス紹介資料
rakko
1
4.1M
4 Signs Your Business is Dying
shpigford
187
22k
Faster Mobile Websites
deanohume
310
32k
Transcript
AIに「任せない」という選択 手羽先プロンプト #1 オープニングLT 中山 龍 / Ryu Nakayama
自己紹介 中山 龍 (なかやま りゅう) @ryu_develop 新卒4年目のエンジニア(24) 株式会社kubell で AIエージェントプロダクトの開発を担当
名古屋市在住 興味のあること: AI / 価値提供 / チーム・組織 / 開発生産性(事業生産性) …
AIの揺れを認識する
AIの揺れを認識する 質問: 同じAIに毎日「おはよう」と入力(インプット)を与えた場合、返答(アウトプット)は毎回同じに なるか? → 同じにならない
AIの揺れを認識する AIによる出力は揺れる(一定にならない) 『そもそも、推論は揺れる』 人間に毎日「おはよう」と言っても返答は一定とは限らないでしょう 「おはよう」と返ってくる日もあれば、「おはよう、今日は暑いね」って日も
AIの揺れを認識する AIは推論ができる という、従来のプログラムとは違った良さがある反面、結果が一定では ないので、不確実性がある → 『AIによる推論』を含んだプロダクト・業務フローは不確実性を 含んだ(非決定論的な )動きをすることになる (本スライドでは「決定論的 :
同じ入力 → 常に同じ出力が返ること」を指す )
AIの揺れを認識する(まとめ) 従来のプログラム・ツール (AIを含まないもの ) 『決定論的に』 動作する → インプット(入力)に対してアウトプット(出力)が一定である → 毎回決まった期待した出力が得られる
AI 『非決定論的に』 動作する → インプット(入力)に対してアウトプット(出力)が一定でない → 期待した出力が得られることもあれば、得られないこともある
揺れを減らす
どうなるのが嬉しい? ユーザー視点 : 期待した結果が安定して返ってくると嬉しい = 決定論的に動くものであるほど安定性は増すので嬉しい ただ、解決したい課題は決定論的に処理できるものだけではない... (≒ 推論をさせる必要があるものも多い) →
より『決定論的』に近づける努力をすることで、揺れ(不確実性)を減らすことを目指す
揺れを減らす 例: イベントの出席者数をスプレッドシートへ記録するフロー 出席者を 数える 出席者数を スプレッド シートへ 入力する このフローの自動化を考えてみましょう
揺れを減らす 例: イベントの出席者数をスプレッドシートへ記録するフロー (ver1) 人 AI Agent 完了 「イベントの出席者数を スプレッドシートへ記録
して」 イベントの出席者数をスプレッドシートへ記録する ?
揺れを減らす 例: イベントの出席者数をスプレッドシートへ記録するフロー (ver1) 人 AI Agent 完了 「イベントの出席者数を スプレッドシートへ記録
して」 イベントの出席者数をスプレッドシートへ記録する ? この全ての処理を AI Agentで 実行する必要はある?
要件から「本当に推論が必要か」を考える
本当に推論が必要か 例: イベントの出席者数をスプレッドシートへ記録するフロー (ver1) 人 AI Agent 完了 「イベントの出席者数を スプレッドシートへ記録
して」 イベントの出席者数をスプレッドシートへ記録する ? 出席者数 イベントの 出席者を数える スプレッドシートへ 記録する 「イベントページの参加者数」を出席者数とする場合、出席 者を取得するAPIが利用できるのであれば、推論がなくても 機械的に集計できそう
本当に推論が必要か 例: イベントの出席者数をスプレッドシートへ記録するフロー (ver1) 人 AI Agent 完了 「イベントの出席者数を スプレッドシートへ記録
して」 イベントの出席者数をスプレッドシートへ記録する ? 出席者数 イベントの 出席者を数える スプレッドシートへ 記録する 記録するシートやフォーマットが決まっているなら、 推論がなくても機械的に記録できそう
本当に推論が必要か 例: イベントの出席者数をスプレッドシートへ記録するフロー (ver1) 人 AI Agent 完了 「イベントの出席者数を スプレッドシートへ記録
して」 イベントの出席者数をスプレッドシートへ記録する ? この要件では推論をさせる必要はない と考えられる 出席者数 イベントの 出席者を数える スプレッドシートへ 記録する 記録するシートやフォーマットが決まっているなら、推論が なくても機械的に記録できそう
本当に推論が必要か 例: イベントの出席者数をスプレッドシートへ記録するフロー (ver2) 人 プログラム プログラム 完了 プログラムを起動する APIからイベント出席者
数を取得する シートへ既定のフォー マットで書き込む 記録が完了 推論がなく、決定論的に処理ができる
推論が必要になりそうなケース 例: イベントの出席者数をスプレッドシートへ記録するフロー (AI ver1) 人 AI Agent 完了 「イベントの出席者数を
スプレッドシートへ記録 して」 イベントの出席者数をスプレッドシートへ記録する ? 出席者数 イベントの 出席者を数える スプレッドシートへ 記録する 逆に「主催者のイベントレポートを読み取り、参加人数と思われる 記述を出席者数とする」という要件だった場合には、 AIに推論させ て処理した方がいいかも?
本当に推論が必要か 例: イベントの出席者数をスプレッドシートへ記録するフロー (ver3) 人 AI Agent プログラム 完了 「イベントの出席者数を
スプレッドシートへ記録 して」 イベントレポートから参 加者数と思われる記載 を見つけ、取得する シートへ既定のフォー マットで書き込む 記録が完了 推論が必要かを考えながら AIを用いることで、 結果の揺れをなるべく小さく抑えることに繋がる
AIに推論をさせることは悪なのか?
AIに推論をさせることは悪なのか? 現在の自分の考え: No - ただし、意図を持ってプロダクトに組み込むことが大切
AIに推論をさせることは悪なのか? 現在の自分の考え: No - ただし、意図を持ってプロダクトに組み込むことが大切 AIを組み込むことで、出力に揺れが出る可能性は上がる。 だが、必ずしも推論が必要でない部分だとしても、AI(推論)を組み込むことでより価値が 提供できる場合も考えられる 例: ユーザー接点にAIを組み込むことで手軽に機能を呼び出せる
複雑なロジックを実装しなくても手軽にフローを実現できる など
AIに推論をさせることは悪なのか? 個人的には 「そのプロダクトや機能が何を重視したいのか」を明 確にし、意図を持って実現方法を選ぶ」 ことが大切だと考えてい る 結果の正確性を重視するためにあれば推論を減らし不確実性を下げたり、 ユーザーの操作の省力化するために不確実性が上がるのを承知で推論を組み込む など
まとめ
まとめ AI(推論)を組み込むと 結果が揺れる可能性がある (処理の不確実性が増す ) • 結果の正確性を重視するのであれば、推論はなるべく必要な部分のみ の利用 に抑え、より決定論的に処理できる状態を目指すのが好ましい •
だが、推論が必須でない部分でも 推論によって得られるメリット は存在する AIの特性を踏まえ、「そのプロダクトや機能が何を重視したいのか」を明確 にし、意図を持って実現方法を選ぶ ことが大切だと考えている
None