AIコーディングエージェントを「使いこなす」ための実践知と現在地 in ログラス / How to Use AI Coding Agent in Loglass

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2024 Loglass Inc. 4 「私たちが知っているプログラミングの終焉」 https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/ ● AI時代のプログラマは「コードを書く人」から「 AIを活用し業務設計する人」へと役割が変化 ● AIによる自動化が進む中でも、人間が「最後の 30%」を補完しなければならず、熟練したプログラマーの知識が依然として不可欠 ● プログラマーの役割は変わるが、AIが新たな需要を生み出し、より多くの人が「 AIを活用したプログラミング」に携わるようになる

Slide 6

Slide 6 text

© 2024 Loglass Inc. 5 過去30日間に書かれたAPEXコードの約20%がAgentforce（AI） https://venturebeat.com/ai/this-ai-already-writes-20-of-salesforces-code-heres-why-developers-arent-worried/ ● 「Vibe Coding」の登場、AI生成コードには新しい品質管理が必要 ● アルゴリズム的思考や小さな問題に分解する能力などは変わらずに重要 ● 開発者は「実装者」から「戦略家・パイロット」へ ○ “何を作るか ” と “どう品質を守るか ” に重点を移していく ● AIエージェントを監督・指導する立場となり、最終的な成果物に対する責任を負う ● これは職の喪失ではなく、役割の「超越（transcendence）」

Slide 7

Slide 7 text

© 2024 Loglass Inc. 6 https://venturebeat.com/ai/this-ai-already-writes-20-of-salesforces-code-heres-why-developers-arent-worried/ “Are you going to build the next-generation database with vibe coding? Unlikely. But could you build a really cool UI that makes database calls and creates a fantastic business application? Absolutely.” 訳）「バイブコーディング "で次世代データベースを構築する？ありえない。しかし、データベースを呼び出し、素晴らしいビジネス・アプリケーションを作成する、本当にクールなUIを構築できるだろうか？もちろんだ。

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2024 Loglass Inc. 9 Cursorアカウントを全開発者に配布してみて ● Cursorの利用者・頻度は順調に増加（8割以上が毎日利用、IntelliJと並行稼働） ● デザイナーやQAメンバーによるRules整備やCursor活用の模索も生まれている https://speakerdeck.com/yuitosato/how-to-create-a-culture-of-using-ai-agents-in-a-50-person-organization

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2024 Loglass Inc. 13 AIコーディングエージェントを使う文化を作る https://speakerdeck.com/yuitosato/how-to-create-a-culture-of-using-ai-agents-in-a-50-person-organization ● 「トップダウン“だけ”でもボトムアップ“だけ” でも炎は広がらない」 ● 配布 → トレーニング → 専用Slack → ルールDocsを1か月内に一気に整備。 ● 週1回 “自分でコードを書かない” 縛りで実タスクを解く。ワイガヤでノウハウを共有

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2024 Loglass Inc. 19 AIコーディングエージェントを育成する「.mdcでAIを“社内ルールを一部知っている ”状態に育成」 AIは多くのことを知っているが逆に実業務においては知っておいて欲しい事を知らない社内や暗黙知として存在する知識を継続的に与える・学ばせ続ける https://speakerdeck.com/yodakeisuke/dot-mdc-driven-knowledge-management

Slide 21

Slide 21 text

© 2024 Loglass Inc. 20 AIコーディングエージェントを育成する「.mdcでAIを“社内ルールを一部知っている ”状態に育成」 AIは多くのことを知っているが逆に実業務においては知っておいて欲しい事を知らない社内や暗黙知として存在する知識を継続的に与える・学ばせ続ける https://speakerdeck.com/yodakeisuke/dot-mdc-driven-knowledge-management 特にプロダクト特有のドメイン知識さらには規約やお作法

Slide 22

Slide 22 text

