
Inkeepが実際どういうものか
正直に言おう。私はサポートキュー向けのAIを仕事として作っている人間なので、こうしたプラットフォームを読むときは「何を簡単にし、何をそっと利用者任せにしているか」を見る。Inkeepは、開発者向けドキュメントサイトで見かけたことがあるであろう「Ask AI」検索ウィジェットとして始まり、2025年を通じてもっと大きなもの、つまりカスタマーエクスペリエンス・プロダクト・go-to-marketチーム向けの「AIチームメイト」として創業者が売り込むAIエージェントプラットフォームへと成長した。
同社はサンフランシスコ拠点のY Combinator W23出身スタートアップで、Nick Gomez氏とRobert Tran氏が創業し、2025年9月にはKhosla VenturesとGreatPoint Venturesが主導する1,300万ドルのシード資金調達を発表した。顧客リストは開発者ツール企業に大きく偏っている。Postman、Anthropic、Pinecone、PostHog、Solana、Clerkなどだ。これは偶然ではなく、Inkeepが自分に合うかどうかを判断するうえで最も有用な一点だ。

上のスクリーンショットは実際のビルダーで、それが物語を語っている。これはサブエージェント、MCPサーバー、認証情報、トレースを備えたエージェント構築用のキャンバスであり、サポートダッシュボードというよりエンジニアリングツールに近い。それがあなたにとって強みになるか警告になるかは立場次第だ。
Inkeepが本当に向いているのは誰か
最も分かりやすい表現をするなら、Inkeepはドキュメントをプロダクトの表面として扱い、手元に開発者がいるチーム向けだ。もしあなたが開発者ツール企業で、サポートの実態が「ユーザーがAPIを使うのを助けること」であり、引用付きのAIドキュメントアシスタントに加えてTypeScriptで独自エージェントを組み立てる自由が欲しいなら、これは市場でも上位の選択肢の一つだ。
一方、たとえばEコマースやSaaS企業のサポートマネージャーで、来週中にZendesk内で返金やアカウントのチケットを解決するAIヘルプデスクエージェントが欲しいという場合には、相性が悪い。Inkeepをそこまで持っていくことはできるが、それは単に切り替えるセルフサーブのスイッチではなく、エンジニア主導の導入とエンタープライズ契約に申し込むということになる。
最大の魅力:ノーコードとコード、そして双方向同期
ここがInkeepが資金調達に見合う実力を発揮する部分だ。ほとんどのエージェントビルダーはどちらか一方を選ばせる。ノーコードツールはGUIに閉じ込め、コードフレームワークはコンテンツを所有する非エンジニアに使えるインターフェースを提供しない。Inkeepはノーコードビジュアルビルダーと@inkeep/agents-sdkというTypeScript SDKの両方を提供し、両者の間で完全な双方向同期があると謳っている。つまり、どちらの画面でも同じエージェントを編集できる。
npx @inkeep/create-agentsという単一のコマンドでプロジェクトを立ち上げ、その後コードでエージェントとサブエージェントを定義する。
import { agent, subAgent } from "@inkeep/agents-sdk";
const helloAgent = subAgent({
id: "hello-agent",
name: "Hello Agent",
description: "Says hello",
prompt: `Reply to the user...`,
});
export const basicAgent = agent({
id: "basic-agent",
name: "Basic Agent",
defaultSubAgent: helloAgent,
subAgents: () => [helloAgent],
});
内部的には、エージェントはサブエージェントのチームであり、互いに作業を引き渡す(transfer)か委任(delegate)し合う。ツールは主にMCPサーバーとして追加され、Composio経由で1万を超える既製のものも利用できる。あなたのエージェント自体をMCPサーバー「として」公開したり、A2Aエンドポイント経由で呼び出したり、webhookやcronスケジュールでトリガーしたりもできる。ソフトウェアを作るのが好きな人には、良い道具箱だ。
正直な注意点は、この力こそが魅力であり、同時に払うべき対価でもあるということだ。あるStreamのエンジニアはHacker Newsでうまく言い表している。
"We use them at getstream.io, the RAG on SDKs is way ahead of other platforms in this space."
その称賛は本物で、エンジニアからのものだ。Inkeepに最も声援を送るのは他の開発者である傾向があり、自分のチームが実際に使う姿を思い描くときにはそのことを覚えておく価値がある。
ナレッジエンジンの仕組み
どちらの方法で構築するにせよ、顧客向けアシスタントは同じ4ステップのループ、すなわちソースを接続し、自動で取り込み、引用付きで回答し、そして改善する、という流れの上で動く。Inkeepは数十のコネクタからデータを引き込む。ナレッジ側ではNotion、Confluence、SharePoint、Google Drive、ヘルプデスク側ではZendesk、Freshdesk、Help Scout、Salesforce、HubSpot、それに加えてWebクロールやファイルアップロードもある。

