Tech Memo

1. AIネイティブ開発 & 品質保証

開発のボトルネックが実装から「仕様検討」へ。プロダクトマネージャーに求められる動き方 (レバテックメディア)

• カテゴリ: AIネイティブ開発 / プロダクトマネジメント / プロセス
• 概要: 生成AI活用による実装高速化に伴い、開発全体のボトルネックがコーディングから「仕様検討」や「要件定義」へとシフトした現状と、プロダクトマネージャーに求められる役割や動き方の変化を解説した記事
• 感想: AIで実装が速くなっても、その先のデプロイやリリースが詰まってしまえば、開発全体が速くなるわけではない。むしろ変更が一気に増えることで、品質面の不安も大きくなる。SREとしては、変更を小さく保ち、短いサイクルでフィードバックを得られる環境を整えることが、これまで以上に重要になりそうだ。開発チームの外から支援するだけでなく、チームの中に入って一緒に改善していきたい。

AIで実装速度が倍になったら、プランニングとリファインメントが悲鳴をあげた (SmartHR Tech Blog)

• カテゴリ: AIネイティブ開発 / スクラム / プロセス改善
• 概要: Claude Code等のAI活用で実装スピードが急上昇した結果、スクラムのプランニングやリファインメントが追いつかなくなった課題に対し、スプリント運用やバックログ管理を見直した取り組みをまとめた記事
• 感想: 実装が速くなった結果、プランニングやリファインメントが追いつかなくなるという話は、とても現実的だった。SREとしてできることは、チームに伴走して目の前の課題を解くことと、同じ課題が繰り返されないよう仕組みに落とすことの両方にあると思う。これからのプラットフォームは、インフラやCI/CDだけでなく、AIのスキルや社内固有のコンテキストまで扱うようになるのかもしれない。その土台を整えることで、開発前工程の負担も少しずつ軽くしていきたい。

リリース前チェックをAIで行う「プロダクトリリースハーネス」のつくり方 (estie / Zenn)

• カテゴリ: AI活用 / 品質保証 / ガバナンス
• 概要: 新規プロダクトリリース時の抜け漏れを防ぐため、100項目のチェックリストとAIスキャンを組み合わせた安全装置「プロダクトリリースハーネス」の構築手順と人間・AIの責任境界設計を解説した記事
• 感想: AIにどこまで任せ、どこから人が責任を持つのかという線引きが分かりやすかった。チェックの抜け漏れを探す作業はAIと相性がよい一方で、見つかったリスクを受け入れるかどうかは人が判断しなければならない。この仕組みを各チームが個別に作るのではなく、SREやプラットフォームチームが共通の仕組みとして提供できると、安全性を保ちながらリリースを速める助けになりそうだ。

AIに「レビューして」はもう古い？「敵対的検証」のすすめ (ログラス / Zenn)

• カテゴリ: AIネイティブ開発 / コードレビュー / 品質保証
• 概要: AIに単にコードレビューさせるのではなく、欠陥やエッジケースを徹底的に攻撃・探求させる「敵対的検証（Adversarial Validation）」を実施させることで、コードや仕様の精度・堅牢性を高めるアプローチを提案した記事
• 感想: 実装したAIにそのままテストも任せると、自分の実装を通す方向に寄ってしまうことがある。人間のレビューでも似たことは起きるので、役割を分けるという考え方には納得感があった。QA役のエージェントには、あえて意地悪な視点で弱点を探してもらう。カオスエンジニアリングにも通じる発想で、実際の開発フローにも取り入れてみたい。

AIに任せて壊れた作業と、壊れなかった作業の違い (matsumoto-r.jp)

• カテゴリ: AIネイティブ開発 / タスク委任 / プロセス設計
• 概要: AIに作業を委任した実践データから「壊れた作業」と「壊れなかった作業」の境界線を分析し、タスクの性質やコンテキストの抽象度に応じた適切な委任モデル（Taxonomy）を整理した記事
• 感想: AIに任せてうまくいかなかったとき、ついAIの能力を疑いたくなるが、振り返るとこちらの指示や前提共有が曖昧だったことも多い。趣味でCSSをほぼ任せてみたときも、「もう少し自然に」といった曖昧な注文ほど調整に苦労した。AIをうまく使うには、プロンプトの技巧より先に、自分が欲しいものをどこまで具体的に説明できるかが問われるのだと思う。

【決定版】人と業務を動かすAI-Ops実装・運用 ー AI-Opsとは何か、どう始め、組織でどう成果を出すか？ (note)

