X投稿調査

Xの検索結果を単なる評判の一覧にせず、一次情報、条件、反証、リンク先の根拠を追跡できる調査結果にする。

原則

• ログイン済みXのネイティブ検索を必須の開始経路にする。
• X検索が利用できない場合は調査を開始しない。一般Web検索や非公式スクレイパーへ自動フォールバックせず、ユーザーへXへのログインまたはログイン済みブラウザの接続を依頼する。
• X検索APIは、ユーザーがAPI利用を明示した場合、または大量取得・継続監視・再現可能な機械取得が要件になりユーザーが同意した場合だけ、別の実行経路として提案する。
• いいね数や表示回数を事実性の根拠にしない。関連投稿を見つけるための手掛かりとしてだけ使う。
• 技術的主張は、可能ならリンク先の公式文書、コード、Issue、ログ、計測結果まで確認する。
• 読み取り専用で操作する。投稿、返信、引用、いいね、リポスト、ブックマーク、フォローを行わない。

手順1: 調査契約を固定する

検索前に次を短く整理する。

1. 調べる主張または問題を一文にする。
2. 製品名、機能名、エラー文、人物・組織、略称、旧名称を列挙する。
3. 対象期間と言語を決める。指定がなければ問題が発生した時期を含む妥当な期間にする。
4. 求める証拠を決める。公式発表、当事者の実測、解決手順、失敗例、反証を区別する。
5. 調査結果を更新するファイルが指定されている場合だけ、記録先を確認する。

コードや既存文書から分かる条件をユーザーへ質問しない。結果の意味が変わる未確定条件だけ確認する。

手順2: ログイン済みXを確保する

1. 利用可能なブラウザ操作ツールの説明と、適用される操作スキルがあればその手順に従う。
2. ユーザーが開いているブラウザまたは接続済みブラウザで https://x.com/home かX検索画面を開く。
3. ログイン済みで検索結果を閲覧できることを確認する。
4. 現在のブラウザで未ログインなら、利用可能な別の接続済みブラウザに既存のログイン状態がないか確認する。
5. どのブラウザでも利用できなければ停止し、ユーザーにXへのログインまたはログイン済みブラウザの接続を依頼する。

Cookie、localStorage、保存済みパスワード、認証ヘッダーを読み出したり複製したりしない。ブラウザの認証情報を非公式CLIやスクレイパーへ渡さない。

手順3: Xネイティブ検索を設計する

最初は狭い一つのクエリで検索し、結果を見て一軸ずつ広げる。Latest を主に使い、必要に応じて Top、返信、引用投稿を確認する。

利用する代表的な演算子:

• 完全一致: "exact error message"
• いずれか: (RunPod OR runpod)
• 投稿者: from:runpod_io
• 宛先: to:runpod_io
• 日付: since:2026-07-01 until:2026-08-08
• 言語: lang:en または lang:ja
• リンク付き: has:links
• 除外: -is:retweet、必要なら -is:reply
• 最小反応: min_faves:5。発見用にだけ使う。

例:

("RunPod Serverless" OR runpod) ("model cache" OR "model caching" OR "cached model") -is:retweet

runpod (FlashBoot OR "cold start" OR "cold-start") (serverless OR ComfyUI) has:links -is:retweet

クエリ調整は次の順で行う。

1. 正確なエラー文または固有機能名で当事者投稿を探す。
2. 製品名と症状の同義語をORで追加する。
3. 公式アカウント、開発者、既知の利用者に from: を付ける。
4. 期間または言語だけを広げる。
5. 元投稿の返信と引用投稿から訂正、条件、失敗例を探す。

手順4: 投稿を採取する

ブラウザが公開する可視DOMから、投稿本文、投稿者、日時、/status/ を含む正規URL、リンク先だけを取得する。非表示のアプリ内部状態や任意のJavaScript実行に依存しない。

候補ごとに次を記録する。

項目	内容
URL	X投稿の正規URL
投稿者・日時	アカウント名と投稿日時
主張	必要最小限の要約。長文引用は避ける
証拠種別	公式、当事者の実測、二次情報、推測
条件	バージョン、構成、規模、地域、期間、計測方法
外部根拠	公式文書、GitHub、ログ、ベンチマークへのリンク
反証	返信・引用投稿・別事例との矛盾
判定	確認済み、条件付き、未確認、反証あり

同じ投稿の言語・クエリ違いによる重複は正規URLで除外する。削除済み、非公開、閲覧不能な投稿の内容を事実として採用しない。

手順5: 技術的主張を検証する

1. 投稿が公式文書やGitHubへリンクしていれば元資料を開く。
2. バージョン、日付、構成、前提条件が現在の対象と一致するか確認する。
3. 「改善した」という主張には、変更前後の値、測定範囲、再起動条件などがあるか確認する。
4. 公式投稿でも保証条件を省略しない。「ホストにモデルが存在する場合」のような条件を結論へ残す。
5. 返信と引用投稿を確認し、作者による訂正や再現失敗を探す。
6. Xだけでは確認できない内容は 未確認 または 当事者報告 と明示する。

X投稿と外部資料が矛盾する場合は、より新しい一次資料と再現可能な証拠を優先し、矛盾そのものを結果へ残す。

手順6: 結果を報告する

結果は次の順で簡潔にまとめる。

1. 確認できたこと: 公式資料または再現可能な一次情報で裏付けた内容。
2. 当事者報告: 有用だが環境依存または未再現の内容。
3. 反証・未確認: 矛盾、削除済み投稿、根拠不足。
4. 適用判断: 現在のプロジェクトへ適用できる条件と、追加検証が必要な点。
5. 調査範囲: 使用した主要クエリ、対象期間、検索日時、確認したXの表示面。

リンクは主張の近くに置く。有用な投稿が見つからなければ、X上の証拠が乏しかったと明記し、推測で埋めない。

既存文書へ追記する場合は、採用した情報、採用理由、適用条件、正規URLだけを適切な節へ統合する。検索結果の生データをそのまま残さない。

失敗時の扱い

• ログインが必要: 別の接続済みブラウザを確認し、それでも不可ならユーザーへログインを依頼して停止する。
• 検索結果が読み込めない: 同じログイン済みX上でクエリを狭め、再読み込みする。一般Web検索へ切り替えない。
• レート制限: 連続再試行せず、最後に成功した範囲と再開条件を報告する。
• 投稿が削除・非公開: 内容を引用・推定せず、閲覧不能として記録する。
• 大量取得が必要: 自動化を始めず、公式X検索APIを使う別作業としてユーザーへ提案する。

完了条件

• ログイン済みXのネイティブ検索を使用した。
• 採用した各主張に正規URL、投稿者、日時、証拠種別がある。
• 返信・引用投稿または別の一次資料から反証を探した。
• 技術的主張のリンク先を可能な範囲で確認した。
• 確認済み、当事者報告、未確認を混同していない。
• 使用クエリ、対象期間、検索日時を残した。
• X上で外部副作用を起こしていない。