【2026年最新】Claude Code×情シス業務30選完全ガイド｜ヘルプデスク・PC管理・セキュリティの実装プロンプト集

「またパスワードリセットの問い合わせが来た……」

先日、企業向けAI研修の場でこんな話を聞きました（想定シナリオ: 100社以上の研修経験をもとに構成）。従業員300名規模のメーカーで情シスを1人で担当するAさんは、1日平均15〜20件の社内問い合わせに追われ、本来やるべきシステム企画や脆弱性対応の時間がほとんど取れない状態でした。「問い合わせの7割はFAQに書いてある内容なのに、毎回個別に返信している」と苦笑いしていたのが印象的でした。

情シス部門の業務は、ヘルプデスク対応・PC管理・セキュリティ運用・監査対応と幅広い。それぞれが重要で、どれも疎かにできない。でも人手は増えない。そのジレンマは、日本の情シス担当者に共通する課題なんです。

Claude Codeは、この問題に対して「コードを書く」+「文章を生成する」の両方を一つのツールで解決できます。正直、最初に試したときは「これがAIツール？」と驚きました。Bashスクリプトを生成させながらそのまま実行させ、ドキュメントも同時に更新できる。情シス担当者の「右腕」として使える初めてのAIツールだと感じています。

この記事では、情シス・IT管理部門の業務を30のカテゴリに分け、Claude Codeですぐに使えるプロンプト+コードスニペットをまとめました。ヘルプデスク自動化から、PCキッティング、セキュリティ監査対応まで、今日から実践できる内容を順に紹介していきます。

なぜいま情シス部門にClaude Codeなのか

情シスの業務を大別すると「定型作業（繰り返し）」と「判断業務（設計・リスク評価）」に分かれます。従来のRPAや既存のAIチャットボットは定型作業の一部を自動化できても、「スクリプトを書いてそのまま実行する」「ドキュメントを読んでポリシーを生成する」という組み合わせには対応できませんでした。

Claude Codeが画期的なのは、コーディング×文書生成×実行環境が一体化している点です。たとえば「Active Directoryの全ユーザーリストをCSV出力するPowerShellスクリプトを書いて」と指示すれば、スクリプトを生成→実行→CSV確認→エラーがあれば修正、という一連の流れをClaude Codeが完結します。

AIヘルプデスク関連の市場も急拡大しています。2025年のSaaS型サービスデスクツール市場規模は約2,659億円規模に達したと予測されており（BOXIL調査）、生成AIを組み込んだ自動化ニーズが急速に高まっています。一方で、汎用AIチャットボットと違い、Claude Codeは情シス担当者が実際に手を動かすスクリプト生成・修正・実行に特化しているため、実務での有用性が高いんです。

また、セキュリティ面でも安心できる設計になっています。AnthropicはSOC 2 Type II認証を取得しており、EnterpriseプランではZDR（Zero Data Retention）オプションで会話データをセッション終了後に即削除できます。詳細なセキュリティ設定についてはAIエージェントセキュリティ完全ガイド2026もご参照ください。

では、具体的なプロンプトに入っていきましょう。まずは効果を即感じられるヘルプデスク業務から。

まず今日試したい「5分即効」プロンプト3選

情シス業務のなかでも、今日の午後から使えるプロンプトを3つ厳選しました。コピペしてClaude Codeに貼り付けるだけで動きます。

即効1: パスワードリセット手順書を30秒で生成

（想定シナリオ: 100社以上の研修経験をもとに構成。ある研修先の情シス担当者がこのプロンプトを試したところ、従来30分かけて書いていたリセット手順書が2分で完成し「自分で書くより分かりやすい」と好評だったケースに基づく想定です。）

## 指示
以下の情報をもとに、一般社員向けのパスワードリセット手順書を作成してください。
ITリテラシーが低い社員でも迷わないよう、スクリーンショットの代わりに丁寧な文章説明を使ってください。

## 環境情報
- システム: [対象システム名を記入 例: Microsoft 365 / 社内基幹システム名]
- 対象者: 全社員（ITリテラシー: 初級〜中級）
- 連絡先: 情シス担当 内線[番号] / メール[アドレス]

## 手順書に含めること
1. パスワードリセットの前提条件（本人確認方法）
2. セルフリセットが可能な場合の手順
3. セルフリセット不可時の連絡先と受付時間
4. 新パスワードの要件（文字数・大文字小文字・記号）
5. よくある失敗パターンとその対処

不足している情報があれば、最初に質問してから作業を開始してください。

効果: 手順書のたたき台を2〜5分で生成。その後FAQページやNotionに貼り付けてブラッシュアップするだけで完成します。

即効2: 障害報告書ドラフトを口述から生成

障害発生直後のヒアリング内容をそのまま貼り付けるだけで、上長報告に耐える障害報告書のドラフトが完成します。

## 指示
以下の口述メモをもとに、社内向けの障害報告書（第1報）を作成してください。
フォーマットは [発生日時] [障害概要] [影響範囲] [暫定対応] [再発防止策（暫定）] [次回報告予定] の順で記載してください。

## 口述メモ
[ここに発生状況を箇条書きで貼り付ける]
例:
- 14:30頃にメールが届かないとの問い合わせが多発
- 確認したところメールサーバーのディスク使用率が98%になっていた
- 14:55に古いログを削除して使用率を80%に戻した
- 15:10時点で送受信が正常に戻っていることを確認
- 根本原因: ログローテーション設定が古いバージョンから引き継がれておらず無効化されていた

