みんなでAI上手ピーポーになろう！ / Let’s All Get AI-Savvy!

by 株式会社カミナシ

Slide 1

Slide 1 text

みんなでAI上手ピーポーになろう！ 2026.01.15【AI時代の開発戦略】開発スピードと品質の両立に向けてー 3社エンジニアの事例から学ぶすずけん / @szk3 AI-Assisted Dev Review の実践

Slide 2

Slide 2 text

1. 自己紹介 2. 本日お話すること / しないこと 3. AI時代における開発スピードと品質の役割分担 4. AI時代の開発戦略 5. AI-assisted Dev Review 6. まとめみんなでAI上手ピーポーになろう！本日の流れ 1

Slide 3

Slide 3 text

はじめに

Slide 4

Slide 4 text

1 4 自己紹介本日の登壇者経歴前職にてフロント・バックエンド・インフラ・ネイティブアプリ・EMなど一通り経験した後に、パブリッククラウド活用のスペシャリストとして、AWS移行やCCoE の組成などを牽引。2022年10月にカミナシに入社。カミナシでの仕事クラウド・インフラロールのICとして、技術負債解消やサービスチームでの開発に従事した後、新規事業「カミナシ設備保全」にて、プレイングマネージャー型のEM を実践中。株式会社カミナシエンジニアリングマネージャー鈴木健太郎 (すずけん) szk3

Slide 5

Slide 5 text

みんなでAI上手ピーポーになろう！本日お話すること / しないこと 1 本日お話すること開発スピードと品質の両立の為に、チームでAI活用レベルを向上させることの重要性と、その具体的な取組みについて - AI-Assisted Dev Review の実践本日お話しないこと・AIを使った特定の開発手法に特化した施策の紹介

Slide 6

Slide 6 text

AI時代における開発スピードと品質の役割分担

Slide 7

Slide 7 text

人とAIが「開発スピード」や「品質」にもたらす役割は、適材適所で分担するのが良いとされる。「AI時代における開発スピードと品質」の役割分担 AI時代における開発スピードと品質の役割分担 1 → 開発（実装）の出力は、AIに委託する → 品質（保守性、正解）の定義は、　人がAIと伴走しながら作り上げる開発スピードの向上は、AIの得意な役割品質の向上は、人間が意志決定する領域

Slide 8

Slide 8 text

AI/LLMは、個人と比べて知識量は多いが、応用するセンスは（指示がなければ）ない。 LLMは世の中の一般的な知識に詳しくそれを使うのが得意だから、一般的な開発（実装）は、AIの得意な領域なので委託したほうがスピードは上がる。残念ながら、技術がコモディティであるほどAIコーディングエージェントによる実装は速く、人がAIに敵うのは難しい。難しいドメインやコンテキストが必要な実装であれば人が書いたほうが良いケースも一定存在するが、遅かれ早かれ一般的なサービス開発において人がコードを書く機会は減っていく未来になると想像できる。開発スピードの向上は、AIの得意な役割 AI時代における開発スピードと品質の役割分担 1

Slide 9

Slide 9 text

人は、LLMと比べて知識量は足りないが、応用するセンス（現況への適用能力）がある。環境やコンテキストが同じことがないという前提で、その場・その時・そのコードや開発戦略に対して、品質が高いという判断基準は人間がデザインするのが望ましい。 AI/LLMの出力精度が上がっているからといって、ノールックでOKというのは品質を判断していないと同義（同じノールックでも Ralph Wiggum loop みたいな収束のさせ方はちょっと別で考えるけど）。品質の向上は、人間が意志決定する領域 AI時代における開発スピードと品質の役割分担 1

Slide 10

Slide 10 text

LLMモデル自体を不変であるとし、人のふるまいを可変と捉えると、人がやるべきことが見えてくる。人とAIの協業をデザインする AI時代における開発スピードと品質の役割分担 1 ● AIを迷わせないように、AIにとってわかりやすい方針を作る ● 品質・正解を、定義・計画する ● コンテキスト（その場、その時、そのコードや開発戦略）をAIにインプットする ● 様々な手法を、実務の中で実行してみる etc 例えば...

Slide 11

Slide 11 text

