ChatGPTが勘定科目表を忘れてしまう理由
総勘定元帳と連携していない
勘定科目表は会計ソフトの中にあります。ChatGPTはそれと直接連携していないため、勘定科目リストはあなたが貼り付けたチャットの会話の中にしか存在しません。つまり、貼り付けた瞬間の状態で固定されてしまいます。翌週に勘定科目を追加しても、モデルは先月の構成に基づいて自信満々に処理を続け、変更を知る術はありません。
アップロードとセッションは一時的なもの
試算表や取引データのエクスポートファイルを添付しても、それはそのチャット内でのみ有効です。ファイルは会話のスコープ内に限定され、その背後にある分析環境は使い捨てです。これは、ChatGPTがアップロードされたファイルを忘れてしまう理由や、データスキーマを忘れてしまう理由で説明されている制限と同じです。タブを閉じれば、クライアントの列レイアウト、勘定科目のマッピング、複雑な行に関するメモはすべて消え去ります。
組み込みのメモリ機能は「好み」を保持するもので、クライアントごとのルール用ではない
ChatGPTのメモリ機能は、あなたに関する永続的な事実（あなたの役割、トーン、出力フォーマットの好みなど）を記憶するように設計されています。その用途には非常に便利です。しかし、クライアントごとのルールエンジンではないため、記帳担当者が本当に必要とする「それぞれ異なる勘定科目構成、例外ルール、前期処理を持つ40社ものクライアント」を管理させようとすると、著しくパフォーマンスが低下します。これらを混同せずに整理させようとすると、自信満々に情報を混同（クロスコンタミネーション）してしまい、白紙の状態よりもタチの悪い結果を招きます。これに類する失敗例として、ChatGPTがクライアントの詳細を忘れる問題やセッション間で文脈を見失う問題が挙げられます。
価値ある知識は「判断」であり、その判断は明文化されていない
毎月あなたが実際に「再説明」している内容に注目してください。勘定科目リスト（これは単なるファイルです）ではなく、意思決定を再説明しているはずです。この継続ベンダーがどの勘定科目にマッピングされたかとその理由、クライアントが合意した按分比率、前四半期にレビュー担当者が強く求めた再分類、経緯を知らない人には間違っているように見える処理方法などです。これらこそが事務所の組織的な記憶（ナレッジ）ですが、現状ではスプレッドシートやSlackのスレッド、あるいは前回そのファイルを担当した人の頭の中にしか存在していません。
多くの事務所が試みること
セッションごとにクライアントの概要を貼り付ける
最も一般的な方法であり、静かに破綻するまでは機能します。4ヶ月目に入る頃には、概要の内容が実際の勘定科目表から乖離してしまいますが、モデルは文句を言わないため誰も気づきません。ただ古いマッピングを適用し続けるだけです。
クライアントごとに1つのCustom GPTまたはProjectを作成する
これは確実な改善策です。指示書や参照ファイルが一箇所にまとまり、スタッフと共有できます。しかし、制限となるのはメンテナンス性と適用範囲です。勘定科目構成が変更されても自動的には更新されず、クライアントへのメールを起草するアシスタントや、同じ数字から管理レポートを作成するアナリストからはその情報が見えません。また、40社のクライアントがいれば、維持管理すべきコンテナが40個存在することになります。
ルールをまとめたスプレッドシートを毎回アップロードする
構造としては優れていますが、同じ問題が残ります。ドライブ内のスプレッドシートが「信頼できる唯一の情報源（Source of Truth）」であり、チャット内のコピーもまた情報源となってしまいます。進化し続けるルールセットのコピーが2つ存在することになり、これが処理の矛盾を生む原因になります。
専用の仕訳・分類ツール
取引を記帳する上では、これらが正解です。元帳と連携し、監査証跡を保持し、レビューワークフロー向けに構築されているからです。その用途にはこれらを使用してください。しかし、これらのツールが通常保持していないのは「ナラティブ（経緯・背景）のレイヤー」です。なぜ例外が認められたのか、誰が承認したのか、クライアントに何を伝えたのか、そして去年の処理のうちどれを意図的に繰り返さないようにしているのか。これこそが、あなたが手動で埋め続けなければならないギャップです。
解決策：ChatGPTに永続的なクライアントメモリを付与する
これまで一括りにしていた2つの要素を切り離しましょう。数値と記帳データは、内部統制と監査証跡を備えた会計システムに残します。一方で、事務所の各クライアントに対する判断（マッピング、例外、承認、前期処理など）は、チャットが終了しても消えないメモリレイヤーに保存します。そのためにあるのがMemoryLakeです。一度保存すれば、どのAIアシスタントが作業を行う場合でも、そのメモリを呼び出すことができます。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを実行できます。
ステップ 2: 最初のメモリをアップロードする
各エンゲージメント（契約）を定義するドキュメント、画像、ファイルをドロップします。勘定科目表のエクスポートデータ、仕訳ルールと例外、合意された按分比率、レビュー担当者の常時修正事項、前期処理、クライアントの報告要件などです。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントに、MCPまたはAPI経由でそのメモリへのアクセス権を付与します。ChatGPTの場合は、APIを通じて関連するクライアントメモリを取得し、会話やワークフローに流し込みます。これにより、セッション開始時に関係性がすでに理解されている状態になり、再度説明を求められることがなくなります。
はっきりとさせておくべき境界線が1つあります。メモリレイヤーはコンテキストの一貫性を保つものであり、出力を自動的に承認するものではありません。人間のレビューと通常の内部統制は引き続き適用されるべきであり、元帳に影響を与えるものはすべて、適切な監査証跡を備えた専用ツールを経由する必要があります。
実務における変化
月末業務における重複作業を数えてみてください。モデルにクライアントの概要を説明するのに8分かかり、それを20件のクライアントファイルで行うと、実際の作業に入る前に、変更のない事項を再説明するためだけに毎月2時間半以上を費やしていることになります。貼り付ける概要が1,500トークンあり、クライアントごとに月に40回送信される場合、トークンコストも無視できませんが、それは二次的な問題です。
本当にコストがかかる失敗は、静かに起こります。誰も例外ルールを再提示しなかったために継続ベンダーが誤った勘定科目にマッピングされたり、按分が去年の比率で適用されたり、理由を知らない誰かによって再分類が元に戻されたりすることです。これらはレビュー時間とクライアントの信頼を損ない、その原因はすべて同じところに行き着きます。「ルールは存在していたが、作業が行われる場所にそれがなかった」ということです。このループを断ち切ることは、他の場面でAIにコンテキストを再説明するのをやめることと同じ規律です。
クライアントメモリのベストプラクティス
エンゲージメントごとに1つのメモリ範囲（スコープ）を設定する
各クライアントのルールを分離し、明確にラベル付けします。クライアントごとの知識における失敗パターンは「にじみ出し（混同）」です。類似するビジネスのルールが誤って別のファイルに適用されてしまう現象ですが、明確なスコープ設定がこれを防ぎます。
例外、理由、日付、承認者を記録する
「携帯電話 60/40 業務/個人 — オーナーがメールで確認、2026-04、レビュー担当者承認」といった記録は、何年にもわたって保持する価値があります。これはスタッフの離職を乗り越え、来年同じ質問が出たときの回答となり、その処理が単に古いだけでなく「期限切れ」であるかどうかを教えてくれます。
保存内容に注意し、追加ではなく置換する
サードパーティのシステムに入力する内容については、事務所のデータポリシーやクライアントの守秘義務に従い、機密性の高い詳細データをそのまま入力するのではなく、参照情報（リファレンス）を使用することを推奨します。ルールが変更された場合は、保存されている事実を置き換え、適用期間をメモしてください。古いルールは、ルールがないことよりも悪影響を及ぼします。モデルもスタッフもそれを正しいと信じてしまうからです。
結論
ChatGPTが勘定科目表を忘れてしまうのは、総勘定元帳と連携しておらず、アップロードされたファイルはチャットの間しか維持されず、メモリ機能が40社分のマッピングルールではなく個人の「好み」を記憶するために作られているからです。だからこそ、コミュニティの評価は一貫しています。「このツールが実務で役立つのは、その実務を理解したときだけである。しかし、毎回手動でコンテキストを流し込む手間があるため、ほとんどの事務所はそこまで到達できない」のです。
記帳データと監査証跡は、そのために構築されたシステムに保管してください。そして、各クライアントに対するあなたの判断（マッピング、例外、承認、前期処理など）は、ツールが読み取れるメモリレイヤーに保存しましょう。そうすれば、来月は白紙のチャットと8分間の入力作業から始めるのではなく、すでに関係性が理解された状態で業務をスタートできます。