26年4月振り返り
04/26 20:39 2026
04/26 20:46 2026
4月の振り返りです！
3月につづき4月の振り返りをやっていきます！
業務は開発とAI研修をやっていて、地方出張が多くてここ半年で一生分出張した気がします。4月に数億年ぶりにディズニーランドに行きました。ディズニーってこんなに面白いのかとなりました。そのあとディズニープラスを契約して、ベイマックス観ました。いい映画です。リメンバーミー以来泣きました。美味しかったやつ貼っておきます。
4月は記事を1本しか書けませんでした。。いや執筆時点で26日で、下書きはあるので2本になるかも。
趣味ではagentoastを隙間で改善してました。個人でここまで使うものを今まで作ったことがなくてとても楽しいです。
- GitHub Copilot CLI に対応
- アプリ化: Settings / Apps ランチャー、オンボーディング、SMAppService でログイン登録
- CLI と GUI を単一バイナリに統合
- Claude Code の検出強化（bash/agent/monitor カウンタ、auto モード）
- tmux 連携拡充: 非エージェントペイン表示、通知自動消去
- 安定性向上: クラッシュ修正、マルチモニター対応、ちらつき解消
- 環境対応: Nix 管理 tmux/git 検出、バイナリパス手動指定
- ビルド基盤を Vite+ に移行
バイナリ統合が出来て、オンボーディング機能もつけた結果、特に目的なくStore公開ってどうやるんだろうと調べたところ、似た性質のツール（iTerm2、Alacritty、WezTerm、Warp 等のターミナル系、tmuxinator GUI 系）はほぼ全てApp Store外配布なように、App Store はサンドボックス強制で無理でした(無知)。出来たとしても、オーケストレーターツール自体は去年から大量にリリースされていて界隈も辟易している感じもある中、一応差別化しているつもりではあるんですが、それを説明して回るのも違うかなという気持ちで、Homebrewで十分かなと思っています。
致命的に問題になりそうな点(Claudeの回答)
正直に言うと、現状のアーキテクチャだと Mac App Store 公開はかなり大変です。主な障壁を挙げます。
- App Sandbox 必須 App Store はサンドボックス強制ですが、agentoast は思いっきりサンドボックス外の操作をしています。
tmuxバイナリの spawn（/opt/homebrew/bin/tmuxなど任意パス実行）git rev-parseなど外部コマンド実行- 任意ディレクトリでの
tmux capture-pane（ユーザーのリポジトリパス全部） NSWorkspace.runningApplicationsでのターミナル列挙 +activateWithOptions__CFBundleIdentifier経由のターミナル特定
これらは entitlements で個別緩和できるものもありますが、「任意の外部バイナリを spawn する」のは原則 NG。com.apple.security.temporary-exception.files.absolute-path.read-write 等で逃げる手はあるものの、審査で弾かれる確率が高い。
- CLI バイナリの配布形態
Agentoast.app/Contents/MacOS/agentoastを Homebrew Cask が/opt/homebrew/bin/に symlink する構成は、App Store では完全に不可。
- App Store アプリは
/Applications配下に固定インストール、PATH 通せない - そもそも CLI を hook から呼ぶ前提なので、ユーザーが
~/.claude/settings.json等から起動する必要がある xcrunのような Helper Tool 配布も App Store では制限が厳しい
-
tmux への依存 ユーザー環境の tmux に shell out する設計そのものが App Store のモデルと相容れない。Homebrew/Nix で入れた tmux を叩くのは、サンドボックスの「外部リソースに依存しない自己完結アプリ」原則に反する。
-
NSPanel /
tauri-nspanelprivate API ギリギリの使い方（can_join_all_spaces、nonactivating_panel、setFrameOrigin:直叩き）。macOSPrivateApi: trueをtauri.conf.jsonで有効化している時点で App Store はほぼ無理（Private API 使用は審査で即リジェクト対象）。 -
SMAppService によるログイン項目 これは v0.39.0 で対応済みなので OK。LaunchAgent 直書きから移行したのは正解。
現実的な選択肢
| 配布方法 | 難易度 | 現状からの差分 |
|---|---|---|
| 現状維持（Developer ID + 公証） | ★ | 完了 |
| Mac App Store | ★★★★★ | アーキテクチャ全面再設計レベル。tmux 依存の捨て、CLI 分離、NSPanel やめる、サンドボックス対応… |
| Setapp | ★★ | Developer ID 配布の延長線。tmux 依存も許容される。レビューはあるが App Store ほど厳しくない |
| Notarized DMG + Sparkle | ★ | 既に Tauri updater で実装済み |
結論
App Store 公開は現実的ではないと思います。理由は agentoast のコア価値（tmux + ローカルバイナリ + ターミナル制御）が、サンドボックスモデルと根本的に噛み合わないため。
仮に出すなら、「tmux 連携を諦めた、純粋な通知ビューア版」を別アプリとして出すくらいの覚悟が必要です。
公証 + staple + Sparkle 風自動アップデートが既に動いているので、現状の Homebrew Cask 配布が最適解だと思います。むしろ App Store 化は機能を削ることになるので、ユーザー価値を毀損する可能性が高いです。
とまぁそんなこんなで特にアウトプットは出せてない感じです！ネイティブアプリ開発はアイディアがない反面、デスクトップアプリ(TAURI)だと沢山あり、自分の作業が効率化されて楽しいので、しばらくはこっちをいじり倒すのがいいかなと思っています。自分はスマホよりPC触っている時間が長いので。
にしてもClaudeは本当にすごくて、もう製品レベルであってもソフトウェアの開発サイクルはAIで完全に閉じてしまう気がしています。コーディング力はもちろん自然言語でのバグ報告からの理解の速さ、ログを書かせて読み取って自己改善など...。
先に来る世界は一発で製品レベルのものを仕上げてくるというよりは、むしろ荒く作ってAI主体でE2Eでアプリをテストしまくってエラーを片っ端から潰して結果製品レベルになるというものだと思っています。これは人間を説得しやすいという面でも現実感があります。最強の鉾で殴りまくってたら仕上がる感じで、Mythosの例もまさにそうでした。
現状の障壁はGUI操作と細かいアプリの反応をどこまで認識できるかで、そのブレークスルーが起きると大きく変わる認識を持っています。
AIで課題を局所的に解決する決定論的に動作するソフトを書くことに多少違和感があります。その根元の課題をAIがそもそも解決してくれるでしょと。とはいえこれから従量課金にシフトしていく流れもあり、決定論的アプローチはまだ息があるかもしれません。
5月はTAURI関連のアウトプットの方に力を入れて、agentoastも既存の処理の最適化や壊れやすい部分のハーネス強化を中心にv1に向けた準備、足回りを整える期間にしようかなと思います！
という感じで明日、明後日は岡山出張です！
shuntaka.dev
This site uses Google Analytics.