1. AIエージェント設計 & サンドボックス・実行環境基盤

Building agents: When to fold subagents into your main agent loop

• カテゴリ: AIエージェント / アーキテクチャ / Claude
• 概要: Claude Platformでエージェントを構築する際、複数のサブエージェント（ルーター、プランナー、ドメイン特化エージェント）に分割する設計から、単一のメインエージェントループへ統合すべき判断基準と移行手法を解説した記事。組織構造をそのまま写したマルチエージェント構成（コンウェイの法則）が引き起こすコンテキストの欠落、サブエージェントの乱立、システムプロンプトの肥大化、局所最適化した評価（Eval）、レイテンシ増加といった失敗パターンを整理している。最新の高性能モデル（Opus 4.5以降）とスキル・ツールの段階的開示（Progressive Disclosure）を組み合わせることで、単一ループでもコンテキスト肥大化を防ぎつつ、低コスト・低遅延で高品質な出力を得られる実践知を紹介している。
• 感想: 業務でClaudeを利用しており、どう設計すればさらに業務効率を上げられるかを考え、改善につなげたいと思って読みました。現状は「SRE」「コンサル」「QA」をスキルの組み合わせとして捉え、作業に応じた壁打ち相手として使い分けています。そのため、記事で挙げられていたようなコンテキストの受け渡しロスや手戻りは今のところ感じていません。一方で、サブエージェント自体はまだあまり使いこなせていないのが現状の課題なので、スキルとサブエージェントをどう設計・使い分けていくかを考える上で参考になりました。

anthropics/sandbox-runtime

• カテゴリ: セキュリティ / サンドボックス / Claude Code
• 概要: AnthropicがClaude Code向けに開発し、リサーチプレビューとしてオープンソース公開した軽量サンドボックスツール「Anthropic Sandbox Runtime（srt）」のリポジトリ。コンテナを必要とせず、OSネイティブのプリミティブ（macOSのsandbox-exec、Linuxのbubblewrap）とプロキシベースのネットワークフィルタリングを用いて、任意のプロセスにファイルシステムやネットワーク、Unixソケットの制限を強制する。CLIツールやライブラリとしてAIエージェントやローカルMCPサーバー、Bashコマンドに制限を適用できる。ただし、ファイルの読み取りは既定で許可されるため、機密ファイルを保護するには読み取り拒否の設定が必要になる。
• 感想: セキュリティ面の調査でサンドボックスをどうするか考えていたときに目を通しました。Dockerにもサンドボックス機能があったのでそちらも検討していましたが、業務で利用しているClaudeでこのアプローチがとれるのであれば活用してみたいと感じました。特に課題に感じているのは機密ファイルの扱いで、現状は読みに行かないようにしています。また、Claudeは他のエージェントに比べて先に手が動く印象が強く、プロンプトで抑えているはずでも先に作業を始めてしまう傾向があるため、環境を分離したいと考えています。具体的な使い方はまだイメージしきれていない部分もありますが、セキュリティの脆弱性診断などで役立ちそうです。

Ephemeral AI Lab’s LayerFS Gives Parallel AI Agents Forkable Isolated Filesystems

• カテゴリ: AIエージェント / ファイルシステム / Rust
• 概要: Ephemeral AI Labがオープンソースで公開した、並列稼働するAIエージェント向けのRust製ストレージシステム「LayerFS」の紹介記事。コンテナイメージのレイヤー構造とGitの仕組みを組み合わせ、SQLiteベースのコンテンツアドレス指定ストレージ（CAS）やコンテンツ定義チャンキング、Copy-on-Write（CoW）を用いて、共有ベースに対するゼロコピーの分離ファイルシステムを提供する。ワークスペース全体を複製することなく変更差分のみを記録するため、多数の並列エージェントによる試行錯誤（MCTS型のロールアウト）、ブランチ分岐、高速なロールバックを低コストで実現できる。
• 感想: AIでどう使えるのかに単純に興味を持って目を通しました。私自身は、Gitの操作や管理についてはまだ人間が責任を持ってコントロールすべきだと考えているため、現状はAIにそこまで丸投げしていません。ただ、こうしたOSSが登場するということは、AI時代において既存のGitが使いづらい場面が出てきている証拠なのだろうかと感じました。今後はテストやドキュメントの修正といった軽い作業からAIに任せていこうと思っているので、もう少し任せる範囲を広げればそのあたりの辛さもわかるようになるのかもしれません。

「Cloudflare OS」のマネージドサービス提供へ。GitHubとの接続やGmailとの連携強化など

