人の努力に頼らないセキュリティをエンジニアリングする在り方 / An approach to engineering security that does not rely on human effort

サポーターズ Colab Conf 2026 秋:
https://supporterz-seminar.connpass.com/event/406430/
ICT本部 セキュリティ・チーム チームマネージャー @co3k

AIエージェントが開発・攻撃の在り方も変えつつある今、「人が頑張る」こと、つまり人の注意や努力に頼る守り方には限界があり、事業の進み方も「把握できる範囲」に合わせることになりがちです。CARTAは、セキュリティそのものをエンジニアリングし、事業を伸ばしながらやるべきことを全部やる道を選びました。その担い手として定義した「Applied Security Engineer」の在り方と実際の取り組み、そして専門領域に閉じないセキュリティ人材のキャリアについてお話しします。

1. サポーターズ CoLab Conf 2026 人の努力に頼らないセキュリティを エンジニアリングする在り方 Applied Security Engineer セキュリティをフルサイクルエンジニアリングする在り⽅ 株式会社CARTA HOLDINGS ICT 本部 セキュリティチーム 海⽼原 昂輔｜2026年11⽉14⽇
2. この秋、国内で公表されたセキュリティの事案（公表組織ごとの延べ件数。誤送信‧紛失なども含む） 1,274件 2026年9⽉1⽇〜11⽉13⽇ 10⽉下旬からは平⽇1⽇40件前後 出典：株式会社キーコネクト「国内セキュリティインシデント 2026年9⽉〜11⽉」（件数は11/13 17時時点、画⾯は9/1〜10/9）
3. 不安な人？
4. 大丈夫、セキュリティは エンジニアリングできる
5. 事業に価値を届ける仕組みを作ってきたなら、 事業を守る仕組みも 同じやり方で作れる
6. 略歴 2005 Web アプリ開発を始める。バグハンター活動も 2014 VOYAGE GROUP（現 CARTA HOLDINGS）⼊社 2017 Lighthouse Studio 創業、CTO（神ゲー攻略などの開発、運⽤） 2024 CTO 室 スタッフエンジニア、AI Lab リーダー 2025 ICT 本部 (コーポレート IT 部⾨) を兼任 2026.10 稼働をセキュリティへ寄せる CARTA 内の役割 ICT 本部 セキュリティチーム マネージャー（今⽇はこの帽⼦！） ICT 本部 セキュリティチーム マネージャー 海⽼原 昂輔 (@co3k) ※ セキュリティエンジニアではありません CTO 室 スタッフエンジニア CARTA AI Lab リーダー Lighthouse Studio 取締役 CTO（神ゲー攻略）
7. 開発のかたわらで⾒つけて報告してきた脆弱性（2006〜2018年） XSS 2012 XSS 2017 XSS 2018 Redmine Slack Kibela XSS 2012 XXE 2013 XXE 2013 WP プラグイン OpenPNE 3 Apache Shindig XXE 2013 CSRF PHP OpenID Library YOURLS CVE-2012-0327 CVE-2012-1245 CVE CVE-2013-4334 XSS 2010 CVE-2013-4335 ⼀覧は co3k.org/pages/reported-vulnerabilities.html で公開しています SQLi ほか 2006〜2018 ほか多数（約40件） CVE-2013-4295 CVE-2013-4701 CVE-2013-4333
8. （念のため、もう⼀度） ※ セキュリティエンジニアではありません 自認はソフトウェアエンジニアです
9. なぜ、いまなのか これまで かけ忘れ 空き巣は1軒ずつ見て回っていた 鍵をかけ忘れた家があっても、たまたま⾒つからずに済んでいた
10. なぜ、いまなのか いま 町じゅうのドアを一度に試せる かけ忘れた鍵が見つかりやすくなった
11. なぜ、いまなのか 攻撃の道具もエージェントに エージェント 外から探す ⼊って、また探す 例：ARTEX（出典：CrowdStrike、2026-10-07。韓国の⾦融機関を狙った活動での利⽤を報告） さらに奥へ 到達
12. 何が変わったのか 攻撃が魔法のように高度になったのではなく、 サボっていたところを探す手間が下がった これまで 探す⼿間 いま 探す⼿間 割に合わず⾒逃されてきたかけ忘れも、今は安く探される
13. 「正しく怖がるために」で全社に伝えたこと 当たり前をしっかりやれば、 ほとんどは守れる 攻撃は魔法ではない。だから、正しく怖がる
14. 当たり前をちゃんとやろうとすると 「当たり前」の範囲は広く、どれも深い 認証・認可 クラウドの設定 依存ライブラリ 秘密情報の管理 脆弱性診断 監視・検知 インシデント対応 ルールと監査 どれにも深い専⾨性が要る だから、仕事は専門ごとに分かれていった
15. 当たり前をちゃんとやろうとすると 「セキュリティエンジニア」の分業 脆弱性診断士 SOC アナリスト CSIRT / PSIRT 抜け⽳を⾒つける 攻撃の兆しを⾒張る 事故が起きたら対応する GRC セキュリティ コンサルタント ルールを作って確かめる 対策を助⾔する
16. 当たり前をちゃんとやろうとすると 「セキュリティ」に対する分業 この分業モデルの構造的な特徴は、 仕事の出⼝が「ハンドオフ（受け渡し）」になっていることです。 指摘‧報告 （対応は相⼿任せ） ここで仕事が途切れる セキュリティ専門家 ソフトウェアエンジニア
17. 当たり前をちゃんとやろうとすると 分業型セキュリティ（ハンドオフ）の課題 指摘する側 開発・運用の現実から距離がある 現場では実⾏が難しい正論を、「正しいから」と積み上げてしまう 「診断で High が出ています。リリースまでに全件、修正を」 「このライブラリに CVE が出ました。今日中に更新を」 セキュリティ 専⾨家 「シークレットは、定期的にローテーションしてください」
18. 当たり前をちゃんとやろうとすると 分業型セキュリティ（ハンドオフ）の課題 受け取る側 多くの場合、セキュリティの専門家ではない 攻撃の⽂脈を知らないまま「影響はない」と判断して、リスクを⾒逃してしまう 「管理画面なので、外からは届かないはずです」 「その機能は使っていないので、影響ないはずです」 「検証環境なので、本番のデータは無いはずです」 ソフトウェア エンジニア
19. 当たり前をちゃんとやろうとすると 分業型セキュリティ（ハンドオフ）の課題 分業による立場の違いは距離を生む 「診断で High が出ています。 リリースまでに全件、修正を」 「管理画面なので、 外からは届かないはずです」 距離 指摘する側 セキュリティ 専⾨家 受け取る側 ソフトウェア エンジニア 相手を動かすには、攻撃が成立すると証明するしかない
20. 私たちはすでに⽴ち向かい⽅を知っている どこかで身に覚えがありませんか？ 分業で⽴場と利害が離れ、コミュニケーションのコストが上がる構造
21. 私たちはすでに⽴ち向かい⽅を知っている そう、DevOps が生まれる前の状況 分業で⽴場と利害が離れ、コミュニケーションのコストが上がる それに⽴ち向かうために、DevOps の考え⽅が⽣まれた
22. 分業化された役割が⽣む弊害（Netflix の例、模式図） 役割を専門化すると、引き継ぎが生まれる 引き継ぎ Design → 開発 Develop → 引き継ぎ Test テスト → 引き継ぎ 引き継ぎ → → Deploy リリース Operate 運⽤ 出典：Fisher-Ogden, Burrell, Marsh「Full Cycle Developers at Netflix — Operate What You Build」Netflix Tech Blog, 2018 邦訳：「Netflixにおけるフルサイクル開発者―開発したものが運⽤する」CARTA TECH BLOG, 2019 Support サポート
23. フルサイクル開発とは 開発したものが 運用する 価値を届けるまでの⼀周が責任範囲。 共通の課題を解くツールが真ん中で⽀える 参考：CARTA TECH BLOG「CARTAとフルサイクル開発者」（2023）
24. CARTA でフルサイクルエンジニアをやってきた コードを書くことだけでなく、顧客への価値提供が仕事 領域横断によってライフサイクル全体を担う 専門性を否定するものではない
25. いまは専門性を直接活かして、 事業価値も直接つくれる AI によってより⼿軽に、より強⼒に実現できるようになった。 しかも仕組みにすればスケールする。
26. 名前のない働き⽅は⽬指せないし、探せないし、求⼈票にも書けない。 だから名前を作った Applied Security Engineer セキュリティの専⾨性を事業に“適⽤”する
27. セキュリティのフルサイクル これが Applied Security Engineer 設計への介入 原則・仕組み更新 ガードレール実装 事業が作るもの 学習 観測 「事業が作るもの」を真ん中に、 サイクルのすべてにオーナシップを持つ セキュリティエンジニア 対応・復旧 検知
28. ⾔い換えると Applied Security Engineer セキュリティの専門性を事業の文脈に適用し、 指摘ではなく実装と運用によって成果を出す エンジニア
29. Applied Security Engineer の合⾔葉 Secure by engineering to scale our business 事業を伸ばすために、エンジニアリングで守る ⼈の注意や努⼒ではなく、エンジニアリング（再現可能な⽅法）で守る。 守る⽬的は事業を⽌めることではなく、事業を伸ばすこと。
30. Applied Security Engineer 5つの要素
31. Applied Security Engineer 5つの要素 1 ガードレール 事業をドライブさせるセキュリティ 2 可観測性 見えないリスクこそ最大のリスクである 3 脅威適応 脅威の変化に適応した動的な防御体制 4 完璧な防御よりも事業を止めない力を レジリエンス 5 ⼈的攻撃⾯ 人間は防御の最終層であり、最大の攻撃面である
32. Applied Security Engineer 5つの要素 1 ガードレール 事業をドライブさせるセキュリティ セキュリティは検問所ではなくガードレール 事業が進む道と守るべき境界をはっきりさせ、 その内側では最⼤の速度で⾛れるようにする
33. Applied Security Engineer 5つの要素 2 可観測性 見えないリスクこそ最大のリスクである 「見える」とは検知できている状態のこと 後半に登場する EASM はこの原則を軸に
34. Applied Security Engineer 5つの要素 3 脅威適応 脅威の変化に適応した動的な防御体制 攻撃者の能力は時間とともに必ず上がる ある時点の攻撃者に合わせた「対策」で満足すれば、 将来の侵害を許すことになる
35. Applied Security Engineer 5つの要素 4 レジリエンス 完璧な防御よりも事業を止めない力を 突破されたら何が起きるかを常に想定する 検知・封じ込め・復旧に投資する
36. Applied Security Engineer 5つの要素 5 ⼈的攻撃⾯ 人間は防御の最終層であり、 最大の攻撃面である 「人間の判断」の正しさに依存しない防御を 設計の基本に
37. 10⽉から1か⽉、ソフトウェアエンジニアとして セキュリティを Applied Security Engineer としてガチってみた。
38. Applied Security Engineer として、1か⽉ガチってみた CARTA では Claude Code を全員使える 普段の開発で AI 利⽤ コードを書くのも、調べるのも AI と共に (e.g. Fable / Mythos) AI に「任せきり」は危険 リスク：誤検知（偽陽性）が多い コスト：無駄が多く、処理が遅い 自分たちのコードの抜け穴も AI に探させている 結果：直すべき問題を見落とす AI 利活用は前提。その先がエンジニアの勝負どころ
39. Applied Security Engineer として、1か⽉ガチってみた ちょうどいいものが世の中にない だから、自分たちで作った 今⽇はこの話 世の中のスキャナは渡されたリストを検査するだけ EASM 入口そのものを外から探す ほかにも 脆弱性診断 誤検知の振り分け トリアージ 資産の台帳 毎⽇の変更を 広く確かめる 確かめた指摘だけを 届ける 警告を⾃分で調べて 判断する 根拠つきで、 ⼈⼿を介さず出す 事業にセキュリティを組み込む ちょうどいいエンジニアリングの需要は山ほどある
40. Applied Security Engineer として、1か⽉ガチってみた 攻撃者と同じ目線で外から自社を見る 露出管理（EASM）：外から⾒える⼊⼝を、攻撃者と同じ⽬線で棚卸しし続けること ARTEX 資産を集めて → 探索する 自社 → 攻撃者 EASM LLM で 計画を練る → → 攻撃する → 結果を積んで ↺ 練り直す → ↺ 攻撃者と同じ目線を持たないと スタートラインにも立てない
41. Applied Security Engineer として、1か⽉ガチってみた 攻撃者と同じ目線で外から自社を見る 露出管理（EASM）：外から⾒える⼊⼝を、攻撃者と同じ⽬線で棚卸しし続けること 攻撃者 ARTEX 自社 EASM 資産を集めて → 探索する ⼊⼝を 集める → LLM で 計画を練る → 攻撃する → 結果を積んで ↺ 練り直す 安全な⽅法で 怪しいものを 台帳に積んで ↺ → → 確かめる 選ぶ 育てる ここが違う 作りはほぼ同じ。決定的に違うのは3つ目
42. EASM でいちばん⼤事な設計判断 攻撃能力は持たない 「まだ作っていない」のではなく「攻撃しない」と決めた
43. Applied Security Engineer として、1か⽉ガチってみた 攻撃能力があると確かめられるものもある ログインの奥にある認可の穴 侵入が本当に成立するか 侵入されたときの影響の大きさ 見えないものとして記録し、診断や個別の対応で補う ⼤事なことは⾒えないものを「ないもの」として扱わない
44. Applied Security Engineer として、1か⽉ガチってみた 攻撃能力を持たない代わりに外と内を行き来できる 防御側は内部の関係者に会いに行ける 「外から見える入口があります。 一緒に確かめませんか」 Applied Security Engineer 「使っていないはずです。 一緒に見てみましょう」 ソフトウェア エンジニア 直すところまでが責任範囲なら、攻撃して証明しなくていい
45. Applied Security Engineer として、1か⽉ガチってみた 攻撃能力を「持たない」と決められた3つの材料 セキュリティ 事業 技術 攻撃の手口を 知っている 直すところまでが 責任範囲 安全に確かめる 仕組みを作れる 判断の材料を複数持つから、「何をしないか」を決められる セキュリティの専⾨性だけでなく、 ソフトウェアエンジニアリングの知識が活きる
46. 1か⽉やってみて ソフトウェアエンジニアとしての 向き合い方で 十分に戦える セキュリティに銀の弾丸はない。 だから、いつものやり⽅でひとつずつ潰す。 セキュリティも⾃分たちの仕事だと、覚悟を持って背負う。
47. Applied Security Engineer はどんな⼈に向いているのか？ 一言で言えば、欲張りな人 次々に現れる新しい技術をキャッチアップしながら、 システムの「つなぎ⽬」や、責任の所在が曖昧な部分を、 深い知識で探索することを楽しめる⼈
48. 町じゅうのドアの話に戻ると 町じゅうのドアが試される時代に、 一人で全部守らなくていい。 「事業をセキュリティエンジニアリング」する チームで⽴ち向かえる場所がある
49. 大丈夫、セキュリティは エンジニアリングできる
50. 企業情報 CARTAとは
51. 02 01 事 企 業 紹 概 情 介 要 報 為したいこと 1億超の CARTAが培ってきた データ × 実効⼒ CARTA HOLDINGS Inc. ⽇本‧世界のマーケティングを進化させていく。 未開拓の地を切り開く挑戦者
52. 02 01 事 企 業 紹 情 介 報 1億超の ビジネスモデル全体図 多⾯的なドコモデータ 広告主 CARTA HOLDINGS Inc. クライ アント 広 告 の 企 画 ‧ 運 ⽤ 等 コ ン サ ル や D X ⽀ 援 等 ネット広告 運⽤型TV CM データ/AI/DX SNS/EC プロダクション 電通の総合提案⼒ メ デ ィ ア 収 益 最 ⼤ 化 ⽀ 援 メディア
53. 事業紹介 BUSINESS
54. Webメディア / YoutubeなどのWeb広告配信「Zucks」 生活者 1億 を超える ID 20年超の専任実績と 圧倒的なデータ解像度 広告オークション 50 APP msで処理 ※機械学習処理含む メディア ドコモデータなどを利活用した統合的なマーケ・広告配信
55. 社内 AI スペシャリストチーム「AI Lab」 AI 特殊部隊 事業に入り込み AIで価値を出すスペシャリストチーム
56. 矜持 「事業をエンジニアリングする」技術者 事業に貢献する「価値」を⽣み出すエンジニア
57. 事業をセキュリティエンジニアリングする Applied Security Engineer になるなら へ ありがとうございました 続きはカジュアル⾯談でお話ししましょう 求⼈はこちら