エージェント

「ハーネスエンジニアリング」という言葉がAIエージェント界隈でバズワード化し、意味の希薄化が起きている。watany氏のZenn記事「AIエージェントの"ハーネス"に関わる混乱と私見」は、この混乱を「内側のハーネス」と「外側のハーネス」という軸で整理している。本記事は、その整理を元に「ハーネス」という言葉の意味的な分裂を読み解く。 内側のハーネス（Internal Harness） 開発者・プラットフォーム視点の定義。 LangChain: 「エージェント = モデル + ハーネス」という等式を掲げ、自社をハーネス構築のプラットフォームとして位置づける Anthropic: 長時間実行されるLLM処理の仕組みとして定義。ステートレスなモデル呼び出し間でセットアップスクリプトやGitの履歴などのコンテキストを引き継ぐ機構を指す。生成Agentと評価Agentからなる二段階のマルチエージェント構成も含む 内側のハーネスの議論はベンダーロックインを促す傾向があり、プラットフォームとしての優位性を訴求する文脈で使われやすい。 外側のハーネス（External Harness） ユーザー・実践者視点の定義。 Mitchell Hashimoto: 「AIエージェントが同じミスを繰り返さないように設計する」という実践的なアプローチ。開発者の日常的な課題に根ざした定義 OpenAI: メンテナブルで読みやすいエージェント出力の設計を重視し、将来の実行エージェントが参照できる保守可能な成果物の生成を重視する 外側のハーネスはベストプラクティスの共有が主眼で、特定プラットフォームへの依存を前提としない。 なぜ混乱するのか Takuto Wada（@t_wada）氏はこの記事を紹介し、同じ言葉なのにスコープが違うのは言う側のポジションで意味合いがズレているのが理由だと指摘している。 ベンダーは「ハーネス」を自社製品の文脈で語り、実践者は「ハーネス」を運用上の問題解決として語る。どちらも正しい文脈を持ちながら、同一の言葉が異なる聴衆に向けて発信されている。 まとめ 「ハーネス」という言葉を聞いたとき、それが誰の視点からの発言かを意識するだけで、議論の意図がずっと明確になる。 プラットフォーム・フレームワーク文脈 → 内側のハーネス（統合基盤としての役割） 実践・運用文脈 → 外側のハーネス（エラー再発防止・出力品質の設計） AIエージェント開発が加速する中、用語の解像度を上げることは技術コミュニティ全体の生産性に直結する。watany氏の整理は、この問題に対して実践的な視点を提供している。 参考: AIエージェントの"ハーネス"に関わる混乱と私見 — watany (Zenn) t_wada氏のポスト (X)

Claude Max のレート制限問題と現実的な解決策 Claude Max に月 $200 を投じて、たった3時間で使い切ってしまった——そんな体験談がきっかけで生まれた、実用的な AI インフラ構成が話題になっています。 解決策はシンプルです。$599 の Mac Mini に5つのローカルモデル（合計約 350 億パラメーター）を用意し、Claude がレート制限に達したら自動でローカルモデルに切り替えるというものです。 構成の概要 この構成で実現していること： メール整理の自動化: エージェントがメールを分類・返信ドラフトを生成 コンテキスト圧縮: 長い会話履歴を自動的に要約して継続利用 深夜の継続稼働: 就寝中もエージェントが動き続ける 自動フォールバック: 深夜4時に Claude がレート制限に達すると、ローカルモデルが自動で引き継ぎ コスト比較が圧倒的です。同じ業務を3人のエンジニアに依頼すると月 $15,000。これが Mac Mini 一台 + ローカルモデルで代替できるとするなら、ROI は明白です。 なぜ Mac Mini が選ばれるのか Apple Silicon 搭載の Mac Mini は、ローカル LLM の実行環境として優れた特性を持っています： 統合メモリ（Unified Memory）: CPU と GPU が同一メモリを共有するため、大容量モデルのロードが高速 省電力: 24時間稼働でも電気代が安い MLX フレームワーク: Apple が開発した機械学習フレームワークで、Apple Silicon 上の推論速度が大幅に向上 静音設計: 自宅・オフィスでも気にならない 実際に Gemma 4、Qwen 3、Mistral などの 350 億パラメーター級モデルを複数搭載し、タスクに応じて使い分けることができます。 ...

