h5i入門: Claude CodeとCodexを並列実行して監査可能な結果を出す方法

こんにちは。もるふぉです。

Claude Codeを複数並列で動かしている人なら、テストログ4MBがコンテキストを食い潰す瞬間を経験したことがあるはずです。

worktreeで凌いできた人は、3エージェントを同時に起動した瞬間に .git/config.lock の競合に遭遇して、ため息をついたことがあるはずです。

コンテキストが汚れる、ログが肥大化する、誰がどの判断をしたのか追えない。

この3点が、エージェント並列運用の壁になっています。

この記事では、その壁を一気に解く h5i というRust製ツールを、インストールから最初の並列実行までを最短ルートで紹介します。

Git自体を監査台帳にしてしまうという思想が、想像以上に効きます。

GitHub - h5i-dev/h5i: Auditable workspaces for AI agent teams: sandboxed worktrees, multi-agent peer-review, 95% lower token waste, and persistent memory.

Auditable workspaces for AI agent teams: sandboxed worktrees, multi-agent peer-review, 95% lower token waste, and persistent memory. - h5i-dev/h5i

github.com

h5iとは何か Git-nativeなエージェント・アンサンブル基盤

「Run many coding agents. Merge one auditable result.」の意味

h5i のキャッチコピーは "Run many coding agents. Merge one auditable result." です。

直訳すると「コーディングエージェントをたくさん走らせて、監査可能な1つの結果にマージする」。

これがそのまま設計思想になっています。

複数エージェントを並列に走らせる仕組みは他にもありますが、h5i が違うのは「結果を中立に検証してから勝者を採用する」点と「採用に至るまでの全プロセスがGitに残る」点です。

