朝、コーヒーを入れてPCの前に座る。Claude Codeを起動して「昨日の続きのバグを直して」と指示を出す。すると、Claude Codeがファイルを読もうとするたびに「許可しますか？」と尋ねてくる。ソースコードを開くのに許可。設定ファイルを確認するのに許可。テストを走らせるのに許可。npmのスクリプトを実行するのに許可。気がつけば、10分間で20回もEnterキーを叩いていた。

これは「承認疲れ」と呼ばれる現象です。AIコーディングツールがファイルの読み書きやコマンドの実行をするたびに確認ダイアログを出すため、作業の流れが細切れになってしまう。せっかくAIが自律的にコードを書いてくれるのに、人間がボタンを押す係になっている。本末転倒です。

しかし、だからといって全ての承認を無効にすれば良いわけでもありません。2025年10月、あるファームウェアプロジェクトでClaude Codeが rm -rf / を実行し、システム全体が消失する事故が起きました。同年12月には、パッケージのクリーンアップを指示しただけで、Macのホームディレクトリ全体が削除される事件も報告されています。承認の仕組みは、こうした事故から私たちを守る防波堤なのです。

この記事では、Claude Codeが提供する承認制御の仕組みを体系的に解説し、「安全性を維持したまま承認疲れを解消する」ための具体的な設定方法をお伝えします。読み終えたら、ご自身の settings.json を開いて、明日から使える設定をすぐに適用できるはずです。

なぜAIコーディングツールに承認が必要なのか

AIコーディングツールは、従来のコード補完とは根本的に異なります。GitHub Copilotの初期バージョンのように「次の1行を提案する」だけなら、人間がそれを採用するかどうかを判断すれば済みます。しかしClaude Codeのようなエージェント型AIツールは、ファイルの作成・編集・削除、シェルコマンドの実行、Webからの情報取得、Git操作まで自律的に行います。つまり、人間の開発者と同等の操作権限を持ちうるのです。

この「自律性」こそがエージェント型AIの強みですが、同時に最大のリスクでもあります。先述の事故事例に加え、全ての承認をスキップするフラグの使用中に意図しないファイル変更やデータ損失が発生した報告がGitHubのIssueトラッカーに複数寄せられています。「AIが優秀だから全部任せよう」という姿勢は、鍵を開けたまま家を出るのと同じです。OWASP Top 10 for LLM Applicationsでも、LLMに過剰な権限を付与するリスクは主要な脅威として挙げられています。

Claude Codeの権限モデルは、**「deny-first（まず拒否する）」と「最小権限の原則」**を根底に設計されています。ルールの評価順序は deny、ask、allow の順で、最初にマッチしたルールが勝ちます。deny（拒否）は絶対的な拒否権を持ち、いかなる下位の設定でも覆すことができません。これは「誤って許可するリスク」よりも「誤って拒否するリスク」を選ぶという安全設計の思想です。

では、この安全設計を活かしながら、日常の作業をスムーズにするにはどうすれば良いのか。Claude Codeは、段階的に承認を制御するための複数の仕組みを用意しています。

Claude Codeが提供する承認制御の全体像

Claude Codeの承認制御は、大きく4つの層で構成されています。静的なルール設定、モードによる一括制御、プログラムによる動的制御、そしてAIによる自動判断です。それぞれの特徴と使いどころを順に見ていきましょう。

第1段階：permissions allow / deny — 信頼するツールを事前登録する

最も基本的な制御が、settings.json の permissions セクションで定義する静的なルールです。「このツールは常に許可する」「このツールは絶対に拒否する」「このツールは毎回確認する」という3種類のルールを、パターンマッチで指定できます。

たとえば、npm run test は毎日何十回も実行するコマンドです。これをいちいち承認するのは時間の無駄でしょう。一方で、git push は本番環境に影響しうる操作なので、毎回確認したい。.env ファイルにはAPIキーが入っているから、AIには絶対に読ませたくない。こうした判断を事前にルールとして書いておけば、Claude Codeはそのルールに従って動作します。