概要 LangChain 創設者 Harrison Chase が提唱する概念。AI エージェントのメモリ（長期記憶）はハーネスの設計と不可分であり、クローズドなハーネスを使うことで将来的な移行が困難になるリスクを指す。ハーネスとメモリを「分離できるプラグイン」ではなく「車と運転」のように一体的なものと捉える。 メモリの4層構造 エージェントのメモリは実際には4層に分かれており、それぞれがハーネスの実装に深く依存する。 層 実体 ハーネス依存の理由 第1層 コンテキストウィンドウ内のメッセージ履歴 構成方法でモデルの応答が変わる 第2層 コンパクション（会話の要約圧縮） 何を残し何を捨てるかで「記憶の質」が変わる 第3層 永続ファイル・データベース（長期メモリ） エージェントの「人格」を形成する 第4層 設定・スキルのロード方式 エージェントの能力を規定する ロックインの3段階 1. ステートフル API のロックイン OpenAI の Responses API や Anthropic のサーバーサイドコンパクションのように、状態をプロバイダーのサーバーに保存する方式では、モデルを切り替えて以前のスレッドを再開できなくなる。 2. クローズドソースハーネスの不透明性 Claude Agent SDK のように内部でクローズドソースのコードを使うハーネスでは、メモリとの相互作用が不透明で、別のハーネスへの移行が困難になる。 3. API の背後に隠されたメモリ ハーネス全体（長期メモリを含む）が API の背後に置かれるケース。Claude Managed Agents が例として挙げられており、メモリの所有権も可視性もゼロになる。 コンパクション方式の違い 各ハーネスでのコンパクション実装の違いが移植性に影響する: ハーネス コンパクション方式 移植性 Claude Code 会話要約をシステムメッセージとして挿入 高（ローカルファイル） OpenAI Codex 暗号化コンパクションサマリー生成 低（OpenAI 以外で復号不可） Claude Managed Agents サーバーサイドで状態保持 低（外部からアクセス不可） Letta / Deep Agents オープン標準での保存 高（移行可能） ロックイン回避のための実践 メモリの所在を把握する: 自分のエージェントのメモリがどこに保存され、誰がコントロールしているかを確認する エクスポート可能な設計を選ぶ: メモリのエクスポート・インポートが可能なハーネスを優先する ステートフル API 依存を最小化する: サーバーサイドのコンパクションや状態管理に過度に依存しない オープン標準を採用する: agents.md などのオープン標準規格に対応したハーネスを検討する メモリがロックインの源泉になる理由 メモリによりエージェントはユーザーとの対話を通じて改善される ユーザーごとのパーソナライズが可能になり、データフライホイールが構築される メモリがなければ同じツールにアクセスできる誰もがエージェントを複製できる メモリがあれば、ユーザーインタラクションと嗜好の独自データセットが蓄積される 関連ページ ハーネスエンジニアリング — ハーネス設計の全体像 Claude Managed Agents — クラウド側でメモリを管理するアプローチ AI エージェント — エージェント基盤の概念 MemPalace — ローカルメモリシステムの実装例 ソース記事 エージェントハーネスとメモリのロックイン問題 — 2026-04-12 Claude Managed Agents: パブリックベータ公開 — 2026-04-10 Anthropic vs OpenAI：Harness 戦略はなぜ真逆なのか — 2026-04-13

