Slide 1

Slide 1 text

CTOがICになる経営意思決定 ~週末3⽇で作ったOLAP DBを起点にした組織変容インパクト~ 「AI駆動経営」勉強会 #2 2026年5⽉28⽇ 株式会社ログラス 執⾏役員CTO 伊藤博志 1

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

ログラスのご紹介 3

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

5

Slide 6

Slide 6 text

ここから本筋スタート 6

Slide 7

Slide 7 text

2026年2⽉某⽇

Slide 8

Slide 8 text

3連休を活⽤して、Claude Codeで とある⼿法を⽤いた開発にトライ

Slide 9

Slide 9 text

何をしたかというと

Slide 10

Slide 10 text

週末3⽇間で⾃作OLAP DBを作ってみました

Slide 11

Slide 11 text

OLAP DBとは

Slide 12

Slide 12 text

OLAP DBとは OLAP DB: 集計‧分析⽤の多次元データベース 12 OLAP(Online Analytical Processing)とは、⼤量のデータを 「多次元キューブ」として保持し、様々な切り⼝から瞬時に集 計‧分析を⾏うための技術です。 「縦軸:組織」「横軸:勘定科⽬」「奥⾏き:時間軸」のよう に、あらかじめデータが空間状に配置されているため、どの⽅ 向からでも⼀瞬で集計値を取り出せる構造になっています。 例えば「4⽉分の集計データ」を切り出したい時に、「スライ ス」という操作で素早く集計値を取得できます。

Slide 13

Slide 13 text

OLAP DBとは いわゆるRDB(OLTP)とOLAP DBの違い 13 OLTP DB(オンライントランザクション処理) OLAP DB(オンライン分析処理) 主たる目的 日常業務の遂行と取引データの正確な記録 業績分析、トレンド予測、経営戦略立案 主な処理タイプ 大量の小規模トランザクション(作成、更新、削除) 大規模データの読み取り、集計、多軸分析 データソースの範囲 単一のアプリケーションやシステムからリアルタイム に入力 複数のオペレーション DBやSFA、販売システムから統合 データの特性 最新かつ現在の状態のみを保持(動的な変動) 過去から現在に至る履歴データの時系列蓄積 応答時間と同時実行 ミリ秒単位 / 数千人の同時ユーザーがアクセス 秒〜分単位 / 意思決定者やアナリストがアクセス 意思決定への影響 業務プロセスの自動化、現場レベルの実行支援 予算策定、セグメント別利益率の可視化、意思決定

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

実際にOLAP DBを作ってみた結果

Slide 16

Slide 16 text

⾃作OLAP DBのパフォーマンス 充填データにおけるパフォーマンスはPolarsを上回るクエリが5/10ほど 16

Slide 17

Slide 17 text

⾃作OLAP DBのパフォーマンス 疎データにおいてはDuckDB/Polarsよりも圧倒的に⾼パフォーマンス 17

Slide 18

Slide 18 text

⾃作OLAP DBのパフォーマンス 細かめの補⾜: 疎データとは => 経営管理や管理会計系のデータの性質 18 次元の乗算的爆発 分析軸(部門、科目、取引先等)を増やすほ ど、集計対象となるセル数は爆発的に増加 します 60億マスの巨大空間が出現 論理的な非在の発生 「人事部 × 製品売上」のように、ビジネ ス上あり得ない組み合わせが、計算上 の空間の大部分を占拠。 意味をなさないセルの増加 充填率1%未満の現実 実際に値が刻まれるのはキューブの 空間の極一部。 99%以上が空(疎) と いう極端な状態が、FP&Aデータでは起 き得ます 次元の掛け算とデータの性質により、多次元データ内に膨大な「空白」が生まれる

Slide 19

Slide 19 text

たった数⽇で ⼀定の疎データのユースケース限定とはいえ 世界的なOSS DBを超えるレベルの OLAP DBが作れてしまった...

Slide 20

Slide 20 text

どうやったのか?

Slide 21

Slide 21 text

企業秘密です(‧ω<)☆

Slide 22

