仮想空間の日常

▲ 【Day 26】AIエージェント併用ケーススタディ（実務応用） 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 25では、急な仕様変更や機能リリース順序の入れ替えにスマートに対応する「チェリーピック（git cherry-pick）」の実践テクニックを学びました。 本日のDay 26は、第5部「開発フェーズ別・現場ケーススタディ」の集大成として、現代のソフトウェア開発を根底から変革しつつある最先端テーマ—— 【AIエージェントを活用したケーススタディ自動実行（Issue-to-PR）】 を徹底解説します！ いま、ソフトウェア開発の現場では Google Antigravity や Claude Code といった自律型AIコーディングエージェントの導入が急速に進んでいます。 かつてエンジニアが手作業で行っていた「チケット確認・ブランチ作成・ソース調査・コード修正・単体テスト実行・プルリクエスト作成」という一連の定型業務は、いまや 『Issue #101 のバグ修正用ブランチを切り、修正してPRを作って』 とプロンプトで一括指示するだけで、AIがターミナルとGitを操作して自律的に完走できるようになりました。 「AIにコードを書かせたら、思わぬバグが混入したりブランチが壊れたりしないのか？」「Gitのブランチ戦略やテスト自動化とどう組み合わせれば安全なのか？」と疑問に思う方も多いでしょう。 本日は、C#現場で頻発する NullReferenceException の障害Issueを題材に、AIエージェントによる「自律ブランチ作成からプルリク起票まで」の完全シミュレーションをお見せします！ さらに、AIが90%の定型作業を高速代行する時代において、 人間のエンジニアが担うべき『最終コードレビューとマージ承認の絶対原則』 まで、実践的なプロの技術を分かりやすくお伝えします！ ...

▲ Day 28: ボリューム（Named Volume）によるSQL Serverデータの安全な永続化 🐳 「物理サーバーのDドライブのように、SQL ServerのDBレコードを安全に守り抜くにはどうすればいいのか？」 前回のDay 27では、Dockerコンテナが「いつでも使い捨てて作り直せるステートレスなプロセス」であり、何も設定せずにデータを書き込むとコンテナ破棄（ docker compose down ）と同時にデータが消滅する原理を学びました。 では、業務システムの要である SQL Server のデータベース（.mdf / .ldf） は、具体的にどのように保護すべきなのでしょうか？ その答えが、Dockerが推奨する 「名前付きボリューム（Named Volume）」 です！ 本講義では、SQL Server公式Linuxコンテナのデータ格納構造（ /var/opt/mssql/data ）を解剖し、 docker-compose.yml での正しいボリューム宣言、一時コンテナを用いた安全バックアップ＆リストア手法、そしてC# / Entity Framework Core開発における超快適なデータ保護サイクルを徹底解説します！ INDEX 本日の講義カリキュラム 第1章: 名前付きボリューム（Named Volume）の基本と仕組み 〜ホスト管理領域の完全隔離〜 第2章: SQL Server Linuxコンテナのデータ格納構造（/var/opt/mssql/data の秘密） 第3章: docker-compose.yml での volumes 定義構文...

▲ 【Day 25】仕様変更・機能のリリース順序入れ替え（チェリーピック） 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 24では、本番環境の緊急障害に対応する「Hotfix」の完全手順と、developへのマージバックによる先祖返り防止サイクルを学びました。 本日のDay 25は、現場のエンジニアなら誰しも一度は遭遇する波乱のシチュエーション—— 【仕様変更・機能のリリース順序入れ替え（チェリーピック）】 を徹底解説します！ 「次の定期リリースに向けて、機能A（AIレコメンド機能）と機能B（請求書PDF決済機能）を並行して開発していたが、突然クライアントや経営陣から『機能Aは仕様再検討で来月に延期！でも機能Bだけは契約上、明日のリリースにどうしても間に合わせてほしい！』と頼まれた……」 このような「リリース順序の逆転」や「特定機能だけの先行リリース」は、アジャイル開発でも受託開発でも日常茶飯事です。 Subversion (SVN) や Visual SourceSafe (VSS) で開発していた時代、これに対応するのはまさに悪夢でした。トランク（trunk）に時系列でコミットされた変更の中から、関係するファイル差分を手作業で洗い出し、別ブランチへ手動でコピペしてビルドする「手動リビジョンマージ」を行っていました。その結果、未完成な機能Aのコードが誤って混入したり、コピペ漏れによるコンパイルエラーや実行時例外が多発していました。 しかしGitなら、 「git cherry-pick」 という極めて強力な武器があります！ Gitのコミットは、独立した変更パッチとして管理されています。そのため、木になっている熟した美味しいさくらんぼをスプーンで摘まみ取るように、 「機能Bに関する特定のコミットだけ」 を狙い撃ちして、安全にリリースブランチや本番ブランチへ移植・複製することができます！ ...

▲ Day 27: コンテナを破棄するとデータが消える！？ データの永続化の原理 🐳 「コンテナを再ビルドしたら、テスト登録したDBレコードや画像が全部消えた…！？」と焦ったことはありませんか？ Windows Server、Hyper-V、VMwareなどで長年インフラや社内システムを構築してきたエンジニアにとって、「仮想マシンのCドライブやDドライブに保存したファイルは、OSを再起動してもマシンを作り直さない限りそのまま残る」というのが当たり前の常識でした。 しかしDockerのコンテナは、 「いつでも破棄して作り直せるエフェメラル（使い捨て）なプロセス」 として設計されています。そのため、何も設定せずにコンテナ内でデータベースを動かしたり、ユーザーがアップロードしたファイルを保存したりすると、コンテナを破棄（ docker rm や docker compose down ）した瞬間に、 すべてのデータが宇宙の彼方へ消滅 してしまいます。 本講義では、なぜコンテナ内のデータが消えるのかという内部アーキテクチャ（OverlayFS / 書き込み可能レイヤー）を解き明かし、データをホストOS側へ安全に逃がして永続化する 「ボリューム（Volume）」と「バインドマウント（Bind Mount）」の原理・使い分け・C#設計パターン を完全マスターします！ INDEX 本日の講義カリキュラム 第1章: なぜコンテナを消すとデータが消えるのか？ 〜OverlayFSと書き込み可能レイヤーの構造〜 第2章: コンテナの「ステートレス（無状態）原則」とデータの寿命管理 第3章: 永続化の2大手法「ボリューム（Volume...