いま、AIをめぐってはノイズや誇大な期待が渦巻いており、議論の多くは雇用の代替やエンジニアが失うものに向けられています。ここでは逆の視点について書きたいと思います。この数ヶ月、プラットフォームチームでの日々の業務にAIエージェントを積極的に取り入れることで、私が何を得られたのかという話です。

魔法だと言うつもりはありません。エージェントは間違いを犯しますし、明確な指示を与えるために必要なエンジニアリングの知識を代替するものでもありません。ただ、エージェントと取り組んできた仕事の中には、明らかに一段違うと感じられるものがありました。コードを書くスピードは上がりましたが、より大きな変化はスコープです。これまでなら先送りにしていた仕事にも取り組めるようになったのです。

プラットフォームチームが抱える課題

プラットフォームチームの課題についての以前の記事を読んでいただいた方なら、この背景はご存知かと思います。小さなチームで、広大な領域を担っているということです。常時、共有サービスやライブラリ、28のプロジェクトにまたがるマイクロフロントエンドアーキテクチャ、CIパイプラインなど、さまざまなものを維持しています。

プラットフォーム業務の歯がゆい現実は、最も難しい問題が必ずしも技術的ではないということです。むしろ組織的な問題であることが多いのです。20以上のプロジェクトにまたがって修正が必要な箇所を見つけ、修正内容が明確にわかっていても、完了までに数ヶ月かかることがあります。各チームがそれぞれの優先事項を抱えており、それが必ずしもプラットフォームチームの取り組みと一致しないからです。プラットフォームチームの課題は、「やるべきだ」と「チームに実行する余力がある」の間にあるギャップを埋めることにあります。

エージェントは、私が予想もしなかった形でそのギャップを埋め始めています。

調査タスク：横断的な意思決定を現実的にする

プラットフォームチームにおいて、最も重要な意思決定ほど、自信を持って下すのが難しいものです。サービスを廃止するにせよ、ライブラリを置き換えるにせよ、組織全体で新しい標準を徹底するにせよ、誰に影響が及ぶのか、エッジケースがどうなっているのかを理解する必要があります。この調査作業は常にコストが高く、結果として不完全な情報のまま判断を下してしまったり、誰も適切に調査する余力がなく決定を無期限に先延ばしにしてしまったりすることになりがちでした。

レガシーサービスを理解する

何年も前から存在するサービスがありました。明確なオーナーもおらず、ドキュメントも最小限で、繰り返し浮上する疑問がありました。いったい誰が、どのように使っているのか？という問いです。サービスは廃止すべきだと感じていましたが、実際の利用状況を把握するまでは移行について明確な判断ができませんでした。その答えを得るには、GitLab上で依存関係を手作業で追跡し、レガシーなSVNリポジトリを掘り返し、とっくに去った人々が何年も前に書いたコードから全体像をかき集める必要がありました。

エージェントを使うことで、その発見作業の大半を任せることができました。エージェントはGitLabとSVNの両方にまたがる利用側プロジェクトを横断し、呼び出し箇所を特定し、サービスが異なる文脈でどのように使われているかを要約し、注意すべきエッジケースをフラグ付けしてくれました。本来なら2日ほどかかったであろう作業が、ごく短時間でレビューし、さらに発展させられるものになったのです。

人間の判断や影響を受けるチームへのフォローアップが不要になるわけではありませんが、調査作業自体ははるかに扱いやすくなりました。

アイコンの利用状況と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行、完了すべき具体的な列を持つスプレッドシートのテンプレートを渡すのです。

これにより、エージェントは体系的に作業を進めるようになります。プロジェクトごと、列ごとに作業し、各行で完了の定義が明確になります。構造のないオープンエンドな調査タスクを与えると、エージェントは期待よりも抽象度の高い要約をしてしまったり、自分は完了したと思い込んで早々に止まってしまったりしがちです。

マイグレーションガイドは書いた上で、プロンプトとして活用する