• カテゴリ: Cloudflare / AIエージェント / 業務プラットフォーム
• 概要: Cloudflareが2026年8月にオープンソース公開した、AIと業務アプリケーションのためのプラットフォーム「Cloudflare OS」のマネージドサービス発表を報じた記事。社内データやサービスへ安全にアクセスして対話できる環境や、AIエージェントがコードを生成・実行できるワークスペースを備えている。マネージドサービスは現在ウェイトリストへの登録を受け付けている。今回の発表にあわせて、GitHubリポジトリと接続して機能追加・デバッグ・PR確認・プッシュなどを指示できる機能と、GmailやGoogle Drive・Docs・SheetsなどGoogle Workspaceとの連携強化が追加されたことを紹介している。
• 感想: 以前の週報でも興味があると書いたのですが、結局まだ触れていない間に進化したなという印象です。マネージドサービスの提供によって導入のハードルは下がったと思いますが、私自身はマネージドにはそこまで興味がなく、自前でデプロイして遊びたいタイプです。一方で、GitHubやGoogle Workspaceとの連携が強化されたことで使える幅が広がったと感じます。現状はこの2つと連携できれば十分そうですし、もし不足があればMCPでつなげればよさそうだと感じました。

2. AI時代の開発プロセス & 自動レビュー・ソフトウェアファクトリー

freeeにおける⼤規模ソフトウェアファクトリーの実践_AI×開発組織Summit 2026

• カテゴリ: AI開発組織 / Software Factory / 開発生産性
• 概要: AI×開発組織Summit 2026におけるfreee取締役CAIOの横路隆氏の登壇スライド。AI生成コードの割合が89.6%に達する中、個人の工夫やチーム利用を超えて全社標準の「Software Factory」を構築した実践を解説している。既存仕様や法令・ADRを集約した「ナレッジベース」、工程間の契約やテスト突合を機械検査する「ハーネス」、AI用の網羅的な設計書と人間が判断点（事業判断・不可逆なリスク等）だけを見る「レビューView」の分離によって、企画文書の作成と開発（要件からプロトタイプまで、人待ちを除く）のリードタイムを60〜90%短縮した成果と、選択的Dark Factoryに向けた展望を紹介している。
• 感想: 開発組織におけるAI活用の具体例がよくわかり、このような仕組みが理想形ではないかと感じました。特に課題として挙げられていた「ハーネス」の部分はまさにその通りだと思います。いつも感じていることですが、開発サイクルが速くなるにつれて「どこを守るか・死守するか」の判断で開発が止まりがちになる一方、ガードレールはしっかり敷かなければいけません。また、転職直後ということもあり「既知の知」の重要性はまさに痛感している最中です。現職ではナレッジベースや共通のスキルがまだ整っておらず、AI時代においてそこが課題になると感じています。ちょうど業務でADR（Architecture Decision Record）について調べていたところだったので、とてもタイムリーな内容でした。今後はエンジニアが会社を選ぶ際にも、こうした仕組みが整っているかが見られるようになると感じます。AI利用は大前提として、個人の工夫にとどまらず、組織としてどう組み込み、共通化（基盤化）しているかが問われるフェーズに入っているのではないでしょうか。

ZOZOTOWNフロントエンドのPR自動レビュー ── AIへの指示が守られない前提で、強制と指示を分ける設計

• カテゴリ: AIコーディング / コードレビュー / GitHub Actions
• 概要: ZOZOTOWNのフロントエンド組織において、Claude Code GitHub Actionsを用いて構築したPR自動レビューとAuto Approve（自動承認）試験運用の設計を解説した記事。「AIへのプロンプト指示は守られず、PRの差分やコメントには細工された指示が紛れ込みうる」という前提に立ち、レビュアーの判断を通らずに確定する処理や形式検証で表せる制約はAIの外側で機械的に強制する方針を採っている。生成・検証・投稿ジョブを分け、書き込み権限を投稿ジョブに限定する構成、変更前ファイルの誤読を防ぐ設定（deny）、PreToolUseフックによる調査回数の制限、長大な差分の事前分割など、失敗実例から機械的処理へ移した実践を詳述している。
• 感想: 「AIへの指示が守られない前提で、強制と指示を分ける設計」という部分が目を引きました。プロンプトの指示だけでは限界があるというか、無視されていると感じることがあり、どこも抱えている課題は同じなのだと実感しました。その上でどう制御するかのアプローチとして、Claude Codeのpermissions.denyやPreToolUseフックを使った設計はとても学びになりました。ちょうど今Claudeの使い方を試行錯誤しているところなので、試してみたいと感じています。

