Hamlet CEOのSunil Rajaraman氏、エンジニアのErich Douglass氏およびJeff Hui氏との対談
によって サラ・シュテフェン による投稿
地方自治体の意思決定へのアクセスや検索を容易にするAI駆動型プラットフォームであるHamletは、DatabricksのLakebase Postgresを活用して、すべてのプルリクエストに本番データの専用ブランチを割り当てています。エンジニアやAIコーディングエージェントは本番環境に影響を与えることなくリアルデータで変更をテストでき、すべてのマージは最終的に人間が承認します。
CEOのSunil Rajaraman氏、リードデベロッパーのErich Douglass氏、シニアAIエンジニアのJeff Hui氏に、彼らの取り組みについてお話を伺いました。
Hamletは、地方自治体の意思決定へのアクセスや検索を容易にするAI駆動型テクノロジープ ラットフォームです。全米の数千に及ぶ市議会、計画委員会、都市計画委員会の議事録のインデックス作成と文字起こしを行うことで、不動産開発業者、ジャーナリスト、研究者、市民が議事録を即座に検索し、地域の政策動向を追跡し、特定のトピック、住所、企業に関するリアルタイムアラートを設定できるようにしています。
Sara Steffen：Hamletは全州の7,200以上の自治体から会議データをインデックス化しています。そのデータ環境はどのようなもので、理解するのがなぜそれほど難しいのでしょうか？
Sunil Rajaraman：米国には1万9,000の市政府、3,000の郡政府、そして約8万の特別区が存在します。その中から2つのウェブサイトを選んだとしても、見た目は全く異なります。それこそが地方自治体の根本的な問題です。一握りのCMSプロバイダーがすべてのサイトのデザインを変えることを決定した結果、政府のインターネット空間は完全に断片化されてしまいました。Hamletはそれらをすべて集約し、標準化しています。
Sara：Hamletは自社をシビックインテリジェンスプラットフォームと位置付けています。文字起こしツールとどう異なり、なぜその違いが重要なのでしょうか？
Sunil：多くのGovTech企業は、自治体データの仲介業のようなことをしています。1998年頃の古いウェブサイト向けに壊れやすいスクレイパーを書き、見た目を現代風に整えているだけです。データをスクレイピングして保存するだけでは、大した価値は生まれま せん。重要なのは、事実に基いてストーリーを語ることです。つまり、誰が発言していて、その問題についてどう考えているのかを把握することです。もしあなたが開発業者なら、市議会議員が住宅プロジェクトを承認してくれるかどうか、その理由、そして市が難色を示す可能性のある過去の経緯を知りたいはずです。
許認可業務を例に挙げてみましょう。許認可データには多額のベンチャーキャピタルが投入されてきましたが、過去10年間で許認可の取得期間はかえって悪化しています。多くの企業が表面的な症状に対処する仕組みを作ってきたに過ぎません。私たちが解決したいのは、人間を理解するという根本的な問題です。私たちが追求しているのは、都市が根本的にどのように機能しているかという問いです。
Sara Steffen：地方自治体のデータを扱うのがこれほど難解な理由は何ですか？
Sunil Rajaraman：どの2つのウェブサイトをとっても、デザインが全く異なります。Hamletはそれらをすべて集約し、標準化しています。
Erich Douglass：単一のプロバイダーと統合するだけでは不十分です。7〜8社で市場の約75%をカバーできますが、残りはカスタム設定の膨大なロングテールです。担当者が議題のPDFをアップロードすることもあれば、紙のコピーをスキャンしてアップロードすることもあります。そのため、かなり奇妙なデータが生成されることがあります。
Sara：顧客はそのデータから何を必要としているのでしょうか？
Sunil：当社の顧客は、不動産開発事業者、デ ータセンター事業者、小売業者などの民間企業です。そのほぼ全員が、プロジェクトの承認を迅速化したい、または新しい機会を見つけたいと考えています。Hamletがなければ、担当者は何時間も会議に同席し、自分のプロジェクトが取り上げられるのを待ち、当局者のボディーランゲージを伺うことになります。私たちは、誰が発言したかを特定し、該当のタイムスタンプに案内して、明確な証拠を提示します。
Erich：また、先例も求められています。自社と類似のプロジェクトが過去に承認または却下されたことがあるか、その理由は何か、市議会はどのような変更を求めたか、といった点です。現場で何が起きているかの真相を示すことができれば、非常に大きな価値を提供できます。
Sara：顧客が見つけたインサイトを信頼できるようにするために、どのような工夫をしていますか？
Jeff Hui：私たちはプロセスのほぼすべての部分でAIを活用しています。初期の頃、Hamletは手作業でこれを行っていましたが、それでは数千の自治体には対応できません。多くの自治体にとって、動画が唯一の一次情報源（Source of Truth）です。それを活用可能な構造化データに変換することが最も重要なプロセスです。平均的な会議は約3時間半に及びます。誰もそのすべてを見たくはありません。AIが確認する価値のある箇所を提示し、いつでも動画で裏付けを確認できるようにしています。実際に何が言われたかを正確に示すことができますが、これは多くのAIシステムが得意としない部分です。
Sara： 数千もの会議の中で、どのようにして発言者を正確に特定しているのですか？
Jeff：コンテキスト（文脈）が最大の鍵となります。発言者の特定にあたっては、どの議会や委員会が開催されていて、当時誰が所属していたかを把握しています。これにより、録音を聞いている人間でさえ聞き取りにくい名前の特定が容易になります。単にモデルに動画を読み込ませて良い結果を期待することはできません。正しく判断できるように、あらゆる周辺情報を収集する必要があります。これは永遠の課題です。
Sara：当局者の発言に対するAIの解釈をどのようにチェックしていますか？
Sunil：まず重要なのは正確な文字起こしです。感情分析（センチメント分析）については、複数のAIモデルを使用して、コメントが特定のトピック（例えばデータセンターなど）に関するものであることを確認します。その後、周辺の文脈を考慮して賛成か反対かを判定します。
質問する前に、「賛成」や「反対」が何を意味するのかを定義することも必要です。警察活動を例にとると、「賛成」とは何を意味するのでしょうか？私たちはそうした問いの設定に細心の注意を払っています。現在では、公開前に複数のモデルがすべてのセンチメント数値を検証しており、高い確信度を求めています。
Lakebaseは、Hamletが各プルリクエストに本番データの独自のブランチを与えるために使用しているマネージド Postgresデータベースです。エンジニアは本番環境に触れることなくバグの原因となったデータに対して変更をテストでき、AIコーディングエージェントはパイプラインを実行して、人間がマージを承認する前に作業を確認します。チームによると、以前のテストデータ設定では、エンジニア1人あたり毎週数時間を要していたとのことです。
Sara：なぜLakebaseを選んだのですか？また、チームにとってどのような変化がありましたか？
Erich：以前はAWS RDS上に、1つの本番インスタンスと1つのステージングインスタンスという一般的な環境を構成していました。私たちの業務の多くは、非常に特定のデータに対してデータパイプラインをチューニングすることです。すべてのプルリクエストについて、検証を実行する前にステージング環境を適切な状態にするために15〜30分を費やしていました。少人数チームである私たちが最も重視しているのは開発速度です。
導入の決め手となったのはデータブランチ機能でした。現在では、すべてのプルリクエストがプレビュー環境に接続された本番データの専用ブランチを取得します。プレビューがデプロイされた時点で準備は完了しています。本番データに影響を与えることなくテストを実行し、さらには書き込みを行うこともできます。
オートスケーリングも効果的です。RDSでは、インスタンスのサイズ変更に伴うマイグレーションに数時間を要することもありました。現在ではスライダーを動かすだけで、2倍の大きさのインスタンスが得られます。
Jeff：15〜30分というのは、運良く適切なデータをコピーできた場合のベストケースでした。各エンジニアは問題追跡のために本番データの一部をローカルにクローンするなど、テストデータを最新に保つために週に数時間を費やしていました。現在ではバグが発生した際、その原因となった正確なデータが存在するため、その同一データを用いて修正を検証できます。
Sara：Lakebaseによって、AIコーディングエージェントの働き方はどのように変わりましたか？
Jeff：ブランチのおかげで、私たちのワークフローはAIコーディングエージェントに非常に適したものになりました。各プルリクエストは本番環境から分離されています。ClaudeやCodexといったエージェントにブランチへのアクセス権限を与え、独自のチェックを実行させます。エージェントはデータパイプラインを最後まで実行し、変更が期待通り機能するかを確認します。すべてのプルリクエストは、まずエージェントによる一次チェックを受けます。人間が確認する頃には、正しく機能するという十分な確信が得られています。最終的なマージ承認は人間が行いますが、それ以外のプロセスの多くが自動化されており、Lakebaseがそれを実現する大きな要因となっています。
Sara：Lakebaseを活用して、次にどのような試みを計画していますか？
Erich：現在、データの大部分はリレーショナルデータベースに保存されており、検索は別のベクトルデータベースで動作しています。そのため、2つの間で同期がズレてしまうことがあります。検索のテストを行う際、以前のステージングの問題が再発してしまいます。Postgresでベクトル検索とテキスト検索を統合するLakebase Searchを試していますが、すべてが1箇所に集約されているのは非常に優れています。
Sara：検索以外で、次に簡素化したいことは何ですか？
Erich：ブランチ機能が非常にうまく機能したため、オブジェクトストレージに保存している大容量ファイルについても同様の機能を望んでいます。各デベロッパーは、1つの共有本番バケットの隣にテストバケットを持っており、それらの間で状態を管理するのが困難です。
Jeff：また、より実行時間の長いエージェント型（Agentic）ジョブをどこで実行すべきかも検討しています。データ取り込みの一部では、AIを使ってウェブブラウザを操作し、政府サイトで適切なコンテンツを検索しています。数分で終わる実行もあれば、30〜40分かかるものもあり、現在のAWS Lambda構成では15分の制限があります。
Hamletの取り組みは元の会議録音から始まるため、お客様はAIによるインサイトを役員の発言まで遡って追跡できます。Lakebaseはそのエクスペリエンスを支えるエンジニアリングワークフローをサポートします。本番データのブランチにより、開発者やコーディングエージェントは本番環境に触れることなく変更をテストでき、人間が最終的なマージを承認します。数千もの行政機関を担当する小規模チームにとって、これはテストデータの準備時間を減らし、製品の改善により多くの時間を割けることを意味 します。
プルリクエストごとにLakebaseブランチを作成し、自動削除するにはどうすればよいですか？
継続的インテグレーション（CI）パイプラインに2つのステップを追加します。プルリクエスト（PR）が開かれたときに本番からブランチを作成し、PRがマージまたはクローズされたときに削除します。両方のステップは Databricks CLIでスクリプト化し、 GitHub Actionsなどのツールから実行できます。ブランチを作成する際に有効期限（TTL）を設定しておくと、クリーンアップステップが実行されなかった場合でも自動的に削除されます。完全な例については、ブランチベースの開発ワークフローチュートリアルを参照してください。
Postgresにおけるデータベースブランチ機能はどのように動作しますか？
Lakebaseブランチは独立したPostgres環境であり、親のスキーマとデータから開始し、コピーオンライトを介してストレージを共有します。ブランチ上で行われた変更のみが個別に書き込まれるため、ブランチの作成はデータベースのサイズに依存しません。標準的なPostgresは既存のデータベースをコピーして新しいデータベースを作成するため、データが重複します。Lakebaseのデータベースブランチはそのコピーを回避し、子ブランチでの変更が親に影響を与えることはありません。
開発チームにデータベースブランチ機能を導入するにはどうすればよいですか？
Hamletが使用しているパターンである「プルリクエストごとに1つのブランチ」から始め、ワークフローの残りの部分にブランチ作成を拡張します。各パターンは、共有のステージングデータベースを分離された環境に置き換えます。
Lakebaseブランチのコストはどのくらいですか？
コストはコンピューティングとストレージによって異なります。各ブランチには独自のコンピューティングがあり、アイドル状態のときはゼロにスケールダウンするため、アクティブなコンピューティング時間分のみ支払いが発生します。ストレージについては、有効期限のあるブランチは変更されたデータ分のみ課金されますが、有効期限のない無期限ブランチはフルデータサイズに対して課金されます。短期間のブランチには有効期限を設定してください。オプションの詳細については、ブランチの有効期限を参照してください。
AIコーディングエージェントは、本番環境に触れることなくLakebaseブランチでテストできますか？
はい、可能です。各ブランチは本番環境から分離されているため、エージェントはマイグレーションを適用し、テストを実行して、完了時にブランチを破棄できます。最終的なマージは依然として人間が承認し、スキーマの変更はブランチのマージではなく、コード内のマイグレーションを通じて親ブランチに移動します。
Lakebaseの詳細については、 Lakebase Postgres製品ページをご覧ください。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。