AIスタッフ体制で複数案件を並走させて学んだこと
akinori複数のクライアント案件を同時に動かしながら、AIに「役職」を与えて役割分担させるという試みを続けている。最初はうまくいかないこともあったが、設計を見直すうちに「これなら実務で使える」と思えるパターンが見えてきた。
この記事では、Claude Code を使って複数案件を並走させる体制をどう組んだか、何に気をつけたかを振り返る。
背景
フリーランス・法人として複数のクライアント案件を同時に抱えていると、どうしても「頭の切り替え」コストが高くなる。案件Aのことを考えていたら案件Bの締め切りが近づいていた、という経験は誰にでもあるはずだ。
AIエージェントを使えばそこを自動化できないか、と思ったのが出発点だった。
起きていた課題
最初の失敗は、すべての案件を1つの Claude Code セッションに突っ込んだことだ。
「A社のバグ修正と、B社の仕様書作成を同時にやって」と頼むと、モデルはそれっぽく返してくれる。しかし気づくと、A社の話をしているときにB社の技術スタックが混入していたり、以前の指示が残っていて意図しない動作をしたりする。
コンテキストが混ざると、確認コストが爆発する。AIを使っているのに、人間がかえって疲弊するという逆転現象が起きた。
検討したこと
問題の本質は「コンテキストの混濁」だと気づいてから、解決策を考えた。
選択肢はいくつかあった。
- セッションを案件ごとに分ける（単純だが、手動切り替えが手間）
- コンテキストを厳密に管理するプロンプトを書く（複雑化する）
- AIに「役職」を与えて、役職ごとにセッションを分ける
3番目の「役職設計」に行き着いたのは、人間のチームに例えたときに一番しっくりきたからだ。プロジェクトマネージャーとエンジニアが同一人物だと、どちらの判断基準で動けばいいか混乱する。AIも同じだ。
実際に行った対応
3層構成にした
秘書（全案件横断）→ディレクター（案件単位）→専門スタッフ（実作業）という3層を設計した。
秘書はすべての案件を俯瞰して、「今日どの案件を優先するか」「専門スタッフにどう指示を出すか」を判断する。承認が必要なアクションは必ず秘書を通す設計にした。
専門スタッフは一つの案件だけを担当し、深く作業する。他の案件のことは知らなくていい。
この分離によって、コンテキストの混濁が劇的に減った。
成果物はファイルで受け渡す
最初はチャットで「さっきの結果を元に次をやって」と続けていたが、セッションをリセットするたびに引き継ぎが消える問題があった。
解決策は単純で、成果物を Markdown ファイルに書き出すことにした。スタッフが作業した結果は必ずファイルに残り、次のスタッフがそのファイルを読むことから始める。
チャットの流れではなくファイルが「真実の場所」になったことで、セッションをまたいだ引き継ぎが確実になった。
1企業=1ターミナルで物理的に分ける
理屈の上ではコンテキストをプロンプトで管理できる。しかし実際には、物理的に分けるのが一番確実だった。
ターミナルのタブを企業ごとに分け、それぞれで独立した Claude Code セッションを起動する。切り替えはタブを変えるだけ。シンプルだが、これだけで「どの案件の話か」を毎回伝え直す手間がなくなった。
承認ポイントを人間が握る
「完全自動化」は目指さなかった。外部への送信、デプロイ、顧客向けの連絡は必ず人間が確認してから実行する設計にした。
AIが「やっておきました」と言ったことが実は間違いだった、というリスクを減らすためだ。AIに任せるのは「判断の補助と下書き」であって、「実行」は人間が握る。この区分けが、実務で使い続けられる設計の鍵だと思っている。
得られた学び
役職を与えるとコンテキストが整理される。AIに「あなたは○○スタッフです」と宣言するだけで、モデルが参照する情報の範囲と判断の基準が絞られる。これは人間のチームマネジメントと同じ原理だ。
ファイル運用は地味だが強い。チャット履歴はセッションを超えられないが、ファイルは残る。成果物をファイルで受け渡す運用は、地味に見えて引き継ぎの確実性を大幅に上げた。
物理的な分離が精神的な余裕を生む。「あのセッションにどの情報があったか」を気にしなくてよくなったことで、案件の切り替えがずっと楽になった。
完全自動化は罠。AIが「全部やっておく」設計にすると、何かが起きたときの確認コストが爆発する。自動化するのは「反復的な判断補助」にとどめ、重要な実行は人間が行う設計が長続きする。
まとめ
AIエージェントを複数案件で使いこなすコツは、「人間のチームっぽく設計すること」だった。役職・責務・成果物の受け渡し・承認フロー。これらを整理すると、AIは驚くほど安定して動くようになった。
Claude Code のカスタムスラッシュコマンドはこの設計を実装するのに非常に向いており、Makefile と組み合わせることでエントリポイントも整理できる。興味があればぜひ試してみてほしい。
実装の詳細は Zenn の技術記事に分けて書いたので、具体的な設計を知りたい方はそちらも参照してほしい。
＼ 最新情報をチェック ／
