おはようございます。今朝も始まりました「zenncast」、MCのマイクです。
今日は2026年4月15日、水曜日の朝7時を少し回ったところですね。
この時間は、技術情報プラットフォームZennに上がっている、いまホットなトレンド記事をピックアップしてご紹介していきます。通勤・通学中のエンジニアのみなさん、コーヒー片手にゆるっとお付き合いください。
さて今日は、お便りコーナーはお休みで、そのぶんがっつり記事を紹介していきたいと思います。
今日紹介する記事は全部で5本です。
モバイルアプリの技術選定から、Python環境整備、GPUジョブスケジューラ、Rustの変態的（褒め言葉です）な型システム活用、そしてKubernetes Ingressの移行ストーリーまで、かなり濃いラインナップになっています。
まず1本目。タイトルは「FlutterからReact Nativeへ。物流アプリのリプレイスに挑んでいる話」。
物流現場向けの「MOVO Driver」というアプリのお話です。最初は、少人数でiOSとAndroidをサクッと立ち上げたい、という理由でFlutterを採用していたそうなんですが、プロダクトが大きくなるにつれて状況が変わってきたと。既存のWebサービスがReactとTypeScriptでがっつり作られていて、「じゃあモバイルもReact Nativeに寄せたほうが、技術的にも組織的にもハッピーなんじゃない？」という判断に至ります。
ここで面白いのが、ただフレームワークを乗り換えただけじゃなくて、Expoをフルに使って開発体験そのものを作り替えているところ。Expo SDKやModules、Config Pluginを活用して、ネイティブ機能や設定の多くをカバーしつつ、ライブラリも「Expoと相性いいもの」を基準に再選定していきます。さらに、AIを使ってFlutterの画面をReact Nativeに移植するプロトタイプまで試していて、「人間がゼロから全部書き直す」のではなく、AIに下書きをさせてから仕上げる、みたいな開発スタイルも見えてきている。
結果、React Nativeに統一したことで、Webフロントエンドのエンジニアとモバイルエンジニアが共通の基盤・言語で話せるようになり、技術選定や知見の共有がしやすくなったそうです。単なる技術スタックの変更ではなく、「Web資産を活かしながら、モバイルとWebを横断した物流現場向けプロダクト開発基盤を作る」っていう、かなり長期目線のリプレイスの物語になっているのが印象的でした。
。 。 。 。
続いて2本目。タイトルは「Python開発環境をスッキリ整える：uv / Ruff / Taskfile」。
Pythonのプロジェクトをやっている方、「ツールが多すぎて、どこに何を書くんだっけ？」ってなりがちじゃないですか。従来は、pyenvでバージョン管理して、Poetryで依存管理して、flake8とblackとisortで静的解析と整形をして、Makefileでコマンドをまとめる……みたいな構成がよくありますよね。便利なんだけど、そのぶん学習コストも管理コストも高い。
この記事の筆者は、そこを「uv」「Ruff」「Taskfile」という3つにギュッとまとめています。uvは、Pythonのバージョン管理・依存管理・仮想環境を一体化して扱えるツールで、「pyenvいらなくない？」っていう世界線を作ってくれる。Ruffは、Lintもフォーマットもインポート整列もまとめて面倒見てくれる、高速なツール。そしてTaskfileは、YAMLで書けるタスクランナーで、「よく使うコマンド」を読みやすく共有できるようにしてくれます。
こうすることで、「ツール同士の順番」とか「設定をどこに書くか」といった認知負荷が下がって、ひたすらコードを書くほうに集中しやすくなる。Pythonプロジェクトのテンプレを作り直したいチームには、かなり参考になる構成だと思います。
。 。 。 。
3本目は、GPUを日々ぶん回している方に刺さりそうな記事。「手元のGPUを遊ばせないためのジョブスケジューラ入門」。
「ジョブスケジューラ」と聞くと、スパコンとか大規模HPC環境のイメージが強いんですが、筆者は「個人のローカル環境でも十分役に立つよ」と主張します。HPCの世界ではSlurmが事実上の標準なんですが、ローカル用に使うにはさすがにオーバースペック。そこで、単一ノード・単一ユーザー向けにRustで書かれた軽量ジョブスケジューラ「slotd」を自作してしまった、というストーリーです。
slotdは、sbatch、srun、salloc、squeue、sacctといったSlurm互換のコマンドを持っていて、CPU・メモリ・GPUの予約、バッチジョブ・対話ジョブ、job array、dependencyなど、必要な機能は一通り実装されています。記事では、sinfoで資源を確認して、sbatchでジョブを投入して、squeueやsacctでジョブ状態や履歴を追いかけて、scancelで止めて、といった基本操作を丁寧に紹介。さらに、--arrayや--dependencyを活用して、たくさんの実験条件をさばいたり、処理フローを分解して安全に回したりする方法にも触れています。
面白いのは、Claude CodeやCodexみたいなCoding Agentとslotdを組み合わせる視点。エージェント側に「どんな実験を回すか」「どんなパラメータを試すか」を考えさせて、実行自体はslotdがしっかり管理する、という役割分担ですね。これによって、GPUを高い稼働率で回しつつも、ログや再現性を保ったまま自動実験サイクルを構築できる。ジョブスケジューラって、もう「研究室のもの」だけじゃなくて、個人の開発マシンでも十分使う価値があるんだな、という気づきを与えてくれる記事でした。
。 。 。 。
4本目は、かなりマニアック寄りのお話です。タイトルは「ところで、Rustのtrait/型システムもチューリング完全らしいのでフィボナッチ数列求めてみた」。
Rustの「型システムだけで計算をする」という、いわゆる型レベルプログラミングの実験記事です。constやマクロは使わずに、traitと型だけでロジックを表現していくスタイル。まずは型レベルBooleanを定義して、IfやNandを組み合わせて論理演算を作っていきます。その次に、ZeroとSucc<T>で自然数を表現して、関連型や関連constを駆使しながら、加算・乗算・べき乗・減算といった演算を再帰的なimplで構築していく。
さらに攻めていて、HListのような可変長配列型を定義し、長さの取得、要素の取得と更新、末尾への追加なども全部「型だけ」でこなします。本来なら高階関数で書きたくなるような部分は、Apply<Op, Arg>というトレイトと、Op用のマーカー型を導入して疑似的に表現。これを土台に「型レベルWhile文」のようなものを実装して、その上でHListと自然数演算を組み合わせてフィボナッチ数列を型レベルで生成してしまうんですね。
もちろん、実務でここまでやることはほぼないんですが、「Rustのtraitと型システムだけでここまで表現できるのか」というデモンストレーションとして非常に面白い。実装するうえでは、Orphan Ruleに引っかからないように工夫が必要だったり、トレイト境界が増えて冗長になったりと、Rust特有の制約もたくさん出てきます。ただそれを乗り越えて、「TypeScriptの型レベルプログラミングに負けない表現力がRustにもあるよ」と示している、読み物としても楽しい記事になっていました。
。 。 。 。
そして最後、5本目。インフラ寄りの話題です。「Ingress NGINXのretirementに伴うGateway API + Envoy Gatewayへの移行」。
2026年3月にingress-nginxがretirementを迎えたことを受けて、「みてね」の社内向けサービスで使っていたIngressをどうするか、という現場の移行ストーリーです。まずやったのは、nginx.ingress.kubernetes.io以下のannotationを機械的に棚卸しして、「どんな機能に依存してるのか」をちゃんと洗い出すこと。特に外部認証まわりは、サービスによって使い方がバラバラだったりするので、ここを要件として整理していきます。
そのうえで、「別のIngress実装に単純乗り換えする」のか、「Gateway APIに寄せていく」のかを比較検討。将来のKubernetes標準への寄せや、責務分離・拡張性を重視して、Gateway API採用を決めます。実装候補としてはNGINX Gateway Fabric、Traefikなども検討したものの、Gateway APIとの親和性、OIDC中心の認証機能の充実、L7制御の表現力、ドキュメントなどを総合して、Envoy Gatewayを選択。
移行作業は、annotationをそのまま変換する感じではなくて、「ルーティング」「認証」「ポリシー」といった単位に分解して再設計していく必要がありました。特にoauth2-proxyを使ったauth-*系の外部認証をGateway APIの世界観にどうマッピングするかは、かなり悩みどころだったようです。また、Gateway/GatewayClassを共通基盤チームが管理して、HTTPRouteやPolicyをアプリチーム側が持つ、といった責務分離の設計も重要な検討ポイントでした。
本番切り替えでは、ALBのリスナールールで旧ingress-nginx経路と新Gateway経路を同じホストで共存させて、特定のクエリパラメータなどで新経路へだけトラフィックを流す、という慎重な段階的移行を実施。問題があったらすぐに旧経路へ切り戻せるようにしておいたそうです。最終的な学びとして、「IngressからGateway APIへの移行はYAMLの単純変換じゃなくて、構成全体の再設計なんだ」と捉え直すこと、そして「依存機能の棚卸し」「認証要件の早期検証」「切り戻しを前提にした切り替え計画」がめちゃくちゃ重要だとまとめていました。
というわけで、今日は全部で5本の記事をご紹介しました。
FlutterからReact Nativeへの物流アプリのリプレイス、Python環境をuv / Ruff / Taskfileでスッキリさせる話、ローカルGPUを有効活用するジョブスケジューラ入門、Rustの型システムだけでフィボナッチ数列を計算しちゃうチャレンジ、そしてIngress NGINXのretirementを受けたGateway API + Envoy Gatewayへの移行ストーリー。どれも、技術選定や基盤づくり、そして「どうやってチームの開発体験を良くするか」という観点で、とても示唆に富んだ内容だったと思います。
気になった記事があれば、詳しい内容はこの番組のショーノートにまとめてありますので、あとでぜひチェックしてみてください。
「zenncast」では、番組の感想や「こんなテーマ扱ってほしい」「この技術の実践談が聞きたい」といったリクエストも大歓迎です。ラジオネームを添えて、気軽に送ってもらえると嬉しいです。
それでは今日はこのへんで。
お相手はマイクでした。次回のzenncastでまたお会いしましょう。いってらっしゃい！