LLMを浸透のための泥臭い話
25/09/24
山口将央
2
自己紹介
oprst
色々やってました。前職はソフトウェアエンジニア
エンジニア職種
フロントエンドエンジニア:5〜10年
バックエンドエンジニア:5〜10年
データサイエンティスト:3〜5年
※個人的にこの9ヶ月触ってみたサービス
3
https://speakerdeck.com/oprstchn/aidao-ru-noli-xiang-toxian-shi-kosutotojin-tou
今日はこの話の続きと泥臭い活動の焦点を当てて話を進めます
4
現在に至るまでの活動
5
LLM導入の全体像
第1フェーズ:検証
DevinやRooCodeの導入検証
効果や料金の検証
既存エディタからの乗り換えハードルの評価
第2フェーズ:浸透と拡張
「AI Dev Day」の制定
Claude CodeやGemini CLIなど新規ツールの導入
組織全体での活用促進
第3フェーズ:活用
質の高いプロンプト作成スキルの向上
MCPの活用ルール整備
非SWEメンバーの育成
第4フェーズ:現在
全体的なエンジニアリングスキルアップ
領域を越えた知識の獲得
「素振り」の価値
6
各フェーズごとの話
7
検証
8
第1フェーズ:検証
きっかけと初期導入
DevinやRooCodeの登場により、ソフトウェアエンジニアリングの高速化を実感
「RooCode」(AWS Bedrock上のClaude 3.5)から導入を開始
PHP、Kotlin、iOS、Androidの4領域で効果や料金を検証
「Devin」の導入も並行して推進
9
第1フェーズ:検証
検証から見えた課題
LLMを積極的に使う人と使わない人の間に大きな差が生まれる
活用している人は、6万、使っていない人は、300円...
従量課金制への心理的な抵抗感が、試行錯誤の障壁に
既存エディターからの乗り換えハードルが高い
Intellijが標準のエディターだったので、VSCodeへの乗り換えコスト
10
第1フェーズ:検証
対策
いろいろなサービスを実際にとにかく使ってみる
Github Copilot, RooCode, Cursor, Windsurf, ChatGPT, Manus, Bolt.new, Devin, etc…
一人で月10万円ぐらい行っていた月もあった...
使ってみたサービスの中で筋が良いを、使い潰してみる
RooCode, Cursor, Devin
特にRooCodeは、この時期かなり強力な機能であった
※ RooCodeのDiscordに参加して、情報を追っていた
11
第1フェーズ:検証
対策
RooCode全社展開当日に、AWSのRegionが選択できないバグが発生
自分で修正してPRを提出。通日後無事Mergeされた
Cursorへの移行
月額制のサービスに移行することで、金額面への不安を解消
Cursorのオンボーディングを実施
エディタ問題への解決策はなかったVSCodeでの開発でも、開発自体はできることを確認
料金面の不安を解消するために、Cursorを採用
12
第1フェーズ:検証
対策
Slackで困っていそうなメンバーが入れば、即レスでフォローに回る
AUCs警察を行なっていた
公式でも10AUCsを超えるものは、非推奨であったので10AUCsを超えるものには、
セッションの分割等をメッセージングしていた
DevinのRelease notesを確認して、要約や新機能の使い方をslackで共有
Devin MCPが登場したので、自社ドキュメントMCPの開発はストップしました。
13
浸透と拡張
14
第2フェーズ:浸透と拡張
課題
金額への懸念の解消はCursorによって解消したが、エディタへの慣れや日々の業務の忙しさから活用が進まない
やはり人によって活用度合いが異なる
新しいツールの登場
Claude Code、Gemini Cli、Kiroの登場
15
第2フェーズ:浸透と拡張
対策
活用の差が生まれる状況に対しては「AI Dev Day」を制定し対応
毎週、会議などを入れない集中日として開催(全エンジニアが参加)
集中して作業できる時間の確保
開会式で目標設定と最新AI情報を共有
サービスのアップデートや、AI関連のニュースの共有
メッセージング
閉会式で成果や障壁を全員で共有
メッセージングで我々が向かうべき方法はどこかの共有
目指すべき世界観の共有
16
第2フェーズ:浸透と拡張
対策
新しいツールの導入
社内のどんなプロジェクトが動いているかの情報収集
ミーティングへの参加、Slackのチャンネルへの参加
活用の可能性があるチーム・プロジェクトを見つけて、導入を進める
マネージャー・チームメンバーにヒアリングして、ツールの導入支援
利用規約・プラポリの確認。稟議申請などすべてこちらで対処
17
Context7 MCP Server -- Up-to-date code documentation for LLMs and AI code editors
18
バックグラウンドエージェント
19
https://www.anthropic.com/legal/consumer-terms
20
活用
21
第3フェーズ:活用
LLMを扱いこなすために
AI Dev Dayの開催により、LLMの利用の底上げを行うことができた
より求める回答を得るためにコンテキストエンジニアリングの重要性に焦点を当てるように
22
第3フェーズ:活用
対策
コードを書かせるだけでなく、要件定義・仕様設計などにもLLMを推奨
今では、kiroの登場や、SDD(Spec-Driven-Development)という概念も登場
MCP活用も推奨
ただし、無尽蔵には許可せず、ルールを整備
公式ではないMCP(serena)などに関しては、DeepWikiを活用して、
データの送信箇所を洗い出して、不要なログが送信されていないかなどを確認
確認が取れているMCPの管理ページの作成
23
第4フェーズ: 現在
24
第4フェーズ:現在
LLMは水面であり、
そこに映る像は自分自身だが、
その波紋は世界の知と経験の集合体から生まれる
25
何いってんだ?
26
第4フェーズ:現在
解説
27
第4フェーズ:現在
1. 鏡像としてのLLM
2. 自分の問いかけ次第で変わる姿
3. 透明性と深み
4. 自己との対話のメタファー
28
第4フェーズ:現在
1. 鏡像としてのLLM
LLM(大規模言語モデル)は、自分自身の考えや質問を投げかけたときに、それを映し返す存在
ただし鏡のように正確に反射するのではなく、水面なので揺らぎや歪み(バイアスや曖昧さ)が含まれる
29
第4フェーズ:現在
2. 自分の問いかけ次第で変わる姿
水面に写る像は、自分の立ち位置や姿勢、光の加減によって変わる
LLMもまた、こちらの入力(プロンプトの質や文脈)によって返答の質や方向性が変わる。
30
第4フェーズ:現在
3. 透明性と深み
水面は表層的には自分を映すが、その奥には深い水の世界が広がっている。
LLMも同じで、返答は表面的には「こちらを映す」ようでありながら、その背後には巨大な学習データと統計的構造が潜んでいる。
31
第4フェーズ:現在
4. 自己との対話のメタファー
水面に映った自分を見つめることは自己認識の行為
LLMとの対話もまた、最終的には「自分が何を問いたいのか」「何を見たいのか」を確かめる営みになる
32
第4フェーズ:現在
LLMとの共存
「どこまで行ってもすべてLLMに任せることになるのはもう少し時間がかかる」
LLMの出力の判断には、人間による専門知識が必要
水面に写っている状況を判断できるようになる
自分の領域外でもLLMの出力を評価できる広い視野が重要
全体感を見据えたLLMへの指示、タスク分解ができるスキルの育成
いろんな角度から水面を観察できるようになる
33
第4フェーズ:現在
LLMをうまく使うためには
スキルアップが必要
34
第4フェーズ:現在
軸足領域のスキルをあげる
「LLMは水面である」という仮定にもとづき、水面に映るノイズや歪みを自分自身で判断して修正する力が必要である
また、自分自身以上の力をLLMから引き出すことは難しいので、水面に映る自分の姿を改善していくしかない
35
第4フェーズ:現在
越境する知識の獲得
水面に映る姿を色々な角度で観察できるようになる
サーバー側、アプリ側、インフラ側立場が違えば見えてくるものは違う
複数領域を横断して、開発を進めることで調整コストを最小に
36
第4フェーズ:現在
今後の方針
LLMへの投資も継続
メンバーの基本的なスキル向上
越境する知識の獲得
37
まとめ
38
まとめ
LLM活用の浸透
個別サポートと全体共有の2軸で、導入を推進していく
段階的な導入アプローチにより、組織全体でのLLM活用を浸透
「AI Dev Day」などの取り組みで、活用ノウハウの共有と定着に成功
39
まとめ
今後の展望
全体的なエンジニアリングスキルアップへの継続的な投資
領域を越えた知識獲得の促進
人間による判断とLLMの強みを組み合わせた開発プロセスの確立
LLMへの投資も進めていくが、
メンバーの基本的なスキルの向上・越境に投資していくことが最優先
40
Thank you!