AIに91%のコミットを書かせた人の「権限設計」が、実務で使える理由
直近80コミット中73コミットがClaude共著。この数字だけ取り出すと「すごい話」で終わってしまうが、本質はそこではない。
ZennにPMのyukamiyaさんが投稿した記事は、AIエージェントに自律実行させるための権限設計・マージ条件・ガードレールを、個人リポジトリ3つの実ログから整理した内容だ。Claude Codeのセッションログ3プロジェクト合計20セッション・約38MBをたどって書かれたという。単なる「やってみた」ではなく、失敗を含めた設計原則の部品表として読める。
なぜこれが今重要か——「AIに任せる」と「安全に任せる」は別問題
AIエージェントを開発フローに組み込もうとしている現場は増えている。しかし多くの場合、議論は「どのツールを使うか」で止まる。権限をどう絞るか、マージ判断をどこで人間が持つか、失敗したときにどう戻せるか——これらの設計論は、まだ個人の勘と試行錯誤に依存している。
再現可能な形で整理された事例が少ない理由のひとつは、「うまくいった話」だけが表に出やすいことだ。この記事が価値を持つのは、macOSのcronが18日間サイレントに全滅していた話や、レビュー用スキル自身が自分の指摘と同じ違反を犯していた話を、設計原則のアップデートとして正直に組み込んでいるからだと思う。
3リポジトリと3層モデルの実装——事実の整理
実験場は性質の異なる3つのリポジトリだ。
| リポジトリ | 性質 | AIに任せたプロセス |
|---|---|---|
| momit.fm | ポッドキャストサイト | エピソード公開のたびに発生する定型リリース作業 |
| yukamiya.me | 個人サイト | コンテンツ更新の検知・QA・レビュー・マージ |
| hub.momit.fm | ブログ+収益化ツール | ツール実装そのものと、PRレビュー・修正・マージ |
権限設計は自然と3層に分かれたと著者は振り返る。
Can（届く範囲を絞る）：Claude Codeのsettings.local.jsonで許可コマンドを前方一致の許可リストで列挙する。WebFetchはドメイン単位。認証情報そのものを渡さない選択もここに入る。アフィリエイトサービスへのログイン操作はブラウザを開くところまでをAIが担い、ログイン操作は人間が行う。
May（実行の瞬間に承認を挟む）：Claude Codeのautoモードには危険操作を止める分類器がおり、本番WordPressへの書き込みコマンドは実際にブロックされた。GitHubではauthor-associationによるゲートを置き、@claudeメンションに反応するworkflowはOWNER/MEMBER/COLLABORATORのコメントにしか反応しない。
Act（成果物はゲートを通って初めて効力を持つ）：音声アップロードは全自動で進むが、配信プラットフォーム上ではDraftとして保存され、公開ボタンは人間だけが押せる。ライブサイトへの書き込みを持つCLIはdry-runが既定で、--applyを明示した時だけ実書き込みが走り、POSTの前に必ず編集前スナップショットをバックアップに残す。
この3層で面白いのは、「AIに自由にやらせる」と「全部人間が確認する」の二択を解体している点だ。層ごとに緩めたり締めたりできるダイヤルが3つある、という構造になっている。
マージ条件の機械可読化——スコアが0/5から5/5に収束するまで
自律実行の中で最も興味深いのがマージ条件の設計だ。hub.momit.fmでは、PRへのpushごとにGitHub Actions workflow（greptile-gate）が起動し、サードパーティAIレビュアのGreptileのConfidence ScoreをパースしてConfidence Score: X/5の形で5/5を確認した場合のみgh pr mergeを実行する。
このゲートが最初に本番で処理したのは、皮肉なことに「自律レビューのスキル自体を追加するPR」だった。
- 1回目：スコア0/5。ブランチ名のシェル未検証、fork PRの誤pushリスク、学習記録の取りこぼしの3点を指摘
- 2回目：スコア3/5。修正したつもりが「規約としては書いたのに、コマンド例文が未反映」と差し戻し
- 3回目：スコア5/5。例文まで修正してゲートを通過し、そのまま自動マージ
人間がやったのは方針の判断と再レビューの号令だけ。「満点になるまでマージされない」という条件が、そのまま修正を促すフィードバック信号として機能した。
「信頼の条件をコードに書く」という発想の転換
ここからは見方の話だ。
この記事が示しているのは、AIエージェント活用の問いの立て方そのものの転換だと思う。「このAIを信頼できるか」という問いは、実は設計できない。しかし「どういう条件を満たしたら信頼できると言えるか」は書ける。書けた分だけ任せられる。著者自身がこれを「一番の収穫だった」と振り返っている。
この考え方は、AIエージェント特有のものに見えて、実はソフトウェアエンジニアリングの基本に近い。テストを書かないまま「このコードは動くはず」と信じるのと、テストが通ることを条件にするのの違いに似ている。条件を言語化してコードに落とす、という操作がAIの自律度を上げるための核心になる。
もうひとつ着目したいのが、外部レビュアーが自己検証の盲点を補った事実だ。著者が構築した自律レビュースキルは、他のPRで「ユーザー固有の絶対パスをハードコードするな」と指摘して修正まで行った。にもかかわらず、そのスキル自身の手順書には絶対パスが直書きされていた。これを見つけたのは外部のAIレビュアだ。
「自己検証には構造的な盲点がある」という当たり前の事実が、AIが書いたコードにも等しく当てはまる。マージ判定を自分と独立した評価者に置く設計は、この盲点を補う仕組みとして機能した。独立した評価者というのは人間である必要はないが、同じコンテキストを共有していないことが重要だ。
失敗事例が教えてくれる設計原則
macOSのlaunchdに登録した週次ジョブが、TCC（macOS Privacy保護）によってOperation not permittedで失敗し続けたケースは18日間サイレントだった。手動実行では正常に動くため気づけない。「ログを見る仕組みだけ作って、ログを見る習慣を作っていなかった」という総括は刺さる。自動化の死活監視はそれ自体を自動化しないと意味がない。
Greptileのタイムアウト問題も示唆的だ。ドキュメントだけの変更pushに対して、Greptileは新しいレビューオブジェクトを作らずサマリコメントをin-place更新することがある。レビューオブジェクトの出現だけを待っていたゲートは、満点が出ているのに永久に気づけなかった。外部サービスの未文書化挙動は必ず踏む前提で、判定材料を単線にしないことにした、と著者は書いている。外部サービスの信頼性をシングルポイントで設計するのは、自前実装でも同じリスクを抱えることになる。
実務的な示唆——どこから始めるか
組織に持ち込む順序として、著者は3段階を提案している。実務感覚からも、この順番は理にかなっていると思う。
まずCanとActから。許可リストで届く範囲を絞り、成果物の受け口をDraft/dry-runにする。ここまでは既存のレビュー体制を一切変えずに導入でき、事故っても戻せる。「AIを入れる」という意思決定をせずに、「安全な実験環境を作る」という意思決定だけで始められる。
次にマージ条件を機械可読にする。いきなり自動マージまで行かなくても、「AIレビューの結果を1行のマーカーで出す」だけでプロセスが監査可能になる。AUTO_REVIEW_STATUS: passのような機械可読な一行を要求するのは、AIのアウトプットを既存の自動化パイプラインに組み込む上でかなり効く小技だ。
最後に学習の置き場所を決める。実行記録・誤検知メモ・学んだルールをリポジトリにコミットする運用にすると、セッションや担当者が変わっても賢さが積み上がる。著者が整理したガードレール原則の中で「1 finding = 1 commit」と「状態はリポジトリに」をAI前提ならではの設計と位置づけているのも同じ理由だ。人間のrevertという操作を、機械が読める学習データに変える仕掛けになる。
次に問題になる論点
この記事で扱われていない部分は、次の課題として残る。合意形成とコンプライアンスのレイヤーは著者も「今回の範囲外」と明言している。個人リポジトリでは不要だったが、組織に持ち込むと「AIがマージした」という記録を誰がどう承認するか、という責任構造の問いが生まれる。
「実績に応じて自律度を段階昇格させる」運用も、著者は現在明文化の途中と書いている。権限を段階的に「稼がせる」設計にしても、その昇格条件を誰が設計し誰が変更権限を持つのか。AIが増えれば増えるほど、「AIに権限を与える権限」の設計が次の焦点になる。
まとめ
AIに91%のコミットを書かせることは、驚くべき結果というより、正しく設計された結果だ。重要なのは、何を任せたかではなく、何を任せないかの条件をコードで書いたこと。
「曖昧に信頼するのでも、曖昧に警戒するのでもなく、条件を書く。書けた分だけ任せられる」——この言葉は、AIエージェント活用を「ツールの問題」ではなく「設計の問題」として捉え直す視点を与えてくれる。
