AIが生成したソフトウェア機能比較表のすべてのセルを検証する方法
AIが生成した比較表にあるアプリに機能が「ある」、別のアプリには「ない」と書かれていた場合、各セルを事実ではなく「検証すべき主張」として扱いましょう。すべての主張について、正確な機能、製品バージョンやプラン、プラットフォーム、そしてそれを裏付ける公式ドキュメントの日付を特定します。このガイドは、ソフトウェアの比較表を信頼したり共有したりする前に確認したい読者向けです。ポイントは、大まかなラベルを検証可能な記述に変換し、同等の詳細度で証拠を記録することです。
各セルが何を主張しているかを定義する
「オフラインアクセス：あり」のようなセルは、検証するには大まかすぎます。ドキュメントの閲覧を意味するのか、編集か、それとも後から変更を同期することなのか？ Web、デスクトップ、モバイルアプリのどれで利用可能なのか？ プランや初期設定によって答えは異なるのか？
調べる前に、主張を書き直してみてください。たとえば、「無料プランでは、オフラインアクセスを有効にすると、デスクトップアプリで選択したページをオフラインで編集できる」といった形です。この一文により、プラン、操作、対象コンテンツの選択、プラットフォーム、前提条件という複数の確認ポイントが生まれます。表をそこまで厳密にできない場合は、「あり」の意味を推測するのではなく、そのセルを「曖昧」としてマークしてください。
可否を判断する前にプランとプラットフォームを確認する
まずはベンダーの最新の価格設定やプラン比較ページを確認し、次に関連する製品のヘルプページを開きます。価格設定ページを見れば、機能がティア（階層）によって異なるかどうかがわかります。また、ヘルプドキュメントには機能を使用するための条件が説明されていることがよくあります。
たとえば、Notionの[料金比較](https://www.notion.com/pricing)では、プランごとのページ履歴保持期間が一覧表示されており、オフラインアクセスはデスクトップおよびモバイルアプリで利用可能な機能として記載されていますが、ティアごとに動作が異なります。「オフライン：あり」とするだけのセルでは、重要な違いが見落とされてしまいます。表にはプラン、アプリ、オフラインで利用可能なページを明記する必要があります。情報源が有料ティアのみについて説明している場合、無料プランでの利用可否は証明されません。
これらの条件によって答えが変わる場合は、「製品・プラン・プラットフォーム」の組み合わせごとに1行を使用してください。そうでない場合は、セル内または明確にリンクされたメモに条件を記載します。ベンダーのページから機能名をそのままコピーして、すべてのユーザーがあらゆるバージョンで使用できると思い込んではいけません。
機能のラベルだけでなく動作を検証する
公式のヘルプ記事を開き、表で可能と主張されている正確な操作を探します。設定、管理者権限、特定のアプリ、または特定のワークフローが必要かどうかを確認してください。それらの前提条件を主張の横に記録します。
Googleによる[ドキュメント、スプレッドシート、スライドでオフラインで作業するための手順](https://support.google.com/docs/answer/6388102?hl=en)には、サポートされているブラウザの使用やオフラインアクセスの有効化など、設定要件が記載されています。その証拠は、オフライン作業に関する条件付きの主張を裏付けるものですが、すべてのユーザーがあらゆるブラウザですぐにオフラインで作業できるという無条件の記述を裏付けるものではありません。ドキュメントに記載された動作とその条件をセットで記録し、情報源の内容以上の意味を表が示唆しないようにしてください。
答えを左右する日付や変更点を追跡する
情報源を確認した日付と、その情報源に有効日や変更の通知が記載されているかを記録します。確認日は、その証拠がいつ時点で最新であったかを読者に伝えるものであり、それ以降製品が変更されていないことを保証するものではありません。
Slackの[無料プランの制限に関するドキュメント](https://slack.com/help/articles/27204752526611-Feature-limitations-on-the-free-version-of-Slack)によると、無料のワークスペースは過去90日間のメッセージとファイル履歴にしかアクセスできず、1年以上前のデータは削除されると記載されています。また、削除の変更が開始された日付として2024年8月26日が指定されています。単に「メッセージ履歴：制限あり」と書かれた表では、制限の基準と時期によって生じる影響の両方が抜け落ちてしまいます。セルまたはそのメモに、制限内容、プラン、該当する日付を含めてください。
ドキュメントに変更の発効日が記載されていない場合は、閲覧日を記録し、日付付きの製品保証のように見せることは避けてください。ページに記載がない場合や、別の公式ページと矛盾している場合は、セルに「不明」とマークし、より具体的な公式情報源を探してください。
すべてのセルの情報源ログを残す
役立つ証拠ログとして、主張ごとに1行を割り当てた付属シートを作成できます。列には、製品、機能、正確な主張、プラン、プラットフォーム、前提条件、情報源のタイトルとURL、該当する一節またはセクション、記載がある場合は発効日、確認日を含めます。セルをその証拠の行にリンクさせるか、セルのメモに簡潔な引用を記載します。
これにより、修正作業が管理しやすくなります。ベンダーが1つのプランを更新したり、特定のプラットフォームのワークフローを廃止したりした場合でも、表全体を再確認することなく、影響を受ける主張を特定できます。メモには情報源ページの本来の意味をそのまま残してください。ベンダーが現在サポートしている内容の証明として、検索結果のスニペット、AIの要約、第三者のまとめ記事に頼ることは避けてください。
答えを捏造せずに不確実性を解消する
情報源が質問に答えていない場合は「確認したドキュメントには記載なし」を使用します。「このプランでは利用不可」は、公式情報源がその制限を明確に示している場合にのみ使用してください。「非対応」「含まれていない」「未検証」は意味が異なるため、明確に区別します。
公式ページ間で相違がある場合は、まず日付、プラン名、地域、プラットフォームの対象範囲を確認します。次に、ベンダーによる最新かつ詳細な記事やリリースノートを探します。それでも矛盾が解消されない場合は、その状況を説明した上で、セルを未解決のままにしておきます。異なるバージョンや条件を曖昧に統合した自信満々の「はい／いいえ」よりも、目に見える不確実性のほうがはるかに有益です。