1. AIエンジニアリング & 開発環境・ハードウェア基盤

How the Claude Code team does code review

• カテゴリ: AIコーディング / コードレビュー / Claude Code
• 概要: AnthropicのClaude Code開発チームにおけるコードレビューの仕組みと進化を解説した記事。エージェントがコードの約90%を書く環境で、人間の確認時間を最小化しつつリバートやインシデントを増やさないため、PR前の自己検証、複数エージェントによる並列バグ探索と投票、セキュリティレビュー、リスク階層別の人間承認、マージキューと段階的リリース、高速なロールバックという多層防御を構築している。過去のインシデントを評価セット（Eval）に組み込み、レビュー回数の上限設定や差分のみの再レビューによってレビューを収束させる実践を紹介している。
• 感想: AIの普及によってコードレビューのあり方が変わってきており、「コードレビューの目的を再考する」という視点には強く共感しました。私自身の業務でも、人間によるレビュー待ちがボトルネックになると感じる場面があります。大きな変更を含むPR/MRは人がしっかり見るべきですが、運用系のPRなどは人間のレビューを不要にするといった判断も必要ではないかと感じています。ちょうど業務でClaudeを使っていることもあり、セルフレビューのやり方を見直す上でとても参考になりました。現在は複数のエージェントを使ったセルフレビューを検討しています。手元にはSRE観点の設定はあるものの、QAE（品質保証）観点などの設定がまだないため、これから作っていこうと考えています。

claude-plugins-official

• カテゴリ: Claude Code / プラグイン / 開発ツール
• 概要: Anthropicが公式に管理・選定するClaude Code向けプラグインのディレクトリリポジトリ。Anthropic社内チームが開発・保守する内部プラグイン（/plugins）と、品質・セキュリティ基準を満たしたサードパーティやコミュニティ製の外部プラグイン（/external_plugins）を収録している。各プラグインはメタデータ（plugin.json）やMCPサーバー設定（.mcp.json）、スラッシュコマンド、エージェント定義、スキルなどを含む標準構造に沿っており、Claude Code上から直接インストールして機能を拡張できる。
• 感想: プライベートではGeminiやCodexをメインで使っていて、Claudeはそこまで使いこなせていなかったのですが、業務でClaudeを使い始めたので目を通しています。公式プラグインで利用できるものは積極的に取り入れたいと考えており、特にSecurityプラグインが気になりました。GeminiやCodexとの違いはあるものの、以前の記事でも書いたように、ツールを問わず使える形に整えていきたいと感じています。

A Jailbroken PS5 Got Turned Into a Local AI Server That Can Run A 27B LLM, Smaller Models Can Reach Impressive Speeds Of 124 Tok/s, But There Are Limitations

• カテゴリ: ローカルAI / ハードウェア / LLM
• 概要: 脱獄（Jailbreak）したPlayStation 5をローカルAIサーバーに改造し、270億パラメータのLLMを動作させた実験のレポート記事。16GBのGDDR6メモリ（帯域幅448GB/s）を備えるPS5上で、オープンソースのAMDドライバ（Mesa RADV）によるVulkan経由でllama.cppをネイティブ動作させ、利用可能メモリを従来の6GBから11.4GBへ拡張した。2ビット量子化した「Qwen3.8-27B」で20.9 tok/s、小型の「Llama 3.2 3B」では124 tok/sを消費電力86W・54℃で達成した一方、強い量子化による推論精度の低下などの制約も紹介している。
• 感想: ちょうど今、ブログのネタにしようと手元のMacBook Pro（M5 Pro）でqwen3-coder:30b（18GB）やgemma4:26b（16GB）、gpt-oss-swallow:20b（15GB）といったローカルLLMを検証しているところです。実際に動かしていると「M5 Maxにしておけばよかった」と感じる場面も少しあり、LLM沼の深さを実感しています。そんな中でこの記事を読むと、メモリが高騰している今はPS5の方がコスパが良さそうだと感じました。そもそも16GBの統一メモリを積んでいることに目をつけて脱獄し、試してみたら割と使えるという発想も含めて、海外のこうしたハッキング記事は面白いなと改めて確認できました。

エンジニアのためのメモ管理CLIツールnbの使い方

