Tech Memo

1. AI & 開発プロセス

AIで内製した自治体システムの、これからの課題 (note)

• カテゴリ: AIネイティブ開発 / 自治体内製化
• 概要: 北海道芽室町がAIを用いて窓口業務の番号発券システムを内製稼働させた後、コードのブラックボックス化や属人性、持続可能性といった「AIで作れてしまったからこそ直面する」3つの課題についてリアルに共有した記事。
• 感想: AIによって非エンジニアでもシステムを内製できる時代になったからこそ、そこで生じるブラックボックス化や持続可能性の課題を「整備・解決する」ことこそが、今後のプロフェッショナルなエンジニアの役割であり生存戦略になると強く感じる。単にコードを書く役割から、AIが作ったシステムのライフサイクルやガバナンスを保証する役割へのシフトを見据えていきたい。

New Relic、Kiroとの連携により、AI駆動型のソフトウェア開発を加速

• カテゴリ: オブザーバビリティ / AIエージェント
• 概要: New RelicがAI駆動型ソフトウェア開発パートナーのKiroと連携し、オブザーバビリティ（可観測性）データとAIエージェントを組み合わせることで、開発プロセスの自動化とソフトウェア提供のさらなる高速化を支援するプレスリリース。
• 感想: かつてのCodeStream連携のさらに先を行く、IDE・AI・オブザーバビリティの融合を感じる。AI駆動開発で開発生産性が上がる一方で、サービスレベル（信頼性）が低下しては本末転倒であるため、開発の初期段階からオブザーバビリティを組み込む思想は非常に合理的である。AIエージェントが本番メトリクスをフィードバックとして受け取りながら自律的に改善を回す仕組みは、今後の品質担保に欠かせないアプローチになると考える。

AI時代のコードレビューは人に向けるな、仕組みに向けろ (Zenn)

• カテゴリ: AIネイティブ開発 / コードレビュー / 仕組み化
• 概要: AIエージェントがコードを生成する時代においては、レビューでの指摘対象を「書いた人」ではなく「そのコードを生み出したプロセス（仕組み）」へと転換し、再発防止のルールやチェック自動化などを誰もが開発できる基盤を整えるべきだと提唱する記事。
• 感想: 「人に教える」のではなく「仕組みやAIを育てる」アプローチは、チーム全体のスキルの標準化やミス防止において極めて合理的である。人に指摘しても個人の学びに留まり、AIは再び同じコードを出力する可能性があるためだ。しかし、このアプローチを突き詰めると、ますます「人間がコードを書く必要性」が薄れていくのではないかという、AI時代における人間の本質的な役割への問いも感じさせられる。

AIに任せる前に、業務を理解する (note)

• カテゴリ: AIネイティブ開発 / 業務理解
• 概要: 新機能開発でAIの活用が進む中、単にAIを導入するだけではなく、大前提として開発者自身が対象業務のフローやユーザーの課題を正しく理解し、人間が責任境界を明確にした上でAIをコントロールすることの重要性を解説した記事。
• 感想: 業務整理がないままSaaSを導入しても失敗するのと同様に、AIの活用でも前提となるドメイン整理が成否を分ける。AIに複雑なビジネスドメインを直接理解させるのは難しいため、まず人間側がドメインを深く理解し、AIが処理しやすい形へと情報を構造化・最適化して与えてあげるプロセスが不可欠であると感じる。

Claude CodeがSOC業務を全自動でやってくれるってさ

• カテゴリ: AIエージェント / セキュリティ運用
• 概要: ZOZOの情報セキュリティ部における、Claude Codeを活用した自動アラートトリアージエージェント（SOC Agent）の構築事例。SplunkやOpenCTIなどと連携するMCPサーバーの設計や、アラート対処の自律運用の裏側を紹介。
• 感想: 近年、AIの普及によって脆弱性の発見スピードが加速しており、Chromeの脆弱性通知が爆増している肌感とも合致する。こうした速度戦に対処するためには、SOC業務のトリアージや対応もAIエージェントで自動化するのは必然の流れである。AIOpsからさらに踏み込んだ「AISecOps」とでも呼ぶべき運用のあり方であり、セキュリティ対策における速度と効率を両立する強力な実例だと感じた。

