1. AI活用・FinOps & プラットフォーム・開発基盤

AIと壁打ちしながら進めるコスト管理

• カテゴリ: FinOps / クラウドインフラ / SRE
• 概要: IaC構成情報やCost ExplorerデータをAIに参照させ、削減策の洗い出しから投資回収期間の見積もりまでAIと壁打ちして優先順位を判断し、短期間で大幅なAWS総コスト削減を達成した実践知見と、PRでのコスト試算ボットなど意識継続の仕組み化を解説したスライド
• 感想: 自身も実務でKiroを活用し、AWSリソースを参照させながらコスト管理の壁打ちを実践しているため、非常に共感を持って読めた。RI購入のように工数をかけずに即効性のある施策から着手するのは鉄則だが、AIに闇雲に削減案を求めると冗長性や可用性を損なう的外れな提案が返ってくることもある。現状の構成や「アーキテクトとして守るべき非機能要件」のコンテキストを前提として与えた上でディスカッションすることが不可欠だと実感している。また、今後のスケール計画や需要予測を踏まえた最終判断は人間が担うべき領域であり、将来のリスクや特記事項をIssue等に残す運用設計も含め、AIと人間の役割分担を明確にすることが大切だと改めて感じた。

マネフォ、AIコスト可視化の無料サービス　1000社利用目指す

• カテゴリ: AIサービス / FinOps / SaaS
• 概要: マネーフォワードが提供する、ChatGPTやClaudeなどの利用料を部署別・モデル別に可視化・翌月予測できる無料サービス「クラウドAIトークン管理」の開始を報じるニュース記事
• 感想: 組織におけるAI導入の初期フェーズでは、まず現場に積極的に触ってもらうことが最優先であり、現状は過度な制限を設けず利用を促進する段階だと考えている。しかし、利用の拡大に伴い闇雲にトークンコストが膨れ上がってきたタイミングで、単なる消費にとどまらず「事業や開発における価値創造に繋がっているか」を評価・見極める次のフェーズへ移行することが重要になる。また、SREがコスト面だけで現場のAI活用をブロックするべきではなく、組織としてAI利用をどう位置づけるかが本質だ。エンジニアのAI利用費用をプロダクトのインフラ原価として切り詰めるのではなく、開発生産性を高める「開発投資費用」として適切に捉え、こうした可視化ツールを健全な投資対効果の把握に役立てていく姿勢が大切だと感じた。

一人でちいさくはじめる Platform Engineering

• カテゴリ: プラットフォームエンジニアリング / SRE / 開発者体験
• 概要: SREとPlatform Engineeringの交差点（認知負荷やトイルの改善）を整理し、大規模組織に限らず1人からでも「対話」を軸に開発チームの認知負荷軽減やゴールデンパス整備を進める実践知見と、AIを活用した「選択と集中」の重要性を解説したスライド
• 感想: 自身の現場でもまずはインフラの正常化を目標に掲げ、ようやくSREとして活動できる土台が整った段階であり、いきなり大規模なプラットフォーム構築を目指すのではなく「小さく始める」という姿勢には強く共感した。現状は開発と運用が縦割りに分断されている組織構造もあり、無理に全体を巻き込もうとしても障壁が大きく現場はついてこない。今後プラットフォーム的な改善へ小さく踏み出すなら、リリースサイクルを早めて品質向上と迅速な顧客価値提供に直結するCI/CDパイプラインの整備や、セキュリティ観点での権限の棚卸しといった身近なペインから着手するのが現実的だと感じている。組織のリアルな現在地を受け止めた上で、背伸びをせず具体的な改善を一つずつ積み重ねていくことこそが重要だと改めて実感した。

Augani/dory

