Gemini Omniで何が変わるか——業務効率化の革命とディープフェイク時代のセキュリティ課題

テキスト・音声・映像を遅延ゼロで変換するAI——これが本当に動いている時代に、僕たちはいる。

Googleの新しいネイティブマルチモーダルAI「Gemini Omni」のハンズオンレビューが各所で公開されている。デモを見る限り、その処理能力は確かに圧倒的だ。リアルタイムでの音声対話、映像認識、テキスト・音声・映像のシームレスな相互変換——SFの世界がついに業務の現場に降りてきた、という印象を持った。

ただ、現場の立場で言わせてもらうと、この技術は「業務効率化のブレイクスルー」であると同時に、「新しいセキュリティリスクの入り口」でもある。今回はGemini Omniのデモから見える両面を、ビジネス活用とセキュリティの観点から評価する。

目次

1. Gemini Omniで何が変わるのか
2. 業務効率化の観点：現場で活きる3つの場面
3. セキュリティの観点：ディープフェイク時代の到来
4. 企業導入で押さえるべき4つのポイント
5. 「使うか・使わないか」ではなく「どう備えるか」

1. Gemini Omniで何が変わるのか

これまでのAIは、テキスト・音声・画像をそれぞれ別のモデルで処理していた。一度テキストに変換してから別のモデルで処理し、また結果を変換する——そういう「リレー方式」が一般的だった。

Gemini Omniが本質的に違うのは、テキスト・音声・映像をネイティブに（つまり最初から統合されたモデルで）処理できる点だ。デモで実証された処理速度を見る限り、人間との対話における違和感はほぼゼロに近い。電話越しに話している相手がAIだと気付かないレベルの応答性は、もはや「テクノロジーデモ」ではなく「日常使いに耐える品質」だ。

業務に与えるインパクトは大きい。同時に、悪用された時の影響も大きい。

2. 業務効率化の観点：現場で活きる3つの場面

Gemini Omniのような統合型マルチモーダルAIが、業務効率化に効く場面を3つ挙げる。

① リアルタイム翻訳・通訳業務
海外取引のある中小企業にとって、これは大きい。会議中にリアルタイムで通訳を挟むコストと時間が削減される。映像越しの会議でも、相手の表情や資料を読み取りながら通訳できるなら、コミュニケーションの質が大きく変わる。

② 議事録・映像コンテンツの自動処理
会議の録画から議事録を生成する仕組みは既存のサービスでもある。だが、Gemini Omniのような処理能力があれば、「ホワイトボードに書かれた内容を認識して議事録に反映する」「発言者の表情から議論の温度感を補足する」といったレベルの精度が見えてくる。

③ 現場業務での「相棒AI」
製造現場での目視検査、医療現場での所見記録、建設現場での進捗確認——スマホやスマートグラスから映像をリアルタイムでAIに渡し、その場で判断のサポートを受ける使い方が現実的になる。「現場の人間がAIを呼び出して質問する」ではなく「AIが常に横にいる」感覚に近い。

この変化は、業務プロセスそのものを再設計する余地を生む。「AIを使う仕事」ではなく「AIと一緒に進める仕事」への移行が、いよいよ現実的な選択肢になってきた。

3. セキュリティの観点：ディープフェイク時代の到来

ここからが本題だ。Gemini Omniのような技術は、セキュリティの観点で見ると新しいリスクの温床になりうる。

最も警戒すべきは、リアルタイムのなりすまし攻撃だ。これまでもディープフェイク動画は存在したが、生成に時間とコストがかかり、リアルタイム性は限定的だった。マルチモーダルAIの進化により、以下のような攻撃が現実味を帯びる。

① 音声でのなりすまし（ボイスフィッシング）
上司の声を学習させ、リアルタイムで部下に電話をかけて指示を出す。「至急、この口座に振り込みを」という指示が、本物の声で行われる時代だ。実際にこのタイプの詐欺は2024年以降増加しており、Gemini Omniのような技術がより一般化すれば被害は加速する。

② 映像でのなりすまし（ビデオ会議偽装）
Zoom・Teamsなどのビデオ会議で、相手の顔と声をリアルタイムで偽装する攻撃。香港で発生した、CFOになりすました複数人のディープフェイクビデオ会議で約38億円の被害が出た事件は、業界に衝撃を与えた。技術の進歩は、この種の攻撃のハードルを確実に下げる。

③ ソーシャルエンジニアリングの高度化
SNSや過去の動画から本人の話し方・癖を学習させれば、本人とほぼ区別のつかないコミュニケーションが可能になる。「声と映像」という、これまで本人確認の最後の砦だった要素が崩れていく。

4. 企業導入で押さえるべき4つのポイント

では、企業がこの種のAIを業務に導入する際、何を押さえるべきか。ISO27001（ISMS）とISO42001（AIマネジメント）の観点から4点に絞った。

① データガバナンスの徹底
マルチモーダルAIに音声・映像を渡すということは、機密情報や個人情報がそのままAIサービスに送信されるということだ。「どのデータをAIに渡してよいか」を明確に定めたガイドラインが必須になる。社内会議の音声、顧客との通話、現場の映像——どこまでクラウドAIに渡してよいかを線引きする必要がある。

→ 中小企業の生成AI利用ガイドライン——今日から始められる5つのアクション

② オンデバイス処理の活用と制限の理解
高度な処理はクラウド側で行われるため、機密性の高い業務には制限がかかる。一部の処理はスマホやPC上でローカル実行できるが、性能はクラウド版に比べて限定的だ。「速さ・賢さ・機密性」のトレードオフを正しく理解し、業務ごとに使い分ける設計が必要になる。

