ログラスのアーキテクチャ

伊藤：今日は「動くだけのその先へ」と題して、40分ほどお話しさせていただきます。私はログラスという会社で執行役員CTOとして技術全般を見ています。

AI駆動開発の手法を説明するにあたって、まずログラスという会社の背景をご紹介します。ログラスは「良い景気を作ろう。」というミッションを掲げ、いろんな企業に元気になってもらいたい、企業価値を上げていく活動をサポートするSaaSを開発している会社です。祖業としては経営管理のプロダクトをリリースしており、経営管理だけでなく人員計画や設備投資計画といった経営の意思決定に寄与するプラットフォームを開発しています。

今日の話も、こうしたプロダクト開発において品質の高いものをいかに素早く提供するか、という文脈で理解してもらえればと思います。

きっかけ：週末で作ったOLAP DB

本編は、いきなり休日の話から始まります。2026年2月の3連休、ちょうどOpus 4.6が出た頃で、スキルやフック、コマンドといったハーネスを構成する要素が揃い始めていた時期でした。まだ「ハーネスエンジニアリング」という言葉自体は出ていなかったものの、それを構成する要素が出てきていたタイミングで、ここで一丁やってみるかと、Claude CodeでOLAP DBを作ってみました。

OLAP DB（オンライン・アナリティカル・プロセッシング・データベース）は、集計や分析用の多次元データベースです。1件ずつの登録・更新・参照やトランザクション処理が主戦場で行指向の格納が典型的なOLTP DBに対し、OLAP DBは大量データをまとめて集計・分析することが主戦場で、列指向の格納が典型です。ログラスは経営管理のアプリケーションを開発しており集計処理を多用するため、こうしたデータベースが自分たちで作れるか試してみました。

まずはパフォーマンスの話として、世界的に有名なフレームワークであるPolarsやDuckDBとベンチマークを比較した結果を表示します。標準的なfP&Aクエリのパフォーマンスでは、週末で作った自作OLAP DBが10個のクエリのうち5個でPolarsを上回りました。安定的に動くうえに速いと言われているPolarsを、週末に作ったものが超えてしまったというのは驚きでした。

さらに、経営管理・管理会計に特有のユースケースとして、部門や科目、取引先といった軸の組み合わせが爆発的に増える一方で、実際に値が存在するのはごく一部という「疎データ」の状況があります。例えば人事部に製品売上という集計はあり得ないので、多くのマス目が空白になるといった具合です。このユースケースにおいては、DuckDBやPolarsより全然速いというびっくりするような結果になりました。

たった数日で、ユースケースは限定的ではあるものの世界有数のOSSに匹敵するレベルのデータベースが作れてしまった、というのがこの週末のトライです。

「世界最高峰のエンジニアチームを雇えたら」という思考実験

どうやって作ったのかは、企業秘密です、というのは冗談で、重要なエッセンスを抽出すると次のような流れです。まずビジョンをインプットし、技術・最新研究をディープリサーチし、そこで得られた知見をベースに仮説ベースでロードマップを作成します。作ったロードマップをアイテムに分解し、開発アイテムごとにADR作成・専門家AIレビュー、そこから仕様策定・テスト設計・設計・実装・検証という一気通貫のパイプラインを回し、できたものをベンチマークで検証します。結果が思い通りであれば次のアイテムへ、なんだか違うとなればロードマップを組み替えてまた戻る、これをひたすらぐるぐる回し続けました。コードを1行も書いておらず、やったことといえばレビューぐらいです。

これは「世界最高峰のエンジニアチームを雇うことができたら、どのように仕事を進めてもらいますか」という問いをそのままやってみた感覚に近いです。出てきた結果に対して「これ本当にそうなの」とツッコミを入れ、その合間に仕様の検証や品質保証、パフォーマンスの検証、セキュリティの担保まで含めてツッコミを入れ続けていました。最近登場したFableのようなモデルではみんな当たり前に感じているかもしれませんが、Opus 4.6でも普通にこのレベルに到達していました。

