監査を耐え抜く会計APIの構築

オランダの企業が帳簿を預けたくなるような金融APIに不可欠な、セキュリティと監査コントロールの実践ガイド。

支払い処理のリクエストに対して単に 200 OK を返す会計APIは、何も語っていないに等しいです。台帳に仕訳が確実に記録されたこと、実行権限を持つアクターが操作したこと、金額のバリデーションを通過したこと、あるいは権限を持つ人物が承認したことのいずれも証明されていません。オランダのように、税務当局が記録の再構築可能性と7年間の保存を義務付けている市場では、「リクエストが成功したこと」と「帳簿が正しいこと」の間のこの乖離が、監査で指摘を受ける原因となります。

監査対応（audit-ready）とは、証明書ではなく運用の設計目標です。これは、APIが認証されたアクターから、認可されたアクション、バリデーション済みの状態変更、承認、台帳の結果、そして改ざんを検知できるエビデンスに至るまでの一連のチェーンを維持している状態を指します。以下に解説するすべての要素は、認証とTLSだけで十分だと思い込むのではなく、このチェーンを意図的に構築するためのものです。

会計APIが「監査対応」であるために必要な条件

監査人が取引を再構築する際には、一連の明確な疑問に答える必要があります。誰がそれを開始したのか。その権限があったのか。変更は会計上のバリデーションを通過したのか。誰が承認したのか。台帳には何が記録されたのか。その記録は後から痕跡を残さずに改ざんできないか。

APIが自身のログとデータモデルからこれら6つの質問すべてに答えられない場合、コードがどれほどクリーンであっても、それは監査対応とは言えません。ほとんどのAPIは最初の質問にはうまく対応できても、残りの部分はおざなりになっています。

このギャップを埋めるコントロールは、明確な会計状態、多層的な認可、スコープ付きの認証、冪等性（Idempotency）のある書き込み、サーバーサイドのバリデーション、職務分離、そして改ざん検知ロギングのいくつかのグループに分類され、これらは互いを補強し合います。認可が脆弱であれば、ログを実行したアクターがその作業を行う正当な権限を持っていたか信頼できなくなるため、強固な監査ログも台無しになります。

エンドポイントを設計する前に会計状態をモデル化する

最もよくある設計ミスは、すべての金融レコードを create、read、update、delete を持つ自由に編集可能なオブジェクトとして扱うことです。会計はそのようには機能せず、転記済みの仕訳がこっそり上書きされている場合、監査人は即座にそれに気付きます。

財務上重要なリソースには、それぞれ明確なステートマシンが必要です。仕訳や支払いは、通常、次のようなライフサイクルをたどります。

draft → submitted → approved → posted → settled

修正によってこの経路を逆戻りさせることはありません。誤った転記済みエントリには、リンクされた取消仕訳（reversal）または相殺調整を行います。元のエントリはそのまま保持されます。

実用的なルールの例:

下書き（Draft）は、権限を持つユーザーが編集できる。
提出済み（Submitted）のレコードは、許可されたロールのみが編集できるか、下書きに戻すことができる。
承認済み（Approved）のレコードは、制御された修正と新たな承認を必要とする。
転記済み（Posted）のレコードは、上書きや削除ができず、取り消しまたは調整のみ可能。
締め期間（Closed period）の変更には、昇格された権限、明確な理由、および監査イベントが必要。

転記済みエントリの編集といった不正な遷移の試みは、安定したエラーを返しつつ、同時に監査レコードを書き込む必要があります。失敗した試み自体もエビデンスとなります。

ここで、改ざん不可能な複式簿記の台帳が真価を発揮します。Nordletの台帳は、すべての取引がバランスの取れた永続的なエントリとして記録されるよう構築されており、コミット時にデータベーストリガーによって貸借一致が強制されます。また、修正は書き換えではなく取消仕訳を介して行われます。この制約は開発段階では厳しく感じられますが、監査の際には公認会計士からの信頼へと変わります。

認証だけでなく、すべてのリクエストを認可する

認証は「誰が」呼び出しているかを証明するものであり、その呼び出し元が特定の請求書、仕訳、または法的エンティティに触れてよいかどうかについては一切言及しません。OWASP API Security Projectが、リスクリストの最上位に「オブジェクトレベルの認可の不備」を挙げているのは、まさにAPIがオブジェクト識別子を露出させているためであり、チェックが欠落しているとテナント間の不正アクセスが容易になってしまうからです。

金融APIへのすべてのリクエストは、単なるトークンではなく、複数の要素を組み合わせて認可されるべきです。

認証されたアクター
クライアントアプリケーションまたはサービスアカウント
テナント
法的エンティティ
リソースID
要求された操作
現在のリソース状態
金額または取引のなしきい値

他のどの要素よりも重要な実用上のルールが2つあります。1つ目は、テナントとユーザーのコンテキストを認証済みIDから導出し、それと矛盾するクライアント提供のテナントまたはロールの主張（claim）はすべて拒否することです。呼び出し元が、自分がどの企業を代理しているかを勝手に主張できるようにしてはなりません。2つ目は、デフォルト拒否（deny-by-default）の原則を採用することです。ポリシーによって明示的にアクションが許可されていない限り、失敗させます。

