「本当にメモリ管理は難しすぎてわからなぁぁぁい‼︎」と思っているみなさん！
メモリ管理への理解を深めるために、その発展の歴史を学んでみませんか？

たった一つのメモリ確保処理を見直しただけでCPU使用率を57%、メモリ使用量を99%も削減できた例があるほど、メモリ管理の知識はアプリケーションのパフォーマンス向上に直結します。
しかしメモリ管理に関する教材の多くは、ガベージコレクションの具体的なアルゴリズムやコンパイラ内部のメモリ構造といった複雑な機能が「どのように(How)」動作するのかに焦点を当てており、初学者向けとは言えません。
本来「How」を理解するためには、「なぜ(Why)」その機能が必要とされ、「何を(What)」実現するかの理解が不可欠です。
そうした土台がないまま「How」の議論を追うのは困難でしょう。

ヒープ、スタック、ガベージコレクションのような仕組みは、プログラミング言語におけるデータ管理をわかりやすくするために進化してきたものです。
動機を知ることでこれらの仕組みをより深く理解し、メモリ管理を語れるエンジニアになりましょう！
本セッションでは、特にGo言語のメモリ管理機能を取り上げてその進化の軌跡を紐解きつつ、発展的なメモリ管理の知識を修得するにあたって強固な土台となる知識を提供します。

[対象者]

• メモリ管理という言葉すら知らない方
• メモリ管理について学びたいが、理解に苦しんでいる方

[話すこと]
以下のメモリ管理機能がなぜ必要とされ、何を実現するかについて、それぞれの相関関係を強調しながら話します。

• ヒープ・スタックのメモリ構造
• GC (ガベージコレクション)
• ヒープエスケープ・エスケープ解析 (Go特有)
• スタックコピーによる可変サイズスタック (Go特有)
• メモリ管理の知識がプロダクション環境のパフォーマンスに大きな影響を与えた例とその解説

[話さないこと]
メモリ管理機能の詳細な処理ロジックや実装

[アウトライン]

1. はじめに (5分)
   • 自己紹介
   • メモリ管理はパフォーマンス向上のため非常に重要
     • たった1か所のメモリ確保処理の見直しで、CPU使用率が57%、メモリ使用量が99%も削減された事例が存在
   • メモリ管理に関するセッションは難しい
     • 実装の詳細やロジック (How) に関する技術的な内容が多い
     • 処理の抽象的な解釈や、必要性に対する理解 (What, Why) が不足している
   • Goの高度なメモリ管理を学ぶには、幅広い機能の基礎知識が必要
     • 各機能が「何を」して「なぜ」あるのかを理解することで初めて習得できる
     • 「How」の前に「What」と「Why」に焦点を当てるのが、修得の最短ルート
2. メモリとは何か / 古のメモリ管理 (2分)
   • メモリ＝プロセスの一時的なデータ保存領域
   • メモリへの直接的なデータ挿入 (アセンブリのデータ管理)
3. 変数の誕生 / スタックとヒープ (5分)
   • 【課題】人間が全てのメモリアドレスを把握する必要がある
   • 高級プログラミング言語の登場
     • 変数＝データの抽象化
     • 人間はアドレスを気にしなくてよくなるが、言語側が代わりにアドレスを管理する必要がある
   • スタックの発明
     • 関数呼び出しのネスト構造や変数スコープをメモリ空間上でうまく表現できる
   • スタックの図解説明
     • 【例】Goでの変数定義や関数呼び出し
   • 直接的な挿入も可能にする、ヒープとポインタ
     • 大きいデータ・サイズ不定のデータ
     • 関数をまたいで利用されるデータ
     • 【例】C言語のmalloc / free
4. ヒープの自動管理 / ガベージコレクション (2分)
   • 【課題】ヒープ上の使い終わったデータは人間が削除する必要がある
     • メモリリークやOOM Killのリスクが高まる
   • ガベージコレクション (GC)
     • ヒープ上の未使用データを検出
     • 未使用データを自動的に削除
5. Goのヒープエスケープ (6分)
   • 【課題】ヒープに大量のデータを置くとGCの負荷が高くなる
     • 【例】構造体や配列をすべてヒープに置く→半分以上の変数がGC対象に
   • ヒープエスケープの導入
     • できるだけスタックにデータを置く
     • 型で判断するのではなく、必要なものだけヒープへ「逃がす」
   • エスケープ解析
     • ヒープへ逃すか決まるのは、実行時ではなくビルドの段階
     • どの変数がエスケープするか見るためのビルドオプションがある
   • ゼロアロケーションライブラリ
     • 関数内でヒープに置かれるデータを一切出さないパッケージ
     • 非常に効率的で、基本的にパフォーマンスが向上する
     • 実装はやや複雑で、コードリーディングが難しい
