正直に言うと、一般の業務でCALL関数を使う場面はほぼありません。アドイン開発者やレガシーExcelファイルの保守担当者など、限られた上級者向けの関数です。

ただ、古いファイルを開いたら見慣れない =CALL(...) が出てきた、という方もいるはずです。この記事ではExcel CALL関数の構文・type_textの型コード・REGISTER.IDとの関係・現代では非推奨である理由までを誠実に解説します。読み終えるころには「読めるが書かない」関数として、CALL関数を正しく扱えるようになります。

ExcelのCALL関数とは？DLL/XLLの外部関数を呼び出す特殊関数

ExcelのCALL関数は、DLLやXLLというExcel外部のコンパイル済みライブラリに含まれる関数を呼び出すための特殊関数です。SUM関数やIF関数のようなExcel内蔵関数とは性質が違います。C/C++などで書かれた外部コードをワークシートから実行できる、いわば「橋渡し」の役割を担います。

DLLとは、Windowsで複数のプログラムから共有して使えるようコンパイル済みコードをまとめたファイルのことです。user32.dll や kernel32.dll などWindows標準のものから、業務システム独自のものまで種類はさまざまです。XLLはこのDLLをExcel専用に拡張したもので、Excelに直接組み込んで関数として登録できます。

CALL関数は古いExcel（Excel 4.0時代のXLM 4.0マクロ言語）から残る互換機能です。現在も互換性のために維持されていますが、現代の業務利用では原則使うべきでない関数である点を、最初にお伝えしておきます。理由は記事後半で詳しく解説します。

ExcelのCALL関数の書き方（構文と引数）

CALL関数には2つの呼び出し形式があります。直接DLLを指定する形式と、REGISTER関数で登録済みのIDから呼ぶ形式です。

形式1：DLLを直接指定する

=CALL(module_text, procedure, type_text, argument1, argument2, ...)

module_text は拡張子 .dll を省略できます。Windows標準DLLなら "user32" のように関数名だけで指定可能です。

形式2：REGISTER関数で登録したIDから呼ぶ

=CALL(register_id, argument1, argument2, ...)

REGISTER関数（またはREGISTER.ID関数）でDLL関数を一度Excelに登録すると、戻り値としてID番号が返ります。次回以降は module_text や procedure を毎回書く必要がありません。IDと引数だけでCALLを実行できるため、実用上ほとんどのケースでこちらの形式が使われます。

type_textの型コード一覧（戻り値・引数の型を指定する記号）

CALL関数で最も理解が難しいのが type_text の型コードです。1文字の記号でC言語の型を指定する独自ルールで、慣れないと暗号のように見えます。

ルールはシンプルです。先頭1文字が戻り値の型、2文字目以降が引数の型を順番に並べるという決まりになっています。

主要な型コードを以下の表にまとめます。

たとえば "JJB" と書くと、戻り値が long int で、引数が long int と double のC関数を意味します。"BBB" なら倍精度の引数2つを取って倍精度を返す関数です。

64bit版のExcelではポインタ型（C/D/E/F/G/L/N/P/R）の扱いに違いがあります。そのため同じ型コードでも、32bit/64bitでDLLの再コンパイルや書き換えが必要になることがあります。

REGISTER.ID関数との関係（CALL関数の実用パターン）

CALL関数を実用する場面では、ほぼ必ずREGISTER関数（またはREGISTER.ID関数）とセットで使います。3つの関数の役割を整理します。

実用上のパターンはこうです。

A1: =REGISTER("MYLIB.DLL", "MyFunc", "BB")
    → 登録成功でID（例: 1）を返す
A2: =CALL(A1, 100)
    → MyFunc(100) を実行し、倍精度浮動小数点を返す
A3: =CALL(A1, 200)
    → 同じMyFunc(200) を実行

REGISTERでDLL関数を一度Excelに登録しておけば、以降はIDを使い回してCALLで何度でも呼び出せる仕組みです。module_text/procedure/type_text を毎回繰り返す必要がなく、数式が短く保守しやすくなります。

なおREGISTERとCALLは「マクロ関数（XLM 4.0マクロ言語）」のグループに属します。互換性のために残されている古いマクロ言語で、後述するセキュリティ警戒の対象でもあります。

