フリーヒルズラボでの取り組み

私が大学発スタートアップ「株式会社フリーヒルズラボ」に参画して、1年以上が経過しました。現在は執行役員として、主に特許情報の解析と技術マッチング領域のシステム開発を牽引しています。

フリーヒルズラボは「ものづくりの現場を支援するAI・Webアプリの開発」を中心に、社会に価値を届けようとしています。また、研究室スピンアウト企業であることから「特許を起点とした技術マッチング」や「オルタナティブデータを活用した経済予測」といった、非常にポテンシャルの高い要素技術やデータを有しています。

しかし、活動を続けていくうちに痛感したのは「技術があること」と「社会に価値を提供できていること」はイコールではないという現実でした。

どんなに高度なAIや独自データがあっても、それを「誰の、どんな課題を解決するサービスとして提供し、どうやって収益を得るのか」というビジネスモデルが描けていないということは、厳しい見方をすれば「社会から継続的な価値として認められていない」と捉えることができます。

どうにかして、この技術を自立したサービスとして社会に届けたい。その思いが、私にとっての大きな原動力になっています。

サービス化を見据えた時、私が真っ先に着手したのは特許データベースの根本的な再構築でした。

私が参画した当初、すでに特許DBの原型は作られていました。しかしそれは、研究用の数十万件のデータで検証を行うためのモックアップに近い構造であり、実運用において数百万件の特許データを高速に捌き、AIと連携させるようなスケールアップには耐えられない状態でした。

どんなに優れたアプリケーションのUIを作っても、根幹となるデータ基盤が脆弱であれば、サービスはいずれ破綻します。私は執行役員として、組織の将来的なスケールを念頭に置き、技術選定から見直してデータベースを一から設計し直す決断を下しました。

現時点では、約470万件の特許公報データを格納し、高速なテキスト検索や意味検索に耐えうる事業基盤として運用しています。

データ基盤という土壌を整え、現在私が最も力を入れて開発しているのが「Veridea」です。

Verideaは、フリーヒルズラボの目標である技術マッチングを体現するWebアプリケーションですが、ただのAIツールではありません。私が研究を通じて得た「ハルシネーションの不確実性を隠さず、透明性を担保する」という知見を、UIやシステム設計の随所に組み込んでいます。研究や検証で幾度となくハルシネーションを目撃し、私自身も惑わされてきたからこそ、ユーザーリテラシーのみに依存するのではなく、システム層でも補助したうえで、安心して生成AIと向き合える環境を提供したいという思いがあります。

ただコードを書く一人のエンジニアとしてではなく、事業の方向性を見据える立場として、「ユーザーが本当にお金を払ってでも使いたいと思えるか」「安心して業務に組み込めるか」を常に問い続け、最適なアプローチは何かを日々模索しています。

開発だけでなく、実際に外部企業の方々と打ち合わせをする機会もいただいています。

ビジネスの現場では、「技術的に正確であること」と「顧客が求めている価値」が必ずしも一致するとは限りません。「自社に技術はあるが、商流がなくどこに売っていいか分からない」といった切実な声や、「突飛な飛躍ではなく、まずは地に足の着いた現実的なアイデアが欲しい」といった具体的なニーズ。

そうした生の声に触れることで、このシステムは誰の、どんな課題を解決するためにあるのかを日々考えさせられています。

事業を支える基盤を構築する中で、私自身のコードに対する向き合い方も大きく変わりました。

プログラミングを始めた当初から「コメントアウトを丁寧に書けばいい」という意識はありました。しかし、今思うと自分だけが理解できるコメントだったのかもしれません。

フリーヒルズラボという組織で長く運用していくシステムにおいては、将来新しく加わるメンバーがいかに迷いなく開発に参加できるか、認知負荷を下げられるかが重要になります。経験したことのない規模感のコードベースの肥大化と複雑化を目の当たりにするうちに「技術負債は極力作らず、コードの品質を保ちたい」という思いが強くなりました。

特に大事にしているのは、「安易に変数名を省略しない」ことです。

例えば、特許公報は patent_publication と表せますが、これを pat_pub と略すこともできます。しかし、このような省略形が用いられているとコードを読むたびに頭の中でわずかであっても「変換コスト」が発生してしまいます。また、法人情報などの外部由来のデータは、公式のリソース定義書やAPI仕様書に沿った正式名称（例: corporate_number）をそのまま利用することを徹底しています。それだけで、外部データソース、DBのカラム名、そして変数名までの間に一貫性が保たれるからです。

略称が慣習として定着している場合でも、同じことが起こりえます。たとえば conn (connection) や cur (cursor) は、データベース接続のサンプルコードに頻出する略称ですが、キャッチアップ当初はどちらの意味も分からず、ある種の呪文として書いていました。表面上は動くコードが書けていても、その行で何をしているかを理解しきれていない。今では略称でも意味を理解した上で流せるようになっていますが、そこを理解して書けていない状態は、どこか怖いなと感じる節もあります。「省略しない」という原則は、そうした状態を自分自身に対しても防ぐ意味があります。

LLMを活用した開発が当たり前になった現在、この意識はより重要性を増していると感じています。生成AIはプロジェクト全体のコンテキストを持たないため、同じ概念に対して場所ごとに異なる略称を使うことがあります。コードを読むのは人間ですから、複数のファイルで同じ概念が別々の名称で定義されていれば、その都度「変換コスト」が発生します。「原則省略しない」というルールは、そうした断絶を防ぐ最もシンプルな手段であると捉えています。

ほかにも意識していることとして、動的型付け言語であっても型定義を明示することや、LinterやFormatterを厳格に適用すること、ドキュメンテーションコメントを記述することなども挙げられますが、すべてはこの「認知負荷の低減と一貫性の担保」という同じ意識に基づいています。

こうした意識の積み重ねが、システムを組織の資産へと昇華させていくのだと思います。

この1年間で、私の視界は大きく広がりました。

自分がイメージした通りにプログラムが動く楽しさから出発したエンジニアリングですが、今は「構築したシステムが、どのように社会の課題と結びつき、事業として自立していくのか」という、より大きな構造を組み上げることに強い責任を感じています。

安定したビジネスモデルの確立など、組織としての課題はまだ山積しています。しかし、その不確実な壁に技術と設計で立ち向かい、道を切り拓いていく過程こそが、スタートアップで活動する最大の面白さだと感じています。