課題

• Gitない
• 数千台のEC2、インフラが魔境（オンプレをそのままクラウドリフトしたため）
• Twelve Factor Appに準拠していない仕組みが多い

方針

• 全体：新しい環境にする
• IoT→10年など長期稼働する→設計も技術も疎結合に

参考にしたもの

• CloudTrailマップ
• K8s完全ガイド(書籍)

失敗したこと

• ステートフルで読解困難なプログラム、設定値もたくさん、ログも多い→すごくでかいコンテナが残ってしまった

ステートフルモノリスのデメリット

• スケーリング困難、可用性・耐障害性の低下、k8sとの相性が悪い

結果

• トラフィック予測、社内メンバー協力で成功
• 直後の課題：ワークロード数多くて認知負荷高い、監視項目の不備が出た

懸念

• 少人数でやったので、ただのリファクタで終わるかもしれない
• →若年層向けに知識をつけるための機会を設ける
• チョークトークの開催：設計思想と判断の背景を伝えて、議論する

チョークトークでの気づき

• ECSとLambdaとの比較
• k8s基盤のデメリット：学習コスト、リリース障害
• k8sの合うところ：トラフィック制御、サービス数の多さ

成果

• 責任感とスピード感がでて、新規事業にも着手 展望
• モノリス解体、UX駆動

挑戦

IoTの障害調査、クラウドからデバイスまでのトレーシング 仕組みは簡単に見えるが、いくつかの工夫があった

• OTelの仕組みをデバイスに適用
  • デバイスからトレースID・Spanの送信
  • CPUとメモリ制限の関係でSDK採用を断念して独自実装
  • 遅延送信でデバイスに影響を与えないようにする
• eBPFで低レイヤを可視化する
  • IoTデバイスはネットワーク・OSレベル障害が多い
  • eBPFで詳細化したが、カーネルイベントにトレースIDを付与（デフォルトでは付与できない？）
  • デバイス内部で何が起きたかまでわかるように
  • 時刻ずれの修正
    • デバイスの時刻が数百msでずれが発生しやすい
  • IoTでの学び・苦労をベースにクラウドに適用していた

環境の変化

ソブリン→デジタル主権

• ソブリンクラウドが求められる
  • 自国でのデータ保存など
  • AIでより一層求められている
• CNCDアニュアルサーベイでは66%の組織がk8sを利用

ソブリンクラウドのビジネスチャンス

• トレンドとベンダー企業のチャンス
  • 欧州発の新市場、日本にも拡大している
  • SI企業の新市場で新ルール
• グローバルトレンドの国内波及

欧州事例から読み解くソブリンテック時代の技術要件

• 背景
  • KubeConの基調講演・セッションがソブリンクラウドの話が多かった
  • 取り組みと検討がかなり増えている
• ソブリンクラウドの定義： Cloud Sovereign Framework
  • 重みベースで主権があるのか・ないのか、グラデーション含めて定義される
  • Effectiveness Assuarance Levelをパスしないと落札できないこともある
• ドイツの事例：Sevreign Cloud Stack
  • 派生プロジェクトの展開：ALASKAとYAOOK
  • Yet Anathor OpenStack なんちゃら　K8s
• フランス国鉄の取り組み
  • フランス国鉄は世界で二番目の鉄道網を持つ
  • ハイブリッド・マルチクラウドアプローチ
  • 3割をオンプレ、7割のワークロードがクラウド
  • データを自動でカテゴライズして、パブリッククラウドか社内か決めている
    • wisely hostと自称

日本では？

• ブリュッセル効果：EUとかの規制や基準が巨大なマーケットの力でEU外に事実上の世界基準として広がる事象
• 後ほど波及する
• MSが100万人育成するための投資を発表するくらい、専用人材がかなり不足してそう
• →人材育成が必要
• →ビジネスとコミュニティの両方が必要

ソブリンクラウド時代の推しPJT

• OpenStack
• OpenTofu
  • Terraformの強力なOSS代替
  • TerraformがOSSじゃない雰囲気になってきた
  • 日本ではまだ流行っていない
• CoHDI：日本初のPJ
• FinOps Foundation：クラウド最適化のベストプラクティス, 2日前に日本語版も出た！

背景

サプライチェーン攻撃は、攻撃者の観点で見ると１パッケージの改ざんだけで多くのアプリに影響を与えることができるメリットがある。

調査によると

• 99.5%のOSSコンポーネントは修正版を提供している
• 80%以上のアプリケーション依存が1年以上更新されない
• 13%は公開から3年以上経っても影響のあるバージョンを使用していることがある

コンテナのベースイメージあるある