ルールの書き方は ツール名(パターン) という形式です。Bash(npm run *) と書けば、npm run に続く任意のコマンド（npm run test、npm run build など）が許可されます。ファイルパスに対しては、* が単一階層、** が再帰的なマッチを表します。Read(./src/**/*.ts) なら、src ディレクトリ配下の全てのTypeScriptファイルの読み取りが対象になります。

ここで注意すべき重要なポイントがあります。Read(./.env) を deny に設定しても、Bash(cat .env) は別のルールです。Readツールによるアクセスはブロックされますが、Bashのcatコマンド経由での読み取りはブロックされません。機密ファイルの保護には、Readの deny だけでなく、Bashコマンドの制限やサンドボックスの併用が不可欠です。この多層防御の考え方は、後述するHooksやサンドボックスの解説で詳しく触れます。

第2段階：権限モード — 用途に応じた一括制御

Claude Codeには6つの「権限モード」があり、用途に応じて切り替えることで承認の粒度を一括変更できます。Shift+Tabキーでモードを順に切り替えられます。

モードファイル編集コマンド実行主な用途
default確認あり確認あり初回利用、慎重な作業
acceptEdits自動承認確認あり日常のコード修正
plan不可不可設計レビュー、調査のみ
autoAIがリスク判定AIがリスク判定集中コーディング（後述）
dontAsk未登録ツールは自動拒否未登録ツールは自動拒否CI/CD的な限定実行
bypassPermissions全て自動全て自動コンテナ内の隔離環境のみ

日常的に最も使いやすいのは acceptEdits モードです。このモードでは、ファイルの編集操作は自動的に承認されますが、シェルコマンドの実行には引き続き確認が求められます。つまり、Claude Codeがコードを書き換えるのは自由にやらせるけれど、外部コマンドを走らせるときは人間がチェックする、という運用になります。

コードの修正作業が中心の日は、このモードが特に有効です。バグの修正やリファクタリングでは、Claude Codeが多数のファイルを連続的に編集します。その一つひとつに承認を出していたら作業が進みません。一方で、npm install や git commit のようなコマンドは比較的少ないので、そこだけ確認しても負担は小さいのです。

plan モードは、Claude Codeに「調べるだけ、触らないで」と伝える使い方です。新しいプロジェクトのコードベースを把握したいときや、設計方針を相談したいときに適しています。dontAsk モードは、事前に allow リストに登録したツールだけを実行し、未知のツールは自動的に拒否します。CI/CDパイプラインのように、決まった操作だけを繰り返す場面で使います。

bypassPermissions モードは開発マシンでは絶対に使わないでください。このモードは全ての承認を無効化するもので、冒頭に紹介した事故はまさにこのモードの使用中に発生しました。Dockerコンテナや仮想マシンのような、壊れても影響がない隔離環境でのみ使うべきものです。

第3段階：Hooks — プログラムで承認判断を自動化する

permissions の allow/deny は「事前に決めた静的なルール」です。しかし実際の開発では、同じツールでも文脈によって許可すべきかどうかが変わることがあります。たとえば、src/ ディレクトリ内のファイル編集は自由にやらせたいけれど、package.json や tsconfig.json のような設定ファイルの編集は確認したい。こうした文脈依存の判断を自動化するのが Hooks です。

Hooks は、Claude Codeの各種イベント（ツール実行前、実行後、権限確認時など）にシェルスクリプトやHTTPリクエストを紐づける仕組みです。LLMの判断に依存しない決定論的な制御を実現できる点が、permissions ルールとの大きな違いです。

権限制御でとくに重要なのは PreToolUse フックです。これはツールが実行される直前に発火し、スクリプトの終了コードや出力するJSONによって、そのツール呼び出しを許可・拒否・確認のいずれかに振り分けることができます。

具体例として、特定のファイルへの編集をブロックするフックを見てみましょう。settings.json に次のように設定すると、Edit または Write ツールが呼ばれるたびに protect-files.sh というスクリプトが実行されます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-files.sh"
          }
        ]
      }
    ]
  }
}

