AI時代のトリセツ設計:AIは情報の「意味」を理解できるか?

通算 第59号:製品利用者に正確な情報を届けるために(2)

<この記事のポイント>
 「CPUの交換手順」と「メモリの交換手順」。テキストだけ見ればそっくりなこの二つを、AIは正しく見分けられるのでしょうか?
 AIが「似て非なる情報」を混同するのを防ぎ、正確な回答を導き出す鍵となるのが、テキストの外側にある「意味(メタデータ)」です。本記事では、実際のトリセツを使った3つの実験を通じて、その効果と具体的な実装方法を検証します。

目次

1.はじめに:カードの山と「スープ缶」のラベル

1.1 「カード化」の次にくる課題

 前回の記事では、AI時代の情報設計における指針として、AIが文脈の罠に陥り情報を「創作」してしまうのを防ぐため、情報を自己完結した「カード型モデル(AI対応トリセツ)」として設計する必要がある、という結論に至りました。
 ここで一つ、巨大な課題が立ちはだかります。「理屈は分かったが、既存の膨大な『書籍型』マニュアルを、誰がどうやって『カード型』に作り変えるのか?」と。すべてを手作業で行うことは非現実的です。もしかすると、「AIが賢いなら、そのままで公開し、質問が来るたびにAIに既存のマニュアルを読ませて回答を抽出させれば良いのでは?」と思いたくなります。
 しかし、トリセツのように極めて高い正確性が求められる情報において、毎回AIの「都度解釈」に頼るのはリスクが伴います。トリセツは、日々内容が変わる動的な情報というよりも、製品と共に提供するどちらかと言えば静的な情報です。であるならば、あらかじめAIを使ってカード化(チャンク化)し、人間が内容を確認した上で公開する。このプロセスこそが、品質担保の観点から合理的なのかもしれません。

 この既存資産をどう安全・効率的にカード化するかという作る側のプロセス変革については、非常に大きなテーマですので、今後の連載で改めて取り上げる予定です。ただ、今回の記事で紹介する「AIによる情報抽出技術」は、まさにその 「自動切り出し作業」に応用できる可能性 を秘めています。ぜひ、そのような視点でも読み進めてみてください。

 さて、トリセツに記載している内容を意味の塊ごとに、情報のデータベースとして切り分けできたとします。すると今度は膨大な数のカードが出来上がることになります。AIは、このカードの山から、ユーザーが今まさに必要としているたった一枚の正解を、間違いなく選び出せるのでしょうか?今回は、データの整理ができた次の段階、ユーザーが求める情報を正しく届けられるのか?という課題に取り組みます。

1.2 「似て非なる情報」の罠

 情報をカードに切り分けたとしても、それで終わりではありません。トリセツの中には、似て非なるカードが山のように存在します。例えば、「CPUの交換手順」と「メモリの交換手順」。 どちらも「ケースを開ける」 「部品を取り外す」といった記述が並び、テキスト(中身)だけを見ても、AIにとってはその違いが非常に曖昧です。このままでは、AIはまたしても情報を混同し、間違った回答をしてしまうかもしれません。

1.3 中身を読まずに、中身を知る

 スーパーマーケットに並ぶ スープの缶詰を想像してみます。 私たちは、中身が「トマトスープ」なのか「コーンポタージュ」なのかを知るために、いちいち缶を開けて味見をしたりはしません。 缶の外側に貼られたパッケージラベル(成分表)を見れば、開けなくても一目瞭然だからです。
 AI対応トリセツも同じです。 AIに毎回すべてのカードの「中身」を読ませて(味見させて)推測させる方法は、非効率なだけでなく、認識ミス(味の見誤り)の原因にもなります。万が一、AIがアレルギー成分を見落としたら大変なことになります。
 そうではなく、カードの外側に「これはCPUの手順」、「 これは安全情報」という正確な 「ラベル(メタデータ)」 を貼っておく。そうすれば、AIは中身を読まずとも、必要なカードを瞬時に、かつ100%の正確さで選び出すことができます。

 今回のテーマは、この「ラベル付け」の技術です。 これは単なる事務作業ではありません。AIに情報の「意味」を教え、膨大な情報の中から正解にたどり着くための地図を与える、情報設計(アーキテクチャ)の核心に迫るものです。記述する情報の品質基準や、ラベルの書き方について、国際規格を手がかりに、AIとの新しいコミュニケーション方法を探求していきます。

