-AI コーディングからテスト・運用まで、開発プロセスはどう変わるべきか-
1. AIにコーディングを任せる方法が変わった
AIを開発に本格的に使い始めてから、わずか数か月で、自分でコードを書くことはほとんどなくなりました。最初は必要な機能を説明してコードを作ってもらう程度でしたが、今ではAIと開発目標を計画し、詳細な計画を立てたうえで、実装と検証まで進めています。
また、AGENTS.mdを通じてプロジェクトの構造やルールをあらかじめ伝え、そのルールの中で作業させるようにしました。SKILL.mdを通じて、作業ごとに必要なコンテキストだけを集中的に提供することもあります。AGENTS.mdがプロジェクト全体に常に適用される共通ルールだとすれば、SKILL.mdは現在の作業に必要な知識や作業方法を選択的に提供する役割に近いものです。1つの作業で複数のSkillを組み合わせて使うこともできます。
状況に応じて、複数のモデルを役割ごとに使い分けることもあります。複雑な分析や設計は性能の高いモデルに、トークン消費の大きいコード生成は比較的安価なモデルに任せます。その後、別のモデルを使って、抜け漏れや実装の完成度などをクロスチェックすることもあります。複数のモデルを使う理由は、コストを抑えながら異なる視点で結果を検討するためです。もちろん、お金に余裕があるなら、最高級のモデルだけを使うのもよいでしょう。
2. 膨大な量のコード、テストに通ったから安心してよいのか？
AIを使えば、以前よりはるかに短い時間で大量のコードを作成できます。問題は、コードの量が増えた分、人間が一つひとつ確認するのがさらに難しくなったことです。AIに機能の実装を依頼すると、もはやコードだけを書いてくれるわけではありません。必要なテストコードも一緒に作成してくれます。ビルドも成功します。JUnitテストもすべて通過します。別のAIにコードレビューを依頼しても、特に問題はないと言われます。
それなら、もう安心してよいのでしょうか。少し考えてみると、そうとは限りません。コードを作ったのもAIであり、どのようなテストが必要かを判断したのもAIです。AIが必要だと考えた数個のテストに通ったからといって、そのプログラムが十分に安全だとは言えません。もちろん、これはAIが作ったコードだけの問題ではありません。私たちが自分でプログラムを作っていた時代にも、100％完璧なソフトウェアはありませんでした。十分なテストを経てリリースしたにもかかわらず、運用中に予想もしなかった問題が発生し、私たちはログを確認して原因を分析し、コードを修正しました。そして、同じ問題が再び発生しないようにテストを追加しました。
このプロセスは、以前から行われてきたソフトウェアエンジニアリングです。AIがコードを作るからといって、この原則が変わるわけではありません。ただし、コード生成の速度がはるかに速くなったため、検証方法もその速度に合わせて変える必要があるのではないかと思います。特に、単純な画面上のエラーと、次のような問題を同じレベルで扱うことはできません。
-
他のユーザーのデータにアクセスできてしまう権限の問題
-
異常な入力を利用した攻撃
-
同じリクエストが複数回処理される問題
-
複数のリクエストが同時に届いたときに発生するデータエラー
-
決済や精算金額が誤って処理される問題
-
開発者がまったく想定していなかった実行順序
コードを作る方法がAI時代に合わせて変わっているのであれば、検証する方法も同時に変わる必要があります。
3. テストの自動化にもAIを組み込もう
たとえば、会員情報を更新するAPIを1つ作ったとしましょう。通常なら、次のようなテストを考えることができます。人間ならいくつか確認して先に進むところでも、AIにはここからさらに多くのバリエーションシナリオを作らせることができます。
だからといって、別途巨大なテストシステムを最初から作る必要はありません。すでにAIコーディングツールは、プロジェクトのコードを読み、コマンドを実行し、テスト結果やエラーログを確認できます。まずは、既存のJUnitテストを実行させ、失敗結果を分析したうえで新しいテストケースを追加させることから始められます。Web画面であれば、PlaywrightやSeleniumなどの既存のブラウザー自動化ツールを利用できますし、セキュリティ検証にはZAPなどのツールを活用できます。最近のPlaywrightのように、AIを利用したテストの生成や修正機能そのものを提供するツールも登場しています。
結局のところ、新しいテストツールを最初から作るのではなく、すでに使っているJUnit、Playwright、Selenium、ZAPなどのツールの前後にAIを組み込むのです。コード生成ですでに行っているように、テストでもシナリオを作成し → 実行し → 結果を確認し → 不足しているテストを再び追加する、というプロセスを繰り返させます。
これだけでも、開発者が自分で考えて作成しなければならなかったテストのかなりの部分を減らせそうです。しかし、ここにも1つ限界が残ります。どれだけ多くのテストを作っても、結局は開発段階で考え出した範囲内で動いているという点です。それでは、私たちが考えも及ばなかった問題は、どこで見つけられるのでしょうか。
4. 運用で得たデータをテストに戻せないか？
どれだけ多くのテストを行っても、実際の運用では予想していなかった問題が発生します。これも新しい話ではありません。これまでも運用ログやモニタリング情報を確認して問題の原因を探し、修正したうえで、同じ問題が再び発生しないようにテストを追加してきました。
|
AI時代には、このプロセスももう少し自動化できるのではないでしょうか。 |
|---|
たとえば、運用中にこのような問題が発生したとしましょう。従来なら、開発者がログを確認し、原因を探して修正していたはずです。AIを使えば、運用記録から問題の原因候補と再現条件を見つけ出し、それを新しいテストにすることができます。そして、実際に発生した1つの問題だけで終わらせず、似た問題が発生する可能性のある別の条件まで広げてテストを作ることもできます。たとえば、応答の遅延後にユーザーが再度リクエストしたことで問題が発生したなら、リトライが複数回発生する場合や、複数のリクエストが同時に届く場合まで追加で作成するのです。結局重要なのは、運用で得た経験を1回の障害対応で終わらせず、次のテストに再び反映することです。
実のところ、これも完全に新しい方法ではありません。昔から使われてきた方法です。AI時代だからといって、従来のソフトウェアエンジニアリングがなくなるわけではありません。むしろ、既存の方法にAIを加え、人間が多く行っていた分析、新しいテストケースを考える作業、運用で見つかった問題を再びテストに反映する作業まで、少しずつ自動化していくことに近いのです。
5. 巨大なソリューションがなければ始められないのか？
まだ私は、この全体構造を自分で実装したわけではありません。そのため、具体的な実装方法を断定的に語るには、まだ学ぶべきことも多くあります。しかし、必要な技術のかなりの部分はすでに存在しています。
-
JavaのテストにはJUnit
-
ブラウザテストの自動化にはSeleniumやPlaywright
-
セキュリティテストにはZAP
-
フローをつなぐ自動化ツールとしてn8n
-
内部コードや運用データを外部に送るのが難しい場合にはローカルLLM
たとえば非常に単純化すると、ローカルLLMがテストシナリオを作成し、JUnitやPlaywright、Selenium、ZAPなどのツールがそれを実行します。その結果とログを再びAIが分析し、新しいテストを追加するという流れを考えることができます。内部コードや運用データを外部に送るのが難しい環境であれば、このAIをローカルLLMで構成することもできます。n8nのようなツールは、このプロセスをつなぐ役割を果たせます。
たとえば、非常に単純な図にすると、次のようになります。
最初から巨大なシステムを作る必要はありません。今、コード生成で行っているように、まずは1つの作業をAIに任せ、効果があれば少しずつ自動化の範囲を広げていけばよいのです。
おわりに
最近、多くの企業がAX(AI Transformation)について語っています。しかし、顧客の業務やシステムをAI中心に変えていくと言いながら、それを作る私たちの開発方法が昔とまったく同じだとしたら、少し不思議ではないでしょうか。AIを使ってコードを作ることは、その変化の始まりにすぎないと思います。コードを作る方法がAIによって変わったのであれば、テストする方法も、テスト結果を分析する方法も、AIを使って変わっていくべきです。
もちろん、これらすべてを一度に変えることはできません。1つずつ変えていけば、最終的にはソフトウェアを作る全プロセスそのものが、AI時代に合わせて変わっていくでしょう。今重要なのは、完璧なコードを一度に作ることではなく、完璧ではないソフトウェアの問題をより早く見つけ、より早く検証し、その経験を次の開発に再び反映できる構造を作ることだと思います。
コード生成から始まった変化が、検証と運用まで1つずつつながっていくとき、初めて開発プロセスもAX時代に入るのではないでしょうか。
zacca