アイコン変えた件、noteデビューした件

こんにちは。 元々のアイコンの写真が古すぎたので、この度新しいアイコンに変えました。 家族が「似てる！」っていってくれたのでそこそこ似ているものと思います。

旧アイコン

新アイコン

noteもデビューしたのでよろしくお願いします！

note.com

WTMTokyo - International Women’s Day 2025に参加しました！


https://wtm-tokyo.connpass.com/event/342888/

 

参加前の心境

職種の範囲が少し広い気がしたけど、話が合うかな…とちょっと心配だったけど、ネガティブな会ではないことを願って参加！ いつもイベントが終わると記憶が抜け落ちちゃうので、今回はスマホを持ってメモを取りながら参加しました。

IF NOT US, WHO?

東京大学の板津先生が女性エンジニアたちに向けてエールを送ってくれました。

AIに絵を描かせてみると、消防士は男性、看護師は女性…なんて、ステレオタイプがそのまま反映されてしまうという話が印象的でした。私なりに考えてみると、LLM（大規模言語モデル）は既存の情報を元に学習されるから、ある意味で「多数決」のようなもの。無意識に使ってしまうと、ジェンダーバイアスが助長される危険も。ポリティカル・コレクトネスの観点からは、男女比や人種のバランスを整える工夫が必要だし、使う側もステレオタイプに気をつける必要がありそうだなと思いました。

AIの話から少し離れて、アシスタントが女性で描かれることが多いという話もありました。女性性は本質的には必要ないけど、一般のお客さんにとっては性別をつけた方がイメージが湧きやすい、という点には納得。

さらに、世界価値観指標の話で、AIに対する認識が地域ごと・宗教ごとに固まっている中、日本だけが外れ値になっているのがとても興味深かったです。

自分の「心の声」に耳を傾けよう

エンジニアリングマネージャーのあらたまさんの話。

振り返ってみて、自分の気持ちを言葉にすると、その後どう行動するかを考えるのが楽になるって話が印象的でした。

エンジニアの自己肯定感　インポスターの壁を破る

Among Usはやったことないけど…この話は共感できるところが多かったです。年齢を重ねても抜けない下っ端根性に悩む私。板津先生のようにカッコよくなりたいなと思いました。

シンデレラなんかになりたくない

シンデレラなんかになりたくない

とにかくスライドが可愛かった！

「女は大学に行っても仕方がない」なんて呪いの言葉を、幸いにも私は誰にも言われませんでしたが、「私たちは、自分で自分を幸せにできる」という言葉にはすごく勇気をもらいました。

そして、「なぜかHTMLとCSSを手打ちできる世代」の話題、懇親会で盛り上がりました！ geocitiesでスペースを借りて、白紙のエディタに手打ちでHTMLを書いてホームページを作っていた頃、あの時代は私の青春だったなぁと思います。

Redefine Possibleでキャリアを広げる

小さな成功体験を積み重ねて前に進むことが大切だという話が心に残りました。

非CSだからこそ

実は、wabiさんと同じテーブルだったんです！

恥ずかしながら、Computer Science（CS）という言葉を初めて知りました。私はCS出身ではないので、非CSということになるのかな。でも、多様性があるからこそできることがあるんだなと感じました。

生成AIのAIエージェントを大手3社（AWS、Azure、Google Cloud）で徹底比較してみた

AIエージェントについてすごく興味があったので、懇親会で詳細を聞けて良かったです！

懇親会

BINGOゲームで、お互いの好みが色々と分かり合えて、ワイワイ楽しみました。エディターで「Eclipse」を挙げた人が何人かいて、ちょっと嬉しかったです。Rubyを始める前、私は9年くらいEclipseを使って開発してました。一緒のテーブルにいたベテランのアプリエンジニアの方から、過去10年のソフトウェア業界の激動について教えてもらいました。時代の流れがすごく早かったんだなぁと実感しました。

