Claude Codeで複数プロジェクトを管理する｜AIと人間の共同管理ダッシュボード

Claude Codeで複数プロジェクトを管理するときは、「どこで何が動いていて、どれが人間の判断を待っているか」を1画面に集めるのが近道です。筆者は全プロジェクトのClaude Codeを横断して見渡し、そこから指示も出せるローカルのダッシュボードを自作して、AIと人間の共同管理の場として使っています。

Claude Codeを使うプロジェクトが増えると、ターミナルの数も増えていきます。確認を求めて止まっている会話に気づくのが遅れたり、どこまでAIに任せてよいかの線が会話ごとにぶれたりするのは、多くの人が通る道です。

この記事では、ダッシュボードの設計を「人間とAIで何を分け持つか」という視点で解説します。公式のagent viewとの使い分け、状態の絞り方、権限の線引き、ローカル専用で動かすための確認ポイント、実装中に見つかったハマりどころまでまとめました。AIを組織として動かす全体の順序は「AI組織」は組織図から作ると失敗するで解説しています。記載の内容は2026年10月11日時点、Claude Code v2.1.296で確認した情報です。

Claude Codeで複数プロジェクトを管理すると何が見えなくなるか

複数プロジェクトでClaude Codeを並行して動かすと、最初に見えなくなるのは「人間の出番」です。作業そのものはAIが進めてくれても、人間が答えるべき場面を見落とすと、そこで仕事が止まります。

• 返事待ちの会話：許可や質問で止まった会話が、別のターミナルの陰に隠れる
• 終わった会話の結果：完了しているのに、結果を読みに行くのが後回しになる
• 任せる範囲：会話ごとに指示文が違うと、公開や送信まで進めてよいかの線がぶれる

この3つはどれも、作業の速さではなく人間の判断が入るところで起きます。だからこそ、ダッシュボードは「全部を見る画面」ではなく、「人間が動くべき場所を見る画面」として設計します。

結論：AIに渡すのは「実行」、人間が持つのは「判断と公開」

共同管理の土台は、AIに実行を渡し、人間が判断と公開を持つという線引きです。筆者は次の役割分担でClaude Codeを動かしています。

ダッシュボードは、この線引きを画面に落としたものです。人間が見るべきものだけを前に出し、実行の細部は会話ログに任せます。

公式のagent viewで足りる場合と、自作ダッシュボードが向く場合

Claude Codeには、バックグラウンドの会話を1画面で見渡す公式の機能「agent view」があります。公式ドキュメント（Manage multiple agents with agent view）によると、ターミナルで claude agents を実行すると、動いている会話・人間の入力を待っている会話・終わった会話がまとめて表示され、そこから新しい作業も投げられます。

ターミナルに慣れたエンジニアが会話を見張って返答するだけなら、まず公式のagent viewで十分です。ただし操作はすべてキーボードとコマンドなので、筆者が試した範囲では、ターミナルに慣れていない人が使うには敷居が高いと感じました。自作が向くのは、非エンジニアのメンバーも状況を見て判断したいとき、プロジェクト単位で全体を見たいとき、会話ログを自分の読みやすい形に絞りたいとき、プロジェクト側のルールと組み合わせて「人間の出番」だけを前に出したいときです。

なお、自作する場合も、状態の読み取りには公式が推奨する claude agents --json を使います。公式ドキュメントでも、外部のプログラムから状態を読む方法として案内されています。

共同管理ダッシュボードの設計：4つの決めごと

設計で決めることは、画面の構成・状態の分け方・任せる範囲・状態の置き場所の4つです。順番に解説します。

画面は4つの要素でできている

ダッシュボードは、プロジェクトカード・指示ボックス・ストリーム・会話ビューの4つでできています。技術的にはNext.jsのアプリで、Claude CodeのCLIと会話ログを読むだけの作りです。

1. プロジェクトカード：直近30日にClaude Codeを使ったプロジェクトを自動で並べ、状態を表示する
2. 指示ボックス：カードを選んで指示を書くと、そのフォルダでバックグラウンドの会話が始まる
3. ストリーム：直近に動いた会話の一覧。どこで何が走っているかを見る
4. 会話ビュー：人間の指示・Claudeの返答・使ったツールだけを時系列で読む

ダッシュボード自身はデータベースを持たず、状態を保存しません。理由はこの後の「状態の正本はプロジェクト側に置く」で説明します。

状態は4つに絞り、人間の出番を見分ける

カードに出す状態は、人間が動く必要があるかどうかで4つに絞ります。細かい状態をすべて出すと、見る側の判断が増えるからです。

