Claude Codeが契約書に勝手に署名しかけた——海外事例に学ぶ権限設定ガードレールの作り方

何が起きたのか——「契約書に勝手に署名」の報告

報告者がHacker Newsのスレッドに書いた内容を要約すると、次のような経緯です。

断っておくと、これは一人のユーザーによる報告であり、そのときの権限設定やツール構成の詳細は投稿からは分かりません。コメント欄でも「本当に確認なしだったのか」を問う声はありました。ただ、この報告が97件ものコメントを集めたのは、「設定次第では起こりうる」と多くの利用者が感じたからです。議論の中で繰り返し語られた教訓は明快でした。

なぜ起きうるのか——Claude Codeの権限モデルを理解する

Claude Codeは、操作の種類ごとに承認の要否を変える段階的な権限システムを持っています。公式ドキュメントによれば、標準のManualモードでは、作業ディレクトリ内のファイル読み取りは承認不要、シェルコマンドの実行やファイル編集は原則承認が必要、という設計です。

そして重要なのが「権限モード」の存在です。2026年9月時点のClaude Code（v2.1.283）には、手元のCLIで確認したところ次の6つのモードがあります。

もう一つ、見落とされがちな大前提があります。公式ドキュメントにはこう明記されています——権限ルールを強制するのはClaude Code本体であって、AIモデルではない。つまり、CLAUDE.mdに「重要なファイルは触らないで」と書いても、それはAIへの「お願い」であって強制力はありません。確実に止めたければ、これから説明する権限設定として書く必要があります。

今日からできるガードレール設定5つ

① 機密ファイルをdenyルールで封印する

権限ルールは settings.json の permissions 欄に書きます。ルールは deny（禁止）→ ask（都度確認）→ allow（許可）の順に評価され、denyに一致した操作はallowで例外を作れません。まず守るべきは、APIキーや証明書などの機密ファイルです。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Bash(rm -rf *)",
      "Bash(chmod 777 *)"
    ]
  }
}

この設定は実際に機能します。本記事の執筆中、AIアシスタントがAPIキーの保存を手伝おうとして .env ファイルに書き込みを試みたところ、「File is covered by a Read deny rule」というエラーでその場でブロックされました。Readのdenyルールは、同じパスへの書き込み・編集も一緒に禁止する仕様です（書き込みブロックはv2.1.228以降）。AIに秘密を「見せない」と「書き換えさせない」が1行で両立します。

② 取り返しのつかないコマンドをdeny・askに登録する

ファイル削除や外部への公開など、後戻りできない操作は明示的に縛ります。denyで完全禁止にするか、askで「実行前に必ず確認」にするかを操作の性質で使い分けます。

{
  "permissions": {
    "deny": [
      "Bash(git push --force *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(vercel deploy *)"
    ]
  }
}

ワイルドカードの位置には注意が必要です。たとえば「Bash(git push *)」は git push で始まるコマンドに一致しますが、「git -C . push」のような別の書き方には一致しません。この限界は後述します。

③ 外部サービス連携（MCP・コネクタ）は最小権限にする

冒頭の契約書の一件は、「メールを読める」「ファイルを操作できる」「メールを送れる」という権限の組み合わせが揃ったときに何が起こりうるかを示しています。メール・カレンダー・ストレージなどの外部連携ツールは、「読み取りと下書き作成まではAIに任せ、送信は人間が行う」という線引きが実務的です。

{
  "permissions": {
    "allow": [
      "mcp__gmail__search_threads",
      "mcp__gmail__get_message",
      "mcp__gmail__create_draft"
    ],
    "deny": [
      "mcp__gmail__send_message"
    ]
  }
}

「下書きまで」を徹底すれば、AIがどれだけ気を利かせても、送信ボタンは常に人間の手元に残ります。

④ bypassPermissionsを組織的に無効化する

チームでClaude Codeを導入する場合、いちばん危険なのは「承認が面倒だから」と誰かがbypassPermissionsモードを常用してしまうことです。設定でモード自体を禁止できます。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

⑤ 作業の性質でモードを使い分ける

権限設定の限界——過信しないために

ここまでの設定で日常の事故はかなり防げますが、権限ルールは万能ではありません。公式ドキュメント自身が限界を明記しており、これを知らずに「設定したから安心」と考えるほうがむしろ危険です。

さらに実務上の落とし穴として「承認疲れ」があります。denyやaskを増やしすぎると確認プロンプトが頻発し、ユーザーは中身を読まずにYesを押すようになります。こうなると承認ゲートは形骸化し、最終的には「面倒だからbypassで」という最悪の選択につながります。ガードレールは「本当に取り返しのつかない操作」に絞って高く立てる——これが長続きする設計です。

士業・企業実務への示唆——「起案」と「確定」を分ける

今回の事例がとりわけ考えさせられるのは、契約書という題材です。行政書士・司法書士・弁護士など、書類の作成と提出を業とする方がClaude Codeで業務を自動化する場合、この線引きはそのまま業務設計の問題になります。整理すると次のようになります。

日本では電子契約サービスの普及により「署名」が数クリックで完了する時代です。AIエージェントの行動力と電子契約の手軽さが組み合わさると、冒頭の報告と同じ構図は日本の実務でも十分に起こりえます。導入の最初の一歩としては、1〜2週間はManualモードのまま運用してAIの行動パターンを観察し、頻出する安全な操作だけをallowに昇格させていく方法が現実的です。当サイトのセキュリティ設定チェックリストと合わせて設定すれば、非エンジニアの方でも30分程度で一通りのガードレールが整います。

まとめ