マイグレーションのためのカスタムエージェントスキルの育て方

わたしたちが開発するプロダクトは、数多くのフレームワークやライブラリに支えられています。

それらのソフトウェアは沢山の開発者の献身によって継続的にメンテナンスされ、セキュリティパッチがあてられ、新しい機能が追加され、バージョンがあがります。そして、それらの変更を適用するために、わたしたちはマイグレーション作業を行います。このフローは、ユーザーに価値を届け続けるために必要不可欠なものです。

しかし、マイグレーションのような技術基盤のメンテナンスは、機能開発のようにわかりやすく直接的に価値を生み出すものではありません。とても地味でたいして面白くもありません。ですから、よりクリティカルである機能開発にリソースを割けるように、メンテナンス作業はコンパクトに計画したいものです。

この記事では、マイグレーションのフローをどのように効率化できるかについて考えていきます。なお、ここで取り上げるのは MUI v5 から v6 へのマイグレーションの事例です。現在目下作業進行中なので確定的な数値は出せませんが、ヒトの判断負荷が軽減されたという手応えを感じます。

マイグレーションは地味で面倒だ

開発者の方は一度は苦労した経験があると思いますが、マイグレーション作業は非常に地味で面倒です。特に破壊的変更を伴うメジャーバージョンアップなどでは API から変わっているケースも多く、とても一筋縄ではいきません。マイグレーションは手間と時間がかかるものです。

さらに、マイグレーションは時にわたしたちの仕事を増やします。例えばマイグレーションの作業中にはこんなことが起こり得ます。

• 他の重要な機能開発タスクにより main ブランチのコードベースに大きな変更が加わる。
• コンフリクトが発生するため解消する。
• その影響でテストが落ち、再検証と再レビューを行う。
• マイグレーション作業のマージは延期となり、さらに他のタスクとも衝突する。
• 以下繰り返し。

マイグレーションに限った事ではないですが、プルリクエストが長生きすればするほど、やらなくてもよかった仕事がどんどん増えていきます。こういったリスクや痛みを小さく抑えるためにも、マイグレーションフローはここぞというタイミングでコンパクトに素早く片付けたいものです。

カスタムエージェントスキルの整備と運用

マイグレーションフローをスピードアップするために工夫したのが、カスタムエージェントスキルです。具体的にイメージしやすいように、ここから先は MUI のバージョンアップに伴うマイグレーションについて考えてみましょう。

ネットを探索すれば MUI のマイグレーション用のエージェントスキルは見つかりそうですが、ここでは独自のカスタムスキルを採用しています。すべて面倒をみてくれる汎用的なスキルより、出来る限り目的をフォーカスしたカスタムスキルのほうが精度と再現性が高くなり、プロジェクトにしっかり刺さるのではないか、と考えたからです。

ここからは、プロジェクトに特化したスキルの作り方を考えてみましょう。

1. 目的を絞り込んで骨子をつくる

ベースの作成は、 /skill-creator などにお任せします。ここで「MUI をマイグレーションするスキル」などと大雑把な指示をしてしまうと、すべてのバージョンがマイグレーションができる汎用的なスキルが出来上がりますが、今回欲しいのは目的に特化した最適化されたスキルです。

MUI v5 から v6 へのマイグレーションを行うスキル

こんな感じにバージョンを決め打ちしてしまうことで、出来ることを制限してシャープに働くスキルを作ってもらいます。

2. グレーゾーンに境界線を引く

たたき台のスキルができたら、判断のグレーゾーンが大きすぎないかチェックさせます。

このスキルを実行させた場合に判断に迷いそうな箇所はないですか？

このようなプロンプトを投げれば、判断が揺れそうな曖昧なパターンを洗い出してくれるでしょう。それらのパターンに対して判断基準を明確にしてやることで、再現度を大きく向上させることができるはずです。

例えば、MUI の古い API である makeStyles で組んであるスタイルをマイグレーションする場合、 sx で書き換えるか styled に置き換えるか判断に迷う場合があります。そこに具体的な判断基準を注入してやります。

• 適用されているスタイルが少ない場合は sx を採用
• styled として外に切り出す対象の要素が少ない場合は styled を採用