公式ドキュメントでは、blocked は「人間の答えがないと先に進めない状態」、done は「頼まれた作業を終えて次の指示を待つ状態」と区別されています。次の指示を待っているだけの会話は返事待ちに入れないのがポイントで、ここを混ぜると「返事待ち」が常に埋まって意味を失います。

1つのプロジェクトで複数の会話が動いているときは、代表の状態を1つだけカードに出します。優先順位は「返事待ち → 作業中 → 完了 → 待機」です。筆者は最初、作業中を先頭にしていましたが、作業中の会話と返事待ちの会話が同じプロジェクトにあると返事待ちが隠れてしまうため、返事待ちを先頭に変えました。人間の出番を見落とさないことが、共同管理ダッシュボードの一番の役目だからです。

どこまでAIに任せるか：権限の線引き

取り返しのつかない操作は、権限ではなくルールで人間に残します。ダッシュボードから始める会話は、許可モードを auto にしています。公式ドキュメント（Choose a permission mode）によると、autoモードでは人間の代わりに別のモデル（分類器）が操作を確認するため、確認ダイアログで止まらずに長い作業を進められます。

ルールは各プロジェクトのCLAUDE.mdとメモリに書き、どの会話のClaudeも同じものを読みます。どの仕事をどこまで任せているかの具体例はAI社員の職種一覧にまとめています。

状態の正本はプロジェクト側に置く

ダッシュボードに状態を持たせず、引き継ぎの情報はプロジェクト側のファイルに置きます。指示ボックスから始まる会話は毎回まっさらですが、次の3つのファイルを最初に読ませることで、作業が途切れずにつながります。

• 開いている作業の一覧：1項目1行で、担当・期日・完了の判定方法を書く。状態を持つのはこのファイルだけ
• 決定台帳：人間が決めたことを日付つきで1行ずつ残す
• 作業の詳細：背景や手順だけを書き、状態は書かない

状態を書く場所が2つになると、片方だけが更新されて食い違います。筆者の環境でも、見出しと本文が食い違って、終わった作業が「残タスク」として報告されたことが何度かありました。ルールファイルとエージェントの書き方はClaude Codeのルール・エージェント設計術で詳しく解説しています。

最小構成の作り方とローカル専用の確認ポイント

最小構成は、公式のコマンド2つと会話ログの読み取りだけで組めます。作る手順と、動かす前に確認しておきたい点をまとめます。

最小構成の手順

最小構成は、状態を読むコマンドと、会話を始めるコマンドの2つで組めます。データベースもサーバーも新しく用意する必要はありません。

1. claude agents --json --all を数秒おきに実行し、会話の一覧と状態を読む
2. ~/.claude/projects/ 以下の会話ログ（JSONL）から作業フォルダ（cwd）を読み、プロジェクトの一覧を作る
3. 状態を4つに変換し、プロジェクトごとに代表の状態をカードに出す
4. 指示を受けたら、対象フォルダで claude --bg を実行して会話を始める
5. 会話ビューでは、会話ログの末尾だけを読み、指示・返答・ツール名を抜き出して表示する

# 会話の一覧と状態を読む（完了した会話も含める）
claude agents --json --all

# 対象フォルダでバックグラウンドの会話を始める
# 指示文が「-」で始まってもオプション扱いされないよう -- で区切る
cd /path/to/project
claude --bg --permission-mode auto -- "引き継ぎファイルを読んで、今日やることを3行で報告して。作業はまだしないで"

アプリから実行するときは、シェルを通さずに引数を配列で渡します。指示文に記号が入っても、コマンドとして解釈されなくなります。

ローカル専用で動かすための確認ポイント

AIに指示を送れる画面は、それ自体がAIへの入口です。筆者のダッシュボードは自分のPCの中だけで動かし、次の4点を確認しています。

スマホや外出先から使いたくなったら、画面を外に公開する前に、ログインと送信元の確認の設計から考えます。

検証ポイント：ダッシュボードが機能しているかの合否ライン

実装したら、状態の表示と指示の送信が正しく動くかを、次の合否ラインで確かめます。あわせて、筆者が実装中にハマった点を2つ紹介します。

• 返事待ちの会話があるプロジェクトは、ほかの会話が作業中でもカードに「返事待ち」と表示される
• 次の指示を待っているだけの会話が、返事待ちに入っていない
• 信頼済みでないフォルダに指示を送ると、エラーで止まる
• 別のドメインのページから指示APIへ送信すると、拒否される

ハマりどころ1：信頼済みかどうかはフォルダ単位で判定される

