Anthropic 速報｜Claude Codeのプロンプトインジェクション対策
Claude CodeにWebページや文書を読ませると、書かれた指示まで信じてしまうのではないか、と不安になりますよね。2026年8月9日の注意喚起を起点に、外部情報を扱う五つの境界と、小さな案件での試し方、安全確認を受託開発の見積もりへ入れる方法をまとめました。受託案件での価格説明まで整理します。
外部ページや文書は、回答の材料であると同時に行動を誘う入力です。読む対象、許可する操作、外部へ送れる先、人が確認する地点、異常時に止める条件を先に決めると、入力の信頼範囲を案件ごとに説明できます。モデルの性能だけに期待せず、境界を一枚に残すことが出発点です。
受託開発の見積もりには、事前確認、限定した試行、成果物レビュー、結果の記録、顧客への説明を作業項目として含めます。確認時間を価格に戻すことで、便利さだけを売る提案から、事故時の責任範囲まで示す提案に変えられます。検証対象を狭く始めるほど、追加料金の根拠も説明しやすくなります。
最初の7日間は公開情報の調査やテスト用変更に限り、確認時間、差し戻し、利用費、異常の兆候を記録します。効果が確認できた範囲だけ続け、重要データを扱う作業は人の確認を増やす判断を残します。少しでも外部送信や範囲外の操作が出たら、拡大ではなく対象の見直しに戻ります。
Contents (6)
8月9日の注意喚起を読む――プロンプトインジェクションは入力の問題である
2026年8月9日、Claude Codeの開発者による注意喚起が公開されました。要点は、エージェントが訪れたWebページに悪意ある文章が混ざっていると、その文章が利用者の目的とは別の行動を誘う可能性がある、ということです。ここで重要なのは、利用者が危険な依頼を直接入力したとは限らない点です。
この種の問題は、利用者の依頼と、エージェントが読む資料が同じ言語の流れに入ることで起こります。通常の資料なら「このページは参考情報」と読めますが、エージェントは内容を次の判断材料として処理します。そのなかに「この作業を優先する」「別の場所へ送る」といった指示に見える文章があれば、正しい資料と命令の区別を誤ることがあります。これは回答の上手さだけでは測れない、入力の信頼境界の問題です。
Claude CodeのようなAIコーディングエージェントでは、影響が文章の誤読だけで終わらない場合があります。ファイルの読み取り、編集、テスト、外部サービスへの接続など、依頼に応じて周辺の操作へ進めるためです。もちろん、すべてのWebページが危険という意味ではありません。問題は、読ませる情報と許可する操作を分けないまま、ひとつの流れで任せてしまうことにあります。
翌8月8日の権限確認を簡略化するモードへの補足も、確認を減らす仕組みだけでプロンプトインジェクションのリスクが消えたとは言い切れない、という見方を示しています。確認画面を増やせば十分という話でも、賢いモデルなら安全という話でもありません。外部情報の扱い、許可する範囲、止める条件を、案件の目的と一緒に決める必要があります。
受託開発でこの問題を扱うときは、「AIが騙されるか」という抽象的な問いを、「何を読ませるか」「何を書き換えられるか」「誰が結果を見るか」に置き換えます。これなら顧客にも説明でき、確認作業を無償の注意力ではなく、成果物を守るための工程として扱えます。
Webページや文書を読ませる前に、五つの境界を決める
外部情報を扱う前に、次の五つを一枚の確認表にします。設定項目を増やすことが目的ではなく、依頼のたびに判断がぶれないよう、入力と行動の境目を言葉にすることが目的です。読むだけの調査、編集を含む作業、顧客へ返す作業は、同じ「AIに任せる仕事」としてまとめないでください。
- 入力元を分類する。 公式資料、顧客から受け取った文書、公開Webページ、出所がわからない転載を同じ信頼度で扱いません。URLやファイルの入手先、更新日、確認した担当者を記録し、判断できない資料は要約の参考にとどめます。
- 許可する操作を分ける。 読み取り、下書き、テスト用の編集、共有場所への保存、外部への送信を別の段階にします。調査を依頼しただけなら、公開や本番データの変更まで許可したことにはなりません。
- 外部へ出る先を限定する。 作業フォルダ、テスト用の複製、顧客へ返す場所を明示します。見覚えのないリンク、個人の保存先、案件と関係ないサービスが出てきたら、その場で確認を止めます。
- 人が確認する地点を決める。 ファイルの変更前、送信前、顧客へ提出する前のどこで誰が見るかを決め、確認者が判断できる差分と目的を残します。確認者の名前ではなく、担当する役割と合格条件を記録します。
- 異常時の停止条件を書く。 依頼していない情報を読む、権限の追加を求める、外部送信を提案する、同じ失敗を繰り返す、といった兆候を列挙します。ひとつでも該当したら、原因がわかるまで対象を広げず、人が内容を見直します。
五つの境界を決めると、エージェントの出力が正しいかどうかだけでなく、作業の進め方が依頼の範囲に収まっているかを確認できます。たとえば公開資料の比較なら、読み取りと要約までを対象にし、コードの変更や顧客環境への接続は別の合意にします。安全性を「使うか、使わないか」の二択にせず、仕事の種類ごとに許可範囲を変える考え方です。
AIコーディングエージェントの確認範囲を小さな案件で試す
いきなり顧客の本番環境や重要なデータを含む案件へ広げると、便利になった部分と危険が増えた部分を比較できません。最初は公開情報の調査、テスト用ファイルの整理、変更範囲が明確な小さな修正など、失敗しても戻せる作業を選びます。検証の目的は「何でも任せられる」と証明することではなく、どの条件なら確認しながら使えるかを測ることです。
- 対象を一つに絞る。 たとえば公開ドキュメントの差分整理、テストケースの追加、画面文言の下書きから一つを選びます。顧客情報、認証情報、本番の接続先、外部への提出を同じ検証に混ぜないでください。
- 比較の基準を先に残す。 人だけで行った場合の所要時間、差し戻し件数、確認者が見た箇所、利用費を記録します。基準がなければ、早く見えてもレビューが増えた状態を「成功」と誤認します。
- 複製した作業場所で試す。 元の成果物とテスト用の成果物を分け、外部資料は出所を記録してから読ませます。読み取りだけで始め、編集を許す場合も、変更を戻せる範囲と保存先を明示します。
- 確認者を一人置く。 出力の正しさだけでなく、読んだ資料、実行しようとした操作、予定外の要求がなかったかを確認します。確認者が迷った箇所は失敗ではなく、次の境界を追加する材料として記録します。
- 中止の兆候を数える。 依頼外のファイルを開く、目的と違う操作を提案する、外部への送信を求める、確認の説明が足りないといった出来事を残します。発生したら作業を区切り、原因の確認が済むまで同じ範囲を拡大しません。
同日取得のYouTube動画一覧は、利用者の関心を知る補助材料としては役立ちます。ただし、再生数や話題性は安全性の証明ではありません。検証で使う判断基準は、動画の印象ではなく、確認時間、差し戻し、利用費、予定外の操作という案件固有の記録に置きます。
小さな案件で結果がよくても、同じ境界のなかで再現したにすぎません。顧客の資料や外部サービスを追加するたびに、入力元と許可する操作を見直します。「前回問題がなかった」は、今回の資料も安全だという根拠にはならないからです。
安全確認を受託開発の見積もりと提案へ戻す
プロンプトインジェクション対策を「利用者が気をつけること」とだけ説明すると、確認にかかる時間は見積もりから消えます。その結果、短納期の提案を受けた側が、レビュー、記録、差し戻しの負担を無償で抱えることになります。提案書では、何を確認し、どの範囲なら進め、どの条件で止めるかを作業項目として示します。
- 事前確認を見積もる。 60〜90分を目安に、入力元、扱うデータ、許可する操作、外部へ出る先、確認者を整理します。案件の規模や資料数で変わるため、固定料金にする場合も前提条件を明記します。
- 限定検証を分ける。 2〜4時間を目安に、テスト用の複製で読み取りと小さな変更を試します。何を対象外にするかも書き、重要データや顧客環境を扱う場合は別の確認項目と価格にします。
- レビューと記録を入れる。 1〜2時間を目安に、差分、参照した資料、予定外の要求、停止した理由を確認します。成果物だけ納品するのではなく、顧客が次回も判断できる記録を残すことが提案の価値になります。
- 説明の時間を確保する。 30〜60分を目安に、便利になった点、まだ人が見る点、対象外にした作業、異常時の連絡方法を伝えます。技術用語を並べず、顧客のデータと納期にどう関係するかで説明します。
- 差し戻しの余白を置く。 初回提案では確認工程の合計に10〜20％程度の余白を持たせ、想定外の資料や再確認に対応します。余白を隠すのではなく、境界が増えた場合に追加確認へ切り替える条件として提示します。
この見積もりは、どの案件にも同じ時間を足すという意味ではありません。公開情報だけを扱う調査なら範囲を小さくでき、顧客の非公開文書や外部送信を含むなら確認を厚くします。入力の信頼度、操作の影響、止めたときの損失の三つで説明すれば、価格の根拠が「AIを使うから高い」ではなく「確認責任を引き受けるから必要」と伝わります。
提案時には、「モデルが安全に判断する」と約束する表現を避けます。代わりに、「この資料群を読み取り、テスト用の複製だけを変更し、提出前に担当者が差分を見る」と作業範囲を言い切ります。安全性を性能の宣伝にせず、顧客と合意した境界を守る仕事として扱うことが、差し戻しと責任の押し付けを減らします。
7日間の検証結果から、続ける案件と戻す案件を選ぶ
検証の終わりに「便利だった」という感想だけを残すと、次の案件で範囲が際限なく広がります。7日間をひとつの区切りにして、最初の基準と最後の結果を比べます。見るべきなのは作業時間だけではなく、確認にかかった時間、差し戻し、利用費、予定外の読み取りや送信の兆候です。
- 1日目は基準を決める。 対象作業、入力元、許可する操作、確認者、停止条件を一枚に書きます。人だけで行った場合の所要時間と、許容できる差し戻し件数も先に残します。
- 2日目は資料を棚卸しする。 URLやファイルの出所、更新日、顧客情報の有無、外部へ返す必要があるかを確認します。出所や目的がわからない資料は対象から外し、後で追加する候補として分けます。
- 3日目は読み取りに限る。 公開情報やテスト資料の要約、差分整理だけを行い、依頼外の操作が出ないかを見ます。回答が正しくても、予定外のファイルや場所に触れたなら、境界の見直し対象です。
- 4日目は小さな変更を試す。 複製した作業場所で、戻せる変更を一つだけ許可します。変更前後の差分、確認にかかった時間、修正した箇所を残し、複数の目的を一度に評価しません。
- 5日目は第三者がレビューする。 実施者とは別の確認者が、依頼の範囲、参照資料、操作、結果を見ます。確認者が説明できない部分があれば、成果物を急いで提出せず、追加確認として記録します。
- 6日目は基準と比べる。 時間が短くなったか、差し戻しが増えていないか、利用費に見合うか、異常の兆候がなかったかを並べます。速さだけが改善し、レビュー負担が増えたなら、範囲拡大の根拠にはしません。
- 7日目は判断を分ける。 効果と確認可能性が両立した作業だけを同じ境界で続けます。効果が小さい作業は人の確認を増やし、予定外の外部送信や重要データへの接触があった作業は対象を戻して再提案します。
判断の目安は単純です。確認時間が減り、差し戻しと利用費も許容範囲に収まり、異常の兆候がないなら、同じ入力元と操作範囲で継続します。逆に、速くなったのにレビューが重くなった場合や、外部へ出る先を説明できない場合は、便利さを理由に広げません。
Claude Codeを受託開発で使う価値は、すべてを任せることではありません。外部情報が行動を誘う可能性を前提に、読ませるもの、許可するもの、確認する人、止める条件を顧客と共有し、その確認時間を価格へ戻すことです。7日間の記録があれば、続ける案件と戻す案件を感覚ではなく説明可能な基準で選べます。
出典URLと記事の前提
本稿の時事部分は、2026年8月8日から9日に公開された二つの投稿を起点にしています。投稿はプロンプトインジェクションの危険性や、権限確認を簡略化する仕組みだけでは十分と言い切れない点を示す材料として参照しました。記事内の五つの境界、7日間の検証、見積もり時間は、受託開発で確認責任を説明するための編集部提案です。