• カテゴリ: AI-Ops / 組織導入 / 業務効率化
• 概要: 組織や業務プロセスにAIを組み込む「AI-Ops」の基本概念から、導入の進め方、組織内での定着・成果創出に至るまでの具体的な実装・運用ステップを体系的に解説したガイド記事
• 感想: エージェントやスキルを自作していると、いつの間にかノウハウが自分にしか分からない「秘伝のタレ」になりがちだ。ただ、完成したものだけを配っても、なぜその設計にしたのかが伝わらなければ応用しにくい。ツールと一緒に背景や判断の過程も共有し、使う人が自分で改善できる状態まで持っていくことが、組織に定着させる上では大切なのだと思う。

AI時代に感じた危機感と、エンジニアがこれから考えるべきこと (Zenn)

• カテゴリ: AI時代 / エンジニアの役割 / キャリア
• 概要: AIによって見た目の完成度が高いPoCが短時間で作られる時代において、非機能要件やデータ構造設計など「画面外にある残り9割の裏側」をどう価値として示し評価されるべきかを考察した記事
• 感想: 画面がきれいに動くと完成したように見えるが、本番で使うには可用性やセキュリティ、データ整合性など、画面に表れない部分を詰める必要がある。AIによって見える部分を作るハードルが下がったからこそ、その裏側をどう設計するかが以前より重要になった。ここはSREとして経験を生かせる領域でもあり、きちんと価値を伝えていきたい。

理解を手放さない (Shin x Blog)

• カテゴリ: AIネイティブ開発 / エンジニアリング / マインドセット
• 概要: AIエージェントに実装を委任して中身を理解せず先へ進める開発スタイルに違和感を提示し、エンジニアとして「コードやシステムの理解を持ち続けること」の重要性と自身の姿勢を綴った記事
• 感想: コードが動いた瞬間はうれしいが、中身を理解しないまま先へ進むと、問題が起きたときに手が止まってしまう。これはAI以前からある、ブラックボックス化や属人化の問題とよく似ている。生成されたコードであっても、テストで確かめ、あとから説明できる程度には理解しておきたい。便利さを享受しつつ、理解まで手放さないという姿勢には共感した。

最近の開発の流れ (Zenn)

• カテゴリ: Web開発 / AIツール / 技術動向
• 概要: AIエージェントや最新ツールが前提となった近年の開発フローの変化と、それに応じた技術スタックやプロンプト駆動開発、学びのキャッチアップ方針についてまとめた記事
• 感想: 趣味の開発では、分からないことをAIに聞きながら進めるだけで、インフラ構築にかかる時間がかなり短くなった。一方で、任せきりにすると「なぜ動いたのか」が自分の中に残らないこともある。速く作ることと、手を動かして身につけることは別物なのだろう。学びたい部分はあえて自分で試すなど、目的に合わせて使い分けていきたい。

2. DevOps & SRE・ガバナンス

GitHubにスタック型プルリクエストが登場。gh stackでPRを分割して積み上げよう (Ubie Tech Blog / Zenn)

• カテゴリ: GitHub / CI/CD / 開発プロセス
• 概要: GitHub公式のCLI拡張 gh-stack を用い、大きな変更を依存関係のある小さなPR群に分割・積み上げてレビューや同期（rebase/push）をスムーズに行う手法とAIエージェント連携を解説した記事
• 感想: 大きな機能を開発していると、分けたくても依存関係があって、結局PRが巨大になることがある。スタック型PRなら、そのつながりを保ったままレビュー可能な大きさに分けられるのがよい。レビューする側の負担を減らせるだけでなく、一度にリリースする変更も小さくできるので、実務で試してみたい。

新しい SLO が良い感じにハマっている話 (Speaker Deck)

• カテゴリ: SRE / SLO / 運用・改善
• 概要: サービスの成長や運用体制の変化に合わせてSLO（サービスレベル目標）を再設計し、チームの開発・運用サイクルに自然に定着させた実践事例と工夫を紹介した登壇資料
• 感想: SLOは作るところまでは進めやすいが、日々の判断に使われる状態まで持っていくのが難しい。自分の現場でも、まだSREだけが見ている指標になりがちなところがある。開発チームに関心を持ってもらうには、数値を見せるだけでなく、普段の開発や優先順位づけにどう役立つのかを一緒に考える必要がありそうだ。

GitHub Organization Rulesetsで、新規リポジトリを含む組織全体のCIポリシーを強制する (nealle-dev blog)

