Model AI Governance Framework for Agentic AI（略称 MGF for Agentic AI）は、バージョン 1.5 のガバナンス文書であり、2026 年 5 月 20 日に公開され、2026 年 6 月 5 日に更新された。文書中では IMDA が、このフレームワークを適用したケーススタディを公開した機関として名前を挙げられており、文書自体は、著者らによる以前のモデルガバナンス・フレームワーク、具体的には MGF（2020）を発展させたものだと述べている。対象はエージェント型 AI の導入を検討している組織であり、その目的は、エージェント型 AI のリスクと、それを管理するための新たなベストプラクティスを体系的に概観できるようにし、組織がより確信をもってエージェント型 AI を採用できるようにすることだとされる。文書の立場は、透明性、説明責任、公平性といった信頼できる AI のための既存の原則は引き続き適用されるが、エージェントに合わせて実践へと落とし込む必要がある、というものである。
フレームワークは、エージェントとは何かを構成要素のレベルで説明することから始まる。単純なエージェントは、推論エンジンとして働くモデル、役割と振る舞いの制約を定める指示、そしてメモリからなると説明される。これに計画と推論、ツール、プロトコルが加わり、さらに統制（アクセス制御、ガードレール、人間による承認）とロギング・監視からなる安全性・信頼性のレイヤーが加わる。そのうえでリスクはこれらの構成要素にさかのぼって整理される。たとえば、ユーザーの意図に反する計画、ハルシネーションで生み出された、あるいは誤って呼び出されたツール、データを持ち出す信頼できない MCP サーバーなどである。その背景にある見解は、リスクそのものはなじみのあるもの（エージェントは従来のソフトウェアの脆弱性と、プロンプトインジェクションのような LLM 特有の脆弱性を引き継ぐ）だが、新しい各部分を通じて異なる形で現れる、というものである。
文書は、自らが政府機関や企業とともにまとめられた「生きた文書」であり、分野の進展に応じて更新されることを意図していると明言している。バージョン 1.5 では、v1.0 以降に 60 社を超える企業からのフィードバックを取り入れたことが記録されており、その中にはシステミックなリスクやマルチエージェントのリスク、そしてシステムの複雑さやサードパーティ製ソリューションの利用といった新たなリスク要因の追加が含まれる。
詳細
フレームワークの中心的な構造は 4 つの次元であり、順番に進む手順ではなく反復的なプロセスとして提示されている。監視中に見つかった異常は、組織に先の次元を再評価させるきっかけとなることが想定されている。
事前にリスクを評価し限定する。 適性は発生可能性と影響の関数として判断され、その際に考慮される要因が挙げられている。すなわち、その領域がどこまで誤りを許容できるか、エージェントが機密データや外部システムにアクセスできるか、その行動の範囲と可逆性、自律性のレベル、タスクの複雑さ、エージェントが外部の当事者によって提供または運用されているか、そしてシステム全体の複雑さである。自律性は、エージェントに何が許されているかと、エージェントがどこまで自ら判断するかという、フレームワークが先に示す区別の一方にあたる（アクション空間 を参照）。限定は設計を通じて行われる。ツールやデータへの最小権限のアクセス、プロセス主導のタスクにおいて自律性を制約する SOP、そしてエージェントをオフラインにし、その影響範囲（ブラスト半径）を限定する仕組みである。フレームワークの一般的な方針ははっきりと述べられている。非決定論的な制限よりも決定論的な制限を優先し、設計によって限定すること、つまりエージェントにツールを呼び出さないようプロンプトで指示するのではなく、アクセス制御によって呼び出しを防ぐことである。エージェントのアイデンティティは限定のもう一方の柱として扱われる。アイデンティティは一意で暗号学的に検証可能であり、監督するエージェント、人間、または部署に結びつけられ、エージェントがどの立場で行動しているかによって区別され、一元的に管理されるべきだとされる。これが エージェントスプロール に対する防御策として示されており、権限付与は範囲が限定され、時間またはセッション単位で有効期限が設けられ、譲渡不可であるべきだとされる。フレームワークは経験則として、人間のユーザーが、自分自身に認められている以上の権限をエージェントに設定できるべきではないと示している。
人間が意味のある形で説明責任を負うようにする。 ここでフレームワークが直面する難しさは、エージェントの行動が固定されたロジックからではなく動的に生じること、そしてモデル開発者、プラットフォーム提供者、システム提供者またはアプリ開発者、ツール提供者、導入者、エンドユーザーにまたがるバリューチェーンが説明責任を分散させてしまうことである。その解決策は明示的な割り当てである。組織内（主要な意思決定者、プロダクトチーム、サイバーセキュリティチーム、ユーザー）でも、外部の当事者との契約においても割り当てを行い、それを意味のある監督のための設計と組み合わせる。具体的には、人間の承認を必要とする重要なチェックポイント（重大な結果を伴う行動、不可逆な行動、外れ値的な振る舞い、ユーザーが定義した閾値）を定め、生のログをそのまま渡すのではなく、承認リクエストを文脈に即した理解しやすいものに保つことである。フレームワークは、その監督が引き続き有効であるかどうかを、前提とするのではなく測定すべきものとして扱っている（自動化バイアス を参照）。
技術的な統制とプロセスを実装する。 統制は、特にエージェント型の新しい構成要素に対して推奨されている。エージェントに自らの計画が指示に沿っているかを振り返らせ、その計画をログに記録すること、厳格な入力形式と最小権限のツール、信頼できる MCP サーバーのホワイトリスト化とコード実行のサンドボックス化、そしてエージェント同士が自由形式のテキストではなく型付きの関数呼び出しで通信するよう求め、エージェント間の共有メモリを制限することである。文書はまた、MCP がエージェントとそれがアクセスするシステムとの間に位置することから、MCP 自体をガバナンスのレイヤーとして活用する案も示している。テストには、出力の正しさを超えた新たな観点が必要だとされる。すなわち、タスク実行全体、ポリシーの遵守、ツール呼び出し、堅牢性であり、これらをワークフロー全体にわたって、マルチエージェントシステムのレベルで、現実的な環境において、さまざまなデータセットで繰り返しテストする。導入は段階的に行い、継続的に監視することが想定されている。そのための手段として、アラートの閾値、異常検知、他のエージェントを監視するエージェント、改ざんできないログ、そして承認の基盤が機能しないときのデフォルト拒否が挙げられている。
エンドユーザーが責任を果たせるようにする。 ユーザーは、エージェントとやり取りする人々と、エージェントを自らの業務プロセスに組み込む人々とに分けられる。前者に対しては透明性が重視され、後者に対してはそれに加えて教育とトレーニングが求められる。フレームワークは特に、実務技能（tradecraft）の喪失を事業継続上のリスクとして取り上げている。通常は訓練の場となる初歩的なタスクをエージェントが引き受けるようになると、エージェントが誤作動したり利用できなくなったりしたときに必要となる業務知識をユーザーが失うおそれがある。
いくつかのケーススタディはエージェント型コーディングに直接関係している。GovTech によるエージェント型コーディングアシスタントの段階的な展開（2025 年 10 月から Windsurf と GitHub Copilot の Agent Mode、2026 年 4 月から Claude Code）では、第 1 段階は意図的に社内の従業員、MCP なし、低リスクのシステムに限定され、その間に第 2 段階に向けて一元的なロギングと MCP ガバナンス・フレームワークが構築されたと説明されている。記録された教訓には、OS ネイティブのサンドボックスを許可することで承認者の認知負荷を減らすことが含まれる。Tencent の CodeBuddy は、行動のリスクに応じて調整された承認要件の例として用いられている。IMDA のケーススタディは、4 つの次元すべてを OpenClaw の導入に適用している。フレームワークはまた、人間による監督についての議論の中で、エージェントを使って「バイブコーディング」を行うユーザーは、生成されたコードの堅牢性をレビューするだけのソフトウェアエンジニアリングの専門知識を持っていない可能性があると指摘している。