【登壇資料】 CCoE実践者コミュニティ関西で「AI時代のリスク管理はどうあるべきか考えてみる」というタイトルで登壇しました

【登壇資料】 CCoE実践者コミュニティ関西で「AI時代のリスク管理はどうあるべきか考えてみる」というタイトルで登壇しました

AIの組織利用が進む中、リスクゼロを目指さず組織として受容できるラインを探ることの重要性や、NIST AI RMFの活用方法などについてLTしました
2026.07.17

こんにちは、クラウド事業統括本部の荒平(@eiraces)です。

2026 年 7 月 16 日に開催された CCoE実践者コミュニティ関西 #9 にて「AI時代のリスク管理はどうあるべきか考えてみる」をテーマにお話させていただきました。

https://ccoekansai.connpass.com/event/396837/

セッションスライド

補足

CCoE / AI CoEに求められていることについては色々ある中で「安全にAIが使える環境が欲しい」というミッションが課されることが多い印象です。

ScreenShot 2026-07-16 at 20.02.47

AIを展開したは良いものの、AI利用によるリスクが顕現してきたという話が目立つようになりました。

image-20260716200511016

利用状況が取れていない(観測する仕組みがない)環境も少なくないと感じており、できる限り情報は取得するべきと考えています。

image-20260716200620106

NIST AI RMF(AI Risk Management Framework)のコア機能についても軽く触れました。
以下のブログに詳細を記載しましたので、併せて参照ください

https://dev.classmethod.jp/articles/understanding-nist-ai-rmf/

これは完全に私見ですが、リスクをゼロにすることは諦めたほうがいいと思っており、組織として受容できるラインを探ることになると思っています。
ベネフィットがデメリットを上回るのであれば、リスクを適切に周知した上で受け入れるのも選択肢だと感じます。

ScreenShot 2026-07-16 at 20.13.41

セキュリティ面の心配は尽きないのですが、組織に配る「お願い事」は追加のmdを配布することで解消できる場合があります。
このルールは厳密に管理しないほうがよく、厳密に制御したい場合は、Claudeならsettings.jsonに記載するなどガードレールに寄せます。

推奨やお願い事項(SHOULD)の例:
・作成するアプリケーションの種類に応じて、社内ガイドラインを参照してルールを確認する
・作成したアプリケーションは、オーナー情報やデータ送信先、処理内容を含めたREADMEを残す
・アーキテクチャの意思決定はADR(Architecture Decision Record)に記録する

ScreenShot 2026-07-16 at 20.18.03

このエントリが誰かの助けになれば幸いです。
それでは、クラウド事業本部 コンサルティング部の荒平がお送りしました!

参考

https://www.nist.gov/itl/ai-risk-management-framework

https://dev.classmethod.jp/articles/security-on-software-development-with-generative-ai/


そのCCoE、つくって終わりになっていませんか

ガバナンスのルールも組織ポリシーも、整えた直後はちゃんと機能する。でも運用が属人化すれば、CCoEはいつのまにか形だけに。ベンダー依存から内製へ踏み出すために、中の人として実行まで伴走する。立ち上げと定着の進め方を、無料資料にまとめました。

CCoE総合支援

CCoE立ち上げ資料をダウンロード

この記事をシェアする

関連記事