まとめ

テック業界の様々な人たちと交流できて、素晴らしい時間を過ごしました。来年も開催されるなら、登壇してみるのもいいかも！楽しみです。

 

 

TokyoRubyKaigi 12に参加しました

RubyKaigi2022に参加して、Rubyのコミュニティにもっと関わりたいと思ったのですが、家族の事情で一時的に活動を控えることに。2025年は少しずつ界隈に顔を出し、情報収集を再開していきたいと考えています。

前夜祭

クリエイティブコーディングワークショップ

クリエイティブコーディングワークショップでは、p5.jsをRubyで書くジェネラティブアートの課題に挑戦しました。入門編ということで平面キャンパスに二次元図形を定義して作成するものでした。プログラミングで図を描くのは久しぶりだったので、あまりスムーズにはいかず、どうにかこうにかルビー形状を動かすところまで完成させました。昔触ったJavaAppletやPOV-Rayを思い出して、少し懐かしい気持ちになりました。

駅伝トーク🎽

LTの密度がとても濃く、次々と繰り出されるアイデアに脳が刺激されました。

ゆるゆるMastodon 鯖缶生活

Mastodonのサーバー運営（鯖缶）の話です。外部側のアップデートで自分のサーバーを修正する必要が出た時にRubyバージョンが古いことが原因ですんなり完了できなかった話に共感しました。開発をストップしている期間もメンテナンスとして外部依存のアップグレードは必要になるので、GitHub Actionsなどを使って自動でアップグレードする仕組みをしっかり敷くと楽になるかなとか考えていました。

超入門WebAssembly ~Rubyのコードを眺めて完全に理解しよう~

Rubyで実装してWebAssemblyを動かすランタイムは既存でRuby以外の言語で書かれたものが適用できます。しかし、Rubyで書かれたランタイムがなかったのでWarditeを開発した、という話をわかりやすく説明されていました。

TokyoRubyKaigi 12

キーノートではGitHubの方が登壇し、マンモス級のインフラを支えるための工夫を紹介していました。RubyとRailsのバージョンを毎週更新しているという話は特に印象的でした。（前日の駅伝トークであったMastodonの運営の話とも通じるものがありました。）また、デプロイキューの詰まり対策としてプルリク単位に切り替えた結果、バグ対応の課題が浮き彫りになり、Feature flagを活用するに至ったというエピソードには学びがありました。

セキュアなDNSを構築する話も素人ながら興味深く感じました。そもそも大規模な会場のWi-Fiがどのように構築されているのか知らなかったので、具体的な事例を聞けたのは新鮮でした。ネットワークに関しては大学の頃からの断片的な知識が積み上がって繋がっていない状態なので、一度時間をとって実装ベースで勉強したいと思いました。

Rubyと暮らす

私がビジネス的な効率や合理性にすごくとらわれてしまっていたので、暮らすという観点で、あって欲しい姿を追求する考え方に目から鱗が落ちる思いでした。この前向きなアプローチこそ、Rubyコミュニティの魅力だと思います。

余談

web業界のカンファレンス全体がこの形式かどうかはよく知らないのですが、質疑応答の時間がないことによる心地よさを実感していました。機械系の学会や翻訳業界のカンファレンスは質疑応答があったのですが、その時間に漂う一種の緊張感が少し苦手だと感じていました。質疑応答がないことでその緊張の時間がなく、結果として発表者と参加者の間に緊張が生まれず、会場の雰囲気が明るいまま次のトピックに頭をスムーズに切り替えられ、かといって議論の機会が失われているかといえばそうではなく、発表者と参加者の距離が近く保たれていることから議論が必要であれば休憩時間にフランクに話しかけられる雰囲気になっていて、とても良いコミュニティが醸成されていると感じます。この形式を採用した方には、ぜひ表彰状を贈りたいと思うほど感動しました。

 