このように具体的な判断材料が与えられていればスキルは再現性をもって判断することができるようになり、マイグレーションの結果がブレにくくなります。

3. コードベースでシミュレートする

さらに再現性を高めるために、実際のプロジェクトのコードベースでドライラン（gitで一瞬で戻せるのでドライランでなくても良いのですが）のシミュレーションをさせ、パターンを学習してもらいます。例えば、こんな具合に指示を出してみましょう。

1. コンポーネントの選定とシミュレーション： 現在のコードベースから、サイズ（小・中・大）や内部構成（状態管理の有無、外部ライブラリ依存、API通信の有無など）が異なるコンポーネントを複数ピックアップし、マイグレーションをシミュレートしてください。
2. 網羅性の確保： できるだけ多くの実装パターンを網羅し、エッジケース（特殊な実装や古い記法など）が含まれるように考慮してください。
3. スキルの拡張（自己学習）： シミュレーション中に判断に迷うケースや、既存のルールでは対応できないケースが発生した場合は、それを「新規パターン」として整理してください。
4. アウトプット： シミュレーション結果のサマリーと、それに基づきアップデート・追記したスキルの内容を報告してください。

性格やレイヤーが異なるコンポーネントをサンプルとして採用することで、出来る限り多くのパターンをカバーできるようにスキルを磨き上げます。

4. より多くのパターンをカバーさせるために

AI がピックするサンプルは偏ることがあります。パターンを満遍なく拾わせるために、AI に「なぜこれらのコンポーネントをサンプルに採用したのか」を説明させ、ヒトはそれを見て批判的な態度でレビューをします。プロジェクト内に特殊な作り方をしたコンポーネントがあったり、カバーされていない層があれば、それらもサンプルに追加してもらいます。

わたしのケースでは、サンプルに選ばれたのがどれも末端のコンポーネントばかりで、ページコンポーネントのような上位の層がカバーされていなかったため、追加でシミュレーションをまわしてもらった結果、さらに５つのパターンを新たに学習してくれました。

5. 運用しながらのブラッシュアップ

それでもやはり、スキルが想定しないパターンというのは存在します。そういった死角はたいてい実際のマイグレーション作業中に明らかになるので、その都度スキルに学習させて継続的にスキルの精度を向上させていきます。

ソフトウェアが常に改善されていくのと同じように、スキルもまた完成することなく学習を重ねて磨かれていくものです。

このようにして、シャープに磨き上げたスキルにより、ここぞというタイミングで一気に終わらせるというのが、現代のマイグレーションの解のひとつなのだと考えます。

ヒトの判断負荷の軽減

実際にこのスキルを運用してみて、もっとも変化を感じられるのは「ヒトが立ち止まって考える回数」の減少です。

ヒトが直接マイグレーション作業に取り組んだ場合、1コンポーネントを処理するたびに「これは sx か styled か」「props の受け渡しをどう変えるか」など、小さな判断ポイントで手が止まってしまいます。これらの判断基準はスキル側に書かれているため、ヒトの仕事は出力結果が「想定通りか」「外れているか」だけ見ればよくなります。体感としては、1コンポーネントあたりの判断負荷は半分以下に減った印象です。

さらに重要なのは、同じパターンの判断を何度も繰り返さなくなることです。一度迷ったケースをスキルに反映してしまえば、次に同じパターンが現れたときには考えなくて済みます。

おわりに

マイグレーション作業というのは機能開発とは違って、直接的には価値を生み出さないものです。しかし、セキュリティ等の観点からもライブラリの最新バージョンに追随しつづけるために非常に重要なプロセスです。わたしたち Gaji-Labo では、そういった目立たないところも大切に取り組んでいきます。

ただ、より注力したいのは、ソフトウェアが提供する体験の改善にクリティカルに貢献する部分です。ですから、そこに集中できるようにマイグレーション作業はできるだけ速やかに、コンパクトに終わらせたいものです。

AI 技術の発達によって、ヒトがコストを割くべき部分に正しく割くことができるようになりました。Gaji-Labo では、AI と上手に協業しながら、私たちエンジニアが本当に価値を生む仕事へとリソースを振り向けていけるように工夫を重ねていきます。

Gaji-Labo Culture Deck