人の責務は、AIを現状の開発スタイルにオンボーディングさせること。人とAIの協業をデザインする AI時代における開発スピードと品質の役割分担 1 生成AI「戦力化」の教科書: P57.より引用つまり、現在のコンテキストを整理し、土台にあるLLMの原理を理解した上でLLMをバックグラウンドに動くツールのふるまいや出力に対する理由を考え、それを新しい出力の質に転化させるルールに落とし込む必要がある。 LLMも人間が意図的にオンボーディングする必要があるのです。 “

Slide 12

Slide 12 text

AI時代の開発戦略

Slide 13

Slide 13 text

このAI時代、サービス/プロダクト/ソフトウェア開発に対し、誰もがパラダイムシフトを感じている。不確実性の高い未来に向けて、現状に旗を立てるなら、不変な事実を整理し拠り所にしたい。まず、AI時代の事実を整理する AI時代の開発戦略 1

Slide 14

Slide 14 text

現時点において自明なこと AI時代の開発戦略 1 ❷ AIの基盤となるLLMにも限界がある ❸ LLMにとって入力(コンテキスト)が、出力(推論結果)の質の源泉になる ❹ AI/LLMに最初の指示を出すのは人である（現時点ではね...） ❶ AI/LLMを取り巻く環境は、昨今類をみないスピードで進化している

Slide 15

Slide 15 text

「〇〇にBetする」とよく聞くものの、実際の開発現場においてはというような新しい課題が生まれている。早すぎる進化がもたらす新たな課題１．AI/LLMを取り巻く環境は、昨今類をみないスピードで進化している 1 ● 特定のフレームワーク・ツール・モデルにコミットしづらい力学が働きやすい ● 今日のべスプラは、明日のベスプラではない可能性のほうが高い ● 個人でキャッチアップした情報がチーム戦に活かしにくい（情報格差がある）

Slide 16

Slide 16 text

絶えず生まれつづけるベスプラは、自分たちの眼の前の課題を全て解決してくれるように見えることがある。しかし、「うまくいきそうだという感覚」と「実際にやってみた」では結構な差が生まれることがある。だからこそ、AI/LLMの活用は、今直面している既存環境（Brown field）で試さないと本当のところはわからない。（Forward Deployed Engineer のような職種が注目される背景のひとつだと感じる）隣の芝生（べスプラ）は青いのか？ 1 １．AI/LLMを取り巻く環境は、昨今類をみないスピードで進化している

Slide 17

Slide 17 text

AIの根幹にあるLLMも万能に見えるが、限界も存在する。代表的なものとして、この３つが挙げられる。 AIの基盤となるLLMにも限界がある２．AIの基盤となるLLMにも限界がある 1 ❶ 一度に渡せるコンテキストは有限 ❷ LLMは確率的（非決定性が高く、出力はガチャ） ❸ 嘘をつく（ハルシネーション）

Slide 18

Slide 18 text

LLMが嘘をつく(様に見える)のは、確率的だから　→　正しい出力の発生確率が低いのは、入力(コンテキスト)の質が悪いからつまり、コンテキストが出力(推論結果)の質を向上する鍵になる　 LLMの限界の相関性２．AIの基盤となるLLMにも限界がある 1 ● コンテキストが多すぎる ● コンテキストが少なすぎる ● 誤ったコンテキストを渡している

Slide 19

Slide 19 text

どれだけLLMの出力が速く大量に出たところで、出力の方向が間違っていたら意味がない。つまり、LLMを基盤とするAI機能が気持ちよく正しい方向に走れるレールの質を高めることが、AI時代の開発戦略として、「開発スピードと質」に貢献する一つの要素である。そのレールの質を高めるには、AI/LLMのお気持ちを察することが必要であり、そのために原理を理解し、入力（コンテキスト）をエンジニアリングすることはとても重要だと感じる。 Prompt Engineering から、Agentic Context Engineering へ３．LLMにとって入力(コンテキスト)が、出力(推論結果)の質の源泉になる 1

Slide 20

Slide 20 text

一方でコンテキストエンジニアリングは、LLMの非決定性の出力の都合上、成果を判断するのが難しい。（トークンが減ったとかはわかりやすいけど）とはいえ、Engメンバー全員からの意見を集めることで、コンテキストエンジニアリングの成果の確からしさを定性的に確認することはできる。コンテキストエンジニアリングは成果を判断するのが難しい３．LLMにとって入力(コンテキスト)が、出力(推論結果)の質の源泉になる 1

Slide 21

Slide 21 text

