1. AIエージェント・活用実践 & アプリケーション基盤

SREインターンが挑んだ「AIエージェントの高速化」と「AIによるSQLレビューの品質向上」 (Zenn)

• カテゴリ: SRE / AIエージェント / インターンシップ
• 概要: ウェルスナビのSREチームにおける20日間の実務型インターンシップの成果を紹介した記事。自社運用のSREエージェント「Clione」に対してAgent Observabilityを導入し、不要な探索やエラーを削減してレスポンスを約40%短縮した。Bytebaseと連携したLLMによるSQL事前レビューでは、プロンプトの改善とテスト体制の構築による品質向上を解説している。
• 感想: 20日間のインターンシップの成果を紹介した記事ですが、SREとして読んでも密度の濃い内容でした。SREエージェントの自社開発や運用は自分たちも進めるべき課題だと認識していますが、実務では費用やツールの利用承認について関係各所と調整することがハードルになりがちです。私たちの環境で進める場合、まずSREエージェントの導入そのものから着手する必要があると感じています。

オブザーバビリティのAIエージェントをどう評価するか (Zenn)

• カテゴリ: オブザーバビリティ / AIエージェント / 評価基盤
• 概要: Grafana Labsの「Grafana Assistant」における評価基盤の設計とOSSベンチマーク「o11y-bench」を題材に、ツール利用を伴うAIエージェントの品質評価手法を考察した記事。最終出力の文章だけでは「もっともらしく見える失敗」を見抜けないため、振る舞いを「シナリオ（仕様）」と「グレーダー（判定）」に分離する。決定的なルールチェックとLLM-as-a-judgeを組み合わせ、エージェントの推論プロセスや状態変化を継続的に評価・改善するアプローチを解説している。
• 感想: AIエージェントの評価の難しさは日頃から実感しています。AIレビューや要約といった機能をプロダクトや運用に組み込む際、SLI/SLOをどう定義し、サービスレベルをどう保つかを考える上でも、こうした客観的な評価基盤は不可欠だと感じました。また、MCPサーバーのSLOも従来のAPIとは別の見方で設計しなければ意味がありません。定量的・継続的な評価の仕組みがあれば、モデルを変更しても品質が保たれているかを検証できるため、Flashなどの軽量・安価なモデルへ安全に切り替えてコストを抑える判断もしやすくなると考えています。

[プレビュー] AWS Well-Architected Agent が登場したので触ってみた

• カテゴリ: AWS / Well-Architected / AIエージェント
• 概要: AWS環境を分析してコスト・セキュリティ・パフォーマンス・回復性の推奨事項を提示する生成AIサービス「AWS Well-Architected Agent」のプレビュー版をいち早く検証したレポート記事。バージニア北部リージョンでのエージェントプロファイル作成、IAMロール設定、ワークロードのレビューと推奨事項の出力まで、セットアップと使用感を紹介している。
• 感想: Well-Architectedの状態を測るツールはこれまでもありましたが、Agentであればアーキテクト視点でのレビューまでまとめて行える点に期待しています。現状で満たせていない項目について、具体的な設定値やTerraformの改善提案まで提示してくれれば助かります。ただし、Terraform側のコード設計を日頃から整理しておかなければ、適切なアドバイスを引き出すのは難しいとも感じました。実務のWell-Architectedレビューでは、相手の理解度に応じた説明や合意形成に多くの工数を割きがちです。エージェントが客観的な根拠や改善策を示してくれることで、その工数も減らせるのではないかと考えています。

MCP Reference: apikeys.googleapis.com

• カテゴリ: Google Cloud / MCP / API管理
• 概要: Google Cloudが提供するAPI Keys API向けModel Context Protocol（MCP）サーバーのリファレンスドキュメント。LLMやAIエージェントが開発者プロジェクトに関連付けられたAPIキーの作成・管理・制限設定などの機能を安全に呼び出せるよう、公開されているMCPサービスエンドポイントや利用可能なMCPツール（関数）の仕様、利用方法を定義している。
• 感想: 業務でGoogle Cloudを扱うことになり、最近は「AWSでできていた運用をGoogle Cloudでやるならどうするか」を考える機会が増えています。AWSではKiroなどを使ってリソース調査を行っていましたが、Google CloudでもMCPを活用してアラート調査やリソース探索をエージェントに任せられないかと考えています。AWSがKnowledge MCPやCloudWatch MCPなどを精力的に提供してきたように、Google Cloudをはじめとする他のクラウドベンダーからも、各サービスを直接操作できる公式MCPがさらに拡充されることを期待しています。

