いくつかのタスク

現在は2026年2月4日、0時です。

一日中働きましたが、全体的にはAIに作業をさせながら考える過程でした。少し眠くなってきたので、明日また続けます。

いくつかやる価値のあることを記録しておきます。

一、我々のシステムの開放

Yuanのホスト内の権限、ホストへの接続権限は非対称設計が可能でしょうか？つまり、すべての端末がホストに接続した後、同じ権限を得るわけではないということです。これは権限をより良く制御するのに役立ち、結果として我々のデータをより良く開放できるようになります。現在、ホスト内の権限メカニズムが欠如しているため、一部のデータソースを一時的に閉鎖せざるを得ず、AIに自由に公開することも躊躇しています。最終的にこれは実験の進捗に影響を与えています。

具体的には、SQLを読み取る権限は与えられるでしょうか？SQLを書き込む権限は与えられるでしょうか？Methodレベルでは、デフォルトでアクセス可能とするべきか、デフォルトでアクセス禁止とするべきか？認可はどのように行うべきか？これらの問題はしっかりと設計する必要があります。

利点としては、Yuan CLIに高い権限を与えることで、AIがより良く作業できるようになることです。

将来的には、Yuanはデータソースと注文実行プラットフォームになる可能性があります。そしてその中間の戦略は多様性に富むものになるでしょう。現時点では、Yuanに組み込まれたKernel+Agent体系の戦略プラットフォームに加え、Mageが開発しているTimeLab戦略プラットフォーム、そして私が最近取り組んでいる持久戦実験リポジトリがあります。これらは異なる設計思想と技術スタックに基づいており、将来的には共存する可能性があります。しかし、これらの戦略プラットフォームはすべてYuanのデータと注文実行インターフェースへのアクセスを必要とします。

したがって、権限体系をどのように設計するかは重要な問題です。開放するには、まず防御を固めなければならない（奉化なまり）。

二、AI資産化の能力

最近、いくつかの中継APIを使用していますが、それらはNew APIというプロジェクトをユーザー管理と課金に利用していることに気づきました。それらは本質的に、自身のサブスクリプションプールを資産化し、卸売りから小売りへ転換し、ユーザーに販売しています。しかし、このような販売方法では、業務に紐づかないため、高値で売ることができません。ここでの価格交渉力は、上流の業務側に譲渡されています。

ある意味では、それらはAI APIの資産化であり、AI資産化の初歩的な形態と言えます。一方、上流のAI製品を構築する際には、基盤となるAPI資産を活用し、上流の業務を円滑にすることができます。これにより、ユーザーはAPI設定の複雑さに直接直面する必要がなくなり、ユーザー体験が向上します。直接製品をサブスクリプションするか、従量課金制の製品を利用するのです！ユーザーは組み合わされた最終製品のみを気にし、基盤となるAPIがどのように設定されているかは気にしません。ここにもう一つの利益の余地があります。

現在、API KEYの管理は、一般ユーザーにとって依然としてハードルです。多くのユーザーはAPI KEYの概念を理解しておらず、申請や管理の方法さえ知りません。したがって、AI業務の中間業者には、依然として大きな機会があります。これは実際には認識の差の問題です。この種の利益は非常にスケーラブルです。

もちろん、将来的には、BYOK（Bring Your Own Key）が確実にトレンドになると考えています。ユーザーは自身のAPI Keyを使用して、データ漏洩の問題を回避したいと望むでしょう。一方で、ユーザーは中間業者にマージンを取られるのではなく、APIのコスト価格でAIサービスを購入したいと望みます。実際、中間業者も多くの業務の組み立てを行っており、それには価値があります。業務側でのBYOKはオプションとして提供できますが、ここ数年、API KEYの概念が十分に普及するまでは、BYOKは主流にはならないでしょう。

三、ユーザーシステムの強化

Supabaseは依然として優れた選択肢ですが、そのユーザーシステムにはいくつかの欠点があります。例えば、PassKeyのようなパスワードレス認証方式をサポートしていません。SupabaseがPassKeyをサポートするための一つの案を思いつきました。それは以下のようなものです：

Edge Function内でadmin（service_role）権限を使用して特定のユーザーのSupabaseセッションを作成し、access_token / refresh_tokenを取得してフロントエンドに返す。

• Supabaseには「adminが任意のユーザーのセッションを直接生成する」公式APIはありません。
• 公式推奨の方法：バックエンド（Edge Function）で auth.admin.generateLink + auth.verifyOtp の組み合わせを使用し、magic linkログインプロセスをシミュレートすることで、そのユーザーのセッションオブジェクト（その中にaccess_token / refresh_tokenなどが含まれる）を取得する。
• このプロセスはEdge Function内部で完全に完了させることができ、実際にユーザーにメールを送信したり、ユーザーがリンクをクリックする必要はありません。

したがって、Edge Functionを通じてPassKeyログイン機能を完全に実装することができます。これにより、Supabaseベースのユーザーシステムで、メールアドレスで登録し、メールアドレスでログインし、さらにPassKeyでログインできるようになります。このプロセス全体はパスワードレスであり、ユーザー体験は向上します。ただし、PassKeyは重いインタラクション方式であるため、すべての操作に使用するのには適していません。初期ログインや、いくつかの重要な操作（パスワード変更、支払い方法の変更など）とのみ紐づけるのが適切です。通常のセッション維持には、Supabaseのaccess_token / refresh_tokenメカニズムを再利用すればよく、JWTメカニズムは十分に有用です。

四、決済システム

非常に古くて現実的な問題です。どうやってユーザーにお金を払ってもらうか？どうやって合法的に会社の受取口座に入金するか？どうやってQRコードを紐づけ、ユーザーがスキャンして支払い、そのお金が会社の口座に入るようにするか？これらの問題はすべて解決する必要があります。

いくつかの案があるでしょうが、決済プラットフォームと連携するのが良い選択肢かもしれません。プロセスを一通り進めてみる必要があります。後でまた共有します。