CALL関数の代替手段（VBA・XLLアドイン・Office Scripts）

「DLLの関数を呼びたい」という目的だけなら、現代のExcelではCALL関数より優れた選択肢が複数あります。

VBAのDeclareステートメント

VBAコード内で Declare PtrSafe Function ... と書いてDLL関数を宣言する方法です。CALL関数と同じくDLLを呼べますが、エラー処理・型チェック・デバッグのしやすさが格段に上です。既存のDLLを呼ぶだけなら、まず候補に挙がります。

Declare PtrSafe Function MessageBoxA Lib "user32" _
    (ByVal hWnd As LongPtr, ByVal lpText As String, _
     ByVal lpCaption As String, ByVal uType As Long) As Long

XLLアドイン（C API / Excel-DNA）

DLLをExcelの「カスタム関数」として登録する方法です。XLLとして関数を提供すれば、利用者はCALL関数ではなく =MyFunc(100) のように通常の関数として呼び出せます。Excel-DNAというオープンソースフレームワークを使えば、C#でもXLLアドインを開発できます。

Office Scripts（クラウド/Excel for Web）

TypeScriptでExcelを自動化する仕組みで、Excel for WebやMicrosoft 365で利用できます。クロスプラットフォームで動き、クラウド連携にも強いのが特徴です。Windows専用DLLは呼べませんが、API連携やデータ処理ならこちらが現代的な選択肢になります。

Power Automate / Power Query

データ統合やAPIアクセスが目的なら、Power AutomateやPower Queryで対応できる範囲が広がっています。「CALLでなにかを呼びたい」という要件の多くは、これらのツールで代替可能です。

CALL関数を使うべきでない理由とセキュリティリスク

CALL関数を新規に書くことが推奨されない理由は、大きく3つあります。

理由1：セキュリティリスクが高い

CALL関数は任意のDLLの任意の関数を実行できます。これは便利な反面、過去にマクロウイルスや遠隔コード実行（RCE）の手段として悪用された歴史があります。

最近のExcelは、インターネット経由のファイルやメール添付ファイルでマクロやXLM 4.0関数を既定でブロックする仕様に変わりました。Microsoft Defender SmartScreenやマクロブロック機能が、不審なファイルでのCALL実行を防いでくれます。

裏を返すと、信頼できないファイルでCALL関数を見かけたら警戒すべきです。そのファイル自体がマクロウイルスの可能性も視野に入れるのが正しい態度になります。安易に「コンテンツの有効化」をクリックしないことを強くおすすめします。

理由2：保守性が低い

type_text の型コードを1文字でも間違えると、Excelごとクラッシュすることがあります。デバッガでステップ実行することもできず、原因切り分けが困難です。VBAのDeclareなら型不整合をある程度検出できますが、CALL関数にはそうした安全弁がありません。

理由3：ポータビリティが低い

32bit Excelと64bit Excelで、ポインタ型のサイズが異なります。同じ type_text の数式でも、32bit版では動いても64bit版で動かないケースが頻繁に起こります。VBAのDeclareでは PtrSafe キーワードで64bit対応を明示できますが、CALL関数には同等の仕組みがありません。

加えて、MicrosoftはXLM 4.0マクロを「将来的に廃止される可能性がある機能」と位置づけています。新規プロジェクトでの採用は推奨されていません。

まとめ：CALL関数は「読めるが書かない」関数

ExcelのCALL関数は、DLLやXLLの外部関数をワークシートから直接呼び出せる強力な特殊関数です。一方で、現代の業務利用ではセキュリティ・保守性・ポータビリティのいずれも代替手段の方が優れています。VBA Declare・XLLアドイン・Office Scriptsが充実した現在、新規に書くべき関数ではありません。

整理すると、押さえるべきポイントは以下の3点です。

• 構文：=CALL(module_text, procedure, type_text, ...) で外部DLLの関数を呼べる
• type_text：先頭1文字が戻り値、2文字目以降が引数の型（B=double, J=long, C=char* など）
• 現代Excelでは非推奨：セキュリティ・保守性・ポータビリティの観点でVBAやXLLが推奨される

