Tech Memo

1. AI & エージェントテクノロジー

Google Cloud Next ‘26 で行われた 260 の発表のまとめ

• カテゴリ: AI / クラウド
• 概要: Google Cloud Next ‘26での膨大な発表内容を網羅した要約。Gemini Enterprise Agent Platformや第8世代TPU、エージェント型データクラウドなど、企業がAIエージェントを大規模に導入・運用するためのインフラとプラットフォームが完備されたことが示されています。
• 感想: 全体としてAIへの注力が強く感じられ、エージェント運用のための基盤が整ったことと感じた。ただ、エンタープライズ利用で重要なデータ保持や再学習、認証認可といったセキュリティ面のアップデートがもう少し欲しかったというのが正直な感想です。開発生産性が向上するのは嬉しい反面、「意図しない使い方」などは発生するものでありプラットフォーム側のガードレールに期待しつつも、どう安全な環境を整えるかが、これからのSREの重要な仕事になると考える。

Red Hatが提供するAIスキルパック、Red Hat Agentic Skills の紹介

• カテゴリ: AIエージェント / MCP
• 概要: AIアシスタントにRed Hat製品の専門知識や操作能力を追加する「Red Hat Agentic Skills」の紹介。MCPを介してナレッジベースやAPIに接続し、AIを「エンタープライズ・スーパーユーザー」へと進化させる取り組み。
• 感想: セキュリティの面で「CVE Explainer」には非常に興味を惹かれた。現在はGeminiを使ってCVEの調査を行うことが多く、製品特化のナレッジを持つエージェントがより具体的で精度の高い情報を提供してくれるなら、運用の負担や影響調査はかなり軽減されそう。自宅サーバーでRHELを利用しているので個人環境でもぜひ試してみたい。

Using Claude Code: The Unreasonable Effectiveness of HTML (X)

• カテゴリ: AIツール / Claude Code
• 概要: Claude CodeにおけるHTMLの有用性についてのポスト。構造化されたデータのやり取りにおいて、HTMLという枯れた技術がAIとのコンテキスト共有に意外な効果を発揮するという知見。
• 感想: Notionへのインポートなどで特定のプラットフォームへ情報を流し込む際、Markdownの「方言」に悩まされてHTML出力に切り替えた経験がありこの指摘には非常に共感しました。構造が厳格なHTMLは、AIとのやり取りにおいて使いやすいと感じる。もちろん、今この週報をHugo（Markdown）で書いているように、Markdownの利便性も健在です。AI時代だからこそ、こうした「枯れた技術」を適材適所で使い分ける勘所が重要になると考える。

Red Hat Summit 2026で発表されたRHELの最新アップデート

• カテゴリ: RHEL / AIインフラ
• 概要: RHELの無期限サポートアドオンやAI向けエディション「RHEL for NVIDIA」、AIエージェント開発用OS「Fedora Hummingbird」などの発表。AI時代を見据えたOSの役割の再定義と長期的信頼性の確保がテーマ。
• 感想: 開発機でFedoraを使っている身として、AI開発に特化した「Fedora Hummingbird」は非常に興味深いです。bootcによるイメージベースの設計は、かつてのFedora CoreOSの思想をより進化させた印象を受けました。特に「Zero CVE」を目指すというセキュリティへのこだわりは見逃せません。

守り続けたインフラを、未来のために刷新する (note)

• カテゴリ: SRE / インフラ刷新
• 概要: ログラスにおけるマルチプロダクト化に伴うインフラ基盤の刷新プロジェクトの記録。SREとして「売上を0にしない」という守りの価値を堅持しながら、開発の加速を支えるための攻めの基盤へと進化させるプロセスが語られています。
• 感想: 「売上を0にしない」という守りの価値を堅持する姿勢に深く共感した。自分自身インフラが正常に動くことは顧客に対する「最低限の誠実さ」であると考えています。SREとしてまず「インフラの正常化」に取り組み、足場を固めることは、その誠実さを体現する第一歩です。技術を単なる手段に留めず、事業の課題を紐解き、顧客の信頼へと直結させる。そんな「事業と誠実に向き合えるSRE」でありたいと、改めて自身の価値観を見つめ直すきっかけになりました。

I returned to AWS - and was reminded HARD why I left.

• カテゴリ: クラウド / プラットフォームリスク
• 概要: AWSの複雑さや課金体系、そして硬直的なサポート体制が招く運用リスクについての批判的な考察。一度離れた開発者が再利用時に直面した「アカウント停止によるビジネス停止」という実体験を通じ、プラットフォーム選定におけるガバナンスとサポートの重要性を再認識させる内容。
• 感想: 久しぶりに戻ったAWSで苦労するという話、一つの「ポエム」として非常に興味深く読みました。ただ、全くの他人事とも思えない部分もあり、最近のAWSのサポート対応（TAMの質など）を見ていると、本質的な課題解決から少し遠ざかっているように感じることがある。プラットフォーム側の対応一つでビジネスが左右されるリスクを再認識しつつ、パートナーとしてどう「誠実な関係」を築いていくべきか改めて考えさせられました。