③ ソーシャルエンジニアリング対策の刷新
従来の「不審なメールに気をつけよう」というセキュリティ教育では足りない。「声や映像でも本人確認をしない」「金銭・機密情報に関する指示は別経路で確認する」という新しいルールを組織に浸透させる必要がある。具体的には、以下のような対策が考えられる。

・重要な指示は必ず複数の経路で確認する（電話＋メール、社内チャット＋対面など）
・金銭・個人情報に関する指示はその場で対応しない（時間を置いて確認する）
・「合言葉」「セキュリティクエスチョン」など事前に決めた本人確認ルールを設ける

④ サードパーティリスクの再評価
Gemini Omniのような外部AIサービスを業務で使う以上、そのサービスのセキュリティ・データ管理体制は自社のリスクと一体になる。サプライチェーンリスクの観点から、定期的な再評価が必要だ。

→ 「自社は無事」でも顧客情報は漏れる——サプライチェーンリスクの教訓と中小企業の備え

「使うか・使わないか」ではなく「どう備えるか」

Gemini Omniのような技術が出てくると、「すごい」と「怖い」が同時に押し寄せる。僕の答えはシンプルだ。「使うか・使わないか」ではなく、「どう備えるか」を考える段階に入っている。

業務効率化のメリットは確実にある。一方でセキュリティリスクも確実に存在する。両方を踏まえた上で、「自社にとってどう使うのが正解か」を判断できる体制を持つこと——それが、AI時代のIT担当者・経営層に求められる視点だ。

この技術は、待っていれば誰かが正解を出してくれるものではない。各社が自分たちの業務とリスクを照らし合わせて、使い方を設計する必要がある。今のうちにISO42001の考え方を参考にしながら、「AIガバナンス」の土台を作っておくことを強くおすすめする。

→ ISO 42001とは何か？AIマネジメント規格を中小企業向けに現場目線で解説

関連記事

・中小企業の生成AI利用ガイドライン——今日から始められる5つのアクション
マルチモーダルAIを使う前提として整備すべきガイドラインの基本。

・ISO 42001とは何か？AIマネジメント規格を中小企業向けに現場目線で解説
AI導入時のリスク管理の体系的な枠組みとしてのISO42001。

・「自社は無事」でも顧客情報は漏れる——サプライチェーンリスクの教訓と中小企業の備え
外部AIサービスを業務に使う上で押さえるべきサプライチェーンリスク。

AIを使ったリスクアセスメントの実践——Claudeと一緒にシートを埋めてみた

「リスクアセスメント、何を書けばいいか分からない」——そのモヤモヤ、Claudeと一緒に解消した。

ISO27001でもISO42001でも、リスクアセスメントは中核の作業だ。でも実際にシートを目の前にすると、「脅威って何を書けばいいの？」「脆弱性と脅威の違いが分からない」「リスク値の付け方が主観的すぎないか」——こういう声を現場でよく聞く。

今回は、Claudeを壁打ち相手にしながらリスクアセスメントシートを実際に埋めていく手順を紹介する。テンプレートも用意しているので、手元にダウンロードして一緒に進めてもらえると嬉しい。

→ 棚卸しから始めるISO27001——情報資産台帳をAIで効率化した話

目次

1. リスクアセスメントとは何か：最小限の理解
2. テンプレートの構成：何をどこに書くか
3. ステップ1：対象資産を決める（情報資産台帳から選ぶ）
4. ステップ2：脅威と脆弱性を洗い出す（Claudeに壁打ちする）
5. ステップ3：リスク値を算出する（発生可能性×影響度）
6. ステップ4：対応策を決める（許容・軽減・回避・移転）
7. AIリスクも同じシートで評価する
8. 「一人で悩まない」がリスクアセスメントのコツ

1. リスクアセスメントとは何か：最小限の理解

リスクアセスメントを一言で言うと、「何が起きる可能性があり、起きたらどれくらい困るかを整理すること」だ。

ISO27001では「情報資産に対するリスク」を、ISO42001では「AIシステムに関するリスク」を評価する。やっていることの本質は同じで、対象資産に対する脅威を洗い出し、その発生可能性と影響度を数値化して、対応の優先順位を決める。

難しく考えがちだが、「うちで一番まずいことが起きるとしたら何か」を整理する作業と捉えれば、そこまでハードルは高くない。

2. テンプレートの構成：何をどこに書くか

リスクアセスメントシートのテンプレートを用意している。構成は以下の通りだ。

対象資産：情報資産台帳から選んだ資産名。
脅威：その資産に対して起こりうる不都合な出来事。
脆弱性：脅威を受けやすくする弱点。
リスク内容：具体的にどんな被害が想定されるか。
発生可能性（1〜3）：起きやすさの評価。
影響度（1〜3）：起きた場合のダメージの大きさ。
リスク値：発生可能性×影響度で自動計算。
対応策：具体的に何をするか。

テンプレートにはサンプルデータが入っているので、それを自社に書き換える形で進められる。

3. ステップ1：対象資産を決める（情報資産台帳から選ぶ）

リスクアセスメントの最初のステップは、「何を評価するか」を決めることだ。情報資産台帳から重要度の高い資産を選ぶ。

全資産を一度に評価しようとすると時間がかかるので、まず重要度「高」の資産を優先して評価することをすすめる。重要度「中」「低」は次の評価サイクルで順次対応すればいい。

