SolrでSparse Vectorを使った検索をする
本記事は情報検索・検索技術 Advent Calendar 2025の22日目の記事です。
SolrでSparse Vector Searchができないかなぁと思って検索していたところ、2025/07に出た9.9で面白そうな機能が入っていたので、それを試してみた記録です。
SolrでのSparse Vector検索のサポート状況について
2025年7月にリリースされたSolr 9.9にて、RawTFSimilarityFactoryなるクラスが追加されました。まだexperimental扱いですが、フィールドのTerm Frequencyを用いて類似度を計算するためのクラスなようです。
またこの追加に付随して、残念ながら今現在Closeとなってしまっていますが、チュートリアルページを追加するPRがでていました。本ブログはこちらを元に試してみた記録です。
実践
Sparse Vector用のスキーマ
まずはRawTFSimilarityFactoryを用いるためのスキーマを定義します。
...
<dynamicField name="*_drtf" type="delimited_rawtf" indexed="true" stored="true" omitPositions="true"/>
<fieldType name="delimited_rawtf" stored="false" indexed="true" class="solr.TextField">
<analyzer>
<tokenizer name="whitespace"/>
<filter name="delimitedTermFrequency"/>
</analyzer>
<analyzer type="query">
<tokenizer name="whitespace"/>
</analyzer>
<similarity class="solr.RawTFSimilarityFactory"/>
</fieldType>
...
ここでは*_drtfという名前のDynamic Field、およびそれに適用するdelimited_rawtfというField Typeを定義しています。
delimited_rawtfではdelimitedTermFrequencyを用いて、スペース区切りのterm|frequencyの形式でタームおよび出現頻度を定義できるようにしています。また、SimilarityとしてRawTFSimilarityFactoryを指定しています。
これらを追加したスキーマ定義をmanaged-schema.xmlとして保存します。
Solrの起動
次に、Docker ComposeでSolrを起動します。以下のcompose.ymlを用意します。
services: solr: image: solr ports: - "8983:8983" volumes: - data:/var/solr - ./managed-schema.xml:/opt/solr/server/solr/configsets/_default/conf/managed-schema.xml:ro command: - solr-precreate - sparse volumes: data:
あとはdocker compose upでSolrを起動するだけです。
ドキュメントの登録
次に、新しく定義したフィールドを用いてドキュメントを登録します。登録内容は以下の通りで、各ドキュメントに対してtext_ws(通常のテキストフィールド)とtext_drtf(Sparse Vector用フィールド)を登録しています。
[ { "id" : "1", "text_ws" : "bumble bee", "text_drtf" : "bee|3 bumble|2" } , { "id" : "2", "text_ws" : "honey bee", "text_drtf" : "bee|3 honey|2 sugar|1" } , { "id" : "3", "text_ws" : "solitary bee", "text_drtf" : "bee|3 solitary|2 alone|1" } ]
検索
最後に、登録したドキュメントに対して検索します。以下のように、text_drtfフィールドに対してクエリを投げることで、Sparse Vector Searchが可能です。
curl 'http://localhost:8983/solr/sparse/select?fl=text_*,score&q=text_drtf:(bumble^10+honey^2+bee)'
{ "responseHeader":{ "status":0, "QTime":2, "params":{ "q":"text_drtf:(bumble^10 honey^2 bee)", "fl":"text_*,score" } }, "response":{ "numFound":3, "start":0, "maxScore":23.0, "numFoundExact":true, "docs":[{ "text_ws":"bumble bee", "text_drtf":"bee|3 bumble|2", "score":23.0 },{ "text_ws":"honey bee", "text_drtf":"bee|3 honey|2 sugar|1", "score":7.0 },{ "text_ws":"solitary bee", "text_drtf":"bee|3 solitary|2 alone|1", "score":3.0 }] } }
ここでそれぞれのドキュメントに対してスコアが
- id:1 -> bumble210 + bee31 = 20 + 3 = 23
- id:2 -> honey22 + bee31 = 7
- id:3 -> bee31 = 3
としてそれぞれ計算されており、事前に登録したSparse Vectorに基づいて正しくスコアリングされていることがわかります。
注意点
今回はシンプルな例でしたが、この実装ではスコアの計算にTerm Frequencyを使用することに注意が必要です。例えばSPLADEのような浮動小数点で表現されるベクトルの場合、事前に浮動小数点のスコアから正の整数への変換が必要となります。浮動小数点のままインデクシングを試みるとUnable to parseの例外が発生します。
まとめ
本記事ではSolr 9.9で追加されたRawTFSimilarityFactoryを用いたシンプルなSparse Vector Searchの方法について紹介しました。Sparse Vector SearchをSolrで試してみたい方の参考になれば幸いです。
LLM向けの検索をどう評価するか
本記事は情報検索・検索技術 Advent Calendar 2025の1日目の記事です。
LLM向けの検索について
昨年に引き続き今年もLLM文脈で検索技術を活用するかについて非常に活発に議論が行なわれた年でした。特に、昨年10月に出たChatGPT Web Search機能以降では、学習データ機関に関わらず、常に最新のデータを元に推論・思考することが当たり前に求められるような世界線となっているように思われます。
RAGシステムを開発されているエンジニアの方も多いかと思われますが、そのようなシーンでの検索結果(≠LLMのアウトプット)の評価はどうされているでしょうか？ 従来通りMAP/MMR/nDCGなどの指標を用いているでしょうか？ それとも、LLMのアウトプットの品質を評価するために検索結果の評価はあまり行なわず、LLMのアウトプットに対して人手評価や自動評価しているでしょうか？
本記事では2025年12月現在で、LLM向けの検索評価についてどのような議論が行なわれているか調査した結果をまとめます。
LLMと人間で検索結果を違って評価するか
ポジショナルバイアスの違い
nDCG, MRRなどの指標からわかるとおり、従来の検索評価では上位にある検索結果に高い価値を置く傾向があります。これは人間が検索結果を上位から順に閲覧・評価するという前提の元に成り立っている仮説であり、リスト型の検索結果がベースとなっている現状の検索UIでは妥当な前提です。
一方、RAGシステムなどではTop-kの検索結果をすべてLLMに与え、その中から必要な情報をLLMが取捨選択してアウトプットを生成します。
実際にLost in the Middle: How Language Models Use Long Contextsでは、複数のLLMに対してドキュメントリストを与え、各順位の情報に対しての回答の正確性について議論しています。結果として、コンテキスト長に関わらず上位および下位のドキュメントに対する正確性が高く、逆に途中のドキュメントに対しては下位のものより正確性が劣るという結果が出ています。
これらから「LLMはコンテキスト内の全ドキュメントをポジションに関わらず同一視している」とは言えないものの、人間とは異なる優先度づけが行なわれているとは言えそうです。またその特性もモデルごとに異なるため、これに適応した評価指標が求められるでしょう。
ノイズとなる検索結果への耐性
検索する過程で検索意図に全く反する、もしくはスパムのような結果が出てきた場合どのように反応するでしょうか？ おそらく多くの方はその結果を無視し、自分の検索意図に適合するドキュメントのみを閲覧するかと思います。
既存の検索評価指標もそれに則って設計されており、関連度のあるドキュメントに対しては何かしらの正のスコアを、非関連のドキュメントには何もスコアを与えない、0スコアを与えるといった処理をするでしょう。
これに対して、非関連なドキュメントがLLMに対して与える影響がThe Power of Noise: Redefining Retrieval for RAG Systemsで議論されています。
ここでは以下二種類の非関連なドキュメントに対して、それぞれRAGの生成結果の正確性にどう影響を与えるかが示されています。 * Distracting Document: クエリに関連しているが、誤った情報を提供するドキュメント * Random Document: クエリに一切関連しないドキュメント
以下のテーブルがその結果ですが、正確な答えを含むドキュメントがコンテキストに含まれている状況でも多くの場合非関連な情報が含まれるだけで正確性が大幅に低下することがわかります。
ここで面白いのが、コンテキスト内で正確なドキュメント(★)がクエリ(Q)と隣接している場合、非関連な情報からくるノイズに強いという点であり、これは従来の上位に関連度の高いドキュメントを持ってくる検索システムの特性と相反する結果です。また、このケースではランダムなドキュメントがクエリから遠い位置にあると精度を向上する傾向も見られます。これは、ノイズがLLMの注意機構のエントロピーを増加させ、性能の低下を防ぐためであると推測されていますがはっきりとは結論づいていないようです。
一方、The Distracting Effect: Understanding Irrelevant Passages in RAGでも同様に非関連なドキュメントが与えるネガティブな影響について議論されています。
この論文では非関連なドキュメントがそれぞれのポジションごとに与える負の影響の違いについて述べられていますが、上位であるほど負の影響が大きく、下位に行くほど縮小していく様子がわかります。
総合すると、LLM向けの検索にシステムにおいて、クエリにある程度関連性のあり、なおかつ非正確な情報をもつドキュメントの取り扱いについては、人間向けの検索システム以上に注意深く設計する必要があると言えそうです。
LLM向けの検索評価指標
ここで2025年10月に発表されたRedefining Retrieval Evaluation in the Era of LLMsについて紹介します。
この論文ではRAGシステム向けの検索評価指標として、新たにUDCG(Utility and Distraction-aware Cumulative Gain)を提案しています。
本論文では二種類のUDCGが提案されており、１つはモデルごとのポジショナルバイアスを考慮した学習を必要とするもの、もう１つはポジションを無視しすべてを同一ウェイトで扱うものです。 それぞれ以下のように定義されます。
ここでα,βはそれぞれのポジションにおける有効性と妨害性への影響を事前に学習し重み付けしたものであり、これによりLLMごとのポジショナルバイアスの違いを吸収しています。
また、u+およびu-はそれぞれ有効なドキュメントと妨害的なドキュメントに対するスコアを表しており、これによりノイズによる悪影響を評価時に考慮可能としています。
上記の2点により、先にあげたLLMと人間の検索評価におけるポジショナルバイアスの違い、およびノイズへの耐性を考慮し評価しようとしているわけです。
実際にUDCGおよび従来指標を用いて最適化したランキングをRAGに組み込んだ場合の正確性評価を行った結果が以下の表のとおりです。
また、この性能向上はコンテキスト長が増加しても維持される結果が示されており、今後発表されるさらに大きなコンテキストを扱えるモデルでも有効に機能することが期待されます。
おわりに
本記事では、LLM向けの検索評価について、LLMと人間の検索評価における違いを踏まえた上で、最新の評価指標について紹介しました。
実際の検索アプリケーションをメンテナンスする上で、ポジティブなドキュメントについてはすでに提案されているクリックや滞在時間といったシンプルなユーザフィードバックを用いることで容易に定量化可能です。一方で、どのようにノイズを定量化し、非関連ドキュメントと異なるように扱うのか、ユーザからの暗黙的なフィードバック収集を自動化できるのかが個人的には興味深い課題に思われます。
LondonJP.dev Tech Talk 2025 Autumnを開催しました
どうも、pakioです。
LondonDev.jp Tech Talk 2025 Autumnを11/14に主催し、また司会をしてきました。本記事はその振り返り記事です。
LondonDev.jp 及び勉強会の目的について
LondonDev.jpは私が友人と会話する中で、日本人エンジニア同士の交流がもう少しあると楽しいよね、という話になり、昨年夏にロンドンに移住した直後から構想を始めたコミュニティです。 主に日本にバックグラウンドを持つ、日本語で会話できるソフトウェアエンジニア同士の交流を目的とした場になります。
ロンドンには様々な国籍のエンジニアがいる中、母国語でのエンジニアリングに関するディスカッションが恋しくなる面が多々ありました。また自分自身エンジニアのコミュニティが大好きということもあり、移住した当初から何かしら自分のためにも、他の日本人エンジニアのためにもなるコミュニティを作りたいなと構想していました。
勉強会の開催自体は年初あたりから計画しており、半年ほどかけ社内審議を通し今回ようやく初回の開催に至った次第です。この辺りの厳密さはさすが大企業といったところ。もう少し早く開催したかったのが本音。
ちなみに勉強会のネーミングについては、自分が日本でお世話になっていた検索技術勉強会をよく言えば参考に、正直に言えば丸パクリにさせていただきました。ありがとうございます。
LondonDev.jp Tech Talk 2025 Autumnについて
今回開催した勉強会では、3名の方にご登壇いただくことができました。以下それぞれのセッションについての紹介です。
@ryoppippi : ccusage - Claude Code, Agentic Coding, そしてこれから
最初の発表はccusageの作者 @ryoppippi さんの ccusage - Claude Code, Agentic Coding, そしてこれから でした。
本セッションではccusageを開発するに至った経緯、開発後のストーリーなどについてご紹介いただきました。個人的にccusageがバズった要因に関する話が興味深く、ユーザの実益に加えてCLIツールでもSNS映えをどう目指すかについては考えたことがなかったので新たな視点でした。
ryoppippiさん自身OSS開発者ということもあり、QAセッションでは関連する話題についての質問がいくつも出ており、非常に参加者の参考になる発表となったのではと思います。
@uiu : SMSでN万円溶かす方法
2番目に、@uiuさんにSMSでN万円溶かす方法、というタイトルでLTのご発表をいただきました。 内容が踏み込んでいるため資料は非公開とのことでしたが、数字にリアリティもあり、また実務のトラブルベースでのお話で参加者の共感も得られたこともあり、大変盛り上がったセッションとなりました。
やぶ : 小さなデータベースを作って学んだこと
最後の発表は、やぶさんによる 小さなデータベースを作って学んだこと という発表でした。
YMSで渡英されてからの就活に関する赤裸々な話から始まり、DBの構文パーサ、データフォーマット、管理など非常に幅広く深い内容までカバーいただいたセッションでした。今回発表いただいた自作DBは生成AIの手を借り、これまで経験のなかった言語で実装されたという点にも非常に驚き、個人的に触発され似たようなプロジェクトを始めようかというモチベーションに繋がりました。
改善点
一人運営をやめる
今回、発案から登壇者探し、会場探し、参加者募集の広報、当日の受付、司会、懇親会会場の確保まで相談を除き実務面はほぼ一人で準備してきました。長期間に渡り計画したとはいえ、実際のやりとりを含めるとかなりハードなタスク量だったなと。また、実務部分のタスクについても仕事の合間に行うには地味に時間が必要で、開催頻度に直結する部分になるので、負担を分散できる仕組みを整えたいところです。
というわけで、共同運営をお手伝いいただける方を是非募集しています。費用面でご負担いただくことはなくタスクの分担をお願いすることになるかと思います。ご興味ある方はXの@paki0oアカウントまでDMでご連絡いただけますと幸いです🙏
オンライン参加者への開放
本勉強会にご参加いただいた方の中に欧州テック会の管理人の方がいらっしゃりお話しする機会がありました。その会話の一部で、ロンドンはエンジニアが多くいるからこういったオフラインの会が開催できるけど、ヨーロッパのその他の都市の多くはそこまで日本人エンジニアの母数がいないので難しいといったお話しがありました。実際ロンドンの規模でも自分が目にした会は無く、日本で頻繁に行われているような形式の勉強会は同タイムゾーン内であまりない印象を持っています。 今回実際ryoppippiさんにオンラインで登壇いただいたこともありかなりその面でのハードルは下がっているので、今後オンラインとオフラインのハイブリッド開催も前向きに検討したいと思います。
費用面
前述の通り今回の運営は私一人で行なったこともあり、今回は企業スポンサーを探す余裕がない状況でした。自身で費用を賄うこととなりましたが、会場費含め3万円近くの出費が毎勉強会ごとに発生するのは持続可能な会とは言えなさそうなので、ここは真っ先に改善していきたい部分です。
もし本コミュニティ及びミートアップの趣旨にご賛同いただける場合、是非スポンサー応募をご検討いただけますと幸いです。ご負担いただく費用は会場レンタル費、ケータリング費の実費のみです。スポンサーいただけた場合プロダクトの広告、採用の宣伝等にご利用いただけるセッションをイベント内で設けさせていただきます。
継続したいこと
公共施設の活用
勉強会を開催するにあたり会場について様々なリサーチを行ったのですが、イベントスペースキュレーションサイトで検索してもどこも2~3時間の利用で£250~500（5~10万円程度）の料金、もしくはパブの一部のスペースを借りるような形の会場しか見つけられませんでした。
そこで現地の知り合いが多い友人にヘルプを求めたところ、どうも公共施設がイベントスペースを貸し出しており値段もお手頃との噂が。実際に今回はロンドン市内にある図書館のイベントスペース（公民館の中会議室的なイメージ）を利用したのですが、机・椅子だけでなくWiFi・プロジェクターも完備、夜間の時間外貸し出しにも応じていただけ非常にありがたかったです。また値段に関しても優秀で、今回２時間半の貸し出しで£90(=2万円くらい)と一般的な会場と比較して半額以下の値段で会場を抑えることができました。
オンライン登壇者の事前チェック
今回ryoppippiさんは諸事情によりオンラインの参加となってしまいましたが、直前に通信環境・資料の投影方法を確認できたので発表・会へのご参加をスムーズに進められました。今後似たようなケースに対応することも可能そうだとわかったことも収穫です。
行動規範の策定
勉強会の開催にあたり、勝手ながらコミュニティの行動規範を策定し、参加者には事前の登録フォームでご同意いただいた上でご参加いただきました。
本規範はZOZOグループが公開しているイベント行動規範を参考に作成したものであり、これを事前に用意することによってトラブルが起きた際も明確に対処ができる安心感がありよかったです。
また、本行動規範の策定にあたりご相談に乗っていただいた @ikkouさんには大変お世話になりました。ありがとうございます。
次回開催予定について
今後も本ミートアップは継続的に実施していく予定をしており、会の最後にもアナウンスした通り次回は2026年春先を予定しています。個人的な希望としては、半年は開けたくないので3月頃にできればいいなぁと。
もしオンライン・オフライン関わらず登壇にご興味ある方がいらっしゃいましたら、以下のフォームからご応募ください。
ヨーロッパ最貧国 アルバニアでダイビング
2024年12月にアルバニアで潜ってきたので忘備録です。
アルバニアについて
アルバニアはイタリアの海を挟んだ東、ギリシャの北に隣接したバルカン半島に位置する国で、ヨーロッパ最貧国と呼ばれることもありますが、それゆえに美しい自然が多く残る国です。
首都はTiranaですが、今回は、地中海に面したリゾート都市Vlorëを拠点に潜ってきました。
TiranaとVlorëの位置関係としてはこんな感じで、Tirana International Airportからの直行便があるほか、日中は首都Tiranaの外れにあるバスターミナルから30分おきにバスが出ています。所要時間は3時間ほど、料金は500レク(=約800円)の固定料金です。
利用したショップ：Oazi Blu
今回のダイビングで利用したのは、「Oazi Blu」というダイビングショップです。ショップには英語を話せるガイドがおり、夏場（ハイシーズン）にはツアーが開催されているそうです。一方今回の私の旅行のようにオフシーズンとなる10月から5月までは、リクエストがある場合に限りツアーが催行されるとのことです。
- 公式サイト: https://oaziblu.com/
- Instagram: @oazi_blu
基本料金
- 1人参加（送迎込み）: €100
- 4人グループ（送迎込み）: €360
- 非ダイバー同行者: €30
- プライベートダイブツアー（1～4名）: €500
- 機材フルレンタル: €20/人
私の場合、オフシーズンだったためプライベートツアーとなりましたが、機材のフルレンタルと送迎込みで180ユーロという料金でした。公式サイトにあるフォームからの予約はオフシーズン中は確認が遅れる可能性があるため、WhatsAppで直接連絡を取る方法がおすすめです。
サイト内リンク遷移が壊れており各ツアーの詳細が見られなくなっていますが、URLから/newを除くと正常なページに飛べます。
例: https://oaziblu.com/new/tours/discover-scuba-diving-in-jale-beach/ -> https://oaziblu.com/tours/discover-scuba-diving-in-jale-beach/
ダイビング体験レポート
ショップはVlorëから比較的近い場所に位置しており、Vlorëに宿泊していれば宿付近 ↔︎ ポイント間の送迎をお願いできます。ただし、Tiranaのような離れた都市に滞在している場合、距離が遠すぎて送迎が難しいとのことなのでご注意を。
1本目のポイントは、Vlorëから車で約1時間の移動で到着するDrymades Beachです。このビーチは観光客がほぼおらず、夏のピークシーズンに向けて工事が進行中の状態でした。着替え場所などの設備はないため、持参したタオルで体を隠しながら準備をする形になります。
このポイントの見どころは、沈没したMig-21戦闘機と沈船です。最大深度は20メートルと、OW（オープンウォーター）ライセンスがあれば十分に潜れる範囲でした。水中の透明度は20メートル以上と非常に良好で、流れも少なく、快適にダイビングを楽しむことができました。ただし、エントリーポイントまで海面を移動する必要があり、足にかかる負担がやや大きかったです。
1本目のダイビングを終えた後、一度服に着替えてから車で約30分移動し、2本目のダイビングポイント、Jale Beachに向かいました。このポイントもリゾート建設中のビーチで、観光客の姿はありませんでした。
こちらのポイントは地形がメインのダイビングスポットで、最大深度は18メートル、水中の透明度も20メートル以上と素晴らしい環境でした。
12月時点の水温はどちらのポイントも18度ほどで、フード付きの7ミリウェットスーツを着用していましたが、止まっていると寒さを感じることもありました。なお、グローブのレンタルはないため、持っている場合は持参することをおすすめします。
そのほか
アルバニア自体かなりダイビングショップに関する情報がなく、かなりショップ探しに苦戦しました。首都はTiranaですがVlorëがマリンスポーツの拠点となることが多いようで、確実にダイビングをしたい場合はVlorëに宿泊することをおすすめします。
また今回利用したショップですがオフシーズン中は潜水作業をメインに行っているらしく、ダイビングツアーを希望する場合は数日バッファを設けて、かつ事前に連絡しておくと安心できそうです。さらに、日本の沖縄や関東近郊のようにダイビングセンターがあるわけではなく、着替えスペースやシャワーがないため、その点は覚悟が必要です。
一度予約が取れてしまえば、移動中の風景も非常に魅力的で、透明度抜群の水中や沈んだ戦闘機といったなかなかできない旅が味わえます。もしチャンスがあり検討されている方がいればぜひ。
2024年振り返り
上半期 : 日本編
上半期に関してはすでに記憶が薄いので箇条書き程度に
- 第58回 Elasticsearch勉強会で登壇をした
- Berlin Buzzwordに現地参加した
- hit-the-sack.hatenablog.com
- この時のつながりから今でもロンドンで開催されている検索エンジニアの勉強会情報をもらったり、コミュニティとのつながりが出来ているので自費参加でも参加してよかった
- Search Engineering Tech Talk 2024 Springをスタッフとしてお手伝い
- ジョージア工科大学のOnline Master of Science in Computer Science (OMSCS)を受験、合格
- これについてはもう少し詳しく書いてもいいのかなと思っている。インターネット上に公開されている記事では数百時間準備に費やしたような人も見受けられるけど、そんなに身構える必要をないよというメッセージも込めて。
下半期 : ロンドン編
海外転職
ここ一年で間違いなく一番大きな変化がこれ。
きっかけとしてはLinkedIn経由でリクルーターから連絡をもらっての転職だったのですが、この連絡が来る直前に大学院受験に向けてLinkedInのプロフィールをアップデートしており、それを見て連絡が来たかと思うと人生どこで何がつながるかわからないなぁと。
検索エンジニアとしての採用だったのですが、これまでの会社と比べて規模が比較的大きいので面倒を見る範囲はかなり狭めに。前職までは検索エンジン、データパイプライン、アプリケーションすべて運用している感じでしたが、現職ではかなり分業制で主な役割は検索の評価、リランキング用のデータパイプライン諸々整備と割とデータ・MLに寄った技術に意図せず切り替わりました。言語としてもPython、C++とこれまであまり触れてこなかった技術となり、プロダクションレベルのコードを書くためのキャッチアップに少し時間を要したもののようやくいくつかのコンポーネントのオーナーシップを委譲してもらいつつあります。 予想せず楽しんでいるのが内製ツールが多い環境で、規模が大きくプロダクトの歴史が長い分、各々ツールを作成し社内公開する文化があります。それをベースに社内コミュニティが醸成されていたり、コントリビューションチャンスがあったりと、業務からちょっと外れたコードが書きたいという欲求は割とここで満たせてしまっている面があります。(ちゃんと世間に公開される貢献がしたい)
もう少し踏み込んだ詳細については、試用期間が明ける来年の２月頃にでも書ければと思っています。
ロンドン生活
転職に伴い、７月末からロンドンに引っ越し約半年ほどこちらに住んでいます。夏はめちゃくちゃ快適、冬も東京程度にしか寒くならないので割と快適な環境で、ずっと曇りで日差しがないことを覗けば気候面は割といい都市な印象。 またこちらで会う日本人は結構面白い人ぞろいで、どんな人でも日本を出てイギリスに住んでいるという共通点がベースとしてあるのでサクッと打ち解けられるのはメリットに感じています。
海外旅行面でもかなり恵まれており、まだ二か国しか行ってませんが3~4時間圏内でアクセスできる国が無数にあるのはめちゃくちゃ良いです。日本のパスポートに感謝。ロシア系の同僚とか出張すらめちゃくちゃ大変そう。
デメリットは物価面くらいで、正直なところ年収が日本時代の2~3倍になったとしても同等のクオリティの生活がギリギリできるかなといった感じなので、お金目的でロンドン移住を検討されている方はお気を付けを。逆にお金を目的としないのであれば、ある程度稼げれば刺激的な環境であることは間違いないです。
大学院
OMSCSの入学が2024年秋学期からだったので、8月から授業も開始に。たまたま現職の上長も同じくOMSCSを受講しており、初Termはシステムに慣れるという面でも学びがありつつ比較的難易度の低いCS 6035: Introduction to Information Securityを受講することに。 脆弱性のあるアプリケーションへの攻撃から、暗号鍵の基礎、通信の傍受など幅広い内容から構成されており、セキュリティエンジニアでなくてもアプリケーション開発を行うエンジニアとしてそういった視点が得られたのは良い学びでした。
来年の抱負
Xでこんな目標の立て方を見たので、これに倣って来年の目標を立ててみる
年末年始に2025年の目標立てる人は多いはず。僕の立て方は
— カモシカ (@kamoshika_en) 2024年12月28日
①行きたい場所×4
②会いたい人×4
③買いたいもの×4
④その他やりたいこと×4
⑤辞めたいこと×4
計20個を5点満点で点数つけて2025年末に自己評価するって方法を、どっかで見てから気に入って使ってる。
- 行きたい場所
- 会いたい人
- 妻にイギリスに引越して来てもらう
- 買いたいもの
- その他やりたいこと
- 大学院で1 term 2 classとってみたい - 自分のキャパシティ限界調査
- 海外旅行を毎月とは言わないが2か月に一回くらい
- そろそろRustちゃんとやってみたい
- 辞めたいこと
- お酒 - 完全に辞めるわけではないけど健康のために頻度と量を減らす必要性は感じている
- 一人暮らし - 妻がこちらに来る夏までは続きそうだけど完全に飽きた。料理のモチベーションが他人に食べてもらうことなので、自分一人だと最低限の食事(茹で野菜、焼いた肉)になって非常によくない。
