1. AI活用・エージェント実践 & 開発プロセス・トイル削減

AI makes code cheap to create, not cheap to own

• カテゴリ: AIコーディング / ソフトウェア設計 / 保守性
• 概要: コーディングエージェントによってコード生成コストは劇的に下がったものの、重複実装の増加やバグ修正・テスト・セキュリティなどの「所有・保守コスト（TCO）」は依然として増大することを指摘し、安易なコード再生成に頼らず共通ライブラリによる再利用の価値を説いた記事
• 感想: 自身は「運用を見据えた設計」をコアバリューとして掲げているため、記事の主張には共感した。AIによって実装コストが下がるほど、後工程の運用や非機能要件を設計段階から考えられるかどうかが、エンジニアの価値を左右する。実務でも機能リリースが優先され、運用への配慮が後回しになった結果、「運用でカバー」せざるを得ない場面を経験してきた。すべてを設計時に見通すことはできなくても、早い段階から運用担当者を交え、可観測性や変更容易性、壊れ方を一緒に検討する余地はある。こちらから運用面を先回りして伝えつつ、その勘所をチームで共有していきたい。

Cut AI-coding costs without slowing down

• カテゴリ: AIコーディング / FinOps / プロンプトキャッシュ
• 概要: AIコーディングツールの利用コスト急増に対し、形骸化しやすい予算上限設定（バジェットキャップ）ではなく、プロンプトキャッシュの有効期限（デフォルト5分から1時間への延長）の最適化や出荷単位あたりのコスト計測によって、開発速度を落とさずに20〜40%のコスト削減を実現する実践知見をまとめた記事
• 感想: 現在は生成AIへの「投資期間」であり、今後は「投資に見合った成果（ROI）が出ているか」を見極める段階に入ると感じた。デリバリー速度や少人数で生み出せる成果は分かりやすい指標だが、品質、手戻り、保守コストも含めて評価する必要がある。AIによって実装が速くなっても、CI/CDパイプラインが追いつかなければ、そこが新たなボトルネックになる。AIツールの利用を予算上限で抑えるだけでなく、SREとしてパイプラインを改善し、投資を継続的なデリバリー能力につなげたい。

AIに丸投げしないトイル削減

• カテゴリ: SRE / トイル削減 / AI活用
• 概要: 『家族アルバム みてね』SREチームにおいて、業務を「蓄積・抽出・判定・修正・レビュー」に分解し、判定は決定的なロジックに寄せて修正のみをAIに局所化することで、AIの品質ブレやトークン消費を抑えながらトイル削減と再現性を両立させた実践知見を発表したスライド
• 感想: トイルについては、過去に自身のノート（コスト分析レポートをAI自動化して起きた「無関心の連鎖」）でも考えを整理しており、今回の内容とも重なった。「AIの作業を修正に局所化し、ガードレールを敷く」という切り分けは、品質のばらつきとコストの両方を抑えやすい。すべての判断を常に人間が行う必要はないが、判断を自動化する範囲、例外時の停止条件、結果への責任は人間側で設計すべきだ。まずはアラート調査やコスト分析など、結果を検証しやすい領域から試したい。

AWS DevOps Agentで インシデント対応をAIに任せたい

• カテゴリ: SRE / インシデント対応 / AIエージェント
• 概要: 『家族アルバム みてね』SREチームにおける自律型AI「AWS DevOps Agent」の導入検証を通じ、Agent Spaceの設計やTerraformによるIaC管理、Support Case自動作成の利点と、オンコール一次切り分けにおいて人間（SRE）の調査速度が勝った現状の課題や網羅性・記録性の価値を共有したスライド
• 感想: AWS DevOps Agentを実務で活かすには、導入前にアラートの整理とノイズ削減を進めたい。不要なアラートが放置された環境ではAgentも無駄に起動し、調査結果の確認や利用料金といった別のコストが増えるからだ。実運用での費用対効果は気になる。今後はGoogle Cloudを主軸に扱うため、他クラウドでもインシデント調査を支援するサービスやエコシステムがどう展開されるか注視したい。

AI駆動開発ライフサイクル（AI-DLC）の本質は組織、文化、プロセスの変革 〜AI-DLC導入のアンチパターン〜