AIを業務で使っている場合は、「利用中のAIサービス」も対象資産に加える。ChatGPT・Claude・社内チャットボットなど、業務に使っているAIサービスを情報資産台帳に追加した上で、リスクアセスメントの対象に含める。

4. ステップ2：脅威と脆弱性を洗い出す（Claudeに壁打ちする）

ここが一番詰まりやすいポイントだ。「脅威って何を書けばいいの？」という問いに対して、Claudeを壁打ち相手にすると効率的に洗い出しができる。

実際に使ったプロンプトの例を紹介する。

「当社は従業員30名の中小企業で、顧客情報データベースを社内サーバーで管理しています。このデータベースに対する情報セキュリティ上の脅威と脆弱性を、それぞれ5つずつ洗い出してください。」

Claudeは汎用的な脅威リストではなく、こちらが提示した状況に合わせた脅威・脆弱性を提案してくれる。そこから「うちではこの脅威は現実的か？」を自分で判断する——この壁打ちプロセスが重要だ。

AIが出した案をそのまま採用するのではなく、自社の実態に合わせて「これはある」「これはうちには当てはまらない」と取捨選択する。この作業こそが、形式ではなく実質のあるリスクアセスメントにする。

5. ステップ3：リスク値を算出する（発生可能性×影響度）

脅威と脆弱性が洗い出せたら、それぞれに「発生可能性」と「影響度」を付ける。

発生可能性：1（ほとんど発生しない）／2（発生することがある）／3（頻繁に発生する）
影響度：1（業務への影響小）／2（一部業務に支障）／3（業務停止・重大損害）

リスク値は「発生可能性×影響度」で算出する。テンプレートでは自動計算が設定されているので数値を入れるだけだ。

リスクレベルの目安：6〜9は「高」（優先対応必須）、3〜5は「中」（計画的に対応）、1〜2は「低」（許容範囲）。

数値のつけ方に迷ったら、ここでもClaudeに壁打ちできる。「このケースだと発生可能性は2と3のどちらが妥当か？」と聞くと、判断の根拠を整理してくれる。

6. ステップ4：対応策を決める（許容・軽減・回避・移転）

リスク値が算出できたら、各リスクに対する対応策を決める。対応策は4つの選択肢がある。

軽減：リスクを下げる対策を実施する（例：パスワードポリシーの強化・アクセス権限の見直し）。
許容：リスクを認識した上で現状を受け入れる（リスク値が低い場合）。
回避：リスクの原因自体をなくす（例：該当業務をやめる・システムを廃止する）。
移転：リスクを第三者に移す（例：サイバー保険に加入する）。

リスクレベルが「高」のものは必ず「軽減」の対応策を定め、期限と担当者を設定する。「許容」を選ぶ場合でも、「なぜ許容するか」の理由を記録しておくことが重要だ。審査ではこの判断根拠を問われる。

7. AIリスクも同じシートで評価する

ISO42001にも対応するなら、同じシートにAIリスクを追加する。

具体的なAIリスクの例をいくつか挙げる。

・AIサービスへの機密情報の入力：脅威は「入力データの漏洩」、脆弱性は「利用ルールの不備・従業員の認識不足」。
・AIの出力結果の誤り：脅威は「誤った情報に基づく業務判断」、脆弱性は「レビュー体制の不備」。
・AIサービスの停止：脅威は「業務で利用しているAIが使えなくなる」、脆弱性は「代替手段の未整備」。

これらも発生可能性×影響度で評価し、既存の情報セキュリティリスクと一つのシートで管理すると、組織全体のリスクが一目で把握できる。

「一人で悩まない」がリスクアセスメントのコツ

リスクアセスメントで一番よくない状態は、「担当者が一人で悩んで手が止まること」だ。

Claudeを壁打ち相手にすることで、「何を書けばいいか」のゼロスタート問題が解消される。AIが出した叩き台を自社の実態に合わせて修正する——このプロセスなら、リスクアセスメントが初めてでも前に進める。

もちろん、最終的な判断は人間がする。AIの提案を鵜呑みにするのではなく、「うちではこれが現実的か？」を自分で考えることが、意味あるリスクアセスメントになる条件だ。

→ ISO27001の取得費用はいくらかかるか——コンサル費・審査費・維持費の現実

関連記事

・ISO42001の管理策38項目——中小企業はどこから始めるか
AIリスクの管理策を優先度順に整理した記事。

・棚卸しから始めるISO27001——情報資産台帳をAIで効率化した話
リスクアセスメントの前提となる情報資産台帳の作成方法。

・ISO27001の取得費用はいくらかかるか——コンサル費・審査費・維持費の現実
リスクアセスメントを外注するか自分でやるかの判断材料。

「自社は無事」でも顧客情報は漏れる——サプライチェーンリスクの教訓と中小企業の備え

「自社のネットワークは無事だった。でも、顧客情報は漏れていた。」——サプライチェーンリスクの怖さは、ここにある。

最近、僕の周りでもクラウドの委託先管理に関する相談が増えている。「このサービス、セキュリティ的に大丈夫ですかね？」「ベンダーに任せているから安心ですよね？」——こういう質問を受けるたびに、今回の事例を思い出すことになりそうだ。

米国の携帯電話事業者で、予約サイトから顧客の個人情報がインターネット上でアクセス可能な状態になっていた事例が明らかになった。原因は自社のシステムではなく、業務を委託していたサードパーティのプラットフォームに存在した脆弱性だった。

