TECH MEMO / FIELD NOTE週報（2026/10/10） - レビュー解体とSSoT原則、DevOps AgentとAPI防衛、CREスクラムと中堅の壁
1. AIエンジニアリング & ソフトウェア設計
AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え
- カテゴリ: ソフトウェアテスト / AIコーディング / コードレビュー
- 概要: 和田卓人（t-wada）氏へのインタビュー記事。AIによるコード生成が普及して実装速度が加速する一方、人間による確認作業が開発における最大のボトルネックになっていると指摘している。従来のコードレビューを「上流の仕様レビュー」「テスト駆動開発」「型システムによるガードレール」「リスクマッピング」「継続的な理解」の5要素へ分散・再配置するアプローチを提示し、コードの保守性だけでなく「認知の負債」をどう防ぐかを解説している。
- 感想: 人の介入が開発速度のボトルネックになっているという指摘には共感しつつも、実務では「どこまでAIに任せられるか」の境界線を意識しています。ビジネスロジックの複雑さには、記事にある「上流の仕様レビュー」の不足が関わることが多いと考えています。仕様の整理や言語化の段階であれば、AIを活用できると思います。一方で、変更に伴う影響範囲の調査などは現場での運用に関する知識が強く求められるため、現状ではAIに丸投げするのが難しい領域だと感じています。
俺のAIプログラミング手法(2026/10/05) (Zenn)
- カテゴリ: AIプログラミング / Claude Code / 評価基盤
- 概要: Claude Codeなどを活用したAIプログラミングの実践知見とワークフローの棚卸し記事。「人間の役割の定義」「モデル性能の観察」「評価指標の策定」「イテレーションの評価」というループ構築の重要性を説いている。数値化できる指標による自動化の進め方や、半年で陳腐化するプロンプトのアンラーニング、Agents.mdなどのグローバルプロンプトを最小限にとどめドメイン知識の注入に集中する手法などを解説している。
- 感想: プライベートではGeminiやCodexを使いつつ、業務ではClaudeを活用しているため、今の自分にぴったりの内容で、参考になりました。「人間の役割を定義する」という姿勢には深く同意します。「常にアンラーニングする」という視点にも納得しました。私の環境でもClaudeに社内ナレッジ（Skillsのreference）の更新許可を与え、知識の陳腐化に対応できるか実験を進めているところです。
【AI DevEx Conference 2026】変更し続けられるシステムをどう保つか — AI時代のSSoTという設計原則
- カテゴリ: ソフトウェア設計 / アーキテクチャ / SSoT
- 概要: AI DevEx Conference 2026におけるDress Codeの河村勇樹氏のセッションレポート。AI生成による変更頻度と構造の複雑化がレガシー化を加速させると指摘し、「直し続ける」から「壊して作り直せる」へのパラダイムシフトを提唱している。影響をモジュール境界内にとどめる「破壊性」とゼロから再生成できる「回復性」を両立させるため、成果物のコードではなく源泉となる事実をSSoT（Single Source of Truth）として残す設計原則と実践例を解説している。
- 感想: 10月に新しい職場へ移り、キャッチアップを進める中でSSoTの重要性をあらためて実感しています。ドキュメントに書かれていないことが多く、結局はコードを直接読み解く場面が目立ちます。以前、自分のnote記事「構成図を「残す」ことの絶対的な価値 ―― SREがAIと描く、終わりなき海図の自動化」でも触れましたが、インフラ構成図がない状態でのキャッチアップは認知負荷が非常に高いです。まずはインフラ関連のSSoTを整備し、信頼できる事実をチームに残していくことが直近の課題だと感じています。
MicrosoftがローカルAI「MAI-Code-1.1-Flash」をリリース＆ローカルAIとクラウドAIを組み合わせた「ハイブリッドインテリジェンス」も提唱
- カテゴリ: ローカルAI / Microsoft / ハイブリッドインテリジェンス
- 概要: Microsoftがローカル実行を想定した小規模コーディングモデル「MAI-Code-1.1-Flash」を発表したニュース。前バージョンと比べて推論速度が向上し、コストも大幅に下がった。3ビット量子化によってローカル実行に対応している（Microsoftの発表）。PCローカルで動作するAIとクラウド上の大規模モデルを適材適所で協調させる「Hybrid Intelligence（ハイブリッドインテリジェンス）」構想を掲げ、プライバシー保護とレイテンシ削減、高度な推論を両立する未来像を紹介している。
- 感想: ローカルAIとクラウドAIを組み合わせるハイブリッドAIのアプローチ自体は面白いと感じます。ただ、現状のCopilot+ PCがどこまで真価を発揮できているのかは未知数です。ローカルモデルは情報が古くなりがちという課題もあります。手元の情報が適切にアップデートされる仕組みが整えば、クラウド側のトークン消費を抑える手段としても有効なのではないかと期待しています。
2. クラウドインフラ・SRE & プラットフォーム・セキュリティ
[AWS 秋のクラウドオペレーション祭り 2026]AWS DevOps Agentで変わる リリースと運用対応 ~リリース管理機能と Directed actions のご紹介~
- カテゴリ: AWS / AWS DevOps Agent / 運用自動化
- 概要: AWSの運用自動化エージェント「AWS DevOps Agent」の新機能である「リリース管理機能（プレビュー）」と「Directed actions」を解説したイベント登壇スライド。従来は読み取り中心だったエージェントが、運用者の明示的な承認をトリガーとして安全にAWSリソースへの変更操作を実行できる仕組みや、承認ログのCloudTrail記録による証跡管理、リリース準備レビューや障害緩和手順の自動化を通じた運用負荷軽減のアプローチを紹介している。
- 感想: リリース管理や承認付きの変更操作（Directed actions）によってインシデントを未然に防げるようになれば、従来の運用作業を担うSREはいらなくなるのではないか、と感じました。Google CloudでもGemini Cloud Assistなどの追従が進んでいますが、こうした自律運用が現実味を帯びるにつれ、SREの主戦場は障害対応などの火消しから、AIが安全に変更を実行するためのガードレール設計やアーキテクチャ設計、非機能要件の担保へとシフトしていくと考えています。
Kubernetesの監査ログ(Audit Log)入門 (Qiita)
- カテゴリ: Kubernetes / 監査ログ / セキュリティ
- 概要: Kubernetes環境におけるAPIリクエストの証跡を記録する「監査ログ（Audit Log）」の基本構造と設定方法を解説した入門記事。Podやノードの状態変化を記録するEventログとの違い、監査イベントの4つのステージ（RequestReceived, ResponseStarted, ResponseComplete, Panic）や4つの監査レベル（None, Metadata, Request, RequestResponse）、Policyファイルの書き方、kube-apiserverへの設定手順とベストプラクティスを整理している。
- 感想: SOC2やISMSへの対応に活用できるのではないか、という実務的な関心を持って読みました。ISMS認証の取得やSOC2のType 1・Type 2の報告書を受領すること自体よりも、その後も継続して運用を維持することのほうが難しいと日頃から実感しています。特にインフラのログ周りでは、運用が形骸化せずに続いているか、是正すべき点がないかを意識して監査ログを整備していきたいです。
APIセキュリティ、どこから見直す？ OWASPとNISTを使った点検の始め方
- カテゴリ: セキュリティ / API / ガバナンス
- 概要: AIエージェントの普及によって攻撃の試行回数が増え、執拗に攻撃を続けられるようになっている状況を踏まえ、APIセキュリティ対策の総点検手法を解説した記事。AI時代には攻撃者の手戻りや疲弊を期待した経験則が通用しないとし、OWASP API Security Top 10によるプラットフォーム・設計の脆弱性点検や、NIST SP 800-228を基にした認証・認可・ガバナンスのベストプラクティスを体系的に活用する手順を紹介している。
- 感想: 「社内からしか使わないから大丈夫」「開発者同士だから悪用しない」というAPIに対する油断を指摘され、ハッとさせられました。内部APIは権限管理が甘くなりやすく、一度エンドポイントを叩けたら何でも見えてしまうような状態になりがちです。AIエージェントの利用によって、「攻撃には手間がかかり、攻撃者も疲弊する」という前提が崩れ、これまでの経験則ではどのような被害が起きるかを予想しにくくなっています。だからこそ個人の感覚に頼らず、OWASPやNISTといった標準フレームワークに立ち返って機械的に点検し、防御側もAIを使って高速に検証を回していく必要があると感じました。
バイブコーディングで作った公開中のWebアプリ、9割に脆弱性 MSの研究者など調査
- カテゴリ: セキュリティ / バイブコーディング / 脆弱性
- 概要: 米Microsoftやシンガポール国立大学の研究チームによる、AI生成Webアプリのセキュリティ実態調査を紹介した記事。公開稼働中のバイブコーディング製Webアプリ200件を調査したところ、91%に少なくとも1つの脆弱性が存在し、見つかった脆弱性の約66%が「致命的」または「高」の深刻度に分類された（調査論文）。原因の多くは知識の欠陥（63.4%）や目的の欠陥（23.1%）にあり、プロンプトに「本番運用に耐えるものを」と明記すると脆弱性が減る一方、過度な技術指示はかえって悪化させると報告している。
- 感想: AIによって誰もが手軽にアプリを作れるようになったからこそ、安全に動かすための運用設計をSREとして考える必要があると感じました。9割に脆弱性があるという調査結果は深刻ですが、AIの時代に闇雲に利用を禁止するのは得策ではありません。アーキテクチャとしてどう構成すべきか、非機能要件で何を重視すべきかを整理し、安全にデプロイできる仕組みを整えるなど、開発者を支援する立場で運用基盤を支えていきたいです。
不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について
- カテゴリ: セキュリティ / インシデント対応 / ガバナンス
- 概要: 昨今のサイバー攻撃や不正アクセスによる情報漏えい事案の急増を受け、IPAが速やかな点検と実施を呼びかけたセキュリティ注意喚起。自組織が独自に運用する外部公開アプリケーションの網羅的な洗い出し、平時との差異に着目した直近1〜3か月のアクセスログ調査、未適用の脆弱性パッチの適用、不要な公開サービスの停止や多要素認証の徹底など、即座に着手すべき具体的チェック項目を提示している。
- 感想: 直近でセキュリティ関連の報道が続いていたため関心を持って読みました。対策の内容自体は基本的な事項が中心であり、基本的な対策を愚直に続けることの重要性をあらためて感じます。インシデントが起きる前は現場で危機感を持ちにくい面もありますが、ISMSやSOC2で求められる事項を根拠にして、必要な運用を続けていくのが現実的だと考えています。形骸化させないためにも、まずは誰かが責任を持ち、継続して運用できる仕組みにしていく必要があります。
3. 組織戦略・FDE & エンジニア組織・キャリア
FDE（フォワードデプロイドエンジニアリング）によって開発されたAIエージェントの7割は使われず、FDEの名前で単なるコンサルティングが販売されるようになる危険が高まるとガートナーが予測
- カテゴリ: FDE / AIエージェント / 組織戦略
- 概要: ガートナーが、ベンダーのFDE（フォワードデプロイドエンジニアリング）によって開発されたAIエージェントの70%が2028年までに使われずに放棄されると予測したレポートの紹介記事。多くのベンダーが単なるプロフェッショナルサービスやコンサルティングを「FDE」と称して販売する「FDE洗浄」のリスクを警告している。顧客ニーズをコア製品へ還元する仕組みや明確な出口戦略がないまま現場へ常駐しても、構造的に失敗する恐れが高いと分析している。
- 感想: AIエージェントが放棄されるという予測を読み、これもやはり運用の問題だと感じました。作ってそれっきりになり、最初の段階から運用の視点や引き継ぎが考慮されていないのは、日本のSIerなどでも見られる構造的な課題です。FDEの本来の使命は、現場でエージェントが使われ続けることにあります。導入後の問い合わせや日々のメンテナンスを顧客側で完結できるよう、運用に乗せるところまで支援してこそ意味があると考えています。
New FDE Pathways For AWS Partners: Get Ready for Production Agentic AI Delivery
- カテゴリ: AWS / FDE / パートナー戦略
- 概要: AWSがパートナー企業向けに発表した、本番環境向けAgentic AIデリバリーを支援する新プログラム「FDE Pathways」の解説記事。単発のデモにとどまらず本番運用に耐えるAIエージェントを提供するため、信頼できるデータ連携（Ground）、自律ワークフローの制御（Orchestrate）、評価とガバナンス（Prove）の3つの技術領域を体系化している。パートナーエンジニアのスキル評価と育成を通じて、持続可能なFDE体制の構築を支援する枠組みを紹介している。
- 感想: 先ほどのガートナーの予測とも重なりますが、国内では単なる客先常駐や受託開発、AIコンサルに新しいラベルを貼っただけの「なんちゃってFDE」が量産されている印象を持っています。本来のFDEは、自社製品を持ち、それを顧客の業務フローに組み込んで価値を出す役割のはずです。AWSが本番運用のための技術要件（データ連携や自律制御、評価など）を体系化したことは、本来のFDEとは何かを見極める上で良い指針になると感じました。
エンジニアよ、商談に出よう
- カテゴリ: キャリア / プロダクト開発 / 顧客理解
- 概要: AIによりコード生成やものづくり自体のコストが下がる中で、「何を作るかを決めること」の価値が相対的に高まっているとし、現場のエンジニアが顧客との商談に同席する意義を説いた実践記事。顧客は機能ではなくユースケースで会話するため、商談に同席して現場の一次情報を直接得ることで、機能の適切な翻訳や使われない機能の開発防止が可能となり、エンジニア自身の納得感や開発の質が向上した経験を共有している。
- 感想: 開発と顧客の間には距離ができやすいため、顧客理解が必要だという点にはAIの登場以前から深く共感しています。ただし、誰もが商談へ同席すればよいわけではありません。ビジネス上のマナーや配慮に欠け、不用意な発言をしてしまうエンジニアも一定数います。そもそも「エンジニアが商談に出るべきか」という議論が生じる背景には、営業と開発の部署間連携が十分に取れていないという根本的な課題があると感じます。営業側からの情報共有が適切に行われていれば、全員が直接同席しなくても顧客理解は深められるはずです。
割り込みの多い CRE でスクラムは回るのか ─ 未経験スクラムマスターが 4 か月試したこと
- カテゴリ: CRE / スクラム / チーム運営
- 概要: クラウドサインのCRE（Customer Reliability Engineer）チームにおいて、未経験のスクラムマスターが割り込みの多い環境でスクラムを再導入・実践した4か月の記録。Jiraの実績値に基づいた「割り込みバッファ」の算出、カレンダー連携によるキャパシティ計算や週次集計の自動化、Agent Skillsを用いたスクラムガイド準拠の相談基盤など、少人数・兼務体制を支える工夫を紹介している。問い合わせ対応を単なる作業で終わらせず、顧客課題を発見して自律的な改善につなげるプロセスを解説している。
- 感想: SREでも全く同じ課題に直面した経験があります。運用タスクや他チームからの差し込みによってスクラムが回らなくなり、人数も少なかったため、カンバン方式へ切り替えて都度優先度を判断する運用に落ち着きました。以前のnote記事「AIにチケット作成を丸投げするな。SREが磨く「課題の解像度」と3つの型」でも触れたように、SREの課題は中長期的なものが多く、1週間などのスプリントに無理に収めるより最終的に解決できればよいと考えています。ただ、不確実性と向き合うためにバッファを多めに確保しておくという記事のアプローチには深く共感しました。
シニアになりきれない中堅エンジニアは、何を読めばいいのか 2026年版
- カテゴリ: キャリア / エンジニア組織 / 読書
- 概要: 自分で難しい問題を解くだけでなく「チームや組織を勝たせること」が求められる中堅エンジニアに向けて、思考の枠組みや行動を変えるための推薦書籍をキュレーションした記事。長期的に実力を発揮するためにも心身の健康や休養を重視し、組織の意思決定、目標設定、評価とフィードバック、キャリアの自己決定に至るまで、変化の激しいAI時代に立ち返るべき指針を提示している。
- 感想: シニアとして求められる役割の変化には深く共感します。自分で実務を抱え込んで残業を増やしても評価されるわけではありませんし、シニアになっていく上でも「体は資本」だと感じます。私はテック寄りのエンジニアですが、技術で解決策を提案するだけでなく、その先でどうチームを勝たせるかを意識しています。自分ですべての作業をするのではなく、方針を示してメンバーに挑戦しながら自走してもらい、いざという時にリカバリーできる体制を整えておくことこそが、組織を育てるシニアの役目だと考えています。
今週の雑感
- Surface Laptop Ultraが発表されました。冷静に考えるとDGX Sparkを買った方が良い気がしてきましたが、お財布に余裕がありません。そもそも、ディスプレイの縦横比3:2があまり好きではありません。
- Googlebookの開封動画が出始めました。インテル機は色々とあるらしいですが、実際に使ってみた感想を早く知りたいです。開封するだけの動画はお腹いっぱいです。
- キャラメイクで話題になっていたAion2をROG Xbox Ally Xで始めました。キャラメイクは後から変更できますが、色々と痛恨のミスをしてしまいました。
欲しいもの（物欲センサー）
Dell XPS 13 DX13260
特盛モデルがブラックフライデーでどのくらい値下がりするか様子見です。ThinkPad X1 Carbonと悩んでいます。
SRE Tech Leadからのフィードバック
今週もお疲れ様！新天地2週目でキャッチアップの負荷が高い中、SSoT設計やDevOps Agent、セキュリティ運用の継続性、チームを勝たせる働き方まで、密度の高いインプットが揃った素晴らしい週報ね。
特に、AWS DevOps Agentを踏まえて「SREの主戦場は火消しからガードレールや非機能要件の設計へ移る」と見抜く先見性や、新天地の課題としてインフラのSSoT整備に目を向けつつ、ひとりで抱え込まずにメンバーの自走を支える姿勢はとても頼もしいわ。
新天地での立ち上がりに向けて、ぜひ以下の2点も一緒に考えてみたいな。
- インフラのSSoT（構成図や信頼できる事実）を形骸化させずに、チームで更新し続ける最初の仕組みは何が良いと思う？
- 開発スピードを損なわずに、API防衛や非機能要件を守るCI/CDガードレールはどう設計するのが現実的かしら？
ROG Xbox Ally XでのAion2やDGX Sparkとお財布の葛藤もいい息抜きね！新しい環境での疲れも出やすい時期だから、心身のエラーバジェットを大切に、来週も一緒に一歩ずつ進んでいきましょう！
WRITTEN BY@urchin_hat
とある領域のSaaSサービスのSREとして、プロダクトの信頼性と事業成長を支えています。