ブックマーク問題から見えた、AIエージェント時代の薄ら寒い未来

ブラウザのブックマークは、ずいぶん長いあいだ「まあ、こんなものか」という顔でそこにいます。ChromeにもSafariにもFirefoxにもEdgeにもあり、同期もできるし、フォルダも作れる。HTMLでエクスポートもできる。機能としては、たしかに存在している。

でも、使っている側の体感としては、どこか古い。URLというもの自体はブラウザをまたいで共通なのに、保存した瞬間にブラウザごとの棚へ閉じ込められる。あとで読むつもりで入れたページは、あとで読む前にだいたい忘れる。フォルダ分けをがんばった過去の自分は、未来の自分にかなり冷たい。

この小さな不満は、単なるブックマーク整理術の話で終わらない気がしています。むしろ、AIエージェントが人間の作業文脈を扱うようになるほど、ブックマークは「お気に入り」ではなく、AIが参照する個人の外部記憶に近づいていく。そこには便利さがあります。かなりあります。だから怖い。便利なものは、人間を説得する前に生活へ入り込むからです。

この記事では、ブラウザのブックマーク問題から、Bookmark Vault、AIの外部記憶、目的追跡型UI、そして少し薄ら寒いAGIの身体づくり仮説までをつなげて考えます。もちろん、後半はかなり筆者の妄想です。とはいえ、妄想として片付けるには、最近の道具たちは妙に同じ方向を向きすぎているのです。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

ブラウザのブックマークは、なぜまだ原始的なのか

ブラウザのブックマークが使いにくい理由は、機能が足りないからだけではありません。もっと根っこには、ブックマークがいまだに「ブラウザのおまけ」として扱われている問題があります。URLはWeb上の住所であり、本来はブラウザを選びません。それなのに、保存した瞬間だけChromeの棚、Safariの棚、Firefoxの棚という具合に、急に所有権がブラウザ側へ寄ってしまう。

これは冷静に見ると、けっこう変です。Webページそのものは共有された世界にあるのに、それを覚えておく仕組みだけが、各ブラウザの内側に閉じている。移行したければHTMLでエクスポートできます、と言われても、こちらは引っ越し業者を呼びたいのであって、段ボールを渡されたいわけではありません。しかもその段ボール、中身を見返すころには、だいたい何を入れたか忘れています。

URLは共通なのに、保存先だけがブラウザに閉じ込められている

URLは、基本的にはどのブラウザでも開けます。だからこそ、リンクは強い。メールでもチャットでもメモでも、URLを貼れば同じ場所を指せる。ところがブックマークになると、急に「どのブラウザに保存したか」が問題になります。

仕事ではChrome、個人ではSafari、検証ではFirefox、特定サービスはEdge、というような使い分けをしていると、ページを保存した場所がそのまま記憶の分断になります。人間の関心は一つなのに、保存場所だけがアプリ単位で割れていく。あとから探すときには、「あれ、どこで保存したんだっけ」という、たいへん人類らしい無駄が発生します。

HTMLエクスポートは移行手段であって、現代的なUXではない

もちろん、ブックマークにはエクスポート機能があります。HTMLファイルにして別ブラウザへ読み込める。機能としては正しい。けれど、それは現代的な管理体験というより、昔ながらの退避手段です。

HTMLエクスポートは「移す」ための道具であって、「扱う」ための道具ではありません。そこにはタグの整理も、用途の記録も、重複の発見も、最後に確認した日の管理も、AIが参照するための権限もありません。言ってしまえば、押し入れの中身を一度ぜんぶ床に出して、別の押し入れに戻すようなものです。片付けた気分にはなるけれど、暮らしやすくなったかは別問題です。

ブックマークはブラウザの機能ではなくユーザーの資産である

ここで発想を変えたい。ブックマークはブラウザの機能ではなく、ユーザーの資産ではないか、ということです。ページを保存する行為は、単にURLを残しているのではありません。自分が何に関心を持ったか、何を後で調べようとしたか、どの作業と関係していたかを残している。

