現場の勤務、経費、請求を扱う出面帳を作りながら、業務システムの作り方について考えていることをまとめておきます。
入口は、GrokBotのような形が正しい
普段の保守や小さな改修は、GrokBotに任せています。GitHubやVercelなどのプラグインを入れておけば、「これをやっておいて」と言うだけで、対象を読み、必要な操作をして、結果を返してくれます。決まった時間に動くルーチンも組めます。
この形は、Palantirのオントロジーの考え方にかなり近いと感じています。業務に出てくる「もの」（案件、勤務、請求書）と、そのつながりと、許された「操作」（承認する、確定する、取り消す）を定義しておき、人もAIもその操作を通して仕事をします。画面は、その操作を呼び出す入口の一つにすぎません。
そう考えると、エージェントに組織の権限をきちんと持たせられるようになれば、業務システムの多くはGrokBotのようなエージェントが巻き取ってしまうと思います。ただ、必要なのは権限だけではありません。誰の承認を通ったか、何を誰が変えたかの履歴、同じ処理を二重に実行しない仕組みがそろって、はじめて任せられます。
Webで作るときも、載せ替えやすくしておく
いまはまだ、Webの業務画面として作ることがほとんどです。それでも、あとからエージェントへ載せ替えやすい設計にしておくべきだと考えています。
具体的には、画面ごとに処理を書くのではなく、「もの」と「操作」を画面から切り離して定義しておくことです。出面帳では、きんたい、せいきゅう、しはらい、しめ、うりあげと、業務ごとに会話画面を分けています。前身はDiscordのbotでした。業務を会話と操作の単位で切っておくと、入口が画面からエージェントへ変わっても、中身はほとんど変えずに済みます。
もっとも、すべてを会話にすればよいわけではありません。呼び出しや定常の作業はエージェントに向いていますが、候補を見比べて判断する作業は、いまも画面のほうが向いています。この使い分けは、非エンジニアでもシステムは作れるのかについてにも書きました。
浮いたコストは、if文に使う
AIのおかげで、実装のコストも、考えるコストもかなり下がりました。その浮いた分は、if文を精巧に作ることに使うべきだと思っています。
業務システムを使い続けてもらえるかどうかは、使う人がどれだけ迷わずに済むかで決まります。例外の多い現場ほど、「この場合はこう」「この状態ではこの操作を出さない」という分岐を細かく作り込むほど、使う人の負担は減ります。以前なら手間がかかりすぎて諦めていた細かさにも、いまなら手が届きます。
出面帳では、会話画面の返答、金額、時間をLLMに任せず、すべてコードで計算しています。見た目は会話でも、中身は作り込んだ分岐です。そしてこの分岐を画面ではなく「操作」の側に置いておけば、入口がエージェントに変わっても、同じように迷わせずに済みます。
業務ごとに、積極的に分けていい
前提として、フロントエンドの実装はほぼ無料のようなものになりました。そうであれば、業務システムは業務ごとに積極的に分けて作ってよいと考えています。一つの大きなシステムに何でも詰め込むより、業務ごとに小さく作ったほうが、画面も分岐も単純になります。
ただし、分けるのは画面の側です。業務データ、権限、オントロジーまでばらばらにすると、同じ情報が食い違い、管理が破綻します。画面は業務ごとに分け、下の層は共有する、という分け方がよいと思っています。分けた分だけ増える保守の手間は、GrokBotの定期ルーチンでかなり吸収できます。
ドメイン知識は、ワークフローとコンテキストの置き場所
業務システムを作るとき、業界の知識をすべて持っている必要はないと思っています。本当に必要なのは、その業務で普段使っているワークフローと、どこにコンテキストを保管しているかを把握できるかどうかです。
誰が何をきっかけに作業を始め、どこで判断し、何を残して終えるのか。必要な情報は、共有ドライブにあるのか、表計算にあるのか、それとも担当者の頭や電話の中にあるのか。ここが分かれば、「もの」と「操作」はおのずと決まり、どこをエージェントに任せ、どこに人の判断を残すかも見えてきます。