『動くだけ』のその先へ — AI駆動開発で品質と速度を両取りする温故知新な新手法 / Beyond Just Vibe Coding - Combining Classic Principles with AI-Driven Development

by Hiroshi Ito

Embed

Start on current slide

Slide 1

Slide 1 text

「動くだけ」のその先へ — AI駆動開発で品質と速度を両取りする温故知新な新⼿法 AI Dev EX Conference｜2026年7⽉23⽇株式会社ログラス執⾏役員CTO 伊藤博志（いとひろ @itohiro73）

Slide 2

Slide 2 text

⾃⼰紹介伊藤博志（いとひろ @itohiro73）株式会社ログラス執⾏役員CTO ゴールドマン‧サックスのテクノロジー部に新卒⼊社後、同社の機関システム開発に従事。その後、 VP/Senior Engineerとしてプラットフォーム開発に携わり、同社発のJavaのOSSであるEclipse Collectionsのコミッター兼プロジェクトリードやOpenJDKへのコントリビュートを⾏うなど、OSS戦略を牽引。スタートアップ2社を経て、READYFORに⼊社し執⾏役員VPoEに就任。エンジニア組織の10名から30名規模への成⻑、決済基盤の刷新、技術的負債の返済、新規プロダクト開発を牽引。 2022年10⽉に株式会社ログラスの開発部へエンジニアとして⼊社。EM、VPoEを経て2024年11⽉より執⾏役員CTOに就任。 © 2026 Loglass Inc. 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

OLAP DBとは OLAP DB: 集計‧分析⽤の多次元データベース OLAP（Online Analytical Processing）とは、⼤量のデータをさまざまな切り⼝から集計‧分析するための処理⽅式です。1件ずつの登録‧更新（OLTP）と対になる考え⽅です。データを「縦軸：組織」「横軸：勘定科⽬」「奥⾏き：時間」のような多次元キューブとして捉え、どの軸からでも集計値を取り出せるようにモデル化します。例えば「4⽉分だけ」を切り出す操作は「スライス」と呼ばれ、時間軸を固定してキューブの断⾯を取り出すことに相当します。 ※ 物理的な実装は製品により様々（事前集計‧列指向など） © 2026 Loglass Inc. 10

Slide 11

Slide 11 text

OLAP DBとは OLTP DBとOLAP DBの違い OLTP DB（業務向け） Online Transaction Processing OLAP DB（分析向け） Online Analytical Processing ● 1件ずつの登録‧更新‧参照 ● ⼤量データをまとめて集計‧分析 ● トランザクション処理が主戦場 ● ⼤きな読み取りと集計が主戦場 ● ⾏指向の格納が典型 ● 列指向の格納が典型 ● 例：受注‧在庫の登録∕更新 ● 例：部⾨ × 科⽬ × 時間の集計 © 2026 Loglass Inc. 11

Slide 12

Slide 12 text

OLAP DBとは参考: OLAP処理が可能なOSSとして⼈気の2フレームワーク Rustで実装されたデータフレームライブラリで、データ分析に特化した⾼速に動作するインプロセ特にパフォーマンスに優れたクエリエンジンでスDBです。SQLiteのような軽量さを持ちながらす。pandasの代替を⽬指しており、⼤規模なデーも、列指向のデータストレージを採⽤しており、タを効率的に処理できる設計がされています。マ⾼度な分析クエリを効率的に実⾏できます。ルチスレッドを活⽤して並列処理を⾏い、Python とのバインディングも提供しているため、pandas に慣れ親しんだユーザーであれば扱いやすいツールです。 https://pola.rs/ https://duckdb.org/ ※ ロゴは各公式サイトより引⽤。商標は各プロジェクトに帰属します © 2026 Loglass Inc. 12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

⾃作OLAP DBのパフォーマンス充填データにおけるパフォーマンスはPolarsを上回るクエリが5/10ほど標準 fP&A クエリのパフォーマンス（1M⾏） ※ 実⾏時間ms‧低いほど⾼性能 88ms ⾃作OLAP 88ms DuckDB Polars 50ms 50ms 88ms 82ms 76ms 52ms 41ms 38ms 28ms 22ms 21ms 25ms 15ms BQ-01 予実⽐較 BQ-02 P&L Rollup BQ-04 YoY⽐較 BQ-06 クロスプラン BQ-07 YTD累計 © 2026 Loglass Inc. 14

Slide 15

Slide 15 text

⾃作OLAP DBのパフォーマンス疎データ(*)においてはDuckDB/Polarsよりも圧倒的に⾼パフォーマンス (*)疎データについては次スライドで補⾜）疎データにおけるパフォーマンス ※ 実⾏時間ms‧対数スケール‧低いほど⾼性能⾃作OLAP DuckDB Polars 29.8ms 22.0ms 18.5ms 12.9ms DuckDB⽐約93倍⾼速 DuckDB⽐約185倍⾼速 0.20ms 0.07ms 疎データ（充填率 1%）疎データ（充填率 10%） © 2026 Loglass Inc. 15

