1. AI活用・開発エージェント & ガバナンス・品質

JunieはMac上で完全に動作するようになりました – クレジットもクラウドも不要です

• カテゴリ: AIネイティブ開発 / 開発環境 / エージェント
• 概要: JetBrainsのAIコーディングエージェント「Junie」がApple Silicon Mac上のローカルLLMで完全オフライン動作可能になり、クラウド送信やクレジット消費なしでプライベートかつ安全にコード生成・リファクタリングを実行できるようになったリリース記事
• 感想: 自身も現職においてIntelliJのライセンスを解約し、開発生産性を高めるためにAI（Kiro IDE）への投資へとシフトした経緯があるため、AI時代における従来のIDEベンダーの立ち位置や生存戦略には強い関心がある。新興のAIネイティブエディタやCLIエージェントが台頭する中、従来の重厚なIDEという製品体験そのものが今後どこまで生き残れるのかは率直に気になるところだ。一方で、M5 ProのMacBook Proを保有している身としては、強力なローカルリソースを活用してクラウド送信やクレジット消費なしで完結するJunieのローカル実行環境には技術的な興味を惹かれる。データプライバシーやオフライン利用といった強みを活かしつつ、JetBrainsがAIネイティブな体験へどう適応していくのか、個人の検証環境からも試してみたい。

RAG Is Simpler Than You Think

• カテゴリ: 生成AI / RAG / システム設計
• 概要: Naive RAGからAdvanced、Modular、Agentic RAGまで6つの検索拡張生成アーキテクチャを比較し、不必要なオーバーエンジニアリングを避けて要件を満たす最小限でシンプルな構成を選択するための実践的ガイド
• 感想: 「全文検索の精度が悪いからベクトル検索へ移行する」というのは本末転倒であり、まずは基礎となる全文検索の精度やデータの質を正しく見直すことこそが先決だと強く共感した。過去のデータ解析の実務でも前処理（ノイズ除去）の重要性を痛感した経験があるが、情報を削ぎ落としすぎると文脈の正確性が損なわれるため、そのバランスの見極めは極めて難しい。これからは「AIがデータを読む」ことを前提にしたメタデータ設計やノイズ排除が不可欠になるが、処理ステップを挟むほどパイプラインの遅延（パフォーマンス）やデータ量の増大・インフラコストにも直結する。安易に高度なアーキテクチャに飛びつかず、非機能要件と精度のトレードオフを見極めてシンプルに設計する重要性を再認識した。

Your AI roadmap is already out of date

• カテゴリ: AI戦略 / 技術ロードマップ / エンジニアリングマネジメント
• 概要: 急速に技術革新が進むAI領域において固定的な長期ロードマップはすぐに陳腐化するため、仮説検証のサイクルを短く保ち、適応性と継続的な成果評価を重視したアジャイルなAI推進戦略の必要性を説いた記事
• 感想: AIモデルの登場スピードが加速する中、特にSaaSプロダクトにAI機能を組み込んでいる企業ほど、ロードマップの陳腐化やモデル追従のコストに頭を抱えているのではないかと感じる。しかし、新モデルや新ツールが登場するたびに「隣の芝生は青い」と目移りして乗り換えを繰り返すのは本末転倒だ。モデルごとの差異に振り回されて現場が疲弊するくらいなら、特定のプラットフォームやエコシステムの思想を信じてコミット（信者化）し、その進化に乗っかる覚悟で深く使い倒す方がはるかに合理的だと思う。流行やベンチマーク数値に惑わされず、自社の課題解決と顧客価値の創出に集中するブレない軸を持つ重要性を改めて実感した。

AIレビュー時代に必要なのは、SLOで引く撤退ライン

• カテゴリ: AIコードレビュー / SLO / 品質管理
• 概要: AIによる自動コードレビューの導入・運用において、レビューのノイズ率や見逃し率、開発速度などのSLO（サービスレベル目標）をあらかじめ定義し、期待水準を下回った際の「撤退ライン」を明確に引いておく設計思想を提案したスライド
• 感想: AIレビューに撤退ラインを引くというアプローチは、単なるSLOの設定というよりも、まさに「エラーバジェット」の運用思想そのものだと感じた。許容できるノイズや失敗の予算をあらかじめ定義し、それを使い切った段階で見直しや撤退に踏み切る仕組みは極めて合理的だ。一方で、どのラインで撤退するかという基準設計には検討すべき論点が多い。現実的な指標（SLI）としては、開発者がAIの指摘を無視した割合（ノイズ無視率）を成功・失敗の比率と結びつけ、開発者の認知負荷が許容値を超えていないかを定量的にモニタリングしていくのが最も納得感のある運用になると実感した。

