verbatim_prompts を有効にした後も、Claude はユーザー入力中のファイルパスへの言及を理解できるか？
理解はできるが、方法が異なる。展開機能を無効にすると、Claude は純粋なテキストとしての @path/to/file という文字列を受け取り、それでも「ユーザーがこのパスについて言及している」という意味を理解することはできる。ただし、ファイル内容を自動的に取得して prompt に埋め込む処理は行われない。アプリケーションで Claude に実際にファイルの内容を読ませる必要がある場合、verbatim_prompts を有効にした後はツール呼び出し（たとえば Claude に明示的にファイル読み取りツールを呼び出させる）を通じて実現する必要があり、メッセージの書式による自動発火には頼れない。
この違いは実はメリットでもある——ファイル読み取りがテキスト書式に隠された暗黙の挙動ではなく、明示的に許可・記録・範囲制限が可能なツール呼び出しになるからだ。
アプリケーションのメッセージの一部が開発者によるもので、一部がユーザー入力を組み込んだものである場合、ユーザー入力部分だけに verbatim_prompts を有効にできるか？
できない。verbatim_prompts はセッション全体、あるいは各 query() 呼び出し単位での設定であり、メッセージ内の特定部分にだけ適用されるトグルではない。prompt の組み立てロジックが開発者のテキストとユーザー入力を同じメッセージ内で混在させている場合、このオプションを有効にするとメッセージ全体で @path と slash command の解析がスキップされ、開発者が本来有効にしたかった部分も含まれてしまう。
より確実な方法は prompt 組み立てロジック自体を見直すことだ——開発者が意図するファイル展開や slash command の発火を、メッセージ書式に頼るのではなく明示的なツール呼び出しやプログラムロジックで処理するように変更すれば、verbatim_prompts を全体で有効にしても必要な機能を犠牲にせずに済む。
verbatim_prompts を有効にすると、Claude の応答の品質や挙動に影響するか？
設計上、モデル自体の理解や応答品質に直接影響することはない——このオプションが動かすのは SDK と CLI の間の prompt 前処理レイヤーであり、モデルの推論挙動ではない。違いが現れるのは、もともと @path 展開や slash command の発火に依存して動作していた機能だけだ。ワークフローがこれらの仕組みに頼ってファイルを自動取得したりコマンドを発火させたりしていた場合、有効化後はその自動化が機能しなくなり、明示的なツール呼び出しに置き換える必要がある。
アプリケーションがもともとこの2つの自動展開メカニズムに依存していなかった場合、このオプションを有効にしてもユーザー体験上は感知できないはずで、純粋に保護層が一つ増えるだけだ。
Claude Agent SDK を社内ツールとしてのみ使用し、利用者が自チームのメンバーだけの場合でも verbatim_prompts は必要か？
リスク評価の鍵は「利用者が誰か」ではなく「メッセージ内のテキストがすべて信頼できる当事者によって生成されたものか」にある。利用者が自チームのメンバーであっても、アプリケーションのメッセージ組み立てロジックに外部由来のテキスト——顧客のメール内容の貼り付け、スクレイピングしたウェブテキスト、サードパーティシステムから返されたフィールドなど——が混ざっている場合、その外部テキスト自体が意図せず @path や slash command の書式に一致する断片を含んでしまい、意図しない挙動を引き起こす可能性がある。悪意のある攻撃である必要はなく、単なる書式の偶然の一致でも発火し得る。
したがって判断基準は「このメッセージ内に開発者自身が打ち込んだもの以外のテキストが含まれているか」であって、「このツールを使う人が信頼できるか」ではない。
Claude Agent SDK で構築されたアプリケーションによくあるアーキテクチャパターンは、ユーザー入力、データベースのフィールド、外部 API から取得したテキストを、そのまま Claude CLI に送る prompt 文字列に組み込むというものだ。問題は、SDK のデフォルトの prompt 処理が、メッセージ内の特定のパターンを「コマンド」として解釈してしまうことにある——@path/to/file のような記法はファイル内容に展開され、/ で始まる文字列は slash command として発火する可能性がある。このテキストが開発者自身が書いたものではなく、信頼できないソース（ユーザーが貼り付けた内容、サードパーティシステムから返されたフィールド）由来である場合、これは具体的なインジェクションリスクとなる：悪意のある者が入力に @/etc/passwd や slash command を偽装した文字列を仕込むだけで、意図しないファイル読み取りやコマンド発火を引き起こせる可能性がある。
新しく追加された ClaudeAgentOptions.verbatim_prompts（デフォルトは False）オプションは、有効化するとユーザーメッセージが書かれたとおりそのまま CLI に渡され、@path によるファイル展開も slash command の発火も行われなくなる。つまり、テキスト内にコマンドのように見える記法が何であれ、Claude が受け取るのは純粋なテキストそのものであり、書式の偶然の一致によってファイルアクセスやコマンド実行の副作用が引き起こされることはない。このオプションは query() 関数呼び出しと、インタラクティブな ClaudeSDKClient.connect()／ClaudeSDKClient.query() の両方で利用でき、文字列入力と非同期イテラブル入力の両方の形式をカバーしている。注意すべき点として、この機能には CLI 2.1.248 以上が必要であり、古い CLI でこのオプションを有効にすると警告がログに記録されるものの実行は中断されない——つまりデプロイ環境が古い CLI バージョンに固定されている場合、この保護は実際には機能しないため、バージョン番号を別途確認する必要がある。
アプリケーションのアーキテクチャにおいて、Claude に送られるすべての prompt が開発者自身の制御するテキストのみで組み立てられ、外部からの生テキストがどこにも含まれないのであれば、verbatim_prompts がもたらす違いはそれほど大きくない。攻撃者が制御できる入力経路がそもそも存在しないからだ。しかしアーキテクチャのどこか一箇所でも、ユーザー入力、スクレイピングしたウェブコンテンツ、サードパーティ API のレスポンスを処理せずに CLI に送るメッセージ文字列へ直接組み込んでいる場合、それは現実に存在するインジェクション面となる——これはカスタマーサポートボット、文書要約ツール、あるいは「外部コンテンツを読んで回答する」あらゆるアプリケーションでよく見られるパターンだ。このようなアプリケーションは verbatim_prompts=True を問題が起きてから後付けするものではなく、デフォルトで有効にすべき保護として扱うべきだ。
はっきりさせておく必要があるのは、verbatim_prompts が解決するのは具体的な攻撃面——@path 展開と slash command の書式を通じて引き起こされる意図しないファイル読み取りやコマンド発火——であるという点だ。より広義の prompt injection 問題、たとえば攻撃者が入力テキストの中で自然言語を使い、モデルに以前の指示を無視させたり、出力すべきでない内容を誘導したりする問題は対象外であり、これらは依然としてシステムプロンプトの設計や出力検証など他の手段で対処する必要がある。verbatim_prompts を唯一の防御線として扱うのは誤解であり、これは多層防御の一層にすぎず、防御全体ではない。
チームが Claude Agent SDK を使って外部入力に触れるアプリケーション——カスタマーサポートシステム、コンテンツ分析ツール、またはサードパーティのテキストを prompt に組み込むあらゆるアーキテクチャ——を構築しているなら、今すぐどのメッセージ組み立て経路に信頼できない生テキストが含まれているかを棚卸しし、該当する経路に対して verbatim_prompts を有効化すべきだ。同時にデプロイ環境の CLI バージョンが 2.1.248 以上であることを確認する必要がある。そうでなければこのスイッチは実際には機能しない。この種のセキュリティオプションのコストは低い（ブール値のパラメータ一つ）が、実際に問題が起きてから追加するのでは、今10分かけて確認するよりもはるかに高い代償を払うことになる。