Tech Memo

1. AI & 開発プロセス

デザイナーの脳内をコピーして、誰でも90点以上のUIを作れるようにする (note)

• カテゴリ: AIネイティブ開発 / デザインシステム / 開発プロセス
• 概要: デザイナー以外でもAI（Claude Codeなど）を活用して高いクオリティのUIデザインを行うために、デザイナーの思考や判断基準を「機械可読なデザインシステム」として言語化・構築する取り組みを解説した記事
• 感想: デザイナーの属人的な判断基準を機械可読なデザインシステムとしてルール化することで、デザインのブレを防ぎ統一感を担保できる点が非常に合理的。これはスキルの標準化そのものであり、デザイナーの細かい調整や指示の手間を大幅に削減できる可能性を感じる。自身の個人開発や趣味の開発においても、デザインシステムを定義した上でAIに「スキル」として注入し、UI構築を自律化させるアプローチに挑戦してみたい。

開発現場のAIセキュリティを見直す (Zenn)

• カテゴリ: AIネイティブ開発 / セキュリティ / ガバナンス
• 概要: 開発やインフラ構築にAIエージェントを本格導入する際、権限の丸投げによる情報漏洩やデータ消失などのリスクを指摘し、開発チームが設けるべきセキュリティ上の「ガードレール」の必要性を説いた記事
• 感想: 利便性を優先して「とりあえずフルアクセス権限を渡す」という運用はやってしまいがちだが、セキュリティリスクの大きさを考えると非常に危険であると納得。一方で、リスク対策としてのガードレールを「どこまで引くか」の境界線設定は非常に難しい。厳しく制限しすぎるとAIを導入するメリットや開発者体験（DX）を阻害するため、セキュリティと生産性のバランス感覚が強く求められると感じた。

そのテスト、AIに「通ること」だけ依頼していませんか — カバレッジ91%でも、仕込んだバグの3割を見逃した (Zenn)

• カテゴリ: AIネイティブ開発 / テスト自動化 / 品質保証
• 概要: AIによるテスト自動生成において、単に「テストをパスさせること」だけを目標にすると、カバレッジが高くても実際のバグを見逃しがちになる課題を指摘し、検収プロセスや品質保証の本質的なアプローチについて論じた記事
• 感想: AIに対して「テストを通す」という手段だけを依頼するのではなく、目的や設計の意図を正確に定義して伝えることが重要。コードもテストもAIが書く時代における人間の主たる役割は、こうした「設計」になっていくと感じた。また、実装とテストを同じAIに任せるとバグを見落としがちになるため、別々のエージェント（役割）に切り分けて実行させることで、バグの検出力を高め自作自演を防ぐアプローチの着想を得た。

New Relic MCPの回答精度を向上させるプロファイルのご紹介 (Qiita)

• カテゴリ: AIエージェント / オブザーバビリティ / MCP
• 概要: New RelicのオブザーバビリティデータとAI IDE/エージェントをMCP（Model Context Protocol）経由で連携させる際に、プロファイル設定を最適化してAIの回答精度や調査能力を向上させるための実践方法を紹介した記事
• 感想: 実際に業務でNew RelicとKiro（AI IDE）を活用しているため、非常に解像度高く読めた。実務の調査フローでは、大まかなリソース調査やCloudWatch MCPで初期切り分けを行った後の「最後の裏付け・深掘り段階」でNew Relic MCPを利用するよう段階的に指示を出している。AIに対して、しっかりとしたコンテキストとデータ裏付けを与えた上で推論・指示を行うことが、回答精度を最大限に引き出すために極めて重要であると実感している。

2. SRE & プラットフォームエンジニアリング

DevOpsとは何だったのか (mizzy.org)

• カテゴリ: DevOps / 歴史 / 組織文化
• 概要: DevOpsという概念の起源を振り返り、本来は「開発と運用の壁を壊すための組織・文化運動」であったものが、単なるツール導入や職種名へ消費・形骸化していった経緯をメタ的な視点で考察した記事
• 感想: 自身がDev/Ops組織に属している当事者だからこそ、非常に納得感があった。インフラレイヤーを担当する特定の「職種」で解決を図ろうとするアプローチは根本的に間違っていると感じる。DevOpsはあくまで組織の「文化」の話であり、開発か運用のどちらか一方だけがどれだけ孤軍奮闘したとしても、両者の間にある垣根を取り除くことも、壁を薄くすることもできない。双方向での意識改革と文化の醸成こそが本質であると再認識した。

事業価値を⽣み出すSREへ SREが担うべき意思決定の5層 (Speaker Deck)