両方の方向でテストを行ってください。あるテナントが別のテナントのデータにアクセスする水平方向のアクセスと、一般ユーザーが承認、転記、またはエクスポート機能にアクセスする垂直方向のアクセスです。どちらも頻繁に発生し、会計データにおいては致命的な結果を招きます。

Nordletのロールモデルは、1つのアカウントの下にある複数の企業に対して、オーナー、管理者、会計士、マネージャー、開発者、閲覧者の各ロールを備えており、この分離を単なる理想論ではなく強制可能なものにするために存在します。下書きの請求書を作成できる開発者ロールに、支払いの実行権限を持たせてはなりません。

CRUD動詞ではなく、ビジネス機能ごとにトークンのスコープを絞る

委任アクセスには、再利用可能なパスワードや広範な静的APIキーではなく、最新のOAuth 2.0セキュリティガイドラインを使用してください。RFC 9700は現在のベストカレントプラクティス（BCP）であり、クライアントと認可サーバーに対して、検証済みのリダイレクトURI、必要に応じたPKCE、発行者とオーディエンスのチェック、アクセストークンの短い有効期間、およびリフレッシュトークンのローテーションと無効化という明確な要件を定めています。

スコープの決定は、会計特有の思想が表れる部分です。read や write のような汎用的なスコープは、職務分離の観点からはほとんど役に立ちます。スコープはビジネス上の機能（capability）にマッピングされるべきです。

journal:create と journal:approve は個別のスコープとする。
支払い指示の作成権限は、支払いの実行許可を意味しない。
一括エクスポートはデータ漏洩の経路となるため、エクスポート権限は読み取り権限とは区別する。

特定の製品がそのスケール上のどこに位置するのかを明確にしてください。NordletのAPIキーは、各アクションでチェックされる sales:read や sales:write などのモジュールごとのスコープを備えており、これによりモジュールの分離、および読み取りと書き込みの分離は実現できますが、作成と承認の分離まではカバーしていません。より厳密な分割が必要な場合は、呼び出しの前に独自のサービス側で強制してください。

高価値の操作に対しては、FAPI 2.0 Security Profileが適用できるかどうかを検討する価値があります。これは機密性の高い金融データを保護するAPI向けに設計されており、ベースラインのOAuthよりも強力な保証を提供します。中小企業向け会計システムの連携のほとんどはプロファイル全体を必要としませんが、支払い実行や銀行連携のフローでは検討すべき対象となります。

Nordletが提供する、ワンタイムのメールリンクによるパスワードレスサインインは、人間にとっての再利用可能なパスワードの問題を解消し、ローテーション、漏洩、フィッシングの対象となる認証情報をひとつ減らします。

金融データの書き込みに冪等性を持たせる

ネットワークはリクエストの途中で失敗します。クライアントが支払い指示を送信し、レスポンスが届く前に接続が切断された場合、クライアントは再試行を行います。保護措置がなければ、2重の支払いが実行されてしまいます。

冪等キー（Idempotency key）はこの問題を解決します。クライアントは書き込みごとに一意のキーを送信し、サーバーはそのキーと結果を記録します。同じキーによる再試行があった場合、2つ目のエントリを作成する代わりに元の結果を返します。Nordletは、すべての変更を伴う呼び出しにおいて Idempotency-Key ヘッダーを受け付け、同じペイロードでの再試行に対しては保存されたレスポンスを再送し、ペイロードが変更されている同じキーについては拒否します。この機能を省略した会計APIは、最終的に誰かが手作業で解きほぐさなければならない重複した台帳エントリを必ず生み出すことになります。

これをサーバーサイドのバリデーションと組み合わせてください。借方と貸方が一致しているか、国や期間に対してVAT（付加価値税）の税率が妥当か、アカウントが存在するかといったチェックをクライアントに任せてはなりません。バリデーションは、状態遷移の前にサーバー上で実行され、拒否された書き込みは安定したエラーと監査レコードを生成します。

改ざん検知監査証跡とオランダの保存義務

監査ログはエビデンス層であり、通常のビジネスデータとは異なる要件を持っています。監査ログには、シークレットや完全な支払い認証情報を決して記録することなく、認可の決定、ポリシーバージョン、アクター、オブジェクト、操作、変更前後の状態、および理由コード（reason code）が記録される必要があります。

最も重要な特性は、改ざん検知（tamper-evident）です。管理者が監査レコードをこっそり編集や削除できてしまっては、ログは何の証明にもなりません。追記型（append-only）ストレージ、暗号学的チェーニング、あるいは一度書いたら変更できない（WORM）保存は、すべてこの問題に対処するものです。重要な点は、いかなる改変も検出可能でなければならないということです。

保存期間（retention）については、ビジネスデータの削除とは別の独自のポリシーが必要です。オランダでは、行政上の記録の一般的な保存期間は7年であり、不動産に関する記録は10年に及びます。通常のデータ削除やGDPRに基づく消却ワークフローによって、法的保存ルールの対象となっている記録や監査証跡が破棄されてしまうことがあってはなりません。監査エビデンスに関する法的保留（legal hold）、アーカイブ、および削除のルールを個別に定義し、運用している管轄区域にマッピングしてください。

