「10セッション並列で動かしたら、2つが同じタスクに着手していた」——これはSF小説の話ではなく、2026年に日本の開発現場で実際に起きた事故だ。AIエージェントの複数連携が当たり前になりつつある今、「とりあえず並列化」という直感が、むしろコストと混乱を倍増させるケースが続出している。限られた予算で本番運用を目指すなら、設計の順番を間違えてはいけない。
並列化vs直列化——AIエージェント設計で最初に問うべき一つの問い
AIエージェントを複数動かすとき、開発者が最初に直面する問いは「並列か、直列か」だ。この判断を誤ると、速度向上どころか二重作業・データ消失・未完了タスクの完了扱いという三重苦に陥る。
判断の分岐点は明快だ。タスク間に依存関係があるかどうか——これだけを問えばいい。
並列化が有効なケースと直列が必要なケース
並列化が機能するのは、タスク同士が互いの結果を必要としない場合に限られる。複数ファイルの独立したリファクタリング、異なるモジュールへの同一パターン適用、テスト生成とドキュメント更新の同時進行——これらは並列化の恩恵を受けられる典型例だ。
一方、以下のような前後依存がある工程を並列化すると競合が発生する。
- スキーマ変更 → それに依存するコード修正
- 設定ファイル更新 → 動作確認
- API仕様策定 → クライアント実装
「スキーマ変更とコード修正を並列で走らせたら、コードが旧スキーマ前提で書かれた」——こうした事故は、依存関係の分析を省略した設計から必ず生まれる。
TOKIUMが記録した「並列化の壁」3事例
経費精算SaaSを提供するTOKIUMの開発チームは、10セッション並列運用の実験で3つの具体的な事故を記録している。
- 同一タスクの二重着手問題：10セッションが互いの存在を知らず、2セッションが同じタスクに同時着手。作業が無駄になるだけでなく、後から競合を解消するコストが発生した
- 設定ファイル競合問題：2セッションが同一ファイルを同時編集し、片方の変更が完全に消滅した
- 完了申告の信頼性問題：エージェントが「done」と自己申告したにもかかわらず、実際には未完了のタスクが完了扱いになり、後続工程が誤った前提で進んだ
3つ目の事故が最も根深い。エージェントは嘘をつくつもりがなくても、自分の完了状態を正確に把握できないことがある。この現実を設計に組み込まなければ、並列化はリスクの増幅装置になる。
「done申告を信じるな」——TOKIUMのForemanモデルが解決した本番運用の核心
TOKIUMが開発した「Foreman」は、エンタープライズ向けの商用フレームワークでも、複雑なマイクロサービスアーキテクチャでもない。台帳ファイル1枚を中心に据えた協調制御モデルだ。
Foremanの「木モデル」——疑いの設計思想
Foremanは「幹（Orchestrator）」と「葉（Worker）」の関係で動く。フローは以下の通りだ。
- 幹がタスクを登録する際、完了の定義を同時に付与する（「このファイルが存在すること」「このテストが通ること」など）
- 葉（Workerエージェント）がタスクをclaimし、実行し、commitし、done申告を行う
- 幹が20秒間隔で巡回し、成果物ファイルの実在を独立確認する「回収スイープ」を実施する
- 申告と実態が一致した場合のみ、タスクを完了扱いにして回収する
核心は「回収スイープ」にある。エージェントの自己申告を鵜呑みにせず、幹側が独立して成果物の実在を検証する。これにより申告と実態の乖離を構造的に防ぐ設計だ。
4コンポーネントをローコストで代替する
LLMオーケストレーションは技術的に正確に定義すると、Agent Registry・State Manager・Execution Engine・Communication Busの4コンポーネントで構成される制御層を指す。しかしForemanモデルが示すように、小規模運用ではこれらをすべて安価に代替できる。
- Agent Registry（各エージェントの能力・制約カタログ）→ CLAUDE.mdへの役割定義で代替可能
- State Manager（エージェント間のコンテキスト引き継ぎ）→ 台帳ファイル（Foremanモデル）で代替可能
- Execution Engine（並列/直列分岐・タイムアウト管理）→ tmux＋シェルスクリプトで部分代替
- Communication Bus（エージェント間メッセージルーティング）→ 共有ファイルシステムで代替可能
月額数万円のSaaSを契約する前に、台帳ファイル1枚から始める「最小有効オーケストレーション」を試すべきだ。TOKIUMの事例はその実現可能性を本番環境で証明している。
知らないと詰む——Claude Codeのサブスク枠外課金とコスト設計の実態
技術的な設計が正しくても、課金構造を誤解したまま実装を進めると、月末に想定外の請求書が届く。Claude Codeにはこの罠が存在する。
サブエージェントとエージェントチームで課金体系は別物
Claude Codeには2種類のマルチエージェント構成があり、課金構造がまったく異なる。
- サブエージェント：セッション内部で動作する軽量ワーカー。親子階層のみで横連携・孫生成は不可。課金は親セッションのトークン消費として計上される
- エージェントチーム：独立したClaude Codeインスタンスとして起動。チームリードが分解・割当・進捗監視を担う。各インスタンスが独立して課金される
エージェントチームを10インスタンス起動すれば、課金も10倍のペースで積み上がる。「並列化=効率化」という思い込みが、ここで直接コストに跳ね返る。
パイプ渡し・非対話起動という隠れトラップ
TOKIUMの事例が明示した最も重要な実務警告がこれだ。
- 可視ウィンドウでの対話起動（blessed経路）：Claude MaxなどのサブスクリプションプランのトークンとしてAnthropic社が処理する
- パイプ渡し・非対話起動：サブスク枠外の従量課金APIとして扱われる可能性があり、気づかないうちに別請求が積み上がる
TOKIUMはこの対策として、CLAUDE.mdに「別課金回避」として起動経路を明文化し、blessed経路のみを正規手順として固定した。性能や実装のシンプルさより課金モデルの安全性を優先した設計判断だ。
Gemini CLIとClaude Codeの現実的な使い分け
コスト構造を比較すると、2つのツールの棲み分けは明確になる。
- Gemini CLI：約1,000リクエスト/日の無料枠あり、オープンソース（GitHub公開）、速度とプロトタイピングに強み
- Claude Code：月額$20〜（Claude Max等）、プロプライエタリ、複雑タスクの一貫性に強み
Parallel.aiの分析が示す結論は明快だ。「モデルの選択より、与えるコンテキストの質の方が重要」——両方インストールして、プロトタイピングはGemini CLI、本番品質が求められる複雑タスクはClaude Codeという使い分けが現実的な運用指針になる。
コンテキスト圧縮とローカル環境——中級者が次に押さえるべき実装の詰まりどころ
基本設計を固めた後、中級者が必ずぶつかる壁がある。コンテキスト管理の誤解と、ローカル環境固有の落とし穴だ。
Claude Codeの6層構造とコンテキスト圧縮器の動作
Claude Codeは6層構造で設計されており、コンテキスト管理はLayer 2（Knowledge Layer）のコンテキスト圧縮器が担う。動作の仕組みはこうだ。
コンテキストウィンドウが約95%に達すると5層カスケード圧縮が起動する。ChatGPTのような単純な「会話要約」ではなく、ファイルパス・コードスニペット・エラー履歴の構造的抽出を行い、重複ツール出力を刈り込む。これにより「使えるコンテキスト」を維持しながら長時間セッションを継続する設計だ。
この仕組みを理解していないと、「コンテキストが溢れる前に手動でクリアしよう」という誤った対処をしてしまう。圧縮器が自動で適切に処理するため、むしろ不必要な手動介入がセッションの継続性を損なう。
出力短縮がコスト削減に逆効果になる——GitHubの実測データ
「出力を短くすればトークンが減ってコストが下がる」——この直感は間違っている。GitHubがCopilot CLIで実施したA/Bテストが、反直感的な実測結果を示している。
RTK（Rust Token Killer）でシェル出力を短縮した場合、省略されたテキストが重要な情報を含む場合、モデルが出力を再度開くかコマンドを再実行する。個々のツール応答は短くなるが、全体トークン消費は増加する。
実際に効果があった施策と削減率は以下の通りだ。
- ビューツールの行番号等プレフィックス削除：3.1%削減
- 出力の選択的圧縮（ノイズのみ対象）：5.5%削減
- タスクツールのプロンプト圧縮：2.9%削減
- 通知時の余分な往復処理削減：2.3%削減
- 合計（独立施策の積み上げ）：約13.8%削減
GitHubが確立した原則は「ソースコード類・任意コマンド実行結果は保持する、検索結果はコンテンツを削除せず再編成する、繰り返されるノイズ（install/build/test/lint出力）のみを圧縮する」という3点だ。闇雲に短縮するのではなく、何を削るかを選別する精度こそがコスト最適化の本質だ。
Windows環境・ローカルLLM運用の固有課題
Windows環境でのClaude Code運用には、Linux/macOSとは異なる詰まりどころが存在する。シェルパスの解釈差異、改行コード（CRLF/LF）の混在によるスクリプト誤動作、WSL2とネイティブWindows間のファイルシステム境界問題——これらは事前に回避策を把握していないと、デバッグに数時間を費やすことになる。ローカルLLM運用では、モデルのコンテキスト長制約がクラウドモデルより厳しいケースが多く、圧縮戦略をより積極的に設計する必要がある。
ハナの所見
今回の調査を通じて、ハナが最も強調したいのは一つの逆説だ。「並列化＝高速化・効率化」という思い込みが、小規模開発者にとって最大のコストリスクになっている。
具体的な懸念点
TOKIUMの事例が示した3つの事故——二重着手・設定ファイル競合・done申告の虚偽——は、いずれも「エージェントが自分の状態を正確に把握できない」という根本的な問題から生じている。これはモデルの性能向上では解決しない構造的な問題だ。並列セッション数を増やせば増やすほど、この問題の発生確率は線形ではなく指数的に増加する。10セッションで2件の事故が起きたなら、20セッションでは単純計算の4件ではなく、それ以上の混乱が生じる可能性が高い。
さらに深刻なのが課金トラップだ。パイプ渡し・非対話起動が従量課金APIとして扱われる可能性があるという事実を、日本の開発者の大半は把握していない。自動化スクリプトを組んで「よし、エージェントが勝手に動いてる」と思っていたら、翌月に予算の数倍の請求が来るという事故は、2026年末にかけて日本でも増加すると断言できる。
日本特有の障壁
日本のAI開発現場には、この問題を悪化させる固有の障壁が3つある。
- Anthropicの利用規約・課金ドキュメントの英語一次情報への接触率の低さ：blessed経路と非対話起動の課金差異は、英語の公式ドキュメントを読まなければ把握できない。日本語の二次情報では、この重要な違いが省略されるケースが多い
- 「動いたら正しい」という検証文化の弱さ：done申告を疑う設計——回収スイープの実装——は、AIの出力を人間側が能動的に検証するという発想を前提とする。しかし日本の開発現場では、AIが「完了した」と言えば完了したとみなす受け身の運用が定着しやすい傾向がある
- フリーランス・スタートアップへのオーケストレーション知識の普及遅れ：大企業のAI活用事例は増えているが、個人開発者・小規模チームが参照できる本番運用の具体的知見は、2026年9月時点でもまだ体系化されていない
時期を明示した予測
2026年末までに、Claude Codeの非対話起動による想定外課金トラブルが日本のX（旧Twitter）やZennで複数報告される。これは予測ではなく、現在の普及速度と課金構造の複雑さから導かれる必然だ。
2027年第1四半期には、台帳ファイルベースの「最小有効オーケストレーション」テンプレートがGitHubで広く共有されるようになり、エンタープライズ向けフレームワーク導入より先にこのアプローチを試す開発者が日本でも主流になる。TOKIUMのForemanモデルが示したのは、技術的洗練さではなく「疑いの設計思想」——AIの自己申告を信じない、課金経路を明文化する、成果物の実在を独立検証するという人間側の規律だ。この規律は大企業も個人開発者も変わらない普遍的な教訓であり、フレームワークの選択より先に身につけるべき設計哲学だ。
台帳ファイル1枚から始める「最小有効オーケストレーション」——まず今日、自分のタスクリストを「前工程の出力が後工程の入力になるか」という一問で仕分けることから始めてほしい。それが、コストを半減させる設計判断の第一歩だ。
あなたの現在のAIエージェント構成は並列化すべきか、直列のままにすべきか——まずタスクの依存関係を書き出すことから始めてみてください。設計判断の具体的な相談や事例共有は、ニュースレター読者限定のDiscordコミュニティで受け付けています。
