Gunosy Tech Blog

Gunosy Tech Blogは株式会社Gunosyのエンジニアが知見を共有する技術ブログです。

CLI First 検証による新規開発の高速化

この記事は 「Gunosy Tech Blog Festa 」の 7日目の記事です。

新規開発チームでIRHubの開発をしているUTです。

開発における難易度の変化

みなさんLLMを使った開発は当たり前のように実施してますよね。 LLMの登場する前の開発では、APIを作ってフロントを作ってといういわゆる画面の開発自体にそれなりの時間が取られていました。 なので、例えばめちゃくちゃ動的な画面とか高負荷な画面とかいわゆる難しい画面を作ることは工数の兼ね合いもあって一大プロジェクトになっていたと思います。 しかし基本的なCRUDの画面であればLLMを使えば数時間(数分?)で完成してしまうので、今まで難易度が高かった実装項目がカジュアルに開発項目として入ってくるようになりました。

一方で、課題は「バックエンドの検証コスト」に移っています。 フロントの難しさだけでなく最近はAI機能としてLLMを使ったバックエンドの実装なども難しい項目の一つです。 フロントよりもバックエンドのほうがPDCAが回しづらく検証スピードが遅くなりがちです。

「CLI-First 検証」

従来PoCを実施するのは(少なくとも自分は)結構腰が重い作業でした。 開発しているプロダクトとは別プロジェクトとして新しく開発環境をセットアップして引数とかも可変にしてなど、PoCなので大体は適当でもいいのですがそれでも面倒でした。 また、PoCのコードは割と書き捨てになるのでコードの保管場所も迷いどころです。 また書き捨てになるのでいざ本番にいれようとしても結局手がかかってしまい、二重に面倒になってしまいます。

しかし、LLMの登場で「とりあえず作る」がかなり早くなり、簡単なCLI作成であれば1リクエストで作れてしまいます。 検証コードにオプションをつけるのも一つの依頼で作ってくれます。

そこで、開発を進めていく中で私たちは 「CLI-First 検証」 をするようになりました。

CLI-First 検証 とは

GUI(画面)を作る前に、まずCLIでコアロジックを完成させる開発スタイル と定義します。 プロダクトと同一のリポジトリ内に別のディレクトリを切って、その中で各PoCのコードを残していきます。

メリット

同一リポジトリにPoCの検証コードを残していくのには以下のメリットがあります。

  • 資産化:検証ロジックが履歴として残って、他メンバーも参照可能
  • 環境の共通化:既存のライブラリや型定義も(言語によっては)使える
  • 本番投入の容易さ:同一リポジトリ内にあるので、LLMにPoCコードを本番に投入する際、依頼が簡単にできる

特に、本番投入はLLMを使うことで実装コストが大幅に減ります。

同一リポジトリにあることでLLMがPoCと本番のコードのコンテキストを理解して作成できるので、実装が 爆速化 します。

具体事例

IRHubではpptxファイルの翻訳して英訳されたpptxファイルをダウンロードできる機能があります。

ただpptxファイルの翻訳は非常に難しいタスクです。

  • カジュアルにテキストボックスを分けて配置できるので、どの文章が繋がっているのかpptxファイルからはわからない。
  • チャートなどはエクセルで別ファイル
  • 翻訳した後、訳した単語をちゃんとpptxにある元のテキストボックスに戻す必要がある

こういう細かいけど難しいタスクを一つずつPoCをしながら解消して本番反映しています。

技術詳細

実際のディレクトリ構成は

.
├── front/          # フロントのコード(TypeScript)
├── server/         # バックエンドのコード(Python)
└── sandbox/        # 「CLI-First 検証」のコード(Python、TypeScript)
    ├── translate-poc/  # 翻訳のPoCプロジェクト
    └── layout-poc/     # レイアウトのPoCプロジェクト

となっています。

技術スタックと環境

Serverサイドの実装はPythonであり、sandbox 内のPoCコードも同様にPythonで記述しています。 パッケージ管理には uv を採用しており、プロダクトコードと同じ依存関係を即座に再現できる環境が整っています。

抱えていた課題

pptxの翻訳処理のような重いタスクは、Web経由で検証しようとすると非常に検証ループが悪くなります。 ローカルサーバーを立ち上げ、ファイルをアップロードし、翻訳完了を待ち、ログを確認する……。 この手順を踏むのは時間がかかりますし、詳細な挙動を追うために本番コードへ一時的なデバッグログを仕込むのも手間です。

CLI-Firstによる解決

しかし、「CLI-First 検証」であれば、手元のファイルを引数としてCLIツールに渡すだけで検証が完了します。 LLMに「このファイルを入力として、ここをデバッグするCLIを作って」と依頼するだけで、余計なWebサーバーの層を通さずに、ロジックそのものの検証ループを爆速で回せるようになりました。

まとめ

今まで多くの時間を取られていた「環境構築」や「コードのコピー」部分をLLMによって代替することで、「実験」と「実装」の距離を限りなくゼロに近づけることができるようになりました。

こうすることで、本質的な課題解決に集中できる環境を作ることができています。

興味がある方は、ぜひIRHubを使ってみてください。