AIエージェントのガバナンスv1.5｜開発者が押さえる5つの要件

2026年5月20日、シンガポールIMDAがModel AI Governance Framework for Agentic AI v1.5を公開した。AIエージェント ガバナンスに特化した世界初のフレームワーク、その改訂版だ。60社超のフィードバックが反映されている。

AIエージェントが自律的にツールを呼び出し、複数ステップを実行する。「暴走したら誰が止めるのか」——この問いが設計段階の必須要件に変わった。従来のAIガバナンスは推論モデル単体を想定していた。エージェントは違う。外部APIを叩き、ファイルを生成し、別のエージェントにタスクを委譲する。制御の粒度が根本的に変わる。

エージェントAI ガバナンス フレームワークは5つの次元で構成される。監督、追跡性、信頼性、対話、エコシステム。設計段階でこの5次元を押さえておかないと、後からアーキテクチャを全面改修する羽目になる。AIガバナンス 2026年の最新動向から日本企業への影響、実装コードまでを一気に網羅する。

AIエージェント ガバナンスv1.5とは何か

IMDAは2026年1月にAIエージェント ガバナンスの初版（v1.0）を公開し、エージェントAI固有のリスクに対応する世界初の指針として注目を集めた。v1.5はその改訂版で、実運用から得られた知見を反映している。

v1.0からの主な変更点

v1.5の核心は、原則論から実装可能なプラクティスへの転換だ。Ant International、Google、PwC、Tencent、Workdayなど13社の実導入ケーススタディが追加された。AIエージェント ガバナンスの「べき論」から「やり方」への移行と言える。

なぜ今ガバナンスが必要なのか

Gartnerの予測では、2026年末までにビジネスアプリの40%がAIエージェントを搭載する。業務プロセスにエージェントが深く入り込むほど、制御不能時の損害は大きくなる。

数字で見ると深刻さがわかる。2026年初頭、MCP SDKのstdioトランスポートに体系的なRCE脆弱性が見つかった。影響範囲は推定1.5億ダウンロード超。AnthropicのProject GlasswingではClaude Mythosが数千件のゼロデイ脆弱性を掘り当てている。エージェントの能力が跳ね上がる一方で、AIエージェント ガバナンスの整備は追いついていない。

5つのガバナンス次元を読み解く

AIガバナンス 2026年の最重要フレームワーク。核心は5つの次元だ。実装負荷が最も高いのはTraceability（追跡性）——順に見ていく。

Oversight（監督）——人間の制御権をどう設計するか

HITLとHOOTLの使い分けは、工場の品質検査ラインに近い。全製品を人間が目視するか、統計的抜き取りで済ませるか——リスクと速度のトレードオフで決まる。フレームワークはHuman-in-the-Loop（HITL）、Human-on-the-Loop（HOTL）、Human-out-of-the-Loop（HOOTL）の3段階を定め、リスクレベルに応じた使い分けを開発者に課している。

金融取引の最終承認はHITL（人間が毎回承認）。ログ集計のような低リスク作業はHOOTL（完全自動）。問題はその境界線だ。フレームワークはこの判断を「デプロイする組織の責任」と明記している。逃げ道はない。

Traceability（追跡性）——事後検証を可能にするログ設計

エージェントのログは、飛行機のフライトレコーダーに相当する。事故が起きてからでないと参照しないが、ない状態で事故が起きると原因調査が不可能になる。ツール呼び出し、外部APIリクエスト、ファイル生成——全行程を再現可能な形で記録する。

必要な記録は4要素。各ステップの入出力、使用したツール名、判断の根拠（LLMの推論テキスト）、タイムスタンプだ。Claude Agent SDKやOpenAI Agents SDKには、こうしたトレースの自動出力が組み込まれつつある。

Reliability（信頼性）——ガードレールの3層構造

信頼性の確保はガードレールの設計に帰着する。フレームワークは3層のアプローチを推奨している。

実務で見落としがちなのがLayer 2の再帰制御だ。マルチエージェント構成ではエージェントAがエージェントBを呼び出し、BがさらにAを呼び出す無限ループが発生しうる。深度制限とタイムアウトの設定は必須になる。

Interaction（対話）——透明性の設計

エージェントがユーザーと対話する際、「自分がAIエージェントである」ことを明示する。当然のように聞こえるが、エージェントが別のサービスを経由してメールを送信するケースでは、受信者がAI生成であることに気づかない可能性がある。

フレームワークはこの透明性要件を、エージェントの行動範囲の事前開示、処理中の状態表示、結果の根拠表示の3レイヤーで定義している。UX設計に直結する要件だ。

Ecosystem（エコシステム）——責任の連鎖を切らない

MCPサーバーを介して外部ツールを呼び出すエージェント。A2Aプロトコルで別のエージェントにタスクを委譲するエージェント。こうしたマルチエージェント環境では、「どのエージェントの判断がエラーを引き起こしたか」の特定が困難になる。

フレームワークはエコシステム全体での責任トレースを要求している。具体的には、エージェント間通信にトランザクションIDを付与し、各エージェントの入出力を一元的に記録する仕組みだ。AWS MCPサーバーのようなマネージドサービスでは、こうしたトレース機能がプラットフォーム側で提供される方向に動いている。