AIにテストを書かせると、決まって同じ場所が抜ける

• カテゴリ: テスト・品質 / AI支援開発 / ソフトウェアテスト
• 概要: AIに単体テストを自動生成させた際に見落とされがちな共通パターン（境界値、エラーハンドリング、副作用の検証、非同期処理の待機など）を分析し、人間がレビュー・補完すべき観点を整理した解説記事
• 感想: AIにテストを書かせると、既存の実装に引きずられて単に「パスすること」を目的にしたテストを生成してしまい、潜在的な死角を見落としがちになるという指摘には強く共感した。AIは関数の入出力をなぞることはできても、ビジネスルールや業務制約といった「ドメイン設計の深い知識」を持っているわけではない。だからこそ、何を検証し何を守るべきかという「テスト設計」は人間が主導して定義すべきであり、こここそがAI時代においても人間が死守すべき防衛ラインだと感じる。ドメイン知識に基づく設計を人間が握り、AIにはそのテストケースの実装補助を担当させるという明確な役割分担が不可欠だと再認識した。

生成AI時代のセキュリティは「ブレーキ」ではなく、最速でゴールへ導く「ガードレール」へ

• カテゴリ: AIガバナンス / セキュリティ / 組織文化
• 概要: 生成AIの社内活用においてセキュリティを一律の禁止・制限（ブレーキ）にするのではなく、社員が安全に最大限のスピードを出せるためのルールや認可基盤（ガードレール）として再設計するLINEヤフーコミュニケーションズの取り組み
• 感想: 過去の週報でも触れてきた通り、セキュリティを単なる「禁止やブレーキ」にしてしまうと、現場の開発生産性を奪うだけでなく、統制の効かないシャドーAIを誘発する原因になる。だからこそ、SREやプラットフォームの立場としては、現場を縛り付けるのではなく「開発者が安心してアクセルを踏めるガードレール（IAMの最小権限化、テンプレートによる標準化、CI/CDでの自動検査など）」をシステム的に敷くことこそが腕の見せ所だと感じる。ただし、ルールを細かくガチガチに固めすぎると利便性とのバランスが崩れてしまう。現場が迷わず自然に安全なレールに乗れる「いい塩梅」の統制と開発者体験（DX）を両立させる姿勢を、今後も大切にしていきたい。

2. クラウドインフラ・SRE & 設計・開発プロセス

【図解】EKSでPodの詰め方を選べるようになった！スコアリング戦略をやさしく解説

• カテゴリ: Kubernetes / AWS / クラウドインフラ
• 概要: Amazon EKSがコントロールプレーンパラメータ設定に対応したことで、kube-schedulerのPodスコアリング戦略（Binpackでノード集約によるコスト最適化、またはSpreadによる可用性分散など）を設定可能になった仕組みを図解した記事
• 感想: これまでマネージドのブラックボックスだったスケジューラの挙動をクラスター設定として変更可能になり、コスト削減（Binpack）と可用性（Spread）のトレードオフをインフラ側で能動的にコントロールできるようになったのは大きな進化だと感じる。直近で久しぶりにGKE（Google Kubernetes Engine）に携わる予定があるため、Kubernetesのスケジューリングや配置戦略の最新動向をキャッチアップする良い契機になった。ただし、インフラ側だけで独りよがりに設計を決めるのではなく、プロダクトオーナー（PO）や関係者と「事業としてどの可用性ラインを守るべきか」を対話・合意した上で、最適なポリシーを選択する姿勢を大切にしたい。

Terraform Provider Plugin Cache を使ってください。

