エンジニア採用のスカウトメッセージで「ちゃんとレジュメを読んでくれた」と感じてもらえる文章をAIに生成させようとしたら、想像以上に大変でした。プロンプトエンジニアリング、RAG、ファインチューニング...次々と手法を試しても期待する品質に届かない。本セッションでは、AIの専門家ではないエンジニアが、特定ユースケースで「妥協しない品質」を実現するまでの泥臭い試行錯誤と、そこから得た知見を共有します。

これまでエンジニア採用で何百、何千のスカウト文章を書いてきて思いました。エンジニア採用の成功率を上げるには、候補者一人ひとりに向き合った「人間味のある」スカウトが大切です。でも、これをAIで自動化しようとしたら...予想以上の苦労が待っていました。

本セッションで話すこと：

1. プロンプトエンジニアリングの限界

   • プロンプト改善で見えた「できること」と「できないこと」
   • 具体例：なぜAIは「〇〇の経験を活かして」という抽象的な表現に逃げるのか

2. RAGで過去資産を活用...したかった

   • 過去のよくできたスカウト文章をRAGで学習させた結果
   • 文脈理解の落とし穴：なぜ的外れな引用をしてしまうのか

3. 品質を妥協しないための工夫

   • 評価基準の明確化：「人間らしさ」を数値化する試み
   • ハイブリッドアプローチ：AIと人間の協調による品質担保

得られる知見：

• MLエンジニアでなくても、AIの出力品質を改善できる実践的手法
• 「期待する品質」を定義し、測定し、改善するフレームワーク
• プロダクト開発でAIを活用する際の現実的な落としどころ

想定聴衆

• AIを活用したプロダクト開発に興味があるエンジニア（初〜中級者向け）
• 生成AIの実用化で苦労している方
• 「AIに任せきり」ではなく品質にこだわりたいエンジニア

テーマ

Keycloakで始める認証基盤入門 — 1年半の運用で学んだ飴と鞭

想定する参加者層（前提知識）

初心者向け

トーク概要

Keycloak という OSS をご存知でしょうか？

昨今、SSOや2段階認証など、認証・認可にまつわる話題が絶えません。
Keycloakは、そんな認証・認可に必要な機能を汎用的に実現できる、セルフホスティングが可能なOSS認証基盤です。

発表者は実務で Keycloak を導入し、1年半ほど運用してきました。
導入の簡単さや、豊富な拡張機能、そして個々の要望への対応の苦労など、飴と鞭を等しく味わっています。

本発表では、そんな Keycloak について興味を持っていただき、将来的な"飴"の量を増やすことをねらいとしています。

• Keycloakで何ができるのか？（SSO統合、OIDC連携、多要素認証など）
• 運用時の課題やその対応、そして実施した工夫
• 認証・認可の複雑さとKeycloakでの向き合い方

これらの知見の共有を通して、これからKeycloakを検討される方、すでに使っている方、どちらにも参考になれば嬉しいです。

テーマ

明日から使える！ソフトウェアテストの歩き方

想定する参加者層（前提知識）

主にソフトウェア開発に携わる一般エンジニアを対象としています。
テストを我流で行っている方、または単体テストや結合テストの品質をもう一歩上げたいと考えている初学者〜中堅エンジニアを想定しています。
JSTQBなどの体系的なテスト知識がなくても理解できる内容ですが、仕様を読みコードを書いた経験があると理解が深まります。
テストエンジニアだけでなく、開発者・PM・デザイナーなど「自分の成果物の品質に責任を持ちたい」と考えている方にもおすすめです。

トーク概要

テストって、どこまでやればいいんだろう？
機能は動いているけど、なんとなく不安。レビューでは「テストケースが浅い」と言われる。
そんな経験をしたことがある方は多いのではないでしょうか。

このセッションでは、現場で本当に役立つ「ソフトウェアテストの考え方」を、明日から実践できる形でお伝えします。
テーマは「同値分割を基本としたテスト技法」「経験ベーステスト」「生成AIを活用したレビュー技法」の3つ。
教科書でおなじみのテスト技法に加え、現場で実践している生成AIの活用方法を紹介します。

テストは、実際のプロジェクトでどう活かすかとなると、途端に難しく感じる人が多い分野でもあります。

私自身、スタートアップでQAエンジニアとして日々開発と向き合っています。
IT業界20年。開発者やマネージャーとしての経験を経て、「理論通りにやってもうまくいかない現場」と、「時間がない中でも品質を守る工夫」を何度も経験してきました。