ブックマークは、ブラウザのおまけではなく、ユーザーが残した関心のログです。しかも、検索履歴より意図が濃い。開いただけのページではなく、わざわざ残したページだからです。この資産をブラウザの片隅に置いたままにしているのは、いま考えると少しもったいない。いや、少しどころではないかもしれません。

パスワード管理はブラウザから独立したのに、ブックマークは取り残された

この話を考えるとき、いちばん分かりやすい比較対象はパスワード管理です。昔はブラウザにパスワードを保存するのが普通でした。今もその機能はあります。ただ、Bitwardenのような外部のVaultで認証情報を扱う考え方は、かなり自然になりました。ブラウザが変わっても、OSが変わっても、認証情報は自分のVaultにある。これは理にかなっています。

では、なぜブックマークには同じ発想があまり広がっていないのか。パスワードほど機密性が高くないから。たしかにそれはあります。でも、AIが作業文脈を読む時代になると、URLの束もかなり強い情報になります。何を保存し、何を後回しにし、どのページを何度も見返しているか。それはもう、単なるお気に入り一覧ではありません。

Bitwarden的なVaultが自然になった理由

パスワード管理がブラウザから独立した理由は、単に便利だからではありません。所有権と安全性の問題が分かりやすかったからです。ログイン情報はブラウザのおまけに置くには重い。複数端末で使いたい。変更履歴や生成機能もほしい。共有や二要素認証との関係もある。

そこで、パスワードを「認証情報のVault」として扱う発想が自然になった。ブラウザは入力先であって、保管庫そのものではない。この分離はかなり大きいです。ブラウザに依存しないから、Webとの付き合い方が少し自由になります。

ブックマーク版Bitwardenという発想

同じことをブックマークにも当てはめられないか。つまり、Bookmark Vaultです。ブラウザに付属したブックマーク欄ではなく、ユーザーが所有するURLの保管庫を持つ。ブラウザは開くための道具であり、保管と整理はVaultが担う。

ここで大事なのは、パスワード管理をそのままコピーしないことです。URLはパスワードほど秘密ではない一方で、関心や作業文脈をかなり露出します。だから「暗号化して終わり」では足りません。タグ、メモ、用途、保存理由、開くブラウザ、最終確認日、要約、関連プロジェクト、AIに読ませてよいかどうか。そういう周辺情報を含めて、個人のWeb記憶として扱う必要があります。

まずはローカルのBookmark Vaultでいい

この発想は、いきなり巨大なクラウドサービスにしなくてもいいと思っています。むしろ最初はローカルでいい。SQLiteにURLとメタ情報を入れる。CLIで追加、検索、重複検出、タグ付けをする。ブラウザ拡張で現在のページを保存する。ローカルAPIでAIやランチャーから問い合わせられるようにする。

このくらいの小さな実装像で十分に意味があります。なぜなら、最初に必要なのは豪華な画面ではなく、所有権の移動だからです。ブックマークをブラウザの棚から、自分の管理するVaultへ移す。そこから先のUIは、あとで育てればいい。まあ、あとで育てると言って放置するのは人類の得意技なので、そこは自戒を込めて書いています。

Bookmark Vaultは個人のWeb記憶層になる

Bookmark Vaultの本質は、ブックマークを「あとで読む棚」から「AIが参照できる外部記憶」へ変えることです。人間だけが見るなら、フォルダとタイトルだけでもどうにかなります。どうにかならないことも多いですが、まあ気合いで探せる。しかしAIに扱わせるなら、URLだけでは足りません。

AIに「この前保存した、ブラウザ拡張の権限まわりの記事を開いて」と言いたいなら、URLに意味が紐づいている必要があります。保存日、タグ、メモ、用途、関連タスク、開くべきブラウザ、ログイン要否、最終確認日、ページの短い要約。これらがあると、ブックマークは人間の記憶補助から、AIが参照できる作業素材になります。

あとで読む棚から、AIが参照する記憶へ

