業務アプリを自社クラウドに置く設計｜権限・データの所在・個人情報

こんにちは、株式会社TIMEWELLの濱本 隆太です。

高額なSaaSを解約して、業務アプリを自前で持つという選択。このシリーズでは、その判断基準から、作ってよい業務の見分け方、5年総額の試算、解約と移行の段取りまでを書いてきました。5本目の今回は、最後に残る問いを扱います。作り直したアプリを、どこに置くかです。

結論を先に書きます。私の見立てでは、自前で持つと決めたなら、置き場所は自社が契約しているクラウドの環境、この記事でいう「自社テナント」にしたほうが動かしやすいケースが多いと考えています。社内のID基盤と権限をそろえられ、既存のデータとつなぎやすく、監査ログを自社で持てるからです。ただ、置き場所を変えると、個人情報の整理と運用の責任も一緒に動きます。国内リージョンを選べば済む話でもありません。情報システム部門、セキュリティや個人情報の担当、ISMS事務局の方に向けて、利点と負担の両方を一次情報に沿って書きます。そもそも解約すべきかの判断から読みたい方は、シリーズの判断基準の記事から入ってください。

マルチテナントのSaaSと自社テナントは、どこが違うのか

言葉の整理から始めます。クラウドの定義として広く引かれる米国立標準技術研究所（NIST）の SP 800-145 は、クラウドの特徴の一つに「リソースの共用（resource pooling）」を挙げ、事業者の計算資源は「マルチテナントモデル」で複数の利用者に提供される、と書いています¹。同じ文書はSaaSについて、利用者はネットワークやサーバ、OS、ストレージはもちろん、個々のアプリケーション機能も管理・制御しない（例外は、限られた利用者ごとの設定だけ）と定めています。SaaSの利用者が触れられるのは、ほぼ設定画面だけということです。

この記事でいう「自社テナント」は、自社が契約するクラウド基盤（AWS、Microsoft Azure、Google Cloud など）のアカウントの中に、業務アプリとデータを自社の資産として置く形を指します。クラウド基盤そのものはクラウド事業者の共有設備ですが、アプリの管理者も、データの持ち主も、権限を配る人も自社です。ベンダーが顧客ごとに専用の環境を用意する「シングルテナント型のSaaS」とも違います。専用の環境でも、運用しているのがベンダーなら、アプリとデータの鍵はベンダーの手元にあります。

SaaSを提供する側の設計指針に、AWSの Well-Architected「SaaS Lens」があります。全テナントで基盤を共有する形を「プール（pool）」、テナントごとに分ける形を「サイロ（silo）」と呼び、それぞれの長所と短所を並べた文書です²³。プール型の短所として挙げられているのは、他のテナントの負荷が自社に響く「ノイジーネイバー」、テナントごとの費用の把握の難しさ、障害の影響範囲の広さ（原文では、プール型の障害は「おそらくシステム内の全テナントに影響する」）、そしてコンプライアンスや規制の要件が資源の隔離を厳しく求める場面での抵抗です。サイロ型はその裏返しで、隔離の要件に応えやすく影響範囲も狭い一方、費用がかさみ、全テナントへの一斉更新がしにくくなります。SaaSを作る会社のための文書ですが、利用者の側から読むと、自分が使っているサービスが何を引き換えにしているのかが見えてきます。

観点	マルチテナントのSaaS	ベンダー専用環境のSaaS	自社テナント
基盤とアプリの運用者	ベンダー	ベンダー	自社（または自社が委ねた先）
アカウントと権限の管理	サービスごとの管理画面	サービスごとの管理画面	自社のID基盤にそろえられる
操作の記録（監査ログ）	出せる範囲と保存期間はベンダーが決める	同左	保存先と期間を自社で決める
仕様変更の時期	ベンダーが決める	交渉の余地が広がる	自社が決める
障害の影響範囲	他社と一緒に止まりうる	自社の環境に閉じやすい	自社の環境に閉じやすい
運用・監視・パッチの責任	大半をベンダーが持つ	大半をベンダーが持つ	自社に来る
費用の形	利用者数などに比例	割高になりやすい	クラウド利用料と運用の人件費