このスクリプト内で対象ファイルを検査し、保護対象であれば終了コード 2 で終了すれば、Claude Codeはその編集操作をキャンセルします。終了コード 0 で正常終了すれば、操作は続行されます。

2026年3月のアップデートでは、Hooks に条件付き実行の if フィールドが追加されました。これにより、permissions ルールと同じ構文で「どのツール呼び出しに対してフックを発火させるか」を細かく制御できます。たとえば "if": "Bash(git *)" と指定すれば、Git関連のコマンドにだけフックが発火し、それ以外のBashコマンドでは無視されます。

Hooksのもう一つの活用法が、操作の監査ログです。PostToolUse フックを使えば、Claude Codeが実行した全てのBashコマンドをファイルに記録できます。何か問題が起きたとき、「AIが何をしたのか」を後から追跡できるのは、組織運用において非常に重要です。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' >> ~/.claude/command-log.txt"
          }
        ]
      }
    ]
  }
}

Hooks には command（シェルスクリプト）、http（HTTPエンドポイント）、prompt（LLMに単発判断させる）、agent（サブエージェントによる多ターン検証）の4タイプがあります。ほとんどの場合は command タイプで十分ですが、社内の承認APIと連携させたい場合には http タイプが有効です。

ここで押さえておくべき設計原則があります。Hooks の allow 判定は、対話的な確認プロンプトをスキップするだけであり、deny ルールを覆すことはできません。managed settings で deny されたツールは、Hooks でどう設定しても実行されません。deny-first の原則は、Hooks経由でも一貫して維持されます。

補足：CLAUDE.mdによる指示ベースの制御

permissions や Hooks と並んで活用したいのが、CLAUDE.mdファイルです。これはプロジェクトルートに配置するマークダウンファイルで、Claude Codeへの「指示書」として機能します。たとえば「テストは必ずすべてパスさせてからコミットする」「本番データベースへの直接接続は禁止」といったプロジェクト固有のルールを自然言語で記述できます。CLAUDE.mdはプロジェクトレベル（./CLAUDE.md）、ユーザーレベル（~/.claude/CLAUDE.md）、さらにManaged Settingsレベルでも配置でき、.claude/rules/ ディレクトリにはパスごとの条件付きルールも定義できます。

ただし、CLAUDE.mdはLLMへの指示であり、permissions のような強制力のある制御ではない点に注意してください。重要なセキュリティルールは permissions の deny で強制し、CLAUDE.md は開発プラクティスや作業手順の指示に使う、という使い分けが適切です。

第4段階：Auto Mode — AIが2層防御でリスク判定する

2026年3月24日にリサーチプレビューとして公開された Auto Mode は、これまでの制御とは異なるアプローチを取ります。各操作についてClaude自身が「この操作はどの程度リスクがあるか」を推論し、低リスクと判断した操作は自動承認、高リスクと判断した操作はユーザーに確認を求めるというものです。

Auto Mode は権限システムを無効化するのではなく、AIによるリスク分類で拡張する仕組みです。内部的には2層の安全機構を備えています。

  • 入力層: サーバーサイドのプロンプトインジェクション検出プローブが、ツールの出力を事前にスキャンします
  • 出力層: Claude Sonnet 4.6ベースの分類器が、各操作を2段階（高速フィルタ → 連鎖的推論）で評価します

claude --enable-auto-mode で有効化でき、Shift+Tab でモードを切り替えられます。長時間のコーディングセッションで、承認プロンプトに中断されることなく作業に集中できるのは大きなメリットです。autoMode.environment 設定で信頼するインフラ（特定のMCPサーバーや内部APIなど）を宣言でき、autoMode.allow や autoMode.soft_deny でAIの判定基準を細かく調整することも可能です。