6. スタックコピーによる、可変サイズスタック (4分)
   • 【課題】通常の言語ではスタックには上限が設けられ、スタックオーバーフローが起きる
   • あらかじめ大きなスタックを確保しておくか…？
   • 【課題】常に大きなスタックを持つと、ヒープが小さくなって不便
   • 可変サイズのスタックにより、効率的なメモリ利用を実現
     • セグメント化スタック (旧実装)
     • スタックコピー (現行の実装)
7. はじめに紹介した事例の解説 (4分)
   • 参考: https://developers.cyberagent.co.jp/blog/archives/54653/
   • フィルタリング関数が呼び出されるたびにヒープ上にスライスを1つ作成
     • このヒープに置かれた変数がボトルネックになっていた
   • 既存のスライスを利用することで割り当てを無くし、メモリ使用量99%削減
     • たった1つのアロケーションがパフォーマンスに大きく影響することを示している
   • CPU使用率57%削減
     • アロケーションとGCコストの削減の合計
8. まとめ (2分)
   • 今回のセッションはあくまで出発点
   • 他のセッションや資料で、各機能を深堀りしてみよう！
9. 次に見るべきおすすめの過去セッション紹介 (時間が余ったら)
   • このセッションで得た基礎知識を土台に、次のステップに進もう！
   • ヒープエスケープとエスケープ解析: "Escape Analysis in Go: Understanding and Optimizing Memory Allocation" - Go Conference 2023 Online
   • GCの条件: "Go1.19から始めるGCのチューニング方法" - Go Conference 2023 Online
   • pprofを使ったパフォーマンスチューニング: "Memory Management in Go: The good, the bad and the ugly" - GopherCon UK 2023
   • 【発展】ヒープ・スタックの、OSレベルでの割り当て: "Goのメモリ管理" - Go Conference 2023 Online
   • 並行処理に対するメモリ設計 (memory model): "よくわかるThe Go Memory Model - 行間を図解で埋め尽くす" - Go Conference 2023 Online

概要

ソフトウェア設計を学び始めたとき、設計原則として「責務を分けよう」「疎結合にしよう」と言われても、実際にどのような設計・実装をすればよいのか、具体的なイメージが湧きづらいと感じたことはありませんか？本セッションは、マインスイーパという身近なゲームを題材に、具体的な設計とコードを通じて、これらの設計原則への解像度を高める体験を提供します。

マインスイーパには、セルやその状態、ボード（座標平面）、プレイヤー操作、難易度など様々な概念が存在し、設計を思考しながら学ぶ題材として適切なゲームであると考えています。セルの開封のように単純なロジックに見えても、「セルは状態を持つのか？」「セルは座標平面に依存するのか？」「セルからその近傍のセルを隠蔽するべきなのか？」など考慮点が多く、設計次第でコードの拡張性や可読性が大きく変わります。

本セッションでは、そんなマインスイーパをRubyによる純粋なオブジェクト指向で設計していきたいと思います。主な設計トピックは下記の通りです。

• 責務の境界線を定義し、情報隠蔽をする
• 具体よりも抽象的なインターフェースへ依存して、疎結合にする
• シンプルなインターフェースで強力な機能を提供する”深い”モジュールを目指す

これから設計を学びたい初学者や、日々の業務で「なんとなく設計している」中級者に向けて、責務と疎結合への解像度を高め、もう一歩深く設計を理解するヒントを持ち帰れるセッションを目指します。

詳細

対象とするターゲット

• 初学者
  • AIに設計を任せ切ってしまっている方
  • 設計の指針を持てていない方
  • 設計の技術書籍を読んで学んだが、あまりピンと来ていない方
• 中級者
  • 設計の技術書籍を読んで学んだが、より実践的に学びたい方
  • Ruby on Railsなどのフレームワークに従っての設計はできるが、そのレールからはみ出た設計に自信のない方
  • GoFのデザインパターンなどを学んだが、暗記になってしまいその本質が掴めていない方

トーク構成

• マインスイーパとは(3min)
  • ルール
