「新しいAIモデルが出るたびに、乗り換えを検討したほうがよいのでしょうか」という問いが立つ場面があります。実際、AIベンダー各社は数か月おきに新しいモデルを発表しており、「前より賢くなった」という触れ込みを目にする機会も増えています。事務所として業務にAIを使う以上、常に一番賢いモデルを使っておきたいという発想は自然です。
新しいモデルの情報を追いかけ、乗り換えを検討する時間そのものが、事務所にとって地味なコストになっている面もあります。年に何度もモデルの世代交代のニュースが出るたびに検討し直していては、腰を据えた運用改善に手が回りません。
社内で行った3タスクの限定的な実験は、この問いを見直す一つの材料になりました。問いを「どのAIモデルが賢いか」だけでなく、**「AIに渡す情報の構造をどう整えるか」**にも広げると、検討の順序が変わります。
結論を先に言うと、この実験では、モデルを変更しても、入力側の出典・参照・更新の欠落による誤りは解消しませんでした。回答品質が常に情報構造だけで決まり、モデル差が影響しないと証明したものではありません。
本稿では、実験の範囲と限界を示したうえで、業務AIへ渡す情報を点検する観点を整理します。
実験の設計: 台帳だけを渡したAIと、一次情報まで読めるAIを比べる
社内で、複数の案件の進捗状況を管理する場面を想定した実験を行いました。比較したのは次の2パターンです。
- 案件台帳 (= 複数案件の状態を1行サマリにまとめた一覧) だけを渡したAI
- メール・議事録・課題管理など、一次情報まで自由に読めるAI
この2パターンに、実務でよくある3つのタスクを実行させました。「経営会議の準備資料を作成する」「ある案件の現状とブロッカーを述べる」など、要するに「今この案件はどうなっているか」を答えさせるタスクです。
採点の軸は、実在する事実をどれだけ拾えたか（網羅率、recall）を中心に置きました。ここでいう網羅率は、一次情報を確認すれば分かった事実のうち、回答が言及できた割合を10点尺度へ換算した内部評価です。
この実験には限界があります。タスクは3本だけで、取得側のモデル以外は、正解基準と審判を同じモデル系統で固定しました。初回採点は完全な盲検ではなく、後日の盲検再採点では台帳経由条件の平均が1.33/10となり、初回の2.3/10から変わりました。したがって、2.3という値を普遍的な性能値として扱わず、条件・採点方法とセットで読みます。
結果: 初回採点は平均2.3/10、後日の盲検再採点は1.33/10でした
初回採点では、台帳だけを渡した条件の網羅率が平均2.3/10（10点満点）でした。後日、正解基準を再生成して盲検で採点し直すと平均1.33/10でした。絶対値は採点方法で変わったため、ここで重視するのは、一次情報へ到達できない条件で重大な事実の欠落と鮮度誤りが残ったことです。
- 実在する障害事項 (ブロッカー) を、「特にありません」と断定して報告した
- 実際には送付済みだった見積書を、「まだ送付していません」と報告した
いずれも、台帳に書かれていた古い記述、あるいは出典の明示されていない記述を、AIがそのまま事実として採用した結果でした。台帳の側に「この記述はいつ・どの一次情報に基づくものか」が残っていなければ、AIにはそれを疑う材料がありません。人が台帳を読むときは経験則で「これは古いかもしれない」と勘を働かせますが、AIにその勘は代わりに宿りません。
AIモデルを乗り換えても、間違え方まで一致した
ここからが実験の核心です。同じ実験を、全く別系統のAIモデル (別ベンダー) で再実行しました。
初回の同一ルーブリックでは、取得側を別系統のモデルへ変えても平均2.3/10で同点でした。障害事項を「なし」とした案件や、見積書の送付状況を誤った案件など、主要な欠落も同型でした。ただし、3タスク・2モデル・固定審判という範囲の結果です。
この範囲では、モデル変更だけで誤りが解消しなかったため、入力側の構造を先に修正する判断材料になりました。確認した欠陥は次の3点です。
- 台帳の記述に出典 (どの一次情報に基づくか) が残っていない
- 台帳と一次情報の間に、参照をたどれるリンクがない
- 台帳の更新が手動に依存しており、実際の業務の進み方と乖離が生まれても検知されない
この3つを残したままでは、モデルを変えても同種の誤りが残る可能性があります。実験が示したのは「マルチモデルでも同じ品質を保証できる」ことではありません。3タスクの範囲で、入力の到達範囲に起因する主要な欠落が2モデルに共通した、という限定的な再現です。
「最新に見える情報」がいちばん危ない
台帳の実験で見えてきたもう一つの論点は、「最終更新日が新しい」ことと「内容が正しい」ことは別物だという点です。
案件台帳は日々更新されるため、常に「最新の状態」に見えます。しかし、更新されているのはあくまで台帳を書いている人が気づいて手を動かした項目だけです。実際の一次情報 (メールでのやり取り、議事録での決定事項) の中で状況が動いていても、それが台帳に書き戻されていなければ、台帳の見た目だけが新しく、中身は古いままという状態が生まれます。
今回の台帳だけを渡す条件では、この見分けに必要な根拠が入力にありませんでした。更新日時だけで内容の正しさを決めず、出典へ戻れるようにする必要があります。
税理士事務所・弁護士事務所側で整えておきたい3つのこと
この限定的な実験から得た点検仮説は、大きく3つです。自所で有効かは、対象業務で確認してください。
一つ目は、サマリや台帳から一次資料 (メール・議事録・原本) への参照を残すことです。台帳の各行に「この記述はどのメール・どの議事録に基づくか」を明示するルールを持たせておくと、AIも人も、記述の信頼度を後から検証できます。出典のない記述は事実として扱わない、という運用を先に決めておく形です。
二つ目は、台帳の手動更新に頼らず、実際の業務記録から状態を書き戻す仕組みを持つことです。台帳が担当者の記憶だけで更新される限り、更新漏れは構造的に発生します。案件管理・メール・議事録などの一次情報側で状況が動いたときに、台帳側にも反映される経路を用意しておくと、見た目の新しさと中身の正しさのズレを縮められます。
三つ目は、「新しく見えるが出典のない情報」を疑う運用を、AIを使う場面に組み込むことです。AIの回答を鵜呑みにせず、根拠となった記述の出典を確認する一手間を、外部に出すアウトプットでは特に徹底しておく形が現実的です。
自所で進めやすい場面と外部の伴走を検討する場面
実験結果を踏まえて、事務所側で「まず何から手をつけるか」を分けてみると、次のように整理できます。
| テーマ | 自所で進めやすい | 外部の伴走を検討 |
|---|---|---|
| 台帳に出典欄を追加する | ○ | — |
| 「正式版」と「下書き」を区別する運用ルール | ○ | — |
| 一次情報から台帳への書き戻し運用の設計 | — | ○ |
| AI/RAG接続時の参照範囲・権限設計 | — | ○ |
| 監査ログ・利用ログの設計 | — | ○ |
台帳に出典欄を足す、正式版と下書きを区別するといった作業は、既存の運用を少し変えるだけで着手できます。一方で、一次情報から自動的に台帳へ状態を書き戻す仕組みや、AI接続時にどこまでの情報を参照させるかの権限設計は、業務システムの構成に踏み込む話になるため、外部の視点を入れて整理したほうが手戻りが少ない場面が多いです。
AIモデルの乗り換えより優先すべき視点の置きどころ
今回確認した出典・参照・更新の欠落は、モデル変更だけでは解消しませんでした。モデル選定と並行して、入力情報の到達範囲と来歴を点検します。
問いを「新しいモデルに乗り換えるべきか」から、**「AIに渡している情報に、出典と更新の仕組みがあるか」**に置き換えてみると、着手すべき場所が見えてきます。これは、士業の方が日常的に行っている「証憑と突き合わせる」という習慣そのものです。AIに渡す情報にも、同じ規律を持たせる必要がある、というのが実験から見えてきた着地点です。
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」(2023年6月2日): https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/