AI活用パターン集

この章でわかること: AIをアプリに載せるときに繰り返し出てくる代表的な”型(パターン)”。「とりあえずAIに聞く」から一歩進んで、やりたいことに合った組み方を選べるようになります。どのパターンも、コードを書けなくても「こういう形で頼む」という発想さえ持てば十分です。

前提として、LLMをアプリに組み込むで扱った「そもそもLLMが要るか」「軽量(エッジ)かクラウドAPIか」を先に押さえておくと、パターン選びがぶれません。

1. 構造化出力(決まった形で出させる)

どんな時に効く: AIの答えを、後続の処理やフォーム・表に流し込みたいとき。 仕組みのイメージ: 「自由な文章」ではなく「決まった項目の埋まった形式(JSON など)」で返させる。人間向けの返事ではなく、プログラムが扱える形で受け取るのがコツ。 プロト例: 問い合わせ文から「氏名・用件・緊急度」を項目として抜き出してフォームに自動入力。 AIへの頼み方: 「回答は文章ではなく、氏名 / 用件 / 緊急度 の決まった項目の形式で返して」注意: 形式を破ることがあるので、受け取り側で「項目が揃っているか」の確認を入れる。

2. 分類・振り分け(ルーティング)

どんな時に効く: 大量の入力を「種類ごと」に仕分けて、その先の処理を変えたいとき。 仕組みのイメージ: AIに「これは A / B / C のどれ?」と選ばせる。仕分けた結果で、表示や通知先、次のパターンを切り替える。受付の交通整理役です。 プロト例: 問い合わせを「クレーム / 質問 / 要望」に自動分類 → 担当チャンネルへ振り分け。 AIへの頼み方: 「本文を『クレーム・質問・要望』のどれか1つに分類して。理由も一言添えて」注意: 選択肢を明確に定義するほど精度が上がる。判断に迷う例は「その他」に逃がす。

3. RAG(自社の資料に基づいて答える)

どんな時に効く: AIに、自社の文書・マニュアル・FAQの内容で正確に答えさせたいとき。 仕組みのイメージ: 質問に関係する箇所をまず社内資料から検索して見つけ、その文章を 根拠としてAIに渡してから答えさせる。AIの”うろ覚え”ではなく、手元の資料を開いて答える イメージ。RAG(検索して補強する生成)と呼ばれ、ハルシネーション対策の定番です。 プロト例: 社内規程PDFを元に「経費精算の締め日は?」に出典つきで答える社内ボット。 AIへの頼み方: 「添付の資料の内容だけを根拠に答えて。資料に無いことは『資料に記載なし』と言って。どの部分を根拠にしたかも示して」注意: 元資料の質がすべて。古い・誤った資料を渡せば誤って答える。出典を必ず添えさせると検証しやすい。

4. 要約・抽出

どんな時に効く: 長い文章を短くしたい、または特定の情報だけ取り出したいとき。 仕組みのイメージ: 大量のテキストを渡し、「要点3つ」「日付と金額だけ」のように削って返させる。 プロト例: 長い議事録を「決定事項・宿題・次回日程」に要約。 AIへの頼み方: 「この議事録を、決定事項・宿題・次回日程の3見出しで要約して」注意: 長すぎる入力は分割が必要なことも(→ 次の「ワークフロー」)。要約は原文の確認とセットで。

5. プロンプトチェーン / ワークフロー(手順に分ける)

どんな時に効く: 一発では難しい複雑な処理を、小さな手順に分けて順に処理したいとき。 仕組みのイメージ: 「下書き → 校正 → 要約」のように、AIへの依頼を数珠つなぎにする。前の出力が次の入力になる。1回の巨大な指示より、区切ったほうが精度が上がります。 プロト例: 商品情報 →(生成)キャッチコピー →(校正)トーン調整 →(変換)3媒体向けに展開。 AIへの頼み方: 「まず要点を箇条書きにして。次にそれを元に案内文を作って。最後に敬語に整えて」注意: 途中に中間成果物を残すと管理しやすい(→中間成果物で精度を上げる)。

6. エージェント(道具を使って自律的に動く)