RAG・AIエージェント実践入門読書勉強会 #1の学びメモ

 RAG・AIエージェント実践入門読書勉強会 #1 - connpass

勉強会に参加して特に学びがあったところだけをメモとして残します。

本を読んで勉強会に参加するとぼんやりしていた知識の輪郭がはっきりしたと感じました。

全体

LLMモデルに意図通りに生成してもらおうとする場合、コンテキストを十分に与える必要がある。

Function Calling

Function Callingに関して腹落ちしてなかったけど、今日腹落ちした。

例えば気象庁のような組織にLLMチャットを作ったとするとわかりやすい。

気象庁のようなところであれば、一口に東京の天気といってもいろいろな条件があるだろう。

東京中心部の平均だとして、各測定点の情報を取得する。おそらく各測定点の配列を引数に入れてfunctionをcallする。その前に測定点一覧を取得する必要があるかもしれない。

もっと言うと、未来の予測であれば実測に加えて天気図や衛星画像を請求するかもしれない。

多くの機能をfunctionとして用意し、それらを使いこなすためにFunction Callingが返る。

 

余談: 翻訳と機械翻訳とLLM

翻訳業界では早くから機械翻訳やニューラルネットワーク翻訳が用いられてきた。大量の原語を自動で翻訳することで翻訳料を安く抑えよう試みだが、うまく品質を担保できない課題がある。その理由をはっきり言語化している例を見たことがないので言語化してみる。私が思うに、機械翻訳を利用してうまくいかない案件は、文になっていない名詞だけの部分が多く、コンテキストも不十分な案件だと思う。原語欄は同じ単語で記載されていても、表示される場所によって訳語の変形や別の訳語を選択しなければならないことがあるが、表示場所などのコンテキスト情報が正確に紐付けられていないことがある。その状態で機械翻訳に任せても誤訳が連発するのは当たり前で、コンテキスト不足を人間のポストエディットに押し付ける業務フローになっている。しかし人間であってもコンテキストが不足していれば推測に頼るしかなく、結果として品質の低い成果物ができあがる。こういった案件で機械翻訳を正しく使おうとするなら、機械にコンテキストを提供するツールを開発して十分なコンテキストを与える必要があるだろう。案件ごとにコンテキストの原語との紐付けを丁寧に行う必要があることから、翻訳会社が目論んでいるよりも手間は多くかかる。

マニュアルなどのPDFだったら翻訳ツールでPDFの該当箇所と原語とを紐付けられたはずなので、既存ツールで丁寧にやればそう難しくはなさそうだが、ソフトウェアUIは難しいだろう。丁寧にやる暇が惜しいから機械翻訳に頼りたいのに機械はそれほど何でもやってはくれないという矛盾に陥って品質を妥協せざるを得ず、結果として世界的に有名な企業が出しているキャッチコピーがなんかおかしかったりする。

そんな低品質な訳文が公に増え、LLMがそれらを学習し、結果として言語の品質は今後低下していくことになるのだろう。

よく出るrubocopエラーの対処法

エラー：

command /Users/{ユーザー名}/.rbenv/shims/rubocop returns empty output! please check configuration.
unrecognized cop or department FactoryBot/ExcessiveCreateList found in .rubocop_todo.yml

対処： .rubocop.ymlでrequireされているrubocopをgem i rubocop-xxxする。

Rails 7のenumでキャストされた文字列を取得したい

前提

  • あるデータが存在しない場合に、そのモデルに定義されているenumのうちの一つのキーをコントローラーから返したい（つまり、Model.statuses.fetch(:before_process)で得られる値に対応するキーを文字列として返したい）
  • ハードコーディングしたくない
  • できればfetchをつかって、キーに対応する値が存在しなければエラーにしたい

今知っている範囲でできること

Model.statuses.key(Model.statuses.fetch(:before_process))
  • Modelを複数回呼び出すのが嫌
  • ネストしているのも嫌