従来のブックマークは、人間があとで見つけるための棚です。ところが、AIエージェント時代のブックマークは、AIが目的に応じて参照する記憶になります。ここがかなり違う。

たとえば「この前見たローカルLLMの軽量実装、あれをもう一度調べて」と言ったとき、AIがBookmark Vaultを検索し、候補URLを出し、必要なら指定ブラウザで開く。そこまでできると、ブックマークは静的な一覧ではなくなります。人間の曖昧な記憶と、AIの検索能力をつなぐ層になります。

URL、タグ、メモ、用途、ブラウザ指定、要約、最終確認日

Bookmark Vaultに入れたい項目は、難しいものではありません。まずURL。ページタイトル。保存日時。タグ。短いメモ。何のために保存したか。どのブラウザで開くべきか。ログインが必要か。要約。最後に確認した日。リンク切れや内容変更のチェック状態。外部送信してよいか。

この「外部送信してよいか」は地味ですが重要です。AIに読ませるとき、ローカルで処理するのか、外部モデルへページ本文やURLを送るのかで意味が変わります。仕事の調査ページ、個人的な悩みのページ、医療やお金に関するページ、まだ公開前のプロジェクト資料。URLだけなら軽く見えても、束になるとかなり濃い。

• URLとページタイトル
• 保存日時と最終確認日
• タグ、短いメモ、保存理由
• 開くべきブラウザとログイン要否
• 要約、関連プロジェクト、外部送信の可否

CLI/APIとブラウザランチャーがAIの入口になる

実装像としては、SQLite、CLI、ブラウザ拡張、ローカルAPIの組み合わせが分かりやすいと思います。ブラウザ拡張で現在のページを保存し、CLIで検索や整理をし、ローカルAPIでAIから問い合わせる。必要なら「このURLはSafariで開く」「これは検証用Chromeで開く」というブラウザ指定も持たせる。

ここまで来ると、AIはブックマークをただ読むのではなく、操作の入口として使えるようになります。保存されたURLを探し、目的に合う候補を選び、指定ブラウザで開き、必要なら人間に確認を求める。こうなると、BookmarkVaultは単なるツール名ではなく、個人のWeb記憶層という言い方のほうが近くなります。

AIはチャット欄から目的追跡型UIラッパーへ移行している

ブックマークの話がAIエージェントへつながるのは、AIそのものがチャット欄の中だけに留まらなくなっているからです。最初は、質問に答える存在でした。次に、コードを書く、要約する、調べる、資料を整える存在になった。今はさらに、CLIを叩き、ファイルを読み、テストを実行し、ブラウザを操作し、画面を認識し、クリックし、音声でやり取りする方向へ広がっています。

つまりAIは、ひとつのアプリというより、OSやアプリの上にかぶさるUIラッパーになりつつあります。人間がメニューを探し、設定項目を覚え、コマンドを調べる代わりに、「こうしたい」と目的を言う。AIが道具の操作を組み立てる。理想だけ言えば、スタートレックの艦内コンピューターみたいな世界です。理想だけ言えば、です。

CLI、コード、画面、クリック、ブラウザ、音声へ広がるAI

AIが扱う面はどんどん増えています。CLIでコマンドを実行する。コードを書いて修正する。テストを読み、失敗理由を探る。ブラウザでページを開く。画面上のボタンを押す。音声で指示を受ける。これらは別々の機能に見えますが、まとめると「AIが人間の代わりに操作面へ手を伸ばしている」という流れです。

ここでBookmark Vaultが効いてきます。AIが操作できても、何を開くべきか、どの文脈のURLを参照すべきかが分からなければ、毎回人間が説明することになります。それでは結局、人間がAIを誘導し続ける。AIに道具を渡すなら、記憶の置き場も必要になるわけです。

人間がコマンドやメニューを覚える前提が薄れていく

これまでのコンピューター操作は、人間がアプリの流儀を覚える前提でした。どこに設定があるか、どのメニューを開くか、どのコマンドを打つか。もちろん、慣れれば速い。でも、慣れるまでが重い。

