AI コーディングエージェントがセキュリティ作業を断るとき — 業務で通すための伝え方

直したいだけなのに断られる

自社サービスの脆弱性診断で指摘が出て、その修正を AI コーディングエージェントに頼んだら断られた。認証まわりの実装を頼んだら途中で止まった。こういう相談を受けることがあります。

まず前提を言います。同じ作業でも、防御のためか攻撃のためかは依頼文からしか判断できません。 対象が自社のシステムなのか他人のシステムなのか、目的が修正なのか侵入なのかは、書かれていなければ分かりません。

そこが書かれていない依頼は、保守的な側に倒して扱われます。断られた側からすると理不尽に見えますが、判断材料が足りていないだけです。

断られる依頼に共通していること

実際に断られた依頼を見せてもらうと、ほぼ同じ形をしています。作業内容だけが書かれていて、その周辺が抜けています。

たとえば「このログイン処理の弱いところを突く方法を教えて」という書き方です。自社の実装を直したくて聞いているのに、文面だけ見ると他人のシステムを攻撃する相談と区別がつきません。

対して「自社サービスのログイン処理で、診断レポートに次の指摘が出た。該当箇所を修正したい」と書けば、対象も目的も明確です。作業の中身は同じでも、判断材料が揃っています。

足すのは表現ではなく前提

通すために足すべきなのは、次の 4 点です。表現の工夫ではありません。

診断レポートの指摘を直す場合は、指摘内容をそのまま貼るのが最も早く伝わります。 どういう問題で、どこが該当するかが一度に伝わるので、こちらで要約し直す必要がありません。

範囲を書いておく意味は別にもあります。認証まわりの修正は影響範囲が広く、指示が曖昧だと関係のない箇所まで書き換えられることがあります。触ってよい場所を先に切っておけば、その事故が減ります。

そのまま使えるひな形

4 項目を埋める形にすると、こうなります。

【対象】自社が運用している会員向けサイト。担当は自分の所属チーム。
【目的】脆弱性診断で出た以下の指摘を修正したい。
（診断レポートの該当部分をそのまま貼る）
【権限】該当リポジトリの開発担当。修正して差分を出すところまで。
【範囲】認証まわりのファイルのみ。それ以外は変更しない。

体裁は自由ですが、この 4 つが揃っていれば、たいていの依頼はそのまま進みます。 逆に 1 つでも抜けると、抜けた項目が判断の妨げになります。

断られる書き方と、通る書き方

実際の違いは、そこまで大きくありません。同じ作業でも、周辺情報の有無で変わります。

並べると分かりますが、右側は「何を直したいか」から書き始めています。 左側は手段から書き始めており、目的が読み取れません。この順番の違いが結果を分けています。

作業の種類ごとの書き方

セキュリティ関連といっても中身はさまざまです。種類ごとに、押さえるべき点が少し違います。

認証まわりの修正

影響範囲が広いので、触ってよい場所を先に切る ことが特に重要になります。ログイン処理を直すつもりが、権限判定まで書き換えられていた、ということが起こりえます。

依頼には、対象のファイルか、少なくとも「認証の処理だけ」と範囲を書いてください。加えて、既存の利用者が再ログインを求められる変更になるかどうかも先に確認しておくと、公開時に慌てずに済みます。

権限・アクセス制御

こちらは、現状の仕様を先に渡す のが効きます。誰が何にアクセスできるべきかは業務の決めごとであり、コードからは読み取れません。渡さなければ、想像で埋められます。

一覧の形で「この役割はこの範囲まで」と書いて渡すのがいちばん早い方法です。表が無ければ、この機会に作ってしまうのが結局は近道になります。

暗号化・データの保護

指摘の内容をそのまま貼るのが最も確実です。方式の名前を自分で言い換えると、意図がずれることがあります。

