Artieの設計：AIドキュメントアシスタント
より広い文脈については、関連するブログ記事をご覧ください：テクニカルライターとAIエージェント：Artieの開発を通じて学んだこと。検索拡張生成（RAG）の仕組みや、このプロジェクトがテクニカルライティングにどのように位置づけられるかを解説しています。
このケーススタディでは、本ドキュメントサイトに組み込まれているAIドキュメントアシスタント「Artie」（Algoliaを使用して構築）の設計決定について詳しく解説します。Artieは、ここで公開されているコンテンツのみを用いて厳密に質問に回答するよう設計された、検索拡張生成（RAG）アシスタントです。そのシステムプロンプトは、一般的な学習知識を用いてドキュメントに関する質問に回答することを制限し、ハルシネーション（幻覚）を最小限に抑え、架空の機能の捏造を防止します。
ドキュメントアシスタントの構築は、エッジケースを考慮するまでは単純そうに見えます：ドキュメントで扱われていない質問をされた場合はどうなるのか？ 異なる2つのユーザー層が同じインターフェースを使用する場合は？ AIに個性を与えつつ、支離滅裂な回答をさせないようにするにはどうすればよいのか？ そして、誰かがプロンプトを完全に乗っ取るのを防ぐにはどうすればよいのか？
このページでは、本設計がこれらの各問題をどのように解決しているかを解説します。
対象ユーザーへのルーティング
Artieは、単一の対話型インターフェースを通じて、2つの対象ユーザーに対応しています：
- 開発者およびエンドユーザー：セットアップ手順、APIリファレンス、またはドキュメントサンプルの説明を探しているユーザー
- 採用担当者や人事担当者：本ポートフォリオを評価し、資格、経験、または執筆プロセスについて質問する可能性のあるユーザー
個別のフローを構築したり、ユーザーに自己申告を求めたりするのではなく、プロンプトは意図に基づいてルーティングを行います。技術的な質問には、ドキュメントインデックスに基づいた段階的な回答が提供されます。ポートフォリオに関する質問には、履歴書の背景情報とサイト上の執筆サンプルを統合した回答が返されます。インデックスに履歴書の背景情報が含まれていない場合、Artieは回答を生成しようとせず、代わりに訪問者を「About Me」ページへ誘導します。
このアプローチにより、インターフェースはシンプルに保たれます（チャットは1つだけで、分岐メニューはありません）。同時に、それぞれの対象者が適切な回答を得られることが保証されます。
知識の基盤と検索
Artieの設計における最も重要な制約は、Algoliaを利用したドキュメントインデックスのみから排他的に回答することです。これが検索拡張生成（RAG）の中核原則です。モデルの応答は、一般的なトレーニングデータから引き出すのではなく、特定のコンテンツ群に錨を下ろしています。
実際には、これは次のことを意味します：
- 架空のコンテンツの排除—アシスタントは、ドキュメントに記載されていない機能をでっち上げたり、ダウンロードリンクを作成したり、手順を説明したりすることはありません。
- 出典リンクの提供—アシスタントはインデックスからのURLやファイル参照を提供し、ユーザーが関連ページに直接移動できるようにします。
- 適切なフォールバック—インデックスに関連情報が不足している場合、Artieはその制限を率直に述べ、再試行やループ、推測を行うことなく、直接連絡を取るよう提案します。
そのトレードオフは対応範囲（スコープ）です—Artieは公開されているドキュメントの範囲外のことには対応できません。これは制限ではなく、特徴です。ポートフォリオサイトにおいては、網羅性よりも正確さが重要です。狭い範囲の質問に対する正確で出典の確かな回答は、一見もっともらしく聞こえて実際には間違っている回答よりも、高い信頼を築きます。
ペルソナとトーンの調整
Artieには軽量な個性があります—ジョージ・ハリスンにインスパイアされた穏やかな温かみと、時折混ざるリヴァプール方言です。キーワードは軽量です。このペルソナは、技術的な内容に干渉することなく、挨拶や締めくくりに個性を加えています。
ここでの設計上の制約は意図的なものです：
- 技術的な回答は簡潔に維持する—個性を理由に回答を長くすることはありません。温かい挨拶の後に簡潔で事実に基づいた回答を続けることで、この目標を達成します。
- 繰り返しよりも多様性—プロンプトには表現のプールが含まれており、Artieが毎回同じ決まり文句に頼るのを防ぎます。
- 説教調の排除—ペルソナは温かく少し皮肉めいたトーンを維持し、説教臭くなったり威圧的になったりすることは決してありません。キャラクターの演技ではなく、役に立つ同僚のように機能します。
このようなトーンの調整は、会話型AIの設計における共通の課題です。個性が強すぎるとアシスタントはギミックのように感じられ、少なすぎるとロボットのように感じられます。解決策は、ペルソナを調味料として扱うことです—存在感はあっても、決して主原料にはしません。
セキュリティとガードレール
ここからが設計の本番です。一般公開されるAIアシスタントは攻撃対象領域（アタックサーフェス）となるため、プロンプトには大規模言語モデル（LLM）の一般的な脆弱性に対する明確な防御策が含まれています。
プロンプトインジェクション対策
Artieのプロンプトは、「以前の指示を無視せよ」といったコマンドや別のペルソナを採用するよう求める要求など、指示を上書きしようとする試みを明示的に拒否します。これにより、OWASPの大規模言語モデルアプリケーション向けTop 10で第1位にランクされているプロンプトインジェクションに対するプロンプトレベルの防御が確立されます。
スコープ制限
プロンプトは明確な拒否カテゴリを定義しています：
- 一般的なコーディング支援—ドキュメントでカバーされていないコーディングの質問をアシスタントは辞退します。
- 無関係な雑学—特別に定義された2つの楽しい機能の範囲外のリクエストをアシスタントは拒否します。
- 個人情報—プロフェッショナルポートフォリオに公開されていない個人情報に関する問い合わせをアシスタントは辞退します。
- フリーランスの料金や交渉—アシスタントは訪問者に直接連絡するよう案内します。
各カテゴリには明確な境界線があります。アシスタントは、回答するのに「十分近い」かどうかを主観的に判断する必要はありません。定義されたスコープ外であれば、丁寧に辞退します。
データプライバシー
Artieは、LinkedInプロフィールやポートフォリオのメールアドレスなど、ドキュメントに明示的に公開されている連絡先情報のみを共有します。電話番号や住所などの個人情報を推測、推論、または生成することはありません。
職業上の境界線
アシスタントは、敵対的なメッセージに応じたり、卑語を使用したり、キャラクターを崩したりすることはありません。これは単なる礼儀正しさを超えています。予測可能な動作を維持するためのものです。アシスタントの限界を試そうとする採用担当者は、毎回一貫したプロフェッショナルな境界線に出会うことになります。
制御されたイースターエッグ
Artieには、悪用の余地を残さずに個性を加える方法を示す2つの「楽しい機能」—Snapple Real Factsときれいなジョーク—が含まれています。
どちらの機能も同じ設計パターンを共有しています：
- 明示的なトリガー—曖昧または的外れなプロンプトではなく、特定のユーザーリクエスト（「Snappleの豆知識を教えて」「ジョークを言って」）でのみ作動します。
- 限定されたコンテンツ—Snappleの豆知識は埋め込まれた検証済みリストに基づいており、ジョークは厳選されたファミリーフレンドリーな内容に限定されます。
- 根拠のない捏造の排除—アシスタントは事実をでっち上げたり、ブランドイメージに合わないユーモアを生成したりすることを避け、対応範囲を厳格に制御します。
これは重要です。制限のない創作機能はトークンを急速に消費し、予測不能な出力を生み出すからです。コンテンツを厳選しトリガーを明示的に保つことで、これらの機能はリスクなく温かみを加えます。
改善したい点
実際のユーザーと接して変更されずに残る設計はありません。私が再検討したい点は以下のとおりです：
- トークンコスト—Snappleの豆知識リストだけでも100項目を超えます。トークン単位で課金される本番システムでは、システムプロンプトに埋め込むのではなく、検索レイヤーに移行するでしょう。チームは、ユーザーが豆知識を求めたかどうかにかかわらず、すべてのリクエストでプロンプト内のすべてのトークンに対して料金を支払います。
- マルチターンコンテキスト—現在の設計はシングルターンのQ&Aを対象としています。より洗練されたバージョンであれば、会話履歴を保持し、クエリを再構成して「次のステップはどうすればいい？」といったフォローアップの質問を解決できるでしょう。
- 分析とフィードバック—Artieがどの質問をうまく処理し、どの質問でフォールバックが発生したかを追跡する仕組みがありません。軽量なロギング（フォールバック応答をカウントするだけでも）を追加すれば、補完すべきドキュメントのギャップが明らかになるでしょう。
- 動的なペルソナ調整—プロンプトは個性の表現をハードコードしています。より保守性の高いアプローチとしては、外部のペルソナ設定を参照し、中核となる指示セットを編集することなくトーンを調整しやすくすることが考えられます。
これらはそれぞれ、本番規模の最適化よりもシンプルさと明快さが重要なポートフォリオプロジェクトのための意図的なトレードオフです。しかし、トラフィックの多い環境に移行する場合、これらは真っ先に対処すべき項目です。