Claudeに協力してもらいながら調べていったところ、awdl0を止めると改善しました。AirDropなどで使われるApple Wireless Direct Linkのインターフェースです。

ただ一度止めてもOSが有効に戻してしまうので、停止した状態を維持するためのhawdlというツールを作りました。調べた内容も書いておきます。

pingで確認

ルーターにpingを打ってみる。

$ ping -c 60 -i 0.25 -q 192.168.0.1
60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.921/236.760/1090.306/268.352 ms

パケットロスはないけど、平均で236ms、最大で1秒以上かかっている。定期的に遅くなるという認識だったけど、平均でも結構遅いですね。

宛先を変えても測ってみました。値はすべてmsです。

インターネットに出る前から遅いので、自宅のLAN内を調べることに。

LAN内の別端末宛でも同じなのでMac側の問題かと思ったんですが、これもアクセスポイント(AP)を経由するので、まだMacとAPのどちらかはわからない。

電波や通信量を確認

$ system_profiler SPAirPortDataType | grep -E 'Signal|Transmit Rate|Channel'
Channel: 48 (5GHz, 80MHz)
Signal / Noise: -37 dBm / -73 dBm
Transmit Rate: 1200

信号強度は-37dBm、表示上の接続速度は1200Mbps。電波が弱いわけではなさそう。

通信量が多くて遅くなっているのかもと思って、pingとあわせてnetstat -I en0 -bの値も確認しました。250msごとの通信量を比べた結果がこれ。

高遅延スロット(n=38) 平均 69631 bytes
低遅延スロット(n=34) 平均 101268 bytes

今回の測定では、遅いときのほうが通信量は少なかった。これだけで原因を除外はできないけど、通信量が増えたときに遅くなる、という感じでもないので別のところを調べる。

awdl0を止めてみる

wdutil infoでチャンネルの情報を確認すると、接続先のch48以外にもch44やch6が出ていました。

$ sudo wdutil info | grep -iE 'channel|rssi|tx rate'
Channel           : 5g48/80
Channel Sequence  : 48++ 0 44++ 0 0 0 0 0 6 0 44++ 0 0 0 0 0
Master Channel    : 6/0

AWDLの通信でチャンネルが切り替わることが影響していそうなので、awdl0を停止して同じ宛先にpingを打ってみました。

sudo ifconfig awdl0 down && sleep 8 && ping -c 60 -i 0.25 -q 192.168.0.1

停止直後に測ったときは20% loss / avg 1334ms / max 4953msとむしろ悪くなっていたんですが、8秒待ってから測り直すと改善しました。この環境では少し待つ必要があったようです。

airportdの内部指標もあわせて比較しています。

pingの平均が249msから3msになって、ばらつきもかなり小さくなった。beaconの受信数も予定数と一致するようになっています。

少なくとも自分の環境では、awdl0を止めることで遅延が改善することがわかりました。

原因はわかったんですが、念のため他の要因も確認しておきました。

hawdlを作った

sudo ifconfig awdl0 downで止めても、AirDropなどを使ったりスリープから復帰したりするとOSがupに戻してしまう。そのたびに手動で止めるのも面倒なので、hawdlを作りました。

Swift製で、外部パッケージへの依存はありません。メニューバーアプリとCLIから操作できます。

root権限で動くデーモンのhawdldがawdl0を監視して、OSが有効に戻したら再度停止します。メニューバーアプリとCLIはUnix domain socket経由でデーモンに接続するので、普段の操作ではsudoは不要です。

監視にはPF_ROUTEのRTM_IFINFOを使っています。イベントを取りこぼした場合に備えて、30秒ごとの状態確認も入れています。

インターフェースの操作はifconfigを呼ばずに、ioctlのSIOCGIFFLAGS / SIOCSIFFLAGSで直接変更するようにしました。このマクロがSwiftからimportできないので、そこだけCのコードを挟んでいます。

OSが短時間に何度も有効に戻す場合は、停止するまでの待ち時間を延ばすようにしています。10秒以内に5回以上戻されたら、1秒、2秒、4秒と間隔を空ける。

