はじめに：LLMに実装させまくる？
gemini cli や claude code を使って、簡単な業務改善ツールをLLM CLIに任せる日々に感動しています。
ちょっとした相談にも応じてくれるし、簡単な処理の雛形を出してもらうには十分便利です。
でも巷の記事を読んでいると、
「これを3日でつくれた！」「生産性が倍になった！」「10倍になった！」
「コードの生成は claude code におまかせして、自分はレビューばかり」
などの話が並びます。
一方で私は、「確かに便利になったけど、そこまで劇的な効果はないな…」と感じていました。
おそらく、生産性を大幅に向上させている人たちは、複数の課題をLLMに同時並行で処理させているのでしょう。
でもいったいどうやって？
たとえば…
-
issue-101ではclaude codeに関数の整理を頼んでいて -
issue-102はgemini cliが実装したので、結果を元に動作確認をしたい -
issue-103はまだだけど、思いついたことをメモしておきたい
仮にそれぞれが同じリポジトリに対する作業だとして、claude code にしても gemini cli にしても、
仕組み上、ディレクトリを分けて作業依頼しているのだと思います。
そうなると、issue-102 の動作確認をするには Docker を起動してポート8080をローカルに転送し、
issue-101 を確認したくなったら、そのDockerをこのディレクトリにマウントし直して再起動する…
これを手作業でやるのは、切り替え作業が面倒すぎませんか？
生産性をあげている方は、どうやってスムースにやっているのでしょうか？
※本稿は、ChatGPTとの議論をもとに私が執筆したもので、
アイデアの一部はChatGPTの提案を取り入れています。
あくまで思考の記録であり、成果物はありません。
相談相手がいないので ChatGPT と話してみました
いつも私の味方で応援してくれている ChatGPT 4o に相談しました。
「切り替えコマンドでissue-101に切り替えたときに、
ディレクトリ移動と docker の再起動を自動的にする仕組みにすればいいんじゃない？」
というのが私の素朴なアイディアです。
そのとき LLM CLI はバックグラウンドで処理継続してくれていればいいのではないか。
案１．それぞれの課題ごとに 専用 docker インスタンスをたてる
最初の図ではいちいち自分で docker のマウントディレクトリを切り替えるイメージでしたが、この案では
-
issue-101/→localhost:8081 -
issue-102/→localhost:8082 -
issue-103/→localhost:8083
みたいにして、それぞれに docker インスタンスをたてて、
それぞれのディレクトリごとに claude code や gemini cli が作業するものです。
それぞれのディレクトリはそれぞれ用にターミナルを開いておく必要があると思います。
これならそれぞれ用のターミナルに切り替えれば、それぞれの進捗がわかります。
issue-101を確認したければ、ブラウザに http://localhost:8081 と入力すれば確認できます。
メリット
- ターミナルを切り替えれば、それぞれの進捗がわかる（切り替えはターミナルクライアントに依存するので、人によってはこれを好きだと感じるかも）
- 同じ課題を
claude codeとgemini cliとcodex cliにやらせて、ターミナルをならべて見比べることもできる
いけてないところ
- 課題ごとにdockerのポート転送がかわるので、「これを確認するには8082だったっけ？」「あれ、修正されてない…あ、こっちのポートだった」みたいになる
- ディレクトリごとにdockerのポート転送とマウントディレクトリを変えて起動するのが面倒くさそう
- 環境によっては重くなりそう
案２． Linux にならう（fg, bg, jobs）
Linux のジョブ制御のように、課題を前面・背面に切り替える発想です。
- 最初に課題開始
（ここで課題用のディレクトリ自動作成し、git cloneして、branch 作成して、
docker 起動する…のを自動的に行う）→これはこのあともう少し考えてみます - LLM に何かを頼んだら
bg（バックグラウンド） して他の作業にうつる - 状況を一覧で見たいときは
jobs - 今見たいタスクを
fg（フォアグラウンド）
実現可能かはおいておいて、この考え方は人間が頭の中でやってる切り替えとすごく近いなと思いました。
現実でも、だれかと打ち合わせしているときはそれしかできません(fg)し、打ち合わせが終わったら(bg)次のタスクに集中(fg)することしかできません。
bg は「AI に考えさせている状態」
issue-101 で gemini に「このクラスをリファクタして」と頼んだあと、しばらく考えてもらってる間に bg しておく。
つまり「このタスクはいま LLM に任せてるから、自分は別の作業をする」という切り替えです。
jobs は「依頼した作業状況の一覧」
次に私に何ができるかな…とみんなの状況を確認します。できるかどうかは別として、こんな感じの一覧が出せれば素敵ですよね：
$ task jobs
[1] issue-101 THINKING gemini
[2] issue-102 WAITING claude docker:8080
[3] issue-103 WAITING gemini
fg は「次にこれを確認する」
WAITING になったら、task fg issue-101 みたいなコマンドで前面に出す。
$ task fg `issue-101`
とか
$ task fg %1
やることは：
-
cdして対象のディレクトリに移動 - docker はカレントディレクトリをマウントし直して再起動（dockerインスタンスはつねに一つだけにする）
- LLM のセッションを復帰？？
- ブラウザで
localhost:8080を開いて確認
メリット
-
localhost:8080に確認方法を統一できる
（案１と違って、ポートを覚えなくていいので認知負荷が低い） - LLM セッション、コード、Docker を全部「文脈」としてひとまとまりにできる
- 作業の切り替えが直感的で、自分が「いまなにをしている」に集中できる
いけてないところ = bg
- bg? task を bg っていったいどう実現するのか…linux で バックグラウンドジョブにしても LLM はちゃんと動いてくれるのか？？
- fg, bg を hook して、fg, bg のタイミングで docker を停止、とかできるのか？？
課題の開始方法を考えてみる
ちょっとここで、課題を開始するときのことを考えてみたいと思います。
なんとなく、以下のようなコマンドで開始できたら楽だなぁと想像しています。
$ task new 102-ログイン画面の不具合を修正する
このコマンドにやってほしいことはこんな感じでしょうか。結構たくさんあります。
- いまの作業ディレクトリ用の docker インスタンスを停止する
- 新しい作業用のディレクトリをつくる
- git clone する？？
- そこにcdする
- 課題用のブランチを作成する
- docker インスタンスを起動する？
- gemini とか codex とか claude を起動する
「2. git clone する??」について
どこから clone するのか？と考えてみると、こういうふうにリポジトリを指定する必要があるように思います。
- task new 102-ログイン画面の不具合を修正する
+ task new 102-ログイン画面の不具合を修正する --repo=https://github.com/xxxx/yyyyyyyy
こういった感じのディレクトリで作業する感じでしょうか…
~/.task-contexts/
├─ issue-101/
│ ├─ .git/ ← git clone するから .git がある
│ ├─ .meta.json ← なんか必要な情報を保存する
│ ├─ docker-compose.yml ← 必要な気がする
│ ├─ app/
│ └─ webroot/
└─ issue-102/
└─ ...
あるいは、リポジトリごとに作業ディレクトリが分かれるとしたら、こんな感じ？
- task new 102-ログイン画面の不具合を修正する
+ task init --repo=https://github.com/xxxx/yyyyyyyy
+ task new repo1 102-ログイン画面の不具合を修正する
そうなるとこういったディレクトリ構成になるかもしれません
~/.task-contexts/
├─ repos1/
│ ├─ .meta.json ← リポジトリごとの設定情報を保存（リポジトリのURLとか）
│ ├─ issue-101/
│ │ ├─ .git/ ← git clone するから .git がある
│ │ ├─ docker-compose.yml ← 必要な気がする
│ │ ├─ app/
│ │ └─ webroot/
│ └─ issue-102/
│ └─ ...
├─ repos2/
│ ├─ .meta.json
:
「5. docker インスタンスを起動する？」について
今回のような仕組みを実現するには、docker インスタンスの自動再起動は欠かせません。
そのためには git clone したディレクトリで docker-compose up -d したら
検証環境が立ち上がるようにしておくのはほとんど必須事項です。
そうなると docker の定義が書かれている docker-compose.yml は
リポジトリルートあたりにあったほうがいいのかもしれません。
~/.task-contexts/
├─ repos1/
│ ├─ .meta.json
│ ├─ issue-101/
│ │ ├─ .git/
│ │ ├─ docker-compose.yml ← これがないと issue-101 用の docker を起動できない気がする
│ │ ├─ app/
│ │ └─ webroot/
│ └─ issue-102/
│ └─ ...
├─ repos2/
│ ├─ .meta.json
:
ところで、そもそも、web 用の docker 単体で使うことは少なくて、
db 用の docker インスタンスと smtp 用の docker インスタンスがあったりします。
localstack とかもあるのかも。
アプリケーションの動作確認という意味では web 用の docker だけディレクトリを変えて再起動すればいいような感じがしますが、
内容によって db のテーブル定義が変更になる場合は db 用の docker インスタンスもわけたほうがいいケースがあるかもしれません。
smtp や localstack の docker インスタンスはなにも設定を変更したりせずに使い続けられるように思います。
でも、そこまで考えると面倒なので、とりあえず課題ごとに docker-compose.yml にしたがって
docker インスタンスを再起動するようにしたとして、こうでしょうか。
アプリケーションリポジトリに docker-compose.yml や Dockerfile も管理しているのが普通なのか？
ちょっと話はそれますが、みなさんは、gitリポジトリのアプリケーションソースに
docker 関連の管理ファイルも同梱していますか？
私はずっと別管理していたのですが、複数人で開発するときなどは README で環境構築してもらうのが
だんだんと煩わしくなってきています。
ですから、docker関連のファイル類もリポジトリの中にいれて一緒に管理したほうがいいのではないか？と、
うっすらと感じていました。感じてはいましたが、まぁいいや、と放置してきました。
しかしここまでくると、アプリケーションソースに docker 関連ファイルを同梱するように
徐々にでも変更していなかったことが悔やまれてきます。
過去の自分を恨んでも仕方ありませんので、
リポジトリに docker-compose.yml はない前提で、
以下のようにしたほうがいいような気もします。
~/.task-contexts/
├─ repos1/
│ ├─ .meta.json
│ ├─ docker-compose.yml ← こっちに移動
│ ├─ issue-101/
│ │ ├─ .git/
│ │ ├─ docker-compose.yml ← ここではなくて
│ │ ├─ app/
│ │ └─ webroot/
│ └─ issue-102/
│ └─ ...
├─ repos2/
│ ├─ .meta.json
:
そうなると、docker-compose.yml をどこかからもってくるようにする必要があるのかもしれません。
- task init --repo=https://github.com/xxxx/yyyyyyyy
- task new repo1 102-ログイン画面の不具合を修正する
+ task init --repo=https://github.com/xxxx/yyyyyyyy --docker-compose=~/workspace/some-dir/docker-compose.yml
+ task new repo1 102-ログイン画面の不具合を修正する
そもそも、docker-compose.yml に「課題ごとのカレントディレクトリをマウントする」ようにするには、
yml に少し手を加える必要もありそうな気がします。
うーん…
案３． bg が難しそうなので tmux を使う
tmux という名前は聞いたことがありましたしインストールして軽くさわったことはありましたが普段使いはしていません。
ChatGPT 4oさんがこれを出してくるまで考えが及んでいませんでした。
でも、案２で技術的な課題になりそうな bg の問題を tmux ならば解決できそうです。
ターミナルを複数立ち上げたりタブとして開くのと大変似ています。
tmux のタブ的なものを切り替えれば、裏で LLM が作業していたものの結果をみることができます。
これをターミナルクライアント一つで行えること（デスクトップがちらからない）がうれしい人もいるでしょう。
さらに tmux のタブ的なものを切り替えるときのイベントを hook して
docker の停止／再起動（して今度最前面に来たタブのカレントディレクトリにマウントしなおす）こともできるそうです。
※これは ChatGPT 4o さんが言っていたことであって、まだ確認はとれていません
こんな感じが私の考える理想像です。案２の jobs 的なものを常に表示しておけば、なおわかりやすい気がしています。
右ペインでは以下のような操作を行います。
$ task init --repo=https://github.com/xxxx/yyyyyyyy --docker-compose=~/workspace/some-dir/docker-compose.yml
$ task new repo1 102-ログイン画面の不具合を修正する #←これでmkdir, git clone, cd, git branch, docker-compose up, tmux に一つ仮想タブを追加
# タスクの切り替えは tmux で行う
# tmux には現在処理中のリストを表示できればよい
$ task finish repo1 102-ログイン画面の不具合を修正する #←この前までにgit commit とか gh pr create とかしておく前提で、rm -rf して仮想タブを消す？
メリット
- 作業の切替時にdockerも課題ディレクトリをマウントし直すので、確認作業は
http://localhost:8080に統一できる - 作業の切り替え＝ tmux の仮想タブの切り替えなので、LLMのセッション管理も不要
- tmux の仮想タブの切り替えを hook して自動化できる（ChatGPT 4o 談）
いけてないところ
- tmux の操作に慣れていない（私が）
まとめ：マルチタスクというより、マルチ文脈スワップ
人間は同時並行ではなく、「文脈を切り替える」ことで複数作業を進めています。
LLM CLI に実作業＝コーディングを任せる、というとき、人間はそれらの成果を確認していく必要がありますが、
このときに簡単に文脈を「切り替える」ことができて、認知的負荷がすくなく確認できることは重要です。
今回の内容は、どちらかというと「考えの過程」の記録で、特定の方法を勧めるものではありません。
「LLM を CLI で活用する人って、いったいどうやってるのかな」という素朴な疑問をきっかけに、いろいろと考えた記録です。
今回の記事で紹介した案はまだ実現していないアイデアですが、皆さんはどのようにLLMを活用してマルチタスクを実現していますか？
次回は（もしやったら）実際に試してみた結果と、その過程で得られた新たな知見をご紹介したいと思います。