こんにちは、スマートラウンドのtsukakeiです！
今日はLLMを活用したソフトウェア開発爆速化の方向性を探ってみての感想を共有したいと思います
要約
- OpenAI o1のような高性能LLMは、開発爆速化に確実に使える
- 一方で、まだまだ制約が存在しており、そこをいかに乗り越えられるかがAI活用の鍵となりそう
- LLMを最大限に活用するためには人間側の知識やスキルも重要であり、エンジニアとしては継続的に学習・検証を行う必要がある
活用したLLMs
弊社ではChatGPT Team PlanとGoogle Workspaceを使っていることもあり、今回は下のLLMたちを使いました
- OpenAI o1
- 主な相談相手、何か困ったり聞きたいことがあったらまずは何でも聞いた
- OpenAI o3-mini-high
- Web検索できるので最新情報に当たりたい時に使った
- 弊社のメインプロダクトでも使っているKtorやExposedで大きめのバージョンアップがあったため、o1の回答は古いと感じる時が時折あった
- Gemini
- 「画像作りたいんですけどおすすめの生成AIありませんか？」とHRに聞いたら教えてくれたから
- おすすめ通り、いい感じの画像を作ってくれた
ちょっとした宣伝
弊社はVertical AI Companyに進化するべく、他にもClaudeやDevinなどを活用しています
Devinの活用事例についてもテックブログを書きましたのでご興味ある方は是非ご覧ください！
成果物
Slack + Webサーバー + Vue SPAの構成でSlackを使ったお問い合わせ管理システムのようなものを作成しました
2週間くらいはかかるかなと思っていましたが、結果としてその半分の1週間で完成させることができました
SlackからBotに問いかける様子
Botからも話しかけることができます
管理画面
全体像
# ディレクトリ構成
このレポジトリのディレクトリ構成です。
ai-rabbit/
├── .gitignore
├── README.md
├── settings.gradle.kts // Gradle マルチモジュール管理設定
├── build.gradle.kts // (必要ならば) ルートプロジェクト用の依存やプラグイン共通設定
│
├── bot/ // Slack Bot (Bolt for Kotlin) 関連プロジェクト
│ ├── build.gradle.kts
│ └── src/
│ ├── main/kotlin/ // Kotlinコード (Bot本体)
│ └── test/kotlin/ // テスト
│
├── server/ // KtorベースのWebサーバ(管理画面API等)プロジェクト
│ ├── build.gradle.kts
│ └── src/
│ ├── main/kotlin/ // Kotlinコード (Ktor)
│ └── test/kotlin/ // テスト
│
├── common/ // 共通ライブラリ・ドメインロジックなど(必要があれば)
│ ├── build.gradle.kts
│ └── src/
│ ├── main/kotlin/
│ └── test/kotlin/
│
├── frontend/ // Vue.jsプロジェクト
│ ├── package.json
│ ├── tsconfig.json
│ ├── vite.config.ts (または webpack.config.js 等)
│ ├── src/
│ │ ├── components/
│ │ ├── views/
│ │ ├── App.vue
│ │ └── main.ts
│ └── public/ // 静的ファイル
│
└── infra/ // インフラ関連ファイル (Docker, IaC, k8s など)
├── Dockerfile-bot
├── Dockerfile-server
├── Dockerfile-frontend
├── docker-compose.yml
└── k8s/ // Kubernetesマニフェスト, Helm charts 等
# ディレクトリ構成の考え方
## `bot/`
- Slack Botを実装するBolt for Kotlinのプロジェクト
- `src/main/kotlin/`配下にBotのハンドラーやSlack連携ロジックを置きます。
- Gradleマルチモジュールとして `:bot` モジュールになるイメージです。
## `server/`
- 管理者用Web Appのバックエンド（Ktor）用プロジェクト。
- 認証認可やデータアクセス、専門家向けのUI APIなどを提供します。
- Gradleマルチモジュールとして `:server` モジュール。
## `common/`
- 必要に応じて、BotとServerで共通利用するドメインモデルやユーティリティ関数などを切り出します。
- Gradleマルチモジュールとして `:common` モジュール。
## `frontend/`
- Vue.js (TypeScript) プロジェクト。
- フロントエンドはSPAでビルドした成果物（distディレクトリなど）をデプロイする想定。
## `infra/`
- DockerfileやKubernetesマニフェスト、Terraformなどのインフラ定義を格納します。
- Bot / Server / Frontend をそれぞれ個別のDockerイメージとしてビルドし、docker-compose.yml や k8s設定で束ねる構成例が多いです。
## `settings.gradle.kts` / `build.gradle.kts`
- リポジトリのルート(`ai-rabbit/`)でマルチモジュールを定義。
これもChatGPT o1が書いてくれました
作成の手順
基本的にはChatGPT o1に壁打ちした上で、方向性を決定し、細かいコードについてもどう書いたらいいかを教えてもらいながら実装を進めていきました
o1とのアーキテクチャ・技術選定
こんな感じのものをこういう技術スタックで作りたいと相談
あなたはソフトウェアアーキテクトです。次のようなプロダクトのプロトタイプを作成したく、実装アーキテクチャについて相談させてください。
# プロダクトイメージ
Slack BotによるAIエージェント
ユーザーがSlack上で@メンションし、質問や依頼をするとAIまたは担当者が対応。
# 実装アーキテクチャイメージ
前提として、主な開発言語はTypeScriptとKotlin、フロントエンドはVue.jsを使います（必要であれば他言語でも可）
- クライアント用Slack App
- Bolt for Javaで構築
- 弊社管理者用Web App
- サーバーサイドはKtor
- フロントエンドはVue.js
- SPAで作れると尚いいかも
- （必要であれば）DBはPostgreSQL
相談したいこと
実装アーキテクチャイメージについて違和感がないか
プロのアーキテクトとして忌憚のない意見を聞きたいです
その回答
以下、プロのソフトウェアアーキテクトとしての視点で、実装アーキテクチャイメージに関する確認・意見を述べます。全体的には妥当性の高い構成だと思いますが、いくつか検討ポイントや追加で考慮すべき点を列挙します。
---
## 1. 実装アーキテクチャ全体に対する印象
### 1.1 アプリケーション構成
- **Slack App (Bolt for Java)**
Slack Botを構築する上でBolt for Javaを採用すること自体は問題ありません。ただしKotlinプロジェクト全体との親和性を考えると、KotlinでのBolt利用（\*1）を検討してもいいかもしれません。
- すでにJavaエコシステムに強みがあり、Bolt for Javaに精通しているチームメンバーがいるのであれば、Javaで統一するメリットもあります。
- 逆にフルKotlinにしたい場合は、Bolt for Kotlinのようなラッパを活用したり、Bolt for JavaをKotlinから呼び出すことも一案です。
\*1: 公式にはBolt for JVM (Java) ですが、Kotlinからでも十分利用可能です
- **サーバーサイド (Ktor)**
KtorはKotlin製フレームワークとして軽量かつ拡張性も高く、反応速度の求められるWeb APIやWebアプリに適しています。特にコルーチンを活用した非同期処理やスケーラビリティを考慮すると、Ktorベースで組むのは良い選択です。
- **フロントエンド (Vue.js)**
管理画面の構築でVue.jsを使うのは一般的であり、TypeScriptと組み合わせれば大規模開発にも耐えられるので妥当です。
- もしフロントエンド開発チームがReactやAngularに慣れているならそちらを採用しても良いですが、Vue.jsに親和性があるなら問題ありません。
- Slackとのやり取りは基本的に「Bot → Slack UI(会話/メンション)」で行われ、管理者用Web画面では別途バックエンドAPIを呼び出す構造だと思うので、それほど複雑なリアルタイム連携は必要ないかもしれません。
- **DB (PostgreSQL)**
特に問題ない選択だと思います。確実性、汎用性、スケーラビリティ、拡張性を兼ね備えており、スタートアップ規模でも十分です。
### 1.2 全体フローの想定
1. **ユーザーがSlack上でBotにメンション** →
2. **Bolt for Javaが受け取り、自動処理 or 担当者アクションを振り分け**
3. **必要に応じてWeb管理画面（Ktor & Vue.js）で専門家や担当者が最終チェックや承認**
4. **承認後の書類送付や連絡はSlack Botが再度受けてユーザーへメッセージ**
上記のような流れを想定するのであれば、KtorサーバーとSlack Appをどのように連携するかがポイントとなります。Bolt for Javaを単独サーバーとして動かすケースと、Ktorアプリ内でBoltを動かすケースがあり得ます。
- **Bolt for Javaを別プロセスで起動する場合**
- Slack APIを受け付けるエンドポイントをBoltが担当。
- 必要に応じてKtorのWeb APIへHTTP通信やgRPC通信を行う。
- 環境構築では2つのアプリケーションをデプロイ・運用管理する必要がある。
- **Ktor内でBoltを組み込む場合**
- 1つのKtorアプリにBolt機能も含める。
- Kotlinコード内でBoltを呼び出す形にする。
- デプロイは1つのサービスとしてまとめられるが、設定やルーティングの分離をどのようにするか考慮が必要。
いずれでも構いませんが、運用チームのスキルセットやCI/CDパイプラインをどう組むかによって選択肢が変わります。
---
## 2. セキュリティや運用面の考慮事項
- **認証認可の設計**
- Slack側はOAuthトークンでBotをインストールする想定ですが、Web管理画面にアクセスする担当者/専門家向けのログイン方式(SSO, OAuth2, Basic認証など)をどのように実装するか、早めに設計しておいた方が良いでしょう。
- **運用時のアップデートと拡張性**
- Slack Botの機能拡張やWeb管理アプリの新機能追加が容易に行えるようにマイクロサービス化するかどうか、将来的な規模を想定して最初の段階からソースコード構成を分割しておくと良いでしょう。
---
## 3. まとめ
**全体として違和感は大きくありません**し、Kotlin＋Vue.js＋PostgreSQLという構成は堅実かつモダンな選択です。Slackアプリ（Bolt for Java/JVM）との連携方法だけ、いくつかのやり方があるため、
- 「Bolt部分とKtor部分を分離して運用するか」
- 「1つのKtorプロジェクトにBoltも組み込み、Kotlinでまとめるか」
をチームの好みとデプロイ戦略・保守性で判断すると良いでしょう。
もしPoC段階であれば、最初は**Bolt for Java or Kotlinで最小限のBot機能 + Ktor/Vue.jsでの管理画面**で十分に試行し、ユーザーに実際に触ってもらいながらFBを得る進め方がおすすめです。そこから得られた知見に基づいて、細かいアーキテクチャの最適化や追加機能を設計するとスムーズかと思います。
何か追加のディスカッションや深堀りしたい要素があれば、いつでもお声がけいただければと思います。
壁打ちでいい返事が来たので詳細を詰め始める様子（全体像を書いてもらっています）
o1とのライブラリセットアップ・実装
Slack Botの作り方やKtor、Exposedのセットアップについては詳しく教えてくれました！
完全コピペで動く場合もあれば、そうでない場合もあるため、多少は公式ガイドも読む必要はありましたが、ほとんど手がかかりませんでした。
たった4秒でこの回答が返ってくるのは神、コーヒー入れる暇もありません☕
UIについては基本ノータッチでo1
こちらのレポジトリを参考にしつつ、UIのことはよくわからないので全投げしました
余談
興味本位でNuxtを使いたかったけど忌憚のない意見で反対されたので断念😢
アイコンはGeminiで作成
かわいいアイコンがサクッと作れてすごい！
感想
o1の精度の高さ
o1の精度の高さにはびっくりしました
知らないことについては時々嘘をつくこともありますが、壁打ち相手としては成熟したエンジニアレベルにあるように感じました
o3-mini-highの微妙さ(？)
o1はモデル学習されたタイミングが少し悪く、ちょうどいいタイミングでo3-mini-highが出てきたので検索させてみたのですが、こちらは思っていたより使えませんでした
調べてって言ったことをただ持ってくるだけという感じで、1次ソースに自分で当たってしまった方が早いかなという感じでした
ソースコードをコンテキストとして渡せない問題
実装を進めていて、だんだんと困ったのは、ソースコードをコンテキストとして渡しづらいため、あまり深く入り込んだ回答が減っていきました
コピペしようにも、なかなか上手くいかないため、相談しつつ、実装するには自分の手を動かす必要が増えていきました
LLMのポテンシャルとユーザー側の知識・スキルの関係
ChatGPT o1については、壁打ち相手としても最高でしたし、今後コードベースとの連携が深まると尚更すごいことができるんだろうなと感じました（モデルもさらに賢くなるだろうし）
その一方で、人間がわからないことはそもそも質問できなかったり、回答の意味が理解できなかったりとすることも出てきそうです
そうなると、LLMsを使いこなすにもある程度のスキルが必要かもしれないと思いました
おわりに
この記事を読んでスマートラウンドにご興味を持った方がいらっしゃれば、ぜひ以下の採用ページをご覧ください！
Discussion