名古屋でAIアプリ公開支援を相談する前に｜要件・データ・担当者の整理

1. 初回相談では、どの業務のどこまでを公開したいか

本稿では、最初の資料を詳細な仕様書ではなく、対象業務を一枚で説明する業務概要にすることを提案します。たとえば問い合わせ対応を支援するなら、受付、資料検索、回答案の生成、担当者の確認、送信という流れを書き、AIに任せる箇所を囲みます。「回答案を作る」と「相手に送信する」は別の要件として扱い、初回公開で含める操作を決めます。現状の困りごとは、抽象的な効率化ではなく、どの場面で誰が何を探し直しているかまで記載します。

次に、成功例だけでなく、公開を見送る条件を具体化します。例として、根拠資料が見つからないときは回答案を確定させず、担当者へ戻す運用を置きます。対象外の質問、判断を人に残す業務、外部への書き込みを許さない範囲も相談資料に含めます。OWASPは設計時のセキュリティ判断を明示的な選択にすることを重視しています。機能の追加希望と公開に必要な条件を分ける整理は、この設計原則を業務要件に落とすための本稿の提案です。[1]

• 利用者、開始操作、入力、出力、最終確認者を一つの業務例で説明する。
• 初回公開に含める機能、後回しにする機能、実装しない操作を分ける。
• 対面が必要な打ち合わせと、オンラインで判断できる議題を区別する。

2. 個人情報を含むデータは、何を持ち込めばよいか

相談時には実データを一式渡すのではなく、項目名、利用目的、保存先、外部送信先を示したデータの流れを用意することを提案します。問い合わせ文の要約なら、本文中の氏名、連絡先、相談内容のうち、どれを処理に使う想定かを整理します。画面への入力だけでなく、添付ファイル、会話履歴、生成結果、検索用データ、操作記録も対象に含めます。初回の説明には架空データを用い、実データの共有が必要な段階になってから、共有範囲と受け渡し方法を判断します。

保存に関しては、「削除する」という一語を、対象、時点、担当に分解します。たとえば会話履歴を消す場合に、生成結果や検索用の複製も処理対象にするかを相談事項として残します。OWASPは機密性のあるデータの保護、バックアップ、保持設定を設計上の検討事項に挙げています。本稿では、その原則を基に、各保存先について保管理由と不要になる条件を記載する方法を提案します。外部AIサービスへの送信可否は、利用予定の契約条件や公式仕様を確認する別項目とします。[1]

• 入力から保存・外部送信・削除までの経路を図にする。
• 相談用サンプルは架空データとし、実在情報を含めない。
• 保存先ごとに、用途、管理担当、保管終了の条件を記録する。

3. 認証と権限は、どの操作単位で相談するか

「ログインできる人だけが使う」という説明に加え、誰がどの情報を閲覧し、変更し、出力できるかを整理します。たとえば担当者は自分の担当分を参照し、管理者は担当の割り当てを変更できる一方、データの一括出力は別の承認対象とする案です。OWASPは認証・認可と最小権限を設計原則として示しています。本稿では、役職名だけで権限を決めず、閲覧、登録、修正、削除、出力、設定変更を分けた一覧を用意し、必要な操作に絞って相談することを提案します。[1]

セッションについては、ログイン後に権限を変更する場面を相談用の確認課題にします。たとえば担当部署の変更後、すでに開いていた画面から旧部署の資料を取得できないことを期待結果として置きます。既存セッションの無効化方法と権限変更の反映条件を、採用候補の公式仕様と検証で確認することを提案します。画面が表示されたかだけで判断せず、変更前にログインした状態から、対象データの取得や更新を試す確認手順を設計し、結果が出るまでは未確認として扱います。

• 通常利用者と管理者の操作を、データ範囲とともに定義する。
• 権限変更前から利用中の状態を、検証シナリオに含める。

4. RAGでは、どの資料を誰に参照させるか

RAGを相談する際は、検索対象にしたい文書名だけでなく、資料の管理者、閲覧対象、更新の起点を用意します。本稿では、公開済み手順書と部署内限定の補足資料が混在する業務を想定し、文書群ごとに取り込み可否を決める方法を提案します。検索用データに含めてよい範囲と、利用者が参照してよい範囲を整理し、閲覧対象外の資料を回答の根拠にしないことを受入条件として置きます。これは期待する設計であり、特定の検索製品が自動的に満たすとみなすものではありません。

品質確認には、正しく答えられる質問に加え、資料に答えがない質問、古い版と新しい版が食い違う質問、閲覧対象外の内容を求める質問を用意します。期待する応答は、回答、保留、担当者への確認依頼などに分けます。また、引用元を表示する案なら、利用者がその資料を開いて確認できるかも評価対象にします。本稿では、質問ごとに参照してよい資料と期待結果を対にした評価用サンプルを作り、回答文の自然さだけで公開可否を決めない進め方を提案します。

• 資料の所有者、対象読者、版、更新・削除の連絡経路を整理する。
• 回答できない場合と参照してはいけない場合を別々に試す。

5. API・Webhook・再実行は、何を確定しておくか

