iOSアプリにLLMを組み込んで、個人開発としてリリースしました。
実際に組み込んでみると学びが多かったので実際に経験したコツを共有してみます。なお今回はOpenAIのAPIを前提としています。Azure Open AI Serviceでもほぼ同じだと思われます。
- コンテクストを都度入れる
- Structured Outputs形式の指定で精度が上がる
- 相反するプロンプトは避けて、モデルを分割する
- 「会話」よりも「共創のための会話」がよい
- 数ヶ月経つとより安くていいモデルが出る前提で開発する
- LLMプロバイダーのAPIはよく変更される
- まとめ
コンテクストを都度入れる
2025年9月現在、OpenAIのAPIはresponses APIが主です。これは通常の呼び出し方だと、これまでの会話の流れだとコンテクスト（文脈）保持をしないステートレス型です。そのため、チャットアプリの組み込みなどでは少し不自然になります。
解決策として、
- responses APIの前回の応答について「previous_response_id」を設定してコンテクストを保持させる
- 数ターン前までの会話を直接入力に入れてしまう
といったことが考えられます。特にprevious_response_idは文脈の保持だけでなく、レイテンシーなどパフォーマンス向上にも寄与すると言われています
Structured Outputs形式の指定で精度が上がる
一度に複数の答えを提出して欲しい時があります。 例えばLLMに料理のレシピを提案して欲しい時、「レシピ名」、「材料」を出してほしいと言ったことがあると思います。その場合、プロンプトに「『レシピ名』、『材料』を必ず出してください」と指示しても絶対ではありません。 しかしjsonのStructured Outputsでは、必ず出力結果を返す出力形式が指定できます。具体的には以下のようなjson形式をAPIのフォーマット指定パラメータに設定します。
{
"name": "recipe_response",
"schema": {
"type": "object",
"properties": {
"recipes": {
"type": "array",
"description": "提案されたレシピの一覧",
"items": {
"type": "object",
"properties": {
"title": {
"type": "string",
"description": "レシピ名"
},
"ingredients": {
"type": "array",
"description": "必要な材料",
"items": {
"type": "string"
}
}
},
"required": ["title", "ingredients"]
}
}
},
"required": ["recipes"]
}
}
取り回しのしやすさなどもあるので、API経由ではStructured Outputsが有用です。
相反するプロンプトは避けて、モデルを分割する
人に近い役割をAIに持たせようとすると、相反する役割を持つことがあります。
例えば、「アイデアの壁打ちをする」という役割を持たせた時、
- 「アイデアを広げる」役割
- 「批判的な思考でアイデアを検討する」役割
といった相反する役割が求められたりします。 プロンプトで解決しようとするとて、「あなたは壁打ちAIです。こういう時はアイデアを広げてください。こういう時は批判的な思考でアイデアを検討してください…」と相反して、しかも長いプロンプトになってきます。
プロンプトが長くなると、LLMも全ての指示を守ることが困難になります。 それなら、
- 「アイデアを広げる」モデル
- 「批判的な思考でアイデアを検討する」モデル
- 「1,2のアウトプットを見て最終回答を考える」モデル
の3つに分割する方がより網羅的に論点を整理でき、回答の精度も上がります。このような複数の役割を持たせることで精度が上がる論文も出ています。
他にも、同じリクエストを、同じプロンプトだけど別々のモデルに投げることで精度が上がると言った論文もあるのでモデルを複数使って組織化するというテクニックは有用なのでしょう。
「会話」よりも「共創のための会話」がよい
LLMはなんだかんだで、タスク思考です。あまり自らゴール設定をしてくれません。チャットUIを作ったとして、ゴールがなければ取り止めのない質問が繰り返されるなど終わりなき会話が広げられます。チャットを目的とするのではなく、何かを作り上げる「共創」のためのチャットがよい所感があります。
caremioでは、物事の捉え方を一緒に整理するためのチャット、という位置付けにしています。
数ヶ月経つとより安くていいモデルが出る前提で開発する
開発中に経験したことですが、OpenAIのモデルは数ヶ月経つと、より良いモデルがより「安く」提供されたりします。
こちらは比較表ですが、GPT4(左)よりGPT4.1（中央）の方がIntelligenceが大幅に上がっているにも関わらず、インプット100万トークンあたりの金額は30ドルから2ドルへと大幅に下がっています。
GPT4.1（中央）とGPT5（右）の比較でもReasoningができるようになっているにも関わらず、インプットあたりの金額は2ドルから1.25ドルへと下がっています。
ここから考えられることは、「時とともにモデルが改善され、しかも安価に提供されていく」前提で開発を進めるのが良いと考えています。つまりコスト面を気にしすぎて開発しないよりは、コストが安くなるだろう前提で開発を計画するのが良いと考えています。
LLMプロバイダーのAPIはよく変更される
6月に紹介したOpen AI Assistant APIですがresponses APIの登場によって開発が停止することが発表されました。
エージェント・シフト─OpenAI Assistantで“自律型ビジネス”が切り拓けるか - 新規事業開発者のブログ
まだまだ変更が激しい世界なので、APIが変わっていくことは検討しつつ、常に変化に敏感にいるべきでしょう。
まとめ
汎用的になりそうな6つのコツを提供しました。小規模アプリ前提での組み込みなので今回の紹介になりましたが、もう少し大規模にやるならLLM組み込みに特化したアプリケーションフレームワークを採用するなどもあるでしょう。
開発効率化の文脈ではたくさんノウハウが提供されていますが、LLM組み込みのコツはノウハウがまだ提供されていないのと、LLMの組み込み余地はいろんなアプリにありそうなので一助になれば幸いです。
ご質問や情報交換されたい方はメールかXまでどうぞ！