• ER図の全体像(2min)
  • クラス図
• セル(3-4min)
  • 責務の境界線を定義し、情報隠蔽をする
    • 座標平面に依存する？
    • 状態を露出させる？
• セルの近傍(4min)
  • 具体よりも抽象的なインターフェースへ依存して、疎結合にする
• グリッド(3min)
  • 二次元配列を隠蔽する
• グリッドのファクトリ(3min)
  • シンプルなインターフェースで強力な機能を提供する”深い”モジュールを目指す
    • 複雑なロジックは隠蔽し、シンプルなインターフェースでグリッドを作成するインターフェース
    • シンプルファクトリパターン
• マインスイーパークラス(3min)
  • 多数のモジュールを利用するメインモジュール
• テスト容易性(3min)

このトークの意義

昨今のAI時代において、私は初学者がAIに取って代わられないために重要なのは「設計」であると考えています。 しかし同時に、初学者がその設計力を育む経験を得づらい環境に置かれていることを危惧しています。

インターフェースを定める「設計」と、その実体である「実装」を比較したとき、事業へのインパクトがより大きいのは明らかに「設計」です。実装は情報が適切に隠蔽され、副作用がなければ容易に差し替え可能ですが、設計は他のモジュールにも波及し、システム全体の構造を左右します。

しかし近年、AIネイティブ世代の初学者が、この重要な「設計」までもAIに全面的に委ねてしまう傾向があると感じています。答えが定まらない中でも試行錯誤し、概念を言語化しながら思考を深める、そうした経験を経ずに、AIに舵を預けてしまっているのです。

私はその原因を、初学者が「設計のポイント」や「思考の取っかかり」を持たないことにあると考えています。

本トークは、そうした初学者の方々に対し、設計を自ら考え始めるための“思考の種”を提供するものです。設計入門の資料は数多くありますが、本トークでは具体的な事例と思考プロセスの両面から、より実践的に「設計」を掘り下げます。

【テーマ】
・ Amazon Simple Email Service（以下「Amazon SES」）でのメール受信についての話

【想定する参加者層】
・ Amazon Web Service（AWS）を扱っている方（主に業務で）
・ Amazon SESを扱った経験、およびAmazon SESでのメール受信の経験は不問です。（経験がない方でも十分理解できる内容となっています）

【トーク概要】
AWSでメールを扱う際にAmazon Simple Email Service（以下「Amazon SES」）を使用することが多いと思います。
「メール送信は経験があるが、受信についてはなかなか扱うことが少ない」という方もいるかもしれませんが、2023年に東京リージョンでもAmazon SESがメール受信に対応したことで、これからAmazon SESでのメール受信に対応するケースも増えてくると思います。

そして受信メールはAmazon SNS/AWS Lambda/Amazon S3で扱えるのですが、これらサービスごとの仕様・制約が大きく異なっており、ビジネスアプリなどで受信メールを扱うのはなかなか一筋縄ではいかないのも事実です。

そこでこのセッションでは、実際に私がAmazon SESでのメール受信をビジネスアプリに組み込んだ経験から
・ Amazon SESでのメールの受信方法
・ Amazon SNS/AWS Lambda/Amazon S3それぞれで受信メールを扱う際の注意点
・どういうケースでどの手法を選択するのが良いのか

などについてお話したいと思います。

【セッションゴール】
・ Amazon SESについて、「受信メールの受信方法」および「受信メールを扱うサービスごとの仕様・制約」を理解できるようになる
・ ビジネスアプリにAmazon SESでのメール受信を組み込む際に「どういう点に気を付けた上で、どういうケースでどの手法を選択するのかが良いか」がある程度理解できるようになる

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

概要

近年、アクセシビリティの重要性が高まってきています。普段携わっているWebサービスやプロダクトでアクセシビリティのテストを自動で行うツールはいくつかあります。その中でもAxeはとても有名なツールの一つです。

本セッションでは、Axeのコアエンジンであるaxe-coreの中でアクセシビリティの自動テストがどのように行われているのかを、具体的なJavaScriptのコードを追いながら確認します。

アクセシビリティのテストは100%自動で検出できるものではありません。しかし、AIの登場によってできることも増えてきました。axe-coreの処理を一緒に探索した後に、自動テストでは何ができて何ができないのかについても考察します。アクセシビリティの理解を一緒に深めていきましょう！

こんな人に聴いてほしい