• ベースイメージにアプリ実行に不要なコンポーネント（シェルやパッケージマネージャなど）
• 開発者自身で修正・脆弱性パッチが難しい
• コミュニティが管理している

イメージ選定

安全なものを選ぶには

1. 信頼できるパブリッシャーから選択する
   1. =発行元が不明確なものを選択しない
2. 必要最小限のコンポーネントで構成されたイメージを選択する
   1. slim, alpine
   2. ディストロレス
      1. デバッグのしづらさがある

課題

1. 明確なイメージは依存・脆弱性が少ないわけではない
2. 必要最小限のコンポーネントは脆弱性対応が早いわけではない
3. ディストロレスは種類が少ない

Hardend Container Images

• 依存・脆弱性を大幅削減し、脆弱性が検知されると即座にパッチ適用を行う（SLA保証）
• Chainguard 社提供
• Docker社も2025から提供（DHI Enterprise）

Docker Hardend Imagesの脆弱性対応の流れ

• 定期的な検知ではなく、リアルタイムに検知している
• 検知すると、影響のあるイメージにパッチ適用する
• Community Editionもある（SLA保証はないが）
• SupportやSLA保証したい場合、ChainguardやDocker Enterprise活用がおすすめ

移行する際は、パスを変えるだけで良い。仕組み上、サイズもかなり削減できる。 Docker Hardened System PackagesでOSレベルまで対応している。

ライブラリ対応どうするか

• Socket Firewallの活用が可能
• 独自プロキシで既存/潜在的なマルウェアを特定し、ブロックする
• DHIにはデフォルトで梱包されている

無料ツールの例

• ZAP セキュリティエンジニア向け、幅広
• sqlmap セキュリティエンジニア向け(ホワイトハッカーなど)、幅狭（SQLインジェクション等に特化）
• Wapiti 開発者向け、幅広
• Dastardly 開発者向け、幅狭

AeyeScanの紹介

• GUIでの操作
• CI/CDと連携も可能

ツール単体ではなく、ハイブリッド型の運用がおすすめ

• 構築時は内製
• 運用時の定期実行でツールを使う

経緯

• AI活用
• リリース頻度・規模も上がった
• AI以前は性能劣化が予測可能だった
  • 日次・週次で遅い目と陸を確認
  • EXPLAIN ANALYZEを職人技で読む
  • インデックス・クエリ改善
• 改善のリードタイムの定義：発見→調査→修正→検証→改善まで
• AIで調査と修正が爆速になった
  • 治し方がわからないはほぼ無くなった

困りごと

• 本番と同じデータ量でないと判別しない
• 遅い状況を再現できない
  • ユーザが踏んだ時と同じ状況にならない
• AIにセキュリティ的に任せられない
  • データを渡せない
  • 本番環境で操作を任せられない

結果、検証がリードタイムの大半を占めている

Platform Engineeringで検証を効率化する

方針：AIでブーストする

調査フェーズ

• o11yの強化
  • APM
  • DBM(db monitoring)
• 遅いクエリを安全に再現する
  • 本番と同等の環境を用意する
  • 1コマンドで本番と同量のデータをサービスに影響なく触れる環境を用意する
  • ネットワークとアクセス経路を分離し、本番へのアクセスする可能性を排除する
• ツールの自作
  • CWLからスロークエリを集めるツール
  • 集めたスロークエリを安全にEXPLAIN ANALYZE
    • 権限の絞り込み
    • fool proofの仕組みでSQL実行でロールバックさせる
  • 作った理由
    • ツール自体は存在するが、自社独自の仕組みにハマるものを作りたかった
    • AI活用
• 性能改善を最重要課題のまま回すための仕組み
  • コストと影響を明確化し、上長に伝えやすくする
  • CSの方も判断しやすくする

修正フェーズ レビュー時、大量のDiffがあるのでSQLを細かく見ることは難しい

• ESLintのカスタムルールを作り、CIで自動検知する
  • インデックスを効かせやすいSQLになっているか
  • AIと並走して作る事ができるように
  • IDEでも警告出せて便利
• 残った知見をSKILLに蓄積する
  • 性能改善PR・インシデントのパターンを出しておく
  • 静的解析と組み合わせて活用

背景と課題

• 220個のマイクロサービス
• 膨大なメンテナンス工数
• スケールしない運用負荷

HPAからKEDAへの移行

課題

1. ゼロスケール（Sandboxを夜間休日に止める。コスト削減
2. 柔軟なスケーリング（Pub/Sub、Cron、Datadog）
3. 中央管理を容易にしたい（ScaledObject）

差分を確認するツールをAIに実装依頼 LinearのIssueにCodex Agentをアサイン（実装が進む）

• 親Issue本文に書く大事なもの：CODEX ENV ID
• マニフェスト生成とマージによる運用のボトルネックが発生

