LLM アプリ開発入門:チャット・アシスタント・自動化

AI Navigate Original / 2026/5/16

共有:

要点

  • LLM アプリの難所はモデル呼び出しでなく不確実出力の設計
  • 構成は入力→プロンプト構築→モデル呼び出し→後処理
  • 用途・モデル(コスト/遅延/規約)・失敗時挙動を先に決める
  • 出力を信用せず境界で検証、コスト・遅延を最初から計測

「LLM を組み込んだアプリ」とは、大規模言語モデル(GPT-5.5 や Claude Opus 4.8 のような文章を生成する AI)を裏側で呼び出して動くソフトのことです。チャットボット・社内アシスタント・定型業務の自動化まで、形はさまざまですが、土台になる構造はどれもよく似ています。難しさは「モデルを呼ぶこと」自体ではありません。本当の勘所は、出力が毎回ぶれる・ときどき間違える前提でアプリを設計すること。ここを押さえると、最初の一歩から落とし穴を避けられます。

Under the Hood

01LLM アプリの基本構造

多くの LLM アプリは、入力を受け取り、モデルに渡す指示文(プロンプト)を組み立て、モデルを呼び、返ってきた答えを検証・整形して使う——というひとつの流れに収まります。ユーザーから見えるのは最後の答えだけですが、その手前に必ずこの 4 段があります。

入力+文脈 プロンプト 構築 指示+文脈+入力 モデル 呼び出し API / ストリーミング 検証・整形・保存

FIG.1 入力 → プロンプト構築 → モデル呼び出し → 後処理。見えるのは最後だけ

4 段それぞれの中身を、もう少しかみくだくと次のようになります。

  1. 入力:ユーザーが打ち込んだ質問や依頼に、会話の履歴や参照すべきデータ(社内文書など)を添える。
  2. プロンプト構築:「あなたは○○のアシスタントです」というシステム指示に、文脈とユーザー入力を組み合わせて、モデルに渡す一塊の文章を作る。
  3. モデル呼び出し:OpenAI や Anthropic などの API へリクエストを送る。返答を一文字ずつ流すストリーミングにすると、待ち時間が体感で短くなる。
  4. 後処理:返ってきた答えをそのまま信じず、形式を確かめ、必要なら外部の処理(ツール)を呼び、最後に画面表示や保存をする。

02作るのは大きく3タイプ

「LLM アプリを作りたい」と言っても、目指す形によって必要な部品も難しさも変わります。代表的な 3 つの型を知っておくと、自分の用途がどこに当たるか見当がつきます。下にいくほど、モデルに任せる範囲が広がり、そのぶん安全策の重みも増します。

チャット

ユーザーと往復で対話する。Q&A や下書き作成など。会話履歴をどう持つかが設計の中心。最初の一歩に向く。

アシスタント

対話に加えて、社内文書の検索や外部サービスの操作(ツール呼び出し)を行う。できることが一気に広がる。

自動化

人を介さず、決まった手順を繰り返し実行する。請求書の仕分けなど。間違いがそのまま流れるので検証が要。

注意したいのは、「チャットは無料・低リスク、自動化は有料・高リスク」と単純に分けられないこと。料金は使うモデルと量で決まり、リスクはその AI に何を触らせるかで決まります。読むだけのチャットより、送金やメール送信ができるアシスタントのほうが、当然慎重さが要ります。

03最初に決める3つのこと

コードを書き始める前に、次の 3 点を言葉にしておくと、後の判断が一気に楽になります。曖昧なまま進めると、モデル選びでも安全策でも迷子になりがちです。

01

用途と必要な正確さ

雑談の相手なら多少の揺らぎは許容できますが、契約書の要約や金額の計算では一文字の誤りも困ります。「どこまで間違いを許せるか」を先に決めると、後の検証の強さが決まります。

02

使うモデル

性能・コスト・応答速度・データの扱い方のバランスで選びます。賢い大型モデルは正確ですが高く遅め、小型モデルは安く速い。用途ごとに使い分けるのが定石です(次節で具体例)。

03

失敗したときの動き

モデルは必ずときどき間違えます。「答えられないときは無理に作らず不明と言わせる」「重要な操作は人が承認する」といった、転んだときの受け身を最初から決めておきます。

04モデルの選び方(2026年の目安)

2026 年現在、主要なモデルは小刻みに更新されています。たとえば OpenAI は 2026 年 4 月に GPT-5.5 を公開し、Anthropic は 5 月に Claude Opus 4.8 を出しました。どちらも「賢いが高め」の大型モデルです。重要なのは特定の型番を覚えることより、同じ提供元の中に賢さ重視と速さ・安さ重視の段があると知っておくことです。

賢さ重視の大型モデル速さ・安さ重視の小型モデル
難しい推論・長い手順・コードに強い分類・要約・定型返信など軽い処理に十分
料金は高め・応答はやや遅い料金は安く・応答が速い
例:GPT-5.5 / Claude Opus 4.8例:各社の mini / Haiku 系

実務では「下書きは小型、最終チェックは大型」のように1 つのアプリで複数モデルを使い分けると、コストと品質の折り合いがつきます。なお料金体系は頻繁に変わるので、金額は必ず各社の公式ページで最新を確認してください。ここに具体的な単価は載せません(すぐ古くなるため)。