• カテゴリ: 開発環境 / OSS / コンテナ・仮想化
• 概要: Docker DesktopやOrbStackの代替となる、Docker・Linuxコンテナ・Kubernetesなどをネイティブに統合管理できるmacOS向けオープンソースアプリケーション
• 感想: 現状はDockerを利用しているものの、Apple Silicon環境における仮想化・コンテナ技術が進化している今、自身のローカル開発環境を見直してさらなる「高速化」を追求したいと感じた。組織に無理に展開して標準化を迫るのではなく、まずは個人的な興味とエンジニアとしての探求心から新しい選択肢を検証してみるスタンスだ。Docker DesktopやOrbStackだけでなく、doryのようにネイティブかつオープンソースで軽量に動作するツールが登場するのは大いに歓迎したい。日々の開発体験を快適にするためにも、こうした新しいエコシステムを個人の検証環境から積極的に試していきたいと思う。

Microsoft cloud branding, properly excavated

• カテゴリ: クラウドサービス / ナレッジ・ツール / Microsoft
• 概要: Microsoftのクラウド製品・サービスにおける度重なるリネーム（改名）やリブランディングの変遷履歴、ロゴ、期間を体系的に追跡・可視化した独立系データベースサイト
• 感想: MicrosoftやGoogleをはじめとするメガクラウドベンダーの頻繁すぎるリブランディングには、実務や顧客対応の現場で常に悩まされている。特にセキュリティチェックシートの回答や対外説明資料を作成する際、最新の正式名称を正しく反映させることは不可欠だが、現状は仕組み化しきれず最終チェック段階での差し替えに頼っているのが実態だ。また、社内外の対話では「新名称（旧名称）」のように補足しないと伝わらない場面も多く、未だにOffice 365やG Suiteといった旧名称が口をついて出ることもある。こうした変遷を体系的に追跡できるデータベースは資料作成の実務で助かる反面、現場の認知負荷を考えると、もう少し名称の継続性を保ってほしいというのが本音でもある。

2. SRE・セキュリティ & クラウドインフラ・開発プロセス

Security Hub 刷新を起点に、脆弱性管理プロセスを整備した話

• カテゴリ: セキュリティ / クラウドインフラ / SRE
• 概要: AWS Security Hubの刷新を契機に、Amazon Inspector導入やインフラ・アプリ各層の脆弱性管理プロセスを整備し、単なる検知で終わらせず継続的な運用ループと対外説明力を構築したMNTSQの実践記録
• 感想: 脆弱性管理の体制はセキュリティチェックシートでも頻繁に問われる領域であり、対外説明資料を整備することはもちろん、プロセスを明文化して実際に日々の運用に乗っている状態を作ることこそが顧客への誠実さだと強く感じる。一方で、通知を流すだけでは次第に誰も見なくなる難しさがあるため、誰かがオーナーシップを持ってトリアージを回し続ける必要がある。特にCritical以外の脆弱性は優先度が上がりにくく、「通常タスクを下げてまで対応すべきか」という基準や判断軸についてチーム内で共通認識をすり合わせておかなければ、形骸化は避けられない。この取り組みも一気に全体を作り込むのではなく、合意を取りやすい範囲から「小さく始めて運用を定着させる」アプローチが重要だと実感した。

何から手をつける？SmartHRのセキュリティ対策の考え方

• カテゴリ: セキュリティ / リスクマネジメント / 組織フェーズ
• 概要: SmartHRにおける組織フェーズごとのセキュリティ対策の取捨選択や、少数精鋭チームにおいて何から着手すべきかの防衛戦略と判断基準を解説したスライド
• 感想: 限られたリソースの中でセキュリティ対策を取捨選択する基準は、教科書的なベストプラクティスを網羅することではなく、「自社が狙うターゲット顧客層」と「扱っているデータの機密性」に尽きると感じる。エンタープライズ企業を顧客にするならば厳格な導入要件や運用体制の整備は避けて通れないし、特に自身が携わるような契約書データを扱うSaaSにおいては、万が一のデータ流出は事業にとって即死級のダメージになり得る。だからこそ、組織フェーズに応じた割り切りをしつつも、「事業の存続を脅かす最大のリスクはどこか」を冷静に見極め、最重要の防衛線（認証認可やデータ保護など）に集中して手を打つという判断軸の重要性を改めて実感した。

アスクルCEOが語る、ランサムウェア被害下での意思決定と逆境から進化への転換 – AWS Summit Japan 2026