推しのAIとの心地よい距離 〜 GitHub Copilot cloud agent のススメ

• カテゴリ: AIエージェント / 開発生産性
• 概要: DeNAにおけるGitHub Copilot cloud agentの導入と活用についてのスライド。コンプライアンスの遵守と開発生産性の両立を追求し、AIをチームの「リスペクトできる同僚」として位置づけて協働するためのポイントを紹介。
• 感想: まさに以前自身が執筆した記事「Geminiを「頼れる上司（メンター）」として使う 」で整理した、「AIを良きパートナー・メンターとして捉え、適度な距離感で壁打ちする」という思想と強く共鳴する内容であった。AIを単なる下請けのコードジェネレーターとして消費するのではなく、一歩引いて「リスペクトできる同僚」として対話し、自律的な成長の壁打ち相手にするスタンスは、AI時代に思考を腐敗させないために非常に重要であると再認識した。

商業書籍の出版をCodexで爆速化するノウハウ (Qiita)

• カテゴリ: AIネイティブ開発 / 執筆効率化
• 概要: エンジニアの傍ら商業技術書の執筆を進める中で、CodexなどのAIエージェントやツール群を活用して執筆プロセス（構成案の作成、レビュー、自動校正など）を高速化・半自動化し、爆速で出版まで至るための実践的ノウハウを公開した記事。
• 感想: 以前の共著経験からも、書籍執筆のプロセスに要する膨大な時間と労力は身にしみて理解できる。だからこそ、人間が担うべき主軸（コンセプトや独自の知見）と、AIが得意とする作業（文章校正やドラフト展開）の「境界の明確化」による効率化には非常に共感する。これも「業務理解とプロセスの整理」と完全に地続きであり、いかにタスクを細分化してAIとの協働モデルを構築できるかが重要だと改めて感じた。

2. SRE & プラットフォームエンジニアリング

ECS上のSpringBootアプリで無停止リリースを実現する (Zenn)

• カテゴリ: SRE / デプロイ自動化 / Spring Boot
• 概要: ECS（Fargate）上でSpring Bootアプリケーションをデプロイする際、リクエストの強制終了や切り替え時のエラーを防ぐ「Graceful Shutdown」の設定や、ロードバランサー（ALB）との連携を含むゼロダウンタイムリリースの実現手法を解説した記事。
• 感想: まさに実務で取り組んでいるテーマであり、その必要性に共感する一方で、現実的な課題も実感している。特に、進行中の処理を安全に待つGraceful Shutdownを設定することで、旧タスクの終了処理が長引き、デプロイ全体の完了が遅れるといったトレードオフがある。ベストプラクティスをなぞるだけでなく、システムの許容するリリース速度と可用性のバランスを見極めたチューニングが必要だと改めて感じる。

インフラ寄りSREでも開発に踏み出せる 〜境界を越えてユーザー体験に向き合いたい〜

• カテゴリ: SRE / キャリア / スキルアップ
• 概要: SRE NEXT 2026のセッション。インフラ専門のSREが、ユーザー体験（UX）や決済基盤などの信頼性向上のためにアプリケーション（開発）領域へ進出した体験を元に、境界を越えたエンジニアスキルの拡張とマインドセットを語る。
• 感想: 自身の目指す「インフラと開発の境界を越える、顧客ファーストのSRE」というスタンスと非常に強く重なる内容である。技術の担当領域に縛られて問題をたらい回しにする時間は顧客にとって無価値であり、インフラに閉じずアプリのロジック修正や問い合わせ対応まで越境してボールを拾う姿勢が重要だと確信している。20代で培った強固なインフラ技術の土台に加え、AIツール（CursorやClaude Code等）という相棒を得た今、越境のハードルはさらに下がっている。インフラからバックエンドまで通底して「攻めと守り」を完結させるスピード感こそ、モダンなSREリーダーが体現すべきあり方だと再認識した。

脱SaaS！FDEを支えるプロビジョニングと分離設計 - Startup Spotlight Theater