【補足情報】
▼検証資料について 本記事の検証に使用した生成AIで読み込んだ入力資料など、資料編ページに掲載しております。ご自身で実際に試される際にご活用ください。(資料編ページはこちらへ
▼使用した生成AIについて 検証にはGoogle Geminiを使用しています。(Geminiのページはこちらへ) 

2.チャレンジ2:AIは情報の「意味」を理解できるか?

 前回記事で、情報を「カード」化することに着手しました。しかし、カードの枚数が増えるにつれて、新たな、そしてより厄介な問題が浮上します。それが 「似て非なる情報の罠」 です。

2.1 テキストだけでは区別がつかない?

 トリセツには、手順や構成が非常によく似たトピックが頻繁に登場します。 例えば、デスクトップPCのメンテナンスマニュアルにある、以下の2つのカードを見てみます。

【カードA:CPUの交換】

  1. PCの電源を切り、ケーブル類を全て外します。
  2. ケース背面のネジを回し、サイドパネルを取り外します。
  3. メインボード上のソケットのレバーを押し下げ、ロックを解除します。
  4. 旧部品を垂直に持ち上げて取り外します。

【カードB:メモリの交換】

  1. PCの電源を切り、ケーブル類を全て外します。
  2. ケース背面のネジを回し、サイドパネルを取り外します。
  3. メインボード上のスロットの両端にあるクリップを押し下げ、ロックを解除します。
  4. 旧部品を垂直に持ち上げて取り外します。

 ステップ1と2は全く同じです。ステップ3以降も、「メインボード」 「ロック解除」 「取り外し」といったキーワードが共通しており、テキストの構造(見た目)はそっくりです。

2.2 AIが陥る「識別の迷路」

 この状態で、ユーザーがAIに 「メインボードの部品を交換したいんだけど」 と、少し曖昧な質問をしたとします。ラベル(メタデータ)を持たないカード情報をAIは、テキストの中身だけを頼りに答えを探します。しかし、カードAもカードBも、テキスト上はどちらもメインボードの部品交換に見えてしまいます。
 その結果、AIはどうするのか想像してみます。

  • あてずっぽう: 文脈を無視して、どちらか一方(例えばCPU)だけを提示してしまう。
  • 混乱(ハルシネーション): 両方の情報を混ぜ合わせ、「レバーを押し下げて(CPUの手順)、クリップを外す(メモリの手順)」という、現実には存在しない危険な手順を創作してしまう。

 このようなことが想像されます。テキスト(中身)だけに頼る検索にはリスクがありそうです。

2.3 解決の鍵:2つの「共通言語」

 この問題を解決するには、AIに「これはCPU」 「これはメモリ」という明確な意味(Identity) を伝える必要があります。そのために、2つの強力なツール(規格)を活用します。

1. カードの品質を高める「JIS X 0153」
 まず、カードの中身(テキスト)自体を、誰が読んでも(AIが読んでも)誤解のないように書く必要があります。JIS X 0153 は、情報の分かりやすさや正確さを担保するための品質基準です。今回は詳細を割愛しますが、この基準も重要な要素です。(資料1-1:JIS X 0153 概要

2. カードに名札を付ける「IEC PAS 63485(iiRDS)」
 そして、カードの外側に付ける「ラベル」の書き方の国際標準が IEC PAS 63485 です。「製品のバリエーションは何か?」 「情報の種類(手順か、故障診断か)は何か?」といった属性を、AIが理解できる共通の形式で記述します。(資料1-2:IEC PAS 63485(iiRDS )概要

3.実験:AIに「意味」を教える — メタデータの効果検証

 第2章で見てきたように、トリセツの中には、テキスト(文字情報)だけでは区別が難しい似て非なる情報が存在します。AIに正確な情報を提供させるためには、テキストの外側にある「意味(メタデータ)」を理解させることが不可欠です。
 ここで行う実験では、実際に「似て非なるカード」を用意し、AIに与える条件を変えながら、その応答がどのように変化するかを検証します。実験は以下の3つのステップで進めます。

  1. 実験1(現状把握): メタデータがない状態で、AIは「似て非なる情報」をどう扱うか?
  2. 実験2(解決策の準備): AIを使って正確なメタデータを付与できるか?
  3. 実験3(効果検証): メタデータがある状態で、AIの応答はどう変わるか?

 これらの実験を通じて、メタデータがAIの「知性」に与える劇的な効果と、その実装の現実性を明らかにします。

<見出し目次>

3.1 実験1:AIは「似て非なる情報」を見分けられるか?

 第2章で触れた似て非なる情報の罠。これをAIはどう処理するのか、実際に検証してみます。

1) 実験の準備: よく見ないと違いがわからない2つのカード
 用意したのは、デスクトップPCのメンテナンスマニュアルから切り出した、以下の2つのカードです。

 これらは、どちらも「電源を切る」 「カバーを開ける」から始まり、核心部分も「固定具を外して、垂直に抜く」という構造が共通しています。テキスト(文字情報)だけを見れば、パット見、そっくりです。

2)実験の実施:メタデータなしでの挑戦
 この2つのカードだけを知識として持ったAIに対し、ユーザー(初心者)になりきって、あえて曖昧な質問を投げかけてみます。

【プロンプト(要点)】

「X-100のメインボードの部品を交換したいのですが、ロックの外し方を教えてください。」

資料3-1:実験1 – プロンプト(全文)

 この質問には「CPU」とも「メモリ」とも書かれていません。AIは、テキストのわずかな違いだけを頼りに、この難問に答えなければなりません。

【AIの回答(結果サマリ)】

取扱説明書データベースによると、メインボード上の交換部品によってロックの外し方が異なります。

1. メインボード「中央」のユニットを交換する場合 ロックの外し方:固定レバーを押し下げ、フックから外してロックを解除します。
2. メインボード「右側」のモジュールを交換する場合 ロックの外し方:固定クリップ(両端)を押し下げ、ロックを解除します。
お客様が交換されようとしているのは、どちらの部品になりますでしょうか?

資料3-2:実験1 – 結果(全文)

3)結果の評価:この結果でよいのか?
 このAIの振る舞いを、どう評価すべきでしょうか。

