「小さく壊す」は許し「一発アウト」は防ぐ Agentic AI 時代のプラットフォームが備えるべきガードレールを再考する

小さく壊すは許し、一発アウトは防ぐ
エージェンティックAI時代のプラットフォームが備えるべき
ガードレールを再興するといったようなタイトルで
私の方から発表させていただきます
よろしくお願いします
ありがとうございます
嬉しいです
まずは発表の前にざっくりプロフィールの本なんですけど
名前は岡麦と言います
フルネームです
結構珍しいと思うので
この機会に覚えて帰ってもらえたら
嬉しいなと思います
経歴としては2022年度に新卒入者として
サイバーエージェントに入って
そのまま株式会社CAMといったところに出向して
現在のロールとしては
SREチームのマネージャー兼
プラットフォームエンジニアリングチームの
メンバーとして活動していると
いったような形になっています
セッションに入る前に少し会社紹介の方も
させていただければなと思っているんですけど
株式会社CAMといった会社は
2025年で設立25周年を迎えるサイバーエージェントの中でも
最高産の会社となっております
なので歴史もあって数多くのサービスが存在していると
ここに書いてあるように20サービス以上を開発運用しているといったのが特徴になるかなと思います
もう一つ組織の大きな特徴としてエンジニアは約30名と
サービスに対してエンジニアの数少なくないって
結構皆さん思うと思うんですけど
そういうのが我々の特徴ですと
普通に考えてわかる通り
従来のフルスクラッチ型の開発だと
やはり20とかを超えるサービスを30人で運用して
なおかつ新規の開発もしていくといったようなことは難しいので
2019年頃からプラットフォームエンジニアリングという言葉が流行る前から
弊社ではプラットフォーム戦略であったりだとか
積み上げ式の開発と言われるようなサービスを
一から作るのではなくて
何個も何個も作っていけば
どんどんどんどんサービス開発のスピードが上がっていくような
戦略を取っていました
これがプラットフォームの概要というか構成図になるんですけど
開発チームAとかBとか
皆さんから見て左側にあるものですね
こういうのがチートポでいうストリームアラインドチームと言われていて
その下にプラットフォームエンジニアリングチームというのもあるんですけど
我々先ほども言ったようにサービス開発のスピードを
少人数でも早くやるために
決済だったりユーザー認証みたいな
コアな機能というのはマイクロサービスとして提供していて
それらを複数のマルチテナントなプラットフォームとして提供していると
そういったののメンテナンスであったり開発というのを
このプラットフォームエンジニアリングチームが
受け負っているというような形になっていますと
あともう一つのチームがSREというのもあって
これはプラットフォーム全体の信頼性
いわゆるマルチテナントなんで
サービスAが死んだときに
サービスB、C、Dと連鎖していかないような
ノイジーネイバー問題や対策であったりだとか
もちろん個別のサービスというのも
ユーザーに信頼性高く提供したいので
そういったのも最適化していくような側面もあるといったような形です
ここからちょっと今日話したいことを
もう少し話せればなと思うんですけど
昨今キーノートの発表とかでもあったと思うんですけど
AIとかAIエージェントが今年すごい普及していると
実際普及していると
なのでプラットフォームエンジニアリングの実践においても
優先度というのがすごく変わってきたなと僕自身感じています
その中の一つがガードレールかなと思っています
なので従来とは違ったアプローチというのも
必要になってくるかなと思うので
そういったものを弊社のプラットフォームエンジニアリングの実践の道のりを振り返りつつ
今年AIエージェント元年の今考えるべきガードレールを
実際の現場地点で話していけたらいいなと思っています
アジェンダとしてはこんな感じでちょっと長いんですけど
振り返ってAIエージェントの登場に変化みたいな
何を恐れているのか防ぎたいのかみたいなことを話していって
終わりに向かっていけたらいいなと思っています
はいじゃあまずは振り返りをさせてください
これまでの振り返りになります
私自身ちょっと入社したのが2022年なのでそこからの振り返りになるんですけど
弊社として大きなコンセプトとして
不必要な認知負荷というのを軽減して開発生産性を高める
社内ではもっとキャッチーにもっとシンプルに楽にとか言われてたりしたんですけど
そういったコンセプトがあったと
そういったのを実現することで
よりビジネスが加速している状態を目指そうねっていうのが
組織の方針としてあったと
具体的に何やってきたか
ここに書いてあるもの以外にもあるんですけど
例えばオブザーバビリティとか
そういったのもあるんですけど
具体的に何をやってきたかというと
例えばローカル開発環境の改善であれば
弊社ではKubernetesを採用していて
ローカルでもKubernetesを用いた開発を行っているので
サービス開発者がKubernetesを意識せずに開発できるようにも
Tiltっていうのを導入してみて
いわゆるインナーループコードを書く
ビルドするテストする調査する
みたいな一連のサイクルをより早く回すみたいな部分をしてもらうために
Tiltを活用してもらってたりだとか
あともちろんプラットフォームエンジニアリングっていう文脈で
よく言われると思うんですけど
開発者の生の声を聞いて
その上でしっかり改善しなさいと
そういったのもしっかり従って
定期的な勉強会だったりアンケートすることで
開発者の生の声をベースに
より自分たちのプラットフォームを作り上げていくと
いったようなこともやっていました
それに加えて先ほども言ったように
2019年頃からプラットフォーム戦略と
いったのを取り入れていて
だいぶアーリーアダプターだったなと思います
なので技術的不採っていうのも年々
溜まっていった側面もあるので
そういった側面も適宜返済していくと
いったようなこともやっていました
それに加えて
不採の返済だけじゃ面白くないし
楽しくないよねってことで
近年流行ってたIDP
内部開発者ポータルのバックステージを活用して
より開発者に全ての情報を集約した上で
提供できないか
インターフェースとしてバックステージを活用できないか
みたいなことも検証してたりしました
その上で
これも去年とかずっと流行ってる
今も流行ってるかなと思うんですけど
セルフサービス化っていう文脈で
より開発者が認知不可が高くない状態で
不可試験ができたりだとか
マニフェストも一から書くんじゃ大変だから
テンプレートを提供してとか
その上でGitOpsっていうのを整備することで
安全にインフラストラクチャを管理したりだとか
そういったようなこともやっていました
ここが最後になるんですけど
これもよく言われることだなと思うんですけど
プラットフォームとか
独自の抽象化レイヤーを増やすと
やっぱり誰でもすぐプラットフォームを利用できないというか
オンボーディングコストが大きくなるみたいな文脈もあるので
そういったのも改善するために
オンボーディングドキュメント継続的に見直したりだとか
そういったようなこともしていました
一方で後回しにされがちだったものがあるのも
事実だなと思います
これは我々視点から見たときに
後回しにされがちだったものですね
それがここでゼロトラスト的思考な
アーキテクチャの構築と紹介してるんですけど
いわゆるどのレイヤーも
信頼せずにセキュリティを監査していくだとか
セキュリティの対策を組み込んでいく
ただともに組み込んでいくみたいな部分は
ちょっと優先の高くはできてなかったかなと思いますと
なんで後回しにされがちだったのかなっていう面で言うと
やっぱり大企業みたいにすごいエンジニアのリソースがいっぱいあって
開発にすごくコースを避けるといったようなわけでもない
さっき言ったように20以上のサービスを30人とか
そういったようなエンジニアの数で
運用を改善していかなくちゃいけないってなると
いわゆる守りのアプローチと
今回はしてもらってるんですけど
そういったアプローチより攻めのアプローチ
例えばバックステージを試してみるとか
そういったものに重点が置かれてきたといったのが背景としてあるかなと思います
でもここまで振り返りをちょっとまとめさせてもらうと
今までって僕たちはセルフサービス化とか
トレンドに沿ったいわゆる攻めのアプローチをしてきたかなと思います
一方で先ほども言ったようにエンジニアリソースがすごく多いわけではないので
様々な内情 リソースだけではないんですけど
守りのアプローチっていうのは後回しにされがちだった
というのもあるかなと思います
ここまで振り返った中で
今年AIエージェントがすごく普及して変化もあったなと思います
今ってAIエージェントにこれやってお願いする時代だと僕は思っていて
どういうことかっていうと
コードの記述
これはちょっとDevinにスラックでコード書いてくださいみたいなのを
お願いしている例なんですけど
皆さんもクロードコードとか
いろんなものにコードの記述やってくださいみたいな
いろんなフォーマットがあると思うんですけど
お願いしてやってもらってると
一方でコードがどんどんAIエージェントに書かれると
コードレビューが大変になるじゃん
みたいな話もあると思うんですけど
そういうのもAIエージェントに任せている
これもあれですね
Devinを使って
GitHub PRをDevinにレビューしてもらっているような感じになって
コードレビューでもAIエージェントを使うと
でももっともっと先に行くと
弊社ではK8SをGitOpsみたいな文脈で管理していて
あとサービス特性として
ファンクラブサイトっていうのを複数ホストしているので
例えばECとかチケット販売の時に
すごい100倍とかトラフィックが跳ねる時があると
そういった時は手動でサーバー増強って言ったら
どうしてもやる必要があるんですけど
そういったものも自然言語で
スラックからDevinにお願いすることが可能になっていると
さらに弊社のこれも特徴かなと思うんですけど
SREチームっていうのがあるので
いわゆるサーバー増強が適切だったかみたいな
キャパシティプランニングみたいなことも
これまでやってるんですけど
そういったものもDevinに任せて
これちょっと100%の精度ではないです
ただ60%ぐらいの精度で
今回の増強が適切だったかとか
逆にこの辺メトリックスちょっと怪しいかもね
みたいなのをまとめさせるといったようなこともやっていますと
じゃあもっともっと大きな話をすると
開発フローっていうレベルでも
AIとかAIエージェントがめちゃめちゃ登場してて
弊社で言うとノートブックLMといったものに
いわゆるビジネスの仕様だったりだとか
コードに滲み出ないようなYを詰め込んで
それをもとにGitHub Issueのひな形を
ノートブックLMに書いてもらうと
そのひな形をGitHub Issue
そのひな形をもとにGitHub Issueを作って
この例だとDevinスラッシュインプルメント
っていうラベルを付けてるんですけど
それを付与したら裏側で実装が開始されると
例えば自分がミーティング中に
イシューを立てて
ラベル付与したら裏側では回ってて
ミーティング終わったらコードレビューができるみたいな
そういったような開発フローも浸透してきてると
ここまで見てもらうと分かる通り
どのレイヤーにも開発運用
どこでもAIエージェントがいると
今までいろんなことを
攻めのアプローチとしてやってきたんですけど
どんな指摘より圧倒的に
もう測るまでもなく開発生産性が上がったなと思ってます
一方で不安要素もあるかなと思ってます
やっぱり不確実性っていう部分ですよね
最近だとAIエージェントが
RM-RFを実行しそうになった
だとかちょっと暴走したとか
いろんな話があると思うんですけど
ある一定の不確実性っていうのがあるっていうのも事実だと
でもここまでまとめてみると
AIエージェントの登場によって
今まで僕が紹介してきたような
攻めのアプローチと比べて
解説させてめちゃくちゃ上がったよねっていうのは
事実としてあると思います
一方で僕たちだけかもしれないんですけど
守りのアプローチっていうのを
ちょっと十分じゃなかったなっていう側面から
やっぱりAIの不確実性により
サービスの継続を怯えかすような一発アウト
一発アウトっていうのは
例えば情報漏洩とか
情報漏洩によって
IP元から信頼を失ってしまい
君たちに開発任せられないよねって言われちゃうとか
そういったようなリスクがあるのではないかと
そういったものをプラットフォームを育ててきた
育てていく人たちが漠然と抱えてるんじゃないかっていうのが
今の現状かなと僕は思っています
今まで話してきたことって結構漠然としてたと思ってて
僕が実際に現場視点から見たときに
何を恐れてるのか防ぎたいのかっていう部分なんですけど
僕の場合だと何も見ずに
パッと考えて出てきたのがこんな感じでしたと
大きく分けるといわゆるコードの品質
もう一つが内部システムの不適切なコード
これらがいわゆる一発リスクにつながるんじゃないか
みたいな考えたときに
一発アウトリスクにつながるんじゃないかって考えたときに
これは人によって変わるかなと思うんですけど
僕はバグと脆弱性 環境の破壊
サプライチェーン攻撃みたいな部分を
特に恐れてるなと個人的には思いましたと
じゃあなんでっていう部分なんですけど
僕たちはプラットフォームをマルチテナントで提供してるので
いわゆる個人決済とか
そういった共通機能に大きなバグが入ると
複数のテナントが影響を受けますと
それこそ20サービス以上が同時に障害が発生してしまうと
いったようなことが考えられると
これはすごく恐ろしいし避けたいことだと
一方で今どんな対策ができてるのかなっていう話なんですけど
僕たち2019年から長くプラットフォーム運用開発してきてるんで
やはり美人職の方も自分たちがどういう開発をしてるのかっていうのを理解してくれてるので
動作確認の文化っていうのは他の企業の方と比べるとだいぶ情勢できてるかなと思いますと
もちろんCICDとかテストもやってると
またいわゆる共通機能っていうのはリポジトリを分割して権限管理を厳格したりだとか
そういったような対策もしていると
もう一個心配してるのがいわゆる脆弱性だと
有名な脆弱性に気づかずコード本番化した結果
これも情報漏洩とかしちゃうんじゃないかみたいな話ですね
これに対する対策今どんな感じのことやってるかっていうと
ソナーキューブとか使って静的解析したりだとか
あとは脆弱性が入っちゃう前提だと
なのでWAFを最初から入れておくといったようなことであったりだとか
弊社と文化として脆弱性診断っていうのを大きな機能リリースであったりだとか
サービスをリリースするときに行っているので
そういったものも文化として存在すると
これ三つ目の恐れてる部分なんですけど
いわゆるAIエージェントの誤操作権限の渡しすぎによって
自由なリソースがデータが削除されちゃうんじゃないかみたいな
その結果としてサービスが復旧困難になっちゃうんじゃないかみたいな
これも大きな一つのリスクとしてあるかなと思います
そこに対する対策として僕たちはこのようなことをやっていて
いわゆる最小権限の徹底ですね
あとは権限を一時的に渡す
永続的な権限ではなく24時間とか1週間とかで切れるような権限の付与であったりだとか
もちろん削除されてしまう前提でリストアできる状態でのバックアップの保持
またはバックアップっていうのを同じGoogleクラウドのプロジェクトではなく別の分離されたプロジェクトに置くとか分離というのもやっていると
もう一つこれ最後にちょっと僕が恐れてるなっていう部分なんですけど
いわゆるサプライチェーン攻撃ですよね
さっき言ったみたいに使用書をAIと一緒に書いて
HowをAIエージェントで全てやらせるパターンですよ
フルスクラッチでAIにコードを書かせると
そうするとハルシネーションとかでいわゆる存在しないパッケージをインストールしてしまって
それが実はマルウェア含んでてみたいな部分を恐れてると
じゃあここに対する対策今どんな感じかなってなると
さっきも言ったように最小軽減の徹底みたいな
いわゆる情報漏洩とかしないように
開発者にはそこまで強い権限を与えていなかったりだとか
もしくは異常動作
内部システムがおかしな動作をしてるとこを検知するために
データドックシームを入れてたりだとか
GitHub Actionsもそんな簡単にサードパーティーのワークフローは使えないようにしてたりだとか
一応対策はしてると
ただちょっとここを見て思ったのは
やっぱりシステム的なものってよりかはちょっと弱めというか
なんか対策あんまできてないのかなとはちょっと思いましたと
でもここまで僕の本当の漠然とした不安っていうのを言語化したときに
意外となんか全く何もしてないわけではなかったなと思いますと
でも僕は不安を感じると
それはなぜなのかっていうのを考えたときに
僕の中ではやっぱりセキュリティのシフトレフトといった
いわゆる脆弱性診断の前
なんならローカル開発の時点から脆弱性にもっと気づいていけない方とか
サプライチェーン攻撃される前提で
もう少し例えばデブコンテナを導入したりだとか
そういった守りのアプローチみたいな
部分がちょっと後手に回りがちだったなと
その結果としてエージェントが来た段階で
課題っていうのが浮き彫りになってしまった結果
僕は不安を抱えているんだなというような結論になりましたと
なのでこういったもののガードレールを整えていけば
いいじゃんっていう話になるかもしれないんですけど
ここでちょっと今回のセッションのタイトルにも入れている
小さ怖さを許すといった
ここが結構キーポイントでもあるんですけど
じゃあなんで小さ怖さを許すのかといった部分なんですけど
さっきも言ったようにAIエージェントの登場によって
制約の重点ってすごく高まってきている
ガードレール大事だよねっていう話が
キーノートであったりだとか皆さん言っていると思うんですけど
一方で全ての事象を防げるのかと
そんなことはできないと思うし
何だろう闇雲にガードレールを増やすっていう行為は
これまで自分たちが頑張って
開発生産性を向上させてきたのに
逆に利便性を損なっちゃうんじゃないか
みたいな側面もあると思います
なので僕は大事だと思っているのは
小さく壊すことは
許容した上で
さっきほど言ったような
事業の継続を脅かすような
一発後対策を取っていくことが
大切なのかなと思っています
でもこれ前提なんですけど
これSREの発表とかでよく使われるような
エレガントパズルって有名な書籍の言いようなんですけど
障害のほとんどはデプロイによって
引き起こされると
AIとかAIエージェントによって
爆発的な開発生産性の向上したら
そりゃデプロイ増えるよねと
そしたら障害も起きやすくなるよねと
これも当たり前の話で
ただそんな中でも大きな
障害の発生頻度が増えたりだとか
障害頻度が増えた結果
会社が冷えすると
いったようなことを望んでいないというのも
事実かなと思います
じゃあどうするかっていうと
私たちこれまでプラットフォームエンジニアリングという取り組みで
いわゆる開発生産性を高めるみたいな取り組みを
してきたと思うんですけど
今度はAIエージェントに逆に調査を行えて
作業を移動できるようにしていくのが
大事なんじゃないのかなと思います
そういった取り組みを通して
小さく壊れる
壊れられるようにするみたいな取り組みも
プラットフォームエンジニアリングの取り組みの一つとして
より脚光を浴びていくのかなと
僕は思っていますと
AIエージェントに調査ができる状態
環境というのをプラットフォームエンジニアリングという
エンジニアリングを通して提供できれば
様々な部分で応用が効くなと思っていますと
今僕もまたちょっとうまくいく段階までいけてなくて
皆さんから見て右側の画像で
ちょっと試行錯誤しているような画像なんですけど
そういったことができるようになれば
例えばCIのエラーを自動で修正みたいな
定期的なキャパシティプランニングを自動でみたいな
こともできるようになっていくので
ここがすごく大事なポイントなのかなと思っていますと
ちょっと長くなっちゃっているので
ここまでの流れをざっくりまとめさせてもらうと
プラットフォームエンジニアリングでは
セルフサービス化など
いわゆる攻めのアプローチというのが
これまでは重要視されてきたかなと思っています
一方でAIエージェントの普及によって
不確実性の高い大量の作業というのが発生するので
漠然とした不安を感じる人が多くなって
いわゆるガードレールも重要視されるようになってきたかなと思います
そんな中で闇雲にガードレールを増やせばいいわけじゃなくて
これまで通り開発生産性とセキュリティとかガバナンスのバランスを取るために
利便性と制約のバランスは担保していく必要があると
そうしたいんだったらやっぱり小さく壊れるようにする
小さく壊すってことは許容できる状態にした上で
一発アウトを防げるような
必要最低限のガードレールを定義してやっていくのが大切かなと思います
ちょっと駆け足になるんですけど
これまでとこれからのガードレールというのをちょっと話していけたらなと思うんですけど
これまでのガードレールって
いろんなガードレールの提供の仕方があったと思うんですが
プラットフォームにセキュリティを組み込むパターンもあれば
ドキュメントを提供するパターン
そのドキュメントを提供して
開発者に準拠してもらうことで
ある一定の品質が保たれますよみたいなゴールデンパスの提供ですね
あとはこれらは別に提供すればいいだけじゃなくて
開発者が納得する形での合意形成を取る必要があったかなと思います
これが変わるかっていうと
僕は変わらないとは思ってますと
一方で変わっていくこともあるなと思ってて
それ何かっていうとやっぱり
不確実性の高い大量の作業が
高速に実行可能になってきていると
その中でどうしていけばいいかというと
先ほど紹介したようにちょっとドキュメントだけで
人間が従ってくれる前提の
やっぱり生前説のゴールデンパスと
ここで言わせてもらってるんですけど
それだけで不十分かなと
不確実性の高いAIエージェントが
必ず準拠してくれるとは限らない
クロードコードとかでも
クロード.mdに従ってくれないとか
よくあると思うんですけど
そういった状態が一発アウトを招くかもしれないので
これからよりシステム的なアプローチっていうのも
僕たち必要になってくるんじゃないかなと考えてます
それに加えて難しくなってくるなと思ってるのが
やはり利便性と制約っていった部分なんですけど
ここ自社のサービスで
防ぎたい本当に一発アウト言語化して
対策をより明確にしていかないと
闇雲にガードレールを増やすことになっちゃって
これまでの取り組みが無駄になるような
ちょっと開発生産性が下がっちゃうような
取り組みになっちゃうかもしれないなと思ってます
なので今までの延長線上ではない
開発文化から変えてくだったり
大きな改革っていうのも必要かもしれないなと
私は考えています
ここからちょっと実践事例の紹介をしたいなと思うんですけど
弊社では開発ツールキットを提供していますと
さっき言ったようにマイクロサービスとか
複数のサービスを開発してるんで
同じような作業を何回もしないように
一般的なベストプラクティスを提供するような
ツールキットをこれらのマイクロサービスだったり
サービスに提供していると
メリットとしてはフルスクラッチでの実装しないので
ガードレールといった側面から言うと
AIエージェントにさせないことが多いと
なので複数のサービスの必殺を保ちやすいかなと
一方でデメリットもあると
独自の抽象化レイヤーみたいなのを作ってるんで
AIエージェントに開発ツールキットの知識を
コンテキストと詰め込まないと
開発がうまく円滑に進まない
AIエージェントをうまく活用できない
みたいな文脈もあるので
最近ではMCPサーバーとかを用いて
コンテキストを詰め込むことにトライしてると
もう一個が
これもちょっと似たような感じなんですけど
コアとなる共通機能の分離といったようなこともやってますと
デメリットとしてはさっきと同じですね
品質を保ちやすいと
一方でデメリット
これも一緒なんですけど
コンテキストの問題は発生してると
あとはマイクロサービスあるあるは
やっぱり多少なりとも発生してるなと
いいようなことがあると
ここまで振り返ると
僕たちでは積み上げ式の開発といっている
いわゆるあまりAIエージェントに作業をさせない
サービス開発運用においてやることを減らしてきたっていうのが
結果としてAIエージェントの行動を抑制してると
その結果ガードレールとなってるんですけど
独自のレイヤー増やしたんで
コンテキストの詰め込みには苦労してると
いったようなのが
私たちの今の現状かなと思います
最後になんですけど
伝えたかったことはこの4つになります
まず1つが不安を漠然としたまま放置しないってことなんですけど
漠然とした不安を抱えてるだけだと
一発アウトの言語化等もできないし
その対策が十分かどうかも分からないと思うので
まずはそこの言語化ってのが大切になるかなと思ってます
その上で小さく壊れることは共有しようと
今日は伝えたいなと思ってて
デプロが増えたら障害も起きやすくなるのは当たり前だと
なので障害を起こさないことに執着するのではなくて
我々はプラットフォームエンジニアリーに行くという取り組みを通じて
小さく壊れるにはどうすればいいのかであったりだとか
開発者を卑弊させないための仕組みだったり
そういったものは何なのかみたいなことを
考えるのがいいかなと思ってます
さらにやっぱりAIエージェントの方が普及していくと
今後さらに守りのアプローチ
キーノートでもガイデットAIとか新しい言葉が出てきましたけど
そういったものも重視されてくると
ただHowに執着すると
やれることってこれから無限に出てきてしまうと思うので
組織で自分たちが本当に防ぎたいことは何なのかみたいな
言語化した上でそれをするために必要最小限のガードレールは
何なのかみたいなことをしっかり考えていくのが
利便性と制約のバランスを取り続けるコツなのかなと思ってます
もう一つこれが最後ですね
よりAIエージェントの登場によって不確実性の高い大量の作業が
実施可能になったのでゴールデンパスだったり
ドキュメントを提供するだけじゃ準拠しない可能性があると
なのでこれからはプラットフォーム自体にガードレールを組み込んでいく
これアプローチはいろいろあると思うんですけど
それこそシーナップとかサルサとか
いわゆるソフトウェアサプライチェーンのフレームワーク
ソフトウェアサプライチェーンを攻撃を防ぐためのフレームワークみたいな
部分なのを自分のプラットフォームに組み込んでいく
みたいなアプローチが今後は重要になってくるんじゃないかなと思います
すいません最後の方ちょっと駆け足でしたが
ご清聴ありがとうございました
はい発表ありがとうございました
それでは質疑応答の方移らせていただこうと思います
はい一つ目ですね
AIエージェントが調査できる環境を作る上での障壁は何ですか
また一発アウトを防ぐため
自分たちに必要なガードレール一覧を見つけるためのプロセスは
どうしたらいいと思いますか
そうですお願いします
そうですね
AIエージェントが調査できる環境を作る上での
今現状で感じている障壁でいうと
やっぱりデータドックとかでも最近MCPサーバーとか出てきたと思うんですけど
AIが扱いやすい形で情報を提供できるかどうかというのがすごく鍵だなと思ってます
なので僕としては今そこに一番障壁を感じていて
MCP以外でもAIにうまく自分たちが伝えたい
詰め込みたいコンテキストを伝える方法は何なのか
みたいなのは今後も探っていく必要があるかなと思います
もう一つが
そうですね自分たちに必要なガードレール一覧を見つけるために
どうしたらいいかという部分で言うと
これはかなり難しいなと思っていて
いわゆる外からの攻撃なのか内部システムなのかみたいな
そういった話もあると思っていて
これをやっていくためにはそうですね
僕はちょっとこの発表でも触れたんですけど
本当に防ぎたいことは何なのかみたいな部分をやっぱり熟考した上で
それで今対策は十分なのかみたいな部分と
あとは実際にそのHowを見つける
例えばツールを入れればいいんじゃないかって
入れてみたとしてもうまくいかない可能性もあるので
検証を早く回すためにはどうすればいいかみたいな
どちらかというと見つけるためのプロセスが大事というよりかは
見つけられるための組織体制だったり
開発体制何なのかみたいな部分の方が
僕は大切かなと思っていると感じですかね
はい ありがとうございます
続いての質問です
私の方からさせていただこうと思います
今回のテーマ一つである守りのアプローチ
一発だと防ぐガードレールについてなんですけど
小さく壊れることを強要していくということを紹介されていたと思うんですけど
特にセキュリティ観点での工夫を詳しく教えていただけますでしょうか
そうですね セキュリティ観点の工夫でいうと
先ほどもちょっと紹介したんですけど
データドックシームといったようなものを入れていたりだとか
データドックに組み込みでセキュリティ機能があるので
いわゆる一般的ではないアクセスとかを検知したらアラートを発砲するとか
そういったようなことはしているかなと思います
はい ありがとうございます
じゃあ次の質問ですね
小さく壊すの小さいはどのように定義されていらっしゃいますかとのことです
よろしくお願いします
そうですね これはちょっと僕の中での言語化になっちゃって申し訳ないんですけど
僕の中の小さいっていうのはいわゆるサービスの信頼を著しく下げない
例えばですけど今まで右肩上がりで1年目1億の売り上げ
2年目10億の売り上げ
じゃあ3年目で30億目指すぞみたいな時に
じゃあそれが10億に戻っちゃいましたみたいな
著しくビジネスに大打撃を与えるよねっていうのが大きい
逆に言えばじゃあ30億目指してたけど
じゃあそれがちょっと8割多数になっちゃいましたぐらいなのは
まあ許容できる範囲なのかなとは思ってるといったような感じですね
はい ありがとうございます
次応答の方はここで終わりにしようかなと思います
発表ありがとうございました
ありがとうございました