Claude Code、Codex、Copilot CLI みたいな CLI coding agent をチームに入れる時、最初に分厚い導入資料を作りたくなります。
気持ちは分かります。権限、コスト、セキュリティ、レビュー方針。決めることは多い。
でも自分なら、最初に作るのはスライドではなく、短い作業ログです。
誰かが issue を切って、agent に読む範囲を渡して、command を承認して、diff を見て、どこで止めたのか。そこが見える方が、次の人は試しやすい。
面白いのは「24%」より social exposure
Microsoft の early 2026 rollout study では、Claude Code と GitHub Copilot CLI の社内導入が分析されています。
数字だけ見ると、adopters の merged PR が counterfactual より約 24% 多かった、という結果が目立ちます。強い数字です。
ただ、自分がこの記事で取り上げたいのはそこではありません。
もっと現場っぽくて面白いのは、first use が social network 経由で広がっている点です。近い reviewer peer、skip-level peer、direct manager が使っていることが、初回利用と結びついていた。
「便利な CLI があります」という説明より、「近くの人がどう使っているか」が効いている。
これは自分の感覚にも近いです。CLI agent は、使う前の説明より、横で一回見る方が早い。
導入資料より、1 task のログを見せる
チームに共有するなら、こんな粒度で十分だと思っています。
## Agent task log
- task: 依存関係更新の影響調査
- agent: Codex / Claude Code / Copilot CLI
- readable files:
- package.json
- pnpm-lock.yaml
- src/**
- blocked files:
- .env
- credentials
- deploy keys
- approved commands:
- pnpm test
- pnpm lint
- stopped commands:
- npm install without reviewing scripts
- human review:
- generated diff は OK
- test failure の読み替えが雑だったので修正
きれいな成功談だけでは足りません。
むしろ、止めた command、読ませなかった file、agent が外した判断を書いた方がいいです。そこが見えると、他の人が「この範囲なら自分も試せそう」と判断できます。
逆に、成功した PR のリンクだけを貼っても、あまり再現性がありません。
その PR がなぜ小さく切れたのか。どこまで agent に任せたのか。どの command は人間が見たのか。reviewer は何を疑ったのか。
知りたいのはそこです。
最初に決めるのは、tool ではなく task class
自分なら、いきなり「全員 Claude Code を使いましょう」とはしません。
まず task class を決めます。
OK:
- test の追加
- 型エラーの修正
- 小さい UI component の分割
- dependency update の影響調査
- docs と example の同期
まだ早い:
- 認可まわりの設計変更
- 決済処理
- migration を含む DB schema 変更
- 大きい package manager 切り替え
- production deploy 設定
agent の導入で揉める時、だいたい「何に使うか」が曖昧です。
人によっては小さい refactor だけに使っている。別の人はいきなり auth flow を書かせている。同じ「AI agent を使った」でも、リスクは別物です。
なので、最初の 2 週間は tool 比較より task class の比較をした方がいい。
Claude Code がいいか、Codex がいいか、Copilot CLI がいいか。それも気になります。
でも最初に知りたいのは、「このチームではどの作業なら agent に渡しても review できるか」です。
AGENTS.md には哲学ではなく実行ルールを書く
作業ログが何本か溜まったら、repo 側の instruction に落とします。
たとえば AGENTS.md にこのくらい。
## Agent usage rules
- Keep agent tasks small enough to review in one PR.
- Before editing, list the files you plan to read and modify.
- Do not read `.env`, credentials, deploy keys, or files outside this repo.
- Ask before running install scripts, migrations, or deploy commands.
- Run lint, typecheck, and relevant tests before reporting completion.
- In the PR description, include what the agent changed and what a human checked.
ここで長い思想を書いても、あまり効きません。
agent に読ませたいのは、実行時に分岐を変えるルールです。
「安全にやってください」では弱い。「migration は承認前に実行しない」なら止まれます。
「レビューしやすくしてください」も弱い。「1 PR で読める大きさに切る」なら行動に落ちます。
PR 数だけを見ると、たぶん見誤る
rollout study の merged PR 増加は無視できません。ただ、paper 自体も merged PR は output proxy であって delivered value そのものではない、と断っています。
ここを雑に扱うと、導入後の会話がだいたい歪みます。
AI agent を入れると、PR 数は増えやすい。小さい修正、docs、test、cleanup を投げやすくなるからです。
でも、PR が増えても reviewer が詰まっていたら意味が薄い。generated code の修正率が高すぎるなら、実は人間の負荷を移動しているだけかもしれない。差分が小さくても、重要な判断を agent が勝手にやっていたら怖い。
自分なら、最初はこのあたりを見ます。
- PR count
- review 待ち時間
- reviewer が読んだ diff の量
- agent 生成部分の修正率
- 差し戻し回数
- task log が別メンバーに再利用された回数
- 人間が承認した command の種類
- 途中で止めた command / prompt
PR count は見ます。見ない理由はありません。
ただ、それだけで「agent 導入は成功」と言うのは早い。
open source における AI coding agent の痕跡を調べる研究でも、bot account や PR だけを見ると取りこぼしが大きい、という話が出ています。設定ファイル、commit message、author identity、bot signature など、複数の signal を組み合わせないと見えない。
チーム内の rollout も似ています。
GitHub 上の PR だけでは、local CLI でどれだけ試行錯誤したか、どの command を止めたか、どの prompt が再利用されたかは見えません。
だから task log を残す。
「見つけた」より「review できる」を見る
もうひとつ、測り方で気をつけたいことがあります。
AI agent の評価は、つい「問題を見つけたか」「修正できたか」に寄りがちです。
でも実務では、それだけだと足りません。
RustMizan のような vulnerability benchmark では、agentic setup で binary classification はある程度できても、line localization はかなり厳しい、という結果が出ています。
ざっくり言うと、「怪しい」と言えることと、「ここを直せ」と言えることの間には距離がある。
frontend の日常作業でも同じです。
この変更は壊れていそうです
より、
`src/components/ProfileForm.tsx` の submit handler で、
optimistic update 後の rollback が抜けています。
再現手順はこれです。
の方が review に乗ります。
agent rollout の指標も、この粒度を見た方がいいです。
PR は増えた。でも、その PR は review できる形だったか。再現手順があったか。失敗した時に止められたか。人間が判断すべき場所が明示されていたか。
こっちの方が、後から効いてきます。
最初の 2 週間の回し方
自分なら、最初の 2 週間はこうします。
1. 2-3 人だけで始める
全員導入にしない。
まず、普段から review が丁寧な人と、実装スピードが速い人を混ぜます。agent が速く書いた差分を、ちゃんと疑える人が必要です。
2. 同じ task class を試す
各自が好きな作業を投げると、比較できません。
最初は揃えます。
- flaky test の原因調査
- component 分割
- lint/type error 修正
- docs と example の同期
同じ種類の task で、agent がどこまで役に立つかを見る。
3. task log を毎回残す
長文はいりません。
## What I asked
`UserMenu` の mobile 表示崩れを調査して、最小 diff で直して。
## What I allowed
- read: app/components/UserMenu.tsx, app/styles/**
- command: pnpm test UserMenu, pnpm lint
## What I stopped
- unrelated header refactor
## Human review
- CSS selector の影響範囲を手で確認
- snapshot update は採用しなかった
このログが 5 本あるだけで、導入資料より強いです。
4. 週末に rule を 3 行だけ更新する
最初から完璧な policy を作らない。
週末に、実際に起きたことだけ AGENTS.md や team docs に反映します。
- Do not touch shared auth middleware without explicit approval.
- For CSS fixes, include before/after screenshots in the PR.
- For dependency updates, inspect install scripts before running tests.
このくらいでいいです。
使った結果から rule を増やす。先に全部決めようとしない。
frontend team だと deploy path までつながってくる
CLI agent の話は、local coding だけで終わらなくなっています。
Vite、Vitest、Rolldown、Oxc のような frontend tooling が platform 側と近づいていくと、agent が local code を触って、test を回して、deploy 直前まで進む流れはもっと自然になります。
Cloudflare が VoidZero を取得した話も、この文脈で見ると分かりやすいです。dev server や bundler の速さは、人間の体感だけでなく、agent の試行回数にも効きます。
だからこそ、team rollout では「便利そう」だけでは足りない。
どこまで agent に進ませるのか。どこで人間が止めるのか。どの log を残すのか。
frontend の DX が良くなるほど、境界設計は地味に大事になります。
まとめ
CLI coding agent は、導入資料だけでは広がりにくいです。
近くの人が、実際にどう使って、どこで止めて、何を review したのか。それが見えると、次の人は試しやすくなる。
最初に作るものは、きれいな onboarding deck ではなく、1 task の作業ログでいいと思います。
PR 数は見る。でも、それだけでは判断しない。
review 負荷、手戻り、task 粒度、止めた command、再利用された log。そこまで見ると、agent が個人技ではなく、チームの開発フローに入ってきます。