仮定した点は必ず"仮定"と明記してください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

即効3: Windowsイベントログを日本語で解説

「イベントビューアのエラーをコピペしたら、何が起きているか日本語で教えてくれ」という使い方です。英語のエラーメッセージやイベントIDを直接貼り付けると、状況と推奨対応を平易な日本語で返してくれます。

## 指示
以下のWindowsイベントログを分析し、以下の形式で説明してください。

1. 何が起きているか（技術的詳細を含む平易な日本語で）
2. 緊急度（緊急 / 要注意 / 低）とその理由
3. まず確認すべきこと（優先度順に3〜5項目）
4. 一般的な解決手順
5. 再発防止のための推奨設定

## ログ
[Windowsイベントログをここに貼り付ける]

不足している情報があれば、最初に質問してから作業を開始してください。

Claude Code×情シス業務は”3つの型”で考える

この3つの型を組み合わせると、日常の情シス業務をほぼカバーできます。本記事では型①〜③のプロンプトを合計30本公開しています。Claude Codeの全機能についての基本解説はClaude Codeでできること25選に詳しくまとめています。

ヘルプデスク自動化プロンプト10選（#1〜#10）

ヘルプデスク業務の悩みで最も多いのは「同じ問い合わせへの繰り返し対応」です。AIチャットボットが入電件数を約30%削減した事例（大京グループ、約6,000人規模）のように、まずは「回答品質の均一化」から始めるのが成功のコツです。

#1: ヘルプデスク回答テンプレートの一括生成

よくある問い合わせジャンルを指定するだけで、一次回答テンプレートを複数生成できます。

## 指示
社内ITヘルプデスク向けの一次回答テンプレートを作成してください。
以下の問い合わせジャンルごとに、担当者が最低限確認すべき情報の質問と、
一般的な対処法を含むテンプレートを作ってください。

## 問い合わせジャンル
1. パスワードリセット
2. 画面共有・Web会議ツールのトラブル
3. 印刷できない
4. VPN接続エラー
5. メールが届かない・送れない

## テンプレートの形式
件名: Re: [問い合わせ内容]
本文:
- お礼と受領確認
- 追加確認事項（箇条書き）
- 一般的な対処法（手順付き）
- 解決しない場合の次のステップ

不足している情報があれば、最初に質問してから作業を開始してください。

#2: FAQデータベースの再構築

過去のメール対応履歴やNotionのメモをそのままコピーして貼り付けると、FAQ形式に整理してくれます。

## 指示
以下の過去の問い合わせ対応履歴を分析して、社内FAQページとして公開できる形式に整理してください。

## 整理の要件
- 似た問い合わせはひとつにまとめる
- 回答は「初めてその問題に遭遇した社員でも解決できる」レベルで詳しく
- カテゴリ分類: ネットワーク / 端末・ハード / アカウント / メール / その他
- 各FAQに難易度タグ（自己解決可/情シス要確認/ベンダー対応必須）を付ける

## 過去の対応履歴
[ここに過去のメール本文や対応メモを貼り付ける]

不足している情報があれば、最初に質問してから作業を開始してください。

#3: チケット起票のための情報収集スクリプト

「問い合わせが来たら確認すること」を自動的にリスト化するプロンプトです。ServiceNowやZendeskのチケットフォームの初期テンプレとして使えます。

## 指示
社内ITヘルプデスクで使う「問い合わせ初期情報収集テンプレート」を作成してください。

## 対象業務・ツール
- サービスデスクツール: [ServiceNow / Zendesk / Freshservice / Jira Service Management など]
- 主な問い合わせカテゴリ: PC障害、アカウント、ネットワーク、ソフトウェア、その他

## 必須収集項目
- 申請者名・所属部門・連絡先
- 問題の発生日時・頻度
- 対象機器（機種・シリアル番号・OS）
- エラーメッセージ（ある場合）
- 直前に行った操作
- 他のPC/端末でも同じ問題が起きるか
- 業務影響度（業務停止/一部影響/軽微）

出力形式: ServiceNowのインシデント起票フォームのカスタムフィールドとして使える形式

不足している情報があれば、最初に質問してから作業を開始してください。

#4: 問い合わせの優先度自動トリアージ

受信したメール本文を貼り付けると、緊急度・影響範囲・推奨対応担当者を判定してくれます。

## 指示
以下の社内ヘルプデスク問い合わせメールを分析し、対応優先度を判定してください。

## 判定基準
- 緊急度: P1（業務停止）/ P2（業務影響大）/ P3（一部影響）/ P4（影響軽微）
- 影響範囲: 個人 / チーム（〜10名）/ 部門（〜100名）/ 全社
- 推奨担当: 一次対応（FAQ参照）/ 二次対応（技術担当）/ エスカレーション（管理職・ベンダー）

## 問い合わせメール
[ここにメール本文を貼り付ける]

## 出力形式
- 優先度: [P1〜P4]
- 影響範囲: [個人〜全社]
- 判定理由: 〜（2〜3行）
- 推奨担当: 〜
- 初動アクション: 〜（3つ以内）

不足している情報があれば、最初に質問してから作業を開始してください。

#5: エスカレーション連絡文の生成

ベンダーや上長へのエスカレーション連絡文を、状況メモから30秒で生成します。

## 指示
以下の障害状況を踏まえて、ベンダーへのエスカレーション連絡メールを作成してください。

