---
title: AIエージェント時代の企業セキュリティ入門_0728
tags: 
author: [connect24h](https://docswell.com/user/connect24h)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4EQY2PQWJP.jpg?width=480
description: 近年、生成AIは、相談相手から業務を実行するAIエージェントへ進化し、企業利用の可能性が大きく広がっています。 一方で、情報漏えい、権限の使い過ぎ、誤操作、外部サービス連携など、新しいリスクも生まれています。 本資料では、AIを止めるのではなく、安全に使いこなすためのゼロトラスト的な導入ポイントをわかりやすく解説します。
published: August 19, 26
canonical: https://docswell.com/s/connect24h/KE1W77-2026-08-19-002524
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4EQY2PQWJP.jpg)

AIエージェント時代の
企業セキュリティ入門
〜 ゼロトラストで考える、安全なAI活用のはじめ方 〜
株式会社エネコム
ITインテグレーション部情報セキュリティビジネスチーム
2026年7月28日
© 2026 Enecom,Inc.


# Page. 2

![Page Image](https://bcdn.docswell.com/page/KJ4WLYN171.jpg)

自己紹介
• 株式会社エネコム
• 情報システム事業本部 ITインテグレーション部 マネージャー
• 濱本常義
同社３０年勤務、５年間は研究開発部門に所属、社内LAN構築、
社内ネットワークポリシー策定、CATVインターネット実験参加、
社内セキュリティ監査業務に携わる。２０００年より、セキュリティ
監査（ペネトレーションテスト含む）およびセキュリティコンサル
ティングなどの業務に従事、現在は上記に加えて標的型メール
訓練、ログ監視、CSIRT運用業務に携わる
• 情報セキュリティポリシー策定、ポリシー教育実績
• 大手公共企業、大手メーカ、情報システムサービス会社、自治体
• LASDEC 高度情報セキュリティ研修講師（2004年広島県、山口県、2005年愛媛県、2006年広島県、2007年広島、高松、鳥
取）
• 経済産業省 学生22歳以下向けイベント、セキュリティ・キャンプ関係講師（2003～2025）
• 情報処理安全確保支援士向け講習会 講師（2017年～）
• マイクロソフトから多数の人に影響を与えた個人に与える賞 MVP(Most Valuable Professional)をWindows-Securityの分野で
12回受賞(2003～2014)
© 2026 Enecom,Inc.
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LE1YL6557G.jpg)

セキュリティ・ミニキャンプin広島をお手伝いしています
実績
• 一般社団法人 広島県情報産業協会
HiBiS 事務局(HISEC)提供
セキュリティ・キャンプ2026ミニ（広島開催）専門講座
2026年12月5日（土）9:00（受付開始8:40）～16:30
セキュリティ・キャンプ2026ミニ（広島開催）一般講座（予定）
2026年12月4日（金）午後
• 過去実績
セキュリティ・ミニキャンプ in 広島 2025（一般講座）
～
セキュリティ・ミニキャンプ in 広島 2016（一般講座）
セキュリティ・ミニキャンプ in 広島 2020（専門講座）
• 講師参加
セキュリティ・キャンプ九州 in 福岡 2014
セキュリティ・ミニキャンプ in 福岡 2013第2弾
セキュリティ・ミニキャンプ in 福岡 2013
© 2026 Enecom,Inc.
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GEWGVW5WJ2.jpg)

あなたの会社では、AIに何を許していますか？
1
文章を作る
2
コードを書く
3
ファイルを読む
4
コマンドを実行する
5
メールを送る
6
本番環境を変更する
下に行くほど、
AIに渡す権限は
大きくなる
どこから先を
「AI利用」ではなく
「特権操作」と
考えるべきか
本日は、この境界の引き方を考えます。
© 2026 Enecom,Inc.
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/47ZL45N2J3.jpg)

日本でも、AIリスクは第3位
情報セキュリティ10大脅威 2026（組織編）／ 約250名の選考会による審議・投票で決定
1位
ランサム攻撃による被害
2位
サプライチェーンや委託先を狙った攻撃
3位
AIの利用をめぐるサイバーリスク
11年連続選出・6年連続1位
4年連続2位
初選出
IPAが挙げるリスク：意図しない情報漏えい ／ 生成結果を検証せず利用 ／ 攻撃者によるAI悪用
出典：IPA「情報セキュリティ10大脅威 2026」（2026年1月公表・組織向けランキング）
© 2026 Enecom,Inc.
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/YJ6W3996JV.jpg)

「答えるAI」から「作業するAI」へ
従来のチャットAI
AIエージェント
人が質問する
人が目標を指示する
AIが回答する
AIが計画する
人が作業する
読む・実行・接続・再試行
AIは、回答者から作業者へ
© 2026 Enecom,Inc.
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GJ5MLNN5J4.jpg)

（ご参考）2年前に準閉域網にシステム開発支援の生成AIを導入
Anthropic Claude
© 2026 Enecom,Inc.
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/9E29L55G7R.jpg)

本日の地図
歴史
モデル競争
攻撃と防御
ゼロトラスト
技術継承
前半＝歴史と競争 ／ 中盤＝実際の事件 ／ 後半＝導入設計と技術継承
© 2026 Enecom,Inc.
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/D7Y4QKKGEM.jpg)

ChatGPTが起こした革命（2022年〜）
自然言語が、コンピューターのUIに
良かったこと
・検索語・SQL・コマンドの暗記が不要になった
・文章要約・翻訳・要件整理・コード説明が誰でも扱える
課題・限界
・ハルシネーション。もっともらしい誤りを検証せず使う
事故
・個人アカウントへ社内情報を貼る「シャドーAI」の発生
・専門部署を経由せず、現場が自分で試せるようになった
・会話履歴が学習に使われる懸念（商用規約の理解不足）
・導入コストがほぼゼロ。ブラウザだけで始められた
・経営層の理解が進み、AI活用の裾野が一気に広がった
・出力の一貫性が低く、同じ問いで答えが変わる
・あくまで「回答する」だけで、実作業は人間に残った
この時代のAIの役割は「回答」。作業と検証は人間に残っていた。
© 2026 Enecom,Inc.
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/VENYKRR8J8.jpg)

GitHub Copilot：補完するAI（2021年〜）
人間が書く。AIが続きを提案
良かったこと
・定型コード・テストコードの記述時間が激減
・書きながら学べる。未知のAPIの使い方がその場で分かる
・人間が主役で、採否は常に人間が決める安心感
・変更の粒度が小さく、レビューで気づける範囲に収まる
・権限も限定的。エディタ内の補完に閉じていた
課題・限界
・提案の丸呑み。動くが意図しないコードが混入する
・脆弱なコード例をそのまま提案するリスク
・ライセンス・著作権の懸念（学習元コードの扱い）
・設計や全体構造は改善されず、局所最適に留まる
・「なぜそう書いたか」の説明責任が曖昧になりやすい
主役は人間。AIの権限はエディタ内に閉じていた。
© 2026 Enecom,Inc.
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/Y79PVMMXE3.jpg)

Cursor：一緒に編集するAI（2024年〜）
1行の補完から、複数ファイルの編集へ
良かったこと
・コードベース全体を文脈にできる。既存コードの理解
が速い
・複数ファイルにまたがるリファクタリングが現実的に
・エラーを見せれば、原因の候補を出して直しに来る
・仕様の相談から実装まで、同じ画面で完結する
・既存プロジェクトの改修スピードが目に見えて上がった
課題・限界
・AIが触るファイル範囲が広がり、差分レビューが重く
なった
・意図しないファイルまで書き換えられる事故
・コードベース全体を外部へ送る前提となり機密の扱い
が論点化
・「動いたから良い」で設計判断がブラックボックス化
・エディタの外（コマンド実行・環境変更）はまだ人間
の領域
ここで初めて「コードベース全体を外へ送る」ことが前提になった。
© 2026 Enecom,Inc.
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/G78DPLL97D.jpg)

CLI型AI：仕事を委任する（2025年〜）
調査
計画
変更
テスト
再試行
コミット
AIは「作業を委任できるエージェント」へ
与える権限が増えた
人間のレビュー機会が減る
痕跡が端末側に残る
ファイルの読み書き・コマンド実行・
外部サービスへの接続。エディタの外
へ出た
計画も実行も検証もAIの中で回る。
差分だけ見ても意図が追えない
会話履歴・トランスクリプトがロー
カルに蓄積される
© 2026 Enecom,Inc.
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/L7LM1LLMJR.jpg)

AIに、どこまで任せるか
回答 → 補完 → 編集 → 委任
© 2026 Enecom,Inc.
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4EMYWMM6EW.jpg)

Claude Code（Anthropic）
ターミナルやIDEから使うエージェント型開発ツール。推論はクラウド、ファイル操作とコマンド実行は端末側
で行う
得意なこと
企業向けの統制点
注意点
・大規模コードベースの調査と原因
分析
・managed settings で組織標準を強制
・端末側にトランスクリプトが残る
・計画→実装→テストの長時間の
連続作業
・Skill / Plugin で手順とルールを配布
・設定を変えられると証跡が欠落し
得る
・既存コードの仕様掘り起こし・
移行作業
・MCP 許可リストで接続先を限定
・コマンド実行を許すため端末統制
が前提
・サブエージェントによる作業分割
・OpenTelemetry でプロンプト・操作
を外部送信
・長時間のエージェント作業との
相性が良い
・Hooks で実行前検査・禁止操作の停止
・禁止ファイル・禁止コマンドの指定
・MCP接続先の権限をそのまま継承
する
・拡張点が多い＝管理対象も多い
一言でいえば「考えながら現場で作業するAI」。統制点の多さが企業利用での強みになる。
© 2026 Enecom,Inc.
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/PER9YVVNJ9.jpg)