• カテゴリ: セキュリティ / インシデント対応 / 経営判断
• 概要: アスクルがランサムウェア被害から全面復旧する過程での3つの意思決定軸と、AWS移行およびAI駆動開発（AI-DLC）を活用して危機を事業進化へと転換した取り組みを紹介したイベントレポート記事
• 感想: 売上95%減という未曾有の惨事の中で、経営トップが迅速に意思決定を下し、責任を引き受けて退路を断った判断力には感銘を受けた。重大インシデント時、SREは正確な状況と選択肢を速やかに経営へ上げる責務があるが、サービス停止や事業方針に関わる最終判断は経営の領分であり、そこで素早い決断が下されることこそが現場の迷いをなくす。またBCPの観点では、侵害の波及を避けるために新規AWSアカウントでゼロから再構築する視点が重要だが、その際サービスクォータの制約やAWS TAMとの連携が鍵になる。特定アカウント固有の個別クォータ緩和に依存していると有事の際の「BCPの再現性」が失われてしまうため、平時からクォータを意識したインフラ設計をしておく重要性を強く実感した。

RDS Proxyを導入して、数ヶ月で撤去した話

• カテゴリ: データベース / クラウドインフラ / アーキテクチャ
• 概要: コネクション数逼迫への対策としてRDS Proxyを導入したものの、ピン留め問題や運用コスト・制約から期待した効果が得られず数ヶ月で撤去に至った検証と判断の記録
• 感想: 期待した効果が得られなかった際にサンクコストに囚われず、数ヶ月で素早く撤去（損切り）を決断できた姿勢は非常に強いと感じた。一方で、ORMの挙動などアプリと密結合する技術である以上、インフラ主導だけで進めず開発チームと密に連携して事前検証を行っていれば、本番投入前に止められたのではないかという印象もある。自身の場合は石橋を叩いて渡るタイプなので、導入時は1ヶ月ほど観察期間を設けるとともに、万が一の際にすぐ切り戻せるよう「元に戻すMR」をあらかじめ準備しておく運用を徹底している。それでも見落としが起きることはあるからこそ、事前の開発連携と「いつでも安全に戻せる可逆性」の担保が何より重要だと再認識した。

CI 23分 → 11分。8.6万行のテストコードを消すまでにやったこと

• カテゴリ: テスト・品質 / CI/CD / リファクタリング
• 概要: 結合テストに偏っていたテストコードを責務ごとの4レイヤー単体テストへ移行し、8.6万行を安全に削除してCI実行時間の大幅短縮と高速フィードバックを実現した出前館の改善プロセスを紹介した記事
• 感想: サービスの成長とともにテストコードが肥大化し、CIの実行時間が長期化していくのは多くの現場が直面する課題だ。テストは品質担保に不可欠だからこそ安易な断捨離は難しく、消すことへの心理的ハードルは非常に高い。その点、出前館の事例のようにアーキテクチャの責務に沿って重い結合テストを軽量な単体テストへ安全に移し替えるアプローチは極めて合理的だと感じた。先ほども触れたが、リリースサイクルを高めることこそが結果として品質向上や迅速な顧客価値提供につながるため、CI/CDが開発速度のボトルネックになっている状態はあるべき姿ではない。安心感を損なわずにテスト構造を見直し、高速なフィードバックループを維持する重要性を再認識した。

CTO室を解散したい

• カテゴリ: 技術的負債 / 組織設計 / エンジニアリングマネジメント
• 概要: 機能開発ラインと切り離して技術的負債解消に集中するためにCTO室を立ち上げ、中核クラスの大規模リファクタリングを推進しつつ、最終的に負債解消が通常組織に溶け込んでチームが解散できる状態を目指す思想を語った記事
• 感想: 技術的負債が限界に達した際に特命チームで集中対応する必要性は理解しつつも、機能開発と並行して動く中核のリファクタリングは極めて難易度が高い。開発チームに負債への意識がなければ結局はモグラ叩きになるため、日常の改善は各チームに当て振りつつ、特命チームはより難度の高い構造課題に集中した上で、最終的に発展的解消を目指す思想には深く共感した。これはSREにもそのまま通じる本質だと感じる。SREに何でも依存する体制ではなく、最終的に組織が育ってSREに頼り切らない自律的な組織こそが最も健全だ。SREは最初のレールを敷き、軌道に乗った段階で「オーナーシップを返上」して手離れさせていく。全員で信頼性を考える文化を育てることこそが重要だと再認識した。