さらに問題を深刻にしたのは、外部の研究者がこの脆弱性を報告したにもかかわらず、企業側がそれを無視し続けたことだ。最終的にインフルエンサーが公に問題を指摘するまで、対応が行われなかった。

今回はこの事例を、ISO27001（ISMS）の観点から「中小企業が学ぶべき3つの教訓」として整理する。

目次

1. 何が起きたか：事実の整理
2. 教訓①：サプライチェーンリスクは「自社の問題」だ
3. 教訓②：脆弱性報告を無視した代償
4. 教訓③：クラウドサービスを「安全に使い続ける」ための備え
5. 中小企業が明日からできる5つの確認事項
6. 「うちは大丈夫」が一番危ない

1. 何が起きたか：事実の整理

まず事実を整理する。

米国の携帯電話事業者の予約サイトにおいて、顧客の個人情報——氏名・メールアドレス・住所・電話番号・注文識別子——がインターネット上でアクセス可能な状態になっていた。クレジットカード情報やパスワードの漏洩は現時点で確認されていないが、すでにデータがスクレイピング（自動収集）され、ダークウェブに流出している懸念が指摘されている。

ポイントは2つある。第一に、直接の原因は自社のネットワークではなく、業務を委託していたサードパーティのプラットフォーム側の脆弱性だったこと。第二に、外部のセキュリティ研究者がこの脆弱性を発見し企業に報告したが、応答がなかったこと。最終的にYouTuberがこの問題を公にしたことで対応が始まった。

この事例から中小企業が学ぶべき教訓は明確だ。以下、3つの観点で整理する。

2. 教訓①：サプライチェーンリスクは「自社の問題」だ

「自社のシステムは安全だった」——これは事実かもしれない。でも、顧客にとっては「どこから漏れたか」は関係ない。「あの会社に預けた情報が漏れた」という事実だけが残る。

ISO27001では、サプライヤーとの関係における情報セキュリティを管理することを要求している。附属書Aの管理策では「供給者関係における情報セキュリティ」として、外部委託先のセキュリティ管理を明確に求めている。

現場で見ていると、クラウドサービスやSaaSを「便利だから」「みんな使っているから」と導入する中小企業は多い。でも、そのサービスがどんなセキュリティ対策を取っているか・データがどこに保管されているか・インシデント時にどう対応してくれるかを確認している会社は極めて少ない。

実際にシステム導入の現場で遭遇したケースを一つ挙げる。ある中小企業が顧客管理用のSaaSを導入していたが、契約書にセキュリティ条項が一切なかった。利用規約すら読んでおらず、「有名なサービスだから大丈夫だと思っていた」と担当者は言った。確認してみると、データの保管先は海外のデータセンターで、インシデント時の通知義務も定められていなかった。もしそのサービスから情報漏洩が起きていたら、「いつ漏れたのか」すら知る手段がなかった——そういう状態だ。

サードパーティに業務を委託した時点で、そのサードパーティのリスクは自社のリスクになる。「任せているから安心」ではなく、「任せているからこそ確認する」が正しい姿勢だ。

→ セキュリティは「機器」より「仕組み」で決まる——ISO27001を現場目線で解説

3. 教訓②：脆弱性報告を無視した代償

この事例でもう一つ深刻なのは、インシデントレスポンス（初動対応）の機能不全だ。

セキュリティ研究者が脆弱性を発見して企業に報告を試みたが、応答がなかった。結果、第三者（YouTuber）が公に問題を指摘するまで対応が行われなかった。この間にデータがスクレイピングされている可能性がある。

もし最初の報告に対して即座に対応していれば、被害は最小限に抑えられたかもしれない。初動の遅れが被害を拡大させた典型例だ。

ISO27001では「情報セキュリティインシデント管理」として、インシデントの報告・対応・記録の手順を整備することを要求している。これは外部からの報告も含む。外部の善意の報告者（セキュリティ研究者）からの連絡を受け取れる窓口と、それを適切にエスカレーションする体制が必要だ。

中小企業に聞きたい。あなたの会社のWebサイトに「セキュリティに関する問い合わせ先」は明記されているか？報告を受けた場合に誰がどう判断するか、手順は決まっているか？——この2点が整備されていないなら、今回の事例と同じリスクを抱えている。

4. 教訓③：クラウドサービスを「安全に使い続ける」ための備え

今回の事例では、サードパーティの「プラットフォームプロバイダー」側の脆弱性が原因だった。これはクラウドサービスやSaaSを利用するすべての企業にとって、他人事ではない話だ。

クラウドサービスを安全に利用するために、日頃から以下の備えが必要だ。

① 委託先の選定時にセキュリティ要件を確認する
SOC2レポート・ISO27001認証の有無・データ保管場所・暗号化の方式——契約前にこれらを確認し、記録として残しておく。「有名だから安全」は判断基準にならない。

② 契約書にセキュリティ条項を入れる
インシデント発生時の通知義務・通知までの時間制限・データの取り扱いに関する条項——これらを契約書に含めることで、いざという時に「聞いていない」を防ぐ。

③ 定期的にサービスのセキュリティ状況を確認する
導入時だけ確認して放置しない。年1回は委託先のセキュリティ状況を再確認し、変更がないか確認する。ISO27001のサーベイランス審査と同じサイクルで見直すのが効率的だ。

→ AIを使ったリスクアセスメントの実践——Claudeと一緒にシートを埋めてみた

5. 中小企業が明日からできる5つの確認事項

今回の事例を受けて、明日からすぐに確認できることを5つに絞った。

