この記事で分かること
- AIシステム開発の初期検討で行うべき7つの手順
- 社内説明に使える課題・効果・リスクの整理方法
- データと既存システムを確認し、AIの適用範囲を見極める観点
- PoCから本番へ進むかを判断するための準備
最初に押さえるべきことは「AIを導入する」ではなく「仕事を変える」こと
AI導入は、それだけで成果になる施策ではありません。文書を探す、問い合わせに答える、帳票から情報を転記する、データを集計して報告するなど、現在の仕事のどこを変えるかが決まって初めて、必要な技術や費用を検討できます。目的が「最新のAIを試す」だけだと、デモの評価で止まりやすく、本番の利用者や運用責任者が後から問題になります。
対象業務を選ぶときは、発生頻度、担当者の作業時間、入力の定型性、失敗した場合の影響、改善後に測れる指標を並べます。頻繁に発生し、資料やデータが一定の形式で存在し、最終判断を人が確認できる業務は、最初の検証対象に向いています。逆に、正解が明確で通常のシステム改修だけで解決できる作業に、無理に生成AIを足す必要はありません。
現行のExcel、Access、業務システム、紙の資料がどの工程に関わるかを図にすると、AIの前に直すべき問題が見えてきます。既存環境の状態を確かめたい場合は、開発前診断・ロードマップのように、修正・連携・刷新を比較する視点を持つことが有効です。
AIシステム開発の最初の7ステップ
ステップ1：困っている業務を一つ選ぶ
候補をいきなり機能名で並べず、業務の名前で書きます。「生成AIチャットボット」ではなく「総務への社内規程の問い合わせに回答する」、「AI分析」ではなく「週次の売上CSVから変化点をまとめる」と表現します。業務名、利用者、発生頻度、今の手順、困っている点を一枚にまとめ、関係者が同じ対象を見られるようにします。
候補が複数ある場合は、期待効果の大きさだけで決めません。データがすぐ使えるか、誤りを人が確認できるか、既存業務への影響が限定されるかも評価します。高リスクの判断をいきなり自動化するより、回答案の作成や検索の補助から始める方が、検証の結果を次の施策へ生かしやすくなります。
ステップ2：現状の流れと時間を記録する
改善前の状態が分からなければ、導入後に良くなったか判断できません。入力を受けるところから、検索、転記、確認、承認、保存、通知までを時系列に並べます。担当者が迷う箇所、差し戻しが多い箇所、手作業で二重入力している箇所には印を付けます。
測定する時間は、AIの回答生成時間だけではありません。入力の準備、結果の確認、誤りの修正、別システムへの転記を含めた一件あたりの総時間を測ります。件数、繁忙期、担当者による差も合わせて記録すると、AI導入で本当に削減できる負担を試算しやすくなります。
ステップ3：期待する成果と対象外を決める
「業務を効率化する」を、確認できる成果へ変換します。作業時間を短くする、回答の初稿を早く作る、検索漏れを減らす、報告書の形式をそろえるなど、AIが直接支援する変化を決めます。売上や顧客満足のような遠い成果は、AI以外の要因もあるため、直接指標と分けて管理します。
対象外も同じくらい大切です。回答案の作成までは行うが送信はしない、参考情報を提示するが最終判断は担当者が行う、今回は特定部署の文書だけを対象にする、と決めます。対象外が明確なら、画面、権限、テストケース、見積もりの範囲を絞れます。
ステップ4：使えるデータと制約を棚卸しする
データの保存場所、形式、件数の規模、更新頻度、管理者、正しさの懸念、閲覧権限を一覧にします。社内文書なら、最新版の判定方法と廃止文書の扱いも確認します。表計算なら、一行の単位、項目の定義、空欄の意味、コード表、履歴の有無を確かめます。
実データを使えない場合は、入力と出力の見本、匿名化した構造、想定件数、例外の種類を用意します。ただし、架空データで動いたことは実データでの精度を示しません。いつ、どの範囲を、どの方法で実データ検証へ移すかを計画に含めます。
データの整理方法については、AIシステム開発に必要なデータの整備・評価も参照できます。AIへ渡す前のデータ品質と、導入後に更新し続ける仕組みを別々の作業として考えることがポイントです。
ステップ5：AI以外の方法と比較する
業務フローの整理、Excelの修正、既存システムの機能追加、SaaS、RPA、通常のWeb開発で解決できるかを並べます。定型的な計算や決まった条件の検索は、ルールベースの方が結果を説明しやすい場合があります。文章の要約や曖昧な問い合わせの整理などは、生成AIが候補になります。
比較表には、初期費用、運用負担、変更のしやすさ、失敗時の影響、担当者の確認量、データの扱いを入れます。AIを採用しない結論も、検討が失敗したのではなく、目的に合った方法を選べた結果です。AI受託開発・生成AIシステム開発の相談でも、AIありきではない選択肢を含めて整理できます。
ステップ6：小さなPoCと評価条件を設計する
PoCは、完成版を安く作る工程ではなく、本番に進む価値と制約を確かめる工程です。対象データ、利用者、実施期間、試すシナリオ、測定指標、合格・中止条件を事前に書きます。デモで都合のよい質問だけを選ばず、通常例、例外、入力不足、答えがない質問も含めます。
精度だけでなく、確認時間、1件あたりの利用コスト、回答の根拠、操作の分かりやすさ、データ更新の手間を測ります。PoCで見つかった問題を、モデルの問題、データの問題、画面や手順の問題、運用責任の問題に分類すると、本番化の改善案を作れます。
費用や期間の目安を検討するときは、公開されている範囲であっても対象業務とデータの条件をそろえて比較します。マクティズムのサービスページでは、AI Quick PoCを120万〜250万円程度・1〜2か月程度の目安として案内していますが、案件の範囲で変わるため、同じ条件で相談することが必要です。
ステップ7：本番後の運用と判断者を決める
本番化の前に、文書やデータの更新担当、利用者の追加、権限の申請、誤回答の報告先、障害時の連絡、モデルやAPIの変更確認を決めます。AIは導入して終わりではなく、業務や資料が変わるたびに出力の状態を確認する仕組みが必要です。
成果を継続的に見る担当者を決め、月次や四半期などの確認周期を設定します。利用回数が少ない、確認時間が減らない、特定の部署で誤りが続くといった兆候を、停止や改善の判断につなげます。使われない原因が機能不足とは限らず、入口の手順や承認ルールにある場合もあります。
7ステップを進める途中で、すべての情報が一度にそろわなくても構いません。大切なのは、仮置きした前提と未確認の項目を分けることです。たとえば、データ件数は概算、利用者は候補、精度目標は業務責任者の確認待ちと記録します。未確認を隠して開発へ進むより、次に誰が何を調べるかを決めた方が、相談先から具体的な提案を受けられます。
7ステップを始める前に作る「一枚の整理シート」
初回の打ち合わせには、対象業務、利用者、開始条件、入力、現在の手順、困っている点、期待する出力、確認者、データの保存場所を記載します。右側に、改善後に減らしたい作業、測定する指標、対象外、気になるリスクを書きます。情報を一枚へ収めることで、技術の話が先行して業務目的が抜けることを防げます。
業務を説明する際は、代表的な一件と、うまくいかない一件を用意します。正常な問い合わせだけでは、資料が見つからない質問や、複数の部署に関係する質問の扱いを検討できません。入力不足、表記揺れ、古い情報、権限の違いなど、現場で実際に起きる例を含めると、PoCの評価条件を早く作れます。
整理シートの最後に、次回までの宿題と判断者を記載します。データの所有者を確認する、利用規約を調べる、現状時間を測る、現場代表を決めるなど、担当と期限のある作業へ分解します。検討会議のたびにシートを更新し、決定事項と保留事項を分けておけば、担当者が変わっても議論を再開できます。
社内合意を得るための資料は、4枚に分けると説明しやすい
AI開発の社内説明では、技術資料だけを配っても意思決定が進みません。業務責任者向けには目的と効果、情報管理向けにはデータと権限、現場向けには操作と確認、決裁者向けには費用・期間・中止条件を示します。一つの長い資料にすべてを詰め込むより、同じ前提から役割ごとの判断材料を分ける方が理解されやすくなります。
| 資料 | 記載する内容 | 主な確認者 |
|---|---|---|
| 業務整理 | 現状、課題、対象範囲、改善後の流れ | 業務責任者・現場 |
| データ整理 | 保存場所、正本、更新、権限、品質の懸念 | 業務責任者・情報システム |
| 検証計画 | シナリオ、評価指標、合格・中止条件 | 業務責任者・決裁者 |
| 運用案 | 利用者、確認者、障害対応、改善周期 | 運用担当・情報管理 |
社内合意でよく起こるのは、「便利そうだから使いたい」と「情報漏えいが怖い」という意見が並び、具体的な判断に進まない状態です。懸念を消すのではなく、扱うデータ、利用者、保存場所、ログ、承認手順に分解し、検証で確かめる事項と運用で管理する事項を分けます。
開発会社へ相談するときに最初に渡す情報
相談の段階で完璧な仕様書は必要ありません。業務の流れ、困っている箇所、入力と出力の見本、データの場所、現在の担当者、期待する効果、避けたいリスクが分かるだけでも、会話の出発点になります。重要なのは、未確定の内容を決定事項のように書かないことです。
質問事項も準備します。実データを扱う場所、モデル変更の方法、ログの保存、追加費用が発生する条件、保守の窓口、PoC後の本番移行方法、成果物の引渡し範囲などです。開発会社の説明を比較するときは、機能の多さだけでなく、制約と前提を具体的に説明しているかを見ます。
既存記事のAI開発会社へ依頼する前に確認したい契約上のリスクも、相談先を比較する際の確認材料になります。初回の会話で「何を作るか」だけでなく、「作らないこと」「発注側が準備すること」「導入後に誰が持つか」を聞いておくと、後の見積もりが読みやすくなります。
よくある質問
AIに詳しい社員がいません。社内だけで最初の検討はできますか？
できます。まず業務の流れ、入力・出力、困っている時間、例外、関係者を整理します。AIの方式やモデルは、業務の条件が見えてから開発会社や専門家と比較すれば構いません。業務担当者の知識は、技術知識とは別に重要な材料です。
いきなり開発会社へ相談してもよいですか？
相談して構いません。ただし、対象業務と困りごとを一枚にまとめておくと、提案の比較がしやすくなります。情報が不足している場合は、要件整理や開発前診断を先に依頼し、調査後に本開発の範囲を決める方法もあります。
PoCは必ず実施した方がよいですか？
必ずではありません。既存システムへの小さな機能追加など、要件とデータが明確で、通常のテストで確認できる場合もあります。一方、精度やデータ品質に不確実性がある場合は、限定したPoCで仮説を確かめる方が、本番開発のリスクを下げられます。
7ステップはどのくらいの期間で行いますか？
業務の複雑さ、関係者、データの準備状況で変わります。短期間で結論を急ぐより、各段階で次へ進む条件を決めることが重要です。データの所在や責任者が分からない場合は、初期の棚卸しに時間をかける方が、後の手戻りを抑えられます。
最初の一歩は、業務候補を一つ選んで一枚に書くこと
AIシステム開発の始め方に迷ったら、AIツールを比較する前に、対象業務の名前、利用者、入力、出力、今の時間、困っている点、改善後に測る指標を書き出します。次に、使えるデータと対象外を確認し、小さな検証と本番運用の責任者を仮置きします。
この一枚があれば、社内合意、開発会社との相談、費用・期間の比較を同じ前提で進められます。情報が足りないこと自体が問題なのではありません。何が未確認で、誰がいつ確認するかを見えるようにすることが、AI導入を前へ進める担当者の最初の成果です。