API連携の相談には、接続先の名称だけでなく、読み取りと書き込みの区別、使用する資格情報、実行を許す操作を用意します。OWASPはシステム構成要素にも最小権限を適用し、秘密情報をコードへ直接埋め込まないことを示しています。本稿では、検索用の連携と登録用の連携を別の権限として検討し、保管場所、更新担当、利用記録の確認方法を相談項目にすることを提案します。Webhookについても、受信内容を何の処理に使うかを定め、送信元確認の方法は接続先の公式仕様で確認します。[1]

再実行の検討では、相談用の仮想事例として、登録は完了したが応答を受け取れなかった状況を置きます。この場合に同じ依頼を送り直してよいか、処理状況を照会してから判断するかを設計課題にします。実際に起こり得る条件や再送時の挙動は、接続先の公式仕様で確認します。本稿では、受付済み、処理中、完了、要確認といった業務上の状態を定義し、自動で再実行する対象と、人が確認する対象を分ける案を提案します。AIの回答生成と外部への登録処理も、別々の再実行単位として検討します。

• 接続先ごとに操作、必要権限、資格情報の管理担当を記載する。
• 再実行してよい条件と、判断を止める条件を業務側と合意する。

6. 公開前の確認表には、何を残すか

本稿では、相談段階から確認表を使い、期待結果、実施状況、判断者を同じ行に残すことを提案します。表は実施例ではなく、これから埋めるひな形です。正常に動く場面だけでなく、権限外の要求、資料不足、外部連携の結果が不明な場面も対象にします。OWASPは設計で見いだした脅威に対するテストや、開発中および配備直前のセキュリティテストを示しています。以下の表だけで検証を完了扱いにはせず、対象構成に応じて確認項目と方法を具体化します。[1]

未確認項目は、その重要性に応じて公開範囲の判断につなげます。たとえば外部登録の確認が終わらない場合は、回答案の作成までに範囲を絞る案を検討します。一方、利用者間の閲覧制御を確認できない状態では、実データを使う公開を進めない判断案とします。IPAの脅威一覧は、AIの利用をめぐるリスクや委託先を狙う攻撃などを検討する背景になりますが、個別アプリの合否基準ではありません。本稿では、脅威の名称を並べるより、自分たちの構成で何を確認するかに置き換えることを提案します。[2]

• 実施日、対象環境、構成の版、結果を確認表と結び付ける。
• 不合格と未実施を区別し、再確認の担当と期限を決める。

7. 公開後の保守を、誰へどう引き継ぐか

保守の相談には、障害時の窓口だけでなく、日常の変更を誰が判断するかを含めます。たとえば検索資料の差し替えは資料管理者、回答手順の変更は業務責任者、設定変更の反映は開発担当という役割案を置きます。本稿では、変更の申請者、承認者、実施者、確認者を引継ぎ資料に残すことを提案します。担当者の名前が未定なら役割名で仮置きし、公開判断までに割り当てる課題とします。連絡先一覧だけでなく、変更を戻す判断と手順も相談対象に含めます。

OWASPは更新の継続と、実践されたインシデント対応計画の重要性を挙げています。本稿では、更新対象の一覧、作業記録、復旧手順、利用停止を判断する連絡経路を引継ぎの単位とすることを提案します。たとえば資料更新後に回答が業務で使えなくなった場合は、直前の構成へ戻すか、対象機能を一時的に止めるかを判断する担当を決めます。必要な記録を誰が確認できるかも整理し、公開後の調査や復旧を相談する範囲と、別途専門的な対応が必要な範囲を分けておきます。[1]

• 更新、問い合わせ、障害連絡、公開継続の判断を役割に割り当てる。
• 引継ぎ資料の保管先と、担当交代時に更新する項目を決める。

よくある質問

業務責任者が初回相談に出席できない場合はどうしますか。

代理の参加者には、現状を説明できる範囲と決裁できる範囲を分けてもらうことを提案します。相談自体は業務の流れや候補案の整理に使い、外部送信や公開範囲などの承認は保留します。持ち帰る質問に回答担当と回答予定日を付け、出席していない人の了解を得た扱いにしないことが判断の要点です。

確認環境がまだない段階でも相談できますか。

本稿では、構成案と架空データによる机上確認から始め、実行確認が必要な項目を切り出す進め方を提案します。画面案だけで権限制御や連携処理を合格にはしません。検証用の環境や接続先を用意できる担当を決め、準備できない場合は、確認可能な範囲へ初回公開を縮小する案を相談します。

資料管理者が一時休職する場合、更新を続けるには何を決めますか。

代行者に任せる対象資料、判断できる変更、本人の復帰後に確認する事項を分ける案を提案します。代行者が内容の妥当性を判断できない資料は、更新を保留するか、検索対象から外す選択を検討します。元の担当者の資格情報を共有して代行するのではなく、代行に必要な権限を申請する運用案として整理します。

公開期限のために、一部の確認を期限付きで例外にできますか。

例外を設ける場合は、対象機能、残る懸念、代替措置、承認者、終了日を記録することを提案します。期限があるだけで未確認事項を合格に変更しません。たとえば連携処理を無効にした限定公開を検討し、期限到来時には自動的に継続扱いにせず、確認結果に基づいて解除、延長、機能停止を判断します。

参考・関連資料

• [1] Secure Product Design - OWASP Cheat Sheet Series ↗
• [2] 情報セキュリティ10大脅威 2026 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構 ↗

公式資料の確認日：2026-10-23。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。