hawdl statusでは現在の状態を確認できます。blockedに、OSが有効に戻したのを何回止めたかが出ます。

インストール

brew install taross-f/hawdl/hawdl
sudo brew services start hawdl

完全修飾名で指定すればtapも一緒に追加されるので、先にbrew tap taross-f/hawdlを打つ必要はありません。最新リリースをソースからビルドします。リリースではなくmainを追いたい場合はbrew install --HEAD taross-f/hawdl/hawdlです。

CLIやメニューバーアプリを使うにはデーモンの起動が必要なので、sudo brew services start hawdlまで実行してください。

メニューバーアプリは別途起動します。

open "$(brew --prefix hawdl)/HawdlBar.app"

AirDropなどを使うとき

AWDLを止めている間は、AirDropやSidecarなどの連係機能が使えなくなることがあります。Handoff、ユニバーサルクリップボード、ユニバーサルコントロール、連係カメラ、ピアツーピアのAirPlayなどにも影響します。

必要なときはhawdl releaseかメニューバーから解除できます。デーモンの通常終了時にもupに戻すようにしています。

awdl0を直接操作しているので、macOSのアップデートで挙動が変わる可能性はあります。制御ソケットのパーミッションは0666で、同じMacの他のユーザーも操作できるため、共用Macで使う場合は注意してください。

自分の環境ではこれでレイテンシが改善しました。AirDropなどが使えなくなるのは不便なので、必要なときは戻しながら使うことになります。

いわゆる8番出口ライクな異変探しゲームです。舞台がオフィスでも地下通路でもなく、ビデオ会議になっています。月曜から金曜まで、毎日の定例会議に出席して、画面のどこかに異変がないかを見張る、それだけのゲームです。

ルール

ルールはシンプルです。

• 会議中、参加者の様子や画面に異変があれば「退出」する
• 異変がなければ最後まで残る
• 月曜から金曜まで、判断を間違えなければクリア

8番出口と同じで、「異変があるのに残る」「異変がないのに退出する」とどちらもアウトです。異変を感じたら勇気を持って退出、なにもなければじっと耐えて最後まで残る。この判断を1週間ぶんやりきれば勝ちです。

異変いろいろ

異変は地味なものから露骨なものまでいろいろ用意しています。たとえば、

• 田中さんの顔色が悪い
• 全員の名前が「田中」になっている
• 渡辺さんの目が赤い
• 高橋さんの背景に人影がある

…みたいなやつです。パッと見ではわからない、いつもの定例会議に紛れ込んだ小さな違和感を探す感じですね。見破った異変は図鑑に記録されていって、全部そろえると全制覇トロフィーがもらえます。

ちなみに、ひとつひとつの異変の細かい中身は自分で作り込んでいません。Claude Codeに任せて生成してもらっているので、自分が作ったゲームなのに「次にどんな異変が出るのか」を自分でも知らないまま遊べて、わりと新鮮な感覚があります。作者なのに普通にビクッとする。

リモートワークで毎週やっている定例会議の、あの独特の手持ち無沙汰な空気感を異変探しに変換できないかな、というのが作ったきっかけでした。

プレイ動画

(プレイ動画はあとでYouTubeで埋め込みます)

技術的な話

React + Viteで作って、GitHub Pagesにそのまま乗せています。これもほぼVibes Codingで、Claude Codeに「8番出口みたいなのをビデオ会議でやりたい」と投げて、異変のバリエーションを足したり効果音をつけたりしながら膨らませていきました。

異変探し系はとにかく「異変パターンの数」が面白さに直結するので、ロジックの本体よりも「どんな違和感がゾッとするか」を考えている時間のほうが長かったです。このあたりはコードを書くというより演出を考えている感覚に近くて、わりと楽しかったですね。

遊べるのはこちらからどうぞ。

定例会議をプレイする

入社して最初の2年は旧Bedore所属でAI HelpdeskチームでSWEとEMをやってて、その後グループ会社のPKSHA Communication(当時)に異動した。今は会社のカンパニー化にともないカンパニー執行役員として複数プロダクトのエンジニア職種を統括する立場で、管理対象人数は50人くらい。