検索の面では、現代的なAI検索エンジンに期待することをきちんとこなす。リランキング付きの語彙検索とベクトル検索を組み合わせたハイブリッドなセマンティック検索、すべての回答に付く出典引用、そして回答を取得したコンテンツに限定するガードレールだ。4番目のステップはチームが過小評価しがちな部分である。Inkeepのギャップレポートは答えられなかった質問を洗い出すので、不足しているドキュメントを書きに行ける。これにより、推測に頼るのではなくナレッジベースのループを閉じることができる。

サポート面:KeepとCoworker
Inkeepにはドキュメント検索を超えたサポートエージェントの側面もある。「Keep」はチケットツール内で動き、返信案を作成するコパイロットで、社内向けの「Coworker」はSlackやサポートプラットフォームから起動し、CRMからコンテキストを集めて、エージェントが送信できる承認待ちの返信案を表示する。Webサイトアシスタントも、複雑な問題は自動的に人間へエスカレーションする。

これは堅実な機能だが、その形に注意してほしい。サポート面も同じドキュメント基盤のエンジンに依存しており、最も深いチケットデフレクションとチャネル連携(Slack、Zendesk、Salesforce)はEnterpriseプランに入っている。質問の大半が「APIはどう動くのか」であれば、これは輝く。大半が「注文はどこにあるのか」であれば、あまり得意ではないチケットトリアージの仕事をドキュメントエンジンに求めていることになる。
Inkeepが示せる数字
Inkeepが「効率が上がる」といった曖昧な主張ではなく、実際の具体的な数字を伴うケーススタディを公開している点は評価に値する。最も強力なものは以下の通りだ。
| 企業 | 用途 | 主な結果 |
|---|---|---|
| Fingerprint | AIドキュメントサポート + Zendeskコパイロット | サポートチケット48%減(A/Bテスト済み)、アクティベーション+18% |
| PostHog | コミュニティフォーラムの質問への自動回答 | 質問の33%を自動解決(759件中247件) |
| Payabli | ドキュメント + Slack + チケットコパイロットの統合 | デフレクション率80%(ベンチマークの50〜60%に対して) |
FingerprintとPostHogの数字を最も信頼できるのは、方法論が伴っているからだ。Fingerprintは自社の48%を「A/Bテストによって統計的に有意」と呼び、アクティベーションを初回のAPI呼び出しと定義している。PostHogは生の分母(約6か月間で759スレッド中247件)を提示している。これがデフレクションの本来あるべき報告の仕方であり、ほとんどのベンダーはそうしていない。
どのツールを買うかにかかわらず、盗んでおく価値のあるPostHogのディテールが一つある。同社のリードデザイナーはこう説明している。
"If Inkeep is highly confident in the quality of response, we show the answer as a reply in the community thread immediately. If not, we simply don't post the AI response at all... This reduces the brand risk of unleashing a poorly-tuned AI bot that annoys users."
推測するくらいなら黙っておく確信度ゲートは、あらゆるAIカスタマーサービスの導入における正しいデフォルトだ。
実際のユーザーの声
Inkeepは開発者ファーストの小規模なツールなので、G2に何百件ものレビューがあるとは期待しないでほしい。実際には一件もない。G2、Capterra、Trustpilotに実質的な存在感はなく、この段階では普通のことだ。検証可能な意見はHacker Newsにあり、実際に導入した運用者からは強くポジティブだ。
"I'm not sure how they do it but the answer quality and the UI is meaningfully better than all the other 'chat with your docs'-type products I've tried."
PostHogによる最も引用される一言は、カテゴリー全体に対する良い判断材料になる。
"IMO Inkeep has been the first AI solution that hasn't sucked, and that's high praise coming from me!"
すべてが称賛というわけではなく、批判こそが有用な部分だ。2025年にInkeepがAgent Builderをローンチした際、最も反発を招いたのは、Elastic License 2.0でのリリースを「オープンソース」と呼んだことだった。
"Fake 'Open source' all over again.. why do we repeatedly have to do this?... I was excited with the pitch. And then had this completely ruin your image."
これは正当な指摘だ。このフレームワークはElastic License 2.0の下でソースアベイラブルであり、n8nのライセンスと同じ系統で、セルフホストしてコードを読むことはできるが競合利用を制限する。それ自体は十分に合理的なライセンスだが、ほとんどのエンジニアが「オープンソース」という言葉で意味するものとは違う。Inkeepは「ソースアベイラブル」と言うだけで、無用の反発を避けられるはずだ。
Inkeepの料金:営業との会話を覚悟すべし
ここが買い手にとって気になる部分であり、正直な答えとしてはInkeepは価格を公開していない。マーケティングの価格ページは執筆時点で404を返し、ドキュメントには2通りの購入方法しか記載がない。