• アクセシビリティに興味がある方
• フロントエンドエンジニアの方
• HTMLで一度でもコーディングしたことがある方

"Why do you need End-to-end Encryption in Ruby? Because..."

国際情勢の緊張が高まる現在、メッセージングのエンドツーエンド暗号化技術はかつてなく重要性が高まっています。
Eメールはその仕組み上エンドツーエンドでの暗号化を持たず、どうしても暗号化を実現しようと思うとS/MIMEなどの高価な仕組みやPGPなどの「オタクしか使っていない」仕組みに頼るしかありません。一方で我々が日常的に利用しているメッセージングアプリにはエンドツーエンド暗号化の仕組みが搭載されていますがベンダーごとに個別の方式で実装されており相互運用性を持ちません。
これらを解決すべくIETFで標準化が行われているMessaging Layer Securityという相互運用可能な鍵交換の技術があります。
現在私はMessaging Layer Security Protocol (RFC 9420)のRuby実装を進めています。この実装を通してMessaging Layer Securityの仕組みを解説することで、皆さんが日常使っているメッセージングアプリのセキュリティについて安心感を持つことができるようになるでしょう。

技術的には以下の内容をカバーする予定です:

• 求めるセキュリティ性質: Forward SecrecyとPost-Compromise Security
• 2人でこれを実現するのは容易だが3人以上の場合は難しい
• MLSの構成要素: Key Schedule, Secret Tree, TreeKEM
• 進行中のRuby実装について

ハッシュ化、共通鍵暗号、公開鍵暗号の概念程度の暗号技術の知識をある程度前提としますが、トークの内容自体はセキュリティに興味のある全技術者向けの内容です。

テーマ

Monorepoによるパッケージ境界と依存の再設計

想定する参加者層

フロントエンドのMonorepo移行を検討している中級者

トーク概要

複数のサービスを運用する中で、コードの重複、責務の曖昧さ、変更時の影響範囲の広さに悩んでいませんか？
本セッションでは、4つのフロントエンドアプリケーションを1つのMonorepoに統合した事例をもとに、統合を起点に進めたリアーキテクトを紹介します。
パッケージの責務境界を見直し、共通コンポーネントと依存関係を整理することで、開発体験を改善しました。
Monorepoへの統合プロセスとツール選定から、責務分離を軸にしたアーキテクチャ再設計の手法まで、実践的なヒントをお届けします！

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

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

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

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

みなさん、アウトプットしてますか？ブログ執筆やカンファレンス登壇など、エンジニアにはアウトプットの機会が他の業種に比べて多くあると思います。情報は発信する人の周りに集まる、という言葉もあるように、アウトプットをすることによる良い効果は多く存在します。

とはいえ、世の中の全エンジニアがアウトプットをすべきかと言われると、それはまた違うと思います。他人に強いられてやるものではないし、好きじゃないと続かない行為だと思います。しかし、ハマる人には超ハマります。

私は今までで約100本のブログ記事の執筆と14回の登壇をしてきました。アウトプットに対する私のモチベーションとアウトプットがもたらす良い効果についてお話しします。

生成AIがテストを自動作成し始めた際、実装＝テストで実装され潜在的不具合を含んだまま、とりあえずテストが存在するみたいな状況が多くなってきたのではないでしょうか？
今一度単体テスト/結合テストについて考えて、生成AIが成果を発揮するための方法を一緒に考えましょう。

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

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

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

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

エンジニアは技術的負債、レガシーコードの刷新、そしてリポジトリの統合といった、避けては通れない大規模なリファクタリング課題に直面します。

私はMOSHというクリエイター向けプラットフォームの開発において、8年近く運用されてきた（自らが積み上げた）負債「旧リポジトリ」の撲滅という大きな挑戦に直面しました。

膨大なコード量、複雑に絡み合った依存関係、そして不足したドキュメント。
従来の手法では数年かかると思われた作業を、AI（Claude + Cursor）とのペアプログラミングによって約100日で完遂しました。

この取り組みを通じて、「AIは単なる補助ツールではなく、最高のペアプログラミングパートナーであり、心の友である」という確信を得ました。

本セッションでは、AIの活用術ではなく、私がなぜ「旧リポジトリからもう逃げない」と決めたのか。

AIという存在がそれを可能にしてくれたわけですが、なぜその意思決定をすることができたのか。

10年近く前のコードに対する私の恐怖をどう変えたのか。

実コードと実データ、そして率直な失敗談を交えて語ります。

