Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
AIに「任せない」という選択
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Ryu-nakayama
July 31, 2026
Programming
90
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
270
日本だけで解禁されているアプリ起動の方法
ryunakayama
0
460
iOSアプリでフロントエンドと仲良くする
ryunakayama
0
180
「ジェン文字」使ってますか?
ryunakayama
0
100
Health Kit × Foundation Models でAIコーチを作ってみた
ryunakayama
0
380
iOSの画面の状態のアレコレを調査してみた
ryunakayama
0
150
作文ツール(Writing Tools)をアプリから制御する
ryunakayama
0
94
iOSアプリで測る!名古屋駅までの 方向と距離
ryunakayama
0
340
「ジェン文字」をアプリ内で使ってみよう
ryunakayama
0
230
Other Decks in Programming
See All in Programming
【加筆修正版】Laravel のアプリケーションをどこにデプロイするか #phpcon_ehime
akase244
0
150
當我們開始不讀 Code - AI Agent 時代,Code Review 與 Clean Code 還剩下什麼?
jame2408
1
280
作れる、でも消せるか?──安全に「枯らして消す」機能削除術 / Drain, Then Delete
chobishiba
2
830
[2026-10-09]一枚の布で作らなくてもいい。 信頼性は「パッチワーク」で紡がれる~既存の運用と新しい可能性をつなぎ合わせてきたCREの話~
tosite
0
110
JIS keyboard support in Omarchy
lef237
0
140
ActionController meets Protocol Buffers
sorah
0
560
Workers Cache を知る
syumai
0
370
自サークルのIdPからログアウトできるようになるまで
taiseiue
1
140
機械に任せるテスト、人が見るテスト ⽣成AIで引き直した、運⽤保守フェーズの線引き
dske104
0
190
Apple Intelligence を用いた個人情報誤送信防止、及びユーザーリクエスト体験の改善について
yukiny
0
360
Compiling a real-world CLI tool to native with Static Hermes
tmikov2023
0
120
The Rails Doctrine Decade
koic
2
600
Featured
See All Featured
How to Ace a Technical Interview
jacobian
280
24k
SEO for Brand Visibility & Recognition
aleyda
0
4.8k
How to Think Like a Performance Engineer
csswizardry
28
2.9k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
730
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
790
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Six Lessons from altMBA
skipperchong
29
4.5k
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
560
Building Applications with DynamoDB
mza
96
7.2k
Thoughts on Productivity
jonyablonski
76
5.4k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
120
120k
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