2026年1月9日か10日、その場で rails new してそのバージョンでライブコーディングします。
何を作るかはその場にいるみんなとノリで決めよう。

テーマ
体重、カロリー、歩数、アクティビティなどのヘルスケア由来の時系列データを分析し、データの不整合から真の問題を特定。記録の徹底と習慣化によって○○kg減量に成功した実践例を、技術的な分析手法とともに紹介します。

想定する参加者層
初心者〜中級者、データ分析に興味がある方、特別な前提知識は不要。ダイエットを始めようとしている方、健康診断の結果が気になる方

トーク概要
数年間で○○kg増えた体重。あすけんで記録したカロリーデータと、Apple Watchが記録した歩数・アクティビティデータは揃っていた。しかし分析してみると、記録されたカロリーでは体重が増えるはずがないという矛盾が浮かび上がった。
詳しく分析すると、いくつかの発見があった：

記録している期間は体重が減っている：カロリー記録がある期間をプロットすると右肩下がり
記録していない期間に体重が増えている：記録の空白期間と体重増加が相関
運動量の変化は体重にほとんど影響していない：歩数・アクティブカロリーと体重変化の相関が低い

この不整合から見えてきたのは、「記録していない日に高カロリーを摂取している」可能性。現在の体重が妥当だとすれば、問題は記録の抜け漏れにあることがわかった。
そこで徹底的に記録をつけるようにした結果、○○kg減量に成功。今度は食事記録とアクティビティデータが整合し、もっともらしい結果が得られた。人間行動心理学的にも、記録をつけることが習慣化を促すことは知られている。
このトークでは：

ヘルスケアデータの取得・可視化手法（Apple Watch、あすけんなどの連携）
時系列データ分析による不整合の発見プロセス
データから見えた「記録している時だけ痩せる」という真実
記録の徹底による習慣化と減量成功の実践例
エンジニアならではの「データドリブン」なダイエット戦略

を紹介します。
技術者として「測定できないものは改善できない」を体現し、データの嘘を見抜き、行動を変えた実体験です。結局、ダイエットは記録をサボらない自分との戦いでした。でも、そこにエンジニアリングで立ち向かいました。 健康が気になる方、データ分析を実生活に活かしたい方、ぜひご参加ください！

テーマ Google Apps Script, TypeScript, JavaScript
想定する参加者層 初学者から幅広く

内容
スプレッドシートをDBのように扱いたい時ありませんか？さらにこのDBから必要に応じて適当な情報を抜いたり差し込んだりしないといけない場合、GASを書いて自動化したくなるでしょう。
しかし、GASでスプレッドシートを操作するのは非常に面倒です。なぜならGASでデータを取得したい場合「このセル(あるいは行か列)からこのセルまでを数字で書かないといけない」ためです。増減するDBデータの中で対象データの行番号列番号位置を探し、データを抜いたり差し込んだりする手間のかかるコードを書かないといけません。
そこで私はORMのようにスプレッドシートを操作でき尚且つ、GASをローカルで開発できるツールを併用しJavaScriptだけではなくTypeScriptで開発できるライブラリを作ってみました！

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

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

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

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

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

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

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

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

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

得られる知見：

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

想定聴衆

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

Python風言語でプログラミングするゲーム「農家は Replace() されました」のエンドコンテンツ、リーダーボードでは、より効果的な農場をプログラミングして世界中のプレーヤーとタイムを競います。
タイムを縮めるためには計測が大切です。どのようにタイムを縮めるのか、その考え方を紹介します。

Webサービス開発、特に自社事業の開発では、機能要件と非機能要件がしばしば明確に分けて扱われます。
企画や施策を実現し、売り上げるを上げるものは「機能要件」、パフォーマンス・UX・セキュリティ・アクセシビリティなどの領域は、「非機能要件」として扱われます。

果たしてここで分類された非機能要件は、本当に非機能的なものでしょうか。

本セッションでは、「機能要件」と「非機能要件」と二分化された分類を1からもう一度捌き、これらが離散的ではなく連続的に捉えるものであり、エンジニアだけではなく全ロールの人が向き合う必要があるという考察をします。

想定参加者:

• Webサービス開発者(エンジニア、デザイナー)
• プロダクトマネージャー・プロダクトマネージャー
• カスタマーサポート・セールス

テーマ

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

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

初心者向け

トーク概要

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

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

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

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

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

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

【テーマ】
・ AWS の IAM RoleやIAM Policy、およびAWSにおけるアクセス可否の判定の仕組みなど

【想定する参加者層】
・ AWSを業務・私用問わず触っている方
・ IAM RoleやIAM Policyについて詳しく知りたい方（特にIAM RoleのAssumeRoleやPrincipalなど）
・ アイデンティティベースポリシー、リソースベースポリシーなどポリシーの種類やそれによる最終的なアクセス可否の判定について知りたい方

