← 一覧に戻る

chibabot REST API 拡張計画 — チバとの会話をもっと便利に

2026年3月3日 00:30 更新

一言でいうと

チバの機能を REST API（汎用的な窓口）で公開し、誰でもどこからでも使えるようにする

なぜこれが必要なのか

現在、Claude Code からチバに質問する方法は1つだけ — 「単発で質問して、単発で回答をもらう」こと。前に何を聞いたかの文脈は残らないし、会話履歴を検索したり、スレッド（話題ごとのまとまり）で管理することもできない。

一方、スマホのチャットアプリ（chibabot-PWA（チバ専用のスマホ向けWebアプリ））には、スレッド管理・メッセージ検索・会話のエクスポート（書き出し）・画像からの文字読み取りなど、便利な機能がすでにたくさんある。

なぜ MCP ではなく REST API なのか

当初はMCP（AIツール専用の通信規格）で機能を公開する計画だったが、方向転換した。理由は「制御権」の問題。

MCP（ツール定義で使い方を固定）
「チバに質問する」機能 → question しか渡せない。RAG検索件数を変えたい、記憶検索をスキップしたいなど、使う側の自由がない。提供側が「こう使え」と決める
REST API（パラメータで機能を柔軟に公開）
「チバに質問する」API → question, ragLimit, includeContext, systemPromptOverride... 何をどう組み合わせるかは使う側が決められる。パラメータを増やすだけで機能拡張できる

REST API（プログラム同士が会話する窓口）なら、Claude Code・PWA・将来のアプリなど、あらゆるクライアントが同じエンドポイント（受付窓口）を叩ける。MCPは将来、この REST API の薄いラッパー（包み紙）として追加する。

何が変わるのか

今まで

  • 単発の質問しかできない
  • 会話の流れが残らない
  • 過去の質問を探せない
  • スマホアプリでしかスレッド管理できない

拡張後

  • スレッド（話題別の部屋）で会話を続けられる
  • 過去の会話を横断検索できる
  • Markdown/JSONで会話を書き出せる
  • 画像から文字を読み取って質問に使える

追加される10個のAPIエンドポイント

エンドポイントとは「プログラムがリクエストを送る宛先」のこと。以下の10個が新たに使えるようになる。

エンドポイントできること
POST /api/threads/:id/askチバに質問する（スレッドの文脈付き。RAG検索件数やプロンプトも指定可能）
POST /api/threads新しいスレッド（話題の部屋）を作成する
GET /api/threadsスレッド一覧を取得する（ページ送り対応）
GET /api/threads/:idスレッドの詳細情報を取得する
PATCH /api/threads/:idスレッドの名前変更・ピン留め・アーカイブ
DELETE /api/threads/:idスレッドを削除する（復元可能な安全削除）
GET /api/threads/:id/messagesスレッド内のメッセージ履歴を取得する
GET /api/messages/search全スレッドを横断してメッセージを検索する
POST /api/threads/:id/export会話をMarkdown/JSONで書き出す
POST /api/ocr画像から文字を読み取る（OCR（画像から文字を読み取る技術））

実際のClaude Codeでの使い方イメージ

言葉だけだとピンとこないと思うので、実際にClaude Code上でどんな対話になるか、具体例を見てみて。

例1: スレッドを作って相談する

You: 「あやか」って子のスレッド作って。初デートの相談したい
→ POST /api/threads { title: "あやか", emoji: "👩" }
スレッド「あやか」(👩) を作成したわ。threadId: abc-123
You: あやかのスレッドでチバに聞いて。「来週初デートなんだけど、表参道でランチのいい店ある？」
→ POST /api/threads/abc-123/ask { question: "来週初デート...", ragLimit: 5 }
チバの回答: 「表参道なら◯◯がオススメだぜ。初デートのランチは...」
※ この会話はスレッド「あやか」に自動保存される

例2: 別のスレッドに切り替える

You: スレッド一覧見せて
→ GET /api/threads?status=all
📌 あやか (👩) — 最終更新: 5分前
    まい (🌸) — 最終更新: 3日前
    恋愛テクニック全般 (📚) — 最終更新: 1週間前
You: まいのスレッドでチバに聞いて。「2回目のデートに誘うLINE、どう送ればいい？」
→ POST /api/threads/def-456/ask { question: "2回目のデート..." }
チバの回答: 「まいちゃんとの前回の会話を踏まえると...」
※ 「まい」のスレッドの過去の会話を文脈として使うので、あやかの話は混ざらない

例3: 過去の会話を検索する