良かった点:
 AIは、テキスト内のわずかな違い( 「中央」と「右側」、「ユニット」と「モジュール」 )を読み取り、ハルシネーションを起こすことなく「2つの可能性がある」と判断しました。これは、大規模言語モデルが持つ基本的なテキスト読解能力と言えそうです。

■足りない点:
 しかし、ユーザー体験としては不十分です。なぜなら、AIは 「それが何の部品か(CPUかメモリか)」を理解していないからです。AIは「中央のやつですか? 右側のやつですか?」と、物理的な特徴でしか問い返せません。 ユーザーは、目の前の基板を見て、自分が交換したい部品が「中央」なのか「右側」なのかを自力で判断しなければなりません。もし基板が部品だらけだったら? 初心者は途方に暮れてしまうでしょう。

4)結論: 「物理」から「意味」へ
 テキスト(中身)だけを読ませるアプローチでは、AIは「形や場所の違い」までは分かっても、それが何であるかという 「意味」 まではたどり着けません。期待する回答とは、AIが 「CPUの交換ですか? それともメモリの交換ですか?」 と、明確な 「名前(意味)」 で問い返してくれることです。
 そのためには、カードに「意味」を与えるメタデータが不可欠です。 次のセクションでは、AIに「意味」を教える実験に挑みます。しかも、そのタグ付け作業さえも、AI自身の力を借りて行ってみます。

3.2 実験2:AIを使って正確なメタデータを付与できるか?

 「カードA」と「カードB」に対し、AIにiiRDS(国際規格)の考え方に基づいたメタデータを自動で抽出・付与させてみます。

1) 実験の準備:AIへの指示(プロンプト)
 AIに「情報アーキテクト」の役割を与え、以下のシンプルなルールで分類を依頼します。

【プロンプト(サマリ)】

あなたは、技術ドキュメントの構造化を専門とする「情報アーキテクト」です。
以下の2つの「情報カード(テキスト)」の内容を解析し、それぞれのカードに適切な「メタデータ」を付与してJSON形式で出力してください。

■付与すべきメタデータの定義(iiRDS参考):
1. InformationType(情報の種類): 手順(Instruction)、説明(Description)、トラブルシューティング(Troubleshooting)などから選択
2. ProductVariant(対象製品): 製品名を抽出
3. Component(対象部品): 作業の対象となっている具体的な部品名を抽出
…(略)…

資料4-1:実験2 – プロンプト(全文)

2) 実験結果:AIが生み出した「構造化データ」
 プロンプトを実行すると、AIは一瞬でテキストを解析し、私たちが普段Excelなどで管理している「属性表」のようなデータを、システムが理解できる形式で出力しました。

