どうもー、おはようございます。マイクです。
時刻は朝7時を少し回ったところ、2026年3月1日・日曜日の朝です。
ここからの時間は「zenncast」、きょうも最新のZennトレンド記事をゆるっと、でも中身はみっちり紹介していきます。エンジニアの朝活のお供に、コーヒー片手にお付き合いください。

さて今日は、お便りはお休みということで、その分たっぷり記事を紹介していきましょう。

きょう紹介する記事は全部で5本です。
ローカルPCをスマホから遠隔操作できる話から、ローカルLLM最前線、Docker Composeでの便利な名前付きURL、Go言語の静的解析のこれまでとこれから、そして「壊れやすいテスト」をどう減らすかというテスト設計の話まで、幅広くピックアップしてます。

まず1本目。
タイトルは「Claude Code のリモートコントロールとスマホ通知の始め方」。
これね、Claude CodeをローカルPCで動かしている人にはかなり刺さる内容です。リモートコントロール機能を使うと、PCで立ち上げたClaudeのセッションを、スマホとか別のブラウザからそのまま触れるようになるんですよね。ローカルの環境やツールを活かしつつ、作業の続きを出先からできる、みたいな世界観です。通信自体はAnthropic API経由でTLSで守られていて、インバウンドのポートを開けなくていい構成なのもポイント。使うにはMaxプラン（順次Pro）と、事前ログイン、それから「このワークスペースは信頼済みですよ」という設定が必要になります。具体的には、/configとか/remote-controlの画面、あるいはコマンドラインで `claude remote-control` を叩いて有効化していく流れですね。
で、この記事の面白いところが通知まわり。Claude Codeって、ローカルで長い処理を走らせてると、「いつ終わったのか分からない問題」があるじゃないですか。それを解決するために、Notification Hook機能と、iOS向けのプッシュアプリ「Bark」を組み合わせる構成を提案しています。permission_promptとかidle_promptみたいな、入力待ちのタイミングでスマホに通知を飛ばすイメージです。Barkはオープンソースのサーバーを持っていて、AES-256-CBCで暗号化した通知にも対応。デバイスキーと、opensslで作った鍵とIVをアプリ側とClaude側に設定して、~/.claude/settings.jsonにhooksと環境変数を追記してあげると、暗号化された通知がちゃんと届くようになります。デフォルトのapi.day.appサーバーは安定性が保証されてるわけじゃないので、気になる人はセルフホストも視野に、という話も書かれていました。結果として、PCで重い処理をガンガン回しておいて、完了したらスマホに通知→そのままスマホからレス、みたいな快適ワークフローを作れるよ、という実践的な記事になっています。

。。。。

続いて2本目。
タイトルは「ついにローカルLLMで安心して仕事が出来る！― Qwen3.5-27B 採用レポート (2026/02/27)」。
ローカルLLM、どこまで実用なの？という疑問にガチで答えているレポートです。筆者の環境はRTX3090でVRAM24GB、Qwen3.5-27Bを5bit量子化して、十分な実用速度で回しているとのこと。注目なのが、いわゆる「GPT-4クラス」と言われてきた30B級のローカルモデルたちから、もう一世代進んだ感触がある、という評価です。独自のIntelligence Indexでは、Qwen3.5-27Bがスコア42、o3-proが41、Qwen3.5-35B-A3Bが37。つまり、27Bモデルなのに、クラウドのフロンティアモデル群を上回る「中堅フロンティア帯」に入っている、という位置づけなんですね。
面白いのが、より大きい35B-A3Bよりも27Bのほうが「長いタスクを最後までちゃんとやり切る」「コードの一貫性が高い」「雑なプロンプトにもある程度耐えてくれる」といった点で明確に質が高く、筆者は常用エンジンとして27Bを採用した、というところ。理由として、線形Attentionと通常Attentionのハイブリッド構造、かなり大規模かつ厳選された学習データ、それから推論強化型RLでエージェント的な振る舞いを鍛えている、という技術的背景も紹介されています。実験として、TypeScriptとCanvasでPongとかBreakout、Tetrisをワンショット生成させて、ちょっと手直しするだけで遊べるレベルに到達したという話も。電気代ベースで見ると、GPT-5 miniクラスのAPIを叩くのと同じくらいのコスト感だけれど、ローカルで動かすとトークン制限やモデルの仕様変更をあまり気にしなくていいし、機密データも外に出さずに済む。そのメリットを重く見ていて、「しばらくはQwen3.5-27BがローカルLLMの新しい基準点になりそうだ」という結論になっていました。

。。。。

3本目。
タイトルは「portless が便利なら、Docker Compose には Traefik がある」。
これはローカル開発環境に悩んでいる人に刺さりそうな話です。portlessって、ローカルで動かしているプロセスに対して、ポート番号じゃなくて名前付きのURLでアクセスできるようにしてくれる便利ツールなんですが、Docker Compose環境だとそのままは使えないんですよね。そこで代わりに登場するのが、TraefikのDockerプロバイダー機能。`defaultRule` をうまく設定してあげると、ラベルをゴリゴリ書かなくても、`サービス名.プロジェクト名.localhost` みたいなURLを自動で生やせる、というアイデアです。
手順もシンプルで、まず共有ネットワークとして `traefik` を作る。そこにTraefikコンテナを立ち上げておいて、各プロジェクトのdocker-composeにそのネットワークを参加させるだけ。Composeはデフォルトで「ディレクトリ名＝プロジェクト名」になるので、git worktreeを使ってブランチごとにディレクトリを分けておけば、たとえば `frontend.feature-branch.localhost` みたいに、ブランチごとの環境を衝突なしで並行起動できるわけです。`*.localhost` はブラウザやOSが標準でループバックに解決してくれるので、追加のDNS設定もいらない。つまり、portlessで感じていた「ポート番号覚えるのつらい問題」を、Docker Composeの世界ではTraefikの一行設定でかなり解消できるよ、という提案になっています。複数サービスを並行で起動することが多い人には、かなり現場感のあるテクニックだと思います。