そこで気づいたのは、テストは“やり方そのもの”ではなく“テストの考え方”を学ぶことが大事だということ。
同値分割の前に「どんな違いが意味を持つのか」を見抜く目。境界値分析の前に「どこが境界なのか」を見つける力。
そして、マニュアルに載っていない「勘」や「経験」は、実は“多くは理屈で説明できる”ものだということです。

本セッションでは、JSTQBの定義をベースにしつつ、
・仕様の読み方をどう変えるとテストがしやすくなるか
・チームで納得できるテストを作るために必要な考え方
・不具合を探索する道標の作り方
など、「ものづくりのラストワンマイル」を埋めるヒントをお話しします。

単に「テストをやる人」ではなく、
「品質をつくる人」として一歩踏み出すためのきっかけになればと思っています。

テストを専門にしていなくても大丈夫。
むしろ、今までは“なんとなく動作確認していた”という方にこそ聞いてほしい内容です。
セッション後には、自分のプロダクトや関わっているプロジェクトを少し違う視点で見られるようになり、
「ここは確認しておこう」「ここが危なそう」と、自然にテストの意図が浮かぶことを期待して準備します。

テストは退屈な作業ではなく、プロダクトを深く理解するための一番身近な探求です。
このセッションを通じて、あなたのテストが「やらされるもの」から「やりたくなるもの」に変わる。
そんな体験をお届けしたいと思っています。

「自分のテストがなんとなく不安」「レビューで指摘されがちでしんどい」そんな方に、
明日から試せる“ソフトウェアテストの歩き方・付き合い方”を持ち帰ってもらえるセッションです。

テーマ

不確実性に立ち向かう品質マネジメント

想定する参加者層（前提知識）

開発現場では、品質に関する判断に迷ったり、リスクを後追いで発見してしまう経験のあるエンジニアを想定しています。
職種としては、開発者・QAエンジニア・テックリード・マネージャーなど、チームでプロダクト開発に関わる方を幅広く対象としています。
品質マネジメントやリスクマネジメントの専門知識がなくても理解できる内容ですが、日々の開発プロセスに課題意識を持っている方ほど共感しやすいと思います。
特に「不確実な環境での意思決定」や「リスクとどう向き合うか」に興味のある方におすすめです。

トーク概要

私は全てのマネジメントの目的は"リスクを見つけ「なるべく早く」対処することが本質だと考えています。
このトークでは、リスクを「なるべく早く」見つけるために工夫しているノウハウを共有します。

変化の激しい開発環境では、不確実性に起因する判断ミスやリスクの見落としが、重大な品質問題へと発展することが多くないと思います。
本トークでは、私がエンジニアとして取り組んできた、そうしたリスクに向き合う考え方と実践について発表します。

過去には、曖昧な仕様や品質知識の不足により十分なテストが行えず、リリース遅延や品質低下を招いた経験があります。
現在、その経験を教訓に、リスクを「プロジェクトリスク」と「プロダクトリスク」に分類し、それぞれに応じた対応を開発プロセスに実施する取り組みを行ってきました。
具体的な例としては、リスクを見分けるのための会議体を設け、開発チームと早期に情報を共有し、設計段階から品質に向き合えるプロセスを整備しました。
これにより、仕様検討段階での認識のずれや改善事項を前倒しで発見・対処する等、リスクの顕在化を未然に防ぐ効果があった。
不確実性が高まるなかで、品質に向き合うためのマインドセットと品質マネジメントの両面から対応した実践的アプローチを紹介します。

皆様にとって、現場で再現可能な品質マネジメントのヒントを提供できれば幸いです。

本トークは、昨年YAPC函館や本年開催のSQiP2025に関連する内容です。
YAPC函館）https://fortee.jp/yapc-hakodate-2024/proposal/da4c92fe-0a90-4fd1-9eec-946ce046c1e2
SQiP2025）https://www.juse.jp/sqip/symposium/detail/day2/#b3-2

【テーマ】
複雑なビジネスロジックを持つ機能の設計についての、現実的なアプローチ

【想定する参加者層（前提知識）】
要件定義や設計から開発まで担当しているソフトウェアエンジニアを主な対象とします。
特に、複雑なビジネスロジックの実装で悩んだ経験のある方はきっと共感できる内容となっています。
他には、今後そのような業務を行う予定、または興味を持っている方も歓迎します。

