Slide 1

Slide 1 text

SRE新規立ち上げ! Hubbleインフラのこれまでと展望 【SRE特集】3社が語るSREの役割 組織の変遷と直面した課題とは?

Slide 2

Slide 2 text

AI契約業務‧管理クラウド 藤井 克也 2022年東京⼤学⼤学院学際情報学府博⼠後期課程修了 (暦本研)。Sony CSL、MIT Media LabでResearch Assistantと して研究職に従事。帰国後ITコンサルタント業を経て、2016 年Hubble創業&CTO就任。 Co-founder & CTO

Slide 3

Slide 3 text

● Hubbleの開発体制について ● Hubble x LLM ● OpenAIレート制限との関わり方 ○ 非同期処理時代 ○ 対話型時代 ● HubbleのSRE役割

Slide 4

Slide 4 text

2,632,430 契約書数 3,985,421 契約バージョン数 2,515,924 コメント数 「あらゆる人が積極的に「契約」と向き合える世界をつくる。」 ID **589 編集/変更 2 ID **123 相手修正 3 ID **123 締結 6 … ID **589 編集/変更 2 ID **795 依頼承認 1 ID **589 編集/変更 4 ID **123 相手修正 5 ID **795 譲歩承認 5 ID **123 譲歩相談 5 ID **123 押印申請 6 ID **846 (担当役員) ID **589 最終調整 6 ID **846 最終承認 6 ID **123 複製更新版 1 締結版 発生・起案 審査・交渉 押印申請・捺印 保管・管理 更新 ID **793 (営業部長) ID **589 (法務) ID **123 (営業) ID **123 依頼申請 1 ID **795 一次承認 6 *2025/07時点

Slide 5

Slide 5 text

非連続成長を実現する AI時代の契約業務・管理を作る AI 開発する4つのチーム体制 Squad モデル 機密情報を扱う上での 柔軟で強固な権限管理の専門チーム Core 開発生産性向上と 効率的な開発を支えるチーム DevEx Hubble全体の顧客体験の向上を図り、 強みを強化していく ValueUp 正社員人数 (業務委託人数 ) 25人 (20人) PdM 4人 PjM (1人) QA 2人 (6人) Frontend 4人 (2人) Backend 10人 (7人) CRE 2人 SRE 1人 (2人) EM 3人

Slide 6

Slide 6 text

非連続成長を実現する AI時代の契約業務・管理を作る AI 開発する4つのチーム体制 Squad モデル 機密情報を扱う上での 柔軟で強固な権限管理の専門チーム Core 開発生産性向上と 効率的な開発を支えるチーム DevEx Hubble全体の顧客体験の向上を図り、 強みを強化していく ValueUp 正社員人数 (業務委託人数 ) 25人 (20人) PdM 4人 PjM (1人) QA 2人 (6人) Frontend 4人 (2人) Backend 10人 (7人) CRE 2人 SRE 1人 (2人) EM 3人 2025年より本格的に SREチームの立ち上げ始動 2025/06 業務委託 SRE1名Join 2025/07 業務委託 SRE1名Join 2025/09 正社員 SRE1名Join予定

Slide 7

Slide 7 text

● Hubbleの開発体制について ● Hubble x LLM ● OpenAIレート制限との関わり方 ○ 非同期処理時代 ○ 対話型時代 ● HubbleとSREのこれから

Slide 8

Slide 8 text

契約 AI 他業界よりも高い割合で、 AI導入が 現実的に期待されている 分野。 引用元:Global Economics Analyst (26 March 2023 ), The Potentially Large Effects of Artificial Intelligence on Economic Growth (Briggs/Kodnani), p7. % 44 が自動化 リーガル業務の 2023年 Goldman Sachsの発表

Slide 9

Slide 9 text

2023/12 業界初 GPT-4による自動情報抽出機能をリリース 契約書をアップロードすると契約相手方、契約終了日等の情報を自動抽出

Slide 10

Slide 10 text

2023/2024 OpenAIの制限 Input/Outputでトークン数が制 限されており、契約書の全デー タを載せることができない場合 があった。 トークン数 1分間あたりに使えるトークン数と リクエスト数に制限 TPM/RPM 革命的な機能ではあるが、 1契約書数百円とコストがかかる コスト

Slide 11

Slide 11 text

2023/2024 OpenAIの制限 Quota Limit 緩和申請をひたすらやる日々。。 (Azure OpenAI) トークン数の対応 TPM/RPMへの対応 非同期処理 + Schedulingでタイミングを制御 (TPMがある程度大きくなってきた段階ではAWS Batchへ) 言い換えると、 リアルタイム にOpenAIを活用する機能は難しかった

Slide 12

Slide 12 text

● Hubbleの開発体制について ● Hubble x LLM ● OpenAIレート制限との関わり方 ○ 非同期処理時代 ○ 対話型時代 ● HubbleとSREのこれから

Slide 13

Slide 13 text

2025 OpenAIの凄すぎる進化 トークン数 100万トークン超大容量で性能爆 上げ(GPT4.1) TPM/RPM 賢いのにどんどん安くなる コスト Azure Enterprise契約でほぼ気にし なくて良いレベルへ( 500M/分) ● トークン数や TPM問題はモデル進化と Azure Enterprise契約に移すことでほぼ無問題に ● モデルのリージョン数も増え、スケールしやすい状態 ● モデルのレスポンススピードも速くなった 非同期から 対話式、リアルタイム な機能提供を開始

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

2025/07 業界初のリーガル AI Agent構想を発表 テレビ朝日「スーパーJチャンネル(土曜・日曜)」

Slide 16

Slide 16 text

