どうも、マイクです。おはようございます。
七月七日、火曜日の朝七時を回りました。「zenncast」今日も元気に始めていきましょう。
この時間は、技術者のみなさんの朝のお供に、Zennで今トレンドになっている記事をまとめてご紹介していきます。
今日はぜんぶで五本、気になる記事をピックアップしてきました。
それぞれ内容みっちりなので、コーヒーでも飲みながらゆるっと聞いてみてください。
まず一本目。
きょう最初に紹介するのは、「Cシャープ」と「ドットネットてん」、つまり .NET Ten ですね。
この組み合わせがどこまで使えるのか、ものすごく広い守備範囲を紹介している記事です。
内容としては、Cシャープと .NET Ten を使うと、まず基本のコンソールツール、それから Web アプリや Web API。
さらに、Blazor を使った SPA、いわゆるシングルページアプリケーションですね。
サーバーレスもカバーしていて、Azure Functions や AWS Lambda といったクラウド関数系の開発。
デスクトップなら Windows 側で WinUI、WPF、WinForms。
モバイルだと .NET MAUI を使ってアプリが作れて、ゲーム開発は Unity や Godot。
さらに機械学習向けの ML.NET。
そして今っぽいところで、LLM を使った AI エージェント開発や、分散アプリケーションのオーケストレーションまで、
Microsoft Agent Framework と Aspire を使って作っていける、というふうに、ほんとに「全部乗せ」な感じで説明されています。
いまの .NET は、昔みたいに「Windows だけ」じゃなくて、Linux と macOS もちゃんとターゲットに入っていて、
しかも毎年バージョンアップしていると。
その中でも .NET Ten は長期サポート版、いわゆる LTS で、二千二十八年までサポートが続く予定なので、
これから新しくプロジェクトを立ち上げるなら、もう機能追加の止まっている .NET Framework ではなくて、
基本は .NET Ten を選ぶのがいいんじゃないか、という主張になっています。
特に、既存の Web アプリとか、古い Web Forms、それから EF6 からの移行ですね。
ここは「ほぼ別物」なので、単純な置き換えっていう感じではいかなくて、
Copilot app modernization みたいな AI ツールをうまく使って、移行を支援してもらうのが現実的ですよ、という話も出てきます。
で、今は AI コーディング時代と言われるくらい、コードは AI と一緒に書くのが当たり前になりつつありますが、
そこで Cシャープの静的型付けとコンパイラチェックが、かなり効いてくると。
型情報がしっかりしていると、AIが書いたコードも検証しやすいですし、
Microsoft.Extensions.AI や Agent Framework、Durable Functions との連携など、
AI と相性のいい公式エコシステムがどんどん整ってきているのも大きな強みだとまとめています。
コンソールから Web、サーバーレス、モバイル、ゲーム、機械学習、AI エージェントまで、
この守備範囲の広さこそ、これからも Cシャープを使い続ける理由になるんじゃないか、という締め方でした。
「ひとつ学べばいろんなとこで応用できるよ」というメッセージが込められた記事ですね。
。。.。。.。.
続いて二本目。
ゲーム好きの方には刺さる話題、「ELDEN RING NIGHTREIGN」でマルチプレイがラグい問題の深掘り記事です。
このラグの原因は、「日本から遊んでいても、スチームの中継サーバーが東京じゃなくて、ソウルとか別の海外サーバーに勝手に選ばれてしまうことが多いからだよ」という説明になっています。
本来ならピングが二十ミリ秒前後で済むところが、そのせいで九十ミリ秒以上になってしまうケースが多いと。
「相手は明らかに日本人ぽいのに、なんかめちゃくちゃ重いな」って感じたことがある人には、かなり納得感のある話です。
対策として、まずフレンドとパーティを組んで遊ぶ場合。
この場合は、スチームの設定で「スチームネットワーキング」を「フレンドのみ」に変えると、
中継サーバーを経由せずに、フレンド同士で直接接続できるようになって、ラグがほぼ解決するよ、と紹介されています。
いわば「直でつなぐから無駄な遠回りをしなくなる」イメージですね。
一方で、野良マッチの場合は、中継サーバーの利用が必須になってしまうので、そこをどうするかが工夫のしどころ。
記事では、Valve が公開している中継サーバー一覧、GetエスディーアールConfig API っていう情報を使って、
「東京、コードでいうとティーワイオーですね、この東京の中継サーバー以外に向かう通信を、Windows ファイアウォールでブロックしてしまう」という方法を取っています。
具体的には、東京以外の中継サーバー宛ての UDP のポート、二万七千十五番から二万七千百四十番まで、
それから旧方式で使われている四三七九番、四三八零番、このあたりをブロックするような PowerShell スクリプトを作って、
通信がなるべく東京経由になるように“固定”してしまう、というアイデアです。
この結果、野良マッチでもピングが二十から二十五ミリ秒くらいで安定して、
「相手は日本勢っぽいのに、なぞのカクカク回」というのがかなり減ったと。
とはいえ、相手側の回線品質とか、海外プレイヤーとマッチングされる場合なんかは、こちらからは制御できないので、
「ラグが完全になくなるわけではないよ」という注意もしっかり書かれています。
ネットワーク周りをちゃんと見てあげるだけで、ゲーム体験ってここまで変わるんだな、というお話でした。
。。.。。.。.
三本目は、ガラッと変わってスマートグラスの話題です。
Even Gツーというスマートグラスで、AIコーディングツールを使うための三つの接続方法と、
それを支える自作ブリッジアプリの仕組みを解説している記事です。
まず一つ目が「ターミナルモード」。
これは Claude Code や Codex みたいな、すでに Even 側が対応している既存ツールの仕組みに乗っかる形で、
自作ツールの xangi に互換 API を実装して接続する方法です。
既存の枠組みを使うので、設定は比較的簡単なんですけど、
どうしても専用の画面に閉じた UI になりがちで、「自由なインターフェースを作り込みたい！」というニーズにはあまり向かないと説明されています。
二つ目が「Even AI の Add Agent 機能」を使う方法。
これは、音声認識が終わったテキストを任意の URL に送って、
ChatGPT っぽい形式のレスポンスを返してあげればよい、というスタイルです。
設定がかなり手軽なので、ちょっとした短い質問とか、簡単な音声コマンドにはぴったりなんですが、
長い応答が必要なケース、たとえば長文コードレビューとかにはあまり強くない、という特徴があります。
そして三つ目が、「Even Hub アプリを自作してしまう」方法。
これはウェブアプリという形で、画面表示やタップ操作、マイク入力の取得なんかを細かくコントロールできるやり方で、
xangi-even-gツーブリッジを経由して、xangi 本体やローカルの Whisper と連携する構成です。
作ったアプリは .ehpk というパッケージ形式でアップロードして、
公開範囲を「プライベート」「ベータ」「パブリック」と切り替えながら運用するやり方も紹介されています。
筆者としては、現時点では「実用性マックス！」というところまではまだ行っていないけれど、
スマートグラスと AI コーディングの組み合わせには、かなりロマンがあって、これからの発展の余地も大きいと感じていると。
UI をきちんと作り込んでいけば、「あれ、これ結構便利じゃない？」というレベルまでは持っていけそうだ、
そんな未来志向の感想で締めくくられていました。
作業中に視界の端っこで AI がコード提案してくれる世界、ちょっとワクワクしますよね。
。。.。。.。.
四本目は、Claude Code を安全に使うための開発環境づくりのお話です。
テーマは「一つの常駐 dev container の中で、複数リポジトリを開発する環境をどう作るか」。
普通だと、リポジトリごとにコンテナを分けたりしがちなんですけど、
この記事ではホームディレクトリのチルダスラデブ、つまりティルダデブ以下を丸ごと一つのコンテナにマウントしてしまって、
その中でディレクトリを切り替えながら、いろんなリポジトリの作業をしていく、というスタイルを提案しています。
ここでポイントになるのが Docker の扱いです。
コンテナからホスト側の docker.sock を共有してしまう、いわゆる DooD、Docker outside of Docker 方式だと、
コンテナにホストの権限を握られてしまうリスクがあるので、そこは避けたいと。
代わりに、コンテナの中に独立した Docker デーモンを立てる、DinD、Docker in Docker 方式を採用しています。
これによって、docker compose で立ち上がるサーバーやデータベースは、すべて dev container の内側に閉じ込めて、
ホスト環境とはしっかり分離できるようにしているわけですね。
認証周りもかなり丁寧です。
AWS や GitHub の認証情報は、コンテナの中には書き込まず、
ホスト側でスクリプトを実行して、一時トークンをその都度取得。
それを devcontainer exec の remote-env オプション経由で、環境変数として毎回注入する形になっています。
Claude Code のログイン情報や設定ファイルについては、named volume を使ってコンテナの外に逃がしておくことで、
「一回ログインしておけば、その後コンテナを作り直しても状態が維持される」という設計です。
さらに、GitHub や Slack などの MCP 設定は、共有のドットエムシーピーJSONにひとまとめにして、
トークンはエンブイアール参照、つまり環境変数経由で外出しするようにしてあります。
GitHub 用には、リポジトリ単位で権限を絞ったパーソナルアクセストークンを用意して、
それをワンパスワードから読み出して環境変数に渡し、MCP に届けることで、
リポジトリごとに細かく権限管理を行っている、というわけです。
面白いのが、コンテナ内の Claude でターン終了音を鳴らすための工夫。
コンテナ側のフックから afplay を呼んで音を鳴らそうとして、もしそれが失敗したら、
共有ディレクトリ上の特定のファイルに「鳴らしてね」という印を付けておいて、
ホスト側でそのファイルを監視して、実際の音を鳴らす仕組みを入れています。
全体として、AI コーディングエージェントを安心して使うために、
セキュリティ、認証と権限管理、そして開発体験、この三つをうまく両立させた dev container の設計例として、
かなり実践的な内容になっていました。
。。.。。.。.
そして最後、五本目。
Slack で Claude Code からメッセージを投稿したときに、Markdown の太字が勝手に斜体になったり、
書式が崩れたりする、あのモヤっと問題を解説している記事です。
原因は、Slack 独自の「mrkdwn」と呼ばれる記法と、
「記号の前後に半角スペースが必要」という微妙な仕様にあります。
特に日本語だと、全角文字が記号にぴったりくっつきがちなので、
この「前後にスペースがあること」という条件を満たせず、
太字、イタリック、取り消し線といった装飾が、意図したとおりに表示されないことが多いんですね。
これを回避するために、筆者はメッセージを送る前に正規表現でテキストを走査して、
Markdown 記法を統一しながら、必要な装飾記号の外側に足りない半角スペースを自動で挿入するスクリプトを書いています。
そしてこのスクリプトを Claude の Skill として公開していて、
Slack MCP が内部で Markdown から mrkdwn へ変換するプロセスが入っても、
日本語まじりのメッセージが崩れずに、ちゃんと太字は太字、斜体は斜体として表示されるように調整していると。
「なんでこんな単純なメッセージが崩れるの…？」と思っていた人には、
「あぁ、そういう仕様だったのね」と納得できる内容になっていましたし、
実用的な回避策までセットなのがうれしいところですね。
。。.。。.。.
というわけで、きょうの「zenncast」は五本立てでお送りしました。
ざっとおさらいすると、
まず一つ目は、Cシャープと .NET Ten がコンソールから Web、モバイル、ゲーム、AI エージェントまで幅広くカバーしていて、
AI 時代にも強いエコシステムだよ、という話。
二本目は、ELDEN RING NIGHTREIGN のマルチがラグい原因と、スチームの中継サーバーを東京に寄せるテクニック。
三本目は、Even Gツーのスマートグラスで AI コーディングツールをつなぐ三つの方法と、自作ブリッジアプリのロマン。
四本目は、Claude Code を安全かつ快適に使うための、一つの dev container で複数リポジトリを扱う設計。
そして五本目は、Slack の mrkdwn 仕様に振り回されないための、Markdown 整形スキルの話でした。
気になった記事があれば、詳しいリンクやキーワードはショーノートにまとめてありますので、
通勤・通学のあと、落ち着いたタイミングでぜひチェックしてみてください。
この番組「zenncast」では、リスナーのみなさんからの感想や質問もお待ちしています。
「こんなテーマ取り上げてほしい」「この技術記事が面白かった」などなど、
ラジオネームを添えて送ってもらえると、番組の中で紹介させていただきます。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。