シンプルにここ10年で一番仕事がしんどい

これまでとは違う難しさ

なんというか、これまでのSWE→EMの延長線上でない。何を求められているのか探るところから難しくて、手探りでやってる感じがずっと続いている。自分が何をすべきなのか、どこに価値を出せるのか、もやっとしている。

EMをやってた時は、チームのパフォーマンスを上げるとか、メンバーの成長を支援するとか、やることがわりと明確だった。でも今の役割は、複数のチーム、複数のプロダクト、そして50人という規模。単純に2倍、3倍のスケールじゃなくて、質的に全然違う

でも周りからの見え方とか期待値は確実に大きくなってて、うまくいかないと「残念だ」みたいな反応をされる。このギャップがまたしんどい。期待に応えたいけど、そもそも何に応えればいいのかがぼんやりしてる。

頑張ってることと成果が出ることは別だし、頑張りが評価される年齢でもないし。

一応テーマは持って進めていた(今期は採用･そのための技術広報を回す)し、それが進んだ結果にはなっていて1年前と比べたら見え方変わっていると思うが、まだまだこれからなのもあるし、結果が出ているとは言い難い。来期もまた違うテーマが見えてきていて、それはさらに難しいものに見えている

強みとは

実は最近、自分の強みって何だったんだろうって考えることが増えた。エンジニアとしての技術力？マネジメント能力？コミュニケーション？正直、よくわからなくなってきている。これまで「なんとなくできてた」ことが、規模が大きくなって通用しなくなってきたのかもしれない。

AI Helpdeskの時は、技術的な判断もできるし、プロダクトの方向性も決められるし、メンバーのケアもできる、みたいな感じで動けてた。でも今は全部を見るなんて物理的に無理で、どこにフォーカスすべきかを決めないといけない。

そもそも、40歳で「自分の強みがわからない」って言ってるのもどうなんだろうと思うけど、たぶん今までは環境に恵まれてて、自分の強みを深く考えなくても何となくうまくいってたんだと思う。

極端に振り切るという選択肢

いっそ極端に振り切ってみるのも手かなと思ったりする。例えば事業にめちゃくちゃ首突っ込んでビジネスサイドとガッツリやるとか、逆に自分はなるべくボールを渡していって、メンバーが動きやすい環境を作ることに徹するとか。中途半端が一番良くない気がしてる。

事業に首突っ込むパターンだと、プロダクトの数値とか売上とか、そういうところまで責任を持つ。エンジニア組織の話だけじゃなくて、ビジネス全体の中でエンジニアリングをどう活かすかを考える。これはこれで面白そうだけど、今まであまりやってこなかった領域だから学習コストは高く、効果があるのか説明も難しい

一方で、環境づくりに徹するパターン。採用とか評価制度とか、開発プロセスの整備とか、そういうところに集中する。直接的な成果は見えにくいけど、長期的には組織の基盤を作ることになる。ただ、これだと「で、ビジネスへの貢献は？」って聞かれた時に答えにくいし、今でもだいぶ遠いのに更に遠くなってよいのか

正直、どっちがいいのかわからない。でも、今みたいに中途半端な状態よりはマシな気がする。

それでもやっていくしかない

まだ成果が出るイメージが持てなくてつらい。朝起きて「今日も頑張るか」って思うけど、会議に出て、1on1して、テキスト書いて、｢今日もなんとかなった｣ではだめ

たぶん1年後くらいに読み返したら「あの時はこんなこと考えてたんだな」って思うんだろう。その時には少しでも前に進んでいたい。というか、進んでいるはず。そう信じてやっていくしかない。この「わからない」状態こそが成長の前段階なのかもしれない。今まで通用してたやり方が通用しなくなって、新しいやり方を模索してる時期。

40歳、5年目。まだまだ人生も折り返し。不惑ではなく惑惑、これをワクワクに(?)

Kindle quoteみたいなノリでKindle以外の文章の引用画像を作成するためのツールです。おもにオライリーの電子書籍を引用するために自分は作ったのですが、汎用的に使えるようになっています。

できること