MVCやオブジェクト指向、アジャイルな開発手法についての知識があると、より深くトークを楽しめると思いますが、それらを特別に意識しない、普遍的な「設計思想と現実的な判断基準」に焦点を当てたトークをする予定です。

※特定の業界知識は不要です。
※スピーカーは、Ruby on Railsで開発を行っていますが、設計思想と現実的な判断基準が中心となるため、他言語・他フレームワークのエンジニアにも十分応用可能な知見を提供します。

【トーク概要】
私の所属する会社では、クライアントと保証契約を締結するために必須の与信審査をRuby on Railsでプログラムのソースコードに落とし込んで自動化し、現在に至るまで約2年間運用してきています。

月間1万件を超えるこの審査業務は、与信に関する高度な専門知識や経験、柔軟な判断を要し、「プログラミングによる自動化に向かない」領域とされてきました。
しかし、私たちは、アジャイルなアプローチで開発を進め、「将来が読めない」という現実と向き合いながら、必要に応じて進化できるシステムを、泥臭くも丁寧に築き上げてきました。

本セッションでは、教科書的な設計原則と現実が衝突した際に、どのように設計判断をすればよいのか、具体例を交えながら、私自身の経験を踏まえて知見を共有します。
具体的には、以下のような内容について話します。

・拡張性を生む骨格設計：すべての土台となる基本ルールを、一番初めに明確化することの必要性
・Fat Modelを恐れない：ロジックをModelに集約させることで得られる凝集度と保守性
・判断基準を「設定」として切り出すコツ：個別パターンのビジネスロジックをカテゴリ化し、設定として切り出すことのススメ
・それでも吸収できない例外パターンへの対処法：可能な限りのグループ化と、最終手段としての影響を最低限に留めるハードコーディング/割り切りの判断基準

これは単なる「実装事例」ではなく、複雑なドメインロジックに日々格闘する全てのエンジニアに贈る、泥臭くも強いコードを生み出すための設計哲学と実践録です。
理想と現実のギャップに悩むあなたの現場に、即戦力となる「泥臭くも強いコード」を生み出すためのヒントを持ち帰ってください。

LLM の登場で、Chrome 拡張のようなシンプルな構成でホスティングする必要のないアプリは Vibe Coding だけで驚くほど簡単に作れるようになりました。
しかし、それを「継続的に」開発・運用しようとすると、

・動作確認はどうする？
・毎回、開発者コンソールからzipを手動アップロードするのは面倒

といった壁にぶつかり、Vibe Coding の手軽さが失われます。

本セッションでは、私が個人開発している Chrome 拡張の実際の開発環境を題材に、Chrome 拡張の E2E テスト自動化の方法やデプロイの自動化といった継続的開発を行うための開発手法を紹介します。
この Chrome 拡張の開発はすべて Vibe Coding で行われており、私は要件の指示とコードレビューのみ実施しています。この経験を紹介することで、LLM 時代の新しい開発プロセスとそのリアルな実践値を共有します。

【想定する参加者層】
・Chrome 拡張の開発に興味がある方、または開発で面倒さを感じている方
・特に、Chrome 拡張のE2Eテスト自動化や自動デプロイに関心がある方
・Vibe Coding やプロンプトエンジニアリングの実践例に興味がある方
・CI/CD や開発環境の自動化・効率化に関心がある方

【このセッションで得られること】
・Chrome 拡張のテストやデプロイを自動化する具体的な手法
・Vibe Coding での開発サイクルの実例

高可用性を実現するために冗長化の設計をしてみたものの、「机上の確認では問題なさそうだが、実際に障害が起きた時に本当に動作してくれるかわからない」と不安になることは誰しも経験があるのではないでしょうか。少なくとも自分はあります。特にKubernetesの設定は複雑で本当に機能するのかに自信が持てませんでした。
ではどうするか？という一つの回答として、できるだけ障害に近い状況を再現して試してみました。今回はKubernetesのPDBやトポロジー制約等のアプリケーションの可用性を担保する仕組みを諸々設定し、さらにAWS Fault Injection Simulator（FIS）を活用してカオスエンジニアリングとして意図的に障害を発生させ動作確認をしました。
本セッションでは、設定した可用性対策についての解説とそれを実際に検証して上手くいったことや上手くいかないことを赤裸々にお話しします。

