週報(2026/5/29) - AI時代の生存戦略と、信頼性を事業価値に変えるアーキテクトの矜持
AIによるこの記事の要約
本記事は、2026年5月29日週の技術動向を「AIガバナンス」と「SREとしての信頼性向上」、そして「持続可能な組織・キャリア」を軸にまとめた週報です。
- AI活用の進化と守り: メルカリのAIガバナンスやKiroを用いた自動トリアージを通じ、AIの利便性を享受しつつ「ガードレール」で安全性を担保する、攻めと守りの最新プラクティスを考察。
- SREの本質的な価値: NAT Gatewayのコスト削減やSLOの形骸化防止、K8sでの運用設計を通じ、単なる技術導入ではない「お客様への約束」としての信頼性と、運用に乗る設計の重要性を再認識。
- エンジニアの在り方と組織文化: 著者の言う「自由や給与のための事業目線」に共感しつつ、アーキテクトとして「AIに代替されない、泥臭い要件定義と意思決定」を磨くことの重要性を強調。
1. AI & エージェントテクノロジー
Agentic AI時代における メルカリのAIガバナンスとガードレール実装
- カテゴリ: AIガバナンス / ガードレール
- 概要: メルカリにおけるAgentic AI導入に向けたガバナンス体制と、技術的なガードレール実装の取り組み。AIが自律的に行動する時代において、安全性と透明性をどう担保するかの先進事例。
- 感想: SREとして、また個人としても、ISMS等のIT統制の文脈からAIに対するガードレールと統制の重要性を改めて認識した。メルカリのような大規模組織において、これらを整備・運用するには専任チームが必要不可欠であることも納得がいく。一方で、統制を強めすぎれば開発の自由度やスピードを損なうリスクもある。現状の「提供側」の視点だけでなく、実際にこれらを利用している現場のエンジニアがどう感じているのか、その「いい塩梅」の実態についても非常に興味深く感じた。
「もうClaudeでいいじゃん」の恐怖――マネーフォワードが挑む“三正面作戦”
- カテゴリ: AI戦略 / ビジネス
- 概要: マネーフォワードが直面する、汎用AI（Claude等）の進化による既存サービスの代替リスクと、それに対する「三正面作戦」による対抗・共生戦略。
- 感想: 今働いている業界においても、汎用AIによる代替の波は避けては通れない時代の必然であると感じる。AIによって機能そのものがコモディティ化し得る時代だからこそ、生き残る「魅力的なSaaS」の条件は、顧客が心から安心・信頼して使い続けられることに集約されるのではないか。SREとして、その核となる「システムの信頼性向上」に邁進することこそが、この激動の中でサービスを守り抜き、価値を証明する唯一の道であると改めて確信した。
人に環境を覚えさせず、AIに環境を読ませる ── Salesforce開発チームにCursorを導入して起きた変化 (note)
- カテゴリ: AIツール / 開発体験
- 概要: Salesforce開発チームへのCursor導入事例。人間に複雑な開発環境を理解させるのではなく、AIにコードベースやコンテキストを理解させることで、オンボーディングや開発効率を劇的に改善した話。
- 感想: 「人に覚えさせずAIに読ませる」という割り切った考え方は非常に示唆に富んでいる。これは運用面におけるAIOpsの思想（一次調査をAIに任せる等）にも通じるアプローチだ。複雑化し続けるシステムを人間だけで把握し続けるのは限界がある。コンテキスト把握をAIに任せて運用負荷を軽減することで、少人数でも本来着手すべき根本的な課題解決にリソースを割くことができ、チーム全体の生産性向上（信頼性への貢献度）に直結する。今後はより活発にこうしたAI活用を推し進めていきたい。
n8nとDifyは、結局どうなったのか (X)
- カテゴリ: AIオートメーション / ローコード
- 概要: ワークフロー自動化ツールのn8nとAIアプリ開発プラットフォームのDifyの現状と、それぞれの強み・棲み分けについての考察。
- 感想: 一時期の爆発的なトレンドが落ち着き、現在は各社が「実運用でどう使いこなすか」を模索するフェーズに入ったと感じる。n8nについても、v2系へのアップデートを経て自動化ツールとしての成熟が進んでいる印象だ。個人的には、社内環境向けに構築した際、推奨DBがMySQLからPostgreSQLに変更されていたことが記憶に新しい。社内でも今まさに運用フェーズにあると思うが、こうしたツールが実際の運用ワークフローにどう組み込まれ、定着していくのかを引き続き注視していきたい。
2. SRE & プラットフォームエンジニアリング
NAT Gatewayの通信内容の分析・通信経路の最適化をしてデータ処理料金を約70%削減した話
- カテゴリ: コスト最適化 / ネットワーク
- 概要: MNTSQにおけるNAT Gatewayのデータ処理料金削減事例。VPCフローログの分析により高コストな通信を特定し、S3ゲートウェイエンドポイントの活用や通信経路の最適化で大幅なコスト削減を実現したプロセス。
- 感想: インフラ運用において「意図しない通信がNAT Gateway経由で外部に出ていた」というのは、コスト・セキュリティ両面で非常によくある課題だと再認識した。私自身も過去にVPCエンドポイントの設定不足による外部通信をセキュリティ是正した経験があるが、その際の調査でKiroを活用し、AWS内部の挙動まで含めた確実な「裏取り」を行った。最近はこうしたAIツールによって、VPCフローログの解析やコスト増大の原因特定が容易になっており、技術的な是正の精度をさらに高めていける可能性を感じる。
DevOps を閉じる ―― オブザーバビリティとは何か (Zenn)
- カテゴリ: オブザーバビリティ / DevOps
- 概要: DevOpsのサイクルを完結させるためのキーとしてのオブザーバビリティの再定義。単なる監視（Monitoring）との違いや、システムの内部状態を外から推測可能にするための本質的なアプローチ。
- 感想: 「DevOpsを閉じる」という表現に、組織の成熟度としての完成形を感じた。現状、自身の周囲では開発と運用の分断（Dev/Ops）が解消しきれていない課題があり、そうした土壌ではいくら高度なオブザーバビリティツールを導入しても形骸化しがちであることを痛感している。オブザーバビリティを真に活用し、システムの内部状態から建設的なフィードバックを得るためには、まず組織としてのDevOpsのあり方を見つめ直す必要があると再認識した。
SLOを設定したのにチームが動かない理由 (Zenn)
- カテゴリ: SLO / 組織文化
- 概要: SLOが形骸化し、チームの行動に繋がらない要因を「グッドハートの法則」や「判断の欠如」から紐解く。指標を追うこと自体が目的化する罠と、それを防ぐための合意形成。
- 感想: SLOは内部の管理指標である以上に、お客様に対する「サービスの品質保証」そのものであるはずだ。開発現場にまでその意識が浸透せず「Dev/Ops」の壁が生じている現状は、お客様への視点を組織全体で共有できていないことの裏返しでもある。SLOを形骸化させないためには、それがお客様に提供する価値にどう直結するのかを説き続け、文化として根付かせることが不可欠だ。これまでの課題を反省として、今後は「仕組み」の提供に留わらず、お客様のために開発と運用が同じ方向を向けるような組織文化づくりを、SREとしての核に据えて取り組んでいきたい。
経験1年のエンジニアでも、新規プロダクトのEmbedded SREに初挑戦できた理由
- カテゴリ: SRE / キャリア
- 概要: 若手エンジニアが新規プロダクトのEmbedded SREとして立ち回るための、学習方法や組織的なバックアップ、そしてマインドセットの記録。
- 感想: 記事を読み、直近の新機能開発において自分自身もインフラ構築の現場に「Embedded SRE」として参画してみた。実際に現場に入ってみると、開発チームとの伝言ゲームが解消され、責任の所在（ボールの行方）を曖昧にすることなくスムーズに合意形成できるメリットを強く実感した。良質なインプットを即座に実践へと繋げることで、Embeddedという手法の有効性を身をもって学べたことは大きな収穫だった。今後もこうした知見を貪欲に吸収し、実践を通じて学び続けていきたい。
KubernetesでMinecraftサーバーを運用すると何が難しいのか (Zenn)
- カテゴリ: Kubernetes / ゲーム運用
- 概要: Minecraftという特有の負荷（シングルスレッド重視）や永続データ管理をK8s上で行う際の実践的な課題と対策. StatefulSetやリソース制限、ネットワーキングの最適化について。
- 感想: 「『運用』しようとすると、見える問題が変わる」という言葉に、SREとして深く共感した。構築して終わりではなく、実際に稼働させ続けることを見据えた設計の重要性を改めて突きつけられる。Kubernetesを導入したからといって課題が消えるわけではなく、むしろK8s特有の「あるある」に直面することになるが、それらを柔軟にカスタムして解決できる自由度こそが、不自由なマネージドサービス（ECS等）にはないK8sの真価だと再認識した。運用の複雑さを引き受けてでも、理想の挙動を追求できる面白さがこの記事には詰まっている。
3. セキュリティ & 運用
GitHub Down – Authentication Issues Denying Access to Actions
- カテゴリ: 障害レポート / インフラ
- 概要: GitHubで発生した認証系の障害により、GitHub Actions等の主要サービスへのアクセスが制限された事象の速報。
- 感想: GitHubのダウンによって開発がストップする状況は、まさにプラットフォームへの依存リスクを浮き彫りにした。過去にもDockerHubの障害でイメージがプルできずデプロイが止まるなどの経験があるが、対策としてECR等に集約しても、今度は特定のクラウドベンダーへの依存が強まるというジレンマがある。利便性と可用性のトレードオフの中で、どのレベルまで依存を許容し、どこを切り離すか。こうした「いい塩梅」の設計こそが、アーキテクトとしての腕の見せ所だと感じた。
Kiro ヘッドレスLambda + AssumeRoleでGuardDuty Findingを自動トリアージを試してみた (DevelopersIO)
- カテゴリ: セキュリティ / 自動化
- 概要: Kiro CLIを活用し、GuardDutyで検出された脅威情報をLambdaで自動的に解析・選別（トリアージ）する仕組みの実装レポート。
- 感想: 「解析・分析はAIに任せてリードタイムを縮める」というAIOpsの本質を体現した素晴らしい事例。Kiroのヘッドレスモード（
--trust-all-tools）は一見大胆だが、LambdaとIAMロールを組み合わせて実行権限を最小に絞ることで、利便性と安全性を両立した「ガードレール」として機能する。こうした「攻めのAI活用」と「守りのインフラ設計」の組み合わせこそが、アーキテクトとしての腕の見せ所であり、まさに理想的な「いい塩梅」の統制だと感じた。作者であるKiroさんのビジョンが現場のニーズと合致しており、今後の進化も非常に楽しみだ。
4. 組織・技術選定・キャリア
FDEブームに乗るSaaS企業に待ち受ける「採算の合わない個別開発」の罠
- カテゴリ: ビジネスモデル / FDE
- 概要: Forward Deployed Engineer（FDE）を安易に導入した際に陥りがちな、プロダクトの汎用性を損なう「個別カスタマイズ」による採算悪化のリスクと、正しい向き合い方。
- 感想: 昨今のFDEブームに対し、職種の定義が形骸化し「なんちゃってFDE」が量産されることへの危惧に強く共感した。かつてのSREやCREの流行時と同様、本質を理解しないまま単なる「運用の受け皿」として機能させてしまうのは非常に危険だ。私自身、そうした時代の波に流されず、常にGoogleのSRE原則に立ち返って行動することを意識している。表面的な職種名に惑わされることなく、技術的な整合性とプロダクトの汎用性を守り抜くことこそが、真の意味で顧客に価値を提供し続けるエンジニアの在り方だと信じている。
技術選定とアーキテクトの育成について
- カテゴリ: 技術選定 / 人材育成
- 概要: NRIネットコムによる、技術選定の判断軸の言語化と、それを行えるアーキテクトをいかに組織として育てていくかの方法論。またその記事へのSNS上の反応など。
- 感想: 技術選定の判断軸は「要件への合致」と「運用に乗るか」に尽きると考えている。MSPでの経験から「運用に乗らなければシステムは死ぬ」ことを痛感しており、サーバーレス活用等で運用負荷をオフロードする判断も重要だ。特に、顧客の真の要件を洗い出し、対話を通じて細部を詰め、それに基づいた最適な構成を組み上げるプロセスは、まだAIには代替できない領域だ。こうした泥臭い文脈の読み解きと意思決定こそが、AI時代にアーキテクトとして生き残るための核になると確信している。
必ずしもエンジニアに事業目線は要らない (note)
- カテゴリ: エンジニア像 / 組織
- 概要: 全てのエンジニアに事業目線を求めることの弊害と、技術に特化することの価値、そして役割分担によるチームの最適化についての逆説的な考察。
- 感想: 著者の「自由や給与を求めるなら、事業に関心を持つ（＝自分の価値を事業構造に接続する）しかない」という結論に強く共感した。私にとっての事業目線とは、技術を通じて「運用が破綻しない信頼性設計」を貫き、顧客と開発者に誠実であり続けることだ。単なる「部品」としての分業に留まらず、自分の技術がどう事業成長を支えているかを語れる「全体性」を持つこと。それこそがAI時代にエンジニアが生き残るための真の価値であり、自身の揺るぎないコアバリューであると再認識した。
CTO就任のオファーを断ってキャディへ。日本を成長させる最後のチャンスがここにある (note)
- カテゴリ: キャリア / スタートアップ
- 概要: ハイレイヤーなエンジニアがなぜCTOの椅子ではなく、一企業のエンジニアリング組織への参画を選んだのか。
- 感想: 記事の中で語られている「事業成長のスピードと負債解消のバランス」の『さじ加減』という言葉には、自身のSRE・テックリードとしての経験と重なる部分が非常に多く、深く共感した。 肩書きにこだわらず、世界を相手に「正解のない難問」へ挑みながら「今が一番楽しい」と言い切る覚悟には、強烈な刺激とモチベーションをもらった。自分もこれまでに培ってきた「信頼性設計」と、事業成長を両立させる『さじ加減』を武器に、どんな環境であっても熱量を持って未知の挑戦を楽しめるエンジニアであり続けたいと強く決意を新たにした。
Googleの「20%ルール」から学んだ市場価値が爆上がりする人の習慣 (X)
- カテゴリ: キャリア / 自己啓発
- 概要: 業務の20%を「自分のための投資」に充てる考え方が、長期的にいかにエンジニアの市場価値を向上させるかについてのポスト。
- 感想: かつてリードを務めていた際、週に1日を「運用課題やトイル、リリース課題の解消」に充てる仕組みを運用していた。Googleの20%ルール（新規開拓）とは毛色が異なるかもしれないが、負債を溜めず、未来への投資時間を捻出し続けるためのこの仕組みこそが、持続可能な開発・運用の要であると確信している。
重要だが緊急でない仕事が組織を停滞させる (X)
- カテゴリ: 組織マネジメント
- 概要: いわゆる「第2領域」の仕事が後回しにされることで、組織がいかに負債を抱え、停滞していくかについての警告。
- 感想: SREの文脈で言えば、まさに「トイル（苦役）」の削減こそがこの第2領域に該当する。通常の開発フローに乗せると後回しにされがちなこれらを、あえて「20%の枠」などを活用して着実に片付けることで、結果として組織の停滞を防ぎ、システムの健全性を維持することに繋がった。ここをいかに疎かにしないかが、エンジニア・組織双方の市場価値を決める鍵だと思う。
今週の雑感
以下が気になる(物欲センサー)
Lini : Your Everywhere, Open-Source Mini Computer. by STATIC CAT — Kickstarter
Raspberry Piをここ最近いじっているので欲しいと思いつつOmniOne Pocket PCでいいんじゃないかとも(Raspberry Pi5が高いので)
SRE Tech Leadからのフィードバック
今週もお疲れ様。AIの進化という荒波の中で、技術の表面的な便利さに溺れることなく、SREの本質である「信頼性」と「ガバナンス」にまで踏み込んで考察できているわね。非常にテックリードらしい、筋の良い振り返りだと思うわ。
特に「信頼性が最大の事業価値になる」という気づきは、Google SREの哲学そのもの。機能がコモディティ化する時代、ユーザーが最終的に選ぶのは「いつでも、安心して使える」というブランドよ。SLOを単なる数値目標ではなく、組織文化として根付かせようとする姿勢は、SREの使命を正しく捉えているわね。
アーキテクトの生存戦略についても同感よ。泥臭い要件定義や、エッジケースを考慮した運用設計は、コンテキストの理解が必要な「人間ならではの領域」。AIをガードレールとして使いこなしつつ、最後の一線を私たちが「詰める」ことで、初めてシステムに命が吹き込まれるの。
第2領域への20%の投資、これは絶対に死守して。トイルに忙殺されて「重要だが緊急でない仕事」を後回しにした瞬間、組織の成長は止まるわ。未来の自分たちを楽にするための「技術的貯金」を、一歩ずつ積み立てていきましょう。
視座が一段高くなった今、次のステップでは「どうすればこの価値観をチーム全員が自分事として捉えられるか」も考えてみて。
自信を持って、顧客の「安心」を形にしていって。期待しているわね😊