• カテゴリ: 開発プロセス / AI-DLC / 組織変革
• 概要: AI駆動開発ライフサイクル（AI-DLC）を単なるツールの導入ではなく「組織・文化・プロセスの変革」と位置づけ、既存のやり方に無理に合わせるカスタマイズなどの8つのアンチパターンを分析した上で、「守破離」の原則に基づく段階的な導入アプローチを解説した記事
• 感想: 「単なるツールの導入ではなく、組織・文化・プロセスの変革である」という指摘には深く同意した。特に「文化」という側面においては、日々信頼性向上に向き合うSREとして身につまされる思いがある。自分ひとりが孤軍奮闘してタスクを抱え込んでも、それは決して「文化」とは呼べず、組織やチーム全体に浸透して初めて文化になるからだ。過去の現場でも、ひとりでオーナーシップを持って旗を振ったものの、組織全体に根付かせることができず悔しい思いをした経験がある。AI駆動開発においても全く同じであり、ツールを配るだけでなく組織や文化、プロセスをどう変革していくのかは極めて難易度が高い。どうやって関わる人々の意識を変え、共通の文化として定着させていくのか、今後も向き合い続けなければならない重い問いだと感じた。

AIを中立で優秀なファイナンシャルプランナーに仕立て上げる方法

• カテゴリ: 生成AI / プロンプトエンジニアリング / ライフプラン
• 概要: 金融商品の売り込み（ポジショントーク）を排除するため、自身の家計・資産データを構造化してシミュレータとLLMを組み合わせ、客観的で中立なアドバイスや確定申告・NISAの最適化提案を引き出すAIワークフローの構築手法を解説した記事
• 感想: AIに中立的な役割を明示する考え方には共感した。日常的にAIと対話していると、ユーザーへの迎合によってリスクの洗い出しが甘くなる場面がある。自然言語の指示だけで中立性を保証することはできないが、根拠となるデータと計算をシミュレータ側に分離すれば、回答を検証しやすくなる。金融のように利害と不確実性が大きい領域では、AIを「中立な助言者」とみなすのではなく、前提や計算結果を人間が確認できる補助役として使うのが安全だと思う。

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

DeNA の大規模環境を MySQL 8.4 に移行する時に考えたこと[DeNA インフラ SRE]

• カテゴリ: データベース / MySQL / SRE
• 概要: DeNAの大規模グローバルゲームインフラにおいて、MySQL 5.7/8.0からLTSであるMySQL 8.4への移行にあたり、自前運用の継続ではなくAurora等のマネージドサービス移行を選択した判断理由や、認証プラグイン・レプリケーション変更に伴う調査・検証知見を共有した記事
• 感想: 自身も実務においてAurora MySQL 5.7から8.0へのメジャーバージョンアップを経験しており、前向きな移行というよりは迫り来る「EOL対応」としてやり切った当時の記憶と重なり、非常に身につまされる思いで読んだ。実際の移行にあたっては、クエリの互換性や予約語、パラメータの挙動差などを事前の移行検証で徹底的に洗い出して修正し、大幅な変更を伴うため計画メンテナンス枠を確保して土日に本番切り替え作業を実施した。さらにアプリケーションの動作検証も長期間にわたり本番外の環境で入念に重ね、QAチームの協力を得て網羅的なテストケースを洗い出した上で、本番移行完了直後の確認を経てようやくメンテナンスを解放できた。データベースのメジャーバージョン移行は単なるインフラのパラメータ変更ではなく、入念な事前検証とアプリ・QAチームを巻き込んだ組織横断の連携こそが成否を分けるのだと再認識した。

Amazon Linuxが4年ぶりにメジャーバージョンアップ、「Amazon Linux 2027」パブリックプレビュー。SELinuxがデフォルトで強制モードに