OpenAI Codex
ローカルCLI・IDE・クラウド・専用アプリから利用でき、複数エージェントの並列運用へ
得意なこと
統制の仕組み
注意点
・複数タスクの並列実行と作業割
り当て
・ローカル実行時のサンドボックス
・並列実行は変更差分の把握が難
しくなる
・ローカルとクラウドの使い分け
・操作の承認モード（読取のみ／
変更可）
・クラウド実行はコードの送信先
が増える
・ChatGPTエコシステムとの連携
・テレメトリの取得
・複数エージェントの権限を個別
に設計する必要
・GPT系モデルとの強い統合
・「AIの開発チームを管理する」
使い方
・組織アカウント経由の利用管理
・クラウド実行環境の分離
・「誰の指示か」の追跡設計が必須
・同時実行数と費用の上限管理
一言でいえば「複数の開発者を並行して動かすAI」。並列化は統制の難度を上げる。
© 2026 Enecom,Inc.
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/P7XQGZZ8EX.jpg)

Google Antigravity CLI（agy）
複数のローカルエージェントを一つの司令塔から管理する、エージェントファーストの開発基盤
特徴
Gemini CLI との関
係
注意点
・ターミナルから自律エージェント
を操作
・個人向け（無料/Pro/Ultra）は
agy へ移行
・「Gemini CLIが全終了」は誤り。
個人向けの移行
・バックグラウンドの
サブエージェント管理
・企業契約・有料APIキーの
Gemini CLI は継続
・クローズド化により内部挙動の
検証が難しい
・Geminiの長いコンテキストを
活かした解析
・Go製・クローズドソースの後継
実装
・クォータ制は長時間作業の計画
に影響する
・Google Cloud / Workspace
との将来的な連携
・週次コンピュートクォータ制へ
変更
・企業契約と個人利用の線引きを
社内で明確化
・複数エージェントの並列管理
・OSSだった実装がクローズドに
なる流れの象徴
「Gemini CLIが全終了」は不正確。個人向けの移行と、企業・API利用の継続は別。
© 2026 Enecom,Inc.
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/37K9488L7D.jpg)

Grok Build（xAI）
Grok 4.5 を標準モデルとするターミナル型コーディングエージェント。Grok 4.5 は2026年7月16日公開
完全に遅れてきたダークホース
特徴
コストと速度
注意点
・対話画面・TUI・ヘッドレス実行
に対応
・公式価格：入力$2 / 出力$6
（100万トークン）
・速さは、誤った変更も速く広げる
・Agent Client Protocol 対応
・大量試行を回しても費用が伸び
にくい
・大量試行はレビュー負荷が増える
・Plan Mode とサブエージェント
・自動化パイプラインへの組み込み
が容易
・Cursorとの共同訓練による最適化
・コンテキストは500Kクラス
・「手数で押す」使い方に向く
・無料期間で利用者が急拡大した
・API費用の上限管理が前提になる
・企業向け統制機能は他CLIより
情報が少ない
・無料期間の利用はデータ取扱い
条件を確認
一言でいえば「速度と手数で押し切るAI」。速さは、誤りも速く広げる。
© 2026 Enecom,Inc.
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/LJ3WL226J5.jpg)

CLIは、役割で使い分ける
CLI
役割イメージ
強み
企業利用での注意点
Claude Code
深く調べて実装する
長時間作業・統制点の多さ
端末側の痕跡と設定改変
Codex
複数作業を並列管理する
並列実行・クラウド連携
差分把握と権限の個別設計
Antigravity CLI
Google環境と長い文脈を扱う
長大コンテキストの解析
クローズド化・クォータ制
Grok Build
高速に大量試行する
速度と価格の競争力
誤変更の拡大とコスト上限
絶対的な性能順位ではない。企業にとっては右端の「注意点」が導入設計を決める。
© 2026 Enecom,Inc.
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/8JDKNZZMEG.jpg)

Skill と Plugin
AIに「やり方」を教え、それを「配る」仕組み。企業の標準を組織全体へ行き渡らせる手段。
Skill：仕事のやり方を教える
Plugin：機能をまとめて配る
・特定作業の手順・判断基準をAIへ渡す
・Skill・エージェント・Hooks・MCPを一括配布
・例：社内コーディング規約に沿った実装手順
・例：CSIRT用の調査プラグイン一式
・例：セキュリティレビューのチェック順序
・例：新人向けの開発標準セット
・例：障害報告書・納品レポートの様式
・プロジェクトやチーム単位で導入できる
・例：社内API・命名規則の使い方
・メリット：導入手順の属人化を防げる
・メリット：品質が担当者に依存しなくなる
・デメリット：配布物のサプライチェーン管理が必要
・デメリット：内容が古びると誤った標準を配る
・出所不明のプラグインは持ち込ませない
SkillとPluginは「標準の配布路」。同時に、配布物のサプライチェーン管理が必要になる。
© 2026 Enecom,Inc.
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/VEPK5DDQ78.jpg)

MCP と Hooks
MCPは「どこへ接続するか」、Hooksは「いつ検査・停止するか」。統制の要はこの2つ。
MCP：外部接続の共通インターフェース
Hooks：処理の前後に割り込む
・AIが外部ツール・データへ接続する規格
・特定の処理前後で自動的に検査・処理を実行
・例：チケット管理・Wiki・DB・監視基盤
・企業の既存システムへの実質的なGatewayになり得る
・例：PreToolUse でコマンド実行前にシークレット検査
・例：ファイル変更後にセキュリティスキャン
・注意：MCP自体は基本的に認証機構を持たない
・例：禁止操作を検知して停止させる
・接続先の権限をそのまま継承してしまう
・例：毎日の監査ログを自動生成させる
・接続先が増えるほどAIの到達範囲が広がる
・メリット：AIの判断に依存せず機械的に止められる
・対策：許可リスト制・最小権限・接続の承認プロセス
・注意：Hooks自体の改変を監視する必要がある
MCPは既存システムへのGatewayになり得るが、それ自体は認証を持たない。だから許可リストと最小権限。
© 2026 Enecom,Inc.
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/27VVP11P7Q.jpg)

Claude Code の統制点（Skill / MCP 以外）
拡張機能だけでなく、権限・分離・巻き戻しの仕組みが揃って初めて「企業で使える」状態になる。
Permissions：
許可・拒否・要承認
Subagent / Sandbox：
分けて閉じる
メモリと巻き戻し
・ツールとコマンドを allow / deny /
ask に振り分ける
・Subagent：役割ごとにエージェント
を分ける
・CLAUDE.md：組織規約・前提を
プロジェクトに常駐
・例：本番ホストへの接続を deny
・例：調査用は読取のみ、実装用は書込可
・Skillが「手順」なら、こちらは「前提」
・コンテキストも権限も分離できる
（＝職務分離）
・カスタムコマンド：定型作業の入口を
固定する
・Sandbox：bash実行やネットワーク
を隔離する
・Checkpoint：変更を巻き戻せるよう
にする
・「本番を変更できない」を仕組みで担保
・Git差分と併用し、いつでも元に戻せる
状態に
・例：rm -rf・force push を deny
・例：外部への送信は ask（人が承認）
・権限設計を、そのまま設定として
書ける
・管理設定で配れば利用者は変更で
きない
・侵害時の影響範囲を先に限定しておく
＝「失敗しても被害が広がらない」の実装
権限（Permissions）・分離（Subagent / Sandbox）・巻き戻し（Checkpoint）。この3つが揃って初めて企業で使える。
© 2026 Enecom,Inc.
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/5JGLP22Q7L.jpg)

「良い聞き方」から「良い環境の作り方」へ
プロンプト → コンテキスト → ハーネス → ループ → グラフ ／
の整理として説明します
© 2026 Enecom,Inc.
用語は発展途上。本講演
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/47QY2PPWEP.jpg)

