チャットボットの作り方|自分の資料で答えるAIを自作する前に決める6項目

結論から言います。自分の資料を読ませて答えるチャットボットを自作するなら、ツールの画面を触る前に6つの決めごとを先に済ませてください。作り方の記事はノーコードツールの操作手順か、エンジニア向けの実装解説に分かれがちですが、実際に手を動かしてみて、手が止まったのは操作ではありませんでした。資料が読み込めない、誰に見せるのか決めていなかった、「会話の中身は誰が見られるの?」に答えられない——止まったのはこの3つです。

みやっち🧑‍💻は2026年9月9日の深夜に、手元の資料を読ませて答えるチャットボットを作れる自社サービス「AIチャットつくーる」の実装を、Claude Code・Codexで始めました。この記事で扱う6項目は、その最初の数日で順にぶつかって決めたものです。開発はいまも続いていて、立ち上げたばかりのサービスなので、顧客数や導入効果といった運用の実績を語れる段階ではありません。ただ、作る側で順番にぶつかった決めごとは、同じ経路をたどる以上、自作する人にも同じ順番で出てくるはずです。それを6項目に並べたのがこの記事です。

自分の資料で答えるチャットボットの作り方: 手元のPDFやWordを読ませて答えるチャットボットは、①読ませる資料の形式 ②上限 ③答えの根拠 ④公開範囲 ⑤会話履歴を誰が見られるか ⑥失敗したときの処理、の6項目を作り始める前に決めるのが要点です。実装そのものはClaude Code・CodexのようなAIに任せられますが、この6項目の中身は作る本人しか決められません。

なぜ操作手順より先に「決めごと」なのか

自分の資料で答えるチャットボットは、画面を作った時点では完成しません。資料を読み込ませ、それを検索できる形にして、答えの根拠として使う——ここまで通って初めて「自分の資料で答える」状態になります。この経路のどこで何を決めるかが空白のまま作り始めると、途中で引き返すことになりがちです。

作る前に決める工程そのものの総論はAI開発の要件定義にまとめました。この記事はその特殊ケース、つまり自分の資料で答えるチャットボットに限った決めごとだけを扱います。何で作るか・どう作り進めるかの工程は業務アプリの作り方とVibe Codingで動く業務アプリを作る始め方にあるので、ここでは繰り返しません。

自分の資料で答えるチャットボットを自作する前に決める6項目

① 何を読ませるか——先に「切る形式」を決める

最初に決めるのは、対応する資料の形式です。みやっち🧑‍💻が実装してこの時点で検証が通ったのは、テキストが入っているPDF・Word(DOCX)・テキスト・Markdownの4種類。逆に、画像として入っている文字の読み取り、動画、Excelの直接取り込みは、作り始める時点で対象外と決めました。

「どんな資料でも全部読める」を目指すと作業が終わりません。先に切る形式を決めるほうが、早く動くものに届きます。

取り込みは「アップロードしたら終わり」ではありません。ファイルから文字を抜き出す処理が別に走ります。最初の関門はここで、実装時も抽出処理だけを切り出したテストを5件通しています。

② 上限をどこに置くか——4つの上限を作る前に決める

決めておく上限は4つあります。1ファイルの容量、抜き出したあとの文字数、PDFのページ数、そして1つのチャットボットにつき何ファイルまで読ませるか。妥当な線は扱う資料の性質で変わるので、値そのものより「作る前に決めてある」ことが大事です。決めないまま公開すると、重い資料を入れた人のところだけ落ちる、という一番説明しづらい状態になります。

そして上限は、作り手だけが知っていても意味がありません。アップロード画面の保存前と保存後の両方から確認できるようにしました。使う人が事前に分かる場所に出ていないと、上限を決めた意味がなくなります。

③ 答えの根拠をどう持たせるか——「それっぽく答える画面」と区別する

チャット画面だけなら、実はすぐ作れます。問題は、それが自分の資料に基づいて答えているかどうかは画面を見ても分からないことです。

