テーマ

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

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

開発現場では、品質に関する判断に迷ったり、リスクを後追いで発見してしまう経験のあるエンジニアを想定しています。
職種としては、開発者・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

テーマ

本セッションでは、次の内容を紹介します。

• スマホ/衛星直接通信（D2C）の現状を手早く把握するための通信技術概要
• AndroidプラットフォームにおけるD2Cの実用実装例。そして衛星経由のSMS送信を多様な端末環境・通信環境（例：dual SIM）で安定稼働させるための工夫
• リアルタイム位置情報というプライベートな情報を、伝えるべき相手（家族や山岳会）へと適切に届ける工夫
  時間が許せば、StarlinkベースのD2Cを使う際に周辺地形の面で考慮すべき点や、おすすめのテストスポットとスポットの探し方も紹介したいです。

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

4G・5Gといった現代スマホの通信方式について、うっすらと知識がある方を対象とします。
4G（LTE）回線の通信バンドについての事前知識があると内容を聞きやすいと思います。

Android SDKについての知識、Unixシェルの知識があると楽しく聞けると思います。

登山や海のレジャーといったアウトドアアクティビティーに馴染みのある方は興味を持ちやすいと思います。

トーク概要

主要通信キャリアの4G回線の人口カバー率は99.9%を超えていますが、実際の国土エリアカバー率は60-70%と言われています。
日本には山岳部や島嶼部が多くあり、スマホの電波が入らない場所もまだまだ多いです。

投稿者は登山を趣味としていますが、少しマイナーな山へ登ったら登山口からすでに圏外というケースも多いです。

2025年、au Starlink Directサービスの開始により、日本国内でスマホが人工衛星と直接通信（Direct to Cell; D2C）できる時代がついに幕を開けました。
今年2026年にはau以外の主要キャリア各社のサービスも本格スタートする見込みです。

投稿者は、D2Cの可能性調査と実用的なユースケース探索、そして自分自身や友人の安全確保を目的として、主に登山の文脈でD2C回線を使ってリアルタイムに家族へ位置情報を送信し圏外の安全を確保する「AnzenMap」というサービスの開発とベータ版運用を2025年5月から継続しています。
これは、「遭難してから衛星通信で助けを呼ぶ」のではなく、「圏外行動中つねに位置情報を家族へ定期送信し、不測の事態が発生したら最後の消息地点を家族が確実に把握できるようにする」というコンセプトのものです。
山岳で滑落して気を失ったら連絡できない、スマホを谷底へ落としたら連絡できない、雪山でスマホの電源が切れて連絡手段がなくなる、といったシビアなケースも想定し、それでも可能な限りの情報を家族へ伝えるためのセーフティー策といえます。

このなかでは、いくつかのシステム要素へ取り組む必要がありました。

1. スマホ上で位置情報を定期取得してau Starlink Direct回線経由でSMS送信するアプリ
2. 圏外の端末からSMS送信した位置情報を自宅ゲートウェイにてデータ変換してクラウドへ載せて家族へ共有する仕組み
3. 日本上空を飛んでいるStarlink D2C衛星の現在位置をスマホ圏外で把握して「現在通信できそうか」を判断する仕組み
   これらの内容を紹介します。

また、この派生物として、公開されている非公式の衛星軌道情報をもとにして「現在の」Direct to Cell接続可能エリアが分かるマップも作成しました。
https://d2c-map.muo.jp/

実用面について、2025年8月末にはau Starlink DirectがSMS/RCS送受信だけではなくデータ通信に対応しましたが、Androidではごく一部の機種でのサポートに留まる（2025年10月現在）ため、「SMSベースで何が出来るか」という思考・システム運用は依然として重要な要素です。

また、D2C接続は「スマホが地上基地局の電波を掴んでいない時だけ接続される」という特性を持ちます。人里において適切に空が見える状態の圏外を見つけるのは困難であるため、テストも難航しました。

本セッションでは、D2Cの現状を把握するための概要、AnzenMapの開発とフィールドテストから得られた通信特性、スマホアプリ開発上の注意点、周辺地形に関して考慮すべき点を紹介します。
おすすめのテストスポットと、その探し方も紹介できれば、と考えております。

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

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

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

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

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

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

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

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

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

テーマ: 文字コード、PHP、PHP_CodeSniffer

想定する参加者層: 中級者ぐらい。ソースコードの文字コードに悩まされている人。

