osint

OSINT

情報の曖昧さを見極め、確信度を評価し、段階的に調査を深めながら、オープンソースインテリジェンスを収集します。公開情報のみを対象とします。漏えいデータは使用しません。ソーシャルエンジニアリングは行いません。定められた範囲を遵守します。

このスキルがオーケストレーションを担います。考えるのはあなたです。ツールとスクリプトは作業を実行します。情報を取得するのはツールとスクリプトであり、判断するのはあなたです。

---

このスキルの使い方

1. 対象を分類します。 個人、企業、ドメイン／IP、B2B アカウント、デューデリジェンスの対象、または脅威主体です。曖昧な場合はユーザーに確認してください。
2. 調査の深さを選びます。 クイック（5 分以内、ウェブ検索のみ）→ 標準（15～30 分、複数のツールを使用）→ ディープ（詳細な調査資料を作成。1 時間ほどかかる場合があります）。ユーザーから別の希望がない限り、標準を選択してください。
3. 以下のゲートを実施します。調査のたびに、必ずすべて実施してください。
4. ワークフローに振り分けます。 振り分け表を参照してください。
5. 出力要件を満たす成果物を作成します。 Markdown 形式の調査資料と、補足ファイル findings.json を作成してください。

---

4 つのゲート

以下の順番で実施してください。いずれかを省略すると、OSINT の調査は失敗します。

ゲート 1 — 範囲と権限

検索を始める前に、次の点を確認してください。

• 適法な根拠。 公人（経営幹部、企業、公開ドメイン）に関する公開情報の調査は問題ありません。ストーキング、嫌がらせ、または許可のない身元調査を目的とした個人調査は禁止です。そのような依頼が疑われる場合は、理由を説明して断ってください。
• 禁止された手法を使わないこと。 有料の漏えいデータベースは使用しません。ソーシャルエンジニアリングは行いません。自分が所有していないアカウントにはアクセスしません。ペイウォールやプラットフォームの利用規約は回避しません。明示的な許可なく、インフラストラクチャへの能動的な調査（ポートスキャン、脆弱性スキャン）は行いません。
• 調査範囲の説明。 次のような一文を作成してください。「[公開情報源] を使い、[目的] のために [対象] を調査します。」 この文を明確に書けない場合は、調査を中止してください。

詳しいルールと依頼を断るべき項目については、references/ethics-and-scope.md を参照してください。

ゲート 2 — 曖昧さの解消

OSINT で最もよくある重大な失敗は、同じ名前の人物（または企業）を取り違えることです。対象について何かを報告する前に、次の手順を実施してください。

1. 名前／ハンドルに一致する可能性のある候補をすべて特定します。
2. 識別要素を選びます。勤務先、所在地、年齢層、ドメイン、業界、写真などです。
3. 識別要素を一次情報源（LinkedIn、企業のプロフィール、企業のウェブサイト、公的な登記情報）で確認します。
4. どの候補を追跡するのか、また、どの候補を明確に対象外とするのかを示します。

曖昧さを解消できない場合は、その旨を伝えてください。推測してはいけません。

詳しい手順については、references/disambiguation.md を参照してください。

ゲート 3 — 情報源の独立性

ある「事実」が、同じ LinkedIn のプロフィールを転載した 10 件のコンテンツファームのサイトで繰り返されていても、情報源は 10 件ではなく 1 件です。調査結果の評価前に、次のことを行ってください。

• 各主張を一次情報源（対象そのもの、権威ある登記情報、直接の証言）までたどります。
• 同じ親会社が所有する 2 つの情報源、または互いを引用する 2 件の記事は、1 つの情報源として扱います。
• 自己公開した主張（対象本人の LinkedIn、プロフィール、ウェブサイト）は、対象が何を主張しているかを知るうえでは有用ですが、その事実の独立した裏付けにはなりません。

ゲート 4 — 確信度の評価

調査資料に記載するすべての調査結果に、アルファベットで評価を付けてください。