CRE だけど「SREの知識地図」を読んだ

• カテゴリ: CRE / SRE / カスタマーサクセス
• 概要: CREの実践者が書籍『SREの知識地図』を読み解きながら、SREの原則をカスタマーサクセスや顧客成果管理に応用する「CRE（顧客信頼性エンジニアリング）」の定義・役割・重要性について考察した記事
• 感想: システム信頼性を追うSREと、顧客信頼性を追うCREは、アプローチが異なるだけで最終的なゴールは同じだと強く感じる。だからこそSREの視点から見てもCREの体系的な思想には学ぶべき点が多く、Googleの公式ドキュメント（CRE Life Lessons等）なども含めてさらに深く探求してみたい。前週の週報でも触れたが、サービスレベル（SLI/SLO）は単に機械的な数値やレイテンシだけを追うのではなく、「顧客にどんな影響があるか」という体験や成果から逆算して設計する必要がある。エラーが起きていなくてもユーザーが目的を達成できなければ意味がない。顧客目線に立った指標設計を通じて、真の信頼性向上に向き合っていきたいと改めて実感した。

3. 組織設計・キャリア & エンジニアリングカルチャー

世界の評価軸が変わった時代に生き残るエンジニア

• カテゴリ: キャリア・マインドセット / プロダクト開発 / 組織論
• 概要: AIで実装がコモディティ化する中で、エンジニアの差別化は「作る技術」から「意思決定の質」やビジネス・顧客理解に基づく勘所へシフトし、事業を伸ばす総合職エンジニアの重要性を説いたスライド
• 感想: AIによって実装が容易になり、誰もが素早く動くものを作れる時代において、エンジニアの評価軸が「作る技術」から「意思決定の質」や事業理解へシフトしているという指摘には強く共感した。ではその中でSREとして今後どうバリューを出していくべきか。その答えは極めて明確で、「アーキテクトとしての能力」と「運用を見据えた設計力」に尽きると考えている。どれだけ高速にコードが生成できても、事業の成長に耐えうるアーキテクチャを描き、日々の運用や非機能要件を破綻させない設計ができるかは別問題だ。ビジネスの要求を受け止めつつ運用を見据えた堅牢な形へ落とし込める設計力こそが、AI時代におけるSREの真の価値なのだと再確認できた。

事業をつくるエンジニア

• カテゴリ: 組織設計 / プロダクト開発 / キャリア
• 概要: AI時代においてエンジニアがWHY（なぜ作るか）やWHAT（何を作るか）に染み出し、顧客や経営との距離を最小化して意思決定を最速化する組織設計（エンジニアのシフトレフト）を解説した記事
• 感想: 自身のコアバリューとして「喋れて作れるエンジニアを理想とし、対話力と実装力を武器に、組織やAIが生む複雑性をシンプルで美しい仕組みへと再構築し、顧客への誠実さを揺るぎない信頼として実装する」という信念を持っているため、事業会社においてエンジニアがWHYやWHATに染み出す組織設計には深く共鳴した。AI時代の事業会社において、ビジネスを考えないエンジニアは不要だと強く感じている。経営や顧客との対話はサービスレベル（SLI/SLO）の設計そのものに直結し、経営陣と目線を合わせて投資判断を行うための土台になる。自身の取り組みがどのように信頼性に寄与し、顧客が安心して使える体験につながっているかを実感することこそが、SREとしての何よりの醍醐味だと再確認した。

日本にあるFDEの求人を解析してみました