■ テーマ
システム分離、リプレース、テスト、移行戦略

■ 想定する参加者層
中級者以上を対象
安全なシステム分離、移行戦略に興味のある方

■ トーク概要

新卒4年目、ECサイト構築サービス「カラーミーショップ byGMOペパボ」のエンジニアです。今年1月に別のサービスから異動し、ジョインして間もなく、私は「レンダリングシステムを分離する」というミッションを任されました。
カラーミーでは、自分のショップのデザインを「デザインテンプレート」という機能で、独自の記法のテンプレートを用いて自由にカスタマイズすることがあります。この機能は、内部ではカスタマイズされたテンプレートをレンダリングする責務を担ったアプリケーションによって実現されています。

しかしこのアプリケーションには、ショップページの「テンプレートレンダリング処理」に加え、そのテンプレートに必要なデータを取得する「データ取得処理」、その他、他のシステムから参照されるさまざまな責務が密結合していました。 この構成は、柔軟性のあるシステムの実現や、パッケージのアップデートを難しくする可能性を秘めていました。
この課題を解決し、より柔軟で堅牢なアーキテクチャを実現するため、「テンプレートレンダリング処理」の責務を別のアプリケーションに分離する必要がありました。

もちろん、サービスを止めることは許されません。 その上で、別のアプリケーションに分離した上でも、レンダリング結果が変わらないことを保証する必要があります。そこで私が採用したのが、稼働中のシステムを徐々に新しいシステムへ置き換えていく「ストラングラーフィグパターン」と「ペンギンテスト」の考え方です。

ストラングラーフィグパターンは、システムを段階的に移行するための手法、そしてペンギンテストは、NE株式会社のさくらいさんがブログで紹介している、システムの移行前と移行後の動作を担保するための手法です。後者は、新旧両方のシステムに同じリクエストを流し、その結果を比較検証することで動作を担保するアプローチです。

本登壇では、異動して半年の私が、このシステム分離にどう立ち向かったのか。 ストラングラーフィグパターンとペンギンテストを参考にした具体的な戦略、新旧の安全な切り替え手法、移行中に実感したペンギンテストのメリット、そして無事に分離を完遂するまでの道のりをお話しします。

この発表を通じて、システムの安全な移行戦略や、段階的なリリースの具体的なノウハウを持ち帰っていただけます。

私の所属するプロダクトは開発者が数十名まで拡大していましたが、SREは長らく2名体制のままでした。この状況で、問い合わせが来るたびにSREが情報共有ツールのKibela上で関連ドキュメントを探し出し、繰り返し同じ説明をすることに時間を費やすことが発生していました。
解決策としてNotebookLMの導入を試みましたが、KibelaのMarkdown形式を直接NotebookLMに取り込むと、回答の根拠となるソース表示が崩れる問題に直面。NotebookLMの回答における情報ソースとしての信頼性を担保できませんでした。この課題を解決したのが、NotebookLMと相性の良いGoogle Docsです。本トークでは、私の専門外のApps ScriptをGeminiと対話しながら構築し、KibelaからGoogle Docsへのドキュメント同期ツールを自動で作成し、NotebookLMに取り込むまでの一連のプロセスを共有します。この対応により問い合わせ工数の削減だけでなく、多国籍チームの開発生産性向上という思わぬ価値も発見しました。AI活用の障壁を乗り越えた実践的な問い合わせ削減の実例をお話しします。

[想定する参加者層]
・社内ドキュメントの管理や活用に課題を持つエンジニア
・Gemini、NotebookLMの具体的な業務活用事例に興味がある方
・多国籍な開発チームの生産性向上に関心がある方

[前提知識]
・ドキュメント管理ツール（Kibela, Google Docsなど）の利用経験
・AIチャット（Gemini, NotebookLMなど）への基本的な関心
※Apps ScriptやJavaScriptの深い知識は不要です。

テーマ

ORMやフレームワークに依存しない、SQL主導のDBマイグレーション。
スキーマを長期的に管理するための合理的アプローチを、ツールと思想の両面から考察します。

想定する参加者層（前提知識）

• Webサービス等のDB設計や運用に関わるエンジニア
• ORMやフレームワークのマイグレーション機能を使った経験がある方

トーク概要