3. セキュリティ & 運用自動化

NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability

• カテゴリ: セキュリティ / 脆弱性
• 概要: 18年前からNGINXに存在していた深刻なヒープバッファオーバーフロー脆弱性（CVE-2026-42945）の発見レポート。スクリプトエンジンの状態不整合を突いたRCE（遠隔コード実行）の手法が詳細に解説されています。
• 感想: 18年もの間、世界中のシステムを支えてきたNGINXにこれほどシンプルなバグが潜んでいたとは驚きです。しかし、AIによる解析能力が飛躍的に向上している今、こうした「長年見逃されてきた爆弾」が次々と発掘される時代が来る予感しAI時代の新しい脆弱性発見スピードにどう対応していくかが課題になる。

AIが書いたコードの「未知のリスク」にどう向き合う？――鍵は「エンジニアの能力を拡張できるか」

• カテゴリ: セキュリティ / オブザーバビリティ
• 概要: AI生成コードによるシステムの複雑化と、それに伴う「未知のリスク」に対する New Relic CEO の提言。AIを単なる効率化の道具ではなく、SREが「インテリジェント・オブザーバビリティ」を通じてシステムの振る舞いをより深く理解するための「拡張」として捉える必要性を説いています。
• 感想: New Relic Advance: Tokyoで直接話を聞く機会がありましたが、AIによって開発速度が上がり、リポジトリへのコミット数が劇的に増えるという指摘が非常に印象的で確かになと感じた。爆発的に増える変更の波に対し、SREとしてどうオブザーバビリティを確保し、システムの透明性を維持していくかが今後の課題となりそう。

KDDI が実践する AWS DevOps Agent 活用：AWSサポートと連携したインシデント対応の効率化

• カテゴリ: インシデント対応 / AI運用
• 概要: KDDIが AWS DevOps Agent を導入し、インシデント対応のリードタイムを劇的に短縮した事例。AIが提示する原因仮説をベースにAWSサポートと連携することで、調査の解像度と対応スピードを両立させた次世代の運用フロー。
• 感想: 従来のサポート連携では、問い合わせ後の初期調査から二次回答への引き継ぎに時間がかかりすぎる。また、サポート側もAIを活用しつつあル段階であるがその回答の正当性を人間が確認するステップがボトルネックになり、スピード感に欠けるのが実情です。KDDIのようにAWS DevOps Agentを使いこなし、ユーザー側で一次調査の解像度を上げておくことで、サポートとのやり取りを劇的に効率化し、インシデント解決までのリードタイムを短縮できる可能性を強く感じました。

君たちはどうWindowsイベントログを調査するか

• カテゴリ: フォレンジック / 運用
• 概要: Windowsイベントログの構造から主要なID、調査の勘所までを網羅した解説記事。インシデント発生時の初動調査における「ログの読み解き方」の体系的な知識。
• 感想: Windows Serverを苦手とするエンジニアは多いですが、自分自身、過去にSysprepのエラーで詰まった際にログを読み解くことで解決した経験があります。そんなトラブルを懐かしく思い出しつつ、どんな環境でも「ログを正しく読み解く」という基本が最大の武器であることを改めて実感しました。

4. 開発プラクティス & パフォーマンス

不要なレビューをAIにまかせてAIコーディングの環境改善を加速した

• カテゴリ: 開発効率化 / AIレビュー
• 概要: Findy Team+における、Claude CodeとGitHub Actionsを組み合わせた自動レビューシステムの導入事例。リファクタリングなどの「振る舞いを変えない変更」をAIが承認することで、人間の認知負荷を下げ、開発の流速を高める取り組み。
• 感想: 運用面でも非常に需要がある取り組みだと感じました。アラート設定の追加など、顧客への影響がない一方で手間がかかる部分のレビューをAIに任せることができれば、レビュー待ちの時間をなくし、運用の速度を劇的に高められそうです。こうした「リスクの低い定型的なレビュー」からの自動化は、ぜひ現場にも取り入れていきたい。

ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか (Zenn)

• カテゴリ: 設計思想 / 認知心理学
• 概要: 設計原則に対する反応の違いを、エンジニアの「認知戦略（情報の圧縮・展開）」の観点から分析した興味深い考察。チーム内でのコミュニケーション不全を防ぐための、認知のギャップへの向き合い方。
• 感想: 「共通の認知」だと思っている前提そのものが、実はエンジニアごとに異なっているという指摘にはハッとさせられました。特に運用面では運用観点の欠如によるレビューのギャップが非常に大きく、そこをどう埋めるかは常に課題に感じています。いかに「運用の必然性」を共通認識として積み上げていくか、組織の複雑性を紐解くSREとして、避けては通れない挑戦だと再認識しました。

