財務チームが財務データを漏らさずにAI製アプリを導入する方法

セキュリティ企業RedAccessが、AIコーディングツールで作成され、そのツール自身のホスティングで公開されたアプリを調べたところ、セキュリティ対策や認証がほとんどないものが5,000件以上見つかりました。同社がWiredに共有した画面には「さまざまな他社の各種売上記録や財務記録」も含まれていました。財務チーム向けAI製アプリも、同じような誰でもアクセスできるアドレスに置かれ、その先で元帳、給与、未発表の業績が公開されるおそれがあります。

ReplitのCEO、Amjad Masadは「公開アプリにインターネットからアクセスできるのは想定された動作です」と答えました。仕組みについては、その説明は正しいものです。私の解釈では、この露出は公開範囲の設定と省略されたレビューによって生じており、どちらもツールを作成した人が対応できる問題です。

要約

• AI製財務ツールは、作成者が対応できる6つの導入ミスによってデータを漏らす可能性があります。公開リンク、コードやチャット履歴に残されたパスワードとキー、管理者権限でのデータベースアクセス、第二の承認者を介さない帳簿への転記、外部サービスへのデータ送信、記録されていない計算の変更です。
• 各ミスには対策があり、その多くはアプリを作ったのと同じAIツールで実施できます。また、データベースが書き込みを拒否する、古いパスワードが使えなくなるといった、対策が機能したことを証明する簡単な確認方法があります。
• 財務ツールは原則としてプライベートネットワークに置き、財務部門以外の人が利用する場合は会社のログインを追加します。第二の承認者なしに元帳へ転記する、カードデータに触れる、SOXの対象となる財務諸表に数値を渡す場合は、IT部門に引き継ぎます。
• サーバーのリージョンはアプリの主要なVPSストレージの所在地を決めますが、バックアップ、ログ、第三者サービスが別の場所にコピーを作る場合があります。構成全体が規則に適合するかどうかは別の問題です。地域の制度をコンプライアンスチームに確認してください。

財務データを漏らす導入ミス

AI製財務ツールは6つの導入ミスによってデータを漏らす可能性があります。公開リンクに置いたままにする、認証情報をコードやチャットに保存する、読み取り専用で足りるのに管理者権限で接続する、第二の承認者なしに転記する、財務データを外部サービスに送る、記録なしに計算を変更することです。いずれも、デモでは便利に見える初期設定です。

以下の各対策には、アプリを作成したAIツール向けのプロンプトがあります。貼り付ける前に角括弧内を書き換えてください。プロンプトは本記事のために書いた未検証の出発点です。AIツールが変更したと報告しても、それだけでは何も証明しません。証明になるのは各プロンプトの下にある確認です。コードとサンプルデータまたは合成データを使って実行し、実際の記録や有効なキーをチャットに貼り付けないでください。

AIビルダーの公開リンクにツールを置いたままにする

AIビルダーのホスティングで公開された資金予測ダッシュボードは、アドレスを知っている誰でも開けます。そこに表示される買掛金の年齢分析、予算対実績、発表前の四半期業績も同様です。RedAccessの調査結果に関するWiredの記事では、研究者がAI提供企業のドメインをGoogleやBingで単純に検索し、こうしたアプリを発見したと説明しています。

一部のアプリは、訪問者に任意のメールアドレスでログインすることしか求めていませんでした。どんなメールアドレスでも受け付けるログインはアクセス制御ではありません。

実データを提供企業のホスティングから撤去してください。管理するサーバーでツールが動くまで、導入先については次の節で説明しますが、合成データセット、またはERPに備わっていればそのサンドボックスやテスト用会社で作成とデモを行い、実データのエクスポートを使わないでください。ホストされたアドレスは最後にデプロイしたバージョンを配信するため、変更後には再デプロイしてください。

このアプリが読み取るテーブルと列に一致する合成データセットを作成してください：[テーブルと列を列挙。例：vendors、invoices、journal_lines]。

架空の仕入先名と顧客名、架空の銀行口座番号、実際の帳簿と同じ整合性を持つ[通貨]の金額を使ってください。すべての仕訳の貸借が一致し、補助元帳の合計が[買掛金／売掛金の統制勘定]と一致するようにしてください。

