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

2026/01/15
【AI時代の開発戦略】開発スピードと品質の両立に向けて ー 3社エンジニアの事例から学ぶ
https://enechange-meetup.connpass.com/event/377158/

みんなでAI上手ピーポーになろう！

鈴木健太郎
エンジニアリングマネージャー

Transcript

1. みんなでAI上手ピーポーになろう！ 2026.01.15【AI時代の開発戦略】開発スピードと品質の両立に向けて ー 3社エンジニアの事例から学ぶ すずけん / @szk3 AI-Assisted Dev Review の実践
2. 1. 自己紹介 2. 本日お話すること / しないこと 3. AI時代における開発スピードと品質の役割分担 4. AI時代の開発戦略 5. AI-assisted Dev Review 6. まとめ みんなでAI上手ピーポーになろう！ 本日の流れ 1
3. はじめに
4. 1 4 自己紹介 本日の登壇者 経歴 前職にてフロント・バックエンド・インフラ・ネイティ ブアプリ・EMなど一通り経験した後に、パブリックク ラウド活用のスペシャリストとして、AWS移行やCCoE の組成などを牽引。2022年10月にカミナシに入社。 カミナシでの仕事 クラウド・インフラロールのICとして、技術負債解消や サービスチームでの開発に従事した後、新規事業「カミ ナシ 設備保全」にて、プレイングマネージャー型のEM を実践中。 株式会社カミナシ エンジニアリングマネージャー 鈴木 健太郎 (すずけん) szk3
5. みんなでAI上手ピーポーになろう！ 本日お話すること / しないこと 1 本日お話すること 開発スピードと品質の両立の為に、チームでAI活用レベルを向上させることの重要 性と、その具体的な取組みについて - AI-Assisted Dev Review の実践 本日お話しないこと ・AIを使った特定の開発手法に特化した施策の紹介
6. AI時代における 開発スピードと品質の役割分担
7. 人とAIが「開発スピード」や「品質」にもたらす役割は、適材適所で分担するのが良いと される。 「AI時代における開発スピードと品質」の役割分担 AI時代における開発スピードと品質の役割分担 1 → 開発（実装）の出力は、AIに委託する → 品質（保守性、正解）の定義は、 　 人がAIと伴走しながら作り上げる 開発スピードの向上は、AIの得意な役割 品質の向上は、人間が意志決定する領域
8. AI/LLMは、個人と比べて知識量は多いが、応用するセンスは（指示がなければ）ない。 LLMは世の中の一般的な知識に詳しくそれを使うのが得意だから、一般的な開発（実装） は、AIの得意な領域なので委託したほうがスピードは上がる。 残念ながら、技術がコモディティであるほどAIコーディングエージェントによる実装は速く、人がAIに 敵うのは難しい。難しいドメインやコンテキストが必要な実装であれば人が書いたほうが良いケース も一定存在するが、遅かれ早かれ一般的なサービス開発において人がコードを書く機会は減っていく 未来になると想像できる。 開発スピードの向上は、AIの得意な役割 AI時代における開発スピードと品質の役割分担 1
9. 人は、LLMと比べて知識量は足りないが、応用するセンス（現況への適用能力）がある。 環境やコンテキストが同じことがないという前提で、その場・その時・そのコードや開発 戦略に対して、品質が高いという判断基準は人間がデザインするのが望ましい。 AI/LLMの出力精度が上がっているからといって、ノールックでOKというのは品質を判断していないと 同義（同じノールックでも Ralph Wiggum loop みたいな収束のさせ方はちょっと別で考えるけど）。 品質の向上は、人間が意志決定する領域 AI時代における開発スピードと品質の役割分担 1
10. LLMモデル自体を 不変 であるとし、人のふるまいを 可変 と捉えると、 人がやるべきことが見えてくる。 人とAIの協業をデザインする AI時代における開発スピードと品質の役割分担 1 • AIを迷わせないように、AIにとってわかりやすい方針を作る • 品質・正解を、定義・計画する • コンテキスト（その場、その時、そのコードや開発戦略）をAIにインプットする • 様々な手法を、実務の中で実行してみる etc 例えば...
11. 人の責務は、AIを現状の開発スタイルにオンボーディングさせること。 人とAIの協業をデザインする AI時代における開発スピードと品質の役割分担 1 生成AI「戦力化」の教科書: P57.より引用 つまり、現在のコンテキストを整理し、土台にあるLLMの原理を理解した上でLLMをバックグラウン ドに動くツールのふるまいや出力に対する理由を考え、それを新しい出力の質に転化させるルールに 落とし込む必要がある。 LLMも人間が意図的にオンボーディングする必要があるのです。 “
12. AI時代の開発戦略
13. このAI時代、サービス/プロダクト/ソフトウェア開発に対し、 誰もがパラダイムシフトを感じている。 不確実性の高い未来に向けて、現状に旗を立てるなら、不変な事実を整理し 拠り所にしたい。 まず、AI時代の事実を整理する AI時代の開発戦略 1
14. 現時点において自明なこと AI時代の開発戦略 1 ❷ AIの基盤となるLLMにも限界がある ❸ LLMにとって入力(コンテキスト)が、出力(推論結果)の質の源泉になる ❹ AI/LLMに最初の指示を出すのは人である（現時点ではね...） ❶ AI/LLMを取り巻く環境は、昨今類をみないスピードで進化している
15. 「〇〇にBetする」とよく聞くものの、実際の開発現場においては というような新しい課題が生まれている。 早すぎる進化がもたらす新たな課題 １．AI/LLMを取り巻く環境は、昨今類をみないスピードで進化している 1 • 特定のフレームワーク・ツール・モデルにコミットしづらい力学が働きやすい • 今日のべスプラは、明日のベスプラではない可能性のほうが高い • 個人でキャッチアップした情報がチーム戦に活かしにくい（情報格差がある）
16. 絶えず生まれつづけるベスプラは、自分たちの眼の前の課題を全て解決してくれるよ うに見えることがある。 しかし、「うまくいきそうだという感覚」と「実際にやってみた」では結構な差が生 まれることがある。 だからこそ、AI/LLMの活用は、今直面している既存環境（Brown field）で試さないと 本当のところはわからない。（Forward Deployed Engineer のような職種が注目される背景の ひとつだと感じる） 隣の芝生（べスプラ）は青いのか？ 1 １．AI/LLMを取り巻く環境は、昨今類をみないスピードで進化している
17. AIの根幹にあるLLMも万能に見えるが、限界も存在する。 代表的なものとして、この３つが挙げられる。 AIの基盤となるLLMにも限界がある ２．AIの基盤となるLLMにも限界がある 1 ❶ 一度に渡せるコンテキストは有限 ❷ LLMは確率的（非決定性が高く、出力はガチャ） ❸ 嘘をつく（ハルシネーション）
18. LLMが嘘をつく(様に見える)のは、確率的だから 　→　正しい出力の発生確率が低いのは、入力(コンテキスト)の質が悪いから つまり、コンテキストが出力(推論結果)の質を向上する鍵になる 　 LLMの限界の相関性 ２．AIの基盤となるLLMにも限界がある 1 • コンテキストが多すぎる • コンテキストが少なすぎる • 誤ったコンテキストを渡している
19. どれだけLLMの出力が速く大量に出たところで、出力の方向が間違っていたら意味が ない。 つまり、LLMを基盤とするAI機能が気持ちよく正しい方向に走れるレールの質を高め ることが、AI時代の開発戦略として、「開発スピードと質」に貢献する一つの要素で ある。 そのレールの質を高めるには、AI/LLMのお気持ちを察することが必要であり、そのた めに原理を理解し、入力（コンテキスト）をエンジニアリングすることはとても重要 だと感じる。 Prompt Engineering から、Agentic Context Engineering へ ３．LLMにとって入力(コンテキスト)が、出力(推論結果)の質の源泉になる 1
20. 一方でコンテキストエンジニアリングは、LLMの非決定性の出力の都合上、成果を判 断するのが難しい。（トークンが減ったとかはわかりやすいけど） とはいえ、Engメンバー全員からの意見を集めることで、コンテキストエンジニアリ ングの成果の確からしさを定性的に確認することはできる。 コンテキストエンジニアリングは成果を判断するのが難しい ３．LLMにとって入力(コンテキスト)が、出力(推論結果)の質の源泉になる 1
21. AIの出力の質は、人のAI活用リテラシーに依存する LLM をベースとしたAIツールやそのエコシステムのトレンドの変化はあまりに早すぎる。 問題は、それらを使う人・チームがその進化に追くのが難しいということ。 また、AIと協業する為のリテラシー（意志決定力・判断力）は一朝一夕では身につかない。 だからこそ、AI/LLM周りのリテラシーを底上げするような、泥臭く地味な取り組みが、人 とAIの協業への投資となり効果を発揮するはず。 ４．AI/LLMに最初の指示を出すのは人である 1
22. AI時代の開発戦略 まとめ 人がAIと協業する試行回数を高め、実務での判断力・応用力を養い、それをチームに 還元するような仕組みを作り、オーナーシップを持って推進していくことが大事。 1 オーナーシップ • AIに正しい方向性で出力してもらう為に人が何をすべきか？の試行回数を増やす • 速すぎるAI/LLMの進化への追従に、個人で疲弊しないようにする • 実務におけるAI活用実例をシェアし、チームのAI活用リテラシーを上げる AI時代の開発戦略
23. AI-assisted Dev Review
24. AI-assited Dev Reviewとは、自サービスチームのEngメンバーに向けた、AI/LLM活用 のリテラシーの向上に投資する開発戦略のひとつ。 具体としては、ただのEng向け定例MTG。 手法としては、ナレッジマネジメントの型をカジュアルに取り入れている。 AI-assisted Dev Review とは？ AI-assisted Dev Review 1
25. 野中郁次郎先生が提唱した概念で、SECIモデル（共同化・表出化・連結化・内面化） を理論的基盤とし、暗黙知を形式知に変えることで、属人化の解消や人材育成、競争 力強化につなげることができる。( 詳しくは、いろんな書籍がでていますので、そちらを参照してください。) ナレッジマネジメント とは？ AI-assisted Dev Review 1
26. 昨今の早すぎるAIの進化に取り残されず、かといって過度に先端を行き過ぎて消耗せ ずに、AIを使ったサービス開発のスキルを向上させて、ソフトウェアエンジニアとし ての生存率をあげること。 AI-assisted Dev Review の目的は？ AI-assisted Dev Review 1
27. 具体は、めちゃくちゃシンプル。 サービス開発を通じて、さまざなAI（Gemini, Claude Code , GitHub Copilot, NotebookLM etc...) を使った開発効率の向上のための取り組みや工夫をシェアするた めの定例MTGを行っているだけ。 議論のネタは、NotionのDBテンプレに沿って、シェアしたい内容を記述していく。 ナレッジに昇華したいものは、Issueにして対応してたりする。 AI-assisted Dev Review の具体的なやり方は？ AI-assisted Dev Review 1
28. 一覧をチラ見せ ・SDD（仕様駆動開発）なツールを使ってみる話 ・Claude Code subagents, Agent Skillsを改善する話 ・コンテキストマネジメントの話 ・Nano BananaでSlackスタンプ作ってる話 などなど、多種多様。 ざっくり、10件/月くらいで増えていっている。 AI-assisted Dev Review で話されている内容は？ AI-assisted Dev Review 1
29. AI-assisted Dev Review とナレッジマネジメント AI-assisted Dev Review 1 共同化（暗黙知→暗黙知）：個々人のAI活用事例や情報のシェア 表出化（暗黙知→形式知）：チームとして実務への取り入れ判断 連結化（形式知→形式知）：実務での観察から、新しい形式への昇華 ※ここは結構まだ難しく、うまく行っている感覚がない 内面化（形式知→暗黙知）：実務で実行した結果を、個人レベルで内省
30. AI-assisted Dev Review とナレッジマネジメントの一例 AI-assisted Dev Review 1 共同化（個々人のAI活用事例や情報のシェア）： Claude Code の subagent / Agent Skills 書いてみたんだけどちょっと適当かも 表出化（チームとして実務への取り入れ判断）： subagent / Agent Skills をfrontend/backendのシニアEngがそれぞれ書いてみる 連結化（実務での観察から、新しい形式への昇華）： ubagent / Agent Skillsの設計が結構違う（が、これはこれで観察したい） 内面化（形式知→暗黙知）： いまの状態で実務で使うとどうなるか試してみよう
31. めんどくさい・難しいと形骸化しやすいので、シンプルすぎるくらいでゆるく始める のがちょうどいい。長く続けるほうが圧倒的に大事。 AI-assisted Dev Review で工夫していること AI-assisted Dev Review 1 • テンプレを用意して書き方を迷わせない • 実行結果の効果にはこだわらない • 情報提供のみにも価値があるとみなす • 実装とは関係ないAI活用例も集める KISSの原則（Keep It Short and Simple）で保つ
32. レビューケース 1 : Fail Fast な具体例 AI-assisted Dev Review 1 claude-code-spec-workflowを使ってみた ・SDDの実証実験のひとつ ・実務で導入したみた結果をレポート 　・使い方 　・フロー 　・出力結果（と、修正） 　・残課題 良い面もあったが、チームの開発スタイルに 合わない面もあることもわかった
33. レビューケース２ : 共同化の具体例 AI-assisted Dev Review 1 Claude Code で使われているコンテキストを確認 ・初期状態でも意外と使っていることがわかる ・MCPが想定よりコンテキストを使ってそう ・利用頻度の低いMCPをdisabledにし解決 シェアした結果 ・メンバーも必要に応じenableにしてたことが判明 残課題 ・MCPの動的ロードできるといいな...
34. レビューケース３ : 進化の速さを体感する例 AI-assisted Dev Review 1 先ほどの課題(MCPの動的読み込み不可)に対し、 本日発表された Tool Search を使うと MCPツール を動的にロードできるになった。 ref: https://x.com/bcherny/status/2011558438355268060?s=20
35. １．シェアされた情報に、他メンバーがのっかりやすい 　　他のメンバーからの関連情報がシェアされ、理解が進むことがある ２．チームで適用するか？その場で決まる 　　サービスチームのEngが全員いるので、対話の中で実行是非の意志決定が速い 　　チームとして意見が反映されるので、施策のエントロピーが爆発しない ３．他チームにおいても関心が高まる 　　この取り組みは、EMs内でもシェアされ、EMから他チームへ共有もされる 　　その結果、他チームにおいて関心が高まる（社内の事例は信頼されやすい） AI-assisted Dev Review の効果は？ AI-assisted Dev Review 1
36. ４．メンバー間のAIに対するスタンス（興味・関心）が表出する 　　どういうところから、どんなの情報収集しているのか？（Xの住民度がわかる） 　　どれくらいローカル環境で試せているのか？ 　　AI/LLM やそれらを取り巻くツールに対する個々人の印象を知ることができる ５．どれくらいAI/LLMに対して取り組んでいるのか？が、チームとして可視化される 　　やってみたけどダメだったことがわかることは、とても大事 　　試行回数が増えていればいるほど、AIへの抵抗が少なくなり当たる確率も上がる AI-assisted Dev Review の効果は？ AI-assisted Dev Review 1
37. まとめ
38. 人間とAIが協業する未来を見据え、チームでAI活用リテラシーを底上げしていく ・開発スピードと質を両立するには、人がAIを使う回数・時間を増やす 　・人の練度に投資する ・AI時代の進化の早さに起因する情報過多で疲弊しない仕組みづくり 　・個人ではなく、チームで行うことが重要 ・実務の中でAIを使い、Fail Fastでリアルな判断をする回数を増やしていく 　・知らないものは使えない、だから試行回数を増やす 自分が考える、AI時代の開発戦略 みんなでAI上手ピーポーになろう！ 1
39. 自分が考える、AI時代の開発戦略 みんなでAI上手ピーポーになろう！ 1 AI時代は、特定のツールや手法に依存した開発戦略は風化が早く、やってみて初めて わかることが多い。 だからこそ、実務の中で開発戦略自体の保守性や柔軟性と、人・チームのAI活用リテ ラシーの向上に投資しつづけることが、複利のように後々の開発スピードと品質に効 いてくる(はず)。
40. 最後に、AI上手ピーポー is 何？ みんなでAI上手ピーポーになろう！ 1 AIと協業し実務の中で実行力を上げていく人を ＼ AI上手ピーポー／ と呼んでますw
41. 参考文献 Appendix 1 書籍： 　・生成AI「戦力化」の教科書　著：松本勇気 Podcast： 　・fukabori.fm 131. AIコーディングの現在地 w/ twada