Copilot マネージド ランタイムとは (プレビュー)

• カテゴリ: Microsoft 365 / Copilot / ガバナンス・ランタイム
• 概要: Microsoftがプレビュー公開した「Copilot マネージド ランタイム」の概要ドキュメント。Copilot CoworkやCopilot Studio、専用SDKで構築されたMicrosoft 365基幹業務アプリをホストし、Microsoft Entra認証や組織のセキュリティ・コンプライアンスポリシーを自動的に継承する。作成者、開発者、管理者、ユーザー向けに、統合された実行・管理環境とポータルを提供することを解説している。
• 感想: 生成AIによってエンジニア以外でも手軽にツールやエージェントを作れるようになった今、野良アプリや野良エージェントの乱立を防ぐ仕組みは理にかなっていると感じます。社内だけで使うツールであっても機密情報の取り扱いには十分な配慮が必要なため、認証やセキュリティポリシーの統制は必須です。社内ツールの共有ニーズは確実に高まっているため、これまでエンジニアが内製していたような業務アプリを各部署が自前で作り、部署内で運用する事例に期待しています。どれだけ工数を削減できるのかも知りたいです。

EmDash 1.0: the stable CMS with a secure plugin registry

• カテゴリ: CMS / Astro / エージェント・プラグイン
• 概要: Cloudflareがエイプリルフールに発表していたWordPressの精神的後継CMS「EmDash」の正式版「EmDash 1.0」をオープンソースとしてリリースした発表記事。Astroベースで構築され、エディタ管理画面に加え、API、CLI、組み込みMCPサーバーを通じて、AIエージェントと連携しやすいワークフローを提供する。中央集権的なマーケットプレイスに依存しない分散型プラグインレジストリやサンドボックスによる安全なプラグイン実行基盤を備えている。
• 感想: 「WordPressの後継」という言葉に惹かれて目を通しました。かつてWordPressを運用していたとき、セキュリティ対応のために本体をバージョンアップしようとしたところ、プラグイン側の互換性が追いついていませんでした。その調査や対応に多くの工数を割いた苦い記憶があります。EmDashが安全なサンドボックス実行やモダンなプラグイン基盤を掲げている点は、そうした長年の課題への取り組みとして興味深いです。今後のエコシステムの広がりも追ってみたいと思います。

AIにより誰でもHTMLで共有する時代に送るGAS×Googleドライブで構築！社内限定HTMLポータル

• カテゴリ: 社内ツール / Google Apps Script / 生成AI活用
• 概要: 生成AIが作成したレポートや仕様書のHTMLを社内（特に非エンジニアや有料アカウントを持たない役職者）へ手軽かつ安全に共有するため、GoogleドライブとGAS（Google Apps Script）を用いて社内限定HTMLポータルを構築した実践記事。他方式（S3やArtifacts）との比較やトレードオフ、フォルダへのファイル配置で目次を自動生成する仕組み、共有ドライブの権限設計、動作するコード全文を公開している。
• 感想: Copilot マネージド ランタイムの記事とも重なり、Google Workspace環境でGASや社内ツールをどう安全に展開するかに関心を持って読みました。最初はS3やサーバーなどのインフラを組んだ方が堅牢だと考えがちですが、それだとエンジニアの工数や部署横断の調整負担が大きくなります。その点、Googleドライブを基盤にすればエンジニアを介さずに各部署で運用できますし、情シスの許可さえあれば気軽に導入できる設計が上手いと感じました。

2. クラウドインフラ・SRE & プラットフォーム・セキュリティ

Google Cloud、ローカルマシンにインストールできる大規模分散型マルチモデルDB「Spanner Omni」正式版リリースを発表