不審なファイルでCALL関数を見かけた場合は、安易に有効化せず、ファイルの出所を確認してください。逆に既存資産の保守でCALL関数のメンテナンスが必要な場合は、可能な範囲でVBAのDeclareやXLLアドインへの移行を検討するのが安全です。

Excelの旧式・特殊関数つながりでは、互換性関数のVARP関数（母分散）、現代では新関数推奨のTTEST関数（t検定）、旧式のNORMSDIST関数（標準正規分布）もあわせて押さえておくと、Excelの「過去と現在」が立体的に見えてきます。CALL関数は読めるが書かない、これが正しい付き合い方です。

普段のExcel業務ではまず触ることがない関数ですが、古いマクロブックの保守や、レガシーなアドイン開発の現場では今も登場します。この記事では、構文と引数、CALL関数とのセットでの使い方、そして「現代のExcelでは何を使えばいいのか」までをまとめて解説します。

ExcelのREGISTER.ID関数とは？

REGISTER.ID関数（読み方：レジスター・アイディー）は、すでに登録されているDLL（ダイナミックリンクライブラリ）またはXLL（Excel拡張アドイン）の関数の、登録済みIDを返す関数です。関数名は「REGISTER（登録）+ ID（識別子）」に由来します。

DLLやXLLには、Excelの外側で動作するC/C++製のプログラム部品が入っています。それをワークシート関数のように使うためには、まずExcelに「この関数を使います」と登録する手順が必要です。REGISTER.IDはこの登録済みのIDを取得する役割を担います。

ポイントは、対象の関数がまだ未登録の場合は自動的に登録した上でIDを返してくれる点です。そのため、CALL関数と組み合わせれば「登録 → 実行」を1セットで行えます。

NOTE
REGISTER.IDは Excel 4.0 マクロ（XLM）時代に作られた古い関数です。現代のExcelには互換性のために残されていますが、新規利用は推奨されていません。後述する代替手段の利用を強くおすすめします。

REGISTER.ID関数の構文と引数

REGISTER.ID関数の構文は次のとおりです。

=REGISTER.ID(module_text, procedure, [type_text])

戻り値は登録IDを表す整数値です。関数の登録に失敗した場合は #VALUE! エラーが返ります。

type_text の型コード

type_text は、戻り値と各引数のデータ型をアルファベット1文字で並べた文字列です。最初の文字が戻り値の型、それ以降の文字が引数の型を順に表します。

たとえば、引数なしで4バイト整数を返す関数なら "J"、文字列を1つ受け取って4バイト整数を返す関数なら "JC" のように指定します。

REGISTER.ID関数の使い方（CALL関数とのセット利用）

REGISTER.ID単体では何もできません。取得したIDをCALL関数に渡してはじめて、外部DLLの関数を実行できます。基本の流れは次のとおりです。

1. REGISTER.IDで対象DLL関数のIDを取得する
2. そのIDをCALL関数の第1引数に渡す
3. CALLが実際の関数を呼び出して結果を返す

概念例：Windows APIの GetTickCount を呼び出す

たとえば Windows の kernel32.dll に含まれる GetTickCount（システム起動からの経過ミリ秒を返す関数）を呼び出す場合は、次のようなイメージになります。

A1: =REGISTER.ID("KERNEL32.DLL", "GetTickCount", "J")
A2: =CALL(A1)

A1で GetTickCount の登録IDを取得し、A2でそのIDを使って関数を実行します。"J" は「引数なし、戻り値は4バイト整数」を意味します。

REGISTER関数・CALL関数との役割分担

REGISTER.IDは似た名前の関数が複数あり、混乱しやすいので役割を整理しておきます。

ざっくり言うと、REGISTERは「登録して名前をつける」、REGISTER.IDは「IDだけ返す」、CALLは「IDで実行する」と覚えておけば十分です。

REGISTER.ID関数を使う前に知っておきたい注意点

REGISTER.ID関数は強力ですが、扱いを誤るとExcel自体が落ちる危険があります。利用前に必ず次の点を確認してください。

1. type_text を間違えるとExcelがクラッシュする

型コードと実際のDLL関数のシグネチャ（引数・戻り値の型）が一致しないと、メモリ破壊が起きてExcelごと強制終了することがあります。保存していない作業内容も失われるため、検証は必ず別ブックで行ってください。