開発者に求められる実装要件

AIエージェント ガバナンスの5次元を実装レベルに落とし込む。開発者が対応すべき要件は大きく4つだ。

ロギングと監査証跡の設計

追跡性の次元が求めるのは、エージェントの全行動を後から再現できる監査ログだ。最低限必要な記録項目を整理する。

このデータ量は想像以上に大きい。1回のエージェント実行で数十のツール呼び出しが発生するケースでは、ログだけで数MBに達する。ストレージコストと保持期間の設計も含めて検討すべきだ。

Human-in-the-Loopの設計パターン

監督の次元で最も実装が難しいのが、「どこに人間の承認ポイントを置くか」の設計だ。承認ポイントが多すぎるとエージェントの自律性が損なわれ、少なすぎるとリスクが放置される。

実務で機能するパターンは3つ。

• 閾値ベース: 金額・件数・影響範囲が閾値を超えた場合のみ承認を要求する。例: 100万円以上の発注は人間承認
• 初回承認+学習: 同一パターンの初回は人間承認、2回目以降は自動実行。例: 新規取引先への初回メール送信
• 時限バッチ: エージェントの行動を一定時間分まとめて人間がレビューする。例: 1時間分のログを要約してSlackに通知

エージェント認証とアクセス制御

エコシステムの次元は、エージェント同士の認証を暗黙に要求している。エージェントAがエージェントBにタスクを委譲する際、Bは「Aが正当なリクエスト元であること」を検証しなければならない。

AIエージェントの認証技術はKnow Your Agent（KYA）やOIDC-Aといったプロトコルが登場している段階で、まだ標準化が進んでいない。フレームワークはこの領域を「今後の重要課題」と位置づけ、最低限のOAuth 2.0ベースの認証を推奨している。

出力のフィルタリングと検証

信頼性の次元で求められるのは出力制御だ。エージェントが生成したテキスト・コード・データに対して、公開前のフィルタリングを行う。PII（個人識別情報）の検出と除去はほぼ必須で、金融・医療分野では業界固有の規制用語チェックも必要になる。

筆者がエージェント開発プロジェクトで検証した範囲では、出力フィルタリングの追加によるレイテンシ増加は平均200-400ms程度。ユーザー体験への影響は許容範囲だが、リアルタイム性が求められるチャットボットでは設計上の工夫がいる。

日本企業への影響と対応策

「シンガポールのフレームワークが日本企業にどう関係するのか」——この疑問は当然だ。直接的な法的拘束力はない。だが影響は確実にある。

日本のAIガバナンス動向との関連

日本では経済産業省が「AI事業者ガイドライン」を公開しており、金融庁もAI利用に関する監督指針を検討している。これらの国内ガイドラインはIMDAフレームワークと多くの共通点を持つ。特に「人間による監督」と「透明性の確保」は日本のガイドラインでも中核要件だ。

グローバルに事業を展開する日本企業、あるいはシンガポール法人を持つ企業にとって、IMDAフレームワークへの準拠は実質的な要件になりうる。たとえばシンガポール金融管理局（MAS）の規制下にある金融サービスでは、このフレームワークが監査基準の一部として参照される可能性が高い。

企業が今すぐ始められる3つのアクション

エージェント開発フレームワークとの関係

AIエージェント ガバナンスの要件を満たすには、開発フレームワーク自体がガバナンス機能を備えているかが鍵になる。2026年の主要フレームワークの対応状況を比較した。

主要フレームワークのガバナンス対応状況

エージェント開発フレームワークの比較は別記事で詳しく扱っているが、ガバナンス観点で選ぶなら、トレース機能とHITL対応が組み込まれているフレームワークを選ぶべきだ。自前でゼロから実装するのは現実的ではない。

MCPプロトコルとガバナンスの接点

MCPサーバーはエージェントに外部ツールへのアクセスを提供する。AIエージェント ガバナンスの観点では、「どのMCPサーバーのどのツールを呼び出せるか」のアクセス制御が鍵になる。

2026年5月時点で公開レジストリに登録されたMCPサーバーは14,000以上。OX Securityが指摘したRCE脆弱性のように、サードパーティ製MCPサーバーのセキュリティリスクは見過ごせない。フレームワークのEcosystem次元は、こうしたサプライチェーンリスクへの対応を暗に求めている。

ガバナンス対応のコード実装例

Python + Claude Agent SDKの構成なら、追跡性の要件は20行で最低限カバーできる。

構造化ログの実装

追跡性の要件を満たすログ出力の基本パターン。

import json
import uuid
from datetime import datetime, timezone

class AgentAuditLogger:
    def __init__(self, agent_id: str):
        self.agent_id = agent_id
        self.transaction_id = str(uuid.uuid4())

    def log_step(self, step_type: str, input_data: dict,
                 output_data: dict, tool_name: str = None):
        record = {
            "transaction_id": self.transaction_id,
            "agent_id": self.agent_id,
            "timestamp": datetime.now(timezone.utc).isoformat(),
            "step_type": step_type,
            "tool_name": tool_name,
            "input": input_data,
            "output": output_data,
        }
        # 構造化ログとして出力（実運用ではS3やBigQueryに送る）
        print(json.dumps(record, ensure_ascii=False))

