チームで実践する AI-DLC 思考の軌跡を残すチェックポイント設計

会社紹介: https://www.belong.co.jp/

エンジニアのキャリア: https://belonginc.dev/careers/

Transcript

1. チームで実践する AI-DLC 思考の軌跡を残すチェックポイント設計 株式会社 Belong 執⾏役員 CTO We Sell Cellular LLC. CTO 福井達也 (Fukui Tatsuya) AI Engineering Summit Tokyo 2026 Summer
2. ⾃⼰紹介 2 Tatsuya Fukui @ttyfky - PROFILE - CTO @ We Sell Cellular LLC. (US) 2025/11 ~ Present CTO @ Belong Inc.(Japan) 2020/06 ~ Present TSE @ Google 2018/07 ~ 2020/05 SWE @ Goldman Sachs 2013/04 ~ 2018/06 2025/9 Published
3. 3 携帯関連の新規事業を目的に 伊藤忠商事の 100％子会社(間接保有 含む)として設立 セキュリティーなど独自の基準をクリアし た中古品をアジアや北米など世界中か ら低価格で仕入れが可能 会社名 株式会社Belong 会社設立 2019年2月 所在地 東京都港区赤坂6-4-10 赤坂ZENビル 4F オペレーション センター 神奈川県座間市広野台2丁目10番10号 GLP座間 3階 社員数 社員数：328名（派遣社員含む）（ 2026年3月末時点） 資本金 9億円（資本準備金8億円含む） 日本最大級規模のオペレーションセ ンターで、選抜されたスタッフが丁寧 に管理、検品を実施しています。 伊藤忠グループの安心ネットワーク 自社運営のオペレーションセンターで品質担保 会社概要
4. 4 座間オペレーションセンター 厳格な基準による検査検品 最適な販売チャネルへの効率的な差配 社内開発による高度なオペレーションシス テム ニューヨーク‧ロングアイランド 国内 海外 海外 国内 調達 独⾃のネットワークにより、スマホ ‧PC‧ウォッチなどのデバイスを 国内外から幅広く⼤量調達 オペレーション ⾃社エンジニアリング部⾨の 内製によるシステムを軸とした、 ⾼度なオペレーション体制を構築 販売 国内外のB2C/B2Bにおける 多様な販売チャネルを駆使して、 効率的に再販価値を最⼤化 個⼈ 法⼈ 法⼈ 個⼈ 法⼈ 法⼈ リサイクル 買取サービス 販売‧レンタルサービス 多面的なサーキュラーエコノミービジネスの展開
5. Belongは伊藤忠グループのネットワークと連携し、グローバル規模でビジネスを展開。 価格変動への効果的な対応を可能とし、市場の多様なニーズに応えています。 5 Europe North America Central and South America Africa Middle East Hong Kong Japan Singapore Australia Taiwan グローバルプレゼンスの強み
6. サーキュラービジネスにおけるエンジニアリングの重要性 6 ©Belong Inc. 01. 年間数百万台の取り扱い 02. 個別管理の難しさ 03. 価格の流動性 04. 利益最大化のための動的差配 model storage battery_health grade iPhone 13 128GB 97 A iPhone 13 128GB 83 B iPhone 13 128GB 90 C 国内 vs. 海外 個人 vs. 法人
7. Belong エンジニアリングチームの体制 7 ©Belong Inc.
8. AI 駆動開発の動向と課題
9. 9 [1] Using PLANS.md for multi-hour problem solving, OpenAI - https://developers.openai.com/cookbook/articles/codex_exec_plans 初期 ChatGPT や GitHub Copilot を始めとするチャットベースのツールから始まり、 コンテキストや⽣成されたコードなどをそれぞれコピペするところから始まった 利⽤ 拡⼤期 Claude Code などを⽤いた SDD (Spec Driven Development) の実践 AI が期待通りのアウトプット（コード⽣成）を⾏うための情報を整理するフェーズへ進化 • 期待する⽅向性を Markdown など ローカルファイルに書き込み⽅向性を提⽰ • ExecPlan[1] を作成し、チェックリストとして「やるべきこと」の可視化と、 「AI が与えられた情報から何を⾏うか」を管理 AI 活用の進化
10. 10 課題 SDD を進めるにあたって感じた課題 • 個⼈ SDD のドキュメントは必ずしもコミット‧共有されない • 「わかる⼈」は⾼速化‧増産されるが、「そうでない⼈」にはアウトプットの 結果しか⾒えない 背景と 影響 キャッチアップの困難さと格差の拡⼤ AI への指⽰内容や思考プロセスの可視化が難しく、暗黙知が温存されやすい • ⼀部のアウトプットが⾼速化する⼀⽅で、⼈による「差」がさらに拡⼤する • ⼿法の説明だけでは不⼗分で、属⼈性を排除‧チーム⼒向上のための フォローアップが必要 SDD の壁: 個⼈内完結と差の拡⼤
11. 11 設計判断全体 ADR 射程 (重要判断) 対話‧判断 暗黙的仮定 - 既存ドメイン知識 - ユーザー理解 鍵はここ 射程外にある「真の暗黙知」 SDD セッション中の対話や、検討の末に棄却 された案などは ADRとは別の過程にある。 チーム底上げの鍵 この「射程外」にある思考プロセスが、 チームの暗黙知を削減する重要な要素。 開発プロセスへの統合 ADR の否定ではなく、⾃然に組み込める延 ⻑線としての仕組みが必要。 ADR はドメイン知識共有の解決策とはならない
12. 12 物理‧仕組み‧データの整合が必要 物理在庫 (現場の動き) システム (データ状態) ドメイン知識の同期 現場の判断根拠を システム設計に深く埋め込む • 物理在庫（⼈‧端末の動き）とシステム上のデータ状態の同期が必要 ◦ ズレ = 誤出荷‧誤査定‧在庫不整合（事業直結の事故） • 設計判断には現場で得たドメイン知識が深く埋め込まれる • AI で速く変更するだけでは現場が耐えない、判断根拠の保持と合意が事業整合 の前提 Belong の特徴: 物理オペとシステム状態の整合
13. AI-DLC × Checkpoint 設計
14. AI-DLC: AI-Driven Development Life Cycle [1] 14 Inception - Spec定義 - ユーザーストーリー定義 - ユニットへ分割 Construction - 論理設計 - ドメインモデル構築 - コード‧テスト⽣成 Operation - CI/CD - IaC コアパターン AI が計画 → ⼈が承認 → AI が実装 （⾼速反復による開発サイクルの加速） 本⽇の Checkpoint 設計はこの AI-DLC の上に乗る [1] AI-Driven Development Life Cycle: Reimagining Software Engineering, AWS - https://aws.amazon.com/jp/blogs/devops/ai-driven-development-life-cycle/ AI-DLC の紹介
15. 成果物‧タスクをセッション内に閉じずファイルに保存し、後続処理でも AI に参照させる [1] Context Rot: How Increasing Input Tokens Impacts LLM Performance, Kelly Hong et al. https://www.trychroma.com/research/context-rot [2] AI-DLC の概要とチーム開発における適⽤例, Belong Eng Hub, https://belonginc.dev/members/ttyfky/posts/aidlc-overview/ 実⾏効率と継続性 再現性 セッション断後の復帰 / 別 PC‧別 AI モデルへの引き継ぎ / git worktree で複数ブランチ並⾛ 並⾏性 依存のないタスクを別セッションで同時実⾏ → 全体時間短縮 コンテキストマネジメント • コンテキスト節約: ⼀度に AI へ渡す情報を絞り、回答精度と速度を両⽴ • インデックスやサマリファイル（作業概要 / リポジトリ構成）などの⼯夫による効率化 • 状態をファイル化し Context Rot[1] を防ぎつつ、以前の知識を活かしてタスクに取り組む AI-DLC の⽣成物による効⽤ 15
16. 特にコードを書きはじめるまでのプロセスを重視し、品質を担保する CP-Spec ユーザーストーリー 定義 PdM + TL CP-Unit Unit分割‧深掘り TL + Eng CP-Design 論理設計‧ 開発チケット化 TL + Eng CP-Impl 実装‧テスト Eng CP-Ops 運⽤フェーズ Eng + (SRE) 16 Inception Construction Operation Checkpoint 全体像 TL - テックリード (or シニアエンジニアup) PdM - プロダクトマネージャー Eng - タスクを任された開発者
17. Checkpoint の発想 AI-DLC の過程における作成者の意図や、「考えたが⾔語化されていない」部分を拾い上げる 1. 判断根拠の記録 作成者がなぜその選択をしたかの追跡 2. 暗黙仮定の明⽰化 ⾔語化されていない前提条件の検出 3. コンテキストの記録 作業背景や周辺情報をセッションの会話から抽出 4. レビュー精度向上 意図の共有による検証品質の向上 5. 失敗の学習 棄却案の記録によるナレッジ蓄積 17 ー＞ これらの「狙い」を達成するために、明確なチェックポイントを設置する
18. Checkpoint で作られるドキュメントが蓄積することで期待していること 18  実装⽔準のボトムアップ ⼈‧AI 誰が⼿を⼊れても⼀定品質のアウトプットを継続的に創出可能に  Spec 定義の⺠主化 TL / シニアレベルでなくても⼀定⽔準の要件定義や設計を⾃律的に進⾏  素早い⽴ち上がり ドキュメントの活⽤により新メンバーが素早くキャッチアップできる環境を構築 AI-DLC + Checkpoint で⽬指している世界
19. 19 CP-Spec における合意は影響範囲が⼤きいため最も ROI が⾼い ⽬的 • 早期の意図の整合 • ビジネス × エンジニアの認識統合 価値 • ⾮システム領域を含めた暗黙知の洗い出し 確認観点 • ビジネス意図 • 網羅性 • 受⼊基準 • スコープ ポイント • AI の既知の⼀般的な情報を引き出す • ⾃⾝特有の条件を共有する CP-Spec：最上流で認識を合わせる
20. 20 ⽬的 認識の齟齬を最⼩化すること。この後「設計書通りに作る」こ とではない。 価値 実装前に⽅向性を確認し、TL/スペシャリストと開発者との委 譲ロスを無くす。 更新前提 実装中の発⾒を設計書へフィードバックし、柔軟にアップデートする。 • あくまでも現時点でベストの合意である • 意図を⼤外ししないことが重要（ウォーターフォール化ではない） 設計成果物の構成イメージ CP-Design: 委譲ロスを防ぐシフトレフト
21. 21 [1] LLM Wiki, karpathy, https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f  AIから引き出す (Knowledge Elicitation) AIに質問を投げかけ、Foundation Model が持つ汎⽤知識を引き出す。 指⽰するのではなく「質問」を投げ、基盤モデルが持つ広範な知識やパターン認識を 最⼤限に活⽤。  AIに与える (Context Engineering) AIが持っていない⾃社固有のコンテキストを設計して構造化して与える。独⾃のビジネ スルールや制約を設計し、AIがメインコンテキストを正しく織り込めるよう構築。 LLM Wiki [1] 的な形でインデックスを設け、収集した情報のサマリ（Cache的に扱う）、⽣データ、URLを保持するよう なナレッジベースをrepo内に構築すると速度‧精度のバランスが良い（がメンテナンスは必要） Checkpoint の質を左右する２つの基本原則
22. AI-DLC で提案されたディレクトリストラクチャを拡張 22  flow: チケット単位の作業記録 migration/{ticket}/plan.md ExecPlan は実装上重要だが、長期的な 保全は必要ない  stock: ユニット単位の⻑期知識 {unit}/ にドメインモデル‧決定ログ蓄積 • チケット完了時に⻑期的知⾒を flow → stock に昇格 • チケットを跨いだ知識継承が機能する Flow と Stock の分離
23. 23  [Question]/[Answer] • Foundation Model の知識に照らし合わせたときに⽣まれる疑問を提⽰させる • 回答はセッション内に埋もれさせない  Decision Log • 複数の選択肢から決めたことは、背景、決定要因などをこまめに残す  Surprises & Discoveries • 想定していなかったことは記録に残す • セッション中に閉じると暗黙知になりやすい AGENT.md などの基本動作定義や Skill などに指⽰を加え、⾃動で積み上がる形にする 未知の知の記録
24. 適⽤ガイドライン タスク規模 適⽤ Checkpoint 具体例 バグ修正‧⼩タスク CP なし（通常 PR フロー） ⽂⾔の微修正、軽微なロジック不具合の修正、ドキュ メントの誤字脱字対応など 1 ⼈数⽇規模 CP-Spec + CP-Impl のみ (Design は実装の過程で⾏う) 新機能の⼀部追加、既存ロジックの⼩規模なリファク タリングなど ⼤規模 （複数⼈‧複数ユニット） フル適⽤ 新規プロジェクトの⽴ち上げ、新機能の追加、機能の 振る舞いの変更、複数チームが関わる基盤刷新など 24 原則: 迷ったら少ない⽅から始める
25. Checkpoint を⽤いた AI-DLC 実践と学び
26. 26  ゴール理解がリーダー層を超えてチーム全体に届く タスクの⾒通しの良さが明らかに向上した  Spec / Design 定義の⽔準向上 PR レビュアーとしての参加から、起案者の層が徐々に拡⼤  FM が「もともと気づかなかった観点」を補完する テストシナリオなどで当初考えていなかった部分が出てくる 導⼊してよかった点
27. 課題: モブエラボレーションの同期時間確保 エンジニア、PdM などが集まり集中して作業する時間が限られる • PR を Checkpoint として通せば⾮同期 OK。Spec の考慮事項が記録に残ることが重要 • 議論も PR ログに残るメリットが有る 27 課題: 既存のプロダクトに対するアプローチ 既存実装の Spec をどこまで書くか • 主要ユーザーストーリーは適切なプロダクト理解のために⾔語化するべき ◦ aidlc-workflows[1] で例⽰されるような “analyze the project” といったプロンプトでも保管可能 • ⼿法を始めるときに全てを指定のフォーマットでドキュメント化する必要はない ◦ 関連機能の変更時に補完 ◦ スプリントバッファで段階的に整備 [1] aidlc-workflows, Amazon Web Services - Labs, https://github.com/awslabs/aidlc-workflows 課題と対応 ①: 運⽤の現実
28. 課題: 分散したリポジトリへのアプローチ フロントエンド / バックエンド / IaC ⽤など別リポジトリで設けている • モノレポは⼀案 • ワーキングディレクトリ + ローカル/GitHub 参照で対応 • 中央集権 vs 分散は規模で選ぶ 課題: 固有ドメインの Spec 定義の難しさ DWH 構築‧モデリングなど、Spec で定義するのが難しいという声 • ⾃社で定義‧⽅針‧デザインを⽤意する投資 ◦ LLM Wiki の構築が効く 28 課題と対応 ②: スコープの広がり
29. 01. 可視化 チームごとの状況を可視化 プロダクトによって適⽤状況はか なり異なるという現実を把握す る。 02. 共有 チームレベルの課題‧Tips を共有 課題追跡 DB を併⾛。Checkpoint 思考を導⼊プロセス⾃体にも適⽤ し、知⾒を循環させる。 29 03. 前進 フィードバックサイクルで 徐々に改善 ⼩さなサイクルを回し続けること で、組織全体の継続的な成⻑を実 現する。 まだまだ試⾏‧改善サイクルの過程にある 継続改善 — フィードバックサイクルで前進
30. おわりに • AI を活かした開発では知識が個⼈のセッション中にとどまり、コンテキストが⼈間で共有 されづらくなる課題がある • AI-DLC を拡張し Checkpoint を設けて仕様や設計での論点を可視化 ◦ Inception ▪ CP-Spec ◦ Construction ▪ CP-Design ▪ CP-Impl • 知識の可視化の効果はあり、タスクの⾒通しは良くなった • 複数のリポジトリや既に⼤きなリポジトリへの対応、必要な知識（コンテキスト）の与え ⽅などは今後も改善の余地がある 30
31. おしらせ 31 各種エンジニア採用中です！ - 求人情報 • Belong は両⽇ともブースを出しています ◦ 私は本⽇この後にブース‧懇親会にいます。ご質問等ございましたらお声がけください • ６⽉末の AI Engineer World's Fair @ San Francisco へ私と Belong のエンジニア１名が 参加予定ですので同様の⽅がいらっしゃったらキャッチアップをぜひさせてください • AI をフル活⽤しプロダクトを開発するソフトウェアエンジニア • プラットフォームチームで AI のプラクティス考案‧ガードレール構築‧Skills などの作成‧各種仕組みの浸透を⾏うエンジニアおよびマネージャー • アメリカへの出張や時間帯を合わせて英語で仕事を進められるエンジニア