## エスカレーション先
- 宛先: [ベンダー名] サポート窓口
- 契約番号/保守番号: [番号]
- 担当者名（弊社側）: [氏名]

## 障害状況メモ
[現象・影響範囲・発生日時・試みた対処・ログなどを箇条書きで記入]

## メールに含めること
1. 件名（緊急度・システム名を含む）
2. 契約情報と担当者連絡先
3. 障害の発生日時・現象・影響範囲
4. これまでの対処内容
5. 要求する対応（電話折返し / リモートサポート / 現地対応 など）
6. 希望する返答期限

仮定した点は必ず"仮定"と明記してください。

#6: 社員向けIT利用ガイドの更新

新しいツール導入時に、既存の社員向けIT利用ガイドの該当箇所を自動更新するプロンプトです。

## 指示
以下の既存の社員向けIT利用ガイドに、新しいツール/ポリシーの情報を追記してください。
文体・トーンは既存ガイドに合わせてください。

## 既存ガイド（該当箇所）
[既存ガイドの関連セクションをここに貼り付ける]

## 追記する内容
- ツール名/変更内容: [例: Slack Enterprise Grid 移行、MFAの全社必須化]
- 有効日: [YYYY-MM-DD]
- 対象: [全社員 / 特定部門]
- 主な変更点（箇条書き）: [内容]
- 問い合わせ先: [情シス連絡先]

不足している情報があれば、最初に質問してから作業を開始してください。

#7: インシデント事後レビュー（ポストモーテム）の作成

## 指示
以下の情報をもとに、インシデントのポストモーテム（事後レビュー）ドキュメントを作成してください。
責任追及ではなく、システム改善を目的とした「ブレームレス」な文体で書いてください。

## インシデント情報
- 発生日時: [YYYY-MM-DD HH:MM]
- 復旧日時: [YYYY-MM-DD HH:MM]
- 影響: [影響範囲・ユーザー数・売上影響など]
- 根本原因（仮説含む）: [内容]
- タイムライン: [検知→対応→復旧の主なステップ]

## ドキュメントの構成
1. エグゼクティブサマリー（3〜5行）
2. インシデントタイムライン（時系列表）
3. 根本原因分析（5 Whys手法で）
4. 対応の振り返り（良かった点 / 改善点）
5. 再発防止策（担当・期限つき）
6. 監視強化・アラート改善の提案

不足している情報があれば、最初に質問してから作業を開始してください。

#8: Slackでのヘルプデスク回答ドラフト生成

Slackの#helpチャンネルに届いた投稿をコピーして貼り付けると、ITに詳しくない社員向けの分かりやすい回答ドラフトを生成します。

## 指示
以下のSlackでの問い合わせに対する回答ドラフトを作成してください。
技術用語をできるだけ使わず、ITに詳しくない社員でも理解できる言葉で書いてください。
必要に応じてStep by Stepの手順を含めてください。

## 前提設定
- 情シス担当者として回答する
- 丁寧だがフレンドリーなトーン（Slackらしく）
- 絵文字は1〜2個程度（過剰にしない）

## 問い合わせ
[Slackの投稿内容をここに貼り付ける]

不足している情報があれば、最初に質問してから作業を開始してください。

#9: 多言語ヘルプデスク対応文の翻訳・生成

外国籍社員や海外拠点からの問い合わせに対応する際、英語・中国語などの回答文を生成します。

## 指示
以下の日本語の回答文を、[英語/中国語（簡体）/その他の言語]に翻訳してください。
IT用語は正確に、平易な言葉で訳してください。
翻訳後に、翻訳した言語での一般的なIT用語（専門用語）の確認も行ってください。

## 日本語原文
[回答文をここに貼り付ける]

不足している情報があれば、最初に質問してから作業を開始してください。

#10: ナレッジベースの品質チェック

既存のFAQやナレッジベースの記事を貼り付けると、情報の古さ・曖昧な表現・追加すべき情報を指摘してくれます。

## 指示
以下の社内ナレッジベース記事をレビューしてください。

## レビュー観点
1. 情報の鮮度（2026年現在も有効か）
2. 手順の抜け漏れ（初めて読む人が迷う箇所）
3. 曖昧な表現（「適切に」「必要に応じて」など）
4. リンク切れの可能性（外部サービスのURL等）
5. 追加すべき注意事項・よくある失敗パターン

## ナレッジベース記事
[記事内容をここに貼り付ける]

指摘は「問題箇所 + 理由 + 改善案」の形式で出力してください。

PCキッティング・アセット管理プロンプト10選（#11〜#20）

PCキッティングはWindows AutopilotとMicrosoft Intuneの組み合わせで「ゼロタッチキッティング」が実現しており、クラウド経由での自動展開が標準化しつつあります。Claude Codeはこの文脈で「設定スクリプトの生成・検証・ドキュメント化」を担うことができます。

事例区分: 想定シナリオ
以下は100社以上の研修経験をもとに構成した典型的なシナリオです。従業員100名規模のサービス業でIntuneを新規導入した際、Claude Codeを使って構成プロファイルのドキュメントを自動生成し、ベンダーとのレビュー準備工数を大幅に削減できたというパターンをもとにしています。

#11: Windows Autopilot/Intune 構成プロファイルのドキュメント化

## 指示
以下のMicrosoft Intune 構成プロファイル設定をもとに、
社内向けのPC管理ドキュメントを作成してください。