ただし、現時点ではリサーチプレビューの段階です。Anthropicは公式セキュリティドキュメントで「no system is completely immune to all attacks（いかなるシステムも全ての攻撃に対して完全に免疫ではない）」と述べており、プロンプトインジェクション防御の研究でも防御の限界を認めています。依存ファイルやコマンド出力に悪意ある指示が埋め込まれるプロンプトインジェクション攻撃を完全に検出・ブロックできる保証はありません。また、各操作に追加の推論処理が必要になるため、トークン消費とコストが増加します。対話的な数時間の使用なら軽微ですが、バッチ処理や自動パイプラインでは無視できない負担になりえます。

Auto Mode は「試す価値はあるが、本番環境では慎重に」というのが現時点での結論です。評価目的で隔離環境（devcontainerや仮想マシン）内で試用し、組織導入は安定版を待つのが賢明です。

実際のsettings.json設定例 — 明日からコピペで使える

ここまでの制御層を解説しましたが、理論だけでは明日から何も変わりません。具体的な設定ファイルの例を示します。ご自身の環境に合わせて調整し、そのまま使ってみてください。

日常開発向けの基本設定

まず、個人の開発作業で使う基本的な設定です。プロジェクトルートの .claude/settings.json に配置します。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npx prettier *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push --force *)",
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env*)",
      "Edit(./.env*)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

この設定の意図を説明します。allow には日常的に繰り返し実行するコマンドを登録しています。npm run test や npm run build、Gitの状態確認やコミットなどは、いちいち承認する必要がありません。deny には、絶対に実行させたくない操作を並べています。rm -rf による再帰的削除、curl や wget による外部通信、.env ファイルへのアクセスは、どんな状況でもブロックします。ask には、実行前に一度立ち止まって確認したい操作を入れています。git push はリモートリポジトリに影響しますし、wrangler pages deploy は本番サイトへのデプロイです。

defaultMode を acceptEdits にしているのは、上記の allow/deny/ask のいずれにも該当しない操作について、ファイル編集は自動承認し、コマンド実行は確認するという動作にするためです。

JSON Schema Storeで公開されている $schema キーを指定すると、VS Codeなどのエディタで設定ファイルを開いたときにオートコンプリートが効くようになります。設定キーの入力ミスを防げるので、ぜひ追加しておきましょう。

監査ログ付きの設定

チームで開発している場合、Claude Codeが実行したコマンドの記録を残しておくと安心です。上記の設定に Hooks を追加します。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npx prettier *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push --force *)",
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env*)",
      "Edit(./.env*)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "defaultMode": "acceptEdits"
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' >> ~/.claude/command-log.txt"
          }
        ]
      }
    ]
  }
}

この設定により、Claude Codeが実行した全てのBashコマンドが ~/.claude/command-log.txt に記録されます。「昨日のセッションでAIが何をしたか」を後から確認できるので、トラブルシューティングにも役立ちます。

パターンマッチの書き方で気をつけること

ルールのパターン記述にはいくつかの落とし穴があります。知っておかないと意図しない動作を招くので、ここで整理しておきます。

Bash(npm run *) のようにスペースの後に * を付けた場合、* はワードバウンダリ（単語の区切り）を強制します。つまり npm run test や npm run build にはマッチしますが、npm runaway にはマッチしません。一方、Bash(ls*) のようにスペースなしで * を付けると、ls で始まるあらゆる文字列にマッチします。ls -la だけでなく lsof にもマッチするので注意が必要です。

ファイルパスの指定は3種類の起点があります。./ はカレントワーキングディレクトリ（プロジェクトルート）相対、~/ はホームディレクトリ相対、// はファイルシステムのルートからの絶対パスです。Windowsの場合、パスはPOSIX形式に正規化されるため、C:\Users\alice は /c/Users/alice として扱われます。

MCP（Model Context Protocol）サーバーのツールに対しても同様のパターンが使えます。mcp__puppeteer__* のように mcp__サーバー名__ツール名 の形式で、特定のMCPサーバーが提供するツールを個別に許可・拒否できます。

設定ファイルの4層構造を理解する

Claude Codeの設定は、1つのファイルだけで完結するわけではありません。4つの階層が重なり合い、それぞれの deny ルールがマージされる構造になっています。この構造を理解しておかないと、「設定したのに効かない」「なぜかブロックされる」といった状況に戸惑うことになります。

