理念と共に、最も困難で狂気の選択を考え続けて諦めない

世の中わからないことだらけだ.少し確かなことは検証をしたことだけ

2025年の振り返り(技術編)

あけましておめでとうございます。

2025年の振り返りを年始のタイミングでまとめます。

今までふり返りの記事はあまり書いてこなかったですが、今回は自身のふり返りだけではなく、まとめとして有意義だと感じたため公開記事として残そうと思います。

仕事

2024年9月にhacomonoへ転職してから、2025年は イベントバスの設計・実装を中心に過ごした一年でした。導入に向けてプロダクトチームへ伴走し、運用体制まで含めて形にしていく、というところまでを主軸に取り組みました。

それ以外にも、新たな基盤の設計のためにデザインドキュメントを書いたりインフラ面の支援、DBのインデックス未使用クエリを検知する仕組みの整備、分散システム領域の相談対応など、横断的に関わる役回りが多かったです。

インデックス未使用クエリ検知の仕組みについては、公開できる形に整えつつあるので、2026年に公開できたらと思っています。

対外的には、プリンシパルエンジニア(分散システム) と名乗るようになったことも、2025年の変化でした。社内では分散システムの専門家として課題解決能力が求められ、特定のチームに所属せず、組織横断的に課題解決に取り組む場面が増えました。

イベントバスの設計・開発・導入・運用もその一環で、数年後も高速かつ安全に開発していくための、重要なビルディングブロックの一つだと考えています。

なお、なぜ内製する必要があったのかについては、別途、社のテックブログでまとめる予定です。

論文を大量にインプットするための仕組み作り

2025年は、2024年よりも論文を大量に読めた一年だったと感じています。背景には、論文を大量にインプットするための仕組みを自作し、読む前処理を自動化できたことがあります。

最近はNotebookLMを活用される方も多いと思います。一方で、この仕組みの主眼は 要約を一切せず、翻訳したマークダウンとその音声を生成する という点にあります。論文の意図や細部を落としたくないため、要約は行いません。

具体的には、以下を一連の流れとして処理します。

  • URLからコンテンツの取得(PDF, HTML)
  • コンテンツのマークダウンへの変換
  • マークダウンコンテンツの翻訳
  • VOICEVOXを用いた音声生成

NotebookLMも何度か試したのですが、論文に記載されているモチベーションや細部が要約されることで、かえって理解が阻害される感覚がありました。そのため、私はこの仕組みによるインプットを継続しています。

また、私は散歩が趣味で、散歩中など「耳だけが空いている時間」が多いです。その時間に耳からインプットしつつ考え続けられるので、この方法と相性が良いのだと思います。

人生初の献本と『NewSQL徹底入門』

インプットという観点では、2025年に人生で初めて献本をいただくという嬉しい出来事もありました。『NewSQL徹底入門 分散DBのアーキテクチャからユースケースまで』を、著者のこばさん(@tzkb)から献本いただきました(講談社様より送付)。まずはこの場を借りて、献本いただいたことへのお礼を申し上げます。ありがとうございます。

www.kodansha.co.jp

本書は、NewSQLが求められるようになった背景から、分散DBを支えるアーキテクチャ(設計上の前提や考え方)、そしてユースケースまでを通して整理できる構成になっています。分散DBに関心がある方が「全体像を掴む」ための導線が丁寧で、同時に、データベースの内部実装の詳細、分散合意アルゴリズムの必要性、旧来のレプリケーションベースのデータベースとの違いなども丁寧に扱われています。

この本の面白いポイント(個人的によかった読みどころポイントや、自身の経験と照らしたときに刺さった点)については、後日あらためて単独の記事としてまとめたいと思っています。

大学院について

だいぶ昔の記事になりますが、以前は大学院へ飛び入学する予定でした。

bootjp.me

その後コロナ禍があり、飛び入学審査試験に必要な英語能力証明のためのTOEICが延期になりました。そこから目標を再設定しきれないまま、2023年まで過ごしていた、という状況です。

コロナ禍が明けた2023年当時は神奈川に住んでおり、JAISTの社会人コースに飛び入学で進学する想定でしたが、社会人コースが開催される品川まで片道1時間半かかるという問題がありました。そうした事情もあり、2023年にhacomonoへの転職のタイミングで自宅を売却し、東京へ引っ越しました。

hacomonoはフルリモートなので、東京へ戻ってきた理由は、ほぼJAISTの社会人コースが目的でした。

