GitHubは顧客資料の置き場所ではない|AIエージェント経理を安全に動かす作業環境

AIを経理業務に使うとき、本当に大事なのは「どのAIを選ぶか」ではありません。AIが何を読み、どこで作業し、どこに保存し、誰が確認するのか――その「仕事場」の設計です。仕事場のないまま働かせれば、優秀なAIほど危険になります。JGA税理士法人では、GitHubを単なるファイル置き場ではなく、AIエージェント経理の「作業ルールを管理する仕事場」として設計しています。本コラムでは、その考え方と実際の作り方をご紹介します。

1. あの事案は「GitHubは危ない」という話ではない

2026年、マネーフォワード社は、GitHubへの不正アクセスが発生したことを公表しました。公式発表では、GitHubの認証情報が漏えいし、その認証情報を使って第三者がリポジトリをコピーしたこと、またリポジトリ内のファイルに含まれていた個人情報の一部が流出した可能性があることが説明されています。一方で、本番データベースからのお客様情報の漏えいは確認されていない、とも説明されています。

この報道を受けて、「GitHubというのは危ないものらしい」という受け止め方をされた方も多いと思います。しかし、少し立ち止まって考えてみてください。事務所に空き巣が入り、机の上に置きっぱなしだった通帳が持ち出されたとき、悪いのは「机」でしょうか。問われるべきは、通帳を金庫ではなく机の上に置いていた運用と、事務所の鍵の管理のはずです。

ここを間違えてはいけません。

この事案の教訓は「GitHubをやめよう」ではありません。「GitHubの中に何を入れるか」「鍵(認証情報)をどう管理するか」を設計しないまま使うことが危険だ、ということです。そして皮肉なことに、AIを業務で使う時代にこそ、GitHubのようにルールを整理し、変更履歴を残し、確認してから反映できる場所が必要になります。

2. AIに仕事をさせるには「仕事場」が要る

AIエージェントは、よく「優秀な新人」に例えられます。飲み込みは早いのに、放っておくと自己流で進めてしまう新人です。皆さまの事務所や経理部門で新人を迎えるとき、何を用意するでしょうか。座る机、読むべきマニュアル、書類の保管ルール、そして「ここから先は上司の決裁」という線引き。実は、AIに必要なものもまったく同じです。

チャット画面でAIに毎回口頭指示を出すやり方は、マニュアルのない職場で新人に毎回口頭で仕事を教えるのに似ています。教える人によって内容がぶれ、言った言わないが残らず、間違った教え方をしても気づけません。そこで必要になるのが、誰が見ても同じルールがあり、変更すれば履歴が残り、危ない変更は確認してから反映される場所――つまりAIの仕事場です。GitHubは、もともとソフトウェア開発者がプログラムをこの方式で管理するために使ってきた仕組みで、この仕事場づくりに最も向いています。

図 1 AIの仕事場の見取り図――ルールはGitHub、顧客資料はGitHubの外

GitHub(非公開設定)=ルールの置き場

  • AIが最初に読む基本方針
  • 業務マニュアル・手順書
  • 設定ファイルの「ひな形」
  • チェックリスト・各種テンプレート
  • 重要ファイルのレビュー担当の指定

顧客資料の保存場所(GitHub管理外)

  • 顧客資料・証憑
  • 会計データ・AI処理の実ログ
  • 顧客ごとの引き継ぎメモ
  • 承認記録・認証情報
AIエージェントは、左の「ルール」を読んで働き、右の「資料」は必要な範囲だけ参照する
登録・更新・外部送信の前には、必ず人間の確認・承認を挟む
会計の正本はあくまでクラウド会計・証憑・顧客回答・税法/会計基準。AIの出力は下書きと確認材料
図1|仕事場の全体像。2つの置き場を物理的に分け、決して混ぜないことがすべての出発点になる。

この図の要点は一つだけです。GitHubを顧客資料の保管庫にしないこと。GitHubに置くのはAIが働くためのルールやテンプレートだけで、顧客資料・証憑・実際の会計データ・ログ・認証情報は、権限管理された別の場所に置きます。冒頭の例えに戻れば、机の上にはマニュアルだけを置き、通帳は金庫に入れる、ということです。