表の下の2行が、この記事の後半で扱う負担です。自社テナントは、上の5行で得をして、下の2行で払う構造だと考えてください。

自社テナントに置くと、何が動かしやすくなるのか

私が「動かしやすい」と言うとき、中身は4つあります。

1つ目は、ID基盤と権限をそろえられることです。SaaSを10個使っていれば、管理画面も権限の設計も10通りあります。入社、異動、退職のたびにそれぞれの画面でアカウントを直す作業が発生し、どこかで消し忘れが出ます。自社テナントなら、社内のID基盤と同じグループで権限を切れます。たとえばAWSの IAM Identity Center は、既存のIDプロバイダーをつなぎ、ディレクトリのユーザーとグループを同期できると説明しています⁴。異動が人事のデータに入れば、業務アプリの権限も同じ流れで変わるわけです。この一本化は、ISMSの内部監査でアクセス権の見直しを説明するときにも効いてきます。

2つ目は、既存のデータとつなぎやすいことです。見積の台帳、社内FAQ、申請の記録。こうしたデータが同じテナントの中にあれば、外部のAPIを経由せずにつなげます。SaaS同士をつなぐ場合、連携できる項目や回数はベンダーのAPIとプランに縛られがちで、上位のプランでないと取り出せないデータもあります。どの業務を自前にするかの見分け方はシリーズ2本目の記事で書きましたが、候補に挙がる業務ほど、他のデータとつながって初めて価値が出るものが多いと感じています。

3つ目は、監査ログを自社で持てることです。誰が、いつ、どのデータに何をしたか。SaaSでは、この記録をどこまで出せるか、何日残るかをベンダーが決めます。自社テナントなら、保存先と期間を自社で決められます。AWS CloudTrail は、利用者やロール、AWSのサービスが行った操作をイベントとして記録するサービスで、設定をしなくても見られるイベント履歴は、管理イベントの過去90日分です⁵。それより長く残したければ、自社で保存先を設定します。裏を返せば、何もしなければ90日で見えなくなるということで、ここは設計で決めておく項目の一つです。

4つ目は、ベンダーの仕様変更に振り回されにくくなることです。SaaSでは、画面の変更、機能の廃止、プランの組み替え、利用規約の改定が、ベンダーの都合の時期にやってきます。日本の民法は定型約款について、相手方の一般の利益に合う場合や、変更の必要性や相当性などに照らして合理的な場合には、個別の合意なしに内容を変更できると定めています（548条の4）⁶。法人向けSaaSの規約が定型約款に当たるかは個別の判断ですが、少なくとも「規約は相手が変えうるもの」という前提で契約を読んでおく必要はあります。自社テナントのアプリなら、変更の時期は自社が決めます。ただし、クラウド基盤の側にもランタイムの提供終了のような変更は来ます。振り回される相手が減るのであって、ゼロになるわけではありません。

4つとも、根っこは同じです。アプリとデータが、自社の他の仕組みと同じ場所にあること。SaaSをやめて作り直すなら、置き場所まで含めて設計したほうが作り直した意味が大きくなる、と私が考える理由はここにあります。

個人データは委託に当たるか。決め手は「誰が触れるか」

次に、個人情報の整理です。いちばん誤解されやすいのがここだと思います。

個人情報保護委員会の「ガイドラインQ&A」Q7-53は、クラウドサービスの利用が、本人の同意が必要な第三者提供や委託に当たるかどうかについて、判断の基準は「保存している電子データに個人データが含まれているかどうか」ではなく、「クラウドサービスを提供する事業者において個人データを取り扱うこととなっているのかどうか」だとしています⁷。取り扱わないこととなっている場合の例として挙げられているのは、契約条項で事業者がサーバに保存された個人データを取り扱わない旨が定められ、適切にアクセス制御を行っている場合などです。この場合は提供に当たらないので、本人の同意も、法25条に基づく委託先の監督も要りません。実務で「クラウド例外」と呼ばれることがある整理です。

