# チャプター1 インスタグラムからLINE登録は増えたのに、相談や売上どう繋がったかわからない。 今日はChat GPT-6 Astraを使うコーデックスで、流入、登録、相談、制約を1件ずつ結ぶ1枚票を作ります。 OpenAIは9月3日にGPT-6 Astraを発表しました。 GPT-6 Astraはモデル名。コーデックスはファイルを読んで作業や検査を進める道具です。 今回はコーデックスでモデル表示を確認し、Astraを選べる環境で4つの匿名ログを称号する手順を扱います。 全員のアカウントで今すぐ使えるという意味ではありません。 月末に数字を見ようとすると、媒体ごとに場所が違います。 インスタグラムには投稿の反応、LINEには友達追加、相談はカレンダーやフォーム、売上は決済や代帳。 それぞれの合計は見えても、どの発信が誰の次の一歩を作ったかが繋がりません。 この状態で今月はLINEが増えたからインスタグラムが成功した。 相談が減ったから投稿が弱いと結論を出すのは危険です。 登録は前月の投稿から来たかもしれない。 相談数は予約枠の不足で減ったかもしれない。 売上は紹介や既存顧客から生まれたかもしれない。 僕も数字が一枚に並ぶと理解した気になりやすいです。 綺麗なグラフほど原因まで見えたように感じる。 でも繋がっていない合計を横に置いただけでは動線を説明できません。 分からない部分を埋めるより分からないと残す方が次の計測を良くします。 今日作る一枚は派手なダッシュボードではありません。 PanelReader.csvという表です。 一行を一つの流入または一つの相談経路にし、確認できる接点だけを同じ流入IDで結びます。 個人の名前を並べる顧客名簿にはしません。 コーデックスへ渡す入力は4つです。 公開済みInstagramという投稿とURLと日時、LINE側で確認できる登録経路、相談フォームや予約の匿名ログ、決済台帳の匿名化した制約情報です。 全て同じ期間へ揃え、元データは読み取り専用で扱います。 成果物の例はフローID、コンテンツID、公開日時、登録経路、LINE登録状態、相談状態、制約状態、金額区分、確認元、確認時刻、計測状態、微行です。 個人を特定する名前、電話番号、メールアドレス、DM本文は入れません。 ここで大事な基準があります。 一枚表の価値は全てを埋めることではありません。 ゼロと未計測を分けることです。 確認済みゼロはその期間に対処の出来事がなかった状態です。 未計測はデータを取得できない、識別しが繋がらない、確認が終わっていない状態です。 この2つを同じゼロにすると、計測できていない場所を成果がなかった場所だと誤解します。 例えば、Instagramの投稿からLINE登録が3件あったとします。 登録経路が投稿別に分からなければ、各投稿へ1件ずつ割り振りません。 週全体の登録3件は確認済み、投稿別内訳は未計測です。 合計を守りながら分解できていないことを残します。 相談が2件あり、1件だけLINE登録との対応が確認できたなら、残り1件を人気投稿へ推測で付けません。 1件は対応済み、もう1件はアンマッチドにする。 見栄えが悪くても、この方が次に必要な流入IDが分かります。 流入IDは人を追跡するためではなく、経路を称号するために使います。 投稿やプロフィールのリンクに発信元を区別できるIDを付け、LINE登録や相談フォームでそのIDを受け取れるときだけ結ぶ。 あとから氏名の似ている人を推測で同一人物にしません。 新モデルを試すときほど、最初は5行の小さなサンプルを使います。 わざと重複を1行、対応先のない記録を1行入れておく。 GPT-6アストラがそれを別状態として出し、元の合計を増やさないか人が献残する。 同じ入力とモデル名を残せば、更新後も同じ検査を繰り返せます。 正しく止まったかまで確かめて、対象期間全体へ広げます。 コーデックスへの最初の指示はこうです。 4つの匿名ログを読み、既存の識別詞だけで接点を結ぶ。 氏名や文章の類似から推測結合をしない。 ゼロ、未計測、不一致を別状態にする。 元ファイルを変更しない。外部サービスへ書き込まない。 最初の処理は入力の形を揃えることです。 日付は同じタイムゾーン。 投稿URLは同じ形式。 金額は税込みか税抜きかを固定する。 LINE登録の時刻しかないのに、秒単位で投稿と結ばない。 時刻が近いことは候補であり、証拠ではありません。 次にコンテンツIDとフローIDを分けます。 コンテンツIDはどの投稿や動画か。 フローIDはどの動線を通ったか。 同じ投稿からプロフィール経由とストーリーズ経由があれば、内容は同じでも動線は違います。 逆に複数投稿が同じプロフィールリンクに集まるなら、流入の流度に限界があります。 3つ目に相談と制約をつなぎます。 相談予約時に引き継がれた流入IDがあり、決済側にも同じ匿名IDがあるときだけ結びます。 口頭でInstagramを見たと聞いた場合は、自己申告という確認元を残します。 自動計測と同じ制度として扱えません。 ここまで聞くと、そこまで厳密にしたらほとんど未計測になると感じるかもしれません。 最初の1枚は成果を証明する表ではなく、計測の穴を見つける表です。 穴が見えれば翌週から1つずつ塞げます。 ここから4つの検査を入れます。 重複、欠損、順序、合計です。 この検査がない1枚表は、見やすいだけで判断を誤らせます。 重複検査では、同じ相談IDや決済IDが2行へ入っていないかを確認します。 Instagram投稿を2つ見た人が1件制約しても、2件の売上げにはしません。 複数接点は、貢献候補として残し、制約件数は1件です。 欠損検査では、必要な列が空いている理由を見ます。 データが存在しない、取得権限がない、ID設計がない、まだ確認していない、この理由を分けます。 ただ空乱にすると、後から誰も直せません。 順序検査では、公開投稿より前に登録したことになってないか、相談より前に制約がついていないかを見ます。 既存フォロワーが過去投稿から来た場合はあり得るので、自動で削除せず、レビューへ置きます。 異常値と実際の例外を、人が判断します。 合計検査では、リーダーの登録、相談、制約の合計が、各製本の確認済み合計を超えていないかを確認します。 一致しなくても、未対応行の数で説明できるかを見る。 数字を合わせるための架空行は作りません。 検査結果は、パス、レビュー、フォールノース、3状態にします。 パスは識別値と順序が一致。レビューは候補はあるが、証拠が足りない。 フォールは重複、製本超過、あり得ない時系列、個人情報混入です。 フォールが1件あれば、集計から外して、人へ返します。 失敗時は、該当協だけを戻します。 相談IDが重複していたら、2行を保留し、別の合格行を作り直さない。 LINEの取得が失敗したら、その列を未計測にし、インスタグラムや売上の製本を再取得しません。 外部結果が不明なら、もう一度登録処理をせず、読み戻しを先にします。 ここから表を経営判断へ変えます。 最初に見るのは、売上額ではなく、どこまで確認できたかです。 投稿から登録、登録から相談、相談から制約。 この3つの接続率ではなく、接続可能率を出します。 未計測が多い段階で、転換率を精密に語りません。 例えば登録10件、相談3件、制約1件でも、投稿別に結べた登録が2件しかなければ、この投稿の制約率を出せません。 言えるのは、周全体の事実と2件の確認済み経路です。 残り8件は、動線改善の前に計測改善が必要です。 数字が少ないときほど、率ではなく、一人の経路を読みます。 確認できた1件について、どの投稿のどの約束から入り、LINEで何を読み、相談時に何を不安に感じ、どこで判断したかを個人情報を覗いてみます。 ここで初めて発信と商品説明の間にある抜けを具体化できます。 ただし、1件の経路を全員の正解にはしません。 この人はストーリーズから来たから、ストーリーズで集中すると飛ばす、次の1週間で同じ動線を計測できる形にします。 小数事例は仮説を作る材料であって、普遍的な価値設置の証明ではありません。 改善する変数は1つです。 投稿ごとのリンクIDを分ける。 LINE登録時に流入元を任意で聞く。 相談フォームへ流入IDを引き継ぐ。 決済台帳へ相談IDを残す。 このうち、一番上流の欠損を1つだけ直します。 全部を同時に変えると、入力ミスが増え、どの変更で接続率が上がったかわからなくなります。 今週は投稿ID、来週は相談への引き継ぎ。 という順番で台帳を育てます。 品質検査は変えません。 1枚表を毎週再利用するときは、列と状態を固定します。 新しい期間のログだけを追加し、過去の確認済み行を書き換えます。 商品名や経路名が変わったら、変更日以降の別地として記録します。 過去まで今の名前合わせません。 人が承認する境界は4つです。 異なるログの対応付けが本当に正しいか。 未計測をどこまで改善するか。 どの数字を社内外へ共有するか。 その数字から何を変えるか。 コーデックスは候補と検査結果を出しても、経営判断を自動で確定しません。 プライバシーも便利さより先に置きます。 個人の行動を必要以上に追わない。 計測目的を決め、匿名IDで足りるなら指名を持たない。 保存期間と閲覧者を決める。 相談内容の原文を売上分析表へコピーしないことです。 1枚で全部見えるを目標にすると、個人情報も無理な推測も集めたくなります。 目標は次の判断に必要な最小限が1枚で繋がることです。 詳しい原本はそれぞれの製本に残し、リーダーには参照元と確認時刻だけを持ちます。 ここから今日作る最小版を確認します。 Instagram投稿を3本。 LINE登録を確認できる範囲。 相談を1件。 制約を1件だけ入れます。 大量の過去データから始めません。 まず公開URLと日時へコンテンツIDを付けます。 次に登録経路として確認できるIDだけを結び、わからないものはアンメジャードへ置く。 相談と制約は匿名IDが一致するものだけを同じフローIDにします。 コーデックスに4検査を実行させ、レビュー行を人が読む。 製本合計を超えていないことを確認する。 最後に未計測が最も大きい接点を1つ選び、翌週の改善欄へ書きます。 これで最小版は完成です。 1週間後、改善が成功したかは売上げの増減だけで決めません。 未計測が減ったか。 重複が増えてないか。 入力負担が続けられるか。 正しい意見を前より早く終えるか。 計測品質が上がって始めて試作の良し悪しを比較できます。 売上げは大切です。 でも売上げだけを終点にして、途中の相手を数字へ変えると発信の価値が薄くなります。 どの言葉が安心を作り、どこで迷い、何が判断を助けたかを知るために数字を使う。 数字で人を押すためではありません。 完成テストは3つです。 同じ制約が2度数えられていない。 未計測がゼロへ変換されていない。 各設定の根拠へ戻れる。 さらに人が対応づけと改善案を承認していれば、一枚表は毎週使える経営の地図になります。 Instagram、LINE、相談、売上げを別々に頑張る状態から、一つの動線として学ぶ状態へ変えてください。 完璧な過去データを持たず、確認できる一件から始めれば、次に達すべき計測が見えます。 今すぐ紙へ、投稿、LINE、相談、制約の4列を書き、推測なしで同じ経路だと言える一件だけを横線で結んでください。