2. 32bit/64bit の整合性

32bit版のExcelは32bit DLLを、64bit版のExcelは64bit DLLしか呼び出せません。同じファイル名のDLLでも、ビット数が合っていないと #VALUE! エラーやクラッシュの原因になります。

3. セキュリティリスク

任意のDLLを読み込めるということは、悪意あるDLLを指定された場合に任意コードが実行されるリスクがあるということです。出所不明のブックでREGISTER.IDが使われている場合は、内容を必ず確認してから開きましょう。

4. マクロ有効ブック（.xlsm / .xlam）でのみ使える

REGISTER.IDはマクロ機能の一部として扱われます。通常の .xlsx ファイルでは保存できません。.xlsm または .xlam、あるいは Excel 4.0 マクロシート（.xlm）から利用してください。

REGISTER.ID関数の代替手段（現代Excelでの推奨）

ここまで読んでお気づきのとおり、REGISTER.IDはとてもクセが強い関数です。Excel 2016 以降では、ほとんどのケースで次のいずれかの代替手段を使うほうが安全で生産的です。

代替1: VBAの Declare 文

VBA の Declare 文を使えば、DLL関数をモジュール内で宣言して使えます。型のチェックも比較的わかりやすく、現代的なエラー処理が組めます。

'--- Windows APIの GetTickCount を宣言 ---
Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long

Sub ShowTick()
    Dim lngTick As Long  ' --- 経過ミリ秒を受け取る変数 ---
    lngTick = GetTickCount()
    MsgBox "起動からの経過ミリ秒: " & lngTick
End Sub

64bit Excelでは PtrSafe キーワードが必須です。古いVBAコードを引き継ぐときも、まずDeclare文への置き換えを検討するのがおすすめです。

代替2: Office Scripts（Microsoft 365 / Excel for the Web）

Office Scripts は Microsoft 365 環境で動く TypeScript ベースのスクリプト機能です。クラウド連携やチーム共有が前提のため、現代的な業務自動化には Office Scripts が適しています。

代替3: Office アドイン（JavaScript API）

ブラウザでもデスクトップでも動くアドインを作りたい場合は、Office アドインの JavaScript API を使います。Web技術ベースなので保守人材も確保しやすい利点があります。

代替4: Power Query / Power Automate

外部APIや外部データソースと連携したいだけであれば、Power Query や Power Automate のほうが適しています。GUIで構築でき、メンテナンスも容易です。

TIP
「DLLを呼び出したい」という要件のうち、9割以上は上記4つのいずれかで解決できます。REGISTER.IDを新規導入する前に、まず代替手段を検討してください。

CALL関数・EUROCONVERT関数との違い

REGISTER.IDと混同しやすい特殊関数の違いを整理しておきます。

CALL関数の使い方や互換性については ExcelのCALL関数の使い方 を、EUROCONVERT関数については ExcelのEUROCONVERT関数の使い方 を、それぞれ参照してください。同じく特殊な統計関数として ExcelのNORMSDIST関数の使い方 も並べて読むと、互換性のために残されている関数群の全体像がつかみやすくなります。

まとめ

ExcelのREGISTER.ID関数は、登録済みのDLL/XLLの関数IDを返す上級者向けの特殊関数です。CALL関数と組み合わせて外部ライブラリを呼び出すための中間ステップとして使われます。Excel 2016 以降では VBA の Declare 文・Office Scripts・Office アドイン・Power Query などの代替手段が用意されており、新規利用はほぼ推奨されません。

この記事のポイントを振り返ります。

• REGISTER.IDは登録済みのDLL/XLL関数のIDを返す関数で、CALL関数とセットで使う
• 構文は =REGISTER.ID(module_text, procedure, [type_text]) の3引数
• type_text を間違えるとExcelごとクラッシュするため検証は別ブックで行う
• 32bit/64bitの整合性とセキュリティリスクに注意する
• 現代のExcelでは VBA Declare 文や Office Scripts などの代替手段の利用を推奨

レガシー資産の保守で出会う機会はあっても、新規開発で選ぶ場面はまずありません。「こういう関数があった」と仕組みを理解しておけば、古いブックを開いたときに慌てずに済みます。代替手段への置き換えを進めて、保守しやすい環境を整えていきましょう。