本シリーズでは、証跡駆動・自己改善型のDynamic MASとAIクローンに関する設計と運用の記録を、SPA-IT（Security × Privacy × AI Governance）視点から段階的に整理している。
第一回では、なぜチャットボットでも固定ワークフローでもなくDynamic MASなのか、なぜ証跡駆動なのかという思想的背景を扱った。
本稿（第二回）では、その続編として、AIエージェントを単に動かすのではなく、説明可能で統制可能な状態に置くための設計原則を整理する。
なお、本稿では再現可能な内部実装の詳細ではなく、ガバナンス上の論点と設計判断の考え方に焦点を置く。実装証跡・具体構成は第三回以降で、必要な証跡と説明責任を伴う形で扱う。
なぜ「チャットボット」でも「固定ワークフロー」でもないのか
チャットボットの限界
チャットボットはリクエストに応答するが、タスクを管理しない。会話が終わればコンテキストが消え、「先週の判断」を翌週のセッションが引き継ぐ仕組みがない。進捗・証跡・承認記録が残らない。
固定ワークフロー自動化の限界
RPA・固定シーケンス型の自動化は、予め定義した手順を機械的に実行する。しかし現実のタスクは、状況に応じてルートが変わり、複数の観点から検討すべき場面があり、人間の判断が必要な境界が存在する。固定手順はその柔軟性を持てない。
Dynamic MASが解く問題
Dynamic MAS（動的マルチエージェントシステム）は、タスクの性質に応じてエージェントが動的に選択・派遣され、合議し、証跡を残しながら進行する。変化する状況への適応性と、ガバナンス的な説明責任を両立する設計が求められる。
設計の核心：4つの原則
本稿では、これらを4つの設計原則として整理する。これは筆者の実装経験を通じた整理であり、重要なのは、それらを自律的なAIエージェント基盤の中で一体として扱う点である。
1. MCP-first（標準ツールバス）
主要な操作を標準化されたプロトコルインターフェース経由に寄せる。タスク作成・証跡添付・合議・通知・承認といった重要操作を、可能な限り同一のインターフェース上で扱う。個別のCLIを直接呼び出す場合もフォールバックとして許容されるが、その場合も監査ログへの記録を義務付ける。
標準バスを選択した理由は単純だ。監査性。全呼び出しを監査記録として残せば、「誰が何を使っていつ実行したか」が一意に追跡できる。セキュリティ視点ではアタックサーフェスの局所化、ガバナンス視点では監査ポイントの一元化だ。
2. RDB-backed（構造化された永続ストアをSoTとして使う）
AIの記憶は揺れる。セッションが変われば解釈がずれる。この問題を根本から解決するには、状態管理をAIの外に出すしかない。
構造化された永続ストア（リレーショナルDB）を唯一の真実のソース（Source of Truth）として使い、タスクの状態遷移、全証跡、全ルール、全承認記録をDB上で永続化する。AIが忘れてもDBが覚えている。
このアーキテクチャ選択の核心は、AIの確率的な動作に対して、DBの決定論的な制約が整合性を保証するという点にある。状態管理をAIに任せないという原則だ。
3. Evidence-driven（証跡義務化）
タスクが完了したとしてAIが申告しても、証跡がなければシステムは完了と認めない。完了宣言は証跡の添付を構造的に必要とする設計になっている。これにより、AIの自己申告による完了宣言を防ぐ。
証跡が存在しない完了は、ガバナンス上存在しないも同然だ。ISO/IEC 42001が求める説明責任の実装として、これが最も根拠ある設計だと判断している。
なお、証跡を厚く残せば説明責任は高まるが、同時にPrivacyやdata minimisationとの緊張も生まれる。何を残すか、なぜ残すか、どの目的で再利用するかを設計しなければ、証跡そのものが新たなリスクになる。この点は、Security、Privacy、AI Governanceを分けて考えると見落としやすい。証跡駆動のMASでは、証跡を「多く残す」ことではなく、「目的に照らして説明可能な形で残す」ことが重要になる。詳細は今後のPrivacy編で扱う。
4. Self-improving（失敗も資産化）
定期的な外部情報取り込み、小規模な改善実験、継続失敗時のエスカレーション設計を組み合わせ、失敗・ブロックを改善候補として資産化する。
システムは自分の問題状態（中途停止状態のまま進まないタスク、証跡が接続されていないタスク等）を検出し、修正タスクを生成する。ただし、コアポリシーの変更・重大なアーキテクチャ変更・外部サービスへの影響は、自己改善の対象外であり、必ず人間の判断を経る。
HITL境界の設計
AIを使う上で最も重要な問いのひとつは「どこで人間が判断するか」だ。全自動化は危険であり、全人間判断は自動化の意味をなさない。
このシステムでは、たとえば外部公開、永続データ構造に影響する変更、認証情報に関わる操作、本番環境に影響する変更などを、人間の承認を必要とする領域として扱う。これはHITL境界の一例であり、すべてを網羅するものではない。実際のエスカレーション条件はリスクに応じて設計しており、その詳細は第五回で扱う。
ガバナンス観点からの位置付け
ISO/IEC 42001（AI Management System）、NIST AI RMF、NCCoEのAIエージェントID管理に関する議論等が重視する要素——説明責任・証跡・HITL・リスクティア管理——を、システム設計の中に組み込むことを重視している。
AIガバナンスを「後から文書化する作業」ではなく「システムの構造として組み込む設計」として捉えることが、実運用型AIエージェント基盤の要件だと考えている。
おわりに
「AIを動かす」ことは今や難しくない。難しいのは「AIが何をしたかを後から説明すること」と「AIの判断境界を設計すること」だ。
MCP-first / RDB-backed / Evidence-driven / Self-improving——この4原則は、その難しさに答えるための設計思想である。自律性と統制可能性は、設計によって両立できる。
次回（第三回：実装証跡編）では、外部入力からタスク化、エージェント処理、人間判断、証跡化までの一連の流れを、公開可能な範囲の証跡・画面例とともに示す予定です。
本稿は、筆者のDynamic MAS環境を用いた生成・レビュー・証跡化プロセスを経たうえで、人間が最終確認したものです。外部公開にあたり、認証情報・内部パス・未実装主張・再現可能性が高すぎる具体的設計情報が含まれていないかを確認しています。