AI component と use case
注：この文書は英語の原文からの自動翻訳です。
AI component と use case
DecAIHub の各プロジェクトカードには、似ているようで異なる問いに答える二つのフィールドがあります：AI component と Use case です。前者はプロジェクト内部の具体的な技術を表し、後者はそのプロジェクトがユーザーのために何をするかを表します。両者を混同すると、AI が本物かどうか、製品が本当の問題を解決しているかどうかを評価しづらくなります。
要約： AI component はシステム内部で AI が何をするか です。Use case は製品から ユーザーが何を得るか です。あるプロジェクトは強力な use case を持ちながら本物の AI component を持たないことも——あるいはその逆も——あり得ます。
「AI component」の意味
プロジェクトカードの AI component（ai_component）フィールドは、次の問いに答えます：このプロジェクトの内部で具体的にどの AI 技術が動いているのか？ それはマーケティング上の説明ではなく、メカニズム——推論、トレーニング、分析、データラベリング、エージェントのオーケストレーション、コンピュート routing——を指し示します。
実際の DecAIHub カードからの例：
AI agent platform (workflows/tools/KB)— ツールとナレッジベースを備えたエージェントフレームワークAI/ML crypto market analytics (app)— 市場データを分析する機械学習モデルAI data labeling + model evaluation (human experts)— human-in-the-loop を備えたラベリングパイプラインcompute orchestration— AI コンピュートジョブのスケジューリングと分散agentic framework (memory/actions/plugins)— メモリとツール統合を備えたエージェントランタイム
AI component は、製品のブランドやマーケティングの主張に関わらず、実際にどのような AI の処理が行われているかを教えてくれます。
このフィールドの使い方： メカニズムを名指しする名詞——モデル、パイプライン、オーケストレーター、評価器——を探してください。その記述がスローガンのように読めるなら、エビデンスセクションと相互確認してください。強いカードは多くの場合、具体的なコンポーネント文字列を、再現可能なアーティファクトや公開された技術的説明と組み合わせています。
「Use case」の意味
Use case（use_case）フィールドは別の問いに答えます：ユーザーはこの製品で何をするのか？ それは、内部で AI がどのように実装されているかに関わらず、プロジェクトが果たす仕事——トレーディング分析、コンピュートマーケットプレイス、エージェントビルダー、データ注釈マーケットプレイス——を表します。
例：
AI trading terminal + no-code agent buildercompute marketplace + orchestrationdata labeling marketplace + dataset tradingbuild + run autonomous AI agentscrypto intelligence for humans + AI agents
Use case は、内部で AI がどのように動くかではなく、なぜ誰かがこの製品を使うのかを教えてくれます。
このフィールドの使い方： 記述された仕事が現代の AI なしで（たとえば静的なダッシュボードとして）存在し得るかを問うてください。もし存在し得るなら、AI component の行が差別化要因となります——技術的に自明でないものを名指しているはずです。
なぜ両者は異なり、なぜ両方が重要か
あるプロジェクトは compute orchestration（AI component）によって動く compute marketplace（use case）を提供しているかもしれません。別のプロジェクトは AI trading terminal（use case）を謳いながら、その AI component は positioning only (plans/roadmap)——つまりまだ確認された稼働中の AI が存在しない——かもしれません。
カードを読むとき、この二つのフィールドを比較すると、製品の約束が技術的な実態と一致しているかどうかが見えてきます：
- 強い AI component + 明確な use case — 技術も製品も両方が見える。
- 弱い、または存在しない AI component + 大胆な use case — マーケティングと実態のあいだにギャップがある可能性。
- 強い AI component + 曖昧な use case — 技術は存在するが製品のストーリーが不明瞭。
両フィールドはともに DecAI Fit スコアに反映されます。高いスコアには、本物の AI のエビデンス（AI component）と 意味のあるオンチェーン統合の両方が必要です——魅力的な製品ナラティブだけでは足りません。
カテゴリと相互確認： 複合 AI カテゴリは方向性とドメインを要約し、AI component と use case は細部にズームインします。AI/Agents | Infra のようなラベルは、精密なコンポーネント文字列の代わりにはなりません——それはブラウジングのためにプロジェクトを位置づけるものです。
特殊な値の読み方
一部のカードには、技術でも use case でもなく、解釈モードである値が含まれます——それらは検証日時点でどれだけのエビデンスが見つかったかを示します。
| 値 | 意味 |
|---|---|
positioning only (...) |
AI はマーケティングや計画で言及されているが、稼働中の AI component の Tier-1 エビデンスは見つかっていない。括弧内は文脈を示す（例：(plans/roadmap) や (meme/narrative)）。 |
none |
AI component も use case も検出されていない。これは恒久的な判定ではなく、検証日時点の状態を反映する。 |
unknown |
評価者が利用可能なソースから値を判断できなかった。Tier-1、Tier-2、Tier-3 のいずれのデータも見つからなかった。 |
これらは独立した技術ではなく、フィールドの解釈モードです。基盤となる技術についてではなく、エビデンスの状態について教えてくれます。positioning only という値はプロジェクトへの非難ではありません——マーケティング上の主張と Tier-1 アーティファクトのあいだのギャップがまだ埋まっていないことを意味します。この原則の詳細は、なぜエビデンスの不在は技術の不在ではないのかを参照してください。
DecAIHub のプロジェクトカードのどこに現れるか
どちらのフィールドも Project Passport の表にあります。次を探してください：
- AI component (ai_component) — 技術的なメカニズム
- Use case (use_case) — 製品レベルの説明
これらのフィールドは、AI thesis fitセクションや Evidence 表とともに、マーケティングと検証可能な主張を切り分けるのに役立ちます。
これらの用語だけでは証明されないこと
- 具体的な AI component を列挙していても、それが実際に機能していることは 証明されません。コンポーネントの記述は評価者が見つけたものを反映しますが、エビデンスの深さはさまざまです。
- 明確な use case があっても、製品がそれを実現していることは 証明されません。Use case はプロジェクトが提供すると主張する内容であり、性能の保証ではありません。
- AI component + use case の組み合わせは、トークンが必要であることを 証明しません。Token necessityは DecAI Fit の別の軸です。
混同しないでください
- Category は AI component や use case と同じではありません。Category（例：
AI/Agents | DeFi）はプロジェクトを高いレベルで分類し、AI component と use case はそれを詳細に記述します。 - AI component は製品の説明ではありません。 それはより狭く、機能セット全体ではなく AI のメカニズムだけを指します。
- Use case は財務予測ではありません。 それは製品が何をするかを記述するものであり、使う価値があるかどうかではありません。
よくある質問
同じ語句が両方のフィールドに現れることはありますか？
ときにはありますが、意味は異なるべきです。製品が狭い場合（たとえば純粋な推論 API）、短いラベルがフィールドをまたいで重なることがあります。そのような場合、カードの他の部分——ベンチマーク、アーキテクチャの注記、エビデンス——が詳細を担います。
どちらのフィールドを先に読むべきですか？
ソフトウェアがユーザーのために何をするか を重視するなら、use case から始め、次に AI component で検証してください。モデルやエージェントが存在するか を重視するなら、AI component から始め、次に use case が誰のためになるかを説明しているかを確認してください。
これは automation と real AI とどう関係しますか？
Use case はルールやスクリプトで満たされ得ます。一方 AI component は、プロジェクトがそう主張する場合、学習ベースまたはモデルベースのメカニズムを名指しすべきです。「AI」のマーケティングと非学習型スタックのあいだの不一致は、検証における一般的なテーマです。
外部リンク
- NIST — Artificial Intelligence Resource Center — 日常的な語（「model」「inference」「training」）を標準志向の文脈における技術的用法と整合させる定義とガイダンス。
- Partnership on AI — resources — 組織が AI の能力や影響をどう記述するかに関する研究とガイダンス。
No comments to display
No comments to display