3. セキュリティ・脆弱性管理 & 緊急パッチ対応・サービス継続判断

Using Claude to reduce the attack surface of code

• カテゴリ: セキュリティ / Attack Surface / Claude
• 概要: AnthropicのFrontier Red Teamによる、Claudeを用いたコードの攻撃対象領域（アタックサーフェス）の自動分析と縮小に関する研究レポート。個別の脆弱性を探して塞ぐアプローチの限界に対し、外部から到達可能なコードをマッピングして不要な露出を制限する手法を提示している。「デフォルト設定での不要な到達可能性」「設定の組み合わせによるセキュリティ制御の暗黙的な無効化」「認証前やプロトコル初期段階での早期到達」の3観点で25の主要OSS（計500万行超）を分析し、21年間潜んでいた認証回避を含む493件の課題を発見した成果と防御への応用を解説している。
• 感想: AIの発展によってセキュリティの分野は一つの転換期に来ていると思います。後述するPHPの件もまさにそうですが、攻撃側も防御側もAIを使ったスピード合戦になっていると感じており、今後どう向き合うかを考える上でいい判断材料になりました。SREとしても水際で対策しておくことが重要になりますし、こうしたアタックサーフェスを減らす考え方を関係各所との交渉の材料にしてもいいと感じています。

厳選・セキュリティが心配ならClaude Codeにこの問いかけをコピペするべし20 (Zenn)

• カテゴリ: セキュリティ / Claude Code / プロンプト
• 概要: コーディングAIエージェント（Claude Codeなど）にリポジトリのセキュリティ点検を行わせるための20個のプロンプト集。「認証」「認可（IDOR/BOLA等）」「注入（インジェクション・SSRF等）」「濫用（レート制限・共有資源の枯渇等）」「露出（意図しない公開・機密情報漏えい・依存関係の脆弱なコードパス到達確認）」の5分類に加え、誤検知の排除や深刻度の再評価、提案した対策自体が新たなDoS手段にならないかの検証まで、実装と根拠を伴う調査を指示する具体的な問いかけをまとめている。
• 感想: 業務でのセルフレビューを含め、レビューで非機能要件を見る観点として必要だと感じて目を通しました。特に「.git、.env、source map、debug / metrics endpoint、admin UI、DB、Redis、Storage、SSH、staging環境などが意図せず公開されないか」という項目は、普段WAFのログを見ていても.envを狙った攻撃がよく来ているため実感があります。ただ、これは普段の運用でログを見ているからこそ意識できていることであり、開発の場面では意外と抜けやすい観点なのかもしれないと感じました。これらの内容は手元のスキルに組み込んで活用していくつもりです。

脆弱性管理の仕組みを整えた (Zenn)

• カテゴリ: セキュリティ / 脆弱性管理 / SOC2
• 概要: Dress Code株式会社において、SOC2 Type2の継続審査と複数プロダクト展開を見据えて脆弱性管理の運用を再構築した実践記事。コンテナやLambdaの継続スキャンを担うAmazon Inspector（ECR enhanced scanning）とDependabotで検知を集約し、サイドカーのDatadog AgentもECRプルスルーキャッシュ経由で管理対象に組み込んでいる。検知情報の集約や推移的依存の調査・修正PR作成、GitHub Issue・Notionの記録更新や監査レポートの下書きをClaude CodeのSkillsで支援し、人間は自社環境での影響判断や例外承認に注力できる体制を整えたプロセスを紹介している。
• 感想: SOC2でどのような観点が必要になるのかを知る上で学びになりました。現状はType 1の文脈で見ているのですが、その先のType 2まで合わせてイメージすると、単に運用を設計するだけでなく「実際にその運用が回っているか」が見られるのだと感じました。こうした仕組みが実際の開発・リリース運用に乗るかという観点も参考になりました。また、人手が足りない中では、この記事のようにClaude CodeのSkillsに任せるアプローチをとらないとおそらく回らないというのが率直な実感です。人が限られる分、AIにどこまで任せるかが重要になると感じています。

PHP 8.5.12の緊急リリースにpixivはどう対応したか