完全オープンソースで動く AI 同僚ツール「Rowboat」が注目を集めている。音声制御、MCP ツール連携、バックグラウンドエージェントなど、有料 AI アシスタントサービスに相当する機能を、データをローカルに保ったまま利用できる点が特徴だ。 Rowboat とは Rowboat（rowboatlabs/rowboat）は「Open-source AI coworker, with memory」を謳う AI 同僚ツール。GitHub スター数は 12,000 以上（2026年4月時点）に達しており、急速に注目が高まっている。 主な特徴は以下の通り。 100% ローカル動作 — データが外部に出ない 音声制御 — リアルなアシスタントのように話しかけられる 任意の LLM に接続可能 — Claude、GPT-4 系などを選択できる MCP ツール + Obsidian ブレイン — ナレッジグラフと外部ツールを組み合わせた記憶管理 バックグラウンド自律エージェント — 裏側で自律的にタスクをこなすエージェント群 知識グラフの自動構築 — 会話・作業履歴から知識を蓄積 ローカルで動く AI 同僚のインパクト これまでの AI アシスタントの多くはクラウド型であり、プロンプト・ドキュメントなどのデータが外部サーバーに送信される仕組みだった。Rowboat はすべてローカルで処理するため、機密情報を扱う業務でも安心して利用できる。 また、任意の LLM を接続できる柔軟性も魅力だ。Anthropic の Claude を接続しながら推論はローカルで完結させるといった構成も可能で、API コストの制御がしやすい。 MCP ツール連携と Obsidian ブレイン Rowboat が対応している MCP（Model Context Protocol）は、AI ツールが外部サービスや情報源と標準化されたインターフェースで通信するためのプロトコルだ。これにより、ファイルシステム、Web 検索、カレンダーなど様々なツールをエージェントに組み込める。 ...

LangChain の創設者 Harrison Chase が 2026年4月11日に公開した記事「Your harness, your memory」を読んだ。AI エージェント開発におけるハーネス（harness）とメモリの密接な関係、そしてクローズドなハーネスがもたらすロックインの危険性を指摘する内容だ。本記事ではその要点を整理し、エージェント開発者が考慮すべきポイントを解説する。 エージェントハーネスとは何か エージェントハーネスとは、LLM がツールやデータソースとやり取りするための「足場」を提供するシステムだ。テストハーネスがテスト実行環境を支える外枠であるように、エージェントハーネスはエージェントの実行環境を支える外枠を指す。Chase は以下のような進化の流れを示している。 RAG チェーン時代（2023年〜）: ChatGPT 登場直後、シンプルな検索拡張生成（LangChain） 複雑なフロー時代: モデルの改善に伴い、より複雑なワークフローが可能に（LangGraph） エージェントハーネス時代（現在）: モデルの大幅な性能向上により、新しい種類の足場が登場 具体的なエージェントハーネスの例として、Claude Code、Deep Agents、Pi（OpenClaw を駆動）、OpenCode、Codex、Letta Code などが挙げられている。 Chase は「モデルがハーネスの機能を吸収していく」という意見に反論する。2023年に必要だった足場の多くは不要になったが、それに代わる新しい種類の足場が登場している。エージェントは定義上、LLM がツールやデータとやり取りするものであり、その相互作用を仲介するシステムは常に必要だ。Chase はその根拠として、Claude Code のソースコードが51万2000行に及ぶ規模を挙げている。 エージェントハーネスとメモリが切り離せない理由 Chase は Letta の CTO Sarah Wooders のブログ「memory isn’t a plugin (it’s the harness)」を引用し、ハーネスとメモリは不可分だと主張する。 メモリをエージェントハーネスにプラグインしてほしいと頼むのは、運転を車にプラグインしてほしいと頼むようなものだ。コンテキストの管理、すなわちメモリの管理は、エージェントハーネスの中核的な能力であり責任だ。 メモリはコンテキストの一形態に過ぎない。ハーネスが管理するコンテキストには以下が含まれる。 短期メモリ: 会話内のメッセージ、大きなツール呼び出し結果 長期メモリ: セッションをまたぐ記憶（クロスセッションメモリ） 設定ファイル: AGENTS.md や CLAUDE.md のロード方法 スキルメタデータ: エージェントへの提示方法 コンパクション（要約による圧縮）: 長い会話履歴を要約して短縮する際、何が残り、何が失われるか これらすべてがハーネスの設計に依存しており、メモリを独立したサービスとして切り離すことは現時点では現実的ではない。 エージェントにおける「メモリ」の実体 Chase の記事では「メモリ」が抽象的に語られているが、その実体は大きく4つの層に分けられる。それぞれの層がなぜハーネスと切り離せないのかを具体的に見ていこう。 第1層: コンテキストウィンドウ内のメッセージ履歴 最も基本的なメモリの実体は、LLM に渡される会話メッセージの配列だ。ユーザーの発言、アシスタントの応答、ツール呼び出しの結果がすべてこの配列に格納される。 ...