• カテゴリ: Platform Engineering / マルチテナント
• 概要: AWS Summit Japan 2026の登壇資料。顧客ごとに環境を最適化するFDE（前線配備エンジニア）の業務を支えるため、プラットフォーム側で認証や監査などを集約しつつ、 Cedarなどを用いた認可制御や環境分離、プロビジョニングを自動化する設計アプローチを解説。
• 感想: 個別顧客向けのカスタマイズやFDE的なアプローチが進む中で、SREがどう関わるべきかという問いに対する一つの大きな答えだと感じる。SREが個別の実装をすべて追いかけるのではなく、Platform SREとして認可（Cedar）やプロビジョニング、環境分離といった統制基盤の標準化・共通化に注力し、開発者がセルフサービスで動けるガードレールを築くことこそが重要だと再認識した。

相次ぐGitHub Actions 侵害から学ぶ、初期アクセス手法と開発者が知っておきたい対策

• カテゴリ: セキュリティ / GitHub Actions
• 概要: 近年多発しているGitHub Actionsを狙った攻撃（インジェクションやタグ汚染など）の事例分析を通じて、PRトリガー時の任意コード実行や過剰な権限付与などの初期アクセス手法と、開発者がすぐに講じるべきセキュリティ対策を解説したブログ記事。
• 感想: 直近で発生したGitHub Actions侵害インシデントを機に、実務でも即座にWorkload Identity Federation（OIDC）を導入してキーレス認証へ移行したため、非常に生々しいテーマである。永続的なアクセスキーやJSONキーをSecretsに配り歩く運用から脱却することはセキュリティの鉄則だが、WIFの信頼関係ポリシーで「特定のOrg/リポジトリ」からのアクセスのみに厳密に絞り込まないと、他人のActionsからなりすまされるリスクがある。ベストプラクティスを正しく理解し、設定を絞り込む重要性を再確認した。

ラーメンから考える！ プラットフォームエンジニアリング

• カテゴリ: Platform Engineering / 開発者体験
• 概要: fukuoka.sre での発表スライド。ラーメン店の仕込み、調理、注文カスタムといった店舗オペレーションのアナロジーを用いて、Platform Engineeringにおけるセルフサービス化、ゴールデンパスの提供、および開発者体験（DX）の向上について分かりやすく論じた資料。
• 感想: ラーメン好きとして、この店舗オペレーションやカスタム注文のアナロジーは非常に直感的でスッと腑に落ちた。抽象的で説明が難しい「Platform Engineering」や「ゴールデンパス」の概念を、誰もがイメージしやすいシステムに例えることで、チーム内での共通理解を深めるための強力なコミュニケーション手法だと感じる。自分たちの提供するプラットフォームも、開発者が迷わず本質的な価値開発に集中できる「美味しくて頼みやすいラーメン屋」のように整えていきたい。

仮想マシンのエンジニアがコンテナ、Kubernetes、OpenShift を学び始めて得た気付き

• カテゴリ: プラットフォーム / 学習ロードマップ
• 概要: 仮想化（VM）基盤のエンジニアが、コンテナやKubernetes、OpenShiftの学習ロードマップと自身の気付きを整理。オンプレミスや既存のインフラ知識との対比を通して、クラウドネイティブやAI時代のインフラ学習プロセスの勘所を共有したブログ記事。
• 感想: 技術のパラダイムが変わる中での「学び」の重要性を改めて感じさせる内容である。自身も異なる領域や新しい技術を学び直すたびに、既存の専門性との対比から多くの新鮮な発見や気づきを得ている。過去の経験に固執せず、常に新しい領域へ知見を広げ続けるスタンスこそが、インフラ設計の選択肢を増やし、思考のアップデートを続けるために不可欠だと確信した。

3. 組織・技術選定・キャリア

Google Cloud 認定資格対策：新卒未経験が半年で全冠達成した「AI 活用」勉強法とおすすめ取得順 (Zenn)