実データのエクスポートではなく、このデータセットを参照するようにアプリを設定し、変更したすべてのファイルと設定を列挙してください。

実際の記録を私に要求しないでください。

機能したことを確認：ログアウトしたブラウザーで提供企業がホストするアドレスを開くか、財務部門以外の同僚に開いてもらい、合成データだけ、ログイン画面だけ、または何も表示されないことを確認します。次に、実際のERPから選んだ3つの仕入先名または顧客名をアプリのデータファイルとリポジトリで検索し、一致がないことを確認します。最後に、アプリの試算表または集計画面で借方合計と貸方合計が等しいことを確認します。

ERP、銀行データ連携、データベースの認証情報をコードやチャットに残す

有効な認証情報がそこに保存されていると、チャット履歴、リポジトリ、MCP設定ファイルを読める人が、それを使ってERP、財務データベース、銀行データ連携にもアクセスできる可能性があります。MCPはClaudeなどのAIツールがERPやデータベースと直接やり取りするためのコネクターであり、その設定ファイルもパスワードが残り得る場所です。

GitGuardianのState of Secrets Sprawl 2026は、MCP設定ファイルで24,008件の固有のシークレットが露出しており、その14%がPostgreSQLデータベースの接続文字列だったと報告しています。同じ報告では、公開GitHubコミットにおいて、Claude Codeが共同作成したコミットのシークレット漏えい率は基準値の約2倍であり、人間の要因も依然として重要だとしています。

チャットメッセージを削除しても露出は取り消せません。チャット、リポジトリ、その履歴のコピーを持つ人には値が残っています。それらの場所に一度でも置いたすべてのパスワード、キー、トークンについて、ERP、データベース、銀行データ連携の管理コンソールで新しいものを発行し、古いものを無効化してください。これが認証情報のローテーションです。

その後、アプリは起動時に環境変数、つまりコードの外部に保持する名前付きの設定から認証情報を読み取ります。環境変数は、サーバー上でアプリをビルドして実行するツールであるデプロイ層が提供します。複数のツールでシークレットを共有し、1か所からローテーションする必要がある場合は、HashiCorp Vaultが次の選択肢です。

チームの人が保管するパスワードのコピーは、Vaultwardenなど、人の利用を想定したパスワードマネージャーに置きます。実行中のアプリは環境から値を読み取ります。まず、AI生成コードに含まれるハードコードされたシークレットをすべて見つけてください。

このプロジェクトにハードコードされたシークレットがないか監査してください。.envファイル、ノートブック、MCP設定ファイル、[ERP名／銀行データ連携プロバイダー／財務データベース]に接続するコードを含め、すべてのパスワード、APIキー、アクセストークン、接続文字列を見つけてください。

コード内の各値を名前付きの環境変数に置き換え、変数名の一覧を提示してください。

実際の値を含むファイルがリポジトリにコミットされないようにし、リポジトリの履歴でそれらの値が現れるすべてのコミットを列挙してください。

場所だけを示してください。シークレットの値を出力しないでください。

機能したことを確認：古いパスワードやトークンを自分で試すかIT部門に依頼し、拒否されることを確認します。次に、現在のプロジェクトファイルで古い値を検索し、残っていないことを確認します。履歴に残る一致がアクセス権を与えなくなるのは、その値の失効または期限切れを確認してからです。

読み取りだけが必要なツールに作成者の管理者ログインで接続する

売掛金の年齢分析を表示するダッシュボードが総勘定元帳を編集できてはいけません。ツールが作成者の管理者ログインで接続すると、そのアカウントの権限を引き継ぎます。Supabaseのsecretキーや旧service_roleキーは、プロジェクトのデータに昇格したアクセス権を与え、Row Level Securityを迂回するため、通常の読み取り専用アクセスに使うべきではありません。1つの年齢分析表のためのレポートが、給与テーブルを含む総勘定元帳全体を露出させることになります。

大きな損害につながるのは書き込み側です。Supabaseを使う1,072件のAI製アプリに対するSymbiotic Securityの調査では、認証なしに誰でも記録を削除できるものが172件、既存の記録を変更できるものが172件、公開キーを持つ誰でもテーブル全体を読めるものが39件見つかりました。