Slide 16

Slide 16 text

⾃作OLAP DBのパフォーマンス細かめの補⾜: 疎データとは＝経営管理や管理会計系のデータの性質次元の掛け算とデータの性質により、多次元データ内に膨⼤な「空⽩」が⽣まれる 1 次元の乗算的爆発 2 論理的な⾮在の発⽣ 3 充填率1%未満の現実分析軸（部⾨、科⽬、取引先等）を増「⼈事部 × 製品売上」のように、ビジ実際に値が刻まれるのはキューブの空やすほど、集計対象となるセル数は爆ネス上あり得ない組み合わせが、計算間の極⼀部。99%以上が空（疎）とい発的に増加します。上の空間の⼤部分を占拠。う極端な状態が、FP&Aデータでは起き得ます。 100 × 200 × 500 × 50 × 12 意味をなさないセルが増加＝ 6,000,000,000 60億マスの巨⼤空間が出現スカスカな空間の効率的処理が鍵 © 2026 Loglass Inc. 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

⾃作OLAP DBをClaude Codeでどうやってつくったか基本の流れ（全てClaude Codeにやらせる）プロダクト全体｜戦略ループ 1 ビジョンをインプット 2 技術‧最新研究をディープリサーチ 3 仮説ベースでロードマップ作成 7 振り返り → ロードマップ組み替え 6 Polars/DuckDB ベンチで検証還流開発アイテム単位｜実装パイプライン 4 ADR作成＋専⾨家AIレビュー 5 仕様策定→テスト設計→設計→実装→検証堅牢性を保って⼀気通貫 ※ 顧客データや機密情報は⼀切含まず、完全にパブリックな情報、または⼀般化‧抽象化された概念のみをインプットしています © 2026 Loglass Inc. 22

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 37

Slide 37 text

3⽇間のトライたとえば、仕様の⼀⽂に振った ID は、検証まで⼀気通貫でつながる仕様書テスト設計書 …… TC-047-1 #047 導出明細3件 → ⼩計＝合計 …… #047 実⾏‧判定 PASS ✓ TC-047-1, TC-047-2 グリーン⼩計は、明細の合計と常に⼀致する検証レポート TC-047-2 検証に紐づいていない仕様：0件明細0件 → ⼩計＝ 0 仕様に紐づいていないテスト：0件対象仕様：#047 から導出 ID をたどれば、「何を保証し、どう検証されたか」に、いつでも答えられる © 2026 Loglass Inc. 37

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

回転数を上げても、壊れないための仕組み実装のコンテキストを、検証に持ち込ませないテストは、仕様から導出するレビューは、独⽴したAIが⾏うコードから作らせると、AIは⾃分の実装を別セッションで、レビュー観点（品質‧ 正解として追認するテストを書く。セキュリティ‧設計）だけを与えたAIが検査。導出元は仕様書に固定し、実装の影響を断つ。実装中の経緯や思い込みを引き継がない。同じコンテキストは、同じ⾒落としを⽣む © 2026 Loglass Inc. 40

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

回転数を上げても、壊れないための仕組み新しい仕様は、「過去の全仕様」との⽭盾も検査される #001 #002 #003 #004 #047 #012 #019 #023 #031 #038 #040 #044 #046 新しい仕様全件と突き合わせて⽭盾を検査これまでに積み上げた仕様のすべて仕様が積み上がるほど検証の網は密になり、「新機能が既存を壊す」を仕様の段階で捕まえる © 2026 Loglass Inc. 43

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

業務SaaSでの実践約3,000万通りの組み合わせを、82構成に圧縮して検証する 16の因⼦が、掛け算で爆発する因⼦A ×3⽔準ペアワイズ法 82構成どの2因⼦のペアも必ず 2因⼦ペアの網羅率 100%（120/120）因⼦B ×5⽔準因⼦C ×4⽔準因⼦D ×4⽔準因⼦E ×4⽔準 …全16因⼦ 1回は現れるように選ぶ、枯れた設計⼿法単純な直積 ≈ 3,000万通りほかに：判定分岐のデシジョンテーブル 138ルール∕業務の年間リズムに沿った横断シナリオ 8本∕⾒つけたバグは、再現テストにしてから直す © 2026 Loglass Inc. 53

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