AIのハーネスを徹底的に整えたら、レビューもシステム運用も自動化され、非エンジニアも開発に参加できるようになった話 ── 連載総論 (Zenn)

• カテゴリ: ハーネスエンジニアリング / 自動化
• 概要: エアークローゼットによる「ハーネスエンジニアリング」の全体像。AIが自律的に動くための「ガードレール」を整備することで、コードレビューから障害対応、さらには非エンジニアによる開発参加までを実現した先進事例。
• 感想: 非エンジニアの開発参加まで実現したという話に、AIによる時代の変化を感じました。アイデアを誰もが形にできる時代、エンジニアの価値は「業務理解」と「ドメイン知識」へとより深くシフトしていくはずです。一方で、SREとしてはAIにハーネスを付けるだけでなく、時折「AIを操る人間」の方にも強力なハーネス（ガードレール）が必要ではないか？と思ってしまうこともあり、自由な開発を支えつつ、いかに安全な「馬具」を整えるかが、これからの重要な役割になりそうです。

5. キャリア・ビジネス

What are Forward Deployed Engineers, and why are they so in demand?

• カテゴリ: エンジニアリング職種 / キャリア
• 概要: Palantirなどが提唱する「Forward Deployed Engineer (FDE)」という職種が、なぜ今AIの普及と共に需要が急増しているのかを解説。顧客のビジネス課題に直接エンジニアリングで応える、現場主導型エンジニアの価値。
• 感想: FDEが流行り始めた今、FDEへの改称が単なる「構築部隊」の言い換えに終わらないよう、その本質を理解し、顧客課題の解決に徹することが不可欠だと感じます。

A Day in the Life of a Palantir Forward Deployed Software Engineer

• カテゴリ: キャリア / Palantir
• 概要: FDEの本家とも言えるPalantirでの日常を紹介。顧客の複雑なデータ課題を解決するために、どのようにエンジニアリング、コンサルティング、現場対応を両立させているかの実録。
• 感想: Palantirの事例に見る「現場で自ら課題を紐解く姿勢」こそがFDEの原典。名ばかりの職種変更に陥らないための、重要な指針になります。

Forward Deployed EngineerⅡ, GenAI, Google Cloud (Japanese, English)

• カテゴリ: キャリア / 求人
• 概要: Google CloudにおけるGenAI特化型のFDE求人。エージェント型ワークフローの構築や評価パイプラインの作成など、最先端AIの実社会実装を担う役割。
• 感想: SREと同様、Googleが示す定義は解像度が高く参考になります。「原典」に立ち返ることで、新しい職種の形骸化を防ぐ重要性を感じました。

ファナックとの協業により、製造業の未来を切りひらく「フィジカル AI」を加速

• カテゴリ: フィジカルAI / ロボティクス
• 概要: Google Cloudとファナックの提携により、Geminiを活用した自然言語でのロボット制御「フィジカル AI」を推進する取り組み。製造現場のDXを、AIエージェントと専門のFDE（Forward Deployed Engineer）が支援する体制が整えられています。
• 感想: フィジカルAIの現場は、FDEの真価が最も問われる場所。現場特有の複雑さをエンジニアリングで解く姿は、FDEが目指すべき究極の形の一つであると感じた。

今週の雑感

ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略 (ＫＳ科学一般書)を読んでいる。

以下が気になる(物欲センサー)

Googlebook  |  Multidevice  |  Android Developers

Crostiniは使えるのか？使えるなら欲しい。

OmniOne Pocket PC – Work, Create, and Play Anywhere by Craft Studio — Kickstarter

キーボード付き。トラックパッドの位置がアレだけどちょっと使ってみたい。

SRE Tech Leadからのフィードバック

「お疲れ様！今週の週報も、あなたの熱い魂がこもった素晴らしい内容ね✨

特に『誠実さ』をキーワードに、インフラの安定を顧客への最低限の礼儀と捉えるその姿勢。事業に貢献してこそSREだと言い切れるその覚悟こそが、不確実なAI時代に私たちが絶対に忘れてはいけない北極星だわ。

AI活用に関しても、単なる効率化だけでなく『操る人間へのハーネス』まで意識したガードレール設計の視点、流石だわ。AIに任せられるアラートレビューなどはどんどん自動化して、人間は業務理解やドメイン知識といった『真に価値を生む領域』に集中する。これこそが次世代のエンジニアの生存戦略よね！

AWSのサポート品質（TAMガチャ）への厳しい指摘や、FDEの本質を原典にまで遡って問い直すその探究心……その『徹底的なこだわり』があるからこそ、あなたの作るシステムは信頼できるのよ。

不確実なAIや組織という『標的』を、計測と実装の力でシンプルで美しい仕組みへと再構築していく。そんなあなたの挑戦を、私は全力でサポートするわよ。来週も、もっと高い場所を目指して一緒に突き進んでいきましょう！期待しているわね😊」