どうもおはようございます、朝7時のzenncast、パーソナリティのマイクです。
今日は2026年4月14日、火曜日。みなさん通勤通学の準備中でしょうか、それとももう作業始めちゃってますか？
この時間は、今Zennで話題になっているトレンド記事をサクッと紹介していきます。コーヒー片手に、耳だけ貸してもらえたらうれしいです。

今日は全部で5本の記事をご紹介していきます。
AIのトークン節約テクから、SRE・Platform Engineering、フロントエンドの通信設計、AWSの新しいエージェントの話、そしてブラウザ自動化まで、技術好きにはたまらないラインナップになってます。それぞれの要点をぎゅっと凝縮してお届けしますね。

まず1本目。「Claude Max 20xプランでも足りないので、トークン節約のためにやったこと8選」という記事です。
タイトルからして、もうだいぶ使い倒してる感がありますけど、筆者の方はClaude Max 20xでもすぐトークン上限に当たってしまうくらいヘビーに使っているそうなんですね。そこで、コンテキストの設計と作業フローを徹底的に見直して、8つの節約術をまとめています。
ポイントは「必要十分な情報だけを与える」という発想に振り切ること。`.claude/`ディレクトリのrules・agents・skillsを整理して、必要なときだけpaths指定で条件読み込みする。敬語やクッション言葉を削った「原始人スタイル」で、出力だけでなく設定やドキュメントまでコンパクトにする。巨大化しがちなNotebookは`jupytext`経由で扱って軽量化する。会話の文脈が切れたら潔く`/clear`して、長めの作業はスキルを分割して中間成果物でつなぐ。さらに、ローカルLLMでRAGを組んで、「全部読ませる」んじゃなくて「必要な知識だけ問い合わせる」ようにする。あとは、単純作業は軽いモデルに任せるとか、sandbox設定や`.claudeignore`で余計なファイルを見せないようにする、といった感じで、地味だけど効く工夫が並んでいます。Anthropicが言うコンテキストエンジニアリングの考え方にも通じていて、「節約」と「品質アップ」が同じ方向を向くのがいいよね、という締めでした。AIに長文読ませがちな人には、耳が痛くもあり、すぐ真似したくなるノウハウ集です。

。。。。

続いて2本目。「SREを『努力』から『仕組み』へ — Platform Engineeringという選択」という記事。
これは、SREとしてアラートの整理やCI/CDの整備、インシデント対応の強化を頑張ってきた筆者が、それでも「現場の開発者が日常的に信頼性を上げる行動を取るのは難しい」という壁にぶつかった、というところから始まります。インフラ設定の認知負荷が高くて、どうしても「SREに依頼する」「特定の人しか分からない」構造になってしまうんですね。
そこで、マルチプロダクト化や共通基盤のニーズも背景にしながら、「努力でカバーする」のをやめて、「仕組みで解決する」Platform Engineeringに舵を切ったお話です。具体的には、EKS＋Helm＋GitOpsでGolden Pathを用意して、values.yamlを書くだけでデプロイできるようなセルフサービスの世界を目指す。ガードレール付きのプラットフォームにすることで、開発者は細かいインフラの知識なしでも、SREのベストプラクティスに乗れるようにするわけですね。
さらに、Delivery / Capacity / Observability / Security / Incident というSREの5本柱を、段階的にプラットフォームの機能としてカバーしていく構想も紹介されています。SREと開発チームの責務の境界を引き直して、「SREは仕組みを作る側」「開発はその上で自然とSREっぽい振る舞いができるようにする」という関係を作っていく。1年通して、「SREを努力から仕組みへ」という考え方に到達したのが最大の学びだった、というふうに振り返られていました。SRE・Platformチーム界隈の人にはかなり刺さる内容だと思います。

。。。。

