初めての月次請求をAIに頼んだ日。AIも私も間違えながら、仕組みを整えました

今回できたこと

月次請求を、AIに頼んで下書きまで作れるようになりました。ただし、1回で終わった話ではありません。

初回のnoteはこちら

初回作成は私が動かしました

前回の最後に「初めてのAI月次請求を社員に頼みます」と書きました。
ただし、9月分は私の環境で回しています。みんなのパソコンにも同じ環境を作りますが、それが私の環境と全く同じ動きをするかは、検証してからでないと分かりません。検証のないまま、いきなり本番で動かさない。これはシステム開発のどのやり方でも同じで、AIになっても変わりません。だから、社員に渡すのは、検証のあとにしました。

結論から言うと、AIも間違えました。そして、私も間違えました。 仕組みが正しく動くようになるまで、かなりチェックしました。一度で完璧には動きませんでした。9月の初めに最初に回したときは、まだ不完全で、確認して、直して、また回す、を何度か繰り返しています。最終的には、全部合った状態になりました。

やりとりの途中で、AIが勘違いをしていることもあれば、「それ、私が勘違いしていました」と気づくこともあります。どちらが悪いという話ではありません。AIと開発するというのは、お互いの勘違いを、ロジックで確かめながら進めることだと感じています。

「AIに任せたら勝手にうまくいく」という話ではありません。今のAI開発は、作る → 確かめる → 直す、を何度も回しながら進んでいます。
この連載は、その回している様子ごと書いていくことにします。

頼み方は、一言でシステムが動く

「9月分の請求データを作成して」

AIが契約と案件の台帳を読んで、請求書の下書きと報告をまとめて返してきます。第1回で書いた「社員が1週間前から準備していた」作業が、一言の依頼から始まる形に変わりました。

見つかったのは、お互いの勘違いと、言葉になっていないルール

チェックで見つかったものは、大きく3種類ありました。

AIの勘違い

入金の付け合わせや見積書の作成で、AIが前提を取り違えたことがありました。AIは間違いを認めて、「次から同じ勘違いをしないように」と、自分で覚えておく場所にメモを残しました。

人の勘違い

請求書の「支払期限」は、入金予定日の欄の日付が印字されます。帳票サービス側の設定を失念し、私は支払期限日という別のフィールドを作り入れていました。AIが気づいて指摘してくれなければ、支払期限が空欄の請求書を発行するところでした。システム屋でも、入れる場所を間違えます。

AIが合っていて、疑った私が間違っていた

同じ取引先の請求書が、2枚に分かれていました。「顧客ごとに1枚にまとめるはずなのに」と、最初は不具合を疑いました。調べると、その会社は、自社で使う分と、複数の会社で按分する分の、2つがあったんです。同じ会社宛でも、請求書は2枚に分けるのが正しい。
そのイレギュラーはルール通りに取得していた。
AIは合っていました。

でも、確認が走ったから、合っていると分かった。確認しなかったら、「AIは合っていた」とも「間違っていた」とも言えません。AIの出したものが正しくても、人が確かめる工程は、なくなりません。

人の頭の中にしかなかったルール

• 製品によって、課金が始まるタイミングが違う（発注の翌月から／契約した月は無償、など）

• 毎月同額のサービスは、案件を毎月コピーせず「契約」として台帳に載せる

• 同じ会社の請求は1枚にまとめる。ただし単発のものは別の1枚にする

• 明細の品目名には「2026年9月分」のように対象の月を入れる。逆に入れない会社もある。

後者は、経理担当が「覚えていた」ことです。人が回しているうちは表に出ません。AIに渡そうとして、はじめて言葉になっていないと気づきました。

テストは、AIが作った後にこそ必要でした

AIが作ったものでも、テストフェーズは省けません。むしろ、作るのが速いぶん、確かめる作業の重みが増します。

9月は、旧システムで作った請求と、新しい仕組みで作った請求を並べて突き合わせました。その中で、契約台帳に載っていなかった月額のサービスを、人が見つけました。AIが完璧だったのではなく、完璧でなくても業務が守られる段取りを先に組んでおいたから、漏れる前に気づけた。

AIが作るのは下書きまで。数字は作らず、元のデータから取る。迷ったら止まって人に聞く。この安全設計のおかげで、間違いは「下書き」の段階で止まりました。

明細の表は、送らなかった行が消える

kintoneを、AIにつないで使う方に、ぜひ知っておいてほしいことがあります。