① 自社が利用しているクラウドサービス・外部委託先の一覧を作れるか？
一覧がなければ、まず棚卸しから始める。誰が何を使っているか把握できていない状態はリスクそのものだ。

② 委託先のセキュリティポリシーを確認したことがあるか？
利用規約の中にデータの取り扱い・保管・削除に関する記載があるか確認する。

③ 自社サイトに「セキュリティに関する連絡先」を明記しているか？
外部からの脆弱性報告を受け取れる窓口がないと、今回と同じ事態が起きうる。

④ 脆弱性の報告を受けた場合の対応手順は決まっているか？
誰に報告し、誰が判断し、いつまでに初動対応するか——この手順が明文化されていれば、初動の遅れを防げる。

⑤ インシデント発生時の対外的な連絡フローは整備されているか？
顧客への通知・監督官庁への報告・メディア対応——これらの手順が事前に決まっていると、パニックの中でも冷静に対応できる。

「うちは大丈夫」が一番危ない

今回の事例で最も重要な教訓は、「自社のシステムを守るだけでは不十分」ということだ。業務を委託している先のセキュリティも、結局は自社の責任になる。

そして、外部からの報告を受け取り、迅速に対応できる体制がなければ、小さな脆弱性が致命的な情報漏洩事故に発展する。

「うちは小さい会社だから狙われない」「うちのシステムは大丈夫」——この思い込みが一番危険だ。攻撃者が狙うのは「弱いところ」であって「大きいところ」ではない。中小企業こそ、サプライチェーンリスクとインシデント対応体制を今一度確認してほしい。

→ ISO27001にコンサルは必要か——正直に言うと、大半の会社はいらない

関連記事

・セキュリティは「機器」より「仕組み」で決まる——ISO27001を現場目線で解説
サプライチェーンリスクを含むISO27001の基本的な考え方と仕組み。

・AIを使ったリスクアセスメントの実践——Claudeと一緒にシートを埋めてみた
サプライチェーンリスクを含むリスクアセスメントの実践手順。

・ISO27001にコンサルは必要か——正直に言うと、大半の会社はいらない
インシデント対応体制の整備でスポット支援が活きる場面について。

ISO42001の管理策38項目——中小企業はどこから始めるか

「ISO42001の管理策、38項目あるけど全部やるの？」——答えは「全部やる必要はない」だ。

前回の記事でISO27001とISO42001の統合管理について書いた。今回はその続きとして、ISO42001の附属書Bに記載されている管理策38項目を中小企業向けに噛み砕いて解説する。

38項目と聞くと構えてしまうが、すべてを等しく実施する必要はない。自社のAI利用状況に合わせて「どこから手をつけるか」を判断することが大事だ。

→ ISO27001 × ISO42001——2つの規格を統合管理する現実的なアプローチ

目次

1. 38項目の全体像：4つのカテゴリに分けて理解する
2. カテゴリA：AIの方針と組織体制（優先度★★★）
3. カテゴリB：AIシステムのライフサイクル管理（優先度★★☆）
4. カテゴリC：データと情報管理（優先度★★★）
5. カテゴリD：透明性・説明可能性・人間の関与（優先度★★☆）
6. 中小企業が最初に取り組むべき10項目
7. 完璧を目指さず「まず10項目」から始める

1. 38項目の全体像：4つのカテゴリに分けて理解する

ISO42001の附属書Bに記載されている管理策は38項目ある。一つずつ読んでいくと途方に暮れるので、4つのカテゴリに分けて理解するのがおすすめだ。

カテゴリA：AIの方針と組織体制——AIをどう使うかの基本方針と、それを管理する体制。
カテゴリB：AIシステムのライフサイクル管理——AIの導入・運用・廃止までの管理プロセス。
カテゴリC：データと情報管理——AIに入力するデータ・出力するデータの管理。
カテゴリD：透明性・説明可能性・人間の関与——AIの判断をどう説明するか、人間がどう関わるか。

すべてのカテゴリを均等に対応する必要はない。自社がAIをどの程度使っているかによって、優先度が変わる。

2. カテゴリA：AIの方針と組織体制（優先度★★★）

ここが最優先だ。AIを使うすべての組織に共通して求められる項目が集中している。

AI方針の策定：組織としてAIをどう使い、何を禁止するかを明文化する。すでに生成AIガイドラインを整備している組織は、それをISO42001の方針文書として位置づけ直すだけで対応できる。

役割と責任の明確化：AIの利用に関する責任者を誰にするか。中小組織ではISMS管理者がAIの責任者を兼務するケースが多い。

AIリスクアセスメントの実施：AIを使うことでどんなリスクがあるかを評価する。これはISO27001のリスクアセスメントを拡張する形で対応できる。

→ 中小企業の生成AI利用ガイドライン——今日から始められる5つのアクション

3. カテゴリB：AIシステムのライフサイクル管理（優先度★★☆）

AIを自社で開発している組織には必須の項目が多い。ただし、AIサービスを「利用しているだけ」の組織は、このカテゴリの多くを「適用除外」にできる。

自社でAIモデルを開発・学習させている場合は、モデルの設計・テスト・検証・監視のプロセスを文書化する必要がある。

一方、ChatGPTやClaudeなどの外部AIサービスを業務に利用しているだけの場合は、「どのサービスをどの業務で使っているか」「利用ルールは何か」を管理していれば基本的にOKだ。

中小企業の大半は後者のケースなので、このカテゴリは必要な項目だけを選んで対応すれば良い。

