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

業務システムの自動化には、「失敗したらやり直せばいい」という前提が置けない領域があります。会計、在庫、決済のように、書き込んだ結果がシステムの外に残るものです。ここではリトライもロールバックも安全策になりません。定石どおりに堅牢化すると、かえって状態が悪くなります。

やっかいなのは、取り消せるかどうかが試すまで分からないことです。APIのドキュメントには「削除できます」としか書いていません。設計を先に書き切ると、その未確認の前提の上に全部が積み上がります。

判断をAIに任せるなら、問いはもう一段重くなります。間違えた結果が取り消せないとき、そもそもAIに書き込みの権限を渡してよいのか、という形になります。

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

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

削除しても元の状態には戻りませんでした

取り消せるかどうかは、ドキュメントではなく実物でしか確かめられません。

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

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

対象外は、その明細を仕訳の対象にしないと宣言した状態です。返るのは「すでに仕訳済みである」という趣旨のメッセージです。削除したあとも会計ソフトは当該明細を仕訳済みとして扱い続けます。

帳簿の内容そのものは直せます。明細に紐づかない仕訳を直接作るエンドポイントが別にあり、こちらは受理されます。正確には「明細の状態は戻せないが、仕訳は作り直せる」です。

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

既定を自動登録に置くか人の確認に置くかは、是正にかかる手間で決まります。

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

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

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

冪等なメソッドは、複数回送っても意図される効果が1回と同じになるものと定義されています[1]。仕訳の作成は POST で冪等ではなく、再送の重複を防ぐ仕組みもありません。二重登録の防止は呼ぶ側で持ちます。

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

取り消せないなら、事故は起きたあとに直せません。帳簿へ書き込む処理では、守りをすべて実行前に寄せました。

• 既定は予行運転です。フラグを明示したときだけ登録します
• 明細の数を絞り、少数で試してから流します。上限を超えたら1つも登録せずに停止します
• 登録済みかどうかは明細の状態と監査ログの両方で判定します
• 勘定科目や税区分を名前で解決できない明細はスキップします
• 監査ログの書き込みに失敗したら、直前の仕訳の識別子を出して中断します
• リトライとロールバックは持ちません。削除すると明細が対象外になり、登録し直せなくなるためです

取り消せない操作の権限は、そもそもAIに渡しません

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

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

MCPの仕様自体も、ツールの実行を任意のコード実行と同等に扱い、実行前に利用者の明示的な同意を得るべきだと定めています[2]。同意を求める仕組みは、押し間違いや読み飛ばしまでは止めません。権限を職務に必要な最小限にとどめる原則は1975年の文献ですでに述べられており[3]、最小権限と呼ばれます。取り消せない書き込みは、そこに入りません。

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

試していない範囲を「無い」と書くと、要らない手作業が残ります

制約は、確かめたものと確かめていないものが混ざったまま設計に入ります。

最初にこの挙動を記録したとき、「対象外を解除する手段は存在しない」と書きました。根拠は、それらしい名前のURLを叩いて全部 404 が返ったことだけです。試していない範囲を「無い」と読むのは推測なので、問いを置き換えました。解除できるかどうかではなく、対象外のまま登録し直せるかどうかです。こちらは状態を悪化させずに試せます。結果は拒否で、主張は実測になりました。公開ドキュメントにない仕様を実測で特定する手順は外部APIの挙動を実測で確かめる記事で説明しています。

同じ推測が設計にも入っていました。勘定科目をさらに細かく分ける区分（補助科目）が必要な明細に、人が画面へ転記する作業を残していました。補助科目をAPIで送れるかどうかを試していなかったためです。試したら受理され、その区分は消えました。未検証であることは項目リストに書いてありましたが、設計書に落ちる段で確認済みの制約と同じ扱いになりました。

まとめ

• 仕訳の削除は成功しますが、元の明細は対象外になり、APIからの再登録は拒否されます
• 誤登録の是正は見送りより高くつきます。判定基準は保守側に倒します
• 取り消せない処理では、リトライとロールバックを持たず、書き込みの権限もAIに渡しません
• 試していない範囲を「無い」と書くと、外すだけでなく要らない手作業が恒久化します