生成AIと進める、制約ある環境でのテストコード導入

株式会社メドレー 医療プラットフォーム本部の山下です。
医療機関業務支援システム「@link（アットリンク）」の開発業務に従事しています。

アットリンクの開発現場ではテストコード導入に向けて準備を進めています。
本記事では、制約ある環境下でどうやってテストコード導入しようとしているか、その実践内容をお届けします。

この記事は 「MEDLEY Summer Tech Blog Relay」 20 日目の記事です。

開発環境

PHP7
Laravel7

この記事で書かないこと

現在の環境にテストコードを導入することを優先事項としているため、言語やフレームワークのバージョンアップについては本記事へ記載しません。

はじめに

アットリンクの開発では、リグレッションテストの多くを人手で実施しています。しかし、開発規模が拡大するにつれ、その手法に限界を迎えつつあります。

以前アットリンク開発チーム内で、一部機能のみテストコードを導入した際、リリース時の「圧倒的な安心感」を経験していました。この成功体験をチーム全体へ広げたい。そして、その挑戦を後押ししてくれたのが、「生成AI」の存在でした。

工夫のしがいがある開発環境

アットリンクの環境は、「歴史の重み」が存在する、チャレンジングなものです。

• フレームワーク: Laravel 7
• コード: サービスの成長と共に拡張されてきた、大規模なコード
• 仕様: ドキュメントは存在せず、まさに「動いているコードが正義」という状況
• アーキテクチャ: 大部分のロジックがControllerに集約されており、データベースと密結合な状態

これらに加え、技術的には以下のような課題も抱えています。

• 機能面の課題: 全国展開しているサービスのため、提供機能も多岐にわたります。その結果、データパターンが非常に複雑化しており、人手による網羅的なリグレッションテストが困難になっています。
• 構造面の課題: 長年の改修を経て、単一のモジュールや関数に複数の役割が詰め込まれていたり、役割が不明確なものが多数存在します。これにより、テスト観点が膨大になりがちです。

こうした制約は、決して珍しいものではないはず...。今回は、この環境で、いかにしてテストコード導入という新たな文化を根付かせようとしているか、ご紹介します。

導入の工夫：巨大機能へ「カバレッジ20%」から始める

「小さく始める」セオリーに反するように聞こえるかもしれませんが、最初のターゲットに選んだのは、ビジネスインパクト・ソース行数が非常に大きい中枢機能です。もちろん、この巨大な機能のテストを100%網羅するのは現実的ではありません。

そこで、目標設定を工夫しました。具体的には「ブランチカバレッジ20%の達成」を最初のマイルストーンに据えました。これにより、最も重要なロジックから優先的にテストで保護することができる見込みです。対象は大きいですが、目標を絞ることで「小さな導入」を実現しようとしています。

生成AIの活用：“プロンプト”への視点転換

テストコード導入の背中を強く押してくれたのが、生成AIの存在でした。しかし、当初はAIにうまく意図が伝わらず、期待したコードが得られないこともしばしばでした。

転機となったのは、社内の輪読会で出会った一冊の書籍、『LLMのプロンプトエンジニアリング』です。

この本で得た最大の気づきは、「LLMは対話しているのではなく、与えられた文書の続きを予測・補完しているだけ」 という視点でした。この前提に立つと、なぜプロンプトを構造化する必要があるのかが腑に落ちます。

それ以降、私は徹底してプロンプトを以下の4つの要素に分けて記述するようになりました。

• 依頼: （例：このPHPのメソッドに対するテストコードを生成してください）
• 依頼の背景: （例：これはLaravel 7のControllerにあり、特定のビジネスロジックをテストしたい）
• 制約条件: （例：DBのモックは使用せず、サービスクラスのモックを使用してください）
• 出力形式: （例：@test アノテーションを付け、メソッド名は日本語にしてください）

この工夫により、AIから返ってくる回答の精度は劇的に向上し、テストコード実装導入に向けて効果的に対応を進められていると感じます。

知見をチームに広げる取り組み

今回の挑戦は、私一人のもので終わらせるのではなく、チーム全体の文化として根付かせることを目指しています。そのために、アットリンク開発メンバーが誰でも再現できるよう、工夫も同時に進めています。

• プロジェクト情報のドキュメント化: なぜテストコードを導入するのか、どのような方針で進めるのかといった検討経緯や、議事録、定期的な振り返りの内容をすべてドキュメントとして残しています。これにより、後から参加したメンバーも背景を理解しやすくなります。
• 得られた知見の共有: 特に、効果的だったプロンプト設計のパターンや、AIとの対話で見つけ出したテスト観点などは、具体的なノウハウとしてドキュメント化を進めています。他のメンバーが同じような課題に直面した際に、すぐに参照できる「生きたドキュメント」を目指しています。

まとめ

テストコードが品質や開発体験を向上させることは、誰もがご存じだと思いますが、私たちのチームもそうであったように、「歴史あるコード」「古いフレームワーク」といった現実的な制約を前に、「できるわけがない」と一歩を踏み出せずにいる方は多いのではないでしょうか。

その重い腰を上げるきっかけとなったのが、生成AIの存在でした。AIは完璧なコードを一度で生み出す魔法の杖ではありません。しかし、テストコードの骨子作成や、自分だけでは気づけなかったテスト観点の洗い出しを手伝ってくれる「賢い壁打ち相手」として、導入への心理的ハードルを大きく下げてくれました。

今回の取り組みは、まだ始まったばかりです。まずは「中枢機能へのテストコード導入」が当面の目標です。そしてその先には、この文化をアットリンク開発メンバー全員に広げ、誰もが当たり前にテストコードを書けるチームにしていく、という未来を目標にしています。

※メドレーでは生成AI利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。

---

MEDLEY Summer Tech Blog Relay 21日目は、医療プラットフォーム本部 山田さんの記事です！お楽しみに！