3. AIエージェントがGitHubを使う5つの理由

では、ルールの置き場がなぜ「共有フォルダ」ではなくGitHubなのか。理由は5つあります。

1. 作業ルールを1か所に集められる
AIに読ませる基本方針、業務マニュアル、設定のひな形、チェックリストを、散らばらせずに管理できます。「最新版がどれか分からない」が起きません。

2. 変更履歴がすべて残る
「いつ、誰が、どのルールを、なぜ変えたか」が自動的に記録されます。AIの挙動がおかしくなったとき、原因のルール変更まで遡れます。

3. 反映前に確認できる
重要なルールの変更は、担当者だけで完結させず、責任者の承認を通してから反映する――この流れを仕組みとして強制できます。

4. AIが常に同じ環境を参照できる
Claude CodeなどのAIエージェントに、誰の端末からでも同じ作業ルールを読ませられます。担当者が変わっても、AIの仕事の質が変わりません。

5. 顧客情報を置かずに運用できる
置くものをルールとテンプレートに限定すれば、万一の事故のときにも顧客情報そのものは影響を受けません。便利さと安全性を両立できます。

そして、この仕事場が力を発揮するかどうかは、最初に決める「運用の基本ルール」で決まります。JGAでは、次の8項目を全作業共通の前提にしています。

図 2 運用の基本ルール8項目――先に決めるほど、AIの動きは安定する
1
GitHubは資料保存場所ではない管理するのは作業環境・設定・ルールのみ。
2
顧客資料はGitHubの外に置く証憑・成果物・ログは専用の保存場所へ。
3
本番のルールを直接書き換えない変更は必ず「作業用の複製→確認→承認→反映」の順で。
4
重要ファイルの変更はレビュー必須AIの基本方針や除外設定は、責任者の承認前に変えない。
5
認証情報は絶対に置かないAPIキー・パスワード・トークンの類いは一切禁止。
6
実際の設定ファイルは端末側で管理GitHubに置くのは「ひな形」だけ。実物は置かない。
7
顧客ごとのメモは置かないGitHubに置いてよいのはダミーの見本のみ。
8
作業前に「今どこにいるか」を確認するルールの置き場と資料の置き場を混同しない。
図2|全作業に共通する基本ルール。AIにもこのルール自体を読ませることで、AI側からも逸脱を検知できる。

4. 置くもの・置かないものを、最初に線引きする

環境構築の最初の仕事は、リポジトリ(GitHub上の保管単位)を作ることではありません。「置くもの」と「置かないもの」の一覧を確定させ、責任者が承認することです。料理でいう「混ぜるな危険」の表示を、作業を始める前に貼っておくわけです。

図 3 GitHubに置くもの/置いてはいけないもの

置くもの(ルールとひな形)

  • リポジトリの説明と基本方針(README)
  • AIが最初に読む作業ルール
  • 置いてはいけないものの除外設定
  • 重要ファイルのレビュー担当の指定
  • 設定ファイルのひな形(実物ではない)
  • 承認前チェックの仕組み
  • 業務手順書・チェックリスト
  • ログや報告書のテンプレート
  • ダミーの見本データ

置いてはいけないもの(実物と機密)

  • 顧客資料・証憑
  • 会計ソフトからの出力データ
  • AI処理の実ログ・承認記録
  • 顧客ごとの引き継ぎメモ
  • 実際の設定ファイル
  • APIキー・パスワード・トークン等の認証情報
  • 個人番号・給与情報
  • 契約書の原本
  • 顧客固有の会計データ全般
⚠ この線引きは「一覧を作って終わり」にせず、除外設定(.gitignore)として仕組みに落とし込み、置けないように機械的に強制する。
図3|左右を分ける基準は「共通のルール・ひな形か、実物・機密か」。迷ったら置かない。