最も優先度が高いのは Managed Settings です。これはIT管理者がシステムレベルで配置する設定ファイルで、macOSでは /Library/Application Support/ClaudeCode/managed-settings.json、Windowsでは C:\Program Files\ClaudeCode\managed-settings.json に置きます。ここで deny されたルールは、どの階層の設定でも覆せません。2026年3月には managed-settings.d/ ディレクトリによるドロップイン方式もサポートされ、チームごとに独立したポリシーファイルを管理できるようになりました。

次に優先されるのが CLI引数 で、--allowedTools や --disallowedTools オプションとしてセッション単位で指定できます。

Local Settings は .claude/settings.local.json に配置する個人用設定で、gitignoreに追加して共有しません。実験的な許可ルールを試すときに使います。Project Settings は .claude/settings.json に配置し、gitでチームと共有します。プロジェクト固有の共通ルールをここに書きます。

最も優先度が低いのが User Settings で、~/.claude/settings.json に配置します。全プロジェクトに共通する個人設定（言語設定、通知フックなど）をここに置きます。

重要なのは、配列型の設定（permissions.allow など）は上書きではなくマージ（結合）される点です。Project Settings で Bash(npm run *) を allow し、User Settings で Bash(git status) を allow していれば、両方が有効になります。ただし、上位レベルで deny されたツールは、下位レベルでいくら allow しても使えません。

他のAIコーディングツールとの比較

Claude Code以外のAIコーディングツールも権限制御の仕組みを持っていますが、その設計思想はかなり異なります。

Cursor は、エディタと一体化したAI統合IDEです。権限制御は .cursor/rules/*.mdc ファイルでルールを記述しますが、これはLLMへの「指示」であり、Claude Codeの permissions のような決定論的な制御ではありません。「このファイルは編集しないでください」と指示しても、LLMが指示を無視する可能性がゼロではないのです。CursorのEnterprise版ではMDMやGPOによる管理者制御が可能ですが、確定的なブロック機構はHooksに相当するものがなく、Claude Codeほどきめ細かい制御はできません。

GitHub Copilot は、GitHubプラットフォームとの統合を強みとするツールです。権限制御はOrganizationレベルとEnterprise Policyレベルの2層構造で、機能単位（コード補完、Agent Mode、Code Reviewなど）のON/OFFを管理画面から設定します。「特定のBashコマンドだけ許可する」といったツール単位の細かい制御ではなく、機能全体の有効/無効を切り替える設計です。SOC 2認証やSSO/SCIMなどのコンプライアンス基盤は3ツールの中で最も成熟しており、規制産業での導入実績が豊富です。

Windsurf（旧Codeium）は、2025年後半から急成長したエージェント型AIエディタです。Cursorと同様にIDE一体型で、Cascadeと呼ばれるエージェントがファイル操作やコマンド実行を行います。権限制御はツール実行前の確認ダイアログが中心で、Claude Codeのようなパターンベースの事前ルール定義やHooksによるプログラマブルな制御には対応していません。

The Pragmatic Engineerの2026年AIツーリング調査では、開発者の46%がClaude Codeを「最も好きなツール」に選び、Cursor（19%）やGitHub Copilot（9%）を大きく引き離しています。その支持の背景にあるのが権限制御の精緻さです。4ツールの権限制御を比較すると、Claude Codeが最も粒度が細かく、決定論的な制御が可能です。Hooksによるプログラマブルな権限判断は他のツールにはない独自の強みで、「このファイルは絶対に触らせない」「このコマンドは絶対に実行させない」という確実な制御が求められる場面で力を発揮します。一方で、設定の複雑さは最も高いため、導入時には段階的なアプローチが重要になります。

組織で導入するときの段階的アプローチ

個人で使う分には、先ほどの settings.json をコピーすれば済みます。しかし、チームや組織で Claude Code を使う場合は、managed settings による全社統制と段階的な導入計画が必要です。

Phase 1：プロジェクト設定で基本ルールを共有する

最初のステップは、.claude/settings.json をgitリポジトリにコミットし、チーム全員が同じ deny/allow ルールで作業することです。機密ファイルへのアクセス禁止、危険なコマンドのブロック、日常コマンドの許可を定義します。このファイルはプルリクエストでレビューできるので、ルールの変更が透明化されます。

Phase 2：監査ログの収集を始める

PostToolUse フックで全てのBashコマンドを記録し始めます。この段階では、ログを収集するだけで、ブロックや制限は追加しません。1〜2週間のログを分析すれば、「チームメンバーが日常的に使っているコマンド」と「想定外の操作」が見えてきます。このデータが、次のフェーズの設定根拠になります。

Phase 3：Managed Settingsで全社セキュリティポリシーを強制する

Phase 2のログ分析結果を踏まえ、managed-settings.json を全社に展開します。ここで定義すべき最低限のルールは次の通りです。

{
  "permissions": {
    "deny": [
      "Read(//**/.env)",
      "Read(//**/secrets/**)",
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "disableBypassPermissionsMode": "disable"
  }
}