## 出力する内容
1. 構成プロファイルの目的と対象（全社員 / 特定グループ）
2. 主な設定内容（IT担当者向けの技術説明 + 社員向けの平易な説明）
3. 変更不可・ユーザー操作不可の設定項目とその理由
4. 運用上の注意点（除外対象・テスト手順）
5. 変更管理フロー（誰が承認してどう適用するか）

## 構成プロファイル情報
[Intuneの設定画面のスクリーンショットテキスト or 設定値をここに貼り付ける]

不足している情報があれば、最初に質問してから作業を開始してください。

#12: 新入社員向けPCセットアップチェックリストの生成

## 指示
以下の環境・条件をもとに、新入社員向けの初期PCセットアップチェックリストを作成してください。

## 環境条件
- OS: [Windows 11 Pro / macOS Sequoia など]
- ID管理: [Azure AD / オンプレAD / Google Workspace など]
- 必須インストールアプリ: [Microsoft 365, Slack, Zoom, Chrome など]
- セキュリティ要件: [BitLocker有効化, MFA設定, EDRインストール など]
- 情シス担当者のリモート確認ツール: [TeamViewer / Microsoft Teams管理 など]

## チェックリストの形式
- 実施者（情シス担当 / 本人 / 上長）を列ごとに分ける
- 各項目に「確認方法」と「NG時の対処」を添える
- 最終確認テスト（必須アプリ起動・印刷テスト・VPN接続テスト）を含める

不足している情報があれば、最初に質問してから作業を開始してください。

#13: 退職時PCの情報消去・回収フロー自動化スクリプト（PowerShell）

## 指示
退職社員のPCを安全に初期化するためのPowerShellスクリプトを作成してください。

## 実行する処理
1. BitLockerの回復キーをAzure ADから取得・記録
2. 対象ユーザーのAzure AD / Entra IDアカウントの無効化（削除ではなく）
3. Intuneのワイプコマンドをリモートで発行
4. 実行ログをCSVに出力（日時・実行者・対象PC・結果）

## 前提環境
- PowerShell 7.x
- Microsoft Graph APIモジュール（既インストール済み）
- 実行者: グローバル管理者 or デバイス管理者権限

スクリプトにはエラーハンドリングと、実行前の確認プロンプト（"y"を入力しないと実行しない）を含めてください。
不足している情報があれば、最初に質問してから作業を開始してください。

#14: PCアセット台帳の自動棚卸スクリプト（PowerShell）

## 指示
Active Directory / Azure ADに登録されているPCの一覧を取得して、
アセット台帳として使えるCSVを生成するPowerShellスクリプトを作成してください。

## 取得する情報
- コンピュータ名
- OS名・バージョン・ビルド番号
- 最終ログオンユーザー
- 最終ログオン日時
- IPアドレス（可能な場合）
- BitLockerの有効/無効状態
- Entra ID参加状態

## 出力形式
- CSV（文字コードUTF-8 BOM付き、Excelで文字化けしない）
- ファイル名: assets_YYYYMMDD.csv

スクリプトにはエラーハンドリングを含めてください。
不足している情報があれば、最初に質問してから作業を開始してください。

#15: ソフトウェアライセンス管理台帳の更新スクリプト

## 指示
以下の情報をもとに、ソフトウェアライセンス管理台帳（Excel/CSV形式）を更新するPythonスクリプトを作成してください。

## 入力ソース
- Intuneのデバイスアプリ一覧（CSVエクスポート）
- 既存のライセンス台帳（Excel形式）

## 処理内容
1. Intuneのデータから各端末にインストールされているアプリ一覧を抽出
2. ライセンス台帳の「インストール数」を自動更新
3. ライセンス数を超過しているアプリを赤色でハイライト（openpyxl使用）
4. 未登録の新規アプリを台帳末尾に追加（確認を求めるフラグ付き）

必要なライブラリは `pip install` コマンドとともに最初に明示してください。
不足している情報があれば、最初に質問してから作業を開始してください。

#16: MDM設定ポリシー（Intune/SCCM）のレビュー

## 指示
以下のMicrosoft Intuneの設定ポリシー（JSON形式またはテキスト形式）を分析してください。

## レビュー観点
1. セキュリティ強度（CIS Benchmarks/NIST SP 800-53の推奨と比較）
2. ユーザビリティへの影響（業務上の支障が出る可能性がある設定）
3. 見落としがちな抜け穴（設定の組み合わせで生まれるリスク）
4. 追加推奨設定（SMBセキュリティ・Windows Defenderの強化設定など）

## ポリシー設定
[IntuneのJSON設定やポリシー一覧をここに貼り付ける]

不足している情報があれば、最初に質問してから作業を開始してください。

#17: クラウドサービス申請フローの自動化テンプレ

## 指示
社員が新しいクラウドサービス（SaaSツール）の利用申請をする際の、
審査フローと申請フォームのテンプレートを設計してください。

## 含める要素
1. 申請フォーム（Google Forms / Microsoft Formsで作れる形式）
   - 申請者情報・利用目的・取り扱うデータの種類・利用人数
2. 情シスの審査チェックリスト
   - SOC 2 / ISO 27001認証の有無
   - データ保管場所（国内 / 海外）
   - 個人情報の処理有無
   - 既存ツールとの重複確認
3. 承認/却下通知テンプレ

不足している情報があれば、最初に質問してから作業を開始してください。

#18: BYODポリシーのドラフト作成

## 指示
私物端末（BYOD）の業務利用ポリシーのドラフトを作成してください。