ただし、続くQ7-54がくぎを刺しています。提供に当たらない場合でも、利用する事業者は「自ら果たすべき安全管理措置の一環として、適切な安全管理措置を講じる必要があります」⁸。委託先を監督する義務がなくなる代わりに、自社でやるべきことはそのまま残る、ということです。

では、SaaSはどうか。個人情報保護委員会は2024年3月25日、クラウドサービス提供事業者が個人情報取扱事業者に当たると判断した事案を受けて、注意喚起を出しています⁹。業務システムが不正アクセスを受け、多数の利用企業の顧客の従業員の個人データが暗号化された事案です。委員会が考慮した要素は3つありました。利用規約で、事業者が保守や運用上必要と判断した場合にデータを監視、分析、調査できるとされていたこと。事業者が保守用IDを持ち、利用者の個人データにアクセスできる状態で、技術的なアクセス制御がなかったこと。確認書を交わしたうえで、実際に個人データを取り扱っていたこと。そのうえで、合意した安全管理措置を規約や契約で「できるだけ客観的に明確化」し、定期的な報告などで確認するよう求めています。SaaSは、ベンダーがアプリを運用する以上、保守やサポートで利用者のデータに触れうる構造になりやすいのです。この注意喚起は、そのことを行政の判断として示したものだと私は読んでいます。

ここからが、自社テナントを考えるときに外せない点です。Q7-53の基準は「置き場所」ではなく「誰が個人データを取り扱うか」でした。そうであれば、自社テナントに置いても、開発や保守を担う外部の業者が本番の個人データに触れるなら、その業者との関係は委託として整理するのが筋です。Q&Aがこの場面を直接書いているわけではなく、Q7-53の基準と注意喚起の考慮要素を当てはめた私の解釈ですが、保守用のIDで本番データを見られる外部の業者は、注意喚起の事案とよく似た立ち位置にあります。当社のようなFDE（Forward Deployed Engineer、顧客の現場に入って開発する技術者）が保守に入る場合も、例外ではありません。

構成	外部の事業者がデータに触れるか	整理の方向（一般論）	自社に残ること
マルチテナントのSaaS	保守やサポートで触れうる	委託に当たることが多い	委託先の監督（法25条）と、契約での明確化
自社テナントで、社内の人だけが運用	クラウド基盤の事業者は、取り扱わない契約とアクセス制御	提供にも委託にも当たらない整理がありうる（Q7-53）	自社の安全管理措置（Q7-54）
自社テナントで、外部の業者が本番データを扱って保守	触れる	委託として扱う	委託先の監督と、アクセスの記録
自社テナントで、外部の業者は伏せたデータだけで開発し、本番の権限を持たない	触れない設計にする	委託に当たらない構成にできる可能性	権限設計の維持と、その証跡

この整理には、2026年の法改正も関わってきます。2026年7月10日に成立し、7月17日に公布された個人情報保護法の改正は、個人情報の取扱いの委託を受けた事業者に、委託を受けた業務の遂行に必要な範囲を超えて取り扱ってはならない義務を明文で課します¹⁰¹¹。あわせて、委託先が取扱いの方法を自ら決めないケース（委託元の指示どおりに機械的に処理するだけの場合など）では、委託契約で取扱いの方法の全部に合意し、委託元が状況を把握するための措置（漏えいを知ったら速やかに報告する、など）に合意すれば、委託先としての義務の適用を原則として免除する仕組みも入ります。ただし、必要な範囲を超えて取り扱わない義務と安全管理の義務は残ります。施行は公布から2年以内で、細部は政令と委員会規則で詰めている最中です。保守のように業者側の判断が入る作業がこの免除の対象になるかは、規則の整備を待って確かめる必要があります。

それでも方向ははっきりしています。委託契約に「何を、どの方法で扱うか」「状況をどう把握するか」を書く重みが増す、ということです。自社テナントに外部の保守業者を入れるなら、この書き方を今のうちから契約に入れておくと、施行のときに慌てずに済むはずです。