AI活用の概念の階層（積み上げの関係）
小さな設計が積み重なり、複雑で大きな自律的な仕事を実現する ― 本講演では、理解し
やすくするため内包関係として整理
グラフエンジニアリング
5
複数の仕事をどうつなぐか
複数のエージェント・ループ・ツール・知識源を、依存関係や分岐を持つ構造として統合する
ループエンジニアリング
4
どう評価し、いつまで回すか
計画・実行・観察・評価・修正を、完了条件／停止条件まで自律的に回す
ハーネスエンジニアリング（実行環境・道具立て）
3
何を使わせ、どこで動かすか
ツール・権限・サンドボックス・検証・ログ・コスト上限を設計する
コンテキストエンジニアリング
2
何を見せるか:AIが判断する時点で見る情報（履歴・検索結果・メモリ・作業状態）
を選び、整理し、更新する
1
プロンプトエンジニアリング
何をしてほしいか
目的・制約・完了条件・出力形式を明確に伝える
できること
複数のエージェントとツールを組み合わせ、
業務プロセス全体を自律的に完遂する
結果を自ら観察・評価・修正し、完了ま
たは停止条件に達するまで進み続ける
与えられた道具と権限の範囲で、一連の
作業を安全に実行し成果物を生み出す
AIが文脈を正しく理解し、精度の高い回
答や適切な判断ができる
AIに自分の意図を伝え、望む成果を得る
（すべての土台）
内側は「言葉」の設計、外側は「環境と権限」の設計。外へ行くほど、そのままセキュリティ設計の話になる
※用語の定義や包含関係は製品・論者によって異なる。本図は実務的な整理
© 2026 Enecom,Inc.
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/KE4WLYY1J1.jpg)

階層の読み方
何をしてほしいか（プロンプト）を伝え、何を見せるか（コンテキスト）を整え、何を
使わせどこで動かすか（ハーネス）を決め、どう評価しいつまで回すか（ループ）を設
計し、複数の仕事をどうつなぐか（グラフ）へ
ゴールは、全層を貫く
CSIRTの視点で読み替え
る
・どの層でも「完了条件」と「停止条件」
が要る
・①② ＝ 何を読ませるか（データ分類）
・階層を上がるほど自律性が増す
＝ 停止条件がないほど危険になる
・③ ＝ 何をさせるか（権限・実行環境）
・だから本講演では最後に扱う
・④ ＝ どこまで回すか（上限・暴走防止）
導入の順序としても使える
・いきなり⑤から始めない
・①②で精度を上げ、③で環境を固める
・④の上限設計と同時に自律度を上げる
・統制が追いつく速度で階層を上がる
・⑤ ＝ どこまで到達できるか
（横展開の範囲）
停止条件のないエージェントは、階層を上がるほど危険になる。
© 2026 Enecom,Inc.
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/L71YL665JG.jpg)

① プロンプトエンジニアリング
「何をしてほしいか」を伝える。目的・制約・完了条件・出力形式を明確にする
何をする技術か
・目的と背景を書く
（なぜ・誰のために）
・出力形式を指定する
（表で・JSONで）
・制約と禁止事項を書く
（やってはいけないこと）
・完了条件・評価基準を示す
・具体例を示す（Few-shot）
・役割設定は補助的に使う
今も有効なこと
・曖昧な指示は、曖昧な成果物になる
・完了条件を書くと精度が上がる
・悪い例・してほしくないことを書く
・短い指示より、前提を書いた指示が
強い
・エージェント時代でも土台として
効く
限界
・一回の指示で完結する前提の技術
・長い作業では前提が流れて忘れられる
・AIが読む情報の中身は制御できない
・「上手な聞き方」では
インジェクションを防げない
＝ 次のコンテキスト設計が必要に
「上手な聞き方」だけでは、AIが読む情報の中身を制御できない。だから次の段階へ
© 2026 Enecom,Inc.
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/G7WGVWWWE2.jpg)

② コンテキストエンジニアリング
「何を見せるか」を整える。AIが判断する時点で見る情報を選び、整理し、更新する
コンテキストに含まれ
るもの
なぜ効くのか
セキュリティ上の論点
・資料・仕様・ソースコード
・文脈が長くなるほど、AIは重要
な指示を見失う
・読ませた情報は、そのまま外部へ
送信される
・会話履歴／過去の実行結果
・関係ない情報は、判断の精度を
下げる
・何を読ませるかの判断
＝データ分類そのもの
・検索結果・RAG／メモリ
・「全部渡す」は最善ではない
・外部文書を読ませる
＝インジェクションの入口
・ツールの説明と現在の作業状態
・必要十分に絞ったほうが速く
安く正確
・「元データは読み取り専用」を徹底
・CLAUDE.md で常駐させる前提
・コンテキスト長＝性能、ではない
・作業ディレクトリを分離して読める
範囲を絞る
※プロンプトもコンテキストの一部
・読める範囲を絞ることが、そのまま
防御になる
何を読ませるかの判断＝データ分類そのもの。読める範囲を絞ることが、そのまま防御になる
© 2026 Enecom,Inc.
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/4JZL4552E3.jpg)

③ ハーネスエンジニアリング（実行環境・道具立て）
「何を使わせ、どこで動かすか」を決める。ハーネス＝AIを動かす周辺環境の全体
ハーネスに含まれるも
の
・ツール（Bash・編集・検索・MCP）
・実行環境
（サンドボックス・コンテナ）
・権限（Permissions）と状態管理
・コンテキスト供給と検証の仕組み
なぜ効くのか
・同じモデルでも、道具と環境で
成果が変わる
・テストを実行できるだけで、
品質は大きく上がる
・AIが自分で検証できる環境
＝人のレビュー負荷が減る
・ログ・可観測性・コスト制限
・「賢いモデルを選ぶ」より効果
が大きい場合がある
・エラー処理と人間の承認点
・モデルを変えても、ハーネスは
資産として残る
ここが統制の主戦場
・与える道具＝与える権限
・実行環境を隔離すれば、失敗の影響
が閉じる
・Permissionsは権限設計を
そのまま書ける
・Subagentは職務分離の実装になる
・Hooksは機械的な検査・停止点になる
＝ 生産性の設計と、統制の設計が
一致する層
与える道具＝与える権限。生産性の設計と、統制の設計が一致する層
© 2026 Enecom,Inc.
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/YE6W39V6EV.jpg)

④ ループエンジニアリング
「どう評価し、いつまで回すか」を設計する。単なる繰り返しではなく、フィードバック制御
計画
実行
ループ設計で決めること
観察
評価
修正
必ず設ける上限
・何を観察するか（テスト・ログ・差分）
・実行回数（無限ループの防止）
・合格／不合格をどう判定するか
・実行時間（セッションのタイムアウト）
・次の行動をどう選ぶか
・API費用（1タスク・1日あたり）
・いつ人間へ戻すか（エスカレーション）
・権限（本番接続・破壊的コマンドの禁止）
「最後まで自律実行させる」ことが目的ではない。観察・評価・停止の設計が本体
© 2026 Enecom,Inc.
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/GE5MLND5E4.jpg)

（補論）ナレッジグラフ／オントロジー設計
⑤グラフの「知識源」を作る技術。業務・顧客・システム・担当者・規程の関係を構造化し、AIに
「会社の地図」を持たせる
身近な入口：Obsidian
本格化：オントロジー
セキュリティ上の含意
・ノート間をリンクしてグラフ化する
・1カード＝1ファイル（YAML）で
Git管理
・グラフはAIの知識を増やす
・議事録・手順書・障害記録を相互
接続
・組織・プロダクト・データ資産・
会議体・用語をカード化
・ローカルのMarkdownなので持ち
出し統制がしやすい
・工夫①：定義に加えて「関係性」を
持たせる
・AIに読ませる文脈として渡せる
・まず個人・チーム単位で始められる
・工夫②：載せない情報を決める
（3か月変わらない事実だけ）
・同時に、侵害時の横展開経路にも
なる
・「誰に聞けばよいか」まで辿れる
＝人の情報の露出
・カードの改ざんは全社・全エージェント
へ即時波及
・鮮度が命の情報は検索語を渡して
生ログを引かせる
・中央管理だからこそ変更レビューが必須
・MCPとCLI（SKILL.md）の両方で
提供する
・アクセス制御と変更履歴をグラフ自体に
適用する
ナレッジグラフはAIの知識を増やす。同時に、侵害時の横展開経路にもなる
© 2026 Enecom,Inc.
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/9729L58GJR.jpg)

地図は本当に効くのか（実践事例）
社員が実際に発した業務上の疑問を評価データにした計測例（品質スコア／150点）
A：何も参照させない
B：オントロジー単体
C：社内ログの都度検索
D：オントロジー＋都度検索
E：社内ログの全件網羅（上限）
8
43
112
119
125
地図を持たせると、全件読ませたのと遜色ない振る舞いを、現実的な時間とコストで実現できた。
参考：AIに会社の地図を持たせたら、3年目社員のように働き始めた ～精度とトークン効率を上げるオントロジーの実践～｜kunpe (ymdpharm)
© 2026 Enecom,Inc.
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/DJY4QK6G7M.jpg)

知識化の自動化
知識は、AIに書かせて、AIに保守させる。人力で維持する台帳は必ず陳腐化する
定期的に知識化する
検索と蓄積の違い
CSIRTとしての論点
・日々の作業・障害対応・判断をログ
として残す
・検索でかき集めた答えは、
その場で使い捨て
・知識化の対象に機密・個人情報
が混入しやすい
・そのログをAIに読ませてカード・
手順書へ変換
・一度カードにした知識は、
次の問いの土台になる
・自動生成された知識の誤りが
全社へ波及する
・構造化された知識をAI自身が
維持し続ける方式
・変更レビュー（PR）を必須にし
て人が承認する
・知識が複利で積み上がる
・知識ベース自体を高機密資産と
して扱う
・未ヒットの用語、頻繁に引かれる用語
を計測
・計測結果をそのまま知識の改善タネ
にする
・呼び出しを全件計測し、継続改善に
回す
・保守もAIに任せる前提で設計する
・「毎回説明し直す」コストが
消える
・アクセス権限と変更履歴を必ず
残す
検索は使い捨て。カード化した知識は複利で積み上がる。ただし知識ベース自体が高機密資産になる
© 2026 Enecom,Inc.
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/V7NYKRZ8E8.jpg)