2025年に改めてJAIST社会人コースの説明会に参加し、篠田研究室にお邪魔しようとしたところ、新規募集が締め切られていることを知りました。篠田先生の直系であれば宇多先生の研究室が相当すると伺ったのですが、宇多先生のゼミは午前中に開催されるようでした。

私は持病として、幼少期から長いこと不眠を抱えており、午前から活動することに困難があります。そのため、JAISTへの進学目標はいったん諦めるという決断を2025年に行いました。

一方で、論文を書くこと自体は続けたいと思っています。今後も論文を書き続ける予定で、現在もKVSのデータティアリングに関する論文を執筆している最中です。

過去に「能力を疑われることで議論がスムーズに進まない」という経験があり、最低限の証明として博士号がほしいと思っていた時期もありました。ただ、今は環境に恵まれ、その必要性も感じなくなっています。

外部発表のまとめ

2025年は仕事の一環で外部に登壇する機会も多かったです。また、VRChatというメタバースプラットフォーム上で「分散システム集会」という分散システムに特化した集会を運営していることもあり、そちらも含めると登壇が多い一年でした。

ここからは資料ベースで振り返っていきたいと思います。

db tech showcase LT

こばさんからご紹介があり、ありがたいことに db tech showcase でLTをさせていただく機会がありました。

後日、主催のインサイトテクノロジー様の懇親会でも他の発表者の方々とお話でき、とても楽しい時間でした。

発表タイトルは「NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意」です。LTでは、Raftの説明を「理論」から始めるのではなく、NewSQL/分散DBの文脈で 何のために必要なのか に寄せて整理しました。

  • 取り上げたかった論点は「強い一貫性を、障害や分断が起きる現実の運用の中で扱うには何が必要か」という点です
  • Raftが提供するもの(ログレプリケーション、リーダー選出、自動フェイルオーバー)を、現場で困りやすい失敗例に紐づけて説明しました
  • その上で、Raftの得意(整合性・可用性設計の土台)と苦手(過半数待ちによるレイテンシ増や、合意形成の通信コスト、リーダーがボトルネックになりやすい点)を明確にしました


speakerdeck.com

Platform Engineering Kaigi

Platform Engineering Kaigi では、2025年にメインで進めていたイベントバスの設計と、その背景を「疎結合でスキーマ駆動開発を実現するイベントバスの設計」というタイトルで発表しました。

発表で伝えたかったことは「イベントバスを置くこと」そのものではなく、疎結合を“運用できる開発体験”にするための仕組み化です。

  • 背景:サービス同士がAPIを直接呼び合う世界では、サービス数の増加とともに依存関係の把握コストが上がり、変更が怖くなって開発速度が落ちやすい
  • 方針:Publish/Subscribe と fire-and-forget を前提に、「出来事」をイベントとして流し、各サービスは必要なイベントだけを購読する
  • 実装・運用に落とす工夫:イベントをスキーマ駆動(互換性チェック・検証・正当性確認)に寄せ、開発フローへ組み込む

細部の工夫としては、CIでの破壊的変更検知(Buf)、バリデーションの共通化(protovalidate)、署名検証(JWT)、重複抑制(DynamoDB)などを紹介しました。加えて「いきなり全てを置き換えない」段階導入の考え方も含めて、現実的に移行できる形としてまとめました。

www.cnia.io
speakerdeck.com
www.youtube.com

第16回 分散システム集会

VRChatのようなリアルタイム処理を支えるための非同期処理について発表しました。初学者の方向けに「なぜ非同期が必要なのか」から扱う構成にしており、現時点で資料は公開していません。

  • リアルタイム性(体験としての応答)を保つために、同期で守る範囲と非同期に逃がす範囲の切り分けをどう考えるか
  • ジョブ設計、リトライ、冪等性、失敗時の扱いなど、運用で破綻しやすい点を先に押さえる
  • 「成功したときに動く」よりも「壊れたときにどう復帰するか」を中心に据える

第17回 分散システム集会

AWSのMemoryDBの論文を読み、内容を解説しました。

Redis互換の低レイテンシを保ちながら、耐久性と一貫性をどう成立させるか、という観点で設計を追っています。

  • インメモリの実行系と、マルチAZに跨る永続ログ(耐久層)を分離し、障害時の「最新を必ず持つ」を成立させる
  • 非決定論的な振る舞い(Luaや一部コマンド)を、サービスの設計としてどう回収するか
  • 単なる機能紹介ではなく、サービスとして成立させるための設計判断(前提・制約・割り切り)が読み取れる点を中心に紹介しました

speakerdeck.com

