RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

生成AIを業務利用して感じたこと、これから意識したいこと

はじめに

こんにちは、サーバサイドエンジニアの rakusksato です
2023年皆さんにとって1番のトピックは何だったでしょうか?
個人的には生成AIの登場、主にChatGPTGitHub Copilotでした。

ラクスでは、生成AIを積極的に業務へ取り入れています。
今回は約1年間、生成AIを業務利用してみて感じたことを対話型AIGitHub Copilotについてそれぞれ分けて話していきたいと思います。

対話型AI(ChatGPT, Copilot Chat, Microsoft Bing, Google Bardなど)

メリットとして特に感じたのは、

漠然としたアイデアから具体的なアウトプットを高速に生成できる

対話型AIは抽象的な考えやアイデアを具体的な形にする手助けをします。
例えば、アプリケーションのアーキテクチャ設計、新機能のアイデア、またはプロジェクトのスコープ定義などについて考える際に、具体的な案を出すことができます。

壁打ち相手として、質問者の認識外の回答も提供

対話型AIはプログラミングや設計の際に疑問や問題に直面したとき、解決策やアプローチを考える助けになります。
この壁打ちプロセスを通じて、ユーザーが自分で考えもしなかったような解決策や視点が提供されることがあります。
このような新しい角度や気づきは、問題解決やアイデア生成に役立つことがよくあります。

以上のように、対話型AIは多様なニーズに応じて有用な情報やインサイトを提供できるツールです。

これらをふまえて、

以下単純な例ですが、ChatGPTでイメージをかためる場合の(個人的に思う)悪い例(1)、良い例(2)です。

(1):答えを教えてください

この程度であれば一瞬ですね。
簡単!ChatGPT神!と思うには、開発業務の場合では安直かもしれません。

例えば、

以下のような考慮が必要でしょう

  • コンテキストの不足: AIは質問のコンテキストを完全に理解しているわけではありません。そのため、特定の用途や環境において最適な解決策を提供できないことがあるでしょう
  • パフォーマンス: AIが生成したコードは効率的でない場合があります。パフォーマンスを重視する場合は、手動での最適化が必要になるでしょう
  • 責任: 最終的には、生成されたコードをプロダクション環境で使用する責任はユーザーにあります。AIの出力は一つの参考程度に留め、必ず専門家の目で確認することが重要でしょう

その他、セキュリティや依存関係など考慮すべきことはありますね。

ただし、

プロトタイプの実装や、業務外のプロジェクトにおいていえば、開発速度の大幅な向上をもたらす可能性があります。
このような環境では、高度なセキュリティやパフォーマンスが必ずしも求められていない場合が多く、AIの即時性と効率性が際立つメリットとなるでしょう。

(2):どんなアプローチがあるか教えてください

これは、複数の選択肢の中から適切な選択ができます。
候補に対して質問を投げ返すことで理解を深め、方法を決定後にAIに実装イメージを生成してもらうのが適切でしょう。

実装に限った話ではなく、例えばエラーを解決したい場合、アーキテクチャを選定したい場合などにも当てはまるでしょう。

結論

答えではなく、選択肢を提示してもらうよう心がけるのがベターだと思います。

GitHub Copilot

AIベースのコード補完ツール、コーディングの作業時間削減や品質の向上が見込め。
以下はcopilot chatの調査内容ですが、多くの人がその結果に満足していることがわかります。
github.blog

これは、プロンプターがアウトプットの明確なイメージを持っていることが前提で、対するコーディング作業時間の削減が主だと思っています。

例えば、

かなり初歩的な話ですが、「複数要素から一意な要素を特定する」ような実装をアウトプットとする場合
多くは、streamに対してfilterで要素を特定する実装が提案されるでしょう。(javaベースの話になりますが)
確かにcopilotはとても頼りになり、シンプルで品質の高いコードを生成してくれるでしょう。

ですが、(前述の対話型AIとかぶりますが)例えば性能面を考慮するとどうでしょうか?要素を特定するのであれば他のアプローチとしてHashMapの利用もしばしば検討されます。
これらはデータサイズや頻度、メモリ制約によってプロンプターが適切な選択をする必要があり、copilotはコーディングの時短にフォーカスして利用すべきだと思います。

品質について

copilotを利用することで品質が上がる」ということをよく目にします。
おおむね同意ですが、注意すべき点としてcopilotは、冗長なコードでも無理なく理解し、空気を読んで冗長なコードから冗長なサジェストを生成してしまうことがあげられるでしょう。

例えば、

以下のようにあえて冗長なコードに対して改修を行うとします。

class Hoge {

  public Hoge(Integer value1, Integer value2) {
    this.value1 = value1;
    this.value2 = value2;
  }

  Integer value1;
  Integer value2;
}
  public List<Hoge> hoge(List<Hoge> list) {
    if (list == null) {
      return new ArrayList<>();
    }

    List<Hoge> a = null;

    for (int i = 0; i < list.size(); i++) {
      var v1 = Objects.isNull(list.get(i).value1) ? 0 : list.get(i).value1;
      var v2 = Objects.isNull(list.get(i).value2) ? 0 : list.get(i).value2;

      if (v1 > 0) {
        if (a == null) {
          a = new ArrayList<>();
        } else {
          a.add(new Hoge(list.get(i).value1, list.get(i).value2));
        }
      } else if (v2 > 0) {
        if (a == null) {
          a = new ArrayList<>();
        } else {
          a.add(new Hoge(list.get(i).value1, list.get(i).value2));
        }
      }
    }

    if (a != null) {
      return a;
    } else {
      return new ArrayList<>();
    }
  }

以下の通り改修

1.Hogeクラスにvalue3, 4を追加

2.value3, 4の値が0より多きい場合は、Hogeをリストに追加

結果

完璧に要件を満たしてはいますが、空気を読んでしまい冗長なコードを生成してしまいます。
確かにcopilotは優秀ですが、元が悪ければ必ずしも高品質なコードが生成されるわけではありません。

だらだらと書いてしまいましたが、
copilot副操縦士)というくらいですから、プロンプターは主操縦士として適切な判断力をもって利用していきましょうということですね。

まとめ

一部否定的に感じられてしまう内容もあったかと思いますが、否定的とか全くそういった感情はありません。
自身でも積極的に業務で利用しており、なかった時代には戻れないというほど恩恵を感じています。

本投稿で言いたかったのは、

  • 生成されたコードにも責任をもちましょう!
  • エンジニアとして適切な判断をしていきましょう!

ということでした。

AI様、これからもよろしくお願いします。

Copyright © RAKUS Co., Ltd. All rights reserved.