プロンプト、モデル、コマンド、テスト結果、判定根拠まで、すべて refs/h5i/* に追記されます。

SaaSに送るログも、外部に握られる証跡もありません。

worktreeやClaude Agent Teamsと何が違うのか

worktreeは作業ディレクトリだけ複製する仕組みなので、複数エージェントが同時に git を叩くと素直に衝突します。

Claude Agent TeamsはSaaSに証跡を預ける形になり、監査要件が厳しい現場では通らないことがあります。

h5i はその両方を回避するために設計されています。

ここからが具体的な仕組みの話です。

なぜ単一エージェント運用では限界が来るのか

コンテキスト汚染とトークン爆発が起きる構造

Claude Codeを単体で長時間動かすと、テスト出力やgrep結果がコンテキストに溜まり続けます。

4MBのテストログを1つ読み込ませただけで、その後の応答精度が露骨に落ちることがあります。

/compact を連打して凌ぐ場面が増えてきたら、それは単一エージェント運用の天井に当たっているサインです。

worktreeで並列起動するときの .git/config.lock 競合

worktreeで3つ以上のエージェントを同時に起動すると、ほぼ確実に .git/config.lock の競合に遭遇します。

anthropics/claude-codeのIssue #34645 でも議論されていて、根本原因は「複数プロセスが同じGit設定を同時に書き換えにいく」ことです。

手で rm .git/config.lock を打って凌ぐような運用は、自動化の意味を半分失わせます。

この2つの問題に、h5i は5つの仕組みで正面から答えています。

h5iが解決する5つの問題

独立サンドボックス Landlock + seccomp + namespaces

各エージェントは独立したサンドボックスで走ります。

Linuxカーネルの Landlock でファイルシステムアクセスを制限し、seccomp でシステムコールを絞り、namespaces でプロセス・ネットワーク空間を分離する三層構造です。

エージェントから /etc/shadow を読もうとしても弾かれますし、外部通信も既定でブロックされます。

worktreeのロック競合が起きないのも、各エージェントが別の名前空間にいるからです。

macOSではこの三層の代わりに、macOS標準サンドボックス機構の Seatbelt を使った隔離実装が適用されます。

各プラットフォームでの強度差や対応状況は、後段の制約セクションでまとめて触れます。

約95%トークン削減 圧縮要約と refs/h5i/objects

ここで面白いのが、h5i は「軽くする」と「失わない」を同時に実現している点です。

各ツール出力を圧縮要約してエージェントに渡し、フルログは refs/h5i/objects にGitオブジェクトとして保存します。

ベンチマーク上の削減率は約95%です。

つまり、コンテキストに渡るのは要約だけ。

でも元のフルログはGitにある。

フルログがGitに残るということは、PRレビュー時に過去のツール出力をそのまま辿れます。

AIが何をした結果そのコードが生まれたのかを、後から追えるわけです。

要約を見て怪しい挙動に気づいたら、いつでも refs/h5i/objects から元のフルログを引き出して検証できます。

i5h メッセージプロトコル ASK / REVIEW_REQUEST / RISK / HANDOFF

エージェント同士は型付きメッセージで会話します。

プロトコル名は i5h で、ASK（質問）、REVIEW_REQUEST（レビュー依頼）、RISK（リスク報告）、HANDOFF（引き継ぎ）、ACK（受領）、DONE（完了）の6種類です。

i5hメッセージは、エージェント同士のSlackチャンネルがGit refsに残るようなものです。

たとえば RISK を投げれば他のエージェントに「この方向は地雷だから踏むな」という危険信号を共有でき、ASK で別のエージェントの判断を待ってから動くこともできます。

すべて refs/h5i/msg にappend-onlyで保存されるため、誰が誰に何を聞いたか、どのリスクを共有したかが時系列で追えます。

7段階の調整プロトコル createRoster から apply まで

h5i の並列実行はランダムではなく、7つのフェーズで進みます。

1. createRoster メンバー編成
2. dispatch タスク配布
3. independent 独立実行
4. freeze 成果物の凍結
5. review 相互レビュー
6. verify 中立検証
7. apply 勝者の適用とマージ

特に重要なのが freeze と verify です。

各エージェントは他のメンバーの作業中の状態を見られず、検証フェーズで初めて成果物が並べられます。

これにより「先に出した答えに引きずられる」型の汚染を排除しています。

最後の apply フェーズでは、verify を通過した勝者が中立的な判定（Verdict）の結果として本流ブランチにマージされます。

Git-native監査 refs/h5i/* に何が記録されるか

refs/h5i/* にはプロンプト、使用モデル、実行コマンド、ツール出力、テスト結果、レビューコメント、最終判定までが追記されます。

Gitリポジトリそのものが監査台帳になる構造で、外部SaaS依存ゼロで証跡が残ります。

「監査要件があるのでSaaS型のAIエージェントツールが導入できない」と言われていた現場には、これだけで導入理由になります。

仕組みを掴んだところで、実際に動かしてみましょう。

インストールから最初の並列実行までの最短ルート

インストールと初期化

インストールは1行です。

Rust製バイナリだから既存の開発環境に何も余分なものを足しません。

curl -fsSL https://raw.githubusercontent.com/h5i-dev/h5i/main/install.sh | sh

Rustが入っているなら cargo install --git https://github.com/h5i-dev/h5i h5i-core でも構いません。

インストール後、対象リポジトリで初期化します。

h5i init
h5i hook setup --write --wrap-bash

h5i hook setup はClaude Code向けのMCPフックを書き込み、bashラッパーを有効化します。

h5i init 1コマンドで始められるのが、導入ハードルを低く保っている理由のひとつです。

Claude Code と Codex を同時に走らせる

環境とチームを作って、ディスパッチすれば並列実行が始まります。

h5i env create claude --profile claude-code
h5i env create codex  --profile codex
h5i team create review-task --base HEAD
h5i team add-env review-task claude
h5i team add-env review-task codex
h5i team dispatch review-task "認証周りのリファクタを検討してテストを通す"

Claude CodeとCodexが別々のサンドボックスで動き始めます。

.git/config.lock の心配はありません。

各エージェントは独立した名前空間にいるので、Git操作も干渉しません。

検証と勝者の適用 h5i team verify / finalize

両エージェントが作業を終えたら、凍結して検証します。

h5i team freeze review-task
h5i team verify review-task
h5i team finalize review-task

verify はテスト実行と差分検証を中立に走らせ、finalize で勝者の成果物を本流ブランチにマージします。

判定根拠も refs/h5i/* に残るので、後から「なぜclaudeを採用したか」を追えます。

コマンド5本で、並列実行から監査ログ生成まで一気通貫で回ります。

h5iはどこに効くか エージェント並列実行の向き・不向き

SaaSロックインを避けたいプラットフォーム / セキュリティ担当者向け

ベンダーロックインに敏感な現場、ログを外部に出せない現場には刺さります。

h5i はSaaSに依存せず、ローカルのGitだけで全機能が回ります。

Apache 2.0ライセンスなので、社内フォークも自由です。

監査証跡が必要なエンタープライズ向け

金融、医療、公共領域では「AIに何をさせたか」の証跡保存が要件化されつつあります。

refs/h5i/* に全プロンプト・モデル・コマンド・判定が追記される構造は、こうした要件にそのまま乗せられます。

個人 / スタートアップでのトークン削減目的の使い方

監査要件がない個人や小チームでも、ツール出力の圧縮効果だけで導入価値があります。

長時間セッションで /compact を連打している人は、h5i のサンドボックス+要約パイプを通すだけでセッション寿命が伸びます。

h5i v0.2.3 現時点の制約

サンドボックス強度のプラットフォーム差

Landlock と seccomp はLinuxカーネル固有の機能です。

macOSでは Seatbelt ベースの別実装が適用され、Linuxほどのシステムコール単位の制御はかかりません。

Windowsでも実行可能ですが、サンドボックス機能はLinux向けに最適化されています。

本番でフルに機能を効かせたいならLinux環境を選ぶのが安全です。

v0.2.3時点での未対応事項

2026-06-22リリースの v0.2.3 時点では、複数リポジトリ横断のチームラン、ブラウザ操作系のエージェント連携などは未対応です。

GitHubスターはまだ422で活発に開発中の段階なので、本番採用前にロードマップとIssueトラッカーは一度見ておく価値があります。

h5i: Infrastructure for AI Agent Teams (Claude Code & Codex)

Run many coding agents. Merge one auditable result. h5i is the Git-native workspace layer for AI agent teams: isolated workspaces, sealed independent attempts, a neutral verifier, and one auditable verdict — in refs/h5i/*, no SaaS.

h5i.dev

まとめ: h5iでエージェント並列実行を始める

h5i は複数エージェントを並列に走らせて監査可能な1つの結果を出すというシンプルな目的に対し、サンドボックス・トークン圧縮・型付きメッセージ・7段階プロトコル・Git監査の5層で答えを出しています。

Claude Code単体で限界を感じている人、worktreeでロック競合に疲れた人、SaaS依存を避けたい人には、いま試す価値があります。

まずは h5i init から h5i team dispatch までを自分の手元で1往復してみるのが最短ルートです。

動かしてみれば、refs/h5i/* を覗くだけでこの設計の意図が腹落ちします。