#security#cloud#identity#privacy#architecture
BotかHumanかを卒業する：AI時代のIntent中心トラフィック統制設計
AIアシスタントやプライバシープロキシの普及で、通信を「bot/human」で二分する設計は急速に限界を迎えています。重要なのはクライアント種別ではなく、そのリクエストが許可された意図に沿い、追跡可能な責任境界を持つかです。
本稿では、この発想転換を実装に落とすための設計原則を示します。
従来のbot対策が崩れる理由
従来モデルは、ブラウザらしさを正当性の代理指標にしてきました。しかし現実は次の通りです。
- 支援技術のアクセスは自動化的に見えても正当
- ユーザー委任エージェントは非ブラウザ挙動が自然
- 人間による不正でも「人間らしさ」は偽装可能
つまり分類軸そのものが古いのです。
Intent分類を先に定義する
まず業務上の意図で通信を分けます。
- 対話型ユーザー通信（低遅延重視）
- 委任エージェント通信（契約ベース）
- 既知クローラー通信（相互利益前提）
- 未知自動化通信（高リスク扱い）
この分類ごとに、許容レート・検証方式・遮断条件を分離します。
説明責任シグナルを導入する
意図主張は証明が必要です。実装の基本は以下です。
- 署名付きリクエスト
- クライアント証明メタデータ
- 過去の振る舞い評価（reputation）
- エンドポイント単位の能力トークン
匿名性を守りつつ、責任あるアクセスを実現できます。
エンドポイント別に統制強度を変える
全URIに同じbotルールを当てると誤検知が増えます。
- 公開閲覧系：緩やかなレート制御
- 状態変更系：リプレイ耐性と強い検証
- 高感度系：多層シグナルと厳格監査
防御強度は画面単位ではなく、被害半径で決めるべきです。
プライバシーを前提に設計する
強い防御は追跡強化と同義ではありません。
- 有効期限付き匿名クレデンシャル
- 目的限定ログ保持
- 収集データの最小化
- 検証対象と非収集項目の明示
透明性はセキュリティ運用の信頼コストを下げます。
運用で見るべきKPI
- エンドポイント階層別の不正抑止率
- 正当自動化に対する誤遮断率
- 判定遅延（policy decision latency）
- ブロック解除までのMTTR
検知率だけ見て開発者体験が悪化すると、統制は現場で回避されます。
障害対応Runbook
- 影響したIntentクラスを特定
- 安全側フォールバックへ切替
- サンプル再生で再現確認
- シグナル重みを再調整
- 変更内容を外部利用者へ通知
統制は「止める仕組み」ではなく「安全に継続する仕組み」です。
60日移行プラン
- 1〜15日：資産棚卸しとIntent分類
- 16〜30日：署名・能力トークン導入
- 31〜45日：階層ポリシーと可観測性整備
- 46〜60日：負荷試験と誤検知予算調整
最も効くのはツール導入より、判定基準の明文化です。
まとめ
AI時代のWeb防御は「botかどうか」ではなく、「この意図がこの権限でこの操作をしてよいか」を判定する設計に移行すべきです。Intent中心の統制は、防御力と正当連携の両立を現実的にします。