You: 全スレッドで「LINE」について検索して
→ GET /api/messages/search?query=LINE
検索結果 3件:
[まい] チバ: 「LINEは即レスしすぎないのがコツ...」
[あやか] あなた: 「LINEの頻度ってどれくらいがいい？」
[恋愛テクニック全般] チバ: 「LINE交換のタイミングは...」
! スレッドでコンテキスト（文脈）が分離される
スレッドごとに会話が独立しているので、「あやか」のスレッドで聞いたことは「まい」のスレッドには影響しない。チバに質問するときは必ず「どのスレッドで」を指定する仕組みなので、意図しない文脈の混在（コンテキスト汚染）が起きない。スレッド名は完全に自由 — 女の子の名前、シチュエーション名、何でもOK。

たとえば「あやか」のスレッド詳細を GET /api/threads/:id で取得すると、タイトル・絵文字・ピン留め状態・メッセージ件数・最終更新日時が返ってくる。GET /api/threads/:id/messages でメッセージ履歴を取得すれば、あやかとの会話内容（自分の質問とチバの回答）が直近100件分まるごと出力される。Claude Code が自動的にこの情報を参照して、文脈を理解した上で次のアクションを提案できるようになる。

MCP ラッパーは Phase 3 で追加: REST API が完成した後、Phase 3 で MCP ツール/リソース（AIツール専用の薄い包み紙）を追加する。Claude Code は Phase 1 の時点からスキル（SKILL.md という指示書）経由で REST API を直接叩けるので、MCP を待つ必要はない。

データの保存場所

会話データの保存先として、D1（Cloudflareが提供するクラウド上のSQLiteデータベース）を新たに導入する。これまでPWAではスマホ内部（IndexedDB（ブラウザ内蔵のデータベース））にデータを保存していたが、D1を正本（データの「原本」）にすることで、Claude Code・PWA・将来のネイティブアプリなど、どこからアクセスしても同じデータを参照できるようになる。

! なぜD1なのか
現在使っているKV（キー・バリュー型のシンプルな保存庫）は「いつかデータが反映される」タイプで、「Aさんが書いたデータをBさんがすぐ見られる」保証がない。会話の履歴は順序が大事なので、「書いたら即座に反映される」D1のほうが適している。

セキュリティ設計

12回のCodex（OpenAIのAIレビューツール）レビューで徹底的に鍛えた安全設計。主なポイントは以下の通り。

ユーザー認証とアクセス制御

画像読み取り時の安全対策（SSRF防御）

画像URLを受け取って文字を読み取る機能では、悪意のあるURLで内部ネットワークにアクセスされないよう多層防御を施している。

実装ステップ（4フェーズ）

1 基盤構築（D1 + REST API コアエンドポイント7個）
データベースの作成、ユーザー認証、スレッド管理とチバへの質問APIを実装する。これだけで「スレッドでチバと会話する」基本体験が完成する。Claude Code からはスキル（SKILL.md）経由で即座に利用可能。
2 検索・エクスポート + スキル SKILL.md
横断検索と会話エクスポートのAPIを追加。Claude Code から REST API を叩く手順を記述したスキル（SKILL.md）も作成する。過去の会話を「あのとき何て言ってたっけ？」と探せるようになる。
3 MCP ラッパー + OCR + 権限細分化
REST API の上に MCP ツール/リソース（AIツール専用の薄い包み紙）を追加。画像文字読み取り機能も追加。トークンごとの権限細分化も行う。
4 PWA との同期（将来）
PWA（スマホアプリ）の保存先をD1に切り替えて、スマホとClaude Codeで同じ会話データを共有できるようにする。REST API なので PWA はそのまま同じエンドポイントを叩くだけ。

ポイント

Codex 12回レビュー済み: OpenAIのAIレビューツールに12ラウンド（合計39件以上の指摘を解消）のレビューを受けてLGTM（問題なし判定）を獲得。セキュリティ・データ整合性・パフォーマンスの3方面から徹底的に検証された設計。

PWAの機能をそのまま移植しない: Push通知（ブラウザ固有機能）、オフラインキュー（クライアント側の責務）、非同期プロキシ（Claude Codeでは不要）など、MCPに不向きな機能は意図的に除外している。必要な機能だけを、MCPに適した形で再設計した。

YAGNI原則: 日本語の全文検索は、Phase 1 では「部分一致検索」というシンプルな方法で始める。個人利用（数千〜数万件）なら十分な速度。データ量が増えて遅くなったらPhase 4で高度な検索方式に切り替える。

📝 質問モード — テキストを選択してね
✓ 質問を送信しました