ある程度経験を積んだエンジニアなら誰しも一度は「これはSQLで書いたほうが早い」と感じたことがあるでしょう。
ORMやDSLによるDB操作は安全面など様々なメリットがある一方で、RDBMSの機能や性能を限界まで引き出すことはできません。
DBのマイグレーションに関しても同様に、SQLで書きたい、あるいは書かざるを得ない場面が稀によくあります。

データの寿命がサービスのそれよりはるかに長いことはよく知られています。ではスキーマの寿命はどうでしょう。
スキーマはDBと共に生きるものであり、フレームワークやライブラリ、ツールといった周辺技術よりもずっと長命なのです。
寿命の短いものでスキーマを管理するより、DBと寿命をともにするSQLを用いるのが合理的ではないでしょうか。

一方で、SQLだけでDBマイグレーションを運用するには多くの課題があります。
本セッションでは、SQLだけで安全かつ確実にDBマイグレーションを行うために必要な要素を整理し、それを支えるためのツール「migy」とそのコンセプトを紹介します。
SQLをマイグレーションの中心に据えてRDBMSの力を最大限に活かしつつ、長期的な信頼性を実現するためのアプローチを提案します。

ゴール

• 熟練エンジニアがSQLに立ち返る理由を、技術要素の寿命構造から理解する
• スキーマ・データ・アプリ・ツールのライフサイクル関係を整理し、SQLで管理する合理性を掴む
• SQLによるマイグレーションの課題とその克服方法を通じて、ORMやFWに依存しない持続的なデータ管理の視点を得る

概要

エンジニアとして実務に携わり始めた私は、最初の数ヶ月で数々の"しくじり"を経験しました。
例えば、SQL の条件指定ミスでスコープ外のデータが見える危険なバグを作成したり、「善意のリファクタリング」が先輩の変更とコンフリクトして修復不能に陥ったり...。さらには、AI レビューツールの提案を鵜呑みにして無駄な修正を繰り返すという、しくじりも経験しました。
しかし今となって思うのは、これらの失敗こそが最高の学習材料でした。特に AI ツールを活用するようになってから学んだのは、AI やツールが答えをくれる時代だからこそ、「自分の頭で考え、判断する力」が重要であるということです。
このセッションでは、ジュニアエンジニアが現場で直面する様々な課題と、そこから学んだ「AI 時代に必要な判断力」について等身大でお話することで、これから同じ壁にぶつかるジュニアエンジニアや、彼らを支える先輩エンジニアの助けになる時間にしたいと思います。

対象者

• 実務 1 年目前後のジュニアエンジニア
• ジュニアエンジニアを育成・レビューするメンター
• チーム開発に慣れず悩んでいる初学者
  ※主な言語は Ruby ですが、特定技術の知識は不要です

トーク構成
第 1 章：新米エンジニアの洗礼

• 初めて直面する膨大なソースコードに戦々恐々

第 2 章：俺のしくじりを超えてゆけ

• データ流出寸前！SQL 条件指定の落とし穴
• これが車輪の再発明！？
• 「それ…AI がやりました！」問題
• 原因は…エラーメッセージに書いてありました
• 善意のリファクタリングが招いた大惨事

第 3 章：AI レビューツール導入編

• 激突！！CodeRabbit vs Rubocop
• AI 君の嘘つき…！

第 4 章：失敗から得た学び編

• 自分の頭で考えて言語化してみよう
• 失敗を恐れず挑戦しよう
• コードレビューは最高の成長機会

伝えたいこと
AI やツールが正答を示してくれる時代だからこそ、私たちは「判断する力」を磨かなければならないと感じています。
AI は確かに効率的で、間違いを減らしてくれます。
しかし、すべてを委ねてしまえば、自分で考え、判断し、失敗から学ぶ機会が失われてしまいます。

ツールは答えをくれますが、どの答えを採用するかは、最終的に自分が決めなければなりません。
このセッションで伝えたいのは、「失敗を恐れず、自分の考えで決めること」の大切さです。

優秀なエンジニアの成功談ではなく、“何度もしくじりながら少しずつ判断力を磨いてきた ジュニアエンジニア”として、同じように悩む誰かの背中をそっと押せる時間にしたいと思います。

ブレットボードで回路を組んだり、はんだ付けをしたり電子工作に慣れてくると基板を作りたくなりませんか？なりますよね。
JLCPCB を初めとした安価な中国メーカーの誕生により以前よりも基板を作るハードルはグッと下がりました。

