領収書も通帳も請求書も、AIが仕分け。リアルタイム管理会計へ。

背景と課題：少人数で全工程を回しながら、数字だけが見えていなかった

土地の仕入れからリノベーション、販売までを一体で運営する、中規模の不動産デベロッパーのお取り組みです。

仕入れ・制作・販売の複数フェーズにまたがる、多数の工程で事業が動いています。

特徴的だったのは、その体制の少なさです。

代表者が営業・物件発掘・価格判断・プロジェクト管理までを一手に担い、経営管理を支えるパートナーとの少人数体制で資金繰りまで握っていました。

事業のスピードは速い一方で、判断と作業が一人に集中し、数字の整備が後回しになりやすい構造がありました。

設立から日が浅く、これから案件数も組織も拡大していくフェーズです。

だからこそ「拡大に耐えられる情報基盤を、いま整えたい」という強い意志が、ご相談の出発点でした。

ヒアリングと業務分解を通じて見えてきたのは、財務まわりに集中した3つのペインでした。

第一に、財務データの分散と手作業です。

案件ごとの損益・キャッシュフロー・残高が一元化されておらず、入力は手打ちが中心で、月次の数字が遅れて出てくる状態でした。

第二に、案件別の費用配分が自動化されていないことです。

建築費・設計費・測量費などが案件に紐づかず、正確な案件別の採算把握が難しくなっていました。

第三に、情報の分断です。

クラウド上のフォルダ構造と、表計算で管理している案件情報が常に食い違い、ステータス更新や仕分けは手作業のため同期漏れが頻発していました。

これらを放置したときのコストは、単なる作業時間にとどまりません。

案件別の採算が遅れて見えれば、価格判断や次の仕入れ判断が後手に回ります。

数字が一人に集中したままでは、組織を増やしても権限を渡せず、属人化がボトルネックになります。

成長フェーズだからこそ、「数字が見えない」ことそのものが意思決定の速度を奪う最大のリスクでした。

なぜHarry&か・解決の中身：まず診断し、撮って送るだけの形に落とす

私たちは、いきなりシステムを作り始めることはしませんでした。

最初に行ったのは、業務を細かく分解し、現状の流れを構造化し、どこに何の手を入れるべきかを設計する診断フェーズです。

この過程で、ご要望のすべてを一度に作るのではなく、「財務のデータ化を最優先にし、分析・会計連携は段階的に」という順序をご提案しました。

優先度と実装順を明確にし、最小のスコープから着実に価値を出す設計です。

本当に必要なものを見極めてから作る——この逆算が、過剰な投資を避けることにつながります。

進め方も、丸投げにはしませんでした。

設計の全体像を説明し、実装へ移る段階で正式にご承認をいただいてから着手しています。

以降も、案件責任者がお客様と同席して進捗を確認する体制をとり、要所では人の最終確認を挟む運用としています。

AIに任せきりにせず、重要な判断は必ず人が握る——この線引きが、安心して任せていただける土台になりました。

第一弾として実装したのは「自動入力・データ化」です。

領収書などの証憑を、スマートフォンで撮影するかメールに添付して送るだけ。

AIが画像から金額・取引先・日付といった項目を自動で抽出します。

抽出した情報をもとに、AIがどの案件のものかを判定し、案件別のフォルダへ自動で振り分けます。

同時に、構造化されたデータとしてデータベースへ格納し、普段ご覧になっている表計算シートにも自動反映します。

これにより、証憑の仕分けとファイリングという手処理そのものをなくしました。

技術面では、証憑の読み取りに画像認識のAIを、情報基盤に権限管理付きのデータベースを採用しています。

案件IDを軸に、版管理・証憑保管・表示面を多軸で連携させ、案件マスターを「正本」として一元管理します。

経営に関わる資金繰りの情報は、権限を分離して経営層のみが閲覧できるよう設計しました。

重要なのは、既存のクラウドストレージ・表計算・チャットを置き換えていない点です。

お客様が日々使っている道具はそのままに、その裏側にAIが読める土台を構築する——これが導入摩擦を最小にする設計でした。

さらに、AIが抽出した値は確認画面で人が最終チェックしてから確定する仕組みにしています。

将来の会計ソフト連携も見据えて、仕訳の自動化へ段階的に移れる構造にしてあります。

成果：手作業をなくし、案件別に見える基盤を整える

第一弾の実装により、証憑の仕分け・ファイリングという手処理を排除する仕組みが整いました。

これまで人手で行っていた入力・整理が、撮って送る／メールするだけの動作に置き換わります。

あわせて、案件マスターを正本として一元管理し、権限分離を両立させました。

データの一貫性を保ちながら「経営に関わる数字は経営層だけが見る」状態を実現しています。

バラバラだった証憑・フォルダ・表計算が、案件IDを軸に一本の流れにまとまります。

本記事の段階では、自動振り分けと確認画面が動作確認済みで、実データでの検証へと進めているフェーズです。

誇張なくお伝えすると、ここからが本番の価値検証です。

ただし「拡大しても数字が見える」ための土台は、すでに動く形で立ち上がっています。

私たちがここで迷ったこと：スコープをどこに絞るか

最初のヒアリングで出てきたご要望は、財務のデータ化・案件別採算の見える化・情報基盤の整備・会計連携・ステータス管理と、複数の領域にまたがっていました。

すべてを同時に設計・実装しようとすれば、最初の成果が出るまでに時間がかかります。

途中でスコープが広がる事態を招くリスクもありました。

私たちが迷ったのは、どの課題を起点に選ぶかという優先判断でした。

最終的に「証憑の自動取り込みとデータ化」を第一弾に選びました。

即効性が最も高く、かつ次の機能拡張の土台にもなる起点だと判断したからです。

全要望を一度に作らず、最小スコープから動く状態を早期に確認してから広げる——この判断の根拠を、実装移行前にお客様と合意することを私たちは重視しています。

内製ではなく外に出す価値：「何から手をつけるか」の設計工程から入れる

このプロジェクトで私たちが最初に行ったのは、業務を細かく分解し、現状の流れを構造化し、どこに何の手を入れるべきかを設計する「診断フェーズ」です。

システムを作り始める前に、課題の全体像と優先順位を外部の目で整理します。

設計の全体像を説明し、実装へ移る段階でお客様の正式な承認を得てから着手する——この進め方は、認識のズレを残さないためのものです。

内製で課題に取り組む場合、診断と実装が同じ担当者に重なることが多くなります。

すると「本当に必要なものから順に作る」設計に立ち返る機会が少なくなりがちです。

外部を使う価値の一つは、この優先判断そのものを客観的な視点で行えることにあります。

どんな会社に向く事例か：少人数で複数工程の事業を回しながら、情報の土台を整えたい組織

この事例が当てはまりやすいのは、次のような状況です。

少人数の体制で、仕入れ・制作・販売など複数の工程にわたる事業を運営していて、それぞれの工程でデータが分散したまま管理されている。

代表者やキーパーソンに情報と判断が集中していて、組織を拡大するほど属人化がボトルネックになるリスクを感じている。

案件別の採算をリアルタイムに把握できる状態にしたい——そうした場合に特に向きます。

逆に、まだ事業の基本的な業務フローが固まっていない段階では、情報基盤の整備より業務設計が先になることがほとんどです。

また、扱うデータ量や案件数が少なく、手作業での管理が特に問題になっていない場合には、この規模の実装が過剰になることもあります。

まず診断で現状を分解し、本当に必要かどうかを一緒に確かめてから進める、というのが私たちのやり方です。