以上は一般論として書いています。個別の構成が委託に当たるかどうかは、自社の法務や専門家と確認してください。

国内リージョンを選んでも、確かめることは残る

「国内リージョンに置けば安心」という言い方をよく耳にします。半分は正しく、半分は誤解を生む言い方だと私は考えています。

正しい半分から書きます。クラウドでは、データを置く場所を国や地域の単位で選べます。NISTの定義も、利用者は資源の正確な位置を知らないのが普通だが、国、州、データセンターといった上位の単位では指定できる場合がある、と書いています¹。AWSには日本に、東京（アベイラビリティゾーン4つ）と大阪（同3つ）のリージョンがあります¹²。

誤解を生む半分は、個人情報保護委員会のQ10-25にあります¹³。外国にある事業者のクラウドを使う場合、事業者が個人データを取り扱わないこととなっていても、利用する企業は「外国において個人データを取り扱うこととなるため、当該外国の個人情報の保護に関する制度等を把握した上で、安全管理措置を講じる必要があります」。そして回答は「日本国内に所在するサーバに個人データが保存される場合においても同様です」と続きます。さらに、安全管理のために講じた措置として、クラウド事業者が所在する外国の名称と、サーバが所在する外国の名称を明らかにし、講じた措置の内容を本人の知り得る状態に置く必要がある、としています。外国のサーバに保存すること自体は、事業者が取り扱わない整理なら外国にある第三者への提供（法28条）には当たりませんが、外国の制度を把握する必要はやはり残ります（Q12-3）¹⁴。

東京リージョンを選んでも、クラウド事業者が外国の会社なら、その国の制度を把握する作業は消えません。リージョンの選択で変わるのは、主に公表内容のうち「サーバの所在国」の欄です。国内に置いたから説明は要らない、とはならないのです。

生成AIを組み込む場合は、もう一段あります。データの保存場所と、AIが推論を処理する場所は別だからです。たとえばAWSの Bedrock には、推論のリクエストを複数のリージョンに振り分ける機能があり、米国やEUといった特定の地理的範囲に限るプロファイルと、世界中の商用リージョンに振り分けるグローバルなプロファイルを選べます¹⁵。AWSの説明では、データの所在に関する要件があるなら地理的な範囲を選び、グローバルは地理的な制約がない代わりにおよそ10%安くなる、とされています。保存は東京でも、推論がどこで処理されるかは設定次第ということです。

では、どう設計すればいいのか。私は、リージョンを最初から一つに決め打ちせず、要件に応じて選べる設計にしておくことを勧めています。国内での処理が契約や業界の規程で求められるデータには、国内の範囲で処理する設定を。そうでないデータには、精度と費用の釣り合うモデルと処理場所を。どちらを選んだかは記録して、本人への公表事項や社内の台帳と合わせておきます。当社のFDEも、処理リージョンを一律には限定せず、この考え方で組んでいます。

リージョンより先に確かめてほしいのは、入力したデータがモデルの学習に使われないかどうかです。当社は、顧客のデータを学習に使わないことが利用規約、契約、設定のいずれかで確かめられるサービスとモデルだけを選び、何を根拠にしたかを記録しています。確かめる先は、クラウド事業者やモデル提供者自身の記述です。たとえばAWSは Bedrock のFAQで、Bedrockへの入力と出力を、AWSも外部のモデル提供者もモデルの学習に使わないと明記しています¹⁶。こうした記述を選定の根拠として台帳に残しておくと、監査のときの説明が短くなります。

運用の責任は自社に来る。先に設計で決めること

ここまで利点を多めに書いてきたので、ここからは払うものの話です。

