朝、コーヒーをいれてから机に向かって、v0.4.1 出したい と入力しました。夕方には v0.5.0 の GitHub Release ページが 13 個のアセットで埋まっていました。あいだで動いていたのは、Claude・Codex・Grok・そして GitHub Actions の CI、計 4 種類の AI と自動化でした。この記事はその 1 日の記録です。

上の図が、この記事全体の流れをざっくり示したものです。監査 → 実装委託 → 第三者検証 → CI 3 回失敗 → タグ push → 4 チャネル配信、という順で読んでいただけると迷子になりません。

many-ai-cli を作っています

自作で many-ai-cli という AI ツール / Web ダッシュボードを作っています。複数のAIコーディングCLIセッションの承認管理・監視を行うローカルWebダッシュボードです。

同じ悩みを持っている方は、下記で入ります。

npm i -g many-ai-cli

リポジトリはこちらです（Star をいただけると励みになります）: https://github.com/ishizakahiroshi/many-ai-cli

3 コマンドで動きます

上の図が、初めて入れる人向けの最短フローです。ターミナルで打つのは最初の 2 コマンドだけ。あとは配置されたショートカットをダブルクリックすれば、Hub UI がブラウザで開きます。

npm i -g many-ai-cli
many-ai-cli setup

ここまでで所要 1 分弱。デスクトップに「Many AI Hub Start」が現れます。それをダブルクリックすると many-ai-cli serve が裏で立ち上がり、http://127.0.0.1:47777/ がブラウザで開いて Hub のダッシュボードが出ます。あとはそのタブから claude や codex を spawn するだけ。設定ファイルの用意もいりません。

「入れる → 起動する」の壁を、v0.5.0 でようやく低くしきりました。ここが今回の一番の推しポイントかもしれません。

「v0.4.1 出したい」から始まった

出発点は本当に何気ないひと言でした。「v0.4.0 のあとに溜まった修正、そろそろまとめたい」。それだけです。

Claude Code に v0.4.1 をリリースしたい、CHANGELOG と README とライセンス、それとバグも網羅的にチェックしてほしい と頼みました。返ってきたのは想定外の情報でした。

直近タグ v0.4.0 以降、develop に 23 commits・146 files・+11234 / -1145 行
新規機能: setup / doctor サブコマンド、autoapproval エンジン、turn-diff、grok history、UX 刷新
CHANGELOG の [Unreleased] は空

要するに、v0.4.1 と呼ぶには膨らみすぎていました。SemVer 的に minor bump 相当。ここで一度立ち止まって v0.5.0 に切り替えました。この判断ミスをしないためだけでも、リリース前の状態把握はやる価値があります。

監査 43 点、Grok に助けられた

タグを打つ前に、監査を挟むことにしました。「ちょっと待って、リリース前に監査しとこうか」。この判断が、この日の流れを大きく変えました。

Claude Code から ultracode モードで多エージェント並列調査を回しました。7 つの subagent を並列に走らせて、バグ・セキュリティ・脆弱性・依存関係・保守性・検証カバレッジを網羅的に調べます。プロンプトは自作の ai-audit-prompts から claude_ultracode_audit_db_app.md を使いました。AI に書かせたコードを業務へ取り込むためのレビュー・監査プロンプト集で、今回の 34 finding もこの型からきれいに出てきています。

結果は 43 / 100（評価 C）でした。決して高くありません。34 件の finding のうち、HIGH ブロッカー 2 件、MEDIUM 15 件、LOW 17 件。

HIGH の 2 件は特に効きました。

1 つ目は Go 1.25.11 の stdlib crypto/tls に到達可能な CVE GO-2026-5856（Encrypted Client Hello privacy leak）が乗っていること。govulncheck が Symbol Results 段で検出しました。到達可能とは、コードから実際に呼ばれる経路が存在するという意味で、実害の可能性があります。go.mod の go 1.25.11 を go 1.25.12 にする、その 1 行だけで解消します。

