AIエージェントハーネス動向 2026年4月

対象期間と読み方

本稿は、2026-04-01〜2026-04-30 に公開・更新された一次ソース、公式ドキュメント、リリースノート、GitHub・フォーラム上の発表を中心に、AI エージェントのハーネス動向を整理する月次リファレンスです。

対象は、Claude Code / Cursor / Codex / OpenAI Agents SDK / Cline などを日常的に使い、hooks、sub-agent、skills、MCP といった用語を既知として扱える開発者です。基礎概念の説明は省き、今月どこを見直すべきかに寄せます。

2026年4月の大きな流れは、ハーネスが個別実装からプロダクト機能へ吸収されつつあることです。サンドボックス、承認、スナップショット、並列実行、PreToolUse / PostToolUse のようなイベントフックが、ツールや SDK の共通プリミティブとして前面に出てきました。

4月の主要アップデート一覧

1. Skills エコシステム：配布単位が「レシピ化」する

4月に目立ったのは、Skills や Hooks が単なる個人設定ではなく、再利用可能な運用レシピとして流通し始めた点です。Claude Directory の Hooks 集では、TDD ガード、secret スキャン、lint / format / test 実行など、現場で導入しやすい単位に整理された例が確認できます。

• Claude Directory: https://www.claudedirectory.org/hooks

実務上の意味は大きいです。これまで各チームがシェルスクリプトや独自ラッパーで作っていた「危険コマンドを止める」「テスト未実行の変更を通さない」「secret らしき文字列を検出する」といった処理が、ハーネスの部品として再利用しやすくなりました。

筆者の評価としては、導入速度を上げる意味ではかなり前向きな動きです。一方で、レシピ集をそのまま入れる運用には注意が要ります。言語、monorepo 構成、テストランナー、CI との責任分界、社内のブランチ保護ルールが合っていないと、開発者体験を悪化させます。

特に Hooks は、CI より手前で止められる反面、誤検知が多いとエージェント作業全体が詰まります。今後は Skills / Hooks に対して、対応言語、必要コマンド、破壊的操作の有無、推奨イベント、想定リポジトリ構成などのメタデータが求められるでしょう。npm パッケージのように、由来・バージョン・互換性を読む文化が必要になります。

2. Sub-agent：並列化は「速度」より「統合設計」が主戦場

Cursor では4月下旬、/multitask による非同期サブエージェント実行、worktrees、multi-root workspace に関する発表がありました。

• Cursor Forum: https://forum.cursor.com/t/multitask-worktrees-and-multi-root-workspaces/158954

これにより、調査、実装、テスト作成、ドキュメント更新を並列で進める運用がより現実的になります。人間のチーム開発で行っていた「担当を分ける」という行為を、IDE 上のエージェント群に割り当てられる形です。

ただし、並列化の本質的な難しさは実行そのものではなく、統合点の制御にあります。同じファイルを複数エージェントが触る、設計方針が分岐する、テスト前提がずれる、といった問題は増えます。worktree 分離や multi-root は衝突の表面化を遅らせるだけで、最終的なマージ判断と検証ゲートは別途設計しなければなりません。

Cline の Subagents も、並列の調査役を立てる方向性として見ておきたい機能です。

• Cline Subagents: https://docs.cline.bot/features/subagents

Cline のパターンは、実装そのものよりもリサーチの並列化に向いています。既存コード探索、依存関係調査、API 仕様確認を複数のサブエージェントに分けると、設計前の情報収集が速くなります。一方で、調査結果を統合して意思決定するオーケストレーターが弱いと、情報だけが増え、実装方針が固まりません。

比較すると、Cursor は IDE 内での作業並列化をユーザー操作として露出し、Cline は調査・探索の分担を強めています。OpenAI Agents SDK は後述するように、サンドボックスとスナップショットで長期タスクを支える基盤寄りです。自社ハーネスでは、どのレイヤーで並列化するのかを分けて考えるのがよいでしょう。

3. Hooks：検証は「お願い」から「通行制御」へ