e-reader風のシンプルなデザインで、美しい引用画像を生成できます。文章だけでなく、本のタイトルや著者名も含めて画像化できるのが特徴です。

使い方

インストール

# グローバルインストール
npm install -g quotto

# プロジェクト内にインストール
npm install quotto

基本的な使い方

# シンプルな引用
quotto --quote "偉大な仕事をする唯一の方法は、あなたがやっていることを愛することです。"

# タイトルと著者付きの引用
quotto \
  --quote "Stay hungry,\nstay foolish." \
  --title "Stanford Commencement Address" \
  --author "Steve Jobs"

オプション

• --quote: 引用文（必須）改行もサポート
• --title: 本や記事のタイトル（任意）
• --author: 著者名（任意）
• --output: 出力ファイル名（任意、デフォルトはタイムスタンプベース）

技術的な話

Claude Codeで100%Vibes Codingで作りました。Vibes CodingだとT3StackなどのTypeScriptベースで作っていくとうまくいきがちで、さらにCLIだと精度があがる印象ですね

オライリーの技術書から気に入った文章を引用する際に、きれいに画像化してシェアしたいというのが作成のきっかけでした。Kindleだと簡単に引用できるのですが、それ以外の電子書籍では同じようなことができないので、自分で作ってみました。

マネジメント層からよく聞くこの言葉。でも、正直なところ「それって具体的に何？」って思いませんか。

最近、自分でもよくわからなくなってミスったので、その反省を書きます。

サッカーで考える全体最適の罠

まず例え話として、サッカーのボランチ（守備的ミッドフィルダー）の話をしましょう。

ボランチの選手が「チームの方針のことを考えて」守備重視でプレーしたとします。攻撃参加を控えて、ディフェンスラインの前でがっちり守る。一見、全体最適っぽいですよね。

でも結果はどうでしょう。

• 中盤の攻撃力が落ちる
• 前線が孤立する
• 得点チャンスが激減する
• 結局、守備的なのに失点も防げない

なぜこうなるのか。それは、ボランチが「想像上の全体最適」を追いかけたからです。

個別最適の衝突が生む本当の最適解

本来なら、こうあるべきでした：

1. ボランチ「俺は攻守のバランスを取りたい」
2. センターバック「もっと前線をカバーしてくれ」
3. オフェンシブMF「もっと前に出てきて欲しい」

この「個別最適のぶつかり合い」から、議論が生まれます。そして監督（上位レイヤー）と擦り合わせた結果、「今日は相手が強いから守備7：攻撃3でいこう」といった具体的な全体最適が見えてくる。

エンジニアリングでも同じですよね。

• フロントエンド「UXを最高にしたい」
• バックエンド「パフォーマンスを追求したい」
• インフラ「コストを抑えたい」

この個別最適をぶつけ合って、初めて「今回のプロダクトではUX重視で、でもレスポンスは500ms以内」みたいな落とし所が見つかる。

マネジメント層が陥りがちな罠

「全体最適を考えて」と言いながら、実は抽象的な理想論を勝手に想像していませんか？

マネジメント層は確かに一つ上のレイヤーの優先度を意識する必要があります。でも、それに寄せすぎて個別最適を無視すると、チームは「で、結局何すればいいの？」状態になります。

大事なのは：

1. 各メンバーの個別最適を引き出す
2. それらを戦わせる場を作る
3. 上位の優先度と擦り合わせる
4. 具体的な行動指針に落とし込む

この「議論を戦わせる」プロセスを飛ばして、いきなり全体最適を取りに行くから破綻するのかなと

実装に落とし込むと

コードレビューでもよくある話です。

「もっと全体のアーキテクチャを考えて」という抽象的なフィードバックより、「このモジュールの責務はXXだから、この処理は別モジュールに」という具体的な議論の方が建設的。

個別最適（各モジュールの責務）を明確にして、それらの関係性を議論することで、結果的に良いアーキテクチャ（全体最適）が生まれる。(ちょっと違うか…?)

結論

つまり”全体最適”とは、個別最適の議論を戦わせる姿勢 + 結論を軌道修正してそれにコミットする動き ということ。全体最適は”目指すもの”じゃなくて”個別最適をぶつけあった結果として生まれるもの”。

