はじめに：AIエージェントが増えすぎた結果起きたこと

最近、CursorやClaude Code、ClineといったAIエージェントツールをローカル開発でフル活用しています。

私の運用では「1プロジェクトにつき1つのClaude Codeを起動する」というスタイルをとっているため、複数のプロジェクトやレイヤー（フロント、API、インフラなど）を並行して進めていると、無数のAIセッションが同時に動くことになります。

最初は「ターミナルで指示するだけでコード書いてくれる！最高！」と感動していたのですが、息をするように大量のAIを同時稼働させるようになった結果、ある悩みが……。

そう、「AIエージェント多すぎて迷子になる問題」です。

バックエンドのAPI改修をClaude Codeに任せつつ、フロントエンドのコンポーネントをCursorで実装し、裏で別のインフラ設定を走らせる。
そんなことをやっていると、ターミナルのウィンドウが散乱します。コーヒーを淹れて戻ってくると、「あ、30分前からファイルの上書き許可（Y/n）で止まってるじゃん……」という悲劇が頻発。

ターミナルを何度も切り替えないと状況が分からず、 AIの力を引き出すためのはずが、ターミナルの管理に時間を使っている ことに気づきました。

既存ツールとの決定的な違い（Terminal vs Project）

この話をすると、「TmuxやZellijみたいなターミナルマルチプレクサを使えば？」「WarpやGhostty等の次世代ターミナルがあるじゃん」「LumberghやCliDeck、Cockpitでセッション管理すればいい」と言われることがあります。

もちろん、それらはどれも優れたツールです。しかし、競合というより「解決している課題」が全く異なります。

既存のツールは 「Terminal」 や 「AI Session」 を管理しています。
しかし、私が欲しかったのは 「Project全体の状態把握」 でした。

知りたいのは、Terminalの黒い画面そのものではありません。
「今どのProjectが動いているか」「どのAgentが止まっているか」「自分待ちなのか」「Review中なのか」「次に自分が何をするべきか」という情報です。

画面の主役はTerminalではなく、Projectであるべきなのです（Project First）。

管理したいのはAIではなく、人間の「認知負荷」

私はこの問題を解決するために、SwiftUIでネイティブなmacOSアプリ「AI Control Center」を自作しました。

このアプリの根底にあるのはHuman Firstの思想です。
AIエージェントが増えるほど、人間が全体を把握するコストは急激に上がります。開発のボトルネックはもはや「コーディング」ではなく、「状況把握」と「コンテキストスイッチ」へと移行しました。

だからこそ、「今、自分の番か？（Waiting User）」がたった5秒で分かること。それだけで計り知れない価値があると考えました。

最大の発明：AIを抽象化する「Status Contract」

このツールを実現するにあたり、一番最初に諦めたのが「ターミナルの標準出力（stdout）を監視・パースする（Terminal Parsing）」というアプローチです。
エージェントごとにUIも出力も違い、アップデートで簡単に壊れるからです。

そこで発想を転換し、 「AIを共通の状態モデルで抽象化する」 ことにしました。

AI Control Centerは、Claude Code専用のビューワーではありません。
Claude Code、Cursor Agent、Gemini CLI、Aider、そして将来登場するであろう未知のAgentを、すべて共通の 「Status Contract」 で扱うことを目指しています。

具体的には、各プロジェクトのルートに .ai/agent-status.json を配置するというルールを設けました。

{
  "schema_version": "1.0",
  "agent": "claude-code",
  "status": "waiting_user",
  "workflow_phase": "deploying",
  "progress": 0.8,
  "task": "Permission required: write to /etc/hosts",
  "branch": "main",
  "started_at": "2026-07-28T09:00:00Z",
  "updated_at": "2026-07-28T10:05:33Z"
}

ダッシュボード側はAgentを直接解析するのではなく、このContract（JSON）だけを読みます。
これがFile-Based Status Architectureです。

長期的には、Agentが増えてもダッシュボード側は変更不要になります。新しいAgentは、このStatus Contractを実装するアダプターを用意するだけで済みます。

実は、私が作っている本当の価値はMacアプリではなく、この「AIエージェント間の共通ステータス仕様（Status Contract）」そのものなのかもしれません。
これが安定すれば、AI開発ツール間をつなぐ強力な基盤になり得ると確信しています。

採用した技術スタックとMVP機能

現在実装しているMVP（最小限の機能）は以下のような構成です。

リアルタイム状態検知：思考中、実行中、ユーザー待ちなどの状況を可視化
通知機能：承認待ちになった瞬間にmacOSネイティブ通知でお知らせ
ターミナルジャンプ：リストをダブルクリックで対象ターミナル（Terminal.app, iTerm2等）へ即座に移動

技術的には、以下のモダンな構成を採用しています。

Swift 6 & SwiftUI：Combineは使わず、@Observable とActorモデル（@MainActor）を活用。
FSEvents (FSEventStream)：低レイヤAPIでJSONの更新を検知。
AsyncStreamブリッジ：C言語ベースのコールバックを async/await に安全にブリッジし、超低負荷で監視。

今後の展望：Dashboardではなく「Mission Control」へ

このプロジェクトが目指すのは、単なる便利ツールではなく、Mac全体で動くAI開発の司令塔、つまり 「AI Development Operating System（AI開発用OS）」 です。

ゆくゆくは、状態だけでなく開発の「Workflow」も管理します。
Spec → Plan → Coding → Testing → Review → Done という流れをプロジェクト単位で可視化し、アプリ上から直接AIのチャットを覗き見たり、ワンクリックで承認（Approve）を出せるようにする予定です。

おわりに

今回は、無数のAIエージェントを束ねるための思想と、共通仕様としての「Status Contract」について紹介しました。

次回以降のシリーズでは、 「Swift 6でC言語のFSEventsをAsyncStreamに安全にブリッジする実装」 や、 「通知とターミナルジャンプをAppleScriptで強引かつエレガントに解決した話」 など、よりディープな技術的トピックを書いていこうと思います。