Anthropic が 2026 年 4 月 10 日に公開したブログ記事「Multi-agent coordination patterns: Five approaches and when to use them」では、複数のAIエージェントを協調させるための 5 つのパターンが紹介されています。 それぞれのパターンを整理してみます。 1. Generator-Verifier（生成・検証） 概要: 一方のエージェントが出力を生成し、もう一方のエージェントが明示的な基準に照らして検証します。検証が失敗した場合、フィードバックが生成エージェントに戻り、条件を満たすか最大反復回数に達するまでループします。 向いているケース: コード生成＋テスト実行のような、品質が最重要でかつ評価基準を明確に定義できるタスク。 注意点: 検証の質は定義した基準の質に完全に依存します。評価基準の設計を省略すると、「品質管理をしているという幻想」だけが残ってしまいます。 2. Orchestrator-Subagent（オーケストレーター・サブエージェント） 概要: リーダー役のエージェントが作業を計画し、専門化されたサブエージェントに明確な境界付きのタスクを委任します。サブエージェントは作業を実行し、結果をオーケストレーターに返します。オーケストレーターは各結果を統合して最終的なアウトプットを生成します。 向いているケース: セキュリティ・テストカバレッジ・スタイルをそれぞれ別エージェントが担当するコードレビューのように、サブタスクの依存関係が少ない明確なタスク分解ができる場合。 注意点: サブエージェント同士で発見した情報に依存関係が生じると、オーケストレーターが「情報のボトルネック」になります。また、明示的に並列化しない限り、サブエージェントは逐次実行されるためスループットが制限されます。 推奨: Anthropic は「大半のユースケースでまず試すべきパターン」としてこのパターンを位置づけています。最も問題の幅広さをカバーしつつ、調整のオーバーヘッドが最小限です。 3. Agent Teams（エージェントチーム） 概要: コーディネーターがキューからタスクを取得する 永続的な ワーカーエージェントを生成します。ワーカーは複数のステップにわたって自律的に作業し、担当コンポーネントのドメイン知識を蓄積します。 向いているケース: 大規模コードベースのサービス移行のように、エージェントが担当範囲に習熟しながら並列で長期間実行するタスク。 Orchestrator-Subagent との違い: サブエージェントが単発タスクで消えるのに対し、チームワーカーはアサインをまたいで生存し続けるため、ドメイン知識が蓄積される。 注意点: タスク間の独立性が必要で、エージェント同士が中間結果を共有しにくい。タスク時間がばらつく場合、完了検知が難しくなります。 4. Message Bus（メッセージバス） 概要: エージェントが共有ルーターを介してトピックをパブリッシュ・サブスクライブします。ルーターはマッチングメッセージを配信しますが、実行順序はあらかじめ決まっていません。 向いているケース: セキュリティアラートが多段階の調査を動的にトリガーするようなイベント駆動パイプラインで、どのエージェントが関与するかがリアルタイムに決まる場合。 注意点: イベントが複数エージェントを連鎖的にトリガーすると、トレーサビリティが困難になります。ルーターがイベントを誤分類すると、エラーが静かに発生します。 5. Shared State（共有ステート） 概要: 中央コーディネーターを置かず、エージェントが永続ストレージに直接読み書きします。エージェントは他エージェントの発見をリアルタイムで参照しながら協調的な知識を蓄積します。 向いているケース: 一方の調査結果が即座に他方のエージェントの探索方向に影響する、協調型のリサーチタスク。単一障害点がなくなるというメリットもあります。 注意点: 収束条件がないとエージェントが際限なく反応し合い、トークンを無駄に消費します。「時間予算・収束閾値・終了エージェントの指定」のいずれかによる明示的な終了条件が必須です。 ...

