こんにちは。Yahoo!検索のフロントエンドエンジニアの山本です。普段は Yahoo!検索の開発と運用を行っています。そのかたわら、Coding Agent を使った開発自動化と AI 活用、 チームへの展開（AX）を進めています。
近年、Coding Agent を活用した開発が広がり、Issue を起点に AI が実装から Pull Request 作成まで進める開発スタイルも身近になってきました。CI が落ちた場合も AI が修正し、人が手を動かさなくてもレビュー待ちの Pull Request ができている。こうした開発ループの自動化に取り組んでいる方も多いのではないでしょうか。私自身も同様の仕組みを構築し、Issue を渡せば Pull Request ができあがる状態を作りました。
具体的には、以下のように Issue 起票から実装、Pull Request 作成、CI の自動修正までを Coding Agent がひとつのループとして自走する仕組みです。CI が落ちてもログを解析して自分で直し、マージ後は次の Issue へ進みます。
しかし、そこで次の壁にぶつかります。個人が速くなることと、チームが速くなることは、まったく別の問題だったのです。
本記事は、個人で作り込んだ AI 活用を、チーム（組織）で回る形に変えるまでの「方針転換」の記録です。単なるツール導入ではなく、開発プロセスと役割の作り替えです。AX（AI Transformation：組織の AI 変革）の一事例として共有します。
はじめに：この記事で話すこと
- 出発点：個人で作り込んだ自動化（Before）
- 壁：個人が速いほど、チームが止まる
- 方針転換：個人運用 → チーム運用へ、何を変えるか
- 移行の手順：共有資産化 → レビュー再設計 → 定型業務の自動化
- 成果と学び：レビュー渋滞の解消、9人月 → 3人月、役割の再定義
特定のツールの宣伝ではなく、「個人の AI 活用を、どうやってチームの成果に引き上げたか」という実践知の共有を目的としています。
出発点：個人で作り込んだ自動化（Before）
まず前提として、個人の開発環境では次のような自動化を組んでいました。
- 開発ループの自動化：Issue の対応から実装、Pull Request 作成、レビュー依頼までを Coding Agent に任せる
- CI 監視・自動修正：CI の結果を定期的に確認し、テストやビルドが失敗したらエラーログを解析して修正を当て、再度プッシュするところまでを自動化
- 脆弱性対応の自動化：依存パッケージの脆弱性をスキャンし、修正版へのバージョン更新から Pull Request 作成までを実行。CI 監視の仕組みと組み合わせて、検知から修正 Pull Request までを一気通貫で完結
- 運用監視・ログ調査：ダッシュボードのメトリクスやログ基盤のクエリ結果を AI に読ませ、状況の要約や、障害や異常が起きたときの原因調査を補助
- 社内ツールの統合：Confluence / Jira / Slack / CI / ログ基盤といった社内システムを、AI から CLI や MCP 経由で直接操作できるツールを作成
個人の生産性という意味では、これで十分に速くなりました。問題は、この速さがそのままではチームに広がらないことでした。
壁：個人が速いほど、チームが止まる
チームで Coding Agent を使い始めると、想定していなかった事態が起きました。
Coding Agent を使いこなせる人が Pull Request を量産し、他のメンバーがレビューしかできなくなったのです。レビューを消化しないと次の実装に進めず、レビュー担当のメンバーの作業が止まってしまう。結果として、チーム全体ではむしろ手が止まるという逆転が起きました。
個人の生産性向上は、レビューという共有リソースに負荷を集中させ、そのままではチームのボトルネックになります。
「自分が速く実装できること」を最適化しても、チームのスループットは上がらない。むしろ、レビュー渋滞という新しい詰まりを生む。ここで、最適化の対象を「自分」から「チーム」へ切り替える必要があると気づきました。
方針転換の本質：個人運用 → チーム運用
個人からチームへ持っていくために、発想そのものを次のように切り替えました。
| 観点 | 個人運用（Before） | チーム/組織運用（After） | 転換に必要なこと |
|---|---|---|---|
| 最適化の対象 | 自分のスループット | チームのスループット | 「自分が速い」より「渋滞を減らす」発想 |
| 資産 | 手元のスクリプト/プロンプト | 共有できるツールや skills | Homebrew / pip3 で配布し、誰でも自走できる形に |
| 品質担保 | 自分でレビュー | レビュー手順を再設計 | レビュー前の品質担保を強化し、レビュー負荷を下げる |
| 対象業務 | 実装の高速化 | 定型業務や動作確認の省力化 | 脆弱性対応やバージョンアップ、運用を AI 化 |
| 再現性 | 使える人だけ | 誰でも再現できる | うまくいった形を skills として整備し、定期更新 |
| ガードレール | 個人の裁量 | 組織的な安全策 | 取得/作成は許可、変更/削除は不許可、をツール側で担保 |
| 進め方 | 自分で決める | 環境が需要を生む | ボトムアップ。まず環境を整える |
狙いを、「AI で速く書く」から「チームで詰まらず流す」へ移しました。以下、実際にどう進めたかを紹介します。
移行の手順
ステップ1：便利なツールを「共有資産」にする
まず、個人が手元で使っていた CLI / MCP tool / skills を、Homebrew や pip3 で社内に配布する仕組みを作りました。社内システムや開発に効くツールを、インストールすればすぐ使える形にして、誰もが自走できる状態を目指しまし た。
あわせて、既存の CI/CD の資産を有効活用し、レビュワーに依頼する前の品質担保を強化することでレビュー負荷を下げました。人がレビューする前に、機械的に担保できることは機械で担保しておく、という考え方です。
属人的なスクリプトを「配布可能なツール」に変えることが、チーム展開の最初の一歩でした。
ステップ2：レビュー手順を再設計する
レビュー渋滞を解くために、レビューのやり方そのものを見直しました。
| 観点 | Before | After |
|---|---|---|
| 必要なレビュワーの承認 | 2人のレビュワーによる承認 | 1人のレビュワーによる承認 ＋ AI レビュー |
| AI レビューの扱い | なし | 必須指摘は、レビュワーに依頼する前に実装者が解消 |
AI レビューを人のレビューの前段に置き、「必須指摘を解消してからレビュワーに依頼する」ことをルール化。これにより、人のレビューは本質的な観点に集中でき、必要なレビュワーの承認数も見直せました。レビュー前の品質担保を強化したことが、結果的にレビュー担当の負荷を下げました。
ステップ3：定型業務と動作確認を自動化する
共有とレビュー設計が回り始めた後、次のような業務を AI に寄せていきました。
- 脆弱性対応やバ ージョンアップなどの定型業務
- E2E テストではカバーしにくい動作確認の自動化
- 運用（監視や調査など）の省力化
「人がやらなくてよいこと」を順に AI や自動化へ移すことで、チームの手を空けていきました。
浸透のさせ方：試して、共有して、育てる
展開は一度きりの導入ではなく、継続的なサイクルにしました。
- 各自がそれぞれ AI の使い方を試行する
- うまくいった形を skills などで共有する
- 定期的にアップデートし、チームの成果として最大化する
フィードバックは常に受け付け、ルールや手順を書いた Markdown ファイルはいつでも更新可能にしています。「正解を配る」のではなく、「良かったやり方が自然に集まって更新されていく」状態を作ることを重視しました。
ガードレール：ツール側で安全を担保する
チームで使う以上、安全策は個人の裁量に任せず、MCP / CLI 側に組み込みました。基本方針はシンプルです。
| 操作 | 可否 |
|---|---|
| fetch（取得・参照） | 許可 |
| create（作成・Pull Request 起票など） | 許可 |
| apply（変更の適用） | 不許可 |
| delete（削除） | 不許可 |
「取得・作成は任せ、変更・削除は人が担う」という線引きを、ツールのレイヤーで担保することで、誰が使っても危険な操作に踏み込まないようにしました。
進め方：ボトムアップで、環境が需要を生む
この取り組みは、トップダウンの号令ではなくボトムアップで進めました。まず使える環境を整えると、環境そのものが「使いたい」という需要を生む。号令で使わせるのではなく、便利だから自然に広がる状態を狙いました。
成果：レビュー渋滞の解消と、9人月 → 3人月
少人数のチームでこの方針転換を進めた結果、次のような変化がありました。
- レビュー渋滞が解消し、実装が止まる状態がなくなった
- 体制変更で少人数のチームになった後も従来の開発量を吸収でき、むしろ余裕が生まれた
- ある作業では、9人月かかっていたものが 3人月まで圧縮できた
「個人が速い」を追っていた頃には出なかった、チーム全体としての効果が出るようになりました。
役割の再定義：AI Ready な環境がもたらしたもの
一連の取り組みを通じて、AI Ready な環境（AI がそのまま扱える形にツールや手順、コンテキストが整った状態）が生まれました。
そして、開発の工数の中身が変わりました。実装そのものよりも、
- 要求の仕様整理（何を作るべきかを明確にする）
- 次の仕事を探す（次に価値を生む対象を見つける）
に時間を使うようになったのです。AI が実装や定型業務を担い、人は「何をやるか」と「判断とレビュー」に集中する。役割の重心が、はっきりと移りました。
おわりに：AX は、ツール導入ではなく作り替え
今回の経験であらためて感じたのは、AX の本質は「強いツールを配ること」ではない、ということです。
- 個人の速さは、そのままではチームの速さにならない（最適化の対象を「自分」から「チーム」へ切り替える）
- 属人的な工夫を、配布可能な共有資産に変える（Homebrew / pip3 / skills）
- レビューの詰まりは、レビュー前の品質担保を強化して解く（AI レビューを前段に、必須指摘は事前解消）
- 安全はツール側で担保する（取得・作成は許可、変更・削除は人が担う）
- 号令ではなく環境で広げる（AI Ready な環境が需要を生み、人の仕事は仕様整理と次の価値探しへ移る）
個人の AI 活用は、始めること自体はもう難しくありません。むしろこれからの論点は、それをチームで詰まらず回る形にどう作り替えるかという、組織としての AX です。本記事が、同じように「個人の成功をチームに広げたい」と考える方の参考になれば幸いです。最後までお読みいただき、ありがとうございました。