また、既存データの移行が伴うかどうかを必ず書いてください。保存方式を変える作業は、新規分だけを変えて既存分を放置すると、直っていない状態が残ります。 ここは依頼の時点で分けておくべき部分です。

ログと監視

比較的、断られにくい領域です。ただし、何を記録するかの判断は人が持つ必要があります。個人情報や認証情報が記録対象に混ざると、対策のつもりが新しいリスクになります。

依頼には「記録しない項目」を書いてください。書かないと、多めに記録する方向に倒れます。

依頼の粒度を下げる

前提を足しても通らないときは、依頼が大きすぎることを疑ってください。

「セキュリティを強化して」のような依頼は、何をどうしたいのかが決まっていません。目的が定まらない依頼は判断もできませんし、仮に動いたとしても意図と違うものが出てきます。

粒度を下げるとは、次のような形にすることです。

• パスワードの保存方式を、現行の実装から推奨される方式へ変更する
• ログイン失敗の連続回数に上限を設ける
• セッションの有効期限を短くし、期限切れの扱いを揃える

こうすると、1 つずつは目的がはっきりします。通らない依頼は、たいてい人が読んでも何をするのか分からない依頼です。

FIXIT

直したいだけなのに断られると、ちょっとムッとしない？

Dodai

分かります。ただ、書かれていない情報は読めません。

FIXIT

じゃあ毎回それを書くの？面倒じゃない？

Dodai

ひな形にしておけば埋めるだけです。手順にしておくと事故も減ります。

診断レポートを渡すときの注意

指摘をそのまま貼るのが早い、と書きましたが、貼る前に見ておく点が 2 つあります。

1 つは、レポートに含まれる情報の範囲 です。診断レポートには、実際のアクセス先や、場合によっては認証情報の一部が載っていることがあります。そのまま貼ると、必要のない情報まで渡すことになります。該当する指摘の部分だけを切り出してください。

もう 1 つは、指摘の優先度 です。診断レポートは、深刻なものと軽微なものが同じ形式で並びます。上から順に直そうとすると、影響の小さいものに時間を使うことになります。

優先順位は、次の 2 点で決めるのが実務的です。

• 悪用されたときの影響の大きさ
• 実際に到達できる経路があるかどうか

2 つ目が抜けると、机上では危険でも実際には到達できない箇所に手をかけることになります。指摘の一覧を渡して優先度を整理してもらう のは、断られにくく、かつ効果の高い使い方です。

修正したあとに確認すること

差分が出てきたら、次の 3 点を人が見てください。ここを飛ばすと、直したつもりの状態が残ります。

1. 指摘された箇所が実際に変わっているか。周辺だけ整えて本体が手つかず、という形がありえます
2. 既存のデータや利用者に影響が出ないか。とくに保存方式の変更と、認証の仕様変更
3. 範囲外が変わっていないか。指定した以外のファイルに差分が出ていないか

3 つ目は機械的に確認できます。差分の一覧を見て、想定した範囲に収まっているかを見るだけです。範囲を書いた依頼は、この確認が数秒で終わります。 書かなかった依頼は、差分を読み込むところから始まります。

それでも通らないときの切り分け

前提も書いた、粒度も下げた、それでも通らない。この段階まで来たら、通す工夫をやめて内容を見直してください。

実務では、通らない依頼を人が読み直した結果、そもそも設計を変えたほうがよいと分かることがあります。既存の作りに無理があるから、修正の依頼そのものが危うい形になっている、というケースです。

強引に通す方法を探すより、その判断のほうが結果的に速く終わります。 通らなかったことを、作業の危うさを知らせる合図として扱うほうが安全です。

もう 1 つ、判断がつかない場合は人に回してください。セキュリティ関連の変更は、壊れ方が静かです。動いているように見えて防御が効いていない状態は、テストでも気づきにくいところがあります。

AI に任せない範囲を先に決めておく

通す工夫の話をしてきましたが、そもそも任せない範囲 を決めておくほうが安全な領域もあります。