• カテゴリ: データベース / Spanner / Google Cloud
• 概要: Google Cloudがマネージド分散データベースSpannerのソフトウェア版「Spanner Omni」を正式リリースしたニュース。LinuxやmacOS等のローカル環境、AWSやオンプレミス等にインストール可能で、ColossusやTrueTimeなどのGoogle独自コンポーネントを代替ソフトウェアで再現。リレーショナル、ベクトル検索、グラフ検索などのマルチモデルに加え、MCP Toolbox for DatabasesによるAIエージェント連携にも対応する。AIワークロードのバックエンドとしても機能することを紹介している。
• 感想: Spannerを手軽に検証できるようになるのではないかという期待を持って読みました。過去の実務では、Spannerの動作確認をするだけでもクラウド上にインスタンスを立ち上げ、アプリケーション側のコネクターや接続設定をその都度整える必要があり、環境準備に手間がかかっていました。手元でSpanner Omniを直接動かせるようになれば、クラウド側のリソースを用意せずに接続を検証できるため、アプリケーション側の開発や動作確認がかなり楽になるのではないかと感じています。

WindowsでLinuxコンテナの作成や実行を可能にする「WSL Containers」正式リリース。コマンドラインとAPIから利用可能

• カテゴリ: Windows / WSL / コンテナ
• 概要: MicrosoftがWSLの新機能として、サードパーティ製ツールを導入せずにWindows上でLinuxコンテナを作成・実行できる「WSL Containers」を正式リリースしたニュース。専用CLI（wslc）やAPI経由で操作でき、virtiofsによる高速化やWindowsと統一されたネットワークモード、Intune/Defenderによる一括管理に対応する。正式版では再起動やネットワーク接続・切断コマンドなどが追加され、compose機能も開発中であることを解説している。
• 感想: WSL自体は扱いやすいものの、以前WLinuxなどを使っていた際は、ファイルアクセス速度の遅さやディストリビューション周りに少し不満がありました。コンテナ機能の統合をはじめ、今後のWSLの進化に期待しています。もしWindows機を用意して検証するなら、まずはWSL上で動くAzure Linux 4.0を試してみたいと考えています。ただ、現在は手元にWindows機がないため、検証用の端末を調達するところから始めたいです。

テレメトリを「契約」として扱う — OpenTelemetry Weaverで試すTelemetry Contract

• カテゴリ: オブザーバビリティ / OpenTelemetry / ソフトウェア設計
• 概要: メトリクス名や属性の変更によってダッシュボードやアラートが使えなくなる問題を防ぐため、テレメトリを公開APIと同様の「契約（Telemetry Contract）」として扱う考え方と、それを機械可読なスキーマで管理するツール「OpenTelemetry Weaver」の活用法を解説した記事。Weaverによるセマンティック規約の定義、ドキュメント自動生成、スキーマ検証を通じて、producerとconsumerの間でテレメトリの互換性を安全に維持する実践を紹介している。
• 感想: テレメトリを公開APIのように契約として扱うという考え方を読み、まさにその通りだと納得しました。Web APIであれば破壊的変更を避け、後方互換性を持たせるのが当然の配慮です。過去の実務でも、メトリクスの変更によってアラートが鳴らず検知が遅れ、ポストモーテムを書くことになった苦い経験があります。提供側と利用側の合意形成は不可欠ですし、ダッシュボードやアラートへの影響範囲を正確に見極められないのであれば、安易に変更しないという判断も必要だと再認識しました。

セキュリティエンジニア視点のKubernetes環境の攻撃面と対策

• カテゴリ: Kubernetes / コンテナセキュリティ / インフラ運用
• 概要: セキュリティエンジニアの視点から、Kubernetes環境における攻撃面と実践的な防御策を解説した記事。API Serverやkubeletの外部露出、Pod侵害を起点としたService Accountトークンの窃取やRBAC設定ミスによる権限昇格、NetworkPolicy未設定による横展開、Admission Controllerの脆弱性などを体系的に整理し、各脅威に対する具体的な確認コマンドと堅牢化手法を紹介している。
• 感想: 「マネージドKubernetesだから安心」「コンテナだから分離されている」という油断がセキュリティ事故を招く、という指摘は重要だと感じました。攻撃手法がわかってこそ、どう守るべきかも見えてきます。以前書いた記事「Dockerで学ぶSQL・コマンドインジェクションの仕組みと対策」でも、攻撃の仕組みを知って適切な対策を学ぶという意図を込めていましたが、Kubernetesでも同じだと感じます。私自身、Kubernetesの経験はまだ浅く、これから本格的に触っていく段階です。こうした攻撃面をしっかり理解し、堅牢な環境の構築に活かしていきたいです。