概要 Anthropic が 2026年4月に公開した、複数 AI エージェントを協調させるための5つの設計パターン。「まず Orchestrator-Subagent から始め、観察した制約に応じて発展させる」という設計哲学が基本。 5 つのパターン 1. Generator-Verifier（生成・検証） 一方のエージェントが出力を生成し、もう一方が明示的な基準で検証。不合格なら生成エージェントにフィードバックが戻り、合格か最大反復回数に達するまでループ。 向いているケース: コード生成＋テスト実行など、品質基準が明確なタスク 注意点: 検証基準の設計が甘いと「品質管理の幻想」になる 2. Orchestrator-Subagent（オーケストレーター・サブエージェント） リーダーエージェントが計画を立て、専門化されたサブエージェントにタスクを委任。Anthropic 推奨のデフォルト出発点。 向いているケース: セキュリティ・テストカバレッジ・スタイルを分担するコードレビュー等 注意点: サブエージェント間の依存が高いと情報ボトルネックになる 3. Agent Teams（エージェントチーム） コーディネーターが永続的なワーカーエージェントを生成。ワーカーはアサインをまたいで生存し、ドメイン知識を蓄積する点が Orchestrator-Subagent との違い。 向いているケース: 大規模コードベースの長期・並列マイグレーション 注意点: タスク間の独立性が必要。完了検知が難しい 4. Message Bus（メッセージバス） エージェントが共有ルーター経由でパブリッシュ・サブスクライブ。実行順序があらかじめ決まらないイベント駆動型。 向いているケース: セキュリティアラートが動的に多段階調査をトリガーするようなパイプライン 注意点: イベント連鎖のトレーサビリティが低下しやすい 5. Shared State（共有ステート） 中央コーディネーターなしに、エージェントが永続ストレージを直接読み書き。他エージェントの発見をリアルタイムに参照できる。 向いているケース: 一方の調査が即座に他方の探索方向に影響する協調リサーチ 注意点: 収束条件が必須。なければ際限なくトークンを消費する 選択の目安 パターン 向いているケース Orchestrator-Subagent 多くのユースケースの出発点 Generator-Verifier 品質基準が明確で反復検証が必要 Agent Teams 並列・長期・ドメイン蓄積が必要 Message Bus イベント駆動で動的にワークフローが変化 Shared State エージェント間でリアルタイムに知識を共有したい 実際のプロダクションでは複数パターンを組み合わせることも多い。 関連ページ Claude Managed Agents エージェントメモリのロックイン ハーネスエンジニアリング ソース記事 Anthropic が解説するマルチエージェント調整パターン 5 選 — 2026-04-11 Claude Managed Agents のアーキテクチャ: Brain / Session / Hands の分離設計 — 2026-04-10

チャエン（@masahirochaen）さんが「外付けのAI脳」と名付けたシステム Exbrain を GitHub で公開した。Claude Code × Obsidian × 常駐エージェントを組み合わせて、記憶・日報・クリッピングを全自動化するという意欲的なプロジェクトだ。 GitHub: chaenmasahiro0425/exbrain Exbrain とは Exbrain は「自分の外側にある AI の脳」を目指したパーソナル PKM（Personal Knowledge Management）システムだ。Karpathy が提唱した「LLM Wiki」パターンの実装版として設計されており、AIが継続的に自分の経験・価値観・目標を学習し続ける仕組みを提供する。 主な特徴: 毎朝の日報自動作成: AI がカレンダー・Slack・Gmail を読み込み、その日のブリーフィングを自動生成 毎夕の振り返り: AI が1日の行動を分析し、繰り返しパターン（例:「月曜は会議10件が3週連続」）を検出・記録 自動クリッピング: X でブックマークした記事やツイートを約4時間後に自動要約して Obsidian に蓄積 Slack 連携: Slack の DM に URL を投げるだけで即座にクリップ 常時稼働: PC を閉じた状態・就寝中でもエージェントが動き続ける iPhone で全部読める: Obsidian の同期により、モバイルからもアクセス可能 SOUL / MEMORY / DREAMS の3ファイル設計 Exbrain の核心は、自分自身を表現する3つの Markdown ファイルだ。 ファイル 役割 SOUL.md 自分は誰か（価値観・境界線） MEMORY.md 何を経験したか（決定・学び） DREAMS.md どこに向かうか（洞察・未解決の問い） AI はこの3ファイルを毎日読み込み、そのコンテキストをもとに振り返りや提案を行う。単なるメモ帳ではなく、AIが自分のことを「知っている」状態を維持する仕組みだ。 ...