個別最適を主張して、他の個別最適とぶつけて、上位レイヤーと擦り合わせる。このプロセスを大切にすることが、本当の全体最適への道なんじゃないでしょうか。

育休取得を予定されている人から何度も聞かれそうなこの質問。5月半ばに3人目が産まれて、エンジニアとして初めての育休(2ヶ月)を取得しました。正直、想像していたものとは全然違う日々を過ごしています。

この記事も、深夜2時赤ちゃんの寝息を確認しながら、一人カタカタとキーボードを叩いて書いています。

我が家の構成：妻、0歳女の子、保育園年中の次男、小学1年生の長男

タイムスケジュールという名の戦場

「育休中ってなにやってるの？」という疑問を解くために、ある日のスケジュールを晒してみます。

6:30 起床 → 上の子2人の朝ご飯準備。「今日のメニューは？」「またパンかよ」のやり取りから1日が始まる
7:30 長男を登校班へ送る。 8:20 次男を保育園へ。「パパ、今日お迎え来る？」と毎日確認される
9:00-12:00 束の間の自由時間…と思いきや、洗濯、掃除、役所への書類提出etc
12:00-14:30 昼食後の昼寝タイム（これがないと夜まで持たない）
14:30-16:00 長男の宿題バトル。音読を聞く作業がなぜか30分を超える 16:30 次男お迎え → 即お風呂 → 夕飯準備 18:00 家族でワイワイ夕食。この時間が一番にぎやか
21:00 妻が上の子たちを寝かしつけ（そのまま一緒に寝落ち）
21:00-3:00 赤ちゃんとの1対1。寝ていればPC作業もできるし、眠かったら無理せずに一緒にねる。寝ない日はもうあきらめてミルクあげたりオムツ変えたり。Audible聞いたりも
3:00 妻とバトンタッチ。

もちろん、このスケジュールの間にも3時間おきのミルク、おむつ替え、泣き対応が割り込んできます。まさにマルチタスクの極み。

「俺、役に立ってる？」問題

育休1週間目、ふと不安になって妻に聞いてしまいました。
「育休とった意味、ありそう？」

妻の答えは意外とシンプルでした。
「一人だったら、今頃倒れてる。特に上の子対応しなくてよいのは楽」

そうか、これを妻が一人でやっていたら…と想像すると、確かにゾッとします。

折り返し地点で見えてきたもの

1ヶ月が経過。生活リズムは安定してきましたが、睡眠不足との戦いは続いています。連続3時間以上寝られた日は、まだ片手で数えられる程度。

そんな中でも、技術への興味は失っていません。Claude Codeが話題になっているのを見て、赤ちゃんが寝ている隙に触ってみたり。エンジニアの性ですね。

昼寝の質を上げるためにCIOのUSB充電式アイマスクを導入したのは、我ながらナイスな判断でした。15分の昼寝でも、しっかり暗くなると回復度が違います。

チームの理解に救われる

仕事面では、チームメンバーの理解と協力に本当に感謝しています。育休取得を伝えた時の「お互い様だから」という言葉。男女問わず育休が当たり前に取れる環境って、改めてすごいことだなと。

週に数回飛んでくるメンションにも、余裕を持って対応できています。完全に仕事から離れるのではなく、この程度の距離感がちょうどいい。

燃え尽きからの回復

実は育休に入る前、仕事に対して少し燃え尽き気味でした。プロジェクトの山を越えて、次の目標が見えなくなっていたというか。

でも、この1ヶ月で少しずつエネルギーが戻ってきているのを感じます。子どもたちと過ごす時間が、意外なリフレッシュになっているのかもしれません。

これからの1ヶ月

長男が「パパ、最近家にいるね」と嬉しそうに言ってくれたり、次男が保育園で「うちのパパは赤ちゃんのお世話してる」と自慢してくれたり。赤ちゃんの様子も正確に説明できるくらい理解できているのは初めてです。

残り1ヶ月。きっとあっという間に過ぎていくでしょう。でも、この経験は確実に自分を変えてくれている気がします。