クラウドの責任分担は、AWSの「責任共有モデル」がわかりやすい整理です¹⁷。AWSは「クラウドのセキュリティ」、つまりハードウェア、ソフトウェア、ネットワーク、施設を守る責任を持ち、利用者は「クラウドにおけるセキュリティ」を持ちます。利用者の責任の範囲は、選んだサービスによって変わります。仮想サーバ（Amazon EC2）のようなIaaSを選べば、ゲストOSの更新やセキュリティパッチ、その上のアプリケーション、ファイアウォールの設定までが利用者の責任です。SaaSのときはベンダーが引き受けていた仕事が、自社テナントに移した瞬間に自社の仕事になる、と考えておくのが安全です。

仕事	SaaSのとき	自社テナントのとき	負担を減らす手
OSやミドルウェアのパッチ	ベンダー	自社	マネージドサービスやサーバーレスを選び、パッチの対象そのものを減らす
監視と障害対応	ベンダー	自社	監視する項目と連絡の順番を最初に決め、夜間の扱いを明確にする
バックアップと復旧	ベンダー（範囲は規約次第）	自社	取るだけで終わらせず、復旧の試験日を年間の予定に入れる
IDと権限の棚卸し	サービスごとに実施	自社のID基盤でまとめて実施	棚卸しの周期をISMSの内部監査とそろえる
監査ログの保管	ベンダーが出せる範囲	自社	保存先、保存期間、閲覧できる人を決める
アプリのコードの脆弱性	ベンダー	自社	レビューと自動検査を開発の流れに組み込む
データの削除	解約時にベンダーが削除	自社	保存期間と削除の手順を設計書に書く

ISMS事務局の方には、管理策の対応も見てほしいところです。JIS Q 27001:2023（ISO/IEC 27001:2022）で新しく加わった11の管理策には、「5.23 クラウドサービスの利用における情報セキュリティ」「8.10 情報の削除」「8.16 監視活動」「8.28 セキュリティに配慮したコーディング」が含まれています¹⁸。SaaSを使っていたころ、5.23の中心は「SaaSをどう選び、どう使うか」でした。自社テナントに移すと、5.23の対象はクラウド基盤の利用に変わり、そこに8.16の監視と8.28のコーディングが自社の仕事として乗ってきます。適用宣言書の見直しも要るかもしれません。ISMSの全体像はISMS入門の記事にまとめています。

8.28は、生成AIでコードを書く今、重さを増しています。スタンフォード大学の研究者らが2023年のACM CCSで発表した利用者調査では、AIアシスタントを使えた参加者は、使えなかった参加者より安全でないコードを書き、しかも自分のコードは安全だと考えやすかった、と報告されています¹⁹。当時のモデルでの結果なので今の道具にそのまま当てはまるとは限りません。それでも、AIが書いたコードを人がレビューする手順を、速さを理由に省かないほうがいいと私は考えています。

8.10の削除は、移行のときにも顔を出します。解約したSaaSに残ったデータが消えたことを確かめる作業と、新しいアプリで保存期間を過ぎたデータを消す仕組みは、別々に要ります。前者の段取りは解約と移行の実務の記事に、運用の人件費まで含めた費用の比べ方は5年総額の試算の記事に書きました。自社テナントの運用費を見積もらずに「SaaSより安い」と判断してしまうのが、いちばん避けたい失敗です。

当社のFDEでできること

ここまでの話を、当社のFDEがどう引き受けているかを書きます。FDEは、顧客の現場に入り、業務を観察しながら動くものを作る技術者です。SaaSの解約と内製化は、FDEで実践できる仕事だと当社は考えています。サービスの全体像はFDEのサービスページにまとめています。

最初にやるのは、置き場所を決める前の棚卸しです。どのSaaSを解約して自前にするか。その業務のデータがどこから来てどこへ行くか。個人データがどこに含まれるか。ここを書き出してから設計に入ります。

次に、自社テナントの設計です。アカウントの分け方、社内のID基盤との連携、権限の型、監査ログの保存先と期間、バックアップと復旧の試験までを決めます。リージョンは要件に応じて選べるようにし、国内での処理が必要なデータとそうでないデータを分けて記録します。生成AIを組み込む場合は、先に書いたとおり、学習に使われないことを確かめられるサービスとモデルだけを選び、その根拠を残します。