GPT4.1 26リージョンで利用可能 (2025/7現在) terraform deploy可能 リージョン数の増加 API Managementの導入 リージョン選択をAPI Managementに委任 OpenAI周りのインフラ強化

Slide 17

Slide 17 text

API Management x OpenAI ● 共通エンドポイント + URL Pathで使用モデルをユーザー側で指定可能 ○ ex)f /openai/deployments/o1-mini/, /openai/deployments/gpt4.1/ ● API Managementポリシーでリージョン制御、セキュリティ保護が実施可能 ○ トークンのレート制限に引っ掛かっても自動で別リージョンへリダイレクト Bearer xxxx sweden-cent 0 ラウンドロビンにリージョンを選ぶポリシー例

Slide 18

Slide 18 text

● もはやコモディティ化していく ○ ユーザーの期待値も上がっている ○ 出すなら早く ● レート制限対策は1日にしてならず ○ 小さな機能から利用実績を積み上げていく ○ Azure Enterpriseなどを検討する( OpenAI Enterpriseもあり) ● Bedrockとかも視野に入れたい ○ 現状はOpenAIのブランド力が優勢か? ○ AWS内に閉じれるのは管理、セキュリティ的にベター HubbleとOpenAIの関わり方

Slide 19

Slide 19 text

● Hubbleの開発体制について ● Hubble x LLM ● OpenAIレート制限との関わり方 ○ 非同期処理時代 ○ 対話型時代 ● HubbleとSREのこれから

Slide 20

Slide 20 text

ElasticBeanstalkでサービス運用 GUI Consoleでぽちぽち管理 Dev/Stg/Prodを共通AWSで管理 2017 2019 Fargate運用に移行 Pulumiに挑戦するも挫折 2023 Terraform化 AWSアカウントを環境別に Datadogを活用した監視体制 Infra Histroy Hubble コスト最適化施策 監視・アラート体制 SLO/SLA/SLI設定・管理 etc… SREメンバー参画 CTOを中心に 各メンバーがそれぞれ対応 VPC/ALB/RDS/ElasicBeanStalk etc… Fargate/AppRunner/AWS Batch/Aurora etc… Redshift/Quicksight/Opensearch/Severless系 etc.. Security Hub/CloudTrail etc…

Slide 21

Slide 21 text

https://www.cleanpng.com/free/completed-stamp.html コスト最適化 ネットワーク精査 Fargateの定期停止 S3 Glacier対応 Saving Plans導入 AWS Enterprise On-Ramp経 由でAWSと定例を実施。コスト の削減提案やベストプラクティ スのご指導を頂く。 Fargateコンテナ間の中心は内部 向けALB経由での通信を行うべき だが、とあるサービスで外部 ALBを 叩いていたが故に NATのコストが 激増していた。 夜間、休日を問わず起動されづづ けていたためコストがかかってい た。開発・ステージング環境で使用 されていない時間は定期的にコン テナを落とす仕組みを導入。 データベースのバックアップやサー ビス上で長時間閲覧されないファイ ルはS3のGlacier対応。 ● コスト最適化よりスピード優先で開発を勧めてきたので、コスト最適化でできることはたくさん ● 定例会、Slack等の密なコミュニケーションの中で それぞれのメンバーが課題を提案し取り組む文化 直近の取り組み

Slide 22

Slide 22 text

https://www.cleanpng.com/free/completed-stamp.html コスト最適化 ネットワーク精査 Fargateの定期停止 S3 Glacier対応 Saving Plans導入 AWS Enterprise On-Ramp経 由でAWSと定例を実施。コスト の削減提案やベストプラクティ スのご指導を頂く。 Fargateコンテナ間の中心は内部 向けALB経由での通信を行うべき だが、とあるサービスで外部 ALBを 叩いていたが故に NATのコストが 激増していた。 夜間、休日を問わず起動されづづ けていたためコストがかかってい た。開発・ステージング環境で使用 されていない時間は定期的にコン テナを落とす仕組みを導入。 データベースのバックアップやサー ビス上で長時間閲覧されないファイ ルはS3のGlacier対応。 ● コスト最適化よりスピード優先で開発を勧めてきたので、コスト最適化でできることはたくさん ● 定例会、Slack等の密なコミュニケーションの中で それぞれのメンバーが課題を提案し取り組む文化 直近の取り組み

Slide 23

Slide 23 text

  監視・アラート体制 ● あらゆるサービスを Datadogで集約。検索 Queryを共有したり、 Dashboardを作成して常に監視。 ● エラー発生時は #datadog_notificationチャンネル上で開発メンバーが議論、対応。 ● Techleadを中心にdatadogのissueを定期的に対応。 ● バグの早期発見やリソース状況に応じた最適スケーリング等を随時行っていきたい。 直近の取り組み Datadogにデータ集約 Slack #datadog_notification Asana Datadog Issue

Slide 24

Slide 24 text

    SLO/SLA/SLI設定・管理 ● 正直まだ何もできてません。。。( SLA等の規定は存在) ● 海外サービスのようなかっこいい System Status を作りたい! ● 提供サービスだけじゃなく、他の部分でもイケてる会社でありたい。 直近の取り組み

Slide 25

Slide 25 text

  ● 契約書という大事なデータを扱う上で、強固なインフラ体制の構築へ ● まだまだこれからの組織なのでやることたくさん ○ SREとしてまだ成長期 ・・・> 立ち上げ時にしかできない経験を! ○ SREとしてそれなりに経験あり ・・・> 成果の集大成としての場として! ● カルチャーを大切にする会社です。 ○ お互いを尊敬し合い、切磋琢磨するメンバーが揃っています。 今後のHubbleにおけるSREチーム   絶賛採用中です!

Slide 26

Slide 26 text

ご清聴ありがとうございました。