新機能の開発でも実践正しく作ろうとするほど、仕様の本質が問われる業務SaaSでは、作り直しだけでなく新機能の開発も実践した。たとえば、こんな問い「グループ⾏の達成率は、ハーネスを活⽤して進めると、仕様の本質を問う問どう計算するのが正しいですか？」いが次々に返ってきた。前提を揃えるには、答える必要のある問いばかりだった。⼦A：120% ⼦B：80% では、グループ⾏は？⾜す？平均？合計から計算し直す？どれも、計算としては作れてしまう顧客にとって価値のある仕様か。意味のある仕様に正解は、計算では決まらない。なっているか。なぜ、これをやるのか。それ⾃体を顧客がこの数字で何を判断するか、で決まる。深める必要が、⾃然と⽣じた。 © 2026 Loglass Inc. 59

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

ハーネスを、開発の外側へ「なぜ‧何を」は、独⽴した成果物として先に固める 1 Why/What ドキュメント（実際の章⽴て）価値は、課題とペアで書く 1. 社会‧市場背景 2. 顧客の課題 PB-001 … 005 2 合格ラインは、検証の前に固定する 1 3. 提供価値 VL-001 … 004（課題とペア） 4. ターゲット‧ペルソナ 3 3 WhatとHowを、1:1で繋ぐ 5. 機能領域 FA-001 … → Howへ（1:1） 6. スコープ（作らないものも明⽰） 2 7. 成功指標（合格ラインを先に固定） 8. Traceability PB ⇔ VL ⇔ FA 仕様の「⼿前」にも、型とゲートがある © 2026 Loglass Inc. 66

Slide 67

Slide 67 text

ハーネスを、開発の外側へ学びの共有: AIにテンプレを埋めさせると、結論ありきの⽂書ができあがる機会定義書 ✓ 顧客課題「他に、どんな案があった？」「何を検討して、捨てた？」 ◯◯業務は⼯数が⼤きく、担当者の負荷が… ✓ 提供価値「なぜ、これを選んだ？」 ◯◯を⾃動化し、リードタイムを⼤幅に… ✓ 成功基準どこにも、残っていないと、読んだ⼈間には不安感が残る。導⼊3社で継続利⽤率が… ⼀⾒、完璧に⾒える。 AIの⽋陥というより、プロセス設計の問題。「埋めさせる」設計そのものが、広げる⼯程をスキップさせる。 © 2026 Loglass Inc. 67

Slide 68

Slide 68 text

Slide 69

Slide 69 text

ハーネスを、開発の外側へ学びの共有: AIの役割は、「⽂書⽣成器」ではなく「熟練インタビュアー」 1 2 3 説明責任のための役割分担意思の痕跡を必須にするわからない所は埋めない⼈＝意思 AI＝構造化記録あり＝有効記録なし＝不完全要証拠：＿＿＿（空欄のまま）意思とインプットは⼈が持つ。AIは引⼈が確認した‧反論した‧決めた。こ確度の低い前提は、空欄のまま⾒えるき出し、構造化し、根拠をもって反論の記録がない成果物は、不完全なもの化する。埋まるまで、ゲートは通さなする。鵜呑みのプロセスにしない。として扱う。い。 AIが⾃動⽣成したドキュメントは、正しそうに⾒えて、⼈を動かさない © 2026 Loglass Inc. 69

Slide 70

Slide 70 text

ハーネスを、開発の外側へ打席数を増やす: つくらずに⽴てる打席と、⼀周まわす打席ディスカバリーの打席：つくらずに検証する机上リサーチインタビュー 1打席が数時間から数⽇。プロトタイプ仮説の外れを、安く早く潰せる筋の良い仮説だけを、⼀周に乗せる⼀周まわす打席：価値検証のフルサイクル探索仕様実装検証リリース学びこの⼀周も、ハーネスがあるから速い打席数はディスカバリーで稼ぎ、当たりは⼀周で確かめる © 2026 Loglass Inc. 70

Slide 71

Slide 71 text

Slide 72

Slide 72 text

ハーネスを、開発の外側へ仮説には、書き⽅と順番の型がある 1 2 3 反証できる形で書く⼀番危ない仮説から試す確からしさは、反証耐性で気持ちを主語にしない。 ✗「使ってくれるはず」重要度都合のいい証拠を数えない。 ★ ここから検証反証の試みに耐えた回数だけ、 ✓「週1回以上使われる」検証度が上がる。観測できる形に、置き換える。証拠の強さ打率は、仮説の「扱い⽅」で決まる © 2026 Loglass Inc. 72

Slide 73

Slide 73 text

Slide 74

Slide 74 text

ハーネスを、開発の外側へ価値のある仕様は、打席と打率の掛け算でつくる打席を増やす打率を上げる ‧つくらずに検証する打席 ‧正しい課題から始める（リサーチ‧インタビュー‧プロトタイプ） × （広げてから絞る、を⼆回） ‧仕様の⼿前に、型とゲート ‧デリバリーまで⼀周まわす打席も、 ‧仮説には、書き⽅と順番の型ハーネスの活⽤で品質⾼く速く ‧学びが、次の打席を書き換える速さは打席のために。プラクティスは打率のために。 © 2026 Loglass Inc. 74