しかしブレットボードやユニバーサル基板で試作した回路を実際どうやって基板にするかわからない方も多いことでしょう。
このセッションでは Kicad を使い、カンファレンスや勉強会などで使えるような名刺基板を作って発注するところまでを解説をしながら行います。

このセッションを聞けばすぐに皆さんも基板を作ることができるようになるでしょう。
ぜひ自分だけの基板を作ってTinyGoで遊んでみませんか。

想定する参加者層

・ 電子工作が好き、興味がある方
・ 基板を作ってみたい
・ もの作りが好き
・ TinyGoに興味がある方

概要

タイトルを見て「本当ですか？」と思われるかもしれません。事実、2024年まで登壇活動はおろか社外コミュニティへの参加はほとんど行っておりませんでした。そんな経歴の私ですが、2025年（10月時点）では社外登壇数４０件超を達成しています。今回のセッションでは「未経験でも（頑張れば）私と同じペースでアウトプットできる方法」について紹介したいと思います。

聴講者に持ち帰ってもらいたいこと

1. 一見無謀なアウトプット目標であっても工夫と努力で達成可能
2. 登壇活動を行っている方は特別な方ではない
3. 社外発信の種は周りにいくらでもある

対象聴講者

1. 技術イベントに参加しているが登壇活動を行ったことがない方
2. 登壇にチャレンジしたいがハードルの高さを感じている方
3. 定期的に登壇活動を行っているが発表ネタにマンネリ感を感じている方

セッションの流れ

はじめに（5分）

自己紹介、2024年まで発信活動について紹介します。本セクションではエンジニアとしてのキャリアスタートから登壇活動を全く行っていなかった2024年10月までをふりかえります。

登壇に目覚めたきっかけ（10分）

登壇活動を始めたきっかけ、登壇したことで得られた体験について紹介します。私が登壇活動に初めてチャレンジしたのは2024年11月に開催されたAWSコミュニティ（JAWS-UG Education支部）でした。社内でも講師として人前で発表する機会は比較的多くありましたが、社外での登壇は初めてでした。今までの社内での発表と違い、「短い時間で自分の想いを伝える」ことに非常に苦労しました。本セクションでは「はじめての登壇経験を通じて失敗したこと、失敗から得た体験」について紹介したいと考えています。

年間40件以上登壇してみて（10分）

2024年11月の初登壇から今までの登壇遍歴、登壇活動を通じて見えたナレッジについて紹介します。最初の数か月は月に1件程度登壇するのがやっとでした。そのうえで、月に2~3件登壇するために必要なアクションについて模索していました。模索する中で「多くの登壇数をこなしている方の共通項」について見出すことが出来ました。結果として、多い時には月8件以上の登壇活動を実現することが出来ました。本セクションでは未経験者でも頑張れば継続的に月2～3件以上登壇するためのポイントについて紹介したいと考えています。

まとめ（5分）

本セッションのまとめ、聴講者へ持ち帰ってもらいたいことについて紹介します。社外発信を行うなかで「人前で話せる経験なんて無い」といった不安があると思います。初登壇する前は私も同じように考えていました。登壇活動を行っていくなかで、「誰もが登壇するためのネタはある、気づいていないだけ」という事実に気づきました。本セクションでは、聴講者がこれから登壇活動してもらうための後押しにつながる話を行いたいと考えています。

概要
みなさん、エンジニアになったばかりの頃の気持ち、覚えていますか？
日々の開発に追われ、いつの間にか仕事の楽しさや「手触り感」を見失っていませんか？
このトークでは、安定した公務員という“養殖場”を飛び出し、エンジニアという大海原にやってきた僕が、エンジニアになって1年半、この世界でどう泳いで、どうもがいて、どんな楽しさを発見してきたかお話しします。
自分のコードが世界を動かす手応え、お客様との対話、チームで大きな壁を越えるスリル。
僕の回遊の物語を通じて、「あ、だからこの仕事は面白いんだ！」と皆さんの日常にある輝きを再発見してもらえたら嬉しいです！

話すこと
なぜ安定の“養殖場”を飛び出したのか？
大海原で見つけた、エンジニアという仕事の楽しさ
バブルに乗った僕が辿り着いた、最高の「結果」とは

対象者
エンジニアという仕事の楽しさを改めて感じたい方
“養殖場”育ちのエンジニアが、どんな泳ぎ方をしているのか興味がある方

概要