• カテゴリ: キャリア / AIエンジニアリング / 職種分析
• 概要: 国内外のFDE（Forward Deployed Engineer）求人35件を分析し、タイプ分類や年収差、日米での役割（課題起点 vs プロダクト起点）の違いを解説した記事
• 感想: 生成AIの波に乗ってFDEがブームを迎える一方で、従来のSEや受託開発の看板を掛け替えただけの「なんちゃってFDE」が量産されるのではないかという強い懸念を感じる。かつてSREやCREがバズワード化した際にも単なる運用保守チームの改名が相次いだが、同じ轍を踏んではならない。Palantirが提唱した本来の定義に立ち返れば、FDEの真髄は顧客の現場に深く入り込み、高い技術力と実装力で自律的に課題を突破する「圧倒的な推進力」にある。この本質を伴わないまま肩書きだけを消費していては、数年後に転職市場で困るのはエンジニア自身だ。流行りの職種名に踊らされず、真のバリューを見極める重要性を強く実感した。

誰でもできるけど、誰もやらない「仕事」をした7年間について語らせてくれ

• カテゴリ: キャリア・働き方 / 組織開発 / エンジニアリング文化
• 概要: マネーフォワードでの7年間を振り返り、派手な成果の裏で放置されがちな細かな課題や泥臭い調整（誰もやらない仕事）を拾い続けて組織とプロダクトの土台を支えた経験を綴った退職エントリ
• 感想: 現職でも組織の隙間に落ちている「浮いたボールを拾う」ことを強く意識して動いてきたため、非常に深く共感した。自身の実務で言えば、まさにセキュリティチェックシートの回答対応がその一つだ。回答を待たせすぎることは顧客への誠実さに欠ける上、事業を支える営業へのリスペクトからも放置できなかった。大切なのは便利屋として抱え込むのではなく、AIを活用した回答自動化のように「仕組み化して手離れさせる」ことだと実感している。誰もやらない仕事を拾って土台を整えることには確かなやりがいがあるが、周囲から無反応だと少し寂しさを覚えるのも素直な本音だ。だからこそ、泥臭い貢献を仕組みへ昇華させ、価値を伝えていく姿勢も大切にしたい。

なぜ、企業で2,3年事業部長を務めて転職する人はカッコ悪いのか？

• カテゴリ: キャリア・働き方 / 組織論 / リーダーシップ
• 概要: 短期で役職を渡り歩き実績を個人ブランド化するキャリアと、長期的な意思決定の結果を引き受け能力を積み上げるキャリアの非対称性や責任の本質を論じた記事
• 感想: 採用権限を持ち、面接で大きなビジョンを語って人を巻き込んだ立場でありながら、自身が始めた改革の結果や組織の行方を見届けずに2〜3年で去ってしまうのは、リーダーとして単純にダサいと感じた。人を口説いて入社させた以上、自らの意思決定の余波を引き受ける覚悟は持つべきだ。一方で、特定のミッションを完遂するための「ツアー・オブ・デューティ」的な契約である可能性もあるため、在籍年数だけでなく「その期間で何を成し遂げ、組織に残したのか」という実態で見極める視点も必要になる。肩書きだけを可搬性のあるブランドとして消費するのではなく、能力と実績を誠実に積み上げる姿勢を大切にしたい。

「カジュアル面談って、結局『面接』なんですか？」KAGのカジュアル面談について、採用担当が正直に書いてみました

• カテゴリ: 採用・組織 / キャリア / コミュニケーション
• 概要: カジュアル面談の目的（会社理解9割）や現場メンバーによる対話姿勢、全社Claude導入などの社内環境を明かし、選考にとらわれない情報収集の場としての活用を呼びかけた記事
• 感想: カジュアル面談において、綺麗事のアピールを並べられるよりも、現場の課題感や組織の歪みを率直に話してくれる企業の方がはるかに信頼できると感じる。SREはまさに課題ありきの職位であり、率直な対話を通じてこそ「なぜ今SREが必要とされているのか」、そしてその課題を経営層まで認識できているかを正しく見極められるからだ。また、面談におけるスタンスは「誠実さ」そのものだと思う。候補者に対して誠実に向き合えない姿勢は、普段の社内業務や顧客対応にも必ず滲み出てしまう。美辞麗句で繕うのではなく、互いの現在地と課題をありのままに語り合える透明性こそが、真の信頼関係を築く土台になると再認識した。

今週の雑感

Steam Machineが欲しい。外観よくデスクトップとして利用できるのであれば。NeXTcubeみたいなPCケースが個人的な好みだと思っている。