• A — 3 件以上の独立した情報源があり、そのうち少なくとも 1 件は一次情報源または権威ある情報源です。
• B — 独立した情報源が 2 件あります。
• C — 情報源が 1 件、または複数あっても独立していません。
• D — 推論、可能性は高いものの未確認、または自己公開された情報源のみです。

調査結果が D としか評価できない場合は、削除するか、推論であると明記してください。

評価基準と特殊なケースについては、references/confidence-grading.md を参照してください。

---

ルーティング表

ユーザーの意図に合ったワークフローを選びます。不明な場合は質問してください。

ユーザーの意図／表現	ワークフロー
「この人物について調べて」「身元調査して」「Xは誰？」	workflows/person.md
「この企業について調べて」「Xは何をしている？」「Xは信頼できる？」	workflows/company.md
「B2Bアカウント情報」「この見込み客にアプローチする価値はある？」「この企業の購買担当者を見つけて」「どんな技術スタックを使っている？」「MSPはどこ？」	workflows/b2b-account.md
「このドメイン／IPを調べて」「技術的な構成」「何が稼働している？」「サブドメインを調べて」	workflows/domain.md
「デューデリジェンス」「投資判断に足る調査」「このベンダー／パートナーを審査して」	workflows/due-diligence.md

複数の対象を調査する場合（例：企業に所属する人物）、該当するワークフローを順に実行し、結果を統合します。

---

フェーズモデル

開始時に調査の深さを決めます。深さとおおよその所要時間をユーザーに伝え、必要に応じて調整できるようにします。

クイック（5分以内、web_search のみ）

• 対象を絞った検索を3～5件実施します。
• 一次情報を1～2件読みます。
• 出力：2～3段落の要約、出典付きの調査結果3～5件、確信度の評価。
• 用途：初期選別、「これを気にする必要があるか」の判断、会議前の準備。

標準（15～30分、複数のツールを使用）

• 一般ウェブ、LinkedIn、企業登記情報を対象に、絞り込んだ検索を8～15件実施します。
• 対象自身が運営するサイトを含む一次情報を5～10件読みます。
• 少なくとも3件の主張について、情報源が独立していることを照合します。
• 出力：templates/dossier.md に従った完全な調査資料と、付属の findings.json。
• 用途：多くのB2Bアカウント調査、見込み客の調査、人物調査。

ディープ（60分以上、利用可能なすべてのツール）

• 段階的に対象を絞り込みながら検索します。
• ドメインが対象の場合は、DNS／WHOIS／証明書の透明性情報を調べます。
• 複数のプラットフォームを相互に照合します。
• 状況を左右する場合は、過去のデータ（Wayback）を調べます。
• 出力：完全な調査資料、findings.json、および1ページのエグゼクティブサマリー。
• 用途：デューデリジェンス、投資判断、大規模アカウントの調査。

伝えた所要時間を超える場合は、続行する前に作業を止めてユーザーに伝えてください。

---

出力仕様

標準またはディープの調査では、必ず次の2つの成果物を作成します。

1. <target-slug>-dossier.md — 人が読める形式で、templates/dossier.md に準拠します。各主張にセクション見出しと確信度の評価を付け、出典URLを末尾にまとめます。
2. <target-slug>-findings.json — 機械可読形式で、templates/findings.schema.json に準拠します。各調査結果に claim、confidence、sources[]、category、extracted_at を含めます。

クイック調査では、Markdown形式の要約だけで十分です。JSONは任意です。

ユーザーから別の指定がない限り、作業ディレクトリ内の osint/<target-slug>/ という名前のフォルダーに出力を保存します。

---

ツールの使用

最低限必要なもの： ウェブ検索とURLの取得機能。このスキルは、これらだけでも動作します。

あると大いに役立つもの（利用できない場合も、可能な範囲で代替します）：

