【ニュース】LovableがAIUC-1を共同発表｜AIコーディングエージェントの安全基準とは

3行まとめ#

• LovableはAIUC（AI Underwriting）と共同で、AIコーディングエージェント向けの新しい安全基準『AIUC-1』に関するホワイトペーパーを公開しました。
• AIUC-1は『セキュリティ／安全／信頼性／説明責任／社会／データとプライバシー』の6原則・51要件・最大5段階のコントロールで構成され、第三者監査による検証が必須です。
• Lovableはコーディングエージェント分野で世界初のAIUC-1認証取得を目指し、2026年夏にSchellman社による監査を予定しています。

なぜ『コーディングエージェント専用』の基準が必要なのか#

従来のAIチャットボットは『人間が読むテキスト』を生成しますが、Lovableのようなコーディングエージェントは『動くソフトウェア』を生成します。生成されたコード・DBスキーマ・APIキー設定・デプロイ済みアプリは、本番インフラ・実ユーザーデータ・システム設定に直接作用します。コードの脆弱性は仮説ではなく、即座に本番の攻撃面になるのです。

ホワイトペーパーが提示する3つのリスク次元

1. 出力面が『実行可能』である：チャットボットなら誤情報は不便で済むが、コーディングエージェントが『幻覚した認証パターン』を生成すれば本番に脆弱性が出荷される。
2. 入力面が『広大かつ非信頼』である：ドキュメント、MCPサーバーのツール説明、依存関係のメタデータなどから文脈を取り込む。2026年4月の『Comment and Control』攻撃では、コードコメントやPR説明文に隠したプロンプトインジェクションでClaude Code・Gemini CLI・GitHub CopilotがAPIキーを漏洩した。
3. アクション面が『広範かつ永続』である：本番クレデンシャルやインフラ設定に対して特権操作を行うため、プロンプトインジェクション一発でデプロイスクリプトの改ざんやバックドア挿入につながり得る。

規模感を示す3つの数字#

• 約20%：USENIX Securityの研究（57.6万サンプル）で、AIが推奨したパッケージのうちnpm/PyPIに『そもそも存在しない』ものの割合。攻撃者の格好の標的（slopsquatting）。
• 36%：Snykが監査した3,984個のエージェントスキルでプロンプトインジェクションが検出された割合。うち76件は実際に悪意あるペイロードを含んでいた。
• 90+：CrowdStrikeの2026年脅威レポートで、プロンプトインジェクション攻撃の標的になった組織数。

AIUC-1フレームワーク：6原則#

AIUC-1はもともとモダリティ非依存のフレームワークとして6原則で設計され、Lovableを含む大手プラットフォームのセキュリティチームと共に、コーディングエージェント特有の75リスク（13カテゴリ）に拡張されました。

• セキュリティ（Security）
• 安全性（Safety）
• 信頼性（Reliability）
• 説明責任（Accountability）
• 社会（Society）
• データとプライバシー（Data & Privacy）

コーディングエージェント向け7つの優先リスク領域#

01. シークレット管理

コーディングエージェントはコードベース全体を文脈として読み込むため、APIキーやDB接続文字列、OAuthトークンが意図せず流出する経路が4つあります（生成コード／会話ログ／推論トラフィック／プラットフォーム計測）。入力側・出力側の両方での検知、テナント分離、ユーザーへの事前警告、ログとアーティファクトのレダクションが要件です。

02. セキュアな生成デフォルト

『セキュリティに詳しくない初回ユーザーが何も指定せずWebアプリを作ったとき、生成コードのデフォルト姿勢はどうあるべきか？』が設計原則です。パラメタライズドクエリ、出力エスケープ、HTTPS強制、Auth0/Clerkなど確立された認証ライブラリ、ワイルドカード版の依存禁止、Cookieに HttpOnly/Secure/SameSite、CSRF・レート制限・入力検証・PIIをログに出さない——これらをユーザー指定ではなくシステムプロンプトと足場コードで標準化します。

03. ランタイム実行とサンドボックス整合性

シェル実行・ファイル書き込み・パッケージインストール・DB操作はサンドボックス内で行い、ファイルシステム／ネットワーク／クレデンシャルの境界を設定可能にします。プロジェクト設定（フック、ツール定義、MCPサーバー設定）の有効化前にユーザー／組織の承認を必須化し、CI/CD等で無人稼働するセッションにはタイムアウトとハートビート監視を義務化します。