【トーク概要】
2025年もいろいろなセキュリティ事故がニュースになり、特に2025年後半はサプライチェーン大手企業に対する攻撃により、我々の生活に関係するほどの影響がありました。
このようなセキュリティ事故ですが、「セキュリティ関連の設定不備」が原因となる事例がかなり多いのも事実です。
IPAの「情報セキュリティ10大脅威 2025」でも3位となっていることからも、「セキュリティ関連の設定不備」がどれほど致命的であるかがわかります。

そしてAWSにおいてセキュリティの基本であり、かつ最も重要なもの、それはIAM PolicyとIAM Roleです。
しかし、それだけ重要なIAM PolicyとIAM Roleですが、意外と十分に理解しきれていない、という方もいらっしゃると思います。
特にIAM RoleのAssume RoleやPrincipal、そしてアイデンティティベースポリシー、リソースベースポリシーなどの各種ポリシーが
複雑に絡み合った場合のアクセス許可・拒否判定の挙動がどうなっているかについて、なかなか把握できないという方もいらっしゃると思います。

そこでこのセッションでは、そんなセキュリティ的に最重要項目であるIAM PolicyとIAM Roleについて、
・ IAM PolicyとIAM Roleの基本
・ IAM RoleのAssume RoleやPrincipal
・ 各種ポリシーが複雑に絡み合った場合のアクセス許可・拒否判定のしくみ

についてお話しし、皆さんが携わっているシステムにおいて、思わぬセキュリティ事故が発生することを防ぐためのお役に立てればと思います。

【セッションゴール】
・ IAM PolicyとIAM Roleの基本、およびAssume RoleやPrincipalなどの仕組みを理解できるようになる
・ AWSにおけるアクセス許可・拒否判定のしくみを理解できるようになる

概要

人生で何度も入力したことのある住所フォーム。
しかし、入力するたびに「郵便番号のハイフンの有無でエラーになる」「全角しか受け付けない」「ブラウザの自動補完が効かない」など、細かな苛立ちを感じたことはないでしょうか。

では、ユーザーにとって使いやすく、迷いのないフォームを作るにはどうすればよいでしょうか。
その判断の指針となる考え方として、「驚き最小の原則」があります。
この原則は「どう振る舞うべきか迷ったときには、相手が最も驚かない選択をする」という考え方です。

このセッションでは、住所フォームを題材に「驚き最小の原則」を具体的な設計判断に落とし込む方法を紹介します。
具体的には次のような内容を予定しています。