AIレビューに社内ガイドラインを引用する

Notionのガイドラインをマークダウンで落としてリポジトリにコミットする

• ガイドラインの指摘が減って、他の議論に集中できた
• 人間のレビュアーが減るわけではない

AIで問い合わせ・トラブルシューティング

肌感で定型的な問い合わせが多い Linear Asks（テンプレートは必要）でLinearのIssueにAIエージェントが確認するフローを構築

入社・退社管理は自動化できた

Prodcution Readiness CheckをAIに任せてみる

• AIでなくてもできることは自動化しておく（CIなど）
• AIがわかりやすく作る

課題

• 状態の制御が難しい
• テスト環境を占有できない
• API制限・課金による繰り返し実行が困難

モック利用で解決することが多い

• 状態の制御ができる
• テスト専用環境で利用できる
• API制限や課金の影響を受けない

一般的なモックの限界

• ステートレスなリクエスト・レスポンスモデルに止まる
• ステートフルな処理や複雑な挙動は再現が難しい
  • リクエスト間で引き継ぐ処理を扱えない（例：認証認可など
  • リクエスト送信と複数ステップ処理(モックがリクエストを送る側になれない)

ソリューション

方針：ステートフルモック＋リクエスト送信＋シナリオ駆動で統合テストを再設計する

• ステートフルモック＝モックサーバで状態を保持し、実システムに近づける
• リクエスト送信による多段フロー再現＝モックサーバがリクエスト送信
• シナリオ駆動設計
  • 通信の流れをYAML定義したテストの構造化
  • =テストケースの定義だけでなく、モックサーバの挙動もYAMLで表現する
  • YAMLを元にテストコードが自動生成される
• CI/CD統合はDockerベースで完全自動実行可能な構成へ

2026の情報セキュリティ10大脅威にAIのリスクが選出 サービスが大丈夫か聞かれた時に、脅威モデリングしてみよう、という話

用語整理

リスク

リスク＝脅威x脆弱性x資産

• リスクは脆弱性が脅威に晒されて初めて顕在化する
• 脆弱性がある≠リスク

リスク管理

ベースライン型アプローチ

• 脆弱性に焦点を当てて、ベースラインとなるガイドラインを使って、課題を洗い出し、リスクを把握し、対策するアプローチ
• 準拠するためのリソースと脆弱性管理のコストが膨大
• 項目や指摘事項をクリアして、どんな脅威を防ぐことができるか観点抜けがち
• セキュリティ担当者以外がどうやって脅威を防いでいるかわかりづらい

脅威ベースアプローチ

• 脅威に焦点を当てるアプローチ

IPAではベースラインと脅威ベースのバランスをとって対策することが大事

脅威モデリング

Threat Modeling Manifest

• アジャイル宣言に影響受けてできたものらしい
• セキュリティに関心を持つ人なら、誰でも良い
• 4つの質問
  • 何を作っているか：システムの可視化と参加者の決定
  • 何がうまくいかないか：脅威の特定
  • それに対して何をするか：リスク分析と対策
  • 十分な仕事ができているか：検証振り返り

STRIDE-LM

7つの脅威カテゴリ。 参考：https://developers.cyberagent.co.jp/blog/archives/40939/（発表内の参照ではなく筆者の検索メモ）

具体的なステップ

1. DFD、システム構成図を描いて、関係者を広く集める
   • 図を書く意義
     • 何を作っているか、全体像が見える
     • コードじゃないので、エンジニア以外も参加できる
   • DFD：システムの概要を俯瞰するのに良い
     • 信頼境界：信頼できる（内部のもの）と外部の線引き
     • 要素が少なく表現力も制限されるが、その分シンプル
   • まずは事業レベルのモデリング（DFD）を描く
     • 外部エンティティに焦点を当てて、システムを１プロセスとして描く
     • 個々のエンティティやネットワークでの脅威が見えやすくなる
   • DFD:level0
     • データの流れに着目して、Context Diagramから分解・詳細化する
   • DFD:level1
     • level0で得たデータの流れからブレークダウン
       • リソースの詳細化
       • 信頼境界を引く
     • 脅威の入り口が見えてくる
2. 脅威を洗い出して、カテゴライズ
   • STRIDE-LP per Element（要素ごとに適用すべきカテゴリ）をチェックシートのように使ってカテゴライズ
   • それでもよくわからない場合→MITRE ATT&CKを見る
     • 攻撃グループがよく利用する戦術・技術・手順のナレッジベース
     • https://attack.mitre.org/
3. リスクの３軸で点数をつける
   • ３段階評価にして、合計値を見るとか
   • 定性的ではあるけど、リスクをスコアリングできる