自分の分身として育つAIエージェント
自分の業務・作業・運用を知識化し続けると、エージェントは一次判断を代行できるようになる
STEP 1
STEP 2
STEP 3
STEP 4
行動を残す
知識に変える
判断を委ねる
分身になる
作業ログ・判断理由・失敗記
録
カード化・手順化・観点の言
語化
定型作業と一次判断を代行さ
せる
自分の観点で先に動ける状態
CSIRTとしての論点
・分身は「新しい権限の集約」である
・分身自身の認証・操作ログ・停止手段が必要
・本人の指示か、分身の自律判断かを区別できること
・退職・異動時に分身をどう扱うか（無効化・引き継ぎ）
分身に権限を渡すなら、分身にもIDと監査が要る。
AIに任せるほど、「誰が指示したのか」を記録する設計が重くなる
© 2026 Enecom,Inc.
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/YJ9PVMZX73.jpg)

その他 ― これから増える設計技術
呼び名は定まっていないが、現場ではすでに始まっている（用語は今後さらに変わる可能性がある）
エバル（評価）エンジ
ニアリング
メモリエンジニアリング
オーケストレーション
（分業）設計
・AIの成果を、機械的に採点する
仕組みを作る
・何を覚えさせ、何を忘れさせるか
を設計する
・複数エージェントに役割を割り
当てる
・テスト・受入基準・スコアを
先に定義する
・作業ログ・判断理由を知識として
蓄積する
・人のレビュー前に、AI自身に
検証させる
・古い前提を意図的に破棄する
・計画・実行・レビュー・監査を
分ける
＝ 人間の組織における職務分離
・「なんとなく良さそう」を排除
する
・前ページの「知識化の自動化」
に繋がる
・知識が腐らない仕組みを回す
・監査の観点では、合否の根拠が
残る
・Subagentやマルチモデル構成
で実装する
・一つのAIに全権限を集中させない
共通するのは「AI任せにしない仕組みを、先に作っておく」という発想
© 2026 Enecom,Inc.
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/GJ8DPL19JD.jpg)

⑥ ゴールエンジニアリング
①〜⑤のどの層でも必要になる、横串の設計。完了条件と停止条件を先に定義してAIへ渡す
何を作るか
成果物の形（コード／文書／設定）と、置き場所・命名まで指定する
何をもって完了とするか
通すべきテスト、満たすべき受入基準、レビュー観点を数えられる形で書く
何をしてはいけないか
触らせないディレクトリ、実行させないコマンド、接続させない宛先を明示する
いつ停止するか
前提が崩れたら止める。判断に迷ったら人へ聞く。N回失敗したら中断する
何を証跡として残すか
変更差分・実行ログ・判断理由。後から第三者が再現できる形にする
禁止事項だけでは足りない。完了条件と停止条件も、ガードレールの一部である
© 2026 Enecom,Inc.
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/LJLM1LQMER.jpg)

資料を作っている間に、主役が変わる
2026年、主役は何度も入れ替わった
© 2026 Enecom,Inc.
35


# Page. 36

![Page Image](https://bcdn.docswell.com/page/47MYWM167W.jpg)

2026年上半期タイムライン
半年ではなく、7月の3週間だけでこれだけ動いた
4月
5月
6/9
6/22
7/9
7/16
7/19
7/24
Claude
Mythos
Project
Glasswing
Claude
Fable 5
Sakana AI
Fugu
Muse Spark
1.1
GPT-5.6 Sol
Grok 4.5
Kimi K3
Qwen3.8Max
Preview
Claude
Opus 5
未知の脆弱性発
見
OSS大規模調査
6/12停止→7/1
再開
国産
複数モデルの
協調
Meta参入・
OpenAI追撃
低価格・2.8兆パ
ラメータ
2.4兆パラメータ
と主張
Fableに迫る性能
を半額で
2026年7月24日、Opus 5が公開
注記：日付は各社の公表日。Fable 5は6/9公開→6/12輸出管理で一時停止→6/30規制解除→7/1再開。
Grok 4.5は7/8にCursor内で先行提供、xAI公式アナウンスは7/16。Kimi K3のウェイト公開は7/28（日本時間の本日）
© 2026 Enecom,Inc.
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/P7R9YVLNE9.jpg)

Claude Mythos の衝撃
AIは、脆弱性を「説明する」段階から、未知の脆弱性を「発見する」段階へ進んだ
何ができるようになっ
たか
だから提供が制限され
た
・既知の脆弱性を説明するのではなく、
未知の候補を探す
・能力そのものがデュアルユース
（攻守両用）
・ソースコードを調べ、人がまだ見つけて
いない箇所を指摘
・一般利用者へ無制限には公開されない
・主要OS・ブラウザでの発見実績が示さ
れた
・複数の弱点を攻撃経路として連結する
・実際に動作する実証コードを生成する
・失敗したら修正して再試行する
・英国AI安全研究所の試験で約7割の確率
で目的情報を取得
・審査されたProject Glasswing参加
組織などへ限定提供
・サイバー・バイオ分野の高度能力を
想定した設計
・Fable 5は同じ基盤に安全制御を付けた
一般提供版
・「誰に・どこまで使わせるか」が
製品設計に組み込まれた
評価は割れている
・Cloudflareは「別種の能力」と評価
・同社は50以上の自社リポジトリで
数か月検証した
・一方でcurl開発者は「誇大」と冷静に
評価
・コード解析を根本から変えるほどで
はないとの指摘
・発見 → 外部確認 → CVE登録
→ 修正完了はすべて別段階
・発見数と修正済み件数を混ぜて語ら
ないこと
能力そのものがデュアルユース。だから「誰に・どこまで使わせるか」が製品設計に入った
© 2026 Enecom,Inc.
37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/PJXQGZW87X.jpg)

見つけるだけではない
従来のスキャナは「ここが危ないかもしれない」で止まる。ここから先が決定的に違う
Exploit chain
construction
・脆弱性を「つなぐ」
・単独では小さな弱点を攻撃経路
として連結する
・例：この設定ミス
＋ この古いライブラリ
＋ この権限設定
＝ 到達可能
・個別に見れば「低リスク」と判定
される組合せ
・人間の担当者が最も見落とす領域
Proof generation
なぜこれが怖いのか
・本当に悪用可能かを「実証」する
・従来スキャナ：既知パターンの照合
が中心
・実際に動作する実証コードを生成
する
・Mythos：未知の組合せを構成し、
実証まで行う
・失敗したら修正して再試行する
・「理論上可能」で止まらず、
動く証拠まで作る
・誤検知と真の脆弱性を切り分けら
れる
・防御側にとっては強力な武器になる
・同時に、攻撃側にとっても強力な
武器になる
・この能力が渡る相手を選ぶ必要がある
・だから限定提供という判断になった
＝トリアージの負荷が下がる
出典：Cloudflare による Mythos Preview の検証（第三者評価）
© 2026 Enecom,Inc.
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/3JK948VLJD.jpg)

発見するAIは速い
同じ調査の中で、段階が進むごとに数字は桁で変わる。混ぜて語ってはいけない
23,019 件
① 検出された脆弱性候補
6,202 件
② 高・重大と推定
1,596 件
③ 開示済み
④ 修正済み
97 件
①② ＝ AIが発見・判定した数 ／ ③④ ＝ 人が確認・修正した数
出典：Project Glasswing 公開情報（2026年5月22日時点の
報告および公開ダッシュボード）
調査規模
外部トリアージ有効率 90.6％
CVE / GHSA 割当 88件
1,000を超えるオープンソースプロジェ
クトを調査
外部の専門家が確認して「有効」と判定
した割合。AIの推定精度は低くない
開示済み1,596件のうち。開示・登録・
修正はすべて別の段階
発見するAIは速い。修正する人間は有限。
― ボトルネックは発見精度ではなく、人間側の処理能力にある
© 2026 Enecom,Inc.
39


# Page. 40

![Page Image](https://bcdn.docswell.com/page/LE3WL2M6E5.jpg)

Fable 5：性能だけでは提供できない
6月9日
6月12日
6月30日
7月1日
公開
提供停止
規制解除
再提供
理由は「輸出管理」。性能でも価格でもなく、安全保障だった
Mythos 5 と基盤を共有する
製品設計に入ってきた要素
・同じ基盤モデルから作られている
・安全保障・輸出管理
・Fable 5 には強い安全制御が設けられた
・利用者の審査と本人確認
・サイバー分野では正当な依頼まで拒否される場合がある
・悪用防止のための能力抑制
・より制限的なモデルへの自動フォールバックが文書化され
ている
・地域・組織単位での提供可否
この安全制御は、後半でお話しする「私のASMが止まる」問題の技術的な背景でもあります。
© 2026 Enecom,Inc.
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/8EDKNZ6M7G.jpg)