自分の資料で答えさせる標準的なやり方は、資料をあらかじめ検索できる形に変換しておくことです(Embedding。文章を数値の並びに変換し、意味の近さで探せるようにしておく処理)。この「毎回資料を検索して答えに使う」やり方はRAGと呼ばれます。実装では、回答生成と変換の両方をAPI接続でテストして成功を確認し、そのうえで最後に資料に基づく実回答をE2E(画面から実際に触って通しで確かめる検証)で確認しました。ここを通すまでは、それっぽく答えるだけのチャット画面と区別がつきません。

根拠として読ませる資料そのものは、教材などの中身と、自分の口調・価値観を伝えるものに分けて用意すると出力が変わります。入れるナレッジは2種類、という分け方はGPTsのナレッジとはにまとめました。

資料そのものをAIに渡す原則はコンテキストエンジニアリングに、資料を蓄積して答えに使う別のやり方はLLM Wikiとはに書いてあります。

④ 誰に見せるか——公開範囲と、共有したあとの更新

公開範囲は最初から絞りました。「自分のみ」と「リンク共有」の2択です。そのうえで共有について決めたことが1つあります。受け取る側に設定やナレッジをコピーしない。共有リンクから来た人には、元のチャットボットを使う権利を足す形にしました。コピーを配る設計にすると、元の資料を直したときに古いコピーが各所に残ります。渡した相手が増えるほど、どれが最新か誰にも分からなくなる——これは作ってから気づくと直すのが重い部分です。

共有画面の状態は「非公開」「共有中」「停止中」の3つを用意し、停止中のときは利用者側に「このAIは現在利用できません。」と表示されるようにしました。作り手の都合で相手の画面から黙って消える、という状態を避けるためです。

⑤ 会話の中身を誰が見られるか——あとから必ず聞かれる項目

会話履歴は、会話した本人だけが閲覧でき、本人の操作で自分の履歴から消せる設計にしました。チャットボットを作った人であっても、他人の会話の中身は見られません。一方で、サービスを運営する側は、提供・保守・不正防止・改善に必要な範囲で、権限を持つ担当者が会話を確認できる形にしました。どちらも、決めたら利用規約に書いて、使う人が読める場所に置くところまでが1組です。

自作する人にとって、一番の分かれ目がここです。社内マニュアルのチャットボットなら、遅かれ早かれ「上司は部下の質問を見られるのか」を聞かれる項目です。そのとき設計を思い出しながら答えるのではなく、先に決めて、どこかに書いておく。決め方に正解はありませんが、決めていない状態だけは避けたいところです。

ちなみに、ChatGPTのプロジェクトを人と共有した場合は、部屋の中の会話がメンバー全員に見える仕様です(ChatGPTのプロジェクト共有で何が見えるか)。会話を本人だけに閉じたいなら、この項目を自分で決められる作り方が要ります。

⑥ 失敗したときにどうするか——再試行と後片付け

最後は、うまくいかなかったときの振る舞いです。3つ決めました。

  1. 資料の取り込み処理に時間の上限を置く。終わらない処理を待ち続けない
  2. 外部AIの使用量が分からないまま失敗したら、利用枠を保留して自動では再試行しない。勝手にリトライすると、失敗のたびに枠を食います
  3. 矛盾する操作はデータベース側のロックで止める。ファイルの処理中にチャットボットを消す、回答の処理中に会話を消す、といった操作です

それでも失敗は残ります。保存領域からの削除が失敗した分はキューに残し、毎日決まった時刻の定期処理で再試行する形にしました。9月11日に定刻で動いたこと、9月12日時点で未処理が0件であることまでは確認しています。ここで決めているのは「失敗したときに何が起きるか」であって、失敗しない保証ではありません。

なお、チャットで整理した結果をスプレッドシートへ書き込む連携まで作る場合は、失敗時の扱いに加えて「どの行に・何を・いつ書くか」と「人が直したセルをどう扱うか」を先に決めておく必要があります。決めた5つはGPTsからスプレッドシートに書き込む連携の決めごとにまとめました。

6項目を決めると、資料の扱いはこう変わる