2 つ目は applyOneTapApproval の順序バグ。承認をタップした瞬間に nonce を消費してから PTY へ送信していて、送信失敗時にロールバックが効かない設計でした。通知タップ中に wrapper WS が切れると、入力は消失。実運用で年に何度も踏むかは分かりませんが、静かに壊れるバグはこわいので直したい。

上の図は v0.5.0 の目玉のひとつ、many-ai-cli setup コマンドの流れです。3 OS すべてでデスクトップに「Many AI Hub Start」ショートカットを 1 発で作り、そこから Hub の起動とブラウザの立ち上げまで自動で通します。ターミナルを開かない人にも届く導線を作りたくて入れました。

setup / doctor / autoapproval、3 つの新機能

監査の話に戻る前に、v0.5.0 の目玉を先に紹介します。今回のリリースで一番自慢したいのはこの 3 つです。

1. `many-ai-cli setup`

Windows / macOS / Linux で、デスクトップに起動用ショートカットを 1 発で作ります。Windows なら .lnk を PowerShell 経由の WScript.Shell で、macOS は .command、Linux は .desktop を出します。ダブルクリックで many-ai-cli serve が起動して、ブラウザで Hub の URL が開く。

なぜこれを入れたかというと、npm i -g many-ai-cli の次にターミナルを開かせるのがそもそも壁だと気づいたからです。エンジニアではない配偶者や親が、こういうツールの門前で足止めを食う。多くの OSS が「ターミナルから操作」を暗黙の前提にしていて、そこを乗り越えられない層の存在を忘れがちだと思います。

2. `many-ai-cli doctor`

環境診断コマンド。Provider CLI（claude / codex / copilot / cursor-agent / grok / opencode）の存在、Hub port / token / ACL、Ollama や Whisper の endpoint、Tailscale の状態、session log ディレクトリ、config.yaml の妥当性を、一気に見ます。

上の図が doctor の診断項目マップです。トラブルシュートの入り口に必ずいるべき機能で、Issue で「動かないんですけど」に対して「many-ai-cli doctor の結果を貼ってください」と返せるようにするのが狙いです。診断結果は CLI にも /api/doctor にも出ます。

3. 自動承認ポリシーエンジン

~/.many-ai-cli/config.yaml の autoapproval.* セクションで、特定のプロンプトパターンに対する自動承認を設定できます。「git status の承認は自動で通していい」「git commit は必ず手動で確認したい」といった宣言的なルールを、コマンド名・作業ディレクトリのパターンで書きます。

危険側の暴走を防ぐ hard-block ガードも入れました。.* みたいな全許可パターンや空文字は Load 時に弾きます。「便利にすると同時に危険にもする」機能なので、ここは慎重に。

上の図は autoapproval の設計です。allow-list パターン、hard-block ガード、simulation エンドポイントの 3 つが 1 セットになっています。simulation は「過去の承認履歴のうち、このルールなら何件が自動化されていたか」を事前に見るための機能で、ルールをいきなり本番投入しない安全弁として置いています。

Codex に F1〜F17 を投げてみた

監査の話に戻ります。43 / 100 のスコアシートを見て、HIGH 2 + MEDIUM 15、つまり F1〜F17 は今回のリリース前に直したい。LOW 17 件（F18〜F34）は v0.5.1 に回す。この線引きをしました。

そのとき、思わず口をついたのが「codex に修正させます」でした。

Claude 側で修正を書かせるより、実装作業は codex に投げて、Claude は指揮官と検証だけに徹する。この分業のほうが結果的に速いのではと思ったからです。

上の図が、そのとき自然に組み上がった 4 AI 協働のパイプラインです。Claude が指揮を執り、codex が実装、Grok が独立検証、GitHub Actions が最終ゲートを担当します。役割の重複を減らして、それぞれの得意に寄せる形になりました。

