アカウント作成スクリプトの赤いエラーは、
どこから来るのか
Active Directory・Microsoft 365・Google Workspace——
3つの仕様が噛み合わないところに、毎年つまずいています
結論から言うと、あの赤いエラーの大半は、書き方が下手だから出ているのではありません。Active Directory と Microsoft 365 と Google Workspace は、それぞれ別の会社が別の時代に作った仕組みです。名前の長さの上限も、パスワードの規則も、変更が反映される速さも違います。その差を全部引き受ける場所が、たまたま学校で書かれた1本のスクリプトになっている——というのが実際のところだと思います。
この記事では、赤いエラーがどこから来るのかを5つに整理します。そのうえで、もっと厄介な「赤くならないまま間違っている」4つのパターンを扱います。最後に、自作を続ける前提で明日から使えるチェックリストを置きました。Conneco（こねこ）を導入されない場合にも役立つ内容を目指しています。
赤いエラーは、だいたい5か所から来る。
① 名前が長すぎて、あとの工程で落ちる
Active Directory のログオン名（sAMAccountName）は20文字までです。学籍番号や職員番号に接頭辞を付けて組み立てると、学校によっては超えます。
やっかいなのは落ちる場所がずれることです。CSV を読み込む段階では何も起きません。名前を組み立てるところでも起きません。AD に作りにいった瞬間に初めて落ちます。ログだけ見ても「どの層で失敗したのか」が分からず、CSV を疑ったりスクリプトを疑ったりで時間を溶かします。
先に検査してしまうのがいちばん速いです。流す前に文字数を数えて、超える行だけ一覧で出す。それだけで、この種の事故はほぼ消えます。
② UPN のドメインが、社内向けのままになっている
Active Directory を構築したときのドメインが example.local のような内部専用の名前だと、そのままでは Microsoft 365 側へ同期できません。実際に使っている公開ドメインを UPN サフィックスとして追加し、全ユーザーの UPN を切り替えるという下ごしらえが要ります。
そしてここが本当に怖いところなのですが——すでにクラウド側で個別にアカウントを作って運用している学校が、あとから同期を始めるとき、UPN かメールアドレスが揃っていないと既存のアカウントと結びつきません。結びつかなかったぶんは新規として作られます。つまり全員分の重複アカウントができます。
初回の1回しか起きない事故なのに、起きると復旧がいちばん重い。同期を始める前に、既存のクラウドアカウントと突き合わせておくことをおすすめします。
③ 生成したパスワードが、規則を満たしていない
Active Directory の既定のパスワード複雑性要件は「8文字以上」かつ「大文字・小文字・数字・記号のうち3種類以上」です（ポリシーの設定によります）。
初期パスワードを「学校の略称＋入学年度＋誕生日」のようなルールで組み立てると、組み合わせによっては2種類しか含まれない行が出ます。しかも返ってくるメッセージは「パスワードが要件を満たしていません」止まりで、どの要件に引っかかったかは教えてくれません。
ルールを決めたら、実際に生成される文字列を数十件ぶん眺めて、最悪のケースでも3種類入るかを確かめておくと安全です。
④ 文字コードで、日本語が壊れる
日本の学校で Excel から「CSV として保存」したファイルは、多くの場合 Shift_JIS（CP932）です。いっぽうシステムから書き出した CSV は UTF-8 のことが多い。読み込み側で片方に決め打ちすると、もう片方が必ず化けます。
逆向きの罠もあります。UTF-8 で書き出したファイルは、先頭に BOM が付いていないと Excel が Shift_JIS と誤認して開きます。「文字化けするから」と現場で手直しされて、さらに崩れることもあります。
さらに念の入ったことに、BOM は「付けているつもりで付いていない」ことがあります。言語やライブラリによっては、BOM を出すかどうかの指定が、書き出しの経路によっては効きません。画面で開くと正しく見えるので、先頭の数バイトを直接見るまで気づけません。
⑤ Excel が、渡す前に値を書き換えている
これはスクリプトの問題ではありません。渡されたファイルが、開いた時点ですでに壊れているという話です。よくあるのは3つです。
前ゼロが落ちる。0012345 が 12345 になります。学籍番号が変わると、その人はシステム上まったくの別人になります。
日付がシリアル値になる。2010-04-01 のつもりの列に 45383 のような5桁の数字が入ります。
目に見えない文字が混ざる。Web からのコピペで、改行しない空白（U+00A0）や幅ゼロの空白（U+200B）が紛れ込みます。氏名に入ると表示名やグループ名が壊れますが、画面上は普通の文字列に見えます。
ここで大事なのは、見つけても勝手に直さないことだと考えています。直してしまうと、次の年も同じ壊れ方のファイルが来ます。検出して「この行のこの列が怪しい」と知らせ、元のファイルを直してもらうほうが、結果として早く終わります。
5つとも、スクリプトを書き直せば消えるものではありません。仕様の差を、どこかで誰かが引き受けるしかない種類の問題です。
赤くならないほうが、怖い。
ここからが本題です。止まってくれるエラーは、まだ親切なほうです。本当に困るのは、成功したように見えて間違っているものです。次の4つは、いずれも画面にもログにも何も出ません。
氏名を「整えた」つもりで、本人の字が変わる
全角の英数字を半角に寄せたくて、氏名にも Unicode の正規化（NFKC・NFC）をかけたくなります。ところがどちらの正規化も、互換漢字を統合漢字へ置き換えます。﨑 は 崎 に、髙 は 高 になります。エラーは出ません。本人の正式な字が黙って書き換わるだけです。
正規化は用途で分けるのが安全です。学籍番号・年度・電話番号にはかけてよく、氏名・住所にはかけない。フリガナは全角カタカナに揃える目的でかける、というふうに。
一覧が、途中で黙って切れている
Active Directory の検索は、ページサイズを指定しないと既定で1000件あたりで打ち切られます。Microsoft のクラウド API は1回の応答が最大999件、Google 側は500件で、続きを取りにいかないと残りは返ってきません。
いずれもエラーにはなりません。件数が足りないだけです。だから在籍1000名未満の学校では何年経っても発覚せず、大規模校か、生徒と教職員を合わせて上限を超えた年に、突然「一部の人だけ処理されない」という形で表に出ます。
存在しない人を、グループに入れられる
Google のグループは、実体のないメールアドレスでもメンバーとして追加できます。API は成功を返します。
アカウントがまだ作られていない人をグループに足すコードを書くと、ログには「追加 16 件 / 失敗 0 件」と出ます。数字だけ見れば完璧な成功です。実際には、誰も所属していないグループができています。
「向こうに無いから消す」が、全消しに化ける
「クラウド側に無い人はこちらでも消す」という突合は、一見きれいな設計です。しかしクラウド側の取得が失敗して空の一覧が返ってきただけでも、同じ条件が成立します。
「全員が向こうに居ない」＝「全員消す」。追加は取得が不完全でも安全ですが、削除だけは違います。一括で取ってきた結果は消す候補を絞るためだけに使い、実際に消す直前にもう一度、1件ずつ確かめる。この非対称は覚えておく価値があります。
「エラーが出なかった」は、「正しかった」ではありません。
処理した件数が、処理するはずだった件数と合っているか——そこまで見て、はじめて確認したことになります。
「書いたのに反映されない」は、
たいてい待ち時間。
もうひとつ、時間を溶かしやすいのが「反映されない」系です。多くの場合これは失敗ではなく、まだ届いていないだけです。
| 経路 | 既定の間隔 | 意味すること |
|---|---|---|
| 従来型の同期（サーバーに導入するもの） | 約30分 | AD で無効化しても、クラウド側で使えなくなるまで最大30分の差がある |
| 軽量型の同期（エージェント方式） | 約2分 | 単一構成の学校ならこちらのほうが待ちが短い |
| パスワードの同期 | 約2分 | ほかの属性の同期サイクルとは独立して動く |
※ いずれも既定値です。構成や設定によって変わります。
Microsoft 365 側には、そもそも書き込めない
意外に知られていないのですが、オンプレミスの AD から同期されたユーザーは、クラウド側では「AD が権威」という扱いになります。この状態のユーザーの氏名や所属をクラウドの API から書き換えようとすると、拒否されるか、通ったように見えても次の同期で AD の値に巻き戻ります。
「クラウド側の API を叩いたのに反映されない」の多くはこれです。書き込む先を AD 側に寄せて、クラウドへは同期に任せる——という整理をしておくと、追いかける対象が半分になります。
年度末に、同期そのものが止まることがある
同期の仕組みには誤操作の安全弁として「削除しきい値」があり、1回のサイクルで既定500件を超える削除が発生すると、そこで止まって管理者に通知が飛びます。
平常時は絶対に届かない数字ですが、卒業処理でまとめて OU を移動する年度末は話が別です。しかも「移動しただけ」のつもりが削除として数えられることがあります——同期の対象範囲から外へ出す操作は、クラウド側からは削除に見えます。卒業生用の OU を同期対象に含めていないと、卒業がそのまま削除になります。
年度末の運用を組むときは、この2つを先に確認しておくと安心です。
途中で止まったとき、
もう一度流せますか？
300人分を流している最中に、120人目でエラーが出て止まった。このとき次に何をするか——ここがいちばん差が出るところだと思っています。
「121人目から再開する」を作り込むのは、想像よりずっと難しい仕事です。どこまで進んだかを正確に記録し続ける必要があり、その記録自体が壊れる可能性もあります。
現実的なのは逆の発想で、「最初から全部流し直しても、結果が同じになる」ようにしておくことです。すでに作られている人は作らない。すでに正しい値の人は触らない。そうしておけば、止まったらもう一度最初から流すだけで済みます。「失敗しても流し直せばいい」と思えるようになると、運用の緊張感がまるで変わります。
そのための考え方が、「差分を命令する」のをやめて「あるべき姿を宣言する」ことです。「この人を作れ・この人を消せ」と手順を並べるのではなく、「名簿がこうなっているので、3つのシステムはこうなっているはず」と宣言して、そこへ寄せる。この形にすると、何度実行しても同じところへ収束します。
もうひとつ、規模の感覚も書いておきます。アカウントの作成や更新は、1人あたりおおむね1秒前後かかります（環境によります）。3000名規模の学校で全員分を1回のリクエストで流そうとすると、途中でタイムアウトして「画面は固まったまま、サーバー側では処理が進んでいる」という、いちばん判断に困る状態になります。数十件ずつに分けて流すほうが、進み具合も見えて安全です。
自作を続けるなら、この7つだけは。
スクリプトをやめる必要はまったくありません。校内で書ける方がいるのは強みです。ただ、次の7つを入れておくと、事故の大半は起きなくなると考えています。
| 1. 流す前に、数える | 「作成 32 件・更新 5 件・無効化 1 件」を先に出して、目視してから実行する。何が起きるか分からないまま押せるボタンを作らない |
|---|---|
| 2. 名前の長さと重複を先に検査する | ログオン名の文字数、同じ番号の使い回し、大文字小文字だけ違う組み合わせ。AD は大文字小文字を区別しません |
| 3. 文字コードを決め打ちしない | UTF-8 として厳密に読めなければ Shift_JIS とみなす、という判定を入れる。読み取った結果を画面に出すと、事故が減ります |
| 4. 氏名には正規化をかけない | 見えない文字と制御文字だけ取り除く。全角半角の統一は、番号やフリガナなど別の列に限る |
| 5. 一覧は最後まで辿る | ページサイズを明示し、続きのトークンがある限り取りにいく。件数が合っているかを毎回確かめる |
| 6. 削除は、消す直前にもう一度確かめる | 一括で取った一覧は候補を絞るためだけに使う。取得に失敗したら、削除には進まず止まる |
| 7. 何度流しても同じ結果になるようにする | 「続きから」ではなく「流し直せる」を目指す。これができると、止まることが怖くなくなります |
どの方法を選ぶかの比較は、新入生のアカウントを一括作成するには？ に整理しています。
Conneco では、こうしています。
教育システム統合アプリ Conneco（こねこ）の Conneco Directory は、この記事に書いたことをそのまま設計に落としたモジュールです。ここで挙げた落とし穴は、どれも私たちが実際に踏んだものです。
あるべき姿を宣言する
名簿を唯一の正として、3つのシステムを「そうあるべき状態」へ寄せる設計です。手順を並べないので、何度実行しても同じところへ収束します。
書き込む先を絞る
書くのは Active Directory と Google Workspace の2つだけ。Microsoft 365 へは同期に任せます。巻き戻る書き込みを最初からしない設計です。
実行前に影響範囲を出す
「作成 32 / 無効化 1 / 移動 1」を実行前に表示します。絞り込み表示が同期の範囲を変えないことも、画面に明記しています。
記録はジョブ単位で1本
3000名の同期で3000行の記録が積まれると、かえって何も追えません。1回の作業を1本にまとめ、中身に全件を書き出す設計です。
取り消せる
一括同期のあとでも、その1本を取り消せば OU も有効・無効も元に戻ります。「速く作れるか」より「間違えたときに戻せるか」を優先しています。
取り込む前に検査する
文字数超過、番号の重複、前ゼロ落ち、日付のシリアル値、見えない文字、異体字。書き込む前に一覧で示し、勝手には直しません。
よくある疑問
いま動いているスクリプトは、捨てなければいけませんか？
いいえ。動いているものを止める必要はありません。この記事の7つのチェックのうち、「流す前に数える」と「削除の前に確かめる」の2つだけでも入れておくと、大きな事故はかなり防げます。
判断が変わるとしたら、規模が数百名を超えたときと、書いた方が異動される見込みが立ったときだと思います。仕組みを入れ替えるかどうかは、そのタイミングで検討されるのが自然です。
Microsoft 365 側に直接書き込むのは、なぜだめなのですか？
だめというより、成立しません。オンプレミスの Active Directory から同期されたユーザーは、クラウド側で「AD が権威」という扱いになります。クラウドの API から属性を書き換えようとすると拒否されるか、通っても次の同期で AD の値に巻き戻ります。
クラウド側だけで作ったアカウント（同期の対象外のもの）は別で、こちらは直接編集できます。同じ画面に並んでいても扱いが違うので、混ざると原因が分からなくなります。
「同期したのに反映されない」とき、どこから見ればいいですか？
まず時間を置いてみてください。従来型の同期は既定で約30分間隔なので、その範囲なら異常ではありません。
それでも反映されない場合は、①同期の対象範囲（OU）から外れていないか ②UPN が公開ドメインになっているか ③同期が止まっていないか（削除しきい値の超過など）——の順に見ると、多くはどこかで当たります。
前ゼロ落ちや日付の崩れは、システム側で直せませんか？
技術的には直せます。ただ私たちは、直さずに知らせる方を選びました。
自動で直すと、次の年も同じ壊れ方のファイルが届きます。しかも「直した」ことによって、元のファイルが壊れていた事実が見えなくなります。0012345 を 12345 と読んでよいのか、それとも本当に5桁の番号なのかは、機械には判断できません。見つけて知らせ、元のファイルを直していただくほうが、結果として早く終わると考えています。
名簿の担当が毎年変わります。何から手を付けるべきですか？
命名規則を文書化するところからをおすすめします。ログオン名・メールアドレス・初期パスワードをどう組み立てているかを1枚にまとめておくだけで、引き継ぎの負担がまったく違います。
そのうえで「誰が・いつ・何をしたか」が画面で見られる状態にできると、前任の方に確認しなくても状況が分かるようになります。年に1回しか触らない作業ほど、この記録が効いてきます。
春のアカウント作成、
今年こそ静かに終わらせませんか。
いま使っておられるスクリプトや手順をお聞かせいただければ、どこが引き継げてどこが置き換えになるかをご説明します。
オンラインデモで、実行前の確認画面と取り消しの動きを実際にご覧いただけます。
最終更新: 2026年8月11日