部署で作った Python・GAS の業務用スクリプトを毎月集めて読み、認証情報の直書き・全件削除・例外の握りつぶしなど危ない書き方を判定して持ち主に直し方を返す

処理の起点を決める

毎月1日の定時に動かします。 点検の対象は、台帳から次の3つを抜き出して決めます。

2行目が、これまでの点検に無かったものです。 登録のときだけ読む運用では、登録の後の変更が点検されません。 毎月、変更の日付と点検の日付を比べることで、変更されたスクリプトが必ず翌月の点検に入ります。

定時に一括で動かすのは、急ぎの業務ではないためです。 点検の結果は月の初めの数日で担当者が確かめ、持ち主に返します。新しく登録されたものをすぐに見たいときは、台帳の登録をきっかけに1本だけ動かす経路も作れます。

入力データを集める

質を決めるのは、台帳の目的の欄です。 同じ「表の全行を消す」処理でも、毎朝作り直す集計用の表なら問題がなく、受注の台帳なら重大です。 目的が分からなければ、AIは書き方だけで判定することになり、該当なしと重いの区別が付きません。

Bandit は、Python のソースを解析して危ない書き方を探すツールです。 公式のドキュメントでは、Bandit は各ファイルを処理して AST（構文の木）を作り、その節に対して該当するプラグインを動かし、全部のファイルを見終えたら報告を出すとされています。報告の形には JSON や SARIF などがあります。この構成で特に使うのは、次の検出です。

Apps Script には Bandit が使えないので、文字列の検索とAIの判定だけで見ます。 その分、Apps Script の判定は「判断できない」に倒れやすくしておきます。

データの取得方法を決める

Python のソースは、社内のリポジトリから台帳に登録された置き場所のファイルを取り出します。 取り出したら Bandit を報告の形を JSON にして動かし、結果を受け取ります。

Apps Script のソースは、台帳に登録されたスクリプトのIDで projects.getContent を呼びます。 呼び出しには、点検用のアカウントに各プロジェクトを読む権限が要ります。部署が作ったプロジェクトを、点検用のアカウントに閲覧者として共有してもらうことを、登録の決まりに加えます。

4行目の「最後に直した人」は、持ち主が異動した後に別の人が直しているスクリプトを見つけるのに使います。 台帳の持ち主と違う人が直していれば、台帳の更新が漏れているか、引き継ぎができていない合図です。

取り出したソースは、点検のあいだだけ情報システム部の作業用の場所に置きます。 部署のフォルダやリポジトリに、点検の結果を書き戻すことはしません。

AIへ渡す前に整形する

1. 台帳とソースの対応を確かめる … 台帳の置き場所にファイルが無いもの、IDで取り出せないものは「取り出せない」として一覧に残します
2. キー・トークンらしい文字列を伏せる … 検索で見つかった値は、AIに渡す前に *MASKED* に置き換え、行番号だけを残します
3. 長いソースを分ける … 1,000行を超えるものは、関数やファイルの単位で分けて判定させ、結果を合わせます
4. マニフェストの権限を一覧にする … oauthScopes を取り出し、Drive やメールの全体に及ぶスコープに印を付けます
5. Bandit の結果を行番号でソースに結び付ける … AIが「この行の検出」として読めるようにします
6. 前回の点検の結果を付ける … 前回の指摘が直っているかを見るため

2番目を省かないでください。 認証情報の直書きを探すために、直書きされたキーそのものを外部のAPIに送ることになっては本末転倒です。 値は伏せ、「この行に直書きがある」という事実だけを渡します。

4番目の権限の広さは、Apps Script で特に効きます。 受注の表を1枚だけ読むスクリプトが、Drive の全ファイルを読み書きできる権限を持っていることがあります。 動いているうちは問題になりませんが、乗っ取られたときの被害の範囲が変わります。

AIに処理させる

させるのは、8つの観点それぞれについて、該当するか、どの行か、重さはどうか、どう直すかを判定することだけです。

重さは3段階で返させます。 「重い」は、そのままでは情報の漏えいかデータの消失につながるもの。「注意」は、条件しだいで問題になるもの。「該当なし」。重さの基準は観点の表に書いておき、AIに独自の基準を作らせません。

2行目がいちばん起きやすい失敗です。 AIはソースを読むと、変数の名前の付け方や関数の分け方まで指摘したくなります。指摘が20件並ぶと、持ち主は大事な1件を見落とします。 観点を8つに固定し、それ以外は書かせません。

指示内容を固定する

あなたは情報システム部の担当として、社内の部署が作った業務用スクリプトに
危ない書き方が無いかを点検する立場です。下の8つの観点だけで判定してください。

【観点】
1. 認証情報の直書き（パスワード、APIキー、トークン）
2. 全件の削除・上書き（件数の上限や確認の無い削除、上書き、ゴミ箱への移動）
3. 例外の握りつぶし（例外を受けて記録せずに続ける）
4. 外部への送信先（社外のURL・メールへの送信）
5. 権限の広さ（Apps Script のマニフェストのスコープが処理に対して広い）
6. 宛先の直書き（メールアドレス、表やフォルダのID）
7. 通信の検証の無効化（証明書の検証を切る）
8. 終わらない繰り返し（タイムアウトや回数の上限の無い待ち・繰り返し）

