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を活用し、今後に備えるための技術知識 / Basic Knowledge to Utili...
Search
Naoki Kishida
September 05, 2025
Programming
22
6.1k
AIを活用し、今後に備えるための技術知識 / Basic Knowledge to Utilize AI
2025年9月5日(金)に開催されたDevelopersIO 2025 FUKUOKAでの登壇資料です。
https://classmethod.connpass.com/event/362962/
Naoki Kishida
September 05, 2025
Tweet
Share
More Decks by Naoki Kishida
See All by Naoki Kishida
Current States of Java Web Frameworks at JCConf 2025
kishida
0
53
LLMベースAIの基本 / basics of LLM based AI
kishida
12
3.3k
Java 24まとめ / Java 24 summary
kishida
3
770
AI時代のプログラミング教育 / programming education in ai era
kishida
25
26k
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
10
2.6k
AI時代に求められるプログラマの能力 / ability of programmer in AI era
kishida
19
13k
Java 23の概要とJava Web Frameworkの現状 / Java 23 and Java web framework
kishida
2
550
Java Webフレームワークの現状 / java web framework
kishida
10
11k
Is Object Oriented nesessary? COSCUP 2024
kishida
0
210
Other Decks in Programming
See All in Programming
Can AI Take Over Frontend QA? - Navigating the Paradigm Shift: A Developer's Mindset for the Future - #layerx_frontend
teyamagu
PRO
4
1.7k
AI Agents: How Do They Work and How to Build Them @ Shift 2025
slobodan
0
120
はじめてのMaterial3 Expressive
ym223
2
1.1k
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
5
3.1k
猫と暮らすネットワークカメラ生活🐈 ~Vision frameworkでペットを愛でよう~ / iOSDC Japan 2025
yutailang0119
0
180
麻雀点数計算問題生成タスクから学ぶ Single Agentの限界と Agentic Workflowの底力
po3rin
5
1.7k
LLMとPlaywright/reg-suitを活用した jQueryリファクタリングの実際
kinocoboy2
4
490
Android StudioのAIコーディングツール、 ぶっちゃけどうなん???
mkeeda
0
180
プロパティベーステストによるUIテスト: LLMによるプロパティ定義生成でエッジケースを捉える
tetta_pdnt
0
6.5k
Server Less Code More - コードを書かない時代に生きるサーバーレスデザイン / server-less-code-more
gawa
5
1.6k
機能追加とリーダー業務の類似性
rinchoku
2
1.4k
Platformに“ちょうどいい”責務ってどこ? 関心の熱さにあわせて考える、責務分担のプラクティス
estie
2
430
Featured
See All Featured
Six Lessons from altMBA
skipperchong
28
4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Thoughts on Productivity
jonyablonski
70
4.8k
How STYLIGHT went responsive
nonsquared
100
5.8k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Large-scale JavaScript Application Architecture
addyosmani
513
110k
Agile that works and the tools we love
rasmusluckow
330
21k
Gamification - CAS2011
davidbonilla
81
5.4k
Done Done
chrislema
185
16k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
Statistics for Hackers
jakevdp
799
220k
Transcript
AIを活用し、今後に備えるための技術知識 2025/9/5 DevelopersIO 2025 FUKUOKA LINEヤフー きしだ なおき
2025/09/05 2 自己紹介 • きしだ なおき • LINEヤフー • X(twitter):
@kis • blog: きしだのHatena • (nowokay.hatenablog.com) • 「プロになるJava」というJavaの本を書いてます
3 AIのコーディング能力があがっている • AIのムーアの法則 • 50%の確率で成功するコード量は7ヵ月で2倍 by METR • 「人が1ヶ月かかるようなタスクを50%の成功率でこなせるようになる
のは2029年後半から2031年初頭」(岡野原さん) • Claude Codeイイゾと思って たら、Codex CLIがもっと よくなった • コードはAIが書く? • エンジニアどうしよう?
4 AIをうまく使うために仕組みを知る • AIは無限には賢くならない • AIは使い方によって能力が決まる • うまく使えば高い能力を発揮する • 仕組みを知ってうまく使う
• なんでもできると期待して、できないことをやらせようとしても無駄 • 仕組みを知っていれば、どうやれば良い返答が引きだせるかもわかる • 仕組みを知っていれば、何ができないかもだいたいわかる • AIは能力をブーストするツール • だれでも同じことができるようになるわけではない • むしろ差が開いていく
5 AIってなに? • LLMを中心とした反応システム • LLM=大規模言語モデル • 言語を扱う大規模なニューラルネットワーク • Transformerを基本とする
• 仕組み的には、文章の続きを生成
Transformer • 2017にGoogleが発表 • Attention is All You Need •
アテンション • 文章中の単語がどの単語を注目しているか • O(n^3)
7 Transformerの発展 • AIが賢くなったというときには技術発展がある GPT3 スケーリング則で学習コストをかけて性能をあげる GPT3.5 チャット対応とRLHFで対話が可能に GPT4 MoEで実行時リソースを削減
Function Callingで外部機能呼び出し o1 Reasoningによる推論時スケーリング o3 エージェントで推論の並列化
スケーリング則 • 言語モデルの性能がパラメータ数、データセットサイズ、計算予 算を変数としたべき乗になる • OpenAIが予算をつぎ込むキッカケになった Scaling Laws for Neural
Language Models (Jared Kaplan, Sam McCandlish et al., 2020-01-23)
チャット対応とRLHF • チャットに対応するファインチューニング • 指示応答モデル • 使いやすくなって爆発的人気 • RLHF(Reinforcement Learning
from Human Feedback) • 人間の評価による強化学習 • やりとりの心地よさ
MoE(Mixture of Experts) • FFNは知識をうけもつ • すべての知識を同時に使うことはない • 多数の専門家モデルを持っておいて、 推論時に必要なモデルだけを呼び出
すことでリソースを節約 • GPT-oss 120B • エキスパート数 128 • アクティブパラメータ数5.1B
Function Calling • LLMから外部関数を呼び出す • OpenAI、Google、Hugging HaceはFunction Calling • Anthropic、AWSはTool
Use • AIが幅広い機能をもつようになった • MCP • JSON-RPCを使ってリモートでFunction Calling • MCPサーバーは状態を持つので、JSON-RPCによる分散オブジェクト
Reasoningと推論時スケーリング • CoT(Chain or Thought) • 「段階的に考えて」 • ユーザーに応答を出す前に考察過程を入れる •
推論時にリソースを使うことでも 思考力がスケールする • 推論時スケーリング
なぜReasoningが効くか • Transformerでは、トークン同士の関係を見た後でモデルの知識 を利用して回答 • ひとつの層ではアテンションでトークン同士の関係、FFNに知識 • 全体では浅い層でトークン同士の関係、深い層で知識 • トークン同士の関係を見るときに知識が
活かされない • Reasoningで知識を出させておくと ユーザー入力と知識がトランスフォーマに 投入される
Agentによる複雑な推論 • o3(恐らく)やGemini Deep ThinkではReasoningを並列に行って 一番いいものを採用して回答 • チャットの中で複数のアイデアを出すのとは違う • コンテキスト(=チャット履歴)の分離が重要
• エージェント=コンテキスト • マルチエージェント • ツール呼び出しや判定を組み入れて複数コンテキストを 管理するシステム
なぜ同じ失敗が続くのか • AIにコードを書かせると、「修正しました!」といって2つ前の バグコードを出してきて「アホか!」と暴言を吐きたくなる
なぜ同じ失敗が続くのか • 間違い同士で注目して、大事な情報だと認識してしまう 関係 ありそう めちゃ関係 ありそう 関係 ありそう 関係
ありそう めちゃ関係 ありそう 関係 ありそう
コンテキストエンジニアリング • コンテキストが必要な情報だけ持つように管理する • コンテキストは汚れに弱い • 関係ありそうで関係ない情報があると性能劣化 • まったく関係ない話が混じると逆に性能よくなるという説も •
長コンテキスト対応といっても性能出るのは30Kトークンくらい • アテンションはO(n^3)なので長くできない • ウィンドウなどなんらか範囲を限定してる • 学習データがそんなに長くない
AIは100倍速くなる • 今後、AIがこれ以上賢くなるかどうかはわからない • 確実に速くなっていく • CerebrasでQwen3 Coder 480Bが2600tok/sec •
Cerebrasはウェハーサイズのプロセッサを作っている
AIが100倍速くなったらどうなるか • 10分かかる処理が5秒、2分かかる処理が1秒 • 例えば • プロンプトを打っていくとリアルタイムにコードが変わる • ユニットテストを書いておけばテストが通るまで生成を続ける •
それで割と早く生成が終わる
機械学習は都合のいいランダムを選ぶ仕組み • 機械学習は当たりが出やすいようパラメータを調整する仕組み • ハズレの確率が減っていくことを「学習が進む」という • 答えが定義できれば、正解が出やすくなるようパラメータを調整 していける • 問題と答えを自動生成できれば
どんどん賢くなる • 教師を超えることはない • テキストのみで学習なら人類を 超えない(個人は超える) • 機械判定できるなら人類を超える
LLMはユニットテストが書けるものは賢くなる • ユニットテストが定義できる問題は学習が進みやすい • ユニットテストが定義できるならテストが通るまで再試行できる • 部分的なユニットテストが通れば全体もだいたい動くといった コードも書ける • シーケンシャルな処理
ユニットテストが書きにくいものは苦手 • 学習ができない • テストが通るまでやりなおす戦略も使えない • 部分が正しくても全体が正しいわけではないものも苦手 • つまり非機能要件 •
ユーザビリティ • API設計 • セキュリティ • メンテナンス性
AIが書き散らしたコードを片付けるのが仕事 • AIは機能を実装するのは得意 • 機能を実装する楽しいお仕事はAIに奪われました • AIが書き散らしたコードを片付ける仕事が残りました! • AIにはメンテナンス性の高いコードが書けない •
機能要件はAIが、非機能要件は人間が担当
要件定義と受入テストは人間が必要 • AIにプロンプトを与える係が必要 • ユーザーの要求から要件を定義してプロンプト化が必要 • 責任は人間がとる必要があるのでテストも人間が担保 • 大げさに言えば、クビになったり逮捕されたりする係 •
AIは責任が取れない • クビにしても逮捕しても痛みを感じない ここが重要
エンジニアがやるべきことは? • AIの仕組みを知ろう • AIを制御していい仕事をさせようと思ったら仕組みを知るほうがいい • コードをちゃんと書けるようになろう • AIが書いた大量のコードを片付けるには生半可な「原則」では無理 •
言語機能、アルゴリズムを押さえて効率よくコード整理を • 上流工程を知ろう • 要件をまとめてAIに伝える、AIのコードを正しく検査する • 結論 • やるべきことが増えました。