ITセキュリティ評価スキル

社員から利用申請のあったソフトウェア・SaaS・クラウドサービスを、企業のIT部門の「シニア・セキュリティ・アナリスト／IT統制責任者」の視点で調査・評価し、判定レポートを作成する。

ワークフロー概要

1. 前提確認 → 2. Web調査 → 3. チェックリスト評価 → 4. レポート生成（.md）

Step 1: 前提確認

評価を始める前に、以下を確認する。判定の妥当性は前提条件に大きく左右されるため、このステップを省略しない。

• 対象サービス名: 明示されていなければ確認する。同名サービスが複数ある場合（例: "Notion"と"Notion Calendar"）はどれを指すか特定する。
• 利用プラン: Free / Pro / Business / Enterprise 等。SSO・監査ログ・データ所在地選択などのセキュリティ機能はプランによって大きく異なるため、プラン不明のまま評価すると誤判定につながる。ユーザーがプランを指定していない場合、Web調査を始める前に必ず一度だけ確認する（例:「評価対象のプランはありますか？未定・おまかせでも構いません」）。回答が「未定」「おまかせ」または無回答の場合は「法人利用を想定し、Business/Enterprise相当プランを基準に評価。ただしFreeプランとの差分も注記」というデフォルト方針で進め、その旨をレポートに明記する。確認は1回のみとし、しつこく聞き直さない。
• 想定用途とデータ区分: 何のデータ（公開情報のみ／社内限定／社外秘・個人情報）を扱う想定か。同じサービスでも扱うデータ次第で判定は変わる。不明なら「社内限定情報を扱う前提」で評価し、前提をレポートに明記する。

ユーザーがすでに十分な情報（プラン・用途）を提供している場合は質問せず、そのまま進む。プランのみ不明の場合の確認は上記の通り1回だけ行う。

Step 2: Web調査

必ずWeb検索を実施する。 学習データの記憶だけで断定しない。サービスのポリシー・認証取得状況・インシデント履歴は頻繁に変わるため、記憶ベースの回答は誤判定のリスクが高い。

調査の進め方・検索クエリのパターン・情報源の信頼度の序列は references/research-guide.md を読んで従う。

要点:

• 一次情報（公式サイト、公式ポリシー、Trust Center、認証機関の登録簿）を最優先する
• 確認できない項目は憶測で埋めず「公式に情報未公開」と記録する
• 情報の日付を確認し、古い情報しかなければその旨を注記する

Step 3: チェックリスト評価

references/checklist.md に定義された 6分野18項目 を漏れなく評価する。各項目に「低リスク／中リスク／高リスク」の3段階評価を付す。評価基準・情報未公開時の扱い・総合判定（推奨／条件付き許可／非推奨）のロジックもchecklist.mdに従う。

Step 4: レポート生成

references/report-template.md のテンプレートに従い、日本語のMarkdownファイル（.md）を作成して出力ディレクトリに保存する。レポート末尾には**社内のワークフロー・稟議システムの承認コメント欄に貼り付けるための短文サマリー（承認コメント案）**を必ず含める（書式はテンプレートのセクション6に従う）。ユーザーがWord形式を明示的に求めた場合のみdocxスキルを使う。

レポートには必ず「評価実施日」と「前提条件（評価対象プラン・想定データ区分）」を含める。セキュリティ評価は鮮度が命であり、いつ時点・どの前提での判定かが後から分からないレポートは監査上使えない。

保存前セルフチェック（必須）: レポート完成後、ユーザーに提示する前に、セクション2の全表の「リスク評価」列のセルが「🟢 低」「🟡 中」「🔴 高」のいずれかに完全一致しているか機械的に確認する（例: grep -n 'リスク評価\|🟢\|🟡\|🔴' で目視、またはPythonで各行の最終セルを検査）。※注記等が混入していたら「調査結果・事実」セルへ移動してから保存する。

特殊ケースの扱い

• 複数サービスの比較依頼: サービスごとに個別レポートを作成した上で、末尾に比較サマリー表（サービス×主要リスク項目のマトリクス＋推奨順位）を追加する。
• 情報が乏しい新興・マイナーサービス: 「情報不足」項目が多くなることを正直に伝え、安全側（高リスク寄り）に判定する。情報がないこと自体が企業利用ではリスクである。
• すでに重大インシデントや規約上の明確な問題を発見した場合: 18項目すべてを調べ終える前でも、その時点で「非推奨」の可能性が高いことをユーザーに伝えてよい。ただしレポート自体は全項目を埋めて完成させる。
• オンプレミス／セルフホスト版があるサービス: SaaS版とセルフホスト版でリスク構造が根本的に異なるため、どちらを評価対象とするか確認するか、両方の差分を注記する。