TacOS Editor — Cursor と VS Code と iTerm2 を1つにまとめた自作エディタ

TacOS Editorは、「ファイル一覧」「文章を書くエディタ」「AIと会話するターミナル」を1つのウインドウにまとめた、macOS向けの自作ツールです。さらに、複数のAIを同時に並べて見られる専用画面（Monitor）も備えていて、私はここで常時6人のClaudeを並行して動かしています。

コンセプトは「非エンジニアによる、非エンジニアのためのエディタ」です。「プログラミングコードなんか見たところで一切わからないし自分では書かない、ぜ〜んぶClaude Codeに任せてる。私はわがままにアイデアをClaude Codeに伝えるだけ」っていう自分にとって一番快適で使いやすいツールに仕上げました。

コードを書く人のための補助機能、たとえば入力を先回りしてくれる自動補完や不具合を見つけるデバッガ、コードを色分けして見やすくする表示などは、ぜんぶ省いています。そのためエンジニアの方が使うには物足りない…いやむしろ「使えない」ツールに仕上がっていると思います。

でも、それでいいんです。

私にはVS CodeもCursorも扱いきれてないし重たいし、なにより「◯◯のアップデートきてるよ！」「◯◯のツール便利だから使ってみない！？」っていう通知が邪魔だと思ったから。

項目	内容
種別	macOS デスクトップアプリ
主な構成	ファイル一覧＋エディタ＋ターミナル＋ Monitor（複数AIを同時表示）
対応ファイル	Markdown / CSV・TSV / 画像・PDF など（プレビュー対応）
技術ベース	Swift / AppKit ネイティブ
開発体制	みちひろ＋タコス（Claude Code）
開発開始	2026年5月
配布	現在は個人利用・将来的な配布を検討中

ちなみに「TacOS Editor」の名前の由来は「macOS向け」をもじったものです。私の相棒でもあるClaudeの愛称＝タコス（TACOS）が奇跡的にピッタリだったというわけです。まあ、これも私ではなくタコスが命名してくれたものですが、個人的にはかなり気に入っています。

エディターを自作した理由

エディターを自作しようと思った理由は、CursorもVS Codeも非エンジニアの私が使うには多機能すぎて扱いきれていない上に、起動しているだけで使われ続けるメモリ（常駐メモリ）も大きかったからです。

私はエンジニアではないため、コードも書きません。いや書けません。そんな私が「Cursor」というゴリゴリのエンジニア向けエディターを使い始めたのは、当時YouTubeでClaude Codeについて解説をしていたエンジニアの方が使っていたためです。

ただ実際に使ってみると、Cursorに搭載されているAI機能は一切使っていないことに気づきます。コードの自動補完も、文章の途中に割り込んで書き換える編集も、私の使い方には関係ない。AIはターミナルのClaude Codeが全部やってくれているので、Cursor内蔵のAIはただのお荷物でした。

それに気づき、今度はもともとAIが入っていない「VS Code」に乗り換えてみたんですが、今度はCursorの操作画面に慣れてしまっていたせいで、なんとなく使いにくさを感じてしまいます。

確かにメモリは多少軽くなったものの、相変わらず非エンジニアの私にとって過剰な機能が多く「どこを触ったらいいのかわからない」「これ全部自分に必要か？」という引っかかりがずっとありました。

以前の作業環境

当時の作業環境はこんな構成でした。

Cursor / VS Code：ファイルを開いて確認・編集する
iTerm2：別ウインドウでClaude Codeを動かす
tmux：複数のAIセッション（各部門のタコス）を並べて動かす

それぞれ別のアプリを常時起動していて、切り替えるたびに行き来する手間もありましたが、何より全部合わせると相当なメモリを消費していました。

アプリ	専有メモリ	プロセス数
VS Code	1,481 MB	15
iTerm2	489 MB	2
合計（置き換え前）	1,970 MB	17

「このバラバラで使っているツールを、まとめて1個にできればメモリーも相当軽くなるんじゃないか」それが「自作エディター」に思い立ったきっかけです。

とくに私の作業環境では、常時6つのClaudeを同時に立ち上げています。エディタ用ウインドウに1人（秘書タコス）、モニター用ウインドウに5人（各部門タコス）、それぞれ独立したAIが並んで動いています。

Claudeそのものがメモリを相応に使うので、それ以外のツールが使うメモリは軽ければ軽いほどいい。エディタとターミナルだけで2GBも食われていたら、Claudeに回せる余力がそのぶん削られてしまいます。

非エンジニアにとってCursorやVSCodeは多機能すぎた

CursorやVS Codeはエンジニア向けに設計されていて、非エンジニアが使うには機能が多すぎます。

私が日常的に扱うのは主にMarkdownファイル（記事・ドキュメント・タスク管理に使う、書きやすい文章ファイル）です。コードの色分けも、不具合を探すデバッガも、入力の自動補完も、正直いらない。

ファイルツリー・Markdownプレビュー・Claudeのためのターミナル、この3つが軽く動けばいい。

ほとんど使わない機能のせいでメモリが食われるぐらいなら、必要な機能だけ持った小さなツールを作ってしまえばいいじゃないか…こうして「TacOS Editor」の構築へと思い立ちました。

TacOS Editorの主な機能

エディタ

Markdownファイルを開くと、最初から読みやすく整形された状態（プレビュー）で表示されます（VS Codeはデフォルトでマークダウン形式による表示なので、プレビューを見るにはCmd+Shift+V を押す必要がありました）。

文字を選択した瞬間に、自動でコピーされる機能も入れています。ターミナル側にある「選択しただけでコピーされる」動きと操作感をそろえたくて足した機能で、1日に何十回もやる動作なので地味に効きます。