プラットフォームチームであれば、変更を利用側チームに伝えるために、いずれにせよマイグレーションガイドを書くことになります。私が気づいたのは、同じガイドをエージェントに与えること自体が、有用な検証ステップになるということです。

エージェントが混乱したり、間違った方向に進んだりした場合、それは大抵、指示の抜けや曖昧さを示しています。ガイドでカバーされていなかったエッジケースは、エージェントが実際のプロジェクトで遭遇したときに表面化します。いくつかのプロジェクトでエージェントを実行し終える頃には、ドキュメントのストレステストも完了しており、結果として変更をレビューしたり手順を手動で追ったりする必要のあるチームにとっても、より良いガイドになっているのです。

ツールについて

私は主にこの種の作業にCursorを使っており、Claude CodeやGitHub Copilotでもいくつか試しています。正直なところ、ツール間の違いは、与えるコンテキストの質ほど重要ではありません。適切に定義されたスキルと優れたMCPサーバーがあれば、ツールを切り替えるよりもはるかに遠くまで行けます。

ここでのオープンな標準（コンテキスト用のMCP、Markdownベースのスキルファイル）のおかげで、あるツールへの投資は大方ほかのツールにも引き継がれます。プロバイダーやモデル間で価格が変動する中で、一つのワークフローに固執しすぎるのではなく、この点を念頭に置いておく価値があります。

これが何を変えるのか

エージェントは間違いを犯します。明確なコンテキストと適切に定義されたタスクが必要です。出力は今もレビューし、何がなされたかを理解し、自分自身の判断を適用する必要があります。エージェントが苦手とするタスクもあり、望む結果を得るために計画段階で何度か反復が必要なこともあります。

「AIがエンジニアに取って代わる」というフレーミングは、ここで本当に面白い点を見逃しています。私が経験したことに近いのは、こういうことです。一人のエンジニアが担えることの上限が上がったのです。

以前なら、28のプロジェクトに影響する問題を見つけても、修正には数ヶ月の調整が必要だと受け入れていました。今は、自分で修正してしまい、チームには変更を自分たちで行うよう依頼するのではなく、作業をレビューしてもらえばよいのです。以前なら、数十のリポジトリにまたがる調査タスクは1週間がかりの作業を意味していました。今なら、半日で済むかもしれません。

これは重要なことです。プラットフォームチームは、担う領域に対してほぼ常にリソースが不足しているからです。何に取り組む価値があるかについて、常に難しい判断を迫られてきました。AIエージェントは、人間の判断を置き換えることによってではなく、かつては法外なコストがかかっていた機械的な実行を担うことで、経済的に実行可能なことの幅を広げているのです。

これには、プラットフォーム業務に特有だと思う、より個人的な側面もあります。プラットフォームチームにいることの根強いフラストレーションの一つは、インパクトからの距離を感じることです。変更を加えても導入は遅く、ロールアウトはばらつき、何かが少しおかしかったと気づいたときには、すでに数ヶ月が経っています。リクエストに対応し、チームのブロックを解除し、必要とされるのを待つという、受け身な感覚に陥りがちです。

私が気づいたのは、エージェントがその力学を変えうるということです。利用側のすべてのチームにマージ可能なMRを届けることは、単に速いだけでなく、結果をすぐに確認できるということでもあります。ブロッカーは数ヶ月ではなく数日で表面化します。これまで、デリバリーの多くが他チームによる優先付けに依存していたプラットフォームの役割では得がたかった、真のエンドツーエンドなオーナーシップの感覚があります。

AIは主にコスト削減のためであり、少ない人数で同じ仕事をするためのものだという語りがあります。ある文脈ではそれが真実かもしれません。しかし私の経験では、より面白い物語は、以前はやる価値がなかったことをやることにあります。より広い範囲をカバーし、より高い水準を維持し、さもなければバックログに永遠に残り続けたであろうマイグレーションに取り組み、プラットフォームの意思決定と現実の成果との間のループをようやく閉じることです。

それこそが、私をワクワクさせていることなのです。何が置き換えられるかという恐れではなく、何が可能になるのかという問いです。