AIが優秀になっても、システムはなくならない ── AIエージェントは道具を使いこなす側に立つ
ツバイソの印具です。
汎用のAIが優秀になれば、業務システムは不要になる。海外では「SaaS is dead」という言葉とともに、こうした議論が続いています。
私も、経費精算のような単純な業務システムは、AIが代替していくと考えます。ただし、代替されるのは、画面からの入力と、入力内容の確認です。確定した記録の更新・削除を禁止するデータベース、毎回同じ結果を返す確定的な処理、申請の状態と、操作の権限を管理するワークフローは、経費精算でもなくなりません。これらはERPのような基盤に集約されて残り、申請・承認の責任を負う人のアカウントも残ります。AIエージェントは、システムという道具を使いこなす側に立つ、というのが私の見方です。
この記事では、当社でAIエージェントが作業記録のファイルを破損させた出来事をきっかけに、私の考えを説明します。
取引や承認の記録は、データベースで管理する
当社では、AIエージェントが作業の計画と進捗をMarkdownのファイルに記録しています。ファイルの冒頭には状態や更新日などの管理情報を記載し、その情報から作業の一覧を自動で作成しています。
あるとき、この管理情報が破損したファイルが見つかりました。ファイル全体を読み込んで上書き保存する処理を推定してプログラムで再現し、破損前のファイルに適用すると、破損したファイルの先頭部分と完全に一致しました。私の記憶では、管理情報の修正を指示した作業で、AIエージェントが同様のプログラムを作成して実行していました。そこで、この方式の上書き保存が原因だと判断しました。修復したファイルは、控えを含めて8件でした。ただし、ファイルには変更の履歴が残っていなかったため、どの作業の上書き保存で破損したかまでは特定できませんでした。
対策として、管理情報を書き換える方法を3つに限り、AIエージェントが作業中に作成したプログラムでファイル全体を上書き保存することを禁じました。
作業記録については、当面この対策で運用しています。しかし、取引や承認の記録では、求められる管理の要件が異なります。Excelや共有フォルダのファイルで管理している台帳をAIエージェントに操作させれば、同じ破損は起こりえます。今回のように定めた形式に合わないデータは、データベースで項目の型を定義すれば、書き込む時点で拒否できます。バージョン管理の仕組みを使えば、ファイルでも変更の履歴は後から確認できるようになります。それでも、確定した項目の更新・削除だけを禁止する機能や、項目ごとに閲覧・更新できる利用者を設定する機能は、ファイルには備わっていません。取引や承認の記録は、項目の型を定義でき、確定後の更新・削除を禁止でき、変更の履歴が残るデータベースで管理する必要があります。AIが優秀になっても、この要件は変わりません。
確定的な処理は、あらかじめ用意したプログラムに任せる
私は大学院で、遺伝的アルゴリズムと、人が評価に加わる対話型遺伝的アルゴリズムを研究していました。どちらも乱数を使って解を探索する手法で、同じ問題でも実行のたびに得られる解が変わりえます。いまのAIエージェントの中核にある大規模言語モデルも、次に続く語を確率に基づいて選んで出力を生成するため、同じ指示でも出力が変わりえます。この性質は、多様な解や出力を探す場面では利点になり、会計のように毎回同じ結果が必要な場面では欠点になります。
見積の金額や、基幹システムに登録する仕訳の科目は、毎回同じ結果でなければなりません。当社では、提案書・見積書の形式と金額、仕訳の科目や取引先を、テンプレート・スクリプト・マスタで確定的に処理しています。これらの処理でのAIエージェントの役割は、テンプレートやスクリプトを呼び出すことに限っています。規則をそのまま実行するプログラムは、AIより正確かつ高速で、結果の根拠を後から説明できます。AIの利用費を抑えられる点でも有利です。
権限と、申請・承認の進行で変わる状態は、システムが管理する
申請・承認のワークフローでは、申請・承認が進むにつれて申請の状態が変わり、状態ごとに操作できる人が変わります。データベースは閲覧・作成・更新・削除（CRUD）の権限を利用者ごとに制御し、ワークフローは状態ごとに誰が操作できるかを制御します。AI単体は、申請の状態を保存し続ける仕組みも、権限の無い人の操作を拒否する仕組みも持ちません。加えて、出力が実行のたびに変わりえます。申請の状態と操作の権限の制御は、AI単体では担えません。
当社のAIエージェントは、利用者本人のアカウントで認証してSalesforceに接続します。AIエージェントが操作できる範囲は本人の権限内に限り、本人より広い権限は与えていません。Salesforceの入力規則とトリガーはサーバー側で実行されるため、AIエージェントが登録したデータにも、人が画面から登録したデータと同じく適用されます。画面上でのみ動作する自動入力は適用されないため、守るべき規則はサーバー側に設定する必要があります。
AIは道具を使う側に立つ ── 入力作業を代行する人は減り、責任を負う人は残る
AIエージェントは、道具を使って仕事をする点で、人に近い存在だと私は考えています。人員がどれほど多くても、機械や装置がなければ業務は成り立ちません。同じように、AIエージェントがどれほど優秀でも、システムという道具は必要です。単純な業務システムの入力や確認は、AIエージェントが代替していきます。画面からの入力をAIエージェントが代替するようになれば、業務ごとに別のシステムを導入する必要性は低くなると考えます。一方で、取引や承認の記録・確定的な処理・権限は、互いに整合している必要があります。そのため、これらを一元管理するERPのような大規模な基盤は、AIエージェントでは代替できません。これらの基盤は、AIエージェントが使う道具として引き続き必要です。
道具と、道具を使う者との関係は、古くから論じられてきました。アリストテレスは『政治学』第1巻で、道具がひとりでに動く場合を仮定しています。
"if thus shuttles wove and quills played harps of themselves, master-craftsmen would have no need of assistants..." （もし杼がひとりでに布を織り、撥がひとりでに竪琴を奏でるなら、親方は助手を必要としないだろう...。英訳からの訳は筆者）
アリストテレスが助手を不要にする条件として挙げたのは、杼がひとりでに動くことでした。同じ箇所では、助手を「いわば、いくつもの道具に先立つ道具」と呼んでいます。私の言葉で言えば、助手は杼があってはじめて役に立ちます。「SaaS is dead」の議論は、優秀な助手がいれば杼は不要になる、と考えているように見えます。私は、AIエージェントは杼を扱う助手に当たると考えています。助手の仕事はAIエージェントが担えるようになりますが、杼は残ります。何を作るかを決め、成果に責任を負う親方も残ります。
システムの利用者のアカウントも、同じ構図で考えます。入力作業を代行する人のアカウントは、減りうると考えます。一方で、承認には本人の判断と責任が必要なため、申請・承認の責任を負う人のアカウントは減らない、と私は考えます。承認するかどうかは、承認者が申請の内容と利害を判断して決め、その責任を負います。AIエージェントは、承認者本人の権限の範囲内に限って、確認・操作・分析を行います。AIエージェントは、承認者本人が判断して指示した場合に限り、承認・却下の操作を行います。この場合も、操作は本人のアカウントで行われ、操作の履歴にも本人の操作として記録されます。申請者についても、申請するかどうかと申請の内容は本人が決め、責任を負います。AIエージェントは、本人の権限の範囲内に限って操作します。
これから問われるのは、AIエージェントにどの道具を、誰の権限で使わせ、その結果に誰が責任を負うかを、組織として設計することです。当社では、AIエージェントが使う道具の一つとして、製品について公開しているナレッジを検索・参照できるMCPサーバーを準備しています（提供の準備中です）。
出典
- アリストテレス『政治学』第1巻1253b（H. Rackham英訳・1944年）・Perseus Digital Library・http://www.perseus.tufts.edu/hopper/text?doc=Perseus:text:1999.01.0058:book=1:section=1253b
ツバイソ株式会社
代表取締役 CEO 印具 毅雄(イング タケオ)
公認会計士、税理士
広島生まれ、福岡育ち。中学生の頃からパソコン、プログラミングが好きで、N88-BASICやマシン語に親しむ。大学、大学院では、AI関連技術のニューラルネットワーク、ファジィシステムとともに遺伝的アルゴリズムの改善研究をC言語で行う。
1999年、修士（芸術工学）。日本知能情報ファジィ学会論文賞受賞「単峰性関数当てはめによるGA（遺伝的アルゴリズム）収束高速化」
インターネットベンチャーを立ち上げるべく、経営の勉強のために公認会計士を取得（公認会計士二次試験2000年合格、登録番号19193）。監査法人トーマツ（Deloitte）を経て、2006年にブルドッグウォータ株式会社の創業、事業開始。
2015年、同社よりRobotERPツバイソ事業を会社分割し、ツバイソ株式会社を設立。