Codex に渡すために、監査結果を素直に貼るのではなく、単体で実行できる指示書を書きました。ファイル名は docs/local/codex-task_audit-fixes-v0.5.0.md。「作業ゴール」「禁止事項」「作業手順」「F1〜F17 の作業内容」「成果物」「停止禁止」を md 本文に直書きしました。ユーザーが codex に「これやって」と md パスを渡すだけで動く形。

このやり方は、この日の学びのひとつです。他 AI CLI に委託する md は、その 1 ファイル単体で動く形で書く。「詳細は別ファイル参照」の Read chain を強要しない。作成時に自分が把握している内容は、その場で書き込む。

Grok に第三者検証してもらった

Codex が F1〜F17 の修正を終えて戻ってきました。18 files 変更、3 新規、加えて securefile/atomic.go という新規パッケージまで書いてくれていました。

ここで一手間かけました。同じ AI に「自己採点」を許すのではなくて、独立した第三者に検証してもらう。Grok Build CLI に頼みました。

Grok に渡す tasking md は、codex に渡したものとは別の設計です。目的が違うので中身も違います。

codex 向け: 「仕様に沿って実装せよ」
Grok 向け: 「実装が仕様どおりかを検証せよ。ソースは書き換えるな」

上の図が監査スコアカードの Before / After です。Before の 43 / 100 から、F1〜F17 反映後は理論値で 68 / 100 相当まで戻せる想定でした。Grok の検証結果は 17 / 17 pass、新規リグレッション 0 件、go vet ./... 通過、変更パッケージの go test 全 green、govulncheck ./... で到達可能 CVE 0 件。

正直、ここまでうまく揃うとは思っていませんでした。同じ Claude で self-review していたら、たぶん見落としがあったと思います。目線を変える価値は、AI 同士でもちゃんとあります。

Validate CI が 3 回落ちた

さて、ここから雲行きが変わります。

Grok 検証まで済んだので、いよいよタグを打とうと develop → main マージ → push → Validate CI 待ち。順調に進むはずでした。

1 回目、fail。

macOS で TestNormalWorktreeCreateAndSafeCleanup と TestTokenAndACLPermissions の 2 テスト、Windows で前者 1 テストが落ちました。ローカル Windows でも、Grok 環境（Windows）でも、通っていたのに CI で落ちる。この時点で、ため息をひとつ。

原因を追いかけたら、両方とも「platform 依存」でした。

normal_worktree の方は、macOS の t.TempDir() が /var/folders/... を返すのに対して、git worktree add の内部で filepath.EvalSymlinks 相当が走って /private/var/folders/... に化ける。Windows は 8.3 short name → long name への展開。テストの期待値だけ、元の path のままなので不一致になっていました。修正は filepath.EvalSymlinks(repo) を先に噛ませる 1 行だけ。

doctor の方は、テストが chmod で dir に 0o600 を当てていて、Unix の dir 走査に必要な execute bit（+x）を落としていました。dir に入れないので、中の config.yaml を os.Stat できない。「Hub トークンは設定済みですが、設定ファイルを確認できません」というエラーで token check が WARN になる。修正は tc.mode | 0o100 で execute bit を足すだけ。あと t.Cleanup で 0o700 に戻さないと t.TempDir の削除も失敗するので、そこも足しました。

commit → push → 2 回目、fail。

今度は staticcheck が 3 件検出しました。

U1000: session.idleStateName() メソッドが unused
SA4006: wrapper_loop.go:352 で rawLogPath と jsonlPath に代入した値がすぐ次の行で上書きされていて、never used

これ、F13 の「wrapperLoop / reattachLoop 大量重複を解消してヘルパ抽出」でリファクタした際に出た副産物です。冗長な sessionlog.Paths(...) 呼び出しがそのまま残っていて、3 行後に startSessionLog(...) の戻り値で上書きされる形になっていました。要はデッドコード。削除して commit → push → 3 回目、green。

10 個の job（web-check / staticcheck / third-party / go-mod-tidy / gosec / web-package-manager-consistency / Go × 3 OS / govulncheck）全部 success。ここでようやく息を吐きました。

タグ push、4 チャネル配信

