データ基盤の開発を全部AIに寄せるためにやっていること / leaning-into-ai-agent-driven-development

2026-05-21「みんなの考えた最強のデータ基盤アーキテクチャ'26前期〜本祭」での発表資料。

AIエージェント主体の開発に振り切るために、開発環境をどう作り変えたかの実践記録。CARTA ZERO データ基盤での AI 導入前後で個人 PR マージ数が月平均 3件 → 210件（約70倍）に変化した実体験から、いま効くと賭けている4つの整備領域（標準に寄せる / CI/CD 最適化 / 判断と思想の明文化 / 権限最小化）を共有する。

イベント: https://datatech-jp.connpass.com/event/386874/

Transcript

1. データ基盤の開発を 全部AI に寄せるために やっていること 2026-05-21 / みんなの考えた最強のデータ基盤アーキテクチャ'26 前期〜本祭
2. Coding Agent で、 何が変わった？ （以下、AI と表記）
3. コードに帰着する仕事の 手数の問題は、ほぼ消えた
4. データ基盤開発における私の PR マージ数 AI 導入前の1 年間 2025 年通年: 36 件 月平均: 3 件 0 件の月: 4 回 AI 導入後の3 ヶ月 2026 年2 〜4 月: 629 件 月平均: 210 件 月数百件が標準 そしてこれは、自分だけじゃない。チーム全体で不可逆な変化が起きている。 集計日: 2026-05-13
5. 約70 倍 月平均 PR マージ数の比較
6. もう、人が書く時代は 終わったな。 そう感じた。
7. AI が開発しやすい を、第一優先に 実際にやってみて、わかった。 AI 前提に切り替えないと、まずい。 なぜなら、もう数十倍のスケールで開発できてしまうから。 AI で開発する会社と、そうでない会社。圧倒的な差がつく。 その流れが来ることに向けて、AI 前提に作り直すと決めた。
8. その作り直し。 旧来なら膨大な工数。 それも、AI が解決する
9. AI 前提への変更も、AI で進める 例えば、AI に dbt モデルを開発させたい。 となると、モデルのメタデータがほしい。 でも、メタデータ整備は大変。 実際、人手で進めてきた充足率は 約20% で止まっていた。 メタデータを読むのは AI 。それなら、整備も AI にやらせる。 最初は品質を心配したが、実際にやらせてみるとクオリティは高かった。 普段のメタデータ作成と同じ手順をスキル化して、並列で回しただけ。 一週間で 100% に。
10. 効率化から、アウトカムへ 最初は AI に dbt を作らせるためだった。 結果的には、開発スピード全体を押し上げ、裾野も広げることになった。 速度: 開発スピード全体が押し上がった 試してから本番に乗るまでが、早くなった。 裾野: 非エンジニアも開発できる 業務を一番知ってる人が、自分で分析環境を組める。
11. 今日話すこと メール、Slack 、決定プロセス。 AI には、あらゆるプロセスを変えるポテンシャルがある。 だから、ゼロベースで評価し直すフェーズが来ている。 その中で今日は データ基盤の開発 の話。 活用を加速するためにやっていることを話す。
12. アジェンダ 1. 自己紹介 2. AI 活用というゲームを理解する 3. いま効くと賭けているところ 4. まとめ
13. 自己紹介 ぺい / pei / 近森淳平 株式会社CARTA ZERO — VP of Data Snowflake Data Superheroes (2024-2026) X: @pei0804
14. アジェンダ 1. 2. AI 活用というゲームを理解する 3. いま効くと賭けているところ 4. まとめ 自己紹介
15. まず、目線合わせ 具体の話に入る前に、 私が AI 活用というゲームをどう捉えているか を、共有したい。
16. AI はなぜ 魅力的 で、 混乱をもたらすのか？
17. 強い武器 であることは、自明。 しかし、 誰も使い所は知らない。
18. AI 活用が 混乱する 理由 これまでは、問題に対して、作られた道具を選ぶだけだった。 Snowflake 、dbt 、Terraform 。 いまは、最強っぽい道具がすでに手元にあって、 何にでも効きそうに見える。 制約もルールも分からない。 我々は、これが何に効くのかを理解していない。
19. 混乱の中で、前に進むには 最初から「これに効かせよう」と狙い撃ちはできない。 複数の場所で試して、効くところを見つけていく。 完璧な計画を立てるより、とりあえずやらせてみるほうが、 結果として正解に早く辿り着く。 前なら数日かかっていたものが、いまは数時間で回る。 試行コストが下がった今こそ、数を打つのが合理的。
20. いまの正解は、非常に短命 ツール同士が、半年単位で機能を取り込み合う。 特定時点の " 正解" は、3 〜6 ヶ月で陳腐化する。 だから、定期的にゼロベースで見直す。 「いまゼロから入れ直すなら、同じ選定をするか」を問う。 辞めるのは 失敗 と捉えない。これは、賭けの見直し。
21. 今日話すのは、 いま効くと賭けている ところ
22. アジェンダ 1. 2. 3. いま効くと賭けているところ 4. まとめ 自己紹介 AI 活用というゲームを理解する
23. いま効くと賭けている、4 つの施策 1. 標準に寄せる 2. 不確実性を、CI/CD で吸収する 3. 判断を、明示する 4. 権限は初手最小、任意で昇格
24. AI は、標準をよく知っている
25. AI は、カスタムは知らない
26. 標準に寄せるほど、教える手間が消える AI は、世の中の公開コードで学習している。 だから、標準的なやり方にはすでに詳しい。 独自設計や独自フレームワークは、教えなければ AI は理解できない。 ドキュメントやスキルで補えば精度は上げられる。 だが、書いて保守するコストがかかる。 標準に寄せれば、ほとんど教えなくても動く部分が増える。 ※ あくまで私の体感
27. 標準で済むものは、標準に寄せた 標準に寄せれるものは標準に。本当に必要なカスタムだけ残した。 もちろん全く同じ振る舞いは作れない。 でも、AI が判断を間違うのも大体カスタム周辺。 このブレを消すメリットを取った。 この移行で、開発サイクルにも修正が必要だった。 ただ、それを AI が補助するので、ユーザーは意識せず乗れた。 結果的に、開発効率も上がり、メンテナンス対象も減った。
28. いま効くと賭けている、4 つの施策 1. 標準に寄せる 2. 不確実性を、CI/CD で吸収する 3. 判断を、明示する 4. 権限は初手最小、任意で昇格
29. いまの AI に、確実性を求めない プロンプトで指示しても、自信満々に間違えることがある。 例えば「マージするな」と指示しても、マージしてくる。 ルール、手順は CI/CD で守らせる。 AI 任せよりも、再現性が高い。 ただ、CI がボトルネックになることがある。 これも同時に対策したい。
30. AI によって、 大量に作られる PR 。 全然終わらない CI 。
31. AI が速くても、CI に引っ張られる AI がどれだけ速く PR を作っても、CI 待ち時間 からは逃げられない。 CI が遅いだけなら、開発スピードが落ちる。これだけなら、まだマシ。 本当にきついのは、rebase 必須ポリシーとの掛け算。 CI 待ちで他の PR がマージされたら、rebase でやり直し。 その間に、また別の PR がマージされる。 マージできない状態 が、ずっと続く。 人が書く時代は、PR 生成速度が遅く、問題になりにくかった。 そこに AI が大量の PR を作ると、CI の遅さが、一気に顕在化する。
32. CI をスリム化して、 AI で担保しよう
33. 再掲。 AI は、自信満々に間違える。
34. 緩めるのは、本質ではない AI は自信満々に間違え、本番に間違いを持ち込む。 CI を緩めれば、それが頻発する。 速度と引き換えに、本番障害を増やしているだけ。 向かうべきは、緩める方向ではなく、速くする方向。 その高速化こそ、AI が得意な領域。 「この CI を速くしたい」まで落とせば、AI が結構やってくれる。
35. いま効くと賭けている、4 つの施策 1. 標準に寄せる 2. 不確実性を、CI/CD で吸収する 3. 判断を、明示する 4. 権限は初手最小、任意で昇格
36. 判断の軸なき AI 。 高速で、いらんもの作る
37. 明示しないと、AI は推測で動く 判断の軸 とは、何を優先し、どこまでやるかの基準。 これは AI にはない。人が持っている。 AI に全てを任せると、世の中のそれらしい答えになるだけ。 人が書く時代は、軸は頭の中で良かった。 いまは違う。テキスト化されてない軸は、考慮されない。 だから、積極的に判断の軸を定義する 必要がある。
38. グレーな部分を減らす AI に読ませる判断は、できる限り 0/1 で下せる形に持っていく。 " こういう場合はやる、それ以外はやらない" まで言い切る。 グレーが残ると、人も AI も 毎回迷う。 迷うほど、解釈が分かれる。
39. 判断は、粒度で書き分ける そして、どういう粒度で書くか も重要。 粒度 中身 場所 タスク単位 目的・成果物・スコープ Issue 設計判断 選択肢・トレードオフ・構造 ADR / Design Doc ルール・手順 書き方・操作 AGENTS.md / skills 全てを AGENTS.md に書くのは、効果的ではない と考えている。 粒度を分けるのは確か。ただ、最適解はまだチームでも模索中。
40. Issue が、全ての起点 3 つに分けた中で、特に重点を置くべきは Issue 。 判断 (ADR) も、実装 ( コード) も、すべて Issue から始まる。 どれだけ AGENTS.md や ADR を書いても、 Issue が悪ければ、AI は違うものを作り切る。
41. Issue は、 「何をやるか」を明確にする Issue で書くのは「何をやるか」 。 「どう作るか」は AGENTS.md 。 Issue を明確にするポイント スコープを絞る — 大きくなったら分割する 成果物を明示する — 目的と完成形を書く ただし「このように書きましょう」では、クオリティがブレる。 このクオリティ担保も、スキル化して AI にやらせる。
42. Issue 粒度の、イメージ 原則は 1 Issue = 1 PR 。 一定の粒度を超えたら、サブ Issue に分割して、それぞれを 1 PR にする。 親 Issue サブ Issue 1 サブ Issue 2 サブ Issue 3 PR PR PR
43. 判断の軸と 自明な Issue を渡せば、 AI は狙ったものを作る
44. いま効くと賭けている、4 つの施策 1. 標準に寄せる 2. 不確実性を、CI/CD で吸収する 3. 判断を、明示する 4. 権限は初手最小、任意で昇格
45. 人前提の権限設計は、 再考が必要
46. AI は、危ない操作を分かっていない 人は、危ない操作を経験的に分かっている。だから、ある程度は自分で守れる。 AI はそうではない。 「これはやるな」を分かっていない。 AGENTS.md に明示的に書かれていても、実行されることはある。 だから、プロンプトで守らせるのではなく、 できる範囲そのものを絞る。
47. 権限で、絞る シンプルだが、これが最も安全。 プロンプトや AGENTS.md で「やるな」と書くより、 そもそも実行できないようにする。
48. 例: 破壊的な操作 AI が破壊的な操作をやろうとしても、 権限が足りなければ 一旦止まる。 ロールを切り替えるかどうか、 人が判断するチャンスが生まれる。 出来ないようにすることで、人が確認するポイントを作る。 これが、最小権限の効き目。 ただし、完全に塞ぐと開発がやりづらい。 許可で昇格できる構造も、セットで持つ。
49. とはいえ、勝手に解決しに行くこともある 権限の範囲内であっても、AI が " 良かれと思って" 想定外の操作に踏み込むことがある。 定型手順は スキル化 する。 アドホックな手順は その都度明示 する。 書かれていない例外へのリカバリは、実行させないように明示しておく。
50. アジェンダ 1. 2. 3. 4. まとめ 自己紹介 AI 活用というゲームを理解する いま効くと賭けているところ
51. 人前提 から AI 前提 へ 観点 Before （人前提） After （AI 前提） 標準 業務に合わせて独自実装する 標準に寄せる CI/CD CI は多少遅くても困らない CI は早い方が良い 判断 頭の中で判断する 判断軸を書き出す 権限 経験で気をつける 権限で防ぐ どれも、人前提でも大事だった。 AI 前提で、より重要になった領域、と捉えている。
52. 何に賭けるべきかの判断軸 AI はあくまで、物量をかけられる一般論のスペシャリスト。 仮に彼（AI ）が自分のチームに入ってきたとして、 「いい感じにやっといて」とは言わないはず。 何が「いい感じ」なのかを、構造的に、明示的に伝えるはず。 相手が AI に変わっても、伝えるべきことは変わらない。 仮に人が AI と同じ速度で動けたとしても、 有益でないものを作っていれば、速く外し続けるだけ。
53. 何を作るかが、 結果を決める。
54. 一緒にやる仲間を募集してます データ&AI マネジメントエンジニア マスターデータの定義・設計とデータガバナンスの仕組みづくり。 データ&AI プラットフォームエンジニア Snowflake を中核に、データ基盤と AI 基盤をコードで設計・運用。 https://hrmos.co/pages/cartaholdings/jobs/zero-e06 https://hrmos.co/pages/cartaholdings/jobs/zero-e07
55. ありがとうございました