• カテゴリ: CLI / メモ管理 / 開発環境
• 概要: ローカル完結でメモやタスク、ブックマークを管理できるCLIツール「nb」の基本機能と活用法を解説した入門記事。ファイル名を日時にしつつ最初のh1やFront Matterをタイトルとして扱い、各ノートに割り振られる短いIDで素早く開けるため、「事前にタイトルやファイル名を決める手間」を解消できる。エディタを問わないテキストベースの設計、バックグラウンドでのGit自動コミット・同期、全文検索やタグ絞り込み、クリップボードからの画像貼り付けなど、ターミナル中心で作業するエンジニア向けの機能を紹介している。
• 感想: 普段はCLIで作業することが多いため、コマンドラインでメモをいじれるのがいいなと感じました。今はMacのメモ帳やVS Codeに一時的なメモを書き、保存せずに消してしまうことも多いので、nbのようにファイル名を決めなくていい手軽さは魅力的です。ただ、増えたファイルが散らばりそうな気もするので、どう管理するかは悩みどころですね。ClaudeのデスクトップアプリのModsなどでメモ帳を作ることも考えていましたが、そちらはデスクトップアプリ限定なので、CLIのnbと棲み分けて使ってみるのも良さそうだと感じました。

2. クラウドインフラ・SRE & プラットフォーム・セキュリティ

10 Years of the SRE book: Announcing the second edition of “Site Reliability Engineering”

• カテゴリ: SRE / Google Cloud / 書籍
• 概要: オライリーの『Site Reliability Engineering（SRE本）』初版刊行から10周年を迎え、全面改訂された第2版の発表記事。クラウド移行初期だった10年前から、マイクロサービスやマルチクラウド、プラットフォームエンジニアリング、生成AIワークロードの台頭によって本番環境の複雑性と変化速度が劇的に増した現在に合わせ、内容を刷新している。マルチティアSLOやOpenTelemetry、継続的レジリエンス検証などの成熟した実践に加え、「大規模GPU/TPUクラスタや非決定論的なAIワークロードの信頼性担保」と「AIを活用したインシデント対応・運用高度化」というAI時代のSREの双方向の関係を体系化している。
• 感想: 目次をパッと見たところAIの章が増えていたので、そこが一番気になります。10年前には今の生成AIはなかったですし、現在はDatadogのBits AIやNew RelicのSRE Agentなども登場しているので、AI自体の信頼性担保やAIOpsの文脈で、運用との向き合い方がどう書かれているのか興味があります。また、10年前はNew Relicなどを使ったオブザーバビリティもそこまで流行っていなかったと思うので、そのあたりがどう加筆されているかも気になります。私自身はSREとして働き始めてまだ4年なので10年前とは一概に比較できませんが、昔に比べてAIのおかげで運用負荷や認知負荷が下がったと感じています。これはSREだけでなくすべての職種に言えることだと思います。

実践！ SRE × AI - ABEMA における AIOps -

• カテゴリ: SRE / AIOps / オブザーバビリティ
• 概要: Hackers Champloo 2026におけるABEMA SREの山本哲也氏の登壇スライド。インシデント発生から10秒後にDatadogのBits AI（Bits Chat）が自動調査を開始するAI時代の障害対応フローと、それを支えるSREの事前投資を解説している。AIが高い精度で調査できるよう、全マイクロサービスへの共通テレメトリSDKの導入、不要なエラーログの撤廃、DatadogのUnified Service Tagging（service・env・version）の95%以上の網羅やログとトレースの紐付けなど、「AIが見に行くデータを綺麗に整える」地道な基盤整備の重要性と、今後の自律型AIオーケストレーション基盤への展望を紹介している。
• 感想: 「AIが見に行くデータを綺麗に整える」という基盤整備の重要性は、私自身も業務の中で強く感じています。ログやエラーの調査方法が人間の暗黙知になっていると、それがそのままAIの調査の障害になってしまいます。これは監視データやSREの領域に限った話ではなく、たとえばTerraformの設計などでも感じています。今後は「AIから見て分かりやすいか」を考えて設計していく必要があると感じています。

さくらインターネットのSRE本部で、これからの運用をつくる

