本稿は「証跡駆動・自己改善型Dynamic MASとAIクローン」シリーズの第一回（思想編）です。本シリーズでは、SPA-IT（Security × Privacy × AI Governance）視点から、証跡駆動・自己改善型のDynamic MASとAIクローンに関する設計と運用の記録を段階的に整理します。
はじめに：「AIが動く」と「AIが制御可能な状態で動く」は別のことです
AIを使って作業を自動化するのは、今やさほど難しくありません。LLMを呼び出し、結果を使えばそれで動きます。問題は、その「動く」状態が持続可能かどうかです。
私はここ数ヶ月、単に動くAIシステムを作るのではなく、制御可能な状態で自律的に動き続けるシステムを設計・構築してきました。本稿ではその設計上の判断とその根拠を、AIガバナンス・セキュリティ・プライバシーを統合したSPA-IT（Security, Privacy, and AI-governance: Integrated Technology）の視点から整理します。
1. なぜ「Dynamic MAS」なのか
固定ワークフローの自動化と、Dynamic Multi-Agent System（動的マルチエージェントシステム）には根本的な違いがあります。
固定ワークフローは、想定された手順が正しく機能している間は強力です。しかし、状況が変わる・例外が起きる・前提が崩れるという場面になると、人間の介入なしには先へ進めなくなります。設計者が想定した範囲の外に出た瞬間に止まるシステムです。
Dynamic MASは、エージェントの構成・経路・フォールバックが状況に応じて変化します。タスクの優先度が変われば担当エージェントが変わる。あるルートが失敗すれば別のルートへ切り替わる。この「状況適応」が、長期稼働・複合タスクに耐えられる本質的な理由です。
業界標準の文脈では、これはIEEE P3394やNCCoE AI Agent Identity等が想定している「autonomous agent / dynamic spawn / inter-agent communication」の実装です。しかし、論文やフレームワーク文書に書かれていることと、実際に動かしたときに現れる問題の間には、かなりの距離があります。
2. AIの記憶に頼らない設計——RDB-backedという選択
LLMの出力は揺れます。同じプロンプトを送っても返答は変わりうる。コンテキストが長くなれば前半の情報が薄まる。これはLLMの特性であり、欠陥ではありません。問題は、この揺れを前提とせずにシステム設計をすることです。
私が採用したのは、RDB / 構造化された永続ストアを唯一の真実のソース（Source of Truth）とする設計です。タスクの状態、承認履歴、エージェントの実行記録、証跡——これら全てをRDBに書き込む。AIはRDBの状態を読んで行動し、行動した結果をRDBに書き戻す。AIの記憶ではなく、データベースの制約が整合性を保証します。
これにより得られるのは「再現性」と「監査可能性」です。昨日のどの時点でどのエージェントが何を決定し、どの人間が承認したか——これが後から問われたとき、即座に答えられる設計になっています。ISO/IEC 42001が求める文書化・説明責任の実装として、これが最も堅牢だと判断しました。
3. MCPを標準ツールバスとして使う理由
Model Context Protocol（MCP）は、AIと外部ツールの接続を標準化するプロトコルです。各ツールを個別のCLIで直接呼び出す構成と比べると、MCP経由の構成は一見迂回路に見えます。なぜ標準バスを選んだのか。
個別CLI直叩きの構成では、接続方法・エラー処理・認証ロジックがツールごとに異なります。新しいツールを追加するたびに全体の設計が変わる。これは短期的には速いが、長期的にはメンテナンスコストと脆弱性を蓄積します。
MCP経由では、接続レイヤーが標準化される。全ての呼び出しが同一の経路を通るため、ログ・監査・権限チェックを一箇所に集約できます。セキュリティの観点では、これはアタックサーフェスの局所化です。ガバナンスの観点では、監査ポイントの一元化です。拡張時の一貫性を保つためにMCPを選びました。
4. Evidence-driven governance——証跡を設計の一部にする
「AIが何かをした」という事実は、証跡として記録されなければガバナンス上存在しないも同然です。
このシステムでは、重要な作業はすべて証跡レコードに接続されます。どのタスクがどの証跡を生んだか、どの承認がどの証跡によって裏付けられているか——この連鎖が監査証跡の実体です。単にログファイルに出力するのではなく、RDB上のレコードとして構造化することで、後から機械的に検索・検証できます。
これはISOやNISTの要求を「形式的に満たす」ためではありません。実際のインシデント対応で、どのエージェントがいつ何を処理したかを即座に特定できないシステムは、ガバナンス上実質的に機能していないからです。証跡設計は後付けではなく、設計の核心に置くべきものです。
5. HITLの境界設計——自動化していい領域と人間が介入すべき領域
HITL（Human-in-the-Loop）の設計で最も難しいのは、境界の定義です。全部人間が承認すれば安全だが、スケールしない。全部自動化すれば速いが、ある日意図しない方向に正確に動いているという状況になる。
私が実装した境界設計は、米国NCCoEのコンセプトペーパーで提唱されている8つのエスカレーショントリガーを参照しています。外部へのデータ送信、本番環境への書き込み、個人情報へのアクセス、閾値超過、自己計画の変更、連続例外、子エージェントの生成、スコープ逸脱——これらを検知した場合は必ず人間の承認を要求します。
逆に言えば、これらのトリガーに該当しない軽微で可逆的なタスクはエージェントが自動で進める。この「明示的な境界」があってはじめて、自律性とコントローラビリティは両立します。
6. 自己改善ループ——システムが自分の問題を検出する
稼働し続けるシステムは必ず経年劣化します。タスクが積み上がり、証跡が欠け、ルールが現実と乖離し始める。これを人間が定期的に監視するのは現実的ではありません。
このシステムには、自分の状態を監視して問題を検出する仕組みがあります。タスクの状態が中途停止状態のまま止まっている、依存関係が変わって実行不能状態になっている、証跡が接続されていない——こういった問題状態を検出し、修正タスクを生成する。さらに、AI技術・MCP仕様・LLMセキュリティに関する外部変化を定期的に取り込み、改善候補として整理・優先度付けする仕組みも含まれています。
ただし、自己改善の境界も明示的に設けています。コアポリシーの変更・重大なアーキテクチャ変更・外部サービスへの影響・人間のHITL判断に影響するルールの変更——これらは自己改善の対象外であり、必ず人間の判断を経ます。
7. AIクローンという方向性
このシステムが目指している長期的な方向性の一つが、AIクローンです。単に作業を自動化するのではなく、私自身の判断軸・思考パターン・優先順位をAIに再現させるという実験です。
これは技術的な課題というより、ガバナンス上の課題です。「自分の判断を代行するAI」が何かを決定したとき、その責任はどこにあるか。どこまでの判断を委ねてよいか。これを設計として組み込まなければ、クローンAIは「便利だが制御不能な代理人」になります。
SPA-IT視点では、クローンAIの設計はHITLとevidenceの密度が最も高くなる領域です。クローンが行動するたびに証跡を残し、クローンが判断を下すたびに人間の承認ゲートを通る——これが現時点での私の設計方針です。
おわりに：「設計された信頼」と「無根拠な信頼」
AIを使っている組織の多くは、「とりあえず動いている」という状態に対して暗黙的な信頼を置いています。エラーが出なければ動いていると判断する。ログが存在すれば監査可能だと思う。しかし「動いていること」と「意図通りに動いていること」は別の命題です。
証跡駆動・HITL境界・自己改善ループ——これらは全て、AIシステムへの信頼を「暗黙」から「設計された根拠」に変換するための仕組みです。規格要求を満たすためではなく、実際に何が起きているかを人間が把握し続けるための設計です。
AIが高速に動くほど、この「設計された信頼」の有無が、統制できるシステムと統制できないシステムの差として現れます。
本記事は2026年5月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。
次回（第二回：統制原則編）では、AIエージェントを単に動かすのではなく、説明可能で統制可能な状態に置くための設計原則を整理します。