AI component のエビデンスとみなされるもの
注：この文書は英語の原文からの自動翻訳です。
AI component のエビデンスとみなされるもの
DecAIHub がプロジェクトに稼働中の AI component があるかどうかを評価するとき、それは 検証可能なアーティファクト を探します——マーケティング文面でも、約束でも、ブランドとの関連でもありません。このページは、DecAI Fit スコアの AI reality 軸を強める種類のエビデンスを、強いものから弱いものへと順に列挙します。
要約： AI のエビデンスとは、検査し、テストし、独立に検証できるアーティファクト——コード、ドキュメント、方法論を伴うメトリクス、稼働するデモ、サードパーティ評価——を意味します。
Tier-1 エビデンス（最も強い）
Tier-1 ソースは、プロジェクト自身が公開または管理するアーティファクトです。AI reality 軸にとって、最も強い Tier-1 エビデンスには次が含まれます：
- AI/ML コードを含む公開リポジトリ — モデルの訓練スクリプト、推論ロジック、データパイプライン、前処理ステップ。コミット、リリース、テストを伴うリポジトリは、README だけのプレースホルダーリポジトリよりはるかに強いです。
- 技術文書 — モデルアーキテクチャ、入出力フォーマット、モデルバージョン、更新履歴の記述。これは「どのモデルか、どう動くか、どのバージョンが稼働しているか」に答えます。
- 方法論を伴う品質メトリクス — 何が、どのデータで、いつ、どのバージョンのモデルで測定されたかを明示する、公開されたベンチマークや評価結果。この文脈を欠くメトリクスは エビデンスではありません。
- 稼働するデモやエンドポイント — AI component をテストできる、公開アクセス可能なインターフェース、API、サンドボックス。実入力を処理し AI 駆動の出力を返すデモは直接的なエビデンスです。
- 監査レポートやサードパーティ評価 — 認知された主体による、モデルの品質、公平性、安全性、性能の独立した評価。
Tier-1 エビデンスを強めるパターン
すべての Tier-1 アーティファクトが等しく説得力を持つわけではありません。いくつかの観察可能なパターンがエビデンスをより信頼できるものにします：
- コミット履歴の深さ。 数か月から数年にわたる漸進的なコミット、プルリクエスト、コードレビュー、バージョン管理されたリリースを持つリポジトリは、持続的なエンジニアリングの努力を示します。一度きりの一括アップロードははるかに軽い意味しか持ちません。
- テストカバレッジと CI パイプライン。 モデル推論、データ検証、統合エンドポイントの自動テストは、概念実証ではなく本番グレードのシステムを示します。
- バージョン管理されたモデルと変更履歴。 ドキュメントが、どのモデルバージョンがデプロイされているか、バージョン間で何がなぜ変わったかを追跡しているとき、それは活発な開発サイクルを持つ生きたシステムを示します。
- 再現可能な出力。 デモや API が、セッションをまたいで同じ入力に対して一貫した説明可能な結果を返すなら、それは一度きりのショーケースより強いです。
- AI ロジックとボイラープレートの分離。 AI/ML モジュールが明確に識別できる——フロントエンドの足場、デプロイスクリプト、トークンコントラクトと区別されている——コードベースは、AI component が実際に何をするかを検証しやすくします。
Tier-2 エビデンス（文脈であって証明ではない）
Tier-2 ソースは文脈を提供しますが、それ自体では稼働中の AI component を証明しません：
- チームが AI の手法、アーキテクチャ、訓練プロセスを語るインタビューや AMA。
- AI 能力に言及するアグリゲータの説明（CoinGecko、DeFiLlama など）。
- AI プロバイダーや研究ラボとのパートナーシップ発表。
Tier-2 エビデンスは Tier-1 の所見を支えることはできますが、それを置き換えることはできません。AI 企業とのパートナーシップは、プロジェクトが自社の稼働する AI を持つことを証明しません。
Tier-2 エビデンスが重要になるとき
Tier-2 ソースは、Tier-1 アーティファクトを裏付けるとき、または Tier-1 だけでは曖昧なギャップを埋めるときに関連性を持ちます：
- チームがドキュメントに記述されたアーキテクチャを順に説明する技術インタビューは、Tier-1 のドキュメントに信頼性を加えます。
- プロジェクト自身のホワイトペーパーに記述された能力と一致するアグリゲータの掲載は、一貫性を示します。
- プロジェクトの公開 API の挙動を映すライブデモを伴うカンファレンスの講演は、そのデモがスクリプト化されていないことを補強します。
しかし、基盤となる Tier-1 アーティファクトがなければ、説得力のある Tier-2 ソースでさえ文脈にとどまります——理解には価値がありますが、検証には不十分です。
何が数えられないか
エビデンスのように見えても、稼働中の AI component を示さないアーティファクトもあります。一般的な誤シグナルには、マーケティング文面、空のリポジトリ、方法論のないメトリクス、独自ロジックのない API ラッパーがあります。詳細なリストは、AI のエビデンスとみなされないものを参照してください。
DecAIHub はどう AI エビデンスを記録するか：フラグ AI_0 から AI_4
AI reality 軸は、どんなエビデンスが見つかったかを捉えるために五つの二値フラグを使います：
| フラグ | 何をチェックするか | 値 |
|---|---|---|
| AI_0 | 少なくとも Tier-1 の AI 意図の宣言（ロードマップ、公式アップデート）があるか | 1 / 0 |
| AI_1 | AI が何をするかの記述があるか | 1 / 0 |
| AI_2 | デモや稼働する例があるか | 1 / 0 |
| AI_3 | 文脈を伴う品質メトリクス（何を、どのデータで、いつ）があるか | 1 / 0 |
| AI_4 | 技術的な記述、アーキテクチャ、モデルバージョンがあるか | 1 / 0 |
1 になるフラグが多いほど ai_score が高くなり、プロジェクトの DecAI Fit が良くなります。どのフラグも設定されていなければ ai_score = 0 となり、DecAI Fit は 0 を超えられません。
フラグの組み合わせが信頼度にどうマップするか
個々のフラグは狭い問いに答えますが、その組み合わせがより完全な像を描きます：
| 設定されたフラグ | 典型的な解釈 |
|---|---|
| AI_0 のみ | 意図は宣言された。稼働する AI はまだ未検証 |
| AI_0 + AI_1 | AI が言葉で記述された。デモ、メトリクス、アーキテクチャはなし |
| AI_0 + AI_1 + AI_2 | 稼働するデモが存在。メトリクスや技術的な深さはまだなし |
| AI_0 + AI_1 + AI_2 + AI_4 | デモとアーキテクチャはある。品質の測定が欠けている |
| 五つすべて（AI_0 から AI_4） | 最も強いエビデンスプロファイル：意図、記述、デモ、メトリクス、アーキテクチャ |
プロジェクトはゼロでない ai_score を得るために五つすべてのフラグを満たす必要はありません。AI_0 単独（Tier-1 ソースを伴う意図）でも ai_score = 1 になります。ただし、より高いフラグは DecAI Fit のより高い上限に寄与します。
なぜメトリクスに方法論が重要か
単独の数値——「95% の精度」「低レイテンシ」「最先端」——は文脈なしにはエビデンスではありません。DecAIHub は、四つの問いに答えるときにのみメトリクスを意味あるものとみなします：何が測定されたか（精度、F1、レイテンシ、パープレキシティ）、どのデータで（公開ベンチマーク、独自のテストセット、本番トラフィック）、いつ（評価の日付）、そしてどのバージョンのモデルがその結果を生んだか。これらがなければ、メトリクスはエビデンスではなく主張です。
四つの問いのテスト
公開されたメトリクスを評価するときは、次のチェックリストを適用してください：
- 何を — メトリクスは名指しされ定義されているか。「精度」は曖昧です。「top-1 分類精度」は具体的です。
- どのデータで — 評価データセットは同定されているか。公開ベンチマークは独立した再現を許します。独自のテストセットは許しませんが、それを名指しすることは沈黙よりは良いです。
- いつ — 日付やリリースタグはあるか。モデルは時とともに変わります。タイムスタンプのないメトリクスは現在のシステムを反映しないかもしれません。
- どのバージョン — モデルやシステムのバージョンは明示されているか。プロジェクトが複数のモデルの反復を出荷しているなら、メトリクスは特定の一つに結びつけられねばなりません。
これら四つのいずれかが欠ければ、DecAIHub の評価ではメトリクスは「エビデンス」から「主張」へと格下げされます。それは記載された主張としてプロジェクトカードに現れるかもしれませんが、AI_3 フラグを 1 に設定することには寄与しません。
このチェックリストの使い方
プロジェクトカードを読むときは、Evidence 表が上記の Tier-1 リストのアーティファクトを参照しているかをチェックしてください。カードが ai_score = 0 を示すか、AI-washing の懸念にフラグを立てている場合、それは検証日時点でこれらのアーティファクトが見つからなかったことを意味します——これはプロジェクトへの非難ではありません。
新しい Tier-1 アーティファクトが現れれば、カードは更新され、スコアが変わり得ます。
読者のための実践的なステップ
- Evidence 表から始める。 リポジトリ、ドキュメント、デモへのリンクを探してください。Evidence 表が空、または Tier-2/3 のソースしか参照していないなら、AI reality の主張は未検証です。
- アーティファクトまでクリックして辿る。 リポジトリのリンクは、その中身次第です。開いて、README やデプロイスクリプトだけでなく AI/ML コードを探してください。
- 検証日を確認する。 エビデンスはスナップショットです。半年前に検証されたカードはプロジェクトの現状を反映しないかもしれません。だからこそ DecAIHub は 550 日を過ぎると古さのペナルティを適用します。
- アンチパターンのリストと相互参照する。 AI のエビデンスとみなされないもののパターンが見られるなら、それに応じてエビデンスを重み付けしてください。
このチェックリストだけでは証明されないこと
- すべてのエビデンス基準を満たしても、AI が高品質である、あるいはエンドユーザーにとって有用であることは 証明されません。それはアーティファクトが存在し検査できることを証明します。
- プロジェクト自身からの Tier-1 エビデンスは、独立性を 証明しません。自己報告のデータは理想的にはサードパーティ評価によって裏付けられるべきです。
- 完全なエビデンスの記録は、トークンが必要であることを 証明しません。AI reality は DecAI Fit の一つの軸であり、token necessity は別の軸です。
よくある質問
crypto プロジェクトにおける AI の最も完全なエビデンスとは何ですか？
意味のあるコミット履歴を伴う AI/ML コードを含む公開リポジトリと、完全な方法論（何が、どのデータで、いつ、どのモデルバージョンで測定されたか）を含む公開された品質メトリクスの組み合わせです。この両方が存在し、稼働するデモや API エンドポイントに支えられているとき、エビデンスのプロファイルは最も完全になります。単一のアーティファクトがそれ自体で決定的なわけではありません——コード、メトリクス、テスト可能な出力の組み合わせこそが、検証済みの AI を未検証の主張から区別します。
プロジェクトはオープンソースのコードなしに本物の AI を持てますか？
はい。オープンソースのコードは最も透明なエビデンスの形ですが、唯一のものではありません。プロジェクトは、詳細な技術文書、方法論を伴う公開ベンチマーク、検証可能な AI 駆動の出力を返す稼働 API、または独立したサードパーティ評価を通じて AI を示せます。しかし、少なくとも何らかの検査可能なアーティファクト——コード、デモ、評価——がなければ、DecAIHub（や他の誰か）が検証するものは何もありません。プロジェクトが閉じているほど、信頼を築くために Tier-2 の裏付け（インタビュー、アグリゲータのデータ、カンファレンスのデモ）に依存することになります。
稼働するデモは AI が本物であることを証明しますか？
稼働するデモは強いエビデンスですが、それ自体では決定的な証明ではありません。よく設計されたフロントエンドは、ハードコードされた応答、事前計算された結果、サードパーティ API への隠れた呼び出しを使って AI らしい挙動を模倣できます。DecAIHub は、API ドキュメント、モデルバージョン識別子、または異なる入力にわたる再現可能な出力を伴うときに、デモをより強いエビデンスとして扱います。任意のユーザー入力を受け取り、多様で文脈的に適切な出力を返すデモは、あらかじめ定められた例を持つ案内付きのショーケースよりも説得力があります。
ゼロでない ai_score に必要な最小限のエビデンスは何ですか？
最小限は Tier-1 の AI 意図の宣言——AI 関連の計画を明示的に述べるロードマップの項目、公式ブログ記事、ドキュメントページ——です。これは AI_0 フラグを 1 に設定し、ai_score = 1 を生みます。これは可能な最低のゼロでないスコアですが、AI の方向性に公式にコミットしたプロジェクトを、AI にまったく言及していないプロジェクトから区別します。より高いスコアに到達するには、プロジェクトは追加のアーティファクトを提供する必要があります：AI component の記述（AI_1）、デモ（AI_2）、方法論を伴うメトリクス（AI_3）、技術的なアーキテクチャの詳細（AI_4）。
外部リンク
- CommonMark specification — プロジェクトカードや explainer を含む、すべての DecAIHub wiki ページで使われるマークアップ標準。
- Model Cards for Model Reporting (Mitchell et al., 2019) — AI モデルの性能、意図された用途、限界を文書化するための基礎的なフレームワーク。DecAIHub のエビデンス基準の背後にある透明性の原則と密接に整合する。
- NIST AI Risk Management Framework — AI リスクを特定し管理するための米国政府のフレームワーク。ドキュメント化、テスト、評価方法論に関するガイダンスを含む。
No comments to display
No comments to display