AIチャットの構築をコードからDifyに変更し開発プロセスをカスタマーサポートチームに完全委譲した
MAMORIOアプリからの問い合わせに返答するAIチャットのバックエンドをコードからDifyのワークフローに置き換えました。
その結果、サーバーサイドのコードが300行減り、関連するテストコードを70％減少し、非エンジニアのカスタマーサポートチームにAIチャットの開発の権限移譲を行いました。
Difyを使用することで、GUIベースでワークフローを構築した後、それをWebAPIとして公開することが可能になります。
この変更により、AIによる応答の構築はカスタマーサポートチームが行い、システムはDifyに対する入力と出力と例外処理のみを管理します。
AIエージェントのワークフローをコードで書くのは馬鹿馬鹿しい
MAMORIO社では新たなコードを追加した際にテストカバレッジが減らないことをマージの条件にしています。
しかし、AI統合によりテストコードが急増し、これは一つの問題点となっていました。
テストカバレッジのルールはWebアプリケーション開発の秩序を保つ上で重要ですが、AIのフローは検索や他のサービスからの情報取得などの外部との連携が多く発生するため、愚直にテストカバレッジを維持しようとするとさまざまなサービスのモックを書く必要が出てきます。
また、フローの各ステップで使われるサービスはあくまで過渡的なものでありすぐに置き換え可能な別の選択肢が出てくるようなものであるため、改善のためのトライアンドエラーをいちいちコードの変更で行うのことには著しい手間がかかります。
LLMを社内に浸透させる
LLMエージェントの管理をカスタマーサポートチームに委譲することは、社内でのLLMの浸透を促進する効果もあります。
テクノロジー界でゲームチェンジャーだと言われSNSで盛り上がっているLLMも、職種によって利用率にばらつきがあります。
たとえば以下の記事ではLLMが特に多く使われている職種として営業・エンジニア・マーケターの三つが挙げられています。
LLMの登場によって従来の一対一のカスタマーサポートがLLMと共同したカスタマーエンジニアリングになっていくことは必然的な流れですが、その際に障壁になるのがシステム作りをすることを入社前に想定していなかったメンバーにエンジニアリング的な思考に慣れてもらうことです。
人間にはどのようなメディアで情報を受け取るかによって理解度が変わる認知特性がありますが、エンジニアは圧倒的に文字優位の文化であり、そうではない人々にとっては参入障壁になります。
そのため、全ての操作をGUIで完結できるDifyは、非エンジニアにも技術的な作業を親しみやすくし、彼らの業務効率を向上させる有効なビジュアルプログラミング言語であるといえます。
認知負荷の低減によりメンテナンスが楽に
開発における画面の切り替えは代表的なソフトウェア開発における認知的負荷として知られていますが、たとえばVisualStudioを使っているサーバーエンジニアがAIのワークフローで利用する検索エンジンをBingに切り替えるコードの変更タスクが発生した場合、以下のように最低でも5〜6回程度画面の切り替えが発生するのではないでしょうか？
[コード]
Googleに切り替えるコードを書く（VS画面）
コンソールまたは開発環境で動作を検証する（開発環境のweb画面またはコンソール画面）
テストコードを書く（VS画面）
テストを行う（コンソール画面）
デプロイ（コンソール画面）
githubでプルリク（github画面）
マージとデプロイ完了の確認（github画面）
Stagingと本番環境で検証（各環境の画面）
一方でカスタマーサポートチームが同様の作業をDifyで行う場合は概ねDify内のワークフロー構成画面の内部で画面の切り替わりが発生せずに完結します。
[Dify]
Googleに切り替える設定変更を行う（Dify設定画面）
当該パーツで結果を検証（Difyワークフロー構築画面）
通しでチェック（Difyワークフロー構築画面）
公開（Difyワークフロー構築画面）
Stagingと本番環境で検証（各環境の画面）
全員参加型の組織へ
Difyの導入は開発プロセスを効率化するだけでなく、企業文化にも影響を与える可能性があります。
認知負荷の低いDifyを利用することで、非エンジニアもシステム開発の手法を習得しやすくなり、業務改善や生産性向上に向けた意思決定に積極的に参加できるようになります。
OpenAIの創立者であるサム・アルトマンは「AIによって一人の人間が1000億円企業を作れるようになる未来がかなり近い将来にやってくる」と述べていますが、生成AIとシステム開発の間にある壁をGUIによって下げるDifyのようなツールは、少人数の組織の全員が職種の垣根を越えてエンジニアとしての業務の改善やPRとしての外部発信を行ない潜在能力を発揮する手段になり得るのではないでしょうか。
Discussion