AIにどこまで任せてよいかを決める

AIを使って試作品や社内ツールを作ろうとしているものの、どこまで任せてよいか迷っている人向けの記事です。すべてのコードを読めるようになる前に、失敗すると誰が困るのか、その失敗を自分たちで見つけて止め、元に戻せるのかを判断できる状態を目指します。個別の法令判断や、各サービスの安全性評価までは扱いません。プログラミングやウェブ開発の経験は前提にしません。

ここでいう黒箱とは、中の実装を細部まで説明できなくても使う部品やサービスです。AIツール、クラウド、マネージドサービス、フレームワーク、ライブラリも黒箱になり得ます。ただし、入出力、使うデータと権限、障害時の動き、責任者が分からないものは、そのまま採用しません。

内部実装を一から作れる必要はありません。まず、①期待する動作と受け入れ条件、②データ・権限・外部への作用と責任者、③検証・停止・復旧・移行の方法と相談先、の三つを自分の案件の言葉で説明できるか確認します。詳しい項目は、後半の「空欄の責任境界判断票」にまとめています。

本記事では、調査と草稿作成にAIを利用しました。編集責任はTsuzura編集部が負い、草稿作成とは分けた工程で、事実、出典、文体、法務をそれぞれ独立して確認しました。

まず、この3段階で決める

急いでいる場合は、次の表で仮の境界を決めます。これはTsuzura編集部の判断補助であり、法令、規格、認証、あらゆる案件に通用する安全基準ではありません。NISTのCSFとSSDFも、達成すべき結果や開発上の実務項目を示しますが、実装方法は組織や用途、リスクに応じ、すべての実務項目がすべての用途へ一律に当てはまるわけではないと説明しています（NIST CSF 2.0、NIST SSDF 1.1）。

段階	典型的な対象	把握しておくこと	黒箱として受け入れやすい範囲	次の判断
影響を限定できる	短命で、入力・保存・アカウントがなく、すぐ消せる試作	表示内容、公開先、費用上限、停止・削除方法、権利と公開時の確認	内部実装。ただし第三者スクリプトの読み込み先やドメインなど、外部との境界は把握する	条件を満たせば小さく始める
継続利用のための確認が必要	永続データを持つ非公開の社内ツール、アクセス解析やフォーム付きのランディングページ（LP）	更新や確認の基準にする元の記録（正本）、権限、保存、バックアップ、移行、規約、担当、インシデント時の連絡先	管理画面や基盤の内部実装。入出力、データ処理、障害時の動き、利用終了時の取り出し方は黒箱にしない	未確認を解消してから開始
専門家による確認が必要	アカウント機能を持つ公開サービス、決済・機微データを扱うサービス	認証・認可、プライバシー、セキュリティ、監視、復旧、契約、事業継続、専門家の判断記録	適格性を確認した提供事業者の内部実装。責任分担と利用側の設定は黒箱にしない	専門家による確認が終わるまで保留

段階は名前では決まりません。「試作」「社内用」と呼んでいても、顧客データの正本を書き換えるなら上の段階です。反対に、公開する短命LPでも、入力と第三者スクリプトをなくし、費用と削除方法を押さえれば、影響を狭くできます。

黒箱にしてよいのは、境界を説明できる部分だけ

黒箱にする前に、次の七条件を確認します。一つでも結論を変える未確認があれば、採用を保留します。

条件	説明できる状態
入力と出力	何を渡し、正常時と異常時に何が返るか。期待外の出力をどう検出するか
権限	誰・AI・サービスが、何を読み、書き、削除し、外部へ送れるか
データ処理	データの持ち主、正本、保存場所、保存期間、再利用、委託・再委託、削除条件
失敗時の動き	停止、誤動作、重複実行、部分成功、提供事業者の障害、料金超過のときに何が起きるか
更新と依存	バージョン、保守状況、脆弱性対応、規約・料金・仕様変更を誰が追うか
回復と退出	バックアップを戻せるか、データを取り出せるか、形式、移行先、終了後の消去、置換費用
責任者	導入、設定、確認、インシデント対応、更新、終了を決める人と引き継ぎ先

