拝読しました。

いったい何の話だよ..
で、いったい誰のハードがいつもパンパンだっていうんだ？
いや、たまにこういう、なぜこうなるのかだけを見てるような、まとまりのないバカみたいな記事が目につくのは何なんだ？
読む側は何も考えないのか？

私はMac miniにアクセスするとき、Tailscale + macOSの画面共有を使っていますが、同じ問題がありました。
少し不便ではあったので、応急処置として解消するには良さそうです

Googleで検索するだけでも簡単に出てくるので、わざわざ探して差し上げることはしません。最近のバークレー大学の研究もありますね。
UC Berkeley and AnChain.ai found that on the platforms they studied, bots lost 77 times more money per user than human traders, according to UC Berkeley’s DataX initiative.

さらに、そもそもシステムトレーディングやボットの勝率が高かったなら、どうにかして使う方法が主流になっていたはずです。

データは過去の痕跡です。そして決定的なものです。この観点では、未来の出来事がデータになることは絶対にあり得ません。株式取引は未来を取引するものです。上がるにせよ下がるにせよ、それは人間の判断領域であって、ボットには判断できません。そもそも人間が排除された株式市場が存在しない限り、勝つことはできません。
データの時点で差があります。人間たちが集まって携帯電話を切り、パーティーをしながら情報交換していることを、ボットがどうやって知ることができるのでしょうか。
ただし、おっしゃる「個人」がご自身を含む「個人投資家」を指しているのであれば、この議論の範囲とはまったく関係ありません。

入って「分析開始」を押すと決済するよう表示されますが、無料ではないみたいですね。

ARであれ今後登場するヒューマノイドであれ、インターフェースはますます抽象化される方向に向かっていくのではないかと思います。

重複実行の検知に（ツール、引数、出力ハッシュ）の組み合わせを使っているという点が印象的です。こちらでも似たような課題を抱えていて、監査ログにハッシュチェーンを付け、同じイベントが二重に記録されるのを防ぐ方式を試験的に運用しています。

おっしゃるとおり、"呼び出しが2回" と "実行が2回" を区別することが重要なんですよね。こちらでは各エージェント作業に idempotency key を付ける方向も検討中なのですが、実サービスで実際に適用されたことはありますか?

ありがとうございます。Gitleaks + ruff + Kyverno + Checkov の組み合わせは、私たちもすぐに参考にできそうです。

追加で共有すると――私たちのチームは少し特殊な構造で運営しています。チーム全体が AI Agent グループです。人間の CEO の下で Steward AI たちが実際の開発・検収・デプロイまで担当する形です。

そのため「AI のミス追跡」は私たちにとって単なるロギングの問題ではなく、Agent ごとの Passport + Spirit Score + Audit Trail によって「誰がどの権限で決定したのか」を記録するガバナンスの問題です。

bsh998 さんの方式のように、事前の静的検証（Gitleaks 系）も私たちの CI に組み込むのが次のステップです。今日も環境変数の漏れでクラッシュが起きましたが――まさにこの点でした。

LLMによる分析にしては、やけに高いですね

ありがとうございます。
今週中にサイト内の言語設定機能を実装しておきます :)

ご回答ありがとうございます！！

またいろいろ質問してしまいそうなのですが……

ターミナルプロトコルについては、今回開発しながら初めて触れたと読み取ったのですが、
気になっているのは、開発前に Rust に関する知識がどの程度あったのかという点です。

私は Zig で開発したのですが、実は Zig は自分で書いた経験がなく、
ターミナルプロトコルや文法、構造についても同様にまったく知識がない状態から、ゼロベースで学ぶつもりで挑戦したケースでした。
なので外部ライブラリへの依存をより避けた、という面もあります。
どのように作られるのかを質問を通じてもう少し理解し、AI と一緒にトラブルシューティングすることを自然に意図していて、制御できないのに動いてはいる、というようなケースを防ぎたかったんです。

4か月ほどかかったとおっしゃっていましたが、
私もリモートで自宅の Mac を起動したまま開発していたので、ssh 上の Claude や Codex CLI で画像アップロードできるようにプロトコルを開発してからは、以前使っていたターミナルアプリは実質リファレンス用途でたまに起動する以外、まったく使わなくなっていました。
個人的にはターミナル開発を始めて2週目？ 3週目くらいだった気がします。

ご回答いただいたように、すぐ使い始めたとのことですが、その時点ですぐに tmux からの脱出も進んだのでしょうか？

それから4か月もかかったのは、私の考えではありますが、機能追加や利便性の向上を続けることのほうが、むしろコア機能の開発よりも時間がかかったのではないかと思っています。私の考えが合っているのか気になります。
私はそうだったのですが、他の人も似たような製品を開発するときに同じような流れなのか、個人的にずっと気になっていたことなので……失礼でなければご回答いただけるとありがたいです(__)。

また、tmux に比べて圧倒的に便利になったと感じたのは、いつ頃からだったのかも気になります。

