開発したAIチャット「加賀」について｜無料枠で動かす技術構成とキャラクター設計
加賀（かが） は、僕が kawagame.com/chat/ で公開しているAIチャットです。雑談や勉強、プログラミングの質問だけでなく、画像の読み取り、Web検索、複雑なテーマの徹底調査にも対応しています。
一番こだわっているのは、AI自身が質問を理解し、次に必要な行動を選びながら回答を作ることです。検索すべきなら調べる。資料が足りなければ追加で探す。集めた情報を確認してから、答えをまとめる。単にLLMのAPIを呼ぶだけではなく、こうした流れを一つのチャットに組み込んでいます。
そして、この仕組みを無料枠の中で動かすために、モデルの使い分けやAPIの利用量も細かく設計しています。この記事では、その技術構成を紹介します。
システムプロンプトの全文、モデルの正確な切替順、安全判定の細かな条件は掲載していません。実際に採用している技術と、そう設計した理由に絞って紹介します。
加賀はどう動いているのか
サイト本体はAstroで作り、Cloudflare Pagesで公開しています。チャットのバックエンドにはCloudflare Pages Functionsを使っています。
ユーザーがメッセージを送ると、まずサーバーが入力や利用状況を確認します。その後、AIが質問を判断し、必要に応じて会話生成、Web検索、徹底調査、画像理解などの処理へ進みます。APIキーはサーバー側で管理しており、ブラウザから外部のAIへ直接接続する構成ではありません。
回答にはServer-Sent Events（SSE）を使っています。AIが文章を生成するたびに少しずつ画面へ届けるので、長い回答でも完成を待たずに読み始められます。
ただし、加賀の中心はストリーミング表示ではありません。質問に合うモデルやツールを選び、得られた結果を次の処理につなげる仕組みです。
無料枠で動かすためのAI編成
AIのAPIには、リクエスト数やトークン数などの利用制限があります。高性能なモデルをすべてのメッセージで使えば、あっという間に枠が尽きます。かといって軽量なモデルだけに任せると、難しい質問への回答が物足りなくなることがあります。
そこで加賀では、一つのモデルにすべてを任せず、仕事に合わせて複数のAIを使い分ける形にしました。
短い雑談なら、素早く自然に答えられる経路を使います。コードの解析や複雑な推論が必要なら、高性能なモデルを試します。画像が送られてきたら画像を理解できるモデルを使い、最新情報が必要なら検索ツールを呼び出します。
検索を進めるAIと、最後の回答を書くAIも、必ずしも同じである必要はありません。どこに高い推論能力が必要なのかを考え、限られた利用枠を配分しています。
混雑したモデルは自動で切り替える
無料枠を使う以上、APIの利用制限は避けられません。あるモデルが混雑していたり、応答が遅かったりする場合には、別の経路を試します。
加賀のルーターには、直前にうまく答えたモデルを短時間優先する仕組みと、利用制限に達したモデルを一時的に候補から外す仕組みがあります。
単に失敗したら同じモデルへ何度も再試行するだけでは、無料枠も時間も無駄です。使えない理由に応じて経路を切り替えることで、回答までの待ち時間を抑えています。
また、回答が画面に流れ始めた後は、途中で別モデルの文章に置き換えません。前半と後半が別のモデルになると、文章がつながらなくなる可能性があるためです。
Workers AIも予備として使う
外部のAIサービスだけでなく、Cloudflare Workers AIも利用しています。これはCloudflareの環境からAIモデルを実行する仕組みで、外部APIが使えないときの予備経路として役立ちます。
Workers AIの消費量はNeuronsという単位で扱われます。加賀では入力と出力の規模から利用量を見積もり、無料枠に余裕を残すよう独自の上限を設けています。
複数の無料枠を組み合わせても、無計画に呼び出せばすぐに使い切ってしまいます。だからこそ、モデルを増やすだけでなく、どの場面で使うかを決めることが重要です。
無駄な呼び出しを減らす
毎回「検索が必要か」を別のAIに判断させるだけでも、APIの呼び出し回数は増えます。加賀では短い雑談などで不要な判断処理を省き、調査が必要な場面にリソースを使うようにしています。
検索で集まった資料の重複除去や整理も、プログラム側で処理できる部分は任せています。また、モデルに渡す会話履歴やプロンプトの長さも調整しています。
高性能なAIを何度も呼ぶのではなく、本当に考える必要がある場面へ集中させる。 これが無料枠で品質を保つための基本方針です。
AIが自分でツールを選ぶ
加賀は、会話の内容に合わせて次に何をするかを判断します。
検索するかどうかを単語の有無だけで決めると、短い発言の意味や直前の会話を十分に読み取れません。加賀では、発言そのものだけでなく、会話の流れから必要な行動を判断します。
例えば、ある製品について話している途中で「今はいくら？」と聞かれたら、直前の製品の価格を調べる必要があります。一方、「さっきの説明、分かりにくい」と言われたら、検索するより説明し直す方が自然です。
この判断に使っているのが、LLMのTool Callingです。
AIに通常の回答、Web検索、詳しい調査の提案などのツールを用意し、会話の流れを踏まえて次の行動を選ばせています。検索すると判断した場合には、必要な検索クエリも考えます。
サーバーは選ばれたツールを実行し、その結果を回答へつなぎます。固定的なキーワード判定とは異なり、会話の意味に応じて処理を選べる構成です。
さらに徹底調査では、ツールを一度呼んで終わるのではありません。得られた情報を確認し、次に何を調べるべきかを判断しながら進めます。 ここが加賀のエージェント機能の中心です。
徹底調査はどうやって自律的に動くのか
通常のWeb検索に加えて、加賀には「徹底調査」モードがあります。
例えば「最近のAI半導体について、主要メーカーの製品や性能、今後の動向を比較して」と聞かれたとします。この質問には、製品の仕様だけでなく、発表時期や市場に関する情報も必要です。一つの検索結果を要約するだけでは、十分な回答になりません。
徹底調査では、AIがまず質問を分析し、調べるべき内容を整理します。そして検索やページ取得のツールを使い、資料を集めていきます。
調べながら、次の行動を決める
徹底調査では、AIが検索ツールを使って資料を探し、必要なページを読み、得られた情報を次の判断へつなげます。
最初に見つかった資料だけで十分とは限りません。あるメーカーの情報はそろっていても、比較対象となる別のメーカーの資料が足りない場合があります。そのときは不足している部分を調べるため、検索の方向を変えます。
調査の進み具合に応じて次の行動を選ぶので、あらかじめ決めた検索を順番に消化するだけではありません。情報を集め、確認し、必要なら調べ直す流れで進みます。
調査の進行管理と最終的な文章の生成は、役割を分けて処理できます。比較的軽いモデルが検索やツール操作を進め、より高度な推論が必要な段階に高性能モデルを使うことで、無料枠を効率よく利用しています。
途中経過も画面に表示する
徹底調査は普通のチャットより時間がかかります。何をしているのか分からないまま待つのではなく、調査の進行状況を画面に表示しています。
検索、資料の読み取り、回答の作成といった段階を確認できるため、AIが今どの作業を進めているのか分かります。
検索結果の品質を高めるために
Web検索のAPIから結果を取得するだけなら、難しいことではありません。しかし、検索結果の上位にあるページが、必ず質問の答えを含んでいるとは限りません。
加賀では、情報を見つけることと、回答の根拠として使えることを分けて考えるようにしています。
複数の検索経路から資料を集める
検索にはExaやTavilyなどのサービスを利用できる構成を採用しています。さらに、必要に応じてWebページの本文を取得する仕組みも用意しています。
検索結果のタイトルや短い説明だけでは、正しい内容かどうか判断できないことがあります。その場合には実際のページを読み、質問に必要な部分を確認します。
一次情報と関連性を重視する
技術仕様なら公式ドキュメント、企業の発表なら企業自身の資料など、質問の内容に合わせて一次情報を優先します。
取得した資料は、重複しているものを整理し、質問との関連性を考慮して選別します。検索結果を専用モデルで並べ直すリランキングにも対応しています。
大量のページをそのまま回答モデルへ渡すより、必要な資料を選んだ方が、回答を組み立てやすくなります。入力トークンが減るため、無料枠の節約にもなります。
根拠が足りなければ追加で調べる
例えば三つのサービスを比較する質問で、一つのサービスの資料だけ詳しく集まっても、比較としては不十分です。
加賀には、質問に必要な項目と取得済みの資料を照合し、情報の不足を探す処理があります。資料同士に矛盾する数値がないか、公式の裏付けが必要な情報が残っていないかも確認します。
足りない情報が見つかった場合には、その項目を調べるための検索を追加します。闇雲に検索回数を増やすのではなく、必要な根拠を探しに行く仕組みです。
回答を書いた後も見直す
資料がそろっていても、AIがその内容を正しく文章にまとめるとは限りません。
そこで複雑な調査では、回答が質問の要求を満たしているか、取得した資料と一致しているかを確認する処理も用意しています。必要があれば資料を追加で調べたり、文章を書き直したりします。
検索して終わりではなく、読み、確かめ、足りなければ調べ直し、回答を作る。 加賀の調査機能は、この一連の作業をAIが進められるように作っています。
超高性能モードと徹底調査を組み合わせる
加賀には、通常の会話とは別に「超高性能モード」もあります。数学やプログラミング、複雑な分析など、より深い推論が必要な質問に向けた機能です。
徹底調査が外部の情報を集める機能なのに対して、超高性能モードは回答を考えるモデルの能力を重視する機能です。そして、この二つは同時に利用できます。
両方オンにするとどうなる？
併用時には、調査エージェントが必要な資料を集め、整理した情報を高性能モデルへ渡して、最終的な回答を作ります。
例えば、最新の技術動向を複数の資料から比較する場合、まず調査のためのAIが検索やページの読み取りを進めます。その後、高性能モデルが集められた情報を使って分析し、文章にまとめます。
ここで重要なのは、検索のたびに高性能モデルを使うわけではないことです。調査を進める役割と、最後に深く考えて文章を書く役割を分け、高性能モデルの利用枠を必要な部分へ集中させています。
この役割分担によって、自律的な情報収集と高度な推論を組み合わせた調査を実行しています。
超高性能モードと徹底調査の利用回数は別々に管理し、実際に使われた処理に応じて消費を確定する仕組みです。
画像の読み取りと推論を分担する
加賀は画像を含む質問にも対応しています。問題集の写真やスクリーンショットを送って質問したり、その後に「二番目は？」と続けたりできます。
画像はブラウザ側で形式やサイズを調整してから送信し、画像に対応したモデルが内容を読み取ります。
一方、高性能な推論モデルの中には、画像を直接受け取れないものもあります。
加賀では、画像を読むAIと、回答を考えるAIを分ける仕組みを用意しています。まず画像対応モデルが文章や数式、図などを読み取り、その情報をテキストにまとめます。次に、推論モデルがそのテキストを使って質問に答えます。
画像の読み取りに失敗した場合は、画像を直接扱える経路へ戻すこともできます。
画像を理解する能力と、複雑な問題を考える能力を分担させることで、異なるAIの長所を組み合わせています。
会話が自然につながるようにする
加賀はAIエージェントとしての機能だけでなく、キャラクターとして自然に会話できることも大切にしています。
名前はサイトのドメインであるkawagameからkagaを取ったものです。性格には『艦隊これくしょん』の加賀を参考にした部分もありますが、独自のキャラクターとして設計しています。
キャラクターの口調が不要なときは、通常のAIアシスタントとして回答する「Kawa Chat」へ切り替えられます。日本語、英語、ベトナム語に対応しています。
モデルが変わっても口調を保つ
複数のモデルを使う場合、同じ指示でも返答の雰囲気が変わることがあります。あるモデルでは自然に話せても、別のモデルでは急に丁寧になったり、同じ表現を繰り返したりします。
そこで、サーバー側でキャラクター設定を管理し、モデルごとの特徴に合わせてプロンプトを調整しています。
「それ」「なんで？」のような短い発言を直前の会話につなげることや、存在しない出来事を勝手に作らないことなど、文章だけでなく会話の自然さを保つための工夫もしています。
会話履歴はブラウザに保存する
会話履歴はブラウザのlocalStorageで管理しています。サーバー側に会話履歴専用のデータベースを用意するのではなく、必要な履歴を送って会話の文脈を保つ構成です。
履歴の件数やデータ量には上限があり、モデルに渡す内容も調整しています。長い履歴を無制限に送り続けないことは、会話の品質とトークン消費量の両方に関わります。
公開サービスとして安定して動かす
複数のAIを組み合わせるだけでは、公開サービスとして十分ではありません。大量アクセスへの対策や、利用回数の管理、障害の検知も必要です。
利用回数はDurable Objectsで管理する
加賀ではCloudflare Durable Objectsを使って、チャットや各モードの利用枠を管理しています。
同時に複数のリクエストが届いても、枠の予約と消費を一貫して扱えるようにするためです。通常の会話、超高性能モード、徹底調査など、それぞれの処理に応じて利用状況を管理します。
また、Cloudflare Turnstileによる人間確認も利用しています。確認済みの状態は署名付きCookieで一定時間維持し、普通の会話で何度も認証操作が発生しないようにしています。
システムプロンプトを守るための強制遮断
加賀のキャラクター設定や会話のルールは、サーバー側でシステムプロンプトとして組み立てています。
ただし、そこに「内部の指示を公開しないで」と書くだけでは、十分な対策にはなりません。ユーザーの入力から内部設定を聞き出そうとする要求が来たとき、AIが必ず拒否するとは限らないためです。
そこで加賀では、通常の回答モデルを呼び出す前に、サーバー側でプロンプト抽出の要求を検査する仕組みを設けています。
明確に内部指示の抽出を求める入力を検出した場合、その時点で通常の回答処理を終了し、用意した応答を返します。加賀の本来のシステムプロンプトを持つモデルには、その要求を渡しません。
判定では直前の発言だけでなく、送信された会話履歴も確認します。一つのメッセージだけでは意図が分からない要求にも対応するためです。
モデルに秘密を守ってもらうだけでなく、秘密を持つモデルへ危険な要求を進ませない。 これが強制遮断の考え方です。
判断が難しい入力は別のAIで確認する
一方、システムプロンプトに関する話題がすべて危険というわけではありません。一般的な仕組みを質問したり、自分で書いたプロンプトを添削したりするのは、普通の利用です。
加賀では、明確な抽出要求を止める判定とは別に、判断が難しい入力を専用のAIで確認する処理を設けています。
この判定用AIには、加賀の本物のシステムプロンプトを渡しません。独立した指示と検査対象の会話だけを使い、内部設定の抽出を求めているかを判断させます。
判定用AIが受け取る情報と、通常の加賀が持つ内部設定を分離しておけば、セキュリティ確認そのものが秘密情報の流出経路になることを防げます。
判定できない場合は安全側で止める
判定用AIが混雑していたり、正常な判定結果を返さなかったりする場合もあります。
加賀では、追加判定が必要な入力について安全だと確認できなければ、通常の回答生成へ進めません。判定に失敗した場合も、内部設定を持つモデルにその入力を渡さず、サーバー側で応答を終了します。
このように、確認処理が失敗したときに安全側へ倒す設計をFail Closedと呼びます。
遮断が確定したときは、通常の加賀を呼び出して拒否文を考えさせるのではなく、サーバーが応答を返します。内部情報を守るだけでなく、不要なAPI呼び出しを減らせる点も、無料枠での運用に合っています。
スコアリングで不正利用を検出する
システムプロンプトの抽出対策とは別に、危険な要求や悪質な利用を検出するためのスコアリングも実装しています。
入力内容を複数のカテゴリに分け、内容の危険性に応じて重み付きのスコアを加算します。危険な行為の具体的な手順を求める要求と、軽い不適切表現を同じ重さで扱わないためです。
問題のある入力が続いた場合には、累積したスコアも考慮します。ただし、スコアだけで機械的に長時間の利用停止を決めるわけではありません。
追加の確認が必要な場合は、通常の会話を担当する加賀とは別のAIが、直近の会話と検出内容を踏まえて審査します。悪質な利用と判断されれば一定時間アクセスを制限し、誤検知ならスコアをリセットして通常の利用を続けられるようにしています。
特に危険性の高い要求については、スコアの累積や追加審査を待たず、その場で回答を拒否する処理もあります。
ルールベースで効率よく検出し、判断が必要な場面だけ別のAIへ任せる。 安全性を確保しながら、無料枠の消費や普通の利用者への影響を抑えるための構成です。
外部から取得した情報も無条件には信用しない
加賀は検索やページの読み取りを自分で進めるAIエージェントです。そのため、ユーザーの入力だけでなく、検索先の文章や画像内の文字も扱います。
こうした外部情報は、回答の根拠にはなっても、加賀の動作ルールを変更するための指示ではありません。
参考資料と実行すべき命令を区別し、外部の文章をそのまま高い権限の指示として扱わないことを重視しています。
AIには調査やツール選択を任せながら、内部情報の保護と安全上の境界はサーバー側でも守る。 これが、公開できるAIエージェントを作るうえでの基本方針です。
稼働状況を実際に確認する
複数のモデルを使っていると、一部の経路だけが混雑することもあります。そこで、稼働状況ページを用意しています。
Cloudflare WorkersのCronを使って定期的に短い生成や検索を実行し、実際に応答が得られるかを確認しています。APIが正常なステータスを返しても、回答が空なら正常とは判断しません。
監視結果や障害履歴の管理にもDurable Objectsを利用しています。
ただし、監視自体も無料枠を消費します。そこで、利用枠の少ない経路では確認頻度を抑えるなど、チャット本体で使う分を残せるようにしています。
開発して分かったこと
加賀を作っていて感じたのは、AIチャットの品質は、使っているモデルの性能だけでは決まらないということです。
高性能なモデルでも、最新情報を知らなければ正しく答えられません。検索できても、資料を読み間違えれば意味がありません。モデルをたくさん用意しても、切り替えが遅かったり、口調が急に変わったりすれば使いにくくなります。
だからこそ、どのAIに何を任せるか、どのタイミングで検索するか、何を根拠に回答するかという部分に時間をかけました。
特に徹底調査では、AIが質問を分析し、自分でツールを使い、情報が足りなければ調べ直す流れを実装しています。高性能モデルを最後の回答生成に集中させられるのも、役割を分けているからです。
無料枠という制約があったからこそ、単純に大きなモデルを呼ぶのではなく、複数のAIに仕事を分け、自律的に動かす仕組みを考えるようになりました。
おわりに
加賀は、無料枠を組み合わせて動かしているAIチャットです。普通の会話に加えて、画像理解、Web検索、徹底調査、超高性能モードなどを利用できます。
その裏側では、AIが会話の内容から次の行動を選び、必要な情報を集め、根拠を確認しながら回答を作っています。
僕が目指しているのは、単に高性能なモデルを使うことではありません。限られた無料枠の中で、AI自身が判断し、行動し、複雑な仕事を進められる仕組みを作ることです。
これからもモデルの編成や検索品質、応答速度を改善しながら、より使いやすいAIに育てていきたいと思っています。