Anthropic で Claude Code を開発している Thariq が、社内での大規模なスキル活用から得た知見をまとめたノートが公開された。スキルは Claude Code の最も使われる拡張ポイントの一つであり、柔軟で作りやすく配布もしやすい。しかしその柔軟性ゆえに「何が正解か」を判断しにくいという問題もある。本記事はそのノートの内容を日本語でまとめたものだ。 スキルとは何か スキルは「ただの Markdown ファイル」という誤解が多いが、実際にはスクリプト・アセット・データなどを含むフォルダー全体がスキルだ。Claude Code では動的なフックの登録など多彩な設定オプションも提供されている。 最も面白いスキルは、こうした設定オプションやフォルダー構造をクリエイティブに活用しているものだ。 スキルの 9 つのカテゴリ 社内のスキルを棚卸ししたところ、いくつかのカテゴリに分類できた。最も優れたスキルは一つのカテゴリに綺麗に収まる。自組織でどのカテゴリが欠けているかを確認するのに役立つ。 1. ライブラリ・API リファレンス ライブラリ、CLI、SDK の正しい使い方を説明するスキル。内部ライブラリや Claude Code が苦手とする一般的なライブラリを対象にする。参照コードスニペットのフォルダーや、Claude が避けるべき「落とし穴（gotchas）」リストを含めることが多い。 例: billing-lib — 社内課金ライブラリのエッジケースや注意点 internal-platform-cli — 社内 CLI の全サブコマンドと使用例 frontend-design — 自社デザインシステムに Claude を合わせる 2. プロダクト検証 コードが正しく動作しているかをテスト・検証するスキル。Playwright や tmux などの外部ツールと組み合わせることが多い。検証スキルは Claude のアウトプットの正確性を担保するために極めて有用で、エンジニアが 1 週間かけて磨き上げる価値がある。 出力の動画録画や各ステップでのプログラムによるアサーションなどの手法も有効だ。 例: signup-flow-driver — サインアップ → メール確認 → オンボーディングをヘッドレスブラウザで実行 checkout-verifier — Stripe テストカードでチェックアウト UI を操作し、請求書の状態を確認 tmux-cli-driver — TTY が必要なインタラクティブ CLI テスト用 3. データ取得・分析 データ・監視スタックに接続するスキル。認証情報付きでデータを取得するライブラリ、特定のダッシュボード ID、一般的なワークフローの手順などを含む。 ...

AIエージェントを使った「0人会社（zero-human company）」のコンセプトが現実に近づいている。 Paperclip は、そのためのオーケストレーション基盤としてオープンソース化されたツールだ。 Paperclip とは Paperclip は「ゼロヒューマン企業」を動かすためのオーケストレーション層（orchestration layer）。 人間なしで自律的に業務が進む組織を設計・運用するための基盤として設計されている。 GitHubリポジトリ: paperclipai/paperclip リリース後またたく間にスターが集まり、2026年3月時点で 53,000スター超 を記録している。 主な機能 Paperclip が提供する機能は次の通り: 組織図（Org Charts） — エージェントの役割と階層を定義する 目標整合（Goal Alignment） — 組織全体の目標を各エージェントのタスクに紐付ける タスクの責任者（Task Ownership） — どのエージェントが何を担うかを明確に割り当てる 予算管理（Budgets） — エージェントが使用できるリソースや費用に上限を設定する エージェントテンプレート（Agent Templates） — 役割ごとの標準的なエージェント設定を再利用する これらの仕組みにより、人間のオペレーターが常時介在しなくても「自律的に仕事が進む会社」を実現できる。 クイックスタート セットアップは npx で1コマンド: 1 npx paperclipai onboard このコマンドを実行すると、初期の組織設計のガイドが始まる。TypeScript 製で、Node.js 環境があればすぐに試せる。 なぜ注目されるのか 従来の AI エージェントフレームワークの多くは、単一エージェントまたは単純なマルチエージェントの連携を想定している。Paperclip が異なるのは、企業・組織レベルの構造をファーストクラスの概念として扱っている点だ。 単なるタスクキューではなく、組織図と権限委譲を持つ エージェント同士の目標が整合されていることを保証する仕組みがある 予算制約により無限ループや暴走を防ぐ設計になっている 「AIエージェントに会社を任せる」という考えを本格的にサポートするインフラとして、エンジニアコミュニティの注目を集めている。 参考リンク paperclipai/paperclip - GitHub オープンソース化を告知したツイート（@dotta）