NIST CSF 2.0は、役割・責任・権限、ハードウェア・ソフトウェア・サービス・データ・外部提供者の把握に加え、外部提供者との契約、導入前確認、継続監視、インシデント、関係終了後の措置まで扱います。IPAのクラウドサービス安全利用の手引きも、扱う情報、停止影響、サービス水準（SLA）、管理者、認証、バックアップ、サポート、契約、終了時のデータ取得・形式・消去を確認項目にしています。

フレームワークやライブラリの内部を再実装する必要はありません。一方で、採用したものの一覧、確認したバージョン、保守と脆弱性対応、ライセンス、更新・置換を追う人は必要です。NIST SSDF 1.1は第三者部品を利用状況に照らしてレビューし、来歴と承認バージョン、更新時の移行を管理する実務項目を示しています。OWASPのソフトウェア供給網指針も、依存部品の一覧化、採用時の保守・テスト・脆弱性対応・ライセンス確認、採用後の継続監視を勧めています。

クラウドの共同責任を広げすぎない

クラウド提供事業者が使う「共同責任」は、その提供事業者と顧客のクラウド利用上の分担を説明するものです。たとえばAWSの公式指針では、AWSと顧客の範囲を分けたうえで、顧客側の責任は利用サービス、連携、適用法などにより変わり、データ分類、アクセス権限（IAM）、設定等が顧客側に残ると説明しています。

これはAWSクラウド固有の例です。同じ分担線を、別のクラウド、AIツール、SaaS（提供事業者が運用し、インターネット経由で利用するソフトウェアサービス）、外注先、フレームワークへそのまま当てはめることはできません。それぞれの仕様、契約、権限、データ処理、サポート終了と、自分たちの責任を確認します。

リスクを見極める10の質問

急ぐ場合は、まず「公開範囲」「データと権限」「失敗時に元へ戻す方法」の三つを確認してください。いずれかに結論を変える不明点があれば保留します。残りの項目は、開始前の詳しい確認に使います。点数は合計せず、一つの重大な不明点を、ほかの低リスク項目で相殺しません。

判断軸	確認する質問	詳しい説明や専門家の確認が必要になる例
公開範囲と利用者	インターネットから到達できるか。人数、社内外、子どもを含む利用者、管理者は誰か	不特定多数、他社、権限の異なる複数利用者
持続性と正本	データは残るか。どれが正本か。書き出し、移行、バックアップ、復旧を実際に試せるか	顧客・会計・在庫・契約等の正本、長期保存
機微性	個人、顧客、社内機密、認証情報、決済、健康等の規制対象になり得るデータを扱うか	漏えい・誤送信・目的外利用の影響が大きいデータ
アカウントと認可	ログイン後、誰が誰のデータを読み、変更、削除、管理できるか	複数の権限区分、組織境界、管理者、代理操作
可逆性と寿命	何分で戻せるか。何年使うか。作り直しやデータ移行、乗り換えにいくらかかるか	取り消せない、長期利用、独自形式、提供事業者への依存
使い続けられる度合い（可用性）と事業影響	止まると業務、売上、顧客、法定期限にどんな影響が出るか	営業停止、金銭損失、顧客対応、代替手段なし
外部提供事業者と依存先	誰が提供し、規約、料金、サービス水準（SLA）、再委託先、保守期限、提供停止を誰が追うか	多数の依存部品、頻繁な更新、終了予定サービス
副作用	書き込み、削除、メール・通知、公開、課金、発注、外部API（外部サービスをプログラムから呼び出す窓口）を使うか	一括変更、外部送信、重複実行、取り消せない処理
監視と引き継ぎ	異常を誰が見つけ、誰に連絡し、何を記録し、次の担当へどう渡すか	無人運用、夜間影響、担当者一人、ログなし
独立検証	AIの説明以外に、期待結果、差分、テスト、実データに近い検証、専門家による確認があるか	同じAIが実装・テスト・判定を完結、対象版が不明

アカウント付きサービスでは、ログインできるかどうかだけでなく、ログイン後に許される操作（認可）を確認します。OWASPの認可指針は、初期状態では操作を拒否し、フレームワークの初期設定に頼らず権限を明示したうえで、リクエストごとに権限を検証するよう勧めています。認証情報も、保管場所だけを確認して終わりではありません。OWASPの秘密情報管理指針が示すように、最小権限、生成、更新、無効化、期限、依存先、インシデント時の連絡先までを一つのライフサイクル（利用開始から終了まで）として扱います。

