Snowflake 「String is too long 」エラー原因と対処法を解説

はじめに:そのエラー、文字数オーバーが原因かも?
エラーの原因:VARCHARの「最大長」を超えている
対処法1:カラムのVARCHAR長を広げる
対処法2:CASTやSUBSTRで明示的に切り詰める
対処法3:セッション設定で自動切り詰めに切り替える
よくあるハマりどころと注意点
まとめ
参考リンク
関連記事
1. ▶次に読むべき記事

はじめに:そのエラー、文字数オーバーが原因かも?

SnowflakeにINSERTやUPDATEを実行したときに、こんなエラーに出会ったことはありませんか?

String 'こんにちは、Snowflakeの世界へようこそ!...' is too long and would be truncated

これは「文字列が長すぎて、カラムに収まりきらないので保存できません」という意味のエラーです。データ移行や外部CSVの取り込みなど、思いがけないタイミングで発生しやすく、つまずきやすいポイントの1つです。

この記事では、このエラーの原因と、VARCHAR長の見直し・CAST・STRING(VARCHAR)_AUTO_TRUNCATE設定といった具体的な対処法を解説します。

エラーの原因:VARCHARの「最大長」を超えている

Snowflakeのテーブルカラムには、文字列を保存するための型として VARCHAR(N) があります。Nは「最大何文字まで入れられるか」を表します。たとえば VARCHAR(10) なら最大10文字までしか入りません。

このN文字を超える値を挿入しようとすると、Snowflakeはデフォルトで「データを勝手に切り捨てるのは危険」と判断し、エラーを返します。

CREATE OR REPLACE TABLE users (name VARCHAR(10));

-- これはOK (5文字)
INSERT INTO users VALUES ('Alice');

-- これはエラー (20文字)
INSERT INTO users VALUES ('VeryLongUserName1234');
-- → String 'VeryLongUserName1234' is too long and would be truncated

ポイントは、Snowflakeはサイレントに切り捨てたりせず、必ず明示的なエラーで知らせてくれるということです。これはデータ品質を守るための親切設計です。

対処法1:カラムのVARCHAR長を広げる

そもそもカラムの長さが業務要件に合っていない場合は、ALTER TABLE で広げるのが一番素直な解決法です。

ALTER TABLE users ALTER COLUMN name SET DATA TYPE VARCHAR(100);

Snowflakeでは VARCHAR は長さを指定してもストレージ消費は変わりません(実際の文字数分だけ消費)。そのため、迷ったら最大の VARCHAR(16777216)(約16MB)を指定しても無駄になりません。設計時から余裕を持たせておくのがおすすめです。

対処法2:CASTやSUBSTRで明示的に切り詰める

「長すぎる値は最初のN文字だけ入れたい」という場合は、SUBSTR や LEFT で明示的にカットしましょう。

INSERT INTO users
SELECT SUBSTR(source_name, 1, 10)
FROM staging_users;

また、CAST(value AS VARCHAR(10)) のように明示的にCASTすると、Snowflakeは「呼び出し側が切り詰めを意図している」と解釈して、エラーではなく切り捨てを行ってくれます。

SELECT CAST('VeryLongUserName1234' AS VARCHAR(10)) AS short_name;
-- → 'VeryLongUs'

対処法3:セッション設定で自動切り詰めに切り替える

大量のデータをロードしていて、いちいち長さを気にしたくない場面では、セッションパラメータ STRING(VARCHAR)_AUTO_TRUNCATE系 や、COPY INTO の ON_ERROR・TRUNCATECOLUMNS オプションを使う方法があります。

-- COPY INTO で超過分を自動切り詰め
COPY INTO users
FROM @my_stage/users.csv
FILE_FORMAT = (TYPE = CSV)
ON_ERROR = 'CONTINUE'
TRUNCATECOLUMNS = TRUE;

TRUNCATECOLUMNS = TRUE を指定すると、カラム長を超えた値はエラーにならず、自動でカットされてロードされます。ただしデータの一部が失われることを意味するので、本番運用では慎重に判断しましょう。

よくあるハマりどころと注意点

マルチバイト文字に注意: VARCHAR(N)のNは「文字数」(コードポイント数)です。バイト数ではないため、日本語でも英語でも同じ文字数で計算します。
暗黙の型変換で発生する: 数値や日付を文字列にCASTした結果が、想定より長くなって発生することもあります。
ビューやCTAS結果のカラム長: CREATE TABLE AS SELECT で作ったテーブルは、ソースの最大長を継承します。後段で短い列にINSERTすると弾かれます。

関連する型・識別子まわりのエラーには、「Date is not recognized」エラーの原因とTO_DATE/TRY_TO_DATEの使い分けや、「Invalid identifier」エラーの原因と解決法もよく似た構造でつまずきがちなので、合わせてチェックしておくと安心です。