disableBypassPermissionsMode を "disable" に設定することで、--dangerously-skip-permissions フラグと bypassPermissions モードを組織全体で無効化できます。これにより、個人の判断で全承認をスキップする事故を防げます。

Managed Settings には、HooksやMCPサーバーの統制機能もあります。allowManagedPermissionRulesOnly を true にすれば、個人やプロジェクトの allow/deny ルールを無視し、Managed ルールだけを適用できます。allowManagedHooksOnly は個人の Hooks を無効化し、allowManagedMcpServersOnly はMCPサーバーの接続先を管理者承認のものだけに制限します。セキュリティ要件が厳しい環境では、これらの設定を組み合わせて統制を強化できます。

Managed Settings のデプロイ方法はOSによって異なります。macOSではMDM（Jamf、Kandjiなど）経由でmanaged preferencesとして配布するか、ファイルを直接配置します。Windowsではグループポリシー（GPO）やIntuneでレジストリ値を配布するか、ファイルを直接配置します。既にMDMやGPOの基盤がある組織なら、既存の配布フローに乗せるだけです。

Phase 4：Auto Modeの評価と限定導入

Phases 1〜3が安定したら、Auto Mode の評価を開始します。まずは隔離環境（devcontainerや仮想マシン）内で試用し、AIのリスク判定精度を検証します。問題がなければ、限定的なプロジェクトから導入を広げていきます。

Auto Modeを組織として禁止したい場合は、Managed Settings に以下を追加します。


defaults write com.anthropic.claudecode disableAutoMode -string "disable"


HKLM\SOFTWARE\Policies\ClaudeCode → disableAutoMode = disable

managed-settings.json に記述する方法でも同様に制御できます。明示的に許可するまでブロックするのが、組織導入における安全な姿勢です。

設定の最適化は「段階的に、信頼できるものから」

この記事で解説した制御層をまとめます。

制御層制御の性質導入のしやすさ制御の確実性
permissions allow/deny静的・パターンマッチすぐ始められる高い（deny は絶対）
acceptEdits モードモード切替設定1行高い
Hooks動的・プログラマブルスクリプト記述が必要高い（deny は覆せない）
Auto ModeAI判断（2層防御）フラグ1つ中程度（リサーチプレビュー）

「承認疲れ」は、AIコーディングツールの宿命ではありません。設定で解消できる問題です。ただし、全ての承認を一気に外すのは事故の元です。まずは permissions の allow に、毎日使う安全なコマンドを登録するところから始めてください。数日使ってみて問題がなければ acceptEdits モードを有効にし、さらにHooksで監査ログを取り始める。この「段階的に、信頼できるものから」というアプローチが、安全性と生産性を両立する唯一の方法です。

settings.json の1行が、チーム全体の生産性を変えます。明日の朝、AIツールを起動する前に、まず設定ファイルを開いてみてください。

参考資料

あわせて読みたい