開発は、個人情報などを伏せたデータで進めます。本番の業務システムに書き込む機能は、権限、実行前のシミュレーション、重要な判断での人の確認、監査記録の4つの条件がそろうまで載せません。当社が本番の個人データに触れる保守を担う必要がある場合は、委託に当たる前提で、取扱いの範囲、アクセスの方法と記録、漏えい時の報告を契約に書きます。当社はISO/IEC 27001の認証を取得しています（登録範囲は、AIテクノロジーを活用したSaaSプロダクトの企画・開発・提供）。

期間は45日から90日で区切ります。終わる条件は、貴社のチームだけで運用できる状態になっていることです。パッチの手順、権限の棚卸し、復旧の試験を、貴社の担当者が自分で回せるところまでを期間に含めます。どこまでを自社でやり、どこから外に頼るかの分け方はAIの内製化の分界の記事でも書いています。

受託開発との違い

受託開発でも、自社テナントにアプリを作ることはできます。違いは、工数の扱いと、学びの行き先と、終わり方です。

受託開発では、工数は売上です。保守が長く続くほど売上が立つので、運用がベンダーに残る設計は、ベンダーにとって自然な選択になります。その結果、自社テナントに置いたはずのアプリが、実際には外部の保守業者しか触れない状態になり、委託先の監督が延々と続きます。これでは、SaaSへの依存を、別の相手への依存に付け替えただけです。

当社のFDEは、工数を投資として扱います。顧客ごとの現場の工数が減っていくことを目標にし、貴社のチームが自走した時点で契約を終えます。他社でも使える共通の仕組みは当社の製品に返して次の顧客の初日から使い、貴社だけの設定と業務のデータは貴社のものとして残します。置き場所が自社テナントであることは、この終わり方と相性がいいのです。アプリもデータも最初から貴社の環境にあるので、当社が抜けるときに持ち出すものがありません。FDEとほかの支援の違いはFDEとAI伴走支援の比較記事で詳しく書きました。

当社の実践と限界

正直に書きます。自社テナントは、すべての会社に勧められる置き場所ではありません。

運用を担う人がいない会社には、勧めにくいのが実情です。上の表に並べた仕事は、作ったあと毎月発生します。社内に運用を回せる人がいない、あるいは運用を委ねる先を決められないなら、SaaSを続けるか、ベンダーが運用する専用環境のほうが合う場合があります。この判断は、初回の相談で率直にお伝えします。

当社が保守を続ける構成を選べば、委託の関係も続きます。監督の手間は貴社に残ります。当社は自走を終了条件にしていますが、夜間の障害対応のように、社内だけでは回しにくい仕事が残ることもあるでしょう。その場合は、範囲を限った保守を別の契約として相談させてください。その契約でも、取扱いの範囲を明確にします。

処理リージョンは一律には限定していません。国内での処理が必須の案件は、個別の契約で取り決め、費用に反映します。「当社に頼めば自動的に国内で処理される」と受け取られないよう、ここは最初に確認します。

当社は法律事務所ではありません。委託に当たるかどうか、外国の制度をどこまで把握すべきかの最終判断は、貴社の法務や専門家に委ねます。当社が用意できるのは、判断に必要な構成図、アクセスの経路、記録です。ISO/IEC 27001の登録範囲も上に書いたとおりで、貴社のテナントで行う個別の作業まで認証が及ぶかのような言い方はしません。

最後に容量です。小さな会社なので、同時に入れる現場の数には限りがあります。

まとめ

自前で持つと決めた業務アプリは、自社テナントに置くと動かしやすくなるケースが多い、というのが私の見立てです。社内のID基盤と権限をそろえ、既存のデータとつなぎ、監査ログを自社で持ち、仕様変更の時期を自社で決められるからです。

