OSINTという手法で調べています
当社の調査は、OSINT（Open Source Intelligence、オシント）という手法で行っています。公開されている情報を集めて分析し、特定の問いに答えるための手法です。軍事や国家安全保障の分野で発展し、現在ではサイバーセキュリティ、企業のリスク調査、報道などで広く使われています。
公開情報は、1つ1つは断片です。出どころの違う記録を何層にも重ねて突き合わせることで、はじめて言えることがあります。下の2つの実例は、その重ね方を見せるものです。使うのは、通常の閲覧で得られる公開情報だけです。OSINTそのものの説明は、調査の方法にまとめています。
当社の調査で決めていること
個別のページを読む前に、保存記録の全件を一覧にします
都合のよい保存だけを見ることを避けるためです。実例1では公開索引が返した1,442件を年別に並べ、保存の多い時期と空白を確かめました。全件とは、今回の公開索引の応答の範囲です。
ページの記載から、別の記録を探す鍵を拾います
社名だけでは、同名の会社を取り違えるおそれがあります。実例1では商号と所在地を法人番号の履歴に、届出番号を総務省の一覧に当てました。ページの説明を、そのまま会社の来歴とは扱いません。
検索条件が効いたことを、結果の中でも確かめます
設定したつもりでも、対象が検索から外れていれば結論が変わります。実例1では、閉鎖された法人と旧商号の行が結果に含まれることを確認しました。
出どころの違う記録を突き合わせます
同じ保存元に記録を増やすだけでは、その保存元の空白は埋まりません。実例2ではWayback Machine（過去のWebページの公開アーカイブ）の結果を、別系統のCommon Crawl（Web収集データ）でも確かめました。後者で裏づけは増えましたが、7月の切り替え時期の幅は縮まりませんでした。
変更日は一点に決めず、確認できた前後の時点で示します
保存日は変更日とは限りません。実例2では、ライセンスの価格を最後に確認できた保存と、表示が変わったあとの最初の保存を並べました。商品一覧と製品ページも別々に扱っています。
見つからないことと、存在しないことを分けます
検索や保存の仕組みには、拾えない範囲があります。実例1では、2007年の会社が検索で見つからない理由を考えるため、法人番号制度の開始当時の公式説明まで戻りました。制度の説明だけで、その会社の経緯は決めません。
拒否された取得を回避せず、失敗も残します
取得できなかった範囲を隠すと、調査の限界が伝わりません。両実例に関わるDNS（ドメインの接続先）の履歴は、アクセスを拒否されて取得を止めました。Common Crawlで失敗した照会も記録し、時間をおいて照会し直しました。
サイトが示す日付と、第三者が観測した日付を分けます
同じ「日付」でも、何を記録した値かが違います。実例2では、sitemap（ページの一覧）に載る更新日を作り替えの日の根拠にはしませんでした。当社の開発と配信の日時も、切り替わった瞬間を示す記録とは分けています。
集めた記録には、取得を終えた日のうちに第三者のタイムスタンプを付けます
出典の保全と検証資料を伴う詳細な調査で行っている手順です。ここでいうタイムスタンプは、ファイル名に日付を入れることではありません。第三者の時刻認証局が発行する電子的な証明です。仕組みはタイムスタンプとは何かで説明します。
当社の一覧だけでは、いつ集めたのか、集めたあとに手を入れていないかを、当社の時計と当社の説明でしか示せません。今回は取得を終えた当日に、その時点までに取得した全ファイルのSHA-256の一覧を作り、その一覧に時刻認証局のタイムスタンプを受け取りました。示せるのは、データがその時刻以前に存在し、検証するときの内容がタイムスタンプを付けたときと一致することまでです。取得した日時そのものをさかのぼって証明するものではありません。検証資料を添えるレポートでは、この一覧とタイムスタンプを、検証の手順と一緒にお渡しします。
同じ記録でも、問いが変わると読む場所が変わる
実例1は利用者を、実例2は記載とサイトの作りの変化を追います。問いにより照合先が変わります。
| 進め方 | 実例1 ドメインの来歴 | 実例2 記載の変更時期 |
|---|---|---|
| 問いの単位 | ドメインと利用者の法人 | URLごとの記載と応答 |
| 最初に取る一覧 | ドメイン全体の保存を年別に整理 | 対象5ページの保存を時系列に整理 |
| 鍵にした情報 | 商号、所在地、届出番号 | 価格や説明の文、読み込み先の特徴 |
| 突き合わせた記録 | 法人番号の履歴、届出一覧、登録情報、証明書 | 前後の本文、別ページ、別系統の収集記録 |
| 線を引いた場所 | 別法人とは示せても、関係が一切ないとは示せない | 観測した前後は示せても、変更の瞬間は決められない |
集めた記録の一覧
2026年11月13日に取得した記録です。
| 記録の種類 | 取得元 | 件数 | 分かること | 分からないこと |
|---|---|---|---|---|
| 保存記録の一覧 | Wayback Machineの公開索引 | 1,442件（2004年11月〜2026年7月の保存） | 保存されたURL、日時、応答の状態、保存の空白 | 保存のない期間の状態 |
| 保存されたページの原本 | Wayback Machine | 298件。うち295件で保存日時と内容の一致を確認 | 保存された時点の本文と応答 | 実際の公開日と変更日 |
| 別系統の収集記録 | Common Crawl | 最初の照会で索引191件、原本119件。129の収集回の多くは照会に失敗 | 別系統の本文と転送先 | 未取得の収集回に記録があるか |
| ドメインの登録情報 | JPRSのWHOIS | 日本語と英語の応答（日本語は別の手段でも取得し、内容の一致を確認） | 現在の登録日と登録者 | 過去の登録者、手放した日 |
| 法人番号と変更履歴 | 国税庁の法人番号公表サイト | 検索結果の4法人と、各法人の履歴 | 旧商号、商号変更と移転の日付、閉鎖の記録の有無 | 法人どうしの関係、営業の実態 |
| 届出電気通信事業者の一覧 | 総務省（現行版と、保存されていた過去の2版） | 4ファイル | 届出番号と名義の対応 | 名義が変わった理由と日付 |
| 証明書の公開記録 | crt.sh | 144件の記録（同じ証明書が複数回記録されるため、証明書の数ではない） | 証明書の有効開始日、対象のホスト名 | サイトの本文が公開された日 |
| 現在のサイトの応答 | netwiz.co.jp | 4つのURL | 取得時点の作り、sitemapに載っていた59のURL | 過去の状態 |
| ドメインの接続先の履歴 | DNSの履歴を公開しているサービス | 取得できず（アクセスを拒否され、回避していない） | — | 接続先の過去の変化 |
| 当社自身の記録（答え合わせ用） | ソースコードの履歴と配信サービスの記録 | 3ファイル | 最初の記録、ドメインの追加、配置の日時 | 接続先を実際に切り替えた時刻 |
外部から取得した記録は、取得のたびに、取得元、取得日時、応答の状態、バイト数、SHA-256（内容が変わると値が変わる照合用の値）を一覧に記録しています。失敗した試行も残し、当社自身の答え合わせ用の記録は別に保管しています。
調査データの一式には、取得を終えた当日（2026年11月13日18時58分、日本時間）に第三者のタイムスタンプを付けました。対象は、取得した記録とその一覧の3,184ファイルと、答え合わせ用の当社の記録3ファイルです。Common Crawlを照会し直して取得した分は、この対象に含めていません。
Common Crawlは、接続できない、またはサーバーのエラーとなる照会が多く、最初の照会で結果を得られたのは129の収集回のうち9回分でした。時間をおいて照会し直しましたが、同じ日のうちに追加で取得できたのは一部の収集回にとどまりました。失敗した収集回に記録があるかどうかは分かりません。上の件数に、照会し直して取得した分は含めていません。
タイムスタンプとは何か
ここでいうタイムスタンプは、ファイル名に「_20261113」のような日付を入れることではありません。パソコンが記録する作成日時や更新日時のことでもありません。どちらも、ファイルの持ち主があとから書き換えられるので、「その日にあった」ことの裏づけにはなりません。
当社が付けているのは、時刻認証局という第三者が発行する電子的な証明です。RFC 3161という、インターネットの標準として公開されている方式を使っています。紙でいえば、封をした書類に第三者の日付印を押してもらうのに近い考え方です。
仕組みは次のとおりです。
- 当社が、データからハッシュ値を計算します。ハッシュ値は、内容が1文字でも変わると別の値になる、照合用の短い値です。
- そのハッシュ値だけを、時刻認証局に送ります。データの中身は送りません。
- 時刻認証局が、受け取ったハッシュ値と、その時点の時刻をひとまとめにして電子署名を付け、送り返します。これがタイムスタンプです。
あとから確かめる人は、まず時刻認証局の証明書を使って、タイムスタンプの電子署名が正しいことを検証します。次に、手元のデータからハッシュ値を計算し直し、タイムスタンプに入っている値と比べます。どちらも通れば、そのデータはタイムスタンプの時刻以前に存在していて、いまの内容がタイムスタンプを付けたときと一致すると分かります。時刻を記録して署名したのは当社ではなく時刻認証局なので、当社が日付をさかのぼらせることはできません。
分かるのは、ここまでです。タイムスタンプは、データがいつ作られたか、だれが作ったか、中身が正しいかまでは示しません。当社がページを取得した日時や、そのページが過去に公開されていたことを、さかのぼって証明するものでもありません。そこで当社は、取得のたびに取得日時を一覧に記録し、取得を終えた日のうちにタイムスタンプを付けて、取得からタイムスタンプまでの間を短くしています。
検証資料は受け取った方が自分で確かめられます
出典の保全と検証資料を伴う詳細な調査では、レポートの本編に検証資料を添えます。入れるものは次のとおりです。
| 入れるもの | 役割 |
|---|---|
| 取得した記録の一覧 | どの記録を、いつ、どこから取得したかを示す。取得元、取得日時、応答の状態、SHA-256を載せる |
| 数量や照合の明細 | レポートの数字のもとになった表。CSVなどの形式で、同じ数字を数え直せる |
| ファイルのハッシュ一覧 | 検証資料に含まれる全ファイルのSHA-256 |
| タイムスタンプ | そのハッシュ一覧に、第三者の時刻認証局が付けた時刻の証明 |
| 検証の手順と証明書 | 確かめるための手順書と、時刻認証局が公開している証明書。証明書の入手先も手順書に書く |
受け取った方は、当社に問い合わせなくても、次の3点を確かめられます。
- 受け取ったファイルの内容が、ハッシュ一覧と一致すること。
- その一覧が、タイムスタンプの時刻以前に存在し、いまの内容がタイムスタンプを付けたときと一致すること。
- タイムスタンプの電子署名が、時刻認証局の証明書までたどれる正しいものであること。
使うのは、誰でも入手できる公開の道具（OpenSSL）です。この実例の調査データでは、データを置いたフォルダの一番上で、次の3つの操作をして確かめられます。
shasum -a 256 -c evidence/2026-11-13/timestamps/hashes-2026-11-13.txt
openssl ts -reply -in evidence/2026-11-13/timestamps/hashes-2026-11-13.tsr -text
openssl ts -verify -data evidence/2026-11-13/timestamps/hashes-2026-11-13.txt -in evidence/2026-11-13/timestamps/hashes-2026-11-13.tsr -CAfile evidence/2026-11-13/timestamps/digicert-roots.pem
1つ目はファイルと一覧の照合、2つ目はタイムスタンプに記録された時刻の表示、3つ目は一覧とタイムスタンプの対応の検証です。1つ目はmacOSやLinuxの例で、Windowsでも標準のコマンドで同じ計算ができます。この実例では、3,187ファイルのハッシュ一覧に2026年11月13日18時58分（日本時間）のタイムスタンプが付いており、3つ目の操作の結果は「Verification: OK」でした。
記録の時点や、あとから手を入れていないかを問われたときに、当社の説明だけでなく、第三者の時刻と計算で確かめてもらえます。記録が証拠としてどう評価されるかは、当社が判断するものではありません。
取得したままの原本は当社で保管します。検証資料に何を含めるかは、用途に応じて着手前に決めます。
これは納品物の見本ではありません
この2つの実例は、調査の進め方の一部を見せるもので、納品するレポートの見本ではありません。題材が当社自身のため、第三者としての調査ではありません。実際の調査では、ご依頼の目的に合わせて範囲を決めます。レポートの位置づけは弁護士・士業の方への案内、使う道具とその限界は調査の方法に記載しています。