エンジニアとして、父親として、一人の人間として。
育休は「休み」ではなく、改めて自分と家族を見つめ直す「修行」なのかもしれません。

セットアップ

MacBookのキー配置と近づけるために英数とかなを2キーに割り当てしてます。前からやってるけどこれやらないとミスタッチしすぎてイライラしちゃうので

Gesture Padは以下のように設定

• 左
  • 上: Ctrl+↑ (Mac側ショートカットをMissionControlにしておく)
  • 下: F11 (Mac側ショートカットをアプリケーションウィンドウにしておく)
• 左下: 左右スクロール
• 右下: Ctrl+←→ (Mac側ショートカットをスペース切り替えにしておく)
• 右: スクロール

これは自分の使い方的にアプリケーションウィンドウをよく使うのと、全画面で開くZoomなりなんなりをスペース切り替えしたくなりそうでそのあたり入れてみました

が、感度最大にしても反応が悪いときが多くてつらくて使えてない…

ポインティングスティックは調整中だけどspeed2と3の間くらいにしてます。細かいところ動かしづらくなるもののぎりぎり許容できるくらいかなと

KarabinerでEmacs key bind入れてるんですが、一部うまく動かなくなっていてSetting > DevicesのModify EventをONにしました。ただこれの弊害なのかわからないけどペーストするときの挙動がちょっとおかしくて2重にペーストされるときあるようで、なんらか環境の改善が必要そう

感想

キータッチについては評判が良かったので現物触らずエイヤで買ってみて、打ち心地はかなり良かったです。キーストロークが浅いのがはじめだけ気になったけどすぐ慣れたし、音も静かでいい感じの音ですね(個人の見解)

ポインティングスティックはまだ慣れなくて、修行と思って使ってます。あとスティックとクリックを右手で同時に触ってると、これまで使ったことない筋肉使うのか手が疲れてくるので、クリック系左手にしようかと考えているものの、クリックしたつもりが⌘キー打ってたりするのでまだ慣れが必要ですね

見た目はこんな感じになっています。トラックパッドはまだしまえていないけどつい使ってしまうので少し離して置いてあるのがミソ(?)です

PFU キーボード HHKB Studio 日本語配列 (ポインティングスティック メカニカルキーボード)

Crean リストレスト パームレスト 木製 クルミ材 キーボード用 腕置き 滑り止め付き おしゃれ (S 60鍵まで対応)

仕事

2023年は、特に技術分野において大きな変化があった年でしたね。OpenAIやLLM周辺の動向を追いつつ、ユースケースを適切に選択してプロダクトへの実装も進めてきました(おもにチームメンバーが)。3月時点でAzureOpenAIをプロダクトに実装していたので、相当早かったはず

プロダクトへは弊チームのハイパー優秀なTechLeadが爆速実装してくれてました! 顧客にも早速使われ始めてて流れに乗れてる感ある😎 https://t.co/I1UoEYqMgb

— 古屋 太郎 (@taross__f) March 16, 2023

このタイミングでAIを事業の柱にしている弊社にいられたのは幸運だなあと思いました。またLLM絡みで登壇機会も複数いただけました。他のコミュニティで話した人でもあのときの講演見てましたよ、みたいなことを言われることもあったり

Microsoft Build Japan2023に登壇した

SaaS on AWS 2023に登壇した

後半はこれまで所属していたチームを異動し、別の子会社のPKSHA Communicationに出向して歴史の長いプロダクトとリリース直後のプロダクトそれぞれでEM的な業務をやっています

なかな大きなチャレンジで、全員初対面でバリューストリームも全然違う組織において課題を解決していかなければならず、まずじっくり観察するところから入って少し自分がいる意味が出てきたような状態ですね。ただこれは本当に難しくてこのロールで成果を出すってなんだっけ…という状態を週に何回か思い返して悩む状態を続けています。これまでのプロダクト開発SWEの延長上にあるマネジメントと異なる現状なので、アンラーンが必要で2024年もここできちんと成果なり自分の中で手応えが感じられるようにすることが個人の目標になるでしょう