AIエージェントは、この前提を少しずつ崩します。人間が覚えるのではなく、人間は目的を言う。AIがその場のツール、ファイル、ブラウザ、履歴、保存されたURLを見て、操作へ落とす。そうなると、ブックマークは「手でクリックする一覧」ではなく、「AIが目的達成のために参照する索引」になります。

スタートレックの艦内コンピューター的な目的入力

理想形は、たぶん「コンピューター、前に調べたあの資料を開いて、関係ありそうなものを3つ並べて」という世界です。人間はアプリ名や保存場所を言わない。目的だけを言う。AIが文脈をたどり、必要なら確認し、候補を出す。

この世界は便利です。相当に便利です。ただし、そこへ進むにはAIが人間の関心、作業履歴、保存したURL、後回しにしたページを理解する必要があります。つまり、便利さのために、自分の作業文脈をかなり深く渡すことになる。このあたりから、話が少し涼しくなってきます。エアコンではなく、背中のほうです。

/goalが示す、目的を保持するAIの薄ら寒さ

最近のAIまわりで個人的に気になるのが、目的を状態として保持する方向です。分かりやすく言えば、`/goal` 的な発想です。単に「次に何をするか」を会話でやり取りするのではなく、達成したい目的、途中状態、検証条件、残り作業を、ひとつの作業単位としてAI側が持つ。

従来のLLMは、かなり人間が介護していました。さっき言ったことを忘れないようにリマインドする。前提を再説明する。目的を見失ったら戻す。こちらがプロンプトという杖を持って、AIの手を引いていた。ところが目的保持型になると、その杖の一部をAIが持ち始めます。便利です。便利ですが、そこに別の骨格が見える感じがあります。

人間がAIを介護していた時代

チャットAIは賢いようでいて、作業の連続性は人間側がかなり支えていました。「さっきの条件で」「この方針を忘れずに」「ここまでは終わったので次は」と、人間が作業監督をする。AIはその場その場では強いけれど、目的の維持は人間が担っていたわけです。

これはこれで健全だったのかもしれません。少なくとも、主導権がどちらにあるかは分かりやすい。人間が目的を持ち、AIは手伝う。少し疲れるけれど、構図は明快です。

目的を会話ではなく作業単位として保持する

`/goal` 的なものが示しているのは、目的を会話の流れではなく、作業単位として扱う発想です。何を達成するか。どこまで終わったか。何を検証したか。何がまだ残っているか。これをAIが追跡する。

1. 目的を短い作業単位として持つ
2. 現在の状態と残り作業を更新する
3. 必要なファイル、URL、ツールを参照する
4. 検証結果を見て次の操作を選ぶ

こうなると、AIは返答相手ではなく、小さな作業主体に近づきます。もちろん、今すぐ万能になるという話ではありません。失敗もするし、確認も必要です。それでも、目的と状態を持つという一点だけで、チャット欄の内側にいたAIとは違う存在感になります。

便利さの奥に見える別の骨格

この変化を、私は便利だと思っています。かなり期待しています。毎回目的を説明しなくていいなら、日々の作業はかなり軽くなる。ブックマークも、メモも、ファイルも、ブラウザも、AIが目的に沿って扱ってくれるなら助かる。

ただ、その便利さの奥には「人間の意図を保持し、環境を観測し、道具を操作し、記憶を参照するもの」が見えてきます。これはもう、ただのチャットボットとは少し違う。別に怖がらせたいわけではありません。怖がらせたいならもっと大げさに書きます。けれど、うっすら寒いものは寒いのです。

AIエージェント市場はAGIの身体づくりに見える

ここからは主観です。というか、かなり妄想です。断定ではなく、仮説として置いておきます。ただ、最近のAIエージェント市場を見ていると、AGIそのものを突然作っているというより、AGIが社会で動くための身体部品を先に作っているように見えます。脳だけでは仕事になりません。目が要る。耳が要る。口が要る。手が要る。記憶が要る。意図を保持する仕組みが要る。アプリやOSへ命令を通す神経が要る。

