人々が語れるようにリンク先を用意する
(simonwillison.net)- プロジェクトや製品機能を人々に理解し、共有してもらいたいなら、繰り返し説明する前にまず専用のWebページが必要
- ChatGPT Code Interpreterは強力な機能であるにもかかわらず、公式ドキュメント上の名称と見つけやすさが安定せず、他の人が作った説明のほうが有用なリンク先になっている
- Claude ArtifactsやGitHub Codespaces・Copilotの事例は、機能がリンク可能な対象になると共有や説明が容易になることを示している
- Dan McKinleyのBoring Technologyのように、概念が別ページとして整理されていると、初めて聞く人でもリンク1つで文脈にすばやく追いつける
- 専用ページの価値は検索での露出にとどまらず、Web上の会話で同じ説明を繰り返さずに済むようにする点にある
リンク可能なページが必要な理由
- プロジェクト、アイデア、製品機能のように、他の人に理解し語ってほしい対象にはリンク可能なページが必要
- ハイパーリンクはWebで会話を広げる基本的な手段であり、説明を毎回新しく書かずに決定的な説明へつなげられる
- 専用ページがないと、関心や検索トラフィックが、他の人が作った説明や検索語を先取りしたページへ流れてしまう可能性がある
ChatGPT Code Interpreterの見つけにくさの問題
- ChatGPT Code Interpreterは、ChatGPTが応答の過程でPythonコードを書いて実行できるようにする機能
- 機能自体は強力だが、プロンプトで有効化する方法を知らないと、その存在に気づきにくい
- OpenAIのサイトでCode Interpreterを探すと、API機能に関する技術ドキュメントや古いフォーラムスレッドが出てきて混乱を招く
- この機能を紹介する際には、OpenAI公式ページよりもcode-interpreterタグページのほうが有用なリンクとして使われている
- 後になって実際のドキュメントが確認されたが、タイトルはData analysis with ChatGPTで、「Code Interpreter」という用語がページになく、見つけにくかった
- OpenAIはこの機能名をCode Interpreter、Advanced Data Analysis、Data analysis with ChatGPTへと変え続けてきた
機能ページをうまく作っている例
- ClaudeのArtifacts機能には、少なくとも見つけやすいヘルプページがある
- ただしArtifactsの発表記事はClaude 3.5 Sonnetの発表と一緒に共有されており、Artifactsだけの明確なリンク先には見えにくい
- GitHubは機能ごとにランディングページを別途提供している
- 機能に別の専用ページがあると、リンクして共有する際の説明の基準点が生まれる
Boring Technology：概念がWebサイトになった例
- Dan McKinleyは2015年のChoose Boring Technologyというエッセイで、Boring Technologyという用語を作った
- 核心は、開発チームが新しい問題を解決できる能力には限りがあるため、その能力を製品を独自のものにする部分へ使うべきだということ
- それ以外の領域では、バグや限界が長年オンラインで理解され議論されてきた、最も退屈でよく知られた技術を選ぶべき
- このアイデアはboringtechnology.clubというWebサイトにも整理されている
- 誰かがこの用語を知らないとき、リンクを1つ共有すれば数分で文脈に追いつける
個人のアイデアにも共有可能なページが必要
- baked data、git scraping、prompt injectionのようなアイデアも、頻繁に共有できるページとして整理されている
- ただし、別ドメインまで確保しないと、「ここがリンクすべき中核ページだ」というメッセージは弱くなる可能性がある
- 明確なリンク先は、アイデアの共有しやすさと会話しやすさを高める
SEOよりも会話でより大きく働く価値
- 専用ページの明確な目的の1つはSEO
- ユーザーが製品機能を検索するとき、他の人が作ったページではなく自分のサイトへ来てもらう必要がある
- より大きな価値は会話の中で現れる
- ある概念を説明するとき、段落を1つ書き直すより、決定的な説明を含むリンクを共有できる
- アイデア、プロジェクト、機能を人々に理解し議論してもらいたいなら、それにふさわしいWebページを作るべき
1件のコメント
Hacker News のコメント
rsync.net はこういうことがうまいサービス。たとえば、ほかのサービスで CEO ページのようなものを見たことがない。
実際に役に立つのかは分からないし、CEO に何かを伝えなければならなかったこともないが、顧客でもないのにこの記事を読んだ瞬間、このページが真っ先に思い浮かんだ。
[1]: https://www.rsync.net/products/ceopage.html
参加者がもっともらしい業務上の理由を自分で作らなくても、上司にそのまま送れるように設計されたページだ。
OpenAI ほどになれば、もう テクニカルライターを雇っていると思っていたが、LinkedIn を見る限りそうではなさそうだ。だからドキュメントの状態がこれほど悪いのも、それほど驚きではない。
なぜドキュメント専任の役割を採用しないのか理解できない。重要だと見ていないのか、ドキュメントより成長を冷徹に優先しているのかもしれないが、理由が何であれ結局は自分たちが損をしている。
記事では https://boringtechnology.club/ が参照されているが、独自の解決策にだけイノベーションの労力を残しておけ、という優れたスライドデッキだ。
それ以外はできるだけ 退屈な技術で行くべきだ。開発チームが下の層まで全部を革新しようとして、肝心のどんな価値を提供しているのかという焦点を失うケースをあまりにもよく見る。このスライドデッキを自分の世界観に刻み込みたい。
Simon のまた良い記事だ。昨夜、新しいプロジェクトにこの考え方をそのまま入れた。Google Gemini App は yt-dlp を検閲するが Gemini API はそうではない、という根拠を示したかったし、同時にプロジェクトへの流入経路と、Simon が言っていたビジネス面の理由も作りたかった。
https://topicalsource.dev/chat/84a0d6dd-f66f-4f12-af17-5e99c...
さらに localStorage を使って、訪問した公開チャットの一覧を保存するようにした。戻ってきたときに読んだ別のチャットを見られるし、元のリンクをどこでもらったのか、メッセージ履歴を漁るよりも見つけやすい。
死んだリンクが一番最悪だ。誰か GPT で死んだリンク先のウェブサイトを幻覚して作ってくれるブラウザ拡張を作れないのか？
アーティストは単にソーシャルメディアサイトだけをリンクするが、アカウントは停止される可能性があり、ユーザー名も変わり得る。開発者も依存関係を「リンク」する一方で、リポジトリが消える可能性や、誰もバックアップしていなければそのバージョンのソースコードも一緒に消える可能性、パッケージのバージョンがレジストリから削除されたり、依存先のオンラインドキュメントが消えたりする可能性を考慮していない。
[1]: 単にマニフェストファイルに名前+バージョンを追加して、永遠に忘れてしまうこと。キャッシュを追加したとしても、まともなミラーですらなく、災害時に依存関係を自分でビルドできる方法にはなおさらなっていない。
人々がそのページが以前どんな見た目だったかを一つずつ描写したり、手がかりを探すためにウェブをクロールしたりするなら、かなり興味深いアイデアだ。「工事中」バナーも復活させられる。
Simonw のブログが好きだ。去年9月から Python インタプリタを使って彼のブログを読んでいる。彼は、その場でアプリケーション全体を作ろうとして一人でそうし始めたと言っていた。
ただ、今でもどうやるのかはっきり分からない。簡単なオプションやボタンがあると思っていたが見つけられなかった。もっと頑張って調べることもできただろうが、便利なリンクやチュートリアルがあれば、GPT をほとんど無視せずに使い続けていたと思う。
この文脈では、Square の 障害対応ミームは https://outage.party/ として今も生きている。
Microsoft 製品のかなり多くを、まさにこの理由で本当に嫌っていました。VSTS/VSO/Dev Ops のように名前が変わる製品や Sharepoint などは特にひどかったです。ディープリンクが1つで700文字あり、base64 のクエリ文字列が何十個も付いて、意味不明なパスまで付いていました。「何が問題なんですか？ URL 短縮サービスを使えばいいでしょう？ URL はもともと長いものなので、仕方ありません」という調子で、気が狂いそうでした。
2014年に、チーム内ツールがシステムリソースの状態を表示していて、すべてのリソースと状態は SQL データベースにありました。ところがその Web アプリは、ルーターのようなものが登場する前の SPA で、URL を更新することも、ディープリンクをサポートすることもありませんでした。特定のリソースの問題をメールやメッセンジャーで送るには、「X ツールに行って Y を検索し、Z -> W -> M -> O -> K を押すとそこに見えます」と説明しなければなりませんでした。なぜ単に https://X.com/Y/Z/W/M/O/K というリンクで、深くネストした状態を共有できないのか、とても腹が立ちました。何度言っても「優先事項ではないし、そんなに大ごとでもない」という答えしか返ってきませんでした。
一度、直したいものに2週間取り組める機会があり、ディープリンクをサポートする代替版を作ることにしました。さらに、すべてのディープリンクに
/api/接頭辞を付けると内容を JSON で返すようにしました。チーム内でも社内でも大ヒットし、私のツールのほうがはるかに単純で機能も少なかったにもかかわらず、X ツールの利用はほとんど一夜にして減りました。結局、ほとんどの人が求めていたのは「深く掘り下げて調査できる強力な SPA」ではなく、リンクを簡単に共有する方法だったのです。1か月後、X ツールのチームは全社メールでディープリンク対応を大々的に発表しました。しかし、
/api/接頭辞で JSON データを返すという単純な機能は重要ではないと見なしました。5年後、私のツールの UI は時代遅れになりましたが、実際のサービスは多くのチームが/api/接頭辞付き URL を中心に自動化を作っていたため、中核的な社内サービスに昇格し、最終的にそのチームがコードを引き取って保守しなければならなくなりました。Simonw のファンとして、まだ誰も指摘していない点を挙げると、Simon が人々がリンクできる対象を提供している別の例は、HN でも非常に効果的です: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Simon は、AI 分野で近い人たちはすでに知っているものの、より広い層にはまだ知られていない進行中のニュースを、とても素早く整理することがよくあります。関連する事実にすぐリンクでき、アクセス可能な形にすることで、その件から離れたところにいる人たちも議論できるようにしてくれます。
「ハイパーリンクはWebの最良の部分」という言葉に同意する。正確にはハイパーリンクとURLだ。
URLはWebの礎石である。文章やほかのリソースを、正確で、普遍的であり、長く残ってほしい形で参照できるようにしてくれる。人々がこのすばらしさに気づかないのを見ると、いつももどかしい。たとえばメッセージにリンクを貼る代わりに「YouTubeでこれを検索して」と言うような場合だ。文章に永続的なWeb上の居場所を与えれば、可視性も高まり、著者が同じ考えを何度も書き直す必要も減る。
関連する古典的エッセイ: Cool URIs don't change. [0][1]
[0] https://www.w3.org/Provider/Style/URI
[1] https://news.ycombinator.com/item?id=23865484
実際の効果はこうだ。誰かと会話しているときや発表のQ&Aで「はい、それは私たちも考えたことがあり、関連情報は acmeinitiative.example.com/skub にあります」と言いたいが、まだ
/skubの記事を書いていないとしても、その場で即座に/skubをその記事の指定ハンドルに決められる。記事は後で書けばそこに現れ、関心のある人はいつでもそのURLで見つけられる。ほかの人が書いた記事や外部リソースでも同じで、自分の名前空間に即席のURLを作り、後で時間ができたときに元のリンクへリダイレクトすればよい。自分のドメインを明らかに所有している賢い技術者が出てくる録音やポッドキャストなどで、このやり方を使っていない例をあまりにも多く聞いてきた。たいていは見つかるかもしれない程度の説明をぼそぼそ言ったり、タイトルを思い出そうとして半分だけ間違えて言ったりする。すると関心のある聴き手全員が、それぞれ時間と注意を浪費して探さなければならず、集団として膨大なエネルギーが漏れ出てしまう。
FBは著作権コンテンツの共有を理由に、無作為なブログまで多くのサイトをブロックしており、redditはすべての
.ru、複数のアーカイブサイト、Telegramリンクなどをブロックしている。Twitterはいくつかのブログプラットフォームをブロックしたし、より小さなサイトでもDiscordをブロックすることが多い。Discordのブロックは正当化できるかもしれないが、こうした流れが人々をそこから離れさせるきっかけになればいいと思う。第一に、すぐにAOL Keywordのような気持ち悪さを刺激する。第二に、検索バブルという概念を完全に無視している。同じ検索語を入れても、あなたと私が受け取る結果は大きく異なる可能性がある。第三に、URLとハイパーリンクがすぐそこにあるのに、わざわざ私に追加作業をさせる必要はない。直接リンクしてくれれば、私は無数のリアクション動画の間をさまよわずに、あなたが正確に何を参照したのかを見られる。
しかし多くのサイトやサービスはこれを嫌う。自分たちの注意の領土を侵害すると見なすからだ。著者として、すでにブログ記事や本で慎重に表現したアイデアにリンクすると、「宣伝」という理由でコメントが削除されたり検閲されたりする。最近のHNでは、罰を避けるために読者がより深く探索できるリンクを示すよりも、自分が書いた原文をそのままコピーして貼り付けることのほうが多くなった。情報を広めるためのよい「学術的」な方法として私たちが説いていることと、表現を統制するシステムの現実との間には、明らかな隔たりがある。