puppyone logopuppyone
ドキュメント価格ブログオープンソース
始める

AIエージェントのガバナンス: なぜビジネスコンテキストとコンテキスト知能が重要なのか

2026年4月14日Lin Ivan

AIエージェント向けコンテキストガバナンスのカバー画像

本番環境でのエージェント障害は、モデルが十分に賢くないから起きるとは限りません。多くは、モデルの周辺システムが間違ったコンテキスト、古いコンテキスト、あるいは境界のないコンテキストを渡してしまうことから始まります。

重要ポイント

  • AIエージェントのガバナンスはモデル選定だけではありません。コンテキスト、権限、実行経路の制御が必要です。
  • ビジネスコンテキストがないと、エージェントはもっともらしく見えても業務的に誤った行動を取ります。
  • コンテキスト知能は、適切なコンテキスト選択、業務ルール下での解釈、行動制御、説明可能性がそろって初めて成立します。
  • 実務では、ビジネス、運用、ポリシーや認可、出所や鮮度の四層に分けると扱いやすくなります。
  • 最初に効くのは、最小権限、信頼ラベル、監査ログ、バージョン管理、Action Gating です。

本当のガバナンス対象はモデルより広い

多くのチームは、いまだに AI Governance を eval、prompt、安全性の話として捉えがちです。しかし agentic system ではそれだけでは足りません。

本当に高くつくリスクは、その周辺にあります。

  • エージェントが古いポリシーを読む
  • 本来見えないデータを見てしまう
  • 承認が必要なツールをそのまま呼んでしまう
  • 最終アクションに至ったコンテキストを再現できない

だからこそ、コンテキスト層と実行層の両方をガバナンス対象にする必要があります。これは NIST AI Risk Management Framework の考え方とも整合します。

ビジネスコンテキストが業務上の誤りを防ぐ

「エージェントに必要なコンテキスト」と言うと、retrieval 結果や chat 履歴、memory を思い浮かべがちです。しかしそれでは狭すぎます。

ビジネスコンテキストには、次が含まれます。

  • 本当に達成したい業務目標
  • どの policy や playbook が適用されるか
  • 何が正しい回答や正しい行動なのか
  • どの例外に承認が必要か
  • レイテンシより重い失敗モードは何か

エージェントにとっての contextual intelligence とは、次をできることです。

  1. 適切なコンテキストを選ぶ
  2. 適切な業務ルールで解釈する
  3. policy と権限で行動を制御する
  4. どの根拠が判断を支えたか説明する

ガバナンス対象としてのコンテキストの分類

コンテキストの種類含まれるものよくある失敗問うべきこと
ビジネスコンテキスト目標、policy、SOP、承認ルールテキストは守るが本当の業務ルールを外すここで妥当な行動は何か
運用コンテキスト環境、アカウント状態、クォータ、障害、ワークフロー状態正しい行動を間違った環境で実行する今なにが真実か
ポリシーや認可コンテキストscope、権限、tool permission、リスク区分技術的には可能でも業務上は禁止の操作をするこのエージェントに何を許すか
出所と鮮度のコンテキストsource、owner、version、timestamp、trust level古い、または低信頼の情報が判断を支配するなぜ今この情報を信じるのか

コンテキストガバナンスを現実のものにする五つの制御

1. コンテキストとツールへの最小権限

  • 必要最小限の collection や record だけに絞る
  • 各ステップで必要な tool だけを見せる
  • 可能なら read-only から始める
  • 危険な tool call は外部 policy 判定を通す

2. 信頼ラベル

すべてのコンテキストを同じように扱うべきではありません。

  • verified
  • internal
  • external
  • unknown

重要なのは、低信頼のコンテキストをそのまま行動根拠にしないことです。

3. 読み取りと行動の両方を監査する

エージェントが何をしたかだけでなく、何を見たかも分からなければ、実用的な audit trail にはなりません。

4. 知識のバージョン管理とロールバック

本番で困るのは「答えがない」ことより、「古い答えや矛盾した答えが残っている」ことです。

5. モデル外の Action Gating

prompt の指示は governance ではありません。データ更新、外部送信、エクスポートのような操作は、モデルの外側にある決定ロジックで最終許可されるべきです。

エージェントが動く前に組織知識をどう検証するか

{
  "source_id": "refund_policy_v17",
  "owner": "finops",
  "trust_level": "verified",
  "approved_at": "2026-04-10T10:20:00Z",
  "expires_at": "2026-07-10T00:00:00Z",
  "audience": ["support-agent", "billing-agent"],
  "risk_class": "high"
}

確認したいのは次の五点です。

  1. provenance
  2. freshness
  3. authorization
  4. consistency
  5. grounding
retrieve context
  -> check provenance
  -> check freshness
  -> check authorization
  -> check for conflicts
  -> allow, block, or escalate

関連する実装論としては AI Pipeline Workflow と Version Control for AI Agent Context が近い記事です。

最小リファレンスアーキテクチャ

  • control plane: policy、承認ルール、identity、compliance
  • context plane: retrieval store、structured bundle、provenance、versioning
  • execution plane: tool invocation、runtime gating、sandboxing、audit hook

puppyone が効く場所

多くの agent deployment は、コンテキストの組み立てで壊れます。policy は一つの system、運用事実は別の system、承認ルールはさらに別の system にあるからです。

governed context layer があると、

  • 知識に provenance と version history を持たせられる
  • MCP 経由で統制された配布ができる
  • 何を読んで何をしたかを audit できる
  • file や role ごとに見える範囲を絞れる

背景として読むなら Ultimate Guide to Agent Context Base: Hybrid Indexing と Context Engineering: When RAG Is Not Enough が最も近いです。

agent governance に即席 retrieval ではなく制御された context が必要なら puppyone を使うGet started

最初にやること

  1. リスクの高い workflow を一つ選ぶ
  2. 本当に必要なコンテキストを洗い出す
  3. 各 source を provenance、freshness、scope でラベル付けする
  4. 最も危険な action の前に gate を置く
  5. context bundle と control decision を記録する

FAQs

Q1: AI Governance と Contextual Governance の違いは何ですか

前者はモデルリスクや統制全体の話で、後者はエージェントがどの情報を、どの条件で使ってよいかに焦点を当てます。

Q2: なぜビジネスコンテキストがそんなに重要なのですか

エージェントは事実を hallucinate するだけでなく、事実の周りにある業務ルールを取り違えて失敗するからです。

Q3: RAG だけで governance になりますか

なりません。retrieval は情報を渡す仕組みであって、その情報が妥当か、最新か、安全に使えるかを判断する仕組みではありません。

関連記事