こんにちは！株式会社雲海設計の技術部です。
「AIエージェントが想定外のAPIを叩いて課金が爆発した」「権限のないテーブルに更新が走り、監査で問題になった」「ログが残っておらず、何が起きたか再現できない」——2025年にエージェント実装が一気に広がった結果、2026年に入ってハーネスエンジニアリング ガードレールに関する相談が、月に複数件入ってくるようになりました。本記事では、AIエージェントを業務投入する前提で、ハーネスエンジニアリング ガードレールの設計パターンを、権限制御・実行境界・監査ログという3つの軸で実装レベルに落として整理します。
TL;DR
ガードレールは「権限制御・実行境界・監査ログ」の3層で設計する。1層でも欠けると本番で必ず事故る
権限はLLMに判断させない。ハーネス側で事前に「使えるツール」を絞り込むのが鉄則
実行境界はタイムアウト・反復回数・コスト上限・副作用範囲の4軸で必ず設定する
監査ログはプロンプト全文・ツール呼び出し・観測結果・最終判断の4点セット。1つでも欠けると再現不能
2026年時点で破壊的操作はHuman-in-the-Loopが必須。これはコスト判断ではなく安全要件
なぜ2026年にガードレール設計が業務投入の生命線なのか？
結論から言うと、2025年に作られた多くのAIエージェントが、ハーネス側のガードレールを軽視してプロンプトと指示文だけで制御しようとした結果、本番投入後の事故率が想定の数倍に達しているからです。Gartnerが2025年末に出した調査では、エージェント案件の約6割が「想定外の挙動」を理由に再設計や運用停止を経験しています。
現場で起きている典型的な事故パターン
ツール暴発型：エージェントが想定外のAPIを連打し、外部サービスのコストやレートリミットを直撃
権限逸脱型：DB書き込み権限を持つツールがプロンプトインジェクション経由で誤発火
無限ループ型：自己反省ループに入り、トークン消費とAPI課金が止まらない
再現不能型：障害が起きても、どのプロンプトでどのツールを呼んだか記録がなく原因究明できない
これらは「LLMがもっと賢くなれば解決する」ものではありません。ハーネス層 (=エージェントを実行する周辺コード) で構造的に防がない限り、永久に同じ事故が繰り返されます。ハーネスエンジニアリングの全体像についてはハーネスエンジニアリングとは？LLM時代に必須の新常識を解説でも整理していますので、合わせてご覧ください。
ガードレールの3層構造とは？
結論から言うと、業務投入に耐えるガードレールは「権限制御・実行境界・監査ログ」の3層を必ずセットで実装する必要があります。1層でも抜けると、運用フェーズで必ず破綻します。
3層の役割と責任分担
| 層 | 役割 | 守る対象 | 主な実装 |
|---|---|---|---|
| 権限制御 | 「何が呼べるか」を絞る | 権限逸脱・破壊操作 | RBAC・ツール許可リスト |
| 実行境界 | 「どこまで動けるか」を縛る | 暴走・コスト爆発 | タイムアウト・反復上限 |
| 監査ログ | 「何が起きたか」を残す | 再現不能・説明責任 | 構造化ログ・トレース |
OWASP「Top 10 for LLM Applications 2025」でも、エージェントの「過剰な権限 (Excessive Agency)」と「不十分な監視」が並んで上位脅威に挙げられています。これらはプロンプトでは解決できず、ハーネス層での構造的対処が必須です。
第1層: 権限制御はどう設計するか？
結論、権限はLLMに判断させない。ハーネスがエージェント起動時に「使えるツールセット」を確定させ、LLMはその中からしか選べない構造にします。
ツール権限の3段階分離
読み取り (Read): 検索・取得・閲覧。副作用なし。比較的自由に許可してよい
副作用あり (Write): メール送信・チケット作成・レコード追加。ユーザー単位の権限スコープで縛る
破壊的 (Destructive): DELETE・本番デプロイ・送金。必ずHuman-in-the-Loopで承認を挟む
実装パターン: ツール許可リストの動的注入
def build_agent(user, task_type):
# ユーザーロールとタスク種別から許可ツールを確定
allowed_tools = resolve_tools(user.role, task_type)
# 破壊系は別フラグで明示的に管理
if needs_destructive(task_type):
allowed_tools = wrap_with_hitl(allowed_tools)
return Agent(
tools=allowed_tools, # LLMが見えるのはこれだけ
system_prompt=SYSTEM_PROMPT,
max_iterations=10,
timeout_sec=60,
)
ポイントは「LLMに権限判定をさせない」こと。プロンプトで「人事情報は触らないでください」と書いても、プロンプトインジェクションで簡単に突破されます。詳しくはAIセキュリティ対策実装ガイド2026もご参照ください。
第2層: 実行境界はどう縛るか？
結論、実行境界はタイムアウト・反復回数・コスト上限・副作用範囲の4軸で必ず設定する。デフォルト値に頼ると、深夜のエッジケースで青ざめることになります。
4軸の境界設定例
| 境界軸 | 推奨初期値 | 越えた時の挙動 |
|---|---|---|
| タイムアウト | 60〜120秒 | 強制中断・状態保存 |
| 反復回数 | 10〜15回 | 中断し人間にエスカレーション |
| トークン/コスト上限 | 1セッション $0.5〜$2 | 中断・要承認モードへ |
| 副作用範囲 | 環境変数で隔離 | 本番影響をブロック |
サーキットブレーカーの導入
1セッション単位だけでなく、システム全体のサーキットブレーカーも入れます。例えば「同一ツールが直近1分で50回以上呼ばれたら全エージェント停止」のような閾値です。これがないと、設定ミスで API 課金が一晩で数十万円に膨らむケースがあります。生成AIの請求が読めない会社へでもコスト管理の実務観点を整理しています。
class CircuitBreaker:
def check(self, tool_name: str):
count = self.redis.incr(f"tool:{tool_name}:1m")
self.redis.expire(f"tool:{tool_name}:1m", 60)
if count > THRESHOLD[tool_name]:
raise CircuitOpen(f"{tool_name} exceeded rate limit")
第3層: 監査ログは何を残すべきか？
結論、監査ログは「プロンプト全文・ツール呼び出し・観測結果・最終判断」の4点セットを、1セッションを通して構造化トレースで保存します。1つでも抜けると、事故時に再現できません。
必須ログ項目
セッションメタ: session_id、user_id、開始/終了時刻、使用モデル、バージョン
プロンプト履歴: system / user / assistant / tool の全メッセージ (PII マスキング済み)
ツール呼び出し: ツール名・引数・実行時間・成功/失敗・コスト
観測結果: ツール戻り値 (大きい場合はハッシュ + S3 等への参照)
最終判断: 出力テキスト・ユーザーへの提示内容・HITL承認の有無
OpenTelemetry ベースのトレース構造
graph TD
A[Session: agent.run] --> B[Span: llm.invoke #1]
A --> C[Span: tool.search_db]
A --> D[Span: llm.invoke #2]
A --> E[Span: tool.send_email - HITL]
E --> F[Span: human.approve]
A --> G[Span: llm.final]
2026年時点では、LangSmith・Langfuse・Arize などのマネージドサービスが OpenTelemetry 互換のトレースを標準化しつつあります。自前で全部作るより、標準準拠のSaaSに乗せて法務・監査要件に応えられる形にするのが現実解です。
業務投入前のチェックリスト
結論、本番リリース前に最低この10項目をチェックすると、初期事故率は体感で半減します。
ツール許可リストはユーザーロール別に定義済みか
破壊的操作は HITL 必須になっているか
タイムアウト・反復回数・コスト上限が個別設定されているか
サーキットブレーカーが全ツールに入っているか
プロンプト全文と引数がログに残っているか
PII マスキングが入っているか (個人情報保護法対応)
セッション ID で全ログを横串で追えるか
異常検知アラートが SRE / セキュリティチームに飛ぶか
ロールバック手順が文書化されているか
敵対的プロンプトの評価セットを30件以上で回したか
これらは要件定義段階で決め切るべき項目です。後付けは確実に揉めます。要件定義の進め方は要件定義チェックリスト20問もどうぞ。
雲海設計の支援アプローチ
当社では、AIエージェントを業務投入する案件で「ハーネス層の設計レビュー → ガードレール実装 → 監査ログ基盤構築 → 評価セット整備」までを伴走支援しています。特に2025年以降、PoCで動いたエージェントを本番化する局面で「ガードレールが入っていなくて止まる」ケースが増えており、評価ハーネスとセットでの提供がご好評をいただいています。
具体的な支援メニューはDXソリューションとITコンサルティングのページに整理してあります。「自社のエージェントが本番運用に耐えるか不安」という段階のご相談も歓迎です。お問い合わせからお気軽にご連絡ください。
よくある質問
Q. プロンプトでガードレールを書けば十分ではないですか？
A. 不十分です。プロンプトインジェクションや指示無視で簡単に破られるため、ハーネス層で物理的に「呼べない・実行できない」構造を作る必要があります。プロンプトはあくまで補助線です。
Q. Human-in-the-Loopを入れると業務効率が落ちませんか？
A. 短期的には落ちますが、破壊的操作の事故1件で失う信頼とリカバリコストの方が圧倒的に大きいです。読み取り・低リスク操作は自動化、破壊系のみHITLという切り分けが現実解です。
Q. 監査ログはどこまで残すべきですか？保管コストが心配です。
A. プロンプト全文・ツール呼び出し・最終出力は最低1年、業界規制があれば3〜7年が目安です。大容量の観測結果はハッシュ化してオブジェクトストレージに退避すれば、コストは想定の1/5以下に抑えられます。
Q. 既存のエージェントに後付けでガードレールを入れられますか？
A. 可能ですが、ツール定義とログ出力の刷新が必要なため、リファクタリング規模になります。当社の支援案件でも、後付けは新規構築の1.5〜2倍の工数がかかる傾向です。可能なら設計初期から組み込むことを推奨します。
Q. 評価ハーネスとガードレールの違いは何ですか？
A. 評価ハーネスは「品質を測る」仕組み、ガードレールは「事故を防ぐ」仕組みです。両者は補完関係にあり、片方だけでは業務投入できません。詳しくはハーネスエンジニアリング ベストプラクティスもご参照ください。