ツールには、読み取るテーブルに限定した読み取り専用の認証情報を与えてください。ERPやデータベースでは、これは専用の連携ユーザーを意味します。ツール用に作った別アカウントで、レポートに必要なオブジェクトの読み取りだけを許可します。Supabaseでは、ツールが使うすべての公開対象テーブルでRow Level Security、つまり各リクエストが見られる行を決めるデータベース規則を有効にし、テーブルへの権限付与も確認してください。権限付与は、ロールがselect、insert、update、deleteを実行できるかを決めます。読み取り専用の財務アプリのロールには、不要な書き込み操作を与えるべきではありません。RLSと最小権限の設定が正しければ、publishableキーはブラウザーのコードに置けます。secretキーと旧service_roleキーはサーバー側に保持し、昇格したアクセス権が本当に必要で、独自に認可を強制するバックエンド処理専用にしてください。

注：Supabaseのpublishableキーや旧anonキーがページのJavaScriptで見えること自体は正常です。SupabaseのAPIキーのドキュメントによれば、アクセスできるのはRow Level Securityが許可する範囲だけです。secretキーはRow Level Securityを迂回するため、ブラウザーに送るものには絶対に含めないでください。

このアプリが[ERPまたはデータベース名]に対して行うすべての読み取りと書き込みを、テーブルまたはオブジェクトごとに列挙してください。

アプリが[必要なテーブル]だけを読み取り、環境変数で提供される別の読み取り専用認証情報で接続するよう変更してください。私個人のログインを使わないでください。

アプリがSupabaseを使う場合は、アクセスするすべての公開対象テーブルでRow Level Securityを有効にしてください。anonとauthenticatedに対するselect、insert、update、deleteの権限付与を列挙してください。この読み取り専用アプリに不要な書き込み権限は削除し、別の本番アプリが依存している場合は変更せずに指摘してください。次に、未ログインの訪問者は何も読めず、ログイン済みユーザーは[規則。例：自分のコストセンターの行]だけを読めるポリシーを作り、ブラウザーへ送るどのファイルにもsecretキーや旧service_roleキーが含まれないことを確認してください。

作成したポリシーを列挙してください。

機能したことを確認：ツールの認証情報を使い、テスト記録の編集などの書き込みを1回試して、拒否されることを確認します。Supabaseでは、ログアウトした状態で財務テーブルの行を要求し、空の結果またはエラーになることを確認します。

第二の承認者なしにツールから元帳へ転記する

直接転記する仕訳インポーターや、銀行へ直接送信する支払ファイル生成ツールは、実行者を作成者と承認者の両方にしてしまいます。1つのバグで1か月分の見越計上額が重複し、1つのフィールド変更で仕入先への支払いが間違った口座へ送られます。これは財務部門が2人の間でも認めない職務分掌違反であり、AIアシスタントで作ったソフトウェアにも例外はありません。

損害はアプリ内にとどまりません。不正なバッチが帳簿に入り、取り消すには修正仕訳と決算時の説明が必要になります。ツールが作成者自身のログインで転記していれば、重複したすべての仕訳に作成者の名前が付きます。

AI製ツールは読み取りと準備を行い、転記と支払の実行はERP自身の承認ワークフローで、ツールを実行した人とは別の人が承認します。私が携わった会計エンジンはすべて、仕訳と承認を2人の責任者による2つのイベントとして扱っており、AI製ツールにも同じ扱いが必要です。

実際には、直接転記する各処理を、ERP内で承認を待つ下書き仕訳または一時保存されたインポートに変えてください。ツールは引き続きマッピング、検証、バッチ作成という面倒な部分を担い、承認は決算に必要なほかの承認と並んでERP内に残ります。ERPにインポートの承認段階がなければ、ツールの出力をファイルにし、第二の担当者がバッチ集計と照合して自分でインポートします。

自動転記、支払ファイル生成、仕入先の銀行情報変更が必要なツールは、次の節の条件に従ってIT部門が担当すべきです。

