לחבר AI ל-Google Sheets: מגבלת 30 השניות של כל פונקציה מותאמת

מי שבונה פונקציה מותאמת ב-Google Sheets שקוראת ל-AI לכל שורה בטבלה ("=AI_SUMMARIZE(A2)"), ומריץ אותה על 500 שורות בבת אחת, עלול לגלות ששורות רבות מחזירות שגיאה במקום תשובה - לא כי ה-AI נכשל, אלא כי Apps Script עצר את הפונקציה באמצע מסיבה טכנית לגמרי אחרת.

שתי מגבלות זמן שונות, לא אחת

לפי Google, לסקריפט Apps Script רגיל יש עד 6 דקות לביצוע - אבל לפונקציה מותאמת אישית (custom function, כמו =AI_SUMMARIZE()) יש רק 30 שניות. זו הסיבה שקריאה בודדת ל-AI מתוך תא בגיליון חייבת לחזור מהר - אם קריאת ה-API למודל אורכת יותר מ-30 שניות (למשל בגלל פרומפט ארוך מדי או תור עמוס), התא מציג שגיאת timeout, לא תוצאה חלקית.

מבחינת ההקמה בפועל: הפונקציה המותאמת שולחת בקשה לכתובת של Claude API עם הטקסט מהתא כתוכן הבקשה, ומחזירה את התשובה הטקסטואלית שמתקבלת ישירות לתא בגיליון. מפתח ה-API עצמו לא נכתב בגוף הפונקציה אלא נשמר בהגדרות המאובטחות של הסקריפט (Script Properties) - כך שהוא לא נחשף לכל מי שיש לו גישת עריכה לקובץ.

הבחירה במודל היא לא סתם עניין של עלות - היא ישירות קשורה למגבלת 30 השניות. מודל מהיר כמו Haiku 4.5 מחזיר תשובה משמעותית מהר יותר ממודל כבד כמו Opus, וזה קריטי כשיש חלון זמן קשיח שלא ניתן להאריך.

מכסת קריאות יומית - לא רק זמן

לפי אותו מקור, חשבון צרכן (Gmail רגיל) מוגבל ל-20,000 קריאות UrlFetch ביום, בעוד חשבון Google Workspace מקבל 100,000 - כל קריאה חיצונית מהסקריפט, כולל כל קריאה ל-AI, נספרת במכסה הזו. גיליון עם 500 שורות שכל אחת קוראת ל-AI פעם אחת צורך 500 מהמכסה - נשמע קטן, אבל אם הפונקציה מחושבת מחדש בכל פעם שהגיליון נפתח או שמשהו בו משתנה (לא רק כשמריצים אותה במפורש), המכסה מתכלה הרבה יותר מהר ממה שמתכננים.

למה לא כדאי לשים את מפתח ה-API ישירות בתוך הקוד

חשוב לוודא שמפתח ה-API לא כתוב ישירות בגוף הפונקציה - זה לא רק היגיינה טכנית, זה קריטי במיוחד ב-Apps Script כי הסקריפט לרוב משותף או מועתק בין גיליונות באותו ארגון. מפתח שמוטבע ישירות בקוד נחשף לכל מי שיש לו גישת עריכה לסקריפט, גם אם אין לו גישה לחשבון שבו המפתח נוצר במקור. שמירה בהגדרות המאובטחות של הסקריפט מפרידה בין הקוד לבין הסוד, ומאפשרת להחליף מפתח בלי לגעת בלוגיקה - זה פרט קטן שכדאי לוודא שהמפתח שמקים את זה יישם, לא רק "שיעבוד".

איפה זה נשבר: חישוב מחדש לא מבוקר

Google Sheets מריץ מחדש פונקציות מותאמות אוטומטית בתרחישים שקל לפספס - פתיחת הגיליון מחדש, שינוי בתא שהפונקציה תלויה בו בעקיפין, או אפילו רענון הדפדפן. פונקציה שקוראת ל-AI ולא נבנתה עם מנגנון קאשינג עלולה לקרוא לאותו טקסט שוב ושוב בלי סיבה אמיתית, ולצרוך גם מכסה וגם כסף על טוקנים בלי תועלת נוספת. הפתרון: לשמור תוצאות בקאש (CacheService של Apps Script) לפי hash של הטקסט הנכנס, ולהחזיר תוצאה שמורה כשהקלט זהה לקריאה קודמת.

מקרה קצה: הפונקציה חייבת לחכות לתלות בתא אחר

Google Sheets לפעמים מריץ פונקציות מותאמות בסדר שלא צפוי מראש, במיוחד כשיש כמה פונקציות שתלויות זו בזו על פני עמודות שונות - אם AI_SUMMARIZE תלויה בתוצאה של פונקציית עזר אחרת שעדיין לא סיימה לחשב, היא עלולה לקבל ערך ריק או "טוען..." ולשלוח אותו כמו שהוא ל-AI. הפתרון הבטוח: לבדוק בתחילת הפונקציה אם הקלט ריק או במצב טעינה (#N/A, מחרוזת ריקה) ולהחזיר ערך ריק במקום לשלוח בקשה חסרת טעם למודל - זה גם חוסך קריאות מיותרות למכסה היומית.

דוגמה: כמה זמן בפועל לוקחת קריאה ל-Haiku

קריאה טיפוסית ל-Claude Haiku 4.5 עם פרומפט קצר (עד כמה מאות מילים) וטוקן פלט מוגבל ל-200, חוזרת בדרך כלל תוך 2-5 שניות - הרבה מתחת למגבלת ה-30 שניות, מה שמשאיר שוליים בטוחים גם אם הרשת איטית או המודל עמוס. קריאה עם פרומפט ארוך יותר (טקסט של אלפי מילים לסיכום) יכולה להתקרב הרבה יותר לגבול, ולכן שווה להגביל מראש את אורך הטקסט שנכנס לתא בודד - לחתוך או לסכם מקדים אם הטקסט חורג ממה שנוח לעבד בפונקציה יחידה.

מה לנסות עכשיו

לפני שמריצים פונקציה כזו על טבלה גדולה, לבדוק אותה קודם על 5-10 שורות ולוודא שהיא לא חורגת מ-30 השניות בממוצע. ואם התוכנית היא לעבד מאות שורות בבת אחת, עדיף פונקציית סקריפט רגילה שרצה פעם אחת על כל הטווח (עם עד 6 דקות, לא 30 שניות) - ולא הרבה קריאות custom function נפרדות שכל אחת מתמודדת עם המגבלה הקשה לבד. הבחירה בין שתי הגישות היא ההבדל בין עיבוד יציב לטבלה גדולה לבין שורות שנתקעות באמצע בלי סיבה ברורה למשתמש.