前の記事では、汎用エージェントのためにハーネスを作るなと書いた。今度は逆に、車輪は何度でも作ればいいと思っている。
矛盾して見えるが、作る目的が違う。長く保守する基盤を増やすためではない。自分で作る過程から理解し、必要なら使い、要らなければすぐ捨てるために作る。
再発明を避けたのは、作るのが高かったからである
車輪の再発明を避けるべきだと言われてきたのには理由がある。すでに動くライブラリや製品があるのに同じものを作れば、実装、検証、学習、保守へ時間がかかる。その時間を、本来解きたかった問題へ使うほうが合理的だった。
AIによって、この前提の一部が崩れた。小さなアプリや拡張機能なら、何を作りたいか話し、既存の実装や仕様を読ませれば、数時間で使えるところまで進むことがある。分からないコードを一行ずつ検索する代わりに、その場で説明させ、最小構成を作らせ、動かし、壊し、比較できる。
もちろん、生成が速くても検証と保守は消えない。だから、作ったものをすべて製品として残す必要はない。試して価値がなければ、その日のうちに捨てればよい。作成物が残らなくても、自分の中に対象の構造と判断軸が残るなら、再発明は失敗ではない。
存在を知ることと、一度作ったことは違う
ある技術の名前を知っていること、既製品を使ったこと、自分で小さく作ったことの間には差がある。
一度作ると、どこが単純で、どこから急に難しくなり、どの権限や状態が危ないのかが見える。完成度の高い既製品を触るだけでは隠れていた設計上の継ぎ目が、自分で組み立てると露出する。完全に理解したとは言えなくても、次に似た問題が出たとき、何を探し、何と組み合わせればよいかを判断できるようになる。
その経験は、あとで使える検索キーになる。すべてを正確に覚える必要はない。何が存在し、どの方向へ掘ればよいかを取り出せればよい。自分の中にRAGを持つというのは、この感覚に近い。知識そのものを暗記するのではなく、必要になったときに参照先へたどり着ける、解像度の粗い索引を増やしていく。
今のボトルネックは、実装速度より、何を知っているかの幅へ移っている。
ゼロイチも、知っているものの組み合わせから生まれる
「AIは学習済みのものからしか生成できないため、ゼロイチはできない」という話を見かける。しかし、人間の生産活動も、何もないところから突然生まれるわけではない。過去に見たもの、別の領域で使った仕組み、目の前の制約を組み替えて、新しい形を作っている。
新しさは、既存の要素が一つも含まれていないことではない。知っている要素を、別の目的や制約の下でつなぎ直すことにある。組み合わせる材料が少なければ、AIを使っても出てくるものは狭い。逆に、分野をまたいで粗くても多くを知っていれば、エージェントへ渡せる目的、比較対象、参照先が増える。
人間の欲望そのものは、それほど大きく変わらない。時間を省きたい、安全でいたい、誰かとつながりたい、認められたい、面白いものを見たい。資本主義が得意なのは、欲望を無から作ることより、既存の欲望へ新しい満たし方と比較軸を与え、それまで名前のなかった不足を需要として立ち上げることだと思う。
その組み合わせを見つけるためにも、知識の幅が要る。車輪を作り直すことは、組み合わせに使える材料を自分の中へ増やす方法になる。
インストールすること自体が、セキュリティ負債になった
AIは作る側だけでなく、攻撃する側のコストも下げた。小さなプラグイン、アプリ、ブラウザ拡張へ、それらしく動く悪意ある処理を混ぜるハードルも下がっている。
エージェントへ追加する第三者プラグインやMCPサーバーは、単なる便利機能ではない。モデルへ渡る情報を増やし、外部サービスを呼び、場合によってはファイルや認証済みサービスを操作する。OpenAIも、信頼できないMCPサーバーへ接続すると、プロンプトインジェクションを含むセキュリティリスクが高まると警告している。自分は、AI関連の野良プラグインを原則として入れない。よい設計や考え方を見つけたら、それを読み、必要な部分だけ自分で管理するプラグインへ取り入れる。
すべてをプロンプトインジェクションと呼ぶのは正確ではない。外部コンテンツに埋め込まれた命令でモデルを誤誘導するのがプロンプトインジェクションであり、実行コードの改ざん、過剰な権限、データの外部送信、更新経路の乗っ取りは、別のサプライチェーンと権限の問題である。入口は違っても、信頼していないものへ仕事と権限を渡すという点では同じである。
ブラウザ拡張も軽く考えないほうがよい。Chrome Web Storeは一度きりの5ドルで開発者登録できる。審査やポリシーはあるが、ストアに存在することが、自分の閲覧内容やCookieへ触れさせてよい保証にはならない。Google自身、拡張機能はブラウザ内で特別な権限を持つため攻撃対象になりやすく、権限を最小限にすべきだとしている。
数時間で作れる程度の機能なら、知らない更新者を継続的に信頼するより、必要な機能だけ手元で作ったほうがよい場合がある。インストールする時間が短くても、信頼する期間は長い。
自作しただけでは、安全にならない
自分で作れば自動的に安全になるわけではない。AIが生成したコードにも脆弱性は入るし、理解せずに広い権限を与えれば、第三者のコードを入れるのと同じように危ない。
再発明する価値があるのは、機能を狭くし、コードと更新経路を把握し、権限と外部通信を減らせる場合である。暗号、認証、サンドボックス、プロトコルのパーサーのように、長い検証の上に成り立つ基盤まで作り直す話ではない。検証された標準やライブラリは使い、その上にある小さなアプリ、画面、ワークフローを自分の用途へ作り直す。
使うか作るかを、実装量だけで決めない。小さくても強い権限を要求し、更新を外部へ委ねるものなら、自作する理由は強くなる。大きくても権限が狭く、標準化され、多くの検証を受けている基盤なら、そのまま使うほうがよい。
Hikizanとtemotoは、信頼する範囲を手元へ戻すために作った
Hikizanは、エージェントの作業に必要だと思った規則を、調査、設計、実行、査読、提出、文章という六つのスキルへまとめた。スキル本体は特定のハーネスから分離し、CodexやCursorなどに固有の処理は任意のHookへ隔離している。外部のプラグインを機能ごとに増やす代わりに、必要な境界を一つのリポジトリで管理し、どこまで実行するかを自分で決められるようにした。
Hikizan自体も公開された第三者プラグインなので、利用者から見れば同じように評価されるべきである。ソース、権限、更新経路、実行内容を確認できるか。自分にとっての違いは、それらを自分で管理し、不要になった処理を外せることにある。
temoto for Chromeでは、色の取得、画面キャプチャ、動画速度、環境切り替え、サイトデータの削除、要素計測を一つの拡張へまとめた。一方、ブラウザ全体へ影響するproxy権限は、temoto Proxyという別の拡張へ分離した。自作の目的は何でも一つへ集めることではない。何を同じ信頼範囲へ置き、どの権限を隔離するかを、自分で決めることである。
残すためではなく、自分の血肉にするために作る
作ることも、分からないものを噛み砕くことも、以前ほど大きなボトルネックではなくなった。何を作るか、何と何を組み合わせるかを決める知識の幅のほうが、結果を左右する。
完成品を増やすためだけに車輪を作るのではない。一度作り、動かし、構造を知り、自分の中へ索引を増やす。使えれば残し、要らなければ捨てる。外部コードへ強い権限を渡さずに済むなら、小さく作り直す。
自分の血肉にするために、車輪は何度でも作ればいい。