取り消せない操作を含む処理は、どう自動化するのか

自動化では、失敗時のリトライやロールバックが定石です。しかし、書き込みを完全には取り消せないAPIでは、再実行が二重登録や別の不整合を増やすことがあります。会計、在庫、決済のように、書き込んだ結果がシステムの外に残る領域で起きる問題です。

今回扱ったAPIでは、公開ドキュメントだけでは元の状態まで戻せるかを判断できませんでした。そして判断をAIに任せるなら、問いはもう一段重くなります。間違えた結果を簡単には戻せないとき、そもそもAIに書き込みの権限を渡してよいのか。

会計ソフト（マネーフォワード クラウド会計）への記帳をAPIで自動化した作業を素材に、取り消せないという制約が設計のどこまでを決めるかを説明します。仕訳は、取引を勘定科目という分類に割り当てて帳簿に記録する単位です。銀行口座やカードから取り込まれた入出金の記録を明細と呼び、仕訳になっていないものが未仕訳として溜まります。以下は2026年8月時点の挙動です。

• 仕訳を削除しても元の明細は未仕訳に戻らず、APIからの再登録も拒否されます
• 取り消せない処理では、誤りのコストと見送りのコストが釣り合いません。判定基準は保守側に倒します
• 取り消せない書き込みの権限はAIに渡さず、経路を検査つきの1本に絞ります

削除しても、APIだけでは元の状態に戻せませんでした

戻せるかどうかを確かめるため、設計を書き切る前に、本番の帳簿へ1つだけ登録して削除する実機スパイクを挟みました。作成も削除も成功しました。明細の状態は次のように動きます。

操作	明細がどうなるか
取り込んだ直後	未仕訳
仕訳を作る	仕訳済み
仕訳を削除する	対象外
対象外のまま登録し直す	400 で拒否される

対象外は、その明細を仕訳の対象にしないと宣言した状態です。仕訳を削除すると、画面上の明細はこの「対象外」になります。一方、その明細をAPIから登録し直そうとすると、「すでに仕訳済みである」という趣旨のメッセージで拒否されます。つまり表示は「対象外」でも、会計ソフトは当該明細を仕訳済みとして扱い続け、APIからは再登録できない状態です。

帳簿の内容そのものは直せます。明細に紐づかない仕訳を直接作るエンドポイントが別にあり、こちらは受理されます。また、画面には対象外を解除する操作があり、人手なら明細を元に戻せます。正確には「明細の状態はAPIだけでは戻せないが、仕訳は作り直せるし、画面操作なら明細も戻せる」です。この自動化はAPIで完結させる前提なので、是正には必ず人の画面操作が入ります。

間違いのコストが釣り合わないと、判断の基準が変わります

自動登録を増やすべきか、人の確認を増やすべきか。このケースでは、「どちらの間違いが高くつくか」を比べると決まりました。

間違いの種類	是正の手順	誰が動くか
登録すべきものを見送った	レポートの内容を承認する	承認する人だけ
登録すべきでないものを登録した	仕訳を削除し、明細の状態を直し、登録し直す	承認する人と画面を操作する人

誤登録の是正だけに画面操作が入るのは、削除した明細が対象外に落ち、APIから登録し直せないためです。自動化した処理は、自分の誤りを自分では是正できません。

この非対称から、既定は「迷ったら登録せずレポートに回す」にし、閾値は誤登録の確率を下げる方向に倒しました。

仕訳の作成には POST が使われます。HTTPの仕様上、POST自体には冪等性（複数回送っても効果が1回と同じになる性質）が保証されません[1]。API側に重複防止の仕組みがあるかも公開資料からは確認できなかったため、この処理では安全な自動再送を前提にせず、二重登録の防止は呼ぶ側で持ちます。

安全機構は制約から逆算して決まります

APIだけでは事故のあとに自動で戻せないため、帳簿へ書き込む処理では、守りをすべて実行前に寄せました。実際に入れた安全機構は次のとおりです。

• 予行運転を既定に: フラグを明示したときだけ登録します
• 件数の制限: 少数で試してから流し、上限を超えたら1つも登録せずに停止します
• 重複実行の検知: 登録済みかどうかを、明細の状態と監査ログの両方で判定します
• 実行前検証: 勘定科目や税区分を名前で解決できない明細はスキップします
• 監査の担保: 監査ログの書き込みに失敗したら、直前の仕訳の識別子を出して中断します
• 無条件の自動再送はしない: 成否が不明になったときは適用済みかを照会し、判定できなければ人の確認に回します

確認を挟むより、書き込み権限そのものを渡さない

書き込みが取り消せないなら、AIに操作を任せる範囲も同じ制約から決まります。利用している会計サービスは、AIから操作するためのMCPサーバーを公開しています。MCP（Model Context Protocol）は、LLMを載せたアプリケーションと外部のデータやツールをつなぐ規約です[2]。当初はこれを使う設計でしたが外しました。

理由は範囲と統制です。MCPサーバーが提供する操作はREST APIの部分集合で、必要なものはAPI側で足ります。そして接続すると、会話の途中でLLMが帳簿へ書き込める状態になります。判断だけをAIに渡す方針と正面から衝突します。

MCPの仕様でも、ツールはモデルが自動的に呼び出せるものとして設計される一方、安全のために人が実行を拒否できる仕組みや確認表示を設けることが推奨されています[2]。同意を求める仕組みは、押し間違いや読み飛ばしまでは止めません。権限を職務に必要な最小限にとどめる原則は1975年の文献ですでに述べられており[3]、最小権限と呼ばれます。この件ではAIの職務を「判定まで」と定義したので、元に戻せない書き込みは必要最小限に含まれない、というのが本記事での適用です。

書き込みは、引数を検査してから実行するスクリプト1本に限定しました。集計も分析も会話から自由に実行できて、書き込みだけが1本の経路を通ります。

なお、「APIでは戻せない」という制約自体も、確認できた範囲と未確認の範囲を分けて扱いました。未確認を「できない」と決めつけると、不要な手作業を設計に残すためです。公開ドキュメントにない仕様を実測で特定する手順は ドキュメントに載っていないAPIの仕様は、どう調べるのか に記載しています。

見送りの是正は承認だけで済み、誤登録の是正には人の画面操作が要る。この非対称が実測で確かめられれば、あとの設計は自然に決まります。閾値は保守側へ、検査は実行前へ、元に戻せない書き込みの経路は検査つきの1本へ。取り消しに制約がある自動化では、再実行の仕組みを考える前に、誤りの是正コストから設計を逆算する必要がありました。