どうも、おはようございます。マイクです。
今朝も「zenncast」お付き合いありがとうございます。
今日は2025年12月13日、土曜日の朝7時台、みなさんいかがお過ごしでしょうか。通勤通学の人はちょっと眠い時間かもしれませんが、ここからはZennで今トレンドになっている記事を、ラジオ感覚でゆるっと一緒に追いかけていきたいと思います。
今日は全部で5本の記事をご紹介していきます。エンジニアの文化祭インフラから、AIで爆速開発の話、Pythonで完結するWebの話、Reactの設計の悩み、そしてObsidianとClaude Codeでの情報整理まで、かなり幅広いラインナップです。コーヒー片手に、耳だけ貸してもらえたらうれしいです。
では、1本目。
タイトル「詳解 筑波大学学園祭を支えた本番ネットワークインフラ全貌」。
これね、読みながら「もうこれ普通に小さい放送局かISPでは？」っていうレベルの話でした。筆者の方は、筑波大学の雙峰祭っていう学園祭で、たった3人のインフラチームを率いて、約4万人来場、3日間の生配信を支えるネットワークを組み上げたそうです。まずスケール感が学生の遊びじゃないんですよ。大学に張り巡らされている既設の光ファイバーを7区間14芯も借りて、それでも足りないところは、本部から設備室まで約100mのインドア光ファイバーを自前施工。さらに屋外ステージには屋外用のファイバーリールをぐるーっと引き回して、最長2.6kmの区間を含む40Gbpsリンクを通したと。上流も、学術情報メディアセンターとWIDEつくばNOCっていう2系統を用意して、実運用は10Gで流してるんですが、3日間で上り3.3TB、下り1.2TBのトラフィックをさばいたそうです。
配信もガチで、3つの常設ステージに加えて、移動配信用の1系統、合計4つを同時配信。カメラはCanonのPTZカメラで、NDIとかLiveU Solo ProみたいなMedia over IP技術をフル活用して、少人数でも回せるように工夫してます。さらに裏側では、高速ストレージサーバーで1.2TB分の映像素材を共有したり、10G接続のPCでSDカードを高速に吸い出したり、MikoPBXとYealinkのIP電話で内線網を組んだり、来場者向けサイネージに運営スタッフ用のWi-Fi 7のAPまで。監視系もきちんと整えていて、「文化祭インフラ」というよりは、もうプロのイベント配信現場です。しかも、機材の多くを企業や学内の組織から協力してもらっているのもおもしろいところ。筆者は今後、ST2110みたいな非圧縮伝送にも挑戦したいって書いていて、機材スポンサーや協賛、局メンバーも募集中とのこと。こういう学生プロジェクトにガチ機材を貸して一緒に遊べる会社、めちゃくちゃ楽しそうですよね。学生のみなさんでインフラとかメディアに興味ある人は、この記事読むだけで「こんな遊び方あるんだ」ってワクワクすると思います。
。.。.。.
続いて2本目。
タイトル「AIの力を借りて2人で10人分の仕事をする (2025年・個人開発)」。
これは、友人2人で「tone」っていうチーム向けの高機能Todoサービスを開発している筆者の話です。サービスを作るだけじゃなくて、LP作ったり、ブログ書いたり、MCPサーバー動かしたりと、とにかくやることが山盛り。でもチームは2人。そこでガッツリAIを使って「体感10人分」まで生産性をブーストしていこうという試みです。
開発プロセスとしておもしろいのが、まずPR（プルリク）から引き継ぎ資料をAIに生成させて、それをtoneとMCP経由でタスク化して実装を進めるっていう流れ。要するに、「コードの変更点の解説」「次やるべきこと」をAIにまとめさせて、それをそのまま次の作業のインプットにしていく感じですね。マーケティング周りでは、ブログのドラフトをAIに書かせて、文体も自分たちっぽく寄せてもらい、レビューや校正、画像のALTテキストまでAIにお願いする。さらにmicroCMSとMCPをつないで、お知らせ配信を自動連携するなど、結構細かいところまで自動化しています。
品質保証でもAIが登場していて、サービス特有の「ここは気をつけたい」という観点をAIに教えた上でコードレビューさせたり、Playwright用のMCPを使ってE2Eテストを回させて、スクリーンショットを自動でアップロードさせたり。分析のところでは、Cloud SQL Studioのtext2sql機能を使って、自然言語からSQLを生成したり、MCP経由で「この指標をこう集計して」って会話しながらデータを見ていく。
ポイントは、「全部を1個の魔法みたいなAIに任せる」のではなくて、「PR引き継ぎ」「ブログ下書き」「テスト実行」「データ集計」みたいな、小さな作業ごとにAIをかませて、ちょっとずつ時間を浮かせていくスタイルなんですよね。その結果、2人でもコアな問い、「何を作るか」「どう届けるか」に集中できる。個人開発やスタートアップの方は、自分の現場に持ち込める工夫がかなり見つかる記事だと思います。
。.。.。.
3本目。
タイトル「『FastAPI + htmxが最強説』- AIエンジニアがモック作るならReactは不要、Streamlitも捨てよう」。
AI系のスタートアップでプロトタイプ作ってる方の、かなり実戦的な主張です。今、LLMとかディープラーニングをやろうと思うと、どうしてもPython前提の世界になるじゃないですか。で、バックエンドはFastAPIを使うことが多い。一方で、フロント側は「とりあえずStreamlitで」「いややっぱReact/Nextでちゃんと作ろうかな」って揺れがちなんですが、著者の結論は「FastAPI + htmxで、Python中心に1サーバー構成でやるのが一番ラクで、しかも捨てないプロトタイプになるよ」というものです。
Streamlitはセットアップも簡単だし、AIデモ作るのには最高なんですけど、どうしても見た目が似たり寄ったりで、デザインを作り込みたいときに限界がきちゃう。本番運用も、ちゃんとやろうと思うと結構つらい。一方、React/Nextは自由度もパワーもあるんですが、「バックエンドのFastAPI」と「フロントのNextサーバー」の二重管理が必要になって、1人とか少人数のチームには重すぎると。
そこで出てくるのがhtmx。HTMLの属性をちょこちょこっと付けるだけで、非同期通信や部分更新、SSE、無限スクロールみたいなことができてしまうライブラリです。これをFastAPIと組み合わせると、「ほとんどPythonだけで」「サーバーは1つだけ動かして」、モックから本番までスムーズにつながるアプリが作れる。しかも、AIがデザイン用のHTML/CSSをある程度出してくれる時代なので、「デザインはAIに吐いてもらって、それにhtmxの属性をちょい足し」「裏側はFastAPIでエンドポイントを書く」という流れが、めちゃくちゃ相性がいい、と。
筆者は、「とりあえずReactで」「とりあえずStreamlitで」っていうお決まりパターンに入る前に、FastAPI + htmxを検討してみよう、と強く推しています。PythonメインでAIプロダクトを作っているエンジニアは、フロントどうしよう問題に一つ解をもらえる記事じゃないかなと思いました。
。.。.。.
4本目。
タイトル「Reactカスタムフックが可読性を損なうとき」。
Reactを書いている人なら、一度は「ロジックはカスタムフックに切り出せばきれいになるはず」と思ったことあるんじゃないでしょうか。この記事では、その「正しそうなパターン」が行き過ぎると、逆にコードが読みにくくなるよという話が、かなり丁寧に解説されています。
まずやられがちなのが、「このコンポーネントでしか使わないのに、とりあえずロジックを全部カスタムフックに分離しちゃう」パターン。こうすると、一見「UIがスッキリした！」ように見えるんですが、実際に挙動を理解しようとすると、UIのファイルとカスタムフックのファイルを何度も行き来しないといけなくなって、認知負荷が上がるんですよね。UIと振る舞いが分断されて、コンポーネントの凝集度も下がってしまう。
もう一つの罠が、useQueryやuseFormみたいな有名ライブラリのフックを、自前のカスタムフックで丸ごとラップしてしまうこと。独自のインターフェースを作ってしまうと、そのプロジェクト特有のAPIを覚えないといけなくて、せっかくの「標準APIの予測可能性」が失われちゃうんです。しかも、一度ラップすると、あとからライブラリ側の新機能やオプションを使いたくなったときに、抽象が邪魔になることも多い。
じゃあカスタムフックは全部やめるのかというと、もちろんそうではなくて、「使う場面をはっきりさせよう」という提案です。例えば、ドメインに依存しない汎用ロジックを再利用したいときとか、副作用を1個の責務としてカプセル化したいとき、あるいは「このライブラリはこの設定でだけ使うよ」というポリシーを薄く型で強制したいとき、親子コンポーネント間で状態リフトアップの契約をきれいにしたいときなど。そういう、価値がはっきりしているときに限ってカスタムフックを使う。
背景にあるのが「拙速な抽象化を避ける」というAHA原則で、「十分な重複が出てから抽象化しよう」と。Reactを書いていて「抽象化しすぎたかな…」と感じた経験がある人には、かなり刺さる内容だと思います。
。.。.。.
最後、5本目。
タイトル「Obsidian × Claude Codeで情報整理を緩くやってみたけど、想像以上によかった話」。
これは、日々いろんなプロジェクトや細かいタスクを抱えている筆者が、「Slackとかメモアプリにタスクが散らばって、結局どれも続かない」というあるある状態から抜け出すために、ObsidianとClaude Codeを中心に「ゆるい情報整理システム」を作った記録です。
構成としては、メモのハブがObsidian。ここにThinoというプラグインを入れて、小さなタスクや感情メモを、あまり考えずにポンポン貯めていく。タスク管理はNotion、予定はGoogleカレンダーという、既に多くの人が使っていそうなツールたちをそのまま使いつつ、Claude Codeを「つなぎ役」として活躍させています。Claude CodeはMCP経由でNotionとカレンダーに接続していて、毎朝、Terminalからコマンドを叩くと、その日の「今日のノート」を自動生成してくれる。そこには、今日の予定、優先タスク、前日までのサマリなどがまとまっていて、「とりあえずこれ見れば今日やることがわかる」状態になります。
さらに、金曜日には1週間分のdailyノートを読み込んで、週報まで自動で作ってくれる。Notion側は、シンプルなカンバンと期限だけで運用していて、Slackで拾ったタスクもそこにちゃんとつながるようにしています。
筆者が一番良かったと言っているのは、「体裁やタグ付けを気にせず、雑にメモしていい」ようになったこと。整理や構造化はAIがあとからやってくれるので、自分はとにかく思いついたことをObsidianに投げ込めばいい。結果として、朝と週初めに、ちゃんとまとまった形で情報が出てくるので、脳の負荷が減って、習慣化しやすくなったと。情報整理って、「きれいにやろう」と思うほど続かなくなるところがあるので、「ゆるく＋AIに肩代わりさせる」というバランス感覚は、多くの人のヒントになりそうだなと感じました。
。.。。.
というわけで、今日の「zenncast」は、
・筑波大学の學園祭を40Gbpsネットワークで支えた、本気の文化祭インフラの話。
・AIをフル活用して、2人で10人分の開発・運用を回す個人開発のワークフロー。
・AIプロダクトのモックから本番までを、FastAPI + htmxでPython中心に完結させるという提案。
・Reactで「カスタムフック万能説」に待ったをかける、可読性と抽象化のバランスの話。
・ObsidianとClaude Codeで、ゆるく続く情報整理術を作った知見。
この5本をご紹介しました。
気になった記事があった方は、番組のショーノートに詳細を載せておきますので、ぜひそちらから原文も読んでみてください。実際の記事には、今日お話ししきれなかった図や具体例、コードや設定の話もたくさん載っています。
「zenncast」では、番組の感想や、「こんなテーマ取り上げてほしい」「自分の書いた記事も紹介してほしい」なんてリクエストもお待ちしています。ラジオネームを添えて、気軽に送ってください。
それでは、そろそろお別れの時間です。
今週末も、学びと遊びのバランスを取りつつ、よい一日をお過ごしください。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。ではでは。