Slide 22 text

それだと勉強会の意味がないので

Slide 23

Slide 23 text

あたりさわりのない エッセンスだけ抽出すると

Slide 24

Slide 24 text

⾃作OLAP DBをClaude Codeでどうやってつくった 基本の流れ(全てClaude Codeにやらせる) 24 • 作るプロダクト‧対象で解決したい世界観をビジョンとしてインプット • そのビジョンを実現するための技術要素‧最新研究をディープリサーチ • 仮説ベースでロードマップを作成 ‐ ロードマップ上の各アイテムに対し • ロードマップアイテム実現のためのアーキテクチャADR作成 ✔ 作成したADRを専⾨家エージェントチームを組成してレビュー • ロードマップアイテムを以下の流れで仕様から実装までを堅牢性を保ちながら⼀気通貫に実現 ✔ 仕様策定 => テスト設計 => 設計 => コーディング => テスト結果/仕様網羅性検証 • Polars/DuckDBをベンチマークにした機能検証‧パフォーマンス検証 • ロードマップアイテムの実装を⼀定繰り返した後に振り返り。必要に応じて技術要素‧最新研究を再リ サーチし、ロードマップの組み替えを⾏う ※顧客データや機密情報は⼀切含まず、完全にパブリックな情報、または⼀般化‧抽象化された概念のみをインプットしています

Slide 25

Slide 25 text

⼀番わかりやすい(?)例え

Slide 26

Slide 26 text

世界最⾼峰の エンジニアチームを雇うことができたら どのように仕事を進めてもらいますか?

Slide 27

Slide 27 text

仕様の検証や 品質保証‧パフォーマンス検証 セキュリティ担保も含めて

Slide 28

Slide 28 text

今のAIは、世界最⾼峰のエンジニアチーム を擬似的に実現できる

Slide 29

Slide 29 text

それがわかったという発⾒が⼤きい

Slide 30

Slide 30 text

そして

Slide 31

Slide 31 text

CTOとしての動きを変容 週末に⾏った実証実験の結果があまりにもインパクトの⼤きいものだったため、即刻経営 提⾔し、CTOとしての動きを変容する意思決定 31

Slide 32

Slide 32 text

マネジメント系の業務を素早く委譲し 短期的にICロールへとコミット

Slide 33

Slide 33 text

CTO⾃ら独⾃ハーネスエンジニアリングの 現場適⽤とフレームワークR&Dに従事

Slide 34

Slide 34 text

CTOがICとして動く意味 「動くだけ」から「価値あるものを品質⾼く」へ 34

Slide 35

Slide 35 text

経過の成果としては

Slide 36

Slide 36 text

R&Dを通じて開発したハーネスでできつつある世界観 BizDevメンバーが、⼀定の複雑な動きのあるプロダクトのプロトタイプを、デザイナー ‧PdM‧エンジニアの⼒を借りることなく作成可能な世界観。とにかく価値検証に時間を 費やす。 36

Slide 37

Slide 37 text

R&Dを通じて開発したハーネスでできつつある世界観 価値検証された動くプロトタイプを堅牢な仕様に落とし込み、仕様 ⇔ テスト設計 ⇔ 動作 検証結果のトレーサビリティが決定論的に担保された状態で本番運⽤可能なアーキテク チャ‧実装をコーディングエージェントが⾃律的に実現 37 仕様策定 テスト設計 設計‧実装 検証 トレーサビリティを決定論的に担保

Slide 38

Slide 38 text

詳細は

Slide 39

Slide 39 text

予告編 AI DevEx Conference2026にて、こんな発表をします 39 AI DevEx Conference 2026: https://dev-productivity-con.findy-code.io/aidevex2026/?m=aidevex2026/m/An688ijZ

Slide 40

Slide 40 text

最終的に⽬指す世界観は

Slide 41

Slide 41 text

プロダクト開発組織の変容につなげ エンタープライズ企業に提供するレベルの プロダクト品質⽔準を⾶躍的に向上

Slide 42

Slide 42 text

42

Slide 43

Slide 43 text

43