AI時代に設計が 最大の生産性レバーになる 意図駆動開発とデータを消さない設計｜Don't Delete Your Data or Your Intent — Design as the Deepest Lever in the AI Era

AI DevEx 2026 登壇資料「AI時代に設計が最大の生産性レバーになる — 意図駆動開発とデータを消さない設計」(2026-07-24)

AIによってコードを「変える」コストは劇的に下がりました。しかし「取り戻す」コストは下がっていません。保存しなかった事実は、どれだけAIが進歩しても復元できない — この登壇では、AI時代の生産性の最も深いレバーは、コードの書き方ではなく「データと意図の保存方式」にあることを、実案件の話を交えて紹介します。

データ: 上書きから追記へ(イベントソーシング / CQRS) — 「誰が・なぜ・何をしたか」を出来事として残す。実案件で、リリース後の想定外の分析依頼に「デプロイなし」で答えられた話。Sekiban / SekibanWasmRuntime / SekibanCloud による実装。
意図駆動開発(intent-cli) — 同じ「消さない」発想を開発の判断にも。目的・制約・ADR・タスク履歴を意図ツリーとしてGitに残し、実作業用の細かなプロンプトはAIに作らせる。
ESの構造はAIコーディングでも有利 — 意味的局所性・実行可能な遷移・観測面の強制・再生可能な入力が、AIが「正解を出しやすい」条件を作る。
未来の問いは選べません。しかし、残すべき履歴は今日から選べます。「その改善は、浅い支点か・深い支点か」— 皆さんの開発でも、AIでも取り戻せないものがどこにあるかを考えるきっかけになれば嬉しいです。

関連リンク: sekiban.dev / intent-driven-development.com / jtechs.com

ーー
AI has made code cheap to change — but it cannot recover what you never saved. This talk argues that the deepest productivity lever in the AI era is not how you write code, but how you store data and decisions.

Productivity improvements have shallow and deep fulcrums. Coding style, libraries, and even architecture can be changed later; the way you persist data and intent cannot. Once a fact is overwritten, no amount of AI can restore it.

We cover three ideas, with real project stories:

Append-only data (Event Sourcing / CQRS): keep events — who did what, and why — instead of overwriting state. A real case where a client's unexpected analytics question was answered with zero deployment, because the events were still there. Sekiban, SekibanWasmRuntime, and SekibanCloud make this practical.
Intent-Driven Development (intent-cli): apply the same append-only mindset to development decisions. Keep purpose, constraints, ADRs, and task history as a Git-managed intent tree, and let AI agents generate precise working prompts from it.
Why this helps AI coding: event-sourced structure gives AI semantic locality, executable transitions, enforced observability, and replayable inputs — the conditions under which AI produces correct changes.
Takeaway: you cannot choose tomorrow's questions, but you can choose today what history to keep. Put your fulcrum where AI cannot recover what is lost — in your data and your intent.

Transcript