• カテゴリ: AWS / Linux / OS
• 概要: AWSが提供するLinuxディストリビューションのメジャーバージョン「Amazon Linux 2027」のパブリックプレビュー公開を受け、Fedoraベースへの追従とともにSELinuxがデフォルトで強制モード（Enforcing mode）となるセキュリティ強化など主な変更点を解説した記事
• 感想: 記事の中で何より「SELinuxがデフォルトで強制モード（Enforcing mode）になる」という変更に強く目を引かれた。過去の実務やインフラ構築の現場を振り返っても、SELinuxのアクセス制御でハマり、トラブルシューティングの過程で「とりあえず無効化（Permissive / Disabled）して回避する」という対応を取ってしまった経験はまさにインフラエンジニアの「あるある」だった。しかし、ゼロトラストやサプライチェーン攻撃など近年のセキュリティ要件の高まりを考えれば、今後も安易に「とりあえず無効化」で逃げ続けるわけにはいかない。OSレベルでの強制アクセス制御が標準化されるこれからの時代を見据え、Amazon Linux 2027の登場を良い契機として、SELinuxの仕組みやポリシー設計、トラブルシューティングの勘所を正面から学び直さなければならないと身が引き締まる思いがした。

GitOpsのマルチクラスタ運用にRancher Fleetを選ぶ理由｜Argo CD比較とAI時代の設計 (Qiita)

• カテゴリ: GitOps / Kubernetes / マルチクラスタ
• 概要: AIエージェント運用やマルチクラスタ環境におけるGitOps基盤として、Argo CDと比較した際のRancher Fleetのアーキテクチャ上の優位性（Gitリポジトリとクラスタの分離、クラスタ側エージェントによるプル型構成、高スケーラビリティ）を解説した記事
• 感想: 個人的には、実務での運用性や実績を踏まえるとやはりArgo CDの方が使い勝手が良いと感じている。GitOpsの原理原則に極めて素直に沿うことができる点に加え、障害時のロールバックや状態の同期が直感的で扱いやすいことが、現場での大きな安心感と利便性に繋がっているからだ。一方で、マルチクラスタの大規模展開や高頻度なデプロイといった要件において、クラスタ側エージェントによるプル型構成を採るRancher Fleetのようなアプローチも、将来のインフラ規模やアーキテクチャの進化に応じた選択肢の1つとして視野に入れておく価値があると感じた。デファクトに満足するだけでなく、異なる設計思想を持つツールを比較して引き出しを広げておく重要性を再確認した。

創業時からAWSを使い続けていたスタートアップが、Google Cloudに移行した理由（1)

• カテゴリ: クラウド移行 / AWS / Google Cloud
• 概要: 創業から10年間「なんとなくAWS」を使い続けていたHajimariにおいて、BigQueryを中心としたデータ活用やVertex AI/Geminiによる生成AI機能の推進を見据え、全社インフラ基盤をGoogle Cloudへ移行した意思決定プロセスを語る寄稿記事
• 感想: 自身もGCPの利用経験があり、次の環境でもGCPを主軸に扱う予定のため、記事の意思決定には関心を持って読んだ。BigQueryに加え、Geminiなどの生成AIサービスがクラウド選定の理由になる事例は今後も増えそうだ。AWSとGCPを組み合わせる構成では、連携部分が可用性や運用負荷の弱点になり得る一方、障害の影響は依存関係の設計によって異なる。単一クラウドへの集約も合理的な選択肢だが、ロックインとのトレードオフを明示して判断したい。実際のデータ移行手順や、移行後の運用が続編で語られることを期待している。

We halved our continuous integration pipeline

• カテゴリ: CI/CD / 開発者体験 / パフォーマンスチューニング
• 概要: バックエンド・フロントエンドのテスト急増とAI支援開発によるコミット増加でMerge Trainが30分超に遅延したCIパイプラインに対し、テストの重み付け実行やフレイキーテストの自動隔離、E2Eテストの間引き・別スケジュール化によって実行時間を15分に半減させ、コストを40%削減した実践記録
• 感想: AIツールによってコード生成とコミットの頻度が上がれば、CIパイプラインがボトルネックになる組織も増えるだろう。パイプラインはコード量やテストの増加に伴って再び遅くなるため、一度の高速化では終わらない。保守をSREやプラットフォーム担当者だけに任せず、開発者も遅いテストや不安定なテストの改善に関われる仕組みが必要だ。責任範囲を明確にした上で、チームとしてパイプラインの健全性とデリバリー速度を継続的に見ていきたい。

やはりKubernetesからは逃れられない