AIの出力の質は、人のAI活用リテラシーに依存する LLM をベースとしたAIツールやそのエコシステムのトレンドの変化はあまりに早すぎる。問題は、それらを使う人・チームがその進化に追くのが難しいということ。また、AIと協業する為のリテラシー（意志決定力・判断力）は一朝一夕では身につかない。だからこそ、AI/LLM周りのリテラシーを底上げするような、泥臭く地味な取り組みが、人とAIの協業への投資となり効果を発揮するはず。４．AI/LLMに最初の指示を出すのは人である 1

Slide 22

Slide 22 text

AI時代の開発戦略まとめ人がAIと協業する試行回数を高め、実務での判断力・応用力を養い、それをチームに還元するような仕組みを作り、オーナーシップを持って推進していくことが大事。 1 オーナーシップ ● AIに正しい方向性で出力してもらう為に人が何をすべきか？の試行回数を増やす ● 速すぎるAI/LLMの進化への追従に、個人で疲弊しないようにする ● 実務におけるAI活用実例をシェアし、チームのAI活用リテラシーを上げる AI時代の開発戦略

Slide 23

Slide 23 text

AI-assisted Dev Review

Slide 24

Slide 24 text

AI-assited Dev Reviewとは、自サービスチームのEngメンバーに向けた、AI/LLM活用のリテラシーの向上に投資する開発戦略のひとつ。具体としては、ただのEng向け定例MTG。手法としては、ナレッジマネジメントの型をカジュアルに取り入れている。 AI-assisted Dev Review とは？ AI-assisted Dev Review 1

Slide 25

Slide 25 text

野中郁次郎先生が提唱した概念で、SECIモデル（共同化・表出化・連結化・内面化）を理論的基盤とし、暗黙知を形式知に変えることで、属人化の解消や人材育成、競争力強化につなげることができる。( 詳しくは、いろんな書籍がでていますので、そちらを参照してください。) ナレッジマネジメントとは？ AI-assisted Dev Review 1

Slide 26

Slide 26 text

昨今の早すぎるAIの進化に取り残されず、かといって過度に先端を行き過ぎて消耗せずに、AIを使ったサービス開発のスキルを向上させて、ソフトウェアエンジニアとしての生存率をあげること。 AI-assisted Dev Review の目的は？ AI-assisted Dev Review 1

Slide 27

Slide 27 text

具体は、めちゃくちゃシンプル。サービス開発を通じて、さまざなAI（Gemini, Claude Code , GitHub Copilot, NotebookLM etc...) を使った開発効率の向上のための取り組みや工夫をシェアするための定例MTGを行っているだけ。議論のネタは、NotionのDBテンプレに沿って、シェアしたい内容を記述していく。ナレッジに昇華したいものは、Issueにして対応してたりする。 AI-assisted Dev Review の具体的なやり方は？ AI-assisted Dev Review 1

Slide 28

Slide 28 text

一覧をチラ見せ・SDD（仕様駆動開発）なツールを使ってみる話・Claude Code subagents, Agent Skillsを改善する話・コンテキストマネジメントの話・Nano BananaでSlackスタンプ作ってる話などなど、多種多様。ざっくり、10件/月くらいで増えていっている。 AI-assisted Dev Review で話されている内容は？ AI-assisted Dev Review 1

Slide 29

Slide 29 text

AI-assisted Dev Review とナレッジマネジメント AI-assisted Dev Review 1 共同化（暗黙知→暗黙知）：個々人のAI活用事例や情報のシェア表出化（暗黙知→形式知）：チームとして実務への取り入れ判断連結化（形式知→形式知）：実務での観察から、新しい形式への昇華 ※ここは結構まだ難しく、うまく行っている感覚がない内面化（形式知→暗黙知）：実務で実行した結果を、個人レベルで内省

Slide 30

Slide 30 text

AI-assisted Dev Review とナレッジマネジメントの一例 AI-assisted Dev Review 1 共同化（個々人のAI活用事例や情報のシェア）： Claude Code の subagent / Agent Skills 書いてみたんだけどちょっと適当かも表出化（チームとして実務への取り入れ判断）： subagent / Agent Skills をfrontend/backendのシニアEngがそれぞれ書いてみる連結化（実務での観察から、新しい形式への昇華）： ubagent / Agent Skillsの設計が結構違う（が、これはこれで観察したい）内面化（形式知→暗黙知）：いまの状態で実務で使うとどうなるか試してみよう

Slide 31

Slide 31 text

