AI開発環境
Claude Codeを9本並列で回す — AIの速度に人間が追いつく運用設計
Claude Code のようなコーディングエージェントは、案件ごとにセッションを立てれば 6 本でも 9 本でも同時に書きます。書く速度は、もう待ち時間の原因ではありません。時間がかかっているのは、その出力を人間が把握して、次の指示を出すところです。
私は Cognisant で LLM システムの受託開発をしていて、設計から実装、顧客とのやり取りまで 1 人で持っています。平日は Claude Code のセッションが 6 本以上、9 本になることも珍しくありません。その運用でいちばん手を入れているのは「AI に何をさせるか」ではなく、人間が AI の速度に追いつくための設計です。この記事はその現状を、企業が複数のエージェントを運用するときの設計に読み替えられる形でまとめたものです。
先に分担を書いておきます。ここに出てくる実装・スクリプト・後述するパネルは、すべて Claude のセッションが書いたものです。私がしているのは、成果物を確認することと、セッションへの指示（CLAUDE.md・スキル・memory）を整えることです。
並列にすると、遅いところが移る
セッションを 1 本から 6 本に増やしたとき、変わったのは書く速度ではなく、待ち時間の置き場でした。
| 観点 | セッション 1 本のとき | 6〜9 本のとき |
|---|---|---|
| 書く速度 | 人間が読む速度とほぼ釣り合う | 人間の側が追いつかない |
| 状態の把握 | ターミナルを見れば足りる | 「今どこで何が変わったか」を探す時間が確認より長くなる |
| 成果物の確認 | コードを読める | コードを全部読む時間はない |
| 指示 | その場で文章で説明できる | 毎回説明していると並列の意味がなくなる |
| 不備の出方 | ほぼ出ない | 識別の取り違え・git の衝突・共有状態の巻き戻りが出る |
つまり、並列数を上げて速くなるのは、人間側の「認識」と「指示」の手段を先に整えた場合だけです。整えないまま増やすと、探す時間と説明する時間で相殺されます。以下、この 2 つに分けて書きます。
認識の設計：状態と成果物を読める形にする
確認はコードではなく、動作と資料で
確認の対象をコードから移しました。自分でコードを読む代わりに、動かして挙動を見ること、全体像を資料として起こさせて読むこと、の 2 つで確認しています。理由は効率だけではありません。今のモデルの水準では、自分でコードレビューをするより、この方が結局は誤りが少なく、品質や方向性のずれも出にくいと感じているからです。
副産物もあります。確認のために作らせた資料・スクリーンショット・動画は、そのまま顧客への説明やメンバーへの共有に使えます。「確認のために作るもの」と「伝えるために作るもの」が同じになるのは、1 人で全部を持つ働き方では都合がよい。
資料は型で作らせる
資料で全体像を読むなら、資料自体が読みやすくないと成り立ちません。なので資料の型をテンプレートにしてスキルに置き、白紙から作らせないようにしています。
| 見たいもの | 型 | 使う場面 |
|---|---|---|
| 誰がどの工程で何をしているか | 現状フロー（スイムレーン） | 業務改善の現状把握。負担や risk の集中点が見える |
| 1 つの文書が承認をどう通るか | 承認フロー | 稟議・申請・検収の整理 |
| 利用者の一連の操作と結果 | ユースケースフロー | 業務アプリのモック、手順書、提案 |
| 会議で投影して議論する | スライドデッキ | 提案・キックオフ。注釈層と発表者ビュー付き |
| 手元で読んで判断する | A4 配布ドキュメント | 仕様確定、報告、配布 |
型があると、セッションは「どの型で」と言えば同じ骨格で出してきますし、こちらは同じ場所に同じ情報がある前提で読めます。作る前には「誰が・どこから開く・最初の 1 画面で何を判断する・どこで決める・次の行動・要らなくなる条件」の 6 行を書かせ、読み手の視点の流れを先に決めさせています。Excel も同じで、開いて一度で読める状態（列幅・折り返し・行高・ズーム）に仕上げさせ、PDF に落として切れや重なりがないかを実機で確認させてから受け取ります。
「今どこが動いたか」を見る窓
6 本、9 本が同時に走ると、数分ごとにどこかで新しいファイルが生まれます。ターミナルを順に見て「何を書いた？」と聞いて回ると、確認そのものより探す時間の方が長くなります。
欲しかったのは「今どこが動いたか」が 1 画面で見えて、クリックで中身が開く窓です。ターミナルの中ではなく、別の窓で。私は Sublime Text を長く使っているので、そこに Recent Activity というパネルを作りました。設計から実装まで Claude Code のセッションに書かせ、私が決めたのは置き場所と何を映すかです。この接続層は OSS として公開しています（sublime-claude-code・MIT・非公式のコミュニティプラグインで、Anthropic とは無関係です）。
24h · docs & media
▼ gg_ds 5 ●2
● gg-ds-8e
* 14:52 STATUS.md
14:51 …/status_archive/2026-09.md
○ gg-ds-b6
14:50 …/snapshots/state.json ⟨.wt-x⟩ ×3
▶ sekisui_chemical 12
直近 24 時間に変わったファイルを 案件 → セッション → ファイル（新しい順） で並べ、クリックで開きます。既定で出るのは文書とメディアだけ（md / txt / html / pdf / xlsx / docx / pptx / csv / 画像 / 動画）で、コードは切り替えで出します。案件の単位は claude を開いたディレクトリで、ツールがサブディレクトリに移動しても分裂しません。
仕組みは、ファイルシステムの監視が「何が変わったか」を、Claude Code の hook が「どのセッションが書いたか」を取り、両方を突き合わせています。運用して分かったこともあります。並列が増えると一覧が縦に長くなり、結局スクロールして探すことになる。そこで、パネルの高さを予算にして「全案件の見出しは必ず残す・各セッションの最新 1 件を先に出す・入らない分は古い案件から畳む」という配分に変えました。全体感が先、詳細はクリックで、です。同じ案件で 2 セッションが同時にコマンドを走らせると帰属が付かない、という弱点はまだ残っています。
逆向きの窓もあります。セッションが成果物を作ったら、自分でそれをエディタに開かせる CLI を渡してあり、「見てほしいものができたらこれで開く」と CLAUDE.md に書いてあります。人間が探しに行くのではなく、持って来させる方向です。
指示の設計：修正を言葉で説明しない
認識ができても、直したいことを毎回文章で説明していたら追いつきません。領域ごとに、指示の渡し方を変えています。
| 領域 | 指示の渡し方 | 中身 |
|---|---|---|
| フロントエンド | 画面上で直す（tweak） | ブラウザ上で要素を選び、文字サイズ・余白・位置・文言を手で直す。その差分を JSON で渡すと、セッションが Tailwind のクラスやトークンに変換してソースへ反映し、前後のスクリーンショットで検証する |
| 資料・スライド | 注釈（annotation） | 資料の上のどこにでも注釈を付け、JSON で書き出してそのまま修正指示にする。「3 枚目のこの図の右上を…」と書かない |
| バックエンド | エンジニアの知見 | ここは道具で省略できない。設計・境界・契約を先に決めさせる、テストを先に書かせる、直すときは 1 層 1 変数で直して全カテゴリの前後差を見る。判断は人間側に要る |
| インフラ | 監視とログ | 動作は監視とログでしか見えない。ログの設計、失敗率の可視化、費用の定点（リクエスト数 ÷ 人間の PV が 100 倍を超えたら構造の不良）を運用に組み込む |
フロントと資料は「言葉で説明しない」方向に寄せ、バックエンドとインフラは「人間の知見と観測を効かせる」方向に寄せています。同じ「指示」でも、効く手段が領域で違います。
確認は選択式にさせる
セッションが判断に迷ったとき、自由記述の質問を投げさせないようにしています。仮説を立てて選択肢を出し、推奨案を先頭に付けて選ばせる。返答が分岐しうるなら両方の分岐を先回りで答えさせる。人間側の返答を 1 タップに寄せるためです。
規則の置き場を決める
守らせたいことは、置き場で効き方が変わります。
- 横断の規則は
CLAUDE.md（全案件に効く） - 行動の直前で必ず参照される規則は、スキルのセルフチェック（PR を作る、対外に送る、といった行動点）
- memory は引き継ぎ用で、規則を埋めない（行動点で参照されず落ちる）
- 案件の設計判断は各案件の設計書・ADR・STATUS（全体規則に昇格させない）
これは、PR の画面イメージのリンクに ?raw=true が抜ける不備が同じ日に 3 回再発した後に決めた分け方です。規則は memory にあったのに、PR を作る瞬間には参照されていませんでした。
指示は受けた瞬間に書かせる
会話の中で「今後は」「必ず」「禁止」と言ったとき、セッションはその発話を記録の代わりにせず、同じターンの中で記録先を判定して書き、返信の末尾に「記録: パス」を付けます。終了時には会話ログの指示語と更新した規範ファイルを機械で突き合わせます。人間の指示が会話に流れて消えるのを防ぐためです。
並列の土台
セッションを増やすと、識別・git・共有状態で不備が出ます。ここは指示として固定してあり、今は 6 本でも 9 本でも問題なく回っています。
- 命名: 起動時に案件と作業の名前を付ける。自動名のまま並列しない。セッション間メッセージの宛先にもなる
- git は worktree で切り分ける: 並列セッションが動きうる案件では、作業ツリーを隔離してから編集・commit させる。既定にしてからは、git 側の不備はほぼ出ていません
- マシン共有の状態は同一コマンド内で切り替える: アカウント切替と操作を同じコマンドのチェーンに入れる。別コマンドに分けると、その間に別セッションが切り替えていて、別アカウントで PR が立ちます。エラーは出ません
- セッション同士に直接話させる: 共有 worktree に触る前の宣言、main への着地通知、相手が手待ちになったときの 1 回だけの通知、に使っています
企業で複数のエージェントを運用するときに、同じ構造が出る
ここまでは 1 人の運用の話ですが、構造は企業がエージェントを部門や業務ごとに走らせるときと同じだと考えています。エージェントが増えるほど、人間側の「把握」と「指示」が追いつかなくなり、放置すると確認されない出力が溜まる。私たちが企業の AI 導入で見てきた「PoC は動いたが運用で止まる」の一部は、ここに原因があります。
| 1 人の運用 | 企業の運用に読み替えると |
|---|---|
| 「今どこが動いたか」の窓（Recent Activity） | エージェントの出力を人が一覧できる可視化。ログではなく成果物単位で |
| 資料の型 | 出力のフォーマットを先に決める。確認者が同じ場所に同じ情報を期待できる |
| 領域別の指示手段 | 現場が直せる部分（画面・文言）と、専門家の判断が要る部分（設計・境界）を分ける |
| 規則の置き場 | 「行動の直前で参照される場所」に規則を置く。ガイドラインの文書だけでは効かない |
| 選択式の確認 | エージェントからの問い合わせを、人が 1 タップで返せる形に統一する |
Cognisant が導入支援で一貫して取っている設計も同じで、「AI を入れるために既存の環境を捨てる」のではなく「いまの環境に AI を繋ぎ、人間が追いつける形にする」です。エディタの話としてはエディタを替えるな、エージェントを繋げに、エージェント設計の話としてはAIエージェント開発の実務に書きました。
まとめ
- 並列数を増やして速くなるのは、人間側の認識と指示の手段を先に整えた場合だけ
- 認識: 確認はコードでなく動作と資料／資料は型で作らせる／「今どこが動いたか」の窓を持つ（OSS: sublime-claude-code）
- 指示: 領域ごとに手段を変える（画面で直す・注釈・知見・監視）／確認は選択式／規則は行動点に置く／指示は受けた瞬間に書かせる
- 土台: 命名・worktree・同一チェーン・セッション間メッセージ
ここに書いたのは今日の時点の答えで、明日も何かを 1 行直しているはずです。同じ運用をしている方がいたら、認識と指示のどこを工夫しているか、ぜひ教えてください。
この記事は、AIツールを活用して作成し、Cognisant 工藤大地がファクトチェック・編集・監修を行っています。セッション数・パネルの挙動は筆者環境での実測（2026年9月）です。
Read next