このアプリが[ERP名]で[仕訳／請求書／支払]を作成、編集、転記するすべての箇所を列挙してください。

各処理を、転記前に[ERP名]で承認が必要な下書き仕訳または一時保存されたインポートを作るよう変更してください。[ERP名]にインポートの承認段階がなければ、代わりにインポート用ファイルを生成し、何も転記しないでください。

その承認なしに転記または支払を実行するコード経路をすべて削除してください。

各バッチについて、行数、借方合計、貸方合計を含む集計を作成してください。

まだ直接転記するものをすべて列挙し、私が確認できるようにしてください。

機能したことを確認：サンプルデータからバッチを1つ実行します。ERPで第二のユーザーが承認するまで、何も転記済みになってはいけません。その後、バッチ集計をERP上のそのバッチと比較し、行数、借方合計、貸方合計が完全に一致することを確認します。1行の差も照合失敗であり、丸めの問題ではありません。

管理できない外部サービスに財務データを送る

総勘定元帳の全抽出データをAI APIへ送る差異説明機能は、全行を第三者へ送信します。ほかにも目立たない2つの経路があります。訪問ごとに提供企業へ報告するページ内の分析スクリプトと、リクエスト本文全体を保存するエラートラッカーやログです。そこに給与の明細、顧客の銀行情報、発表前の数値が残ることがあります。

財務部門が作る社内ツールでは、サービスと具体的なデータフローが組織のベンダー、セキュリティ、コンプライアンスの手続きで明示的に承認されていない限り、発表前の業績と給与を第三者への呼び出しに含めないでください。それ以外についても、すべての送信先を列挙し、各呼び出しには必要なフィールドだけを送ります。外部サービスが受信データを保存したり学習に使ったりするかは、ベンダー契約に署名する担当者が、そのベンダー自身の条件に照らして確認すべき問題です。利用頻度を知りたい場合は、Umamiのようなセルフホスト型分析ツールならページ閲覧の情報を自社サーバーに保持できます。

AI API、分析スクリプト、エラー追跡、メール、Webhook、ログファイルを含め、このアプリが[自社サーバー]の外へデータを送るすべての箇所を列挙してください。

送信先ごとに、受け取るフィールドを正確に列挙してください。

[給与額／銀行口座番号／発表前の業績／顧客名]を含むものをすべて指摘してください。

指摘した各項目について、送信するフィールドを減らすか送信しない方法を示し、私が確認した後にだけ変更してください。

機能したことを確認：判別しやすい架空の口座番号と給与額を含むサンプルデータで、各機能を1回実行します。エラートラッカーとログで両方の値を検索し、見つからないことを確認します。AI APIの経路では、このサンプル実行中にアプリからの送信リクエスト本文をログに記録させ、同じ2つの値がなく、承認したフィールドだけが含まれることを確認します。その後、このログ記録を無効にしてください。

記録も照合もなく計算を変更する

見越計上額の計算ツールや収益ウォーターフォール（revenue waterfall）の検証ツールでは、コードそのものが統制です。数式を1つ変えると決算に使われる数値も変わり、バージョン管理がなければ誰が何をいつ変更したのか分かりません。

Claude Codeで作った社内ツールについてのCPA事務所のr/ClaudeAIスレッドで、あるコメント投稿者は限界を率直に述べています。「『会計士＋claude code』は監査証跡の要件にぶつかるまでは機能する。そこが本当の限界だ。」

変更する前に現在の動作を固定してください。出力を固定すれば、合計が気付かないうちにずれることなくロジックを改善できます。コードをバージョン管理に置き、各変更を作成者と日付とともに記録します。

固定したサンプルファイルでツールを実行し、記録した基準値と結果を比較するテストを作り、変更のリリース前に照合を通過させてください。固定されたテストは誤りも含めて記録したものを守るため、信用する前に基準値の合計をその期間のERPの合計と照合してください。

計算ロジックの変更には第二の担当者のレビューを必須とし、本番での各実行をERP自身の合計と照合してください。

まだバージョン管理されていなければこのプロジェクトを管理下に置き、計算ロジックを含むファイルを列挙してください。

