本記事はポエムです。
Q&A専用チャットを用意したが使いづらい？
Q&Aチャットを導入したが、上記のような使いづらさを感じたことはありませんか？
「RAG用のドキュメントを追加するたびに管理画面を開いてアップロードしないといけない」
「質問するたびにチャット画面を開くのが面倒」
「古いデータかどうか判断しないといけない」
私は実際にシステム開発のPJでRAGを使ったQ&Aチャットがあったのですが、このような使いづらさを感じていました。
RAGには最新の仕組みを使っていて精度も高い、画面もモダンで使いやすい、、、でもなんで使いづらい？
私はこれをUXの問題と考えました。
具体的には、下記のような行動コストです。
画面遷移・選択・確認
面倒くささがナレッジの流れを止める
一般的なRAGシステムの操作を分解してみると、こうなります。
ドキュメントを追加したい
→ フォルダ名・ファイル名を確認する（古いファイルが混じっていないか）
→ 管理画面 or アップロード用ツールを開く
→ ファイルをアップロードする
質問したい
→ チャットAIの画面を開く
→ 使用する知識を選択 or 専用のカスタムチャットを開く
→ 質問する
それぞれ3ステップです。1回なら大した手間ではありません。でも「ちょっとドキュメント共有しておこうかな」という軽い動機に対して、この3ステップは面倒に感じます。人は手間に正直です。 （主語がでかいですね。私は手間に正直です。。。）抵抗感を覚えた瞬間、「後でやろう」になります。
その結果、何が起きるか。
- ドキュメントが上がってこない → 知識DBが育たない（RAG用のデータが蓄積されない）
- 質問する習慣がつかない → RAGが「あるけど使わないもの」になる
- データが個人の手元に残り続ける → 俗人化が解消されない
RAGのシステムとしての品質がいくら高くても、ナレッジが流れてこなければ意味がありません。 問題の本質は、ドキュメント登録と質問という2つの行動を、いかに日常の延長として設計できるか、です。
対策の原則：ツールをユーザーのいる場所に置く
この問題（冒頭ではUXの問題と仮定）に対して、今回考えてた対策はシンプルです。
「ユーザーが移動しなくていいようにする」
エンジニアがすでに開いているもの——それはターミナルとエディタです。
であれば、そこにRAGの入口を置けばいいじゃないか？
別のツールを開かせない。画面を切り替えさせない。今いる場所で完結する。これがこのUX設計の核心です。
最近ではターミナルで動くAIツール（Claude Code CLI）があり、「スキル」という仕組みがあります。プロジェクト固有のスラッシュコマンド（例：/upload）を定義しておくと、ユーザーがそれを入力した瞬間にAIエージェントが指示書（SKILL.md）を読んで必要な処理を実行してくれる、というものです。このスキルを使って、RAGのアップロードと質問をCLIチャット上に統合しました。
2つの導線設計（skillの設計）
/upload：「共有する」の心理的ハードルを下げる
ドキュメントを共有しない理由の多くは、手間です。「あとでやろう」が積み重なり、気づけば知識が個人の手元に眠ったままになります。
/upload は、この「あとで」をなくすための設計です。
Claude Code CLIを開いた状態で /upload と打つだけで、指定フォルダのファイルがそのままRAGサーバーへ送られます。ユーザーはファイルを選ばない。画面を開かない。コマンドを覚えないでOKです。
アップロード済みかどうか？Oldフォルダかどうか？などはAgentが判断します。
/rag 質問文：「調べる」を会話に溶け込ませる
「調べる」行動が別ツールへの切り替えを要求する限り、それは習慣にはなりません。
/rag は、質問をCLIの会話の延長として行えるようにします。コードを書きながら、設計を考えながら、ふと「これどういう仕様だっけ」と思ったとき——そのままチャット欄に /rag 質問文 と打てば答えが返ってくる。ウィンドウと頭の切り替えコストが発生しません。
「アップロードする」「調べる」という行動が、CLI上の会話の一部になる。それがこの設計の狙いです。
実際作って・使ってどうだった？
実際にCLI上で動かしてみた様子です。「コードを書く手を止めずに、そのまま質問できるか」という観点で見てください。
ユーザー: /rag マイクロサービス間の通信方針を教えて
Claude: 当社のマイクロサービス間通信は、原則として「同期通信は最小限、
非同期通信を基本」とする方針です。
- 同期通信（gRPC）：ユーザーリクエストの直線的な処理経路に限定
- 非同期通信（メッセージキュー）：状態変更の伝播・後続処理・通知系
サービス間で直接DBを参照することは禁止しており、必ずAPIまたは
イベント経由でやりとりします...
=== 参照元 ===
[1] microservices_design_principles.md (score: 0.564)
[2] inter_service_communication.md (score: 0.491)
ユーザー: /rag 認証APIのエラーハンドリング方針を教えて
Claude: 認証APIでは、認証失敗時に詳細なエラー理由を返さず、汎用的な
401 Unauthorized を返す方針です。これは、...
=== 参照元 ===
[1] api_design_guide.md (score: 0.512)
[2] security_policy.md (score: 0.448)
ドキュメントにない情報を聞くとちゃんと「見つかりませんでした」と返ってきます。
ユーザー: /rag GraphQLのレートリミット設定について
Claude: 関連する情報が見つかりませんでした。
（スコアが低く、関連ドキュメントなし）
回答には参照元ドキュメントとスコアが添えられるため、「どこから答えたか」が透明です。
まとめ
今回のアイデアで操作がどう変わったかを表で書くとこのようになります。
| 行動 | 従来のRAG操作 | このプロジェクトでの操作 |
|---|---|---|
| 共有する | 管理画面を開く → ファイル選択 → アップロード |
/upload と打つ |
| 質問する | チャットを開く → 知識を選ぶ → 質問する |
/rag 質問文 と打つ |
UXのシンプル化は目的ではなく手段です。目指したのは、ナレッジの収集と活用が、意識しなくても起きる状態をつくることです。
Claude Code CLIのスキル機能は、既存のバックエンド資産をチャットUIに昇格させる軽量な手段として有効でした。エンジニアが日常的に開いているツールの中に、RAGの入口を溶け込ませる——この設計アプローチが、誰かの参考になれば幸いです。