トーク概要:
EUC-JPで書かれたPHPアプリケーションのコードベースを触ったことはあるでしょうか？
多くのツールはソースコードがUTF-8であることを前提に作られているため、そうしたアプリケーションの開発に関わっていると、まれに困ることがありました。

そのアプリケーションの開発をしているときは課題を感じつつ、自身の体感では大きな問題なく開発していました。しかし、、EUC-JPを上手く扱えないClaude Codeの登場をきっかけに、思い切ってUTF-8への移行の着手を決意。アプリケーションのコードを全てUTF-8に置き換えるべく動きました。

単にソースコードを一気にUTF-8に変更すればいいかというと、そういうわけではありません。EUC-JPのコードの中にマルチバイトの文字列リテラルがある場合、UTF-8にそのままコードを変えると動作が変わる可能性があります。

では、ソースコードにマルチバイトの文字列リテラルが「ない」状態を保証できたらどうでしょうか？

このLTでは、i18nを参考にしたUTF-8化の作戦と、PHP_CodeSnifferのカスタムルールを使った工夫、そして苦労、最後にこれからの展望ををお話しします。

同じくEUC-JPやShift_JISなど、UTF-8以外のマルチバイトエンコーディングのコードをどうにかしたいと考えている開発者の参考になれば幸いです。

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）を活用してカオスエンジニアリングとして意図的に障害を発生させ動作確認をしました。
本セッションでは、設定した可用性対策についての解説とそれを実際に検証して上手くいったことや上手くいかないことを赤裸々にお話しします。

Raspberry Pi Pico 2Wという小さなマイコンをRustで動かしながら、組込み開発の面白さを“ちょっと深く”味わっていく話をします。対象は、普段はWebやアプリを触っているけれど、マイコンにも興味がある学生さんやエンジニアの方、あるいはC言語での組込みに少し触れたことがあるけれどRustでの開発は初めて、という方です。

Raspberry Pi Pico 2Wは、1,000円ちょっとで買えるボードですが、デュアルコアCPU、Wi-Fi / Bluetooth、USB通信など、かなり本格的な機能を持っています。このトークでは、そんなPico 2WをRustで動かしてみる中で見えてきた“Rustらしい組込みの考え方”を紹介します。

トークの中では、

・Lチカ（LED点滅）のプログラムを動かす
・USB経由で、PCのGUIアプリからLEDの点滅速度を変える
・Blutooth通信を使ってスマートフォンのアプリ（Flutterで自作）からLEDの点滅速度を変える

という使い方を実物で示しながら、その中身で活躍するコードのテクニックを紹介します。単なるハードウェア制御ではなく、「PC・スマホ・マイコンをRustでつなぐ」体験を通して、Rustの良さを感じてもらえることを目標とします。

Rustで組込み開発をすると、最初は「何がそんなに違うの？」と思うかもしれません。でも、実際に書いてみると、変数の所有権や型システムが“動かないバグ”を事前に防いでくれたり、スレッドや割り込みの扱いがとても安心できる設計になっていたりします。C言語では見落としがちな部分を、Rustは“コンパイルエラー”として教えてくれるのです。これは、組込みのようなハードウェアに近い開発では特にありがたい特徴です。

このトークでは、そんなRustの「安全さ」と「気軽さ」を両立させる実践方法を、Raspberry Pi Pico 2Wという分かりやすい題材を通して紹介します。コードの細かい部分よりも、「なぜこう書くと安全なのか」「どんな考え方で設計するとRustが生きるのか」というポイントを中心にお話しします。また、途中でPico 2W特有の“ちょっと変わった構造”（PIOによる柔軟なI/O制御や、無線モジュールCYW43の動作など）にも軽く触れ、マイコンの内部構造を理解する面白さも感じてもらえるようにします。

このトークを通して、Rustを使った組込み開発が「難しそう」から「やってみたい！」に変わるきっかけを届けたいと思っています。マイコンを初めて触る方にも、CからRustへ一歩踏み出してみたい方にも、ぜひ聞いてほしい内容です。

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

昨今のITエンジニアは先人の記事にとどまらず、生成AIを活用することで学びの速度を大きく上げられるようになりました。私自身も日々の開発や調査でAIを活用しています。
ある日、ファイル判定の仕様を調べる中で「RFC」に触れる機会がありました。RFCの存在は知っていましたが、実際に読んだことはありませんでした。いざ読んでみると「ちゃんと書いてある」、「読んでいなかったから、わからなかった」。 そんな体験をしました。