4. カテゴリC：データと情報管理（優先度★★★）

データ管理はAIの方針と並んで最優先のカテゴリだ。AIに入力するデータ・AIから出力されるデータの両方に管理が求められる。

入力データの管理：AIに個人情報を入力していないか。機密情報をクラウドのAIサービスに送信していないか。この確認は情報資産台帳と連動させて管理できる。

出力データの品質管理：AIが生成した文書やコード・回答をそのまま業務に使っていないか。人間のレビューを経ているか。「AIの出力を鵜呑みにしない」というルールを組織内で徹底することがここでの管理策だ。

データの保持と削除：AIサービスに送信したデータがどこに保存され、いつ削除されるかを把握しているか。サービス提供元の利用規約・データポリシーを確認し、記録しておくことが求められる。

5. カテゴリD：透明性・説明可能性・人間の関与（優先度★★☆）

このカテゴリはAIの「ブラックボックス問題」に対応するものだ。中小企業にとっては少しハードルが高く感じるかもしれない。

透明性：AIを使っていることを関係者（顧客・取引先・従業員）に適切に伝えているか。たとえば「このメールの文案はAIを使って作成しました」という開示が求められる場面がある。

説明可能性：AIの判断理由を説明できる状態にあるか。自社開発のAIモデルでは重要だが、外部AIサービスの利用ではサービス提供元の説明に依存する部分が大きい。

人間の関与：AIの判断に対して人間が最終的な意思決定を行う体制があるか。「AIが出した答えをそのまま採用するのではなく、人間が確認・判断する」——この原則を組織として明確にすることが管理策の核心だ。

6. 中小企業が最初に取り組むべき10項目

38項目のうち、中小企業が最初に取り組むべき項目を10個に絞ると以下のようになる。

① AI利用方針の策定：「何に使い、何に使わないか」の明文化。
② AI利用に関する責任者の任命：ISMS管理者との兼務でOK。
③ AIリスクアセスメントの実施：情報セキュリティリスクと統合して評価。
④ AI利用台帳の作成：どのAIを・誰が・何の目的で使っているかの一覧。
⑤ 入力データの管理ルール：個人情報・機密情報のAI入力禁止ルール。
⑥ 出力データのレビュー体制：AIの出力を人間が確認するプロセス。
⑦ 従業員への教育：AIリテラシー教育の実施。
⑧ 利用サービスのデータポリシー確認：送信データの保存・削除の把握。
⑨ AIの利用に関する透明性の確保：関係者への適切な開示。
⑩ インシデント対応へのAIリスクの追加：AI起因のインシデントへの対応手順。

完璧を目指さず「まず10項目」から始める

38項目を見て「全部対応しないとダメだ」と思う必要はない。ISO42001は自社のAI利用状況に応じて、適用する管理策を選択できる設計になっている。

中小企業がAIを「利用」している段階なら、上記の10項目をカバーするだけで実質的なAIリスク管理は大幅に向上する。完璧を目指して動けなくなるより、「まず10項目」から始める方がずっと価値がある。

次回は、リスクアセスメントの実践として、Claudeを使って実際にAIリスクを含むアセスメントシートを埋める手順を紹介する。

関連記事

・ISO27001 × ISO42001——2つの規格を統合管理する現実的なアプローチ
2つの規格をどう統合するかの全体設計を解説した前編記事。

・ISO 42001とは何か？AIマネジメント規格を中小企業向けに現場目線で解説
ISO42001の基本概念を解説した入門記事。

・中小企業の生成AI利用ガイドライン——今日から始められる5つのアクション
管理策の「AI利用方針の策定」に直結する実践記事。

「AIがコンサルを不要にする」は半分だけ正しい——本当に必要なのは"伴走者"だ

「AIがあればコンサルはいらない」——この言葉が、最近あちこちで聞こえるようになった。

マッキンゼーが数千人規模の人員削減を計画し、アクセンチュアもAIを使わない社員を昇進させないという方針を打ち出した。「コンサルの仕事の3割はAIで代替できる」という専門家の指摘もある。

セキュリティコンサルタントとして活動している僕自身、この流れを無視するわけにはいかない。でも現場で感じているのは、「AIがコンサルを不要にする」は半分だけ正しいということだ。残りの半分について、正直に書く。

→ ISO27001にコンサルは必要か——正直に言うと、大半の会社はいらない

目次

1. 現実：AIは中堅コンサルタントのレベルに達した
2. AIが代替した部分：調査・整理・テンプレート
3. AIが代替できない部分：意思決定の伴走
4. 「自分でやれる」が落とし穴になるケース
5. 必要なのは「答えを出す人」ではなく「伴走者」だ
6. フルコンサルから「スポット伴走」へ
7. AIを使いこなせる人が横にいること——それが新しいコンサルの形だ

1. 現実：AIは中堅コンサルタントのレベルに達した

まず事実を認めなければならない。AIは確実にコンサルタントの仕事を侵食している。

大手コンサルファームで実際にAIが行っているのは、論点整理・情報収集・切り口の導出・レポートのドラフト生成——これらはかつて中堅コンサルタントが担っていた業務そのものだ。

元BCGのコンサルタントが「5年後の話だと思っていたことが今年の話になった」と述懐しているが、この加速度は僕も体感している。1年前と今とでは、AIにできることの幅が全く違う。

2. AIが代替した部分：調査・整理・テンプレート

具体的にAIが代替した——あるいは代替しつつある——コンサル業務を整理する。