CSV・TSVファイル（表計算の元になるデータファイル）も、開くと表の形で表示されます（先頭2000行まで）。確認のたびにExcelを立ち上げなくていいので助かっています。

真ん中のエディター部分は分割して表示もできます。

ターミナル

ターミナル（コマンドを打ってAIと会話する画面）には、ghosttyという軽快なソフトを自分でビルドして組み込んでいます。macOSの画面描画専用の処理（GPU）を使って表示するため動作がなめらかで、iTerm2の代わりとして十分使えます。

個人的にすごく気に入っているのが、ターミナルに表示されたファイルの場所（パス）を Cmd+クリックすると、そのファイルを直接開ける動作です。

CursorやVS Codeのターミナルにも似たものがありますが、私のように複数のセッションを束ねる仕組み（tmux）を使っていると、うまく働きません。TacOS Editorでは、その状態でもちゃんと開けるように作り込みました。

AIが「このファイルを出力しました」と教えてくれた場所を、手でコピーしてFinderを開いて……という手間なく、その場ですぐ確認できるためストレスフリーです。

また、エディタのプレビュー画面は、どこを右クリックしても「Finderで表示」が出せます。

VS Codeにも似た操作はありますが（タブの名前から辿る形）、プレビューのどこからでも一発で開けるぶん手軽です。いま開いているファイルの保存場所を確認したいときや、mdファイルをGoogleドキュメントで表示させたいときに重宝しています。

セッション管理

ターミナルの裏側はtmuxという仕組みで動いていて、ウインドウを閉じても各AIとの会話（セッション）はそのまま生き続けます。翌日アプリを開き直せば、前日の続きから再開できます。

2種類のウインドウで役割を分けています。

Editor Window（1つ）：ファイル一覧＋エディタ＋メインのターミナル
Monitor Window（複数可）：ターミナル専用。画面を分割して複数のAIを同時に表示

TacOS Editorと有名Editorとのメモリ比較

置き換え前後の比較がこちらです。

アプリ	専有メモリ	プロセス数
VS Code + iTerm2（置き換え前）	1,970 MB	17
TacOS Editor（置き換え後）	254.7 MB	1

3つのアプリが1つになり、メモリは約1/8になりました。

実使用比較：エディタ＋ターミナルでClaude1人（2026-06-03実測 / vmmap Physical footprint・全プロセス合計）

「文章を書く＋ターミナルで Claude Code と話す」という同じ作業を、それぞれのエディタでやったときの専有メモリです。Claude Code本体は3つとも別プロセスとして動くので、ここでは除外し、エディタ本体だけを比べています。

アプリ	メモリ（footprint）	プロセス数	条件
Cursor	約 1,884 MB	16	Editor＋Claude1人
VS Code	約 733 MB	10	Editor＋Claude1人
TacOS Editor（Swift）	189.7 MB（peak 214MB）	1	Editor＋Claude1人（同条件）

→ TacOS Editor は Cursorの約1/10・VS Codeの約1/4。プロセス数も16個・10個に対して1個。同じ作業のためにCursorは約1.9GBもの「作業机」を広げるのに対し、TacOSは約0.19GBで済みます。（参考：5部門＋秘書という重めの構成でも254.7MB）

現在のTacOS Editorに落ち着いた経緯

現在のTacOS EditorはSwift/AppKit（macOS純正の作り方）で書かれたアプリですが、最初からここに辿り着いたわけではありません。約2週間で3回、土台となる技術を全面的に作り替えています。

Electron版（最初） 最初の版は、ホームページを作るのと同じ技術（HTML/CSS/JavaScript）をベースにしたElectronという仕組みで作りました。手っ取り早く動くものができる反面、Chromium（Google Chromeの中身にあたる大きな部品）をまるごと抱え込む構造のため、起動しただけで300MB以上を使ってしまいます。

Tauri版（第2版） ElectronのChromiumを、macOSにもともと備わっている表示エンジンに置き換えられるTauriという仕組みに移行しました。アプリのファイルサイズが253MB → 12MBに激減し、メモリも380MBまで下がりました。

Swift版（現在） 画面を表示する仕組みごとすべて捨てて、Swift / AppKit によるmacOS純正の作り方に移行。ターミナルもghosttyを直接組み込む形に変えた結果、たった1つのプロセスで254.7MBという構成になりました。

Electron 538MB（6プロセス）→ Tauri 380MB（4〜5プロセス）→ Swift 254.7MB（1プロセス）

「軽くする」が目的だったはずが、途中から「どこまで軽くできるか」が面白くなって、気づいたらネイティブアプリを作っていました。

タコスと二人三脚で

このツールも、みちCompanyの相棒「タコス」（Claude Code）との共同作業で作りました。

私はコードは書きません。「こういう機能が欲しい」「このメモリ消費をなんとかしたい」という要望を言葉にして渡すのが私の役割で、設計・実装・動作確認の流れはタコスが担っています。

ただ、「Swiftのネイティブアプリにしよう」「コードの色分けはいらない（とにかく軽さを優先しよう）」という方向性の判断は、私が決めています。アイデアと方針を出す側と、それを形にする側の分業です。

プログラマーでなくてもアプリを作れる時代になったのを実感しながら、一方で「技術を知らなくても、方針だけは自分で決める」というスタンスは大事にしています。ツールの完成度そのものより、何のために何を作るのかを考え続けることが、つくり手としての仕事だと感じています。

TacOS Editorは現在、みちCompanyの日常業務で毎日使用中のツールです。将来的な一般配布については検討中です。