請求書や案件の明細は、「テーブル」と呼ばれる表の形で入っています。このテーブルを、APIという方法で更新するとき、一部の行だけを更新しようとして、その行だけを送ると、送らなかった行が削除されます。 変えたい行以外も含めて、既存のすべての行を送る必要があります。kintoneの公式のドキュメントにも書いてある仕様です。

私たちは、この仕様を、使ってみてから知りました。9月20日、案件の明細に、商品名を紐づける作業をしていたときです。条件に合う行だけを送った結果、5件の案件の明細が消えました。

幸い、旧システムに元のデータが残っていたので、全部復元できました。 並行稼働で旧システムを残していたことが、バックアップとして効いたんです。

ここから、決めたことがあります。

• 明細を1行でも更新するときは、いまある全行を読んで、変えない行も含めて送る

• 書き込む前に、合計金額と行数を記録する。書き込んだ後に、突き合わせる

• レコードそのものを消すのは、人だけ。AIは消さない。消す前に、AIが「何を消して、何を戻すか」の計画書を作り、人が見て承認する

• 月次請求の「作り直し」は、明細を全行まるごと置き換える設計にしてある。手で足した行や直した金額が消えるので、守りたいものには鍵（ロック）をかける

kintone開発をしているエンジニアであれば、APIの仕様を知っていて最初から配慮した作りになるでょう。
でも、私はコードを書かないので最初から指示は出せませんでした。
AIが間違えたのでも、私が間違えたのでもありません。仕様を知らないまま、頼んでいた。
これって、新人に仕事を任せた時に起きそうな事例ですよね。分かってる人がやれば起きないことも、知らないと起こる。
だから、業務の「目的」と出てくる「答え」をユーザーがきちんと知っている必要があります。
そして分かったら、手順書に書く。
AIとともに業務システムを開発するコツとして、それを繰り返しています。

直したことは、手順書に戻しました

見つかったルールは、全部手順書に書き戻しました。手順書が1本増えて、既存の手順書も厚くなりました。

AIに教えるために言葉にしたことは、そのまま会社に残ります。新しい人が来ても、私がいなくても、このルールは残る。初めての月次請求でいちばん価値があったのは、請求書の下書きではなく、この手順書だったと思っています。

今回人に残した仕事

• 下書きの確認（経理担当）と承認（私）

• 新旧の突き合わせと、ずれの判断

• AIの間違いと、抜けていたルールを見分けて、手順書に戻すこと

真似するなら

• 毎月やっている仕事を、「○月分の△△を作成して」の一言で頼める形まで、手順として言葉にしてみる。言葉にできない部分が、人の頭の中にあるルールです

• 最初の1回は、人が今までどおりやった結果と並べて確かめる

• AIが勘違いしたら、直して終わりにしない。手順書に戻して、次から同じ勘違いが起きないようにする

• kintoneをAIにつないで使うなら、kintoneエンジニアの開発記事をたくさん学習させる(Qiitaや developerサイトなどをもっと読み込ませる)

• kintone ドキュメンテーションMCPも使う
  

締め

システムとしては、安定していきます。ただ、いろんな人が使い始めると、改善したいところが次々に見えてきます。

直し方は、そのときどきで違います。AIに頼んで直すこともあれば、プラグインという追加の部品で対応することもあります。
仕組みそのもの、ロジックを変えることもあります。

AIに任せるのか、プラグインで済ませるのか、ロジックを変えるのか。その分かれ目は、分岐が多いか、決まりきっている処理か、スピードが要るか、で決めています。
自分で分岐の項目を作って、直したら「これ直したよ」とAIに伝えて、手順書を書いてもらう。決まった型はなくて、臨機応変にやっています。

体感ですが、月末月初の作業ボリュームは、明らかに減りました。数字で測ったわけではないので、そこは体感として書いておきます。

この連載は、完成した仕組みの紹介ではなく、直しながら使っている日々の記録です。次回以降、直したところも、まだ直せていないところも、そのまま書いていきます。

▶ この記事を読んだら、AIにこう頼めます

「○月分の請求データを作成して」と、毎月の定型作業を一言で頼む。その前に、手順を言葉にしておくことはどのフェーズにおいても重要です。

自分の業務の流れ、ちゃんと理解してますか？

お知らせ

この連載で書いている仕組みを、手順ごと納品して私がいなくても回る形にするサービス「Haidy（ハイディ）」。無償の初回診断を、お問い合わせフォームから受け付けています。

木村琴絵／ 釧路 ／ Voicy「コトラジ」配信中