。。。。

4本目。
タイトルは「静的解析からみるGoの過去と未来」。
Go言語って、誕生の頃から「ツールの作りやすさ」をかなり意識して設計されてきたんですが、その静的解析まわりの歴史とこれからを、きれいに整理してくれている記事です。標準ライブラリにASTまわりのパッケージがちゃんと入っていて、`go vet` や `gofmt` が最初から用意されていたり、インポートパスの設計によって「ソースコードさえあれば解析が完結する」ようにしてある、というのがまず土台として紹介されています。そのあと `go/types` が入ってきて、型情報も踏まえた高度な解析ができるようになり、`go/analysis` と gopls の登場で、静的解析がモジュール化＆高効率化されていった流れが説明されています。
近年のGo Modules、型パラメータ、イテレータといった言語仕様の変化にも、静的解析の仕組みが追従してきた話や、セキュリティ分野への応用としてgovulncheckやCapslockのようなツールが出てきた話も触れられていました。個人的に面白かったのは、Go 1.26で `go fix` がリニューアルされて、「古い書き方を新しいスタイルに直す」ための公式ツールとして位置付け直されたという点。`//go:fix inline` みたいなアノテーションをソースコードに書いておくと、ライブラリ作者自身が「こういう風に置き換えてね」とマイグレーションを案内できるようになる構想です。今後は、こういったアノテーションを活用して「セルフサービスな静的解析」を広げていったり、Analyzerを動的にロードできるようにしたり、パターンマッチングベースで誰でも簡単にLinterを作れる世界を目指している、というビジョンも語られていました。Goを書いてない人でも、「言語とツールを一緒に育てていくとこうなるんだ」という良いケーススタディになりそうな内容でした。

。。。。

そしてラスト、5本目。
タイトルは「壊れやすいテストとは？ 『単体テストの考え方/使い方』(古典学派)と『実践テスト駆動開発』(ロンドン学派)を読んで考える」。
テスト本の古典2冊を読み直して、「壊れやすいテスト」って具体的に何が問題で、どうやって減らしていくのかを整理した記事です。まず、古典学派と呼ばれる「単体テストの考え方/使い方」側は、少量のコードを短時間でテストすること、テストケース同士の隔離をすごく重視していて、ドメイン層のテストと、実DBを使うController層の結合テストを主軸に据えるスタイル。モックは外部APIとか、システムの外にある依存に限定するのが基本方針です。一方ロンドン学派、「実践テスト駆動開発」のほうは、TDDを外側から内側に向かって進めるダブルループや「動くスケルトン」という考え方を大事にしていて、まだ実装していない部分をモックで置き換えながら、かなり早い段階から受け入れテストを書いていくスタイルですね。
じゃあ「壊れやすいテスト」はどこから生まれるのか。この記事では、テストケースの隔離ができていない（共有DBやグローバル状態をそのまま使っている）、実装の詳細に依存しすぎている（private関数まで直接テストしたり、スタブの呼び出し回数チェックを過剰にやる）、テストの中にロジックを書きすぎる、時刻や乱数といった外部要因に引っ張られてFlakyになる、といった要因を挙げています。こういうテストは偽陽性を生みがちで、リファクタリングへの耐性が低くなる。だから「Controllerのテストは壊れやすい」とか、そういう印象論だけで語るんじゃなくて、「なぜ壊れるのか」「テスト側の設計をどう直すのか」をちゃんと分析しよう、と呼びかけています。最後はAI時代の話にもつながっていて、テストやTDDの歴史的な背景を理解しておくことで、AIが自動生成したテストをちゃんと評価できるようになろう、という締めくくりになっていました。AI任せではなく、人間側のテストリテラシーが問われる、という視点ですね。

。。。。

というわけで、きょうのzenncastは、
・Claude Codeをスマホから遠隔操作＆通知連携する話、
・ローカルLLMの新しい基準になりそうなQwen3.5-27Bの採用レポート、
・Docker Compose環境でTraefikを使って名前付きURLを自動発行するテクニック、
・Goの静的解析がどう進化してきたか、これからどこへ向かうのか、
・古典とロンドン、2つのテストスタイルから「壊れやすいテスト」を見直す話、
この5本を駆け足でお送りしました。

気になった記事があれば、詳しい内容は番組のショーノートにまとめておきますので、そちらから元記事もチェックしてみてください。
番組への感想や、「こんなテーマ掘り下げてほしい」みたいなリクエストも大歓迎です。あなたの開発現場でのモヤモヤや発見なんかも、ぜひ共有してもらえると嬉しいです。

それでは、きょうも良い日曜日と、良い開発ライフを。
お相手はマイクでした。また次回のzenncastでお会いしましょう。バイバーイ。