AIへの指示専用の本格エディタを、自分が欲しいから作った話
何番煎じかわからないけど、AIへの指示専用、「思考の鍛冶場」となる自作エディタを、AIに作らせて、メインのエディタを置き換えた！
こんにちは。生成AI（ChatGPT、Gemini、Claude など）が息をするように使われる現代、皆さんは 「AIへの指示出し（プロンプト）の作成」 をどこで行っていますか？
ブラウザのチャット入力欄に直接書き込んで、「もう少し推敲しよう」と思った矢先に誤ってEnterをターン！と叩いてしまい、未完成の指示が送信される絶望を味わっていませんか？
あるいは、VSCodeなどのメインエディタの端っこに temp.md や prompt_01.txt のような一時ファイルを作り、気づけば「名称未設定ファイル」がディレクトリを汚染していませんか？
以前は、AIへの指示は、あまり複雑なものは書かないこと、がある種のベストプラクティスだったのですが、特に昨今「エージェント型」に依頼する際には、一度にかなりまとめた量の指示を投げつけることになります。AI指示用の文章は日に日に複雑化していきます。私は日々、生成AIを活用した開発を行う中で、ある強烈な課題感を抱くようになりました。
「AIと本気で共創するなら、メインの開発環境とは物理的に切り離された、『指示を練るためだけの専用エディタ』が必要なのではないか？」 と。
そしてもう一つ、個人的で非常に切実な欲求がありました。
「作業中に画面の背景にお気に入りの画像（推しのキャラクター、あるいは心落ち着く風景）をいい感じの透過度で敷き詰めて、爆発的なモチベーションでタイピングしたい！！！」
さらに、 「自宅のMacでも、会社のWindowsでも、全く同じ美学・同じショートカットキー・同じ使用感で動く軽量なサブエディタが欲しい」 というわがままな条件まで重なりました。
さまざまなエディタを探しましたが、上記の要件に合致するものはなかなか見つかりません。 「そうだ！であればこの時代、自分で専用のエディタを作ってしまおう！というか、AIに作らせてしまおう！！」
それが、今回リリースした 「TansenEditor（鍛洗エディタ）」 です。
「AIへの指示専用」ですが、日常のちょっとしたメモや、普通のエディタとしても十分使いやすい機能を搭載しておりますので、ぜひお試しください。
様々な機能があるので、まずは一度紹介ページを見てみてください。
私も、実質的なメインエディタをコレに置き換えました！
この記事では、AI任せで、エディタという「無限の魔境」を開発した汗と涙の冒険譚、そしてエディタ開発から学んだ「哲学」について、学びのメモを残しておこうと思い記載します。このエディタの開発自体、このエディタを用いてAI指示を作成していたのですが、そのコンセプトや指示内容を、またAIにまとめて読ませることで、こういった学びの記録も、効率的に記事としてまとめることができます（多重AIループ構造）。
1. コンセプト：「思考を分離」し「鍛え、洗う」
なぜ既存のエディタではダメなのか？
現代のソフトウェア開発において、VSCodeなどの強力なIDEは「AIが生成したコードを受信し、プレビューし、デバッグし、デプロイする場所」へと役割を移しつつあります。
そこは言わば「実行と思考の出力先（フロントライン）」です。
しかし、AIに対して「こういうアーキテクチャで、こういう制約で、こんなコードを書いて」と長文の要求を組み立てる作業（プランニング）は、実行の場で行うとノイズが多すぎます。開発コード（成果物）と、AIへの指示（メタ情報）が同じエディタ内で混濁すると、人間の脳のコンテキスト・スイッチに負荷がかかります。「開発用」と「ちょっとしたメモ用」は分離しておきたい、のが自然の欲求ではないでしょうか。
一方で、既存のサブエディタ、は少し前時代のものが多いため、逆にシンプルすぎる、AI連携機能が無い、Windows版またはMac版しかない、などの課題が出てきます。
TansenEditorの哲学
「Tansen」は「鍛洗（たんせん：鍛え洗うこと）」に由来します。
AIへの指示をただの使い捨ての文字列ではなく「設計図」として捉え、鍛え、洗い、磨き上げるための軽量・シンプルエディタ。これがTansenEditorの根本哲学です。
TansenEditorを支える3つの柱
-
シンプル・軽量・軽快なクロスプラットフォーム
MacとWindowsの両方で同じようにサクサク動くこと。多すぎるボタンやロード時間などは排除しました。 -
AI親和性と「ストック化」
Ctrl + N(新規作成) を押すだけで、自動的に現在日時のファイル名（例:20260406_1200_00.txt）で保存が開始されます。指示を「使い捨て」にするのではなく、思考の履歴として自然にストックされていく設計です。 -
徹底的なモチベーション特化（背景画像・透過機能）
どんなに良いエディタでも、気分が乗らなければ意味がありません。任意の壁紙を設定し、メインのエディタ領域を透過させることで、常に推しを感じながら思考することができます。
2. 開発手法：「完全AI駆動」と「ドッグフーディングの極致」
今回の開発手法では、「私はコードを一切見ない。書かない。すべてAI（OpenCode等）に書かせる」という縛りを設けました。いわゆる流行りのバイブコーディングです。
そして、このエディタを改善するためのAIへのプロンプト自体を、開発中の『TansenEditor』自身を使って書いていきました。
自分が作った不完全なツールを使って、その不完全なツールをアップデートしていく。一種のドッグフーディングの極みであり、「自己を書き換えるプログラム」のような不思議なメタ体験が生じます。
初期段階の構築は驚くほどスムーズでした。「ファイルを開く」「保存する」「タブを作る」程度のことは、便利で洗練されたエディタ用のライブラリと、現代のLLMにかかれば一瞬です。
初期段階での工夫として、技術スタックを、軽量高速＆おしゃれなエディタ実装が可能な、最先端のライブラリや開発手法を事前調査し、最適なフレームワークを選定していたこと、も功を奏していたようです。
「AIすげえ！エディタ開発なんて一瞬で終わるじゃん！」……そう思っていた時期が、私にもありました。
3. エディタ開発の魔境：足し算と引き算、そして泥沼のバグ
エディタとは、少しでもプログラミングをかじった人間なら誰でも一度は作りたくなるものでありながら、底なし沼の代名詞でもあります。なぜなら「機能」というものを考え始めると、ユーザー（私）の欲求は無限大だからです。
そして、TansenEditorを使っていくうちに、思いもよらぬバグと仕様の衝突が発生しました。私の指示書ログ（何万文字もの阿鼻叫喚）から、激闘の歴史をいくつか抜粋します。
第一章：Windowsメニューバー・透明化無限ループ事件
当初は「エディタ全体を一発で透明化するボタン」を作っていました。
「ボタン一つでアプリ全体を透明化させてエディタの背後で実施している内容をすぐに把握できるようにする」という機能を実装しました。Mac版では美しく動いたのですが、Windows版には魔物が棲んでいました。
【ログより抜粋された私の悲鳴】
私「Windowsの場合、メニューバー（ファイルや編集）が透過度100%になって文字が見えないから直して。」
AI「直しました！」
私「直ったけど、今度は透明化モードにしてもアプリ全体が透明にならなくなったよ。これも両立させて。」
AI「直しました！」
私「またWindows版のメニューバーが完全透明になってるじゃん！！」
AI「直しました！」
私「もういいかげんにしてくれ！！！ 一方を直すと一方がデグレードしてる。Windows版でテストするのがすごく面倒なんだからもう二度と間違えないで！！」
OSネイティブのメニューバーの透過仕様と、エディタ本体の透過仕様がWindows環境下で激しくバッティングしていたのです。AIは場当たり的な opacity 調整を繰り返すだけで、根本的な解決に至りません。
「OSネイティブのメニューバーを使うのを完全にやめ、黒いカスタムタイトルバーをHTML/CSSで自前レンダリングしてそこにメニューを乗せる」という大手術まで行ったのですが、すると、今度はメニューバーが美しくありません。
最終的には、残念ながらこの透明化機能は完全に削除しました。
各種フレームワーク同士の衝突で、どうしても修正できない課題もあるものです。
第二章：IME（日本語入力機能）が明後日の方向へ飛んでいく事件
テキストエディタにおいて「文字がまともに打てない」というのは致命傷です。
ウィンドウを移動させたり、リサイズしたりすると、Windowsの日本語入力（IME）の変換候補が、カーソルの下ではなく 「画面の左上の遠い彼方」 に小さなポップアップとしてポツンと表示されてしまう怪現象が発生しました。
【ログより抜粋】
私「ウィンドウ移動すると、IMEの変換候補がおかしな場所に出る。WEBで調べて調査して。」
AI「調査しました。TauriなどのWebViewフレームワークにおいて、ウィンドウ移動時にOSとブラウザエンジンの間でのキャレット（カーソル）のスクリーン座標の同期が取れておらず、古い座標がIMEに送られ続ける事象です。Rust側のset_ime_cursor_area関数を強制的に叩く必要があります。」
私「原因判明したなら直して。」
AI「直しました！」
私「全 く 直 っ て な い 。」
Rust側のバックエンドと、React/WebView2のフロントエンドでのイベントのフックタイミングのズレという、フレームワークの深淵に触れるバグでした。
私はAIに対して、「もう一度WEBでTauriのIME不具合事例を検索しろ」「対処療法でもいいからウィンドウ移動イベント直後にフォーカスをリセットする処理を入れろ」「事象と実施策のレポートを出せ」と、冷酷なマネージャーのように指示を重ねました。
IME系の不具合は、よく見られ、かつ深刻化しやすい内容らしく、AIは頑張ってその修正とレポートを試みます。私はその深淵を理解していないものの、雰囲気で、こんな感じに修正してみて、とそれっぽいコメントを繰り返します。そのうち、おそらく捻り出した対処療法の何かが当たったようです。無事、執念で解決策を捻り出させることができました。
AIでのバイブコーディングは、その開発言語、フレームワークの真髄を理解していなくても、いわゆる 「指示ガチャ」 によって、ちゃんと修正できることもあるのです。
第三章：左右分割ペインのジレンマとState大渋滞
AIへの長文指示を書いていると、「左側でMarkdownを編集しつつ、右側にプレビュー表示」「過去の指示書を右側に置きながら、左側で新しい指示書を書く」といった左右画面分割機能が欲しくなります。機能として要求すると、AIはいともたやすく「画面を縦に二分割するUI」を作ってくれました。しかし……
【ログより抜粋】
私「ねえ、右側の画面でスクロールしたら、なぜか左側の別のファイルまで一緒にスクロールされるんだけど？」
AI「直しました！」
私「右の画面で編集してCtrl + S押したら、左の画面の同名ファイルがないってエラーが出て保存できない！ショートカットの適用先がおかしい！」
AI「直しました！」
私「右の画面でMarkdown編集してるのに、プレビューが全然更新されない！…これ、左画面に元のファイルが開かれてないとプレビュー更新されない仕様になってる？」
コンポーネントをただ雑にコピーしただけだったため、状態管理（ReactのState等）が左右で激しく混線していたのです。「キーボードのショートカットが発火した瞬間、現在アクティブなカーソルが左右どちらにあるかを判定し、そちら側の変数のみを独立して更新する」という原則をAIに教え込み、完璧な独立を果たすまで泥臭いテストを繰り返しました。
第四章：文字コード自動判定の洗礼（Shift-JIS vs UTF-8）
テキストエディタ開発者の「通過儀礼」とも言える文字コード問題。
WindowsにあるANSI（Shift-JIS）などのファイルを読み込んだ瞬間、エラーが発生。さらに、保存できない文字に対しては「黄色の波線でエラー警告を出す」といった細かいUI制御を要求し、ライブラリの拡張へと踏み込んでいきました。これもAIとの根気強い対話で実装しました。
第五章：拡張子関連付けとMacコード署名（Notarization）の壁
アプリを公開するうえで、最も隠された難題とも言えるものが 「macOSのGatekeeper（セキュリティ機能）」と「拡張子の関連付け」 でした。
エディタである以上、.txt だけではなく .md、.py、.json など、あらゆるテキスト系のファイルをアイコンとともに紐付け、「このファイルはTansenEditorで開く」という動作を作らねばなりません。エディタというのは予想以上に面倒なものなのです。
そして最大のハードルが、Mac版の配布です。
私「Macで実行ファイルをzipで固めて配っても、『悪意のあるソフトウェアかどうかをAppleが確認できないため開けません』って怒られるんだけど。Apple Developer Programには登録したよ。後はどうすればいいか詳しく指示して実行して。」
Appleの公証（Notarization）、証明書（Certificate）の管理、キーチェーンの登録、Tauriの設定でのチームIDの紐付け、そしてビルド時の環境変数付与……。
正直、私には何が何だかさっぱり分かりませんでしたが、「AIが全部やってくれた」のです。
これらを一つ一つ手作業で調べていたら、おそらく「Mac版は配布を諦める」という結末になっていたでしょう。
第六章：なんかわからないけどなんか重いの壁
選定したフレームワークは良くても、やはりエディタを作っていくと、打鍵時のもたつきのようなもの、が気になることも度々ありました。定期的に、症状をAIに伝え、原因の究明、および、デグレードリスクが無い形での解消、を指示し、都度リファクタリング、もたつきの解消をしていました。
こうした非機能要件では、一度の指示では解決しないことも度々ありました。また、一見よさそうな状況でも、例えば、複数ファイルを開いている時に重い、などのように、条件によって発動する重さ、は難敵です。どのようなケースを想定して確認をするのか、AIが出来ていないケースを想定しながら、受け入れ確認をする必要がありました。
UI/UX方面は、完全に手放しでAIに任せることは出来ません。とにかくドッグフィーディングを繰り返し、自身が違和感無く使えるツールになっているのか、常に確認してくことが、品質向上の鍵だと思います。
4. エディタ開発の哲学：なぜ謎機能が増えていくのか
「シンプルで軽量なエディタを作る」と言っていたはずが、TansenEditorにはいつのまにか謎の機能が大量に搭載されています。
- 電卓機能: 「ちょっと金額とか計算したい時に、いちいちOS標準の電卓アプリやスマホを出すのが面倒だから」という理由でサイドバーに生まれました。
- カレンダー機能: 「今日は何日だっけ？と確認したり、クリックでYYYY/MM/DDの文字列をコピーできた方が便利だから」という理由で生まれました。
- タイマー／アラーム・プレゼンタイマー: 画面の通知バーでトースト通知してくれます。「過集中してしまい、次の会議をすっぽかした」という私や同僚の個人的なトラウマから生まれました。
- ボスが来たボタン（MindRain）: ワンボタンでエディタ上にマトリックス風のオシャレな雨が降り注ぎ、謎のハッカー画面っぽくなります。別に勤務中に後ろめたいことはしていませんが、黒背景に緑色の文字が出る画面、はロマンとして必要でした。
「こんな機能、普通のプレーンテキストエディタに要る？」
一般向けの商用アプリケーションなら確実にボツになる機能たちです。「単機能に絞るのが美しい」という引き算の美学とは完全に逆行しています。
しかし、個人開発の最大の醍醐味はそこにあります。
「万人のための機能」ではなく、「今の私が、最高に欲しい機能」を追加する。処理を重くしない範囲であれば、自分の欲望に100%忠実な道具を作り上げる。「足し算と引き算」に悩みながらも、 「私が欲しいから要るんだよ！！！」 と叫んでAIに作らせる 「それはエゴだよ!!」 が、自作ツールのダイナミズムなのです。
そうそう「シンプルなAI連携機能」も一つの目玉です。AIへの指示を書くために、別スレッドで本当にちょっとしたことをAIに聞きたい、というのは良くあります。メインのAI作業場でスレッドを切り替えるという方法もありますが、メインを邪魔しないように、簡単な１往復程度の指示が出来ること、は地味に役立つでしょう。
5. 「エージェント型AI」の真の威力：ターミナルを一切触らない開発体験
今回、コーディングそのもの以上に私を感動させたのが、エージェント型AIによる「オペレーションの自動化」 です。
多くの人は、AIのメリットを「コードを書いてくれること」だと思っています。しかし真価はそこにとどまりません。
私の指示書ログには、日常的にこんな一言が記されています。
「OK、コミット、gitへのpush、そしてリリース物件と配布物の再作成までやっておいて。」
たったこれだけです。
AIはこれを理解し、自動的に裏でターミナルを立ち上げ、変更されたファイルを git add し、適切なコミットメッセージを生成して git commit し、リモートリポジトリへ push。さらにリリースビルド環境までもが自律的に実行され、完了を報告してくれます。
私は開発中、ターミナルすら開いていません。
黒い画面でコマンドを叩く必要すらなく、ただ日本語で「そうやっておいて」と話しかけるだけ。
開発からデプロイ、配布物の作成に至るまで、完全に「監督」の立ち位置から作業を終えることができる。これこそが、次世代の開発体験であり、「エージェント型AI」の計り知れないメリットです。
6. 人間は何をするのか？（AIコーディングの手触り）
全くコードを書かずにエディタを作る過程で、強烈に実感したことがあります。
「こういう機能を作って」と指示すれば、AIは一瞬でロジックを組み上げます。しかし、それが 「気持ちいいツールになっているか」は、AIには決して分かりません。
- 「ここのパネルのマージン、あと少し狭い方がシュッとしてる」
- 「角の丸み（border-radius）が強すぎて野暮ったい。もっとエディタ画面と同じくらい鋭角にして」
- 「新規作成時のフォーカスの当たり方がワンテンポ遅くてイライラする」
こういった「手触り」「ぬるぬる感」「目線の気持ちよさ」「デザインのフィット感」は、血の通った人間が実際にキーボードを叩き、マウスを動かさなければ絶対に検知できないものです。（これらの細かいデザイン修正もログに大量に残されています）。
AIがどれだけ賢くなろうとも、最終的な「美学の判断」と「UXの微調整」は、人間の執念とエゴによってしか達成されないのです。
いくらライブラリの基本機能が優れているからといって、触ってみて違和感の無い挙動になっているかどうかは、かなり別の問題であり、特にエディタにおいては、機能の多さ、複雑さや、やりたいことの多様性により、「痒いところ」に手が届くかどうか、が大きな難題でした。さわってみてもたつく感じが無いか、が価値に直結しました。これをやりたい、と思ったときに、その操作方法が自然な導線で導かれるか、が心地よさでした。
テストファースト？テストコード？そんなものは一切ありません。手触り感や心地よさは、テストケースとして表現することは難しいですし、テストにパスしたかどうかよりも、違和感の無いUIや体験になっているか、を実際に触り続けることに意味があると思います。
（異論は認めます。また、何を作ろうとしているか、によっても大きく違うでしょう。）
7. おわりに：思考の鍛冶場へのご招待
こうして、幾多のバグとの試行錯誤と、個人的なエゴによって鍛え上げられた「TansenEditor」は誕生しました。最初にお見せしたリンクから、無料でダウンロードしてご利用いただけます。
まだまだ完璧ではなく、時折変な動きを見せるかもしれませんが、私自身が日々のAI指示書作成や、ブログ記事の執筆にヘビーユースしながら、随時アップデートを繰り返しています。
「VSCodeをわざわざ開くのは重いけど、普通のメモ帳じゃ味気ない」
「AIへの指示を体系的に管理・ストックしたい」
「とりあえず、推しの画像を背景に透かしながら作業したい」
「MacとWindowsで同じエディタを使いたい」
もし、そんな私と似たような「業」を抱えている方がいらっしゃれば、ぜひ手にとって遊んでみてください。ご意見やバグレポート、あるいは「こういう変な機能が欲しい」というエゴの共有、もお待ちしています！
（まだ発展途上ということで各種バグはおおめにみてください）
AIの進化により、プログラミングの「コードを書く苦労」は格段に減りました。ですがその分、「何をどう作るか」「どう自分の思考を手助けしてくれる道具に育てるか」という「こだわる楽しさ」に全振りできる、良い時代になりました。
さらに、この記事自体、TansenEditorによって蓄積されたAIへの指示文のフォルダをAIに読み込ませることにより、その骨格や苦戦箇所の解説等を手間なくまとめることができました。飛散しがちな経緯やノウハウ等をまとめておく用途にも有益です。
皆さんの良きAIライフの傍らに、この「思考の鍛冶場」が少しでも役立てば幸いです。
Discussion