見積業務のAI効率化プロジェクト②
～　Claudeに「役割」を持たせた　～

1人のAIに、全部任せなかった

最初は、1つのClaudeに、設計から開発まで全部頼むつもりでした。しかし、データは数百万行です。設計、開発、確認が1つの会話に混ざると、どこで何を直したのか、すぐにわからなくなります。

そこで、AIが自分で作業を分けて進める「エージェント機能」を使うべきか、Claudeに直接相談しました。

返ってきた答えは、エージェントは、互いに独立した作業を任せるのに向いている、というものでした。今回は、データベースの設計と、アプリの開発が連動しています。一方を変えれば、もう一方も変わります。そのため、人間が役割を分けて、画面ごとに指示を出す、いまのやり方のほうが合うという判断でした。

実際には、「あなたはデータベース担当です」と伝えて、役割を書いたファイルを読み込ませると、すぐにその役割で動き始めます。エージェント同士が連絡を取り合う仕組みもあるため、結果的には、どちらでも大差ないのかもしれません。どちらが正解かは、いまもわかりません。

開発には、Anthropic社の上位モデル「Claude Fable」を、すべての役割で使っています。人間のチームと同じで、設計する人、作る人、疑う人が別々にいるほうが、抜け漏れは減ります。

3つの役割と、その分担

中心となる役割は、次の3つです。

• 　●　データベース設計担当（私は「DB君」と呼んでいます）：資料を読み込み、データベースを設計し、更新します。
• 　●　アプリ設計担当（私は「アプリ君」と呼んでいます）：見積アプリの画面と機能を設計します。データベースは触らないよう、指示しています。
• 　●　調査隊：データベースやアプリのコードを調べて、抜け漏れや不明点を指摘します。

ポイントは、「作る役」と「疑う役」を分けたことです。作る側のAIは、渡された資料の範囲で、もっともらしく仕上げてしまいます。そこへ、疑う側が入ることで、見えなかった穴が見えてきます。

調査隊の指摘が、止まらない

いちばん手強かったのは、調査隊です。指摘は、細かく、容赦がありません。たとえば、データベース設計担当には、次のような指摘が上がりました。

「約300あるExcelのうち、このファイルの、この部分が読み込めていません」

いちばん多かったのは、この指摘です。仕入先ごとに形式が違い、セルが結合されていたり、表の形が崩れていたりするため、読み込めていない部分が、あとからあとから見つかります。

指摘は、例えば「〇〇.xlsxの、左から5番目のシートの、何行目の何列です」というように、場所まで具体的に届きます。私の仕事は、その場所の元の資料を開いて、実際に何が書かれているのかを確認することでした。数えてはいませんが、100回近くは、この作業を繰り返したと思います。

「10年分のExcelの中に、同じ得意先でも、支所ごとに異なる売価を持っているものがあります。どう扱いますか」

「表の外に書かれた日本語を、読めていませんでした。値上げの時期が、表の外に書かれていました」

表の中のデータだけを読んでいても、表の外の一言に、大事な情報が隠れていることがあります。人間なら「見ればわかる」ことが、AIには見えないのです。

アプリ君にも、指摘が入ります。

• 　●　見積のひな形に入れるべき列の情報が、おかしい
• 　●　売価が未入力でも、マスタの売価が黙って補われ、営業担当者が入力漏れに気づけない
• 　●　数量が0以下でも、見積書を出力できてしまう

一つ直せば、次の指摘が上がってくる。地道な繰り返しです。まず、指摘された場所の元の資料を開いて、確認します。それでも意味がわからないときは、現場の担当者に聞きに行きます。答えを持ち帰って、また直す。調査隊の指摘だけでも、人間の確認だけでも、正しいDBやアプリはできませんでした。調査隊と人間が一緒になって、はじめて正しいものに近づいていく。これが、開発を通じた実感です。ただ、指摘、確認、現場への質問、修正の往復には時間がかかり、これが「3歩進んで2歩下がる」の正体でした。

不思議なことがあります。調査隊も、DB君も、同じClaude Fableを使っています。それなのに、DB君が自分では気づけなかった間違いを、調査隊が次々に見つけてきます。DB君は同じような間違いをすることも多く、なぜ調査隊は修正できるのに、DB君はいつまでも気づかないのか。不思議です。

一方で、気づいたことがあります。調査隊が指摘できるのは、資料に書かれていることだけです。資料に書かれていないことは、AIには見えません。この点は、連載の最後に、もう一度触れます。

データベースの選び方と、更新の仕組み

データベースには、SQLiteという軽量なデータベースを採用しました。理由は3つあります。

1つ目は、利用者が10名程度で、見積の検索が中心だからです。この規模であれば、軽く、速く動きます。現場でのテスト運用でも、動作に問題は出ていません。

2つ目は、部品が少なく、構成がシンプルなことです。データベースが1つのファイルで済むため、専用PCの中で完結し、バックアップもファイルを保管するだけです。将来、担当者が代わっても、引き継ぎやすい構成です。

3つ目は、データベース用のサーバーを別に借りたり立てたりせず、専用PC1台で完結させて、費用を抑えたかったからです。

ただ、データは数百万行あります。全件でデータベースを作り直すと、Claude Fableでも30分ほどかかります。設計を32版まで繰り返していた間は、この待ち時間が重なるため、途中から、変わった部分だけを更新する、差分更新の仕組みに切り替えました。

運用に入ったあとの毎月の更新は、全ファイルを読み直す方式です。新しいファイルを入れておけば、30分ほどかけて、夜間に自動で更新されます。完全に無人ではありませんが、使い続けられる形にすることまで含めて、設計しました。

こうして、担当者の方に実際の操作を見ていただいたうえで、見積アプリは、テスト運用に入りました。使い始めてもらうと、現場から早くも、「このアプリを、発注書づくりにも使えないか」という声が上がりました。使ってもらえているからこそ出てきた、前向きな要望です。

ただ、こうして活用を広げていくうえで重要なのは、AIの性能だけではありません。AIは、渡されたデータの範囲でしか、考えることができません。次回は最終回です。AIの性能以外で重要なポイントを、お伝えします。