業務ツールは「作る」時代へ——AIエージェントで自社専用シミュレーターをつくるという選択肢

業務ツールの内製とは、自社の業務に合わせたソフトウェアを、既製のSaaS(ソフトウェアを買わずネット経由で借りる仕組み)に頼らず自分たちで作ることです。以前はエンジニアの採用と数百万円規模の予算が必要でしたが、AIエージェント(指示に沿って自らコードを書き進めるAI)の登場で、少人数のチームでも試作から公開まで到達しやすくなりました。この記事では、私たちがリフォーム会社向けの概算見積シミュレーター「メヤス」を実際に内製した過程から、内製すべきかどうかの判断基準と始め方を整理します。

なぜ「買う」から「作る」に選択肢が増えたのか

理由は、ソフトウェアを作る手間そのものが変わったからです。以前は要件定義・設計・実装・テストのそれぞれに専門知識と時間が必要で、小さな会社が独自ツールを持つという発想自体が現実的ではありませんでした。

いまはAIエージェントに業務の流れを説明すると、動くプロトタイプ(試作品)をその場で生成できます。私たちが6日間でプロダクトを1本作った記録はClaude Codeで6日プロダクトを作った話に残しています。もちろん開発にかかる時間は業務の複雑さで変わるため、「誰でも同じ日数で作れる」と一般化はできません。

以前との一番の違いは、試すためのコストです。かつては「作ってみて、違ったら捨てる」ができませんでした。一度発注すれば見積もりと納期が発生し、外れたときの損が大きすぎたからです。

いまは試作を捨てる前提で始められるので、最初に正解を当てる必要がなくなりました。ここが「買う」との決定的な差です。既製品は買ってから合わないと分かっても、捨てるのに勇気が要ります。

ただし、変わったのは作る手間で、変わっていないのは決める手間です。何を入れたら何が出てくるか、例外のときはどう扱うか——ここを言葉にするのは、いまも人の仕事として残ります。AIエージェントは決まったことを速く形にしますが、決まっていないことは形にできません。

汎用ツールのどこに限界があるか

Excelのテンプレートや汎用のSaaSは、多くの会社に共通する部分をカバーするために作られています。だからこそ、自社の業務に特有の計算ルールや例外条件は、テンプレートに合わせて業務のほうを変える必要が出てきます。

リフォーム業界の見積もりを例にすると、工種ごとの原価構造・グレード別の価格帯・地域差のある諸経費など、汎用ツールでは吸収しきれない項目が積み重なります。既製の見積ソフトを比較検討した記録はリフォーム見積ソフトの比較にまとめています。汎用ツールが悪いのではなく、「自社の業務ロジックが、どれだけ独自か」で向き不向きが分かれるということです。

テンプレートに業務を合わせると、合わなかった分はどこかに逃げます。多いのは備考欄・手書きのメモ・担当者だけが知っている口頭の補足です。逃げた分は集計にも引き継ぎにも乗らないので、使うほど「そのツールの外側」が増えていきます。

逆に言えば、テンプレートに素直に収まる業務なら、内製する理由はほとんどありません。判断の軸は「便利かどうか」ではなく、「自社のロジックがテンプレートに収まるかどうか」です。

私たちが内製した例 — メヤスの概算見積シミュレーター

私たちが開発しているメヤスは、リフォーム会社向けの概算見積シミュレーターです。社内の開発方針メモには「汎用ツールとは戦わない。品質・業界知識・運用で差別化する」という一文が残っています。既製品を置き換えるのではなく、業界特化の使い勝手そのものを商品にする発想でした。

プロトタイプは、要件を整理したその日のうちに、実際に数字を入れて動かせる形として試作できました。そこから改修を重ね、建物カテゴリごとの価格帯・グレード別の商品写真・問い合わせフォームの実送信までを、外部の受託開発に発注せず自分たちで組み上げています。商品写真も、AI画像生成ツールをブラウザ操作で連続実行して複数枚まとめて作成しました。