Claude Code の Hooks は、2026年4月時点でハーネス制御の中心的インターフェースとして扱いやすくなっています。公式ドキュメントでは、PreToolUse、PostToolUse、失敗時フィードバックなど、ツール実行ライフサイクルに沿った制御点が整理されています。

• Claude Code Hooks: https://code.claude.com/docs/en/hooks
• Claude Code Changelog: https://code.claude.com/docs/en/changelog

4月10日の changelog では、SessionEnd フックのタイムアウト制御に関わる改善が確認できます。これは一見小さな変更ですが、実運用では重要です。セッション終了時にログ収集、作業サマリ保存、差分退避、通知、メトリクス送信を行う場合、終了フックの挙動が不安定だと、監査性が落ちます。

現場での影響は明確です。危険な shell コマンド、保護ブランチへの直接変更、secret を含むファイル操作、テストを伴わない変更を、プロンプト上の指示ではなく PreToolUse で止められます。PostToolUse では、変更後に lint、format、型チェック、対象ユニットテストを実行し、失敗時にエージェントへ即時フィードバックできます。

筆者の見方では、Hooks の価値は「自動化」よりも「強制力」にあります。エージェントに「テストして」と頼むのではなく、変更後にテストが走る状態を作る。危険操作を「気をつけて」と書くのではなく、実行前に弾く。この差が、業務利用では効いてきます。

一方で、Hooks は増やすほど遅くなり、誤検知も増えます。すべてをブロックにすると開発者体験が崩れるため、warn、soft block、hard block の段階を分ける設計が必要です。軽量チェックはローカル Hooks、重い統合テストは CI、破壊的操作は人間承認、という責務分担が現実的です。

4. コーディング規約：Markdown から実行基盤へ

4月のもう一つの特徴は、コーディング規約を「ドキュメントに書く」だけでなく、ハーネスで制約として扱う流れです。

OpenAI は4月15日、Agents SDK の次の進化として、モデルネイティブなハーネス、ネイティブサンドボックス実行、snapshot / rehydrate を発表しました。

• OpenAI: The next evolution of the Agents SDK
  https://openai.com/index/the-next-evolution-of-the-agents-sdk

このアップデートは、単なる SDK 機能追加というより、エージェント実行環境を「安全・再現・再開」できる基盤へ寄せるものです。これまで自前で E2B やコンテナ、権限ラッパーを組み合わせていたチームにとって、SDK 側が共通プリミティブを提供する意味は大きいです。

規約面では、lint / format / test だけでなく、ファイルシステム権限、ネットワーク権限、認証情報の扱い、長期タスクの復旧まで、プロンプトではなく実行基盤で担保する発想が強まります。

Claude Code が端末・IDE 内のイベントフックで即時ガードを提供するのに対し、OpenAI Agents SDK はサンドボックス、snapshot、rehydrate により、隔離と再開性を提供する色が濃いです。併用するなら、IDE Hooks で開発中の危険操作を止め、SDK サンドボックスで長時間実行や外部操作を隔離する役割分担が自然です。

ネガティブ面もあります。基盤側の機能に寄せるほど、ベンダー依存と監査ログの所在が問題になります。ハーネスが便利機能の集合になると、どの層で何を制御しているのかが見えにくくなります。導入時は、フック、サンドボックス、承認、ログ、再開ポイントを図に落とし、責務境界を明示することを勧めます。

5. Codex app：作業面統合とレビュー導線

OpenAI は4月16日、「Codex for (almost) everything」として、Codex app の作業面統合を打ち出しました。

• OpenAI: Codex for (almost) everything
  https://openai.com/index/codex-for-almost-everything/

注目点は、ブラウザ、PRレビュー、複数ファイル、複数ターミナル、SSH といった開発ワークフローが、アプリ内の同じ作業面に寄っていることです。これは Skills や自動化の置き場が、IDE 拡張だけでなくデスクトップアプリ側にも広がることを意味します。

