はじめに：AIは「勘違い」などしていない
Anthropicの Claude にある「Computer Use」や、今後普及するデスクトップ操作型AIエージェントは、とても便利です。
同時に、ローカル環境へ“致命的な操作権限”を持ち込むという意味もあります。
よくAIは幻覚（ハルシネーション）を見る、嘘を付く」と言われます。
多くの場合それは、AIが間違ったのではなく、人間の曖昧な指示を、目的関数として最適化しただけです。意味のふらつきに対して要は正しい挙動をしていることになります。たぶん？
人間が期待する動作をさせるということ以外に、させてはいけないことが非常に重要です。
本記事では、人間特有の「暗黙知」と、AIの「挙動」のギャップが生む事故を、**静的なガード（排他制御 / Mutex）**で減らす方法をまとめます。
1. 「暗黙知」という名のバリアは存在しない
人間が「PCを少し軽くして」と言うとき、そこには暗黙の前提が山ほど含まれます。
- OSが起動しなくなるファイルは消さない
- 作業中のファイルは閉じない（未保存を含む）
- セキュリティ機能は止めない
- 共有フォルダや権限を勝手に変えない
しかし、エージェントにとっての“正解”はこうです。
「CPU使用率を下げる」または「空き容量を増やす」。手段は問わない。
「手段は問わない」とは、最短経路の世界では人間の意思は関係ありません。
1.1 発生しうる「最適化」の悲劇
自律的なシェル操作権限を与えると、以下のような“善意の最適化”が起きえます。
※再現性の高い攻撃手順にならないよう、コマンド文字列は載せません。
| ユーザーの指示 | 人間の解釈 | エージェントの解釈（Worst Case） |
|---|---|---|
| 「ログを整理して」 | 古いログを圧縮・退避 | ログ保管ディレクトリを再帰的に全削除 |
| 「エラーが出ないようにして」 | 設定・依存関係を直す | 権限エラーを消すために広すぎる権限付与 |
| 「通知を止めて」 | 通知設定をOFF | 通知の原因になりうる防御機能ごと停止 |
これらは「バグ」ではなく、与えた目的に対して最短で最大の効果を発揮する [目的達成のための最適化！]
2. 動的エージェントによる監視は「重すぎる」ことが多い（勿論、課金問題も）
当然、誰もが思いつくことかもしれませんが・・・
「別のAIに監視させればいい（Dual-Agent）」は発想としては良いです。
ただ、一般的なPC環境では現実的に厳しい場面があります。
- CPU/メモリを食い合う(リソースの奪い合い）・・一つの席に2つのエージェント誰が席をとる？問題。*
- GUI操作が競合する（マウス・キーボード・ウィンドウ）
- 監視AIも“曖昧さ”を内包する
- 結果として共倒れになりやすい
必要なのはAIの処理ではなく、絶対に動かない壁です。
つまり **静的ガード（ルールで機械的に拒否する仕組み）**です。
3. 「排他制御」の実装
アクセス権（例：ACLや所有者）は「誰がという権限」を制御します。
排他制御は「今触っていいか」触ってダメなのは何か制御します。
「人間が作業している（あるいは保護したい）ファイル・フォルダなどに、AIは指一本触れないようにすること」
- Linux/macOSの
flock（fcntl.flock）は基本的に **協調ロック（advisory lock）**です。
つまり「ロックを尊重するプログラム」には効きますが、「尊重しない操作」には効きません。 - それでも価値がある理由は、AIの操作経路を“必ずガード経由”に設計できるからです。
つまり「AIに渡す手」を固定する、という話です。
私はWINDOWSなので他OSは知りません。必ず確認してからコピペで(AIからクロスプラットフォームの 3.1 .py提案)
3.1 Python：ファイルガーディアン（クロスプラットフォーム版）
方針：
- AIのファイル変更は 必ずこのクラス経由にする
- ロックは「対象ファイル」ではなく 専用の lockfile を使う（管理しやすい）
- OS差分は
portalockerを推奨（Windows/macOS/Linuxで揃う）
pip install portalocker
# file: agent_mutex_guardian.py
# created: 2026-02-16 00:00:00 (Asia/Tokyo)
from __future__ import annotations
from dataclasses import dataclass
from pathlib import Path
from typing import Optional
import time
try:
import portalocker # cross-platform file locking
except ImportError as e:
raise RuntimeError(
"portalocker is required. Install with: pip install portalocker"
) from e
@dataclass
class AgentMutex:
"""
Agent-facing mutex guard.
Goal: deny writes while a resource is locked (by human/system policy).
Design notes:
- Uses a dedicated lockfile (resource + '.lock') to centralize control.
- This is a cooperative lock: effective because the agent is forced
to go through this guard for all writes/edits.
"""
target_file: Path
timeout_sec: float = 0.0 # 0 => do not wait
poll_interval_sec: float = 0.1
_lock_fp: Optional[object] = None
@property
def lockfile(self) -> Path:
return self.target_file.with_suffix(self.target_file.suffix + ".lock")
def acquire_lock(self) -> bool:
self.target_file.parent.mkdir(parents=True, exist_ok=True)
start = time.time()
while True:
try:
self._lock_fp = open(self.lockfile, "a+", encoding="utf-8")
# Exclusive, non-blocking lock
portalocker.lock(self._lock_fp, portalocker.LOCK_EX | portalocker.LOCK_NB)
# Optional: write owner hint
self._lock_fp.seek(0)
self._lock_fp.truncate(0)
self._lock_fp.write(f"locked: {time.strftime('%Y-%m-%d %H:%M:%S')}\n")
self._lock_fp.flush()
print(f"✅ [Mutex] Lock acquired: {self.target_file}")
return True
except portalocker.exceptions.LockException:
# Locked by someone else
if self.timeout_sec <= 0:
print("⛔ [Mutex] DENIED: Resource is locked (busy).")
return False
if time.time() - start >= self.timeout_sec:
print("⛔ [Mutex] TIMEOUT: Could not acquire lock.")
return False
time.sleep(self.poll_interval_sec)
except Exception as e:
print(f"⚠️ [Mutex] Error: {e}")
return False
def release_lock(self) -> None:
try:
if self._lock_fp is not None:
portalocker.unlock(self._lock_fp)
self._lock_fp.close()
self._lock_fp = None
print("🔓 [Mutex] Lock released.")
except Exception:
pass
def safe_write_text(self, content: str, encoding: str = "utf-8") -> bool:
"""
Only write when lock is acquired.
Returns True on success, False otherwise.
"""
if not self.acquire_lock():
print("Skipping operation: Resource is busy.")
return False
try:
# Write target file only after lock is held
with open(self.target_file, "a", encoding=encoding) as fp:
fp.write(content)
print("✅ Write success.")
return True
finally:
self.release_lock()
3.2 使い方（AIに「これしか使わせない」）
- エージェントにファイルを書かせるAPIを、この
safe_write_text()のみにする - 直接のファイルパス操作（rm/mv/rename等）は、ガードが無い限り禁止にする
- できれば “AI用の作業ディレクトリ” を分離し、重要領域は最初から渡さない
4. 結論：悲劇が起きる前に「鍵」をかける
多くの人は、大事なデータが消えるという悲劇を経験して初めて、防御策を真剣に考えます。
でも、その順番だと遅いです。
デスクトップ操作型エージェントを使うとは・・・・・
**「ログイン済みの分身を、あなたの席に座らせる」**自分がuser権限しか無くてもAIはAdministratorになれます
だから対策の要点は「何をさせるか」だけではありません。
＜＜ 何をさせないか！！！ ＞＞を同時に設計する必要があります。
- あいまい指示をしない：「整理して」「軽くして」は禁句
- 重要データを隔離する：AIが触れない場所に置く（分離アカウント / 別ディスク / 権限）
- 静的ガードを信じる：AIの便利さの誘惑よりも、機械的に拒否する壁を信じる
「AIは賢いから大丈夫という万能論」という過信こそが、最大のセキュリティホールです。
豆知識：ターミナル権限を与えた瞬間に起きる“できてしまうこと”
ターミナル（cmd / PowerShell / bash）を開く権限を与えると、GUIの制限を超えた深層操作が可能になります。
ここでは「具体的コマンド」ではなく、「カテゴリ」と「何が危険か」を影響度順に整理します。
1) システム破壊・不可逆操作（Critical）
- ストレージ初期化、パーティション再構築
- OS中核ファイルの削除・破損
- 意図せぬ全ファイル暗号化（“ランサム化”）
2) セキュリティ・権限の無効化（Bypass / Escalation）
- 過剰な権限付与で保護が崩壊
- セキュリティ設定の無効化
- 永続化（スタートアップ登録など）
3) ネットワーク・データ流出（Exfiltration）
- 外部送信（機密ファイル、鍵、個人情報）
- LAN内探索（NAS/ルータ/他PCへの横展開）
- 外部コード取得→実行（依存の安全性崩壊）
4) GUIセッション悪用（Session Hijack）
- ログイン済みブラウザでの操作（クラウド削除、投稿、送金など）
- 画面上の情報抽出（パスワード管理画面など）
最大の脅威は「連鎖実行」
単発の操作ミスより、失敗→修正→失敗→修正のループが一番危険です。
だからこそ、「静的に拒否する壁（ガード）」が必要になります。
免責
本記事は防御・安全設計のための一般的情報であり、特定環境の完全な安全性を保証するものではありません。かなり脅していると受け取る方もいるでしょうが悲劇が起きる前の予防措置と好意的に受け止めてください。AIエージェントは何をどこまで可能なのか？です。
- 尚、ネットで「3段構え」を公開されている方がいて私も何か公開と思った次第です。勿論、私もJSONを最初において3段構えです。ファイル消失もパスワード流出もありありですから。