その代わりに、2つのことを引き受けます。一つは個人情報の整理です。委託に当たるかは置き場所ではなく「誰が個人データを取り扱うか」で決まります。開発や保守の外部業者が本番データに触れる構成なら委託として扱い、触れない構成にするなら権限の設計と証跡で裏付けます。国内リージョンを選んでも、外国の事業者のクラウドなら、外国の制度の把握は残ります。もう一つは運用の責任で、パッチ、監視、バックアップ、削除がそのまま自社の仕事になります。

月曜日に一つだけやるとしたら、解約を考えているSaaSについて「ベンダー側の誰が、どのIDで、自社のデータに触れうるのか」を契約と規約で確かめてみてください。答えがはっきりしないなら、それ自体が自社テナントを検討する理由の一つになります。

自社テナントの設計と、そこへの移行をFDEで進めたい方は、FDEのサービスページをご覧いただくか、FDEの個別相談でお話ししましょう。シリーズを最初から読む方は、判断基準の記事へどうぞ。

Footnotes

1. NIST Special Publication 800-145, The NIST Definition of Cloud Computing（NIST、2011年9月）。resource pooling、SaaS、private cloud の定義は同文書による（筆者訳） ↩ ↩²

2. Pool isolation（AWS Well-Architected, SaaS Lens）。プール型の長所と短所（Noisy neighbor、Tenant cost tracking、Increased scope of impact、Compliance pushback）は同ページによる（筆者訳） ↩

3. Silo isolation（AWS Well-Architected, SaaS Lens） ↩

4. What is IAM Identity Center?（AWS IAM Identity Center User Guide） ↩

5. What Is AWS CloudTrail?（AWS CloudTrail User Guide）。イベント履歴が管理イベントの過去90日分であることは同ページによる ↩

6. 民法（明治二十九年法律第八十九号）第548条の4（定型約款の変更）。e-Gov法令検索 ↩

7. 「個人情報の保護に関する法律についてのガイドライン」に関するQ&A Q7-53（個人情報保護委員会） ↩

8. 同 Q7-54（個人情報保護委員会） ↩

9. クラウドサービス提供事業者が個人情報保護法上の個人情報取扱事業者に該当する場合の留意点について（注意喚起）（個人情報保護委員会、2024年3月25日） ↩

10. 個人情報保護法等の一部を改正する法律について（個人情報保護委員会事務局、2026年7月）。委託先に対する規律の見直しは12ページ。改正後の条文は第30条の3。関連資料の一覧は令和８年 改正個人情報保護法 ↩

11. 個人情報の保護に関する法律の一部を改正する法律の成立を受けた個人情報保護委員会の今後の取組について（個人情報保護委員会事務局、2026年7月31日）。2026年7月10日成立、7月17日公布の記載は同資料による ↩

12. AWS Regions（AWS Global Infrastructure documentation）。ap-northeast-1（東京）のアベイラビリティゾーンは4、ap-northeast-3（大阪）は3（2026年9月29日確認） ↩

13. 「個人情報の保護に関する法律についてのガイドライン」に関するQ&A Q10-25（個人情報保護委員会、令和3年9月追加） ↩

14. 同 Q12-3（個人情報保護委員会、令和3年9月更新） ↩

15. Route model inference requests across AWS Regions with cross-Region inference（Amazon Bedrock User Guide）。地理的プロファイルとグローバルプロファイルの違い、グローバルでおよそ10%安くなる点は同ページによる（2026年9月29日確認） ↩

16. Amazon Bedrock FAQs（AWS）。入力と出力をモデルの学習に使わない旨は同ページのセキュリティの項による（2026年9月29日確認） ↩

17. Shared Responsibility Model（AWS） ↩

18. ISMSユーザーズガイド JIS Q 27001:2023（ISO/IEC 27001:2022）対応 JIP-ISMS111-4.0（一般財団法人日本情報経済社会推進協会、2025年3月31日）。追加された11の管理策は74ページの表A-2による ↩

19. Neil Perry, Megha Srivastava, Deepak Kumar, Dan Boneh, "Do Users Write More Insecure Code with AI Assistants?"（arXiv:2211.03622、ACM CCS 2023） ↩