実務上は、レビュー導線をハーネスに組み込みやすくなります。たとえば、エージェントが変更し、ブラウザで確認し、PR 差分を見て、レビューコメントを受け、再修正する流れを単一の面に閉じられます。これにより、人間レビューを工程として挟みやすくなります。

評価としては、作業体験の統合には大きな利点があります。一方で、統合された環境ほどブラックボックス化しやすいです。誰が、どの自動化を、どの権限で実行し、どのログが残ったのか。ここを外部へ出せる API や監査ログが採用判断の焦点になります。

今後は、作業エージェント、レビューエージェント、セキュリティエージェントを分け、承認フローの一部をサブエージェントが担う設計が増えるでしょう。ただし、削除、上書き、秘密情報、課金操作に関わる領域では、人間承認を残す設計が安全です。

6. Verification：TDD ガードと差分ベース検証

4月の Hooks レシピ群で目立つのは、TDD ガードや lint / test 自動実行です。これは、エージェントが「動きそうなコード」を生成するだけでは足りず、変更直後に検証を走らせる流れが定着しつつあることを示しています。

CI だけに頼る場合、フィードバックが遅く、エージェントの修正ループが長くなります。PostToolUse で軽量な検証を走らせ、失敗をその場でコンテキストに戻せば、手戻りは小さくなります。

ただし、全テストを毎回走らせるのは現実的ではありません。差分に応じたテスト選択、対象パッケージだけの型チェック、format の自動適用、secret scan の即時ブロックなど、チェックを層に分ける必要があります。

筆者としては、2026年4月時点の推奨構成は次のように見ています。

1. PreToolUse: 危険操作、secret、保護ブランチ、破壊的コマンドを止める
2. PostToolUse: format、lint、型チェック、関連ユニットテストを実行
3. SessionEnd: ログ保存、差分サマリ、作業メタデータの記録
4. CI: 統合テスト、E2E、セキュリティスキャン、レビュー必須条件
5. Review agent: 差分要約、規約違反候補、テスト不足の指摘

この構成なら、ローカルハーネスは即時性、CI は網羅性、レビューエージェントは人間の認知負荷削減を担えます。

7. 5月以降に向けた見直しチェックリスト

4月の流れを踏まえると、自社ハーネスでは次の点を見直す価値があります。

Skills / Hooks 管理

• 追加した Skills / Hooks の出所を記録しているか
• バージョン固定、レビュー履歴、ロールバック手段があるか
• CI と Hooks の責務が重複しすぎていないか
• warn から block へ移す基準を決めているか

Sub-agent 並列化

• 並列作業の単位をファイル、機能、PR、調査テーマで切れているか
• worktree や multi-root workspace の使い分けが決まっているか
• 最終統合者が人間かエージェントか明確か
• 並列成果物を束ねる検証ゲートがあるか

Verification

• PreToolUse で止める操作を定義しているか
• PostToolUse で走らせる軽量検証を決めているか
• 重い検証を CI 側へ逃がせているか
• 失敗時ログが人間にもエージェントにも読める形で残るか

再現性と再開

• 長時間タスクの snapshot / rehydrate 戦略があるか
• セッション終了時のサマリと差分を保存しているか
• サンドボックス内外の権限境界を説明できるか

まとめ

2026年4月の AI エージェントハーネスは、Skills / Hooks のレシピ化、Sub-agent の並列化、Hooks による検証強制、SDK レベルのサンドボックスと再開性が同時に進んだ月でした。

ポイントは、エージェントに賢く振る舞わせることより、賢く振る舞えなかったときに壊れない実行基盤を作ることです。プロンプトで規約を伝えるだけの運用から、PreToolUse、PostToolUse、サンドボックス、snapshot、レビューエージェントで制御する運用へ移行する流れは、今後さらに強まるでしょう。

4月の更新を踏まえると、まず見直すべきは「どこで止めるか」「どこで検証するか」「どこで統合するか」です。並列化や Skills 追加の前に、この3点をハーネスの設計図として明文化しておくと、5月以降の機能追加にも耐えやすくなります。