大事なのは、この一覧を「気をつけましょう」という心がけで終わらせないことです。GitHubには、指定したファイルをそもそも管理対象から除外する設定(.gitignore)や、認証情報らしき文字列の登録を自動でブロックする機能があります。人の注意力ではなく、仕組みで守る。ここが、共有フォルダにルールを置くだけの運用との決定的な違いです。

5. 仕事場の中身――机とマニュアル棚のつくり方

線引きが決まったら、いよいよ仕事場を作ります。といっても、複雑なことはしません。AIが迷わず必要なルールにたどり着けるよう、決まった場所に決まったものを置くだけです。JGAで使っている標準の構成は次のとおりです。

図 4 仕事場の標準構成――AIが読む順に、決まった場所へ
ai-agent-accounting/            ← GitHubで管理する「仕事場」
├─ README.md                   … この仕事場の説明と基本方針
├─ CLAUDE.md                   … AIが最初に読む作業ルール
├─ .gitignore                  … 置いてはいけないものの除外設定
├─ CODEOWNERS                  … 重要ファイルのレビュー担当の指定
├─ .claude/
│   ├─ settings.example.json  … 設定の「ひな形」(実物は置かない)
│   ├─ hooks/                  … 承認前チェックの仕組み
│   └─ skills/                 … 業務ごとの手順書(スキル)
├─ docs/                       … 方針・承認ルール・運用手順
├─ templates/                  … ログ・チェック表のテンプレート
└─ samples/                    … ダミーの見本のみ(実データ禁止)
図4|標準フォルダ構成(名称は一例)。「きれいに整理すること」ではなく「AIと人が迷わないこと」が目的。

ここで一つ、実務上のポイントがあります。「設定のひな形はGitHub、実際の設定は各端末」という分担です。ひな形と実物を分けるのは、経理でいえば「勘定科目マスタの設計書は共有し、各社の実データは共有しない」のと同じ発想です。共通化すべきは考え方と型であって、中身の実物ではありません。

図 5 管理の分担――「ひな形はGitHub、実物は外」
区分GitHubで管理(共通・ひな形)GitHubの外で管理(実物)
設定ファイルひな形(example)と設定方針各端末の実際の設定ファイル
チェックの仕組み承認前チェックの雛形実行環境での実際の設定
顧客に関する情報ダミーの見本のみ顧客資料・証憑・メモ・実ログ
認証情報一切置かない端末・専用の管理場所で厳重に保管
図5|AIはGitHub内のルールを読んで働き、顧客資料は外部の保存場所から必要な範囲だけ参照する。

実際の初期構築では、非公開のリポジトリを作り、この標準構成を配置し、除外設定が効いているかをダミーファイルでテストします。「顧客資料のダミーを置いてみて、本当にブロックされるか」まで確認してから運用を始める――ここまでが環境構築です。

6. 日常運用は、経理の内部統制と同じ「型」で回す

仕事場は、作って終わりではなく、日々の運用で価値が出ます。そして税理士・経理担当者の皆さまには、この運用はまったく新しい話ではありません。承認のない仕訳は切らせない。証跡を残す。作る人と承認する人を分ける。――経理の内部統制で当たり前にやってきたことを、対象を「仕訳」から「AIのルール」に置き換えるだけです。

ルールを変更したいときは、いきなり本番のルールを書き換えるのではなく、作業用の複製の上で修正し、変更内容を提出し、別の人の確認と責任者の承認を経てから反映します。

図 6 ルール変更の流れ――承認のない変更は、本番に入らない
1
作業用の複製を作る
本番には触れない
2
修正する
変更理由も記録
3
変更内容を提出
差分が一覧できる
4
別の目で確認
ダブルチェック
5
責任者が承認
決裁
6
本番に反映
履歴が残る
7
各端末に取り込む
全員が最新ルールに
⚠ 黄色の工程が統制ポイント。担当者が変わっても、同じルールを見て、同じ確認をして、同じ手順で進められる。
図6|変更は小さくてもこの流れを通す。「承認なしに本番へ」を仕組み上できなくするのが要点。