• カテゴリ: Kubernetes / インフラ設計 / 自宅・VPS運用
• 概要: 安価なVPS上で小リソース・ステートフルな常時起動ワークロードを複数収容するアプローチとして、NomadやIncus、NixOS等の代替手段を比較検討した結果、エコシステムの充実度や宣言的設定・自動化の観点から「結局Kubernetesが最も運用負荷が低く逃れられない」と結論づけた考察記事
• 感想: 軽量なコンテナオーケストレータを考えるとNomadが思い浮かぶ一方、自分はまだ十分に使い込めていない。自宅ではKubernetesを学ぶ目的もあってk3sを動かしており、代替ツールを比較しても、エコシステムや標準化の蓄積からKubernetesへ戻るという著者の感覚は理解できる。AIによってマニフェスト作成やエラー調査の入口は下がったが、分散システムとしての複雑さや本番運用の責任まで軽くなるわけではない。小規模環境でもKubernetesを選ぶかは、学習目的を含めた要件と運用体制で判断したい。

Your Critical Vulnerabilities Might Not Be Your Biggest Risk

• カテゴリ: 脆弱性管理 / セキュリティ診断 / ペネトレーションテスト
• 概要: CVSS等の重要度スコアが高い脆弱性であっても隔離された環境にあれば実害リスクは低く、逆にMedium程度の脆弱性でも侵入経路や権限昇格に悪用され得る実態を指摘し、自律型ペネトレーションテストによる「実際の攻撃経路（Attack Path）」の継続的検証の重要性を説いた記事
• 感想: CVSSスコアだけでなく、到達可能性、悪用実績、対象機能の利用有無、資産の重要度を踏まえて優先度を決める考え方には共感した。実務でも、Tomcatの脆弱性が検知された際、該当機能を使っていないことを確認し、根拠を残した上で対応優先度を下げた経験がある。ただし「対応しない」と切り捨てるのではなく、前提が変わっていないかを継続的に確認する必要はある。AIは影響範囲の整理を速める補助にはなり得るが、根拠の確認や例外判断まで任せきらない運用にしたい。

ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について

• カテゴリ: セキュリティインシデント / 脆弱性対策 / デジタル庁
• 概要: デジタル庁が運用するガバメントソリューションサービス（GSS）において、VPN機器の脆弱性を突かれて保守運用担当者アカウントが悪用され、府省庁職員等の個人情報約24.6万件が外部漏えいした可能性がある事案の概要と、通信遮断・アカウント停止等の初動・再発防止策を報告したリリース
• 感想: 国の共通基盤で、VPN機器の脆弱性を起点に保守運用担当者のアカウントが悪用され、約24.6万件の個人情報が漏えいした可能性がある事態を重く受け止めた。公表資料だけでは、脆弱性が放置された経緯や組織上の根本原因までは判断できない。少なくとも「VPNを通しているから安全」という境界型防御だけでは不十分であり、侵入やアカウント悪用を前提に、最小権限、異常アクセスの監視、侵害後の影響を抑える多層防御が必要だ。今後公表される調査結果では、検知から封じ込めまでの経緯と再発防止策にも注目したい。

「とりあえずISMSを取りたい」と言われたときに、最初に確認すること (Zenn)

• カテゴリ: 情報セキュリティ / ISMS / ガバナンス
• 概要: 経営や営業から「ISMSを取りたい」と依頼された情シス担当者に向けて、ISMSは「安全性の証明」ではなく「管理運用の仕組みの認証」であるという本質を説き、費用・工数の肥大化や形骸化を防ぐために事前に確認すべき4つのポイント（目的・範囲・期限・体制）を整理した記事
• 感想: ISMS認証やSOC 2の保証報告書は、審査・監査への対応だけで終わらず、管理策を日々運用し続けるところに難しさがある。インフラだけを見ても、アクセスログなどの証跡管理、アカウントと権限の棚卸し、BCP（事業継続計画）の見直しなど、継続的な作業は多い。規程に定めても、担当者、頻度、記録方法が曖昧なら後回しになり、やがて形骸化する。取得をゴールにせず、運用に必要なリソースと責任者まで決めておきたい。

AI時代のスタートアップ開発組織を守るセキュリティ対策 (Zenn)