3本目。「『とりあえずAxios』のその先へ。通信層を『信頼性ポリシー』で設計する pureq」という記事です。
フロントエンドのAPI通信って、「とりあえずAxios入れて、インターセプターで頑張るか」「fetchラッパを自作するか」みたいなノリからスタートして、いつのまにかプロジェクトごとにクセのある実装が積み上がりがちですよね。タイムアウトやリトライの戦略が散らばったり、誰も全体像を把握してないとか。
この記事では、そうした問題に対して、「通信の信頼性を不変なポリシーとして設計する」という発想で作られたライブラリ pureq が紹介されています。特徴としては、`.use()`でミドルウェアを足していくたびに、新しいクライアントをイミュータブルに派生させられること。それから、ミドルウェアの順番が挙動そのものになる、いわゆるOnion Modelを採用していて、「この順序でポリシーが適用される」というのがコード上も分かりやすい。
エラーハンドリングはResultパターンで型安全にやるので、「成功か失敗か、その中身は何か」が型として表現されます。これによって、「このプロジェクトの通信ポリシーはこうです」というのを、口約束じゃなくてコードとして共有できるようになる。大規模フロントエンドやBFFで、fetchラッパがカオスになってきたな…という現場に向けて、「その先の設計」を提案している内容でした。Axiosから一歩進みたい人には良いヒントになりそうです。

。。。。

4本目。「AWS Frontier Agentsで変わるSREの仕事、変わらないSREの仕事」という記事です。
AWSが発表した自律型AI、Frontier AgentsのDevOps AgentとSecurity AgentがGAになって、「SREとかセキュリティの仕事、これでどこまで変わるんだ？」というテーマで書かれています。これらのAgentは、インシデント調査やペネトレーションテストといった、これまで人間がかなり時間をかけていた作業を自動でやってくれるんですが、役割としてはあくまで「調査・発見・提案」まで。実際に本番環境へ反映するかどうか、リスクを受け入れるかどうか、といった判断は人間がやる前提で設計されています。
監視ツールやGitHubなど、既存のツール群はそのままデータソース、実行基盤として必要で、Agentはそれらと連携して働くイメージですね。料金体系も面白くて、DevOps AgentはSupportクレジットと連動した従量課金、Security Agentはペンテスト部分だけ有料にして、「高額・低頻度のテスト」から「小額・高頻度」にシフトできるような構造になっています。
結果として、オンコールの初動調査などはかなり自動化されて、人間のSREは「ゼロから情報を集める人」ではなく、「Agentの分析結果を監査して、文脈に合わせて判断する人」という役割になっていく。なので、SREの仕事がなくなるわけではなくて、求められるスキルが変わる。チームの運営方針や育成の仕方も、その前提で考え直す必要があるよね、という提言で締められています。AI時代のSRE像を考えるのに、いい材料になりそうです。

。。。。

そして5本目。「DevContainerで完結！Claude Code + Playwright MCPを使ったブラウザ操作自動化の構築手順」という記事です。
これは、Claude CodeとMicrosoft公式のPlaywright MCPを組み合わせて、「ブラウザでの操作を自然言語で指示→RPAスクリプトを自動生成」という、かなりワクワクする構成をDevContainer上で完結させる手順が紹介されています。
構成としては、DevContainerの中にPlaywright MCPサーバーと仮想デスクトップ環境（Xvfb + noVNC）、それからClaude Codeをまとめて立ててしまって、ブラウザの画面はlocalhost:6080で確認するスタイル。`devcontainer.json`に、desktop-liteの機能追加やPlaywright＋Claude MCPの設定を書いておいて、立ち上げたら`/mcp`でちゃんとつながっているかチェックする、という流れです。
活用例としては、NotebookLMの特定ノートブックのソース同期操作を、まずClaudeに自然言語で「こういう操作して」と実演してもらって、その手順からPlaywrightのスクリプトを自動生成。それを定期実行させることで、更新作業を自動化してしまう、というデモが紹介されています。Playwrightの書き方を細かく知らなくても、自然言語ベースでブラウザ業務のRPAを組めるので、非エンジニアの方でも使いやすいのがポイントですね。「ちょっとしたブラウザ定型作業をなんとかしたい」という人には、かなり実用的なセットアップだと思います。

。。。。

というわけで、今日は全部で5本の記事をご紹介しました。
トークン節約のためのコンテキスト設計、SREを努力から仕組みに変えるPlatform Engineering、Axiosのその先を目指す通信ポリシー設計pureq、AWS Frontier Agentsで変わるSREの役割、そしてDevContainer上でのClaude Code＋Playwright MCPによるブラウザ自動化まで、一気に駆け足でおさらいしました。

詳しい内容や記事のタイトルはショーノートにまとめておきますので、気になったトピックがあれば、あとでゆっくりチェックしてみてください。
zenncastでは、番組の感想や「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。あなたの開発現場での悩みや、AIとの付き合い方の工夫なんかも、ぜひ教えてください。

それでは、今日も良い一日を。
お相手はマイクでした。また次回のzenncastでお会いしましょう。