Team Topologiesのストリームアラインドチームのようにチームを分割すると、各チームが自律的に動く一方で、他チームの成功や失敗から学びにくくなり、専門知識が分断される問題が生じる。Spotifyの組織モデルを例に、自律性を保ちながら専門知識を共有する方法を考察する記事。
何年も動き続ける resilient なソフトウェアを作るうえで重要だと筆者が考える指針をまとめた意見記事。開発者としての経験から得た考えを順不同で並べたもので、特定の技術に依存しない設計・実装・保守の姿勢に関する内容。
SREの現場で組織構造を考える際に役立つ「チームトポロジー」の基本的な用語を解説する記事。ユーザーに良い機能を素早く届けるためのチーム分割や組織設計の考え方を紹介している。
AIエージェントに実装を任せることでPRやテストコードが増え、CIの稼働時間が増大した問題に対し、CIの目的を維持したまま3つの対応を行い、1runあたり144分から39分（73%削減）まで短縮した取り組みの紹介。
エージェントはゲームの一発生成や大規模なマイグレーションをこなせるようになったが、実際のソフトウェア開発の大部分は依然として人間のエンジニアが主導している。多くの組織が大量のトークンをエージェントに投じたものの成果は芳しくなく、幻滅期に入っている。次の段階では、エンジニアの価値は「良いアイデアを出すこと」と「適切なアーキテクチャを設計すること」に移り、バグの検出と修正、本番エラーのデバッグとパッチ適用、エージェント用プロンプトの最適化、フロントエンドの一貫性維持といった作業はエージェントに任せるべき領域として挙げられる。そのためにはループやガードレール、評価基盤など新しいプリミティブの整備が必要になる。
生成AIを業務に組み込む際、生成→評価→実行の流れでは、実行しないと評価情報が得られない処理に対応できない。実行を段階的に許可し、何を観測し、その結果から次の実行範囲をどう判断するかというHuman-in-the-loopのゲート設計の必要性を論じている。
全28回のDevOps実践連載の振り返りとして、Git/GitHubによる開発基盤、DockerとGitHub ActionsのCI/CD、EKSとTerraformのIaC、CloudWatchによる監視、AWS BudgetsやGuardDuty/Security Hubによるフィードバックまでを総括。そのうえで「AIがコードやインフラ定義を生成するならDevOpsは不要か」という問いに対し、SRE・GitOps・プラットフォームエンジニアリング・AIOpsはDevOpsを置き換えたものではなく進化形だと整理し、AI時代に変わるもの（定型コード生成やログ解析の一次切り分けの自動化など）と変わらないものを論じる。
2026年9月11日に開催されたDevelopers Summit 2026と「もう一度考えるSRE #2 in 福岡」の参加レポート。BtoB SaaSのバックエンド開発を担当する筆者が、生成AI活用やAI時代のATDD、SREに関するセッションから得た気づきと、自チームに持ち帰りたい事柄をまとめている。
ShopifyがReact NativeからSwift/Kotlinによるネイティブ開発へ回帰する方針を示したことを受け、クロスプラットフォーム開発が解決できるコストと解決できないコストを整理した記事。技術選定のトレードオフを考える材料になる。
Provetで実際に起きた障害危機に対し、「Code Yellow」を用いて組織を止めずに8週間で収束させた事例。技術的な不安定さ以上に顧客の信頼低下が深刻になる中、James Stanierが、一時的に組織を動員して危機に対応するマネジメント手法とその運用を紹介している。テックリード向けの障害対応・組織運営の知見。
AWS を用いたシステム導入の工程のうち、どこを AI に任せ、どこを手作業で行っているかを筆者の経験から整理した記事。AI はボトルネックを解消するのではなく別の工程に移しているだけという指摘を出発点に、AI を使いこなせているとは言えない現状を述べている。
アクセンチュアの崎原晴香氏による登壇内容の紹介。LambdaランタイムのEoL対応やライブラリ脆弱性対応といった横断的な繰り返し作業が各サービスで個別に発生し開発工数を圧迫する問題に対し、Platform Engineeringを共通基盤による解決策として提示する。Kubernetesは必須ではなく、「どこか一ヶ所に集まるオペレーションに共通の統制を利かせる」考え方が本質だとし、Kyverno・Cosign・Istioのようなクラスタ全体へのポリシー適用や、組織ポリシーを反映したAWS CDKコンストラクタ、サンプルリポジトリ、AWS Configによる検知・修正など、Kubernetes以外の例も挙げる。共通基盤を一度に全サービスへ適用しようとすると設計・浸透・利用の3つの難しさに直面するため、完成形を急がず、チーム内の課題共有や小さな便利ツール作りから段階的に始めるLevel 1的な進め方を解説する。
AIを業務に組み込む際、実行前に評価に必要な情報が得られない処理では、最終承認型のHuman-in-the-loopだけでは不十分であり、「事前評価可能性」と「可逆性」に基づく段階的なゲート判断（限定実行→観測→再判断）として設計すべきだと論じる。Kubernetesのローリング更新を具体例として、その部品と人間の承認ワークフローの設計を分けて考える必要性を述べている。
フロントエンドからSREに異動した著者が、前提知識不足やPRレビューの難しさを、Claude Codeを活用して乗り越えた過程を紹介。AIにレビュー論点を洗い出させ、下書きコメントまでに留めて人間が判断する手法や、CI移行時のコンテナイメージ検証をskill化する運用などが具体的に述べられている。
オンコール調査を自動化するSlack bot「dev-bot」の紹介。Google Cloudのアラート発火時にClaude Managed Agentsが人間より先に調査し、影響範囲や対処方法をSlackスレッドに報告する。Runbookの整備が精度の鍵で、偽陽性評価によるアラート削減も実施。コストは3日1ドルと低く、週次の人間レビューなど自動化しない範囲も意図的に設計している。
AIによるインシデント対応ツールが増えるほど、エンジニアの運用経験が減り、複雑な障害では対応力が落ちるという懸念を論じる。自動化の皮肉（アイアニー・オブ・オートメーション）を引用し、シミュレーション訓練やハンズオン演習の重要性を説く。
Google Cloudブログで、AIプロトタイプを本番環境に移行するスタートアップ向けに、オンボーディング、スケール、管理の3フェーズに分けた10の質問と実践的なコードスニペットを紹介。Google AI StudioとGemini Enterprise Agent Platformの使い分け、IAM設定、コストやエージェント暴走の防止など、GCP固有の移行ノウハウに焦点を当てている。
社会人1年目のデータ移行の実体験を通してSREの基本概念（監視・アラート、自動化、SLO、オンコールなど）を説明する初心者向け記事。具体性は薄いが、SREの考え方を把握できる。
複数サーバを行き来する環境で本番とローカルを誤認する事故を防ぐための対策集。プロンプトへの色付け、サーバごとのメモ記録、apt-mark showmanualやapt履歴での導入済みパッケージ調査、SSH config整理、rm前のfind確認やバックアップ・構文チェックなど、現在地の可視化と危険操作の防護を具体的な手順で紹介している。
環境変数は本来デプロイ環境ごとに値が異なるもの（DB接続先や認証情報など）に限定すべきで、環境間で変わらないAPIパスやパラメータなどはコードに書くべきだと主張する記事。何でも環境変数にすると変更漏れによる障害リスクが増えるほか、AIエージェントが機微情報保護のため.envを読めない設計になっている現状とも相性が悪いと指摘している。
AWSアクセスキーは有効期限がなく漏洩時の被害が大きいため、開発者はaws login、AWSリソースはIAMロール、CI/CDはOIDC、外部サーバーはIAM Roles Anywhereといった一時クレデンシャルへの移行を提案。移行できない場合の対策として、gitleaksやPush Protectionによる予防、最小権限やローテーションによる防御、GuardDutyによる検知という3段構えの防御策と、漏洩時は即座に無効化すべきことを解説している。