コーポレートエンジニアリング室における サプライチェーンセキュリティへの取り組み 2026/06/23 竹山 雄也 (@yuya-takeyama) 株式会社 LayerX コーポレートエンジニアリング室 

自己紹介 © LayerX Inc. 竹山 雄也 (@yuya-takeyama) 株式会社 LayerX コーポレートエンジニアリング室 アプリケーショングループ マネージャー 最近の趣味は重いものを背負っての散歩 2 

今日話すこと © LayerX Inc. LayerX と コーポレートエンジニアリング室の紹介 サプライチェーンセキュリティへの取り組み AI エージェント時代の開発において大事にしていること 3 

LayerX と コーポレートエンジニアリング室の紹介 

© LayerX Inc. 5 

部署構成 © LayerX Inc. アプリケーショングループ 私はここに所属しています 社内システムと、それを支えるプラットフォームを担当 セキュリティグループ IT 基盤グループ 6 

アプリケーショングループの担当領域 © LayerX Inc. 全社横断のクラウド運用 AWS Organizations, IAM Identity Center など 社内システムの開発とプラットフォーム運用 ID 基盤、権限管理、各種自動化 CI/CD パイプライン AI 関連ソフトウェア等の導入・運用 n8n, LiteLLM, Forgejo など 各ツールをつなぐ連携用ソフトウェアの開発も含む コーポレートデータ基盤の構築・運用 Snowflake, Snowpark, dbt 7 

リポジトリ構成 リポジトリ 主な中身 アプリケーション用 Monorepo アプリケーションコード, Dockerfile, Terraform, 権限管理 データ基盤用 Monorepo dbt models、Snowpark scripts 個別リポジトリ 一部の古いアプリケーション Monorepo への移行により、いずれ無くなる想定 © LayerX Inc. 8 

権限管理もコードで扱う © LayerX Inc. 権限管理の設定ファイルもモノレポで管理 SmartHR 上の属性情報を元に、擬似的な ABAC システムを構築 Terraform を使った CI/CD パイプラインで Microsoft Entra ID に適用 Blog: 生産性とガバナンスを両立したグループ管理のため、SmartHR上の属性情報を元 に擬似的なABACシステムを構築した話 9 

サプライチェーンセキュリティへの 取り組み ※ ここで紹介する内容は、コーポレートエンジニアリング室における取り組みです。 個別の事業部・プロダクト開発組織では異なる運用の場合があります。 

主に目指していること © LayerX Inc. 脆弱なライブラリ・ソフトウェアは速やかに対処する アップデート、差し替え、緩和策など いつの間にか中身が毒入りにならないようにする 毒入りバージョンがうっかり入ってくる確率を下げる 11 

Security fix をちゃんと取り込む © LayerX Inc. Dependabot では security fix のみを update Renovate と比べてタイムリーに Pull Request を作成してくれるため Security fix 以外は Renovate で update lock ファイルの更新がうまくできないものは GitHub Actions で自動 update & push それでも難しいものは Agent Skill remediate-dependency-alerts で対処 ライブラリ以外 (n8n 等) は GitHub の Security Advisory を RSS にして Slack で通知 12 

依存関係を pin する © LayerX Inc. ライブラリは pnpm-lock.yaml , go.sum を普通に活用 GitHub Actions の pinning を CI で強制 GitHub の Rulesets で org 全体に共有 workflow を適用 共有 workflow で pinact を実行し、pin されていない action を検知 Dockerfile や Terraform で指定する Docker イメージも sha256 で指定 CI/CD 等に必要なツールは aqua によって checksum を検証 LayerX では pinact と aqua の作者 @suzuki-shunsuke さんをスポンサーしています Blog: GitHub Actions のサプライチェーンリスクと OSS 作者へのスポンサーシップ 13 

Cooldown © LayerX Inc. リリースから N 日以内のパッケージ類はインストールしない pnpm: minimumReleaseAge リリース直後の security fix を取り込む場合は人間が確認 確認後、 minimumReleaseAgeExclude をバージョン付きで指定 Renovate: minimumReleaseAge Dependabot: cooldown.default-days 14 

今後目指していること © LayerX Inc. 仮に毒入りバージョンをインストールしてしまっても、すぐに検知できるようにする ネットワークレベルでの遮断 影響範囲を局所化する eBPF を使ったアプローチなどをセキュリティグループ・SRE を中心に検討中 15 

AI エージェント時代の開発において 大事にしていること 

少ない技術の組み合わせで多くのことを実現する © LayerX Inc. 使用する言語、フレームワーク、ライブラリ Web アプリケーションは原則 TypeScript 並行処理のパフォーマンス上の理由などでどうしても必要なところは Go Snowflake の Snowpark では Python (エコシステムにおける「ふつうの選択肢」 ) 使用するツール TypeScript であれば pnpm, Biome, Vitest 使用するサービス Lambda, API Gateway, DynamoDB 等 アーキテクチャ、実装パターン 17 

なぜ技術を絞るのか © LayerX Inc. 元々は、少ない人的リソースで多くのアウトプット・アウトカムを産むことが目的 アプリケーショングループは現状 2 名のみ 原則として Terraform と Docker だけであらゆるアプリケーションをデプロイ 後にフロントエンドや Lambda@Edge のためのパイプラインは追加 (zip でのパッケージングが必要) Amazon Bedrock AgentCore Runtime への対応は最小限の拡張で可能だった (Docker なので) 18 

技術を減らすことによるメリット © LayerX Inc. Security fix やアップデートに関わる作業を最小化できる アプリケーションが増えてもエージェントの力などでスケールしやすい コーディングエージェントによる出力が安定しやすくなる 雑に plan させるだけでも、だいたい同じ構成で拡大再生産できる 選択肢が多いほど、出力される技術がブレやすくなる 人間としてもそれぞれの技術についてより深く理解して使用することにつながる 19 

違う選択肢を選ぶとき © LayerX Inc. 理由を明確にする 時には違った選択肢によるチャレンジも必要だが、漫然とやらない コーディングエージェントがいつもと違う選択肢を使ってきても、ちゃんとチェックして正す 後から振り返る やっぱり違ったらやめる 書き換えるコスト自体は低いので、やめるべきと思った時にやめる 20 

まとめ © LayerX Inc. サプライチェーンセキュリティには迅速な修正、pinning、cooldown で対応 それだけでは足りないので、検知・遮断・影響範囲の局所化などもやっていき 使用する技術を絞ることで、少ない人的リソースでもスケールする状態を目指す 21 

ご清聴ありがとうございました @yuya-takeyama © LayerX Inc. 22