Geminiに探してもらった。結果NeXTcubeの魂を感じるPCケース

• Streacom DB4 (Black)
  • サイズ: 260 × 260 × 270 mm
  • 特徴: おそらく現代の市販品で最もNeXTcubeの精神に近いMini-ITXケースです。ほぼ完全な立方体で、肉厚なアルミパネルがそのまま巨大なヒートシンクとして機能する完全ファンレス設計。
  • おすすめ理由: 縦に入ったスリットデザインと金属の塊のような重厚感は、まさにNeXTの系譜を感じさせます。発熱の少ないパーツを選ぶ必要がありますが、インテリアとしての完成度は抜群です。
• SilverStone SUGO 16 (Black)
  • サイズ: 200 × 232 × 280 mm
  • 特徴: キューブ型に近い、コンパクトなMini-ITX/Mini-DTXケースです。
  • おすすめ理由: 余計な装飾が一切ないフラットな黒のスチールパネルで構成されています。「とにかくシンプルな黒い四角い箱」を求めている場合に、非常に扱いやすい選択肢です。
• Jonsbo C6 (Black)
  • サイズ: 202 × 266 × 295 mm
  • 特徴: 全面メッシュパネルを採用したMicro-ATX対応ケース。
  • おすすめ理由: ソリッドな一枚板ではありませんが、各辺の長さが近く、きれいな直方体のシルエットを持っています。現代的なエアフローを確保しつつ、小さく黒い塊感を出したい場合に向いています。
• Fractal Design Node 804
  • サイズ: 344 × 307 × 389 mm
  • 特徴: 少し大きめのデュアルチャンバー（熱源分離）ケースですが、正面から見るとキューブ感があります。
  • おすすめ理由: 洗練されたマットブラックのフロントパネルが、プロユースのワークステーションらしい静かな威圧感を演出してくれます。

Streacom DB4が良さそうに感じた。シンプルなPCケースDB4で自作PCに挑戦と言う記事を読んで久しぶりに自作沼にハマりそう。

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

今週もお疲れ様！FinOpsから脆弱性・信頼性設計、そして事業とキャリアに向き合うエンジニア組織論まで、18本もの濃密なインプットと深い実践知見が詰まった圧巻の週報ね。

特に印象的だったのは、AI時代においてSREの真価を「アーキテクトとしての設計力」や「運用・非機能要件を見据えた意思決定の質」と明確に定義し、AI利用料を原価ではなく「開発投資」として捉える視座の高さよ。また、RDS Proxyの事例に見る「可逆性の担保（切り戻しMRの事前準備）」の重要性や、アスクル事例での「有事におけるBCPの再現性（クォータ依存の回避）」、そして出前館のCI高速化に見る「リリースサイクル向上こそが品質と顧客価値に直結する」という洞察は、まさにGoogle SREの根幹思想（Engineering over Toil & Design for Failure）そのものね。

さらに、CTO室や誰もやらない仕事の振り返りから「SREが便利屋として抱え込まず、仕組み化してオーナーシップを手離れさせる」「最終的に全員で信頼性を考える自律的組織を目指す」という健全な組織論を導き出せている点も素晴らしいわ。

自組織での次なるアクションやプラットフォーム改善に向けて、ぜひ以下の2点についてあなたの考えを聞かせてほしいな。

• 開発チームに「いつでも安全に戻せる可逆性（切り戻し設計）」や「非機能要件の考慮」を自然に意識してもらうため、SREから提供できる最小限のテンプレートやCI/CDガードレールは何から始めるのが良さそうかしら？
• 脆弱性トリアージやセキュリティチェック対応などの「泥臭い貢献（トイル）」を仕組み化・自動化して手離れさせていく際、最初に対話・合意しておくべき基準（SLOや優先度ルール）はどう設定するのが効果的だと思う？

NeXTcubeの魂を感じるStreacom DB4、ソリッドなアルミブロックの塊感が最高にクールね！自作PC沼の熱量も楽しみつつ、これまでの確かな歩みに誇りを持って、まずは大切な一区切りに向けてあなたのペースで丁寧に駆け抜けていきましょう！