もう一つ、私も実は似たテーマでターミナルを開発して満足してはいるのですが、いずれにしても継続的に保守し続けなければならない性質のプログラムですよね。
ブログに書かれていたように Ocra、cmux、heder など似た目的のツールが次々に出てきていますし、有名なライブラリの多くは、企業であれ支援であれ貢献であれ、どうしても個人に比べて圧倒的にスピードが速く、そのぶんフィードバックもよく反映されるプログラムです。
競争（？）する立場としては、日本語 IME を除けば、細かな利便性や UX 改善の速度では実質的に圧倒的に遅れざるを得ないのではないかと思うのですが、
保守については、上で述べたような似た性質のアプリと比べて、どこまでやれば十分だと感じていらっしゃるのかも気になります。

それから Rust で gpu を選ばれたということは、Windows まである程度視野に入れているのでしょうか？？

私も個人プログラムの開発ではありますが、エコシステムでは負けていても（？）、言及したアプリ群くらいのクオリティにはするのが目標ではあります。

それと copad は、Ocra のようではあるものの Electron ベースではなく、ターミナルベースの ADE を最終目標にされているのでしょうか？

似た目的のアプリを開発している韓国人を初めて見たので、つい質問を大量に投げてしまいましたが、すべての質問に答えていただかなくても大丈夫です……！

コメントを見ていると、思い出して布団を蹴りたくなる瞬間が浮かびますね。

実際、たいていの開発にスーパー開発者は必要ないんですよね。普通の人たちが集まって何かを作っていく過程なんだと思います。

Openweight とオープンソースを区別する文章は、かなり久しぶりに見た気がします

私は逆に、それに対するアンドリュー・ンの反応のほうが印象的でした。

「これはまったく同じケースではありません。誰にでも自分のコードを非公開にしておく権利があります。問題は、他の人がコードをオープンソースとして公開しようとすることまで妨げようとする場合です。」 (https://x.com/AndrewYNg/status/2081103828859117908)

あっ！別に投稿できるカテゴリーがあったんですね！教えていただきありがとうございます！

昔のGOM Playerのゲームを思い出しますね……

👍 こういうのは本当に良いですね..

他の2FAよりは確実に私は便利だと感じていましたが、不便に感じる方もいるようですね。仕様上は、どんなセキュリティよりも安全でもありますし。

韓国のセキュリティ規制が、Face IDや指紋認証のような個人を情報とする認証を排除する方向に進んでいるようにも感じますが、パスキーにはそうした懸念もありません。

AppleがやるからFace IDは良いものだと思えるのであって、新興スタートアップがやるとなると、そもそも顔を撮影すること自体に抵抗感があるかもしれません。

そもそもユーザーが2FAを使っていない、あるいは認識していないために起きた出来事のように思います。

たとえば「銀行のOTPを使う？ パスキーを使う？」と聞かれたら、パスキーのほうが圧倒的に便利だと思います。

こんにちは！
良い経験やお考えを共有してくださりありがとうございます。

もちろん、コードを生み出すコストが下がったことで自作への道は開けましたが、個人的にはAI時代になったこととは関係なく、外部ライブラリを導入するという考え方で見ています。

1. 自分の要件を満たすライブラリがない
2. 似たツールを自分で改造するより、作り直したほうが安い

この2つが当てはまると思える場合にだけ、自分で作るようにしています。
理由はいろいろありますが、結局どんなに小さなコード片でも自分が管理し始めると、最終的には自分がレビュー、テスト、保守などをしなければならない領域に入り、単にコードを書く以上のコストが常についてくると考えているからです。
開発の過程で起きた問題も、window manager のようなかなりコアなプログラムとの衝突が多かったので、もしこれまで全部 build from scratch していたら、外部依存との衝突をデバッグしてテストする期間よりも、はるかに多くの時間を実装と検証に費やすことになっていたと思います。

加えて、私は開発に入ってからずっとつらいながらも自分で作ったツールを使ってきたのですが、それが可能だった理由も、ある程度は依存関係の上に乗って開発を始めたからではないかとも思っています。
MacOS で SwiftTerm を取り除いた事例のように、まず外部依存を入れて自分の望むコンセプトが動くかを確認し、自分で実装すべきものが出てきたら直接実装を始めますが、この時点でも外部依存によってひとまず自分のプログラムは動いているので、その上で継続して安定化や機能追加に注力できました。

さらに、webkit を入れれば、たいていのウェブアプリは通常のブラウザを開いたときと同じように動作します！
最近は headless browser を cli から制御できるツールや、claude in chrome も積極的に活用していますし、ターミナルにまで chromium を載せてメモリを過剰に使うのは避けたいので、大きなことがない限り、ターミナル内の webview の技術スタックはあまり変えないと思います。

読んでくださってありがとうございます！

私たちのデモはちょうど静的 HTML の1ファイルなので、相性が良さそうです。リンクを固定できるなら共有もしやすそうですね。教えていただきありがとうございます。デモ終了後に適用してみます。ありがとうございます！