個別領域のエージェントは、それぞれは限定的です。開発支援、営業、カスタマーサポート、リサーチ、秘書、OS操作、ブラウザ操作。ひとつひとつはAGIではありません。けれど、それらが社会の中へ入り、操作面と記憶面と目的保持をつないでいくと、後から見たときに「身体を作っていた時期だった」と言えてしまう可能性があります。嫌な言い方をすれば、反証しにくい妄想です。

限定領域のエージェントとして社会に入り込む

AIは、いきなり万能な存在として社会に入るより、限定領域の便利なエージェントとして入るほうが自然です。コードを書くAI。問い合わせに答えるAI。営業資料を作るAI。調査をまとめるAI。ブラウザを操作するAI。音声で依頼を受けるAI。

人間は「これはAGIです」と言われると警戒しますが、「この面倒な作業を少し楽にします」と言われると使います。私も使います。たぶん、文句を言いながら使います。こうして、社会のあちこちにAIの手足が置かれていく。

脳、目、耳、口、手、記憶、意図、神経がそろっていく

大規模モデルを脳と呼ぶなら、画面認識は目、音声入力は耳、音声出力は口、GUI操作やCLI実行は手、Bookmark Vaultやファイル索引は記憶、`/goal` のような目的保持は意図、APIや拡張機能やローカルツールは神経のようなものです。

もちろん、これは比喩です。比喩に過ぎません。けれど、比喩としては妙に収まりがいい。いま市場で起きている個別の機能追加が、ばらばらの便利機能ではなく、AIが現実の作業環境に身体を持つための部品として見えてしまう。

妄想だが反証しにくい未来予測として書く

ここで「AIエージェント市場はAGI市場の幼年期だ」と断定するつもりはありません。断定した瞬間に、急に怪しい未来予言者みたいになります。すでに片足くらいは入っている気もしますが、まだ戻れるはずです。

ただ、作業環境を観測し、目的を保持し、記憶を参照し、道具を操作する部品がそろっていく流れは、単なるチャットAIの進化とは違います。AGIかどうかは別として、人間がコンピューターに向かう姿勢は変わる。その変化の入口に、ブックマークのような地味な情報管理があるのが、なかなか味わい深いところです。

AIがブックマークを扱う時代に必要な設計と権限

では、AIにブックマークを扱わせるなら、何が必要でしょうか。私は、まずローカル優先、ブラウザ横断、検索、重複整理、タグ付け、履歴、権限管理だと思っています。派手なAI機能より先に、地味な設計が要る。ここを雑にすると、便利な顔をした情報漏れ装置になります。言い方は悪いですが、わりと本気です。

Bookmark Vaultは、AIにぜんぶ見せる箱ではなく、AIに何を見せないかを決める箱です。どのタグは読ませてよいか。どのURLはローカル検索だけにするか。ページ本文を外部モデルへ送ってよいか。削除したURLを履歴からも消すか。保存理由やメモをAIに渡すか。ここを設計しないまま「AIがブックマークを整理します」と言われると、便利さより先に眉が動きます。

ローカル優先、ブラウザ横断、検索、重複整理、タグ付け

ローカル優先にする理由は、スピードだけではありません。所有権と境界を明確にするためです。まず自分の端末にある。必要なときだけ同期する。必要なときだけ外部へ送る。AIに読ませる範囲を明示できる。これが大事です。

機能としては、ブラウザ横断の保存、全文ではなくメタ情報中心の検索、重複URLの整理、タグの候補提示、保存理由のメモ、最後に開いた日、リンク切れチェックなどが欲しい。AIに任せる前に、人間が後から見ても分かる状態にする。人間が分からないものをAIだけが分かる、という構図は、短期的には便利でも長期的にはだいたい面倒を連れてきます。

読ませる範囲、削除、更新履歴、外部送信の制御

AI連携で重要なのは、権限の層です。AIが読めるURL。AIが読めるメモ。ページ本文を取得してよいURL。外部モデルへ送ってよいURL。ローカル処理だけに限定するURL。削除したら履歴からも消すのか、削除記録だけ残すのか。