| プラン | 価格 | ホスティング | 得られるもの |
|---|---|---|---|
| Open Source | 永久無料 | セルフホスト(Vercel/Docker) | ビジュアルビルダー+SDK、マルチエージェント、MCPツール、トレース。サポートはコミュニティのみ |
| Enterprise | 見積もり制、営業に問い合わせ | クラウド、ハイブリッド、またはセルフホスト | マネージドRAG取り込み、Slack/Zendesk/Salesforceチャネル、SSO/RBAC、SOC 2、フォワードデプロイエンジニア |
この分け方は巧妙で、理解しておく価値がある。ほぼすべての「構築」面はオープンソースプランで無料だ。お金を払うのは「マネージド」の部分、つまりホスト型の取り込み、サポートデスクやチャットプラットフォームのチャネル、コンプライアンス、そして人的サポートである。マネージドプラットフォームの無料トライアルはなく、自社コンテンツでの30日間デモのみで、公開されている座席数課金や解決数課金の指標もない。2024年のローンチ当時、あるコメンターは月額150ドルという入門価格に反発していたが、今日ではその数字さえ公開されていないので、営業との会話を予算に組み込んでおくべきだ。
Dockerを喜んで動かし、自前の取り込みを構築してくれるエンジニアがいるなら、オープンソースプランは本物の気前の良いオファーだ。そうでないなら、あなたが買うのはEnterpriseであり、SaaSのサブスクリプションではなくエンタープライズのコミットメントとして予算を組むべきだ。
Inkeepの限界、そして私が別を探す場面
これはどれもInkeepへの非難ではない。Inkeepは、それが作られた目的においては優れている。しかし、その重心はエンジニアリング主導のセットアップを伴う開発者向けドキュメントのデフレクションにあり、そのために、コントロールよりスピードを求めるサポートチームには本当の隙間が残る。

構築プロジェクトなしで実際のチケットキュー上ですぐに稼働できる、その左上の領域こそ私が時間を費やしている場所であり、そこでサポートチームが何を得られるのか具体的に述べたい。
eeselを試す
ドキュメントサイトではなくサポートキューを運用しているからInkeepのレビューを読んでいるのなら、eeselはまさにそのマップの一角のために作られている。すでに使っているヘルプデスク、Zendesk、Freshdesk、あるいは共有受信箱に組み込むAIチームメイトであり、公開ドキュメントだけでなく過去のチケットやマクロから学習する。

Inkeepとの違いで最も重要なのは2点だ。まず、セットアップはエンジニアリングスプリントではなく分単位で測られ、実際に顧客へ返信する前に、eeselは何千もの過去のチケットでシミュレーションを行い、得られるであろう解決率を確認できる。次に、料金は公開されており従量制なので、数字を知るためだけにデモを予約する必要がない。
そして、Inkeepの開発者向けの側面が気に入っていたとしても、それを諦める必要はない。eeselはCLIとMCPサーバーを提供しており、ダッシュボードで設定するのと同じチームメイトをターミナルから操作したり、自分のワークフローに組み込んだり、Claude CodeやCursorのようなコーディングエージェントに操作させたりできる。エンジニアが求めるプログラム可能な制御を、まずプリミティブからエージェントを組み立てる手間なしで手に入れられる。無料で試すことができ、何かにコミットする前にシミュレーションが実行される。
よくある質問
Inkeepとは何で、どんな企業に向いていますか?
Inkeepの料金はいくらですか?
Inkeepは本当にオープンソースですか?
Inkeepのチケットデフレクションの実力はどうですか?
Inkeepの代替として最適なものは何ですか?

Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.