「属性管理表(左)」が、AIによってシステムが直接読める「JSON形式(右)」に自動変換されるイメージ)

図1:Excel属性表とJSON形式の対比

 AIが出力したのは、JSON(ジェイソン) と呼ばれるデータ形式です。一見するとプログラムのコードのようで身構えてしまうかもしれませんが、中身は皆様がよく知る「項目名」と「値」のペアが並んでいるだけの、単なる 「データの整理箱」 です。

※技術的な補足:
本来のiiRDS規格では、メタデータはRDFという、より高度な形式で記述され、厳密な定義(オントロジー)を持ちます。本記事では、AIへの指示のしやすさと分かりやすさを優先し、その概念をJSON形式で簡易的に再現しています。

【AIの出力結果(抜粋)】

[
 {
  ”Title”: “製品X-100 CPUユニットの交換手順”,
  ”Metadata”: {
   ”InformationType”: “Instruction”,
   ”Component”: “CPUユニット” ←★ ここが自動抽出された!
  }
 } 
 …
]

資料4-2:実験2 – 結果(全文)

※JSONについての簡単な解説は、資料5:『怖くない!Excel管理表がそのままシステムに入る「JSON」超入門』をご覧ください。

3) 結果の評価
 ご覧ください。AIは本文の文脈を読み取り、Component(部品)という項目に対して、正確に "CPUユニット" という値を記入しています。 これまで「似て非なるテキストの塊」でしかなかった情報が、このタグが付いたことで、システム上で明確に区別できる状態になりました。これが、「スープ缶にラベルが貼られた瞬間」 です。

3.3 実験3:メタデータがある状態で、AIの応答はどう変わるか?

 いよいよ最後の実験です。今度は、AIに 「メタデータ付きのデータベース」 を持たせた状態で、再度あの曖昧な質問を投げかけます。

1)実験の準備:AIに「判断ルール」を与える
 このとき、難しいプログラムを書く必要はありません。AIに対し、「もし質問が曖昧で判断に迷ったら、勝手に推測せず、『Component(部品名)』というタグを見てユーザーに質問しなさい」 といった、たった1行のルールを与えるだけです。
(※実際に使用したプロンプト全文と、AIに読み込ませたJSONデータの中身は、資料6-1:実験3 – プロンプト(全文))を参照ください。

2)実験の結果:劇的に変化した「対話」
 準備が整いました。ユーザー(初心者)として、再びあの質問を投げかけます。「X-100のメインボードの部品を交換したいのですが、ロックの外し方を教えてください。」

 AIの回答は、以下のようになりました。

【AIの回答(全文)】

X-100のサポート担当です。お問い合わせありがとうございます。

ご質問いただいた「メインボードの部品のロックの外し方」についてですが、データベース上の該当部品として以下の2つがあり、それぞれ手順が異なります。

交換をご希望の部品は、以下のどちらでしょうか?
CPUユニット(メインボード中央にある部品)
メモリ・モジュール(メインボード右側にある部品)

対象の部品を教えていただければ、正しい手順をご案内いたします。

3)結果の評価:ついに「会話」が成立した
 実験1と比較し、この挙動をどう評価すべきでしょうか。

評価:満点
 AIは、私たちが期待した通りの完璧な振る舞いを見せました。評価すべきポイントは以下の2点です。

ポイント1: 「意味(ID)」と「物理特徴」を正しく使い分けた
 実験1では、AIはテキストの表面的な違いである「物理的な特徴(中央、右側)」に頼るしかありませんでした。 しかし今回は、「CPUユニット」 「メモリ・モジュール」という固有の名前(意味) を理解した上で、補足情報として「中央にある」「右側にある」という物理特徴を提示しています。 これにより、「部品名を知っている中級者」も、「場所しか分からない初心者」も、両方が迷わず正解に辿り着けるようになりました。メタデータは物理情報を否定するものではなく、それらを確信を持って紐づけるためのアンカー(錨)として機能したのです。

ポイント2: 「安全装置」として機能した
 これが最も重要な点です。実験1のように、AIが「右側の部品ですか?」とユーザーに曖昧な判断を委ねることは、非常に危険です。もしユーザーが誤認して違う部品を取り外せば、故障や事故につながりかねません(PL法上のリスク)。 今回、AIはメタデータという確かな根拠に基づいて「CPUですか? メモリですか?」と明確に問いかけました。これは単に検索が便利になっただけでなく、ユーザーの誤操作を未然に防ぐための強力な安全装置が機能したと言えるでしょう。