3日でここまでできるとわかったのは非常に大きな発見でして、すぐさま経営に「マネジメントをしている場合ではない、こういう技術的にグリップを効かせるべき領域だ」と提言し、自らIC（Individual Contributor、現場のエンジニア）として動く意思決定をしました。以降半年ほど、決定論的ハーネスエンジニアリングの現場適用とフレームワークのR&Dに従事してきています。

決定論的に固めるハーネスエンジニアリングの中身

せっかくなので、この3日間で何をやったのかを振り返りとして言語化しておきたいと思います。前提として、AIの出力は非決定論的で毎回同じものが出るとは限らず揺らぎます。人間がレビューするという話ももちろんありますが、それだけに頼らず仕組みで品質を決定論的に固めたい、というのが大きなトライでした。

ハーネスに必要な仕組み群、スキルやルール、フック、コマンド、サブエージェントといった要素が揃ってきていた時期だったので、これらを外枠の枠組みとして最大限活用しました。

その核となるのが、仕様・テスト設計・検証を番号のIDでつなげるトレーサビリティです。仕様書の一文に振ったIDが、そこから導出されるテスト設計書のテストケース、さらに実行後の検証レポートまで一気通貫でつながる仕組みで、検証に紐づいていない仕様や仕様に紐づいていないテストがないかもスクリプトで機械的に判定できます。

IDをたどれば「何を保証し、どう検証されたか」に人間がいつでも答えられ、後追いでのトレーサビリティも担保されます。テストが通ったと言いつつ実装されていない、そもそもテストが書かれていない、といったAIの非決定的な振る舞いも、この仕組みでつながっていれば逃げられなくなり、正しく作ってくれるようになりました。

こうして仕様を書いてからテスト設計、実装、検証という順番で進める流れは、IT業界の経験が長い人ほど「ウォーターフォールっぽい」と感じると思います。実際その通りで、シフトレフト的にテストを先に書くという点も含めてウォーターフォールに近いです。

しかし、従来のウォーターフォールが1サイクル数ヶ月かかり手戻りが数ヶ月の損失になるのに対し、AIの速度で回転数を上げきったウォーターフォールは、1サイクルが数時間、1日に何周も回せるレベルになり、いわゆるアジャイル的なイテレーションとほとんど区別がつかなくなると思います。何回もぐるぐる回して品質を高く検証し、できたものが期待通りであることを確かめられるのが重要です。

決定論的につながっているとはいえ、レビューをきちんと行うことも重要です。AI自体に別のコンテキストやペルソナを持たせてレビューさせる、テストはコードを先に作るのではなく仕様から導出する、という順番を徹底しました。

さらに回転数を上げても壊れないための仕組みとして、形式手法も活用しています。仕様を書いた後、矛盾や曖昧さがゼロになるまで機械的に検査し、ゼロになって初めてテスト設計へ進むというフローで、「実装してから仕様の矛盾に気づく」という手戻りを最初から締め出しています。新しい仕様がこれまで書いた仕様と矛盾していないかも、この形式手法で検証できるので、形式手法自体は導入のハードルが高い手法ですが、ハーネスが勝手にやってくれる世界観であれば人間が意識しなくてよくなるのも利点です。

さらに、同じクエリを自作OLAP DBとDuckDB、Polarsという3つのエンジンに投げて答えを突き合わせる「オラクルテスト」と呼ばれる古典的な手法も使っています。答えが一致すれば前進し、不一致であれば自作側の誤りをその場で検知して即座に修正する、というものです。テストの見落としは、この答えの不一致が教えてくれます。

ベンチマークで測った性能についても、専門家AI、つまり「あなたはデータベース専門家です」という立場でレビューさせ、期待した通りの性能が出ているかを確認し、おかしければディープリサーチをやり直して最新の研究と照らし合わせる、というのをひたすら回していました。

業務SaaSへの適用：レポートエンジンのリプレイス