## 会社情報
- 業種: [製造業 / サービス業 / 金融 など]
- 従業員数: [人数]
- 取り扱う情報の機密度: [公開情報のみ / 社内限定 / 個人情報あり]
- 利用を許可するデバイス: [スマートフォンのみ / PCも可 / タブレットも可]
- MDM適用: [Intune MAM / Jamf / なし]

## ポリシーに含めること
1. BYODの目的と適用範囲
2. 利用可能なデバイスの要件（OS バージョン・暗号化・ロック設定）
3. 禁止事項（会社データの個人クラウドへの保存など）
4. 紛失・盗難時の報告義務と対応手順
5. 退職時の会社データ削除確認プロセス
6. 違反時の措置

不足している情報があれば、最初に質問してから作業を開始してください。

#19: 機器廃棄時のデータ消去証明書の生成

## 指示
PC・サーバー・ストレージ機器の廃棄時に使用する、データ消去証明書のテンプレートを作成してください。

## 証明書に含める項目
1. 機器情報（種別・製造元・型番・シリアル番号・資産番号）
2. データ消去実施日・実施者氏名・立会者氏名
3. 消去方式（ソフトウェア消去/物理破壊/専門業者委託）
4. 消去規格（NIST SP 800-88 / DoD 5220.22-M など）
5. 確認事項チェックボックス（BitLocker解除確認・消去ツール名・回数）
6. 署名欄

出力形式: MarkdownまたはHTMLで、そのまま印刷できる形式

#20: ヘルプデスク対応時間の傾向分析（Python）

## 指示
以下のヘルプデスクチケットデータ（CSV形式）を分析して、
対応改善に役立つインサイトを抽出するPythonスクリプトを作成してください。

## 分析内容
1. カテゴリ別チケット件数・割合（円グラフ）
2. 曜日・時間帯別の受付件数ヒートマップ
3. 平均解決時間（カテゴリ別）
4. 未解決チケットの件数推移（折れ線グラフ）
5. 再開率（一度解決済みとしたが再問い合わせが来た件数）

## 入力CSVの形式
[CSVのヘッダー行をここに貼り付ける。例: ticket_id, created_at, category, priority, status, resolved_at, reopened]

## 出力
- 分析レポート（Markdown形式）
- グラフ画像（PNG、matplotlib使用）

必要なライブラリは `pip install` コマンドとともに最初に明示してください。
不足している情報があれば、最初に質問してから作業を開始してください。

セキュリティ運用・監査対応プロンプト10選（#21〜#30）

情シス部門のセキュリティ業務で最も工数がかかるのが「文書整備」です。ISMS内部監査対応・インシデント対応計画・ポリシー文書の更新は、毎年繰り返す割に自動化が進んでいない領域。Claude Codeはこの領域で特に力を発揮します。

セキュリティ全般のAI活用についてはmacOS Keychain×Claude Codeのセキュリティガイドも参照してください。

#21: ISMS内部監査チェックリストの生成（ISO 27001:2022対応）

（想定シナリオ: 100社以上の研修経験をもとに構成。ISMS認証を取得した製造業の情シス担当者が、年次内部監査の準備にClaude Codeを使ってチェックリストを生成し、監査準備工数を削減できたパターンをもとにしています。）

## 指示
ISO/IEC 27001:2022（JIS Q 27001:2025対応）の内部監査に使用するチェックリストを作成してください。

## 対象領域（必要な領域を指定）
- [ ] 情報セキュリティポリシー（箇条5）
- [ ] 組織の役割と責任（箇条5）
- [ ] リスクアセスメント・リスク対応（箇条6）
- [ ] アクセス制御（附属書A 5.15〜5.18）
- [ ] 暗号化（附属書A 8.24〜8.25）
- [ ] 物理的セキュリティ（附属書A 7.1〜7.14）
- [ ] インシデント管理（附属書A 5.24〜5.28）
- [ ] 事業継続管理（附属書A 5.30）
- [ ] サプライヤー管理（附属書A 5.19〜5.23）

## チェックリストの形式
- 各管理策について「確認すべき証跡（エビデンス）」を具体的に列挙
- 適合 / 部分適合 / 不適合 の3段階評価欄
- 指摘事項・改善提案の記入欄

不足している情報があれば、最初に質問してから作業を開始してください。

#22: セキュリティポリシー文書のドラフト作成

## 指示
以下の条件をもとに、情報セキュリティポリシーのドラフトを作成してください。

## 会社情報
- 業種: [業種を入力]
- 従業員数: [規模]
- 取り扱うデータ: [個人情報 / 機密情報 / 公開情報 の有無]
- 取得済み認証: [ISMS / プライバシーマーク / なし]
- 適用規制: [個人情報保護法 / 金融商品取引法 / 医療法 など]

## ポリシーに含めること
1. 目的・適用範囲・基本方針
2. 情報分類基準（機密 / 社内限定 / 公開）
3. アクセス制御の基本ルール
4. パスワード・認証ポリシー（最低文字数・有効期限・MFA要件）
5. 端末管理・持ち出しルール
6. インシデント報告フロー
7. 違反時の措置

不足している情報があれば、最初に質問してから作業を開始してください。

#23: 脆弱性情報（CVE）のトリアージと優先度判定

## 指示
以下のCVE（脆弱性情報）を分析し、自社環境への影響と対応優先度を判定してください。