作るもの別に、責任範囲を比べる

次の比較もTsuzura編集部の指針です。「黒箱にできる」は、内部実装を細部まで説明しなくてよいという意味です。安全、適法、無事故を保証する表示ではありません。

例	黒箱として受け入れ得る範囲	自分たちが説明・検証する範囲	専門家による確認・保留の目安
使い捨てのキャンペーンLP、フォームなし	静的サイト生成ツールやホスティングの内部実装	表示内容、公開URL（ページのアドレス）、ドメインの所有者、第三者スクリプト、費用上限、削除、主要なブラウザーでの表示、キーボード操作、スマートフォン表示	権利不明の素材、組織の公開基準不明、第三者スクリプトの挙動不明なら保留
アクセス解析または問い合わせフォーム付きLP	利用条件を確認したアクセス解析・フォーム提供事業者の内部実装	取得項目、送信先、Cookie（ブラウザに保存される情報）等、プライバシー表示、迷惑送信対策、保存・削除、通知先、アクセス権	個人データの委託・国外移転・規約等を判断できなければ個人情報保護と法務の担当者へ相談
個人の端末内だけ一時ツール	OS（端末の基本ソフト）や端末内のフレームワークの内部実装	読むファイル、書くファイル、削除範囲、バックアップ、外部通信がないこと、終了方法	機密・認証情報を読む、広いファイル権限を使う、業務の正本を書き換えるなら段階を上げる
非公開だが永続データを持つ社内システム	データベースの内部機構や、提供事業者に運用を任せる基盤（マネージド基盤）の内部実装	正本、データ構造（スキーマ）、権限、変更履歴、バックアップ復元、移行、可用性、担当と引き継ぎ	顧客・従業員・機密データ、基幹業務、正本、代替なしならセキュリティ・プライバシー・業務責任者のレビュー
アカウント機能を持つ公開サービス	利用条件を確認した認証サービスやホスティングサービスの提供事業者の内部実装	アカウントの作成から削除まで、リクエストごとの認可、データ分離、不正利用対策、監視、インシデント、復旧、退会・書き出し	認可設計、公開サービスのセキュリティ、プライバシーを検証できる担当がいなければ開始しない
決済または機微データを扱う公開サービス	適格性を確認した決済サービスなどの提供事業者の内部実装	提供事業者との責任分担、契約、データの流れ、権限、ログ、返金・取消、インシデント、事業継続	決済、プライバシー、セキュリティ、適用規制を担当する専門家による確認が終わるまで保留

使い捨てLPにも残る責任

フォームのない短命LPは相対的に影響を限定しやすいだけで、責任がなくなるわけではありません。

ドメインの所有者、DNS（ドメイン名と接続先を対応させる仕組み）の変更権限、更新・失効時の扱い
第三者スクリプトが読み取れる情報と、外部から読み込む画像・フォント・スクリプト等の停止・改ざん時の影響
キーボード操作、文字拡大、コントラスト、代替テキスト、モバイル表示等のアクセシビリティ
画像、文章、フォント、ブランド表示の著作権・利用許諾
アクセス解析を置く場合の取得データ、プライバシー、保存・委託先
ホスティング、ドメイン、API、従量課金の費用上限と停止方法
公開時のセキュリティ、誤情報、古いキャンペーンの取り下げ

WCAG 2.2は、端末の種類を問わずウェブコンテンツを利用しやすくするための、検証可能な達成基準を示しています。評価方法については、W3Cのテスト規則解説が自動テストツールと手動テストの方法を扱っています。テスト規則への合格だけではWCAGへの適合を判定できず、人による追加確認が必要になる場合があると説明しています。また、OWASPのCSP指針は、入力欄のない完全な静的サイトでも、アクセス解析などの第三者JavaScriptを読み込むとリスクが残る例を挙げています。CSP（読み込める外部ファイルを制限する設定）とSRI（取得した外部ファイルの改ざんを検知する仕組み）は、多層防御の一部です。いずれも、一度の確認や一つの設定だけで、適合や安全が保証されるとはしていません。