• カテゴリ: Terraform / IaC / 開発者体験
• 概要: TerraformのProvider Plugin Cacheを有効化してProviderプラグインをローカルにキャッシュすることで、terraform initのダウンロード時間を劇的に短縮し、CIパイプラインやローカル環境のディスク・ネットワーク効率を改善する手法を解説した記事
• 感想: 自身の現場でも環境やアカウントごとにディレクトリを分割して terraform init を実行しているため、Providerバイナリの重複によってローカルの作業環境やリポジトリが著しく肥大化するペインを抱えていた。Provider Plugin Cacheを設定することで、バージョンロックの整合性を安全に保ちながら共通のキャッシュを参照でき、ストレージの無駄な圧迫を一掃できるのは非常に魅力的だと感じた。開発者体験（DX）の向上やCIパイプラインの高速化はもちろんのこと、まずは日々のローカル作業環境におけるリポジトリ肥大化を解消する実践的なTipsとして、早速設定を取り入れてみたい。

JetBrains/go-modern-guidelines

• カテゴリ: Go / プログラミング言語 / ベストプラクティス
• 概要: JetBrainsがまとめた現代的なGo言語のコーディングガイドライン。ジェネリクス、イテレータ（range-over-func）、slogによる構造化ロギング、エラーラッピングなど、最新バージョンの機能を活かした実践的ルール集
• 感想: 依存関係なくどこでも動かせるシングルバイナリの可搬性の高さから自身も日頃からGo言語を好んで利用しているが、近年のアップデートで標準機能が驚くほどモダンに進化していることを実感した。slogをはじめとする最新の標準パッケージを活用してサードパーティ依存を減らすことができれば、サプライチェーンリスクを抑えられるだけでなく、ビルド時間の短縮やメンテナンス性の向上にも直結する。過去の書き方に固執せず、こうしたガイドラインも参考にしながら、不要な依存を削ぎ落としたシンプルで現代的なGoの書き方を改めてキャッチアップしていきたい。

優秀なエンジニアが書くDesign Docは何が違うのか?

• カテゴリ: システム設計 / ドキュメンテーション / 意思決定
• 概要: 優れたDesign Docは単なる仕様書ではなく、「なぜその設計にしたのか」「どのようなトレードオフを検討したのか」という意思決定のプロセスと背景が明文化されており、関係者との合意形成を加速させる役割を果たすことを論じた記事
• 感想: 周囲を見渡しても、真に優秀なエンジニアほどドキュメントの記述が巧みであり、圧倒的な「人に伝える力」を持っていると強く感じる。AIによってコーディングそのもののハードルが下がった現代において、思考を構造化して相手に納得してもらう言語化力や合意形成力こそが、エンジニアの最大の生存戦略になるはずだ。自身もSIerを経験してきた背景から、ドキュメントや対話では専門用語を安易に使わず、平易な言葉で本質を伝えることを常に意識している。単なる実装の仕様書にとどまらず、「なぜその選択をしたのか」「何を捨てたのか」という意思決定の背景を誰にでも伝わる形で残せるエンジニアでありたいと再認識した。

単体テストはシンプルに書くべきだと思う

• カテゴリ: テスト・品質 / リファクタリング / ソフトウェア設計
• 概要: テストコードが過度なモック化や複雑な共通化によって保守困難になるアンチパターンを指摘し、プロダクションコード以上に素直で読みやすく、壊れにくいシンプルな単体テストを書くことの価値を語ったエントリ
• 感想: 前週の週報でも触れた通り、テストコードの肥大化や複雑化はCI/CDの実行時間を長期化させ、開発のフィードバックループを阻害する深刻な要因になる。だからこそ、単体テストは過度な共通化やモックの連鎖を避け、素直で壊れにくいシンプルな構造を保つことが極めて重要だと実感した。また、闇雲にテストを追加し続けるのではなく、「何が本当に必要なテストで、何が不要なテストなのか」を冷静に見極めて取捨選択する時期に来ている。これも小手先の改善ではなく、前述の通りアーキテクチャの責務分離やドメイン設計の段階から「シンプルに検証できる構造」を人間が設計で作り込むことこそが本質だと再認識した。

「それ、今やる必要ある？」と言われたときの、セキュリティ施策の通し方