git tag -a v0.5.0 -m "..." して git push origin v0.5.0。Release ワークフローが走り出しました。

goreleaser がクロスコンパイル → GitHub Release に 4 platform の zip + SBOM + deb + rpm + SHA256SUMS + cosign 署名を出す → winget-pkgs へ manifest PR を投げる → homebrew-tap の cask を更新 → npm へ root + platform 4 種を publish。この一連が全自動で通ります。

GitHub Release: 13 assets
npm: many-ai-cli@0.5.0 と platform 4 種すべて 0.5.0
winget: winget-pkgs PR #401729 が open
homebrew: homebrew-tap に cask 更新の commit

上の図はチャネル配信のマップです。人がやったのはタグを打つところまで、そこから先は goreleaser と GitHub Actions が引き取ってくれる。この設計は v0.1 のころに悩んで積み上げてきた資産で、v0.5 でようやく回収した気分です。

学んだこと

丸 1 日かかって思ったのは、次のようなことです。

**AI に「委託」するとき、その AI が単体で動ける md を渡す。「詳細は別ファイル参照」の Read chain を強要しない。**作成する AI（この場合は Claude）が把握している情報は、その場で md に書き込む。把握していない情報は、参照で残して理由を添える。あとで受け取る AI が迷わない形にする責任は、作成する側にあります。
**自己採点より、他人採点。同じ AI に自分の仕事を review させるのは弱い。**codex の実装を Grok に検証させる、この単純な分業だけで、見落としが減りました。同じモデルの盲点は、別モデルには意外と見えます。
**CI が落ちるのは、ローカルで通ってからが本番。**Grok の Windows 環境で通っていた normal_worktree のテストが、CI Windows で落ちる。この差分は「そこまで見ないよね」と流していたら、リリース後にユーザーが踏むところでした。CI の意義は、ローカルの油断を捕まえるところに 8 割あると思っています。
**go 1.25.11 → go 1.25.12 の 1 行で消える CVE は必ずリリース前に潰す。**この 1 行の変更は、レビューコストほぼゼロ、副作用ほぼゼロ、リスク回避大。「1 行で消えるものは全部消す」の姿勢は、地味ですが積み上がると効きます。

many-ai-cli はこんなときに刺さります

Claude Code や Codex を並列で走らせていて、ターミナルの往復に疲れている人
承認プロンプトを見落として AI が止まってしまい、後で気づく体験をしたことがある人
離席中もスマホから承認だけ返しておきたい人
v0.5.0 の setup コマンドで、非エンジニアの家族にも AI コーディングを開放したい人

いずれかに心当たりがあれば、npm i -g many-ai-cli で 1 分で試せます。設定ゼロで動きます。

リポジトリ（Issue / PR 歓迎）: https://github.com/ishizakahiroshi/many-ai-cli
npm: https://www.npmjs.com/package/many-ai-cli

Star をいただけると開発の励みになります。使ってみて「ここが不便」があれば、Issue でも X の DM でも大歓迎です。

あわせて、今回の監査で使ったプロンプト集も置いておきます。AI に書かせたコードや作業を業務へ安全に取り込みたい方向けの、レビュー・監査用プロンプト集です。

ai-audit-prompts（Prompt Engineering / HTML）: https://github.com/ishizakahiroshi/ai-audit-prompts

おわりに

朝コーヒーで v0.4.1 と入力して、夕方に v0.5.0 が全チャネルへ配信される。あいだで CI が 3 回落ちる。1 日の変化としては、悪くない濃度でした。

こういう「AI 同士で分業して 1 日でひとつ形にする」やり方は、まだこれから体系化されていくところだと思います。今日のやり方が正解かは分かりませんが、少なくとも「同じ AI に自己採点させない」だけは、これからも守っていきます。

小さく。次のリリースも、こういう記録を残しながら進めていこうと思います。

※ ヘッダー画像とインフォグラフィックは AI（画像生成）で作成しています。

書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.github.io/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi

バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。