外部のアクセス解析や問い合わせフォームの提供事業者を使う場合は、訪問情報や問い合わせ内容が提供事業者に送信され、保存されるかを、実装と設定で確認します。送信される情報が個人データに当たり、その取扱いを委託する場合は、個人情報保護委員会の通則指針に従い、委託先の選定、契約、取扱状況の把握、再委託の監督を確認します。該当性や必要な表示は、実際の取得項目、目的、主体、委託関係で確認します。

非公開でも、データが残れば低リスクとは限らない

利用者が社内数人でも、唯一の顧客台帳を保存するツールが壊れれば、業務を止めたり記録を失ったりします。公開範囲が狭いことは一つの軸にすぎません。正本、保存期間、機微性、権限、誤削除、バックアップ復元、担当交代を別に確認します。「社内用」「ノーコード」「試作」という呼び名で段階を下げません。

決済を外へ任せても、責任は全部移らない

決済画面を決済事業者に任せると、自分たちがカード会員データに直接触れる範囲を減らせる場合があります。それでも、PCI SSCの公式FAQは、加盟店には、決済事業者の適合状況の確認、書面による合意、継続的な確認、責任分担などが残ると説明しています。具体的な適用範囲は、契約するアクワイアラー（加盟店契約会社）、国際カードブランド、決済事業者、または専門家に確認します。

AIに任せる範囲と、別に確かめる証拠を分ける

AIを人の理解の代わりにはせず、候補の作成、説明、実装、検証の準備に使います。期待動作、確認する版、AIに与える情報と権限、合格条件、停止条件は人が決め、最終判断も人が担います。

AIへ渡す前に境界を決める

AIに任せる操作	最初の境界	リスクが上がる条件
読む・要約する	対象ファイルとフォルダを限定し、外部送信条件を確認	個人データ、顧客情報、機密、認証情報を含む
コードや設定を提案する	変更対象と禁止対象を指定し、差分で確認	認証・認可、データ移行、ネットワーク、秘密情報、課金に触れる
テストを作る・実行する	期待結果を人が先に書き、テストが破壊的でないと確認	実データ、外部送信、削除、課金、負荷を発生させる
ファイルやデータを書き換える	小さな範囲、バックアップ、実行前の確認、承認、元に戻す手順を用意	一括書き込み・削除、正本、復元未確認、不可逆操作
外部システムを操作する	ツールごとに最小権限、上限、明示承認、記録、緊急停止	公開、メール、決済、発注、アカウント変更、顧客への影響

OWASPのAIエージェントセキュリティ指針は、ツールごとに読み取り・書き込み・操作対象の範囲を最小化し、高影響・不可逆操作に明示承認を置き、操作・結果・費用等を記録し、停止・元に戻す手順を用意するよう勧めています。これらの対策があるだけで安全になるわけではありません。元に戻せないツールなら、AIへ許す操作をさらに狭めます。

AIの出力を独立して確かめる

検証は、AIに「合っていますか」と尋ねて終わりではありません。次の順で、AIの説明とは別の証拠を集めます。

期待結果を先に書きます。正常時に加え、処理を拒否する場合、入力が空の場合、同じ処理が重複した場合、処理に失敗した場合、権限が異なる場合の結果も書きます。
対象版を固定します。生成後に変更されていないコード、設定、依存部品のバージョン、公開物を確認します。
実際の差分を見ます。AIの作業報告ではなく、追加・変更・削除のすべてを確認します。
別の観点からテストします。同じAIが生成したテストだけに頼らず、人が決めた受け入れ条件、異常系テスト、静的解析、実行テストを使います。必要に応じて、別の確認者やツールにも確かめてもらいます。
権限と副作用を観察します。誰のデータを読み書きしたか、外部送信、通知、課金、削除が想定どおりかを確認します。
失敗時の動きと回復方法を試します。提供事業者の停止、タイムアウト、途中失敗、誤入力を再現し、バックアップからの復元や元に戻す手順を安全な環境で確かめます。
自分では確かめられない点を記録します。推測で合格にせず、専門家、業務責任者、提供事業者へ確認を引き継ぎます。

NIST SSDF 1.1は、コードのレビュー・解析と、実行可能なコードのテストを別々の実務項目として示しています。OWASPのAIコーディング指針も、AI生成コードには人の責任者を置き、人によるレビュー、異常系テスト、独立した解析を使うよう勧めています。同じAIエージェントだけで、コード作成とセキュリティテストを完結させないことも勧めています。

