生成AIで内部ツール開発のジレンマを解決する

はじめに

生成AI研究開発チームでソフトウェアエンジニアをしている坂尾です。

カケハシでは製品として生成AIを活用するのはもちろんですが、業務の中でも活発に生成AIを利用しています。今回は、生成AIを活用して内部ツールを効率的に開発した事例をご紹介します。

内部ツール開発のジレンマ

開発や運用作業をする上で、管理画面などの内部ツールの開発をすることも多々あります。例えば、運用するための管理画面やfeature flagを設定するデバッグ機能などです。

しかし、これらは「あれば便利」だよねというものも多く、直接的な利益を生むわけではないため、以下のような課題があります：

エンジニアリングリソースは製品の開発に集中させたいため、優先度が下がりがち
工数が取れていざ取り掛かろうとした時にはモチベーションが下がってしまいがち
コードは書いた瞬間から負債となるため、最低限にしたい。必要なものを見極めるのは難しい

一方で、実際に作られるとやはり便利で、作成されたツールによって開発や検証のスピードが上がることもしばしばあります。

最近、生成AIで作ったものが思いのほかチームメンバーからの評判が良かったので、ここで紹介させてください。

生成AIを活用して作ったChrome拡張

背景：マイクロフロントエンドのアーキテクチャ

私の所属しているチームでは、Musubiに搭載する生成AI機能を開発しています。この生成AI機能はマイクロフロントエンドのアーキテクチャで作成されており、Musubi側が私たちのチームで開発しているフロントエンドのJSを読み込んで実行するような形になっています。

graph LR
    B["Musubi"] -->|読み込み| A["生成AI機能 JS"]
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px

Musubiのチームと生成AI機能を開発しているチームは分かれており、それぞれが開発環境を持っています。

課題：環境の増加

ここで、生成AI機能を開発する環境と同じ数だけMusubi側の環境も必要となるという問題がありました。

各Musubiの環境でロードする生成AI機能のJSは基本的には一つしかないようになっています。そのため以下のように生成AI機能の環境ごとにMusubiの環境が必要になってきます。

graph LR
    subgraph "生成AI機能"
        A1["JS (Dev)"]
        A2["JS (Stg)"]
        A3["JS (local)"]
    end
    
    subgraph "Musubi"
        B1["環境1"]
        B2["環境2"]
        B3["環境3"]
    end
    
    B1 --> A1
    B2 --> A2
    B3 --> A3
    
    style A1 fill:#f9f,stroke:#333,stroke-width:2px
    style A2 fill:#f9f,stroke:#333,stroke-width:2px
    style A3 fill:#f9f,stroke:#333,stroke-width:2px
    style B1 fill:#bbf,stroke:#333,stroke-width:2px
    style B2 fill:#bbf,stroke:#333,stroke-width:2px
    style B3 fill:#bbf,stroke:#333,stroke-width:2px

Musubi側に機能を追加するという手段も考えられますが、このようなデバッグ用途の機能を製品に組み込むのは憚られます。さらに環境が増えてしまうのは運用コストも肥大してしまうため、可能な限り避けたいところです。

解決策：Chrome拡張の開発

そこで、Musubiから生成AI機能の環境を切り替えるChrome拡張を作成しました。 UI は以下のようなものです。

技術的にはDeclarativeNetRequest APIを利用して、特定のリクエストを任意のものに置き換えるという形で実装しています。ブラウザのネットワークレイヤで内部的な Redirect が実行され、呼び出す JS を切り替えるということを行っています。

これによって、全てを一つのMusubi環境から切り替えることができるようになりました。

graph LR
    subgraph "生成AI機能"
        A1["JS (Dev)"]
        A2["JS (Stg)"]
        A3["JS (local)"]
    end
    
    B["Musubi環境"]
    C["Chrome拡張"]
    
    B -->|リクエスト| C
    C -->|切り替え| A1
    C -->|切り替え| A2
    C -->|切り替え| A3
    
    style A1 fill:#f9f,stroke:#333,stroke-width:2px
    style A2 fill:#f9f,stroke:#333,stroke-width:2px
    style A3 fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px
    style C fill:#ffa,stroke:#333,stroke-width:2px,stroke-dasharray:5 5

生成AIによる開発スピード

この実装はCursorを利用して片手間に2時間程度で作成することができました。具体的な時間配分は以下の通りです：

初期設計と調査（20分）：生成AIとの対話し、 Chrome 拡張での実現可能性の調査と設計
実装とデバッグ（100分）：生成AIへの指示出しとコード生成、動作確認と修正を繰り返し

ほとんど自分でコードは書いておらず、指示と動作検証だけ行っただけです。

今回はChrome拡張を取り上げましたが、運用のための管理画面も生成AIで作成しました。こちらも数時間で作成することができました。

どちらも機能によりますが、通常であれば数日程度かかるようなものではないでしょうか？特にChrome拡張などは全く仕様なども知らない状態でも、短時間でこれだけのものを作成することができました。

生成AIがもたらす新しい可能性

内部ツールは「あれば便利」だよねというものも多く、明確に利益につながるわけではなく、コストもかかってしまうため、やや優先度が落ちがちです。しかし、明確に生産性に寄与するツールもあると思っています。

生成AIは着想から実装までのスピードを飛躍的に向上させることができるため、今までコスト見合いで実現・検証できなかったものも、まずは実現させることができます。動くもので有用性を検証するということができるようになりました。生成AIによる開発は内部ツール開発におけるジレンマを解決してくれるかもしれません。

みんなの頭の中にあるだけで「あれば便利」だが、実際にはコスト見合いなどで生み出されなかったソフトウェアは数多くあるのではないかと思います。それらが実現されることを考えるとワクワクしますね。

開発時の課題と学び

リファクタリングや機能を追加するタイミングで 生成AIが既存動作を壊す変更を行なってしまう ということが発生しました。こうなるとちゃんとコードを読んで修正したり、動作する地点まで commit を巻き戻したりするということが必要になりました。やはり生成AIによる開発では commit をこまめにすることが重要だと感じました。