ここまでは、仕様が世の中にすでに確立している「基盤データベース」を作った際の話でした。ログラスの本業は経営の意思決定を支える業務SaaSを作ることであり、OLAP DBはあくまで週末3日間の実験に過ぎません。

OLAP DBは仕様自体が世の中で確立していて最初のインプットとして明確でしたが、業務SaaSの開発にもこのやり方が通用するのかというのが次のチャレンジになっています。

既存プロダクトには、レポート的な機能を持つ部分で、データ規模が大きい場合の処理性能や、内部仕様の保守性に改善余地がありました。これを週末にトライした手法でできないかと、現場に入り込みながら試すことにしました。

ここでフィーチャーフラグを使い、稼働し続ける既存システムの中で旧エンジンと新エンジンをオン・オフ切り替えられるようにしてみました。問題が起きてもスイッチひとつで即座に元へ戻せるうえ、旧エンジンにすでに存在する仕様を正としてオラクルテストに使える、これをリバースエンジニアリングしながら既存の仕様を満たす新エンジンを作ればいいのではないか、という仮説のもとで進めました。

同じハーネスと規律を実プロダクトにも適用し、仕様の一文一文に番号を振って、仕様策定・テスト設計・実装・検証まで同じ番号で追跡できるようにしました。3日間のトライで確立した手法を、そのまま実プロダクトの複雑な既存コードに持ち込んだ形です。

この規律があったからこそ、次に語る結果につながったと思います。

結果として、パフォーマンスの高速化は大幅に改善し、もともと数ヶ月かかると見込んでいたものが、動くまでの話だけなら営業日8日ほどです。ただし品質を担保するには網羅的に、いろんなシナリオをテストしないといけません。16の因子を単純に掛け合わせると約3,000万通りにも組み合わせが爆発してしまうため、どの2因子のペアも必ず1回は現れるように選ぶ「ペアワイズ法」という枯れた設計手法を使って82構成にまで圧縮し、2因子ペアの網羅率100%（120分の120）を確保して検証していきました。ほかにも判定分岐のデシジョンテーブル138ルールや、業務の年間リズムに沿った横断シナリオ8本なども用意し、見つけたバグは再現テストにしてから直す、ということを繰り返しました。

バグを見つけては直すというサイクルを重ねた結果、最終的には2ヶ月ほどかかったのですが、それでも、本来半年から1年ほどかかりそうなものが2ヶ月でできたのは、かなり素早く品質の高いものを作れたと言えます。

「仕様が違えば間違ったものを爆速で作るだけ」という気づき

ただ、ここで大きな問いにぶつかりました。この手法が守ってくれるのは、あくまで「仕様通りに正しく動く」ことだけです。そもそも仕様そのものが間違っていたらどうなるのか。正しく作る仕組みは、間違ったものを高速に量産する仕組みになってしまいます。

実際、レポートエンジンの作り直しと並行して新規機能の開発も紛れており、この手法を試すと、「そもそもこの仕様はどうなのか」という前提を揃えるための問いがAIから大量に返ってくる場面が出てきました。品質保証や高速な開発がどれだけすごくなったとしても、その仕様が本当にお客様にとって価値があるのか、意味のあるものになっているのかには、我々自身が真摯に向き合わなければならない、という気づきです。

なぜ、週末のOLAP DBのトライや既存業務SaaSの作り直しは手堅くいったのか。理由は同じで、「仕様がすでに存在していた」からです。週末のOLAP実験は世の中に答えがあり、既存業務SaaSの作り直しは自社の旧エンジンという形で答えがすでにありました。

しかし新規機能開発では誰も答えを持っておらず、仕様の「手前」にまで踏み込む必要がある、という違いがあります。だからこそ、開発の外側にハーネスを広げる必要が出てくるのです。

ダブルダイヤモンドとAIをインタビュアーとして使う手法

そこで、ハーネスを開発工程の外側にも広げ、開発だけでなくその手前のディスカバリーのフェーズと、作ったものをデリバリーした後に仮説が満たされたかを確かめるフェーズまで、ライフサイクル全体を一本の鎖でつなげることが重要だと考えるようになりました。

