AIを活用し、今後に備えるための技術知識 / Basic Knowledge to Utilize AI

2025年9月5日(金)に開催されたDevelopersIO 2025 FUKUOKAでの登壇資料です。
https://classmethod.connpass.com/event/362962/

Transcript

1. AIを活用し、今後に備えるための技術知識 2025/9/5 DevelopersIO 2025 FUKUOKA LINEヤフー きしだ なおき
2. 2025/09/05 2 自己紹介 • きしだ なおき • LINEヤフー • X(twitter): @kis • blog: きしだのHatena • (nowokay.hatenablog.com) • 「プロになるJava」というJavaの本を書いてます
3. 3 AIのコーディング能力があがっている • AIのムーアの法則 • 50%の確率で成功するコード量は7ヵ月で2倍 by METR • 「人が1ヶ月かかるようなタスクを50%の成功率でこなせるようになる のは2029年後半から2031年初頭」(岡野原さん) • Claude Codeイイゾと思って たら、Codex CLIがもっと よくなった • コードはAIが書く？ • エンジニアどうしよう？
4. 4 AIをうまく使うために仕組みを知る • AIは無限には賢くならない • AIは使い方によって能力が決まる • うまく使えば高い能力を発揮する • 仕組みを知ってうまく使う • なんでもできると期待して、できないことをやらせようとしても無駄 • 仕組みを知っていれば、どうやれば良い返答が引きだせるかもわかる • 仕組みを知っていれば、何ができないかもだいたいわかる • AIは能力をブーストするツール • だれでも同じことができるようになるわけではない • むしろ差が開いていく
5. 5 AIってなに？ • LLMを中心とした反応システム • LLM=大規模言語モデル • 言語を扱う大規模なニューラルネットワーク • Transformerを基本とする • 仕組み的には、文章の続きを生成
6. Transformer • 2017にGoogleが発表 • Attention is All You Need • アテンション • 文章中の単語がどの単語を注目しているか • O(n^3)
7. 7 Transformerの発展 • AIが賢くなったというときには技術発展がある GPT3 スケーリング則で学習コストをかけて性能をあげる GPT3.5 チャット対応とRLHFで対話が可能に GPT4 MoEで実行時リソースを削減 Function Callingで外部機能呼び出し o1 Reasoningによる推論時スケーリング o3 エージェントで推論の並列化
8. スケーリング則 • 言語モデルの性能がパラメータ数、データセットサイズ、計算予 算を変数としたべき乗になる • OpenAIが予算をつぎ込むキッカケになった Scaling Laws for Neural Language Models (Jared Kaplan, Sam McCandlish et al., 2020-01-23)
9. チャット対応とRLHF • チャットに対応するファインチューニング • 指示応答モデル • 使いやすくなって爆発的人気 • RLHF(Reinforcement Learning from Human Feedback) • 人間の評価による強化学習 • やりとりの心地よさ
10. MoE(Mixture of Experts) • FFNは知識をうけもつ • すべての知識を同時に使うことはない • 多数の専門家モデルを持っておいて、 推論時に必要なモデルだけを呼び出 すことでリソースを節約 • GPT-oss 120B • エキスパート数 128 • アクティブパラメータ数5.1B
11. Function Calling • LLMから外部関数を呼び出す • OpenAI、Google、Hugging HaceはFunction Calling • Anthropic、AWSはTool Use • AIが幅広い機能をもつようになった • MCP • JSON-RPCを使ってリモートでFunction Calling • MCPサーバーは状態を持つので、JSON-RPCによる分散オブジェクト
12. Reasoningと推論時スケーリング • CoT(Chain or Thought) • 「段階的に考えて」 • ユーザーに応答を出す前に考察過程を入れる • 推論時にリソースを使うことでも 思考力がスケールする • 推論時スケーリング
13. なぜReasoningが効くか • Transformerでは、トークン同士の関係を見た後でモデルの知識 を利用して回答 • ひとつの層ではアテンションでトークン同士の関係、FFNに知識 • 全体では浅い層でトークン同士の関係、深い層で知識 • トークン同士の関係を見るときに知識が 活かされない • Reasoningで知識を出させておくと ユーザー入力と知識がトランスフォーマに 投入される
14. Agentによる複雑な推論 • o3(恐らく)やGemini Deep ThinkではReasoningを並列に行って 一番いいものを採用して回答 • チャットの中で複数のアイデアを出すのとは違う • コンテキスト(=チャット履歴)の分離が重要 • エージェント=コンテキスト • マルチエージェント • ツール呼び出しや判定を組み入れて複数コンテキストを 管理するシステム
15. なぜ同じ失敗が続くのか • AIにコードを書かせると、「修正しました！」といって２つ前の バグコードを出してきて「アホか！」と暴言を吐きたくなる
16. なぜ同じ失敗が続くのか • 間違い同士で注目して、大事な情報だと認識してしまう 関係 ありそう めちゃ関係 ありそう 関係 ありそう 関係 ありそう めちゃ関係 ありそう 関係 ありそう
17. コンテキストエンジニアリング • コンテキストが必要な情報だけ持つように管理する • コンテキストは汚れに弱い • 関係ありそうで関係ない情報があると性能劣化 • まったく関係ない話が混じると逆に性能よくなるという説も • 長コンテキスト対応といっても性能出るのは30Kトークンくらい • アテンションはO(n^3)なので長くできない • ウィンドウなどなんらか範囲を限定してる • 学習データがそんなに長くない
18. AIは100倍速くなる • 今後、AIがこれ以上賢くなるかどうかはわからない • 確実に速くなっていく • CerebrasでQwen3 Coder 480Bが2600tok/sec • Cerebrasはウェハーサイズのプロセッサを作っている
19. AIが100倍速くなったらどうなるか • 10分かかる処理が5秒、2分かかる処理が1秒 • 例えば • プロンプトを打っていくとリアルタイムにコードが変わる • ユニットテストを書いておけばテストが通るまで生成を続ける • それで割と早く生成が終わる
20. 機械学習は都合のいいランダムを選ぶ仕組み • 機械学習は当たりが出やすいようパラメータを調整する仕組み • ハズレの確率が減っていくことを「学習が進む」という • 答えが定義できれば、正解が出やすくなるようパラメータを調整 していける • 問題と答えを自動生成できれば どんどん賢くなる • 教師を超えることはない • テキストのみで学習なら人類を 超えない(個人は超える) • 機械判定できるなら人類を超える
21. LLMはユニットテストが書けるものは賢くなる • ユニットテストが定義できる問題は学習が進みやすい • ユニットテストが定義できるならテストが通るまで再試行できる • 部分的なユニットテストが通れば全体もだいたい動くといった コードも書ける • シーケンシャルな処理
22. ユニットテストが書きにくいものは苦手 • 学習ができない • テストが通るまでやりなおす戦略も使えない • 部分が正しくても全体が正しいわけではないものも苦手 • つまり非機能要件 • ユーザビリティ • API設計 • セキュリティ • メンテナンス性
23. AIが書き散らしたコードを片付けるのが仕事 • AIは機能を実装するのは得意 • 機能を実装する楽しいお仕事はAIに奪われました • AIが書き散らしたコードを片付ける仕事が残りました！ • AIにはメンテナンス性の高いコードが書けない • 機能要件はAIが、非機能要件は人間が担当
24. 要件定義と受入テストは人間が必要 • AIにプロンプトを与える係が必要 • ユーザーの要求から要件を定義してプロンプト化が必要 • 責任は人間がとる必要があるのでテストも人間が担保 • 大げさに言えば、クビになったり逮捕されたりする係 • AIは責任が取れない • クビにしても逮捕しても痛みを感じない ここが重要
25. エンジニアがやるべきことは？ • AIの仕組みを知ろう • AIを制御していい仕事をさせようと思ったら仕組みを知るほうがいい • コードをちゃんと書けるようになろう • AIが書いた大量のコードを片付けるには生半可な「原則」では無理 • 言語機能、アルゴリズムを押さえて効率よくコード整理を • 上流工程を知ろう • 要件をまとめてAIに伝える、AIのコードを正しく検査する • 結論 • やるべきことが増えました。