[サンプルファイル]でアプリを実行するテストを作り、現在の出力である[勘定／会社・事業体／期間]ごとの行数と合計を記録してください。

記録した出力を保存する前に、[期間]の[ERP名]と照合できるよう合計を示してください。

いずれかの合計を変える変更は、必ずテストを失敗させるようにしてください。

テストの作成中は計算ロジックを変更しないでください。

機能したことを確認：例えば丸め規則など、計算を1つ意図的に変更し、テストが失敗することを確認します。変更を元に戻し、すべてのテストが再び成功することを確認します。

原則非公開、利用者が増えたら会社のログイン、元帳はIT部門へ

実際の財務データをAIツールのホスティングに置いたままにしてはいけません。財務チームだけが安全にAI製財務アプリを使うには、プライベートネットワークからだけアクセスできる、自分たちが管理するサーバーに置きます。チーム外の人が必要とする場合は会社のログインを追加し、以下の一覧のどれかに該当すればIT部門へ引き継ぎます。

VPSはOSとソフトウェア構成を自分で管理できる、レンタルの仮想サーバーです。プライベートネットワーク、Tailscaleの用語ではtailnetは、承認された端末をそのサーバーに接続します。ツールを公開インターネットから切り離すには、例えばサーバーのファイアウォールでアプリへの公開着信アクセスを遮断し、VPNまたはtailnetのインターフェースだけに公開する必要があります。IDプロバイダーは会社のユーザーアカウントを管理し、リバースプロキシはアプリの手前で全リクエストを先にログイン処理へ通す門番です。

最初のミスで説明した理由により、AIツール自身のホスティングは表に含めていません。Northflankのような企業向け導入プラットフォームも同様です。そうしたものは、プラットフォーム提供企業と必要な審査の予算をすでに確保している大規模組織に適しています。少人数が使う部門用ツールには、そこまでの契約は必要ありません。

私の経験では、2つのプライベートネットワークの選択肢のうちTailscaleの方が導入が速いものの、Tailscaleは調整サービスを自社でホストしています。完全にセルフホストできる選択肢はWireGuardです。

プライベートネットワークを標準にする理由は、インターネットに応答しないツールは検索で発見されず、ログインページを攻撃されることもないからです。一方、AIツールが書いたログインページの品質は、その背後のAI生成コードに左右されます。プライベートネットワークの外に公開する必要がある場合、会社のログインは管理された認証層を手前に追加します。そのため、これを第二段階にしています。

予算責任者にアクセスが必要になったら、ツール自身のログインを会社のログイン、つまりシングルサインオン（SSO）に置き換えます。既存の会社アカウントを使うため、そのアカウントを無効化すれば新しいログインを防げます。既存セッションが残らないよう、セッション失効、バックチャネルログアウト、または十分に短いセッション有効期間を設定してください。プロンプトでは、AuthentikとKeycloakの両方が対応する標準ログインプロトコルOIDCを使います。

OIDCを使い、[Authentik／Keycloak／自社のIDプロバイダー]を通じた会社のログインに、このアプリ自身のログインを置き換えてください。

ログイン情報から各ユーザーのグループを読み取ってください。

[給与ページ]は[グループ名]のメンバーだけに許可し、メニューだけでなく、すべてのページ、エクスポート、APIエンドポイントについてサーバー側でその規則を強制してください。

有効なログイン情報を伴わないリクエストをすべて拒否してください。

機能したことを確認：グループに属さないテストアカウントでログインし、制限対象ページとそのエクスポートまたはAPIアドレスを直接要求して、両方が拒否されることを確認します。次に、IDプロバイダーでテストアカウントを無効化し、新しいセッションを開始できないことを確認します。既存セッションも、設定した時間内に失効または期限切れになることを確認してください。

チームで管理し続けるべきでないツールもあります。以下のいずれかに該当する場合、ITまたはエンジニアリング部門へ引き継いでください。

