帳票の自動生成見積を保存すると、製造現場の指示書が自動で立ち上がる
営業が見積を作成・保存した時点で、製造向けの架装指示書が自動生成されます。現場では内容を追記・編集し、既存のExcelテンプレートへ流し込んで出力。納車予定月を付けて作業時間管理システムへ共有され、進捗が双方向で反映されます。
「AIに仕事をさせる」と聞くと、何でも自動でやってくれる万能の存在を想像しがちです。実務でうまくいくのは、その逆です。判断が必要な部分は人に残し、判断のいらない部分——集める、転記する、形式を整える、決まった時刻に送る——だけを機械に渡す。この切り分けができている自動化だけが定着します。
TIFFINが実装してきたのは、たとえばこういう仕組みです。営業が見積を保存すると、製造現場向けの架装指示書が自動で立ち上がる。契約が成立した顧客が、毎時のバッチでオーナー向けの配信リストへ自動的に移る。毎朝8時に、当日出荷すべき注文と取り寄せ中の商品をまとめたメールが担当者に届く。支払条件に沿って請求書が定期的に自動生成される。どれも「誰かが忘れると止まる作業」でした。
生成AIが加わったことで、これまで自動化できなかった「文章を読んで判断する」部分も渡せるようになりました。ただしそこには誤りの可能性がついて回るため、まず下書きまでで止めて数週間動かし、精度を確認してから自動送信に切り替える——という進め方を標準にしています。
ISSUES
「うちの業務は特殊だから」と言われることが多いのですが、分解すると自動化できる部分は必ずあります。
月次の請求、定期の報告、フォローアップの連絡。担当者が休んだ日に抜け落ち、後で発覚する。
あるシステムの内容を別のシステムに手で入れ直している。件数が増えるほど時間とミスが増える。
画面操作を記録する方式のため、画面が少し変わっただけで動かなくなり、直せる人がいない。
間違ったメールがお客様に飛ぶのが怖くて、結局すべて手作業のままになっている。
どういう理由でそう処理したのかが分からず、後から検証できないため導入に踏み切れない。
会計、在庫、メール、Excel。それぞれが独立していて、間を人が埋めている。
SERVICE
実際に組んできた自動化の型です。
データの入力や状態変化をきっかけに、必要な書類を自動で作ります。人は確認と修正だけ行います。
毎朝・毎週・毎月の決まった処理を、忘れずに実行します。
届いた情報を読み取り、正しい場所へ登録します。
生成AIを使い、これまで人が読んで判断していた部分を扱います。必ず確認工程とセットにします。
申請から承認、通知、記録までを流れとして組みます。
既存の複数システムをつなぎ、人が間を埋めていた部分をなくします。
ENGINEERING
自動化で怖いのは「間違えること」ではなく「間違えたことに気づけないこと」です。
「金額が10万円以上なら部長承認」のように条件で決まることは、コードで判定します。AIに渡すのは、文章を読んで意味を取る必要がある部分だけ。これによって、動作が予測可能になり、費用も下がります。
新しい自動化は、必ず「作るところまで」で止めて開始します。数週間、人が確認して修正した内容を記録し、修正率が十分に下がったことを確認してから自動送信へ切り替えます。いきなり全自動にすると、事故が起きたときに信用を取り戻せません。
AIの判断には確からしさの度合いがあります。閾値を下回るものは自動処理せず「要確認」の一覧に積み、人が判断します。全件を人が見るのではなく、迷ったものだけを見る状態を作ります。
いつ、何をきっかけに、どういう根拠で、何をしたか。すべて記録します。「なぜこの請求書が作られたのか」を後から追える状態にしておかないと、監査にも障害調査にも耐えられません。
自動配信には、必ず停止ボタンと送信時間帯の制限を設けます。実案件のメール配信では、送信間隔と停止時間帯を管理画面から設定できるようにし、夜間や休日に大量送信が飛ばないようにしています。
自動処理でいちばん危険なのは、静かに失敗して誰も気づかないことです。実行結果を記録し、失敗時は担当者へ通知します。過去には送信予定が一覧から溢れて見えなくなる不具合を修正した例もあり、こうした「見えなくなる」設計を避けることを重視しています。
自動化のために業務システムを作り直す必要はありません。既存のデータベースやAPI、あるいはCSVの受け渡しを使って、外側から自動化を足すことができます。
| 実行基盤 | Node.js / Python のバッチ・ワーカー、cron による定期実行、Webhookによるイベント駆動。 |
|---|---|
| AI | Anthropic Claude ほかのLLM。構造化出力（JSON）で受け取り、後続処理が壊れないようにします。確信度に応じた分岐を実装。 |
| トリガ | 時刻、データベースの変更（イベント購読）、メール受信（IMAP）、フォーム送信、外部システムのWebhook。 |
| アクション | 帳票生成（ExcelJS / Puppeteer）、メール送信（SMTP）、LINE Messaging API、SMS（Twilio）、DB更新、ファイル出力。 |
| 監視 | 実行ログ、成功／失敗の記録、失敗時の通知、再実行、処理件数のダッシュボード。 |
| 安全装置 | 送信時間帯の制限、送信間隔の制御、停止ボタン、下書き／自動の切替、取り消し操作。 |
「この作業、自動化できますか？」という単発のご相談から入っていただけます。1つ自動化して効果が出てから、次に広げるのが確実です。
WORKS
実際に日々動いている仕組みです。
営業が見積を作成・保存した時点で、製造向けの架装指示書が自動生成されます。現場では内容を追記・編集し、既存のExcelテンプレートへ流し込んで出力。納車予定月を付けて作業時間管理システムへ共有され、進捗が双方向で反映されます。
届いた問い合わせを分類し、過去の対応履歴と価格表を参照して返信案を作ります。送信ボタンは人が押す設計です。まず下書き止まりで運用し、修正率を見ながら自動化の範囲を広げていきます。
「半年以上連絡のないオーナー」「未処理の展示会問い合わせ」「見積を出したまま連絡していない顧客」を毎日自動で抽出し、朝いちばんのダッシュボードに表示します。人が探しに行く必要をなくす自動化です。
休み依頼が出た時点で、資格・雇用区分・当日の稼働状況から代替候補を自動で抽出します。「承認制」「全自動」「手動」を管理者が選べるようにし、現場の判断を残したまま自動化しました。
FLOW
最初のご相談から納品後の改修まで、同じ担当が一貫して伴走します。
毎日・毎週やっている作業を書き出し、時間を測ります。ここで自動化の効果が数字で見えます。
「ルールで決まる部分」「AIに読ませる部分」「人が判断する部分」に分解します。ここが設計の中心です。
最も効果が大きく、最も安全なものを1つ選んで実装します。いきなり全部は作りません。
数週間、人が確認する前提で動かします。修正内容を記録し、精度を測ります。
精度が確認できた部分から自動実行に切り替えます。安全装置と停止手段を必ず用意します。
1つ定着したら次へ。この繰り返しが、確実にいちばん早い進め方です。
PRICE
自動化する作業の数と、つなぐシステムの数で変わります。
定期レポートの自動送信、書類の自動生成など、単一の作業を対象とした実装。既存システムへの後付けを含みます。
申請〜承認〜通知〜記録のように、複数ステップにまたがる流れの自動化。管理画面とログ機能を含みます。
文章の読解・分類・下書き生成を含む構成。下書き運用期間の伴走と、精度改善までを含みます。
※ AI利用料（従量）とサーバー費用が別途かかります。自動化前後の作業時間を測り、投資回収の見込みをお出しします。
FAQ
ここに載っていないことも、お問い合わせフォームからお気軽にどうぞ。
RPAの多くは画面操作を記録して再現する方式のため、画面の変更に弱く、壊れると直せる人がいない状態になりがちです。当社はデータベースやAPIを直接扱う実装を基本とするため、画面の変更に影響されず、動作も追跡できます。
その懸念は正しいです。だからこそ、まず下書きまでで止める運用から始めます。数週間分の修正率を見て、十分に精度が出ていることを確認してから自動送信に切り替えます。送信時間帯の制限と停止ボタンも標準で入れます。
不要です。既存システムのデータベース、API、あるいはCSVの受け渡しを使って、外側から自動化を足す形が基本です。
「毎回必ず同じ手順」「間違えても致命的でない」「頻度が高い」の3つを満たす作業です。定期レポートの作成・送信、書類の自動生成あたりが最初の候補になることが多いです。
記録します。何を根拠に、どういう分類をしたかを実行ログに残します。後から検証できない自動化は、業務では使えないと考えています。
停止ボタンを必ず用意します。設定で自動実行をオフにし、手作業に戻せる状態を維持したまま運用します。
RELATED
ひとつの案件で複数の領域にまたがる場合も、窓口はひとつのままご相談いただけます。
ENGINEERING
AIに任せるほど、「どこまで自動で進めて、どこで人が確認するか」の線引きが重要になります。
毎日やっている作業を1つ挙げていただければ、自動化できるかどうかその場でお答えします。
できない場合も、なぜできないかをご説明します。
お電話でのご相談：070-8445-2324（平日9:00〜18:00）