>
>
公開日
最終更新日
Cursorでは間接プロンプトインジェクションの脆弱性やGhostApprovalの欠陥が発見され修正されているため、AIコーディングエージェントは便利な開発支援ツールとしてではなく、権限を持つ外部接続ソフトウェアとして統制します。
本記事は、AIコーディングツールの導入とガバナンス統制を担う情報システム部門の管理者を対象にしています。AIがリポジトリ、SaaS、ローカル端末へ接続する環境では、利用申請の有無だけではリスクを把握できません。ツール本体、OAuth認可、MCPサーバー、実行権限を分けて管理し、Admina MCPによる参照と既存のMDM、EDR、CASB、IdPを組み合わせることが現実的です。
IPAやデジタル庁の公開資料、国内企業の導入事例を踏まえ、情シスが30日以内に始める棚卸しと、90日以内に整備するポリシー・監査運用を具体化します。
Admina MCPとは
Admina MCPとは、マネーフォワード Adminaに連携されたSaaS、アカウント、デバイスの管理情報を、MCP対応のAIツールやAIヘルプデスクから自然言語で参照するための連携手段です。
本記事のポイント
Cursorの危険性は、生成コードの品質だけでなく、間接プロンプトインジェクションや承認回避を含む実行経路にあります。
Admina MCPは、Adminaに連携されたSaaS・アカウント・デバイスの管理情報を参照する手段であり、端末上の全MCPサーバーを直接検知するものではありません。
シャドーAI対策は、SaaS可視化、OAuth認可の棚卸し、端末・ネットワーク制御をMDM・IdP・CASB等で分担させて進めます。
Model Context Protocolは、AIモデルが外部のデータソースやツールを一定の仕様で利用するためのプロトコルです。従来は、情シスが個別APIを開発し、画面ごとに検索条件を設定して台帳を確認する必要がありました。MCP対応のAIクライアントでは、許可されたツールを介して「退職者に紐づくSaaSアカウントを確認したい」「利用中のサービス一覧を取得したい」といった問い合わせを、会話形式で管理データに照会できます。
Admina MCPの参照範囲
Adminaの公式サポート案内（Admina公式サポートページ）では、Admina MCPサーバーをAIヘルプデスクに連携すると、デバイス情報を取得するget_devices、ユーザー情報を取得するget_identities、利用SaaS一覧を取得するget_services、サービスアカウントやユーザー別アカウントを取得するツールを利用できると説明しています。つまり、管理者が保有する台帳情報をAIが勝手に書き換える仕組みではなく、まずは参照と問い合わせ対応を効率化する構成です。
Adminaの公式サポート情報（Remote MCP仕様ページ）では、Remote MCPのget_servicesは、Adminaに連携済みのサービス一覧とアカウントのプレビューを取得する参照専用ツールとして案内されています。AIに管理操作を一任するのではなく、台帳照会、棚卸し候補の抽出、ヘルプデスクの一次回答に用途を絞ると、導入時の権限設計を単純化できます。
情シスでの利用場面
利用価値が出やすいのは、入退社対応、SaaS棚卸し、問い合わせ一次対応です。たとえば退職処理では、人事情報、IdP、SaaS台帳、貸与端末の情報が別々に存在すると、確認漏れが起こります。Adminaに連携済みの情報をAI経由で照会すれば、担当者は対象者に紐づくアカウントと端末の確認を始めやすくなります。
一方で、AIの回答をそのまま削除処理やアカウント停止の根拠にしてはいけません。参照結果は棚卸し候補として扱い、アカウント所有者、業務継続性、共有アカウントかどうかを確認したうえで、承認済みのワークフローから停止します。
マネーフォワードiが2023年に実施した1,021社調査（調査レポート）では、事業部門が主体となってSaaSを選定する企業は40.8％でした。また、事業部門が利用するSaaSのほうが全社契約より多いと答えた企業は50.6％に達しています。部門ごとに導入されたサービスが増える状況では、台帳の検索性を高めるMCP連携は有効ですが、参照権限を広げすぎないことが前提になります。
▶ 関連記事: AIエージェントのセキュリティと情シス向けガバナンス実務ガイド
AIコーディングエージェント統制が必要な理由
開発自律化に伴うセキュリティ境界の変容には、利用ツール、接続先、実行権限を継続的に可視化する仕組みが不可欠です。
AIコーディングエージェントは、コード補完だけでなく、ファイルの読み書き、ターミナル操作、外部サービスへの接続、プルリクエスト作成まで担う場合があります。このため、従来の「ソースコードを社外に送らない」というルールだけでは不十分です。どのAIが、どの端末から、どの認可情報を使い、何を実行できる状態かを管理対象に含めます。
AIエージェントの業務活用は国内外で広がっており、情シスが統制設計を後追いにすると、個人契約や非承認の拡張機能が先に定着しやすくなります。
Vibe Codingの業務リスク
Vibe Codingとは、利用者が自然言語で目的を伝え、AIに設計、実装、修正を大きく委ねる開発スタイルです。試作や定型作業では速度を上げられる一方で、利用者が生成物の依存関係、権限、外部通信、データ処理を十分に確認しないまま実行すると、問題の発見が遅れます。
情シスが管理すべきなのは、Vibe Codingそのものの禁止ではありません。本番環境への直接接続、機密データを含むファイルの無制限な読み込み、承認なしの外部MCP接続を禁止し、開発・検証環境では許可済みツールを使えるように分けます。コード生成は許可しても、本番デプロイ、秘密情報の参照、データ削除は人間の承認を必須にする設計が基本です。
Cursorの危険性と間接プロンプトインジェクション
IPAは「情報セキュリティ10大脅威 2026」組織向け解説書（IPA公式PDF、および概要ページはこちら）において、AIコードエディタCursorにおいて、プロジェクト内のファイルに悪意ある指示を埋め込むことで任意コードを実行させる間接プロンプトインジェクションの脆弱性が発見されたと説明しています。同PDFで直接内容を確認し、対策の根拠として参照してください。AIがREADME、設定ファイル、Issue、生成済みコードなどを参照する際、そこに含まれる命令文を利用者の指示と誤認する経路が問題になります。
対策は、プロンプトに「無視してください」と書くことではありません。AIエージェントに渡すリポジトリを信頼済みのものに限定し、外部から取得したコードやドキュメントは隔離環境で確認します。さらに、ターミナル実行、ファイル削除、ネットワーク通信、資格情報へのアクセスは、ツール設定とOS権限の両方で制限します。エージェントの確認画面だけに依存しないことがポイントです。
GhostApprovalと承認境界
IPAは、AIセキュリティ関連資料（IPA公式PDF）において、WizがAIコーディング支援6製品に共通する欠陥パターン「GhostApproval」を公表し（Wiz公式ブログ: GhostApproval解説）、AWS、Cursor、Googleが該当製品にCVEを採番して修正したと紹介しています。この欠陥は、利用者が安全だと認識している承認操作と、実際に実行される操作の境界がずれる可能性を示しました。
修正版を利用していても、承認ダイアログを万能な防御策として扱う失敗は残ります。端末管理ではクライアントのバージョン更新を把握し、脆弱な版の利用を止めます。開発基盤では、本番用の認証情報をローカル端末に常駐させず、短時間で失効する認証情報と権限の小さいロールを使います。AIが誤動作しても影響範囲を限定できる状態が、承認機能より優先されます。
▶ 関連記事: シャドーAIとは？情報漏洩リスクと情シス向け検知・対策ガイド
AI BYODとデータ保護の判断基準
個人契約のAIサービスを業務利用するAI BYODは、禁止通知だけでは減らないため、承認済みの利用経路と送信可能なデータを明文化します。
開発担当者が個人アカウントでコードエディタやチャットAIを使うと、会社が契約主体ではないため、退職時のアカウント停止、ログ保全、利用規約の統一、データ保持条件の確認が難しくなります。SaaS利用数が増えるほど、こうした管理外の経路は見つけにくくなります。
freeeが2025年に公表した調査では、SaaS利用数が2年前と比べて「増えている・現状維持」と答えた企業は95％以上でした。同調査では、経営層がセキュリティに問題意識を持っているという回答は61％でした。利用サービスが増え続ける環境では、現場の利便性と統制の間にある差を、承認済みサービスの提供で埋める必要があります。
学習利用と保持条件の確認項目
「個人向けプランは必ず学習に使われる」「法人プランなら必ず学習されない」と一般化してはいけません。入力データのモデル学習への利用可否、オプトアウトの方法、設定が組織全体に強制されるか、ログの保持期間、データの保存地域、サブプロセッサー、契約終了後の削除条件は、事業者、プラン、契約地域、管理設定によって変わります。
情シスは、調達時にこれらを一枚の確認表にし、法務・セキュリティ部門と判断をそろえます。組織設定で学習利用を無効化でき、管理者がその設定を固定できるなら、承認済み用途に限定して利用を開始します。設定を組織で強制できない場合は、個人情報、顧客データ、未公開のソースコードを投入不可にし、用途を公開情報の要約や検証用データに限定します。
送信データの分類基準
ポリシーには、抽象的な「機密情報を入力しない」ではなく、入力可否を分類して記載します。公開済み資料と匿名化済みのテストデータは、承認済みサービスで利用可能とします。顧客情報、認証情報、秘密鍵、本番ログ、脆弱性情報、未公開のソースコードは、個人アカウントと未承認ツールへの入力を禁止します。社内限定資料は、契約・設定・保存先の条件を満たす法人環境だけで扱う、と定義すると現場が判断しやすくなります。
やってはいけない運用は、個人契約を一律禁止した後に代替手段を示さないことです。開発者が緊急の調査や検証を必要とする場面で承認経路がないと、別の個人サービスへ移ります。利用目的、扱うデータ区分、必要なSaaS接続、利用期限を記録する例外申請を用意し、期限後に再審査する運用へ切り替えます。
▶ 関連記事: MCP企業導入のセキュリティ完全ガイド｜ガバナンスとリスク対策
▲ AIサービスの業務利用におけるデータ保護・学習利用の判断フロー
30日・90日で進めるガバナンス設計
コーディングエージェントの統制は、30日以内に実態を把握し、90日以内に権限・ライセンス・ログを運用へ組み込む順序で進めます。
いきなり全ツールの利用を停止すると、非承認利用を地下化させます。まず利用実態とデータ経路を確認し、危険度が高い接続から制限します。その後、許可済みツールと例外申請を定着させ、定期監査へ移します。
期間 | 担当の中心 | 実施内容 | 残す証跡 |
|---|---|---|---|
30日以内 | 情シス・開発管理者 | 利用中のAIツール、拡張機能、SaaS接続、個人契約、OAuth認可を棚卸しします。本番環境への直接接続と共有トークンを特定します。 | ツール台帳、認可一覧、リスク判定表、停止対象一覧 |
31〜90日 | 情シス・セキュリティ・法務 | 利用ポリシー、データ分類、法人ライセンス、例外申請、ログ保全、退職時の停止手順を定義します。 | 承認ポリシー、設定標準、契約条件確認表、教育記録 |
継続運用 | 情シス・SOC・開発組織 | OAuth認可、端末導入ソフト、未使用ライセンス、管理者権限、異常な外部通信を定期確認します。 | 監査記録、是正履歴、例外期限一覧、インシデント記録 |
利用ポリシーの最低記載事項
ポリシーは、許可ツール名だけで終わらせません。利用可能なデータ区分、禁止する操作、本番環境での権限、人間の承認が必要な操作、MCP接続の申請条件、ログ保存の担当、違反時の停止手順まで記載します。特に「AIが実行したコマンドも利用者の操作として扱う」ことを明文化すると、責任分界が曖昧になりません。
本番環境では、AIエージェントに恒久的な管理者権限を付けず、読み取り専用を原則にします。書き込みが必要な検証は、隔離環境と限定ロールで行い、デプロイはCI/CDの承認フローへ戻します。これにより、AIクライアント、端末、認可トークンのどれか一つが侵害されても、直接の本番破壊につながる経路を減らせます。
データ保護と権限分離
AIコーディングツールに与えるアクセスは、リポジトリ単位、環境単位、操作単位で分けます。開発用リポジトリの閲覧を許可しても、秘密情報を含む設定リポジトリ、運用手順、顧客データ基盤は別権限にします。個人用アクセストークンを共有する運用は、利用者の退職や異動時に追跡できないため廃止し、サービスアカウントには所有者と利用期限を設定します。
ライセンスと監査ログ
ライセンス管理では、契約数ではなく、誰が業務用途で利用しているかを把握します。未使用アカウントが残るとコストだけでなく、退職者アカウントや共有アカウントの見落としにつながります。マネーフォワードiの調査では、未使用の無駄なアカウントがあると答えた企業は78.0％でした。AIツールも月次で利用者、最終利用、付与権限、契約主体を照合します。
ログは、プロンプト本文を無制限に集めるより、利用者、時刻、対象リポジトリ、実行操作、接続先、承認者、エラーを追跡できる形を優先します。顧客情報や秘密情報がログに残るなら、閲覧権限とマスキングを設計します。SIEMへ送れるログがあれば既存の監視基盤に統合し、送れない場合は管理画面またはCSVから定期的に監査記録を保管します。
▶ 関連記事: 情シス主導のAI業務効率化ロードマップ｜業務棚卸しから運用まで【2026年版】
▲ ガバナンス設計を進める3段階のロードマップ
主要AIコーディングツールの統制比較
ツール選定では、生成品質の比較よりも、アクセス制御、監査ログ、学習利用条件、ライセンス管理を同じ軸で評価します。
特定の製品名だけで承認・不承認を決めると、機能更新やプラン変更に追随できません。管理者が確認すべき統制機能を共通の評価表にし、導入時と更新時に同じ基準で判定します。料金、利用可能な管理機能、データ利用条件は変更されるため、契約判断では各社の公式料金・管理ドキュメントで対象プランと契約地域を照合し、その結果を調達記録に残します。
対象 | アクセス制御の確認軸 | ログ取得の確認軸 | 学習利用の確認軸 | ライセンス統制の確認軸 |
|---|---|---|---|---|
Claude Code | 組織管理設定で端末・プロジェクトごとの許可操作を固定できる場合は承認対象とし、固定できない場合は管理者が個別に設定変更できる状態のため、利用を機密データを扱わない用途に限定します。確認先：各プランの管理者ドキュメント（Admin Console）。 | 操作履歴・実行コマンド・外部接続をAPIまたは管理画面から取得できる場合はSIEMへ統合し、取得できない場合は機密データを扱う用途での利用を保留します。確認先：Audit log仕様ページ。 | 法人契約の管理者設定で入力データの学習利用を無効化でき、その設定を組織全体に強制できる場合は承認済み用途に限定して利用を開始し、強制できない場合は公開情報または匿名化済みデータのみ投入可とします。確認先：Data Privacy仕様ページ（対象プラン・契約地域を照合のこと）。 | SSOと退職時の一括停止が管理者画面から実施できる場合は法人ライセンスとして調達し、できない場合は個人アカウントを業務利用させない運用とします。確認先：管理者向けユーザー管理ドキュメント。 |
Cursor | 端末へのアプリ配布、拡張機能の制限、リポジトリ接続範囲、エージェント実行権限をMDMおよびCursor管理設定で制限できる場合は承認対象とし、制限できない場合はOSの権限管理で補完します。確認先：Cursor Business管理ドキュメント。 | 利用者・接続先・操作履歴をAPIまたはログエクスポートで取得できる場合は既存のSIEMへ統合し、取得できない場合は機密データを扱う用途での利用を保留します。確認先：Audit log仕様ページ。 | オプトアウトが可能で、かつその設定を管理者が組織全体に強制できる場合は承認済み用途で利用を開始し、個人設定に委ねる場合は未公開コードや顧客データの投入を禁止します。確認先：Privacy設定ページ（プラン別）。 | 個人契約を法人アカウントへ統合できる場合は移行手順を情シスが案内し、移行できない場合は個人アカウントを業務利用停止として扱います。確認先：Cursor Business移行ガイド。 |
GitHub Copilot | 組織・リポジトリ単位で有効化範囲と利用者グループを管理者が制御できる場合は承認対象とし、組織設定を適用できない個人プランは業務利用停止として扱います。確認先：GitHub Organization設定 › Copilotポリシー。 | 監査ログをGitHub Audit log APIで取得し、リポジトリ側の変更履歴と関連付けられる場合は既存監視へ統合し、取得できない場合は変更履歴の追跡を別途設計します。確認先：GitHub Audit log APIドキュメント。 | 契約プラン別のデータ処理条件をGitHub Data Protectionドキュメントで照合し、学習利用を無効化できるプランを調達条件とします。確認先：GitHub Copilot Trust Center（プラン・契約地域別）。 | 組織所有のライセンスで付与・回収を管理者が一括操作できる場合は法人ライセンスとして調達し、個人所有ライセンスの業務利用は退職時の停止追跡が困難なため認めません。確認先：GitHub Organization › Billing設定。 |
Microsoft Copilot | IdPのグループと条件付きアクセスポリシーが既存のデータアクセス権と連動して反映される場合は既存の認証基盤と統合し、反映されない場合は別途アクセス制御設計が必要です。確認先：Microsoft Entra ID条件付きアクセスドキュメント。 | Microsoft 365管理センターおよびMicrosoft Purview監査基盤でCopilotの操作ログを取得でき、DLP通知と連携できる場合は既存監視へ統合し、取得できない場合は利用範囲を機密データ外に限定します。確認先：Microsoft Purview Audit（Standard/Premium）仕様ページ。 | テナント設定でデータ境界を管理者が固定でき、データ処理の契約条件を確認できる場合は承認済み用途で利用し、確認できない場合は法務・セキュリティ部門との判断をそろえてから調達します。確認先：Microsoft Product Terms（対象テナント地域・プランを照合のこと）。 | 対象ユーザーへのライセンス付与と異動・退職時の回収をMicrosoft 365管理センターから一括操作できる場合は法人ライセンスとして調達し、個人単位の契約は業務利用停止として扱います。確認先：Microsoft 365管理センター › ライセンス管理。 |
設定強制の実装例
設定強制では、許可されないMCPサーバーの接続、承認なしのターミナル実行、未承認の拡張機能導入、個人トークンの利用を技術的に制限します。設定ファイルを各開発者に配布するだけでは、ローカルで変更される可能性があります。MDMによるアプリ配布、OSの権限管理、IdPの条件付きアクセス、リポジトリの保護ルールを組み合わせ、利用者が単独で解除できない層を作ります。
コーディング拒否管理サービスという言葉で探されることがある対策は、AIの利用を一律に拒否する単一製品を指すものではありません。実務では、MDMによる未承認アプリの制御、CASBやSSEによるクラウド利用の把握、IdPによる認証・認可、DLPによるデータ送信制御、開発基盤の承認フローを組み合わせます。機密コードの外部送信を止めたい場合はDLPとネットワーク制御を優先し、未承認ツールの利用実態を把握したい場合はSaaS・端末台帳の棚卸しを先に行います。
Admina MCPによるシャドーAI可視化
Admina MCPは、SaaS・アカウント・デバイスの管理情報をAIから参照し、シャドーAI対策の調査と問い合わせ対応を効率化するための入口です。
シャドーコーディングAIの対策では、端末に導入されたAIクライアント、AIが接続するSaaSへのOAuth認可、MCPサーバーという三つの層を分けます。すべてを一つの製品で監視しようとすると、責任分界が曖昧になります。Adminaは主に利用SaaS、アカウント、デバイスの関係を台帳として把握する層を担い、MCP連携はその情報への参照を支援します。
OAuth Grant棚卸しの進め方
OAuth Grantは、利用者がSaaS上で外部アプリケーションに付与した認可です。AIクライアントやMCPサーバーがGitHub、Slack、Google Workspaceなどへ接続する際、この認可が入口になる場合があります。棚卸しでは、アプリ名だけでなく、認可した利用者、権限の範囲、付与日、最終利用、業務上の所有者、失効方法を記録します。
退職済み利用者、用途不明のサードパーティーアプリ、必要以上に広い権限、所有者が不在の連携は優先して是正します。AI利用を継続する必要がある連携は、個人アカウントではなく組織管理アカウントへ移し、読み取り専用権限から開始します。業務上書き込みが必要と確認できた連携だけを追加審査し、期限と所有者を設定します。
マネーフォワードiの2023年調査（調査レポート）では、シャドーITを完全に検知できている企業は15.3％にとどまりました。一方で、完全に検知できていない、または分からないという回答は合計33.3％でした。棚卸しの目的は、検知率を数字上だけで高めることではなく、見つかった未承認利用を法人契約への移行、認可の縮小、利用停止のいずれかに確実につなげることです。
Admina MCPの検知・参照範囲
Admina MCPが直接扱うのは、Adminaへ連携されている管理情報です。AIクライアントから利用SaaS、ユーザー、デバイス、アカウント情報を照会できるため、情シスは台帳横断の確認作業を短縮できます。ただし、ローカル端末で個人が起動したすべてのMCPサーバープロセスや、ネットワーク外の通信までをAdmina MCPだけで検知するものではありません。
公開情報で確認できる範囲では、Admina MCPのget_servicesは参照専用です。MCPサーバー自体の稼働状況、個別のプロンプト内容、端末上の任意コマンド実行をAdmina MCPが直接検知・停止するという公式仕様は確認できません。端末上の実行状況はEDR・MDM、外部通信はCASB・SSE、認証はIdP、SaaS認可は各サービスの管理機能と組み合わせて確認します。
セキュリティ製品との役割分担
管理領域 | 主な役割 | 情シスの確認結果 |
|---|---|---|
Admina・Admina MCP | SaaS、アカウント、デバイス情報の可視化と参照 | 利用者・サービス・端末の対応関係を台帳化します。 |
IdP | SSO、多要素認証、グループ・条件付きアクセス | 退職者停止と最小権限を適用します。 |
MDM・EDR | 端末のアプリ配布、バージョン管理、実行検知 | 未承認クライアントと脆弱な版を制御します。 |
CASB・SSE・DLP | クラウド利用、外部送信、機密データの制御 | コード・認証情報・個人情報の送信経路を制限します。 |
SIEM・開発基盤 | 監査ログ集約、リポジトリ保護、承認フロー | 異常操作を調査し、本番反映を人の承認へ戻します。 |
国内企業の導入例として、newscastが掲載した事例記事（newscast掲載事例）では、株式会社hokanがマネーフォワード Adminaの導入後、従来は10〜20人規模が必要だったSaaS管理を3人のチームで運用し、確認作業を週1回約30分に短縮したと伝えています。アジアクエスト株式会社も、SaaSアカウントの確認から削除までの時間を約8割削減したと発表しています（PR TIMES掲載事例）。これらは個別企業の事例ですが、台帳を整備してから入退社・棚卸しの運用へ接続することで、管理作業を減らせることを示しています。
▶ 関連記事: シャドーMCP対策ガイド｜AIコーディングが招く新たなデータ漏洩リスクと検知の入口
▲ シャドーAI対策における3つの管理レイヤーとAdmina MCPの位置づけ
導入時の注意点と失敗パターン
AIコーディング統制がうまくいかない原因は、禁止中心のルール、台帳だけで終わる棚卸し、AIへの過剰な権限付与に集約されます。
全面禁止によるシャドー化
もっとも起こりやすい失敗は、リスク説明だけで全AIツールを禁止し、代替サービスや例外申請を用意しないことです。現場は期限のある開発・調査を止められないため、私用端末、個人メールアドレス、ブラウザ拡張機能へ利用が移ります。禁止対象を増やす前に、承認済みツール、利用可能なデータ、申請窓口、審査期限を示し、利用者が正規ルートを選べる状態にします。
台帳と是正の分断
未承認のSaaSやOAuth認可を見つけても、所有者、期限、停止手順が決まっていなければ棚卸しは一度きりで終わります。検出した項目は「法人契約へ移行」「認可を縮小」「利用停止」「継続審査中」のいずれかに分類し、担当者と期限を設定します。月次レビューで期限切れの例外を閉じることで、台帳を運用記録に変えられます。
AIへの管理者権限付与
検証を急ぐために、本番環境の管理者権限や長期間有効なAPIキーをAIクライアントに渡す運用は避けます。間接プロンプトインジェクションや承認回避の問題が発生した際、AIの誤操作がそのまま高権限操作になります。読み取り専用、短期トークン、隔離環境、CI/CDの承認フローへ分ければ、AI活用を止めずに被害範囲を狭められます。
製品名だけでの選定
「このツールなら安全」という選定も失敗につながります。機能はプラン、契約、更新時期で変わるため、アクセス制御、監査ログ、データ利用条件、ライセンス回収、脆弱性情報の受け取り方を調達条件にします。監査ログをAPIまたは管理画面から取得できるなら限定検証に進み、取得できない場合は、機密データを扱わない用途に限定するか、別の監査手段を用意します。
コーディングエージェント統制のよくある質問
導入判断で生じやすい疑問を、情シスの管理対象と実施順序に沿って整理します。
Cursorの危険性への対処
Q：Cursorの危険性にはどのように対処しますか？
A：IPAが説明する間接プロンプトインジェクションとGhostApprovalを前提に、クライアントを最新版へ更新し、信頼できないリポジトリを隔離します。本番権限、秘密情報、恒久トークンをローカルAIクライアントへ渡さず、危険な実行はOS権限とCI/CD承認で止めます。
Admina MCPの参照範囲
Q：Admina MCPで何を検知・参照できますか？
A：Adminaに連携されたSaaS、ユーザー、デバイス、サービスアカウントなどの管理情報をAIから参照できます。公開情報で確認できるget_servicesは参照専用であり、全てのローカルMCPサーバーや端末上の任意実行を直接検知する機能ではありません。
コーディング拒否・制限の実施方法
Q：コーディング拒否管理サービスだけで未承認AIを止められますか？
A：単一のサービスだけで、端末アプリ、ブラウザ拡張、OAuth認可、外部通信、リポジトリ権限を完全に管理することはできません。未承認アプリはMDM・EDR、SaaS認可はIdPと各SaaS管理機能、機密データ送信はDLP・CASB、利用実態はSaaS・端末台帳で分担します。
法人契約への切り替え判断
Q：個人契約を法人契約へ切り替える基準は何ですか？
A：業務データや未公開コードを扱うなら、組織管理、利用者の一括停止、監査ログ、データ利用条件を契約上確認できる法人環境へ移します。これらが確認できない用途は、公開情報または匿名化済みデータだけを扱う限定利用にします。
まとめ
AIコーディングエージェントの統制では、AIを禁止するかどうかではなく、どのデータへ、どの権限で、どの接続先まで許可するかを決めます。Cursorで確認された間接プロンプトインジェクションやGhostApprovalの事例は、確認画面だけに依存せず、権限分離と更新管理を行う必要性を示しています。
30日以内のチェックリスト
利用中のAIクライアント、拡張機能、個人契約、OAuth認可を台帳化します。
本番環境へ直接接続できるAIクライアントと恒久トークンを特定し、読み取り専用または停止へ切り替えます。
AdminaのSaaS・アカウント・デバイス情報を用い、利用者とサービスの対応関係を確認します。
90日以内のチェックリスト
利用ポリシーに、入力可能なデータ区分、禁止操作、例外申請、承認者を記載します。
法人ライセンス、SSO、退職時のアカウント停止、監査ログ保全を運用へ組み込みます。
MDM・EDR、IdP、CASB・DLP、SIEMとAdminaの役割を分け、月次のOAuth認可・未使用アカウント棚卸しを開始します。
まずは未承認のAI利用とOAuth認可を可視化し、所有者不明・高権限・退職者に紐づく項目を是正対象として登録します。この順序なら、開発速度を保ちながら統制の土台を作れます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