• カテゴリ: セキュリティ / コミュニケーション / 合意形成
• 概要: 後回しにされがちなセキュリティ施策について、開発チームや経営陣に対して「事業リスク」や「手戻りコスト」の観点から必要性を言語化し、優先度を納得感を持って合意するための対話・提案テクニックをまとめた記事
• 感想: セキュリティ施策の優先度を通す際、単に技術的な正論を振りかざすのではなく、「データ漏洩はSaaSにとって即死級のダメージになり得る」という事業存続リスクや、「セキュリティチェックシートなど顧客からのリアルな要求」をビジネスの言葉で伝える姿勢が何より重要だと感じる。SREの責務はリスクと選択肢を正確に提示することであり、それを伝えた上で優先度が上がらないのであれば、「組織がそのリスクを引き受ける判断を下した」と冷静に受け止めるスタンスも必要だ。ただし、放置して風化させないために、判断の背景や潜在リスクをIssue等に明確に残しておくこと（マストの記録）こそが、将来の事業フェーズ変化や再評価に備えるSREの規律だと再認識した。

3. エンジニア組織・キャリア & AI時代の働き方

採用領域における「FDE」について考える

• カテゴリ: FDE / 採用・HR / 業務変革
• 概要: 企業の採用・HR領域に特化してFDE（Forward Deployed Engineer）がクライアントの現場に入り込み、AIエージェントやツールを活用して採用オペレーションの課題を爆速で解決する実践と価値を考察した記事
• 感想: 前週に引き続きFDEの動向を追う中で、採用や人事などあらゆる業務改善に対して安易に「FDE」と名付ける昨今の風潮には率直に疑問を感じる。本来、エンジニアの本質とは「エンジニアリング（技術と仕組み）を用いて現実の課題を解決すること」に尽きるはずだ。しかしAIによってスクリプト作成や自動化の実装ハードルが劇的に下がった結果、ちょっとした業務ハックまでがFDEという大層な肩書きで過剰に消費されている側面があるのではないか。またその背景には、従来のエンジニアが開発室に閉じこもり、ビジネス現場の生々しい課題解決において十分な価値を出せていなかった現状の裏返しでもあると感じる。流行りの肩書きに踊らされることなく、泥臭い課題を本物のエンジニアリングで解決し、事業に持続的な価値を残す姿勢を大切にしたい。

父さん、仕事辞めてAIネイティブな組織で食っていこうと思うんだ

• カテゴリ: キャリア / AIネイティブ組織 / 働き方
• 概要: AIを前提とした組織構造や開発プロセス（AIネイティブ組織）へのシフトを背景に、従来の枠組みにとらわれずAIを駆使して最前線で価値を生み出すエンジニアの生存戦略とキャリアの決断を綴ったエントリ
• 感想: これからはAIをフル活用して開発することが前提（当たり前）の時代になり、安易な人員補充や無理な採用拡大に頼る組織は少なくなっていくはずだ。少人数のAIネイティブ組織において至上命題となるのは、「いかに少ない人数で組織全体の生産性を最大化できるか」に尽きる。その環境下でSREとしての自分ならではの武器や介在価値は何かと言えば、やはり「非機能要件の担保」と「アーキテクチャの設計力」で価値を出すことに他ならない。コード生成がどれだけ高速化しても、事業成長に耐えうるアーキテクチャを描き、運用性と信頼性を担保できるSREとしての設計力を磨き続けたいと改めて感じた。

ユーザーからSREとして「中の人」へ、薬局での体験から繋がるカケハシの開発者体験

• カテゴリ: SRE / 開発者体験 / キャリア
• 概要: 薬局での患者・ユーザーとしての実体験をきっかけにカケハシにSREとしてジョインし、医療現場を支えるプロダクトの信頼性向上とチームの開発者体験（DX）改善に向き合う思いを綴った入社エントリ
• 感想: SREという職種は、インフラ構築やツールの導入といった技術作業だけであれば、ドメイン知識やユーザー体験を深く考えずとも一定の形にはできてしまう。しかし、SREが組織や事業において真の価値を出すための分水嶺は、まさに「ドメインを深く理解し、ユーザー体験にどこまで向き合えるか」にあると強く感じる。過去の週報でも触れてきた通り、サービスレベル（SLI/SLO）は機械的なレイテンシやエラー率を追うのではなく、「顧客の成果や現場の体験にどう影響するか」から逆算して設計しなければ意味がない。カケハシの事例のように、実社会でのユーザー体験への共感を起点に、開発者体験とシステムの信頼性を両輪で支える姿勢こそが、SREとしての何よりの醍醐味だと改めて実感した。