順番としては、まず見積もりの計算の流れをそのまま言葉にし、次にそれをAIエージェントに渡して画面の形にしました。数字が入って動く画面になると、机の上の議論では出てこなかった不足が見えます。

「この工種にはグレードの区別が要る」「この諸経費は地域で変える」といった指摘は、いずれも動くものを触ってから出てきたものです。言葉で書いた要件を読み返している段階では、誰も気づけませんでした。

外部に発注しなかったことで得たのは、費用よりも直す速さでした。気になったところをその日のうちに直して、次の日また触る。この回し方ができるかどうかが、業界特化の使い勝手を商品にするうえでは大きいと考えています。

内製する/しないの判断基準

すべての業務を内製すべきというわけではありません。向き不向きを整理すると、次のようになります。

左側に当てはまる項目が多いほど、内製で得られるものが大きくなります。

一方で、内製は「作った後も自分たちで持ち続ける」という選択です。使う人が増えれば要望も増え、直すかどうかの判断を毎回自分たちで下すことになります。

この重さを引き受けられるかどうかは、表のどの項目よりも先に来る前提条件です。持ち続ける体制がないまま作ると、動くけれど誰も直せないツールが社内に残ります。

小さく内製を始める4つの手順

いきなり完成形を目指すと、時間もコストもかかりすぎます。小さく始めるための手順は次のとおりです。

手順1で業務を1つに絞るのは、範囲が狭いほど「できた/できていない」の判定が速くなるからです。複数の業務をまとめて扱うと、うまくいかなかったときに原因がどこにあるか分からなくなります。

手順2の言語化は、いちばん飛ばされやすく、いちばん効く工程です。入力と出力を書き出す過程で、実は担当者ごとにやり方が違った、例外の扱いが決まっていなかった、といった論点が先に見つかります。ここを曖昧にしたままAIエージェントに渡すと、曖昧なままのツールができます。

手順3で「1つだけ」と限るのは、試作を捨てられる状態にしておくためです。作り込んでから方向を変えるほうが、早い段階で作り直すより高くつきます。

手順4は、使い始めてからの話です。使いながら直す前提で作るなら、最初の完成度は低くてかまいません。逆に最初から全業務をカバーしようとすると、一度も使われないまま手が止まります。

最初の1つが動けば、次の業務に広げるかどうかは、実際に使ってみてから判断できます。

よくある質問

Q. エンジニアがいなくても内製できますか。 簡単なプロトタイプであれば、AIエージェントに業務の流れを説明することで試作できます。ただし本番運用に必要なセキュリティ対応や継続的な保守は、規模が大きくなるほど専門知識が必要になります。

Q. 内製と既製ツールを併用してもいいですか。 問題ありません。汎用的な業務は既製のSaaSに任せ、自社特有の業務だけを内製するという組み合わせも現実的な選択肢です。

Q. 内製したツールのデータの扱いは大丈夫ですか。 どのAIツールにどこまでのデータを渡すかは、事前に取り扱い方針を決めておく必要があります。個人情報や機密情報を含む場合は、特に慎重な設計が求められます。

Q. 既製のSaaSと比べてコストは必ず下がりますか。 一概には言えません。試作にかかる時間は短縮できても、保守・改修・サポート体制まで含めたコストは業務の規模によって変わります。

まとめ

• 変わったのは作る手間で、決める手間は残る。「何を入れたら何が出てくるか」を言葉にする工程は人の仕事
• 向き不向きは「便利かどうか」ではなく、自社の業務ロジックがテンプレートに収まるかどうかで分かれる
• 始め方は、一番手間のかかる業務を1つ選び、言葉にして、動く試作を1つ作り、使いながら直す

リフォーム会社の見積もり業務そのものを、業界特化で内製した実例を見てみたい方は、メヤス(新しいタブで開く)の概算見積シミュレーターをご覧ください。

本記事は一般的な情報提供であり、開発期間やコストの効果を保証するものではありません。内容は2026年8月24日時点の自社での開発経験にもとづきます。