# 使用例
logger = AgentAuditLogger(agent_id="finance-agent-01")
logger.log_step(
    step_type="tool_call",
    tool_name="get_stock_price",
    input_data={"symbol": "7203.T"},
    output_data={"price": 2850, "currency": "JPY"}
)

閾値ベースのHITL承認ゲート

金額が閾値を超えた場合に人間の承認を要求する実装例。

import asyncio

APPROVAL_THRESHOLD_JPY = 1_000_000  # 100万円

async def execute_with_approval(action: dict, logger):
    amount = action.get("amount", 0)

    if amount >= APPROVAL_THRESHOLD_JPY:
        logger.log_step("approval_required", action, {"status": "pending"})
        # Slack通知 → 人間の承認待ち
        approved = await wait_for_human_approval(action)
        if not approved:
            logger.log_step("approval_denied", action, {"status": "denied"})
            return {"error": "Human denied the action"}

    result = await perform_action(action)
    logger.log_step("action_executed", action, result)
    return result

MCPツール呼び出しのアクセス制御

エージェントが呼び出せるMCPツールを許可リストで制限する。

# エージェントのツール許可リスト定義
TOOL_ALLOWLIST = {
    "finance-agent-01": [
        "get_stock_price",
        "get_exchange_rate",
        "search_financial_news",
    ],
    "support-agent-02": [
        "search_knowledge_base",
        "create_ticket",
        # "delete_user" は意図的に除外
    ],
}

def validate_tool_call(agent_id: str, tool_name: str) -> bool:
    allowed = TOOL_ALLOWLIST.get(agent_id, [])
    if tool_name not in allowed:
        raise PermissionError(
            f"Agent {agent_id} is not allowed to call {tool_name}"
        )
    return True

主要AIガバナンス指針の比較

IMDAフレームワークは世界で唯一のAIガバナンス指針ではない。各国・地域の主要な指針を比較し、共通点と差異を整理する。

IMDAフレームワークが他と異なるのは、「エージェントAI」に特化している点だ。EU AI ActやNIST AI RMFはAI全般をカバーする汎用的な枠組みであり、エージェント固有の課題——自律的なツール呼び出し、マルチエージェント間の責任分界、再帰的な判断ループ——への具体的な対処法までは踏み込んでいない。

自分ならIMDAから始める。EU AI ActとNIST RMFは後から差分だけ確認すれば十分だ。理由は単純で、エージェント特化の実装指針として具体性が最も高いのがIMDAだからだ。ただしこの優先順位は、次のv2.0で変わる可能性がある。

AIエージェント ガバナンスの今後

フレームワークは「リビングドキュメント」と明記されており、継続的な更新が予定されている。今後の展開として注目すべき3つの方向性がある。

エージェント認証の標準化

現在のフレームワークはOAuth 2.0ベースの認証を推奨しているが、エージェント間のピアツーピア認証については「今後の課題」にとどまっている。KYAやOIDC-Aといったプロトコルが成熟すれば、v2.0でエージェント認証の具体的な技術要件が追加される可能性が高い。

マルチエージェントの責任分界

A2Aプロトコルの普及で、異なる組織のエージェント同士が連携するケースが増える。エージェントAの判断ミスがエージェントBのアウトプットを狂わせた場合、責任はどちらにあるのか。法的整理がない。技術的なトレーサビリティだけでは解決しない。実際にエージェント間のタスク委譲でトラブルシュートに丸1日かかった事例もあり、この「責任の連鎖」問題は2026年のAIエージェント ガバナンスにおける最大の未解決領域だ。

自律性のスペクトラム定義

現在のHITL/HOTL/HOOTLの3分類は粗い。エージェントの自律性はもっと細かいスペクトラムとして定義される方向に向かうだろう。自律レベル1（完全監督下）からレベル5（完全自律）のような段階的な定義が、v2.0以降で導入される可能性がある。AIエージェントの基本概念とあわせて押さえておくと、全体像が見えやすい。

よくある質問（FAQ）

まとめ

IMDAのModel AI Governance Framework for Agentic AI v1.5は、AIエージェント開発のガバナンスを5次元（監督・追跡性・信頼性・対話・エコシステム）で整理した実務指針だ。60社以上のフィードバックを反映したv1.5は、原則論から実装可能なプラクティスへと進化している。

開発者にとっての最優先アクションは3つ。構造化ログの設計を開発初期から組み込むこと。高リスク操作にHITL承認ゲートを設置すること。エージェントのツール呼び出しを許可リストで制限すること。この3つを押さえるだけで、フレームワークの主要要件の大半をカバーできる。

AIエージェントの能力は月単位で跳ね上がっている。ガバナンスを後回しにする企業は、必ず痛い目を見る。先にログ設計を入れ、承認ゲートを置き、ツール許可リストを絞る。この順番で動くべきだ。AIエージェントの全体像を把握したうえで、ガバナンスを設計の初日から組み込むのが2026年の標準だ。