1. ERPで人が承認することなく、総勘定元帳やほかの正式記録システムへ転記する。
2. 支払ファイルを生成する、支払いを実行する、仕入先の銀行情報を変更する。
3. 出力がSEC登録企業の財務諸表に使われ、財務報告に係る内部統制（ICFR）の対象になる可能性がある。決算に使う前に内部監査へ相談してください。SOX第404(b)条の対象となる発行体では、外部監査人も関連する統制を検証する場合があります。
4. 支払カードデータを保存、処理、送信する。
5. 個人の信用力をスコア化する。
6. パッチ適用、アクセス権のレビュー、廃止の責任をチームの誰も引き受けない。

6番目の条件は見た目以上に重要です。セルフホストでは更新、バックアップ、監視を自分たちが担当します。誰も保守しない財務ツールはIT部門に任せる方が安全です。IT部門の対応は遅いかもしれませんが、それがこれらの条件に必要なガバナンスの代償です。

段階1と2では、利用者がツールを開く前にサーバー、デプロイ層、プライベートネットワーク、段階2ならIDプロバイダーを用意する必要があります。エンジニアのいない財務チームは自分たちで構築しなければなりません。当社のLinux VPSではrootアクセスが使えます。CoolifyとWireGuardはワンクリック導入が可能で、Tailscaleは公式の1コマンドインストーラーで導入でき、Authentikは公式のDocker Compose構成で動作します。そのため、導入基盤を一から組み立てる代わりに、上記の対策へ時間を使えます。当社の拠点にはEUのフランクフルトとアムステルダム、英国のロンドン、米国の複数都市があり、アプリの主要なVPSストレージのリージョンを選べます。その選択が認められるかの判断はコンプライアンス担当に委ねられます。

地域別にコンプライアンスチームと確認すべき規則

適用される制度は、ツールが扱うもの、会社の所在地、データに含まれる人の所在地によって異なります。EU従業員の給与を含むテーブルと、米国上場企業の財務諸表へ数値を渡す収益明細には、異なる制度が適用される場合があります。

本記事は法律上の助言ではありません。以下の表はコンプライアンスチームに相談すべき制度を示すもので、あなたに適用されるかどうかを判断するものではありません。

SOXの行にあるAS 2201は、Sarbanes-Oxley法第404(b)条が言及する監査人の証明に関するPCAOBの基準です。監査人が不正リスクに対応する際に評価する統制には、期末財務報告プロセスでの仕訳と修正に関する統制が含まれると明記しています。これらの地域以外では、まず自国のデータ保護当局の公式サイトを確認してください。サーバーの所在地は主要ストレージの場所を決めますが、すべてのバックアップ、ログ、第三者のコピーがどこにあるかは示しません。また、それだけで上記の制度を満たすわけではありません。

よくある質問

Vibe Codingは財務ツールに安全ですか？

デモで残る不足を埋めれば、安全にできる場合があります。私は証拠を、コーディングより導入の問題として捉えています。財務ツールはERPを読み取り、帳簿へ書き込めるため、個人プロジェクトよりリスクが高くなります。第二の承認者なしに転記する、支払いを扱う、カードデータに触れる段階になれば、IT部門が担当すべきです。

財務部門におけるShadow AIとは何ですか？

Shadow AIとは、IT部門の認知や承認なしに会社のデータで使われるAIツールやAI製アプリです。例えば、IT部門が一度も見たことのないERP接続の予測ダッシュボードです。IBMの2025年Cost of a Data Breach Reportでは、Shadow AIの利用が多い組織の漏えいコストは、少ないか利用がない組織より平均で$670,000高かったとしています（IBMの発表による）。

内部監査や外部監査人には何を示すべきですか？

決算で使う前に4つを準備します。実行場所とアクセスできる人、出力を固定したテストを含む変更履歴、ERPで転記が承認される方法、各バッチがERPの合計と一致する照合証拠です。監査人が何を要求するかは監査人の判断ですが、これらが具体的な評価材料になります。

作成者が異動や退職をした後、AI製財務ツールは誰が担当しますか？

稼働開始前に財務部門の責任者と技術担当の連絡先を決めてください。作成者個人のログインではなくサービス用認証情報で実行し、会社のログインを通じてアクセスさせます。退職者の会社アカウントを無効化すれば新しいログインが止まり、既存セッションは方針に従って失効させるか期限切れにします。廃止時には認証情報を無効化し、保存方針で必要なものを残し、それ以外を削除して停止します。