レガシーコードから目を背けてきたエンジニア、技術的負債の返済を諦めかけているチーム、そしてAIが開発組織の意思決定をどう変えるのか知りたいリーダーにとって、明日からの判断基準を変える内容を提供します。

UIライブラリは入れ替わりが早い一方で導入後はコンポーネント構造やテーマ設計・CSSトークン・A11y実装などがライブラリ側で固定化されやすく、結果としてロックインが生じやすいです。
本セッションではその前提を踏まえつつ、いま shadcn-ui をどのように評価し、ロックイン等のリスクと向き合うべきなのかを考えます。

発表内容

• UIライブラリのこれまで、選定基準など
• shadcn-uiを選ぶ理由と評価ポイント
  • コピー所有でロックイン低減、RadixベースのA11y、他ライブラリとの親和性
• 現場で見えた限界と対処
  • classNameによる意図せぬ拡張、改修時のルールの整備

エンジニアは新規技術の採用や組織課題など、さまざまな問題に直面します。

私は LINE API を利用した新規プロダクト開発や技術組織の拡大に伴う課題に直面した際、LINE Developers Community や EM Oasis といったコミュニティに参加することで活路を見出してきました。
そして、活動は課題解決に留まらず、現在は LINE API Expert としての初学者支援や EM Oasis の運営という形で、コミュニティへ貢献する活動へと繋がっています。

これらの経験は、「コミュニティがエンジニアの成長と課題解決に極めて有効である」という確信を与えてくれました。

本セッションでは、この実体験に基づき、以下の実践的なプロセスと技術を解説します。

• 課題発生から解決の糸口を見つけるまでのプロセス
• コミュニティ内で信頼を得て、より深い情報を得るための技術
• インプットをアウトプットに繋げ、自身の専門性を確立する方法

私がなぜ技術的な課題に直面した際にコミュニティに参加をするのか、私はなぜ課題が解決した今でもコミュニティ活動を続けているのか、LINE API Expert や EM Oasis 運営の活動を通して何を感じているのか、実体験を元にコミュニティ活動の素晴らしさを語りたいと考えています！

技術コミュニティへの参加を検討している方、また既に参加しているがより効果的に活用したい方にとって、具体的な行動指針となる内容を提供します。

私たちは常日頃からありとあらゆるエラーメッセージと向き合っています。ソフトウェアエンジニアに限った話で言えば、コンパイラや言語処理系のエラーメッセージは最も頻繁に向き合うインターフェースの一つであり、毎日眺め、頭を悩ませていることでしょう。
そういった中で、Rustコンパイラ(rustc)はわかりやすいエラーメッセージ(diagnostics)を出すことに注力しています。そして、そのエラーメッセージは一つひとつが丁寧に設計され、コードレビューで磨かれ、ユーザーフィードバックにより改善されています。

わかりやすいエラーメッセージとはどういったものなのか。どのように実装、改善されているのか。どのように開発者体験、あるいはユーザー体験を向上させているのか。
このセッションではRustコンパイラへのコントリビューションで得た経験をもとにして、Rustコンパイラで行われているエラーメッセージの実装・改善活動を例に、わかりやすいエラーメッセージのあり方などについてご紹介します。

ここではRustやコンパイラを題材としますが、これらへの深い造詣は必要ありません。
Rustコンパイラの開発がどのように行われているのかといったOSS開発に関する知見だけでなく、日頃の開発においてエラーメッセージを通して開発者・ユーザー体験を向上させるテクニックや考え方をご紹介できる内容を目指します。

メンテナンスされ続けるStorybook運用を目標に、設計と運用の要点を共有します。
Coding Agentに「作成・更新・整理」といった負荷の高い作業を委ね、速度と品質の両立をねらう取り組みを紹介します。
本テーマは実装の細部ではなく、意思決定の拠り所となる原則にフォーカスします。

発表内容

• AIに委ねる範囲・人が握る範囲の定義（境界設計・責務分離）
• 実装ガイドラインのガードレール設計
  • ファイル配置・命名、Storyの分割設計、バリエーションの整理、Controlの方針
• 小さく導入してから段階的に適用領域を拡大する進め方
• 運用コストの削減、変更の見通しとレビュー品質の維持、チームの開発速度確保