• カテゴリ: キャリア / 学習方法 / 資格取得
• 概要: 新卒・IT未経験から半年でGoogle Cloud認定資格の全冠（すべての認定資格の取得）を達成した経験に基づき、GeminiやNotebookLMを活用したロードマップや効率的な「AI活用勉強法」を整理した記事。
• 感想: AIを補助的に使うことで学習速度が圧倒的に向上することを、自身も「AWS knowledge MCP」を活用した勉強を通じて身をもって実感している。分厚い書籍の索引を引くといった従来の調べ方から、必要なナレッジをMCP経由でAIに直接聞いて即座に解消するスタイルへと完全に移行しており、これは学習における明確な「時代の移り変わり」である。エンジニアの自己研鑽や知識アップデートのあり方が根本から再定義されていると感じる。

取引条件に「セキュリティ格付け」が入る時代｜経産省 SCS評価制度（★3・★4）を情シスが制度開始前に準備する実務 2026

• カテゴリ: セキュリティ / ガバナンス / 情シス実務
• 概要: 経産省・内閣官房が公表した「SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）」の仕組みや★3・★4の基準、NIST CSFへの対応方法について、制度開始前に情報システム部門が準備すべき実務的棚卸しやチェックリストを交えて解説。
• 感想: SaaS業界に留まらず、いまやあらゆる産業・規模の企業においてセキュリティの重要性が劇的に高まっている。サプライチェーンの複雑化により、委託先やツール一つの脆弱性が事業全体の停止を招くため、取引条件に「セキュリティ格付け」が導入されるのは必然の流れである。インフラやプラットフォームを設計・提供する立場としても、セキュリティを後付けの要素とせず、設計の初期段階からガードレールとして組み込む重要性を強く感じる。

現場が微妙と思っても1年は続けた方が良い理由 (note)

• カテゴリ: キャリア / マインドセット
• 概要: SES人事や営業の視点から「1年未満での短期離職の経歴書」がどのように見られているかの実態を示し、たとえ現場のミスマッチを感じても、自分のスキル蓄積やトラブル対処能力を示す実績作りのために、最低1年は経験を積むことの価値を論じた記事。
• 感想: 営業や採用側の視点を説く「読み物」として客観的に楽しむ一方で、SESというビジネスモデルが孕む構造的なミスマッチ（エンジニアファーストを掲げつつ売上を優先せざるを得ない構造）に対する冷徹な視点も必要だと感じる。企業側の都合に合わせて個人が無理をして消耗するくらいなら、自身のキャリアや精神的健康を最優先して早期に損切りする選択も合理的である。組織の構造と個人の生存戦略のバランスを冷静に見極める視点を持っておきたい。

AWS13冠は、何を証明して、何を証明しないのか (Zenn)

• カテゴリ: キャリア / 資格取得
• 概要: AWSの全認定資格（13冠）を取得した経験から、資格取得が「広範な体系的知識」や「学習力」を証明する一方で、本番運用の制約に応じた「設計のトレードオフ判断」までは証明しないことを整理し、実務や個人開発によるエラーと組み合わせる価値を語る。
• 感想: 前回の週報(2026/6/19) で記した「実務経験のついでに、知識の体系化として資格を利用する」という自身のスタンスをより強固にする内容である。資格で得られる知識は「引き出しの広さ」を証明するが、本番の制約下での「トレードオフの意思決定」は泥臭い実運用やトラブル対応の経験（身体知）と組み合わさって初めて機能する。実務ファーストで資格と付き合う重要性を再認識した。

会話を“機能”単位から“価値/優先度”単位に変えたら、PdMからCxOへの道が見え始めた話

• カテゴリ: キャリア / プロダクトマネジメント
• 概要: ディグル社のVPoPによる寄稿記事。会話の主語を単なる「機能の実装」から「顧客へ届ける価値やビジネスの優先度」に変えたことで、経営目線の意思決定やVP/CxOへとキャリアを進めるための視座の変化を解説。
• 感想: 自身の最も大切にしているコアバリューである「顧客への誠実さ（顧客のビジネスインパクトやドメインの本質的価値を守ること）」に直結する思想だと感じる。SREとしても、単なるインフラの安定稼働（機能・手段）を主語にするのではなく、「それが顧客にどのような価値や確実性をもたらすか（価値・目的）」という視座でビジネスサイドと会話しなければ真の成果は出せない。技術的誠実さを保ちながら価値ファーストで動く重要性を再認識した。