claude --bg は、信頼済みにしていないフォルダでは始まりません。公式ドキュメントにも、スクリプトから実行すると Workspace not trusted のエラーで終わると書かれています。筆者の環境では、親フォルダ（~/Projects）を信頼済みにしていても、その中のフォルダでは弾かれました。信頼済みの判定は親をたどらず、フォルダごとに確認するのが確実です。

ハマりどころ2：ターミナルの会話は返ってくる項目が違う

claude agents --json の結果のうち、バックグラウンドの会話には state が入りますが、ターミナルで開いている会話には state が無く、プロセスの状態を表す status（busy・waiting・idle）だけが入っていました。両方を同じ形に揃えてから状態を判定し、status が waiting の会話も返事待ちとして扱うと、見落としが減ります。筆者の実装も、この扱いに直しています。

次の一手：足す機能の優先順位

最小構成が動いたら、次は「投げっぱなし」から一歩進める機能を足します。筆者が予定している順番は次のとおりです。

決まった時刻に動かしたい作業は、ダッシュボードから投げるより、Claude Codeの/loopや/scheduleに任せたほうが向いています。使い分けはClaude Codeのスキル・ループ・ワークフローの使い分けで、完了の通知などをフックで受け取る方法はClaude Code上級編｜MCP・Hooks・Skills・サブエージェント実践ガイドで解説しています。

このダッシュボードをしばらく運用して、指示の件数や返事待ちの数などを測った結果は、続編の記事でまとめる予定です。

FAQ

Claude Codeで複数プロジェクトを管理するダッシュボードについて、よくある質問をまとめました。

Q. 公式のagent viewだけでは足りませんか？

ターミナルに慣れたエンジニアが会話を見張って返答するだけなら、公式のagent viewで十分です。非エンジニアも画面で状況を見て判断したい、プロジェクト単位で全体を見たい、会話ログの見せ方を変えたい、といった要望が出てきたときに自作を検討すると、手間に見合います。

Q. 許可モードをautoにしても大丈夫ですか？

autoモードでは別のモデルが操作を確認するので、長い作業を止めずに進められます。そのうえで、公開・送信・削除のような取り返しのつかない操作は、指示文とCLAUDE.mdで「人間がやる」と決めておくと安心です。

Q. スマホから指示を出せるようにできますか？

できますが、画面を外に公開する前に、ログインと送信元の確認を設計する必要があります。まずは自分のPCの中だけで使い、必要になった時点で認証から作るのが確実です。

Q. 同じプロジェクトに同時に複数の指示を出してもよいですか？

gitリポジトリのプロジェクトなら、バックグラウンドの会話はそれぞれ別の作業コピー（worktree）で編集するので、同時に出してもファイルが直接ぶつかることはありません。gitで管理していないフォルダでは同じファイルを書き換えてぶつかることがあるので、1本ずつ出すのがおすすめです。

Q. ダッシュボードにデータベースは必要ですか？

必要ありません。状態はclaude agents --jsonで、会話の中身は~/.claude/projects以下の会話ログで読めます。状態を保存しないほうが、プロジェクト側のファイルと食い違わずに済みます。

Q. 料金は増えますか？

ダッシュボード自体に料金はかかりません。ただし、始めた会話はClaude Codeの利用枠を使うので、一度に何本も走らせると枠を早く使い切ります。

まとめ

Claude Codeで複数プロジェクトを管理するときは、人間が動くべき場所だけを1画面に集め、AIには実行を、人間には判断と公開を残すのが基本です。

• エンジニアが会話を見張って返答するだけなら、まず公式のagent view（claude agents）を使う。非エンジニアも見るならブラウザの画面を用意する
• 自作するなら、状態は「作業中・返事待ち・完了・待機」の4つに絞り、返事待ちを最優先で見せる
• 次の指示を待つだけの会話（done）は返事待ちに入れない
• 取り返しのつかない操作は、権限ではなくCLAUDE.mdのルールで人間に残す
• 状態の正本はプロジェクト側のファイルに置き、ダッシュボードは読むだけにする
• AIに指示を送れる画面は、ローカル専用から始める

自社の業務に合わせたダッシュボードや社内ツールを作る時間が取れない場合は、制作の相談を受け付けています。

関連記事

• 「AI組織」は組織図から作ると失敗する｜1人会社をAI会社化する正しい順序
• AI社員の職種一覧｜1人会社が実際に配属できる仕事とその境界
• Claude Codeのルール・エージェント設計術｜CLAUDE.mdとサブエージェント運用の実践知
• Claude Codeのスキル・ループ・ワークフローの使い分け
• Claude Code上級編｜MCP・Hooks・Skills・サブエージェント実践ガイド
• 社内ポータルをClaude Codeで自作する｜チームボードの作り方と公開前チェック