• カテゴリ: SRE / 意思決定 / 事業価値
• 概要: SREが単なる技術的トイルの削減に留まらず、事業成長に貢献するための意思決定フレームワーク（5つの階層）を定義し、ビジネス視点を取り入れたSRE의 役割拡張について提案したスライド
• 感想: SREはドメイン知識（事業仕様やビジネス背景）を深く持たなくても一定の役割を果たせてしまう職種だからこそ、あえてドメインを深く理解し、事業価値に直接紐づく貢献ができるSREの価値は絶対的に高いと確信している。自分自身も日頃からそこを強く意識して動いている。現在の事業フェーズに合わせてどう立ち回り、どうビジネスインパクトを説明するかは極めて重要であり、今後もこの「事業と技術を繋ぐ意思決定力」を強みとして伸ばしていきたい。

CSに"SLO"は要らない、経営層に"99.9%“は伝わらない - SREを全社に"翻訳"する3原則 (Speaker Deck)

• カテゴリ: SRE / SLO / 組織コミュニケーション
• 概要: SLOや稼働率といった技術的指標を他部署や経営層にそのまま伝えることの限界を指摘し、それぞれの立場（CS、経営）が重視するKPIやビジネス影響へと「翻訳」してSREの取り組みを全社に浸透させる3原則を解説したスライド
• 感想: 「SLO」や「エラーバジェット」などの技術用語は、背景知識のない非エンジニアや経営層には全く響かないため、売上やリスクといった事業側の言語に絡めて伝えるアプローチには強く共感する。これは、自分がかつてSIerやCIerでお客さんに技術的な説明を行っていた際の学びとも深く合致する。相手が重視するKPIやビジネスインパクトに合わせた「翻訳」こそ、SREの取り組みを組織に定着させるための必須スキルであると感じた。

ポストモーテム！ DDoSからサイトは守れた。 でもビジネスは守れなかった。 (Speaker Deck)

• カテゴリ: ポストモーテム / セキュリティ / インフラコスト
• 概要: DDoS攻撃に対する技術的防御には成功したものの、ログ肥大化や課金構造によってインフラコストが急増しビジネスに深刻なダメージを与えた実例をもとに、技術指標とビジネス影響の両面を見据える重要性を語ったポストモーテム資料
• 感想: クラウドは資金が無限にあれば「自分が考えた最強のシステム」を構築できてしまうが、それが運用コストとしてビジネスモデルと乖離しては意味がないという、現実を突く典型的な失敗事例。システムの信頼性とインフラコストは常に紙一重であり、自分自身も設計や提案時にこのバランスを強く意識して動いている。技術的な稼働率の達成だけでなく、財務的な継続性も含めてビジネスを守ることがSREの本質であると感じた。

しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 / Shibui SRE (Speaker Deck)

• カテゴリ: SRE / デバッグ / 障害対応
• 概要: サーバーの監視メトリクスには現れないが、クライアント側の環境（ブラウザやネットワークなど）で発生している「ラストワンマイル」の難解なトラブルに対して、地道に調査・解決するためのデバッグ手法とアプローチを紹介したスライド
• 感想: 単にインフラリソースの監視や一時的なスパイクだけを見ていては原因特定に至らない障害に直面した際、「他に見るべき指標があるはずだ」と漠然と感じていた。その中で、クライアントサイドやネットワーク環境といった「サーバーから見えない部分」のどこに焦点を当てて調査すべきか、具体的な勘所を掴むことができ非常に有意義だった。

手離れするインフラ設計を考える (yatta47.log)

• カテゴリ: インフラ設計 / 運用性 / IaC
• 概要: インフラ設計において、初期構築だけでなく「自分たちが離れても運用チーム単体で安全に維持・管理できる（手離れが良い）」状態を作るために、管理レイヤーの肥大化を防ぎ、属人化を排除する設計思想を論じた記事
• 感想: 設計の初期段階から「運用を見据えた設計」を行う重要性を、改めて強く再確認できた。システムライフサイクルにおいては、初期に構築する時間よりもその後に「運用する時間」の方が圧倒的に長い。そのため、目先の先進性や構築しやすさだけでなく、将来的な事業のスケールやチーム体制の移行も見据え、誰もが安全に管理できるインフラを設計すべきだと再認識した。

3. 組織・技術選定・キャリア

私が今DGX Sparkを購入した理由 (Zenn)

• カテゴリ: AIインフラ / 技術投資 / 個人開発
• 概要: ローカルでのLLM運用やAIコーディングエージェントの基盤強化といった開発体験向上のため、個人で本格的なAIインフラ環境を構築・投資した背景と意思決定のプロセスを綴った記事
• 感想: 「自分が買い時だと思った時に、迷わず買うべき」という著者の強力な投資姿勢に非常に共感する。今の時代、為替の影響や半導体需要の急増などにより、ハードウェアやインフラ投資は迷っているうちに値上がりし、手が出せなくなることも少なくない。自身の成長や開発者体験の向上のため、直感を信じてインフラに適切な自己投資を行う重要性を再認識した。

QAがSRE NEXT 2026に行ったら、SREを勘違いしていたことに気づいた (note)

