AIを活用したテスト自動化ツールの開発で協業
オーティファイは、テスト自動化のツールを開発・提供する企業。末村氏は、まず簡単にいくつかのツールの特徴を説明した。
例えば、AIによってエンドツーエンドのテストを自動化できるツール「Autify Nexus」は、自然言語によるテストシナリオ作成・修正や、仕様書からのテストケース作成まで行う。
「従来の自動化ツールは、操作ログをもとにテストを生成するものが多かったが、Autify Nexusはチャットの指示でテストを実装できる。画面の横に出てくるAIエージェントに、どういうテストを作りたいか指示するだけで、AIがUIを考慮しながらテストを作成してくれます」（末村氏）
また、ダイキン工業と協業して開発した「Autify Genesis 2.0」についても説明した。これは仕様/テスト駆動開発AIエージェントシステムと表現され、ソフトウェア開発に必須の「仕様」「コード」「テスト」の3つをバランスよく作成するためのツールだという。
仕様書の作成、それを基にしたテストケースの生成、仕様・コード・テストの全容を理解したAIチャットによる疑問解消といった機能を備えている。いくらテストを自動化しようとしても、仕様書がしっかり書かれていないと適切なテストを設計できない。「そういった課題意識をダイキン工業も持っていたため、仕様書の作成から支援するAutify Genesis 2.0の開発に協力してくれた」と末村氏は説明した。
続いて五十嵐氏が、自身の業務について簡単に紹介した。
五十嵐氏はダイキン工業のR&D部門にあたるテクノロジー・イノベーションセンターに所属し、開発プロセスにおいて生成AIを活用するための検証や現場支援を行っている。
ダイキン工業のソフトウェア開発の現場でも、世の中の流れと変わらず、生成AIの導入が進んでいる。
ChatGPT Enterpriseや社内版チャットボットの導入、GitHub Copilotの利用のほか、社内の開発者コミュニティでAIエージェントを特に活用しているメンバーからの情報共有や勉強会が開かれている。また、五十嵐氏のチームが主導してコーディングエージェントの検証やトライアルも推進しているという。
生成AIの登場で、新規・既存開発はどう変わった？
生成AIが開発現場に浸透するにつれて、ダイキン工業ではどのような変化が起きたのか。五十嵐氏は、生成AIの影響は「新規開発・PoCと、既存プロジェクトで異なる」と分析する。
新規開発やPoCにおいては、「動くものを作って試し、それを壊してまた作る――といったサイクルを高速に回せるようになった。開発者個人単位でかなり生産性がアップしている」と大きな効果を指摘した。
一方、既存プロジェクトにどう生成AIの効果を発揮できるのかについては、「まだ検証中」だと語る。
「新規開発とは異なり、既存プロジェクトで生成AIを適用する難しさは、背景情報が多い点にあります。既存プロジェクトの設計方針に沿った実装になっているか、追加開発が既存機能に影響を与えないか、あるいは仕様が正しく反映されているかなど、考慮すべき点が多岐にわたるからです」（五十嵐氏）
そのため、既存プロジェクトに生成AIを活用するには土台整備が必要となる。その一歩目としてダイキン工業では「テストの整備にフォーカスして取り組んでいる」と五十嵐氏。
その土台整備の一歩目のテストにも、生成AIは活用できる。どのような考え方で、生成AIの取り組みを進めているのか、パネルディスカッション形式で語った。
生成AI活用で変わるもの、変わらないもの
まず、末村氏が「生成AIの登場によって、社内の開発に対する考え方・やり方の変化」があったか尋ねた。
五十嵐氏は先述の「トライアル的な開発がやりやすくなった」ことのほかに、生成AIの活用によって、開発生産性が上がったことでアウトプットの質をより高められるようになったと話した。
要件が多く、工数の見積もりもシビアな大規模プロジェクトにおいては、リソースや時間・コストの問題があってすべてを理想的に進められてはいなかった。生成AIの登場によって、追加の開発で設計を変えたり、リファクタリングしたりといった、これまでなかなか手を出しづらかった活動にも、挑戦できるようになったという。
末村氏が「アウトプットの量に関してはどうか」と尋ねると、五十嵐氏は「開発できる量も確実に増えている」としたうえで「生成AIが一発で正しいアウトプットを出してくれるかというのはまた難しい問題」と答えた。その正しいアウトプットを保証するために、テストという軸を整えている最中だ。
一方で、生成AIが開発に浸透しても変わらない部分もある。五十嵐氏は「テストしやすいアーキテクチャや設計、レビューしやすい粒度といった、人間の認知負荷を下げるアプローチは引き続き必要なのでは」と提言。
「人間がやっていたタスクを生成AIが行うようになっても、時間が短くなっただけで構造としては同じ。生成AIでいうコンテキストウィンドウが人間の認知と同じようなものだと考えていて、そこに収まる範囲での作業が理想なのでは」と持論を話した。
続いてのテーマとして、「AIに任せられるところ・任せられないところの違いは？」と尋ねた末村氏。「バイブコーディングには限界があるという話が話題になっていて、AIに任せられるところとそうでないところの選定は、人間が行わなければならないのではないか」と問いかけた。
これに対して五十嵐氏は、「なんとなく頭の中にある複雑な実装や、コンテキストを渡しにくいものはAIに任せづらい」と考察する。
「例えば、実行環境がCLIツールと別のウィンドウで開いている場合など、背景を人間しか理解していない状況でタスクを任せると、認識の齟齬が生じやすい。逆に言えば、コンテキストを適切に渡せるような仕組みを整えれば、複雑な実装もAIに任せることが可能だと考えています」（五十嵐氏）
AIがコンテキストにアクセスしにくいものには、例えばハードウェアの情報などがある。エアコンのリモコンに表示されている温度を把握するには、人間なら目視で確認すればよいが、AIが理解できるようにするためには工夫が必要になる。
末村氏が「ダイキン工業のAI活用においては、そういったハードウェアとソフトウェアの連動に関しても工夫が求められるのではないか」分析すると、「まさにトライしている最中」と五十嵐氏。「物理世界はアクセスしづらいので、IoTシステムへの生成AI活用はより難しくなる。人間がやらなければいけない部分もあり、工夫してテストを重ねていく必要がある」と説明した。
最後に、「AIと共に歩む時代、これからの開発のあり方」をどう考えているか、二人がそれぞれ語った。
「生成AIは大量のアウトプットを出してくる。そのすべてに目を通すのは大変なので、仕組みを工夫する必要があります。そこで今思い描いているのは、テストをしっかり整備し、それが動く状態を保ったまま次はコードを変えていく……というプロセスです。テストを起点にそういったサイクルを早く回していくことが重要だと考えています」（五十嵐氏）
これを受けて末村氏は「すごく面白い考え方。『テストから何かを始める』というアイデアは昔からあった。今、生成AIが膨大なアウトプットを作るようになったことで頻繁に検証することの重要性が高まってきた。これにより、十分な情報を必要な時に与えられる環境も重要になってきている」と考察した。
五十嵐氏は今後の展望について、「現在は生成AIを使ってドキュメントからテスト、テストを起点にコードを書くといった、ドキュメント・テスト・コードを三位一体で表現するアプローチを模索しているところ。これからもトライアルアンドエラーでノウハウを見つけていこうと思います」と締めくくった。
