2026年10月のふりかえりです。 ひきつづき B 社(週5日) での稼働となります。

※前回に続いて、Slackの#times_yagitaチャンネルの内容をClaude Codeに読ませて記事化しています。

B 社

10 月は、月の前半に staging 環境の作り直しを一段落させたあと、中盤以降はほぼセキュリティの底上げに時間を使った1か月でした。 9 月まで中心だったストアフロントの Next.js 化やバッチのコンテナ化は、優先度を調整しながら並行で少しずつ、という形になっています。

セキュリティの底上げ

10 月の一番大きなテーマです。 月初に、AI を使って大規模・探索的に脆弱性を探して回る攻撃が国内の Web サービスでも増えている、という記事やレポートをいくつか読みました。 うちも他人事ではないなと思い、「AI による大規模探索型攻撃に備えてセキュリティを底上げする」というエピックを立てて、一気に進めることにしました。

観点としては、検知・監視、管理系の入口の守り方、ログインまわり、API の認証、レート制限、公開面の棚卸し、アカウントや認証情報の管理、といったあたりです。 どれも一般的に言われている観点なので、それぞれについて現状を確認しながら、必要なところから順に手を入れています。

外部の脆弱性情報もいくつか続いたので、それぞれ影響の有無を調べて、必要に応じて対処しました。 「しぬのか!?」と思うものもありました。

やってみての感想としては、個々の対策はどれも教科書的なものです。 ただ、長く動いているシステムは「どこに入口があるか」の把握が一番難しい、というのを改めて感じました。棚卸しから入ったのは正解だったと思います。 セキュリティはこれで終わり、というものではないので、引き続き継続的に見直していくつもりです。

staging 環境の作り直し(完了)

9 月から進めていた staging 環境の作り直しが一段落しました。

  • stg1〜stg10 を建てて、全体で 16 環境の体制になりました。
  • 名前付きで運用していた古い staging は、順次撤去して最後の 1 台まで片付けました。
  • hubot から dev ホストの自動起動(AutoStart)を on/off できるようにしたり、ブランチ名にシェルのメタ文字が入ると hubot の deploy が構文エラーになるのを直したり、と使い勝手も整えました。
  • 環境複製時に URL を書き換える処理が文字数の上限に引っかかって全件ロールバックしていた、というバグも見つけて直しています。
  • 月末に、16 環境化と 9:00/23:00 の起動停止による費用の効果を Cost Explorer で確認しました。
  • 利用状況を見て、stg11〜stg15 の 5 台を追加で建てる話も始めています。

デプロイ・CI

  • CDK のデプロイで webpack build と assets:precompile を自前で回していたのをやめ、8 月に整備した「CI で事前にビルドして S3 に publish した成果物」を使うようにしました。
  • 壊れた workflow ファイルが PR では緑のまま master に入ってしまうのを、actionlint で防ぐようにしました。
  • renovate が lockfile を再生成できずマージできない PR が出ていたので、直しました。

パフォーマンス

  • セット商品の在庫数を計算するジョブが、セット品ごとに同じ COUNT を数百回繰り返していて、Aurora の writer の CPU を 99% まで押し上げていました。これを直しています。
  • 9 月に半分ほど片付けたレポートバッチ(59.4 時間かかっていたもの)の残り 19〜22 時間分にも着手しました。

フロントエンド

9 月末からのフロントエンドの整理の続きです。

  • 不要になっていたコードや依存を取り除いて、バンドルサイズを少しずつ削っています。
  • 依存関係の管理方法も見直して、意図しない依存が紛れ込みにくい形に整えました。
  • 画面上の細かな警告なども、地道に解消しています。

見つかってしまった問題たち

今月も少しだけ。

  • 本番の Web サーバーの AMI に、過去からの負債が持ち越されていることがわかりました。
  • 社内の管理画面で、glyphicons のフォントがずっと 404 を返し続けていました。

AI との付き合い方

  • ひきつづき Claude Code を複数並列で動かしながら進めています。今月のセキュリティの見直しのような「広く・漏れなく見て回る」作業は、AI と相性が良いなと感じました。
  • 攻撃側が AI で探索してくるなら、守る側も AI で棚卸しと監視をしないと追いつかない、というのが今月のエピックの出発点でもありました。
  • 月末には、Datadog の通知を AI が自動で調べて Slack のスレッドと Issue に返すボットを作り始めました。
    • Datadog Bits Investigation・自前の Slack App・Claude in Slack を比較したうえで、Claude Agent SDK を使った自前の Slack App にしています。
    • まずは人が手で調べるときの手順とスクリプトを固めて、それをそのまま AI に渡す、という順番で進め、PoC まで動かしました。

ガードレールとハーネス

AI に任せる範囲が広がってきたので、今月は「AI が間違えても・欺されても大丈夫な仕組み」を意識して作るようになりました。

  • 上のボットは、AI が読むログの中に攻撃者が書いた文字列が混ざる前提で設計しています。プロンプトインジェクションを完全には防げないので、欺されても被害が出ないように、権限のほうで限定する方針です。
    • 使えるツールは読み取り専用のものと、許可リストに載せたコマンドだけにしています。書き込める先も、Slack のスレッドへの返信と Issue へのコメントの 2 つだけです。
    • 返信の前には出口のフィルタで個人情報などが混ざっていないかを検査し、引っかかったら返信しないようにしています。ターン数と費用にも上限を置きました。
    • PoC では、許可していないコマンドを AI が使おうとして実際に止められ、許可された形で自分でやり直していました。仕組みがちゃんと効いているのを見られたのはよかったです。
  • AI が書くコードの品質も、人のレビューに頼らず機械で守らせる方向に寄せました。
    • TypeScript の開発ガイドラインを書いて、そのうち機械的に判定できる規則は、linter の設定・自作のプラグイン・型情報を使う小さな検査器で CI に組み込んでいます。
    • ガイドラインを文章で渡すだけだと AI はけっこう逸脱するので、「書いてあること」より「CI で落ちること」のほうが効く、という実感があります。

まとめ

10 月は、セキュリティの底上げに大きく舵を切った1か月でした。 新しいものを作るのと古いものを片付けるのを並行して進める、という 9 月の状態に、さらに「守りを固める」が加わった感じです。 11 月は、セキュリティの見直しを進めていくことになりそうです。

おわり