initechプロジェクトの技術記事。
March 28, 2026
なぜAIエージェント用のターミナルマルチプレクサを構築したのか
複数のClaude Codeエージェントを並列管理するGo TUIを構築しました。セッションランタイムとしてtmuxを置き換えました。
各エージェントにロール固有の指示を持つClaude Codeターミナルを与えます。supervisorエージェントが調整。エンジニアエージェントが実装。QAエージェントが検証。shipperエージェントがリリース。各エージェントは、アイデンティティ、制約、ワークフロー、通信プロトコルをエンコードするCLAUDE.mdを持ちます。
initechを構築する前に、4つのプロジェクトでこのパターンを実行しました。並列エンジニアリング、独立したQA、リリースゲーティング、セッション間の組織記憶を備えた実際のソフトウェアをシップしました。
tmuxはエージェントを追加するほど悪化する3つの問題を抱えています。
tmux send-keysには配信保証がありません。エージェントのペインにメッセージを送り、届くことを祈ります。届かなくてもエラーは出ません。engからsuperへの完了報告がドロップすると、superはengの完了を知らず、QAはディスパッチされず、ビーズは1時間停滞します。
ハングしたエージェントと生産的なエージェントは、tmuxでは同じに見えます。完了と作業中も同じに見えます。確認する唯一の方法は各ペインを覗くこと。9エージェントなら、10-15分ごとに9回の手動チェックです。
tmuxはどんな作業があるか、誰が何に割り当てられているか、エージェントがタスクをready for QAにしたことも知りません。全てのオーケストレーションはsuperのコンテキストウィンドウに存在します。コンテキストはコンパクトされ、メッセージは失われ、supervisorエージェントはengの完了を忘れ、ディスパッチチェーンが停滞します。
tmuxは汎用ターミナルマルチプレクサであり、アプリケーションレベルのインテリジェンスが必要な仕事をしています。
各セッションはUnixドメインソケットを実行します。initech sendはエミュレータを通じてエージェントのPTYにテキストを書き込み、配信を確認します。送信者は数秒以内に明示的なOKまたはエラーを受け取ります。
$ initech send eng1 "fix the auth bug in middleware.go" $ initech peek eng1 -n 20
最初にJSONLセッションログのテーリングを試しました。信頼性なし：Claudeは会話の境界でJSONLに書き込みますが、予測不能です。45秒の思考中の停止で、エントリはゼロ。タイムアウトのどんな値も、何かのケースでは不正解です。
正解：PTYが最後に出力を生成した時間を追跡。Claude Codeのスピナーは思考中に10-30 fpsでアニメーション。出力ゼロの唯一の状態はプロンプトでのアイドル。2秒の閾値でクリーンなバイナリ検出が可能。
緑は稼働中。グレーはアイドル。黄色はタスク待ちでアイドル。オーバーレイでペインを開かずに全エージェントの状態を表示。
JSONLはアクティビティ検出には失敗しましたが、セマンティックイベントには機能します。セッションログにはツール使用結果、アシスタントメッセージ、エラーシーケンスが含まれます。イベントシステムはこれらを解析して：
* ビーズ完了：エージェントが実行 bd update --status ready_for_qa
* 停滞：ビーズ割り当て中に10分以上出力なし
* エラーループ：3回以上連続のツール失敗
* ビーズクレーム：bdコマンドから自動検出、追加のCLIコール不要
イベントはトースト通知として表示。superが報告する前に「eng1 completed ini-bhk.3」が緑色で表示されます。
各エージェントのリボンに現在のビーズを表示。オーバーレイで全エージェントの状態を一覧。エージェントがビーズを保持したままアイドルになると、TUIがsupervisorエージェントに直接通知：「[from initech] eng1 is now idle (bead: ini-bhk.3). Check if work is complete.」
上記の全ての数字はツール自体が生成したものです。initechはinitechを構築したエージェントを管理しました。
TUIはランタイム。テンプレートがインテリジェンス。悪いCLAUDE.mdはTUIがどんなに良くても悪い出力を生みます。11のテンプレートを3回書き直し、実際の失敗からの教訓をコード化：エンジニアエージェントがPLANコメントをスキップ、QAエージェントがラバースタンプ、supervisorエージェントがディスパッチせずに作業を実施。
PTYバイトリーセンシーが機能するまで3つのアプローチを試しました。JSONLテーリング：遅すぎ。ターミナル出力レート：SIGWINCHの偽陽性。プロンプト検出：UI変更に脆弱。スピナーアプローチはClaude Codeが作業時に常に出力するから機能します。静的な「thinking...」表示では壊れます。
supervisorエージェントの最大の失敗：ディスパッチせずに実装すること。ディスパッチは遅く感じます。しかし、マルチエージェントの要点は専門化です。「エージェントを使わない」がsuperテンプレートの最初のクリティカル失敗モードになりました。
全てのエージェントは最終的にコーディング前のPLANコメント、ready_for_qa前のpush、ビーズ表示のクリアを忘れます。auto-notifyはエージェントが完了報告を忘れるために存在します。ガードレールは助けになりますが、完全には排除できません。プロセス遵守はバイナリではなく、グラデーションです。
セッション移植性 は未着手。マシン間（MacBookからワークベンチへ）のセッション移動は手動rsyncが必要。PRDには initech migrate コマンドが記述されていますが、まだ存在しません。
リソース管理 はフラグの後ろにあります。メモリプレッシャー下でのオートサスペンド/レジューム（36GBノートPCで有効なエージェント容量を倍増させる機能）は実装済みですが、 --auto-suspend の後ろにゲートされています。ポリシーが実セッションで十分にテストされていないためです。
オンボーディング は荒削りです。初めて initech を実行した新規ユーザーは、ガイダンスなしで7つのペインを見ます。ステータスバーのヒントが下部に表示されますが、完全なワークフローを文書化したオペレーターガイドはありません。このツールは自身のユーザーによって構築されたもので、それが表れています。
初期段階。 initechは現在、複数のプロジェクトで使用されていますが、ユーザーベースはまだ小さいです。より多くの実際の使用がドッグフーディングでは見つからなかったギャップを明らかにするでしょう。
curl -fsSL https://initech.sh/install.sh | bash mkdir myproject && cd myproject initech init initech