特に重要なのが、反映前のチェックです。AIに読ませるルールを変えるということは、AIの行動を変えるということです。だからこそ反映の直前に、「置いてはいけないものが紛れ込んでいないか」を型どおりに確認します。仕訳の承認前に証憑を突合するのと同じ感覚です。

図 7 反映前チェックリスト――1つでも未確認なら反映しない
  • 顧客資料・証憑が入っていない
  • 会計ソフトの出力データが入っていない
  • AI処理の実ログ・承認記録が入っていない
  • 認証情報(APIキー・パスワード・トークン)が入っていない
  • 実際の設定ファイルが入っていない
  • 作業名やコメントに顧客名が入っていない
  • 重要ファイルの変更に、責任者の承認が付いている
図7|チェックは記憶ではなくリストで。確認した事実そのものが記録として残る。

それでも、人間の作業にミスはつきものです。だからJGAでは、「事故は起きない前提」ではなく「起きたときに止められる前提」で初動まで決めています。火災訓練と同じで、決めておくから慌てずに動けます。

図 8 置いてはいけないものを置いてしまったときの初動
共通の初動:作業を止める → 隠さず責任者に報告する → 記録を残す

反映前に気づいた

  • 対象ファイルを管理対象から外す
  • 除外設定を修正する
  • 除外が効いたことを確認して再開

反映後に気づいた

  • 該当する変更を特定する
  • 影響範囲を確認する
  • 履歴からの削除は管理者の判断で行う

認証情報だった

  • 何よりも先に無効化・再発行
  • 履歴の対応はその後でよい
  • 再発防止をルールに反映する
⚠ 対応の最後は必ず「再発防止のルール改訂」まで。ここまでやって初めて運用と呼べる。
図8|冒頭の事案が教えるとおり、認証情報はファイル削除より「無効化」が先。鍵が漏れたら、まず鍵を替える。

7. GitHubは、AIを安全に育てるための土台

これからの経理業務では、AIエージェントが下書き、チェック、整理、確認事項の作成を担う場面が確実に増えていきます。ここで見落とされがちなのは、AIに任せる範囲が広がるほど、人間側の「設計」の重要性が増すという事実です。優秀な新人ほど、良いマニュアルと良い上司の下でこそ力を発揮するのと同じです。

GitHubを使う本当のメリットは、ファイルが保存できることではありません。AIの仕事場を整え、ルールを共有し、変更を記録し、確認してから反映できること。そして何より、顧客情報を一切置かずに、AIの作業環境だけを管理できることです。

まとめ

GitHubは、顧客資料の置き場所ではありません。AIに仕事をさせるための「作業ルールの置き場所」です。

顧客情報は置かず、ルールだけを置く。担当者が作業し、別の目が確認し、責任者が承認する。AIはそのルールを読んで働き、登録や送信の前には必ず人間の承認を挟む。

この設計ができたとき、AIエージェント経理は「便利だが少し怖いツール」から、「再現性のある業務環境」に変わります。JGA税理士法人は、この環境構築を実務レベルで進めています。

※ 本コラムの図表は、JGA税理士法人の社内資料「AIエージェント経理 GitHub導入詳細マニュアル」をもとに、コラム用に再構成したものです。
参考:株式会社マネーフォワード「『GitHub』への不正アクセス発生に関するお知らせとお詫び(第一報)」

筆者紹介

JGA税理士法人 代表社員 片瀬陽平

JGA税理士法人
代表社員/税理士 片瀬 陽平

税理士業界が変遷する中、国際ビジネスに長く携わる。税理士法人時代から国際ビジネス支援に従事し、2013年にはメキシコに渡り、現地会計コンサルティングファームの立ち上げを行う。渡墨後は、日系企業のメキシコ進出サポートおよび現地日系企業への経営コンサルティングを主に担当。2016年にはアメリカに渡り、Bridge Note (Thailand) Co., Ltd.(現 BM Accounting Co., Ltd.)を立ち上げ、次いでインドネシアの PT. Bridge Note Indonesia の移転価格事業部を組成した。専門領域は、経営コンサルティング、インバウンド支援、国際税務コンサルティング、社内DX化など多岐にわたる。