このLTでは
・ RFCの概要
・ RFCの読み方
・ RFCを読むことで得た“技術的な目の深まり”
・ 生成AI時代に必要な「裏どり力」の大切さ
について、私自身の小さな発見を例にお話しします。

深い学びをしていきましょう。

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

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

■ トーク概要

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

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

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

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

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

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

【テーマ】
Webページのパスキーに対応できるかどうかを明らかにするため、WebViewのビルドに挑戦した新卒エンジニアの試行錯誤

【想定する参加者層】
・WebViewを使ったAndroidアプリ開発に携わっている方
・ブラウザ、パスキーに関心がある方
・WebView（Chromium）やカスタムROMのビルドに興味がある方
・「やってみた」系の話が好きな方

【トーク概要】
WebViewは最小限のブラウジング機能を有しますが、Chromeと異なりWebページのパスキーに対応していません。
AOSP（Android Open Source Project）のWebViewに関するコードを調べたところ、パスキーを利用可能にする「CHROME_3PP_ENABLED」定数が設定不可にされている一方、別箇所ではその定数の設定を想定しているようなコードも存在しました。
この矛盾する発見について、上司から次のように提案を受けました。 「もしこの定数を設定できるようコードを修正し、パスキーを動作させられれば、それをPoCとしてGoogleに機能拡張を提案できるかもしれない。AOSPをビルドして検証してみてはどうか？」

本セッションでは、この仮説に基づいて行った検証実験を以下の内容で共有します。
・前提１： 基本的なWebViewのパスキー実装
・前提２： パスキー実装の制約、その技術的背景
・WebViewのビルド： Azure VMを使ったビルドマシンの用意、ビルド成功までの試行錯誤
・さらなる課題： WebViewの実行環境としてのLineage OS（カスタムROM）のビルド、エミュレータの起動
・ようやくたどり着いた検証実験、その結果

本セッションはサクセスストーリーではありません。新卒入社２年目のエンジニアが情報リソースの限られた中で、いかにしてWebViewのパスキー実装に関する調査や、WebViewおよびLineage OSのビルドを行い、検証実験に至ったのか、その過程を共有します。

【テーマ】

JavaScript 3大ランタイム Node.js、Deno、Bun についてさまざまな観点から比較を行います。
さらに各ランタイムそれぞれが持つユニークな特徴なども深掘りしていきます。

【想定する参加者層】

• JavaScript / TypeScript に興味のあるすべての人（言語自体は知らなくても OK）
• Node.js、Deno、Bun。聞いたことはあるけど何が違うかよくわかっていない人

【トーク概要】

JavaScript ランタイムといえば何を思い浮かべますか？
一番メジャーなのは Node.js ですが、Deno や Bun を聞いたことがある方も多いかもしれません。

「セキュリティや Web 標準は Deno」「高速性は Bun」といった大きな特徴ではよく比較されるものの、各ランタイムを取り巻くエコシステムや、開発環境における違いなど細かい部分についてはあまり知らない方も多いと思います。

本発表では、JS エンジンや速度面はもちろん、ランタイム自体の開発言語やエコシステム、開発環境などにも焦点を当てて、各ランタイムの比較・ユニークな特徴を紹介したいと思います！

JS を知らない方には、JS ランタイムについて知ってもらい、
Node.js を使ってきた方には、Deno や Bun の違いを知ってもらい、
3つをすでに知っている方にも、さらにディープな違いを知ってもらえる内容です！

30分後、きっとあなたの ”推しランタイム” が見つかりますよ

・テーマ
オンプレミス脳からクラウドネイティブ脳への「思考のリファクタリング」を、料理のレシピのように4つのステップで話します。現場の失敗談と成功体験を材料として混ぜ込み、クラウド移行の悩みを解消するレシピを提供します。
さらに、「思考のリファクタリング」にAIが与える可能性を、実験的な「隠し味」として紹介します。

・想定する参加者層

• オンプレミスレシピの呪縛から解放されたいエンジニア
• クラウド移行で迷子になっている方
• AIによるアレンジで開発レシピを革新してみたい技術者

・トーク概要
従来のオンプレミス環境で培われた設計思想から、クラウドネイティブな考え方への転換を、4つのステップとして体系化してお話します。技術的な詳細よりも、思考プロセスの変化に焦点を当てることで、参加者の方が持ち帰って実践できる考え方やアプローチを中心にお話しします。クラウドネイティブへの転換に悩む方々にとって、明日からの取り組みのヒントとなるような内容を目指します。
また、AI技術を使って設計プロセスの効率化や品質向上にどの程度貢献できるのかを実際に試してみた結果を紹介します。成功例だけでなく、期待通りにいかなかった事例も含めて、現実的な視点でAI活用の可能性と限界について考察します。