YoY300%成長のクリエイター向けオールインワンプラットフォームの成長に伴い、複数プロダクトでの通知機能共通化が急務となりました。
メール・LINE・アプリ内通知を統一基盤として提供しつつ、将来の事業拡大を見据えた拡張性と、ミッションクリティカルな通知の確実な配信を両立する必要がありました。

本セッションでは最終的なインフラ・アーキテクチャ構成を共有したのち、その設計の過程でどのような制約や判断軸の中で候補として上がった技術について触れてなぜそれを採用しなかったのかという生々しい設計のリアル話をお伝えるすることが出来ます。
作成した成果物やその結果を伝えるセッションではなく、そこに至る技術的な判断や思考をみなさんに共有して今後の設計に役立つようなものにしたいと考えております！

主な内容

マルチプロダクト戦略での基盤設計思想

• なぜ通知を共通化したのか、将来を見据えた設計判断
• 今後様々なプロダクトが利用することを考慮した責務の分離とインターフェイスの設計についてどう考えたか

技術スタック選定

• StepFunctions vs SQS/SNS vs Fluent での可用性・柔軟性・一覧性との比較
• DynamoDB vs RDS vs Redis - 冪等性におけるデータストアの検討
• TypeScript統一による認知負荷軽減の判断

冪等性設計の技術判断

• DynamoDB条件付き書き込みによる排他制御の選択理由

聴講者が得られる価値

• マルチプロダクト環境での共通基盤設計における技術選定の判断基準
• 高可用性システムでの冪等性実装における具体的な技術選択肢と評価軸
• 将来の拡張性と現在の要件のバランスを取る設計判断の考え方

PoC段階では新技術を使って、楽しいですが本番運用するにはPoCとは違って考えることがたくさんあります。
AI関連の話が乱雑になっていてたくさんの会社でPoCを開始していると思うので、決め手となるのは本番運用に載せたときのメリットデメリットの話だとおもっていますので、今一度基本に戻ってはいかがでしょうか？っということで話そうと思います。

■概要
生成AIの台頭により、GitHub Copilot（GHCP）の企業活用が急増しています。Copilotをセキュアかつ組織統制下で活かすには、その基盤となる GitHub Enterprise Cloud（GHEC）の整備が実質的に必須です。
現場では「試用 → 本番」や「通常アカウント → EMU（Enterprise Managed Users）」への段階移行が増加中。本セッションでは、実案件およびコミュニティでの知見（※GitHub Stars受賞者としての最新動向も踏まえ）から、GEI / GitHub Migration Analyzer / gh-repo-stats等の実運用ノウハウを整理します。
“移せる／移せない”の線引き、ガバナンスを崩さないCopilot活用の判断軸、スモールスタートの実例まで、明日から使えるチェックリストとともに解説します。

■こんな人におすすめ
・企業内でGitHub導入・統合・再編をリードするDevOps／プラットフォーム担当
・既存GitHub資産を落とさず移行したい技術責任者・PM
・Copilot導入を見据え、まず基盤とガバナンスを整えたい方

■前提知識
・GitHub Enterpriseの基本概念（Org／Repo／Teams／Policies）の基礎理解（薄くでOK）
・IaCやCI/CDの一般知識があると理解が早い（なくても可）

■持ち帰れること
・「計画 → 解析 → 検証 → 本番」の実務フレーム＆チェックリスト
・GEI／Migration Analyzer／gh-repo-statsの使いどころと限界
・“移せないもの”の代表例と代替策（再作成・自動化・割り切りの判断）
・EMU移行時のセキュリティ／ガバナンス観点（ID、監査、ポリシー）の勘所

■発表者プロフィール（短）
外資系コンサルのDevOpsエンジニア／マネージャー。GitHub Stars。GitHub Enterprise／EMUの導入・統合・運用、Copilot展開、監査ログ連携やセキュリティ統制の実装支援に従事。

『薬屋のひとりごと』（以下「薬屋」）に出てくる主人公・猫猫（まおまお）の問題解決の進め方をヒントに、システム障害対応を分かりやすく整理したものです。

薬屋は、薬の知識を持つ少女が後宮で起きる毒や病の理由を探る物語です。やっていることは「状態を観察→原因候補を考える→確かめる→再発を防ぐ」で、これはまさにシステム障害対応と同じ流れです。
猫猫のやり方に当てはめてシステム障害を解決に導く流れを楽しく学んでいきましょう。

なお、原著作物のストーリーや独自文章などに配慮して特定のシーンは扱いません。アニメなどを視聴した前提での話とさせていただきます。