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

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

⾃⼰紹介伊藤博志（いとひろ @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

2026.02 2026年2⽉、週末三連休でどこまで⾏けるか試してみた。⽇⽉⽕⽔⽊⾦
⼟ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 © 2026 Loglass Inc. 7

Claude Codeで、 OLAP DBをつくってみた。 $ claude > OLAP DBを、ゼロからつくって。▍

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

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

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

⾃作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

⾃作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

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

たった数⽇で⼀定の疎データのユースケース限定ではあるものの世界的なOSS DBに匹敵‧凌駕するパフォーマンスを⽰す OLAP DBが作れてしまった… © 2026 Loglass Inc.
17

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

3⽇間のトライハーネス＝ AIに規律を「外付け」する仕組みの総称 harness ＝⾺具。⼒を殺さずに、⽅向と安全を制御する装具ハーネス Skills Rules
Hooks AIエージェント（Claude Code） Commands サブエージェントプロジェクト規約仕組みは道具に依らない。今⽇は、Claude Codeでの実装を例に © 2026 Loglass Inc. 35

3⽇間のトライ仕様‧テスト設計‧検証を、双⽅向に追跡できる「ID」でつなげる双⽅向トレース仕様双⽅向トレーステスト設計検証実装（TDDで駆動される）
実装は連鎖には⼊らない。「検証される対象」として⽣成される © 2026 Loglass Inc. 36

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

これは、ウォーターフォールなのか？回転数が上がりきったウォーターフォールは、イテレーションと区別がつかない従来のウォーターフォール AIの速度で回すと仕様仕様テスト設計検証 ↻ テスト設計
実装検証実装 1サイクル＝数ヶ⽉ 1サイクル＝数時間 ↻ ↻ ↻ 1⽇に何周も⼿戻りは数ヶ⽉の損失。ドキュメントは腐る学びが数時間で、次の周の仕様へ © 2026 Loglass Inc. 39

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

回転数を上げても、壊れないための仕組み「やったか」は決定的に全件チェック、「正しいか」はリスクに応じて積む形式⼿法で証明仕様の⽭盾を、数学的に検査別のAIがレビュー質的検証：リスクに応じて積み増す内容の妥当性を、別の⽬で検査⼟台の決定論的ガードレール：スクリプトが機械判定（常時‧全件） IDの鎖‧テスト実⾏‧ビルド。「やったか」を決定論的にで担保する ©
2026 Loglass Inc. 41

回転数を上げても、壊れないための仕組み形式⼿法：⽭盾と曖昧さがゼロになるまで、実装に進まない⽭盾‧曖昧あり → 差し戻しゼロになって、はじめて通過機械的に検査仕様を書く（⽭盾‧曖昧‧⾏き⽌まテスト設計へ
り）「実装してから、仕様の⽭盾に気づく」という⼿戻りを、最初から締め出す © 2026 Loglass Inc. 42

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

回転数を上げても、壊れないための仕組み同じ問いを3つのエンジンに投げて、答えを突き合わせる⾃作OLAP DB ⼀致 ✓ 同じクエリ DuckDB 答えは
⼀致するか？ → 前進する不⼀致 → ⾃作側の誤りを検知。 Polars 即、修正「オラクルテスト」と呼ばれる枯れた⼿法。テストの⾒落としは、答えの不⼀致が教えてくれる © 2026 Loglass Inc. 44

回転数を上げても、壊れないための仕組み性能も「回して」上げる、計測と研究のループ実装ベンチマーク計測専⾨家AIが評価改善をロードマップへ毎フェーズ必須楽観バイアスを禁⽌反映の省略は禁⽌ 2つの規模
× 他エンジン⽐較⾚‧⻩‧緑で厳しく判定計測が次の計画になる⾏き詰まったら、ディープリサーチ。最新研究‧学術知⾒をループに注⼊学びと打開策が、次の周の実装へ © 2026 Loglass Inc. 45

業務SaaSでの実践とあるプロダクトで実際に起きていた課題 1 データ規模の⼤きいお客様に対し、性能が限界に達していた 2 内部は密に絡み合い、⼀部だけを安全に直せる構造ではなかった 3 インデックスやクエリの改善は、すでに頭打ちだった構造ごと作り直す ©
2026 Loglass Inc. 48

業務SaaSでの実践システムは⽌めずに、仕様が明確な部分ごとに置き換える稼働し続ける既存システムフラグで ON/OFF 既存機能旧エンジン既存機能既存機能問題が起きても、スイッチひとつで即座に元へ戻せる

業務SaaSでの実践システムは⽌めずに、仕様が明確な部分ごとに置き換える稼働し続ける既存システムフラグで ON/OFF 既存機能新エンジン既存機能既存機能問題が起きても、スイッチひとつで即座に元へ戻せる

業務SaaSでの実践 3⽇間の経験と同様のハーネス‧規律で実プロダクトで実践 #047 #047 仕様策定テスト設計 #047 実装検証仕様の⼀⽂⼀⽂に番号を振り、テスト‧検証まで同じ番号で追跡できる

業務SaaSでの実践作り直しの結果最も使われる画⾯の表⽰データ量の増加で表⽰速度が課題に数秒エンジン置き換え‧第1弾の開発期間 8⽇間従来なら数ヶ⽉単位と⾒積もっていた規模
約30倍の⾼速化 © 2026 Loglass Inc. 52

業務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

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

なぜ、あの3⽇間のトライは⼿堅くいったのか理由は同じ。「仕様が、すでに存在していた」から週末のOLAP実験既存業務SaaSの作り直し仕様が、すでにある世の中に、答えがあった新規機能開発誰も、答えを持っていない⾃社に、答えがあった答えを、作るところから
新機能開発においては、仕様の「⼿前」に踏み込む必要がある © 2026 Loglass Inc. 61

ハーネスを、開発の外側へ「なぜ‧何を」は、独⽴した成果物として先に固める 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

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

ハーネスを、開発の外側へ学びの共有: だから、「広げてから絞る」を⼆回やる（ダブルダイヤモンド）正しい課題を⾒つける正しい解を⾒つける問題空間解空間解くべき課題広げる（発散）絞る（収束）
価値のある仕様広げる（発散）絞る（収束）正しい課題なしに、正しい解はない ※ ダブルダイヤモンド：デザイン思考の定⽯プロセス © 2026 Loglass Inc. 68

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

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

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

ハーネスを、開発の外側へ出して終わりにしない。学びが、次の打席を書き換える次の打席へリリース成果レビュー学びを台帳へロードマップを書き換える先に決めた合格ラインで判定外れた仮説も、消さずに記録次に潰す仮説が変わる
トレーサビリティの鎖は、リリースの先まで続いている © 2026 Loglass Inc. 73

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

ログラスの Product Team Value Update Normal：「当たり前」を更新し続ける当たり前を疑う新しい当たり前にする「当たり前のようにこうしている」を単発の改善で終わらせず、
⾜を⽌めて疑い、更新する新しい「普通」として定着させる開発の「当たり前」が⾳を⽴てて変わるいま、ここに全⼒で取り組む © 2026 Loglass Inc. 80

『動くだけ』のその先へ — AI駆動開発で品質と速度を両取りする温故知新な新手法 / Beyo...

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

More Decks by Hiroshi Ito

Featured

Transcript