AI導入を検討する経営者・担当者の多くが、最初に考えるのは「何を導入するか」です。しかし私たちが業務の現場に入って最初にやることは、「何を手放すか」を特定することです。本書では、LITERAS AIが採用する 業務観察 メソッドを中心に、観察 → PoC → 受託 → サポートの4フェーズを具体的に解説します。補論では、バックオフィス職種別の「手放す業務リスト」を公開します。
序文：導入する前に、手放すものを決める
バックオフィスの現場を見ると、長年の慣習として続いているだけで、実は誰も必要だと思っていない業務が必ずあります。月に数十時間をかけて担当者が入力しているExcelが、実は誰も参照していない。毎月作成している帳票が、ほとんどが「念のため」で保管されているだけ。そういった業務は、AIで自動化する前に、そもそも「やめる」と決断すべきものです。
AIを入れても、不要な業務を効率化するだけでは本質は変わりません。
「手放す」を決めてから「自動化する」を設計する。この順番が、業務改善の成否を分けます。
本書の構成（4章 + 補論）
本書の章立ては、LITERAS AIが受託開発案件で実際に採用している進行フェーズと完全に対応しています。読者は自社の現状に最も近いフェーズから読み始めてください。
— 4 Phases of AI Implementation
業務観察
PoC
受託開発
初期サポート
| フェーズ | 本書の章 | 目的 | 期間（目安） | 費用感 |
|---|---|---|---|---|
| 業務観察 | 第1章 | 現在の業務を「AIが入った後の光」で見直す。手放す業務・変える業務・残す業務を特定する | 2〜3週間 | 40万円〜（参考価格） |
| PoC | 第2章 | 最小限の機能で本当に動くかを検証する。「やめる勇気」を持てる判断を設計する | 4〜8週間 | 個別見積 |
| 受託開発 | 第3章 | 本番実装。要件定義・スコープ管理・体制・セキュリティ設計をフルで行う | 6〜10週間 | 個別見積 |
| 初期サポート | 第4章 | 定着化・効果測定・現場での改善サイクル確立 | 契約後3〜6ヶ月 | 個別見積 |
| 補論 | — | バックオフィス職種別「手放す業務リスト」（LITERAS暫定版） | — | 無料公開 |
※ 各フェーズの費用は、業務内容・システム連携の複雑度により大きく異なります。まず業務観察から始め、観察結果をもとに次フェーズの詳細見積を提示します。
第1章 業務観察
今の仕事を、AI後の光で見直す。
他社は「ヒアリング」や「アセスメント」と呼ぶ。私たちは「観察」と呼ぶ。なぜなら、聞くだけでは業務の実態は見えないからです。
§1 「業務観察」とは何か
多くのAIコンサル・受託開発会社は、最初のフェーズを「アセスメント」「業務ヒアリング」「ビジョン策定」と呼びます。共通するのは、担当者にインタビューして課題を聞き取るアプローチです。LITERAS AIはこれを 業務観察 と呼び、まったく異なる進め方をします。
「ヒアリング」との決定的な違い
インタビューで聞き取れる情報は、担当者が「課題だと認識している」範囲に限られます。しかし実際に業務改善の種になる情報の多くは、担当者自身が「当たり前」だと感じていて、言語化されていない部分に潜んでいます。業務観察では、実際の業務フローを共に追います。具体的には次のことをします。
- 担当者が実際に操作しているExcelシートやシステム画面を見る
- 業務中に発生する「例外」の処理を記録する（例：データ形式が違う取引先の請求書が来たとき、何をするか）
- 「そういうもんだから」と言われる慣習的な作業を掘り起こす
- 入力データの実データを見せていただき、どこで揺れ・バラツキが生じているかを確認する
「観察」という言葉を選んだ理由
「観察」には、評価や判断を一時保留にして、まず現状を正確に捉えるという態度が含まれます。「このツールを使えばいい」「こう変えるべきだ」という結論を先に持ち込まず、まず業務の実態を照らし直す。それがLITERAS AIの出発点です。観察を終えた後、私たちが最初にお渡しするのは「提案書」ではなく 「手放す業務リスト（案）」 です。
§2 観察の現場で見るもの — 4つの観点
業務観察では、次の4つの観点で現場を記録します。いずれかが「複雑・不安定・個人依存」になっているほど、AIによる改善余地が大きくなります。
1. 業務フローの全体像
誰が・何のトリガーで・何をやり・次に何が起きるかを、実際の業務の流れに沿って図に起こします。「思っていたよりも多くの人が関与している」「一度も見直されていない承認ステップが残っている」といった発見が、ここで起きます。
観察で把握するフローの例：
- 請求書が届いてから会計ソフトに入力されるまでの全ステップ
- 採用候補者の情報がスプレッドシートに登録されてから内定通知が出るまで
- 契約書のドラフトが社内で回覧され署名が完了するまで
2. 入力データの実態
「どんなデータが入ってくるか」を実際に確認します。請求書なら、紙・PDF・エクセル・メール本文など複数の形式が混在していることが多い。このデータの「揺れ」がそのままAI化の難易度と直結します。フォーマットが標準化されているほど自動化は容易です。逆に言えば、「まずフォーマット統一が先」という判断もここから生まれます。
3. 例外処理の記録
定型の業務フローから外れる「例外」がどのくらい発生しているか、そのときに誰が・どう対処しているかを記録します。例外処理の多くは特定の担当者のみが対応でき、属人化の温床になっています。AIが例外をどう扱うかを設計するために、この観察は不可欠です。
4. 属人化点の特定
「この業務は〇〇さんしかわからない」という箇所を可視化します。属人化した業務はAI化の最優先候補であると同時に、担当者の協力なしにAI化できないため、移行計画の設計が特に重要になります。
§3 業務観察パッケージ — 内容・期間・参考価格
パッケージに含まれるもの
| 項目 | 詳細 |
|---|---|
| 業務フロー図（現状・as-is） | 対象部門の業務を図化。最大3部門（経理・人事・総務）まで対応 |
| 入力データ確認レポート | データ形式・揺れ・バラツキの現状記録 |
| 例外処理ログ | 定型フロー外の処理パターンと頻度を整理 |
| 属人化マップ | 「この人しかわからない業務」を職種・工程別に可視化 |
| 手放す業務リスト（案） | 観察結果にもとづく「やめる・変える・残す」の分類案 |
| AI活用ポイント特定レポート | 自動化・AI化が効果的な箇所と、その実現難易度の評価 |
| 次フェーズ（PoC）への提言 | PoCで検証すべき仮説とスコープの提案 |
期間と費用の目安
- 期間：2〜3週間（現地またはリモートでのセッションを複数回実施）
- 参考価格：40万円〜（業務範囲・部門数・システム複雑度により変動）
- 補助金活用：業務観察単体での補助金適用は難しいケースが多いですが、後続のPoC・受託開発と合算した場合、IT導入補助金・ものづくり補助金の対象となる場合があります。詳細は無料相談でご確認ください。
「まず観察だけ」で構いません。PoC・受託・サポートへの進行は、観察結果をご覧いただいた上でご判断ください。観察の結果、「今は時期尚早」「自社内で対応できる」となった場合でも、手放す業務リストと業務フロー図は貴社の資産として残ります。
第2章 PoC（概念実証）
動くか、動かないかを、小さく確かめる。
PoCの本当の目的は、「成功の確認」ではありません。「やめる判断」を安全にできることです。
§1 PoC設計 — 「やめる勇気」を持てる検証
業務観察で「この業務はAI化できる」と特定したら、次はPoC（Proof of Concept：概念実証）に移ります。PoCの目的は「本当に動くか」を最小コストで検証することですが、LITERAS AIがPoCで特に重視するのは「やめる判断をきちんとできるか」です。
PoCで検証すること
1. 技術的実現性
想定していたAI処理が、実際のデータで動くか。OCR精度は許容範囲か、LLMによる判定はどの程度の精度が出るか、既存システムとのデータ連携は技術的に可能か。
2. 業務フィット
AIが出力した結果を、現場担当者が使えるか。「精度は出ているが、担当者が結果を信頼できない」という失敗パターンが特に多い。PoCでは担当者に実際に使ってもらい、心理的な受け入れも確認します。
3. 例外の許容範囲
業務観察で記録した例外処理のうち、どのくらいをAIが対応でき、どのくらいが人間の判断を要するか。例外の比率が高すぎる場合、本開発に進む意味が薄れます。
PoCで「やめる」判断をするとき
PoCの結果が思わしくない場合、私たちは明確に「この方向では本開発に進むべきではない」と報告します。大きな予算を使う前にやめることができる。それがPoCの最大の価値です。「やめる」判断が出やすいのは、次のようなケースです。
- 入力データの品質が想定より悪く、AI化の前提が崩れる
- AI精度は出るが、担当者の業務フローへの組み込みが難しい
- 既存システムのAPI連携が技術的・契約的に不可能と判明する
やめた場合でも、PoC費用は「失敗コスト」ではなく「数千万円規模の誤った本開発を避けるための保険」として位置づけてください。
§2 PoCの判断基準・期間・費用感
PoC成功の判断基準（業務観察フェーズで事前に定義）
PoCに入る前に、以下の3つの指標を業務観察レポートの中で合意します。数字の目標は業務ごとに異なるため、ここでは枠組みのみ示します。
| 判断軸 | 確認項目 | 判断方法 |
|---|---|---|
| AI精度 | 処理結果の正解率・エラー率 | 実際のデータ〇件を処理して測定 |
| 業務フィット | 担当者が「使える」と判定したか | 現場担当者へのフィードバックセッション |
| 例外処理率 | AIが処理できない例外の割合 | 例外発生率〇%以下を合格基準として設定 |
すべての基準を事前に文書化し、「合格・不合格」を感覚ではなく数字で判断できるよう設計します。
期間・費用感
- 期間：4〜8週間
- 費用：個別見積（業務規模・システム連携の複雑度・PoC対象の業務数による）
- 次アクション：まず業務観察から始めていただき、観察完了後に具体的なPoC費用を提示します。
第3章 受託開発
検証済みの仮説を、本番の業務システムに実装する。
PoCで「動く」が証明されて初めて、本開発の話ができます。
§1 要件定義の論点とスコープ管理
「何を作るか」の前に「何を作らないか」を決める。PoC成功後、本開発の要件定義に移ります。要件定義で最も重要なのは「スコープ」の確定です。スコープとは「何を開発するか・何は開発しないか」の明確な境界線です。この境界が曖昧なまま開発に入ると、途中でどんどん機能が追加され（スコープクリープ）、納期とコストが膨らむ典型的な失敗パターンに陥ります。
要件定義の4つの論点
1. 機能スコープ
「この機能はPoC済み・本開発に含める」「この機能は将来対応」「この機能はスコープ外」を三段階で整理します。PoCで検証していない機能を本開発に盛り込む場合、追加リスクが生じることを合意した上で進みます。
2. 既存システム連携の範囲
会計ソフト・勤怠管理・CRMなど既存システムとのAPI連携は、LITERAS AIが対応するか・顧客側IT担当者が対応するかの分担を明確にします。APIが存在しない場合の代替手段（データエクスポート・手動連携）も設計に含めます。
3. セキュリティ要件
取り扱うデータの機密レベルに応じて、データの保管場所（顧客VPC内 or クラウド）・アクセス権限・監査ログの範囲を確定します。個人情報・給与情報・決算情報を扱う場合は、より厳格な設計が必要です。
4. 運用引き渡しの設計
本開発完了後、誰がシステムを運用するかを先に決めます。担当者が変わっても運用できるよう、ドキュメント化と社内トレーニングの実施を本開発のスコープに含めます。
スコープ管理のルール
本開発期間中に「あれも追加してほしい」という要望が発生することがあります。追加要件はスコープ外として記録し、次フェーズ（追加開発・保守契約での対応）に回すことを基本とします。緊急度が高い場合は個別に費用・スケジュールを協議します。
§2 開発フェーズの体制・期間・費用感
本開発の体制
LITERAS AIの受託開発は、代表・澁江周真が業務観察から保守まで一貫して担当します。「営業が受注して別のエンジニアが実装する」という分離はしません。業務を理解した人間が実装まで担う体制が、バックオフィス特化の受託開発では特に重要です。
| 担当領域 | 内容 |
|---|---|
| 要件定義・設計 | 業務観察・PoCの知見を踏まえた詳細設計 |
| AI実装 | Azure OpenAI（Private Endpoint）またはAWS Bedrock構成。データは顧客VPC内に閉じた設計 |
| 既存システム連携 | 会計ソフト・勤怠管理・CRM等とのAPI連携 |
| セキュリティ設計 | VPC設定・監査ログ・アクセス制御 |
| テスト・品質保証 | 機能テスト・セキュリティ検証・ユーザー受入テスト |
| 運用ドキュメント | セットアップ・トラブルシューティング・運用マニュアルの作成 |
期間・費用感
- 期間：6〜10週間（機能規模・連携システム数による）
- 費用：個別見積（PoC完了後に確定見積を提示）
- 補助金活用：本開発はIT導入補助金・ものづくり補助金の対象となる可能性が高い。中小企業（資本金・従業員規模の要件を満たす法人）が対象。補助率は最大3/4。申請支援はLITERAS AIで対応します。
第4章 初期サポート
本番稼働後が、本当のスタートです。
システムを「使えるようにする」のは受託開発の仕事。「使い続ける文化を作る」のが初期サポートの仕事です。
§1 定着化のフレーム — なぜ本番稼働後に「使われない」が起きるか
バックオフィスへのAI導入で最も多い失敗パターンが 「システムは動いているのに、担当者が使わない」 です。原因は技術の問題ではありません。担当者が「AIの判断を信頼できない」「エラーが起きたときの対処法がわからない」「元のやり方の方が安心」と感じているからです。これを放置すると、システムは形だけ存在して、実態は以前の手作業が続くという最悪の結果になります。
LITERAS AIの定着化3ステップ
ステップ1：初期トレーニング（本番稼働前）
本番稼働前に、実際の業務担当者向けトレーニングを実施します。操作方法の説明だけでなく、「AIが苦手なパターン」「エラーが出たときの見分け方」「どの判断をAIに任せて、どの判断は人間がするか」の境界線を共有します。
ステップ2：並走期間（本番稼働後1〜4週間）
本番稼働直後は、旧来の手作業とAI処理を並行して走らせます。AIの結果が正しいか、担当者自身が確認する期間を設けます。この期間に「AIがここまではやってくれる」という信頼が生まれます。
ステップ3：自走移行（並走期間終了後）
担当者が「これはAIに任せられる」「ここは自分が判断する」という感覚を持って自走できる状態に移行します。以降は月次の保守契約（任意）でLITERAS AIがサポートを継続します。
担当者変更・引き継ぎへの備え
担当者が変わってもシステムが続けて使えるよう、以下を本開発スコープ内で作成します。
- 業務別操作マニュアル（スクリーンショット付き）
- よくあるエラーと対処法のQ&A
- 業務ルール変更時のシステム修正依頼手順
§2 効果測定 — 件数・時間・工数 3軸の数字
「業務が楽になった」という感覚ではなく、数字で効果を確認します。LITERAS AIが採用する効果測定の3軸を説明します。
軸1：件数（処理量の変化）
AI導入前後で、担当者1人あたりの月間処理件数がどう変わったかを測定します。
- 例：請求書処理件数が月150件 → AI補助後に同じ時間で月220件に増加（処理量47%向上）
- 例：契約書のリスク確認件数が月20件 → AI確認後に同じ時間で月50件に増加
軸2：時間（業務時間の削減）
同じ量の処理に要する時間が何時間削減されたかを測定します。
- 測定方法：AI導入前の業務記録（2〜4週間の実績）と、導入後の業務記録を比較
- 例：仕訳入力に月120時間かかっていたものが月20時間に削減（削減率83%）
- 人件費換算（前提：担当者の時給2,000円）：削減100時間 × 2,000円 = 月20万円分の工数回収
軸3：工数（人員と難易度の変化）
特定の業務を担当できる人が「1人」から「複数人」に広がったか、あるいは担当者のスキルレベルを問わなくなったかを確認します。
- 例：仕訳チェックが「経験5年以上の経理担当者のみ」から「入社1年目でもAI補助があれば可能」に変化
- 属人化の解消が定量化できる指標
測定スケジュール（標準）
| タイミング | 測定内容 |
|---|---|
| 本番稼働前（ベースライン） | 直近2〜4週間の業務記録を集計。処理件数・所要時間・担当者数を記録 |
| 本番稼働1ヶ月後 | 同様の指標を再測定。AI処理の介入率・エラー率も計測 |
| 本番稼働3ヶ月後 | 定着状況の確認。担当者アンケート（信頼度・使いやすさ）も実施 |
| 本番稼働6ヶ月後 | 最終的な効果確定。必要に応じてPoC・本開発の追加領域を提案 |
補論：手放す業務リスト（バックオフィス職種別）
これはLITERAS AIが業務観察を通じて発見してきた 手放す業務 の暫定リストです。ただし、要・不要の判断は必ず業務観察（実態確認）の上で行ってください。同じ業務名でも、会社の規模・業種・システム環境によって「まだ人が必要」なケースがあります。
このリストを読み、自社で該当しそうな項目に印をつけてください。印のついた項目が多い部門ほど、業務観察の優先順位が高くなります。
経理（出納・仕訳・帳票作成）
- 紙・PDFの請求書を手入力で会計ソフトに転記する作業（OCRとAI仕訳で90%以上自動化可能）
- 月次の仕訳チェック作業のうち、定型パターン分（ルール化可能な仕訳の自動化で削減）
- 月次レポート・決算書の数字をExcelに手で転記してから整形する作業（会計ソフトとの自動連携で不要化）
- 入金確認のための通帳データ目視チェック（銀行API連携・自動マッチングで削減）
- 督促メールの手動送信（入金期日と入金状況の自動監視 + メール自動送信で置き換え可能）
- 「念のため」で毎月作成しているが誰も参照していない定型帳票の出力（対象帳票の棚卸しで廃止）
人事・労務（勤怠・給与・採用）
- 勤務表の集計作業（スプレッドシートの手作業集計。勤怠管理システムとのAPI連携で自動化）
- 勤務表データを給与計算ソフトに手動で入力するコピー作業（システム連携で不要化）
- 面接候補者とのスケジュール調整メールのやり取り（スケジュール調整ツールの活用で削減）
- 採用書類の初期スクリーニング（応募者の基本要件確認はAI補助で時間を短縮）
- 手当（通勤・家族・住宅）の変更申請時の転記作業（人事システム → 給与計算システムへの手動連携）
- 入退社時の各種システム登録作業のうち、定型フォーマット分（マスタデータからの自動展開で削減）
- 毎月の給与明細の個別印刷・封入作業（電子給与明細化で廃止）
総務（契約・経費・文書・庶務）
- 契約書の更新期限を手動カレンダーや付箋で管理する作業（契約管理システム + 自動リマインドで置き換え）
- 経費精算のレシート目視確認と金額転記（経費精算システムのOCR機能で削減。既に多くのツールが対応）
- 全社会議の議事録を会議後に聞き直しながら文字起こしする作業（AI議事録ツールで置き換え可能。すでに採用企業多数）
- 社内問い合わせ（規程確認・手続き方法）への個別メール対応（社内FAQのAI化で担当者の対応時間を削減）
- 備品発注のための在庫確認・発注書作成・承認ルーティング（ルール化が明確な場合、自動化の余地大）
- 複数部署からのデータを手集計して経営会議資料のスライドを作成する作業（BI連携 + 自動グラフ生成で削減）
法務・契約
- 毎回ゼロから作成している定型的な契約書（NDA、業務委託など）のドラフト作成（テンプレートAI生成 + リーガルチェックの分業で削減）
- 受領した契約書の条文確認のうち、標準的な条項（支払条件・納期・免責条項）のリスクチェック（AI補助による一次確認で法務担当者の工数を削減）
- 契約書の保管場所がバラバラで毎回検索に時間がかかる状況（契約管理システムへの一元化で解消）
- 社内規程集の更新が遅れており、担当者が最新版を把握するのに時間がかかる（ドキュメント管理の整備 + AI検索で削減）
経営管理・役員補佐
- 各部門からデータを収集してExcelで集計する月次経営レポートの作成（数値は各システムから自動取得。経営者の判断に必要な分析に時間を充てる）
- 定型の議事録・報告書のフォーマット整形作業（AI補助で初稿生成。担当者は確認・加筆に集中）
- 「同じことを複数の場所に転記している」情報管理（一元化とAPI連携で転記そのものを廃止）
ケーススタディ：LITERAS AI自身のクライアントゼロ事例
私たち自身が最初のクライアントです。LITERAS AIは「外部クライアントに提案する前に、自社で実証する」という方針を取っています。創業後ただちに、自社のバックオフィス業務3領域にAIを導入し、その結果を公開します。
— Case 01
経理処理の自動化（請求書・仕訳）
対象業務：受領請求書の処理（PDF・紙・メール形式が混在）→ 会計ソフトへの入力
導入前の状況
- 月間処理件数：約40件（取引先・外注先からの請求書）
- 処理時間：月8〜10時間（受領 → 金額確認 → 会計ソフト入力 → 仕訳）
- 問題点：形式が5パターン混在。PDFは手入力、紙はスキャン後手入力
実施したこと
- 業務フロー図の作成と「手放す工程」の特定（確認フローが二重になっていた工程を統合）
- 受領請求書のOCR処理 + AI仕訳提案の実装（ルールベース + LLM補助）
- 会計ソフトへの自動転記とレビュー承認フローの設計
結果（本番稼働3ヶ月後の計測）
- 処理時間：月8〜10時間 → 月2時間以下（削減率75〜80%）
- 処理件数：同じ2時間でPoCから本番移行後は月60件対応可能に（処理能力50%向上）
- エラー率：手入力時の金額誤入は月平均1.2件あったが、導入後0件（6ヶ月継続）
— Case 02
人事業務の効率化（採用・勤怠）
対象業務：採用候補者の情報管理 + 面接スケジュール調整
導入前の状況
- 年間採用数：5〜8名（外注・パートナー含む）
- 処理時間：候補者1名あたり平均4〜6時間（書類確認・日程調整メール往復・情報整理）
- 問題点：メール返信・スプレッドシートへの転記が手作業。情報が複数ツールに散在
実施したこと
- 採用プロセスの棚卸し（5工程のうち2工程が「念のため確認」で廃止可能と判断）
- スケジュール調整の自動化（カレンダーツール連携 + 候補者への自動案内送信）
- 候補者情報の一元管理（スプレッドシート分散 → 統合管理ツールに集約）
結果
- 1名採用あたりの事務工数：4〜6時間 → 1〜1.5時間に削減（削減率70〜75%）
- 情報散在によるミス（日程送付ミス・連絡漏れ）：導入前 月平均0.8件 → 導入後0件
- 担当者の所感：「面接候補者への対応に集中できるようになった。事務的なやり取りに時間を取られていたことに気づいた」
— Case 03
契約書チェックの効率化
対象業務：受領した業務委託契約書・NDAの初期リスク確認
導入前の状況
- 月間確認件数：5〜10件（外注・パートナー契約が増加傾向）
- 処理時間：1件あたり30〜60分（条文の読み込み・リスク箇所のメモ）
- 問題点：法律の専門家でなく、確認漏れへの不安が常にあった
実施したこと
- 確認すべきリスク条項のリスト化（支払条件・成果物帰属・損害賠償・解除条件の4カテゴリ）
- AI補助による条文の一次確認（LLMでリスク箇所を抽出・コメント付き要約を生成）
- 代表による最終確認フローを設計（AIの一次確認 → 代表が重要箇所のみ精読）
結果
- 1件あたりの確認時間：30〜60分 → 10〜15分（削減率70%）
- 確認品質：AIが一次チェックをすることで確認漏れへの不安が減少。重要条項への集中度が向上
- 月間対応可能件数：同じ時間で約3倍の件数を対応できるように
3事例を通じた気づき
AIを導入して最初に感じたことは「効率化した」ではなく、「本来やるべきことに時間を使えるようになった」でした。請求書の転記、スケジュール調整のメール往復、契約書の通読。これらはすべて「やらなければならない」作業でしたが、「自分でなければできない」作業ではありませんでした。AIがその部分を担うことで、判断・関係構築・創造的な仕事に時間が向かいます。これが私たちが 業務観察 から始める理由です。
よくある質問
Q1. まだAIを導入したことがない会社でも相談できますか？
はい。LITERAS AIのクライアントの多くは「AIを使ったことがない・何から始めればいいかわからない」という状態からご相談いただいています。まず業務観察から始め、「どこでAIが効くか」を一緒に見つけるところからスタートします。
Q2. システム開発の専門知識がない担当者でも対応できますか？
はい。業務観察・PoC・本開発を通じて、技術的な内容をわかりやすく説明しながら進めます。「どんな仕様にするか」の決定は業務を知っている皆様に、「どう実装するか」の部分はLITERAS AIが担当します。
Q3. 補助金の申請は自分たちでやらなければなりませんか？
見積書の作成・申請に必要な書類の整備についてはLITERAS AIがサポートします。申請手続き自体は事業者様が行いますが、申請の手順・スケジュール・必要書類についての説明と準備支援を行います。
Q4. 最初から全部をAI化しようとしなくて大丈夫ですか？
むしろ、最初から全部を変えようとしないことを推奨しています。業務観察で特定した「最も効果が高く・リスクが低い」1つの業務からPoC → 本開発を進める段階アプローチが標準です。1つで成果が出れば、次の業務への展開がスムーズになります。
Q5. 既存のシステム（会計ソフト・勤怠管理など）はそのまま使えますか？
原則として既存システムを変更しない方向で設計します。APIで連携できるシステムが多く、既存ツールとAIの間をつなぐ形で実装します。既存システムのリプレースが必要なケースは少ないですが、APIが存在しない場合は代替手段を業務観察の段階で確認します。
Q6. 開発後にシステムが使えなくなった場合のサポートは？
本開発納品後から月次の保守契約（任意）を提供しています。バグ対応・プロンプト調整・AI精度の再最適化・新しい業務への拡張対応を継続的にサポートします。
まず「自社の手放す業務リスト」を一緒に作りましょう
本書の補論「手放す業務リスト」を読んで、自社に当てはまりそうな項目が見つかりましたか？LITERAS AIでは、この資料のご感想と「自社で気になった業務」をお伝えいただくだけで、「自社版・手放す業務リスト」の無料診断（30分・オンライン）を実施しています。業務観察の本格実施前に、まず「どの業務が候補になるか」の仮説を一緒に整理します。費用はかかりません。
無料診断の内容
- 所要時間：30分（オンライン）
- 費用：無料
- 進め方：
- 貴社のバックオフィス業務で「時間がかかっている・煩雑だと感じている」業務を3〜5つ教えてください
- 本書の補論リストを参考に、あてはまる項目を共有してください
- LITERAS AIが「手放せる業務・AIが向いている業務・今は変えない方がいい業務」の3分類で初期診断をお伝えします
- 診断後の選択肢：業務観察（有料）に進む／一度持ち帰って社内で検討する／今は見送る（無理な営業はしません）
お申し込み・お問い合わせ
メール：info@literas-ai.jp（24時間受付・3営業日以内に返信）
公式サイト：https://literas-ai.jp
件名の記載例：「手放す業務リスト診断を希望します」