[Mastra YouTube 解説] エージェントハーネスとは何か ― AIエージェントを「使いこなす」ための設計思想
Mastra の公式YouTubeチャンネルにアップされた動画を速報ベースでお伝えします。ただの文字起こしではなく、扱われているトピックの抽出と、トピックごとの要約をしています。速報性重視でAIの力を多分に使っているので、私自身の考察は少なめです。
動画情報
- URL: https://www.youtube.com/live/-ESSuPpJ5r8?si=mtM5zxx5_-U6eGlG
- 公開日: 2026年3月19日
- 長さ: 約70分
- 言語: 英語
- 登壇者: Alex Booker（Mastra DevEx Engineer）、Abby（Mastra CTO & 共同創業者）
概要
Mastraの毎週木曜ワークショップです。今回のテーマは「エージェントハーネス（Agent Harness）」。これが何なのか、なぜ今AIエージェント開発の最前線で注目されているのかを、MastraのCTO兼共同創業者であるAbbyが、理論・コンポーネント設計・実際のプロダクトデモを交えながら解説しています。
登壇したAbbyは、数週間にわたって社内でこのテーマを議論してきたと話します。「ハーネスエンジニアリング（Harness Engineering）」という言葉を使って新しいカテゴリーを定義しようとしている企業が増えてきており、混乱も生じています。フレームワークとの違いは何か、Mastraはどこに位置するのか。そういった疑問に正面から向き合いながら、実際に使えるプリミティブとしてのハーネスを紹介する1時間以上のセッションです。
フレームワークとハーネス ― スペクトルで考える
この概念を最初に整理したのはCrew AIのTony Kです。彼のブログポストを参照しながら、Abbyはエージェント開発のツールをスペクトルとして整理していきます。
ローコード（Raw Code）
スペクトルの左端にあるのが「ローコード」、つまりAPIコールを直接書いて何でも自分でやる方法です。最大の柔軟性を持ちますが、同じことを何度も繰り返すことになります。DRY原則（Don't Repeat Yourself）に従えば、最終的に誰もが同じような構造を書いて、それが抽象化されてライブラリやフレームワークになっていきます。フレームワークはそうして生まれました。
フレームワーク（Framework）
プログラマが同じパターンを繰り返し書くうちに「これは共通化できる」と気づいた結果が、フレームワークです。Mastra、Crew AI、LangChainがここに属します。フレームワークは「構造と抽象化のビルディングブロック」を提供します。各ブロックはモジュール式でスワップ可能。フレームワークを使えば、より速く、より遠くへ到達できます。
Mastraが掲げるのもまさにこれです。「開発者がエージェントを構築する際に、より速く遠くに到達できるようにする」。
ただしフレームワークも一定の意見（opinion）を持ちます。しかしその意見は「緩やかに（loosely held）」強く持っています。モジュール性と柔軟性を維持しなければならないためです。
ハーネス（Harness）
スペクトルの右に行くほど、意見は強くなります。ハーネスは完全にバッテリー同梱（batteries included）のシステムです。メモリ管理、ツール群、エージェントループ、そのすべてが組み込まれています。ユーザーは何もカスタマイズしなくてよいのです。ハーネスはすでに「最善の一手（best foot forward）」を出しています。
最も身近なハーネスの例として挙げられるのがClaude Codeです。何十億ドルもの収益を上げているコーディングエージェントで、基本的にカスタマイズ不要。エンジニアが作った意見を信頼できます。プラグインで多少のカスタマイズはできますが、バニラのまま使っている人がほとんどでしょう。もう一つがOpen Codeというオープンソースのハーネスで、プラグインシステムで非常にカスタマイズ可能です。
Abbyいわく「Claude Co-WorkもGUIを持つハーネスの例」。Claude CodeのハーネスをUIで包んで、非技術的なタスク（Google Driveの操作など）もこなせるようにしたものがCo-Work、あるいはそのオープンソース版のOpen Co-Workです。
| レイヤー | 例 | 特徴 |
|---|---|---|
| ローコード | ReactループのRaw API呼び出し | 最大の柔軟性、最大の手間 |
| フレームワーク | Mastra、Crew AI、LangChain | モジュール式、ある程度の意見 |
| ハーネス | Claude Code、Open Code、MRO Code | バッテリー同梱、強い意見 |
この区分はクリーンではないとAbbyも認めています。フレームワークがハーネスっぽい機能を持つこともあります（MastraもそうだとAbbyは言います）。Open Codeのようにソースが公開されて内部を変えられる「オープンなハーネス」もあります。ラインは曖昧です。
ユーザー向けかビルダー向けか
もう一つの整理軸は「誰のためのものか」です。
- フレームワークはビルダー向け。プリミティブを提供して、それらの組み合わせ方は自分で決めます
- ハーネスはユーザー向け。APIキーを追加すれば使い始められます。最高のデフォルト体験を出発点にします
もちろんどちらを使うかは状況によります。SaaSプロダクトを作っているなら、ユーザーにエージェントを触ってもらうためのハーネスが欲しいかもしれません。自社向けのコーディングエージェントなら、Claude Codeをそのまま使えばよいでしょう。ケースバイケースです。
「フレームワークとしてのMastra」を起点とした「ハーネス」の理解
Mastraはフレームワークとして、エージェントを「どう作るか」の枠組みを提供します。具体的には Agent クラス、createTool() API、メモリインターフェース、Workflowの定義構文といった「定義のためのAPI群」です。これらがMastraの「プリミティブ」であり、ビルダーはこれを使ってドメイン固有の実装を組み上げていきます。
つまり、3つの層をこう整理できます：
| 層 | 何をするか | 例 |
|---|---|---|
| Mastraが提供する | 定義APIと実行ランタイム |
Agentクラス、createTool()、メモリIF、Workflow構文 |
| ビルダーが実装する | ドメイン固有の組み合わせ | 特定用途のエージェント定義、ツール、記憶の中身 |
| ハーネスとして完成する | エンドユーザーが使える完成品 | Claude Code、MRO Code、Artifact |
ここで重要なのは、「ビルダーがエージェントもツールもメモリも自分で書く」という点です。Mastraが代わりに書いてくれるわけではありません。Mastraは「どう定義するか」の構文と「どう動かすか」の実行基盤を担います。ビルダーはそれを土台に、実際のドメインロジックを実装するのです。
ハーネスとは、このビルダーの作業が完了した状態を指します。エージェントは定義済み、ツールは揃っている、メモリの振る舞いも決まっている。エンドユーザーはAPIキーを入力するだけで使い始められます。最も深い設計判断はすでにビルダーが下しているのです。
もちろん、ハーネスは必ずしもMastraで作る必要はありません。Claude CodeもOpen CodeもMastraとは無関係に構築されたハーネスです。「Mastraで作られたもの＝ハーネス」ではなく、「エンドユーザー向けの完成系システム＝ハーネス」という定義が正確です。
なぜ今ハーネスが注目されるのか
モデルは着実に強力になっています。推論できる、コードを書ける、複雑な指示を処理できる。でも箱から出したままでは、モデルだけでは何もできないことがたくさんあります。
- 状態を維持できない。同じ会話であっても、セッションをまたぐ記憶は持っていません
- コードを実行できない。書いたコードが動くかどうかは別の話です
- リアルタイムの知識が持てない。訓練データには含まれていない最新情報にはアクセスできません
- 現実世界と対話する手段がない。ツールがなければAPIを叩くことも、ファイルを操作することもできません
- 環境のセットアップが必要。コードを動かす場所を用意しなければなりません
ハーネスはモデルの「外側」にある、これらすべてを引き受ける存在です。
ハーネスが担当するもの
├── 状態管理（モデルが忘れないために）
├── ツール群（現実世界と対話するために）
├── メモリ（長期セッションを続けるために）
├── コントロールフロー（適切な次の一手を選ぶために）
└── 環境（安全にコードを実行するために）
これはデータベースだけを管理すればよかった時代ではなくなったことに似ています。Webアプリを作るだけでもキャッシュ、認証、ロギング、メッセージキュー、CDN……数え切れない関心事を扱う必要があります。AIエージェントを使ったアプリケーションも同様に、モデル以外の多くのことを考えなければなりません。
Mastraはこれらをカバーするプリミティブをすでに持っていました。だからハーネスクラスを構築する段階になっても、ゼロから発明する必要はありませんでした。「すでにピースが揃っていた」とAbbyは言います。
ハーネスを構成する要素
ここからが本題です。Abbyは「ハーネスのコンポーネント」として以下の多層構造を示しています。
1. メインエージェント（動的なシステムプロンプト）
ハーネスの中心にはメインエージェントがあります。そして、このエージェントが「動的（dynamic）」であることがポイントです。
コーディングエージェントのようなハーネスでは、システムプロンプトは単純な文字列ではありません。実行時に複数のレイヤーから組み立てられます：
- 環境コンテキスト：今エージェントがいるコードベース、ファイル構造など
- モードプロンプト：ビルドモードなら「ビルドモードではこう振る舞え」という指示
- 利用可能なツールとその説明：モードに応じてアクセスできるツールが変わり、その説明も変わります
- タスクリスト：今進行中のタスクが含まれます
- コンテキストファイル：agents.md、claude.md、memory.mdなど、状況を説明するドキュメント
- アクティベートされたスキル：今アクティブなスキルの内容
静的なプロンプトも作れますが、動的な環境では機能しません。これらは「方向付け（orientation）」の役割を持ちます。エージェントが今まさにやるべきことに向けて、正しい方向を示すのです。
2. スキル（Skills）と動的アクティベーション
スキルについて、Abbyは「アクティベート（activate）」という動詞が気に入っていると話します。
スキルがアクティベートされると、動的にシステムプロンプトに追加されます。エージェントがスキルを取得したとたん、それを使えるようになります。まるでMatrixのNeoが「カンフーを入手した瞬間に使えるようになる」感覚です。
逆に言えば、スキルは必要がなければ非アクティブ化できます。システムプロンプトから取り除かれ、不要なトークンを消費しません。
スキルが「ファイル」として存在することが、ファイルシステムの重要性を生み出しました。スキルをエージェントに届けるには、パスに置く必要があります。スキルにはディレクトリ構造があり、references/、scripts/、SKILL.mdといったファイルで構成されます。
「スキルがファイルとして生まれた瞬間に、エージェントにファイルシステムが必要になった。コーディングのユースケースだけでなく、あらゆるエージェントにとって。スキルが必要ならファイルシステムが必要だ」
スキルの動的性はさらに進みます。スキル検索API（skill search API）やskills.shを使えば、エージェントがスキルを自分で探してダウンロードし、アクティベートすることができます。Abbyが紹介した「スキルクリエイター（skill creator）」というスキルは、エージェントがスキルを自ら作成できるようにするものです。これは、タスクを実行しながらエージェントが自分自身の能力を拡張していく方向性を示しています。
3. ワークスペース（Workspace）
エージェントにはスクラッチパッド、つまり「作業場所」が必要です。Mastraでは、ファイルシステム・サンドボックス・ツール・スキルを束ねたものを「ワークスペース（Workspace）」と呼びます。
ファイルシステムは、コードを読み書きし、スキルを保存し、成果物を扱うための場所です。ローカルのファイルシステムを使う方法もあります。
サンドボックスは、セキュリティの観点から重要です。エージェントが書いたコードは「信頼できないコード（untrusted code）」です。自分が書いたコードなら信頼できるかもしれませんが、エージェントが書いたコードは自分の書いたものではありません。「rm -rf database」のようなことをしてしまうかもしれません（笑）。だからサンドボックスを使います。MastraはE2BやDaytonaのようなクラウドサンドボックスプロバイダーとの連携をサポートしています。
4. メモリとコンテキスト管理
会話が続くにつれてコンテキストは成長します。「コンテキストロット（context rot）」という言葉をAbbyは使います。コンテキストウィンドウがいっぱいになるほど、エージェントのパフォーマンスが落ちていくという問題です。
Opus 4.6やCodexが100万トークンものコンテキストウィンドウを提供しているとはいえ、Abbyはこう言います。
「コンテキストウィンドウが埋まるほど、エージェントはバカになる。そう感じる。コンパクション後は、ロボトミー（脳手術）を受けたような状態になる」
この問題に対してみんなはどう対処しているのでしょうか。
コンパクション（Compaction）
Claude CodeやOpen Codeで使われているアプローチです。トークン数が一定のしきい値に達すると、これまでの会話の要約を作成して、エージェントに渡します。Claude Codeでは「死のドクロマーク」が表示される瞬間がコンパクションのタイミングです。
しかし、コンパクションには問題があります。「要約（summary）」には情報損失が伴うのです（ロッシーな変換）。100万トークンの会話を要約すると、重要な指示が消えてしまうことがあります。有名な事例として、コンパクションによって「メールを削除しないで」というユーザーの指示がサマリーから落とされ、エージェントが全メールを削除してしまったことがありました。
Observational Memory（観測的メモリ）
Mastraのアプローチです。「Friends don't let friends compact（友達はコンパクションをさせない）」という標語のもと、コンパクションの代わりに「圧縮（compression）」を行います。
仕組みは3エージェントシステムです：
┌─────────────────────────────────────────┐
│ Observational Memory │
│ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ Actor │ │ Observation │ │
│ │ (main) │────▶│ Agent │ │
│ │ agent │ │ (observes │ │
│ └──────────┘ │ context) │ │
│ │ └──────┬───────┘ │
│ │ │ しきい値 │
│ │ ▼ │
│ │ ┌──────────────┐ │
│ │ │ Reflection │ │
│ └────────▶│ Agent │ │
│ │ (further │ │
│ │ compress) │ │
│ └──────────────┘ │
└─────────────────────────────────────────┘
- **アクター（メインエージェント）**がタスクを実行します
- 観測エージェントがバックグラウンドでコンテキストウィンドウを見張っています
- トークン数がしきい値に達すると、会話を「イベントベースの観察（event-based observations）」に変換します
- 以前のメッセージは観察に置き換えられます（トークン数が大幅に削減）
- 観察自体がまた別のしきい値に達すると、リフレクションエージェントが起動してさらに圧縮します
コンパクションとの決定的な違いは何でしょうか。コンパクションが「全体のサマリー」を作るのに対して、Observational Memoryは「イベントベースの観察」にリライトします。ツールコールがあったこと、何を使ったか、エージェントが推論した内容を短い形式で記録します。ツールコールの詳細な引数や膨大なツール結果は、再コール時に役立たないものを除去します。
Alexがわかりやすくたとえを出しました：
「要は、チャット履歴全体を一通り見ながら最適化する編集者のようなものですね。『このメール削除禁止の指示は残す』、『この長いメッセージは重要な部分だけ残す』、『このツールコール結果は最終的に使わなかったから削除』という感じで、必要なものだけ残した最適化されたチャット履歴を作る」
また時間軸での推論（temporal reasoning）もポイントです。何がいつ起きたかを把握することが、良い応答を生成するうえで重要になります。観察はイベントベースなので、時系列がわかります。コンパクションのサマリーでは、時系列が失われやすいのです。
Abbyの実体験：「私は1ヶ月半、同じセッションの中で作業し続けています。ワークツリーを使わない実験として。ブランチを切り替えながらも同じコンテキストを持ち続けています。リコールの精度はかなり良好です。みんながこれをやれとは言いませんが」
5. モード（Modes）
モードは「同じエージェントに異なる振る舞いをさせる」仕組みです。Abbyはこんな比喩を使います。
「エージェントをスキゾ（多重人格）にする。同じエージェントでも、ビルドモードでは一つの個性、プランモードでは別の個性。大学時代を思い出してほしい。私には勉強モードがあった。でも金曜の夜にパーティモードになる。同じ人間だけど、システムプロンプトとやる気（ambition）が変わっている」
モードは主に「利用可能なプロンプト」と「利用可能なツール」によって定義されます：
プランモード（Plan Mode）
- 計画の設計と承認に特化
- 利用可能なツールはすべてリードオンリー（コードベース探索、計画提出など）
- 「この計画で進めていいですか？」という承認ステップが重要
ビルドモード（Build Mode）
- 計画を実行するフェーズ
- 書き込み系ツール（ファイル編集、コード実行）も利用可能
- 推論ベースで実行していく
- Opusのようなパワフルなモデルをアサインすることもよい
ファストモード（Fast Mode）
- スピード優先、詳細な会話はいらない
- Haiku、GLMなど高速なモデルを使う
- とにかく動けばいい、細かいことは後
トリアージモード（Triage Mode）
- GitHubイシューを確認してアサインする
- チームの知識と役割分担に応じてカスタマイズする
レビューモード（Review Mode）
- マージ前のコードレビューに特化
Alexより: 「Claude Codeのプランモードとビルドモードとの対応がよくわかりました。でもここで全く新しいトリアージモードを作れるっていうのが面白い。これは実際に解決する問題があるということですよね」
Abbyが大切にしているのは「モードはどんな内容でも自分でデザインできる」という点です。万人共通のトリアージエージェントはありません。チームのコードに詳しいかどうか、誰がどの領域の専門家かによって、最適なトリアージモードは変わってくるのです。
6. ステアリング（Steering）― 人間が制御に参加する
「ハーネスは訊くべきであり、ただ行動してはいけない（The harness should ask, not just act）」
Mastraのエンジニア、Tylerの言葉です。ハーネスの重要なUX設計原則として、人間が制御に参加できる仕組みを組み込む必要があります。
プラン承認（Plan Approval）
エージェントが計画を提示し、人間が承認・拒否・変更を指示できます。「Claudeっぽいプランモードビュー」として多くの人が見慣れているものです。
ツール承認（Tool Approval）
ツールが実行される前に確認を求めます。コマンドの内容が表示され、「承認（approve）」「拒否（deny）」「常時承認（always approve）」から選べます。
ミッドストリームステアリング（Midstream Steering）
実行中に割り込んで方向を修正できます。Abbyはよくこれをやるそうです。
「コーディングエージェントが明らかに間違ったことをしているとわかるとき、Ctrl+Cで止めて、『何やってんだよ（大文字で）』と入力して、正しい方向に向けて続けさせる。トークンと時間を無駄にしたくないから」
YOLOモード（YOLO Mode）
逆に「何でも自動でやってくれ」という全自動モードです。探索タスクなど、人間の確認が不要なときに便利です。
ユーザーメッセージキュー
エージェントが絶好調で動いているとき、止めたくないが次のアイデアは忘れたくない。そんなときにキューに溜めておけます。
7. イベントとストリーミング
ハーネスのループは何千もの手順を実行します。数日単位で動き続けることもあります。テレビを見ながらエージェントが自律的に作業しているとき、何が起きているかを把握する手段が必要です。
イベントはハーネスの状態変化を外部に通知します。ツールコール、モード変更、モデル変更、観測メモリのしきい値到達……これらが全てイベントになります。このイベントストリームを使って、TUI（ターミナルUI）やReactアプリなどのUXを構築できます。
ストリーミングも重要なUX要素です：
- ストリームを中断できること
- 再開できること
- 耐障害性のあるストリーム（durable streams）
Abbyより 「個人的にはWebSocketsが戻ってくると思っています。言っておきます、これが私の予測。マルチプレイヤーエージェントや購読型のストリームを考えると、それが自然な選択になると思う」
8. ツールポリシーとコスト管理
特定のツールは：
- 常時実行可能（always allow）：リードオンリーな操作など
- 実行前に確認が必要（require confirmation）：ファイル書き込みやコード実行など
- 常に拒否（deny）：特定のシステム操作など
36時間動き続けるエージェントのコストは馬鹿になりません。コストトラッキングもハーネスに組み込まれるべき機能です。
ハートビート（Heartbeat）― コンテキスト認識型のcron
後半でAlexが「ハートビートって何ですか？」と質問しました。Open Clawが実装して話題になったものです。
ハートビートとは「コンテキスト認識型のcron（Context-aware Cron）」です。
通常のcronジョブはシンプルなスケジュール実行です。しかしハートビートは違います：
- プロンプトがcronとして機能します
- インターバル（実行間隔）を設定します
- セッションのコンテキストを持っています
例を挙げると：
「友達に結婚式に招待されたか気になっているけど、まだ招待状が届いていない。5分ごとにGmailを確認して、招待が届いたら教えて」
これをハートビートとして設定すると：
- 5分ごとに「Gmailで招待状を確認するプロンプト」が実行されます
- まだ届いていない場合は、コンテキストに「まだ届いていない」という記録を残します
- 5分後にまた確認
- ... 届いたらユーザーに通知
ハートビートの出力はWhatsAppやTelegramなどのチャンネルにストリームすることもできます。
Mastraにもこの機能を追加予定で、ハーネス以外でも単独で使えるようになる予定だといいます。また、ワークフロー経由の定期タスク（crons）も追加予定です。
サブエージェントとスキルの使い分け
「サブエージェントとスキルの違いは何ですか？」という質問がチャットに来ました。Abbyの答えは明確でした。
サブエージェントは集中した特定のタスクに使います。MRO Codeで最もよく使うサブエージェントは「explore agent（探索エージェント）」です。コードベースを探索したいとき、10個の探索エージェントを立ち上げてバックグラウンドで並列に実行させます。それぞれが独立したループを持ち、メインエージェントのループには影響しません。まるで「World of Warcraftで自分の軍隊を送り込む」感覚です。
スキルはメインエージェント自体を方向付けるためのものです。スキルをアクティベートすることで、メインエージェントの能力と行動方針が変わります。
| サブエージェント | スキル | |
|---|---|---|
| 目的 | 集中した特定タスクの実行 | メインエージェントの方向付け |
| 動作 | 独立したループで動作 | システムプロンプトに組み込まれる |
| 例 | 探索エージェント、計画エージェント、実行エージェント | PR-reviewスキル、コードスタイルスキル |
| アナロジー | 軍隊を送り込む | スキルを習得する |
具体的なツール設計 ― バッシュ vs 特化型ツール
ワークショップ中、面白い議論となったのが「エージェントへのツールの与え方」についてです。
最近よく耳にする議論があります：
- 「bashを与えてしまえば、後は自分でよいbashコマンドを考えてくれる」
- 「TypeScriptを与えれば、パッケージをimportして何でもできる」
- つまり「コードモード（code mode）=最強説」です
MRO Codeが採用しているのはこれとは逆のアプローチ：**目的特化型ツール（purpose-built tools）**を作ることです。
LSP（Language Server Protocol）の活用、regexサーチ、grep、editsなど、特定の目的に絞ったツールを組み込んでいます。ユーザーはそれらを意識する必要がありません。エージェントも「どうやってファイル内のテキストを検索するか」をゼロから考える必要がありません。
Abbyいわく：
「同じ操作を一度書いたなら、それをツール化すればいい。毎回また書かせる必要はない」
一方で「コードモードは探索タスクには本当に便利」とも認めています。動作確認のためにPythonをさっと書いて実行するのは強力です。どちらが優れているというわけではなく、用途によって使い分けるべきでしょう。
Artifact Engineeringの例では、電気工学設計ツールのハーネスには「回路設計のためのツール」が組み込まれています。「grep」や「find」ではなく、回路設計に特化したツールです。ハーネスのツール設定は、そのハーネスのドメインを強く反映するのです。
プロダクションレベルのハーネスが持つべきもの
Abbyはまとめとして、本番利用に耐えうるハーネスが備えるべき要素を列挙しました：
- ステートフルで再開可能な実行（state and resumability）
- 動的なシステムプロンプト（モードに応じて動態的に組み立てられる）
- ワークスペース（ファイルシステム＋セキュアなサンドボックス）
- メモリシステム（コンテキストロット対策）
- モード（エージェントの振る舞いを状況に応じて切り替える）
- ヒューマン・イン・ザ・ループ（インタラプト、プラン承認、ツール承認）
- イベントとストリーミング（外部からの観察と制御）
- ツールポリシー（ツールごとの許可設定）
- コストトラッキング（36時間動かし続けるためのコスト可視化）
- マルチモデル・マルチモーダル対応（テキストだけでなく音声や画像も）
3つのデモ ― ハーネスは今すでに動いている
理論の後、Abbyは3つのデモを見せました。いずれもMastraのハーネスクラスを使っています。
デモ①：Superset ― コーディングエージェントのオーケストレーター
Supersetはコーディングエージェントのオーケストレーターで、最近MRO Codeのハーネスを使ってチャットビューを追加しました。
デモでは「ありがとうスライドを最後に追加するのを忘れた、手伝ってくれますか？」と入力。エージェントはすぐに「どのプロジェクトですか？」と質問を返してきました。これはハーネスのコアUXです。人間に確認を取ってから進みます。答えを送ると、タスクリストを生成し、ファイルを順番に編集していきます。見慣れたClaude Code風のUXですが、その裏でMastraのハーネスが動いています。
デモ②：Artifact ― 電気工学設計ツール
ArtifactはHermesやTeslaが利用する、電気エンジニア向けの設計ツールです。コーディングエージェントとは全く異なるドメインのハーネスです。
「衛星を設計してください」と入力（Abby自身は電気工学の知識がありません）。エージェントはすぐに「CubeSatにしますか、小型衛星にしますか、フルサイズ宇宙船にしますか？」と選択肢を返してきました。「大きく行く。コアシステムのみ」と返答し、YOLOモードで承認。すると、サブシステムの設計が始まり、ライブラリアイテム（ソーラーパネルアレイ、バッテリーパック……）が生成され、ダイアグラムが構築されていきました。
「これがコーディングエージェントじゃないというのが大切なんです。同じ構造で、ドメインが全く違う」
エージェントが持つツール群は、コードを書くものではなく、回路ダイアグラムを描画するためのものです。同じハーネスの設計思想が、全く異なるドメインで機能しています。
デモ③：MRO Code ― Mastraのオープンソースハーネス
Mastra自身が社内で使っているコーディングエージェントのTUI（ターミナルUI）版です。Observational Memoryが画面に見えるかたちで組み込まれています。
- メッセージしきい値とリフレクションしきい値の2つのゲージが画面に表示
- 「このワークショップのコードベースを深く調査して、どう構築されているか、著者は誰か、スライドの品質について教えて」と入力
- 複数のサブエージェントが並列でコードベースを探索し始める様子がリアルタイムで見えます
- OMの設定を5Kプリセットに変更すると、数メッセージ後にトークン数が2Kに戻りました
- 「死のドクロ」表示なし、バックグラウンドで圧縮が完了していました
エージェントはワークショップの著者（Shane+Abby、Daniel+Alex、Abby+Alex……）を正確に見つけ出し、スライドの品質について「真摯な仕事（genuinely impressive work）」と評価しました。
コーディングエージェントの先へ
ワークショップの最後、Abbyは「コーディングエージェントがすべてではない」という考えを強調しました。
コーダーがハーネスを作り、コーダーが使うから、コーディングエージェントが出発点になるのは自然なことでした。でも、これは始まりにすぎません。
- 大手会計事務所向けのハーネス
- 投資分析向けのハーネス
- 都市計画向けのハーネス
- 医療診断向けのハーネス
すべての業界に、その業界特有のワークフローとツールを組み込んだハーネスが登場するでしょう。Artifactのデモはその方向性の一端を示しています。
「Claude Codeはクローズドですが、ハーネスは自分で構築できます。どう動くかを理解した上で。私はみんなに、もっと『Co-Work系』のハーネスを作ってほしい。コーディングエージェントだけが最終目標ではないはずです」
関連リンク
- Mastra公式サイト
- MRO Code（Mastraオープンソースコーディングエージェント）
- Superset（コーディングエージェントオーケストレーター）
- Artifact（電気工学設計ツール）
- Tony K（Crew AI）のハーネスに関するブログポスト
- Open Code（オープンソースコーディングハーネス）
- Mastra Observational Memoryワークショップ
- 次回ワークショップ：Multi-Agent Networks（Lennard & Grayson担当）
要点まとめ
- ハーネスはフレームワークより右にある。ローコード → フレームワーク → ハーネスというスペクトルの中で、ハーネスは最も意見が強く、完全なシステムを提供する
- Claude Codeはハーネスの代表例。プラグインでカスタマイズできるが、ほとんどの人はそのまま使う
- ハーネスにはメインエージェント、動的システムプロンプト、メモリ、ワークスペース、モード、ステアリングが必要
- コンテキストロットは実在する。Observational Memoryはコンパクションとはことなるアプローチで、イベントベースの観察にコンテキストを変換する
- モードは「エージェントのシステムプロンプトと能力を切り替える」もの。別のエージェントを作るわけではない
- スキルは動的にアクティベートされる。必要な時だけシステムプロンプトに追加され、不要になれば非アクティブ化される
- ハーネスはコーディングエージェントだけではない。電気工学設計ツール、会計、医療など、あらゆるドメインに応用できる
- ハートビートはコンテキスト認識型のcron。定期的にプロンプトを実行して、セッションの文脈の中でアクションをとる
Discussion