05土台になる道具立て

ゼロからすべて自作もできますが、用途に合った道具を使うと立ち上がりが速くなります。2026 年時点でよく使われる選択肢を、役割ごとに挙げます。どれを使うかは「何を作りたいか」で選べば十分です。

  • 公式 SDK:OpenAI / Anthropic などが配る純正ライブラリ。モデルを呼ぶだけならこれが一番素直で、何が起きているか追いやすい。
  • UI 連携:Web 画面に組み込むなら Vercel AI SDK が定番。ストリーミング表示などを楽に扱える。
  • オーケストレーション:検索や複数ステップを組む LangChain / LlamaIndex。ただし近年は、モデル自体が賢くなり素のままで十分なことも増えたため、「まず公式 SDK で素朴に作り、必要になってから足す」が無難。

最初から重いフレームワークを抱え込まず、素直な実装で動かしてから必要な部品を足す。

06ツール呼び出しでできることが広がる

チャットを「アシスタント」に進化させる鍵がツール呼び出し(function calling)です。モデルに「使える関数の一覧」を渡しておくと、モデルは必要に応じて「この関数を、この引数で呼んで」と指示を返します。実際にその関数を動かすのはあなたのアプリ側で、結果をモデルに戻すと、それを踏まえて最終回答を作ります。これで、天気の取得・社内検索・カレンダー登録など、文章生成だけでは届かない世界に手が伸びます。

モデル アプリ +ツール ① 「この関数を呼んで」 ② 実行した結果を返す ③ 結果を踏まえて最終回答 検索・登録・送信…

FIG.2 モデルは「呼んでほしい関数」を返すだけ。実行と判断はアプリ側に残る

ここで肝心なのは、モデルは関数を直接実行できないという点です。実行の主導権はアプリ側にあるので、「送金」「ファイル削除」のような取り返しのつかない操作は、アプリ側で人の承認を挟む設計にできます。次節の安全策に直結する、重要な分かれ目です。

07出力を信用しない設計

LLM は、もっともらしいのに事実と違う内容を堂々と書くこと(ハルシネーション)があります。これは不具合というより、確率で次の言葉を選ぶ仕組みそのものの性質です。だから「賢いモデルを使えば消える」とは考えず、間違いが混ざる前提で受け止める仕掛けを必ず置きます。

  • 根拠で裏を取る:事実が重要なら、社内文書や信頼できる一次情報を検索させ、その根拠から答えさせる。引用を必須にすると検証しやすい。
  • 形式を検証する:日付や金額、決まった選択肢などは、返ってきた値がルール通りか機械的にチェックする。外れたら作り直させる。
  • 分からないときは「不明」:根拠が足りないなら無理に答えさせず、不足点を返す方が安全。

「出力は下書き、最終判断は人かルール」という姿勢が、信頼できるアプリの背骨になります。

Security First

一番の脅威はプロンプトインジェクション

LLM アプリで現実的に怖いのは、プロンプトインジェクションです。ユーザー入力や、モデルが読み込む外部データ(Web ページ・メール・社内文書)に「これまでの指示を無視して機密を出せ」といった悪意の文を仕込み、モデルを乗っ取る攻撃で、OWASP の LLM 向けリスク一覧でも筆頭に挙げられ続けています。とくにツールを使えるアシスタントでは、勝手にメール送信やデータ削除をさせられる恐れがあります。

外部データ 悪意の指示が混入 入力フィルタ +境界の検証 信用しない前提で扱う モデル 重要操作は 人が承認

FIG.3 外部データは常に「敵かもしれない」。境界で検証し、危険な操作は承認制にする

完全に防ぐ特効薬はまだありません。だからこそ多層防御が基本です。具体的には、最小権限(その AI に本当に必要なツールしか渡さない)、入出力のフィルタ、そして重要操作には人の承認を必ず挟むこと。さらに、わざと攻撃文を投げて壊れないか試す敵対的テストを定期的に回します。「外部から来たテキストは信用しない」を合言葉にしてください。

08動かす前に測る・守る

最後に、運用に乗せる前の構えです。LLM アプリは「動いた」で終わりにせず、測る・守るを最初から組み込みます。後付けは大変なので、小さくても初日から入れておくのが得策です。

  • コストとレイテンシを計測:呼び出しごとの料金と応答時間を記録する。拾いすぎ・長文の渡しすぎがすぐ見つかる。
  • ログを残す:入力・組み立てたプロンプト・モデルの答え・実行したツールを記録すると、不具合の追跡と改善の両方に効く(個人情報の扱いには注意)。
  • 評価セットを育てる:実際に近い質問と理想の答えを 30〜50 問ほど用意し、変更のたびに当てて品質を見る。これが改善の最強の資産になる。

09まとめ:小さく動かす→測る→守る

LLM アプリの中心は、「入力 → プロンプト構築 → モデル呼び出し → 後処理」というシンプルな流れと、出力を信用しない設計です。まずは公式 SDK で素朴なチャットを動かし、必要になったらツール呼び出しや検索を足す。並行してコスト・ログ・評価を測り、プロンプトインジェクションには最小権限と人の承認で備える。小さく動かす → 計測する → 守る。この順で進めれば、最初の一本から堅実なアプリに育てられます。