【結果の比較まとめ】

項目実験1(メタデータなし)実験3(メタデータあり)
問いかけ方「中央のユニットですか? 右側のモジュールですか?」「CPUユニットですか? メモリ・モジュールですか?」
判断基準テキスト内の物理的な記述(場所・形状)のみメタデータによる意味的な定義(名前)+物理的な記述の補足
ユーザー体験実機を見て場所を確認しなければならない(不安・誤認リスク大自分が交換したい部品名を選ぶだけでよい(確実・安全

4.分析: 「物理」から「意味」への進化

 この3つの実験を通じて、AIの認識能力がどう変化したか、整理します。第1章で「スープ缶」の比喩を持ち出しました。これに当てはめてみます。

 実験1(メタデータなし) の状態は、AIに 「缶を開けて、中身を味見して判断しろ」 と言っているのと同じ状態でした。AIは 「トマトっぽい味がするけど、コーンのような気もする…」 と迷い、結果として「赤いスープですか? 黄色いスープですか?」という曖昧な確認しかできませんでした。
 対して、実験3(メタデータあり) の状態は、「缶のラベル(成分表)を見ろ」 と指示した状態です。AIは中身を一切味見することなく、ラベルに書かれた SoupType: Tomato という文字だけを見て、「これはトマトスープです」と即答できました。
 AIの検索精度を上げるために、AIがもっと賢くなること(モデルの性能向上)を待つ必要はありません。私たちが、AIに 「読むべきラベル(メタデータ)」を用意してあげることで、期待する成果が得られるようになります。

5.考察:「加工」から「設計・承認」 へ ~AI時代のヒトが担うべき役割~

 実験結果は、メタデータの威力を確認できました。しかし、現場をよく知る方ほど、新たな懸念が頭をよぎるかもしれません。
「理屈はわかった。しかし、数千ページあるマニュアル全てに、誰がそんなタグを付けていくんだ? もしかして、私たちの新しい仕事は、来る日も来る日もAIにタグ付けをさせる『タグ付け係』になることなのか?」
もしそうなら、それは悪夢です。しかし、実験2を思い出してください。今回の検証ではタグを一つも手入力していません。

<見出し目次>

5.1 「加工」はAIで

 実験2 でAIに指示したのは、「このテキストを読んで、製品名と部品名を抜き出して」ということだけでした。AIはその指示に従い、一瞬にして正確なメタデータを生成しました。 つまり、「情報を読み取り、タグを付ける」という「加工」の実作業は、もはやヒトが汗をかく仕事ではありません。 それは、AIが最も得意とする領域です。

5.2 ヒトは「設計」と「承認」にフォーカスする

 人手で、カード型データからメタデータの割り振りを一つ一つ行う必要はありませんが、大事な役割があります。情報の設計と成果物の確認という2つの役割です。

役割1:情報の「設計者(アーキテクト)」
 AIに指示を与える前段階、つまり「どのようなラベルがあれば、情報は正しく区別されるか?」を考える役割です。しかし、ゼロからタグの名前や体系を考える必要はありません。 今回利用したiiRDSのような国際標準規格には、製品情報に必要な基本的な語彙(タグのセット)があらかじめ定義されています。
 iiRDSは、使用情報の国際規格であるIEC 82079-1をベースに作られています。そのため、マニュアルに必要な基本的な語彙がすでにあらかじめ定義されており、殆どの場合、それらを自社製品に合わせて『適用(選択)』するだけで対応できます。特殊な独自機能など、足りない部分に対しては、 「拡張(追加)」 できるようになっています。標準を利用することで、設計の負担は大幅に軽減できます。

役割2:AIの成果物の「承認者(品質責任者)」
 これが重要です。AIが出力したタグが正しいか、安全性を担保できているか。それを最終的に確認し、承認する責任は、引き続きヒトが行います。
 ここで、「AIがタグ付けしても、結局ヒトが確認するなら、仕事が増えるだけではないか?」という懸念を持たれるかもしれません。しかし、これはAIが出力した全てのデータをヒトが1件ずつ目視チェックするという意味ではありません。例えば、AIが「自信度90%未満」で出力したものだけをヒトが重点的にチェックしたり、明らかな矛盾(必須タグの欠落など)はシステム側で自動的に弾いたりといった、テクノロジーを活用した効率的な承認フローを構築します。
 重要なのは、ヒトが単純作業員ではなく、「AIの監督者(品質のゲートキーパー)」 としての役割を担うということです。AIの間違いを正すフィードバックのプロセスでAIはだんだんと賢くなり、将来的には承認の手間も減っていきます。これは単純なコスト増ではなく、将来の自動化に向けた必要な投資であり、そもそも製品知識がなければできない高度な品質保証業務です。

AIが自信を持てないデータのみをヒトが重点的にチェックする。全権目視の負担を避けつつ、品質を維持する。

図2:AIによるタグ付け実行と振り分けの効率化

6.まとめ:トリセツは「静的な冊子」から「成長するデータベース」へ

 今回の記事では、「似て非なる情報」の罠を乗り越えるために、情報に「意味(メタデータ)」を与えることの重要性を検証しました。

  • カード化だけでは不十分: テキストが似ていると、AIはまだ迷う。
  • メタデータの威力: 「意味」を知ったAIは、正確に交通整理ができる。
  • 役割の変化: タグ付け(加工)はAIに任せ、ヒトはルール(設計)を作る。

運用で育てながら精度をあげていく

 「設計が重要」とはいえ、最初から完璧なラベル設計をするのは困難かもしれません。AI時代のトリセツは、リリースして終わりの「固定物」ではある必要はありません。リリース時は、仕様に基づいて出荷前に定義可能な必要最小限の 「メタデータ」 でスタートしたとしても、後からも利便性を向上させる手立てがあります。運用が始まれば、ユーザーの検索ログや問い合わせ内容といった 「生きたデータ」 が集まります。

  • 「このカードはよく検索されているから、優先度を上げよう」
  • 「ユーザーは『異音』という言葉で検索しているから、AIにタグを追加させよう」
    このように、トリセツを 「使われるほど賢くなる情報基盤」 と捉えることで、より創造的なサイクルを生み出すことができます。

残された課題: 「Delivery(配信)」から「Discovery(発見)」へ

 AIに、iiRDS(国際規格)を参考にした詳細な「意味(メタデータ)」を教えることで、テキストが酷似していても、AIはそれらを正確に区別し、適切な回答を導き出せるようになりました。これは、トリセツが持つ複雑で専門的な情報を扱う上で、iiRDSのような「専門家の共通言語」が不可欠であることを示しています。
 これで十分としたいところですが、実は、まだ 「足りないこと」 があります。 それは、「外の世界への対応」 です。

 今回の検証で利用したiiRDSの概念は、メーカーのポータルサイトや特定のシステム内で、ユーザーの状況に合わせて正確に情報を 「届ける(Delivery)」 ためには最強のツールです。しかし、その詳細で専門的なタグは、そのままではGoogleのような巨大な検索エンジンの海では通じにくいのです。
 検索エンジンは、まず情報を 「見つける(Discovery)」 ための、もっと広く一般的な、インターネットの「標準語」を求めています。世界中のユーザーに正確な情報を届けるために何をするとよいのでしょうか。

次回予告:Schema.orgで、情報の抽象度を上げる

 情報を「特定の専門領域(Delivery)」だけでなく、「世界中(Discovery)」のユーザーに正しく届けるためには、もう一段階、視座を上げる必要があります。そこで登場するのが、インターネットの世界共通言語である Schema.org です。
 私たちは今、iiRDSによって構造化された、最高品質の情報資産を持っています。詳細な土台(Deliveryの基盤)があるからこそ、それをSchema.orgという「世界の言葉(Discoveryの基盤)」に適切に翻訳(マッピング)し、抽象度を上げて広く発信することが可能になるのです。
 次回は、今回作成した「メタデータ付きカード」を、Googleが理解できるSchema.orgの語彙を使ってマッピングする実験に挑みます。専門性と汎用性がつながったとき、検索結果の画面はどのように変わり、ユーザーの体験はどう進化するのか?
 トリセツの価値を、正しく世界に届けるための挑戦。ぜひ、ご期待ください。

<終わりーAI時代のトリセツ設計:AIは情報の「意味」を理解できるか?>

関連記事のご案内

お問い合わせ

お気軽にお問い合わせください。
※株式会社情報システムエンジニアリングよりご案内させていただきます。

*)セールスに関してご返信はいたしませんので、あらかじめご了承ください。

個人情報の取り扱いについて

  • URLをコピーしました!
目次