## 自社環境情報
- 利用OS: Windows 11 / Windows Server 2022 / RHEL 9 / macOS 15 [該当するもの]
- 利用ミドルウェア: [Apache / Nginx / IIS / PostgreSQL など]
- インターネット公開サービス: [有 / 無] [公開している場合は概要]
- EDR: [Microsoft Defender / CrowdStrike / SentinelOne など]

## CVE情報
[NVDまたはJVNのCVEページのテキストをここに貼り付ける]

## 出力形式
- 影響有無: [有 / 無 / 調査要]
- CVSS スコア評価（環境スコアを自社環境で補正した考え方）
- 悪用可能性（PoCコードの存在有無・実際の攻撃観測の有無）
- 対応優先度: [緊急（48時間以内）/ 高（1週間以内）/ 中（1ヶ月以内）/ 低]
- 推奨対応（パッチ適用手順の概要 + 一時的な回避策）

数字と固有名詞は、根拠（出典/計算式）を添えてください。

#24: インシデント対応手順書（IRP）のドラフト作成

## 指示
以下のインシデントシナリオに対応する、インシデント対応手順書（IRP）を作成してください。

## インシデントシナリオ
[以下から選択または自由記入]
- ランサムウェア感染（エンドポイント1台 / 複数台 / サーバー）
- フィッシングメール開封・認証情報漏洩疑い
- 内部不正（USBへの大量データコピー検知）
- DDoS攻撃によるWebサービス停止
- クラウドサービスの設定ミスによるデータ公開

## 手順書の構成
1. 初動対応（最初の15分でやること）
2. 封じ込め手順（詳細ステップ）
3. 証跡保全の方法（ログ・メモリダンプ・タイムライン）
4. エスカレーション先一覧（内部・外部）
5. 復旧手順
6. 報告・通知義務（個人情報保護委員会・顧客 など）

不足している情報があれば、最初に質問してから作業を開始してください。

#25: 特権アクセス管理（PAM）の設計ドキュメント

## 指示
特権アクセス管理（PAM）の運用ポリシーと技術設計ドキュメントを作成してください。

## 対象環境
- 管理対象: [Windows Server AD / Linux サーバー / クラウド（AWS/Azure/GCP）/ SaaSツール]
- 特権アカウント数（概算）: [件数]
- 現状の課題: [共有アカウント使用 / パスワード管理ツールなし / アクセスログなし など]

## ドキュメントの内容
1. 特権アカウントの種類と定義
2. 特権アクセスの申請・承認フロー
3. 最小権限の原則の適用方針
4. Just-In-Time（JIT）アクセスの設計
5. セッション記録・監査ログの取得方法
6. 定期レビュー（アカウントの棚卸）の手順

不足している情報があれば、最初に質問してから作業を開始してください。

#26: SOX/J-SOX対応のIT統制ドキュメント整備

## 指示
J-SOX（内部統制報告制度）対応のためのIT全般統制（ITGC）ドキュメントを整備してください。

## 対象の統制領域
- [ ] アクセス管理統制（論理アクセス管理）
- [ ] 変更管理統制（システム変更管理）
- [ ] 運用・監視統制（バックアップ・監視）
- [ ] インシデント管理統制

## ドキュメントの形式
1. 統制目標の説明
2. リスク（統制が機能しない場合に何が起きるか）
3. 統制活動（実際に行っている対応手順）
4. 証跡（エビデンス）の種類と保管場所・期間
5. テスト手順（有効性評価の方法）

不足している情報があれば、最初に質問してから作業を開始してください。

#27: SBOMの生成と管理ポリシーの作成

SBOM（ソフトウェア部品表）は、EUのサイバーレジリエンス法（2027年から義務化）や日本のMETI/IPA/NISCのガイドラインでも重要性が増しています。2026年時点では日本での法的義務化は途上ですが、取引先からの提出要求が増加しています。

## 指示
自社システムのSBOM（ソフトウェア部品表）管理ポリシーを作成してください。

## 対象システム
- [Webアプリケーション / 組み込みシステム / 社内業務システム]
- 主要な開発言語・フレームワーク: [Node.js / Python / Java / .NET など]
- 利用しているパッケージ管理: [npm / pip / Maven / NuGet など]

## ポリシーに含めること
1. SBOMの生成タイミング（リリース時 / 四半期 / 定期スキャン）
2. 使用するSBOMフォーマット（SPDX / CycloneDX）と生成ツール
3. 脆弱性スキャンとの連携（OSVスキャン等）
4. SBOMの保管場所・共有方法・アクセス権限
5. 取引先からのSBOM提出要求への対応フロー
6. METI/IPA ガイドライン（2024年版）との対応関係

不足している情報があれば、最初に質問してから作業を開始してください。

#28: フィッシング訓練シナリオとレポートの生成

## 指示
社内向けフィッシング訓練のシナリオとレポートを作成してください。

## 訓練の概要
- 対象: [全社員 / 特定部門（経理・人事など）/ 経営幹部]
- 実施時期: [YYYY-MM]
- 訓練の難易度: [初級（一般的なフィッシング） / 中級（標的型メール） / 上級（BEC（ビジネスメール詐欺））]

## 作成するドキュメント
1. 訓練メールのシナリオ（件名・本文・偽リンクの説明）
2. 実際には送らないが「こんなシナリオで考えます」という設計案
3. クリック者への学習コンテンツ（なぜ危険か・正しい見分け方）
4. 訓練結果のレポートテンプレ（クリック率・報告率・部門別集計）