めんどくさい・難しいと形骸化しやすいので、シンプルすぎるくらいでゆるく始めるのがちょうどいい。長く続けるほうが圧倒的に大事。 AI-assisted Dev Review で工夫していること AI-assisted Dev Review 1 ● テンプレを用意して書き方を迷わせない ● 実行結果の効果にはこだわらない ● 情報提供のみにも価値があるとみなす ● 実装とは関係ないAI活用例も集める KISSの原則（Keep It Short and Simple）で保つ

Slide 32

Slide 32 text

レビューケース 1 : Fail Fast な具体例 AI-assisted Dev Review 1 claude-code-spec-workflowを使ってみた・SDDの実証実験のひとつ・実務で導入したみた結果をレポート　・使い方　・フロー　・出力結果（と、修正）　・残課題良い面もあったが、チームの開発スタイルに合わない面もあることもわかった

Slide 33

Slide 33 text

レビューケース２ : 共同化の具体例 AI-assisted Dev Review 1 Claude Code で使われているコンテキストを確認・初期状態でも意外と使っていることがわかる・MCPが想定よりコンテキストを使ってそう・利用頻度の低いMCPをdisabledにし解決シェアした結果・メンバーも必要に応じenableにしてたことが判明残課題・MCPの動的ロードできるといいな...

Slide 34

Slide 34 text

レビューケース３ : 進化の速さを体感する例 AI-assisted Dev Review 1 先ほどの課題(MCPの動的読み込み不可)に対し、本日発表された Tool Search を使うと MCPツールを動的にロードできるになった。 ref: https://x.com/bcherny/status/2011558438355268060?s=20

Slide 35

Slide 35 text

１．シェアされた情報に、他メンバーがのっかりやすい　　他のメンバーからの関連情報がシェアされ、理解が進むことがある２．チームで適用するか？その場で決まる　　サービスチームのEngが全員いるので、対話の中で実行是非の意志決定が速い　　チームとして意見が反映されるので、施策のエントロピーが爆発しない３．他チームにおいても関心が高まる　　この取り組みは、EMs内でもシェアされ、EMから他チームへ共有もされる　　その結果、他チームにおいて関心が高まる（社内の事例は信頼されやすい） AI-assisted Dev Review の効果は？ AI-assisted Dev Review 1

Slide 36

Slide 36 text

４．メンバー間のAIに対するスタンス（興味・関心）が表出する　　どういうところから、どんなの情報収集しているのか？（Xの住民度がわかる）　　どれくらいローカル環境で試せているのか？　　AI/LLM やそれらを取り巻くツールに対する個々人の印象を知ることができる５．どれくらいAI/LLMに対して取り組んでいるのか？が、チームとして可視化される　　やってみたけどダメだったことがわかることは、とても大事　　試行回数が増えていればいるほど、AIへの抵抗が少なくなり当たる確率も上がる AI-assisted Dev Review の効果は？ AI-assisted Dev Review 1

Slide 37

Slide 37 text

まとめ

Slide 38

Slide 38 text

人間とAIが協業する未来を見据え、チームでAI活用リテラシーを底上げしていく・開発スピードと質を両立するには、人がAIを使う回数・時間を増やす　・人の練度に投資する・AI時代の進化の早さに起因する情報過多で疲弊しない仕組みづくり　・個人ではなく、チームで行うことが重要・実務の中でAIを使い、Fail Fastでリアルな判断をする回数を増やしていく　・知らないものは使えない、だから試行回数を増やす自分が考える、AI時代の開発戦略みんなでAI上手ピーポーになろう！ 1

Slide 39

Slide 39 text

自分が考える、AI時代の開発戦略みんなでAI上手ピーポーになろう！ 1 AI時代は、特定のツールや手法に依存した開発戦略は風化が早く、やってみて初めてわかることが多い。だからこそ、実務の中で開発戦略自体の保守性や柔軟性と、人・チームのAI活用リテラシーの向上に投資しつづけることが、複利のように後々の開発スピードと品質に効いてくる(はず)。

Slide 40

Slide 40 text

最後に、AI上手ピーポー is 何？みんなでAI上手ピーポーになろう！ 1 AIと協業し実務の中で実行力を上げていく人を＼ AI上手ピーポー／と呼んでますw

Slide 41

Slide 41 text

参考文献 Appendix 1 書籍：　・生成AI「戦力化」の教科書　著：松本勇気 Podcast：　・fukabori.fm 131. AIコーディングの現在地 w/ twada