どんな時に効く: AIに、複数の道具(検索・計算・外部API・ファイル操作)を自分で選んで 使わせ、目標まで自律的に進めたいとき。 仕組みのイメージ: AIに「使える道具」を渡すと、状況を見てどれを使うか判断しながら 作業を進める。実はこのサイトを作っている Claude Code 自体がエージェントの一例です (ファイルを読み・書き・コマンドを実行しながら進める)。 プロト例: 「この住所リストを調べて、営業日だけ抽出し、地図に出して」を一気に代行。 AIへの頼み方: 「次の道具(検索・計算)を使ってよい。手順は任せるので、目標を達成して。各ステップで何をしたかは報告して」注意: 自律度が上がるほど予想外の動きもしうる。お金や外部への影響がある操作は 実行前に人の承認を挟む(→ Human-in-the-loop)。

7. マルチモーダル(文字以外も扱う)

どんな時に効く: 文字だけでなく、画像・音声も入力/出力に使いたいとき。 仕組みのイメージ: 画像を「見て」説明・抽出させる、音声を扱う。文字専用ではないAIを使う。 プロト例: レシート画像から金額と日付を抽出、写真を見て不備を指摘、図の内容を説明。 AIへの頼み方: 「この画像を見て、写っている表を文字の表に起こして」注意: 画像OCRの精度は品質しだい。個人情報が写り込む画像の扱いに注意(→個人情報・著作権の注意)。

8. 音声対話(声で会話する)

どんな時に効く: 手が離せない場面や、会話UIで使ってもらいたいとき。 仕組みのイメージ: 音声認識(声→文字)→ LLM(考える)→ 音声合成(文字→声) の3段をつなぐ。入口と出口はブラウザ標準の機能でも試せます(→Web / Chrome API にライブデモあり)。 プロト例: 声で質問すると、声で案内を返す受付デモ。 AIへの頼み方: 「音声認識で聞き取った質問に答えて、その回答を読み上げるところまでつなげて」注意: 認識・合成はブラウザ差がある。非対応時に文字入力へ切り替える備えを。

9. Human-in-the-loop(人の確認を挟む)

どんな時に効く: AIの出力を、そのまま実行・公開すると危ないとき。 仕組みのイメージ: AIは下書き・提案までを担い、送信・確定・公開の前に人が確認する。全自動にせず、要所に「人のOK」を入れる設計。 プロト例: AIが返信文を作る → 担当者が確認・修正してから送信。 AIへの頼み方: 「返信は下書きまで。送信はしないで、人が確認できるように表示して」注意: お金・個人情報・対外的な発信が絡む処理は、原則ここを入れる(内製と外注の線引きにも通じます)。

10. ガードレール・評価(暴走と品質を抑える)

どんな時に効く: 変な出力・危険な出力を防ぎ、品質を一定に保ちたいとき。 仕組みのイメージ: 入口で「扱ってよい話題か」を確認し、出口で「形式は正しいか」「不適切でないか」を もう一段チェックする。別のAIや簡単なルールでAIの答えを検品するイメージ。 プロト例: 生成した文章に禁止ワードが無いか確認してから表示。範囲外の質問は丁寧に断る。 AIへの頼み方: 「回答の前に、これが対応範囲内の質問か判定して。範囲外なら丁寧に断って」注意: 完全は狙えない。最後は人が見る前提(Human-in-the-loop)と重ねると安全。

選び方・組み合わせの目安

社内情報で正確に答えたい → RAG(+出典表示、+Human-in-the-loop)
入力を仕分けて処理を分けたい → 分類・ルーティング(+構造化出力)
フォームや表に流し込みたい → 構造化出力
複雑な作業を任せたい → ワークフロー(手順分け)、必要ならエージェント(+承認)
画像・音声を扱いたい → マルチモーダル / 音声対話
事故を防ぎたい → Human-in-the-loop、ガードレール(常に添える)

なぜ大事か

AIを「なんとなく賢い箱」として1回呼ぶだけでは、精度も安全性も頭打ちになります。 RAGで根拠を持たせ、構造化出力で受け渡し、人の確認で事故を防ぐ——こうした型を知っていると、「それAIでできる?」に対して**“どう組めば実用になるか”まで**答えられます。夢を広げる素材はAI・外部サービスでできること、載せ方の土台は LLMをアプリに組み込む、安全に出す作法はセキュリティの章へ。

参考リンク(情報ソース)

RAG(検索拡張生成)の解説 — AWS: https://aws.amazon.com/jp/what-is/retrieval-augmented-generation/
Anthropic「Building effective agents」(エージェント/ワークフローの設計): https://www.anthropic.com/engineering/building-effective-agents
OpenAI(構造化出力 / Structured Outputs): https://platform.openai.com/docs/guides/structured-outputs
MDN Web Speech API(音声認識・音声合成): https://developer.mozilla.org/ja/docs/Web/API/Web_Speech_API