• サービスにおける「住所」という重要情報の立ち位置
• 「驚き最小の法則」とは何か、サービス開発ではどのように応用できるのか
• 住所フォームでのHTMLで構築するための input 要素や select 要素、または補強する属性 (placeholderなど）の正しい使い方
• システムによる住所自動入力と、ユーザーの意図した手動入力を両立させる工夫

日々 UI を設計・実装するエンジニアに向けて、ユーザーが自然に感じる動作を実現するための具体的な指針を提供します。
セッションを聞いた後、判断に迷ったときには「驚き最小の原則」に立ちかえり、より良い選択ができるようになることをゴールとします。

想定する参加者

• UI を実装する際にどのような画面を作ればよいか判断に迷う初級〜中級エンジニア
• UI 設計の判断基準をジュニアエンジニアに伝えていきたいベテランエンジニア
• 専任のフロントエンドエンジニアやデザイナーがいない現場で UI を作る必要があるエンジニア

想定する参加者に持ち帰ってほしいこと

• サービス開発をしていて迷ったときに「ユーザーが驚きが少ない選択」を取れるようになる「驚き最小の原則」という判断軸を身につけること
• input 要素や select 要素など、フォーム構築する上で必要なHTML要素を定義に沿って正しく使うこと

Nxの被害など、npmパッケージのサプライチェーン攻撃が現実の脅威となった今、開発環境のセキュリティ対策は全ての開発者にとって避けられない課題です。

本セッションでは、実際の攻撃事例から学ぶ教訓をもとに、今すぐ実行できる対策から1Password CLIとコンテナ技術を組み合わせた理想形まで、段階的にセキュリティを強化していく現実的で実践的なアプローチを紹介します。

テーマ

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

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

主にソフトウェア開発に携わる一般エンジニアを対象としています。
テストを我流で行っている方、または単体テストや結合テストの品質をもう一歩上げたいと考えている初学者〜中堅エンジニアを想定しています。
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）を活用してカオスエンジニアリングとして意図的に障害を発生させ動作確認をしました。
本セッションでは、設定した可用性対策についての解説とそれを実際に検証して上手くいったことや上手くいかないことを赤裸々にお話しします。

WebAssemblyとしてビルドされたロジックを利用したAndroidアプリを試作しました。この試作によって、NDKに対応していないJavaScriptなどの言語で実装されたライブラリをAndroidアプリに組み込むことが可能になることが示唆されます。
WebAssembly（Wasm）とは、ビルドターゲットの1つで、RustやC++などをビルドして作成するほか、JavaScriptやPython、Rubyなどのスクリプト言語を変換することでも作成できます。Webブラウザでの利用のほか、サーバレス環境やエッジ処理などで利用されています。
今回は、この処理系をNDKを利用して、Androidアプリに組み込みました。その処理系経由でWasmを利用しています。このセッションでは、組み込みの詳細と述べるとともに、組み込み時のいくつかの注意点と工夫についても述べます。
複数の言語をまたいで関数が呼び出される様子に興味のある方、WasmのWeb以外でのフロントエンドでの利用について興味をお持ちの方は楽しめるのではないかと思います。

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

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

■ トーク概要

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

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

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

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

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

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

◆テーマ
Webサイトのテーブル（表）表示が思い通りにいかない理由と対処法をHTML/CSSの仕様や現職における巨大テーブル開発で培った経験に基づいて紹介します。

◆想定する参加者層（前提知識）
・Webサイト制作を最近はじめてテーブル表示のじゃじゃ馬っぷりに苦しめられてる初心者
・Webサイト制作に慣れてるけど、テーブル表示のトラブルに場当たり的に対応してるので結局なにがどうダメなのか体系的に理解してない中級者

◆トーク概要
Web開発者の悩みの種に「表（テーブル）の表示が上手くいかない！」という問題があります。
装飾が上手くいかない、サイズ調整が上手くいかない、スマホ表示が上手くいかない…どの悩みを1度は抱えたことがあるはず。
そして、HTMLやCSSをガチャガチャいじったらなんか上手くいったからいいや…と場当たり的な対応でその場を凌いでる人もいるのではないでしょうか。

本セッションでは、私が現職で取り組んでいるSaaS製品の巨大テーブル開発における経験やHTML/CSSの仕様などに基づき、テーブル表示の上手くいかないところとその対処法を整理します。
歴史的経緯により仕様と挙動が混沌に満ちているテーブル表示の実態を理解して、テーブルと仲良くなりましょう！
たった30分で厄介なテーブル実装に自信を持てるようになるお得な発表です！

私の所属するプロダクトは開発者が数十名まで拡大していましたが、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の深い知識は不要です。

Goは、Kubernetesやコンテナランタイムをはじめクラウドネイティブ基盤の中核を担っている言語です。
しかし、Goは決して「何でもできる」万能言語ではありません。

Goの非常に扱いやすい並行処理モデルは、OSプロセスを直接扱うような低レベルな領域との相性が悪いという側面を持ちます。
このような処理は、実際にOSに干渉してコンテナを生成する、低レベルコンテナランタイムに欠かせない技術です。
現在低レベルランタイムのデファクトスタンダートであるruncはGoで書かれていますが、そのプロセス制御はCGoという仕組みで呼び出されるC言語のロジックに強く依存しています。

このセッションでは、上で述べたGoの設計と低レベルランタイムのギャップを紐解きながら、以下のようなトピックを深掘りします。

• コンテナとは何か、OSプロセスとsyscallの基礎
• コンテナランタイムの構造 (高レベル/低レベル)
• Go特有の並行処理、goroutineとプロセス作成に及ぼす影響
• CとGoの2言語で簡素なコンテナを作るライブコーディング
• 代替ランタイムであるyouki、crunの紹介

コンテナランタイムやGo言語の並行処理の仕組みを理解し、プロジェクトに適した言語を選ぶ重要性を一緒に再確認していきましょう。

[対象者]

• コンテナを日常的に使っており、その裏側を理解したい方
• Go言語の並行処理(goroutineとその中身)に興味がある方
• 普段はアプリケーション開発が中心だが、OSの動きを学んでみたい方
  • OSやシステムプログラミングに興味があるアプリケーションエンジニアが、言語・OSやコンテナの裏側を覗く第一歩として最適です。

[アウトライン]

1. コンテナとは何か/OSプロセスとsyscall
2. コンテナランタイムのアーキテクチャ
3. ライブコーディング: Cで作る簡素なコンテナ
4. Goの並行処理、goroutineとその実行モデル
5. ライブコーディング: Goで作る簡素なコンテナ
6. runcにおけるCGoでのプロセス管理
7. 代替ランタイム: youki、crun、etc...