情報収集と調査：業界動向・競合分析・法規制の調査は、AIが圧倒的に速い。人間が数日かけていた調査が、数時間で終わる。

フレームワークの適用と整理：SWOT分析・PEST分析・リスクマトリクスの作成などは、AIの得意分野だ。構造化された分析結果を瞬時に出してくれる。

テンプレート的な文書作成：規程・手順書・報告書の叩き台を作る作業は、もはやAIで十分だ。僕自身、クライアント向けの文書ドラフトの多くをClaudeで作成している。

これらの業務を「コンサルの価値」として高額な費用を請求していたコンサルタントは、確実に淘汰される。ここは認めなければならない。

3. AIが代替できない部分：意思決定の伴走

では、AIが代替できない部分は何か。

「この会社の、この状況で、この判断は妥当か」を一緒に考えること——これはAIにはまだできない。

AIは汎用的に「こういう場合はこうすべきです」と回答する。でも現場では「社長がセキュリティに興味がない」「担当者が来月異動する」「予算が来期まで出ない」という個別の事情がある。この事情を踏まえた上で「今どう動くか」を一緒に考えるには、組織の文脈を理解している人間が必要だ。

さらに言えば、内部統制の観点から、判断の独立性を担保する外部の人間の存在は、AIでは代替できない。自分で調べて、自分で判断して、自分で実行する——この構造は内部統制として弱い。外部の人間がプロセスに関与することの価値は、AIの時代でも変わらない。

4. 「自分でやれる」が落とし穴になるケース

AIがあれば自分でできる——その判断自体は間違っていない。実際、多くの業務はAIの力を借りれば自力で進められるようになった。

問題は、「自分でやれる」と「正しくやれている」は別の話だということだ。

AIが出したリスクアセスメントの結果を「これで大丈夫だろう」と採用する。AIが書いたセキュリティ規程を「よくできているから」とそのまま使う。AIが提案した管理策を「AIが言うなら」と実装する——このプロセスに誰もチェックを入れていない状態は、実はかなり危険だ。

AIの出力を正しく評価し、自社の実態に合っているか判断できる「目利き」が横にいるかどうか——これが結果の品質を左右する。

5. 必要なのは「答えを出す人」ではなく「伴走者」だ

ここまで書いてきたことを整理すると、コンサルタントの役割は明確に変わった。

昔のコンサル：答えを持ってくる人
調査して、分析して、「こうすべきです」と提案する。この役割はAIが代替した。

これからのコンサル：プロセスに伴走する人
AIと一緒に進める担当者の横にいて、判断の妥当性を確認し、意思決定を支援し、プロセスの品質を担保する。

「伴走」という言葉が最近よく使われるが、これは単に「一緒にいる」という意味ではない。AIの出力を正しく評価し、組織の実態に合わせた判断ができ、内部統制上の独立性を持った外部の人間がプロセスに関与すること——これが伴走の本質だ。

6. フルコンサルから「スポット伴走」へ

伴走の形も変わってきている。フルタイムでプロジェクトに張り付くフルコンサルは、中小組織では費用対効果が合わない。

AIを活用することで、担当者が自力で進められる範囲が大幅に広がった。だからこそ、「詰まったときだけ相談できる」「判断に迷ったときだけ壁打ちできる」というスポット型の伴走が合理的な選択肢になっている。

適用範囲の設定で迷ったとき。リスクアセスメントの結果が妥当か不安なとき。内部監査の初回で進め方が分からないとき——こういう「ピンポイントの困りごと」に対応するスポット伴走は、AIの時代だからこそ価値が上がっていると感じている。

→ ISO27001 × ISO42001——2つの規格を統合管理する現実的なアプローチ

AIを使いこなせる人が横にいること——それが新しいコンサルの形だ

「AIがコンサルを不要にする」——これは半分正しい。調査・整理・テンプレートの仕事を高額で請求する旧来型のコンサルは、もう必要ない。

でも残りの半分、AIを正しく使いこなし、その出力を評価でき、組織の文脈に合わせた判断を支援できる人間の価値——これはむしろ上がっている。

AIがどれだけ賢くなっても、「この会社の、この担当者の、この状況で、今何をすべきか」を一緒に考えられる人間は必要だ。それがこれからのコンサルの形であり、僕自身が目指しているポジションでもある。

→ AIツールの「企業姿勢」で選ぶ時代——僕がClaudeを使い始めた話

関連記事

・ISO27001にコンサルは必要か——正直に言うと、大半の会社はいらない
コンサルの必要性を3パターンに整理した記事。本記事の前提として読むと理解が深まる。

・ISO27001 × ISO42001——2つの規格を統合管理する現実的なアプローチ
AIを業務に組み込む時代の新しい規格対応。スポット伴走が活きる場面の具体例。

・AIツールの「企業姿勢」で選ぶ時代——僕がClaudeを使い始めた話
僕自身がAIをどう選び、どう使っているかの原点記事。

ISO27001 × ISO42001——2つの規格を統合管理する現実的なアプローチ

「ISO27001を取ったけど、AIのリスク管理もやらないといけない。ISO42001も必要？」——この問いが増えている。

ISO27001（情報セキュリティ）とISO42001（AIマネジメント）——2つの規格が視界に入ってくる会社が増えている。AIを業務に導入する以上、情報セキュリティだけでなくAI固有のリスクにも向き合う必要が出てきた。

でも、2つの規格を別々に構築・運用するのは中小組織にとって現実的じゃない。今回は「2つの規格をどう使い分け、どう統合するか」を整理する。

