「AIでつくる」と
「AIを組み込む」の違い。

AIを使うのは、
「つくるとき」か「使うときも」か。

たとえば「売上を毎週まとめたい」なら、集計だけで十分な場合があります。「売上データと顧客の声を読んで、改善案の下書きまで欲しい」なら、その部分へのAI活用を検討できます。

それぞれの強みと、
引き受ける手間。

A：ルールで動かすツール

強みは、処理の根拠を確認しやすいことです。単価や計算式を示せるので、期待した結果になるかを具体的にテストできます。同じ入力・ルール・参照データで結果を再現しやすく、決まった処理を繰り返す業務に向いています。

弱点は、ルールにできていないケースへの対応です。取引先ごとに書式が違う、文章から意図をくみ取る必要がある、例外が多いといった場合には、入力の統一、例外処理の追加、人による確認などが必要です。業務ルールの変更に合わせた改修も続きます。

B：利用時にもAIが働くツール

強みは、表現や書式の違いを扱いやすくなることです。メールの言い回しが違っても必要な項目を拾う、長い文章を要約する、回答の候補を作る、といった支援を期待できます。ただし、どこまで対応できるかは実際の資料で確かめます。

弱点は、もっともらしい誤りや、結果のばらつきがあることです。項目を取り違えたり、資料にない説明を補ったりする可能性があります。NISTも、生成AIが誤った内容を確信的に提示する現象をリスクとして整理しています。参考：NIST Generative AI Profile、2.2節 ↗

そのため、根拠の表示、分からない場合に止める処理、人に引き継ぐ仕組みを設計します。導入後も、読み取りの誤りや確認の負担を見て、改善を続ける運用が必要です。

表は横にスクロールできます。

「AIで開発した」だけでは、品質や低価格は保証されません。どちらも要件の確認、テスト、修正が必要です。GitHubも、AIが生成したコードのレビューとテストを求めています。参考：GitHub Copilot Agents の責任ある利用 ↗

同じ「注文処理を楽にしたい」でも、
必要な仕組みは変わります。

営業事務の注文処理を例に考えます。以下は、作り方を説明するための業務例です。

AIが候補を作ることと、発注・送信・承認まで任せることは、別の設計判断です。最初は下書きまでにとどめるなど、業務への影響に合わせて任せる範囲を決められます。

注文書の照合・確認サンプルを見る ↗公開サンプルは架空データと固定の読み取り例です。実際のAI読取は行いません。

欲しいツールを決める前に、
今の仕事を一緒に整理する。

最初からA・Bを選ぶ必要はありません。次の質問で、どの作業を減らしたいのかを具体化できます。相談の場では、答えられるところからお聞かせください。

1. 何が変われば、導入してよかったと思えますか？

   「入力時間を減らす」「確認漏れを減らす」「提案まで進める」など、欲しい成果を伺います。現在の件数・時間も、比較の出発点になります。

2. 何を受け取り、何を作っていますか？

   入力資料と完成例を見比べます。典型的な例に加え、普段困る例外もあると、ルールで処理できる部分と、読み取りが必要な部分を分けやすくなります。

3. 「正しい」と判断する基準はありますか？

   単価表・計算式・社内規程なのか、文章の分かりやすさや担当者の判断なのかを確認します。基準がまだ曖昧な場合は、試作の前に整理します。

4. 間違えたとき、何が起きますか？ 誰が確認できますか？

   下書きの修正で済むのか、請求や発注に影響するのか。確認できる人と時間も伺い、止める条件や、人に戻す範囲を決めます。

5. 使えるデータと、守るべき制約は何ですか？

   資料を試作に使えるか、外部サービスへ送れるか、既存のシステムとどうつなぐかを確認します。機密資料は、共有できる範囲を決めてから扱います。

6. どのくらい使い、費用や待ち時間をどこまで許容できますか？

   月の件数、集中する時間帯、必要な応答速度を伺います。AI利用料だけでなく、確認・修正にかかる人の時間を含めて比較します。

7. 誰が、いつ試し、何を見て続けるか判断しますか？

   試作品を評価する担当者と時間を先に確保します。動くものができても評価できない、という状態を避け、次の開発へ進む条件を決めます。

【業務ツールの相談メモ】
1. 改善したい業務・得たい成果：
   現在の件数・作業時間：
2. 入力資料／完成させたいもの／困る例外：
3. 正しさを判断する基準・参照資料：
4. 誤りの影響／確認する人と使える時間：
5. 使用できるデータ・共有範囲・接続先：
6. 月の処理量・費用の目安・許容する待ち時間：
7. 試す人・評価する日・継続を決める基準：

【相談後に整理】
ルールで処理する部分：
AIで支援する候補：
人が確認・判断する部分：
今回の試作に含めないこと：
未確認の点と次に確かめること：

最初の試作品で、
「本当に楽になるか」を確かめる。

まず一つの業務に絞り、MVP（必要な機能に絞った、動く試作品）を作ります。AIが文章を出せることに加えて、実際の作業全体が改善するかを確認します。

• 時間：入力の準備から確認・修正まで含めて、どのくらいかかるか。
• 品質：通常の例と例外で、何を正しく処理でき、どこで誤るか。
• 負担：担当者が使えて、無理なく確認を続けられるか。
• 費用：想定件数での利用・保守費用が、得られる効果に見合うか。

成功例だけで判断せず、見落としや確認に戻った件数も見ます。条件を満たした部分から次の開発へ進み、合わなければ、ルールによる自動化へ切り替えたり、対象を狭めたりできます。本番利用に必要な権限管理・例外対応・保守は別途確認します。

試作品は、どう受け取って使う？ 提供方法を見る ↗ブラウザーで使う形を基本に、Qzが行う設定、お客様の準備、社内で利用中のAIとの接続をまとめています。

Qz AI Labsでは、業務に必要な範囲でAIを使う方針です。AIシステムの設計について、Anthropicもまず単純な方法を選び、必要に応じて複雑さを増やすことを勧めています。性能と費用・待ち時間の兼ね合いも検討事項です。参考：Building Effective Agents ↗