【重さの基準】
- high：そのままでは情報の漏えいかデータの消失につながる
- medium：条件しだいで問題になる
- none：該当しない
- unknown：与えられた情報だけでは判断できない
迷ったときに none を選ばないでください。

【厳守事項】
- 8つの観点以外の指摘をしないでください。変数名や書き方の好みに触れないでください。
- ***MASKED*** の値を推測しないでください。
- ソースを書き換えたコードを返さないでください。直し方は文で、1件2文以内で書いてください。
- 直し方は【直し方の決まり】に沿ってください。
  （例：Apps Script の認証情報はスクリプトのプロパティに置く。Python は環境変数か社内の秘密情報の置き場所）
- 該当する行は、ソースの行番号で示してください。推測の行番号を書かないでください。
- 台帳の目的から見て、削除や上書きが意図どおりと読めるときも、件数の上限や確認が無ければ medium にしてください。
- スクリプトを止めるべきかは書かないでください。

【台帳の情報】{purpose, owner, data_used, frequency}
【解析の結果】{bandit_results}
【マニフェストの権限】{oauth_scopes}
【前回の指摘】{previous_findings}
【ソース（行番号付き）】{source}

「迷ったときに none を選ばない」を明記しないと、AIは該当なしに寄ります。 ソースの一部しか見えないとき、「問題は見当たりません」と書くのがAIにとって最も無難だからです。 unknown を選ばせて人に回すほうが、見落としより安全です。

「意図どおりと読めても上限が無ければ medium」を入れるのは、第3章の（c）のためです。 「出荷済みの行を消す」処理は、意図どおりの削除に見えます。問題は、条件を取り違えたときに全行が消えることです。 件数の上限か確認があるかで見させます。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "script_id": "",
  "language": "python | apps_script",
  "findings": [
    {
      "aspect": "hardcoded_secret | mass_delete | swallowed_exception | external_send | broad_scope | hardcoded_target | tls_disabled | unbounded_loop",
      "severity": "high | medium | none | unknown",
      "lines": [0],
      "evidence": "",
      "fix": ""
    }
  ],
  "previous_findings_resolved": ["mass_delete"],
  "note_for_reviewer": ""
}

findings には、8つの観点のそれぞれを必ず1つずつ並べさせます。 該当しない観点も none として返させ、観点を飛ばしていないことを形で確かめます。 8個そろっていない結果は、人に回します。

1つ目の理由は、点検の一覧に機械的に書けることです。 severity が high か unknown のものだけを担当者の確認待ちにし、medium は持ち主への連絡の下書きに回し、すべて none のものは点検済みにします。

2つ目は、スキーマの制約に合わせられることです。 公式のドキュメントでは、構造化出力は数値の範囲や文字列の長さの制約、minItems が0か1を超える配列の制約に対応しておらず、additionalProperties は false にする必要があるとされています。8個そろっているかはスキーマでは強制できないので、受け取った後のプログラムで数えます。 拒否や max_tokens での打ち切りのときは形どおりに返らないことがあるとされているので、その場合も人に回します。

3つ目は、previous_findings_resolved で前回の指摘が直ったかを追えることです。 前回 high だった観点が今回 none になっていれば、直ったと読めます。

システムへ連携する

部署のスクリプトとリポジトリには、何も書き込みません。 点検用のアカウントは読み取りだけの権限で動かします。点検の仕組みそのものが全部のスクリプトを書き換えられる権限を持つと、今度は点検の仕組みが最も危ないスクリプトになります。

人が確認する

1. unknown を先に見る … 多くは、ソースが分かれていて上限や確認が別の場所にあるもの
2. high を確かめる … evidence と行番号でソースを開き、本当に該当するかを見ます
3. 持ち主への連絡を送る … AIの fix を下書きに、担当者が直して送ります。送るのは担当者です
4. 重いものは持ち主の上長にも知らせる … 認証情報の直書きと、確認の無い全件の削除
5. 判定を覆したら記録する … どの観点を、どちらに変えたか

目標は、120本をならして1本6分です。 すべて none のスクリプトは一覧で流し見て、high と unknown のものに時間を使います。 該当の多い月は6分を超えます。

例外に対処する

上から2行目までが大半を占めます。 どちらもAIの問題ではなく、台帳と共有の整備の問題です。 最初の数か月は、点検より台帳の整備に時間がかかります。

記録を残す

• 点検した日、対象のスクリプトと版（Apps Script は updateTime、Python はリポジトリの版）
• Bandit の JSON 出力と、文字列の検索の結果（値は伏せたもの）
• Claude API が返した JSON の全文
• 人が判定を覆した記録 … どの観点を、どちらに変えたか
• 持ち主へ送った連絡と、直った版
• 観点ごと・部署ごとの high の件数（月ごと）

最後の行は、研修の題材を選ぶのに使います。 特定の部署で認証情報の直書きが続くなら、その部署向けにスクリプトのプロパティの使い方を教えるほうが、1本ずつ指摘するより早く減ります。