これまでと視点を変えないといけない打席をもらえてると感じているので、ここは結果につなげていきたいですね

副業は去年一つ手伝いはじめたところ、うまくワークできずストップしてしまったりしました。すこしアドバイス的なこともしましたが、やはりスクラムチーム入らずにやっていくのは厳しいですね。ご迷惑をおかけしました…

また前職もほとんど何もやってない状態で契約だけずっとあったのでちゃんと契約終了として、今抱えている副業はゼロになり、手は空いています! ただ個人でいろいろやりたいこともあるので、あまり積極的に副業はやらないようにしていくつもりです

生活

一番大きなできごとは妻の仕事復帰でした。上の子は幼稚園通っていましたが保育園に転園し、妻のシフトに合わせて日に応じて送り迎えをするスタイルになりました

幸運なことに子供二人とも徒歩5分の保育園に入園できてよかったです。そこがだめだったらチャリで15分みたいな園になってたので生活もだいぶ違ったはず

妻も5年ぶりの仕事復帰でいろいろ大変だと思いますがなんとかやれているようです。会社としても基本リモート+裁量労働+休み多めなので調整しやすくて助かっています。子供たちも保育園の洗礼(?)なのか半年くらいはやたら体調崩してましたが、だいぶ安定してきました

子供連れてフェスにも行けたし、旅行も気軽に行けるようになったしいろいろ楽しめるようになってきた感あります

趣味としては年初にコロナになったきっかけでUndertaleにハマったりしたおかげか、Undertale関連の音楽をよく聞いていたし、ピアノをちゃんと練習したくなって来ました。あとはティアキンやったり

来年に向けて

仕事も個人の業務としては今年の大きな変化を受けてきちんと成果につなげていきたいですね。あとはいろいろな場所にも顔を出して、とくにコミュニティ活動みたいなの苦手なので、技術広報だったりコミュニケーションだったりするためにもアウトプットを重要と捉える1年にしていきたいと思いました

社内のEmbeddingやRAG実装の事例を紹介しつつ、実は事例ごとに結構気にするところ違うんですよね、という話をしました。冒頭に生成AIの実プロダクトへの実装やられている方挙手してもらったら数人しかいなくて、弊社にいると当たり前のように実装事例あるんですがまだまだこれからやっていくところが多いんだなと改めて感じました。また今回は社内の事例を集めたので当事者でない情報も多かったですが、お客様含め協力的でとても助かりました。ありがとうございました

Ask the speakerではほとんど質問者は現れなかったのが少し悲しかったですが、AWSの方とガッツリ話せたので良しとします。あとは懇親会で出たビールがCOEDOビールメインで、ロジやられた方にとても親近感を覚えました

弊社は引き続きRAGだったりLLM関連技術を踏まえて社会実装しているのでご興味ある方はぜひDMでご連絡ください。採用ページリンクはこちら

少し前ですが所属するチームでMicrosoft Teams上でのアプリケーションを開発していることもあってMicrosoftの方からお声がけを頂き、2023年6月27日Microsoft Build Japanで登壇しました。上記はめちゃくちゃそれっぽく撮影いただいた写真です。タイトルは、”Azure OpenAI Serviceを活用した AI SaaSプロダクト開発の実践”でした。プレゼンテーションの内容については、以下のリンクからご覧いただけます。

私の所属するチームでは、Azure OpenAI ServiceをAI SaaSプロダクトに組み込んでいます。登壇では、そのLLMのプロダクトへの実装に当たって考慮すべきポイントや注意すべき点について話しました。アンケートの内容も悪くなかったようですし、反響もすこしはいただけたのでよかったかなと思います

なお、久しぶりのリアル登壇であり、ピンマイクをつけての発表は初めての経験でした。その新鮮さと直前の機材トラブルからか逆に緊張がほぐれてたすかりました

現在私たちはLLM含めざまざまなアルゴリズムを組み込むプロダクト開発を進めています。この分野に興味がある方は、下記リンクから詳細をご覧いただけます。カジュアル面談もできますのでぜひご連絡ください

AI Helpdesk LP リクルーティング情報