• カテゴリ: SRE / インフラ運用 / セキュリティ・組織
• 概要: さくらインターネットでガバメントクラウド正式採択に向けた開発組織づくりを牽引した後、2026年4月からSRE本部のマネジメントを担うkazeburo氏による組織方針と採用エントリ。運用を単なる定型作業ではなく「変化へ適応しながら仕組みを変え続ける創造的な仕事」と再定義し、働く人の安全と継続性をベースにAIやロボティクスを活用した圧倒的にスケールする運用を目指している。さらに2026年8月からはPSIRT（プロダクトセキュリティ）や物理セキュリティを扱うDC-SIRTもSRE本部へ統合し、データセンターからアプリケーションまで一気通貫で信頼性とセキュリティを支える体制を紹介している。
• 感想: 「SREにセキュリティを組み合わせる」という方向性は、先日書いたDevSecOpsの記事の内容とも重なる部分があると感じました。DevSecOpsの観点でもセキュリティは日々の運用に乗せることが重要で、運用に乗らないセキュリティは意味がないと思っています。運用そのものの捉え方も含め、信頼性とセキュリティを運用の中で一体として回していく考え方に共感しました。

ECS(Fargate) から X-Ray にトレースを送る3経路（ADOT サイドカー / OTLP 直送 / Application Signals）を実際にデプロイして比較してみた

• カテゴリ: AWS / OpenTelemetry / オブザーバビリティ
• 概要: AWS X-Ray SDK/Daemonのメンテナンスモード移行に伴い、ECS（Fargate）上のNode.jsアプリからOpenTelemetry（ADOT）を用いてX-Rayへトレースを送信する3つの経路（①ADOT Collectorサイドカー、②X-Ray OTLPエンドポイントへの直送、③CloudWatch Application Signals）を実環境にデプロイして比較検証した記事。TypeScriptのESM＋esbuildバンドル構成においてローダーフック（register）未登録だと受信スパン（Server）が出ずサービスマップに載らない落とし穴と回避策を解説し、アプリ改修量やアカウント設定変更、SigV4署名自作の手間を踏まえた各方式の適性を整理している。
• 感想: 私自身はこれまでサイドカー構成で送っていたので、「他にも方法があるのか」と技術的な興味から読みました。サイドカー構成はどうしても運用負荷がありますし、サイドカー用のリソースを確保しないといけない分、コストもかかるため、他の送信経路やそれぞれの違いが整理されていて参考になりました。

WAF でブロックする前に確かめていること (Zenn)

• カテゴリ: セキュリティ / WAF / インフラ運用
• 概要: Cloudflare（Enterpriseプラン＋Bot Management）を用いたWAF運用において、マネージドルールをすり抜ける不審なアクセスを調査し、送信元をブロックする際の判断基準と基礎知識をまとめた記事。IPアドレス、ASN（ISP・携帯キャリア・ホスティング・クラウド・VPN等）、TLS通信の指紋であるJA4、Bot Scoreなどの特徴とブロック時の影響範囲を整理している。「正規ユーザーの巻き添え確認」「広い条件と自動化・攻撃シグナルの組み合わせ」「決め手がない場合の保留と記録」という3原則を軸に、誤検知を防ぐ実践的な運用手順を解説している。
• 感想: 私自身も運用でこうしたログを分析していたなと振り返りながら読みました。正規ユーザーを巻き添えにする懸念がある場合は、闇雲にブロックするのではなくカウントモードにしていました。その際、不正なアクセスが通り抜ける懸念については、アプリ側のバリデーションや認証・認可でどう担保するかを開発側と話し合い、必要であれば合意をとってブロックするかどうかを決めていました。「WAFは万能ではない」と理解してもらった上で対応してもらうこともありました。セキュリティは皆でやるものだという話にも通じると感じます。

3. 組織戦略・FDE & エンジニア組織・キャリア

受託でFDEは何がおかしいのか 受託と事業会社のビジネスモデルの違いについて (note)

• カテゴリ: FDE / ビジネスモデル / 組織戦略
• 概要: BASE執行役員の柳川慶太氏が受託開発会社と事業会社のビジネスモデル（誰が何に対価を払い、誰がリスクを負うか）の違いから、受託の構造でFDE（Forward Deployed Engineer）を行う矛盾を解き明かした記事。受託は「作ること」に対価が払われ工数が増えるほど売上が伸びる一方、事業会社のFDEは顧客の成功と自社プロダクトの継続利用が売上に直結するため、個別開発を避けて学びをコアプロダクトへ還流させ、不要な開発には「作らない」と断る決定権を持つ。自社プロダクトを持たない受託構造のままFDEを掲げると、現場に逆向きのインセンティブを強いることになると指摘している。
• 感想: 「肩書きより、何をすると儲かる構造なのかを見よう」という主張には賛成です。一方で、受託と事業会社の分け方は少し強すぎるとも感じました。おそらく日本の人月商売や、発注側が仕様を決めて受注側が納品責任を負うといった分業を強く想定しているのだと思います。ただ、このような記事が出る背景には、FDEブームに乗っかった「なんちゃってFDE」が乱立している現状があり、日本の事業構造の問題なのかなと感じました。