• LinkedIn検索（ウェブ検索演算子またはスクレイパー経由）
• ドメイン調査用のWHOIS／DNS／証明書の透明性情報
• GitHub検索（無料のAPI利用枠で十分です）
• Wayback Machine（過去の情報には web.archive.org）
• ソーシャルプラットフォームの情報抽出用ApifyまたはBright Dataのアクター（APIキーがある場合）

検索演算子のリファレンス： references/search-operators.md — Googleの検索演算子、LinkedIn X-ray、GitHub検索構文、Waybackの使い方。

APIキーの確認（標準またはディープの調査を始める際に一度だけ、ユーザーに知らせず実行します）：

[ -n "$GITHUB_TOKEN" ]   && echo "github: yes"   || echo "github: no"
[ -n "$BRAVE_API_KEY" ]  && echo "brave: yes"    || echo "brave: no"
[ -n "$APIFY_TOKEN" ]    && echo "apify: yes"    || echo "apify: no"
[ -n "$SHODAN_API_KEY" ] && echo "shodan: yes"   || echo "shodan: no"

キーが不足している場合は、ウェブ検索に切り替えます。代替手段を試す前に「これはできません」とユーザーに伝えてはいけません。

---

避けるべきアンチパターン

• 最初に調査書を提示しないでください。 まず調査の深さ、範囲、人物の特定結果を伝え、最後に調査書を作成してください。
• 確信度を捏造しないでください。 C評価の調査結果をCと表示するのは有用です。Aと表示すると、レポート全体の信頼性を損ないます。
• 無意味な情報で水増ししないでください。 出典のしっかりした5件の調査結果は、ざっと触れただけの50件より価値があります。
• 最も目立つ候補が正しいとは限りません。 CEOは有名ですが、実際に連絡を取りたいITディレクターはそうではありません。
• 憶測に基づく経歴を書かないでください。 出典に書かれていないことは、あなたも書いてはいけません。
• 質問に答えた後も調査を続けないでください。 手早く済ませるべきです。

---

エージェント型 OS との統合

現在のプロジェクトルートに .agent/ ディレクトリがある場合、このスキルは Agentic OS の共有メモリモデルに必ず参加する必要があります。

実行の最後に、.agent/state/last-run.json を確認してください。ファイルが存在する場合は、必須スキーマに従って追記または更新し、実行環境（agent_id）、assigned_skill、簡潔な description、decision_log、outcome を記録してください。キューからタスクを完了する場合は、python3 ~/.agents/skills/heartbeat/scripts/heartbeat.py complete <task_id> ... を使用してください。

オプション：PAI / OpenCode との統合

PAI または PAI-OpenCode 内で実行している場合、以下が自動的に適用されます。

• ~/.opencode/skills/PAI/USER/SKILLCUSTOMIZATIONS/OSINT/PREFERENCES.md にあるユーザー設定は、既定値より優先されます。
• ~/.opencode/skills/Apify/ に Apify アクターがある場合は、それらを使用します。
• ファイルが存在する場合、最初に ~/.opencode/skills/PAI/SKILL.md からメモリ／コンテキストを読み込みます。

これらのパスが存在しない場合は無視してください。このスキルは単独でも完全に機能します。

---

クイックスタートの例

ユーザー：「Avenir Senior Living の Jason Gurash について調べてください。B2B の見込み顧客で、インフラコンサルティングの提案を考えています。」

あなたの最初の応答（まだ調査書は作成しないでください）：

B2B アカウント情報の調査を設定しています。workflows/b2b-account.md に従って進めます。調査の深さ：標準（約20分）。特定対象：Avenir Senior Living のオペレーション担当副社長、Jason Gurash。個人的な情報を報告する前に、この人物で間違いないか確認します。範囲：営業の事前調査に役立つ公開情報（企業サイト、LinkedIn、ニュース、テクノロジーの導入状況）。コンサルティングの用途に関係しないため、私生活に関する情報は対象外とします。調査を開始します。

その後、ワークフローを実行します。続いて、評価を付けた調査書を作成します。