詳しい差分確認はAI生成コードをレビューするへ進みます。ここでは、レビューを誰に引き継ぐかまでを責任境界に含めます。

開始、保留、専門家へ相談する条件

開始できる条件

期待動作と、今回扱わない範囲が書けている
責任者、利用者、データの持ち主、正本が分かる
AI・人・提供事業者の読み取り、書き込み、削除、外部送信の範囲が分かる
結果を確認する証拠と対象版が決まっている
料金・利用量・公開範囲に上限がある
停止、元に戻す手順、バックアップ、移行、削除のうち、リスクに必要なものを試している
インシデント時の連絡先と、担当不在時の引き継ぎ先がある
自分で確認できない点について、必要な担当者が確認・承認した記録がある

保留する条件

責任者、正本、利用者、データの流れのいずれかが分からない
AIや提供事業者が何を読み、外部へ送り、保存するか分からない
一括書き込み、削除、公開、メール、課金等を実行前に確認できず、停止も元に戻すこともできない
バックアップはあるが、戻せることを確認していない
認可、契約、料金上限、提供事業者終了時の書き出しが未確認
同じAIの説明とテストだけが合格根拠になっている
障害を検知する人、インシデント時の連絡先、引き継ぎ先がいない

専門家へ相談する条件

個人、顧客、従業員、機密、認証情報、決済、健康等の規制対象になり得るデータを扱う
アカウント機能を持つ公開サービスの認証・認可、データ分離、不正利用対策を自分たちで検証できない
金銭、契約、法定記録、顧客通知、生命・身体へ影響する副作用がある
提供事業者との責任分担、規約、委託・再委託、データ保存地、移行・消去を判断できない
インシデントが起きたとき、原因の切り分けや安全な復旧を自分たちで判断できない

IPAのインシデント対応の手引きは、責任者・担当者と連絡を定め、対応が難しい場合は外部専門家へ相談し、原因や不具合の修正を確認してから復旧するよう示しています。「理解できるまで一人で進める」のではなく、確認できない範囲を止めて渡すことも責任です。

空欄の責任境界判断票

対象ごとに複製し、空欄を推測で埋めません。結論を変える空欄は保留にします。

対象名：
目的・期待動作：
今回扱わない範囲：

責任者：
利用者（社内外・人数・種類）：
公開範囲：

扱うデータと持ち主：
正本：
保存期間・保存場所：
バックアップと復元確認：
移行・書き出し・終了後の消去：

個人・顧客・機密・認証情報・決済・規制データ：
アカウントの作成から削除まで：
権限区分ごとの読み取り／書き込み／削除／管理権限：

AIが読める範囲：
AIが書き込み／削除／外部送信できる範囲：
AI操作の事前確認・承認・上限・停止・元に戻す手順：

外部提供事業者・フレームワーク・ライブラリとバージョン：
規約・料金・サービス水準（SLA）・保守終了を追う人：
障害・部分失敗・重複実行時の動き：
置換方法、乗り換えにくさ（ロックイン）、作り直し費用：

可用性と事業への影響：
監視方法：
インシデント時の連絡先：
担当交代時の引き継ぎ先と記録場所：

黒箱として受け入れる範囲：
自分たちが説明・検証する範囲：
独立検証の方法と対象バージョン：
専門家による確認が必要な範囲・担当・期限：

開始条件：
保留条件：
停止条件：
復旧条件：
相談条件：

結論（開始／保留／専門家へ相談）：
判断者・日付・根拠：
見直す日・見直しのきっかけ：

次に進む

責任境界が決まったら、実装を始める前に必要な記録を順番に整えます。

期待動作と合格条件は要件と受入条件の決め方へ
提供事業者、フレームワーク、ライブラリの候補比較は技術選定の進め方へ
アカウントと権限区分の境界は認証・認可設計の進め方へ
AIが作った差分とテストの確認はAI生成コードをレビューするへ
変更を版として戻せるようにする手順はGitで変更を管理するへ
公開直前の判断は公開前チェックリストへ
監視、連絡、復旧、引き継ぎは小さなサービスの最小運用へ

責任境界は一度決めて終わりではありません。公開範囲、利用者、データ、権限、提供事業者、料金、寿命、副作用のどれかが変わったら、判断票へ戻ります。