AIエージェント開発の最前線：ハーネス設計・メモリ管理・ブラウザ自動化が切り拓く新たなソフトウェアエンジニアリング
Claude Codeのフック・メモリ機構からAnthropicのハーネス設計論、StripeのMinions、Playwright CLI・agent-browserまで、2026年初頭に結実しつつあるAIエージェント実用化の技術的全貌を深掘りする。
なぜ今「AIエージェント実用化」が臨界点を迎えているのか
2025年末から2026年初頭にかけて、AIコーディングツールをめぐる議論は「使えるか使えないか」という段階を完全に卒業した。問題の重心は「どう制御し、どう持続させ、どう組織化するか」という工学的問いへと移行している。
OpenAIが「Harness Engineering」という概念を提唱し、Anthropicが長時間稼働エージェントのハーネス設計を公開し、StripeがMinionsと呼ぶ社内エージェント基盤を発表し、MicrosoftとVercelがそれぞれブラウザ自動化CLIをリリースした。これらは個別のニュースではなく、同一の技術的潮流が異なる角度から結晶化したものだ。
その潮流とは何か。LLMを「使う」から「制御する」へのパラダイムシフトである。本稿では、Claude Codeの公式ドキュメント、Anthropicのエンジニアリングブログ、Thoughtworksの技術分析、実務者のワークフロー事例、そして新世代のブラウザ自動化ツールを横断的に読み解き、この転換の技術的本質を明らかにする。
ハーネスとは何か：決定論とLLMの協調設計
「ハーネス（harness）」という語は、もともと馬具を意味する。AIエージェントの文脈では、エージェントの行動を制御・誘導するための道具立て全体を指す。Thoughtworksのディスティングイッシュドエンジニア、Birgitta Böckelerは
でこの概念を丁寧に分解している。OpenAIチームが構築したハーネスは三つの層から成る。第一はコンテキストエンジニアリング：コードベース内の継続的に強化される知識ベースと、オブザーバビリティデータやブラウザナビゲーションへのエージェントアクセス。第二はアーキテクチャ制約：LLMベースのエージェントだけでなく、決定論的なカスタムリンターや構造テストによる監視。第三は**「ガベージコレクション」**：ドキュメントの不整合やアーキテクチャ違反を定期的に発見するエージェント群。
Böckelerが鋭く指摘するのは、このアプローチが「何でも生成できる」というLLMへの幻想を否定している点だ。信頼性の高いAI生成コードを大規模に維持するには、解空間を意図的に制約する必要がある。特定のアーキテクチャパターン、強制された境界、標準化された構造——これらは柔軟性の放棄ではなく、スケーラブルな自律性を得るための必要条件だ。
Anthropicは
で、この問題をより実装寄りに論じている。複数のコンテキストウィンドウにまたがる長時間稼働エージェントの核心的課題は、各セッションが前のセッションの記憶を持たないことだ。これを「シフト交代制のエンジニアチームで、各エンジニアが前のシフトの記憶を持たない状態」と表現するアナロジーは秀逸である。
Anthropicの解決策は二部構成だ。イニシャライザーエージェントが最初のセッションで環境を構築する：init.shスクリプト、進捗ログファイルclaude-progress.txt、初期gitコミット。その後のコーディングエージェントは、このインフラを足場にして一度に一機能ずつインクリメンタルに進捗を積み上げ、セッション終了時に「クリーンな状態」——mainブランチにマージ可能な品質——を維持する。
特筆すべきは機能要件の管理方法だ。200以上の機能をJSONファイルで管理し、各機能のpassesフィールドのみを変更するよう強く指示する。MarkdownではなくあえてJSONを選んだ理由が興味深い：モデルはMarkdownファイルを不適切に書き換えてしまうが、JSONファイルはそうしにくいという実験的知見だ。これは決定論的制約とLLMの特性を組み合わせたハーネス設計の好例である。
Claude Codeのフックシステム：決定論的制御の実装
ハーネスの概念を最も具体的に実装したのが、Claude Codeのフックシステムだ。
によれば、フックとは「Claude Codeのライフサイクルの特定ポイントで実行されるユーザー定義のシェルコマンド」であり、その本質はLLMが選択するかどうかに依存せず、特定のアクションが必ず実行されることを保証する決定論的制御にある。
フックが発火するイベントは多岐にわたる。PostToolUseイベントでファイル編集後に自動フォーマットを実行する、NotificationイベントでClaudeが入力待ちになった際にデスクトップ通知を送る、PreToolUseイベントで.envやpackage-lock.jsonなどの保護ファイルへの編集をブロックする——これらはすべて、LLMの判断を介さない確実な制御だ。
アーキテクチャ的に重要なのは、フックが三種類の実装形態を持つことだ。コマンドフック（シェルコマンド直接実行）、プロンプトベースフック（Claudeモデルが条件を評価）、エージェントベースフック（サブエージェントが判断）。決定論的なルールには前者を、判断が必要な場合には後者を使い分けるという設計思想は、Böckelerが分析したハーネスの「決定論とLLMの協調」と完全に対応している。
フックの入出力はJSON形式で標準化されており、jqコマンドでパースして処理するパターンが推奨される。終了コード2でツール実行をブロックし、標準エラー出力でClaudeにフィードバックを返す——この設計により、フックはClaudeの行動ループに組み込まれたフィードバック機構として機能する。
メモリとコンテキストの永続化：CLAUDE.mdとオートメモリの二層構造
長時間稼働エージェントの課題がセッション間の記憶喪失であるなら、その解決策の一つがClaudeのメモリシステムだ。
は、二つの補完的なメカニズムを詳述している。
CLAUDE.mdファイルは人間が書く永続的な指示書だ。プロジェクトルート、ユーザーホームディレクトリ、組織レベルのシステムパスなど、スコープに応じた複数の場所に配置できる。重要なのは、これが「強制される設定」ではなく「コンテキストとして読み込まれる指示」であるという点だ。つまり、書き方の質が遵守率に直結する。
効果的なCLAUDE.mdの原則は明確だ：200行以内に収める、Markdownの見出しと箇条書きで構造化する、「コードを適切にフォーマットする」ではなく「2スペースインデントを使用する」のように検証可能な具体的指示を書く。これはソフトウェアエンジニアリングにおける「実行可能な仕様」の考え方と同じだ。
オートメモリはClaudeが自律的に書くメモリだ。ユーザーの修正や好みから学習し、次のセッションに引き継ぐ。各ワーキングツリーにスコープされ、最初の200行または25KBがセッション開始時に読み込まれる。
@path/to/import構文によるファイルインポートは特に強力だ。README.mdやpackage.jsonを直接参照したり、チームで共有するCLAUDE.mdから個人の設定ファイルをインポートしたりできる。これにより、組織レベルの標準と個人の好みを分離しながら統合するという複雑な要件を、シンプルな仕組みで実現している。
実務者のワークフロー：計画と実装の分離という原則
理論的なハーネス設計を、実際の開発ワークフローに落とし込んだ事例として、
のBoris Taneの実践は示唆に富む。9ヶ月間Claude Codeを主要開発ツールとして使い続けた彼が到達した核心的原則は一つ：Claudeがコードを書く前に、書面による計画をレビューし承認する。
彼のワークフローは六段階だ：リサーチ→計画→アノテーション（1〜6回繰り返し）→Todoリスト→実装→フィードバックと反復。
リサーチフェーズで特徴的なのは、「深く」「詳細に」「細部まで」という言葉を意図的に使うことだ。これは「表面的な読み取りは許容しない」というシグナルをモデルに送るためだ。そして成果物を必ずresearch.mdとして永続化する——これはAnthropicのclaude-progress.txtと同じ発想、すなわち次のコンテキストウィンドウへの橋渡しとしての構造化アーティファクトだ。
アノテーションサイクルは彼のワークフローで最も独自性が高い部分だ。Claudeが生成したplan.mdを自分のエディタで開き、ドキュメントに直接インラインノートを追加する。「not optional」という2語のこともあれば、ビジネス制約を説明する段落のこともある。そしてClaudeに「ノートに対処してドキュメントを更新せよ、実装はするな」と指示する。
このアプローチが優れているのは、マークダウンファイルが人間とClaudeの間の共有可変状態として機能する点だ。チャットメッセージで方向修正しようとすると、スクロールして決定を再構築しなければならない。計画ドキュメントなら、問題のある箇所を直接指摘して修正を書き込める。これは本質的に異なる認知的インターフェースだ。
ブラウザ自動化の新潮流：CLIとSKILLSによるトークン効率の追求
エージェントがブラウザを操作する能力は、テスト自動化から実世界のタスク実行まで、AIエージェントの実用性を大きく左右する。2026年初頭、この領域で二つの重要なツールが登場した。
のPlaywright CLIは、MicrosoftがPlaywrightをAIエージェント向けに再設計したものだ。最大の特徴は**トークン効率**への徹底的なこだわりだ。従来のPlaywright MCPがページデータ全体をLLMコンテキストに押し込むのに対し、CLIアプローチは簡潔な目的特化コマンドでエージェントが行動できるようにする。playwright-cli snapshotでアクセシビリティツリーを取得し、playwright-cli click e21で要素をクリックする——このパターンは、大規模コードベースとブラウザ自動化を限られたコンテキストウィンドウ内でバランスさせる必要があるエージェントに最適化されている。SKILLSという概念も重要で、エージェントがplaywright-cli --helpを読んでスキルを自律的に習得できる設計になっている。
agent-browser snapshotが返すアクセシビリティツリーの@ref形式、--annotateオプションによる番号付き要素ラベル付きスクリーンショット、stream enableによるWebSocketリアルタイムストリーミング——これらはすべて、AIエージェントが視覚的・構造的情報を効率的に消費するための設計だ。26,000スターという数字は、この方向性への市場の強い支持を示している。
両ツールに共通するのは、MCPとCLIの使い分けに関する明確な設計哲学だ。探索的自動化や自己修復テストなど、永続的な状態と豊富なイントロスペクションが必要な場合はMCP。高スループットのコーディングエージェントでブラウザ自動化と大規模コードベースを同時に扱う場合はCLI。この二分法は、ツール選択の実践的指針として機能する。
業界・社会への影響：ハーネスが変えるソフトウェア開発の構造
これらの技術的発展が示す業界への含意は深い。
テックスタックの収束：Böckelerが指摘するように、AIエージェントによるコード生成が主流になると、「良いハーネスが存在するスタック」が選ばれるようになる。開発者の好みや言語の表現力よりも、AIフレンドリーさが技術選択の基準になりうる。これはプログラミング言語やフレームワークのエコシステムに構造的変化をもたらす。
ハーネスのサービステンプレート化：今日の「ゴールデンパス」サービステンプレートが、明日はカスタムリンター・構造テスト・コンテキストプロバイダーを含むハーネスに進化するかもしれない。ただし、サービステンプレートと同様に、フォークと同期の課題が生じるだろう。
既存コードベースの二極化：ハーネスを前提に設計された新規コードベースと、後付けでハーネスを適用しようとする既存コードベースの間には、メンテナビリティの格差が生まれる。静的解析ツールを初めて導入したときのアラート洪水と同様の問題が、AIエージェントの文脈で再現される可能性がある。
エンジニアの役割変容：Boris Taneのアノテーションサイクルが示すように、エンジニアの価値は「コードを書く」から「計画を精査し、ドメイン知識を注入し、アーキテクチャ判断を下す」へとシフトする。これはソフトウェアエンジニアリングの認知的負荷の再配分だ。
まとめ：制御の工学としてのAIエージェント開発
2026年初頭の技術的景観を俯瞰すると、AIエージェント開発の成熟度は「プロンプトを書く」段階から「制御システムを設計する」段階へと明確に移行している。
Claude Codeのフックシステムは決定論的制御の実装を、メモリシステムはセッション間の知識継続を、Anthropicのハーネス設計はマルチセッション稼働の工学的解法を、Boris Taneのワークフローは人間とエージェントの協働インターフェースを、Playwright CLIとagent-browserはエージェントの実世界インタラクションのトークン効率を——それぞれ異なる角度から同じ問いに答えている。
その問いとは：どうすれば、AIエージェントを信頼できる形で長期間・大規模に稼働させられるか。
Anthropicのエンジニアが述べた「最も困難な課題は今や、環境・フィードバックループ・制御システムの設計にある」という言葉は、この問いの本質を突いている。そしてBöckelerが引用するChad Fowlerの「厳密さの再配置（Relocating Rigor）」という概念——AIが書くコードの品質保証の責任が、コードレビューからハーネス設計へと移動する——は、今後のソフトウェアエンジニアリングが向かう方向を示している。
ハーネスは5ヶ月かけて構築するものだ。しかし、今日のプリコミットフック、カスタムリンター、構造テスト、CLAUDE.mdの整備——これらの小さな積み重ねが、明日のハーネスの基盤になる。