04. 依存関係とサプライチェーン整合性

05. エージェントの自律性と人間の監督

破壊的・不可逆な操作の前には完全な変更サマリと、ルーチン操作と視覚的に区別された確認UIを必須化。デフォルトは制限的権限とし、特権は明示的オプトインで付与。永続メモリはユーザーが閲覧／編集／削除可能にして、セッションをまたぐプロンプトインジェクションを断ち切ります。

06. データ機密性とIP保護

テナント分離はクレデンシャル保管・実行環境・生成成果物まで拡張。制限ライセンスの学習データに一致するコードを検出するライセンス汚染フィルタ、入出力でのクレデンシャル検知が含まれます。

07. エンタープライズガバナンスと透明性

管理者によるポリシー強制（権限ポスチャ、MCP許可リスト、必須安全設定）、IaaS/PaaSに類比した責任共有モデルの文書化、ツール呼び出し／サブエージェント委譲／承認イベント／推論トレースを保全するエージェント実行チェーンログが必要です。

監査の中身：51要件と4つのエビデンス#

AIUC-1は51要件・各1〜5のコントロールで構成され、要件ごとに『何を』『誰に』提示するかが定義されています（Core＝認証必須／Supplemental＝推奨）。

• ポリシーエビデンス：利用規約、プライバシーポリシー、DPA、許容利用ポリシーなど。『顧客データで学習しない』などのコミットメントを文書化。
• 技術エビデンス：システムプロンプト、フィルタ実装、IAM設定、サンドボックスポリシー、クレデンシャル検知コード、ロギング——監査人がスライドではなくコードを読む層。
• オペレーショナルエビデンス：変更管理、インシデント対応、四半期内部レビュー、ベンダーDD等の運用プロセス。
• 第三者レッドチーミング：四半期に1度以上、敵対的ロバスト性／有害出力／幻覚／ツール呼び出し安全性で実施。自己認証を許さない層。

Lovableの対応状況（2026年夏に第三者監査）#

Lovableは1年以上、自然言語だけで構築された本番アプリを大規模にホスティング・運用・統制してきた経験を持ち、その知見を基に以下を実装または開発中です。第三者検証はSchellman社により2026年夏に実施予定です。

• セキュアな生成：パラメタライズドクエリ、出力エスケープ、確立された認証ライブラリ、版固定済み依存をシステムガイダンスで誘導。生成成果物に脆弱性スキャナを実行。
• データプライバシーと所有権：顧客のコードやプロンプトをモデル学習に使用しない方針をToS/DPAで明記。テナント単位の論理分離とテナントスコープ暗号化で連携サービス資格情報を保護。
• シークレット保護：入力／出力の両側で検知。ユーザー入力にシークレットを検出した場合は警告し、保存物やログへの永続化を防止。
• サンドボックスと実行セキュリティ：FS／ネットワーク／クレデンシャル境界を定義した環境内で実行。プレビューと本番を分離し、エージェントは承認済みバックエンドとMCPサーバーのみアクセス可。
• 人間の監督と介入：エージェントの動作をリアルタイムで可視化。一時停止・停止・方向転換が可能。破壊的操作には変更サマリとユーザー確認を必須化。
• エンタープライズガバナンス：チーム横断のセキュリティポリシー／ユーザー権限／エージェント能力を管理者が中央集権的に制御。プラットフォームと利用者の責任共有モデルを明示。

日本の導入担当者がいま確認すべき問い#

• 評価チェックリストに『AIUC-1のコントロールに沿ったエビデンスを開示できるか』を追加する。
• ベンダー回答に対して『監査レポート』『四半期レッドチーム結果』『責任共有モデル』を要求する。
• 自社のSLA／セキュリティレビュー基準を、テキスト生成AI前提から『コードを生成・実行するエージェント』前提に更新する。
• MCP許可リスト、シークレット検知、サンドボックス、変更承認UIなど、AIUC-1の優先7領域に紐づく社内ルールを整備する。

原典・参考リンク#

• ホワイトペーパー本文・ダウンロード：lovable.dev/blog
• AIUC-1標準：aiuc-1.com
• 監査機関：Schellman
• Lovable公式：lovable.dev