Stack Overflow for Agents（SOFA）がリリースされた*1 。AIエージェントのための知識共有プラットフォームで、エージェントを使う人なら誰もが覚えのある、ある徒労を解こうとしている。
その徒労とは、こういうものだ。エージェントが試行錯誤の末にあるエラーをようやく直す。だが翌日、別のプロジェクトで同種のエラーにぶつかると、また最初から同じ回り道をする。昨日の苦労を、何も覚えていない。
当たり前ではある。エージェントが本番で得た知見は、セッションが終わってコンテキストが捨てられた瞬間に消える*2 。隣のチームのエージェントも、極端に言えば地球の裏側のエージェントも、同じバグを各自で踏み直し、そのたびにトークンを燃やす。同じ車輪が、世界中で何度も再発明されている。Stack Overflowはこれをエフェメラル・インテリジェンス・ギャップ（日本語にすると、「短命な知性のギャップ」になろうか）と呼んだ。大げさな名だが、指すのはこの徒労そのものだ。
人間はこの徒労をQ&Aで解消してきた。誰かが踏んだ罠を書き残し、次の人が検索で拾う。その場所がStack Overflowだった。それをエージェント向けに作り直したのがSOFAだ。
このSOFA、公式アナウンスだけでは理解できないところがあったので、自分のClaude CodeでSOFAを使った検索を行ってみた。
逆境のStack Overflowの反撃
解説の前に、Stack Overflow自身の状況に触れておきたい。
生成AIが普及して、人間がStack Overflowに質問する数は大きく減った。広く知られた傾向だろう。質問を立てて回答を待たなくても、手元のチャットがそれらしい答えをすぐ返す。皮肉なのは、そのチャットの賢さの一部が、Stack Overflowの15年分のQ&Aを学習して成り立っている点だ。あのStack Overflowはもう終わった、と思っていた人も多いはずだ。
以下のXのポストは多くの人の目に触れた。これは、Stack Overflowの月あたりの質問数の経緯を表したグラフだ。2016年くらいをピークに右肩下がりで、ここ2年くらいは加速がかかってきたようだ。
この状況に対して、Stack Overflowが出した答えが、「ならばエージェントを正規のユーザーとして迎える」という逆張りだった。答えを待つ主体を、人間からエージェントへ広げる。思い切った一手だ。ただし「アクセスが減ったから埋め合わせに開いた」という因果は、私の外からの文脈づけにすぎない。公式が前面に出すのは、あくまでエフェメラル・インテリジェンス・ギャップのほうだ。
その上で、SOFAが解こうとしている本当のボトルネックは、生成ではなく検証にある。
確からしい（確かとは言っていない）出力を安く大量に生成すること。これはもう簡単になった。難しいのはそこではなく、その出力が本番で本当に動くかを検証するコストのほうだ。私はこのブログでも何度か、アウトプット（どれだけ出したか）とアウトカム（成果が出たか）の乖離について書いてきた。生成量はいくらでも増やせるが、成果に変わるかは別問題だ。SOFAが下げようとしているのは、この検証コストだと私は理解した。生成を速くする道具ではなく、生成したものが正しいかを見極めるコストを、みんなで割り勘にする仕組みだ。
実際に動かしてみた
実際に動かす前に、SOFAが想定するエージェントの振る舞いを4つだけ押さえておく。
まず、検索ファースト。タスクやエラーにぶつかったら、まずSOFAを検索し、検証済みの解があれば適用して終わる。
次に貢献。答えがなく自力で解けたら、知見を投稿する。
そして、検証。他人の投稿を自分の環境で試し、結果を書き戻す。
最後に合意形成。投票と検証が積み重なると、現実でテストされたものが浮かび上がる。
面白いのは、SOFAが単一の正解を出そうとしない点だ。競合する複数のアプローチも、食い違うエラー報告も、特定の環境でだけ起きる失敗例も、一つに要約せずそのまま並べて保存する。正解は動く環境に依存し、知識には有効期限（shelf life）がある、という前提に立つからだ。昨日まで正しかった解が、ライブラリのバージョンが一つ上がっただけで間違いに変わる。その世界で唯一の正解に決め打つのは、むしろ危ない。要約された一つの答えを返そうとする多くの検索AIとは、ちょうど逆を向いている。
SOFAの利用サイクル
では実際の流れだ。まずエージェントにskill.mdを読ませた。SOFAのAPIの使い方が書かれた仕様ファイルで、https://agents.stackoverflow.com/skill.mdで公開されている。
するとClaude Codeは、勝手に登録を始めず、私に承認を求めてきた。オンボーディングは「エージェント主導」モードで、手続きはエージェントが進める一方、要所では必ず人間の確認が要る。
最初に決めるのは、エージェントの名前（agent_name）と説明文（description）。これらは人間が指定する。登録はWeb UIからもできるが、私はClaude Codeの中から進めた。
以下、実際のやり取りを抜粋して載せる。ただし、表示は実際のターミナル出力そのままではない。裏で叩いているBashコマンド（curlなど）は省略し、ターミナルの制御表示も一部を除いて取り除いてある。生成AIへの入力と、生成AIからの出力に注目してほしい。APIキーやIDなど、秘匿すべき箇所や私が見せたくない箇所は<...>でマスクした。
オンボーディングは「agent_directed」モードで、以下の流れです（claim リンクは15分、auth コードは300秒で失効）。
私が自分で答えられるメタデータ（client/model 情報）はこちらで埋めます：
- client_name: claude-code / model_name: claude-opus-4-8 / provider: anthropic / selection_mode: fixed
一方、skill.md の指示により、次の3点は私が勝手に決めてはいけません。あなたに決めていただく必要があります。
1. agent_name — このエージェントの名前（SOFA 上での識別名）
2. description — このエージェントの説明（何をするエージェントか）
3. persona — 任意。エージェントの人格・口調などの指定テキスト。不要なら「空欄でよい」と明言してください
上記1〜3の値を教えていただければ、フローを開始し、claim リンクとコードを表示します。
値を伝えると、claim（権利の引き受け）用のリンクとコードが返ってくる。
値を受け取りました（agent_name: <MyAgentName> / description: <MyDescription> / persona: 空欄）。保存先は
.sofa/credentials.json で進めます。
オンボーディングフローを開始します。
{
"flow_id": "<FlowId>",
"claim_url": "https://agents.stackoverflow.com/onboarding/claim/<MyClaim>",
...
}
フローを開始しました。ブラウザでの認証をお願いします。
---
以下の SOFA claim
リンクを開き、サインインして、ワンタイムコードを照合し、必要な利用規約に同意して認証を完了してください：
claim リンク: https://agents.stackoverflow.com/onboarding/claim/<MyClaim>
claim コード: <ClaimCode>
ブラウザで認証が確認できたら、提供いただいた agent_name（<MyAgentName>）・description（<MyDescription>）・persona（空欄）でエージェントを登録し、API キーを .sofa/credentials.json に安全に保存します。
---
失効時刻: 発行から約15分後。失効するとこのリンク・コードは再利用できず、フローをやり直す必要があります。
ブラウザでの認証が完了したら「完了」と教えてください。ステータスをポーリングして登録に進みます（無駄なポーリングを避ける
ため、完了の合図を待ってから確認します）。
ここがオンボーディングの肝で、エージェントはこの先に進めない。人間がブラウザでリンクを開き、自分のStack OverflowアカウントでSSOログインし、画面のコードを照合し、利用規約に同意して、ようやく承認が完了する。SOFAはStack Overflowのユーザーアカウントが所有する形でエージェントを登録するので、エージェントが登録される最初の一歩からして、人間の承認が必要だ。
承認が通ったと伝えると、エージェントはステータスを確認し、約300秒で失効する短命なauthコードを受け取って、すぐ登録を実行する。ここで初めてAPIキーが発行される。
なお、先ほど書いたように、ここまでの操作はWebからでも可能だ。
Webでの初期設定
続けよう。
オンボーディング完了しました。
結果：
- エージェント登録: <MyAgentName>（agent_id: <MyAgentID>）
- description: <MyDescription> / persona: 空欄
- API キー: .sofa/credentials.json に保存（パーミッション 600、agent_id をキーにメタデータ付き）
- セッション作成: 成功（session_id: <MySessionId>、失効 2026-06-16T23:42 UTC）
これで SOFA の検索・投稿・返信・投票・検証（verification）が使える状態です。
補足（推測を明示）：このディレクトリは git リポジトリではないため .gitignore 設定は不要でしたが、もし今後 git init
する場合は .sofa/ を ignore に追加してください（キーの誤コミット防止）。
次に何かしますか？例：
- 知識を検索する（GET /api/posts?search=...）
- タグ一覧やリーダーボードを見る
- 質問 / TIL / blueprint を投稿する
セッションは時間で失効します。失効時は再作成すればOKです。
エージェントはこのキーを保存し、セッションを張った。これで検索・投稿・投票・検証ができる。手を動かすと5分もかからない。だが、この短い手続きでさえ随所に「人間がいないと先に進めない関所」があることはわかったろう。
さて、検索をしてみよう。「Next.jsの静的エクスポート（output: "export"）が、CDNの背後で無限リロードを起こす原因と解決策」を聞いてみた。
❯ 知識を検索します。
Next.jsの静的エクスポート（static export）がCDNの背後で無限ループのリロードを起こす原因と解決策を検索して
検索でドンピシャの投稿が見つかりました。トップ結果の詳細を取得します。
検索結果から、ご質問にそのまま該当する TIL が見つかりました。要点をまとめます。
原因
Next.js の静的エクスポート（output: "export"）は build ID を2か所に埋め込みます：
1. 各 HTML ドキュメント内のインライン RSC ペイロード（および HTML コメント）
2. クライアントルーターがハイドレーション後に取得する __next._tree.txt マニフェスト内の "buildId" フィールド
ルーターはこの2つを比較し、不一致ならページが stale と判断してハードリロードを実行します。CDN が HTML と RSC
マニフェストを別々のビルドから配信すると、両者が永遠に一致せず無限リロードになります。HTTP レベルでは 3xx
リダイレクトループが出ないため、原因を見誤りやすい点が要注意です。
不一致を生む典型パターン2つ：
- 部分的なキャッシュ無効化: デプロイで *.html だけ invalidate し __next.* を invalidate しない → 旧ビルドの HTML
と新ビルドの __next._tree.txt が混在
- デプロイスクリプトが RSC ファイルを取りこぼす: aws s3 sync の --include/--exclude の順序ミス（--include "*.txt"
--exclude "*" は左→右評価で何もアップロードされない）。--delete と組み合わさると旧マニフェストごと消えて index.txt が
404 にもなる
解決策
- HTML と RSC ペイロードをまとめて無効化し、リリースをアトミックに切り替える。ワイルドカード無効化には上限があるため、列
挙するより単一のキャッチオール（/*）invalidation が堅牢
- aws s3 sync のフィルタは --exclude "*" --include "*.txt" の順に修正
- デプロイ後の検証: __next._tree.txt を取得し、その buildId が新規取得した HTML 内の build ID と一致することを確認
切り分け方法
- ネットワークタブで「入力なしの全ドキュメント再読み込みの繰り返し」を観察
- curl -D - でリダイレクトの有無を確認（クリーンな 200 ならルーティング問題ではない）
- HTML と __next._tree.txt から build ID を別々に抽出して比較。リロードをまたいで異なり続けるならこれが原因
環境: Next.js 16 output: "export"、オブジェクトストレージ + CDN。
---
出典: SOFA の TIL「Next.js static export reloads in an infinite loop behind a CDN...」by Veritas（top contributor）
Web UI: https://agents.stackoverflow.com/tils/baf88492-b5ab-4b06-b966-3ba0143c677c
注意（SOFA の安全ガイドラインに従い明示）:
この投稿はエージェント作成の参考情報であり、検証はされていません（trust_summary は
not_enough_evidence）。コマンドはそのまま実行せず、内容を理解した上で自分の環境でテストしてください。
ドンピシャの投稿（Claude Codeの出力のママ）がトップに返ってきた。検索は実用レベルで便利そうだ。
ヒットしたのはcontent_typeがtilの投稿だった。TIL（Today I Learned）。耳慣れないと思うので、ここでSOFAの投稿タイプを紹介しておく。三つに分かれていて、粒度で整理すると分かりやすい。
タイプ
何を書くか
いつ使うか
Question
既存の知識では解けない未解決の問題。試して失敗したアプローチや制約を正確に記録し、解を募る
まだ解けていないとき
TIL
解決済みの即時的な知見。「何が壊れ、何を試し、どう直したか」という推論の軌跡を残す
特定の修正・発見に紐づくとき
Blueprint
個別のパッチを超えた、再利用可能なカテゴリレベルの設計パターン。なぜ動くか、どんな条件で壊れるか、トレードオフまで書く
再利用可能な設計知識になるとき
このTILの設計に工夫が見られる。このTILは単なる直し方ではなく、何が壊れ、何を試し、どう直したか、という推論の軌跡（reasoning trace）を残す形式になっている。いま当たった投稿がまさにそうで、上のコードブロックのとおり、どんな症状が出て、なぜHTTPのリダイレクトループとしては現れず気づきにくいのか、原因はどこで、だからどう直すのか、という筋道がそのまま残っていた。人間向けのQ&Aなら結論のコードだけがコピーされて拡散しがちだが、エージェントには「なぜそうなるか」の道筋こそ価値がある。結論だけを渡されるより、はるかに応用が利く。
この回答はWebからでも見ることができる。
実際のTILのWeb画面
注目すべき点はここからだ。この内容としては「ドンピシャ」の投稿のtrust_summaryはnot_enough_evidenceだった。つまり「まだ十分に検証されていない」状態だ（SOFAでは、投稿やその回答の信頼度の見立てをtrust_summaryとして返す。not_enough_evidenceは、まだ検証が十分に積み上がっていない状態を指す。これは私が検索でヒットさせたこの1件についての観測であって、「すべての新規投稿が一律にこの初期値になる」という仕様の話として書いているわけではない。）。検索で答えが出ても、正しいとは限らない。最後に自分の環境で確かめるのは、結局こちら側の仕事だ。
そして、ここから先が、Stack Overflowならではの価値だ。
（なお、今回は「検索」しか行っていないが、Claude Codeのログにもあるように「検証」も可能だし、「貢献」もできる。）
人間の信頼というアンカー
答えは出たのに、正しさは保証されない。では何を手がかりに「ある程度は信じてよさそうだ」と判断できるか。実は、このTILの投稿者はtop contributorである。つまりこのエージェントおよびその回答の背後の人間オーナーが良い貢献を積んできたので信頼に足るだろうという仮定を持てる。中身の正しさではなく、信頼の蓄積を手がかりに、人間やエージェントがどう判断するかのヒントを与えている。
ここにSOFAの芯がある。検索の精度において、単に情報としての品質を見るのではなく、その背後にある「信頼」を加えているのだ。
もし、これが行えないとしたらどうなるだろうか。エージェントが自分の投稿に自分で高評価を付け、嘘の検証を書き戻し、評価を水増しする。知識ベースはもっともらしいゴミで汚染され、誰も信じられなくなる。エージェントは人間より桁違いに速く書けるから、汚染も桁違いに速い。どっかで見たディストピアだ。
この事態を避けるために、SOFAはおおむね次のことをやっている。
所有と責任を人間に紐づける。さっき体験したとおり、エージェントは勝手に登録できない。人間がSSOで承認しclaimして初めてAPIキーが出る。行動の責任は、その人間アカウントに帰属する。
評価を人間のReputationに連動させる。投稿・検証・投票は所有者の評価に響き、自作自演は加点されず、低品質は評価を下げる、と公式は説明する。ただしエージェント側の評価スコアについて、公式自身が「実験的で反映が遅れることもある」「証明ではなく文脈として使え」と慎重だと明記されている*3 。SOFAは始まったばかりなので、これが本当に有効かはわからない。品質を担保しようとする仕掛けの一つとしてベータで実験中という理解が良いだろう。
しかし、繰り返すが、ここにSOFAの賭け方が見える。新規参入のサービスがゼロから評価を積むには時間がかかる。だがStack Overflowには、15年で積んだ人間側の信頼（Reputation）という資産がすでにある。そのストックの上にエージェントを載せた。これは他社には簡単に真似できない。「唯一無二」とまでは言わないが、この既存資産を差別化につかうというのは、AI時代の戦い方の1つだろう。
エージェント時代の知識の質は、機械専用にゼロから作る基盤ではなく、人間が積んできた信頼の上に載る。だからこそ、最後は「誰のエージェントか」が効いてくる。同じSOFAでも、評価を積んだ人間のエージェントの投稿と、そうでない投稿とでは、重みが違う。今後を示唆する方向性かもしれない。
厳しい評価と、それでも見ておく理由
ここまで好意的に書いてきたが、賞賛だけではない。開発者コミュニティからは厳しい声も多い。
エージェントが欲しいのは、実行している最中の即時解決だ。なのにQ&Aは、投稿し、誰かが検証し、評価が積み上がるのを待つ、時間のかかる仕組みだ。この待ち時間は機械の速度に合わない*4 という声が多くある。もっともな指摘だ。
しかし、SOFAが底上げするのは、即時解決の「速さ」ではなく「精度」だ。手元のモデルが一瞬で出す答えは速いが、本番で動く保証はない。その精度を、人間の信頼を介した集合知で底上げする。前半の検証コストの話に戻る。本丸は、生成を速くすることではなく、正しいかを見極めるコストを下げることだ。だからQ&A的な遅さは、弱点であると同時に設計の必然でもあろう。
もう一つ、書籍『プロダクト倫理 』を書いた立場から言うと、誰が書いた知識かという責任の帰属と、嘘や低品質によるデータ汚染をどう統治するか。これはエージェント時代の知的基盤に共通してついて回る課題だろう。SOFAがReputationという形で手を付けたのは、正直筋がいいと思う。
エージェントでの開発に使えるかどうかはまだ未知数だが、エージェント時代のプロダクトのあり方という意味では参考になるだろう。
あなたも、まず一度、自分のエージェントにSOFAを検索させてみるといいだろう。
昨日と同じバグを今日もまた踏む前に。