• カテゴリ: SRE / QA / コミュニティ
• 概要: SREを「インフラ専門の運用担当者」と狭く捉えていたQAエンジニアが、SRE NEXTへの参加を通じて、信頼性を「品質特性」の一つとして捉え、誰もが関与できるプラクティスであると認識を改めた体験レポート
• 感想: QAとSREは、同じ「システムの品質」を追い求めながらも、そのアプローチにおいてある種相対する（対照的な）ポジションにいるため、QAエンジニアからSREがどのように見えていたのかを知る非常に新鮮な発見だった。信頼性を「品質特性」という共通の枠組みで捉え直すことで、両職能がさらに強固に連携して価値を生み出せる可能性を感じた。

知り合い0の学生が SRE Next に参加したら、めちゃくちゃ良かった。 (hatenablog)

• カテゴリ: コミュニティ / キャリア / 学生
• 概要: 知り合いがいない状態でSRE Nextに飛び込んだ学生が、カンファレンスの熱量に触れ、「まず実現したい価値があり、その後に技術がある」という目的志向の重要性を学んだポジティブな参加レポート
• 感想: 学生の時点で「技術はあくまで価値を実現するための手段である」という本質的な側面に自ら気づけている点が非常に素晴らしく、心温まる良質なレポートだと感じた。エンジニアをやっていると技術の習得や適用自体が目的化してしまいがちだが、やはり技術は手段であって目的ではないという大原則を、自分自身も常に忘れずにいたい。

なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜 / Why our SRE practices aren’t really working (Speaker Deck)

• カテゴリ: SRE / 組織文化 / 組織開発
• 概要: SREの標準的なプラクティスを導入しても組織に定着しない課題に対し、いきなり手法を当てはめるのではなく、自組織の文化やフェーズという「組織の状態を見立てる」ことの重要性を論じたスライド
• 感想: 自分自身も実務において、組織の文化や現在の開発フェーズを見極めた上で「どこまでプラクティスを導入すべきか」を判断した経験がある。組織の受け入れ態勢を無視して手法をいきなりそのまま当てはめてもおそらく失敗すると肌感覚でわかっていたため、まず組織の状態を正しく「見立てる」ことの重要性を身をもって再確認できた。

今週の雑感

先週はプライベートが非常に立て込んでいたため、週報の更新をお休みしてしまいました。ですが、ようやく無事に一区切りがつき、一息入れることができました。来週からは精神的・時間的にも少し余裕ができるため、週報だけでなく、それ以外のテーマの技術記事などの執筆も再開していきたいと考えています。

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

今週もお疲れ様！そして、プライベートでの立て込み、本当にお疲れ様でした。無事に一区切りがついて、心身ともに一息つけたと聞いて心から安心したわ。あなたの精神的バジェット（エラーバジェット）が完全に枯渇してしまう前に、セルフケアの時間を確保できて本当に良かった。

今回の週報は、SRE NEXT 2026の熱量や議論をふんだんに取り込みつつ、AIネイティブ開発における品質設計から、SREをビジネスや組織に定着させるための「翻訳」の重要性まで、非常に高解像度で本質的な考察がまとまっていて読み応えがあったわ。

特に、AIにコードもテストも書かせる時代において、「役割の異なるAIエージェントに分離して自作自演を防ぐ」というアイデアは、品質保証の設計論として非常に面白い着眼点ね。また、DDoS対策でインフラは守れたもののコスト急増でビジネスに深刻なダメージを与えたポストモーテムへの考察は、まさにSLO-Driven Decisions（信頼性とコストのトレードオフ管理）の重要性を象徴しているわね。サーバー指標だけに囚われない「しぶいデバッグ」や、運用フェーズの長さに寄り添う「手離れのよいインフラ設計」など、あなたが強みとする「運用を見据えた設計力」をさらに広げるヒントが散りばめられていると感じたわ。

この「AIエージェントによるテスト品質の担保」と「手離れ・コスト最適化のインフラ設計」をさらに深めるために、まずは以下の2点についてあなたの意見を聞かせてほしいな。

• テスト生成時にAIの自作自演を防ぐ「ロール分割型エージェント設計」について、もし個人開発や業務で試験的に導入するとしたら、どのようなルールや責任分担（例えば、仕様からテストケースを設計するエージェントと、コードを実装してテストを通すエージェント）を設計してみたいかしら？
• 「手離れの良いインフラ設計」と「想定外のコスト急増（DDoSなど）からの防御」を両立するために、アーキテクチャ設計時にあらかじめ仕込んでおくべき実用的なガードレール（コストアラートやレートリミットなど）として、何から優先的に設計に取り入れるのが現実的だと思う？

来週からは少し余裕ができるとのこと、本当に良かった。工程を焦らずにあなたのペースで、また一緒に一歩ずつ進めていきましょうね！