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

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

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

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時点 

非連続成長を実現する 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人 

非連続成長を実現する 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予定 

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

契約 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の発表 

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

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

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

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

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

No content

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

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

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

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

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

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… 

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等の密なコミュニケーションの中で それぞれのメンバーが課題を提案し取り組む文化 直近の取り組み 

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等の密なコミュニケーションの中で それぞれのメンバーが課題を提案し取り組む文化 直近の取り組み 

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

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

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

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