AI診断の選択肢が増えた今、依頼前に確認したいこと
AGESTは2026年9月28日、オンプレミスで提供するAIセキュリティプラットフォームなどの商用提供開始を発表しました。同社は脆弱性を探索する製品について、ソースコードを外部へ送信しない構成と説明しています。日本経済新聞も同日、サイバー防御を国内で完結させる企業の動きを報じています。
ソースコードは、システムを動かすプログラムの記述です。診断へ渡すときは、コードだけでなく、設定ファイルや試験データまで同じフォルダに入っていないかを確かめます。「国内処理」「社内の機器で実行」という説明と、渡してよい情報の範囲は、分けて確認したい条件です。
ここからは、外部へ業務システムの診断を依頼する会社に向けたSHINJIDAIの設計案です。依頼番号・役割・図は架空例であり、紹介した製品の標準機能や顧客の実績を示すものではありません。
「診断用の一式」に、顧客データや接続情報が混ざっていないか
架空の卸売会社が、受発注サイトの診断を保守会社へ依頼する場面を考えます。担当者は「コード一式を送れば早い」と考えましたが、同じフォルダには実際の注文を使った試験用ファイルと、接続先を記した設定も入っています。管理責任者が承認したのはコードの診断だけでした。
まず、何を調べるために、どのファイルが必要かを診断先とそろえます。対象コードの版を指定し、試験データは架空のものを用意できるか確認。認証情報を含む設定は、そのまま添付せず、必要な設定項目と共有方法を別途決めます。
そのうえで、第三者へ開示してよい範囲を契約担当者や権利者と確認します。所有している、手元にある、開発費用を払ったという理由だけで、すべての情報を渡せるとは判断しません。
フォルダ一式を渡す
依頼 AI-031 の範囲を決める
処理先だけでなく、ログ・結果・保守の行き先を追う
「国内処理」という回答を受けたら、どの処理まで含む説明かを確かめます。入力を受け取る場所、AIが計算する場所、結果やログを保存する場所、障害調査で保守担当者が見る場所を分けると、確認漏れが見えます。
例えばAmazon Bedrockの公式資料は、複数の地域の設備を使う処理方式では、指定した地理的範囲内でも、入力・出力が最初に指定したリージョンから別のリージョンへ移る場合があると説明しています。リージョンはクラウド設備の地域区分です。これは同サービスの特定方式の条件であり、すべてのAIサービスに同じ動作があるという意味ではありません。
また同サービスの保存条件は、モデルや設定によって異なり、人による確認を伴う場合もあります。学習への利用、保存、人による閲覧は同じ問いではありません。利用するサービスの現行資料と契約で、それぞれ確認します。
入力を受け取る
コード・設定・試験データの種類、送付先、受け取る会社
AIで処理する
使うモデル・実行環境・地域。別環境へ切り替わる条件
結果とログを残す
診断結果・入力の記録・エラー情報の保存先と保存期間
保守担当者が調べる
閲覧する会社・担当、接続元、追加の複製や再委託の有無
依頼を終える
共有停止、返却・削除、バックアップ等に残る条件
契約の説明と、実際に使う環境が一致するまで入力を保留する
架空の依頼 AI-031 では、対象コードの版と送付先、AIの実行環境は確認できました。一方、障害時に渡すログの範囲と、保守終了後の保存期間は回答待ちです。この状態を「国内処理だから承認」とせず、未確認の条件が残る依頼として入力を保留します。
契約担当者は契約・提供条件を、技術担当者は実際の構成と設定を確認します。社内の情報管理責任者が、その組み合わせで対象情報を渡してよいか判断します。委託先の回答には、対象サービスとモデル、資料の版や確認日をひも付けます。
承認後は、送るファイル一覧と版が承認内容に一致するかを実行担当者が照合します。AIを使う環境が別になった、追加ファイルが必要になったという場合は、同じ依頼番号でも条件を見直します。承認済みという一つの印だけで済ませない運用です。
- 01
対象を確定
コードの版・開示条件・架空データの範囲を確認
- 02
未確認を保留
ログの受渡しと保存期間は回答待ち。まだ送らない
- 03
根拠と実環境を照合
契約の回答とモデル・設定・保守経路を確かめる
- 04
判断した範囲だけ送る
責任者の承認後、実行担当が対象と送付先を照合
既存設定で足りるか、受渡しの連携や専用環境が必要か
担当者が迷う原因が、提出する情報や確認担当を決めていないことなら、まず既存の共有機能・権限設定・申請手順を整えます。専用環境を新設しても、誰が送ってよいか不明なままでは受渡しの問題は残ります。
一方、承認したファイルと実際に送る内容が何度も食い違う、複数窓口へ同じ依頼を転記する場合は、送付用一覧の作成や承認との照合を連携する案を比較します。現行サービスの条件では扱えない情報がある場合に、専用環境を含めて検討します。
経営側は、満たせない条件、対象業務への影響、導入後に誰が更新・監視・問い合わせを担うかを確認します。機器の費用だけで比べず、構成を維持し、条件変更を確認し続ける負担まで見ます。
既存設定・手順を整える
情報の範囲と担当が原因なら優先。共有制限・期限・承認記録が実際に働くか確認
受渡しを連携・改修する
転記や版の食い違いが残る場合。承認した一覧と送付結果を結び、変更時は再確認
専用環境を検討する
現行の提供条件では満たせない要件がある場合。処理だけでなく更新・保守・保存まで確認
モデル変更・ログの追加提出・依頼中止でも判断を戻せるようにする
最初の説明に合意しても、依頼の途中で条件は変わり得ます。変更の通知先、判断が済むまで止める作業、再開する条件を決めておくと、担当者がその場で持出しを判断せずに済みます。
診断結果にも、システムの構成や弱点を推測できる情報が含まれる可能性があります。受け取った報告書を別のAIへ入力する、社外の共有フォルダへ置くという後工程も、最初の依頼とは別に確認します。
- モデルや処理環境の変更：混雑や障害を理由に別環境へ切り替える場合も、合意した条件を満たすか確認してから再開する。
- 保守からのログ提出依頼：必要箇所と目的を確認する。追加の閲覧者・保存・再委託の条件が未確認なら、提出を保留して担当へ戻す。
- 診断結果の再利用：共有先と使う目的を限定する。報告書を別サービスへ入力してよいとは自動的に扱わない。
- 依頼の中止・終了：アクセス停止と情報の削除を分ける。バックアップ等に残る期間・扱いも確認し、即時削除と未確認の状態を混同しない。
SHINJIDAIは、情報の受渡しから運用での確認まで一緒に整えます
SHINJIDAIは、業務の課題を整理し、解決策の提案から設計・開発・導入まで伴走しています。このテーマでは、診断依頼の一件を題材に、何を渡すか、誰が条件を確認するか、どこで承認と実際の送付がずれるかを整理します。
まず今の契約確認・共有方法・システム構成を関係者と確認し、既存機能で直せる箇所と、連携や開発が必要な箇所を比較します。合意した範囲で、受渡し一覧・権限・承認記録・送付結果を結ぶ仕組みなどを実装します。
導入前には架空データで受渡しを試します。未承認の追加ファイル、送付先変更、ログの追加提出、担当交代、依頼取消を含めて、確認が必要なときに止まり、誰に戻すか分かるかを担当者と確かめます。
業務の課題整理から、設計・開発・導入まで
AI診断へ渡す情報と、確認する担当を整理するなら、
SHINJIDAIにご相談ください。
- コード・試験データを、どこまで渡してよいか迷う
- 国内処理の説明と、ログ・保守の条件がつながらない
- 今の共有機能を活かし、承認した範囲と実際の送付をそろえたい
課題の整理から伴走診断依頼の一件から、渡す情報・処理先・保存先・確認担当を整理します。既存設定と運用の見直し、必要な連携・開発を比較し、合意した範囲を実装。未承認の追加・送付先変更・依頼取消で、確認へ戻せるかを担当者と確かめます。
初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。
診断、契約上の判断、監視・事故対応の要否と担当、調査・設定・連携・開発の範囲は個別に確認します。
ID・パスワードや顧客データは、フォームに記載しないでください。
セキュリティ整備・伴走の支援を見る出典
確認日：2026年9月29日。AGESTの発表は商用提供の開始と説明された構成、日経の報道は背景把握に用いています。各社の発表をSHINJIDAIの提供サービスや、すべてのAI製品に共通する仕様として扱っていません。
AWS資料は、処理の地域と入力・出力の保存条件を分けて確認するための製品別の例です。採用する製品・モデル・設定の条件は、導入時と変更時に現行資料で確認してください。本文の依頼番号、確認手順、比較図はSHINJIDAIの設計案・架空例です。
よくある質問
国内で処理するAIなら、社外へ渡してよいという判断になりますか？
処理場所は判断材料の一つです。何を入力するか、ログや診断結果の保存先、閲覧できる担当者、再委託や保守時の持出しも確認します。自社の情報管理方針と契約条件に照らし、使うサービス・モデル・設定を特定してから判断します。
自社が費用を払って開発したシステムなら、ソースコードを渡せますか？
費用の負担だけで判断せず、コードの利用・第三者への開示条件を契約と権利関係から確認します。他社製品や外部ライブラリの扱い、顧客との取り決めが関わる場合もあります。分からない部分は契約担当者・権利者に確認し、許可された範囲を先に決めます。
診断のために、本番の顧客データやログを丸ごと送る必要がありますか？
まず目的に必要な情報を診断先と確認し、架空データや必要箇所だけで調べられるかを検討します。情報を削ることで再現できなくなる条件もあるため、単に伏せれば十分とは扱いません。実データが必要なら、対象・目的・保存・閲覧の条件を追加で判断します。
オンプレミスの専用環境を用意すべきですか？
一律には決めません。自社内の機器で処理する方式でも、更新作業、障害時のログ提供、保守担当者の接続条件を決める必要があります。まず既存サービスの設定と運用で要件を満たせるか確認し、満たせない条件と運用負担を明確にして専用環境と比較します。
SHINJIDAIへ相談するとき、最初からコードを送る必要がありますか？
初回は業務の概要、困っている受渡し、関係する部署と委託先、現在の管理方法から相談できます。機密情報そのものを先に送る必要はありません。確認したい条件を整理し、必要な情報の範囲と共有方法に合意したうえで、設定・連携・開発の支援範囲を検討します。