これはハーネスが自動的にやってくれるという話ではなく、上流に行けば行くほど人間の判断がちゃんと挟まっていく必要があり、それをどうやって実現するかの試行錯誤です。

そもそも何を作るのかという情報をアーティファクトとして定義し、提供価値や機能領域、成功基準を言語化すれば、それを入り口として先の開発プロセスに落とし込めるのではないか、という仮説を持って試してみたところ、AIはすごい勢いでその欄を埋めてくれました。ただ、ざっくりとしたイメージを伝えただけで顧客課題や提供価値、成功基準がわーっと埋まってしまうと、どういう案を検討してどういう理由でそこに収束したのかがまったく分からず、パッと見良さそうに書かれているぶん逆に不安になる、という学びがありました。

そこで大事にしているのが、デザイン思考の定石プロセスとして知られる「ダブルダイヤモンド」です。正しい課題を見つけるために問題空間で発散し課題を収束させ、続いて正しい解を見つけるために解空間でもう一度発散し解を収束させる、この「広げてから絞る」を二回やることで、正しい課題なしに正しい解はない、という考え方を実践しています。ここでのAIの役割はドキュメントを生成することではなく、発散と収束のプロセスを手伝ってくれるインタビュアー的な立ち位置で使っています。「grill-me」や「grilling」といった名称で最近世の中に広まっているスキルを使い、いろんな問いを投げてもらうことで、人間が意思を込めて答えながら考えを広げていくことができ、自分たちの意思を説明責任として残せるし、よく分からないところはちゃんと空白として残せます。

こうしたハーネスやプロトタイプを作れる仕組みを整えることで、エンジニアだけでなくビジネスサイドのメンバーも、仮説をもとに「だいたいこんな感じでどう」というプロトタイプを作れるスキルも用意しました。開発リソースを待たずに単独でプロトタイプを作成し、とにかく価値検証に時間を費やすことで、素早く価値検証を回せるようになると思います。

さらに、より蓋然性の低い仮説を潰していく順番をプロジェクトマネジメントとしてスキルにインプットしていくトライアルも進めています。これはまだ結果が出ているものではなく、新規事業で今まさにトライしている最中です。

まとめ：打席と打率、Why・Whatに向き合う時代

どう作るかというHowの部分は、世界最高峰のエンジニアと一緒に働いているような感覚で進められる世界観になってきました。だからこそ人間が本当にやらなければならないのは手前側に移り、なぜそれを作るのか、何を作るのかという、本来当たり前だったはずのプロセスに真摯に向き合うことです。想定顧客の業務を理解し、対話をし、仮説を立てて検証するというプロセスはそもそも大事だとずっと思っていたはずなのに、開発の大変さゆえに開発生産性の議論にセンサーが向きがちだった、それがAIを追いかけていたら結局はここが大事だという原点に戻ってきた感覚があります。

これまでプロダクトマネジメント、デザイナー、エンジニアリング、ビズデブといった役割分担がありましたが、この原点の前では職種の境界はどんどん溶けていき、誰もが「何を実現したくて何を作るのか」という同じ問いに本気で向き合う時代になってきたと思っています。

ログラスには「Update Normal」と呼ぶプロダクトチームバリューがあり、当たり前を常に更新し続ける開発組織カルチャーを大切にしています。今日話したテーマである「動くだけのその先へ」を振り返ると、バイブコーディングは誰でもできる「動く」の段階です。最初にトライしていたのは、正しく動く、品質高く動く仕組みで担保できるやり方は何だったかというところでした。

これを極め続けると、そもそも価値があるものをどうやって作るのかという、当たり前ではあるけれどもその先にたどり着いた場所に改めて向き合うことになります。仮説を試す打席をとにかく増やすことと、打率を上げること、その両方を追求し続けることで、プロダクトの価値の改善性を上げていきたいと思っています。

私の講演としては以上になります。本日はありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。