AIが踏み越えてはいけない線をどう書くか｜境界設計の5分類【AI活用検証vol.123】

AIエージェントは指示が曖昧だと暴走しがちで、しかも「動くコード」を作るために最短経路を取ろうとする傾向があります。

そのためコードベース側で「ここから先は絶対に踏み越えるな」という境界を明示する記述が、急速に発達しています。この調査では6つのOSSを題材に、その表現方法を5つに分類しました。

本記事はOSS横断調査シリーズの深掘り記事です。全体像は「AGENTS.md / CLAUDE.md 実装事例 横断調査」をご覧ください。

この調査の概要

結論：「絶対に〜しない」という否定形が効く

調査全体を通じて見えた表現上の要点です。

「絶対に〜しない」という否定形での宣言が効果的で、肯定形（「〜する」）よりも境界として機能します。

もう1つ重要な点があります。

アーキテクチャ境界はコードを読むだけでは見えません。「あえて書かない」という設計判断は、コード上に痕跡が残らないためです。だからこそ、AI向け設定ファイルで明示する意義が大きくなります。

分類A：アーキテクチャ境界

「このコンポーネントはこの責任を絶対に持たない」という設計上の不変条件を伝えます。

あるワークフロー基盤のAGENTS.mdには、次の記述があります。

Scheduler は絶対にユーザーコードを実行しない。

これはセキュリティモデルそのものです。SchedulerがDAGファイルから任意コードを実行すると、Workerとの権限境界が壊れます。

別のフレームワークでは、Dead Code Eliminationの境界やエッジランタイムとNodeランタイムの境界、特定の環境変数を使ったときの落とし穴が明示されています。

AIは「動かすために」境界を踏み越えがちです。明示しておかないとリスクになります。

分類B：エディション境界

オープンコア型のビジネスモデルでは、Community EditionとEnterprise Editionでコードが分離されます。

CEコードに src/app/ee/ を絶対 import しない

ここが重要な指摘です。エディション境界はビジネス上の理由（ライセンス・課金）で存在するため、技術的には自由に行き来できてしまいます。

AI視点では「使えるなら使う」になりがちで、明示的な禁止指示が必要です。技術的な制約がないものは、書かなければ守られません。

理想的には、違反検出のためのLintルールやCIチェックも併設します。

分類C：入出力境界（SSRF・インジェクション対策）

脆弱性に直結する領域です。

標準ライブラリを使わせない

あるプロジェクトでは、サーバーパッケージからの外部HTTPに標準のHTTPクライアントではなく独自ラッパーを使うよう指示しています。

このラッパーはプライベートIP（10.x.x.x、169.254.x.x、127.x.x.x 等）へのリクエストをブロックするSSRF対策を含みます。

マルチテナントのスコープ強制

ORM操作では必ず tenant_id でクエリをスコープする / 生SQLの使用禁止

マルチテナントSaaSで、AIが「便利だから」と他テナントのデータに横断クエリを書いてしまうリスクへの対策です。

要点

AIは標準APIを使いがちです。「標準より独自ラッパーを使え」という指示は明示的に書く必要があります。

そして規約の遵守はCIレベルで強制するのが望ましい領域です。ドキュメントに書くだけでは守られません。

分類D：自律性境界（ガバナンス）

AIエージェントの自律的な行動範囲を制限し、「人間の介在を必須とする操作」を明文化します。

完全自律の禁止

あるプロジェクトは、技術仕様とは独立したガバナンスポリシーファイルを設置しています。

ポリシーは、人間の関与なしに「完全自律エージェント」がIssue・プルリクエスト・コントリビューションを作成することを明示的に禁止している

興味深いのは、あわせてAI発のコントリビューションを識別するシグナル（特定のマーカーを含むIssue/PRは優先処理される）も用意している点です。禁止するだけでなく、識別できるようにしています。

出力への署名義務

別のプロジェクトでは、エージェントが作成したメッセージにDrafted-by: <Agent Name and Version> フッターを義務化し、人間レビューの有無も明記させています。

物理的にブロックする

最も強い対策です。フックで検証スキップのコマンドをシステムレベルでブロックし、AIが「テストが通らないなら飛ばす」を物理的にできなくしています。

要点

• 自律性境界は規約レベルだけでなく、フック・CI・ファイル分離など多層で実装されている
• AI出力をリポジトリ上で識別可能にすることで、人間レビュアーが確認の濃度を変えられる
• 技術仕様とガバナンスのファイル分離は、更新責任が異なることを反映した設計——前者は開発者、後者はメンテナや法務

分類E：コミュニケーション境界

見落とされやすい観点です。

OSSではIssue・PR・コミットメッセージが公開されます。セキュリティ修正で攻撃ベクターを露出すると、修正前のバージョンを使っているユーザーが攻撃されます。

そのため、あるプロジェクトではブランチ名・コミットメッセージ・テスト記述・コードコメントのすべてについて「攻撃ベクターを一切露出しない」ルールを設けています。

テストコメントについても、攻撃の再現方法を直接書かないとしています。

AIは「分かりやすい名前を付ける」ことを良いことだと判断します。セキュリティ修正の文脈では、それが逆効果になることを明示する必要があります。

自社に適用するときの順序

5分類のうち、どこから手を付けるべきか整理すると次のようになります。

1. 入出力境界——脆弱性に直結するため最優先。CIでの強制もセットで
2. 自律性境界——AIの出力が人の確認なしに反映される経路を塞ぐ
3. アーキテクチャ境界——コードを読んでも分からない不変条件を明示
4. エディション境界——該当するビジネスモデルの場合
5. コミュニケーション境界——公開リポジトリの場合

よくある質問

なぜ境界を明示する必要があるのですか？

AIは「動くコード」を作るために最短経路を取ろうとするためです。特にアーキテクチャ上の不変条件は、コードを読むだけでは見えません。「あえて書かない」という設計判断には痕跡が残らないためです。

効果的な書き方はありますか？

「絶対に〜しない」という否定形が、肯定形よりも境界として機能します。

ドキュメントに書けば守られますか？

不十分です。特に入出力境界のような脆弱性に直結する領域は、LintルールやCIチェック、フックによる物理的なブロックまで併用するのが望ましい実装です。

技術仕様とガバナンスは同じファイルでよいですか？

分離する例が観測されています。更新責任が異なる（技術仕様は開発者、ガバナンスはメンテナや法務）ことを反映した設計です。

まとめ

• 境界の表現はアーキテクチャ／エディション／入出力／自律性／コミュニケーションの5分類に整理できる
• 「絶対に〜しない」という否定形が境界として機能する
• アーキテクチャ境界はコードを読んでも見えない。だから明示する意義がある
• 技術的に自由に行き来できるものほど、明示的な禁止が必要（エディション境界）
• AIは標準APIを使いがち。独自ラッパーの強制は書かないと守られない
• 自律性境界は規約・フック・CI・ファイル分離の多層で実装される
• AI出力を識別可能にすると、人間レビューの濃度を変えられる
• セキュリティ修正では「分かりやすい名前」が逆効果になることを明示する

AIに任せる範囲が広がるほど、任せてはいけない範囲の定義が重要になります。書いていない制約は、守られないものとして扱う必要があります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。