Bekind Labs でのAIの活用

Transcript

1. © 2025 Bekind Labs LLC. All rights reserved 1 Bekind Labs での AI の活用 Kentaro Terasaki Software Dev Manager @ Bekind Labs 2026 July
2. © 2025 Bekind Labs LLC. All rights reserved 2
3. © 2025 Bekind Labs LLC. All rights reserved 3 チーム内コラボレーションの変化 Designer / PM こういうのを 作って欲しい Before ・デザインモック ・参考アプリ ・文字による説明 After ・動くアプリ Developer どうやって伝えるか？
4. © 2025 Bekind Labs LLC. All rights reserved 4 AI登場前後の変化 役割の大幅なシフト エンジニアの主要業務はコードの記述から 「レビュー」と「意思決定」へシフト。 従来の開発 手動でのコード記述が主たる業務 AIを利用した開発 設計・コード評価・決定権を担う
5. © 2025 Bekind Labs LLC. All rights reserved 5 よく聞く現場の3つの問い 問1 AIのコード、 そのままマージしていい？ 問2 エージェント、 何本まで同時実行させる？ 問3 AI時代、ジュニアは どうやって育てる？ これらの問いに、どう答えていくべきだろうか？
6. © 2025 Bekind Labs LLC. All rights reserved 6 What is XP? XPの簡単な説明 ビジネス要求の急速な変化に対応し、高品質なソフトウェア を迅速に提供することを追求するアジャイル開発手法。 いつできたのか 1990年代後半、Kent Beck らによって、変化しやすく不確実なソ フトウェア開発を成功に導くために提唱された。 コアとなる3つの構造 抽象的な価値観から具体的な行動へと落とし込む、 3つのレイヤーで定義されている。 Values (価値) → Principles (原則) → Practices (実践)
7. © 2025 Bekind Labs LLC. All rights reserved 7 何を変えるべきで、何を変えないべきか？ Values Principles Practices Communication / Simplicity / Feedback Courage / Respect 人間性、経済性、相互利益、自己相似性、改善、冗長性、品質、な ど… IPM、スモールリリース、シンプルな設計、テスト、リファクタリ ング、ペアプログラミング、持続可能なペース、コーディング標 準、など… 変更なし ？？？ ？？？
8. © 2025 Bekind Labs LLC. All rights reserved 8 どう変えるのか？ 変える根拠を「AIの弱さ」におくと、モデルの進化で陳腐化する。 「AIの弱さ」を根拠とする 「AIはミスをするから、根気強く確認せよ」 → LLMの進化でミス率が減ったら無意味になる 「人間と組織の不変なもの」に着目する 「AIに責任は委譲できないから、理解せよ」 → モデルが進化しても変わらない 「人間と組織の不変なもの」に依らせる。 組織内での行動指針となり得るものにする。 除外したもの：プロンプト技法・モデル比較・コンテキストウィンドウ管理術 — 数ヶ月で陳腐化する層
9. © 2025 Bekind Labs LLC. All rights reserved 9 4つの原則 認知の希少性 人間の認知力はスケールしない。 人間の認知力を最も希少な資源として扱う。 知識の外在化 外在化されない知識は、新しい協働者（人間でもAIでも）に 伝わらない。 責任の引き受け AIは責任を引き受けられない。 成果物の責任は人間が引き受けることになる。 意図の非対称性 成果物が意図通りかの判定は、意図の保有者にしかできない。
10. © 2025 Bekind Labs LLC. All rights reserved 10 基本プラクティス 単独で安全に始められ、単独で利益が出る基本プラクティス 01 コンテキストのコード化 Context as Code AIに渡す前提知識をリポジトリに置き、 コードと同様にレビュー・管理する。 02 学びのコード化 Lessons as Code AIの誤りをその場しのぎにせず、再発防止 ルールとしてリポジトリに残す。 03 意図の事前合意 Intent First 実装前に、人間が検証可能な「意図」を合意・ 固定してからAIに委任する。 04 契約としてのテスト Test as Contract テストを人間とAIの間の契約とし、 人間が理解・保証できる状態に保つ。 05 レビュー可能な増分 Reviewable Increments 変更は人間に理解できる大きさに刻み、 レビュー不能な巨大な変化は避ける。 06 実行可能なガードレール Executable Guardrails 守らせたい規範は指示文ではなく、CIや型、 フックなどの機械的な仕組みに落とす。 07 委任のWIP制限 Delegation WIP Limit 責任を担保し、監督できるまで 上限エージェント数を制限する。 08 最小権限エージェント Least-Privilege Agents 必要最小限の権限のみを与え、想定外の事態で は停止・報告させる。 09 意図的なペアワーク Deliberate Pairing 育成、暗黙知共有、不可逆作業などの特定の目 的のために人間同士で組む。
11. © 2025 Bekind Labs LLC. All rights reserved 11 01 永続的オンボーディング Perpetual Onboarding AIは毎セッション「初日の新人」。 15分で貢献を始められる状態を維持する。 02 追跡可能な委任 Traceable Delegation AIの変更も人間と同じ導線に乗せ、意図から変更まで双方向に 追跡可能にする。 導出プラクティス 基本プラクティスの上に成り立つプラクティス 04 AI機能の継続評価 Evals as Tests プロンプト・エージェント構成をコードと同格に扱い、 定期的にパフォーマンスを観察する。 03 コンテキストの剪定 Context Pruning 陳腐化・矛盾・未使用を定期的に削除。 追加と同じくらい重要。
12. © 2025 Bekind Labs LLC. All rights reserved 12 よく聞く現場の3つの問い 問1 AIのコード、 そのままマージしていい？ 問2 エージェント、 何本まで同時実行させる？ 問3 AI時代、ジュニアは どうやって育てる？ これらの問いに、どう答えていくべきだろうか？
13. © 2025 Bekind Labs LLC. All rights reserved 13 判断を支える知識の積層構造 【判断】 不可逆作業の “Go / No Go” 判断 【自信】 システムへの理解と自信 【知識】 日々のレビューで蓄まる周辺知識 問1. そのままマージ？ 責任は、委譲できない。取り込んだ瞬間、それは「自分たちが出したもの」になる。 論点は品質の高低ではなく —— 責任を持てるか。 原則・プラクティス 意図の非対称性 責任の引き受け 意図の事前合意 レビュー可能な増分 委任のWIP制限 意図的なペアワーク
14. © 2025 Bekind Labs LLC. All rights reserved 14 問2. エージェント、何本まで同時実行させる？ 総レビュー負荷の計算式 同時実行数が増えると、レビュー負荷は掛け算で爆発的に増加する。 件数 × 変更量 × 注意力 ▪ 件数：同時並行で走るエージェントの数（WIP） ▪ 変更量：1回あたりのPRやコミットの規模 ▪ 注意力：理解に必要な認知負荷（重要度が高いと上がる） 原則・プラクティス 認知の希少性 責任の引き受け 委任のWIP制限 レビュー可能な増分
15. © 2025 Bekind Labs LLC. All rights reserved 15 問3. ジュニアはどこで育つ？ 意図的なペアワーク 人間同士のペアを、目的を決めて使い続ける ▪ 判断力の学習と移転：経験の浅いメンバーの育成 ▪ 暗黙知の共有：外在化しきれない知識は、人の間でしか移転しない ▪ 不可逆な作業：リリース・本番マイグレーションは、シニア同士でもペアで。 原則・プラクティス 油断すると育成が放置され、組織全体の地盤沈下を招く可能性を孕む。 知識の外在化 コンテキストのコード化 意図的なペアワーク
16. © 2025 Bekind Labs LLC. All rights reserved 16
17. © 2025 Bekind Labs LLC. All rights reserved 17 おしまい