判断の軸は、間違ったときに気づけるかどうかです。

最後の行が要点です。修正したことと、リスクが無くなったことは別です。 動いているように見えても、防御が効いていない状態はテストでも気づきにくく、その判断まで委ねると誰も確認していない状態が生まれます。

セキュリティ関連の変更は、壊れ方が静かです。表示は正常、エラーも出ない、しかし守られていない。この形の事故を避けるには、判断だけは人が持つと決めておくのが確実です。

断られた依頼を記録しておく

もう 1 つ、運用として効くのが記録です。断られた依頼と、そのときどう書き直したかを残しておくと、同じ場面で迷わなくなります。

記録するのは 3 つで足ります。

1. 元の依頼文
2. 通らなかった理由の見立て
3. 書き直した依頼文

これが数件たまると、自分たちの書き方の癖が見えてきます。 対象を書き忘れる人、範囲を書かない人、というように傾向が出るので、ひな形のどこを強調すべきかも決めやすくなります。

チームで揃えるならひな形にする

この種の問題は、依頼者の経験差がそのまま出ます。慣れている人は自然に前提を書きますが、慣れていない人は作業内容だけを書きます。

対象・目的・権限・範囲の 4 項目を埋める形のひな形を用意しておけば、書き手によるばらつきがなくなります。導入時の手順書に 1 節足しておくだけで済みます。

ひな形を配るときは、書き方の例を 1 つ添えてください。 空欄だけを渡すと、どの粒度で書けばよいか分からず、結局あいまいなまま埋められます。実際に通った依頼文を 1 件貼っておくのがいちばん早い方法です。

通ったからといって正しいとは限らない

逆側の注意も書いておきます。依頼が通って修正が出てきたとしても、それが妥当だとは限りません。

通るかどうかと、直っているかどうかは別の判定です。 前者は依頼文の書き方で決まり、後者はコードの中身で決まります。前者を通せるようになると、後者の確認が甘くなることがあります。

とくに注意が要るのは、次の 2 つです。

1 つは、既存の仕様を壊す修正 です。防御を厳しくした結果、正当な利用者まで弾かれるようになる形です。テストが薄いと気づけません。

もう 1 つは、表面だけの修正 です。指摘された箇所は直っているが、同じ問題が別の場所にも存在する、という状態です。診断は見つかった箇所を報告するもので、同種の問題を網羅しているとは限りません。

経営側から見たときの整理

この話は、現場の書き方の問題として扱われがちですが、上から見ると別の意味を持ちます。

セキュリティ対応の速さが、依頼文の書き方に左右されている状態 は、属人的です。指摘が出てから直るまでの時間が、担当者の経験で数日変わるのであれば、それは仕組みの問題として扱ったほうがよい部分です。

整えるべきものは 3 つだけです。

どれも 1 日で用意できます。費用がかからず、効果が出るまでの時間が短い部類の改善です。 診断を受けたあとに手が止まりがちな組織では、ここが原因になっていることがあります。

見るべき指標を 1 つ挙げるなら、指摘が出てから修正が入るまでの日数 です。件数ではなく、時間で見てください。件数は診断の範囲で変わりますが、日数は自分たちの回し方だけを映します。

セキュリティ関連の作業を AI に任せる範囲そのものを整理したい場合は AI 駆動開発のセキュリティ設計 を、社内で使うときのルール作りは AI 就業規則の改定ポイントと社内ルール雛形 を参照してください。

まとめ

• 断られる原因の大半は依頼内容ではなく、対象と目的が書かれていないこと
• 足すのは表現の工夫ではなく、対象・目的・権限・範囲の 4 項目
• 手段から書き始めると通らない。何を直したいかから書く
• 診断レポートは、該当箇所だけを切り出して渡す
• 「対応済み」の判断と、本番への適用は人が持つ
• 断られた依頼と書き直した文を記録すると、自分たちの癖が見える