🚀 Fastify × Kintone × Googleログイン 連携時にハマった「undefined地獄」とそのスマートな回避法
🐞 発端：Googleログイン成功 → その直後にクラッシュ！？
Fastify × Kintone で Googleログイン機能を実装していたときのこと。
Googleログイン後、createUser() 関数を通じて Kintone にユーザー情報をPOSTし、
そのまま JWT を発行する流れを構築していたのですが…
const user = await createUser(...);
console.log(user.fc_username.value); // 💥 ここでエラー！
と、見事にエラー：
TypeError: Cannot read properties of undefined (reading 'fc_username')
えっ、登録は成功してるのに！？
原因は「KintoneのAPIレスポンス仕様」にありました。
🔍 原因：KintoneのPOSTレスポンスはレコード内容を含まない！
Kintoneの /record.json にPOSTしたときのレスポンスを見てみましょう：
{
"id": "9",
"revision": "1"
}
つまり、「登録したレコードの内容（record）」は返ってこない！
なのに return response.data.record なんて書いていたら、当然 undefined になるわけです。
✅ 解決策：自前でレコード形式を組み立てて返す
Kintoneと同じ構造（value付きオブジェクト）を自前で返すように修正。
// ❌ Before（ダメ）
return response.data.record;
// ✅ After（OK）
return {
fc_username: { value: fc_username },
fc_name: { value: fc_name },
fc_email: { value: fc_email },
fc_role: { value: fc_role || "user" }
};
これで .value アクセス前提の後続処理もバッチリ安定！
🧠 教訓まとめ
- KintoneのPOST APIは最低限の情報しか返さないので油断禁物
- レスポンスに頼らず、自前で「Kintone風」の構造を組んで返す方が安全
- JWT発行やセッション生成に使うデータは常に明示的にreturnするべし
- 「登録できたのに次でクラッシュ」は、戻り値の構造ミスが大半！
🧩 おまけ：なぜ value を揃えるべきか？
Kintone連携プロジェクトでは user.fc_username.value のように「value前提」のデータ構造がスタンダード。
この構造をcreate時点で守ることで、後続のバリデーション・JWT生成・UI表示などすべてがシンプルになる。
“データの整合性は戻り値から” を合言葉に、設計していきましょう。
✨ 結論
KintoneのAPIレスポンスを過信するな！
自分でレコード構造を返すことで、Googleログイン → Kintone登録 → JWT発行がスムーズにつながる！
Zenn読者のみなさんも、Fastify × Kintone構成を組む際は、
「APIレスポンスに頼らない設計」 を意識してみてください💡