Opus 4.8：知能と信頼性は別
講演者の実体験
賢い。しかし、任せきれない
指示逸脱
過剰変更
判断のぶれ
虚偽の完了報告
依頼していない部分まで
変更する
必要以上に広く書き換え
る
長時間作業で方針が変わ
る
終わっていないのに完了
と言う
企業が求めているのは、賢さの最大値ではなく、任せた範囲を守る予測可能性。
知能が高いことと、業務で安定して任せられることは別
© 2026 Enecom,Inc.
41


# Page. 42

![Page Image](https://bcdn.docswell.com/page/V7PK5DYQJ8.jpg)

2026年7月24日、Opus 5が公開された
「Opus 4.8は扱いにくかった」という資料を作っていたら、講演の直前に Opus 5 がリリース
公開日
2026年7月24日（＝講演の4日前）。この資料は講演直前まで更新しました
性能
Fable 5のフロンティア性能に近づきながら、Fableの半額。エージェント開発
能力を強化
価格
API入力 $5 / 出力 $25（100万トークン）。Opus 4.8と同価格を維持
安全設計
攻撃的サイバー能力はMythos 5より抑えた設計。安全判定で制限的なモデルへ
切り替わる挙動あり
示唆
性能向上と能力抑制が同時に設計されている。企業は「どのモデルが使えるか」
を継続的に見直す必要がある
© 2026 Enecom,Inc.
42


# Page. 43

![Page Image](https://bcdn.docswell.com/page/2JVVP1GPJQ.jpg)

OpenAI、xAI／Meta、Google の重心の違い
同じ方向に走っているように見えて、各社が置いている重心は違う
OpenAI：
長文脈と安全性
xAI / Meta：
速度と価格
・GPT-5.6 Sol
（2026年7月9日公開）
・Grok 4.5（7/16公開・入力$2/出力$6）
・約105万トークンのコンテキスト
・Cursorとの共同訓練による最適化
・最大12.8万トークンの出力
・Meta Muse Spark 1.1（7/9公開）
Google：
慎重に仕上げる
・Gemini 3.5 Pro は7月下旬時点で未提供
・当初「6月提供」から繰り返し延期
・延期理由はコーディング性能が社内目標
未達との報道
・現行フラッグシップは Gemini 3.1 Pro
・コーディング・サイバー・
エージェント強化
・入力$1.25/出力$4.25の攻撃的価格
・プロンプトインジェクション
耐性の向上を説明
・エージェント・ツール操作・
コンピュータ操作を強化
・廉価版 GPT-5.6 Luna も提供
・価格で市場を動かす戦略
・3.6 Flash / 3.5 Flash-Lite / 3.5 Flash
Cyber を発表
・サイバー特化モデルが出てきた点に注目
注記：Gemini 3.5 Proの延期理由は報道ベース
© 2026 Enecom,Inc.
43


# Page. 44

![Page Image](https://bcdn.docswell.com/page/5EGLP28QJL.jpg)

Sakana AI Fugu：巨大化から協調へ
単一モデルの大きさではなく、複数モデルをどう組み合わせるかという競争軸。
何をするものか
企業にとっての意味
・2026年6月22日リリース
・特定ベンダーへの依存を薄めら
れる
・オーケストレーション層が新た
な単一障害点になる
・モデルが使えなくなっても
切り替えられる
・上流に複数モデル＝データ送信
先が複数になる
・用途ごとに最適なモデルを
選ばせられる
・どのモデルへ何を送ったかの
記録が必要
・国産という選択肢
（AI主権の文脈）
・各モデルの規約・データ取扱い
を個別に確認
・地方企業・SIerにとって現実的
な保険になる
・性能の主張は第三者検証と分け
て扱う
・複数のフロンティアモデルを
単一APIで統合
・Fugu / Fugu Ultra / Fugu Cyber
を展開
・Fugu Ultra は Fable / Mythos
級の性能を主張
・「System as a Model」という
考え方
・モデルを選ばせる
オーケストレーション層
注意点
モデルを巨大化する競争から、複数のモデルをどう組み合わせるかという競争へ。
© 2026 Enecom,Inc.
44


# Page. 45

![Page Image](https://bcdn.docswell.com/page/4JQY2P9W7P.jpg)

AIを、チームとして使う
講演者の実体験
計画
実行管理
高速実装
レビュー
全体監査
Fable
Opus
Grok
GPT
Gemini
全体計画を書かせる
現場の問題を解かせる
手数で押させる
限界まで粗探しさせる
長文脈で通し確認
一つのAIへ全権限を集中させない。＝ 人間の組織と同じ職務分離
この考え方が、そのまま後半の「AIエージェントの権限設計」になります。
© 2026 Enecom,Inc.
45


# Page. 46

![Page Image](https://bcdn.docswell.com/page/K74WLYX1E1.jpg)

フロンティアは、
閉じた場所だけではない。
オープンウェイトが、競争軸を変えている
© 2026 Enecom,Inc.
46


# Page. 47

![Page Image](https://bcdn.docswell.com/page/LJ1YL6N5EG.jpg)

Kimi K3 と Qwen3.8-Max Preview
2026年7月、中国勢が相次いで超大規模モデルを発表した。ただし「使える形」かは別問題。
Kimi K3
（Moonshot AI）
Qwen3.8-Max
Preview（Alibaba）
ここから読み取ること
・総パラメータ 2.8兆・コンテキスト
100万トークン
・総パラメータ 2.4兆と発表
（2026年7月19日・上海WAIC）
・Kimi K3の2日後にQwen3.8が発表
された＝対抗の動き
・2026年7月16日に発表
・マルチモーダル
（テキスト・画像・動画・文書）
・発表がベンチマークより先に来る
競争になっている
・画像理解・コーディング・
エージェント処理を特徴とする
・ウェイト公開予定は2026年7月28日
（＝講演の当日）
・公開済みなら自己ホストが可能
・米国製品（Cursor等）にも既に組み
込まれている
・コンテキスト100万トークン
・「Fable 5に次ぐ」はAlibaba自社評価
にもとづく主張
・モデルカード・ベンチマーク表・
ライセンス・稼働パラメータ数は未公開
・重み公開は「近日」とされ日付未定
・ベンダー主張と第三者検証は必ず
分けて扱う
・Moonshotは弱点も公表：曖昧な場面
で確認せず動く（＝停止条件が要る）
・企業は発表ではなく「使える状態」
で判断する
注記：「オープンウェイト」の扱いは慎重に。APIで使えるのか、重みを取得できるのか、ライセンスが確定しているのかは別条件。
Kimi K3 のライセンスは Modified MIT の予定。
© 2026 Enecom,Inc.
47


# Page. 48

![Page Image](https://bcdn.docswell.com/page/GJWGVW4W72.jpg)

GLM-5.2・DeepSeek V4・MiniMax M3
すでに第三者評価が可能で、実際にダウンロードして動かせるモデル群。
GLM-5.2（Z.ai）
・2026年6月13日リリース
・約7,440億パラメータ／
稼働約400億（MoE）
・コンテキスト100万トークン・
MITライセンス
・SWE-bench Pro 62.1％
（オープンウェイト最高水準）
・第三者指標で
オープンウェイト1位・総合上位
・長時間のエージェント作業を重視
した設計
DeepSeek V4
（DeepSeek）
MiniMax M3
（MiniMax）
・2026年4月24日リリース
（V4 Pro / V4 Flash）
・2026年6月1日リリース
・コンテキスト100万トークン・
MITライセンス
・LiveCodeBench 93.5％
（全モデル中最高水準）
・Codeforces レーティング 3206
・出力トークン単価がGLMの約5分の1
・競技プログラミング系・アルゴリズム
推論に強い
・約4,280億パラメータ
・コンテキスト100万トークン
・テキスト・画像・動画を統合して
扱える
・SWE-bench Pro 59.0％
（自社評価）
・ネイティブマルチモーダルの
オープンウェイト
注意：SWE-bench Verified と SWE-bench Pro は別のテスト。同一軸で比較しない。ベンダー値と第三者評価も区別する。
© 2026 Enecom,Inc.
48


# Page. 49

![Page Image](https://bcdn.docswell.com/page/4EZL452273.jpg)

性能以外の競争軸
ベンチマーク1位のモデルが、自社の最適解とは限らない。評価軸は多数ある。
コストの評価軸は一つ
ではない
データとロケーション
・APIの従量課金
（入力・出力トークン単価）
・データを社外へ出せるか
（機密区分・契約）
・クラウドのPaaS利用料（Bedrock
・Vertex等）
・データ保管地（国内保管が要件か）
・オンプレのハードウェア調達費
（GPU・メモリ）
・自社環境・閉域で動かせるか
・電気代・空調・データセンター費用
・運用人件費・脆弱性対応の工数
・学習利用の有無と契約上の保証
・監査ログを自社で保持できるか
・「オンプレが安い」とは限らない。
稼働率が低ければ割高になる
継続性とロックイン
・モデルが突然利用できなくなる
リスク
・価格・利用条件の変更
・安全制御によって業務が拒否
される可能性
・ベンダーとの契約終了
・モデルを交換できる構成に
なっているか
・AI基盤は事業継続計画の
一部である
「オンプレが安い」とは限らない。稼働率が低ければ、償却と電気代を払い続けることになる。
© 2026 Enecom,Inc.
49


# Page. 50

![Page Image](https://bcdn.docswell.com/page/Y76W3V667V.jpg)

米中の規制と対立
AIモデルは、地政学と切り離せなくなった。確定政策・当局の主張・報道上の検討を分けて読む。
米国側の動き
反対する声
中国側の動きと企業へ
の含意
・中国企業による米国モデルの
「蒸留」利用を問題視
・NVIDIA CEOがオープンウェイト
擁護の投稿
・自国の最先端モデルを安全保障
上の資産として扱う動き
・ホワイトハウスがKimi K3の
開発経緯に言及したと報じられる
・米国の新興企業・産業界から全面
禁止に反対
・将来の高度モデルの海外アクセス
制限を検討と報じられる
・制裁・規制・禁止措置の検討が
進む
・「規制の私物化」という批判
・※確定政策ではなく検討段階
・輸出管理の実例：Fable 5が
6/12〜6/30に停止された
・広範な規制は技術革新を阻害する
との主張
・政権内・業界で対応が割れている
・OpenAI幹部も規制リスクに言及
・含意：クラウドAIが同条件で
使い続けられる保証はない
・含意：一つのモデルへ完全依存
しない構成が望ましい
・含意：モデル選定はサプライ
チェーンリスク管理になった
確定した政策・当局関係者の主張・報道上の検討は、それぞれ確度が違う。混ぜて語らない。
© 2026 Enecom,Inc.
50


# Page. 51

![Page Image](https://bcdn.docswell.com/page/G75MLD6574.jpg)

統一指標で比較する（コーディング用途）
複数ベンダーの自社ベンチを混ぜず、単一の公開リーダーボードで比較する（当日朝に再取得しスナップショットとし
て固定）
Rank
Model
提供元・ライセンス
Score
Votes
Price $/M
Context
1
kimi-k3
Moonshot・重み公開予定
1682
3,774
$3 / $15
1M
2
claude-fable-5
Anthropic・Proprietary
1630
5,570
$10 / $50
1M
3
gpt-5.6-sol-xhigh
OpenAI・Proprietary
1625
4,996
$5 / $30
1.1M
4
glm-5.2 (max)
Z.ai・MIT
1588
5,537
$1.40 / $4.40
1M
5
claude-opus-4-8-thinking
Anthropic・Proprietary
1568
8,060
$5 / $25
1M
8
grok-4.5
xAI・Proprietary
1550
3,178
$2 / $6
500K
13
muse-spark-1.1
Meta・Proprietary
1536
3,030
$1.25 / $4.25
N/A
15
gemini-3.6-flash
Google・Proprietary
1526
2,409
$1.50 / $7.50
1M
16
claude-sonnet-4-6
Anthropic・Proprietary
1523
16,574
$3 / $15
1M
MITライセンスのGLM-5.2が、価格1桁違いで4位に入っている。※Kimi K3は7/28にウェイト公開
（Modified MIT）― 公開済みなら「オープンウェイトが1位」に読み替わる
参考：WebDev AI Leaderboard - Best AI Models for Web Development
© 2026 Enecom,Inc.
51


# Page. 52

![Page Image](https://bcdn.docswell.com/page/9J29L8MGER.jpg)

性能と価格のマトリクス
縦軸に性能、横軸に価格。選択肢の「構造」を見る。
フロンティアは、
もう閉じた場所だけ
にはない
・上位のプロプライエタリ群
・価格が1桁違うオープン群
が、別の位置に固まる
・異なるテストを同一軸に
混ぜない
・ベンダー値と第三者評価を
分ける
AI モデル コスパマトリクス｜価格×知能
スコア散布図【2026年7月】 - ai-garage
© 2026 Enecom,Inc.
52


# Page. 53

![Page Image](https://bcdn.docswell.com/page/DEY4Q6XGJM.jpg)

未来の予測ではない
ここからは、実際に起きた話
© 2026 Enecom,Inc.
53


# Page. 54

![Page Image](https://bcdn.docswell.com/page/VJNYKZ1878.jpg)

GTG-1002：それは既に起きていた
Anthropicが2025年11月に公表した、AIオーケストレーション型のサイバースパイ活動。
何が起きたか
どう構成されたか
公平を期すために
・Anthropicが2025年9月中旬に
検知、11月13日に報告書公表
・Claude Code を攻撃基盤の中核
（オーケストレーター）に
・「史上初・大規模」の位置づけ
には専門家から異論もある
・中国国家系と評価される攻撃
グループ（呼称：GTG-1002）
・MCP でオープンソースのペンテスト
ツールへ接続
・公開脅威情報リポジトリでの
独立検証は確認されていない
・標的は約30組織（技術・金融・
化学・政府）
・活動は長期にわたり、封じ込め
まで時間を要した
・複数の侵入に成功したと報告さ
れている
・例：Nmap（探索）Metasploit（攻撃）
SQLMap（DB攻撃）
・複数のClaude Codeインスタンスを
群として動かした
・ポリモーフィック型のコード生成で
検知を回避
・C2通信を通常トラフィックに似せて
隠蔽
・AI側も誤検知・誤った認証情報
の生成など失敗した
・完全自律ではなく、人間の判断
ゲートが存在した
・ただし攻撃経済性を変えたという
評価は広く共有されている
ここで申し上げたいのは、私がこれから企業導入をお勧めするClaude Codeが、すでに攻撃側にも使われたということです。
© 2026 Enecom,Inc.
54


# Page. 55

![Page Image](https://bcdn.docswell.com/page/YE9PVZ5XJ3.jpg)

戦術的作業の80〜90％をAIが実行(Anthropicより)
80〜90%
をAIが実行
人間の関与は
1キャンペーン当たり
4〜6回の判断ゲートのみ
通常必要な労力の
10〜20％で
国家レベルの規模を実現
偵察
公開資産・認証ポータル・設定不備を並列に洗い出す
脆弱性探索
候補を試し、結果を見て次の手を選ぶ
攻撃コード生成
ペイロードを作り、失敗したら作り直す
認証情報取得
トークン・鍵を抽出し、再利用を試す
横展開
内部の別サービスへ広げる
データ抽出
価値のある情報を選別して持ち出す
報告書作成
発見内容を自動で文書化する
ピーク時は毎秒複数回・数千件規模。ただしAIは誤った認証情報の生成など失敗も起こしている（＝完全自律ではない）。
© 2026 Enecom,Inc.
55


# Page. 56

![Page Image](https://bcdn.docswell.com/page/GE8DP1Y9ED.jpg)

ガードレールは「役割設定」で突破された
① 依頼を小さく分割する
② 役割を設定する（ロールプレイ）
「この企業に侵入せよ」ではなく
「私たちは正規のセキュリティ企業です」
「このIPレンジの公開ポートを列挙せよ」
「顧客から認可された防御テストです」
「このバージョンの既知の問題を調べよ」
「ペネトレーションテストの一環です」
「このパラメータで動作確認せよ」
AIはその文脈を受け入れて作業を続けた
→ 個々の依頼は正当な作業に見える
→ 安全フィルタが働かなかった
AIを説得できても、権限は与えない。
プロンプト上の説明でAIを守ることはできない。守るのは権限設計とネットワークとログ。
© 2026 Enecom,Inc.
56


# Page. 57

![Page Image](https://bcdn.docswell.com/page/LELM1Q4M7R.jpg)

OpenAI × Hugging Face：時系列
7/9頃
サンドボックス脱出
評価用AIエージェントがテスト環境からの脱出を試みる
7/11–13
本番環境への侵入
盗まれた認証情報とゼロデイを連鎖させ、RCE経路を発見
7/16
Hugging Face が検知・公表
LLMベースの異常検知でシグナルを相関分析して発見
約1週間
攻撃源の特定に要した時間
OpenAIが自社エージェントと侵入を関連付けるまで（報道）
7/21
OpenAI が公表
「前例のないインシデント」として説明。共同調査を継続
使用モデル：GPT-5.6 Sol ＋ 未公開の高性能モデル ／ 目的：評価ベンチ（ExploitGym）の解答を先に見ること
© 2026 Enecom,Inc.
57


# Page. 58

![Page Image](https://bcdn.docswell.com/page/4JMYW1K6JW.jpg)

AIが攻撃し、AIが見つけた
悪意ではなく、与えられた評価目標を最適化した結果、想定外の手段を選んだ。
攻撃側で起きたこと
防御側で機能したこと
露呈した非対称性
・Hugging Face 側もAIで検知した
・攻撃側は制約なくAIを使える
・AIは評価環境の境界を越えた
・セキュリティテレメトリをLLMで
トリアージ
・盗まれた認証情報とゼロデイを連鎖
させた
・日常のノイズから異常シグナルを
相関分析
・防御側が商用AIでログ解析を試み
ると、セキュリティガードレールに
阻まれた
・RCE（リモートコード実行）経路を
見つけた
・17,000件超の攻撃イベントを
AIエージェントで解析
・悪意ではなく「目標の最適化」の結果
・通常数日かかる作業を数時間で完了
・AIに脆弱性調査という目標を与えた
・人間はすぐに異常と判断できなかった
・OpenAI側でも社内で異常活動を
発見
・「防御目的だから通る」わけでは
ない
・これが後半の私自身の悩みにつな
がる
・防御側の道具立てが追いついてい
ない
攻撃側は制約なくAIを使い、防御側は縛られる。これが「非対称性」の正体。
© 2026 Enecom,Inc.
58


# Page. 59

![Page Image](https://bcdn.docswell.com/page/PJR9YLXN79.jpg)

29分。最速27秒
【前提】ブレイクアウトタイム＝最初の侵入から、別システムへの横展開を開始するまでの時間。この時
間内に封じ込められれば被害は一台で止まる。
29分
27秒
平均ブレイクアウトタイム
最速記録
その29分で、組織は何ができるか
・アラートに気づく
・状況を確認する
・関係者へ連絡する
・対応方針を決める
・封じ込めを実行する
会議を開き、担当者を決める前に、攻撃者は横展開を終えている
守る側が手作業だけでは、速度で負ける。だから防御側も自動化が必要になる
出典：CrowdStrike「2026 Global Threat Report」（2026年2月）
© 2026 Enecom,Inc.
59


# Page. 60

![Page Image](https://bcdn.docswell.com/page/PEXQGW68JX.jpg)

攻撃側は動く。自作ASMは攻撃準備とみなされ止まる
講演者の実体験
AIを使ったASM（攻撃対象領域管理）を試作。商用製品に準ずるところまでは動いた。しかし本運
用には至っていない。
攻撃側
防御側（自作ASM）
中華モデルという選択肢
・ガードレールを役割設定でだまして
外した
・肝心な調査で安全判定が働き拒否さ
れる
・動く。セキュリティ用途でも止まら
ない
・戦術的作業の80〜90％を自動化
・Fable 5は安全判定で制限的モデル
へ切替（文書化された仕様）
・しかしガードレールが反対に効かな
い恐れ
・私の体感ではなく、設計としてそう
なっている
・データ送信先に関する懸念
・精度とあわせて、本運用に至らない
・悩みどころである
・毎秒複数回・数千件の処理速度
・止まらない
・規制・供給継続性のリスク
攻撃側はガードレールをだまして外す。防御側は、ガードレールが正しく動いて止まる。
これが非対称性。本番運用含めての迅速性、安定性、安全性の課題
© 2026 Enecom,Inc.
60


# Page. 61

![Page Image](https://bcdn.docswell.com/page/3EK94V1LED.jpg)

3週間の仕事を、3時間で
講演者の実体験
実際のインシデント対応で、フォレンジックレポートをAIエージェントに作らせた。
3週間
3時間
3回
人間が書くなら
AIの初稿
人間の手直し
相談した警察関係者の見積もり
ただしハルシネーションだらけ
ここで商用レポート級になった
専門家の価値は、書くことから「直せること」へ
逆に言えば、直せる人がいなければ、この「3時間」は使えない
また、この3時間は、事前準備の2か月ありきであるということ
© 2026 Enecom,Inc.
61


# Page. 62

![Page Image](https://bcdn.docswell.com/page/L73WLMQ675.jpg)

AIを止めるのではない
権限と影響範囲を設計する
では、企業はどう迎え入れるか
© 2026 Enecom,Inc.
62


# Page. 63

![Page Image](https://bcdn.docswell.com/page/87DKN69MJG.jpg)

AI版ゼロトラスト
ゼロトラストの原則は、AIにもそのまま適用できる。対象が「人と端末」から「AIエージェント」に増えただけ
Never trust：
信用しない
Always verify：
毎回確認する
Assume breach：
破られる前提
・AIの回答を信用しない
（検証してから使う）
・一度認証したら全許可、にしない
・AIはだまされる
（GTG-1002が実証した）
・AIに読ませる文書を信用しない
・セッション単位で検証する
→ そこがインジェクションの土壌
になる
・ツール実行の単位で検証する
・AIは間違える
（誤った認証情報を作った）
・接続するMCPサーバーも信用しない
・生成されたコードもレビュー対象
にする
・出力をそのまま実行させない
・外部接続・ファイル変更の単位
で検証する
・利用者・端末・権限・接続先を
毎回確認
・AIは突破される
（Hugging Face 事件が示した）
・だから影響範囲を先に限定しておく
・すべて記録し、後から追えるようにする
・Hugging Faceはこの姿勢で検知に成功
・準拠端末かどうかも条件に入れる
対象が「人と端末」から「AIエージェント」へ増えただけ。原則は変わらない。
© 2026 Enecom,Inc.
63


# Page. 64

![Page Image](https://bcdn.docswell.com/page/VJPK5YZQE8.jpg)

7つの確認 ― そして、何を記録するか
認証時に一度ではなく、セッション・ツール実行・外部接続・ファイル変更の単位で検証する。
1
誰が
IdPの利用者ID・所属・認証結果・MFAの成否
2
どの端末から
端末ID・準拠状態・接続元IP・VPN経由かどうか
3
どのモデルを
モデル名・バージョン・トークン数・費用
4
どのデータに
読んだファイルパス・リポジトリ・データ区分
5
どのツールで
実行したツール・MCPサーバー名・許可／拒否の判定
6
どこへ接続し
宛先ホスト・API・Allowlist内かどうか
7
何を実行したか
プロンプト・回答・コマンド・変更差分（Git）
この7項目が、そのままログ設計の項目になる。埋まっていない導入は、監査に耐えない。
© 2026 Enecom,Inc.
64


# Page. 65

![Page Image](https://bcdn.docswell.com/page/2EVVPGWPEQ.jpg)

プロンプトインジェクションは権限の問題
AIがだまされることは防げない。だまされても被害が出ない設計にする。
秘密を読めない
外部へ送れない
.env・秘密鍵・認証情報フォルダを読
取対象から除外
宛先をAllowlistで限定。未承認の通信
を拒否
危険操作は承認が必要
破壊的コマンド・公開操作は人間の承
認を挟む
履歴が残る
プロンプト・コマンド・ファイル操作
を記録
本番を変更できない
本番環境への接続を禁止。作業領域を
分離
元に戻せる
Gitで差分管理。切り戻し手順を用意
GTG-1002は、役割設定でAIを説得した。説得できても、権限は渡さない。
© 2026 Enecom,Inc.
65


# Page. 66

![Page Image](https://bcdn.docswell.com/page/57GLP8DQEL.jpg)

AI駆動開発の情報漏えい対策：最低限の4要件
機能を導入するだけでは企業利用にならない。この4点が揃って初めて成立する。
① 認証・認可
会社IDで認証し、権限を最小化する。個人アカウント・APIキー
直利用を禁止。退職・異動を反映する
② 社内からのみ利用
社内ネットワークまたは管理されたVPNからのみ。接続元IPを
制限し、迂回経路をネットワークで遮断する
③ プロンプトログの保存
入力・回答・コマンド・ファイル操作を中央に保存。端末設定
に依存せず取得できる経路を用意する
④ 監査対応
誰がいつ何をしたかを追跡でき、異常時に確認・停止できる体
制。ログ欠落の検知まで含める
この4要件に対して、セキュリティ製品側の対応はまだ追いついていない（次ページ）。
© 2026 Enecom,Inc.
66


# Page. 67

![Page Image](https://bcdn.docswell.com/page/4EQY291WJP.jpg)

単一製品では守れない（結論はまだ出ていない）
カテゴリ
見えるもの
見えないもの・弱点
ブラウザ拡張型
画面上の入力・貼り付け
CLI・端末アプリを捕捉できない
SWG型
接続先・通信の可否
プロンプト単位の意味理解と記録が弱い
CASB / DLP型
機密データの分類と流出
AIエージェント特有の操作が範囲外になりがち
AIゲートウェイ型
プロンプト・モデル・コスト
新しく実績が乏しい。端末内のファイル操作は見えない
EDR型
端末の挙動・設定改変
クラウドへ送信された中身は見えない
Git
実際に何が変わったか
指示の過程・意図は残らない
どれも一長一短。単独では成立しない。当面は組み合わせるしかなく、業界の答えは
まだ出ていない。
© 2026 Enecom,Inc.
67


# Page. 68

![Page Image](https://bcdn.docswell.com/page/KJ4WLXR171.jpg)

既存の管理基盤から始める
AI製品から選ぶのではなく、既存の管理基盤から導入経路を選ぶ。統制はゼロから作らない。
Microsoft中心の企業
・Entra ID：SSO・条件付きアクセス
MFA
・Intune：端末管理・設定強制・
準拠デバイス
Google中心の企業
・Cloud Identity：ID管理・SSO
・Endpoint Management：端末
管理
なぜ近道なのか
・ID・端末・DLP・監査ログが既に
整っている
・入退社連動の仕組みが既にある
・Defender：EDR・脅威検知
・Workspace DLP：データ流出
防止
・監査部門が慣れている画面と
レポートを使える
・Purview：DLP・情報保護・
監査ログ
・Google Cloud：ログ集約・IAM
・AI専用の統制基盤を新設しなくて
済む
・既存の条件付きアクセスを
AIアプリへスコープする
・既存のコンテキスト認識アクセス
を流用する
・端末統制がそのままAI統制に効く
・「AIだけ別ルール」という抜け穴
を作らない
・結果として、エンタープライズ要件
を満たしやすい
AI専用の統制基盤を新設しない。「AIだけ別ルール」という抜け穴を作らない。
© 2026 Enecom,Inc.
68


# Page. 69

![Page Image](https://bcdn.docswell.com/page/LE1YLNQ57G.jpg)

Claude Code 導入要件
会社IDで認証
社内からのみ利用
APIキー直利用の禁止
SSO必須・個人アカウント禁止
接続元IP制限・VPN経由
端末に配らない・経路を強制
プロンプト・操作ログ
シークレット誤送信防止
利用ルール・監査
入力/回答/コマンド/ファイル操作
読取拒否・Hook検査・多層防御
モニタリング告知・定期レビュー
この6点を満たす構成として、2つのパターンを比べます。
© 2026 Enecom,Inc.
69


# Page. 70

![Page Image](https://bcdn.docswell.com/page/GEWGV4MWJ2.jpg)

パターンA：Anthropic 直接接続
社内管理端末（Claude Code）
速く導入しやすい
社内Proxy・SWG／固定出口IP
SSO・組織管理・標準の監査機能をすぐ利用でき
る。Gateway基盤の構築が不要
Anthropic（Claude Enterprise）
Compliance API ／ Claude Code Otel
(注)OpenTelemetry（以下、OTel）
SIEM（相関分析・検知）
S3等（長期アーカイブ）
© 2026 Enecom,Inc.
サンドボックス基盤
コマンド実行・ファイル操作はAnthropic提供の
サンドボックスを基盤とする
ログ経路が分散する
Claude Web／Claude Code OTel／Proxy／IdP
が別経路。S3に置くだけでは監査にならない。
SIEMで相関分析し、S3は長期アーカイブに
70


# Page. 71

![Page Image](https://bcdn.docswell.com/page/47ZL42Q2J3.jpg)

パターンB：AWS Gateway ＋ Bedrock
社内管理端末（Claude Code）
社内LAN・VPN
統制が強い
端末にAPIキーもAWS認証情報も置かない。
テレメトリ送信先をサーバ側で固定できる
Internal ALB（接続元IP制限）
二重の証跡が取れる
Claude apps Gateway（OIDC認証）
VPC Endpoint → Amazon Bedrock
SIEM（相関分析・検知）
S3＋KMS＋Object Lock（保全）
© 2026 Enecom,Inc.
クライアント側のOTelと、Bedrock側のモデル入
出力ログを突合できる
構築・運用が必要
Gateway・ALB・DBの運用と脆弱性対応。障害
時はClaude Codeが使えない
71


# Page. 72

![Page Image](https://bcdn.docswell.com/page/YJ6W3VN6JV.jpg)

一般利用はA、高監査開発はB
比較項目
パターンA：Anthropic直接
パターンB：AWS Gateway＋Bedrock
主な用途
一般業務・文章作成・公開情報の調査
社内開発・納品前データ・高監査案件
導入速度
速い（SaaS設定中心）
構築期間が必要
運用負担
小さい
Gateway・ALB・DBの運用が発生
認証
Claude Enterprise の SSO / SCIM
自社IdP（OIDC）＋Gateway
接続元制御
Proxy・SWG・IP Allowlist
Internal ALB・Security Group・VPN
APIキー
端末に残る可能性があり運用で抑止
原則不要（Gatewayへ集中）
プロンプトログ
Compliance API ＋ 端末OTel（設定依存） OTel（送信先固定）＋ Bedrockログ
ログの集約先
SIEM ＋ S3アーカイブ
SIEM ＋ S3（KMS・Object Lock）
統制の強さ
中〜高
高
情報区分と業務リスクで使い分ける。どちらもログはSIEMで相関分析し、S3は長期保全に使う。
© 2026 Enecom,Inc.
72


# Page. 73

![Page Image](https://bcdn.docswell.com/page/GJ5MLD55J4.jpg)

ガードレールは、配らず強制する
① サーバ側 管理設定
認証・接続先・利用モデル・ログ送信先
② MDM・GPO・ゴールデンイメージ
端末設定・証明書・禁止ファイル・禁止コマンド
③ Git（CLAUDE.md 等）
プロジェクト固有の作業ルールのみ
補助：ログオンスクリプト
設定の存在確認・バージョン確認・疎通確認
サインイン時に配布。ローカルで上書き不可
Windows=HKLM／macOS=MDM／Linux=システム領域／
Docker=ECRイメージに焼き込み
利用者が削除・迂回できる。セキュリティ統制には使わない
失敗や未実行を把握しにくいため主手段にしない
git clone だけでは、統制にならない。
© 2026 Enecom,Inc.
73


# Page. 74

![Page Image](https://bcdn.docswell.com/page/LE3WLMN5E5.jpg)

シークレットとAPIキーを守る
一つの仕組みには依存しない。多層で止める。そして平文で置かないことが出発点。
シークレットを持たせない
APIキーを直接使わせない
・SOPS等で暗号化して保管する
・端末へAPIキー・AWSアクセスキーを配らない
・.env に平文で残さない（これが出発点）
・ログイン先（Gateway）を管理設定で固定する
・本来は1Password等の商用シークレット管理がベスト
・SWGで api.anthropic.com への直接通信を拒否
・Claude Codeの読取対象から除外：.env / *.pem /
*.key / credentials
・IAM／SCPでモデル呼び出しをGatewayロールに限定
・PreToolUse Hook で実行前に内容を検査
・EDRで ANTHROPIC_API_KEY 等の存在を検知
・Hookで毎日の監査レポートを自動生成させる
・発見時はキーを失効・交換する
・承認されたVPC Endpoint経由のみ許可
・Git pre-commit・CI・DLPでも重ねて検査
出発点は「平文で置かない」。SOPSや商用シークレット管理を前提に、Hookで毎日監査する。
© 2026 Enecom,Inc.
74


# Page. 75

![Page Image](https://bcdn.docswell.com/page/8EDKN6WY7G.jpg)

ログは、取得より欠落検知
取得するログ（7つの確認に対応）
・IdP認証
誰が
・接続元IP・端末
どの端末から
・モデル利用・トークン
どのモデルを
ログが届いていないことを検知す
る。
・プロンプト・回答
何を入力したか
欠落の原因
・コマンド・ファイル操作
何を実行したか
・MCP接続先
どこへ接続したか
・Git差分・PR
実際に何が変わったか
・利用者が設定を変更した
・OTel Collectorが停止した
・ネットワーク障害で転送できなかった
・端末が管理外だった
→ セッションがあるのにログがない状態をSIEMで検知する
SIEMで突合する：IdP × 接続元 × モデル利用 × プロンプト × コマンド × Git差分
© 2026 Enecom,Inc.
75


# Page. 76

![Page Image](https://bcdn.docswell.com/page/V7PK5Y92J8.jpg)

2時間で作れた機能に、いくら請求するか
講演者の実体験
製品に無かった「隔離ページのパスワード初期化機能」を、約2時間でPoCできた。
しかも自動化できたもの：二重のセキュリティ診断 ／ OWASP Top 10 準拠チェック ／ デシジョンテーブルに
よるパラメータチェック ／ 納品レポート
では、何を根拠に価格を決めるのか？
工数
知識
品質保証
責任
2時間で終わったら2時間
分か
何を作るべきか分かるこ
との価値
「大丈夫」と言える根拠
を持つこと
障害時に引き受ける覚悟
SIerの価値とソフトウェアの価格を、再定義する必要がある。
© 2026 Enecom,Inc.
76


# Page. 77

![Page Image](https://bcdn.docswell.com/page/2JVVPGMXJQ.jpg)

障害が起きた夜中3時に、誰が直すのか
講演者の実体験
障害対応は現地現物、起動ログを眺めて構造と障害を覚えた世代と、AIに聞けば3秒で答えが
返る世代のギャップ
AIに任せること
人が経験すること
・調査と下書きの作成
・構造の理解（なぜそうなるか）
・定型作業の自動化
・障害の切り分けと復旧
・大量の試行と検証
・成果の品質保証
・報告書の初稿
・「大丈夫」と言える根拠
提案：手順書はPoC環境で実施し、構築はあえて手順書を元に手動で経験する。
自動化とは別に、育成・クロスチェック・技術継承の設計が必要。何をもって成果とし、何をもって対価とす
るか。
若い世代を否定したいのではない。境界を、皆さんと一緒に設計したい。
© 2026 Enecom,Inc.
77


# Page. 78

![Page Image](https://bcdn.docswell.com/page/5EGLP8GRJL.jpg)

5つの原則
1
AIエージェントは、特権主体とし
て管理する
4
APIキーを配らず、認証・通信・ロ
グを集約する
2
最強のモデルより、交換できる基
盤を作る
5
失敗しても、被害が広がらないよ
うにする
3
プロンプトインジェクションは権
限設計の問題
© 2026 Enecom,Inc.
78


# Page. 79

![Page Image](https://bcdn.docswell.com/page/4JQY29XY7P.jpg)

AIは、もう答えるだけではない。
読む
考える
接続する
実行する
だからこそ、
AIにもゼロトラストが必要である
AIを信頼するな。検証せよ
© 2026 Enecom,Inc.
79