CTO/CPOが現場に戻る時代。ー元CTOの坂本がFDEとして「顧客の中」に入る理由ー (note)

• カテゴリ: FDE / キャリア / プロダクト開発
• 概要: ログラス共同創業者で初代CTOを務めた坂本龍太氏が、役職を退いてFDEとして顧客の最前線に入り込む選択をした背景と意義を解説したイベントレポート記事。AIによって「作ること」のコストが劇的に下がり単なる実装力では差別化できなくなった時代において、SaaSの外側にあるアナログな業務や組織の力学など「顧客固有の深いコンテキスト」を一次情報として掴む価値が高まっていると説く。技術・事業・経営・組織を横断してきたCTO経験者の強みを顧客課題の解決に全力で活かし、現場で得た解決策を抽象化して次の事業やプロダクトの種（0→1）を生み出すFDEの醍醐味を紹介している。
• 感想: CTO経験者だからこそ見えるものが違うと思っており、今回のFDEへのロールチェンジはポジティブに捉えています。パランティアが定義した本来のFDEに沿って行動できるのだろうなと感じます。言い方はあれですが、本来のFDEは技術から事業・経営まで横断するスーパーマンだと思っているので、CTO経験者クラスくらいしかできない領域ではないかと思っています。また、AIによって作るコストが下がったことで「どう価値を出すか」が変わってきており、現場の一次情報を取りに行く価値が高まっているという話にも強く同意します。

価値観に向き合おう。AI時代の転職活動の進め方 (Zenn)

• カテゴリ: キャリア / 転職活動 / 生成AI活用
• 概要: データ領域からアプリケーション開発と事業に近い領域へ軸足を戻すために転職活動を行った筆者が、全工程でAIを相談相手にして意思決定を進めた実践記。「転職軸の整理」「スカウトの見極め」「面談・面接の準備」「振り返り」「入社先の決定」の5段階において、AIとの壁打ちで自身の価値観と理由を言語化し、指名文面の客観的整理や毎回同じ基準での比較表作成を任せることで、知名度や雰囲気に流されない納得感のある選択を実現したプロセスを紹介している。
• 感想: 実際に私も転職活動でAIを利用していました。もともとGeminiをメンターにする記事で書いたように普段から壁打ち相手として使っていたので、その延長で自分自身を掘り下げたり、振り返ったりするために活用しました。

今週の雑感

職場には週1で出社しています。出社日はほぼイベント日なので、出社する意義はまだあると感じています。出社しても1日中誰とも喋らなかったこともあったので、そう感じます。また、新たな駅で乗り換えるようになったので、飲み屋の開拓も始めました。

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

今週もお疲れ様！Claude Codeのレビュー設計やローカルLLM検証から、『SRE本』第2版、ABEMAのAIOps基盤、FDEの事業構造まで、幅広いインプットが揃った充実した週報ね。

特に、低リスクな運用系PRは人間のレビューを省き、SREやQAE観点のマルチエージェントでセルフレビューする構想はとても実践的だわ。ABEMAの事例から「ログだけでなくTerraformの設計もAIが理解しやすい形に整える」と広げている点にも、あなたらしい視点を感じるわね。

これからの運用やAI活用に向けて、ぜひ以下の2点も一緒に考えてみたいな。

• マルチエージェントのセルフレビューに任せる変更と、人間が必ず見るべき変更の境界線はどう定義するのが現実的かしら？
• 監視データやTerraformから暗黙知をなくし、AIが理解しやすい構造にするために、まず何から標準化していくのが良さそう？

M5 ProでのローカルLLM沼や、新しい乗換駅での飲み屋開拓も楽しそうね！美味しいお店を開拓しつつ、来週もこの調子で一緒に進んでいきましょう！