Harness and Agent：AI システムのレイヤードアーキテクチャ
ツール層と Agent 層の関係を探り、MCPlato がどのように MCP ネイティブアーキテクチャを実装するか
公開日 2026-03-19
Harness and Agent：AI システムのレイヤードアーキテクチャ
MCP プロトコルから MCPlato のツール層と Agent 層の設計へ
1. はじめに：AI システムのアーキテクチャ的目覚め
モデル至上からアーキテクチャ至上へ
過去 3 年間、AI 業界は単一の指標に執着してきました：モデル機能。ベンチマークスコア、パラメータ数、コンテキストウィンドウサイズが技術的議論を支配しました。暗黙の仮定は明確でした—モデルが優れていれば、システムも優れている。
しかし、2024 年に変化がありました。
大規模言語モデル（LLM）がほとんどの実用的タスクで"十分良い"閾値を超えると、実務者は厳然たる真実を発見しました：AI システムのボトルネックは、めったにモデル自体ではありません。ツール統合が不十分な GPT-4 クラスのモデルは、適切に設計されたツール層を持つ GPT-3.5 クラスのモデルよりも劣ったパフォーマンスを示します。競争の焦点は、生の知能からアーキテクチャのエレガンスへと移行しました。
なぜ Harness 層はモデルよりも重要なのか
このシナリオを考えてみてください：世界で最も能力の高い AI モデルにアクセスできます。複雑な問題を推論し、洗練されたコードを書き、微妙な指示を理解できます。しかし、現実世界との相互作用を試みるとき—ファイルを読み、API を呼び、ウェブサイトを閲覧するとき—それは設計が不十分で、形式が一貫しておらず、安全に実装されていないツールを通じて行います。
結果？フラストレーション、エラー、そして最終的に価値の提供失敗です。
Harness 層（ツール層とも呼ばれる）は、AI が外部世界と相互作用できるようにするすべてのものを表します：ツール定義、実行環境、セキュリティポリシー、エラー処理、結果のフォーマット、メモリ管理。部屋に閉じ込められた輝かしい頭脳と、世界に対して行動できるように装備された頭脳との違いです。
核心的課題：安全で信頼性の高いツール使用
現代の AI アーキテクチャが直面する根本的な問いは、思いのほか単純です：どのようにして Agent が安全で、信頼性が高く、効果的にツールを使用できるようにするのか？
この問いには以下が含まれます：
- 安全性：どのようにして不正なファイルアクセス、データ流出、悪意のあるコード実行を防ぐのか？
- 信頼性：どのようにしてツールが一貫した動作をし、エラーを優雅に処理し、失敗から回復するようにするのか？
- 構成可能性：どのようにして Agent が複数のツールを組み合わせて複雑なタスクを達成できるようにするのか？
- 発見可能性：Agent はどのようにしてどのツールが利用可能で、いつ使用するかを知るのか？
これらの問いに答えるには、関心事を分離し、明確なインターフェースを確立し、利便性よりも堅牢性を優先する、慎重なアーキテクチャアプローチが必要です。
2. レイヤードアーキテクチャ：Harness と Agent の理論モデル
これらの課題に対処するために、2 つの異なるアーキテクチャ層間の明確な関心事の分離を提案します：Harness 層とAgent 層です。この分離は単なる組織的なものではありません—根本的に異なる責任、障害モード、最適化目標を反映しています。
2.1 Harness 層（ツール層）
Harness 層は、AI 推論と外部世界間のインターフェースとして機能します。その責任は具体的で、運用的であり、主に決定ではなく実行に関心があります。
核心的責任
| 責任 | 説明 |
|---|---|
| ツールカプセル化 | 外部機能（ファイルシステム、API、データベース、ブラウザ）を明確に定義された呼び出し可能インターフェースにラップする |
| 実行オーケストレーション | ツール呼び出しのライフサイクルを管理：検証、実行、タイムアウト処理、クリーンアップ |
| 検証と保護 | セキュリティポリシーの実施、信頼できない操作のサンドボックス化、不正アクセスの防止 |
| メモリ管理 | 状態永続化、Session ストレージ、ツール呼び出し間のコンテキスト共有の処理 |
| 結果フォーマット | 生のツール出力をモデル消費に適した構造化形式に変換 |
重要な洞察：Harness は"その他すべて"を処理する
Harness 層の決定的な特徴は、純粋なモデル推論の外部のすべてを処理することです。モデルが"セールスデータの CSV を分析して要約レポートを生成する"という計画を生成するとき、Harness 層は：
- CSV ファイルを検索して読み込む
- ファイルパーミッションと形式を検証する
- 分析を実行する（コードを呼び出す可能性あり）
- エラーやエッジケースを処理する
- モデル消費用に結果をフォーマットする
- 一時的なリソースとクリーンアップを管理する
モデルは何をすべきかに集中します；Harness はそれを安全にかつ信頼性を持って実行できることを保証します。
2.2 Agent 層（プロキシ層）
Harness 層が実行についてであるなら、Agent 層は意思決定についてです。より高いレベルの抽象化で動作し、特定のツール呼び出しではなく目標、計画、戦略に関心があります。
核心的責任
| 責任 | 説明 |
|---|---|
| タスク計画 | 高レベルの目標を実行可能なサブタスクに分解し、実行順序を決定する |
| ツール選択 | 特定のサブタスクに適切なツール（あれば）を選択する |
| 推論と意思決定 | 中間結果の評価、フィードバックに基づく計画の調整、曖昧性の処理 |
| コンテキスト管理 | 関連する会話履歴の維持、ノイズのフィルタリング、重要な情報の優先順位付け |
| ユーザーインタラクション | いつ説明を求め、中間結果を提示し、承認を要求するかを決定する |
重要な洞察：Agent は抽象化を通じて動作する
Agent 層は、ファイルを直接操作したりコードを実行したりしません。代わりに、ツールの抽象化を通じて動作します—その機能、制限、適切なユースケースを理解します。Agent が"関連ドキュメントを検索する"と決定するとき、実際の検索操作を Harness 層に委任し、Harness がクエリ構築、API 呼び出し、結果取得の詳細を処理することを信頼します。
2.3 インタラクションモデル：テキストフロー図
Agent と Harness 間の関係は、明確な境界を持つリクエスト-レスポンスパターンに従います：
┌─────────────────────────────────────────────────────────────────────┐
│ インタラクションフロー │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ツール検出 ┌──────────────────────┐ │
│ │ │ ─────────────────────> │ │ │
│ │ AGENT │ │ HARNESS │ │
│ │ LAYER │ │ LAYER │ │
│ │ │ <───────────────────── │ │ │
│ │ │ ツールマニフェスト │ │ │
│ └──────┬───────┘ └──────────────────────┘ │
│ │ │
│ │ 1. Agent がタスクを分析し適切なツールを選択する │
│ │ 2. Agent がパラメータを持つ呼び出しリクエストを作成する │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 呼び出しリクエスト │ │
│ │ { │ │
│ │ "tool": "file_read", │ │
│ │ "params": { "path": "/data/sales.csv" }, │ │
│ │ "context": { "session_id": "abc123" } │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HARNESS 処理 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 検証 │ ─>│ 実行 │ ─>│ フォーマット │ │ │
│ │ │ リクエスト │ │ ツール │ │ 結果 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ レスポンスメッセージ │ │
│ │ { │ │
│ │ "status": "success", │ │
│ │ "result": { "content": "...", "metadata": {...} }, │ │
│ │ "elapsed_ms": 150 │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ AGENT │ ← Agent が結果を統合し、推論を続ける │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
2.4 分離の利点
このレイヤードアーキテクチャは、いくつかの重要な利点を提供します：
1. 独立した進化 Harness 層は、Agent 層を変更することなく新しいツールで拡張できます。新しい API が利用可能になると、ツール実装のみを変更する必要があります—Agent は単にツールマニフェストで新しい機能を見ます。
2. 再現性とテスト Harness 操作は決定論的でテスト可能です。Agent がそのファイルを読み取る決定とは無関係に、ファイル読み取り操作が正しく機能することを確認できます。この分離により、両方の層でのユニットテストが可能になります。
3. セキュリティ境界 セキュリティポリシーは Harness 層で実施され、Agent が回避できないハード境界を作成します。Agent が侵害されたり誤導されたりしても、Harness サンドボックスの制約内で動作します。
4. マルチ Agent サポート 複数の Agent が同じ Harness 層を共有でき、それぞれが一貫したツール動作とセキュリティポリシーから恩恵を受けます。これにより、複雑なタスクの異なる側面を異なる Agent が処理する協力シナリオが可能になります。
3. MCP プロトコル：AI の USB-C インターフェース
2024 年 11 月、Anthropic は **Model Context Protocol（MCP）**をリリースしました。これは、USB-C がデバイス接続に対して行ったことを AI ツール統合に対して実現することを約束するオープン標準です：単一の汎用インターフェースを提供し、フラグメンテーションを排除し、真の相互運用性を実現します。
3.1 MCP が解決する問題
MCP 以前、新しいデータソースやツールを AI アプリケーションに統合するには、通常カスタムコネクタの構築が必要でした。Postgres データベースを AI にクエリさせたいですか？コネクタを書いてください。会社の CRM にアクセスさせたいですか？別のコネクタを書いてください。各統合は独自のもので、脆弱で、特定の AI プラットフォームに依存していました。
MCP は、AI アプリケーションが外部システムに接続する方法の標準プロトコルを定義することにより、この統合コストを排除します。N×M 回の統合（N ツール × M AI プラットフォーム）の代わりに、MCP は N+M 回の統合を可能にします（各ツールが一度 MCP を実装し、各プラットフォームが一度 MCP をサポートする）。
3.2 MCP アーキテクチャ：3 つのコア役割
MCP は、ツールエコシステム内の異なる責任に対応する 3 つのアーキテクチャ役割を定義します：
┌─────────────────────────────────────────────────────────────────────┐
│ MCP アーキテクチャ │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │
│ │ │ │ │ │ │ │
│ │ HOST │◄───────►│ CLIENT │◄───────►│ SERVER │ │
│ │ │ │ │ │ │ │
│ │ AI アプリ │ │ 接続管理 │ │ ツール/データ│ │
│ │ (MCPlato, │ │ │ │ プロバイダ │ │
│ │ Claude, │ │ • プロトコル │ │ │ │
│ │ Cursor) │ │ 処理 │ │ • Tools │ │
│ │ │ │ • 能力発見 │ │ • Resources│ │
│ │ インタラクション│ │ • 状態管理 │ │ • Prompts │ │
│ │ のオーケストレーション│ │ │ │ │ │
│ │ │ │ │ │ │ │
│ └──────────────┘ └──────────────┘ └────────────┘ │
│ │
│ 責任： │
│ • HOST：UX、オーケストレーション、ライフサイクル管理 │
│ • CLIENT：プロトコルコンプライアンス、能力交渉 │
│ • SERVER：ツール実装、データアクセス、実行 │
│ │
└─────────────────────────────────────────────────────────────────────┘
| 役割 | 説明 | 例 |
|---|---|---|
| Host | ユーザーが相互作用する AI アプリケーション；接続を管理しインタラクションをオーケストレーションする | MCPlato、Claude Desktop、Cursor |
| Client | 特定の MCP Server への接続を管理；プロトコルコンプライアンスと能力発見を処理する | Host 内の組み込み MCP Client |
| Server | MCP プロトコルを介して特定の能力（ツール、リソース、プロンプト）を提供する | ファイルシステム Server、GitHub Server、Postgres Server |
3.3 MCP コアプリミティブ
MCP は、Server が提供できる 3 つの基本的なプリミティブを定義します：
Tools（実行可能関数） Tools は、アクションを実行する関数—ファイルの読み取り、データベースのクエリ、メッセージの送信、コードの実行などです。構造化パラメータを受け入れ、構造化結果を返します。Tools は、コンテキストと必要性に基づいて AI によって明示的に呼び出されます。
{
"name": "file_read",
"description": "ファイルの内容を読み込む",
"inputSchema": {
"type": "object",
"properties": {
"path": { "type": "string", "description": "ファイルパス" }
},
"required": ["path"]
}
}
Resources（データソース） Resources は、AI が参照できるデータ—ファイルの内容、データベーススキーマ、API ドキュメント、設定ファイルなどを表します。Tools と異なり、Resources は通常読み取り専用であり、アクションではなくコンテキストとして機能します。
Prompts（インタラクションテンプレート） Prompts は、特定のタスクにおける AI の動作をガイドする、事前定義されたインタラクションパターンまたはテンプレートを提供します。システム指示、例示インタラクション、または構造化リクエスト形式を含むことができます。
3.4 なぜ MCP はアーキテクチャにとって重要なのか
MCP は、単なる利便性以上のものです—AI ツール統合について考える方法の根本的な転換を表しています：
標準化は競争を可能にする ツールが共通標準を実装すると、競争は"誰が最も多くの統合を持っているか"から"誰がそれらの統合で最良のエクスペリエンスを提供するか"に移行します。これはユーザーに利益をもたらし、ツール品質と AI 機能の両方でイノベーションを促進します。
分離は専門化を可能にする MCP を使用すると、ツール開発者は AI プラットフォームの互換性を心配することなく、優れたツールの構築に集中できます。AI プラットフォームは、数え切れないほどのカスタムコネクタを維持することなく、オーケストレーションと推論に集中できます。
構成可能性はエコシステムを可能にする MCP はネットワーク効果を生み出します：各新しい MCP Server はすべての MCP 互換 Host に利益をもたらし、各新しい MCP Host は既存のすべての Server に価値を生み出します。このフライホイール効果は、エコシステムの成長を加速します。
4. MCPlato のアーキテクチャ実践
MCPlato は、Harness-Agent レイヤードアーキテクチャの具体的な実装を表し、MCP を事後考慮ではなく基礎原則として構築されています。その設計は、学術研究と AI システムの実際のデプロイメントの両方から得た教訓を反映しています。
4.1 3 層アーキテクチャモデル
MCPlato のアーキテクチャは、明確な責任と境界を持つ 3 つの異なる層を中心に構成されています：
┌─────────────────────────────────────────────────────────────────────┐
│ MCPLATO アーキテクチャ │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ WORKSPACE LAYER │ │
│ │ │ │
│ │ • Workspace 管理と分離 │ │
│ │ • マルチディレクトリマウント │ │
│ │ • クロス Session メモリ（Diary） │ │
│ │ • 環境設定 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ SESSION LAYER │ │
│ │ │ │
│ │ • コンテキスト維持とメッセージ履歴 │ │
│ │ • メッセージルーティングと配信 │ │
│ │ • Session レベル状態管理 │ │
│ │ • マルチ Session 調整 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ AGENT LAYER │ │
│ │ │ │
│ │ • ClawMode 自律実行 │ │
│ │ • タスク計画と分解 │ │
│ │ • ツール選択と呼び出し │ │
│ │ • マルチステップ推論と回復 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HARNESS LAYER │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌────────┐ │ │
│ │ │ @Tool │ │ Infographic │ │ Browser │ │ PDF │ │ │
│ │ │ Suite │ │ Creator │ │ Automation │ │ Tools │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └────────┘ │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌────────────────────────┐ │ │
│ │ │ MCP │ │ Image Gen │ │ Document Analysis │ │ │
│ │ │ Host │ │ & Edit │ │ (OCR/Understanding) │ │ │
│ │ └─────────────┘ └─────────────┘ └────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Workspace Layer
Workspace 層は、組織的な境界と、個々の Session をまたぐ永続ストレージを提供します。これは MCPlato の階層における最も高いレベルの抽象化です。
主な機能：
- 分離：各 Workspace は、個別の設定、マウントされたディレクトリ、環境変数を維持する
- マルチディレクトリマウント：Workspace は複数のプロジェクトディレクトリを含むことができ、クロスプロジェクトワークフローを可能にする
- 永続メモリ：Diary システムは、Session をまたいで長期記憶を維持し、洞察と決定を保存する
- 環境管理：MCP Server、カスタムツール、動作設定の Workspace レベル設定
Session Layer
Session 層は、即時のインタラクションコンテキスト—特定の会話またはタスクに関連するメッセージ、状態、一時的なデータ—を管理します。
主な機能：
- コンテキスト維持：Session 内のメッセージ履歴、ツール結果、中間状態
- メッセージルーティング：ユーザー入力を適切なハンドラに配信し、出力をルーティングし直す
- 並列実行：単一の Workspace 内での複数の同時 Session のサポート
- 状態永続化：長時間実行タスクの Session 状態を保存して再開する能力
Agent Layer
Agent 層は、MCPlato の ClawMode 自律実行エンジンに体現されている、システムの推論と意思決定能力を実装します。
主な機能：
- 自律実行：ClawMode は、継続的なユーザー入力なしに決定を下して独立して動作することを Agent に可能にする
- タスク計画：依存関係管理を持つ実行可能なステップに複雑な目標を分解する
- マルチ Session 調整：並列または順次実行のために、複数の Session にわたって作業をオーケストレーションする
- 自己改善：実行パターンから学び、将来の動作を最適化する能力
4.2 Harness 統合特性
MCPlato の Harness 層は、いくつかの重要な設計決定によって際立っています：
MCP ネイティブサポート
MCP サポートをプラグインまたは拡張として追加するシステムとは異なり、MCPlato は MCP をコアアーキテクチャ原則として実装します：
- 組み込み MCP Host：stdio および HTTP トランスポートをサポートする完全な MCP Host 実装
- 動的 Server 管理：MCP Server のランタイム追加、削除、設定
- 能力発見：利用可能なツール、リソース、プロンプトの自動検出と公開
- ホットロード：アプリケーションを再起動することなく新しい MCP Server を追加できる
組み込みツールスイート
MCP に加えて、MCPlato は、生産性ワークフロー向けに設計された包括的な組み込みツールセットを提供します：
| ツールカテゴリ | 機能 |
|---|---|
| @Tool Suite | ファイル操作、bash 実行、コード編集、Web 検索 |
| Infographic Creator | データ可視化、チャート生成、ダイアグラム作成 |
| Browser Automation | Web ナビゲーション、フォーム入力、スクリーンショットキャプチャ、要素インタラクション |
| Image Tools | 生成（複数モデル）、編集（インペイント/アウトペイント）、合成、スタイル転送 |
| Document Tools | PDF 分析、OCR、構造化抽出、形式変換 |
組み込みスイートの各ツールは、MCP ツールと同じインターフェース標準に従い、ネイティブ機能または外部 Server を使用する場合に一貫した動作を保証します。
動的ツール発見
Harness 層は、洗練されたツール発見メカニズムを実装します：
- ランタイム内省：ツールはその機能、パラメータ、要件を動的に宣伝する
- セマンティックマッチング：Agent は、必要な自然言語記述に基づいてツールを発見できる
- バージョン管理：同一ツールの複数バージョンのサポートと優雅な非推奨化
- 依存関係解決：ツール依存関係と前提条件チェックの自動処理
4.3 Agent 機能
MCPlato の Agent 層（ClawMode）は、より単純なチャットベースのインターフェースとは区別されるいくつかの高度な機能を実装します：
タスク計画と分解
複雑な目標が提示されると、Agent は：
- 必要なステップと依存関係を特定するために目標を分析する
- 各ステップに適切なツールを選択する
- 成功基準とチェックポイントを確立する
- 中断から生き残ることができる回復可能な実行計画を作成する
マルチ Session 調整
Agent は、複数の Session にわたって作業をオーケストレーションできます：
- 並列実行：別々の Session で独立したサブタスクを実行する
- シーケンシャルパイプライン：一方の出力が他方の入力になる Session をチェーンする
- クロス Session メモリ：分離を維持しながら Session 間で関連するコンテキストを共有する
長時間実行タスクのサポート
MCPlato は、単一のインタラクションを超えるタスクをサポートします：
- スケジュール実行：Cron ベースおよび定期的なタスクスケジューリング
- チェックポイントと再開：回復のための主要マイルストーンでの状態保存
- 進捗報告：長時間実行操作のリアルタイム更新
- ヒューマンインザループ：人間の判断を必要とする決定の適切なエスカレーションポイント
5. 競合アーキテクチャ比較
MCPlato のアーキテクチャ上の選択を理解するために、AI Agent ランドスケープの他のシステムと比較すると有用です。次の表は、重要なアーキテクチャ上の違いをまとめています：
| 製品 | Harness 設計 | Agent 設計 | アーキテクチャ特性 |
|---|---|---|---|
| Claude Code | 組み込みツール + MCP サポート | 単一 Agent、長時間実行 Session | Agent-Harness 統合の先駆者；ターミナル中心；CLAUDE.md でメモリ管理 |
| Cursor | MCP エコシステム + 組み込みエディタツール | Agent 2.0 で自律機能 | Agent 優先 IDE；マルチファイル変更用 Composer；並列 Agent 実行（最大 8） |
| OpenClaw | ツールサンドボックス + Skills フレームワーク | 階層的マルチ Agent 設計 | オープンソースフレームワーク；マルチチャネルアクセス用 Gateway 層；セルフホスト |
| Devin | クラウド統合ツールスイート | エンドツーエンドエンジニアリング Agent | Agent ネイティブ IDE；完全なクラウドサンドボックス；SWE-bench 最適化 |
| MCPlato | 組み込みツール + MCP ネイティブ Host | ClawMode 自律実行 | 3 層分離アーキテクチャ；Local First；完全なツールチェーン |
5.1 設計選択の分析
Claude Code は、シンプルさと既存の開発者ワークフローとの統合を優先します。その Harness はリーンで、基本的なファイルおよびターミナル操作に焦点を当てています。Agent 層は単一の長時間実行 Session を維持し、これはコンテキスト管理を簡素化しますが並列化を制限します。
Cursor は、IDE コンテキスト内での開発者生産性を強調します。その Harness は、エディタの既存機能を活用しながら、拡張性のために MCP サポートを追加します。Agent 2.0 アーキテクチャは、コード編集の限られたコンテキスト内で自律性を導入します。
OpenClaw（MCPlato のオープンソース基盤）は、その Gateway-Agent-Tools 階層を通じて最大の柔軟性を提供します。フレームワークとして製品ではないため、すぐに使えるエクスペリエンスよりも構成可能性を優先します。
Devin はクラウドネイティブの極端を表します：環境全体が仮想化され、管理されています。これにより強力な機能が可能になりますが、クラウドインフラストラクチャへの統制の譲渡が必要です。
MCPlato は独自の位置を占めています：OpenClaw の柔軟性と製品レベルの磨き上げを組み合わせ、Local First 原則を追加し、関心事を明確に分離する 3 層アーキテクチャを実装します。
5.2 重要な差別化要因
| 次元 | MCPlato の利点 |
|---|---|
| アーキテクチャの深さ | 3 層設計（Workspace-Session-Agent）対 2 層またはフラット設計 |
| MCP 統合 | ネイティブ Host 実装対アドオンサポート |
| Local First | 完全なローカルツールチェーン対クラウド依存またはサンドボックス制限 |
| ツールの完全性 | 基本的なファイル操作を超えた組み込み画像、ドキュメント、Infographic、ブラウザツール |
| メモリアーキテクチャ | 3 層永続化（Workspace/Session/Diary）対単一コンテキストまたは手動メモリファイル |
| スケジューリング | ネイティブ Cron ベーススケジューリング対外部スケジューラ依存またはサポートなし |
6. アーキテクチャ設計原則とベストプラクティス
MCPlato および比較可能なシステムの分析に基づき、効果的な Harness-Agent アーキテクチャを設計するためのいくつかの原則を抽出できます：
6.1 原則 1：レイヤード・ディカップリング
Harness 層と Agent 層は、明確で安定したインターフェースを持つべきです。
- 層間に明示的なコントラクトを定義する（MCP などのプロトコルがこれらを提供する）
- 層境界を越えて実装の詳細が漏れるのを避ける
- 各層の独立したテスト、デプロイメント、進化を可能にする
- 層の責任を曖昧にする"便利な"ショートカットを追加する誘惑を抑える
6.2 原則 2：標準優先
カスタムソリューションを構築する前にオープン標準を採用する。
- MCP などの標準は即座のエコシステム利益を提供する
- カスタムプロトコルは技術的負債と統合課題を生み出す
- 標準は集合的知恵から生まれる—その蓄積された知識を尊重する
- 不必要にフォークするより、標準の進化に貢献する
6.3 原則 3：動的発見
ツールはハードコードではなく、ランタイムで発見可能であるべきです。
- Agent は、コード変更なしで利用可能なツールに適応できるべきである
- ツールマニフェストには豊富なメタデータ（説明、パラメータ、例）を含めるべきである
- ゼロダウンタイムツール更新のためのホットロードをサポートする
- 標準インターフェースを通じてツールチェーニングと構成を可能にする
6.4 原則 4：セキュリティ分離
ツール実行はサンドボックス化され、ポリシーによって実施されるべきです。
- Agent が間違いを犯したり誤導されたりする可能性があると仮定する
- 多層での検証による多層防御を実装する
- 最小権限の原則を使用する—ツールは必要なパーミッションのみを取得する
- セキュリティ重視の操作に明確な監査証跡を提供する
6.5 原則 5：状態永続化
長時間実行タスクには堅牢な状態管理が必要です。
- 中断を考慮した設計—タスクは一時停止、強制終了、または失敗する
- タスク境界でのチェックポイント/復元メカニズムを実装する
- 一時的な状態を永続的な状態から分離する
- 状態が失われたときの優雅な劣化を可能にする
6.6 ベストプラクティスチェックリスト
Harness-Agent アーキテクチャを実装する際、以下を考慮する：
- ツール定義：ツールは明確なスキーマと例を持って適切に文書化されているか？
- エラー処理：ツールは実用的なエラーメッセージと回復提案を提供するか？
- 可観測性：Agent の決定から Harness 実行までリクエストを追跡できるか？
- レート制限：偶発的な悪用や無限ループに対する保護はあるか？
- ユーザーコントロール：ユーザーは Agent のツール選択を検査、承認、または上書きできるか？
- フォールバック戦略：優先ツールが利用できない場合はどうなるか？
- リソースクリーンアップ：一時ファイル、接続、プロセスは適切に解放されているか？
7. 結論：アーキテクチャとしての競争優位
AI システムの未来を見据えると、明確なパターンが浮かび上がります：モデル機能は商品化されつつありますが、アーキテクチャの優秀さは持続可能な競争優位であり続けます。
7.1 モデル機能のプラトー
フロンティアモデルと有能なオープンソースの代替品の間のギャップは縮まっています。蒸留、量子化、効率的なトレーニングなどの技術は、強力な推論能力へのアクセスを民主化しています。数年以内に、ほとんどのアプリケーションにとって"モデル品質"は解決済みの問題になるでしょう。
解決されないのは統合の課題—これらの有能なモデルを企業システム、個人のワークフロー、外部データソースの混乱した、異種混合の現実に接続することです。これがアーキテクチャの領域です。
7.2 Harness 信頼性としての決定的要素
モデルが"十分良い"とき、決定的要素は次のようになります：
- 信頼性：システムは多様なシナリオで一貫して動作するか？
- 安全性：ユーザーはシステムを自分のデータとシステムで信頼できるか？
- 拡張性：システムは再設計なしに新しい要件に適応できるか？
- 可観測性：運用者はシステムの動作を理解してデバッグできるか？
これらはモデルの関心事ではなく、アーキテクチャの関心事です。Harness 層は、これらの関心事に対処する場所です。
7.3 MCP とツールアクセスの統一
MCP は、AI アーキテクチャにおける極めて重要な瞬間—ツール統合の真の標準の出現を表します。MCP の採用が増えるにつれ、次のことが期待できます：
- 利用可能なツールの爆発的な成長（すべての SaaS 製品、データベース、API が AI アクセス可能になる）
- 統合数量ではなくオーケストレーション品質での AI プラットフォーム間の競争の激化
- 専門化した Harness プロバイダーの出現（セキュリティ重視、パフォーマンス最適化、ドメイン固有）
7.4 単一 Agent からマルチ Agent 協調へ
現在の世代の AI システムは、主に Agent を単一のエンティティとして扱います。次の世代は、特殊化した Agent が複雑なタスクで協調するマルチ Agent アーキテクチャを受け入れるでしょう：
- 情報を収集して統合するリサーチ Agent
- 目標を分解してリソースを割り当てるプランニング Agent
- 特定のシステムとツールと相互作用する実行 Agent
- 品質を検証し、エラーを捕捉するレビュー Agent
これらのマルチ Agent システムには、以下ができる洗練された Harness 層が必要になります：
- Agent 間通信と調整
- Agent 境界を越えた共有コンテキスト管理
- Agent が意見を異にするときの紛争解決
- リソース配分と優先順位付け
Workspace、Session、Agent の関心事を明確に分離した MCPlato の 3 層アーキテクチャは、このマルチ Agent の未来の基盤を提供します。
7.5 最後の考え
"モデル優先"から"アーキテクチャ優先"の考え方への移行は、AI 分野の成熟を表します。私たちは、何が可能かを示す時代から、何が信頼できるかを提供する時代へと移行しています。
今日 AI システムを構築する実務者にとって、教訓は明確です：Harness 層に投資してください。適切に設計された Harness は、現在のモデルプロバイダーよりも長持ちし、新しいユースケースに適応し、まだ想像もしていない機能の基盤を提供します。
MCPlato のアーキテクチャ—MCP ネイティブ、3 層分離、Local First—は、この基盤がどのように見えるかの一つのビジョンを表します。これは唯一の有効なアプローチではありませんが、今後数年間に成功する AI アーキテクチャを導く原則を示しています。
アーキテクチャ優先 AI の時代が始まりました。
よくある質問
Q：AI システムにおける Harness 層とは何ですか？
Harness 層（ツール層）は、ツールのカプセル化、実行オーケストレーション、検証と保護、メモリ管理を担当します。外部機能（ファイル、API、検索）を呼び出し可能な Tool/Skill にラップし、セキュリティサンドボックス、エラー処理、結果のフォーマットを含むモデル推論以外のすべての機能を処理します。
Q：MCPlato は Harness-Agent アーキテクチャをどのように実装していますか？
MCPlato は 3 層アーキテクチャを実装しています：Workspace 層は Workspace 管理と分離のため、Session 層はコンテキスト維持とメッセージ配信のため、Agent 層は ClawMode 自律実行のためです。ネイティブ MCP Host 機能、@Tool、Infographic、Browser、Image、Document ツールを含む組み込みツールセットを提供し、動的ツール検出とホットロードをサポートしています。
Q：MCP とは何で、なぜ重要なのですか？
MCP（Model Context Protocol）は、2024 年 11 月に Anthropic がリリースしたオープン標準です。AI アプリケーションと外部システム間の汎用インターフェースとして機能し、各データソース用に個別のコネクタを構築する必要を排除します。MCP は 3 つのコアプリミティブを定義します：Tools（実行可能関数）、Resources（データソース）、Prompts（インタラクションテンプレート）。
Q：なぜ Harness 層はモデル自体よりも重要なのですか？
ある閾値を超えると、モデル機能は商品化されます。Harness 層の信頼性、セキュリティ、ツール統合品質が、本番 AI システムの決定的要素となります。適切に設計された Harness は、安全で信頼性の高いツール使用を可能にし、基盤となるモデルに関係なく一貫したインターフェースを提供します。
Q：Harness-Agent アーキテクチャを設計するための重要な原則は何ですか？
重要な原則には以下が含まれます：（1）Harness と Agent の責任を明確に分離するレイヤード・ディカップリング、（2）MCP などのプロトコルの標準優先採用、（3）ランタイムツール登録のための動的検出、（4）サンドボックス実行によるセキュリティ分離、（5）長時間実行タスクのための状態永続化。
Q：MCPlato は Claude Code や Cursor とはどう違いますか？
MCPlato は以下により区別されます：（1）3 層アーキテクチャ対 2 層設計、（2）ネイティブ MCP Host 実装対アドオンサポート、（3）完全なローカルツールチェーンを持つ Local First、（4）組み込み画像、ドキュメント、Infographic、ブラウザツール、（5）3 層メモリアーキテクチャ、（6）ネイティブスケジューリング機能。
Q：AI システムアーキテクチャの将来の方向性は何ですか？
業界は単一 Agent からマルチ Agent 協調へ、モデル中心からアーキテクチャ中心の設計へ、そして独自の統合から MCP のような標準化されたプロトコルへと移行しています。将来のシステムは、信頼性、可観測性、拡張性を主要な設計目標として強調するでしょう。