※ 実際のフィッシングメールの送信は専門ツール（KnowBe4/Proofpoint等）を使用し、Claude Codeは設計・コンテンツ生成のみに使用してください。
不足している情報があれば、最初に質問してから作業を開始してください。

#29: Entra ID / Azure ADの不審なサインイン分析

## 指示
以下のAzure AD / Microsoft Entra IDサインインログを分析し、不審なアクセスを特定してください。

## 分析観点
1. 不可能な旅行（Impossible Travel）: 短時間に地理的に離れた場所からのサインイン
2. 新規デバイス・新規ブラウザからのサインイン
3. 深夜・早朝の業務時間外アクセス（タイムゾーン考慮）
4. 連続した認証失敗後の成功（パスワードスプレー攻撃の兆候）
5. レガシー認証プロトコル（SMTP/IMAP/POP3）の使用

## ログデータ
[Azure PortalからエクスポートしたCSVのデータ、または該当行をここに貼り付ける]

## 出力形式
- 要調査アカウントの一覧（優先度付き）
- 各アカウントの不審な理由（具体的なイベント）
- 推奨する即時対応（パスワードリセット / MFA強制 / アカウント一時無効化）

不足している情報があれば、最初に質問してから作業を開始してください。

#30: セキュリティ月次レポートの自動生成

## 指示
以下の情報をもとに、経営幹部向けのセキュリティ月次レポートを作成してください。

## レポート期間
[YYYY年MM月度]

## 入力データ
- インシデント件数・内容（種別・重要度・対応状況）: [内容を箇条書きで]
- 脆弱性対応状況（パッチ適用率・未適用の件数）: [数値]
- フィッシング訓練結果（実施した場合）: [クリック率 など]
- ヘルプデスクチケット数（前月比）: [数値]
- セキュリティ教育の受講状況: [受講率]

## レポートの構成
1. エグゼクティブサマリー（3〜5行・技術用語なし）
2. 今月のハイライト（良かった点と要改善点）
3. インシデント対応状況（表形式）
4. セキュリティKPI（前月比グラフは担当者が別途作成、テキストで概要）
5. 来月の重点施策
6. 経営層への要請事項（予算・体制・意思決定が必要なもの）

仮定した点は必ず"仮定"と明記してください。

【要注意】情シス担当者がClaude Codeで陥りがちな失敗パターン4選

この4つは本当によく見る失敗です。特に1番目と3番目は「やらかした後で気づく」パターンが多いので、事前に確認しておいてください。

失敗1: 生成されたスクリプトをレビューなしで本番実行する

❌ よくある間違い: Claude Codeが生成したPowerShellスクリプトを、テスト環境で確認せずにいきなり本番ADに実行してしまう

⭕ 正しいアプローチ: 必ず「テスト環境で実行 → 結果を確認 → 本番実行」のステップを踏む。Claude Codeにも「-WhatIf パラメータをつけてドライランできる形で書いて」と明示する

なぜ重要か: Claude Codeは実行環境のコンテキストを完全に把握しているわけではありません。ADの環境設定や独自カスタムが異なる場合、予期しない挙動が起きることがあります。「AI任せ」ではなく「AIと協業」が正しいアプローチです。

失敗2: 機密情報をプロンプトにそのまま貼り付ける

❌ よくある間違い: 実際のADユーザーリスト・IPアドレス一覧・社員の個人情報をそのままプロンプトに貼り付けて送信する

⭕ 正しいアプローチ: 機密性の高い情報は「[社員名]」「[部署名]」などのプレースホルダーに置き換えてからプロンプトに渡す。Enterpriseプランを使用しZDRオプションを有効にする

なぜ重要か: AnthropicのEnterpriseプランはSOC 2 Type II準拠ですが、個人情報保護法や社内情報セキュリティポリシーの観点から、機密情報の外部サービス入力には社内承認プロセスが必要なことが多いです。

失敗3: プロンプトを一般的すぎる形で書く

❌ よくある間違い: 「セキュリティポリシーを作って」「ヘルプデスクの手順書を書いて」と曖昧に指示する

⭕ 正しいアプローチ: 本記事のプロンプト例のように「環境情報・含めるべき項目・出力形式・対象読者」を具体的に指定する。不足情報は先に質問させる文言（「不足している情報があれば、最初に質問してから作業を開始してください」）を必ず末尾に入れる

なぜ重要か: 曖昧な指示では汎用的な出力になり、自社環境に合わせた加工が多くなります。最初に5分かけて詳しいプロンプトを書くことで、後の修正工数を大幅に削減できます。

失敗4: Claude Codeを「万能な回答機」と思い込む

❌ よくある間違い: 生成されたセキュリティポリシーや監査チェックリストをそのまま正式文書として使用し、自社の状況に合わせた確認を行わない

⭕ 正しいアプローチ: Claude Codeの出力は「たたき台」。特にセキュリティ・コンプライアンス関係の文書は、法令や規制の最新版・自社状況に照らした専門家（社内担当者・外部コンサルタント）のレビューを必ず経る

なぜ重要か: 正直に言うと、Claude Codeは知識のカットオフがあり、最新の規制改正情報を常に反映しているわけではありません。たとえばJIS Q 27001:2025（2025年改訂版）の細かい変更点については、公式のISMS-ACやIPAのガイドを一次ソースとして確認してください。

情シス担当者のためのClaude Codeガバナンス設計

特権アクセス・管理者権限の扱い