© 2024 Loglass Inc. 21 AIコーディングエージェントを育成する「.mdcでAIを“社内ルールを一部知っている ”状態に育成」 AIは多くのことを知っているが逆に実業務においては知っておいて欲しい事を知らない社内や暗黙知として存在する知識を継続的に与える・学ばせ続ける https://speakerdeck.com/yodakeisuke/dot-mdc-driven-knowledge-management ファジーにルールを扱えることの強さ e.g. 「PRの変更行数は200行を目安に」（その分だけ発生するゆらぎやブレをどうコントロールするか？）

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2024 Loglass Inc. 23 AIコーディングエージェントのガードレール変わらないガードレールとしての型・自動テスト・ Lintの重要性は今までコードで規定していた制約を自然言語で実現可能に。多少の揺れと幅を許容できるのはメリットもデメリットもある = ”決定論的な”制約の表現・検証方法との使い分け自動テストや型、静的解析ツールの資産はガードレールとして使える。自動テスト・関数型などの文化が整っていたおかげで一定やりやすかった

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2024 Loglass Inc. 25 v0のEval Driven Development https://vercel.com/blog/eval-driven-development-build-better-ai-faster テストではなく評価（ Eval）が開発サイクルの主役プロンプト変更やモデル更新を合格率という数値ゲートで判定し、失敗例を評価セットへ追加して学習ループを回し続ける修正→評価→改善→再評価のループ

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2024 Loglass Inc. 35 AIアクセシビリティ、AIリーダブルの向上まだまだAIからアクセス不能になってる既存資産が多い Notionを代表に活用しきれていないドキュメントが存在。プロジェクト・チームによっては、仕様ドキュメントのGitHub管理やドキュメント自動生成のトライ中短期ではMCPサーバー内製の必要も一定感じるドメインモデリング図なども扱えるようにしていきたいが、取り扱いコストが高いマークダウン等のシンプルテキストで表記されていることの価値が高くなっている

Slide 37

Slide 37 text

© 2024 Loglass Inc. 36 ルール改善プロセスのアップデート Meta‑Rule (ルールを評価するルール )や、複数モデルの実行・結果を評価する仕組みなど ● ルールを評価する仕組みや評価セットの需要 ● ルールの中にもタイプ・分類がある、それぞれ評価や動作確認の仕方が変わりうる ● 同一ルールでもモデル毎に挙動は変わりうる ○ e.g. 「Playwright MCPでの画面テストがモデルによっては上手く動かない」、「必ずxxxをさせるルールで必ず実行されていることを確認する」 ○ 例えば、規約やMCP操作を行うルールであれば、可能な限り同じ/正確な挙動をして欲しい ○ 手動で細かく修正・モデル変更を繰り返すのは辛い...！ ● 現時点ではRules/コンテキストが増えすぎても性能は劣化しがち

Slide 38

Slide 38 text

© 2024 Loglass Inc. 37 ルールの分類（例）名称主眼カテゴリ例ルール例 Quality Basis コード品質スタイル / Lint / フォーマット Prettier相当のimport並び順デグレ防止「既存xxxxxを壊す変更は禁止」 Architecture 構造保全レイヤ責務「service層から直接dbへのアクセス禁止」依存ライブラリ制御「暗黙依存ではなくDI経由で」 Domain 業務知識ドメイン知識 / ユビキタス言語「net_sales = quantity × unit_price」 UI/UX 用語統一「“Investors” を必ず “IR投資家” と訳す」 Workflow 開発プロセス Pull‑request テンプレ / チケット連携「AI が書いたコミットには ai: prefix」 Meta‑Rule（ルール自体の管理）古い/未使用ルールを 90 日ごとに警告

Slide 39

Slide 39 text

© 2024 Loglass Inc. 38 自動化された改善プロセス Devinのナレッジが自動で増えていく体験は GOOD 利用を続けていれば勝手に”育っていく”体験ルールやドキュメント、ワークフロー化の拡充は開発者の善意と気づきで行われているが、自動化・仕組み化の余地を探したい（e.g.コード<->仕様ドキュメントの相互更新、Slack/PR等からのルール自動提案、自社環境/ タスクにおける最適モデルの発見） LLM As a JudgeやEval Driven Developmentの考えは一定は転用可能と考えている（ので試行錯誤していきたい）

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© 2024 Loglass Inc. 40 AI-based operations from scratch. https://hrmos.co/pages/loglass/jobs/1813462408235663396144 いかにAI前提の業務フローを構築、試行錯誤できるか？開発組織に限らず、AI前提の業務プロセスを構築できるかが競争力に直結する時代ログラス社も“AIが活躍することを前提とした業務そのものの再設計”するJDを公開開発組織に限らず、AI前提での業務のあり方の探索が求められる

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 2024 Loglass Inc. 42 まとめ ● ログラス社のAIコーディングエージェント活用の取り組みについて紹介 ● 利用が当たり前の文化は一定生まれたと言っても良さそう ● これからは、”AIコーディングエージェントの活躍の場を増やす”ための工夫が求められている ○ e.g. 既存ドキュメント資産の再利用性、コーディングタスク以外での活用、ソフトウェア開発プロセス全体での活用、etc… ● AIコーディングエージェントによる割れ窓の拡散問題にも向き合う必要がある ○ “どう品質を守るか” 、レビュー・テスト・評価の重要性 ● サーバーサイドKotlin問題は、Jetbrains社のJunieに期待

Slide 44

Slide 44 text