決める前の状態はこうです。教材も社内マニュアルもお客様向けの説明資料もある。なのに「あの件、どこに書いてありましたっけ」と聞かれるたびに、自分がファイルを開いて該当箇所を探して返している。せっかく作った資料が、自分を経由しないと使えない。作り始めても、資料が読み込めない・誰に見せるか決めていない・履歴の扱いを説明できない、のどれかで止まる。

6項目を決めておくと、同じ資料を窓口の形で人に渡すところまで進められます。読ませる形式が決まっているから取り込みが通り、リンクを渡す相手と範囲が決まっていて、「会話の中身は誰が見られるのか」を聞かれてもその場で答えられる。そして資料を直せば窓口の答えも変わる、という形に持っていけます。自分が探して答える仕事から、資料を整えて窓口を渡す仕事へ——変わるのはここです。

自作する前に、まず教材への回答を小さく試したい場合は、AIチャットつくーるで教材1本から作る手順を使えます。名前・指示・教材を設定し、三種類の質問で答えを確かめる流れです。

「毎回資料を貼る」では届かないところ

汎用のチャットAIに資料をその場で貼り付けて質問するやり方でも、自分ひとりで使う分には答えは出ます。ただ、渡す相手が自分以外になった瞬間に、貼る作業も「どの資料を貼るべきか」の判断も相手側に移ります。相手はその資料の全体像を知らないので、ここで止まります。

だから、資料を読み込ませた窓口ごと渡す形が要るのです。そして、どの形式を読ませ、どこまで見せ、会話を誰が見られるかは、市販のサービスを選んだとしても結局あなたが決めることになります。実装はAIエージェントであるClaude Code・Codexに任せられますが、6項目の中身は業務と資料を知っている本人にしか埋められません。せっかく資料が手元にあるのに、決めごとの空白で止まったままなのはもったいない話です。

よくある質問

チャットボットは無料で作れますか?

完全に無料で、というのは難しいところです。まず実装を任せるAIエージェント側に費用がかかります(Claude Codeは有料プランが前提です)。加えて、資料を検索できる形に変換する処理と回答の生成には外部AIのAPIを使うため、使った分の費用が別に発生します。だから⑥の「失敗したときに自動で再試行しない」が効いてきます。無料で試したい段階なら、まずは資料1本・自分だけが使う状態で通してみるのが現実的です。

個人でも作れますか?

作れます。むしろ6項目は、個人で作るときのほうが決めやすいはずです。読ませる資料も、見せる相手も、自分で全部把握しているからです。組織で作る場合に難しくなるのは⑤で、会話履歴を誰が見られるかを関係者と合意しておく必要があります。

プログラミングができなくても作れますか?

実装をClaude Code・Codexに任せれば、非エンジニアでも作れます。ただし中身を確かめずに進めるという意味ではありません。動くものを先に作り、詰まった箇所だけ内容を確かめながら降りていく進め方は、Vibe Codingで動く業務アプリを作る始め方で詳しく書いています。この記事の6項目は、その前に置く工程です。

社内マニュアル用に作る場合、上司は部下の質問を見られますか?

設計次第です。会話した本人だけが見られる形にもできますし、管理者が全体を見られる形にもできます。大事なのはどちらを選ぶかではなく、作る前に決めて、使う人に伝えておくことです。あとから変えると、伝えていた前提と食い違うため説明が難しくなります。

決めてから作れば、途中で引き返さない

チャットボットの作り方でつまずくのは、たいてい技術ではなく決めごとの空白です。6項目を先に埋めておけば、あとは作る工程に集中できます。

そして決めたとおりに動く窓口は、自分の資料・自分の相手・自分のルールに合わせて6項目を決めたときに手に入ります。実装を任せられるClaude Code・Codexがあるいま、その組み立ては非エンジニアでも自分の手でやれます。

AI Crewでは、こうした「何を作るか・作る前に何を決めるか」の工程から、みやっち🧑‍💻が受講生と一緒に進めています。まず無料セミナーでお会いしましょう。

関連記事

「AI Crew」は株式会社AI Orchestraの登録商標(登録第6942947号)です。