はじめに
情報の「形」を覗き見る
前回（第5回）は、私たちがアプリを操作した瞬間からAIが応答を返すまでの、舞台裏での「情報のバトンタッチ」の流れを追いました。ユーザーのリクエストをきっかけに、アプリが必要な 文脈 (Context) 情報を集め、MCPのようなルールに従って整理し、AIモデルへと渡し、AIがそれを処理して応答を返す…
という、目に見えない連携プレーがあるのでしたね。
さて、ここで一つの疑問が湧いてきます。第4回で学んだ様々なコンテキスト情報（会話履歴、ユーザーの好み、場所、時間、アプリの状態など）は、実際にAIに渡されるとき、一体どのような「形」をしているのでしょうか？ アプリが集めた情報が詰め込まれた「バトン」の中身は、どうなっているのでしょう？
今回は、その疑問に答えるべく、 「データ構造」 というものに少しだけ触れてみます。「構造」と聞くと難しく感じるかもしれませんが、心配はいりません。専門知識やコーディングのスキルは一切不要です！
今回は、データ分析などに使われる「Code Interpreter」のようなツール（※）を私たちが持っていると仮定して、そのツールを使って、AIに渡されるコンテキスト情報がどのようなデータ形式で整理されているのか、その具体例を一緒に「覗いてみる」体験をしてみましょう。
（※注：ここでは特定のツール機能そのものではなく、「データの中身や構造を分かりやすく見せてくれるツール」というコンセプトを借りて説明します。実際に何かを操作する必要はありません。）
これまでの抽象的な説明から一歩進んで、情報が持つ具体的な「顔」や「形」を見ることで、AIがどのように情報を扱っているのか、よりリアルなイメージを掴むことができるはずです。今回も、お馴染みの 「地図アプリでカフェを探す」 シナリオを使って、AIが見ているかもしれない情報の「形」を探検してみましょう！
「データ構造」って何？ 情報を整理する「器」
本題に入る前に、「データ構造」という言葉について、簡単にイメージを掴んでおきましょう。
難しく考える必要はありません。「データ構造」とは、文字通り、 データを整理して格納するための「構造」や「形式」、「器」 のことです。情報（データ）を、コンピューター（そしてAI）が効率的に理解し、扱いやすいように、特定のルールに従って並べたり、関連付けたりする方法、と考えてください。
例えるなら…
整理された書類棚: 書類（データ）を、プロジェクト名や日付といった「ラベル」が付いたフォルダ（構造）に入れ、キャビネット（さらに大きな構造）に整理して保管しますよね。これにより、後で必要な書類をすぐに見つけ出すことができます。
レシピ
料理を作るために必要な「材料」とその「分量」、「手順」（構造）がリスト形式で書かれています。この構造があるから、誰でも（ある程度は）同じ料理を再現できます。
名刺ホルダー
名前、会社名、役職、連絡先といった項目（構造）ごとに情報が整理されていて、目的の人を探しやすくなっています。
このように、情報を特定の「構造」に当てはめて整理することで、その情報が持つ意味が明確になり、扱いやすくなります。AIに渡されるコンテキスト情報も、このような「構造化」された形で整理されているのです。
よく使われるデータ構造の考え方に、 「リスト（一覧）」と「キーと値のペア（ラベルと中身の組み合わせ）」 があります。
リスト
情報を順番に並べたもの。「買い物リスト」のように、項目が順番に並んでいるイメージです。
キーと値のペア
各データに「ラベル（キー）」を付けて、その「中身（値）」とセットにする方法。「名前：山田太郎」「年齢：30」のように、何の情報なのかが一目でわかります。
AIに渡されるコンテキスト情報は、特にこの「キーと値のペア」を組み合わせた形式（※）で整理されていることが多いです。
（※補足：専門的にはJSON（ジェイソン）と呼ばれる形式がよく使われますが、ここではその名前は重要ではありません。「ラベルと中身がセットになった情報がたくさん集まっているんだな」というイメージで十分です。）
仮想Code Interpreter体験：コンテキストデータの中身を見てみよう！
お待たせしました！ それでは、仮想的な「Code Interpreter」を使って、第5回で登場した「地図アプリでWi-Fiカフェを探す」シナリオで、アプリからAIへと渡されたかもしれない「コンテキスト情報パッケージ（バトンの中身）」の例を覗いてみましょう。
【状況設定】
ユーザーが地図アプリで「近くのWi-Fiが使えるカフェ」を検索しました。アプリは必要な情報を集め、MCPのルールに従って以下のようなデータパッケージを作成し、AIモデルに送信しました。
【仮想Code Interpreterで表示されたデータ（例）】
JSON
// === AIに渡されたコンテキスト情報パッケージ（簡略化した例） ===
{
// --- (1) ユーザーからの直接のリクエスト ---
"request": {
"type": "search", // リクエストの種類：検索
"query": "カフェ", // 検索キーワード：カフェ
"filters": ["Wi-Fi利用可能", "評価4以上希望"] // 絞り込み条件：Wi-Fiあり、評価4以上希望
},
// --- (2) ユーザーに関するコンテキスト ---
"user_context": {
"profile": { // ユーザープロフィール
"user_id": "user775", // ユーザーを識別するID
"preferences": { // ユーザーの好み設定
"preferred_seating": "quiet", // 好みの席：静か
"likes_brands": ["星乃珈琲店", "ドトール"], // よく利用/好きなブランド
"dislikes_brands": ["Super Coffee Chain Z"], // あまり好まないブランド
"visits_often_area": ["銀座", "日本橋"] // よく訪れるエリア
},
"language": "ja" // 使用言語：日本語
},
"interaction_history": [ // 直近の対話履歴 (最新のものが最後)
{"role": "user", "content": "近くで本屋さんを探して。"},
{"role": "assistant", "content": "承知しました。〇〇書店が現在地から約300mです。"},
{"role": "user", "content": "ありがとう。じゃあ、その近くでWi-Fiが使えて評価の高いカフェはある？"}
]
},
// --- (3) 利用環境に関するコンテキスト ---
"environment_context": {
"location": { // 現在地情報
"latitude": 35.671236, // 緯度
"longitude": 139.767125, // 経度 (例：東京駅付近)
"accuracy_meters": 10, // 位置情報の精度(メートル)
"source": "GPS" // 位置情報の取得元
},
"timestamp": "2025-04-18T11:30:00+09:00", // リクエスト時刻 (日本標準時)
"device": { // 利用デバイス情報
"type": "smartphone", // 種類：スマートフォン
"os": "iOS", // OSの種類
"battery_level": "75%" // バッテリー残量
},
"network": { // ネットワーク状況
"type": "Wi-Fi",
"signal_strength": "strong"
}
},
// --- (4) アプリケーションに関するコンテキスト ---
"application_context": {
"app_name": "Awesome Navi", // アプリ名
"app_version": "4.0.1", // アプリのバージョン
"current_view": "map_main_screen", // 現在表示している画面
"recent_searches_app": ["書店", "レストラン", "公園"], // アプリ内での最近の検索履歴
"settings": { // アプリ固有の設定
"map_style": "standard", // 地図の表示スタイル
"traffic_info_enabled": true // 交通情報の表示：オン
}
}
}
// === ここまで ===
データ構造を読み解く
各情報の意味と役割
どうでしょうか？ 少し複雑に見えるかもしれませんが、一つ一つ見ていくと、第4回で学んだコンテキスト情報の種類が、きちんと「ラベル（キー）」と共に整理されているのが分かるはずです。仮想Code Interpreterが、このように情報を分かりやすく表示してくれたと想像してください。
(1) request（リクエスト）
ユーザーが直接行った操作や要求内容です。
"query": "カフェ" で何を検索したいか、"filters": [...] でどんな条件（Wi-Fi、評価）を付けているかが明確に分かります。これがAIの処理の「核」となります。
(2) user_context（ユーザーコンテキスト）
ユーザー自身に関する情報がまとめられています。
profile の中の preferences には、「静かな席が好き」「このブランドが好き/嫌い」「よく行くエリア」といった好みが入っており、AIがパーソナライズされた提案をするのに役立ちます。例えば、dislikes_brands にあるチェーン店を除外したり、visits_often_area にあるエリアのカフェを優先したりできます。
interaction_history には、直前の会話の流れが記録されています。「本屋さんを探した」後に「その近くでカフェを」と言っているので、AIは単に現在地の近くではなく、「〇〇書店の近く」という文脈を理解してカフェを探すことができます。role で誰の発言（user/assistant）かも区別されています。
(3) environment_context（環境コンテキスト）
ユーザーが今いる場所や時間、使っているデバイスに関する情報です。
location の緯度経度は「近くの」カフェを探す上で最も重要です。accuracy_meters で位置情報の精度も分かります。
timestamp でリクエストされた時刻が分かるので、AIは「現在営業中のカフェ」を絞り込めます。
device 情報は、例えばスマートフォンの小さな画面に適した表示を返す、といった調整に使えるかもしれません。battery_level も、場合によっては省電力モードの提案などに繋がるかもしれません。
(4) application_context（アプリケーションコンテキスト）
利用中のアプリ固有の情報です。
recent_searches_app で、ユーザーがこのアプリ内で最近「書店」や「公園」も探していたことが分かり、関連性の高い提案（例：「公園が見えるカフェ」など）のヒントになるかもしれません。
settings の traffic_info_enabled が true なので、もしカフェまでのルート案内を提案するなら、交通情報を考慮した所要時間を提示すべきだとAIは判断できます。
なぜ、このような「構造」がAIにとって重要なのか？
この例のように情報が構造化されていることには、AIが効率よく、かつ的確に処理を行う上で、大きなメリットがあります。
意味の明確化
"latitude" というキー（ラベル）があれば、その値が「緯度」であることは一目瞭然です。単に数字が並んでいるだけでは、AIは何の情報か判断できません。明確なラベル付けが、データの意味を正確に伝えます。
網羅性と整理: 関連する情報がグループ化（例: location の中に緯度・経度・精度）されているため、AIは必要な情報をまとめて把握できます。ユーザー情報、環境情報、アプリ情報といったカテゴリー分けも、情報の全体像を掴むのに役立ちます。
処理の効率化
AIは、「environment_context の中の location の中の latitude」といった形で、必要な情報にピンポイントでアクセスできます。構造化されていない大量のテキストデータから探し出すよりも、はるかに高速かつ効率的に処理を進められます。
一貫性と再利用性
MCPのような共通のルール（プロトコル）に基づいてデータ構造を定義しておけば、異なるアプリやサービス間でも、同じAIモデルに対して一貫した形式で情報を渡すことができます。これにより、AIモデルの再利用性が高まり、開発効率も向上します。
Code Interpreterなら、さらに何ができる？（イメージ）
今回は、構造化されたデータを「見る」体験をシミュレートしました。実際のCode Interpreterのようなツールは、さらに進んで、このデータを分析したり、可視化したりすることも可能です（通常は開発者やデータ分析者が利用します）。
例えば（あくまでイメージです）
interaction_history の対話回数をカウントする。
location の緯度経度を地図上にプロットする。
preferences の likes_brands と dislikes_brands を比較して、ユーザーのブランド嗜好を要約する。
timestamp から曜日や時間帯のパターンを分析する（もし履歴が大量にあれば）。
このように、データを構造化して持つことで、単にAIの応答生成に使うだけでなく、様々な分析や洞察を得ることも可能になるのです。
まとめ
AIが見ている情報の「顔」
今回は、仮想的なCode Interpreter体験を通じて、AIに渡されるコンテキスト情報が、実際には「キーと値のペア」などを使って構造化されたデータとして整理されていること、そしてその「形」の一例を覗いてみました。
コンテキスト情報は、AIが理解しやすいように構造化されている。
キー（ラベル）と値（中身）のペアなどが使われ、情報が整理されている。
構造化により、情報の意味が明確になり、AIは効率的かつ正確に処理できる。
今回見たのは簡略化した一例だが、AIが「データ」を扱っているという具体的なイメージが掴めたはず。
AIがまるで魔法のように私たちの意図を汲み取ってくれる背景には、このように地道に情報を収集し、整理し、構造化されたデータとしてAIに渡す、というプロセスが存在します。決して魔法ではなく、よく設計された情報の連携プレーなのです。
この情報の「形」を少しでもイメージできたことで、AIという存在が、より具体的で理解可能なものに感じられるようになったのではないでしょうか。
次回予告
さて、コンテキスト情報がこのように構造化されてAIに渡されることの重要性が分かりました。では、なぜ個々のアプリやサービスがバラバラの形式を使うのではなく、MCPのような 「共通のルール（標準プロトコル）」 を持つことが、これからのAI活用において大切になってくるのでしょうか？
次回、第7回「なぜ「みんなのルール」が必要なの？ MCPの「標準化」が目指すこと」では、標準化がもたらすメリットや、それが私たちのサービス利用体験にどう繋がっていくのかについて、解説していきます。お楽しみに！