3年目の新人エンジニアとして入社2週間で、2.5ヶ月以内の採用管理ツール（ATS）のMVP開発を一人で任されました。
既存SaaSの上に Next.js + Hono + AWS Lambda で構築し、DDDを前提に拡張可能な設計を担当。
要件定義は済んだ状態で引き継いだものの、ページデザイン未定、外部連携（A社は運用まで6週間かつ要運用実績、B社は連絡不通）など不確実性が多く、仕様確定を待たずに進める必要がありました。
既存コードのキャッチアップから設計・実装まで、短期間で並走させるために取った「考え方」と「進め方」を実体験ベースで共有します。

想定ターゲット

• 新しいプロジェクトを中途参入または単独で引き継ぐエンジニア
• 要件定義後のフェーズから設計・実装を任される中堅層（2〜5年目）
• スタートアップや小規模チームで、不確実性の高いMVP開発に関わるエンジニア
• “設計の理想と現実的な進め方”の調和方法を模索している方

数理最適化は、物流ルートの最適化やシフトの最適化などに活用される、数学の応用分野の一つです。

世間では Python による実装が標準ですが、ここは、あえて Go 言語で解きながら、Step by step で解説します

https://qiita.com/ysaito8015@github/items/087e11b940d64731b816

キャリアの話は、働く人にとって最も重要な事柄の1つにも関わらず、あまり公には話されません。
一方、思い通りの仕事をしたり、希望するロールにたどり着けるのは一握りの人です。

思い通りのキャリアを歩むには社内政治や転職が必要なのでしょうか？
はたまた計画的偶発性理論？セルフブランディング？

継続的なアウトプットをしつつ、コミュニティの運営・裏方も担当し、採用担当もするKaitouが、着実に自分の思い描くキャリアに近づくための「アウトプット」についてお話いたします。

こんな方に聞いて欲しい！

• キャリアについて考えたことがない方
• キャリアについて迷っている方
• キャリアを上手く歩めていないと感じている方
• アウトプットに勇気が出ない方
• アプトプットをついついサボってしまう方
• 若手や部下にアウトプットしてもらいたいけれど、なかなかしてもらえなくて困っている方
• 面白おかしくキャリアップしたい方

Baseline Tooling Hackathon に参加し、インストール不要で npx で実行出来る baseline-search というツールを作成しました。
Baseline とは何なのかにも触れつつ、私が作成したツールのご紹介と、ハッカソンに参加して得られた経験を共有出来ればと思います。

RAGだけでは解決できないIoTサービスに関する問い合わせに対応するため、Bedrockのmulti-agentで“行動するAIサポート担当”をつくってみた話です。

IoTサービスの運用では「通信が切れた」「データが届かない」といった問い合わせが日常的に発生します。原因はデバイス設定／通信回線／クラウド構成など多岐にわたり、担当者はドキュメントを参照しつつAPIで現状を確認して総合的に判断します。本セッションでは、この“調べて→判断して→提案する”プロセスを支援するために、Amazon Bedrock上で動作するマルチエージェント構成を試作した知見を紹介します。

「通信が切れた」などのケースで、一般的な確認手順と実ステータスの両面から原因候補と対応を導く流れを解説します。エージェント間のコンテキスト共有、RAG結果とAPIレスポンスの整合、失敗時のハンドリングなど、設計と運用での工夫も共有します。

最終的には、自分が日常的に行っている問い合わせ対応をどこまでAIに任せられるかを評価しました。

Bunでバックエンドを構築する際、可観測性確保のためにDatadog APMを導入しました。
dd-trace ライブラリはBunを正式サポートしていませんが、工夫次第で本番環境での運用が可能です。

実際に導入を進める中で、スパンは取得できるものの、スパンが関連付けされず、トレースとしてまとまらない問題に直面しました。
Node.jsでは自動で行われるリクエストコンテキストの伝播が、BunとHonoの組み合わせでは効かないことが原因でした。

本セッションでは、この問題の「なぜ」を技術的に深掘りします。
Node.jsでの自動計装の内部メカニズム(モジュールパッチング、AsyncLocalStorageによるコンテキスト管理)を解説し、Bunとの違いがどう影響するかを分析します。
また、Bunでもdd-traceサポートの対応がなされていますが、何をカバーし、何が不足していたのかも明らかにした上で、解決策を紹介します。

対象者: BunやHonoに興味がある方、APM導入を検討している方、ランタイムの内部動作や自動計装の仕組みに関心がある方