AIを導入しても、誰が判断し、誰が見守るのかが曖昧なままでは、安心して使い続けられません。
AWSのAI導入フレームワーク「CAF-AI」を読む後編では、ガバナンス・プラットフォーム・セキュリティ・運用の4つの観点を見ます。
前編の「何を目指し、どう組織を動かすか」から、「どう形にして、使い続けるか」へ。私たちの現場にも重なる話です。
（※2026年10月23日時点で確認した公開資料に基づきます。CAF-AIは2024年2月更新の文書で、AWSは歴史的参考資料と位置づけています。）
今回も医療田さんと機械屋さんの会話でどうぞ。
＝＝＝＝＝＝
医療田：
ねえ機械屋さん。CAF-AIの後半、お願いします。
前回は、AIを入れるには、目的と言葉と文化をそろえるのが大事、って話だったよね。
機械屋：
はい。CAF-AIは、組織がAIから価値を生み出すために、考えるべきことを整理した枠組みでした。
前編では、全体像と進め方、それから「ビジネス」「人材」を見ました。
今日は残りの4つです。先に並べますね。
・ガバナンス：何を認め、誰が責任を持つかを決める
・プラットフォーム：AIを作り、使うための土台を整える
・セキュリティ：データとAIのシステムを守る
・運用：動き出したAIを見守り、問題に対応する
医療田：
技術寄りだと思ってたけど、「誰が」という話が多そうだね。
機械屋：
そうなんです。技術と、組織の仕事をつないで読んでみましょう。
● ガバナンス ― お金もデータも、担当を曖昧にしない
機械屋：
ガバナンスとは、組織の取り組みを、ルールと責任分担で統制することです。
CAF-AIは、複数の部門が参加するチームをつくり、目標やルールを決め、結果を見ながら見直すことを勧めています。
医療田：
IT部門だけで決めるんじゃないんだね。
機械屋：
はい。予算もその一つです。
AIの費用は、ずっと同じ調子で増えるとは限りません。
データを整える段階、小さく試す段階、本番で使えるものにする段階で、かかるお金が変わります。
CAF-AIは、その例を「ジグザグ」の費用として説明しています。
医療田：
私のダイエット中の体重グラフみたい。
機械屋：
え、ええ、、波を見込んでおく、という意味では＾＾；
ただし、必ず同じ順に上下するわけではありません。
データが整っていれば初期費用は小さく済むこともありますし、大きなAIを学習させれば、試すだけでも高くなることがあります。
本番では利用量によって費用が変わるので、「導入したら安く落ち着く」とも限りません。
医療田：
最初の見積もりだけで、安心しちゃいけないのね。
機械屋：
そうです。性能が少し上がることで、仕事の成果がどれくらい変わるのかも考えます。
それに、開発にお金をかけても、期待した成果が出るとは限りません。
そのリスクを含めて、どこまで投資するかを判断するわけです。
医療田：
うっく、、現実的。
機械屋：
データの扱いにも、同じように責任が要ります。
CAF-AIには、精度が頭打ちになったら、モデルの工夫だけでなく、データの質や量を見直す、という指摘があります。
医療田：
検査の精度が出ないときに、機械を替える前に、検体の取り方を見直す感じかな。
機械屋：
いいたとえですね。
記録を置いておくだけでなく、誰が手入れし、どこに何があり、どんな用途に使えるかを分かるようにする。
データを、責任者のいる「製品」のように扱う考え方です。
医療田：
カルテ庫の奥に眠っているだけでは、役に立たない、と。
機械屋：
そして、もう一つが「責任あるAI利用」です。
公平性やプライバシー、結果を説明できること、想定外の入力でも壊れにくいことなどを、企画から運用まで考えます。
CAF-AIは、人事・法務・調達なども参加するAIガバナンス委員会を提案しています。
医療田：
生成AIの心配ごとも、そこに入る？
機械屋：
はい。もっともらしい誤情報を出すハルシネーション、著作権の問題、データ漏えい、安全上の制限を突破されるジェイルブレイクなどです。
使うモデルの提供元が、こうした問題にどう取り組んでいるかも確認する。
よそのAIを使っていても、自分たちの仕事への影響は考える必要があります。
● プラットフォーム ― 作るところから、見直すところまで
機械屋：
次は、AIを開発して使うための土台、プラットフォームです。
CAF-AIは、これを3つの層で考えています。
・計算の層：AIの学習や、答えを出す処理に使うコンピューター
・AIサービスの層：モデルを学習・調整する仕組みや、既存のAIを使う仕組み
・利用の層：AIの結果を、画面や業務の中で実際に使う仕組み
医療田：
Vol.86の、クラウドの3つの層と同じ？
機械屋：
分ける目的が違います。
Vol.86は「どこまで借りるか」でした。こちらは、AIを動かす土台の役割分担です。
利用の層の例には、RAGも出てきます。
医療田：
ラグ、、なんだっけ。
機械屋：
検索拡張生成といって、AIが答える前に、社内資料などを検索し、その内容を参考に答える仕組みです。
資料を机に広げて答えるイメージですね。
医療田：
それなら、間違えなくなる？
機械屋：
誤りを減らす助けにはなりますが、なくなるわけではありません。
必要な資料を探せなかったり、見つけた資料に沿わない答えを出したりすることもあります。
AWSのRAG評価の解説でも、検索と回答の両方を確かめる必要があるとされています。
医療田：
資料持ち込み可でも、満点とは限らないんだね。。
機械屋：
はい。だから、人が関わる場所も設計します。
途中で人が確認して判断する形や、動いているAIを人が監督する形です。
専門用語では、それぞれヒューマン・イン・ザ・ループ、ヒューマン・オン・ザ・ループと呼びます。
医療田：
あ、Vol.68のエージェントの回で出てきた、HITLとHOTLだね。
途中で人が確認するか、動いているAIを見守って必要なときに介入するか、って話だった。
「人が見ています」で終わりじゃなく、どこで何を見るか、だね。
機械屋：
そうです。
さらに、作って終わりにしないためのMLOps、エムエルオプスという考え方があります。
モデルを作る、本番で使う、性能を見守る、必要に応じて更新する、という流れを、繰り返せる仕組みにすることです。
医療田：
性能が落ちたら、学習し直すとか？
機械屋：
それも一つです。CAF-AIには、その自動化も出てきます。
ただ、作り直したモデルを、そのまま本番に出せばいいわけではありません。
公開を承認する担当や評価の手順、元に戻せる版の管理までつなげて考えます。
既存のAIサービスを使う場合も、提供元のモデル変更で、自分たちの仕事への影響が変わらないかを見る必要がありますね。
医療田：
更新ボタンを押せば終わり、じゃないんだ。
機械屋：
はい。そして性能の数字だけでなく、仕事の成果に効いているかを見る。
使う人が迷わない画面や、困ったときの案内も含めて、土台を整えます。
● セキュリティ ― 入力・モデル・出力を守る
機械屋：
セキュリティでは、従来の対策に、AI特有の弱点への備えを加えます。
CAF-AIの整理は「入力・モデル・出力」の3か所です。
医療田：
どんな攻撃があるの？
機械屋：
たとえば、次のようなものです。
・プロンプトインジェクション：AIへの入力や、AIが読む文書に悪意ある指示を紛れ込ませる
・データポイズニング：学習に使うデータなどを汚して、判断をゆがめる
・モデル反転：モデルの出力などを手掛かりに、学習データに関する情報を推測する
医療田：
読ませる資料にも、罠があるんだ。。
機械屋：
はい。入力を点検し、資料の内容を、そのまま実行すべき命令として扱わないようにします。
ただ、区別する指示を書くだけで万全になるわけではありません。
AIに許す操作を必要最小限にし、出力も確認してから次の処理に渡す、と対策を重ねます。
医療田：
合鍵を持たせすぎないし、言われたことをそのまま実行もしない。
機械屋：
そうです。
どのデータをどのAIに使ってよいか、承認する担当も決めます。
モデルを提供する側の利用条件や、データの扱いも確認する。
さらに、何のモデルを使っていて、技術面と業務面の担当が誰なのかを、一覧にしておきます。
医療田：
何かあったとき、「詳しい人が休みなので分かりません」では困るもんね。
機械屋：
はい。正常だった状態に戻すために、モデルや関連するデータを管理しておくことも大切です。
ただし、元の版に戻せることと、漏えいした情報を取り戻せることは別です。
復旧の備えと、漏えいを防ぐ備えは、両方要ります。
● 運用 ― 「報告が0件」を安心の根拠にしない
機械屋：
最後は運用です。
CAF-AIは、AIの妥当性を確かめても、それであらゆる状況での正しさを保証できるわけではない、という姿勢を示しています。
だから、使い始めてからも観察を続けるんです。
医療田：
試験で合格したのに、本番ではうまくいかないこともある？
機械屋：
あります。学習時と実際に使うときで、データや処理に食い違いがあることを、トレーニング・サービング・スキューと呼びます。
それから、時間とともに入力されるデータや、その意味が変わる「ドリフト」もあります。
どちらも、性能が落ちる原因になり得ます。
医療田：
昨日までうまくいっていたから、今日も大丈夫、とは限らないのね。
機械屋：
はい。たとえば、次のような備えです。
・利用者が「この答えはおかしい」と報告できるようにする
・報告を受けて調べ、対応する担当を決める
・AIでは対応できないとき、人の確認や別の手順へ切り替えられるようにする
・特定の利用者だけに、困った結果が出ていないかを見る
この最後の点では、学習データに十分含まれていない人には、うまく働かない可能性も考えます。
医療田：
平均点がよくても、困っている人が見えなくなることがあるんだね。
機械屋：
そうです。そしてCAF-AIは、問題は起こり得ると考え、報告が一つもないなら、むしろ疑うよう促しています。
医療田：
それ、病院の医療安全と似てる。
インシデントレポートが0件でも、報告しにくいだけかもしれない、って。
機械屋：
はい。もちろん、0件だから問題が隠れている、と決めつけるわけではありません。
気づけるか、報告できるか、報告したら対応してもらえるかを確かめる、ということですね。
また、運用で見るのは答えの質だけではありません。
返事にかかる時間、利用が集中しても処理できる量、費用も見ます。
医療田：
正しい答えでも、診療が終わってから返ってきたら困るもんね。
機械屋：
その通りです。使う現場に必要な水準で、動き続けられることが大事なんです。
● 古い地図を、いまの現場で使うには
医療田：
前編でも言ってたけど、CAF-AIって、古い文書なんだよね。
機械屋：
初版は2023年5月22日、履歴にある更新は2024年2月13日です。
公式PDFには、歴史的参考資料であり、一部の内容やリンクが古い可能性があると明記されています。
医療田：
じゃあ、そのまま手順書にはできないね。
機械屋：
はい。個別の製品や設定は、新しい公式資料で調べ直す必要があります。
でも、「何を目指すか」「誰が決めるか」「どう守り、見直すか」という問いは、いまの現場でも使えます。
私は、細かい道順を写すより、見落としている場所を探す地図として読むのがよいと思います。
医療田：
6つの観点って、6つの別々の部署に配って終わり、でもなさそう。
機械屋：
まさにそうです。
プラットフォームにも人の判断が必要ですし、セキュリティや運用にも技術が必要です。
「技術の担当」と「組織の担当」を切り離すより、つながりを確認するための6つの観点なんですね。
● まとめ
機械屋：
後編の教訓をまとめましょうか：
・ガバナンス：目的・予算・データ・リスクについて、部門をまたいで判断と責任の仕組みをつくる
・プラットフォーム：計算・AIサービス・利用の3層を整え、人の確認や、評価・更新の流れまで設計する
・セキュリティ：入力・モデル・出力を守る。権限を絞り、使えるデータと担当を明らかにする
・運用：使い始めてからも、性能・費用・現場への影響を見守る。問題を報告し、対応できるようにする
・6つの観点は互いにつながっている。CAF-AIは検討漏れを探す地図として使い、具体的な実装は最新資料で確かめる
医療田：
前編で目的と言葉をそろえて、後編で、実際に回る仕組みにするんだね。
私の医局に当てはめるなら、「AIを何に使いたいか」と一緒に、「困ったら誰に相談するか」を話してみようかな。
機械屋：
いい第一歩だと思います＾＾
身近な用途を一つ選べば、必要な役割も具体的に考えやすくなりますね。
医療田：
、、相談先が全部、私にならないようにしないと。
機械屋：
ははは。。そこからもう、ガバナンスの出番ですね。
＝＝＝＝＝＝
● よくある質問（FAQ）
Q. ガバナンスとセキュリティは、どう違いますか？
A. ガバナンスは、目的・予算・リスクなどを含め、誰がどう判断するかを整える観点です。セキュリティは、データとシステムを守る観点です。両者は重なり、守るためのルールと技術をつなぐ必要があります。
Q. AIの費用は、運用が始まれば安くなりますか？
A. 一律には言えません。データの準備状況、モデルの規模、利用量や更新の頻度によって変わります。CAF-AIの「ジグザグ」は費用変動の例であり、決まった値動きの保証ではありません。
Q. RAGを使えば、誤回答はなくなりますか？
A. なくなりません。検索する資料が適切か、その資料に沿って答えているかを、それぞれ評価する必要があります。人が確認する場面や、答えられないときの扱いも設計します。
Q. 問題の報告が0件なら、安心してよいですか？
A. 件数だけでは判断できません。利用者が誤りに気づけるか、報告しやすいか、受け取った側が対応できるかも確かめます。報告と監視を組み合わせて、運用の状態を見ます。
Q. 古いCAF-AIを、いま読む意味はありますか？
A. 技術だけに偏らず、AI導入で考えるべきことを整理するために使えます。ただし、最新の製品仕様や設定手順を保証する資料ではありません。個別の実装は、新しい公式資料で確認します。
＝＝＝＝＝＝
●参考
AWS CAF-AI：全体像（日本語版）
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-caf-for-ai/aws-caf-for-ai.html
AWS CAF-AI：ガバナンス（費用、データ、リスク、責任あるAI利用）
AWS CAF-AI：プラットフォーム（3層、人の関与、AIのライフサイクル）
AWS CAF-AI：セキュリティ（入力・モデル・出力の保護と責任分担）
AWS CAF-AI：運用（問題報告、監視、性能と処理能力）
AWS CAF-AI：更新履歴
https://docs.aws.amazon.com/whitepapers/latest/aws-caf-for-ai/document-revisions.html
AWS CAF-AI：公式PDF（歴史的参考資料である旨の注記）
https://docs.aws.amazon.com/pdfs/whitepapers/latest/aws-caf-for-ai/aws-caf-for-ai.pdf
AWS：RAGアプリケーションの信頼性評価（2024年6月20日）
●関連記事
2分で読める生成AIのいま Vol.87 AWS CAF for AIを読む（前編）
https://note.com/41machida_ai/n/ndd6efeb01ca8
AIエージェントの「中身」を知る ― 構成と監督設計で読み解く、これからのAI（2分で読める生成AIのいま Vol.68）
https://note.com/41machida_ai/n/nab211b18ed89
2分で読める生成AIのいま Vol.86 【時事】クラウド一斉被害で学ぶ「層」と責任共有モデル
https://note.com/41machida_ai/n/n86dd5c9baec9
2分で読める生成AIのいま Vol.77 相次ぐ情報漏えいと「AIエージェント攻撃」説 ― 事実と推測の仕分け
https://note.com/41machida_ai/n/nc545b1f39ae9
●前編（Vol.87）と後編（Vol.88）は、マガジン「AI Business Strategist 学習ノート」にまとめる予定です。
●2分で読める「生成AIのいま」シリーズ。バックナンバーはブログからどうぞ！
https://www.youichimachida-ai.com/blog
――――――――――
町田洋一（医師・医学博士・経営管理学博士）
Youichi MACHIDA, MD, PhD, DBA
