🔖

Fastify × Kintone × Googleログイン 連携時にハマった

に公開
Node.js
Google
JWT
kintone
Fastly
tech

🚀 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レスポンスに頼らない設計」 を意識してみてください💡

Discussion