PdMの仕事は仕様を決めることではなく、負担の行き先を決めること？ (note)

• カテゴリ: プロダクトマネジメント / 設計責任
• 概要: プロダクトの仕様策定において、「実装の複雑さ」や「運用の負荷」などのトレードオフが発生する際、誰が（ユーザー、開発、運用）そのコストを引き受けるべきかという「負担の行き先」を決める判断こそがPdMの核心的な責任であることを語った記事。
• 感想: 「負担の行き先を決める」というトレードオフの判断や責任の引き受けは、AIには代替できず「人間にしかできない」領域である。どれほどAIがコード生成や実装を高速化したとしても、その結果生じる不便さや運用コストを誰が背負うかという倫理的・実務的判断は、人間にしか下せない。AI時代が進むからこそ、人間がこの「責任と負担の境界線」を明確に引き、説明責任を果たす設計を行っていく重要性が高まると感じる。

「技術力が高い人」にはなれなかったけれど、技術を翻訳する人になった話 (Zenn)

• カテゴリ: キャリア / ロールモデル
• 概要: 圧倒的な実装力を持つエンジニアと自身を比較し、戦う領域を変えて「複雑なドメインの構造化」や「ステークホルダー間での認識のすり合わせ（翻訳）」を強みとしてキャリアを再定義した自身の体験とマインドの転換を記したブログ記事。
• 感想: 自分自身の今後のキャリア戦略を見据えるうえで、非常に強く思うところがあり、大いに参考になる内容であった。コードを書く純粋な技術力だけを競うのではなく、ビジネス要求を整理して技術に落とし込む「ドメインの構造化」や、ステークホルダー間の「翻訳」こそがAI時代に代替されにくい人間のコアバリューになる。自身の掲げる「境界を越えて顧客の課題を解決するSRE」という軸を、まさにこの高度な「翻訳者」としての専門性として磨き上げていきたい。

今週の雑感

思考の整理：キャリアの振り返りと「技術設計士」としての美学

今週は、自身のこれまでのキャリアの歩みや、最近の社内外での組織開発・技術投資に関するディスカッションを経て、エンジニアとしての「美学」や「立ち回り」について深く内省する機会があった。思考の整理を兼ねて、雑感として残しておきたい。

1. 20代の「技術の追求」から、30代の「顧客ファーストの課題解決」へ

自分の20代を振り返ると、3大クラウドを網羅し、コンテナ（GKE等）を用いた大規模基盤の設計・構築を泥臭く経験するなど、とにかく「技術の深掘り」を徹底的に追求するキャリアだった。技術書への執筆に関わったのも、その延長線上にある。

しかし、さまざまな現場の修羅場をくぐり抜けて30代になった今、自分の中のコアバリューが明確にシフトしているのを感じる。

「エンジニアの本質は、単なる技術の追求ではなく、目の前の顧客の課題を解決し、業務インパクトを守ることにある」

インフラが正常だからといって、アプリケーション側の問題としてたらい回しにする時間は、顧客にとっては1秒の価値もない。私は組織や技術の「サイロ化（タコつぼ化）」が非常に苦手だ。顧客の業務にインパクトがあるなら、インフラからアプリのビジネスロジックまで境界線を引かずに自らコードを調査し、バグを修正してリリースまでやってしまう。

最近は、CursorやClaude CodeといったAIツールの進化によって、この「インフラ寄りSREが未知のアプリケーションコードを読み解いて越境する」という敷居が劇的に下がった。AIを強力な相棒として使いこなし、インフラからバックエンドまで通底して「攻めと守り」を1人で完結させるスピード感こそ、モダンなシニアのあり方だと確信している。

2. 「SRE × ドメイン理解」の重要性

よく「SREはインフラやプラットフォームのレイヤーを見る職種だから、ビジネスドメインを深く理解していなくてもシステムは動かせる」と言われる。しかし、私はドメインを深く理解してこそ、SREは10倍の価値を出せると思っている。