第19回 分散システム集会

AkamaiのAdaptSizeについて解説しました。

CDNキャッシュの世界では、eviction(追い出し)だけでなく admission(そもそも入れるか)が本質的に重要になる、という問題意識から入っています。

  • サイズ分布が偏る現実のワークロードでは「入れ方」がキャッシュ効率を大きく左右する
  • サイズに応じた確率でキャッシュ投入を制御し、パラメータをオンラインで追従させることで、メモリ層の効率(OHR)を上げる
  • 研究としてのモデル化と、プロダクション運用へ落とす意図がセットで読める点を中心に整理しました

speakerdeck.com

第21回 分散システム集会

Amazon Aurora Serverless から Aurora Serverless v2 への刷新に伴う論文が出ていたので、そちらをベースに読み解説しました。

Serverless v1の制約を踏まえつつ、v2で「低レイテンシにスケールさせる」ために、どこに設計の主戦場を置き直したのかを追っています。

  • 1秒単位の推定でACUを増減し、余裕があればインプレースでスケールさせる
  • ホストがホットになったら凍結・移動に切り替える(ライブマイグレーションを“運用可能な仕組み”として成立させる)
  • DB内部の状態と、OS/ハイパーバイザ側の制御を合わせて移動コストを抑える工夫が読みどころでした

speakerdeck.com

執筆したブログ記事

2025年は発表だけでなく、ブログ記事としてアウトプットする機会もありました。

RedisをナイーブにQueueにするとデータロストする/可視性タイムアウトの役割

Redisを「キューっぽく」使うときに起きやすい落とし穴を、Queueの要件(少なくとも一度、未処理の救済)に寄せて整理した記事です。

  • 「取り出した瞬間に削除する」実装だと、処理中クラッシュで未処理メッセージがロストしうる
  • SQSのVisibility Timeoutのように、処理中は不可視にしてACKがなければ再配信する、という考え方が重要
  • Redisで近いことをやる場合の方針(処理中キュー、タイムアウト復帰、アトミック化、Streams/Consumer Groupなど)を紹介しました

techblog.hacomono.jp

クラウドネイティブなデータベースはなぜコンピュートとストレージを分離するのか

Compute / Storage 分離が一般化した背景を「何が嬉しいのか」「何を引き換えにするのか」という観点で整理した記事です。

  • Computeは可能な限り身軽にしてスケールを速くし、耐久性や回復の責務をStorage側へ寄せる、という方向性
  • スケールや復旧を「重い作業」から「接続し直す作業」に近づけることで、運用の性質を変える
  • 一方で、ネットワークI/Oや合意形成のレイテンシといったトレードオフもあるため、どこで相殺するか(設計と最適化)が論点になる

techblog.hacomono.jp

まとめ

2025年は、仕事と研究を「両輪」として回すための基盤が整ってきた一年でした。

仕事では、イベントバスの設計・実装から導入支援、運用体制の整備までを一気通貫で進め、疎結合なアーキテクチャを“運用できる開発体験”として成立させるための土台を作れました。あわせて、インデックス未使用クエリ検知の仕組みなど、日々の開発・運用に効く改善も進められました。

研究面では、論文インプットの仕組み化によって学習のスループットを上げられたこと、そして登壇・記事執筆・分散システム集会を通してアウトプットまで繋げられたことが大きな収穫でした。

また、『NewSQL徹底入門』の献本は、分散DBを体系として整理し直す良い契機になりました。面白いポイントについては、後日あらためて単独の記事としてまとめたいと思っています。

今後の展望

2026年は、2025年に積み上げたものを「定着させる」「外へ出す」「成果として残す」を軸に、仕事と研究の両輪で前に進めたいと思っています。

  • イベントバスを、より広いチームで使っても破綻しない形へ定着・改善する(運用・ガバナンス・観測性を含む)
  • インデックス未使用クエリ検知の仕組みを、会社のリポジトリでOSSとして公開し、公開にあわせて社のテックブログを書く
  • KVSのデータティアリングに関する論文を「書き切り」、査読を突破できるだけの貢献として成立させる(新規性・評価・再現性を強くする)
  • 数学を学び直し、分散システム研究のモデル化・分析・議論の強度に還元する
  • ベクトルデータベース周りの分散システム・エコシステムで、貢献できる余地がないか調査する
  • 分散システム集会は継続しつつ、発表者が増える仕組みを整える
  • 商業誌の執筆機会があれば積極的に活かす
  • 最低限自身の論文の内容を説明できるだけの英語力を身につける