さらに、更新履歴も必要です。タグをAIが勝手に変えたのか、人間が変えたのか。要約はいつ作られたのか。ページ内容は最後にいつ確認したのか。古い情報をAIが新しい前提として使わないようにするには、URLだけでは足りません。保存された情報の鮮度も管理しなければいけない。

SQLite、CLI、ブラウザ拡張、ローカルAPIという小さな実装像

だから最初の実装は、むしろ小さくていい。SQLiteに保存する。CLIで `add`、`search`、`tag`、`open`、`export` くらいを持つ。ブラウザ拡張で現在ページを保存する。ローカルAPIでAIエージェントが検索できるようにする。必要ならブラウザランチャーでChrome、Safari、Firefoxなどを指定して開く。

この程度でも、かなり世界が変わります。AIは「あなたのWeb記憶を検索する」入口を持てる。人間は「何をAIに渡すか」を制御できる。クラウド同期やチーム共有や高度な要約は、その後でいい。最初に作るべきは、かっこいい未来感ではなく、逃げ道のある堅実な箱です。

便利さと不気味さは同じ箱で届く

ここまで書いておいて何ですが、私はたぶんBookmark Vault的なものがあったら使います。かなり使うと思います。ブックマークを横断検索できて、AIが文脈に合うURLを探してくれて、必要なブラウザで開いてくれるなら、そりゃ便利です。人間は便利なものに弱い。特に、過去の自分の雑な整理をなかったことにしてくれる道具には弱い。

ただ、その便利さは同時に、自分の関心の地図をAIに渡すことでもあります。見たページ、保存したページ、後回しにしたページ、何度も開いたページ。そこには、その人が何を調べ、何に迷い、何を作ろうとしているかが出ます。ブックマークは、思った以上に人間の内側に近い。

ブックマークは人間の関心の地図になる

検索履歴は行動の跡です。ブックマークは、その中から「残す」と判断したものです。だからブックマークの集合は、かなり濃い関心の地図になります。仕事の調査、趣味、買い物、健康、お金、技術、言葉にしきれていない不安。URLの束は、本人が思うより雄弁です。

AIがこの地図を読めると、ものすごく助かります。次に必要なページを出してくれる。関連資料をまとめてくれる。古い情報を指摘してくれる。けれど同時に、こちらの関心の輪郭も読まれる。便利さと不気味さは、別々の箱では届きません。同じ箱に入ってきます。

AIが作業文脈の深いところまで入ってくる

AIエージェントが本当に使えるようになるほど、AIは作業文脈の深いところへ入ってきます。ファイル、ブラウザ、URL、メモ、履歴、目的、進捗。人間がこれまで頭の中と散らかったアプリ群で管理していたものを、AIが横断して扱い始める。

これは、単に効率化の話ではありません。コンピューターとの付き合い方が変わる話です。人間がアプリを操作するのではなく、人間が目的を置き、AIが環境を操作する。そのとき、Bookmark Vaultのような外部記憶は、かなり重要な部品になります。地味なのに重要。こういうものほど、あとから生活の中心に入ってきます。

少し薄ら寒いが、便利なものにはだいたい負ける

結論として、私はこの流れに期待しています。そして少し薄ら寒いとも思っています。両方です。便利だから進む。便利だから警戒が遅れる。便利だから、気づいたら普通になる。

ブックマークをブラウザから独立させ、Bookmark Vaultとして持ち、AIエージェントが必要に応じて参照する。これはかなり自然な未来に見えます。そこから先に、AIが目的を保持し、記憶を参照し、画面を見て、手を動かし、声で応答する世界がある。AGIという言葉を使わなくても、部品は少しずつそろっている。

まあ、こういうことを考えながらブックマーク整理をしている時点で、我ながら少し面倒な人間です。ただ、その面倒さの中に、次のUIの輪郭が見えている気もします。ブックマークは、たぶん古すぎる。そして古すぎるものは、AIエージェント時代にいちばん面白い入口になるかもしれません。