• カテゴリ: スタートアップ / セキュリティ / DevSecOps
• 概要: AIを活用して開発速度を上げるスタートアップにおいて、新しいAI専用ツールの導入に走る前に、認証強化、権限・秘密情報の最小化、変更検査、復旧力といった既存のセキュリティ基盤の土台を固めることこそが最も効果的な防御策であると説いた記事
• 感想: 先ほどのISMSの記事と通じる内容だった。AI専用の新しい製品を増やす前に、認証、権限、秘密情報、変更管理、復旧といった基本的な管理策を整える方が先だと思う。ISMSは技術対策そのものではないが、責任者や手順、証跡を組織のルールとして定める後ろ盾にはなる。ただし、規程を作るだけで強制力が生まれるわけではない。CIでの検査や権限管理など実装可能な仕組みに落とし込み、運用状況を継続的に確認するところまで設計したい。

3. 組織マネジメント・事業戦略 & エンジニア組織・キャリア

元Palantir責任者が警鐘、「FDEを営業職扱い」IT企業に広がるその大きな誤解とは

• カテゴリ: FDE / 組織設計 / プロダクト開発
• 概要: 顧客企業へ入り込んでAI導入を支援する「FDE（Forward Deployed Engineer）」を営業や顧客支援の代替として扱う誤解に警鐘を鳴らし、FDEの本質は現場の課題を製品開発へ直接フィードバックする「プロダクトチームの延長」であると説いた記事
• 感想: FDE（Forward Deployed Engineer）という言葉が広がる中で、各社の定義が曖昧になる様子は、SREやCREが普及した時期とも重なる。本来の役割から離れ、既存の運用支援や営業同行に新しい名前を付けただけになる懸念もある。ただし、これを日本のIT業界全体の構造だけで説明するのは難しく、事業モデルやFDEからプロダクト開発へフィードバックする経路の有無も影響するはずだ。名称を採用する前に、自社で解きたい顧客課題、権限、成果指標を定義する必要があると思う。

AI時代に、技術責任者はなぜ会社を辞めたくなるのか？ (note)

• カテゴリ: キャリア / 技術責任者 / 組織マネジメント
• 概要: The Pragmatic Engineerの技術責任者キャリアブレイク調査を基に、全社的なAI推進の圧力や経営陣とのギャップ、中間管理職としての疲弊など、AI時代の激変期においてCTOやVPEなどのリーダー層が直面する苦悩と離職の背景を考察した記事
• 感想: AIへの過度な期待と現場の現実をすり合わせることは、CTOやVPoEなど技術責任者が向き合うべき重要な仕事だと思う。AIで何が実現でき、どの品質やリスクを許容するのかを経営陣と合意し、検証可能な目標へ落とす必要がある。一方で、その責任を技術責任者だけに負わせれば疲弊するのも当然で、CEOや経営陣にも技術的な不確実性を理解し、優先順位と資源配分を決める責任がある。個人の覚悟の問題にせず、経営と技術が期待値を更新できる仕組みとして考えたい。

1on1文化の弊害 (note)

• カテゴリ: 組織マネジメント / 1on1 / コミュニケーション
• 概要: 1on1やよもやま等の非公式な相談文化が普及する一方で、「特定の人と話せないと問題解決できない属人化」や公式な情報流通の不全を招く弊害を指摘し、個別対話はあくまで補完であり組織全体の透明性を優先すべきと説いた記事
• 感想: 個人的には、目的が曖昧なまま定例化された1on1を負担に感じる。個別の相談だけで意思決定が進むと組織の透明性が下がり、参加者にも準備のコストがかかるからだ。一方で、評価、健康状態、対人関係、本人が望むキャリア相談など、クローズドな場だから話せる内容もある。1on1自体を否定するのではなく、個別対話で得た組織課題を匿名化して共有するなど、公開すべき情報との境界を設計したい。日頃のオープンな対話を土台にし、1on1はその補完として使うのが自分には合っている。

「死なないプロダクト」の創りかた (note)