期間ロック（period locking）は、会計レイヤーでこれをサポートします。ひとたび月次が締められたら、昇格された権限と記録された理由がない限り、その中のエントリを変更することはできません。Nordletは期間ロックを強制するため、締められた月は閉じられたままとなり、API経由であってもロックされた期間内に日付を持つ仕訳の転記はすべて拒否されます。これはオランダの監査人が真っ先にチェックするポイントの1つです。

エッジの保護：Webhooks、エクスポート、インテグレーション

コアAPIは通常、システムの中で最も厳重に防御されている部分ですが、エッジ部分は脆弱になりがちです。

Webhooksは偽造リクエストのリスクを孕んでいます。sale_invoice.paid のようなイベントは、受信者が自社からの送信であることを検証できるように署名されるべきであり、受信側は少なくとも1回（at-least-once）の配信を前提としてイベントIDによる重複排除を行う必要があります。Nordletは、生ボディに対するHMAC署名によって各Webhookの配信に署名し、失敗した配信は指数バックオフで再試行するため、受信側は厳密に1回（exactly-once）の配信を仮定するのではなく、署名の検証とイベントIDによる重複排除を行う必要があります。

エクスポートはバルクデータ漏洩の経路となります。XLSX、PDF、またはJSONでのレポートエクスポートは、1回の操作で大量の財務データを引き出すため、独自の権限、レート制限、および監査ロギングが必要です。利用するサードパーティ製インテグレーションは信頼できない入力として扱い、直接のクライアントリクエストと同じ方法でバリデーションを行ってください。

オランダ向け会計APIの監査対応チェックリスト

統合が監査対応済みと主張する前に、以下を確認してください。

すべての金融リソースに明確なステートマシンが存在し、転記済みエントリの上書きができないこと
すべてのリクエストにおいてオブジェクトレベルおよび法的エンティティの認可がデフォルト拒否で適用されていること
テナントおよびロールのコンテキストがクライアントの主張ではなくトークンから導出されていること
RFC 9700に準拠したOAuth 2.0、機能ベースのスコープ、作成と承認の分離があること
職務分離が単なる文書化だけでなくロールで強制されていること
すべての金融データの書き込みに冪等キーが存在すること
状態遷移の前にサーバーサイドで会計およびVATのバリデーションが実行されること
理由コード付きの、追記型で改ざん検知可能な監査ログがあること
保存および法的保留のルールがオランダの期間（通常7年、不動産は10年）にマッピングされていること
締められた月に対する期間ロックがあること
重複排除機能を備えた署名済みWebhook、スコープとレート制限が設定されたログ付きのエクスポートがあること

私たちが最初に構築する機能

明日オランダのプラットフォームに会計機能を組み込むとしたら、ビジネス用のエンドポイントを1つも書く前に、まず状態モデルとオブジェクトレベルの認可から始めます。これら2つの決定事項はその後のすべてに制約を課すため、仕訳エントリを編集可能な行として扱ってきたシステムにこれらを後付けするのは非常に困難です。次に冪等性と監査ログを実装します。これらは早い段階で追加するコストは低いものの、データが流れ始めてから追加しようとするとコストが高くなるためです。

残りの機能（スコープ付きトークン、署名済みWebhook、期間ロック）は、基盤がしっかりしていればより容易に追加できます。これらすべての機能は、本番データに触れる前にサンドボックス企業に対して検証することができます。

FAQ

監査対応APIがあるということは、ビジネスがコンプライアンスを満たしているということですか？

いいえ、この点については明確にしておく必要があります。監査対応とはシステムの設計上の特性です。つまり、監査が成功するように台帳、コントロール、エビデンスチェーンが構築されているということです。特定の税務、会計、セキュリティのフレームワークへのコンプライアンスは、それらのコントロールを特定の基準にマッピングする別の評価です。よく構築されたAPIはコンプライアンス作業を容易にしますが、それ自体がコンプライアンスを代替するものではありません。

オランダでは会計記録をどのくらいの期間保存する必要がありますか？

一般的な義務は行政上の記録については7年間であり、不動産に紐づく記録については10年に延長されます。通常の削除ワークフローでは上書きできない保存および法的保留のルールを構築してください。

金融系インテグレーションにおいて、静的APIキーだけで十分ですか？

スコープが限定されたサーバー間の自動化であれば機能しますが、再利用可能な静的キーはローテーションが難しく、万が一漏洩した場合には危険です。委任アクセスや人間が関与するフローでは、有効期間が短く、機能スコープが設定されたOAuth 2.0の方がより強力な選択肢となります。

なぜ会計において特に冪等性が重要なのですか？

ほとんどのシステムにおいて重複した書き込みは単なる煩わしさで済みますが、会計における重複した書き込みは帳簿上の数値の狂いを意味し、誰かがそれを探し出して修正しなければならないためです。冪等キーは、再試行を危険なものではなく安全なものにします。