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
その節約、円になってますか?
isamumumu
0
490
Lean は証明の正しさを確認するためだけのツールって思ってませんか?
inoueasei
1
120
5分で問診!Composer セキュリティ健康診断
codmoninc
0
700
torikago - Ruby::Boxで照らすモジュラモノリスの実行境界
se4weed
1
260
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
480
AI時代、エンジニアはどう育つのか -未経験エンジニアの成長を間近で見て考えたこと-
thasu0123
0
200
使いながら育てる Claude Code — 開発フローの1コマンド化 × 繰り返し指摘の自動仕組み化
shiki_kakaku
0
1.3k
作るコストが小さくなった時代 幸せに働くために改めて考えたいこと 〜エンジニアとして価値を出し続けるために注視している二分野〜
yuppeeng
0
140
OpenSpecのproposalにbrainstormingを持たせてみた
tigertora7571
1
150
【やさしく解説 設計編・中級 #6】良いアーキテクチャとは ~ 一本の登り道の、行き先 ~
panda728
PRO
0
190
FDEが実現するAI駆動経営の現在地
gonta
2
240
複数の Claude Code が"放置"されてしまう問題をCLI ダッシュボードを自作して解決した話
sumihiro3
0
530
Featured
See All Featured
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
330
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
Designing for Performance
lara
611
70k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.3k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
230
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Documentation Writing (for coders)
carmenintech
77
5.4k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
930
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2k
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