1. AI時代に設計が AI DevEx 2026 最 の 産性レバーになる 意図駆動開発とデータを消さない設計 丘 知央 株式会社ジェイテックジャパン 年 水 日 月 高 生 大 2026 7 22 ( CTO / @tomohisa ) AI DevEx 2026
2. 丘 知央 紹介 - Tomohisa Takaoka X: @tomohisa GitHub: @tomohisa 株式会社ジェイテックジャパン、 グループ 中 企業の受託開発をモダンな開発スタイルで。イベント ソーシング、 などのソフトウェアアーキテクチャに関する コンサル業務。企業向けの 活 開発の 援 セミナー コンサ ルティングも展開中 Works at: Inc.(JTS J-Tech Creations, ) CTO: CQRS AI Microsoft MVP for Developer Technologies from Nov 2024- / Microsoft On .NET Live 出演 己 cli - Intent-Driven Development ・ ・ 支 用 小 高 自 OSS: Sekiban - Event Sourcing and CQRS Framework / intent- 2 / 33
3. 本 のアジェンダ タイピングの価値は変わった。価値を届ける仕事は変わらない。 1. 2. 3. 4. / CQRS (IDD) intent-cli : 入 方 支 ・ 支 生 日 5. 産性のために、何を考えるかを考える 点としてのデータ保存 式 イベントソーシング で追跡 分析を構造に れる 意図駆動開発 と まとめ 開発の決断の 点をどこに置くか 3 / 33
4. 産性のために、何を考えるかを考える 「難しそう」で、始める前に諦めていないかýという問いから始めます。 産性の改善には浅い 点と深い 点があり、書き やライブラリより、根元にあるデータ構造 保存 式のほうが効果が Chapter 1 支 大 方 ・ 方 支 支 生 生 きい。この章では「どこに 点を置く価値があるか」を考えます。 4 / 33
5. 「難しそう」で、始める前に諦めていないか 倒そう 難しそう、で始めないと、うまくいく可能性ごと 消える AI時代は、 び込む前にAIと 緒に「海の中」を偵察できる 問うべきは「怖いか」ではなく「どこに 点を置く価値があ るか」 実例 も「難しそう」と躊躇していた時期があった。使っ てみると便利で、思ったほど 変ではなかった。 : IaC(Infrastructure as Code) 支 一 ・ 飛 大 止 面 生 「難しそう」で めたままの設計判断が、僕にもあった 5 / 33 1-1 産性のために、何を考えるかを考える
6. 産性のために、何を考えるかを考える レバーは、 点を深く置くほど、 さな で強い を出せる 1-2 強い 開発 さな い腕を押す 深い 点 = データ 意図の保存 式 書き ライブラリ 語 アーキテクチャ 保存 式 浅い 後から変えられる 影響は局所的 深い 取り戻せない 影響が根元に及ぶ 残さなかったデータ 意図は、後から取り戻せない ( ( ) ) 力 力 方 方 — 言 支 ・ 支 ・ — 方 ・ 支 長 小 力 力 小 支 生 「その改善は、浅い 点か 深い 点か」を先に考える 6 / 33
7. コードよりデータ構造を よ 1-3 産性のために、何を考えるかを考える "Good programmers worry about data structures and their relationships." Linus Torvalds(git ML, 2006) 良いプログラマーはデータ構造とその関係を気にする "Data dominates. ... Data structures, not algorithms, are central to programming." Rob Pike, Notes on Programming in C(1989)Rule 5 造 プログラミングの中 はアルゴリズムでなくデータ構 「テーブルを せてくれれば、フローチャートは要らない」も同系統 見 心 — — 見 生 Fred Brooks 7 / 33
8. 消した出来事は、AIでも読めない が下げたのは「変える」コスト。コード も設計も、作り直しは 気に安くなった でも「取り戻す」コストは下げていない。 残っていない事実は、AIでも復元できない データが無ければ、AIは推測で埋めて、捏 造してしまうこともある 状態を上書きすると、残るのは「今」だ け。「なぜ どう変わったか」はその瞬間に 捨てられている 1-4 産性のために、何を考えるかを考える ・ 一 生 AI いま上書きしているものを、5年後に欲しくならないか 8 / 33
9. 点としてのデータ保存 式 Chapter 2 ý 方 見 支 士 文 支 保存しなかった問いには、後から答えられない。50年前の天 写真が未来の問いに答えた Precovery、数千年前から続く「会計 は消しゴムを使わない」作法 上書きせず出来事を残すこ とが、未来の問いに答えるための深い 点になることを ます。 9 / 33
10. 保存しなかった問いには、後から答えられない 2-1 点としてのデータ保存 式 将来どんな問いが来るかは、最初には予測できない でも「誰が なぜ 何をしたか」を残せば、読み は後で変えられる 保存時に、将来の全クエリを予測しなくていい 迷って離脱した は、何 ? 誰が なぜ 何をした 誰が なぜ 何をした 誰が なぜ 何をした 答えられる 何も残っていない ✕ 答えられない 出来事が残っている 方 ・ ・ ・ ・ ・ 人 人 ・ ・ ・ 方 支 なぜ、この仕様にした? 半年前の 分のシステムに、「なぜ」を聞けるようにしておきたかった 自 10 / 33
11. 年前の写真が、未来の問いに答えた 2-2 Precovery: 50 点としてのデータ保存 式 発 以前にアーカイブされた画像から天体を つけ出すこと 惑星 は、 年撮影の乾板に写っていた 旧称 年超の観測期間から、地球衝突リスクを後から算出できた Precovery = 2000 YK66 1950 ( 1950 DA) 50 ※ 乾板 かんぱん ( / photographic plate)= フィルム以前の、ガラス板に感光乳剤を塗った写真記録メディア 天 写真乾板の例 ハレー彗星 : (1910) 方 1950 DA レーダー画像 (2001) NASA/JPL, Public Domain 観測時に知らなかった問いに、保存データが後から答える 未来の問いに答える「乾板」は、残しておかないと に らない 見 入 手 文 小 見 支 Harvard College Observatory / PD-US 回収後の
12. 会計 は消しゴムを使わない 2-3 点としてのデータ保存 式 "Accountants don't use pencils: they use pens. You do not erase something in the middle of your ledger." Greg Young, "CQRS and Event Sourcing"(Code on the Beach 2014) の途中を消したりはしない 数千年前 シュメールの粘 板 の配分記録 方 今 同じ作法を、設計に 湿った粘 に刻み、乾 けば恒久的な記録に 封泥 印章で、内容と 真正性を検証できた 「消さずに残し、後か ら確かめる」作法 は「 度書いたら消えない」から まれ たプロダクト。イベントは更新も削除もせず、追 記だけで積み上がる。 Sekiban 麦 大 士 生 一 ・ 土 — 土 — — 士 支 CC0 / The Met, 会計 は鉛筆でなくペンを使う。台帳 12 / 33
13. 消さないのは、あとで「なぜ」に答えるため 2-4 点としてのデータ保存 式 状態は えても、理由は えない。そこが気になっていた 残すのは状態そのものではなく、変更に った出来事と理由 業務データも、開発の判断も同じ 「なぜこうなったか」に後から答えられる形で残 す 消すべきものは消す。ただし消す判断と理由は履歴に残す いつ なぜ消したか ( 未来の問いは選べない。残すべき履歴は、今 から選べる ) ・ 日 方 ・ — 至 見 見 支 ※「何でも永久保存」ではない。プライバシー要件による削除にも、「いつ なぜ消したか」の痕跡を残して応える。 13 / 33
14. 「消さない」を、システムの構造にする Chapter 3 前章では、未来の問いに備えて出来事と理由を残す意味を ました。ここでは、その態度を善意に任 せず、保存と読み の分離として構造に埋め込みます。 の仕組み、デプロイなしで想定外の 問いへ答えた実例、 による実装へ進みます。 ES/CQRS 方 見 Sekiban 14 / 33
15. イベントソーシング で追跡 分析を構造に れる 保存と読み を分ければ、新しい問いは「新しい読み 」と して せる 3-1 / CQRS 前章の設計態度を、ここからは構造にする。 画 Projection: 状態を組み てる コマンド 書き込み Event Store 追記のみ 出来事の列 画 操作 分析 分析 経営レポート 新しい問い 未来の問いへの答え Projection: 集計 傾向を出す Projection: 後から追加できる つの保存から、読み は後からいくつでも作れる 1 入 ・ "Businesses regularly come up with new and interesting ways of looking at data." 方 ・ ビジネスは、データの新しい ・ ・ 用 ・ 立 面 用 面 足 方 Greg Young, CQRS Documents(2010) 方 見 — 方 15 / 33 を後から思いつく
16. イベントソーシング で追跡 分析を構造に れる 実話 「どう悩んでオプションを追加したか、分析してほし い」 3-2 / CQRS : オプションの多い保険商品システム なかった依頼 残ったイベント列 オプションA を選ぶ (Sekiban 採 。リリース後に届いた、設計時には想定してい ) 気が変わる いったん 外す オプションB を追加 補償条件 を変更 申込 確定 ( ) 後から作った読み 迷った回数 付け外ししたオプション 確定までの経路 (Projection) で即席集計 デプロイなし AI — 入 ・ ・ ・ 方 用 ・ イベントが残っていたから、デプロイなしで想定外の問いに答えられた 16 / 33
17. Sekiban あなた / AI なら、難しくない が書く ドメイン ( 3-3 イベントソーシング で追跡 分析を構造に れる ) コマンド 集約 状態遷移 イベント : 難しい所は Sekiban / CQRS が担う 整合性境界 (DCB) タグで宣 動的に決定 追記で保存 が引き受ける デプロイ 読み の配線 Event Store Sekiban Projection IaC で 動化 貫性の担保は、 分で書かずフレームワークに任せる タグ が整合性スコープを宣 し、守るべき境界をコマンドごとに動的に決 める 現 の推奨。集約を否定するものではない 。 の概念は 語 フレームワークが変わっても きく変わらないので、 エージェントに書かせる精度が上がっている 特に 以降 。 DCB(Dynamic Consistency Boundary)= ( Sekiban (ITag) ) 入 ( 自 方 大 ・ 言 ／ 行 言 自 ・ 一 言 ・ AI ES/CQRS 17 / 33 Opus 4.5 )
18. 実 する SekibanWasmRuntime: ドメインを書く 語 Wasm MoonBit Swift( ) Runtime / Elastic License 2.0) 入 プレビュー に任せれば、ドメインは好きな 語で書ける 言 ・ ・ 用 ・ 行 ・ 一 ・ 言 行 用 ・ : Zenn: SekibanWasmRuntime( ・ = 集約 コマンド イベント → アップロード 「安全に動かす」を サンドボックス 安全な実 境界 利 者のドメインコード Wasm 出典 で追跡 分析を構造に れる 保存 貫性 配信のインフラ 公開コンテナ → ローカルテストも簡単 実験サンプル 同じ規格の にコンパイル TS / CQRS Sekiban Host(C# / Orleans) C# / Rust Go イベントソーシング 利 者のドメインコードを安全に 3-4 18 / 33
19. SekibanCloud イベントソーシング と、下がり続ける採 障壁 3-5 昔、ES採 に必要だったもの 実装をまとめる 考え を教える 学ぶ意欲のあるチーム 今 AI( 概念の障壁を下げる / CQRS で追跡 分析を構造に れる ) WasmRuntime / Cloud( 実装 運 の障 壁を下げる 意図を定義して、伝える 間 データは持ち出せる セルフホストへ 移 可 ) 採 に必要だった障壁は、今は下がってきた ES 上に構築中のマネージドサービス 認証 マルチテナント インフラ 動化 。 は万能ではなく適材適所 " " の注意も残る。 入 用 ・ SekibanCloud = WasmRuntime 用 ・ Fowler for most systems CQRS adds risky complexity — 人 人 行 19 / 33 ／ 自 ・ ・ 用 — 方 人 用 ES/CQRS ( )
20. おまけ : ES イベントソーシング で追跡 分析を構造に れる の構造は、 コーディングでも有利に働く 3-6 / CQRS AI 意味的局所性 変更の 脈が に局所化。表 修正 が の変更だけで済むことも多い 実 可能な遷移 過去イベント コマンド 新イベント が、 に 渡せる構造化された仕様になる 観測 の強制 全状態変化がイベント経由 振る舞いの差分が必ず える形で残る 上書き型は観測を「含めずに作れてしまう」 再 可能な 過去バグの再現も、後付け もリプレイで command / decider / projection projection Given( )- When( )- Then( ) AI = ( 入 示 文 を使っている限りこの構造が強制される 乗れる 見 — — — — 力 入 生 面 行 — ・ ES ) 20 / 33 read model AI が「正解を出しやすい」形に
21. 意図駆動開発 Chapter 4 (IDD) と intent-cli 出来事を残す発想を、開発の判断にも持ち込む。コードには は残るが、 なぜ 何を 判断したか は残らない。開発の意図も放っておくと消えていきます。意図をツリーにして に残し 、 に渡して開発を回す 意図駆動開発 と の章です。 ) AI ý why( Git (IDD) ・ (Intent-as-Source) how / what 21 / 33 intent-cli
22. 意図駆動開発 AI時代に重くなる仕事は、構造の意味を 極め、選ぶこと データ保存の 点を深く置く話は、開発の進め にもそのまま当てはまる。 AI Framework 間 → → 4-1 実装例 概念へのアクセス 貫性 実 基盤 (IDD) 何を残す構造にするかを 極め、選ぶ 実装が速くなるほど、「何を成功と呼ぶか」を先に決めておきたい "Structured communication is the bottleneck." Sean Grove(OpenAI) "The New Code", AI Engineer World's Fair 2025 見 — 行 ・ 一 ・ 人 方 支 見 く、意図を構造として共有する速度 22 / 33 詰まるのはコードを書く速度ではな と intent-cli
23. 開発の意図も、放っておくと消えていく 散らばる意図 Issue レビュー コメント DM 頭 意図ツリーに集約 的 背景 Issue と ) (Intent) 制約 成功条件 と 間が同じ前提を て、後からレビューできる に残っても後から辿りにくく、 見 ・ 目 人 口 ・ (IDD) AI 口 ・ や (Git 意図 記憶だのみ PR 意図駆動開発 本の意図ツリー 管理 1 チャット PR 4-2 23 / 33 DM 頭はそもそも残らない intent-cli
24. コードの前にある「なぜ 何を」を残す 4-3 意図駆動開発 (IDD) と intent-cli = Intent-as- Source 顧客 ステークホルダー 何を達成したいか / 意図 ↓ 的 背景 制約 成功条件 仕様 (Intent) と 間が共有する判断材料 ↓ (Spec / Design) AI コード が 成 AI 間が管理 ↓ 間がレビュー 意図を残せば、AIと 間が同じ判断材料を られる 「意図駆動開発」は 分のオリジナルではない。 同じ問題意識が外部にも現れている。 人 — ・ ・ ・ — 見 一 自 人 人 ・ 生 人 目 ・ GitHub Spec Kit も第 原則に " Intent-driven development " を掲げる
25. intent-cli ① 意図をツリーにして : Git に残す 4-4 意図駆動開発 (IDD) と intent-cli intent tree .intent MVV 理念 的 基本原則 (Intent Storming) / Git で差分管理 技術選択 実装 針 ADR 守るべき前提 会話 配下 判断理由 で整理し、 構造で管理 過去のタスク どう作るか packet の履歴 と 間が同じ前提を る AI は運転しない を起動しない 。意図と契約を残し、 エージェントに次の 順を決定論的に案 内する。意図と選択がここにまとまっているから、実作業 の細かくしっかりしたプロンプトは に作らせられる が残すのは意図、プロンプトは 成物。 intent-cli (Claude / Codex ) AI AI 生 方 人 — 用 手 見 人 — 木 目 ・ ・ 会話で決めたことを、リポジトリに残すようにした 25 / 33
26. intent-cli 会話 ② 意図を渡して開発を回す : 設計スレッド 間と会話して intent / / ADR 間 packet / issue 実装単位に切り出す ) issue 状態確認 次の作業を判断 委譲 まりを検知して復旧 を読んで実装 間 意図 = 設計スレッドが 間とやりとりする 針 判断 PR を作成 PR を intent と照合 レビュー orchestrator = merge 各 状態確認 委譲 進 管理 「指 して回す」から「意図を渡して回す」へ receiver 次の issue へ は「依頼された時だけ 件ずつ」処理 receiver = 1 orchestrator mode を現在のメインとして運 。従来の 。 SQLite) ・ 行 ・ ・ 用 用 ・ 高 ・ 人 示 ・ 方 ・ 人 人 ・ 人 ・ ・ 人 ・ ・ 止 ・ 方 人 ・ agmsg(Claude / Codex / Gemini CLI 26 / 33 (loopless) 実装 レビューの個別処理 間の役割を「減らす」のではなく、「集中させる」 効率 成功率とも く、 スレッド間連携は intent-cli review receiver 定期的に動くのはこれだけ 間判断が必要な時だけ、設計スレッドへ戻す design / human receiver = と (intent-cli / GitHub) closeout 質問 (IDD) implementation receiver スレッド 管制塔 ( 意図駆動開発 (orchestrator mode) orchestrator を整理 やりたいこと 技術 針 制約 質問に答える 判断する 4-5 timer-loop mode も引き続き使 可。
27. 失敗も迷 も、意図に照らして て直す 4-6 improve: 最近の作業を振り返る PR packet 実装 意図 ADR 実装と照合 MVV intent-tree ズレ 短期ループ ブロッカーを特定 も 是正パケット 意図の明 化 結論の型 : 整合 意図を明 化 明確化 是正パケット 意図駆動開発 (IDD) と intent-cli 是正の を提案 承認後に適 更新へ ADR 更新 ADR 短期ループ検知 間の判断 失敗は、コードの差分ではなく「どの意図とズレたか」で 直す 設計スレッドの定期リフレクション 。振り返りの観点 レポート型を決定論的に案内 し、意味判断は 間と は起動しない 。提案が先で、適 は承認後。 intent-cli improve = (realignment) ) 用 ・ 手 見 人 ・ 文 用 一 立 ・ ・ ・ ・ ・ ・ 文 人 ・ ・ 走 AI(AI 27 / 33
28. 学習と継承を える 4-7 残っていないチーム 同じ説明を何度もする 設計理由が属 化する AIも毎回ゼロから推測する 意図が残るチーム 同じ失敗を繰り返しにくい 新メンバーが「なぜ」を辿れる AIが過去の判断を読める 意図が残れば、新メンバーも判断の経緯まで辿れる 側は経営分析を、 側はチームの学習 継承を える どちらも「消さずに残す設計」 IDD — 支 ・ 人 支 ES 意図駆動開発 28 / 33 (IDD) と intent-cli
29. まとめ 開発の決断の 点をどこに置くか コードは再 成できる。しかし判断の履歴は、設計しないと消えていく。データと意図を消さないこ とýそれが僕にとっての深い 点でした。最後に、あなたのチームの「深い 点」はどこかを 緒 に考えて締めます。 Chapter 5 一 支 支 生 支 : 29 / 33
30. まとめ 開発の決断の 点をどこに置くか コードは再 成できる。判断の履歴は、設計しないと消えて いく 5-1 AI コード 成 で変えやすい 浅い 点 ( ライブラリ ) AI アーキテクチャ 浅い : でも取り戻せない 深い 点 ( ) データ 意図の保存 式 上書きしたら、AIでも復元できない 深い 根元 ( ) イベントで残すデータも、ツリーで残す意図も、積んでいるのは同じもの 「なぜ 何をしたか」 という判断の記録。将来どんな問いが来るかは予測できなくても、残してさえいれば後から答えら れる。 ・ 方 支 — — 生 ・ 支 生 支 業務の判断はイベントに、開発の判断は意図に 「消さずに積む」が共通の 形 30 / 33
31. レバーの 点を、どこに置くか AIで変えられるものではなく、 AIでも取り戻せないものを る / アルキメデス 点さえあれば、地球も動か せる。深い 点を選べば、 さな が強い になる。 力 方 ・ — 支 見 小 力 支 支 ) 力 支 31 / 33 力 — 支 小 : 強い開発 さな = "Give me a place to stand, and I shall move the earth." 支 まとめ 開発の決断の 点をどこに置くか 深い 点 データを消さない 意図を消さない 僕は、そこに 点を置いた。 Archimedes( 5-2 データ 意図の保存 式
32. 参考 献 リソース Core references Tools & resources Torvalds(git ML 2006)/ Pike "Notes on Programming in Sekiban / SekibanWasmRuntime / SekibanCloud " Rule 5 / Brooks "The Mythical Man-Month" C intent-cli / Intent-Driven Development Helland Fowler "Immutability Changes Everything"(CIDR 2015)/ sekiban.dev "Event Sourcing" / Greg Young "CQRS " Documents Naur intent-driven-development.com "Programming as Theory Building"(1985)/ GitHub Spec Kit / Sean Grove "The New Code" 天 アーカイブ ) 文 ・ 文 Menzies et al.(2017)/ Precovery( 32 / 33
33. Thank You 丘 知央 @tomohisa — 高 sekiban.dev · intent-driven-development.com · jtechs.com