Claude Codeに「管理者権限で実行するスクリプトを書かせる」という使い方は効果的ですが、スクリプトの実行そのものには人間の確認が必須です。以下の原則を徹底してください。

• 最小権限の原則: Claude Codeを使う作業アカウントは、その作業に必要な最低限の権限のみ付与する
• dry-runファースト: 変更を伴うスクリプトは必ず-WhatIf / –dry-runオプション付きで先に確認
• 実行ログの保全: どのスクリプトをいつ誰が実行したかを記録するログを残す（SOX・ISMS監査の証跡として活用可能）

SOX/J-SOX対応との連携

AnthropicはSOC 2 Type II認証を取得しており、2025年8月にはAudit APIを提供開始しています（管理者レベルの操作ログをSIEMに流せる）。ただしAudit APIは「誰がどのリソースを操作したか」のログを提供するもので、「会話内容のログ」は別途企業側での設計が必要です。J-SOX対応で「AIツールの利用を内部統制の証跡に含める」場合は、Enterpriseプランでの実施を強く推奨します。

詳細なセキュリティ管理のベストプラクティスはAI内部統制・ガバナンス30日プランにまとめています。

情報分類とプロンプト設計のルール化

情シス部門でClaude Codeを複数担当者で使う場合は、以下の社内ルールを最初に決めておくことをお勧めします。

既存ツール（Slack / ServiceNow / Microsoft Intune）との連携

Claude Codeは単体で使う以外に、既存のITSMツールやコラボレーションツールと組み合わせることで効果が最大化します。

ServiceNowとの連携パターン

ServiceNowはREST APIを提供しているため、Claude Codeでスクリプトを生成してServiceNowのインシデントを自動更新・自動クローズする仕組みを構築できます。たとえば「特定のイベントログが検知されたら自動的にインシデントチケットを起票するスクリプト」をClaude Codeで生成し、サービスアカウントで定期実行するパターンは、情シスの自動化として非常に効果的です。

Slack / Microsoft Teams連携

Claude Codeで生成したFAQコンテンツをSlack Botやバンドルされた社内Wikiに組み込む際、Markdown形式で出力させることでそのまま貼り付けられます。また「Slackの#helpチャンネルに届いた質問を毎朝まとめてClaude Codeに送り、回答ドラフトを生成する」という半自動化フローを実現している情シス担当者もいます（#8のプロンプトが活用できます）。

Microsoft Intune / Entra ID連携

Microsoft Graph APIとClaude Codeを組み合わせると、Intuneのデバイスステータスの定期レポート生成、コンプライアンス違反デバイスの自動通知スクリプト生成が可能です。#14（PCアセット棚卸スクリプト）や#13（退職時PC初期化スクリプト）がそのまま活用できます。

Claude Codeの全社導入については生成AI全社展開90日ガイドも参考にしてください。

ROI試算: 情シス担当者のClaude Code活用の費用対効果

以下はあくまで想定シナリオ（100社以上の研修経験をもとに構成した試算）です。実際の効果は組織の規模・業務内容・ツール環境によって異なります。

試算の前提: 情シス担当者1名・時給換算3,000円・上記4業務合計で月45時間が対象業務と仮定。40〜65%の削減が実現した場合、月18〜29時間の削減→月額5〜9万円相当の工数削減という計算になります。Claude Codeのチームプランは1席25ドル（約3,500〜4,000円）/月なので、ROIは投資対比の効果が期待できる試算です。ただし導入初期には学習コストが発生します。

情シス×Claude Code 導入ロードマップ（3ヶ月）

まとめ: 情シス担当者が今日から始める3つのアクション

Claude Code×情シス業務は、「文書生成→スクリプト生成→分析・審査」の3ステップで段階的に活用領域を広げられます。一人情シスでも、大きなIT部門でも、まず「今日の午後に一つ試す」ことが最速の近道です。

1. 今日やること: #1のヘルプデスク回答テンプレートプロンプトをClaude Codeに貼り付けて、よくある5つの問い合わせへの回答テンプレートを生成してみる
2. 今週中: #4（優先度トリアージ）と#7（ポストモーテム作成）を実際の業務で試し、生成物の品質を評価する
3. 今月中: 情シス部門内のClaude Code利用ルール（情報分類とプロンプト設計のガイドライン）を1枚のNotionページにまとめる

次回予告: 次の記事では「Claude Code×経理・財務部門」をテーマに、請求書処理・仕訳補助・月次決算準備の自動化プロンプトをお届けします。

参考・出典

• 情報マネジメントシステム認定センター（ISMS-AC）「ISMS適合性評価制度の概要」 — ISMS-AC（参照日: 2026-05-11）
• 「2026年最新 ISO27001規格改訂の全貌を徹底解説」 — 認証パートナー（参照日: 2026-05-11）
• 「SBOMとは？義務化の流れや重要性、3つの標準フォーマットについて解説」 — アジェスト（参照日: 2026-05-11）
• 「SBOMとは？義務化の動きと管理運用フォーマットの具体例」 — yamory（参照日: 2026-05-11）
• “Claude Code SOC 2 compliance — what your auditor needs to know” — Amit Kothari（参照日: 2026-05-11）
• 「サービスデスクツールのシェア・市場規模」 — BOXIL Magazine（参照日: 2026-05-11）
• 「生成AIをヘルプデスクで活用するメリット！問い合わせ対応事例も紹介」 — Helpfeel（参照日: 2026-05-11）