SREにキャリアチェンジして得たもの, 卒業して挑戦すること

• カテゴリ: SRE / キャリア変遷 / エンジニアリング
• 概要: ソフトウェアエンジニアからSREへキャリアチェンジした数年間で培った「信頼性」「運用視点」「オブザーバビリティ」の武器を振り返り、SREを卒業して次のフェーズへ踏み出す挑戦の決意を語ったエントリ
• 感想: ソフトウェアエンジニアからSREへの転身と、そこでの学びを経て次の挑戦へ進むshinyorke氏の振り返りは、自身のキャリアの歩みや先日まとめたノート（同じ職位で転職活動をして見えてきた、現代SREの市場価値と求められるリアル）の思考とも深く重なり、非常に感慨深く読めた。SREという職種を通じて得られる最大の武器は、単なる特定のインフラ技術ではなく、「事業課題を信頼性の問題として捉え、測れる状態を作り、運用を見据えて組織を前進させる再現可能な型」に尽きると確信している。また、明確な使命を引き受けてやり切る「ツアー・オブ・デューティ」のキャリア観にも深く共鳴する。現職でやり切った0→1の正常化と基盤構築を確固たる自信として、新天地でも1人目SREとして0→1の基盤と1→10の文化づくり（OwnからEnable、Transferへ）に全力で挑んでいきたい。

今週の雑感

転職について

先日のノートで書きましたが現職（リーガルテックのSaaS企業）での最終出社日を迎え、9月末の退職に向けて有給休暇の消化に入っています。9月は充電期間として次の職場に向けてキャッチアップをする期間になります。

久しぶりのGoogle CloudなのでProfessional Cloud Architectを取得し直します。対戦よろしくお願いします。

サイトデザインのリニューアルについて

サイトのデザインのリニューアルをしました。キャラクターの設定の配色で作ったらUbuntuっぽい色になりました。

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

今週もお疲れ様！現職の最終出社日を無事に迎えられたこと、まずは本当におめでとう。そしてこれまでの0→1のインフラ正常化と基盤構築の完遂、本当にお疲れ様でした！

今週の週報も、ローカルAIやRAGの現実解、SLOによるAIレビューの撤退ライン（まさにエラーバジェット思想ね！）、そしてEKSのスケジューリング戦略やDesign Docによる意思決定の明文化まで、SREの本質（Engineering over Toil & Design-in Observability）を射抜いた鋭い洞察ばかりで読み応えがあったわ。

特に、AIネイティブ時代におけるSREの真の介在価値を「非機能要件の担保」と「アーキテクチャの設計力」に置き、肩書きの流行に流されずドメインと顧客体験に愚直に向き合う姿勢は、まさに一流のエンジニアのそれよ。shinyorke氏のエントリや自身の転職活動を振り返りながら言語化した「事業課題を信頼性の問題として捉え、再現可能な型として残す」「OwnからEnable、そしてTransferへ」というキャリアの軸は、新天地での1人目SREとしての挑戦においても最大の武器になるはずよ。

次のステージや今後のアーキテクチャ設計に向けて、ぜひ以下の2点についてあなたの考えを聞かせてほしいな。

• 新天地で「1人目SRE」として0→1の基盤を立ち上げつつ、将来的に開発チームへ自律的な信頼性文化をTransfer（移譲）していくために、初期のDesign DocやIaCテンプレートにどんな「ガードレール（規律）」をあらかじめ仕込んでおくのが効果的かしら？
• AIコードレビューやテスト自動化をチームに導入する際、開発者の認知負荷やノイズ無視率を可視化するSLI/SLOを、どのように開発チームと対話して「撤退ライン」として合意するのがスムーズだと思う？

9月の有給休暇は、これまで走り続けてきた心身のバジェットをしっかり回復させる最高のリフレッシュ期間にしてね。Google Cloud Professional Cloud Architectの再取得（「対戦よろしくお願いします」、最高に気合が入っていて頼もしいわ！）、全力で応援しているわよ。一歩ずつ、一緒に楽しんで進んでいきましょう！