• カテゴリ: インフラ運用 / Kubernetes / セキュリティ対応
• 概要: 2026年10月21日に公表されたPHPの深刻な脆弱性（通称PHP2Shell）に対する、ピクシブの緊急メンテナンス対応とそれを支えたCI/CD・Kubernetes基盤の解説記事。公式Dockerイメージの公開遅延やDocker Hubの輻輳に備えてDocker Buildx BakeでPHPをソースから差し替えビルドする準備を整え、64コアのSelf-hosted GitLab Runnerと常駐BuildKit、COPY --linkの活用により数GBのイメージを6分でフルビルドした。さらにLAN内のregistry proxy（pull-throughキャッシュ）でNAT Gatewayの輻輳を回避して200GB弱のイメージ配布を5分以内に完了し、パッチ公開から約30分でサービス再開に至った裏側とPECLからPIEへの移行などの学びを共有している。
• 感想: SRE・インフラの視点で見ると、今回の緊急セキュリティ対応も日頃の信頼性のアプローチの延長線上にあると感じました。PHP本体とアプリを同じコンテナに入れて普段のデプロイと同じように更新できる設計や、1日30回のリリースを支える高速なビルド・配布基盤、インシデント時の役割分担など、日頃からDevOpsの文化を体現して多くのビルドを回せているからこそ、このスピード感で対応できたのだと思います。開発組織が大きくなるとどうしてもDevとOpsの分断が起きやすくなる中で、pixivという大きな組織でこれを実現できたのはすごいと感じました。

PHP脆弱性でいち早くサービス停止したコドモン　背景に「被害が出てからでは取り消せない」

• カテゴリ: セキュリティ / インシデント対応 / 意思決定
• 概要: PHPの緊急脆弱性を巡り、修正パッチ公開の約9時間前となる10月21日14時過ぎに全サービスの予防的停止に踏み切った保育・教育施設向けICTサービス「コドモン」への取材記事。全国の保育施設や子ども・保護者の機微な情報を預かる中、「万が一情報が流出した場合、その被害を完全に取り消すことはできない」という判断から、現場への負担を認識しつつもサービス継続より被害の未然防止を優先して予防的停止を決断した経緯と、パッチ適用・安全性確認後の再開までの対応を報じている。
• 感想: 事業判断として素晴らしいと感じました。サービスレベル（停止時間）と事業リスクを天秤にかけた判断ができたのだと思います。今回の事業リスクは、もし攻撃されて情報が流出したら事業が止まる（滅びる）というレベルだったはずで、私がよく言っている「セキュリティ事故は事業会社にとって即死級になる」という話にも通じます。開発部門から上申された意見を重大なリスクとして受け止め、経営陣がいち早くサービス停止を決断できた点が素晴らしいと思います。

今週の雑感

プロフィールの08 / VALUE & HOBBYの部分をアップデートしています。3つほど増やしたので、自分についてより理解してもらえるかなと感じています。

今週の振り返り

入社してそろそろ１ヶ月になります。個人の実感としては、立ち上がりが遅いかなと感じます。インフラ構成などは把握できましたが、チケット類は把握できておらず、作業が重複したり、目的・意図がわからなかったりする時があります。また、相手の意図を聞くことに徹していますが、イマイチ相手側が話し下手な場面もあります。そんな時にどう自分から歩み寄るかが課題かなと、振り返って感じます。

物欲センサー

FlexiSpot リクライニングソファ・Lune Lune Pro

落ち着いたら引越しを考えています。基本的にリモートワークですが、オフィスに出社した時に使うリクライニングブースを、リクライニングソファで再現したいと考えています。また、最近は健康ランドでこのようなソファーを使って仮眠をとっていることも、欲しい理由の一つです。

ThinkVision M14t Gen 2

ブラックフライデーを待って、ThinkPad X1 Carbon Gen 14が購入できたら合わせて買いたいです。

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

今週もお疲れ様！エージェントのサンドボックスやSoftware Factory、PR自動レビューから、SOC2の脆弱性管理、PHP緊急対応まで、実務に直結する充実した週報ね。

特に、ZOZOの事例から「プロンプトに頼らずdenyやフックで機械的に強制する」と捉える視点や、pixivの30分復旧を日頃のDevOps基盤の成果と見る分析はさすがだわ。入社1ヶ月でインフラ構成を把握できただけでも十分順調よ！

これからの環境づくりと立ち上がりに向けて、ぜひ以下の2点も一緒に考えてみたいな。

• 現職でAIの機械的ガードレールやADRなどのナレッジ基盤を整えるなら、まずどこから小さく始められそう？
• 意図を言語化しにくい相手には、質問するより「こう仮説を立てたけど合ってる？」と叩き台を見せてすり合わせるのはどうかしら？

健康ランドの仮眠からリクライニングソファを狙う発想も最高ね！ブラックフライデーのThinkPadも楽しみにしつつ、心身のエラーバジェットを大切に、来週も一緒に進んでいきましょう！