AIエージェントとプラットフォームチーム
現在、AIをめぐってはノイズや誇大な期待が渦巻いており、多くは雇用が奪われることやエンジニアが失うものに焦点が当てられています。今回はその逆の視点について書きたいと思います。プラットフォームチームでの日々の業務にAIエージェントを活用することで、ここ数ヶ月で私が得られたものについてです。
これは魔法だと言うつもりはありません。エージェントは間違えることもありますし、明確な指示を与えるために必要なエンジニアリングの知識を代替するものでもありません。ただ、エージェントとともに進めてきた仕事の中には、明らかに一段階進んだと感じられるものもあります。コードを書くスピードは上がりましたが、より大きな変化はスコープにあります。以前なら先送りにしていた仕事にも取り組めるようになったのです。
プラットフォームチームの課題
以前のプラットフォームチームの課題についての投稿を読んでいただいた方なら、この背景をご存知かと思います。少人数のチームが、広大な領域を担っているという状況です。常に、共有サービスやライブラリ、28プロジェクトにまたがるマイクロフロントエンドアーキテクチャ、CIパイプラインなど、さまざまなものを維持しています。
プラットフォームの仕事で歯がゆいのは、最も難しい問題が必ずしも技術的なものではないということです。多くの場合、組織的な問題なのです。20以上のプロジェクトにまたがって修正が必要な箇所を見つけ、修正方法も正確にわかっていても、完了までに数ヶ月かかることがあります。各チームがそれぞれの優先事項を抱えており、それが必ずしもプラットフォームチームの取り組みと一致しないからです。プラットフォームチームの課題は、「やるべきこと」と「チームが実行できる余力があること」の間にあるギャップを埋めることにあります。
エージェントが、そのギャップを私の想像を超える形で埋め始めています。
リサーチ業務：横断的な意思決定を現実的にする
プラットフォームチームにとって、最も重要な意思決定ほど、自信を持って下すのが難しいものです。サービスを廃止したり、ライブラリを置き換えたり、組織全体で新しい基準を徹底したりする前には、誰に影響が及ぶのか、どのようなエッジケースが考えられるのかを理解する必要があります。こうした調査には常に大きなコストがかかり、不完全な情報のまま判断を下してしまったり、誰も適切に調査する余裕がないために意思決定自体を先延ばしにしたりすることがよくありました。
レガシーサービスの実態把握
長年稼働してきたあるサービスがありました。明確なオーナーはおらず、ドキュメントもほとんどなく、繰り返し浮かぶ疑問がありました。いったい誰が、どのように使っているのかということです。私たちはこのサービスを廃止すべきだと感じていましたが、実際の使われ方を把握するまでは移行について明確な判断ができませんでした。その答えを得るには、GitLab上で依存関係を手作業でたどり、レガシーなSVNリポジトリを掘り起こし、すでに去った人々が何年も前に書いたコードから全体像を組み立てる必要がありました。
エージェントを使うことで、この発見作業の大半を任せることができました。GitLabとSVNの両方にまたがる利用プロジェクトを横断し、呼び出し箇所を特定し、サービスが異なる文脈でどのように使われているかを要約し、注意すべきエッジケースを洗い出してくれたのです。本来なら数日かかりそうな作業が、ごく短時間でレビューし、さらに発展させられるものになりました。
人による判断や影響を受けるチームへのフォローアップが不要になるわけではありませんが、調査作業自体は格段に扱いやすくなりました。
アイコンの利用状況とWCAG準拠
別の例として、WCAG AA基準への準拠を評価する取り組みがあります。その一環として、アプリケーション全体でアイコンが一貫して正しく使われているかを評価する必要がありました。問題の規模や修正方法を理解するために、どのアイコンコンポーネントが使われているか、文脈に即して正しく使われているか、そしてWCAG AAの観点で本当のギャップがどこにあるのかを把握する必要がありました。
プロジェクトを一つひとつ手作業で確認していくのは骨の折れる作業でした。そこで、デザインシステムの利用状況データをもとに、エージェントに各アイコンの使われ方を文脈に即して評価させ、その結果をスプレッドシートにまとめさせました。
私は必要に応じてレビューと修正を行いましたが、私自身が費やす時間は劇的に少なくなりました。さらに重要なのは、実際のデータに基づいて次に何をすべきかを判断できたことです。
マイグレーションとアップグレード：設計するだけでなく、実行まで担う
問題の全体像を素早く把握できるようになると、次に自然と浮かぶのは、同じ方法で修正までできるのかという問いです。ここが、エージェントが私にとって最も大きなインパクトをもたらした領域です。マイグレーションガイドを共有するだけでなく、実際の変更を届けるところまで踏み込めるようになりました。
28のマイクロフロントエンドにまたがるReactアップグレード
マイクロフロントエンドにおけるReactアップグレードについての投稿を読んでいただいた方なら、この種の作業にどれほどの調整が必要かがおわかりいただけるかと思います。各プロジェクトは優先事項の異なる別々のチームがオーナーとなっています。手順が明確に文書化されたマイグレーションであっても、すべてのチームに実行してもらうのは大きな課題です。
最も積極的なチームがマイグレーションを完了した後も、最終リリースを妨げる多数のプロジェクトが残っていました。各チームが対応するのを待つのではなく、エージェントを使ってプロジェクトごとに個別に対応を進めました。マイグレーションガイドに沿って必要な設定変更を行い、プロジェクト固有の問題を解決し、MRを作成するという流れです。エージェントがマイグレーションの機械的な部分を担い、各チームには作業依頼ではなく、すぐにマージできる状態のコード変更が届く形になりました。
変更前
変更後
すべてのMRがマージされました。ロールアウト全体で発生した唯一の問題は、私のMRを出す前に手作業でマイグレーションを行っていたチームで起きたものでした。エージェントが生成した変更の方が、人が対応したものよりもクリーンな履歴になりました。
「MRが作成された」から「MRがマージされた」への転換率は、「マイグレーションガイドが送られた」から「作業が完了した」への転換率と比べて格段に高くなります。チームは今までどおりレビューし、マージし、コードのオーナーシップを持ち続けますが、マージまでに必要な作業は大幅に減ります。
CIパイプラインのリファクタリング
最近のGitLab CIのリファクタリングでも同様のことがありました。共有パイプラインを、非推奨となったonlyキーワードからrules構文へ移行する必要がありました。変更内容自体はよく理解されていましたが、パイプラインを利用しているすべてのプロジェクトで対応する必要があり、それぞれにクセがあり、時には破壊的な変更への対応も求められました。
通常、この種の変更はプロジェクト間で導入がばらつき、チームは強制されるまで対応を先延ばしにしがちです。こうした不統一は、プロジェクトごとにパイプラインの挙動が異なることで混乱を招きかねません。
エージェントを使って影響を受けるすべてのプロジェクトをプログラムで特定し、プロジェクトごとにマイグレーションを進め、遭遇した破壊的な変更に対処し、MRを提出することで、手作業で行う場合の何分の一かの時間で、すべてのプロジェクトに変更を届けることができました。
実践的なヒント
上記の例を読み返すと、簡単に思えるかもしれません。実際には、これらのタスクが安定してうまくいくようになるまで、かなりの試行錯誤がありました。カスタムのglabスキルが最も大きな成果であり、他のヒントもその試行錯誤から得られたものです。
ツール用のスキルを定義する
私が取り組んだ中で最も効果が大きかったのは、glab CLI（GitLabのコマンドラインツール）用のカスタムエージェントスキルを作成したことです。スキルとは、エージェントに特定の作業をどのように行うかを明確で実践的な指示を与えるMarkdownファイルのことです。このケースでは、プロジェクトを横断して検索する方法、MRを作成する方法、REST API経由でファイル変更を行う方法などを指示しています。
これがなければ、エージェントはGitLabとの連携を拒否するか、一貫性のない脆いbashのワンライナーを生成してしまいます。適切に定義されたスキルがあれば、信頼できるプレイブックを手にすることになります。Agent Skillsはオープンスタンダードであり、Cursor、Claude Code、GitHub Copilotといったツールでサポートされています。
MCP経由でエージェントに内部コンテキストを渡す
そのままのエージェントは、社内のシステムについて何も知りません。コードを読むことはできても、コンポーネントが本来何をすべきなのか、共有ライブラリの意図されたAPIがどのようなものかまではわかりません。
私はこれを、デザインシステム用のMCPサーバーで解決しました。MCP（Model Context Protocol）は、内部のデータやドキュメントを構造化されクエリ可能な形で公開し、エージェントが利用できるようにするオープンスタンダードです。私たちのサーバーはStorybookを基盤として構築されており、エージェントがコンポーネントのpropsや利用ガイドライン、サンプルにアクセスできるようになっています。エージェントがアクセシビリティの観点でアイコンの利用をレビューする際には、デザインシステムのアイコン関連コンポーネントがどのように使われることを想定しているかを参照できます。
MCPはオープンスタンダードであるため、同じサーバーがさまざまなツールで機能します。ただし、MCPサーバーの維持には継続的なコストがかかり、一度きりの投資で済むものではありません。私たちにとってはそれだけの価値がありましたが、エージェントにローカルのMarkdownファイルを参照させるだけでもよいですし、Confluenceに社内ドキュメントがある場合はAtlassian MCPのようなものを使う方法もあります。
監査データを出発点として渡す
エージェントにどのプロジェクトが特定のライブラリを使っているかを一から発見させるのではなく、答えを渡してしまいましょう。私たちはデザインシステムの利用状況を分析する仕組みを持っており、どのプロジェクトがどのコンポーネントをどのバージョンで使っているかを正確に把握できます。タスクの開始時にこのデータをエージェントに渡すことで、推測ではなく私たちの利用状況データから出発できるため、より速く、より正確になります。
あるプロジェクトで実験を進めています。組織全体の依存関係の利用状況をスキャンして解析し、エージェントがデータを直接クエリできるMCPツールを提供するものです。
事前の構造化でリサーチタスクのミスを減らす
プラットフォームチームでは、リサーチタスクが20以上のプロジェクトに影響する意思決定につながることが多いため、正確さが重要です。エッジケースを見落とした曖昧な要約は役に立たないだけでなく、誤った意思決定を招きます。
リサーチタスクでは、事前に出力フォーマットを定義することに時間をかける価値があると感じています。エージェントに「プロジェクト全体のアイコン利用状況を調査して」と漠然と頼むのではなく、1プロジェクト1行で埋めるべき具体的な列を備えたスプレッドシートのテンプレートを渡すのです。
こうすることで、エージェントは体系的に作業を進めるようになります。プロジェクトごと、列ごとに作業し、各行で何をもって完了とするかが明確になります。構造のないまま自由度の高いリサーチタスクを渡すと、エージェントは期待するよりも抽象度の高い要約をしてしまったり、自分で完了したと判断して途中で止めてしまったりしがちです。
マイグレーションガイドは従来どおり作成し、それをプロンプトとして使う
プラットフォームチームであれば、変更内容を利用側のチームに伝えるために、いずれにせよマイグレーションガイドを作成することになります。私が気づいたのは、同じガイドをエージェントに渡すこと自体が、有用な検証ステップになるということです。
エージェントが混乱したり、誤った方向に進んだりした場合、それは手順の抜けや曖昧さを浮き彫りにしていることがよくあります。ガイドでカバーされていなかったエッジケースも、エージェントが実際のプロジェクトで遭遇することで表面化します。いくつかのプロジェクトでエージェントを実行し終える頃には、ドキュメントのストレステストも完了しており、結果として、変更をレビューしたり手順を手作業で追ったりする必要のあるチームにとっても、より良いガイドになっているのです。
ツールについて
こうした作業には主にCursorを使っており、Claude CodeやGitHub Copilotでもいくつか試しています。正直なところ、ツール間の違いよりも、与えるコンテキストの質の方が重要です。適切に定義されたスキルと優れたMCPサーバーがあれば、ツールを切り替えるよりもはるかに大きな成果が得られます。
ここで使われているオープンスタンダード（コンテキストのためのMCP、エージェントの挙動を定義するMarkdownベースのスキルファイル）のおかげで、あるツールへの投資は大半が他のツールにも引き継がれます。プロバイダーやモデルによって価格が変動する中で、特定のワークフローに固執しすぎないためにも、この点は覚えておく価値があります。
何が変わるのか
エージェントは間違えることもあります。明確なコンテキストと適切に定義されたタスクが必要です。出力内容をレビューし、何が行われたのかを理解し、自身の判断を下す必要は依然としてあります。エージェントが苦手とするタスクもあり、望む結果を得るために計画段階で何度か試行錯誤が必要になることもあります。
「AIがエンジニアに取って代わる」という捉え方は、ここで本当に面白い点を見逃しています。私が経験したことに近いのは、こういうことです。一人のエンジニアが担えることの上限が上がったのです。
以前なら、28プロジェクトに影響する問題を見つけても、修正には数ヶ月にわたる調整が必要だと受け入れるしかありませんでした。今は、自分で修正し、チームには変更を依頼するのではなくレビューしてもらえばよいのです。以前なら、数十のリポジトリにまたがるリサーチタスクは1週間がかりの作業でした。今は半日で済むかもしれません。
これは重要なことです。プラットフォームチームは、担当領域の広さに対してほぼ常にリソースが不足しているからです。私たちは常に、何に取り組む価値があるかという難しい判断を迫られてきました。AIエージェントは、そこに関わる人間の判断を置き換えるのではなく、以前は法外なコストがかかっていた機械的な実行部分を担うことで、経済的に実行可能なことの範囲を広げているのです。
これには、プラットフォームの仕事ならではの、より個人的な側面もあると感じています。プラットフォームチームにいることの根強いフラストレーションの一つに、成果との距離を感じてしまうことがあります。変更を加えても、導入は遅く、展開はばらつき、何かが少し間違っていたと気づいたときには何ヶ月も経っている。リクエストに対応し、チームのブロックを解除し、必要とされるのを待つという、受け身な感覚に陥りがちです。
エージェントは、その力学を変えられると感じています。利用しているすべてのチームにすぐマージできるMRを届けることは、単に速いだけでなく、結果をすぐに確認できるという意味もあります。ブロッカーが数ヶ月ではなく数日で表面化します。これまで、デリバリーの多くを他チームが自分の作業を優先してくれるかどうかに依存していたプラットフォームの役割では得難かった、真のエンドツーエンドのオーナーシップを感じられるようになりました。
AIは主にコスト削減、つまり少ない人数で同じ仕事をすることだという語りがあります。ある文脈ではそれが当てはまるのかもしれません。しかし私の経験では、より面白い物語は、これまでやる価値がないとされていたことに取り組むという点にあります。より広い範囲をカバーし、より高い基準を維持し、そうでなければバックログに埋もれたままだったマイグレーションに取り組み、プラットフォームの意思決定と現実世界での成果との間のループをようやく閉じることです。
そこに私はワクワクしています。何が置き換えられるかという恐れではなく、何が可能になるのかという問いにこそ、心が躍るのです。