← ishizakahiroshi.com
設計の振り返り5分で読める要約版2026-11-02

AIは借りる。自分の道具は、肩肘張らずに作る

AIは借りる。自分の道具は、自分で。肩肘張らずにOSSを育てる

AIはベンダーのものを使いながら、認証や実行環境は自分で管理する。many-ai-cliとMany Irisの提供範囲を整理し、まず自分が使うところから育てる方針をまとめました。

noteで全文を読むQiitaで設計の詳細を読む

便利にする範囲が、少し広がりすぎた

スマホからAIに仕事を頼み、手元のPCで進む作業を確認したい。many-ai-cliとMany Irisを一式として考えるうちに、認証や中継、接続先の登録まで、提供側で引き受ける話に広がりました。

でも、最初から一般向けのサービスを運営したいわけではありません。AIの能力はベンダーから借りながら、道具の運営者へのアカウント作成や認証情報の預託を必須にしない形を目指します。

環境の管理と、日常の操作を分ける

PC・VPS・ネットワークは利用者が選び、その環境と認証情報を管理する。ソフト側では、依頼、実行状況、承認待ち、担当交代、成果の根拠を追いやすくしたいと考えています。初期設定を自分で行うことと、毎日の操作が面倒なことは別です。

AIベンダーから借りる能力、利用者が管理する環境、ソフトが支援する日常操作の分担
提供範囲を整理した方針図です。全ての実装が完成していることを示す図ではありません。

外部AIへ送った指示や資料は、そのベンダーが処理します。また、スマホがTailscaleにつながっていても、クラウド側が呼び出すMCPから手元のPCに届くとは限りません。通信を始める場所と、処理を動かす場所を分けて設計する必要があります。

まず、自分が使うところから育てる

T3 CodeやOrcaにも、自分で管理する環境へ接続する方法があります。自己管理できることだけで、独自の強みや安全性が決まるわけではありません。ゼロトラストも、ローカル実行やOSSというだけで実現するものではありません。

自己管理には更新や復旧の手間も残ります。だから、CloudflareとVPSの全経路を最初からそろえるより、自分が毎日使う依頼から結果確認までの一周を仕上げます。使い方が合う人には使ってもらい、必要なら自由に改造してもらう。そのくらいの温度感で育てたいと思っています。

Many Irisとの統合は未完成です。これは完成報告ではなく、何を引き受け、何を利用者に任せるかを整理した記録です。

もっと深く読みたい人へ

noteでは今回の考え方を振り返り、Qiitaでは認証・接続・操作の責務と一次資料を整理しています。

noteで全文を読むQiitaで設計の詳細を読む

many-ai-cliのGitHub / many-ai-cliの紹介ページ