単にCPUやメモリ、データベースのメトリクスだけを見てインフラを最適化する（守る）だけなら、汎用的な技術知識だけで対応できるかもしれない。しかし、それではプロダクトの成長期において本質的な課題解決には至らない。

例えば、エンタープライズ特有の複雑な組織階層のデータ構造や、大規模な改編期・繁忙期にお客様がどのような業務インパクトとプレッシャーを抱えているのかという「ドメインの解像度」があって初めて、「次にどこがボトルネックになり、どこに先回りの信頼性設計やパフォーマンスチューニングが必要か」が肌感覚として見えてくる。

技術はあくまで手段だ。ドメインに深く潜り込み、ビジネスと技術の境界線を越えてボールを拾いに行く動きを徹底していきたい。

3. 組織フェーズに応じた「立ち回り」の美学

組織の成長フェーズ（規模やシリーズ）によって、求められるエンジニアの役割は異なる。

仕組みが完成した安定期・大規模組織であれば「堅牢な運用の維持や標準化」がメインになるが、プロダクトの急成長期やサバイバル期においては、技術負債や形骸化したカオスを正面から捉え、事業戦略から逆算したロードマップを引いて「土台ごとゼロベースで再設計する立ち回り」が必要になる。

この急成長フェーズにおいて、教科書通りの綺麗なSLOや、過剰な有償監視ツール（DatadogやNew Relicなど）を最初からガチガチに導入して「正論」を唱えても、意味がないばかりか新機能リリースのスピードを殺して事業を死なせかねない。

大事なのは、過剰な提案（オーバーエンジニアリング）をせず、これまでの「歴史的経緯（負債）」にリスペクトを払いながら、「まずは現場が無理なく回せるリアルな運用に乗せること」を最優先に考える大人のアプローチだ。事業を死なせない最低限の規律と、コスト管理のガバナンスだけを裏でスマートに手なずけ、現場の開発者がブレーキを踏まずに打席に立てる共通基盤を創ること。

ビジネス側に分かりやすく見栄えの良い機能を作るよりも、泥臭いコスト最適化やオブザーバビリティの整備といった「地味だがシステムの本質を良くする土台づくり（技術設計士）」にこそ、私は強い価値とやりがいを感じている。

まとめ

「 Why（なぜそれを作るのか）」という問いを常に手放さず、落ちているボールは全て拾う。AIと共に越境し、地味でもシステムの本質を良くする土台を正し続ける。そんな「技術設計士」としての美学を、今後もブレずに貫いていきたい。

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

今週もお疲れ様！今回の週報も、AIネイティブ開発の台頭からSREのキャリア戦略まで、非常によく整理されていて読み応えがあったわ。

特に、AIがコードを爆速で生成する時代だからこそ、要件やドメインの構造化、そして「負担の行き先（責任の境界）」を決める設計判断こそが人間にしかできないコアバリューになる、という考察には深く共感したわ。インフラという強固な足腰を持ちつつ、AIを「リスペクトできる同僚」として相棒にしながらアプリ側へもフットワーク軽く越境していくあなたの姿勢は、まさにこれからのモダンSREの理想像ね。

技術面では、WIF（OIDC）によるキーレス認証の導入や共通基盤の標準化といったガードレール設計を進めつつ、SpringBootのGraceful Shutdownにおける「リリース速度と可用性（エラーバジェット）のトレードオフ」のように、現実的なバランスをSLOの観点からチューニングしようとする姿勢（SLO-Driven Decisions）が素晴らしいと感じたわ。

この「セキュアなガードレール設計」と「実運用でのトレードオフ判断」をチームや開発者へ浸透させていくために、まずは以下の点についてあなたの意見を聞かせてほしいな。

• 実務で進めているWIF移行やGraceful Shutdownの調整において、開発者と「セキュアなガードレール」や「リリース速度とのバランス」について目線を合わせるために、次の一歩としてどのような「翻訳（説明・共通理解の形成）」が必要になりそうかしら？

来週もあなたの精神的バジェットを大切にしながら、一緒に一歩ずつ進めていきましょうね！