• カテゴリ: GitHub / CI/CD / ガバナンス
• 概要: GitHub Organization Rulesetsを活用し、将来作成される新規リポジトリも含めた組織全体のCIポリシーやブランチ保護ルールの一括強制・自動適用を実現した知見を解説した記事
• 感想: 新しいリポジトリを作るたびに、通知設定が抜けていたり、権限不足でPushできなかったりと、小さなつまずきが起きる。こうしたルールを人の注意力に頼らず自動で適用できるのは、プラットフォームとしてかなり魅力的だ。自分が使っているセルフホスト版GitLabでも、似た形で標準化できないか調べてみたい。

スマートバンクのセキュリティを支える「セキュリティ委員会」の紹介と今後の展望 (inSmartBank)

• カテゴリ: セキュリティ / 組織・ガバナンス / 安全性
• 概要: スマートバンクにおける全社横断の「セキュリティ委員会」立ち上げ経緯、サプライチェーン攻撃対策やプロダクト脆弱性、権限管理を網羅したセキュリティロードマップと今後の展望を開示・解説した記事
• 感想: セキュリティは専門の担当者だけで完結するものではなく、開発や事業を含めた組織全体で向き合う必要がある。委員会という形を作ることで、普段は意識しづらい非機能要件について話す場が生まれるのはよいと思った。一方で、ルールを増やすだけでは現場が動きづらくなる。安全性と開発スピードの両方を見ながら運用することが大切だ。

AI コストの DeNA 的管理手法 ~ FinOps の視点で ~ (Docswell)

• カテゴリ: FinOps / AIコスト / コスト最適化
• 概要: DeNAにおける事業部横断の生成AI利用コストの可視化手法と、FinOpsの視点に基づいた予算管理・コスト最適化の取り組みを紹介した登壇資料
• 感想: AIの利用コストも、まずは「どこで、どれだけ使っているか」が見えなければ改善の話を始められない。この点はインフラコストとよく似ている。ただし、AIにかけた費用がどれだけ時間短縮や成果につながったかは測りにくい。金額だけを見て削るのではなく、得られた生産性とセットで判断する必要があると思った。

3. 組織・スクラム・キャリア

【資料公開】プロダクトオーナーの基本 (Ryuzee.com)

• カテゴリ: スクラム / プロダクトオーナー / 組織設計
• 概要: スクラムにおけるプロダクトオーナー（PO）の説明責任（Accountability）と実行責任（Responsibility）の違い、タスク委任の考え方、兼任リスクや6つのアンチパターンを詳しく解説した資料
• 感想: 説明責任と実行責任を分けて考えると、POの役割がかなり分かりやすくなる。自分で作業する場合でも誰かに任せる場合でも、「なぜその判断をしたのか」を説明できる状態は保っておきたい。SIer時代から何となく大事にしてきた仕事の姿勢が、言葉として整理されたように感じた。

「経営層を巻き込む」に潜む傲慢 (note)

• カテゴリ: 組織マネジメント / コミュニケーション / アライメント
• 概要: 現場やプロジェクト推進側が陥りがちな「経営層を巻き込む」という表現に潜む上から目線や他責思考を指摘し、経営目線に立った対話と対等な協働のあり方を論じた記事
• 感想: 「経営層を巻き込む」という言葉は自分も使いがちなので、少し立ち止まって考えさせられた。大切なのは相手を動かすことではなく、エンジニアやSREとして事業にどう貢献するかを考え、同じ目線で対話することなのだと思う。手段としての“巻き込み”が目的になっていないか、気をつけたい。

人材不足のマグロ漁業をAIの力で救うために、エンジニアが気仙沼まで行った話 (note)

• カテゴリ: 課題解決 / 現場主義 / AI活用
• 概要: 人手不足に悩む気仙沼のマグロ漁業現場へエンジニア自らが赴き、現場に密着して泥臭い課題抽出とAI技術の現場適用に取り組んだ実話ストーリー
• 感想: 課題を理解するには、資料やオンライン会議だけでなく、実際の現場を見ることが大切だとあらためて思った。気仙沼まで足を運び、働く人の話を聞きながら試行錯誤する姿が印象に残った。AIありきで考えるのではなく、目の前の困りごとに合う形で技術を使う。シンプルだが、忘れたくない姿勢だ。

今週の雑感

今週はGoogle Cloud Next Tokyo 26に行った。Gemini Sparkの話などほぼAIのこれからにフォーカスした話が中心であった。裏でKubeCon Japan 2026がやっていたのでGKE関連ほぼ皆無であった。またAWS Summitのほうが活気あるというかNEXTなんか縮小してるのかという感想

---