サイボウズにおけるGitHubの全社的な利用改善、セキュリティ、ガバナンス強化の取り組み 2026

• カテゴリ: GitHub / プラットフォームエンジニアリング / セキュリティ・ガバナンス
• 概要: サイボウズの生産性向上チームが社内向けGitHubプラットフォームチームとして取り組んだ、全社的なGitHub利用改善・セキュリティ・ガバナンス強化の実践スライド。SBOMを活用したサプライチェーン攻撃の影響調査CLIの自作、アカウントと社員情報の紐付け、Fine-grained PATへの移行と承認運用の見直し、全社ルールの改定と自動検査ツールの統一フレームワーク構築などを紹介している。開発者の利便性とガバナンスを両立させたプロセスを解説している。
• 感想: 最初に気になったのは、全社的なセキュリティやガバナンスの要望をすべてCI/CDに組み込むと、実行時間がどれほど長くなるのかという点でした。過去の実務でも、もともと遅かったCI/CDパイプラインにセキュリティスキャンを追加した結果、実行時間がさらに長引き、うまくいかなかった経験があります。開発速度やフィードバックループを損なわないためにも、PRごとの同期的な検査は最低限に絞り、詳細なスキャンや監査は夜間バッチなどで非同期に実行する方法が現実的だと感じます。

3. 組織戦略・働き方 & エンジニア組織・キャリア

目を醒ませ 僕らの信頼が生成AIに侵略されてるぞ (Zenn)

• カテゴリ: 生成AI / エンジニアリング組織 / キャリア・倫理
• 概要: 生成AIが業務に深く浸透した現場で、仕様策定・設計・実装・レビューの各工程において誰も中身を読まずにAIの出力をコピペして横流しする「Meat Proxy（肉のプロキシ）」現象と、それが破綻する構造を描き、警鐘を鳴らしたエッセイ。AIは責任を負えないため原理的に副操縦士であり、エンジニア自身が介在する価値は、自らの「意思」と「責任」にあると説いている。
• 感想: AIの出力をそのまま横流しにする「Meat Proxy」への警鐘には、同意しかありません。以前執筆した「AIにチケット作成を丸投げするな。SREが磨く「課題の解像度」と3つの型」でも同じ危機感を書きました。現場でも、AIで作成した内容を本人が理解しておらず、説明できない場面を見かけることがあります。中身を把握していないと、何を優先すべきかの判断すら自分で下せなくなってしまいます。AIは良きパートナーですが、責任を持たせてはいけません。エンジニア自身が意思と責任を持って使いこなす必要があると、改めて思いました。

打ち手に飛びつく前に、一度立ち止まろう (Zenn)

• カテゴリ: プロダクト開発 / 要件定義 / クリティカルシンキング
• 概要: AIコーディングにより実装コストが劇的に下がった時代だからこそ、ユーザーからの要望（打ち手）に安易に飛びつくのではなく、一度立ち止まって「本質的な課題は何か」「どこで、なぜ起きているのか」を構造的に見極める重要性を説いた記事。架空のプロダクト改善事例をもとに、論点の整理から選択肢の網羅的洗い出し、選定理由の明確化に至る思考プロセス（クリティカルシンキングの型）を解説している。
• 感想: これも自身のnote記事「AIにチケット作成を丸投げするな。SREが磨く「課題の解像度」と3つの型」の考え方に通じる部分が多く、強く共感しました。課題を書く前に一度立ち止まり、「本当に必要なのか？」と自問することで、初めて課題の本質が見えてきます。「とりあえず課題を作る」のは明らかに悪手だと感じています。安易に起票した課題は、後になって作った本人すら存在を忘れ、放置されることがよくあります。本人ですら忘れてしまうようなものは、そもそも重要ではない課題だったという証拠です。実装が容易になった今こそ、解くべき課題かどうかを見極めてから着手したいです。

