tako

なぜ作ったか

作り始めたきっかけは、Claude Code を日常的に使うようになって、コードを考えている時間より画面を整えている時間のほうが長いと気づいたことだった。

tako で目指しているのは、人が受け持つのは AI との会話だけ、という開発のかたちだ。ファイルを開いて見せる、変更の差分を並べる、動かしたサーバーの出力を横に置く。こうした画面の段取りまで AI が引き受けてくれれば、人は出てきたものを見て「それでいい」「そこは違う」と返せば済む。ところが手元のターミナルには、AI がタブやペインの配置に手を出す口がなかった。

名前は蛸から取った。何本もの腕（ペインやエージェント）を、1 つの頭（タブ）が束ねている姿を重ねている。

作り方の判断と経緯

Windows のビルドを初日から回し続ける

最初のコミットは 2026 年 6 月 11 日。Electron を使わずに速さを出すため、描画は Rust と Zed の GPUI で、端末のエミュレーションは alacritty_terminal に任せると決め、この日のうちに仕様書と両方の試作、macOS と Windows の両方でビルドとテストを走らせる CI までを入れた。いちばん大きな賭けは GPUI が Windows で動くかどうかだったので、そこから先に確かめている。macOS で機能を積みながら Windows のビルドも毎回通しているのは、最後にまとめて移植するのを避けるためで、GPUI の Windows 対応がどこまで進んだかを追い続ける意味もある。

閉じても作業が消えないようにした代わりに

2 日目には、ファイルツリーやプレビューの作業をいったん止めて、すべてのペインの中身を tmux のセッションとして持つ作りを先に入れた。tako を閉じて開き直しても、動いていたエージェントやサーバーが画面ごと戻ってくる。

その分、画面の並びと tmux の側の実体という 2 つを食い違わせない手間を背負うことになった。7 月 13 日には、使っている最中の tako から全部のペインが消えた（#177）。調べると、tako を作っている AI の worker が、動作確認のために開発中の tako をもう 1 つ起動していた。切り離しが半端だったそちらが自分を本物だと判定し、本物がつないでいた tmux のセッションを横取りしていた。ペインを失った本物の側は、縮んだ並びで保存を上書きしていた。直した版は同じ日に入れている。復元の前に別の tako がつないでいないかを確かめて控えに回る、ペインが半分未満に減る保存の前には直前の並びを退避する、試験用の起動を 1 つの環境変数でまとめて切り離す、退避から戻す tako recover を足す、の 4 つだ。

AI にできない画面の操作を作らない。例外は 1 つだけ

画面でできることは、すべて CLI と MCP からもできるようにする、を開発の決まりにしている。機能を足すたびに AI 向けの道具も増えるので、MCP のツールは 10 月 9 日の時点で 160 本になった。

仕様で唯一の例外にしているのは、スマートフォンなど別の端末から tako を操作するリモート接続の承認だ。新しい端末に操作の権限を渡すかどうかは、Mac の画面の前にいる人しか決められない。ここまで AI が代わりにできてしまうと、端末の認証を二段にしている意味がなくなる（#283）。

tako を、tako の上で AI に作らせる

6 月 18 日には、master のエージェントが複数の worker に作業を割り振り、その画面を tako の中に並べて見張るオーケストレーターを入れた。7 月からは、Issue 1 件ごとに worker が PR を出し、master が確かめて取り込む形で開発している。6 月は main に直接入れていたコミットが、7 月以降は 8 割（1,062 のうち 866）が PR を通っていて、main 全体の 84% は Claude との共著だ。リリースも、前の版から変更があった夜だけ手元の定期実行（launchd）がプレリリースを作って出し、Homebrew で配る安定版へは別に昇格させている（#166）。

速さのために描画を作り直した経緯（裏のタブの出力でも画面全体を描き直していた問題など）は、測った数字と一緒に tako 開発日記 #1 に書いた。

数字で見る今

2026 年 10 月 9 日に、GitHub とリポジトリ、tako のドキュメントで数えた。

項目	値
コミット（main）	1,333。うち Claude との共著が 1,119
Issue	1,059 件。閉じたものは 804 件
プルリクエスト	885 件。マージしたものは 868 件
リリース	83 回（安定版 28・プレリリース 55）。v0.1.0 は 6 月 26 日、最新の安定版は v0.8.26（9 月 30 日）
MCP のツール	160 本
テスト	6,515 件（10 月 9 日の全体の実行）
Rust のコード	620 ファイル・約 57 万行（テストを含む）
Windows の対応表	160 項目のうち 123 項目が「対応」
ドキュメント	34 ページ

始めてから 4 か月で、Issue は 1 日に 9 件近いペースで立ち、その 4 分の 3 が閉じている。作業を Issue 1 件ずつに切り、AI の worker に 1 本ずつ PR を出させて取り込む進め方が、この数字の大きさに出ている。

これから

いちばん大きな残りは Windows だ。対応表の 123 項目は Windows の実機で確かめたものだけを数えている。アプリのセルフテストを実機で最後まで通し、「一部対応」「未実測」「未対応」の 35 項目を減らしていくのが次の段になる（#467）。

使い始めの手間もまだ残っている。プログラミングを知らない人にも届けるには、tako setup が案内を出して止まる箇所を減らし、検出から導入まで自動で済ませたい（#1500）。8 月末からは、当初「やらない」に入れていた LSP の統合（補完・診断・定義ジャンプ）にも取り組んでいる（#1007）。10 月には、Claude Code の画面の中に使用量の残りや worker の様子を出す、mod の仕組みも始めた（#1877）。

関連リンク

• アーキテクチャ … クレートの分け方と、CLI・MCP・パッシブ検知の 3 層の連携
• Windows 対応状況 … 上の対応表の中身。項目ごとに確かめた方法が載っている
• リリースノート … 版ごとの変更
• tako 開発日記 #2（Zenn） … チャットの表示を仮想リストにして、メモリの残りを 10 分の 1 にした話