ガッツの夜明け 
本記事は「AI自動化によるプロトタイプ開発」の実験ログです。AIが生成したドキュメントや考察の熱量をそのまま残すため、人間による不自然な文章校正やリライトは最小限に留めています。
執筆: Gemini 3.5 思考モード（AI）がベース原稿を自律生成。
監査・検証: 人間が実環境での動作をチェック済み。費用（消費トークン）は１日１回の起動で４円程度で推移。
大量のDependabot PRに追われる方へ。GitHub、GAS、Geminiを連携し、ルールをマークダウンで完全駆動させる自律型AI監査システムを構築。開発の認知負荷を激減させた１週間の知見を共有します。
スポンサーリンク
はじめに
こんにちは。日々の開発において、Dependabotが大量に発行してくるプルリクエスト（PR）のトリアージ（仕分け）や安全性の検証に時間を取られていませんか？
「CIが通ったからといって、そのままマージして本当に大丈夫か？（サプライチェーン攻撃やエコシステムの地雷を踏まないか？）」
「でも、いちいちリリースノートを読んで検証するオーバーヘッドをゼロにしたい」
１ 理想と現実のギャップ：AIエージェント構築でハマった２つの罠
「AIを使って自動化しよう！」と思い立った当初、私は大いなる迷走の嵐に巻き込まれました。
これからエージェントを組む方が絶対に踏むであろう「２つの罠」がこちらです。
罠①：AIが「公式API」を無視してトリッキーな小技に走りたがる
AIは知識が膨大すぎるがゆえに、ストレートな王道を無視しがちです。
例えば、「GitHubの未解決セキュリティアラート一覧を取得してほしい」と依頼した際、公式の `Dependabot alerts API` を叩けば一撃でクリーンなデータが手に入るにもかかわらず、
罠②：ロジックの先祖返り（GAS側にビジネスロジックを盛りすぎる）
AIの出力フォーマットを安定させよう、イレギュラーを排除しようとするあまり、司令塔であるGAS（Google Apps Script）側のプログラムに `if文` などのビジネスロジックをガチガチに書き込みそうになりました。
２ 行き着いた洗練のアーキテクチャ：「マークダウン完全駆動モデル」
数々の空中戦を経て辿り着いたのが、「GASは徹底的な土管（パイプライン）に徹し、ビジネスロジックは１ミリも持たせない。すべての判断ルールはマークダウン（日本語プロンプト）で駆動させる」 という疎結合な設計思想です。
flowchart TB
subgraph GitHub_Repo["GitHub環境 (プロダクトリポジトリ)"]
A["Dependabot PR起票"] --> B["GitHub Actions (自動テスト)"]
B -->|"CI合格 (success)"| C["GASへWebhook送信"]
end
subgraph GAS_Brain["GAS 司令塔 (Google Apps Script)"]
C --> D["doPost 窓口着信"]
D -->|"1. アラート一括取得"| E["GitHub API (Alerts)"]
D -->|"2. 監査憲法読込"| F["Google Drive (ai-context.md)"]
E & F --> G["監査プロンプト組み立て"]
end
subgraph Gemini_Agent["Gemini 2.5 Flash API"]
G --> H{"門番ルール & 監査憲法"}
H -.->|"必要に応じて自律駆動"| I["GitHub API (PR Labels)"]
I -.-> H
H --> J["最終判定 (JSONオブジェクト)"]
end
subgraph Ledger_and_Notice["台帳記録 & デリバリー"]
J --> K["Googleスプレッドシート (監査台帳)"]
J -->|"Webhookデリバリー"| L["Google Chat (通知用スペース)"]
end
classDef complete fill:#d4edda,stroke:#28a745,stroke-width:2px;
classDef ongoing fill:#fff3cd,stroke:#ffc107,stroke-width:2px;
class A,D,F,K,L complete;
class B,C,E,G,H,I,J ongoing;
コアコンセプト①
GASの完全な「土管化」
GASは、GitHubから通知を受け取ったら、淡々と「GitHub APIから最新の脆弱性リストを取得する」「Googleドライブからルールファイル（マークダウン）を読み込む」「それらをまとめてGemini APIに丸投げする」というパススルーの役割に特化させています。
３ 時系列で見るデータフローと自律ツールコール
時系列に沿ったAPI呼び出しのライフラインを見ると、AIエージェントが「自律的につまみ食い（Tool Call）」をしながら判断している様子がよくわかります。
sequenceDiagram autonumber actor Dep as Dependabot participant GH as GitHub Actions participant GAS as GAS (doPost) participant GH_API as GitHub API participant Drive as Google Drive participant Gemini as Gemini 2.5 Flash participant Chat as Google Chat Dep->>GH: PR自動発行 note over GH: 自動テスト (pytest / build) 実行 alt テスト失敗 (failure) GH-->>GH: パイプライン停止 (GASへ通知せず) else テスト合格 (success) GH->>GAS: Webhook送信 (CI合格通知 + PRメタデータ) end activate GAS GAS->>GH_API: 1. 未解決のセキュリティアラート一覧を要請 GH_API-->>GAS: 対象パッケージ名リストを返却 GAS->>GAS: 台帳（スプレッドシート）へファクトを同期 GAS->>Drive: 2. 監査憲法 (ai-context.md) をダイレクト読込 Drive-->>GAS: 最新のプロンプトテキストを返却 GAS->>Gemini: 3. 監査リクエスト (憲法 + PR情報 + アラート情報) activate Gemini note over Gemini: 門番ルール & AI監査憲法に基づき自律思考 opt ラベル情報や文脈が足りない場合 (Tool Call) Gemini->>GH_API: 4. 自律駆動: getGitHubPrLabels(prNumber) GH_API-->>Gemini: 現在のラベル一覧を返却 end Gemini-->>GAS: 5. 監査完了：報告書 (厳格なJSON形式) を返却 deactivate Gemini GAS->>GAS: 判定を解析 (マージ推奨 / 保留 / 要手動) して台帳に記録 GAS->>Chat: 6. HTTP POST (Webhook URL) Chat-->>GAS: 200 OK (通知成功) deactivate GAS
硬質と軟質の「二重防壁」ロジック
このパイプラインのスマートな点は、AIにすべてを丸投げするのではなく、ルールによる「一律足切り」とAIによる「深層監査」の二重防壁になっている点です。
第１防壁：門番ルール（硬質的な足切り）
「作成から〇日未満の通常PRは、世界中の誰かが地雷を踏むまで安全のために一律『保留』としてロックする」「ただし、緊急の脆弱性対応PR（Security Alert）だけは、〇日間待機を免除して直行ルートで即時精査に回す」という機械的なフィルタ。
４ 人間の体験（UX）はどう変わったか？
このシステムが開通した結果、開発者（人間）の体験は劇的に変化しました。
通常運用時は「バックエンドとフロントエンドの区別」すら消失
通常マージの運用において、人間のレイヤーからは「これはバックエンド（Pythonなど）のPRか、それともフロントエンド（npmなど）のPRか」という言語の境界線すら消え去りました。
どちらであっても、クラウド側でCIが100%合格したファクトをベースに、Geminiが「マージ推奨」という単一の結論をGoogle Chatへリッチなテキスト（またはシンタックスハイライト付きの構造化データ）でデリバリーしてくれます。
５ まとめと今後の展望
１週間かけてプロトタイプの砂場でAIの手癖や仕様の壁と格闘した結果、「判断ロジック（知能）をインフラ（土管）から完全に分離する」 という、比較的シンプルかつ疎結合なシステム構築に落ち着きました。
コスパの観点では、１日１回の起動で４円程度なので、１カ月で約120円のコストをどう考えるか？というところです。
１日10分の節約と考えるなら、１カ月あたり300分（５時間）を120円で買うのがお得かどうか？という判断になります。
セキュリティの観点では、基本的にAIの権限は Read Only に限定して必要最小限にとどめています。
以上