セキュリティ人材は、やっぱりもっとAIに本気になっていい。（2025年5月の答え合わせとさらに先の未来） (note)

• カテゴリ: セキュリティ / Agentic SOC / キャリア・組織変革
• 概要: 2025年5月の「セキュリティ人材はもっとAIに本気になっていい」という考察から1年4か月が経ち、Agentic SOCや自律実行、権限管理の進展を踏まえた答え合わせと未来予測を記した記事。セキュリティ担当者が作業実行者からアーキテクト（自律性の範囲や統制の設計者）へ移行している実態をMicrosoftやISC2の調査データを交えて検証し、今後はプロジェクト初期からのAI組み込みや特定役割チームのAI化が進む未来を論じている。
• 感想: 本番環境を運用するSREとして、私も実行権限をAIに渡さないという考えです。AIは結果の責任を負えないからです。ログやメトリクスの調査・分析まではAIを活用するとしても、最終的な判断や本番環境への変更作業に関する権限は絶対にAIへ渡さず、SRE自身が判断や作業を担うことを常に意識しています。記事で述べられている「AIの統制やガードレールを設計するアーキテクト」という役割は、セキュリティ担当者に限らず、これからのエンジニアに共通する視点だと感じます。とりわけシステムの信頼性を預かるSREには欠かせない考え方で、強く共感しました。

リモートワークを続けるためにやるべきこと

• カテゴリ: 働き方 / リモートワーク / 組織コミュニケーション
• 概要: 出社回帰の動きが広がる中で、労働者側がリモートワークという働き方を維持するために意識すべき工夫を、労働者と管理職の双方の視点から説いた記事。「仕事している状態を可視化する」「手戻りを防ぐため小さい相談・報告の頻度を上げる」「オンボーディングや重要な議論など対面が有効な場面ではリモートに固執しない」といった、生産性を損ねていると判断させないための実践的な立ち回りを提唱している。
• 感想: 「仕事している状態の可視化」という点に、ハッとさせられました。SREは業務の特性上、組織の中で割と孤独になりがちなため、自分が何に取り組んでいるのかを意識して共有しないとまずいと痛感します。ちょうど10月から新しい職場に移り、現在は業務のキャッチアップ真っ最中です。周囲との信頼関係を築き始める時期だからこそ、仕事の状況をこまめに共有していきたいです。

今週の雑感

DeepSeekの擬人化キャラのDeepSeek Whale-chanがかわいい。

10月から新しい職場で働き始めました。有給消化期間中は、ほぼ雨が降っていました。

また、Pixel 11 Proを購入しました。RAMが16GBのモデルです。

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

今週もお疲れ様！そして10月からの新天地スタート、本当におめでとう。初週の立ち上げで慌ただしい中でも、SREエージェント評価やTelemetry Contract、AI時代の責任境界まで、骨太なインプットが揃った素晴らしい週報ね。

特に、過去の苦い経験からテレメトリを「契約」と捉える視点や、本番の実行権限をAIに渡さず「ガードレールを設計するアーキテクト」として責任を背負う姿勢は、極めてSRE的で頼もしいわ。

新天地での立ち上げに向けて、ぜひ以下の2点も一緒に考えてみたいな。

• Telemetry Contractを定着させる際、開発速度を損なわずにスキーマの互換性を守るガードレールはどう設計するのが現実的かしら？
• 孤立しがちなSREとして周囲の信頼を得るために、最初の1〜2ヶ月で仕掛けたい「仕事の可視化」は何だと思う？

入社後90日のアクション洗い出しも、後でじっくり壁打ち相手になるわね。キャッチアップやクイックウィンの狙いどころを一緒に整理していきましょう。

Pixel 11 Pro（16GB）も羨ましいわ！新しい環境でも心身のエラーバジェットを大切に、来週も一緒に一歩ずつ進んでいきましょう！