→ ISO 42001とは何か？AIマネジメント規格を中小企業向けに現場目線で解説

目次

1. 2つの規格は何が違うのか：守備範囲の整理
2. 共通点が多い：統合管理が成立する理由
3. 統合のアプローチ：ISMSを土台にAIを乗せる
4. リスクアセスメントの統合：情報資産＋AIリスクを一本化する
5. 文書体系の統合：規程を二重に作らない
6. 内部監査の統合：1回の監査で両方カバーする
7. 中小組織こそ統合管理が合理的だ

1. 2つの規格は何が違うのか：守備範囲の整理

まず前提を整理する。ISO27001とISO42001は別の規格だが、目的も構造も近い。

ISO27001は情報セキュリティマネジメントシステム（ISMS）の規格だ。組織の情報資産を機密性・完全性・可用性の観点で保護する仕組みを定める。対象は「情報」全般だ。

ISO42001はAIマネジメントシステム（AIMS）の規格で、2023年に発行された新しい規格だ。AIシステムの開発・提供・利用に伴うリスクを管理する仕組みを定める。対象は「AIシステム」に特化している。

守備範囲は異なるが、マネジメントシステムとしての構造は共通している。これが統合管理を可能にする理由だ。

2. 共通点が多い：統合管理が成立する理由

ISO27001もISO42001も、ISOのマネジメントシステム規格に共通する「附属書SL」という上位構造に基づいている。つまり、以下の要素が両方に存在する。

リーダーシップとコミットメント・リスクアセスメント・管理策の実施・内部監査・経営者レビュー・継続的改善——この骨格が同じだから、2つの規格を一つの管理体系で運用できる。

別々に構築すると、文書が二重になり、監査が二度必要になり、担当者の負担が倍増する。中小組織でこれは現実的ではない。

3. 統合のアプローチ：ISMSを土台にAIを乗せる

統合の考え方はシンプルだ。既存のISMS（ISO27001）を土台にして、AIに関するリスク管理をその上に乗せる。

ISO27001をすでに取得している組織なら、ISMSの枠組みは整っている。そこにISO42001が求める「AI固有のリスク評価」「AIのライフサイクル管理」「透明性・説明可能性への対応」を追加する形で統合できる。

ゼロからISO42001を構築するより、ISMSの延長線上にAIマネジメントを位置づける方が、文書も体制も効率的だ。

4. リスクアセスメントの統合：情報資産＋AIリスクを一本化する

リスクアセスメントは両規格の中核だ。統合する場合、情報資産に対するリスクとAIシステムに対するリスクを一つのアセスメントシートで管理できる。

具体的には、既存のリスクアセスメントシートに「AIリスク」の列を追加する形で対応できる。

AIリスクの例としては、AIモデルへの入力データに個人情報が含まれるリスク・AIの出力結果が誤っている場合の業務影響・AIサービスの可用性が低下した場合の業務停止リスク・AIの判断プロセスが説明できないリスク——こういったAI固有のリスクを、既存の情報セキュリティリスクと並べて評価する。

別々のシートで管理するより、一つのシートで「情報セキュリティリスク」と「AIリスク」を横並びに見る方が、対応の優先順位が判断しやすい。

5. 文書体系の統合：規程を二重に作らない

文書の統合は実務上最も効果が大きい。情報セキュリティポリシーの中にAIに関する方針を含める形にすれば、AIポリシーを別文書で作る必要がなくなる。

具体的な統合方法としては、情報セキュリティポリシーに「AIシステムの利用に関する方針」の章を追加する。リスクアセスメント手順書にAIリスクの評価基準を追加する。教育計画にAIリテラシー教育を組み込む——新しい文書を作るのではなく、既存文書にAIの章を足すのが効率的なアプローチだ。

→ 中小企業の生成AI利用ガイドライン——今日から始められる5つのアクション

6. 内部監査の統合：1回の監査で両方カバーする

内部監査も統合できる。ISO27001の内部監査チェックリストにAI関連の確認項目を追加するだけで、1回の監査で両規格の要求事項をカバーできる。

追加すべきAI関連の監査項目としては、AI利用に関する方針が周知されているか・AIの入出力データの管理が適切か・AIの利用状況が記録されているか・AIの判断結果に対する人間のレビュー体制があるか——こういった項目を既存のチェックリストに組み込む。

監査を年2回別々に実施するのと、1回で統合して実施するのでは、担当者の負荷が全く違う。中小組織では統合監査一択だと思っている。

中小組織こそ統合管理が合理的だ

大企業ならISO27001とISO42001を別々のチームで運用することも可能だ。でも中小組織では、担当者もリソースも限られている。2つの規格を別々に回す余裕はない。

ISMSを土台にAIマネジメントを統合することで、文書は一本化され、監査は1回で済み、担当者の負担は最小化される。これは妥協ではなく、合理的な設計だ。

次回は、ISO42001が具体的にどんな管理策を求めているかを、中小企業向けに噛み砕いて解説する。

→ セキュリティは「機器」より「仕組み」で決まる——ISO27001を現場目線で解説

関連記事

・ISO 42001とは何か？AIマネジメント規格を中小企業向けに現場目線で解説
ISO42001の基本的な考え方と全体像を解説した入門記事。

・中小企業の生成AI利用ガイドライン——今日から始められる5つのアクション
AIマネジメントの第一歩として、すぐに始められるガイドライン整備の話。

・セキュリティは「機器」より「仕組み」で決まる——ISO27001を現場目線で解説
統合管理の土台となるISO27001の基本。