オンプレ思考からクラウドネイティブ思考への転換レシピ
～AI活用のスパイスを添えて～

• ステップ１　システム分離への思考転換
• ステップ２　データ戦略の思考転換
• ステップ３　処理方式の思考転換
• ステップ４　障害対応の思考転換
• アレンジ　　AI活用の可能性

共同スピーカー:加藤寛士

よりパワフルで柔軟な UI を実現する、エキサイティングな Web の機能が、今年も多く登場しました。

CSS Containment、Value Processing、UA による DOM のクローン、Top Layer、そしてレンダリングエンジンにおける最適化。
針の穴に糸を通すような仕様と実装の工夫が積み重ねられ、不可能だったことを可能にする基盤が今、整ってきました。
その結果、ずっと絵に描いたモチだと思っていた機能が、気づけばポンっと実体化した。
それが、 2025 年の Web UI です。
参考：https://blog.sakupi01.com/dev/articles/2025-css-advent-25

そんな今年の Web UI を取り巻く HTML&CSS&JS 機能のアップデートと、今後登場が期待される機能、そして"Primitive 性" に焦点を当てた Web UI 進化の方向性をご紹介します。

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

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

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

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

VS Codeのオープンな文化と、IBMが推進するエンタープライズ開発者体験(DX)。その交差点には、"ギーク的思考"と"企業的スケール"を融合する挑戦があります。本セッションでは、今日現在、IBMが早期アクセス提供中のIBM Bob （オープンソース版のVS Code互換のIDE） 概要や、IBM、Red Hat、HashiCorpが提供する拡張機能を用いたコンテナアプリ開発デモ実演を交えてお届けします。

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

2025年後半は、ランサムウェア感染、データ損害、クラウド障害という話題がIT業界を震撼させました。
クラウドはスケーラブルな一方で、障害・攻撃・設定ミスなどのリスクを正しく評価できていないことは問題です。いま求められているのは、単なる高可用性ではなく「レジリエンス＝回復力」を備えた設計です。本セッションでは、マルチクラウド（AWS/Azure/GCP/OCI）におけるレジリエンス可視化について考え、システム障害・サイバー攻撃の両面から耐性を強化するアプローチを解説します。四大クラウドにおけるベストプラクティス比較も行い、設計・評価・運用を一体化した継続的レジリエンス向上の手法を紹介します。
想定対象は、クラウドアーキテクト、セキュリティ担当者、システム企画担当。中級者以上を主な対象とします。

【テーマ】
生成AI (Claude Code) を活用した開発リードタイムの劇的な短縮。工数不足で放置されがちだった施策を高速で実行し、アイデアをすぐに形にして検証する手法と、それにより実現したチーム間の信頼関係の向上について扱います。

【想定する参加者層】
・ソフトウェアに関する新規事業や価値検証に携わっているエンジニア、プロダクトオーナー、デザイナー、マネージャーなど
・生成AIを具体的な現場の課題解決に役立てたいと考えている全ての方

【トーク概要】
あなたのチームで「やりたいけど時間がない」と諦めているアイデアはありませんか？
私たちの開発現場も同じ悩みを抱えていました。ビジネスサイドからの要望や、デザイナーによる良いデザインの修正など、事業にとって素晴らしい施策があると分かっていても、他に優先すべきタスクが多く、工数不足からなかなか着手できない状況でした。
このまま対応を先延ばしにすれば、プロダクトはユーザーの離脱を防げないままとなり、さらに「せっかくの提案が開発に回してもらえない」という不満から、チーム間の信頼関係が損なわれてしまうというリスクがありました。

「やりたいけど時間がない」。そんな理由で見送られていた施策を、生成AI Claude Codeの活用によって一変させました。
本セッションでは、PR自動生成ワークフローを構築し、アイデアを即座に実装・検証できるようにした実践事例を紹介します。

この仕組みにより、1週間以上かかっていたデザイン・開発タスクを1時間以内で完了させることが可能になり、チーム間の信頼関係やモチベーションも向上しました。
「AIがコードを書く」だけではなく、「チームがより良い形で連携する」ための仕組みとしてClaude Codeをどう活かしたのか。
現場での課題感から、実際の構築プロセス、そして得られた変化までをリアルにお伝えします。
生成AIを使って“やりたいことを諦めない”開発サイクルを作りたい方におすすめのセッションです。