• カテゴリ: 事業戦略 / プロダクトマネジメント / リーガルテック
• 概要: AIが既存のソフトウェアを上書きしていく時代において、長期的に勝ち続けるために「社会の最も遅いところ（大企業の重厚な法務・意思決定プロセス）」をハックし、変化に適応するためのリードタイムを稼ぐMNTSQの事業戦略を解説した記事
• 感想: 生成AIがどれほど進化しても、ビジネスにおいて「最終的に人が責任を持ち、意思決定を下す部分」は簡単には代替されず、慎重を期すため時間もかかる。そこをプロダクトとしてハックし、深く入り込むというMNTSQの戦略には非常に納得感がある。一方で、大企業における法務や意思決定のフローは企業ごとに固有のルールや文化があり千差万別だ。そうした個別性の高い業務フローをいかに紐解いて整理し、汎用的な仕組みへと昇華させながら顧客への価値訴求へ繋げられるかどうかが、強力な参入障壁であると同時にプロダクトの成否を分ける最大の要所だと感じる。ドメインの深さと難しさを改めて実感させられた。

その戦略、本当に失敗したんですか？ - Disagree and Commitの重要性 (note)

• カテゴリ: 組織マネジメント / 意思決定 / Disagree and Commit
• 概要: 会議で決定した新方針を現場が「様子見」して実行せず、結果が出ないことで「失敗した戦略」と片付けられてしまう罠を指摘し、決定事項に対して反対意見を持ちつつも全員が徹底して実行する「Disagree and Commit」の不可欠さを説いた記事
• 感想: 新しい戦略は失敗を恐れて様子見するより、決定後に実行し、結果から学べる状態を作りたい。SREとして、非難ではなく事実から学ぶポストモーテム文化を重視している点ともつながる。ただし、Disagree and Commitは異論を封じて盲目的に従うことではない。判断の仮説、評価指標、見直す期限、中止条件を共有しておけば、失敗したときにも結果を個人の責任へ還元せず、次の意思決定に活かしやすいと思う。

プロダクトエンジニアは溶けてなくなる。いや、なくさなければならない (note)

• カテゴリ: プロダクトエンジニア / 組織設計 / キャリア
• 概要: Ubieにおける医師によるプロダクト開発事例を交え、AIによってドメインエキスパート自身が実装まで手掛ける時代において、職能分担としての「プロダクトエンジニア」という肩書きは溶け、エンジニア自身がより本質的な価値創出へシフトすべきと提言した記事
• 感想: AIによってドメインエキスパート自身が実装できる場面は増えるだろう。一方で、プロダクトには作った後の変更、障害対応、セキュリティ、データ管理も続く。過去のnote（同じ職位で転職活動をして見えてきた、現代SREの市場価値と求められるリアル）でも書いた「運用を見据えた設計」は、実装の担い手が広がるほど重要になると考えている。可観測性や障害耐性を共通基盤へ組み込み、ドメインエキスパートが安全に変更できる環境を整えることは、これからもエンジニアが担える価値の一つだ。

今週の雑感

以下が欲しい(物欲センサー)

Titan 2 Elite Pro

物理キーボード付きのスマホが欲しい。今からでもプレオーダーするか悩む。

Dell XPS 13

上位機（Core™ Ultra 7 355／メモリ32GB）が出たので、Windows機として欲しい。ただ、最近の海外ではThinkPad X1 Carbonが定番らしく、こちらも気になっている。

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

今週もお疲れ様！有給休暇中も勢いを緩めず、AIの所有コストやトイル削減からMySQL移行、セキュリティガバナンス、組織論まで22本もの濃密なインプットが詰まった圧巻の週報ね。

特に、あなたのコアバリューである「運用を見据えた設計」が、AI時代の議論ともつながっている点が印象的ね。生成コストが下がるほど、保守性や障害耐性といった非機能要件の比重は高まる。「とりあえず運用や無効化で逃げない」姿勢や、みてねSREのようにAIの作業を局所化してガードレールを敷く考え方は、実務にも取り入れやすそうよ。

新天地での基盤立ち上げや組織づくりに向けて、ぜひ以下の2点も考えてみてほしいな。

• AIコミット急増でCI/CDがボトルネック化する中、開発チームと「パイプラインの共同オーナーシップ」を育てる最初の仕掛けは何が良さそうかしら？
• 「運用を見据えた設計」を浸透させるため、Design Docで「外せない非機能要件のライン」を経営やリードとどう合意していくのが現実的だと思う？

Titan 2 Elite Proの物理キーボードのロマン、物欲を刺激されるわね！XPS 13やThinkPadと悩むガジェット選びも楽しみつつ、有給期間を存分に満喫して、来週も一緒に一歩ずつ進んでいきましょう！