「暴走するAI」をどう手なずけるか？ — 会計監査のブラックボックス化を防ぐ「検証六角ボルト」の打ち方
📚 論理ソルバーMCP 連載（全3回） ① 全体像：会計チェックを「毎回ブレない仕組み」に ／ ② なぜ論理ソルバーか：生成AIはなぜ「ロジカルな話」で間違えるのか ／ ③ 品質を守る：「暴走するAI」をどう手なずけるか （この記事は ③）
[▲ 正常と指摘を分ける枠組み（緑＝正常／赤＝指摘）]
はじめに：テストで監査クエリの「輪郭」をなぞる
AIエージェントに仕事を任せると、品質がブレます。同じ依頼でも、出てくる成果物は毎回ちょっと違う。9回うまくいって、10回目にスルッと変なものが出る。この確率的なブレを手なずける鍵が、テストです。
イメージで言うと、こうです。たくさんの取引を「金額 × 証憑あり/なし」の平面にバラまくと、ふつうの**正常な取引が大きな“かたまり”（緑）を作り、そこから外れた指摘すべき取引（赤）**が、その外側に散らばります。たとえば「金額が小さく証憑もある取引」はかたまりの内側（正常）、「5万1千円なのに証憑が無い取引」はかたまりの外（指摘すべき）。そして——
監査クエリとは、この“正常のかたまり”の輪郭をなぞる線。輪郭の外に出た取引を「指摘」します。この境界線をクエリとして書き起こすことが「ルール化」で、テストは、その輪郭を留める代表点（六角ボルト）です。
つまり、やることは2階建てです。まず「正常と指摘の境目」をクエリでルール化して輪郭を引く（さきほどの図の濃い線）。次に、その輪郭を、テスト（六角ボルト）で留めて崩れないようにする。 この記事は、主に後半のテストの話ですが、先に「境目をクエリでルール化する」があってこそ、テストが効きます。
「5万1千円・証憑なし → 指摘する（赤・外側）」「4万9千円・証憑なし → 拾わない（緑・内側）」——こうした境界の両側を一組のテストとして置く。点を増やすほど輪郭はくっきりし、AIはその輪郭を崩さず安全に拡張できる＝自走できる。新しい例外を取り込もうとクエリを場当たりに曲げて反対側の輪郭が崩れれば、既存のテストが即座に「赤」で教えてくれるからです。
その「輪郭」は、どこから来るのか——業務経験です
では、なぞるべき正しい輪郭は誰が持っているのか。会計・税務の業務経験を積んだ人の、頭の中です。ただし、その輪郭は最初からくっきりしているわけではありません。「だいたいこのあたりが怪しい」という手描きのにじんだ線として存在しています。
[▲ 業務経験が描く、あいまいな輪郭]
このあいまいな直感を、業務のことばで「これは正常／これは指摘」と一点ずつ宣言して固定していく。それがこのツールのテストの正体です。
この記事でいちばん大事なこと（先に2つ）
① テストは「業務の why / what」を表す。how（監査クエリの中身）は隠して、AIに任せる。 「なぜ拾うのか／なぜ拾わないのか（why）」「正しい指摘か・見逃しか（what）」だけを業務のことばで固定する。どう実現するか（how）は、税理士・会計士・経理担当が一行も書かずにAIへ委ねる。
② テストは「六角ボルト」。後方互換性を保ち、AIの“局所最適化による崩壊”を防ぐ。 想定外のケースを後から取り込む拡張のとき、AIは目の前の1点だけを最適化しようとして、他を平気で壊しがち（局所最適化）。だが既存テストが六角ボルトとして留めてあれば、後方互換性が崩れた瞬間に「赤」で止まる。だからAIは全体を保ったまま、安全に輪郭を広げられる。
この②を一枚で言うと、こうです——「テスト（六角ボルト）があるか／ないか」が、輪郭の運命を分ける。
[▲ TDDあり＝六角ボルトで輪郭が安定]
図で見る：想定外のケースを「あるべき姿」に持っていくまで
では、その「六角ボルトで守る」が実際にどう効くのか。想定外のケースが来たときの動きを、「発見」から「あるべき姿」まで順に追ってみましょう。
① まず、見逃しを発見する
いままで気づかなかった“見逃し”——正常に見えて、実は指摘すべきだった取引——を見つける場面です。
[▲ 見逃しの発見（緑の中に赤が一つ）]
② いきなり直さない。まず「失敗するテスト（赤い六角ボルト）」を置く＝TDD
「拾えるようにしたい」と思っても、いきなり監査クエリはいじりません。まずやるのは、その境目にテストを“両側”打って固定することです。
- 「これは指摘すべき」（正指摘） … 見つけた取引を、赤い六角ボルトとして置く。今は正常側に紛れているので 赤＝失敗 の状態
- 「これは今までどおり正常」（正容認） … すぐ隣の、触ってはいけない取引も、緑の六角ボルトで留めておく
こうして正指摘（赤）と正容認（緑）の両方をアンカー（固定）しておくのがミソです。「拾いたい1点」と「巻き込みたくない隣」を先に釘で留めておけば、あとで境界に小さな切れ込みを入れて広げるのが、ぐっと安全・簡単になる。これがTDDの最初の一手です。
[▲ 切れ込みを入れる前に、正指摘（赤）と正容認（緑）の両側をアンカー]
③ 直す。ただし、やり方しだいで結果が分かれる
次に、その赤を緑に変えようと監査クエリを直します。ここで、目の前の1点だけを追って輪郭を場当たりに曲げると——反対側の輪郭が崩れ、これまで正しく判定できていた取引まで巻き込んで壊してしまいます。
[▲ テスト無し＝1点を追って輪郭が崩れる]
テストの六角ボルトが無ければ、この崩れに誰も気づけません。 ——そして、これこそが、テストの無いノーコード／ローコード／Excelマクロや、勢いで書く“バイブコーディング”が、いつのまにか壊れる理由そのものです。「動いているように見えて、実は別のところが黙って壊れている」のに、それを教えてくれる仕組みが無い。だから、規模が大きくなるほど手がつけられなくなります。
逆に、六角ボルト（テスト）さえ刺さっていれば話は変わります。AIが作業している途中では、TDDがあっても、この“崩れた状態”に一時的になることはあります。でも決定的に違うのは、崩れた瞬間に既存の六角ボルトが「赤」になって、どこを壊したかを自動で教えてくれること。だからAIは誤りに気づき、自分で（自走して）直しにいけます。
④ あるべき姿へ——既存を壊さず、新しいケースだけ取り込む
最後に、既存の六角ボルトを一つも崩さないまま、見つけた取引だけを正常のかたまりの“外（指摘側）”へ正しく出します。② で正指摘と正容認の両側をアンカーしておいたおかげで、境界に小さな切れ込みを入れて、拾いたい1点だけをスッと外へ出せる——隣の正常を巻き込まずに。これが、TDDで目指す後方互換を保った拡張です。
[▲ テスト有り＝既存を壊さず取り込む（後方互換）]
六角ボルトの数だけ「壊したら赤になる箇所」が増えるので、AIは全体の形を保ったまま、目的の1点だけを安全に直せます。
「判定の輪郭」を、実際の自動テストで見る
「輪郭」「六角ボルト」と言われても、まだピンと来ないかもしれません。そこで、本ツールに実際に登録されている自動テストを1つ、そのまま見てみましょう。記事の冒頭から例にしている「3万円以上で証憑（領収書）が無い取引を指摘する」という監査クエリ（high_amount_no_receipt）です。業務上の意味はこう書かれています。
金額が 3 万円以上の高額取引のうち、証憑が添付されていないものを抜き出します。電子帳簿保存法と内部統制（社内承認フロー）の観点から要調査です。
この監査クエリに、実務を抽象化した**代表ケース（＝輪郭を留める六角ボルト）**が、最初から5つ束ねてあります。実際のテスト名そのままで並べると——
- 30000円ぴったり＋証憑なし → 指摘する（境界の片側。「3万円以上」にちょうど3万円も含む、と固定）
- 29999円＋証憑なし → 指摘しない（境界のもう片側。1円下がっただけで対象外、と固定）
- 30000円＋証憑あり → 指摘しない（金額は高くても、証憑があれば義務を充足）
- 金額が未記録 → 指摘しない（そもそも高額か判定できないケースの取り扱いを固定）
- 3万円以上＋証憑なしの取引だけを拾う（証憑あり・3万円未満が混ざっていても、該当分だけ抜く）
見てのとおり、いちばん効くのが**「30000円は指摘／29999円は指摘しない」という、境界をまたいだ一組です。これがまさに、図でいう「輪郭の内側に緑・外側に赤の六角ボルトを一組で打つ」の正体。AIがこの監査クエリをどう書き換えても、29999円を指摘し始めたり、30000円を見逃したりした瞬間に、このテストが赤で止めてくれます。抽象的な「判定の輪郭」は、製品の中ではこういう具体的な代表ケースの束**として存在しています。
この「テストで育てる」やり方が、これまでITエンジニアの世界にとどまっていた理由——そして、なぜ生成AIで変わるのか
ここで一歩引いて、「そもそもなぜ、この“テストで育てる”やり方が今まで会計の現場で使われてこなかったのか」を考えてみます。
TDDに意味があるのは、実務から抽象化した代表ケースを、自動テストで一発で切り分けてくれるからです。さっきの5ケースを、監査クエリを少し直すたびに人手で全部確かめていたら、とても割に合いません。「ちょっと変えて、今までのケースを全部テストし直す」——これがコストに見合うようになるには、自動化が必須です。
そして、その自動化を組むには、業務知識（何が正解か）とエンジニアリング知識（どう自動で回すか）の両方が要ります。両方を併せ持つのは、これまで実質ITエンジニアくらいでした。だからTDDは、長らくソフトウェア開発の世界の中だけの道具だったのです。
さきほど、テストが無いと自動化は「黙って壊れる」と書きました。もう一度、強調させてください。 これこそ、テストの無いExcelマクロ／ローコード・ノーコードの業務ツール、そしてAIに勢いで書かせた“バイブコーディング”で、多くの人が痛い目を見てきた理由そのものだからです。最初は動くのに、誰かが触った瞬間どこかが壊れ、気づかないまま運用が続く——その怖さの正体は、いつも同じ「あるべき判定を留めるテストが無い」こと。つまり、業務でこのやり方を回すには、結局テスト（六角ボルト）を組む力が要る、ということです。
ここを変えるのが、生成AIです。生成AIは、**複数のドメインの知識を幅広く持った“翻訳者”になれます。業務のことば（何が正解か）を、エンジニアリングの形（自動テストと監査クエリ）へ翻訳する。この橋渡し役にこそ、生成AIはうってつけなのです。業務知識を持つ人が「正解の代表ケース」を語れば、AIがそれを自動テストと監査クエリに翻訳する——「ITエンジニアでなくてもTDDを回せる時代が、ようやく来た」**というわけです。
以下は、この考え方が製品の中でどう形になっているか、の話です。
1. 結果は「4象限」で自動判定される
テストの代表点は、ただ「○か×か」ではありません。「期待」と「実際」のクロスで、4つに分類されます。医療検査の「陽性/陰性 × 正解/不正解」とまったく同じ構造です。
監査クエリの「判定」（適正＝指摘しない／違反＝指摘する）と、取引の「実際」（適正か違反か）をクロスさせると、4つに分かれます。
[▲ 混同行列（正容認／看過／誤指摘／正指摘）]
いちばん危ないのが、右上の看過（＝実際は違反なのに「適正」と判定して取りこぼす＝見逃し）です。「誤指摘」は人が見れば気づけますが、看過はそもそも俎上に載らないので発見されにくい。だからテストは、「これは違反（正指摘すべき）」と「これは適正（正容認すべき）」を一組で置くのが鉄則です。境界の片側だけ固定しても、反対側がいつのまにか崩れます。
なぜ「両側」が要るのでしょう。仮に、テスト（六角ボルト）を**「これは正常」側にしか置かなかった**とします。
そのとき何が起きるか。監査クエリの境界線が、本来の正しい範囲から外側へ大きくはみ出して、本当は指摘すべき取引（違反）まで「正常」と飲み込んでしまったとしても——正常側のボルトは、どれも「正常を正常と言えている」ので、一つも赤くなりません。つまり、看過（見逃し）が起きているのに、テストは全部グリーン。誰も異常に気づけないのです。
ここで**「これは違反」側にもボルトを打ってあれば**、境界が外へはみ出した瞬間に「違反のはずが正常と判定された」とボルトが赤くなり、ズレを捕まえられます。正常側と違反側、両方にボルトがあって初めて、境界の崩れを両方向から止められる——これが「両側を一組で」の理由です。
[▲ 片側だけのテストは境界のズレを見逃す]
2. 期待値は「2軸」で書く
もう一段、解像度を上げます。本ツールでは、各テストデータ（取引などの行）に対し、期待値を2つの軸で持ちます。
- クエリ期待値：この監査クエリは、この取引を検知すべきか（detected / 検知しないのが正解 = expected_miss）
- 業務期待値：そもそも業務上、この取引は違反なのか正常なのか（issue / no_issue）
この2軸をクロスさせると、さきほどの4象限が自動で決まります。「クエリは検知すべき（detected）」×「業務的に違反（issue）」なら 正しい指摘（正指摘）。「クエリは検知すべきでない（expected_miss）」×「業務的に正常（no_issue）」なら 正しいスルー（正常）。ズレれば誤指摘・見逃しとして赤になります。
ポイントは、書く人は「業務のことば」だけを書けばいいこと。「なぜこれを指摘するのか／しないのか」を業務語で宣言すれば、4象限判定はしくみが自動で下す。クエリの中身（how）は意識しなくていい。
ここで、はっきりさせておきたい線引きがあります。業務期待値（＝そもそも違反か正常か）は、人間が決める「意志」です。ここはAIに推測させたり、別のルールから自動で導き出したりしません。「どう判定するか（how）」は機械の仕事、「何を正しいとするか」は人間の仕事——この境界を崩して、機械に“正解の値”まで決めさせてしまうと、それは人間の意志を機械が騙(かた)ることになってしまう。だから業務期待値は、人がGUIから入れる一級の値として扱い、AIが出す下書き（ドラフト）とは、はっきり区別しています。「枠組み（型）は機械が用意し、中に入れる値は人間が供給する」——この形を守るのが、設計上のいちばん大事な約束です。
3. テストは「実際の freee 画面」で確かめられる
テストは2通りで回せます。ひとつは ロジカルテスト——freeeを介さず、テストに付いた事実だけで一瞬で判定する机上チェックで、AIが試行錯誤する高速ループ用です。ただ、ここでの主役はもうひとつの E2Eテスト のほう。
E2Eテストは、想定シナリオの取引を実際の freee（開発用事業所）に投入して、本番同等のデータで監査クエリを通します。「机上の論理」だけでなく「実データでも本当に拾えるか」を担保する段です。
何より便利なのが——E2Eで使うテスト取引は、ボタン一つで実際の freee 画面に作られること。テスト用の取引を手で freee に打ち込む必要はありません。投入された取引は、いつもの freee の仕訳帳でそのまま開いて確認できます。「テストデータが本当に入ったか」「想定どおりの取引になっているか」を、見慣れた画面で目視できる——ここが、机上で完結しないE2Eの強みです。
[▲ E2Eのテスト取引が freee 仕訳帳に実在]
監査ルール管理の画面では、各テスト行の「結果」が 「E2E 成功」 なら freee 実投入の検証まで通過。行の**「freeeリンク」から、その取引を freee でワンクリックで開けます**。
[▲ テスト行から freee の取引へワンクリック]
（E2E には地味だが大事なしくみも。テストデータの依存関係——「この受領書を、この取引に紐づける」など——を、本ツールが投入順に自動で並べ替えてから入れるので、「まだ無いものを参照して壊れる」事故が起きません。）
4. AIの暴走を止める「ガードレール」── テストケース一覧ビュー
🔰 用語メモ：ガードレール（guardrails） … AIエージェント界隈で最近よく使われる言葉で、AIが勝手なこと・危ないことをしないよう、安全な範囲に囲い込むしくみのこと。道路のガードレールと同じで、「外に飛び出さないように脇を固める」イメージです。
テストが増えると、それ自体が資産であり、確認の起点になります。本ツールには、監査クエリに紐づく全テストケースを1つの表で並べるビューがあり、各テストの期待値と直近の結果がひと目で見渡せます。
AIが監査クエリ改修を提案してきたとき、人はこの一覧を起点に「この期待値で合っていますか？」と確認する。**AIが監査クエリを勝手に書き換えて挙動が変わるのを防ぐ“ガードレール”**です。期待値はその場で（権限の範囲で）編集でき、フィルタ／ソート／列選択で大量の監査クエリも素早く絞り込めます。
ちなみに、こうやってテストで品質を測ること自体は、界隈では 評価（evals） と呼ばれます。本ツールのテストは、「品質を測る（evals）」と「暴走を止める（ガードレール）」を一枚で兼ねている、というわけです。
「金額」「結果（成功/失敗/見逃し…）」「公開範囲」などで一覧を絞り、崩れている行だけを炙り出す——テストが多いほど、この絞り込みが効いてきます。
[▲ テストケース一覧（1行＝1つの“正解の見本”＝六角ボルト）]
[▲ 多段フィルタ]
正直に言うと、テストの“鍛え方”はこれからです
ソフトウェアのテスト工学には、テストそのものを強くする技がいろいろあります。たとえば——
- カバレッジ（網羅率）：監査クエリの「どの条件分岐」までテストが踏めているかを測る
- テストの中間層：いきなり全体を試すのではなく、部品（述語）ごとにも小さくテストを置く
- 説明的テスト：そのテストが「なぜこの判定であるべきか」を、業務のことばで残す
- ミューテーションテスト：わざと監査クエリを少し壊してみて、テストがちゃんと「赤」で気づくかを確かめる（＝テストの“目”が節穴でないかのテスト）
これらは強力ですが、本ツールではまだ全部を運用に組み込めてはいません。少しずつ導入している途中です。 ここで誤解してほしくないのは、テストが足りない＝即・欠陥、ではないということ。テストは一度に完璧を目指すものではなく、使いながら、危なかった所から一本ずつ足して育てていくもの。「ゼロか百か」ではなく漸進的に厚くしていく——その前提で受け取ってもらえると、いちばん実態に近いです。
5. 集合知レビュー：期待値を「決めきれない」を救う
TDDの一番の難所は、テストを書くこと自体ではなく、「そもそも、この取引は指摘すべきなのか？」という正解そのものが分からない場面です。担当者一人では判断しきれない。
白黒つかないものは、無理に二値化せず「重要度」で表す
会計の判断は、白黒の二択ばかりではありません。「明確にアウト」もあれば、「これは状況次第。ケースごとに人が見て決めるべき」というグレーもある。本ツールはこの差を、検出結果の重要度で表現します。
- エラー（要修正） … 確実に直すべき、はっきりした違反
- 警告（要確認） … ケースで判断が要るグレー。白黒を急がず、“判断待ち”として可視化する
さっきの図形で言えば、ほとんどの領域は「緑（正常）」と「赤（指摘）」にきれいに分かれます。でも一部に、正常（緑）と指摘（赤）が入り混じって、どんな線を引いても分けきれない一帯が出てきます。そこが論理ソルバーの限界領域です。
[▲ 限界領域（白黒つかない一帯）]
重要度を「一本の物差し」として捉えると、こうなります。
[▲ 重要度の3段（要修正／要調査／対応不要）]
そして、この警告＝判断待ちを、人、または生成AIにエスカレーションして詰めます。「決めきれない」を無理に二値へ丸めて誤判定するのではなく、重要度という形で残し、適切な判断者に渡す——これが次の「集合知レビュー」につながります。
本ツールは、ここをチームの集合知で埋める動線を持っています。
- 個人の手元で出した結果を、同じ組織のメンバーに共有できる
- メンバーは期待値を 提案・承認・差し戻しできる（自分の結果と共有結果はマージ表示）
- 「自分では決めきれないケース」を、**業務知識を持つ別メンバーに“回答リクエスト”**として送れる。回答が返れば期待値に反映され、再び pass/fail の判定対象に戻る
監査クエリ品質を、一人の頭の中ではなく、レビューの動線で磨いていく。テストは「個人のメモ」から「チームで合意された仕様」へと育ちます。
[▲ 集合知レビューの循環]
6. 実践のテンポ：赤を先に作って、AIに渡す
最後に、日々の回し方を。コツは入門記事と同じく、順番をひっくり返すこと。
- 「このケースも拾えるようにしたい」と思った瞬間に、まずそれを**失敗するテスト（赤）**として置く。「本来指摘すべきなのに、今は拾えていない」状態を先に作る
- その赤を、AIエージェントに「緑にして」と渡す
- AIは、既存の緑を一つも壊さないことを全テストで確認しながら、赤を緑に変える（＝さきほど図で見た、既存を壊さず新しいケースだけ取り込むやり方）
- 人は、AIの改修案を承認するかどうかだけ判断する
この「最後に人が承認する」設計は、界隈では human-in-the-loop（ヒューマン・イン・ザ・ループ） と呼ばれます。直訳すると「輪の中に人を残す」── AIに全部任せ切らず、判断の最後の一押しは人に残しておくという考え方です。
ロジカルテストで高速に回し、要所でE2Eで本物を確かめ、迷ったら集合知に投げる。人は「正解の見本」を並べ、AIは輪郭を保ったまま育てる。 これが、logic-solver-mcp におけるTDDの実像です。
「赤を先に置く」は、チームの集合知にも効く
この「まず失敗するテスト（赤）を置く」という順番は、一人の作業だけでなく、チームで監査クエリを育てるときのガバナンスにもそのまま効きます。
仮に、全ユーザーがクエリ（監査クエリの中身）を自由に書き換えられるようにしたら、どうなるでしょう。誰かの修正が他の誰かの判定を黙って壊し、収拾がつかなくなります。クエリの変更権を全員に配ると、監査クエリは破綻します。
一方で、「このケースはこう判定すべきだ」というドラフトのテストを足すことは、ずっと気軽です。 テストは「あるべき判定」を宣言するだけで、既存の監査クエリ（中身）を書き換えませんし、実行時の判定そのものには影響しません。だから、実装コード（クエリ）を直接いじるのに比べて、足したときの“負の影響”がはるかに小さい。誰が足しても事故になりにくく、むしろテストが増えるほど、輪郭を留める六角ボルトが増えて、監査クエリは丈夫になります。
だから、チームでの進め方はこうなります。
- メンバーは「この取引はこう判定すべき」というテスト（あるべき判定）をドラフトとして足す。クエリ本体は触らない
- その判定で本当に合っているかを、集合知レビューで合意する（提案・承認・回答リクエスト）
- 合意できたテストを満たすクエリは、AIが作る／直す
つまり、業務の「あるべき姿」はテストが写し取り、それを実現するクエリ（how）はAIに任せる。 人は「何が正解か」をテストとして持ち寄って合意し、監査クエリの書き換えそのものは、テストという安全網の内側でAIに委ねる——これなら、大人数で触っても壊れにくくなります。
両立しないテストが出たときこそ、専門家の出番
ときには、どうしても同時には満たせないテストの組が出てきます。「このケースは指摘すべき」「いや、よく似たこのケースは正常だ」——どちらも一理あるのに、片方を立てるともう片方が崩れる。これは、AIの力不足ではありません。いままで誰も言語化していなかった、判断の難所が見つかったというサインです。だからこそ、ここは専門家が集まって議論する価値があります。
対応は、いくつかあります。
- クエリでの両立を、もう一度目指す：条件をもう一段ていねいに分ければ、両方を満たせることも多い。まずはここをAIと探る
- 片方の「あるべき判定」を直す：議論の結果、どちらかの期待値が間違っていたと分かれば、テストのほうを正す
- 自動判定の限界として、線を引き直す：きれいに分けきれないと結論が出たら、その一帯を「エラー（要修正）」から「警告（要調査）」に落とし、機械任せにせず、きちんと工数をかけてAIや専門家が一件ずつ判定する領域として扱う
3つめは、無理に白黒を機械へ押し込めず、「ここは人が見るべき限界領域だ」と正直に認める選択です。テストの衝突が、“どこまでを自動化し、どこからを人に残すか”の線引きを、チームの合意として浮かび上がらせてくれます。
機械がやるのは「実行」── 人間から奪わないもの
ここまで「自動で」「AIに任せる」と書いてきたので、念のため強調させてください。このツールが目指すのは、人間を会計判断から外すこと、ではありません。
機械（論理ソルバー）がやるのは、あくまで決められたルールを、決められたとおりに実行すること。「そもそも何を指摘すべきか」「どこからを違反とみなすか」という“ものさしの中身”を決めるのは、最後まで人間です。いわば立法と執行の関係に近い。ルールという“法”を定める意志は人間の側にあり、機械はそれを忠実に執行するだけ。機械には、ものさしそのものを決める権限はありません——これは機能の不足ではなく、設計上わざと引いた、権限の境界線です。
だからこのしくみには、人間の判断のための「余白」が意図的に残してあります。さきほどの「業務期待値（値は人間が入れる）」も、グレーなケースを警告（要調査）として人に残すのも、その余白です。枠組み（型）は機械が用意し、そこに入る“正解の値”は人間が供給する。 機械が気を利かせて値まで埋めてしまえば、人間の意志を機械が乗っ取ることになる——そこへは踏み込ませない、という約束です。
つまりこのツールの価値は、人間を消すことではなく、人間にしか出せない判断に集中できるよう、機械的な手間のほうを引き受けることにあります。何千件を目で追う作業や、ルールを毎回引き直す手間は機械へ。人は「これは本当に指摘すべきか」「このルールでいいのか」という、意志の要る判断に時間を使う。役割を奪う道具ではなく、役割を取り戻すための道具——それが、いちばん近い言い方だと思っています。
まとめ
入門記事の「テストで輪郭をなぞる」を、製品はここまで具体化しています。
- 結果は 正容認・看過・誤指摘・正指摘の4区分で自動判定。最も怖いのは看過（見逃し）
- 期待値は クエリ期待値 × 業務期待値の2軸。書くのは業務のことばだけ
- テストは E2E で 実際の freee 画面に取引が作られ、そのまま確認できる
- テストケース一覧ビューが、AIの暴走を止めるガードレールになる
- 分けきれない限界領域は「警告」として残し、集合知レビューで「正解を決めきれない」をチームで埋める
改めて、いちばん大事な2つを。
- テストは「業務の why / what」を担い、how はAIに委ねる。専門家は正解を定義し、承認するだけ。
- テストは「六角ボルト」として後方互換性を保ち、拡張時にAIが起こしがちな“局所最適化による崩壊”を防ぐ。1点を直して10点を壊す事故を、赤が止める。
確率的でブレるAIを、4象限のテストで囲い込み、後方互換性を保ったまま、チームで育てていく。テストが“業務の仕様”そのものになる——それが、AIエージェント時代の監査クエリ開発だと、私たちは考えています。
🔰 用語メモ：ハーネス／足場（harness / scaffolding） … 生のAIモデルそのままでは実用に耐えないので、その周りに「道具・手順・検証・ガードレール」を組み付けて、ちゃんと働く“装置”に仕立てます。この外側の足場一式を、最近この界隈では ハーネス（harness） や 足場（scaffolding） と呼びます（馬や作業員に装着する“ハーネス”と同じ語感です）。本ツールは、**論理ソルバー＋テスト（ガードレール）＋承認（human-in-the-loop）**で、会計監査向けのハーネスを一式そろえたもの、と言えます。
【前提】 ここで「期待値（正解）を定義・承認する人」は、税務・監査の有資格者、または業務知識を持つ担当者を想定しています。本ツールは「税理士・会計士の業務効率化」と「事業者による自社データの自己点検」のための道具で、無資格者が他人の税務を代行するものではありません。最終判断は有資格者の責任のもとで（詳細は下記リリース記事の「だいじな前提」を参照）。
関連記事（同時公開）
- 🚀 freeeの会計データを「論理」で監査する（リリース・全体像） … まずはここから。何ができるツールか。
- 🧩 生成AIって、なんで「ロジカルな話」で間違えるんだろう？ … テストが守る「監査クエリの中身」を、なぜ論理ルール（Datalog）で書くのか。