〜AIと作った山舩のシステム統合記〜
普段はhgr.jpでWeb制作の仕事をしていますが、実はもう一つ、さわら出汁パックを作って販売している合同会社山舩という会社もやっています。今回はそちらの話です。
タスク管理ツールやSEOツールと同じで、「非エンジニアでもAIと一緒にシステムを作れる」という話の延長線上にあります。今回は経理・会計まわりです。
はじめに
合同会社山舩は、さわら出汁パックなどを百貨店やサービスエリアで販売している会社です。
このシステムは、最初から会計を作ろうとして始めたわけではありません。もともとは在庫管理と、見積書・請求書の発行を自動化したくて作ったシステムでした。きっかけは卸販売を始めるタイミングです。卸が始まれば在庫と卸価格の管理が絶対に必要になるのは目に見えていましたが、まだ売上が立っていない段階で外部の在庫管理システムに発注するような予算感でもありません。だったら「AIでできるところまで自分でやってみよう」というのがスタートでした。実際に手を動かしながら在庫管理の流れそのものを見直したり、「ここはこうなっていないと使いにくい」という気づきが出るたびに設計と開発を交互に回す、という進め方をしています。
請求書発行の自動化まで進んだところで、「じゃあこの請求データ、そのまま仕訳にも使えるんじゃないか」と気づいたのがきっかけです。売上・請求・在庫は元々つながっている情報なのに、会計だけGoogleスプレッドシートで別管理していたのが非効率でした。だったら会計も同じシステムに統合してしまおう、という自然な流れで会計機能を追加しました。
売上が増えてくると、経理の手間も比例して増えていきます。毎月の仕訳入力、年末の税理士への提出、「あの取引どこに書いたっけ?」という検索地獄。この記事では、在庫・請求書のシステムに会計を統合するところまでを、Claudeとの開発過程も含めてまとめます。
課題:スプレッドシート仕訳の限界
在庫管理・請求書発行はすでにシステム化されていましたが、会計だけは相変わらずこんな状態でした:
毎月の作業
- 銀行の入出金明細を見ながら、Googleスプレッドシートに手入力
- 日付・勘定科目・摘要・入出金額・残高を1行ずつ記録
- 仕入先・ローン返済・各種経費…件数が多い月は30件以上
年末の作業
- 1年分のスプレッドシートを税理士に渡す
- 「この取引は何ですか?」という確認が毎年発生
特につらかったのが、銀行CSVと手入力の二重作業でした。銀行の明細を見ながら、それをスプレッドシートに打ち込む。単純だけど時間がかかる、ミスもある。すでに請求書発行はシステムで自動化できていたのに、会計だけ手作業に取り残されている状態がちぐはぐで、「ここも同じシステムに寄せられるはず」と思ったのが開発のきっかけです。
設計の方針:難しくしない
会計システムと聞くと「複式簿記」「借方・貸方」というワードが浮かびます。でも、実際の業務に必要なものを整理すると:
- 日付
- 勘定科目(売上高・仕入高・支払手数料など)
- 摘要(何の取引か)
- 入金額 or 出金額
- 残高(自動計算)
これだけでした。税理士に提出するのも、この形式のデータです。
いわゆる現金出納帳スタイル。1行1科目で、シンプルに記録する方式です。
複式簿記(借方・貸方を別々に記録する)も検討しましたが、実際の運用を考えると「1科目・入金か出金か」で十分でした。シンプルな設計が後々の開発をスムーズにしました。
作った機能
1. 仕訳帳
手動入力用の基本画面です。
- 日付・勘定科目・補助科目・摘要・入出金額を入力
- 残高は自動計算
- 月別・科目別の絞り込み表示
- CSV出力(税理士への提出用)
勘定科目はマスタで管理。よく使う科目(売上高・仕入高・支払手数料・長期借入金・地代家賃など)をあらかじめ登録しておくことで、入力時はプルダウンから選ぶだけになりました。
2. 売上との自動連携
在庫管理システムで請求書を発行すると、自動的に仕訳帳に記録されます。
請求書発行
↓(自動)
仕訳帳に「売掛金 / 売上高」を記録売上の仕訳を手入力する必要がなくなりました。
3. 銀行CSV自動仕訳(メイン機能)
住信SBIネット銀行からダウンロードしたCSVをアップロードすると、自動で仕訳を生成する機能です。
仕組み
- 事前にキーワード→勘定科目のルールを登録
- CSVをアップロード
- 各行の「内容」をルールと照合して科目を自動設定
- プレビューで確認(修正可能)
- 登録ボタンで一括仕訳
ルールの例
| キーワード | 勘定科目 | 摘要テンプレート |
|---|---|---|
| 日本政策金融公庫 | 長期借入金 | 借入金返済 – %content% |
| リコーリース | 地代家賃 | リース料 |
| 振込手数料 | 支払手数料 | 振込手数料 |
| スクエア(入金) | 売上高 | Square入金 – %content% |
| ピーオーピー | 仕入高 | 仕入 – %content% |
%content%は銀行CSVの内容に自動置換されます。
重複チェック機能
同じ日付・金額・内容の仕訳がすでに登録されている場合、「重複の可能性あり」と警告を表示。手動と自動の二重登録を防ぎます。
開発秘話:動いているのにデータが登録されない謎
銀行CSV自動仕訳の実装で、一番ハマったのがこれです。
CSVをインポートして「○件の仕訳を登録しました」というメッセージが表示される。でも仕訳帳を確認するとデータが0件。
「メッセージが出てるのになぜ?」と原因を探ると、二重の問題が隠れていました。
問題1:テーブル設計のミス
最初、ルールテーブルを複式簿記を前提に設計していました:
debit_subject_id(借方科目ID)
credit_subject_id(貸方科目ID)でも既存の仕訳帳は単式記帳スタイル(1行1科目)。この設計の食い違いで、データが正しく送られていませんでした。
問題2:必須チェックで全件スキップ
登録処理に「借方科目IDが空なら登録しない」というチェックがあり、全件スキップされていました。だから「○件登録しました」と表示されても実際には0件だったのです。
// バグあり:存在しないカラムをチェックしていた
if (empty($d['debit_subject_id'])) continue;
// 修正後:正しいカラムをチェック
if (empty($d['subject_id'])) continue;テーブル設計を単式記帳に統一し直すことで解決。既存システムの設計を理解してから拡張するという教訓になりました。
開発秘話:CSV出力で年度が切り替わらない
仕訳帳のCSV出力ボタンを押すと、画面で2025年を選んでいるのに「2026年のデータが出てくる」という問題が発生しました。
原因は単純で、CSV出力リンクに検索条件が含まれていなかったのです。
// バグあり:条件なし
<a href="journal_export.php">CSV出力</a>
// 修正後:年・月・科目を引き継ぐ
<a href="journal_export.php?year=<?= $year ?>&month=<?= $month ?>">CSV出力</a>1行の修正で解決。でも「画面に表示されているデータと出力されるデータが一致していない」という状態は、経理業務では致命的なので、早めに気づけて良かったです。
税理士さんの反応
会計機能が完成してから、税理士さんに実際に使ってもらいました。
反応は「かなり満足」とのこと。
特に評価されたポイント:
- 年間データをCSV一発で出力できる
- 銀行明細と仕訳が自動で連携している
- 月次・年次の集計が一目瞭然
まだ細々とした要望はあるようですが、それは今後対応予定です。
数字で振り返る
開発前
- 毎月の仕訳入力:30〜50件を手入力
- 所要時間:月2〜3時間
開発後
- 売上仕訳:自動(0件手入力)
- 銀行取引:CSVインポートで約8割が自動仕訳
- 手入力が必要なもの:特殊な取引のみ
- 所要時間:月15〜30分程度
毎月2時間以上かかっていた作業が、30分以下に短縮されました。
やってみてわかったこと
1. 「何を記録したいか」を明確にすることが全て
会計システムというと難しそうに聞こえますが、「自分が税理士に渡しているデータは何か」を整理すると、必要な機能がシンプルに見えてきました。複雑な機能は後回しにして、まず「使えるもの」を作ることが大切でした。
2. 自動化は「確認できる形で」
銀行CSVの自動仕訳は、いきなり登録するのではなく、必ずプレビューを挟む設計にしました。「自動化 = 人が確認しない」ではなく、「自動化 = 人の作業を減らしつつ、確認は人がする」という考え方が安心して使えるシステムにつながりました。
3. シンプルな設計が拡張しやすい
複式簿記にしなかったことで、開発はシンプルになりました。もし将来、税理士さんから「複式簿記で出力してほしい」という要望が出たとしても、現在のデータから変換する仕組みを作ることができます。最初から完璧を目指すより、「今必要なもの」から始める方が結果的に早く使えるようになりました。
おわりに
Googleスプレッドシートでの手仕訳から、自動仕訳システムへの移行。
技術的には複雑な部分もありましたが、一番大切だったのは「自分たちの業務をどう整理するか」という部分でした。AIはコードを書いてくれますが、「何を作るか」は人間が考え続ける必要があります。
この記事が、経理業務の自動化を考えている方の参考になれば幸いです。
タスク管理ツールやSEO保守ツールの開発話も同じ視点で書いているので、よければそちらも読んでみてください。




